本文作者：格創東智大數據工程師王子超（轉載請注明作者及來源）

隨著工業4.0時代的到來，工業互聯網和企業的智能化、信息化都將不斷推進，傳統的工業實時數據庫和關系數據庫已經難以完全勝任工業大數據的存儲，以HBase為代表的NoSQL數據庫正在蓬勃發展，其完全分布式特征、高性能、多副本和靈活的動態擴展等特點，使得HBase在工業大數據的存儲上擁有強大的優勢，打破了流程工業生產中的"數據壁壘"效應的瓶頸,可以促進工業生產水平和生產管理水平的提高。本期格物匯，就來給大家介紹HBase數據庫及格創東智相關實戰案例。

了解HBase

HBase是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系統，利用HBase技術可在廉價PC Server上搭建起大規模結構化存儲集群。HBASE的目標是存儲并處理大型的數據，更具體來說是僅需使用普通的硬件配置，就能夠處理由成千上萬的行和列所組成的大型數據。

HBASE是GoogleBigtable的開源實現，但是也有很多不同之處。比如：Google Bigtable使用GFS作為其文件存儲系統，HBASE利用HadoopHDFS作為其文件存儲系統；Google運行MAPREDUCE來處理Bigtable中的海量數據，HBASE同樣利用Hadoop MapReduce來處理HBASE中的海量數據；Google Bigtable利用Chubby作為協同服務，HBASE利用Zookeeper作為協同服務。

與傳統數據庫的相比，HBASE具備多重優勢：

1）線性擴展，隨著數據量增多可以通過節點擴展進行支撐；

2）數據存儲在hdfs上，備份機制健全；

3）通過zookeeper協調查找數據，訪問速度快。

HBase實戰案例

為了更好的介紹 HBase 在人工智能場景下的使用，下面我們以某半導體顯示企業為案例，給大家分析格創東智大數據團隊如何利用 HBase 設計出一個快速查找面板特征的系統。

目前，該公司的業務場景里面有很多面板相關的特征數據，每張面板數據大概 3.2k。這些面板數據又被分成很多組，每個面板特征屬于某個組。組和面板的數據分布如下：

——43%左右的組含有1張面板數據；

——47%左右的組含有 2 ~9張面板數據；

——其余的組面板數范圍為 10 ~ 10000張。

現在的業務需求主要有以下兩類：

——根據組的 id 查找該組下面的所有面板數據；

——根據組 id +面板id 查找某個面板的具體數據。

原有方案：MySQL+OSS

之前業務數據量比較小的情況使用的存儲主要為 MySQL 以及 OSS(對象存儲)。相關表主要有面板組表group和面板表face。表的格式如下：

group表：

glass表：

其中 feature（特征）大小為3.2k，是二進制數據 base64 后存入的，這個就是真實的面板特征數據。現在面板組 id 和面板id 對應關系存儲在MySQL 中，對應上面的 group 表；面板 id 和面板相關的特征數據存儲在 OSS 里面，對應上面的 face 表。

因為每個面板組包含的玻璃特征數相差很大(1 ~ 10000)，所以基于上面的表設計，我們需要將面板組以及每張面板特征id存儲在每一行，那么屬于同一個面板組的數據在MySQL 里面上實際上存儲了很多行。比如某個組id對應的特征數為10000，那么需要在MySQL 里面存儲 10000 行。

我們如果需要根據面板組 id 查找該組下面的所有面板，那么需要從 MySQL 中讀取很多行的數據，從中獲取到組和面板對應的關系，然后到 OSS 里面根據面板id獲取所有相關的特征數據。

這樣的查詢導致鏈路非常長。從上面的設計可看出，如果查詢的組包含的面板張數比較多的情況下，那么我們需要從 MySQL 里面掃描很多行，然后再從 OSS 里面拿到這些特征數據，整個查詢時間在10秒左右，遠遠不能滿足現有業務快速發展的需求。

HBase解決方案：

