用于電力大數據快速組合查詢的 動態索引技術

欒開寧 鄭海雁 丁 陳 李昆明

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

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

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

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

1 用電大數據的特征

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

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

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

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

2 大數據創建索引和快速查詢面臨的挑戰

2.1 大數據快速查詢存在的問題

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

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

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

表1列出了基于Hadoop 的大數據快速查詢產品。

表1 基于Hadoop 的大數據產品

（續）

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

2.2 大數據創建索引面臨的挑戰

大數據創建索引雖然重要，然而其難度也是同樣大幅提高的。

1）創建索引成本極高，尤其是數據量越來越大時，維護索引的成本越來越高，導致系統整體性能急劇下降。

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

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

3 大數據高效索引與快速組合查詢技術

3.1 大數據快速查詢理念

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

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

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

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

3.2 大數據的高效索引技術

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

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

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

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

DIG 充分利用了云設備的緩存調度，多核計算，將孤立創建的索引連接成索引系統，如圖1所示。

圖1 DIG 示意圖

當用戶執行查詢任務時，系統將智能的甄別查詢類型，查詢規模，自動選取最優的查詢算法。在立體的索引系統中，利用選擇的最優算法規避逐條搜索，充分使用系統預處理產生的多級索引及索引間的關聯索引，索引內預判預讀，多線程并行處理。最終達到大幅提高查詢速度的效果。

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

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

3.3 大數據快速組合查詢的設計

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

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

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

1）從最底層的數據存儲層上，利用大數據虛擬文件系統實現高性能大數據存儲，為大數據快速查詢提供了良好的基礎。

2）使用多維數據庫為數據提供最優化的處理方式。

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

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

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

4 電力大數據快速組合查詢方案設計

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

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

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

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

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

圖2 電力用戶數據查詢流程

1）當HBASE 讀入新增數據時，所有數據同步被送到指定的查詢加速服務器，按指定關鍵字和日期對某個字段進行數值的統計，并建立查詢 索引。

2）當用戶向HBASE 發出查詢請求時，該請求 被即時送到特制的查詢引擎，根據查詢條件返回對應的索引地址，通過索引地址找到原始數據，并返回結果。

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

5 結論

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

[1] 中國電力大數據發展白皮書[Z].北京: 中國電機工程學會信息化專委會,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 權威指南[M].2 版.北京:清華大學出版社,2011.

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