HBase入門問題有哪些

本篇內容介紹了“HBase入門問題有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

　　一些常見的HBase新手問題

　　·什么樣的數據適合用HBase來存儲?　 

　　行由看似”雜亂無章”的列組成，行與行之間也無須遵循一致的定義，而這種定義恰好符合半結構化數據或非結構化數據的特點。本文所要講述的HBase，就屬于該派系的一個典型代表。這些”雜亂無章”的列所構成的多行數據，被稱之為一個”稀疏矩陣”，而上圖中的每一個”黑塊塊”，在HBase中稱之為一個KeyValue。

　　Apache HBase官方給出了這樣的定義：

　　Apache HBase? is the hadoop database, a distributed , scalable , big data store .

　　即：Apache HBase是基于Hadoop構建的一個 分布式 的、 可伸縮 的 海量數據存儲系統 。

　　HBase常被用來存放一些結構簡單，但數據量非常大的數據(通常在TB級別以上)，如歷史訂單記錄，日志數據，監控Metris數據等等，HBase提供了簡單的基于Key值的快速查詢能力。

　　HBase在國內市場已經取得了非常廣泛的應用，在搜索引擎中，也可以看出來，HBase在國內呈現出了逐年上升的勢態：

　　(需要說明的一點：HBase中的每一次commit，都已經過社區Commiter成員嚴格的Review，在commit之前，一個Patch可能已經被修改了幾十個版本)

　　令人欣喜的是，國內的開發者也積極參與到了HBase社區貢獻中，而且被社區接納了多名PMC以及Committer成員。

　　本文將以 一條數據在HBase中的“旅程” 為線索，介紹HBase的核心概念與流程，幾乎每一部分都可以展開成一篇獨立的長文，但本文旨在讓讀者能夠快速的了解HBase的架構輪廓，所以很多特性/流程被被一言帶過，但這些特性在社區中往往經歷了漫長的開發過程。至于講什么以及講到什么程度，本文都做了艱難的取舍，在講解的過程中，將會穿插解答本文開始所提出的針對初學者的一些常見問題。

　　本文適用于HBase新手，而對于具備一定經驗的HBase開發人員，相信本文也可以提供一些有價值的參考。本文內容基于HBase 2.0 beta 2版本，對比于1.0甚至是更早期的版本，2.0出現了大量變化，下面這些問題的答案與部分關鍵的變化相關(新手可以直接跳過這些問題)：

　　·HBase meta Region在哪里提供服務?

　　·HBase是否可以保證單行操作的原子性?

　　·Region中寫WAL與寫MemStore的順序是怎樣的?

　　·你是否遇到過Region長時間處于RIT的狀態? 你認為舊版本中Assignment Manager的主要問題是什么?

　　·在面對Full GC問題時，你嘗試做過哪些優化?

　　·你是否深究過HBase Compaction帶來的“寫放大”有多嚴重?

　　·HBase的RPC框架存在什么問題?

　　·導致查詢時延毛刺的原因有哪些?

　　本系列文章的 整體行文思路 如下：

　　·介紹HBase數據模型

　　·基于數據模型介紹HBase的適用場景

　　·快速介紹集群關鍵角色以及集群部署建議

　　·示例數據介紹

　　·寫數據流程

　　·讀數據流程

　　·數據更新

　　·負載均衡機制

　　HBase如何存儲小文件數據

　　這些內容將會被拆成幾篇文章。至于集群服務故障的處理機制，集群工具，周邊生態，性能調優以及最佳實踐等進階內容，暫不放在本系列文章范疇內。

　　約定

　　本文范圍內針對一些關鍵特性/流程，使用了加粗以及加下劃線的方式做了強調，如” ProcedureV2 “。這些特性往往在本文中僅僅被粗淺提及，后續計劃以獨立的文章來介紹這些特性/流程。

　　術語縮寫 ：對于一些進程/角色名稱，在本文范圍內可能通過縮寫形式來表述：

　　Region是HBase中負載均衡的基本單元，當一個Region增長到一定大小以后，會自動分裂成兩個。

　　Column Family

　　如果將Region看成是一個表的 橫向切割 ，那么，一個Region中的數據列的 縱向切割 ，稱之為一個 Column Family 。每一個列，都必須歸屬于一個Column Family，這個歸屬關系是在寫數據時指定的，而不是建表時預先定義。

　　看的出來，KeyValue是支撐”稀疏矩陣”設計的一個關鍵點：一些Key相同的任意數量的獨立KeyValue就可以構成一行數據。但這種設計帶來的一個顯而易見的缺點： 每一個KeyValue所攜帶的自我描述信息，會帶來顯著的數據膨脹 。

　　適用場景

　　在介紹完了HBase的數據模型以后，我們可以回答本文一開始的前兩個問題：

　　·什么樣的數據適合用HBase來存儲?

