隨著工業(yè)4.0時(shí)代的到來，工業(yè)互聯(lián)網(wǎng)和企業(yè)的智能化、信息化都將不斷推進(jìn)，傳統(tǒng)的工業(yè)實(shí)時(shí)數(shù)據(jù)庫和關(guān)系數(shù)據(jù)庫已經(jīng)難以完全勝任工業(yè)大數(shù)據(jù)的存儲(chǔ)，以HBase為代表的NoSQL數(shù)據(jù)庫正在蓬勃發(fā)展，其完全分布式特征、高性能、多副本和靈活的動(dòng)態(tài)擴(kuò)展等特點(diǎn)，使得HBase在工業(yè)大數(shù)據(jù)的存儲(chǔ)上擁有強(qiáng)大的優(yōu)勢，打破了流程工業(yè)生產(chǎn)中的"數(shù)據(jù)壁壘"效應(yīng)的瓶頸,可以促進(jìn)工業(yè)生產(chǎn)水平和生產(chǎn)管理水平的提高。本期格物匯，就來給大家介紹HBase數(shù)據(jù)庫及格創(chuàng)東智相關(guān)實(shí)戰(zhàn)案例。

了解HBase

HBase是一個(gè)高可靠性、高性能、面向列、可伸縮的分布式存儲(chǔ)系統(tǒng)，利用HBase技術(shù)可在廉價(jià)PCServer上搭建起大規(guī)模結(jié)構(gòu)化存儲(chǔ)集群。HBASE的目標(biāo)是存儲(chǔ)并處理大型的數(shù)據(jù)，更具體來說是僅需使用普通的硬件配置，就能夠處理由成千上萬的行和列所組成的大型數(shù)據(jù)。

HBASE是GoogleBigtable的開源實(shí)現(xiàn)，但是也有很多不同之處。比如：GoogleBigtable使用GFS作為其文件存儲(chǔ)系統(tǒng)，HBASE利用HadoopHDFS作為其文件存儲(chǔ)系統(tǒng)；Google運(yùn)行MAPREDUCE來處理Bigtable中的海量數(shù)據(jù)，HBASE同樣利用HadoopMapReduce來處理HBASE中的海量數(shù)據(jù)；GoogleBigtable利用Chubby作為協(xié)同服務(wù)，HBASE利用Zookeeper作為協(xié)同服務(wù)。

與傳統(tǒng)數(shù)據(jù)庫的相比，HBASE具備多重優(yōu)勢：

1）線性擴(kuò)展，隨著數(shù)據(jù)量增多可以通過節(jié)點(diǎn)擴(kuò)展進(jìn)行支撐；

2）數(shù)據(jù)存儲(chǔ)在hdfs上，備份機(jī)制健全；

3）通過zookeeper協(xié)調(diào)查找數(shù)據(jù)，訪問速度快。

HBase實(shí)戰(zhàn)案例

為了更好的介紹HBase在人工智能場景下的使用，下面我們以某半導(dǎo)體顯示企業(yè)為案例，給大家分析格創(chuàng)東智大數(shù)據(jù)團(tuán)隊(duì)如何利用HBase設(shè)計(jì)出一個(gè)快速查找面板特征的系統(tǒng)。

目前，該公司的業(yè)務(wù)場景里面有很多面板相關(guān)的特征數(shù)據(jù)，每張面板數(shù)據(jù)大概3.2k。這些面板數(shù)據(jù)又被分成很多組，每個(gè)面板特征屬于某個(gè)組。組和面板的數(shù)據(jù)分布如下：

——43%左右的組含有1張面板數(shù)據(jù)；

——47%左右的組含有2~9張面板數(shù)據(jù)；

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

現(xiàn)在的業(yè)務(wù)需求主要有以下兩類：

——根據(jù)組的id查找該組下面的所有面板數(shù)據(jù)；

——根據(jù)組id+面板id查找某個(gè)面板的具體數(shù)據(jù)。

原有方案：MySQL+OSS

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

group表：

group_idsize12

glass表：

glass_idgroup_idfeature"TB7B3695BA05"1"CASBA"

其中feature（特征）大小為3.2k，是二進(jìn)制數(shù)據(jù)base64后存入的，這個(gè)就是真實(shí)的面板特征數(shù)據(jù)。現(xiàn)在面板組id和面板id對應(yīng)關(guān)系存儲(chǔ)在MySQL中，對應(yīng)上面的group表；面板id和面板相關(guān)的特征數(shù)據(jù)存儲(chǔ)在OSS里面，對應(yīng)上面的face表。

因?yàn)槊總€(gè)面板組包含的玻璃特征數(shù)相差很大(1~10000)，所以基于上面的表設(shè)計(jì)，我們需要將面板組以及每張面板特征id存儲(chǔ)在每一行，那么屬于同一個(gè)面板組的數(shù)據(jù)在MySQL里面上實(shí)際上存儲(chǔ)了很多行。比如某個(gè)組id對應(yīng)的特征數(shù)為10000，那么需要在MySQL里面存儲(chǔ)10000行。

