欒開寧 鄭海雁 丁 陳 李昆明

（1.江蘇省電力公司，南京 210024； 2.江蘇方天電力技術(shù)有限公司，南京 211102； 3.上海晟淘大數(shù)據(jù)科技有限公司，上海 200433）

隨著電力系統(tǒng)數(shù)字化進程的推進，電力系統(tǒng)積累了大量的發(fā)、輸、用電數(shù)據(jù)。目前僅江蘇省用電信息系統(tǒng)歷年保存下來的全省用電信息數(shù)據(jù)已達到幾十TB，如何利用現(xiàn)有的大數(shù)據(jù)分析技術(shù)，挖掘電力大數(shù)據(jù)的潛在價值，使電力企業(yè)為客戶提供更好的服務(wù)，是一個值得研究的課題。而2013年《中國電力大數(shù)據(jù)發(fā)展白皮書》[1]的發(fā)布，將中國的電力大數(shù)據(jù)研究推向了一個新的起點，對中國電力大數(shù)據(jù)的研究與應(yīng)用有著劃時代的意義。

目前比較常見的大數(shù)據(jù)解決方案為 Hadoop+ HBase[2]，該解決方案通過搭建分布式處理軟件框架和分布式存儲系統(tǒng)[3-4]，實現(xiàn)大數(shù)據(jù)的分布式存儲和查詢。HBase 是按Rowkey 進行排序和存儲的，在進行數(shù)據(jù)查詢時需要對數(shù)據(jù)塊按行檢索，查詢速度遠無法滿足實時的需求。

本文提出采用動態(tài)索引圖（Dnamic Index Graph,DIG）技術(shù)建立電力大數(shù)據(jù)的索引，實現(xiàn)多條件列索引的建立和快速組合查詢，它通過建立索引圖為每個查詢專門創(chuàng)建復(fù)合索引，避免了全表逐行掃描，大大提升了查詢的速度。

1 用電大數(shù)據(jù)的特征

文獻[1]指出電力大數(shù)據(jù)其特征可概括為3“V”3“E”，3“V”代表體量大（Volume），類型多（Variety）和速度快（Velocity），3“E”代表數(shù)據(jù)即能量（Energy）、數(shù)據(jù)即交互（Exchange）、數(shù)據(jù)即共情（Empathy）。在用電大數(shù)據(jù)中，這樣的概括同樣適用。

體量大。目前為止江蘇省用電采集系統(tǒng)投入運行140 余萬臺采集終端，120 余萬集抄終端，覆蓋3400 余萬用戶。僅上采集一項日產(chǎn)生數(shù)據(jù)量達30多GB，自2006年以來，積累下來的數(shù)據(jù)已達40TB之多。在構(gòu)建基于氣象因素的用電影響因素模型時，經(jīng)多輪次數(shù)據(jù)驗證、調(diào)整、重算，生成江蘇省13 個地市8000 多類，300 多萬條模型數(shù)據(jù)，預(yù)計未來各模型反映的總電量影響關(guān)系將超過2 億條。

類型多。從數(shù)據(jù)本身結(jié)構(gòu)來看，用電數(shù)據(jù)類型包括結(jié)構(gòu)化數(shù)據(jù)、半結(jié)構(gòu)化數(shù)據(jù)和非結(jié)構(gòu)化數(shù)據(jù)。從業(yè)務(wù)角度來看，用電數(shù)據(jù)涉及不同用戶群體、不同行業(yè)領(lǐng)域、不同電氣指標等。未來，當(dāng)所有的大中型家用電器都裝有電量傳感器之后，用電數(shù)據(jù)類型將得到極大地擴展，也更加便于電力企業(yè)分析和研究用戶的用電結(jié)構(gòu)，為用戶提出更加合理的用電建議。

速度快。在采集端，目前3400 余萬居民用戶每日取一次電量數(shù)據(jù)、20 余萬企業(yè)用戶每15min 取一次電量數(shù)據(jù)，在未來將要求所有用戶15min、1min，甚至1s 取一次電量數(shù)據(jù)，這無疑對現(xiàn)有的通信系統(tǒng)傳輸速度、采集終端處理能力發(fā)起了極大地挑戰(zhàn)。在客戶端，電力公司要求實時處理大量產(chǎn)生的用電數(shù)據(jù)，實時優(yōu)化控制用電設(shè)備的啟停；居民用戶要求實時查詢用電量情況和家用電器用電比例，企業(yè)用戶要求實時查詢用電量情況和生產(chǎn)設(shè)備的運行情況。