　　·既然HBase也是一個數據庫，能否用它將現有系統中昂貴的Oracle替換掉?

　　HBase的數據模型比較簡單，數據按照RowKey排序存放，適合HBase存儲的數據，可以簡單總結如下：

　　·以 實體 為中心的數據

　　·實體可以包括但不限于如下幾種：

　　描述這些實體的，可以有基礎屬性信息、實體關系(圖數據)、所發生的事件(如交易記錄、車輛軌跡點)等等。

　　·自然人/賬戶/手機號/車輛相關數據

　　·用戶畫像數據(含標簽類數據)

　　·圖數據(關系類數據)

　　·以 事件 為中心的數據

　　·監控數據

　　·時序數據

　　·實時位置類數據

　　·消息/日志類數據

　　上面所描述的這些數據，有的是結構化數據，有的是半結構化或非結構化數據。HBase的“稀疏矩陣”設計，使其應對非結構化數據存儲時能夠得心應手，但在我們的實際用戶場景中，結構化數據存儲依然占據了比較重的比例。由于HBase僅提供了基于RowKey的單維度索引能力，在應對一些具體的場景時，依然還需要基于HBase之上構建一些專業的能力，如：

　　·OpenTSDB 時序數據存儲，提供基于Metrics+時間+標簽的一些組合維度查詢與聚合能力

　　·GeoMesa 時空數據存儲，提供基于時間+空間范圍的索引能力

　　·JanusGraph 圖數據存儲，提供基于屬性、關系的圖索引能力

　　HBase擅長于存儲結構簡單的海量數據但索引能力有限，而Oracle等傳統關系型數據庫(RDBMS)能夠提供豐富的查詢能力，但卻疲于應對TB級別的海量數據存儲，HBase對傳統的RDBMS并不是取代關系，而是一種補充。

　　HBase與HDFS

　　我們都知道HBase的數據是存儲于HDFS里面的，相信大家也都有這么的認知：

　　·HBase是一個 分布式數據庫 ，HDFS是一個 分布式文件系統

　　理解了這一點，我們先來粗略回答本文已開始提出的其中兩個問題：

　　·HBase中的數據為何不直接存放于HDFS之上?

　　HBase中存儲的海量數據記錄，通常在幾百Bytes到KB級別，如果將這些數據直接存儲于HDFS之上，會導致大量的小文件產生，為HDFS的元數據管理節點(NameNode)帶來沉重的壓力。

　　·文件能否直接存儲于HBase里面?

　　如果是幾MB的文件，其實也可以直接存儲于HBase里面，我們暫且將這類文件稱之為小文件，HBase提供了一個名為MOB的特性來應對這類小文件的存儲。但如果是更大的文件，強烈不建議用HBase來存儲，關于這里更多的原因，希望你在詳細讀完本文所有內容之后能夠自己解答。

　　集群角色

　　關于集群環境，你可以使用國內外大數據廠商的平臺，如Cloudera，Hontonworks以及國內的華為，都發行了自己的企業版大數據平臺，另外，華為云、阿里云中也均推出了全托管式的HBase服務。

　　我們假設集群環境已經Ready了，先來看一下集群中的 關鍵角色 ：

　　管理節點獨立于數據節點部署

　　如果是基于物理機部署，每一臺物理機節點上可以設置幾個RegionServers/DataNodes來提升資源使用率。

　　也可以選擇基于容器來部署，如在HBaseCon Asia 2017大會知乎的演講主題中，就提到了知乎基于Kubernetes部署HBase服務的實踐。

　　對于公有云HBase服務而言，為了降低總體擁有成本( TCO )，通常選擇” 計算與存儲物理分離 “的方式，從架構上來說，可能導致平均時延略有下降，但可以借助于共享存儲底層的IO優化來做一些”彌補”。

　　HBase集群中的RegionServers可以按邏輯劃分為多個Groups，一個表可以與一個指定的Group綁定，可以將RegionServer Group理解成將一個大的集群劃分成了多個邏輯子集群，借此可以實現多租戶間的隔離，這就是HBase中的 RegionServer Group 特性。

　　示例數據

　　以我們日常生活都熟悉的手機通話記錄的存儲為例，先簡單給出示例數據的字段定義：

　　在本文大部分內容中所涉及的一條數據，是上面加粗的最后一行” MSISDN1 “為” 13400006666 “這行記錄。

　　在本系列文章的流程圖中，我們將會使用一個 紅色的五角星 來表示該數據所在的位置。

　　寫數據之前：建立連接

　　Login

　　在啟用了安全特性的前提下，Login階段是為了完成 用戶認證 (確定用戶的合法身份)，這是后續一切 安全訪問控制 的基礎。

