1）紅外圖像存儲模型。
HBase是一個分布式的、面向列的開源數據庫，該技術來源于Fay Chang所撰寫的論文“Bigtable:—個結構化數據的分布式存儲系統”。就儀Bigtable利用了Google文件系統（File System）所提供的分布式數據存儲一樣，HBase在Hadoop之上提供了類似于Bigtable的能力。HBase是Apache的Hadoop項目的子項目。HBase不同于一般的關系數據庫，它是一個適合于非結構化數據存儲的數據庫。另一個不同是HBase是基于列的而不是基于行的模式。
HBase是采用KeyValue的列存儲，Rowkey是KeyValue的Key,表示唯一一行。Rowkey是一段二進制碼流，最大值為64KB，內客由用戶自定義。數據的加載數據Rowkey的二進制序由小到大進行排序。HBase根據數據的規模將數據自動分切到多個Region的多個HFile中。

 

圖3-18HBase物理存儲架構

另外與傳統的面向列的關系型數據庫為基本單元不同，HBase的基本存儲單元為列簇(columnfamily)。HBase數據邏輯上由行和列組成二維矩陣存儲。其中由HBase的列簇、列組成了二維矩陣中的一維,由Rowkey組成了另一維，每一個非空的行列節點稱為一個Cell,Cell是HRase最小的邏輯存儲單元

 

圖3-19 HBase邏輯存儲架構

2)存儲模型中Columnkey設計。
近似內聚原則：由于HBase是一個面向列簇的存儲器，相同的列簇存儲在同一個HRegion中，并交由對應的HRegionServer來管理。HBase從同一個HRegion獲取數據的效率遠高于從不同的HRegion中獲取數據。目前使用中HBase的調優和存儲都是在列簇這個層次上進行的，最好使列簇成員都有相同的訪問模式(access pattern)和大小特征。
減少列簇原則：在一張表里不要定義太多的列簇。目前HBase并不能很好地處理超過3個列簇的表。因為某個列簇在flush的時候:它鄰近的列簇也會因關聯效應被觸發flush,最終導致系統產生更多的I/O。
根據上述兩個原則，結合紅外圖像診斷的實際業務，本數據存儲模型分為3個列簇。

圖3-20三個列簇

☆基本信息簇(f_info):存儲圖像對應設備名稱、類型、所屬廠站、上傳時間、拍攝時間以及拍攝設備類型等基本信息。

圖3-21圖像基本信息簇

其中“processed”列為標識圖像是否被預處理的標識位。
 ☆圖像信息簇(f_img):以字節流形式存儲圖像全部信息。

 

 圖3-22圖像信息簇

☆溫度信息簇(f_temp):存儲圖像預處理后的各部位溫度分析結果信息。

 

 圖3-23溫度信息簇

 每一列以Key-Value形式存儲著圖像中一個關系區域的溫度分結果，其中Key為區域Id,Value存儲著對應區域的最高溫、最低溫以及平均溫度并以“，”分隔開。

3）存儲模型中RowKey設計。
唯一原則：Rowkey作為一張圖片的索引，唯一性是最基本的原則。不同于關系型數據庫HBase中不支持對于關聯關系的維護，在Rowkey的設計中一般不會采用無業務意義的流水ID、UUID等主鍵方式。HBase中Rowkey的設計往往需要結合業務需求，將多個有實時意義的屬性拼接而成。結合紅外圖像診斷的實際業務，可以將設備名稱、設備類型、設備所屬站以及拍攝時間這幾個屬性拼接。