2 大數(shù)據(jù)創(chuàng)建索引和快速查詢面臨的挑戰(zhàn)

2.1 大數(shù)據(jù)快速查詢存在的問題

一直以來，快速查詢是數(shù)據(jù)庫最核心的技術(shù)之一。數(shù)據(jù)庫一般存放的數(shù)據(jù)比較復(fù)雜，一個查詢往往需要將多個數(shù)據(jù)表相關(guān)聯(lián)，甚至需要跨庫數(shù)據(jù)的關(guān)聯(lián)，導(dǎo)致查詢性能急劇下降，即使在一個不是非常大的數(shù)據(jù)庫（千萬級）執(zhí)行一次查詢可能需要幾個小時，乃至幾天。

大數(shù)據(jù)帶來了諸多數(shù)據(jù)庫核心技術(shù)的突破。大數(shù)據(jù)的核心理念是“分布處理”，通過普通計算機橫向擴展，多臺設(shè)備協(xié)同工作，把耗時的計算分布在多臺設(shè)備上并行處理，從而獲得高性能。值得一提的是，大數(shù)據(jù)不僅僅通過“分布處理”獲得高性能，另一個非常重要的核心理念是“普通計算機”，通過大量低廉的計算機實現(xiàn)低成本、高性能。因為技術(shù)能力從某種程度上獲得了“無限”的提升，算法在某種意義上“失效”了：即通過大量快速計算，不同算法之間的差異趨于無限小。

但同時，在大數(shù)據(jù)快速查詢方面，主要問題是過度依賴大數(shù)據(jù)帶來的計算能力而放棄方法上的努力。如當(dāng)前市場上最火熱的基于Hadoop 的大數(shù)據(jù)系列產(chǎn)品，都是通過大量廉價機器堆積來獲得性能的保證。在大數(shù)據(jù)起步階段，這樣做可以獲得相當(dāng)不錯的數(shù)據(jù)處理效率的提升。然而，數(shù)據(jù)量往往不是線性增長的，而是呈指數(shù)形式的快速增長，但是硬件性能和數(shù)量卻是以線性方式在增長。這樣隨著時間的發(fā)展，數(shù)據(jù)量與硬件的矛盾在不遠的將來會再次成為大數(shù)據(jù)處理的瓶頸。

表1列出了基于Hadoop 的大數(shù)據(jù)快速查詢產(chǎn)品。

表1 基于Hadoop 的大數(shù)據(jù)產(chǎn)品

（續(xù)）

不難看出，絕大部分大數(shù)據(jù)快速查詢產(chǎn)品都放棄使用索引，HBase 也僅僅是一張表支持一個索引。華為在HBTC 2012 上公布了其二級索引方案，在業(yè)界引起了強烈的反響，它通過二級索引采用B 樹和R 樹互相補充的方式，可以通過維度信息范圍快速定位到子節(jié)點上的索引，有效提升大數(shù)據(jù)查詢速度。

2.2 大數(shù)據(jù)創(chuàng)建索引面臨的挑戰(zhàn)

大數(shù)據(jù)創(chuàng)建索引雖然重要，然而其難度也是同樣大幅提高的。

1）創(chuàng)建索引成本極高，尤其是數(shù)據(jù)量越來越大時，維護索引的成本越來越高，導(dǎo)致系統(tǒng)整體性能急劇下降。

2）磁盤讀寫速度限制。計算機技術(shù)飛速發(fā)展，尤其是計算機CPU 速度及內(nèi)存容量，但是磁盤的讀寫速度卻一直沒有本質(zhì)性的突破。創(chuàng)建索引需要大量修改數(shù)據(jù)，極大地增加對磁盤IO 壓力。更為嚴重的是這些修改可能都是海量的“小數(shù)據(jù)”修改，需要頻繁地對存儲有海量數(shù)據(jù)的磁盤進行重復(fù)性的IO 操作。

3）Hadoop 本身不支持數(shù)據(jù)修改，但維護索引需要修改數(shù)據(jù)，這是令Hadoop 上的幾乎所有快速查詢軟件都不使用索引的另一主要原因。

3 大數(shù)據(jù)高效索引與快速組合查詢技術(shù)

3.1 大數(shù)據(jù)快速查詢理念

在數(shù)據(jù)量急劇擴展的同時，隨著商業(yè)智能分析的深入，各種查詢分析的邏輯也越來越復(fù)雜。這兩個因素是當(dāng)前傳統(tǒng)數(shù)據(jù)面對查詢越來越力不從心的根本原因。