　　當前Hadoop/HBase僅支持基于Kerberos的用戶認證，ZooKeeper除了Kerberos認證，還能支持簡單的用戶名/密碼認證，但都基于靜態的配置，無法動態新增用戶。如果要支持其它第三方認證，需要對現有的安全框架做出比較大的改動。

　　創建Connection

　　Connection可以理解為一個HBase集群連接的抽象，建議使用ConnectionFactory提供的工具方法來創建。因為HBase當前提供了兩種連接模式：同步連接，異步連接，這兩種連接模式下所創建的Connection也是不同的。我們給出ConnectionFactory中關于獲取這兩種連接的典型方法定義：

　　預設合理的數據分片 – Region

　　分片數量會給讀寫吞吐量帶來直接的影響，因此，建表時通常建議由用戶主動指定劃分 Region分割點 ，來設定Region的數量。

　　HBase中數據是按照RowKey的字典順序排列的，為了能夠劃分出合理的Region分割點，需要依據如下幾點信息：

　　·Key的組成結構

　　·Key的數據分布預估

　　如果不能基于Key的組成結構來預估數據分布的話，可能會導致數據在Region間的分布不均勻

　　·讀寫并發度需求

　　·依據讀寫并發度需求，設置合理的Region數量

　　·為表定義合理的Schema

　　既然HBase號稱”schema-less”的數據存儲系統，那何來的是schema? 的確，在數據庫范式的支持上，HBase非常弱，這里的Schema，主要指如下一些信息的設置：

　　·NameSpace設置

　　·Column Family的數量

　　每一個Column Family中所關聯的一些 關鍵配置 ：

　　·Compression

　　HBase當前可以支持Snappy，GZ，LZO，LZ4，Bzip2以及ZSTD壓縮算法

　　·DataBlock Encoding

　　HBase針對自身的特殊數據模型所做的一種壓縮編碼

　　·BloomFilter

　　可用來協助快速判斷一條記錄是否存在

　　·TTL

　　指定數據的過期時間

　　·StoragePolicy

　　指定Column Family的存儲策略，可選配置有：

　　“ALL_SSD”，”ONE_SSD”，”HOT”，”WARM”，”COLD”，”LAZY_PERSIST”

　　HBase中并不需要預先設置Column定義信息，這就是HBase schema-less設計的核心。

　　Client發送建表請求到Master

　　建表的請求是通過RPC的方式由Client發送到Master:

　　·RPC接口基于Protocol Buffer定義

　　·建表相關的描述參數，也由Protocol Buffer進行定義及序列化

　　Client端側調用了Master服務的什么接口，參數是什么，這些信息都被通過RPC通信傳輸到Master側，Master再依據這些接口\參數描述信息決定要執行的操作。2.0版本中，HBase目前已經支持基于Netty的 異步RPC框架 。

　　關于HBase RPC框架

　　早期的HBase RPC框架，完全借鑒了Hadoop中的實現，那時，Netty項目尚不盛行。

　　Master側接收到Client側的建表請求以后，一些主要操作包括：

　　生成每一個Region的描述信息對象HRegionInfo，這些描述信息包括：Region ID, Region名稱，Key范圍，表名稱等信息

　　生成每一個Region在HDFS中的文件目錄

　　將HRegionInfo信息寫入到記錄元數據的hbase:meta表中。

　　說明

　　meta表位于名為”hbase”的namespace中，因此，它的全稱為”hbase:meta”。

　　但在本系列文章范疇內，常將其縮寫為”meta”。

　　整個過程中，新表的狀態也是記錄在hbase:meta表中的，而不用再存儲在ZooKeeper中。

　　如果建表執行了一半，Master進程掛掉了，如何處理?這里是由HBase自身提供的一個名為 Procedure(V2) 的框架來保障操作的事務性的，備Master接管服務以后，將會繼續完成整個建表操作。

　　一個被創建成功的表，還可以被執行如下操作：

　　Disable 將所有的Region下線，該表暫停讀寫服務

　　Enable 將一個Disable過的表重新Enable，也就是上線所有的Region來正常提供讀寫服務

　　Alter 更改表或列族的描述信息

　　Master分配Regions到各個RegionServers

　　新創建的所有的Regions，通過 AssignmentManager 將這些Region按照輪詢(Round-Robin)的方式分配到每一個RegionServer中，具體的分配計劃是由 LoadBalancer 來提供的。

　　AssignmentManager負責所有Regions的分配/遷移操作，Master中有一個定時運行的線程，來檢查集群中的Regions在各個RegionServer之間的負載是否是均衡的，如果不均衡，則通過LoadBalancer生成相應的Region遷移計劃，HBase中支持多種負載均衡算法，有最簡單的僅考慮各RegionServer上的Regions數目的負載均衡算法，有基于遷移代價的負載均衡算法，也有數據本地化率優先的負載均衡算法，因為這一部分已經提供了插件化機制，用戶也可以自定義負載均衡算法。

“HBase入門問題有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！