MySQL + OSS的設計方案有兩個問題：第一，原本屬于同一條數據的內容由于數據本身大小的原因無法存儲到一行里面，導致后續查下需要訪問兩個存儲系統；第二，由于MySQL不支持動態列的特性，所以屬于同一個面板組的數據被拆成多行存儲。

針對這兩個問題，格創東智的大數據團隊進行了分析，認為這是HBase 的典型場景，原因如下：

——HBase 擁有動態列的特性，支持萬億行，百萬列；

——HBase 支持多版本，所有的修改都會記錄在 HBase 中；

——HBase 2.0 引入了MOB(Medium-Sized Object)特性，支持小文件存儲。

HBase 的 MOB 特性針對文件大小在 1k~10MB 范圍的，比如圖片，短視頻，文檔等，具有低延遲，讀寫強一致，檢索能力強，水平易擴展等關鍵能力。

格創東智的大數據團隊使用這三個功能重新設計上面 MySQL + OSS 方案。結合應用場景的兩大查詢需求，將面板組 id 作為 HBase 的 Rowkey，在創建表的時候打開 MOB 功能，如下：

create'glass',{NAME=>'c',IS_MOB=>true,MOB_THRESHOLD=>2048}

上面我們創建了名為 glass 的表，IS_MOB屬性說明列簇 c 將啟用 MOB 特性，MOB_THRESHOLD是 MOB 文件大小的閾值，單位是字節，這里的設置說明文件大于 2k 的列都當做小文件存儲。大家可能注意到上面原始方案中采用了 OSS 對象存儲，那我們為什么不直接使用 OSS 存儲面板特征數據呢，如果有這個疑問，可以看看下面表的性能測試：

StringCF_DEFAULT="c";根據上面的對比，使用 HBase MOB特性來存儲小于10MB的對象相比直接使用對象存儲有一些優勢。
我們現在來看看具體的表設計，使用面板id作為列名。我們只使用了HBase 的一張表就替換了之前方面的三張表！雖然我們啟用了 MOB，但是具體插入的方法和正常使用一樣，代碼片段如下：

Putput=newPut(groupId.getBytes());
put.addColumn(CF_DEFAULT.getBytes(),glassId1.getBytes(),feature1.getBytes());
put.addColumn(CF_DEFAULT.getBytes(),glassId2.getBytes(),feature2.getBytes());
……
put.addColumn(CF_DEFAULT.getBytes(),glassIdn.getBytes(),featuren.getBytes());
table.put(put);

用戶如果需要根據面板組id獲取所有面板數據，可以使用下面方法：

Getget=newGet(groupId.getBytes());
Resultre=table.get(get);

這樣我們可以拿到某個組id對應的所有面板數據。如果需要根據組id+面板id查找某個面板的具體數據，看可以使用下面方法：

Getget=newGet(groupId.getBytes());
get.addColumn(CF_DEFAULT.getBytes(),glassId1.getBytes())
Resultre=table.get(get);

經過上面的改造，在2臺 HBaseWorker 節點內存為32GB，核數為8，每個節點掛載四塊大小為 250GB 的 SSD 磁盤，并寫入100W 行，每行有1W列，讀取一行的時間在100ms-500毫秒左右。在每行有1000個face的情況下，讀取一行的時間基本在20-50毫秒左右，相比之前的10秒提升200~500倍。

從下面這張對比表，我們可以清楚的看到HBase方案的巨大優勢。

現在，我們已經將面板特征數據存儲在Cloudera HBase 之中，這個只是數據應用的第一步，如何將隱藏在這些數據背后的價值發揮出來？這就得借助于數據分析，在這個場景就需要采用機器學習的方法進行操作。我們可以借助大數據分析工具Spark 對存儲于 HBase 之中的數據進行分析，而且 Spark 本身支持機器學習的。最后，用戶就可以通過訪問 HBase 里面已經挖掘好的特征數據進行其他的應用了。