如今大數(shù)據(jù)技術(shù)方興未艾，查詢效率無疑是大數(shù)據(jù)領(lǐng)域重要的一環(huán)。如前文所述，傳統(tǒng)數(shù)據(jù)近年來為了提升查詢效率也已經(jīng)做了很多工作，但它們更多的還是依賴于更快的計算速度，優(yōu)化的查詢邏輯等。面對過快的數(shù)據(jù)量和查詢邏輯級數(shù)的增長，大數(shù)據(jù)技術(shù)針對這一問題則具備了它獨特的理念。

1）通過底層處理邏輯的優(yōu)化，而非僅僅查詢處理層面的邏輯優(yōu)化。通常查詢者的查詢邏輯是客觀存在的，在這上面去做優(yōu)化要做到既保證質(zhì)量又保證性能，對查詢者的專業(yè)技能要求太高。DIG 則是從數(shù)據(jù)最底層的處理邏輯上來實現(xiàn)查詢性能的根本性改變。

2）通過預(yù)處理來減少用戶的等待時間。當(dāng)數(shù)據(jù)庫表數(shù)量眾多，而用戶進行復(fù)雜邏輯的SQL 查詢時，即使只有幾百萬的數(shù)據(jù)，傳統(tǒng)方法下一個查詢也許需要用戶等待幾十分鐘，甚至幾個小時。大數(shù)據(jù)的核心理念之一便是盡可能的使用預(yù)處理，而減少用戶查詢時實時數(shù)據(jù)處理的工作量。DIG 技術(shù)的核心思想也正是如此，盡可能地在數(shù)據(jù)進入數(shù)據(jù)庫時即自動創(chuàng)建索引。通過底層核心技術(shù)，在用戶進行復(fù)雜多條件查詢時，動態(tài)地將各個數(shù)據(jù)表上的索引文件智能組合，快速響應(yīng)用戶的查詢請求。

3.2 大數(shù)據(jù)的高效索引技術(shù)

大數(shù)據(jù)基礎(chǔ)之上創(chuàng)建高效索引雖然非常之難，但顯而易見的是，大數(shù)據(jù)對索引的需求相比傳統(tǒng)數(shù)據(jù)庫更加迫切：傳統(tǒng)數(shù)據(jù)庫在幾十萬、幾百萬數(shù)據(jù)量的情況下需要使用索引才能提供滿足要求的查詢性能，那么專注于處理動輒幾百億、幾千億數(shù)據(jù)量的大數(shù)據(jù)技術(shù)如果不提供索引又如何能滿足性能需求呢？

傳統(tǒng)數(shù)據(jù)庫的索引其實都是一種單索引結(jié)構(gòu)，雖然很多基于Hadoop 的大數(shù)據(jù)產(chǎn)品可以支持復(fù)合索引，然而這種復(fù)合索引其本質(zhì)依然是單索引，即一次查詢只能用一個索引，所謂復(fù)合索引也只是將多個字段簡單拼接。單索引的效率可以滿足用戶單條件的查詢，而傳統(tǒng)的復(fù)合索引由于其拼接的技術(shù)過于簡單，因此也只能支持單一的查詢，如果用戶的查詢條件更復(fù)雜、條件組合更靈活時，它就完全不能滿足用戶的需求了。

為了解決大數(shù)據(jù)查詢的效率問題，同時避免傳統(tǒng)復(fù)合索引技術(shù)的帶來的局限性，本文提出了一種適用于用電大數(shù)據(jù)的復(fù)合索引技術(shù)——動態(tài)索引圖技術(shù)。

DIG 技術(shù)是一種基于分布式存儲，分布式計算的索引架構(gòu)，它對數(shù)據(jù)建立了一套立體的索引系統(tǒng)。這套索引系統(tǒng)首先利用第一個域進行排序，建立若干索引起始點，使用hash 技術(shù)將索引分段，由第一個域的這些起始點指向下一個域的分段，以此類推，構(gòu)建一個多級立體式的索引分段系統(tǒng)。當(dāng)某一分段較疏松時，適當(dāng)合并減少分段數(shù)，當(dāng)某一分段較密集時，適當(dāng)分離多建立分段，以達到分段的存儲讀取效率與查詢效率之間的平衡。當(dāng)一個查詢開始時，由一個或多個起始點開始，根據(jù)約束條件進行遞歸查詢。最終確定終結(jié)點的查詢內(nèi)容。