長度原則：Rowkey是一個二進制碼流，理論上HBase支持最大的Rowkey為64KB，但原則上Rowkey的長度越短越好。原因一：數據的持久化文件HFile中是按照Keyvalue存儲的，如果Rowkey過長比如100個字節，3600萬列數據光Rowkey就要占用100x3600萬=36億個字節，超過33G數據，這會極大影響HFile的存儲效率；原因二：MemStore將緩存部分數據到內存，如果Rowkey字段過長，內存的有效利用率會降低，系統將無法緩存更多的數據，這會降低檢索效率。目前操作系統是都是64位系統，內存8字節對齊，在設計主鍵時應盡量使得Rowkey的長度為8的整數倍。
為了盡量減少Rowkey的長度，Rowkey一般不采用漢字，而采用數值型編碼格式。結合電力系統的實時情況，一個地市廠站ID設為000?999之間，設備類型在00~99之間，某一廠站下某一類型的設備ID設置在00~99之間。

 離散原則：HBase的基本存儲單元是HRegion,每個HRegion由相對的HRegionServer特定處理。HBase中的記錄根據Rowkey序存儲在不同的HRegion中，Rowkey越相近的記錄存儲在相同HRegion上的概率越大。如果一次查詢中大部分數據集中在某個HRegion上會造成HRegionServer之間的負荷均衡問題，導致個別HRegionServer過熱，降低查詢效率。
結合到紅外圖像診斷系統中圖像的拍攝時間（格式為yyMMddhhmm）最不適合作為Rowkey的高位。其他格式的時間例“mmhhyyMMdd”等雖然滿足了離散原則，但由于查詢的結果集根據Rowkey降序排列的，選用如此格式的時間將造成結果集的混亂，增加后序計算的難度。采用廠站ID作為Rowkey的高位面臨同樣的問題，將造成同一廠站內的圖像存儲在同一HRegion的概率增加。比較而言，設備ID以及設備類型ID作為Rowkey的高位比較合適。實際應用中，根據設備類型排序更有意義。
綜上所述，本數據模型最終選擇的Rowkey格式為：設備類型ID+“-”+廠站ID+“-”+拍攝時間+“-”+設備ID。為了便于檢索，各類屬性之間用“-”分隔開。

4）Rowkey的查詢設計。
HBase的查詢實現只提供兩種方式:
A、按指定Rowkey獲取唯一一條記錄，get方法。
B、按指定的條件獲取一批記錄，scan方法。

對于第一種方法一次獲取唯一一條記錄，查詢效率極高，但局限性也很大，需要知道詳細的Rowkey值。此方法沒有過多的優化空間。實現條件查詢功能使用的就是scan方式，scan在使用時有以下幾點值得注意：
A、scan可以通過setCatch與setBatch方法提高速度（以空間換時間）。
B、scan可以通過setStartROW與setEndROW方法來限定范圍。范圍越小，性能越高。
C、scan可以通過設計一個或者一組過濾器“Filter”對結果集進行過濾。

對于已知RowKey高位屬性，可以通過簡單地設置StartRow與EndRow以及添加過濾器的形式來實現高效査詢。例如查詢廠站ID為012,在2014年06月01號到2014年09月30號內所有開關（02）的紅外圖像，其對應的參數設置為

startRow=02-012-1406010000-00
endRow=02-012-l409302359-99
而對于Rowkey高位不確定的情況，則稍稍麻煩一點。例如查詢一個廠站（012）在2014年06月01號到2014年09月30號內所有設備的紅外圖像，其對應的參數設置為
startRow=00-012-1406010000-00
endRow=99-012-1409302359-99
然后再設置一個正則表達式過濾器（RegexStringComparator）,過濾掉不符合條件的數據。對應的正則表達式為
regStr=“\\w-\\012-140[6-9][0-l][l-9][0-2][0-9][0-5][0-9]-\\w”

5）基于HBase的圖像數據模型優點。
基于HBase的圖像模型存儲，克服了傳統關系型數據庫+文件管理系統在安全性、擴展性以及一致性等方面缺點，也克服了基于HDFS小文件存儲效率不高的缺點。本模型很好地實現了圖像基本信息、圖像信息、圖像處理結果信息的一體化存儲，并且利用HBase列存儲的特性可實現了更多的業務擴展。
本存儲模型結合實際業務需求，實現了對圖像相關信息按拍攝時間、設備所屬廠站、設備類型以及設備名稱的快速模糊檢索功能，為基于大數據的紅外圖像的分析與診斷提供了技術支撐。

 

書名：電力大數據：能源互聯網時代的電力企業轉型與價值創造

ISBN：978-7-111-51693-4

作者：賴征田

出版日期：2016-01

出版社：機械工業出版社