我們?nèi)绻枰鶕?jù)面板組id查找該組下面的所有面板，那么需要從MySQL中讀取很多行的數(shù)據(jù)，從中獲取到組和面板對應(yīng)的關(guān)系，然后到OSS里面根據(jù)面板id獲取所有相關(guān)的特征數(shù)據(jù)。

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

HBase解決方案：

MySQL+OSS的設(shè)計(jì)方案有兩個(gè)問題：第一，原本屬于同一條數(shù)據(jù)的內(nèi)容由于數(shù)據(jù)本身大小的原因無法存儲(chǔ)到一行里面，導(dǎo)致后續(xù)查下需要訪問兩個(gè)存儲(chǔ)系統(tǒng)；第二，由于MySQL不支持動(dòng)態(tài)列的特性，所以屬于同一個(gè)面板組的數(shù)據(jù)被拆成多行存儲(chǔ)。

針對這兩個(gè)問題，格創(chuàng)東智的大數(shù)據(jù)團(tuán)隊(duì)進(jìn)行了分析，認(rèn)為這是HBase的典型場景，原因如下：

——HBase擁有動(dòng)態(tài)列的特性，支持萬億行，百萬列；

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

——HBase2.0引入了MOB(Medium-SizedObject)特性，支持小文件存儲(chǔ)。

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

格創(chuàng)東智的大數(shù)據(jù)團(tuán)隊(duì)使用這三個(gè)功能重新設(shè)計(jì)上面MySQL+OSS方案。結(jié)合應(yīng)用場景的兩大查詢需求，將面板組id作為HBase的Rowkey，在創(chuàng)建表的時(shí)候打開MOB功能，如下：

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

上面我們創(chuàng)建了名為glass的表，IS_MOB屬性說明列簇c將啟用MOB特性，MOB_THRESHOLD是MOB文件大小的閾值，單位是字節(jié)，這里的設(shè)置說明文件大于2k的列都當(dāng)做小文件存儲(chǔ)。大家可能注意到上面原始方案中采用了OSS對象存儲(chǔ)，那我們?yōu)槭裁床恢苯邮褂肙SS存儲(chǔ)面板特征數(shù)據(jù)呢，如果有這個(gè)疑問，可以看看下面表的性能測試：

對比屬性對象存儲(chǔ)云HBase建模能力KVKV、表格、稀疏表、SQL、全文索引、時(shí)空、時(shí)序、圖查詢查詢能力前綴查找前綴查找、過濾器、索引性能優(yōu)優(yōu)，特別對小對象有更低的延遲；在復(fù)雜查詢場景下，比對象存儲(chǔ)有10倍以上的性能提升成本按流量，請求次數(shù)計(jì)費(fèi)，托管式，在高并發(fā)，高吞吐場景有更低的成本適合訪問頻率低的場景擴(kuò)展性優(yōu)優(yōu)適用對象范圍通用<10MB

StringCF_DEFAULT="c";根據(jù)上面的對比，使用HBaseMOB特性來存儲(chǔ)小于10MB的對象相比直接使用對象存儲(chǔ)有一些優(yōu)勢。

我們現(xiàn)在來看看具體的表設(shè)計(jì)，使用面板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);

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

Getget=newGet(groupId.getBytes());

Resultre=table.get(get);

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

Getget=newGet(groupId.getBytes());

get.addColumn(CF_DEFAULT.getBytes(),glassId1.getBytes())

Resultre=table.get(get);

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

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

對比屬性對象存儲(chǔ)MySQL+對象存儲(chǔ)HBaseMOB讀寫強(qiáng)一致YNY查詢能力弱強(qiáng)強(qiáng)查詢響應(yīng)時(shí)間高高低運(yùn)維成本低高低水平擴(kuò)展YYY

現(xiàn)在，我們已經(jīng)將面板特征數(shù)據(jù)存儲(chǔ)在ClouderaHBase之中，這個(gè)只是數(shù)據(jù)應(yīng)用的第一步，如何將隱藏在這些數(shù)據(jù)背后的價(jià)值發(fā)揮出來？這就得借助于數(shù)據(jù)分析，在這個(gè)場景就需要采用機(jī)器學(xué)習(xí)的方法進(jìn)行操作。我們可以借助大數(shù)據(jù)分析工具Spark對存儲(chǔ)于HBase之中的數(shù)據(jù)進(jìn)行分析，而且Spark本身支持機(jī)器學(xué)習(xí)的。最后，用戶就可以通過訪問HBase里面已經(jīng)挖掘好的特征數(shù)據(jù)進(jìn)行其他的應(yīng)用了。