DIG 充分利用了云設(shè)備的緩存調(diào)度，多核計算，將孤立創(chuàng)建的索引連接成索引系統(tǒng)，如圖1所示。

圖1 DIG 示意圖

當(dāng)用戶執(zhí)行查詢?nèi)蝿?wù)時，系統(tǒng)將智能的甄別查詢類型，查詢規(guī)模，自動選取最優(yōu)的查詢算法。在立體的索引系統(tǒng)中，利用選擇的最優(yōu)算法規(guī)避逐條搜索，充分使用系統(tǒng)預(yù)處理產(chǎn)生的多級索引及索引間的關(guān)聯(lián)索引，索引內(nèi)預(yù)判預(yù)讀，多線程并行處理。最終達到大幅提高查詢速度的效果。

由于在普通規(guī)模數(shù)據(jù)系統(tǒng)中的大多數(shù)查詢是能夠在秒級時間單位中完成，而這些操作對于海量數(shù)據(jù)往往就會上升成為分鐘級，小時級的操作，DIG技術(shù)將查詢海量數(shù)據(jù)時的大量應(yīng)用從耗時若干分鐘，加速至只需若干秒，從而把系統(tǒng)的響應(yīng)時間壓縮到用戶等待的心理承受范圍之內(nèi)。

以四臺設(shè)備，40 億條數(shù)據(jù)為例，假設(shè)每條數(shù)據(jù)有五個字段，每個字段10 個字節(jié)定長。其全表內(nèi)容約為200GB，每臺設(shè)備處理50GB 數(shù)據(jù)，以每分鐘處理3GB 的硬盤上限處理能力計算，一次查詢需要15min 以上。首頁查詢較優(yōu)條件下也在5min 以上。而使用DIG 技術(shù)后首頁查詢時間會縮短至10～20s，從而使查詢時間落入用戶等待的心理承受范圍內(nèi)。

3.3 大數(shù)據(jù)快速組合查詢的設(shè)計

索引對于傳統(tǒng)數(shù)據(jù)庫只是一個輔助手段，若用戶使用了一個查詢組合，但是這個查詢組合并未建立索引，臨時采用全表掃描技術(shù)進行查詢也是可接受的一個解決方案。

但當(dāng)分配到每臺普通計算機的數(shù)據(jù)量大到一定程度時，逐行掃描技術(shù)已經(jīng)完全無法滿足系統(tǒng)的性能需求時，大數(shù)據(jù)下的高效索引則不僅僅是查詢加速的輔助，而是查詢的必要條件。因此，大數(shù)據(jù)快速組合查詢的設(shè)計必須滿足速度和通用性兩個要求。

為滿足快速組合查詢的速度要求，從以下兩個方面進行查詢效率提升：

1）從最底層的數(shù)據(jù)存儲層上，利用大數(shù)據(jù)虛擬文件系統(tǒng)實現(xiàn)高性能大數(shù)據(jù)存儲，為大數(shù)據(jù)快速查詢提供了良好的基礎(chǔ)。

2）使用多維數(shù)據(jù)庫為數(shù)據(jù)提供最優(yōu)化的處理方式。

從通用性的角度來看，由于大數(shù)據(jù)查詢對索引的要求不再僅僅局限于為查詢提供一種加速的輔助功能，而是所有查詢必須要使用的技術(shù)，因此，大數(shù)據(jù)技術(shù)下的索引技術(shù)必須能夠為任意多條件的所有可能組合用的。

DIG 技術(shù)創(chuàng)建的索引用戶不必去考慮任意多條件的組合的可能性數(shù)量，只需要對可能用到的查詢條件對應(yīng)的字段創(chuàng)建索引即可。當(dāng)用戶使用由這些條件組成的條件組合進行數(shù)據(jù)查詢時，數(shù)據(jù)庫引擎會依據(jù)自身的獨有機制動態(tài)使用這些原本獨立創(chuàng)建索引提供任意組合的多條件的數(shù)據(jù)查詢。

