訂閱
糾錯
加入自媒體

基于HBase的工業大數據存儲實戰

2018-12-25 10:05
來源: 格創東智

隨著工業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表:

group_idsize12

glass表:

glass_idgroup_idfeature"TB7B3695BA05"1"CASBA"

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

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

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

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

1  2  下一頁>  
聲明: 本文由入駐維科號的作者撰寫,觀點僅代表作者本人,不代表OFweek立場。如有侵權或其他問題,請聯系舉報。

發表評論

0條評論,0人參與

請輸入評論內容...

請輸入評論/評論長度6~500個字

您提交的評論過于頻繁,請輸入驗證碼繼續

暫無評論

暫無評論

    智能制造 獵頭職位 更多
    文章糾錯
    x
    *文字標題:
    *糾錯內容:
    聯系郵箱:
    *驗 證 碼:

    粵公網安備 44030502002758號