若使用沒有創(chuàng)建索引的字段與其他已經(jīng)創(chuàng)建了索引的字段進行組合查詢，系統(tǒng)首先智能地去判斷，發(fā)現(xiàn)其中的幾個字段已有索引，將優(yōu)先使用這幾個字段初步判斷與過濾，得到一組中間查詢結(jié)果；由于另外的一些字段并未建立索引，因此需要再對中間結(jié)果數(shù)據(jù)進行逐條掃描。因為已經(jīng)使用已有索引的幾個字段進行了過濾，因此進行中間結(jié)果的逐條比對時，數(shù)據(jù)集的規(guī)模已經(jīng)得到大幅降低。因此，即使偶爾使用了極少數(shù)沒有提前創(chuàng)建索引的字段進行查詢，在本文的查詢引擎下，也可以提供相當(dāng)不錯的查詢效率。

4 電力大數(shù)據(jù)快速組合查詢方案設(shè)計

隨著智能電表的普及，電力行業(yè)的數(shù)據(jù)量呈井噴式增長。電力行業(yè)是當(dāng)前將終端普及到千家萬戶每一個角落的少有的幾個行業(yè)之一（類似的還有水、煤氣等行業(yè)）。

電力數(shù)據(jù)具有格式化、數(shù)據(jù)量大、周期性明顯等特征。以江蘇電力為例，如果每個小時采集一次數(shù)據(jù)，則一個小時就會產(chǎn)生三千萬量級的數(shù)據(jù)，這個數(shù)據(jù)量還會隨著數(shù)據(jù)采集頻率的提升和用電單位數(shù)量的增長呈指數(shù)增長。

面對周期性產(chǎn)生的海量數(shù)據(jù)，大數(shù)據(jù)領(lǐng)域較為先進的HBase 作為大數(shù)據(jù)存儲與處理的基本平臺。HBase 雖然也提供了相對不錯的大數(shù)據(jù)處理能力，但它依然不能提供任意多條件查詢的索引技術(shù)。

由于HBase 是按列存儲的，并支持列族概念，對一個表做一個固定條件的查詢時效率很高；但一般查詢時往往需要進行多個條件的組合查詢，而HBase 并不支持多個條件的組合查詢。因此結(jié)合HBase 的自身特性，引入DIG 技術(shù)以提高組合查詢的效率是非常必要的。

用戶通過 java 數(shù)據(jù)庫連接（Java data base connectivity,JDBC）與HBase 實現(xiàn)數(shù)據(jù)庫的互通，并實時完成統(tǒng)計預(yù)處理和建立查詢索引。具體做法如下：

圖2 電力用戶數(shù)據(jù)查詢流程

1）當(dāng)HBASE 讀入新增數(shù)據(jù)時，所有數(shù)據(jù)同步被送到指定的查詢加速服務(wù)器，按指定關(guān)鍵字和日期對某個字段進行數(shù)值的統(tǒng)計，并建立查詢 索引。

2）當(dāng)用戶向HBASE 發(fā)出查詢請求時，該請求 被即時送到特制的查詢引擎，根據(jù)查詢條件返回對應(yīng)的索引地址，通過索引地址找到原始數(shù)據(jù)，并返回結(jié)果。

基于DIG 技術(shù)的查詢，無論數(shù)據(jù)總量多少，查詢的速度要求少于5 秒。通過本方案實現(xiàn)了無需改變HBase 的任何配置，同時無需任何編程，即可在海量大數(shù)據(jù)的壓力下實現(xiàn)統(tǒng)計和查詢的秒級 響應(yīng)。

5 結(jié)論

通過Jimo 系統(tǒng)的DIG 技術(shù)的引入，理論上可以實現(xiàn)無論數(shù)據(jù)量有多大，都可以提供任意多條件的秒級的查詢與統(tǒng)計分析。鑒于數(shù)據(jù)處理性能的保證，電力系統(tǒng)大數(shù)據(jù)項目中能實現(xiàn)提供的數(shù)據(jù)分析 處理的視野也將更加廣闊，不會再有數(shù)據(jù)分析功能因為數(shù)據(jù)處理性能的低下而變得無法實現(xiàn)，電力大數(shù)據(jù)的前景將不再受制于數(shù)據(jù)處理性能。

[1] 中國電力大數(shù)據(jù)發(fā)展白皮書[Z].北京: 中國電機工程學(xué)會信息化專委會,2013.

[2] Taylor R C．An overview of the Hadoop/Mapreduce/ HBase-framework and its current applications in bioinformatics[C].// Proceedings of the 11th Annual Bioinformatics Open Source Conference,2010.

[3] Tome White.Hadoop 權(quán)威指南[M].2 版.北京:清華大學(xué)出版社,2011.

[4] Lars George.HBase 權(quán)威指南[M].北京: 人民郵電出版社,2013.