Hadoop中HBase工作的簡要概述
1.引言
HBase是一種高可靠性，高性能，面向列的可擴展分佈式存儲系統，它使用HBase技術在廉價的PC服務器上構建大規模結構化存儲集群。 HBase的目標是存儲和處理大量數據，特別是僅使用標準硬件配置即可處理包含數千行和列的大量數據。
與MapReduce的離線批量計算框架不同，HBase是隨機訪問存儲和檢索數據平臺，彌補了HDFS無法隨機訪問數據的缺點。
它適用於實時性要求不高的業務場景-HBase存儲Byte數組，該數組不介意數據類型，從而允許動態，靈活的數據模型。
> Hadoop Ecosystem (Credit: Edureka.com)
上圖描繪了Hadoop 2.0生態系統的各個層-位於結構化存儲層上的Hbase。
HDFS為HBase提供了高可靠性的低級存儲支持。
MapReduce為HBase提供了高性能的批處理功能。 ZooKeeper為HBase提供穩定的服務和故障轉移機制。 Pig和Hive為數據統計處理的高級語言支持提供了HBase，Sqoop為HDB提供了可用的RDBMS數據導入功能，這使得從傳統數據庫到HBase的業務數據遷移非常方便。
2. HBase架構
2.1設計Idea
HBase是一個分佈式數據庫，使用ZooKeeper來管理群集和HDFS作為基礎存儲。
在體系結構級別，它由HMaster（由Zookeeper選擇的領導者）和多個HRegionServers組成。
下圖顯示了基礎架構：
在HBase的概念中，HRegionServer對應於群集中的一個節點，一個HRegionServer負責管理多個HRegion，一個HRegion代表表數據的一部分。
在HBase中，一個表可能需要很多HRegion來存儲數據，並且每個HRegion中的數據都不會雜亂無章。
當HBase管理HRegion時，它將為每個HRegion定義一定範圍的Rowkey。 屬於定義範圍的數據將被移交給特定區域，從而將負載分配給多個節點，從而利用分佈和特性的優勢。
同樣，HBase將自動調整區域的位置。 如果HRegionServer過熱，即大量請求落在HRegionServer管理的HRegion上，則HBase會將HRegion移動到相對空閒的其他節點，以確保充分利用群集環境。
2.2基本架構
HBase由HMaster和HRegionServer組成，並且遵循主從服務器體系結構。 HBase將邏輯表分為多個數據塊HRegion，並將它們存儲在HRegionServer中。
HMaster負責管理所有HRegionServer。 它本身不存儲任何數據，而僅存儲數據到HRegionServer的映射（元數據）。
群集中的所有節點均由Zookeeper協調，並處理HBase操作期間可能遇到的各種問題。 HBase的基本架構如下所示：
客戶端：使用HBase的RPC機制與HMaster和HRegionServer通信，提交請求並獲得結果。 對於管理操作，客戶端使用HMaster執行RPC。 對於數據讀取和寫入操作，客戶端使用HRegionServer執行RPC。
Zookeeper：通過將集群中每個節點的狀態信息註冊到ZooKeeper，HMaster可以隨時感知每個HRegionServer的健康狀態，還可以避免HMaster的單點故障。
HMaster：管理所有HRegionServer，告訴他們需要維護哪些HRegion，並監視所有HRegionServer的運行狀況。 當新的HRegionServer登錄到HMaster時，HMaster告訴它等待數據分配。 當HRegion死亡時，HMaster將其負責的所有HRegion標記為未分配，然後將它們分配給其他HRegionServer。 HMaster沒有單點問題。 HBase可以啟動多個HMaster。 通過Zookeeper的選舉機制，群集中始終有一個HMaster運行，從而提高了群集的可用性。
HRegion：當表的大小超過預設值時，HBase會自動將表劃分為不同的區域，每個區域都包含表中所有行的子集。 對於用戶來說，每個表都是數據的集合，用主鍵（RowKey）加以區分。 從物理上講，一個表分為多個塊，每個塊都是一個HRegion。 我們使用表名+開始/結束主鍵來區分每個HRegion。 一個HRegion會將一段連續數據保存在一個表中。 完整的表數據存儲在多個HRegions中。
HRegionServer：HBase中的所有數據通常從底層存儲在HDFS中。 用戶可以通過一系列HRegionServer獲得此數據。 通常，群集的一個節點上僅運行一臺HRegionServer，並且每個段的HRegion僅由一個HRegionServer維護。 HRegionServer主要負責響應用戶I / O請求將數據讀取和寫入HDFS文件系統。 它是HBase中的核心模塊。 HRegionServer在內部管理一系列HRegion對象，每個HRegion對應於邏輯表中的連續數據段。 HRegion由多個HStore組成。 每個HStore對應於邏輯表中一個列族的存儲。 可以看出，每個列族都是一個集中式存儲單元。 因此，為了提高操作效率，最好將具有共同I / O特性的列放在一個列系列中。
HStore：它是HBase存儲的核心，它由MemStore和StoreFiles組成。 MemStore是內存緩衝區。用戶寫入的數據將首先放入MemStore。當MemStore已滿時，Flush將是一個StoreFile（底層實現是HFile）。當StoreFile文件的數量增加到某個閾值時，將觸發Compact合併操作，將多個StoreFile合併為一個StoreFile，並在合併過程中執行版本合併和數據刪除操作。因此，可以看出，HBase僅添加數據，並且所有更新和刪除操作都在後續的Compact進程中執行，因此用戶的寫入操作可以在其進入內存後立即返回，從而確保HBaseI /哦當StoreFiles Compact時，它將逐漸形成越來越大的StoreFile。當單個StoreFile的大小超過某個閾值時，將觸發分割操作。同時，當前的HRegion將被拆分為2個HRegion，並且父HRegion將脫機。 HMaster將這兩個子HRegion分配給相應的HRegionServer，以便將原始HRegion的負載壓力分流到這兩個HRegion。
HLog：每個HRegionServer都有一個HLog對象，該對象是實現預寫日誌的預寫日誌類。 每次用戶將數據寫入MemStore時，它還將數據的副本寫入HLog文件。 定期滾動和刪除HLog文件，並刪除舊文件（已保存到StoreFile的數據）。 當HMaster檢測到HRegionServer被Zookeeper意外終止時，HMaster首先處理舊版HLog文件，分割不同HRegion的HLog數據，將它們放入相應的HRegion目錄中，然後重新分發無效的HRegion。 在加載HRegion的過程中，這些HRegion的HRegionServer將發現需要處理HLog的歷史記錄，因此將Replay HLog中的數據傳輸到MemStore，然後刷新到StoreFiles以完成數據恢復。
2.3 根和元
HBase的所有HRegion元數據都存儲在.META中。 表。 隨著HRegion的增加，.META表中的數據也增加並分裂為多個新的HRegion。
為了找到.META表中每個HRegion的位置，將表中.META表中所有HRegion的元數據存儲在-ROOT-table中，最後，Zookeeper記錄ROOT表的位置信息。
在所有客戶端訪問用戶數據之前，他們需要首先訪問Zookeeper以獲取-ROOT-的位置，然後訪問-ROOT-table以獲取.META表的位置，最後根據以下信息確定用戶數據的位置： META表中的信息，如下所示：該圖顯示。
-ROOT表永遠不會拆分。 它只有一個HRegion，這可以確保只需三個跳轉就可以定位任何HRegion。 為了加快訪問速度，.META表的所有區域都保留在內存中。
客戶端緩存查詢的位置信息，並且緩存不會主動失敗。 如果客戶端仍然無法基於緩存的信息訪問數據，則請相關.META表的Region服務器嘗試獲取數據的位置。 如果仍然失敗，請詢問與-ROOT-table關聯的.META表在哪裡。
最後，如果先前的信息全部無效，則Zookeeper將HRegion的數據重定位。 因此，如果客戶端上的緩存完全無效，則需要來回六次以獲取正確的HRegion。
3. HBase數據模型
HBase是類似於BigTable的分佈式數據庫。 它是稀疏的長期存儲（在HDFS上），多維和排序的映射表。 該表的索引是行關鍵字，列關鍵字和時間戳。 HBase數據是字符串，沒有類型。
將表視為大型映射。 您可以按行鍵，行鍵+時間戳或行鍵+列（列族：列修飾符）查找特定數據。 由於HBase稀疏地存儲數據，因此某些列可以為空。 上表給出了com.cnn.www網站的邏輯存儲邏輯視圖。 表中只有一行數據。
該行的唯一標識符是" com.cnn.www"，並且此數據行的每次邏輯修改都有一定的時間。 標記對應於。
該表中有四列：內容：HTML，anchor：cnnsi.com，anchor：my.look.ca，mime：type，每個列都給出了它所屬的列族。
行鍵（RowKey）是表中數據行的唯一標識符，並用作檢索記錄的主鍵。
在HBase中，只有三種方法可以訪問表中的行：通過行鍵進行訪問，給定行鍵的範圍訪問以及全表掃描。
行鍵可以是任何字符串（最大長度為64KB），並按字典順序存儲。 對於經常一起讀取的行，需要仔細設計基本值，以便可以將它們一起存儲。
4. HBase讀寫過程
下圖是HRegionServer數據存儲關係圖。 如上所述，HBase使用MemStore和StoreFile將更新存儲到表中。 數據在更新後首先寫入HLog和MemStore。 MemStore中的數據已排序。
當MemStore累積到某個閾值時，將創建一個新的MemStore，並將舊的MemStore添加到Flush隊列中，並將一個單獨的線程刷新到磁盤上以成為StoreFile。 同時，系統將在Zookeeper中記錄一個CheckPoint，表明該時間之前的數據更改已保留。 當發生意外系統時，MemStore中的數據可能會丟失。
在這種情況下，HLog用於在CheckPoint之後恢復數據。
StoreFile是隻讀的，一旦創建便無法修改。 因此，HBase的更新是一項附加操作。 當商店中的StoreFile達到某個閾值時，將執行合併操作，並且將相同密鑰的修改合併以形成一個大型StoreFile。 當StoreFile的大小達到某個閾值時，StoreFile被拆分並分為兩個StoreFiles。
4.1寫操作流程
步驟1：客戶端通過Zookeeper的調度向HRegionServer發送寫數據請求，並將數據寫入HRegion。
步驟2：將數據寫入HRegion的MemStore，直到MemStore達到預設閾值。
步驟3：MemStore中的數據被整理到StoreFile中。
步驟4：隨著StoreFile文件數量的增加，當StoreFile文件數量增加到特定閾值時，將執行Compact合併操作，並將多個StoreFiles合併到一個StoreFile中，並在版本庫中執行版本合併和數據刪除。 同時。
步驟5：StoreFiles通過連續的Compact操作逐漸形成越來越大的StoreFile。
步驟6：在單個StoreFile的大小超過某個閾值之後，將觸發Split操作，將當前的HRegion拆分為兩個新的HRegion。 父HRegion將脫機，新的Split的兩個子HRegion將由HMaster分配給相應的HRegionServer，以便可以將原始HRegion的壓力分流到這兩個HRegion。
4.2讀取操作流程
步驟1：客戶端訪問Zookeeper，找到-ROOT-table，並獲得.META。 表信息。
步驟2：從.META中搜索。 表獲取目標數據的HRegion信息，找到對應的HRegionServer。
步驟3：獲取需要通過HRegionServer查找的數據。
步驟4：HRegionserver的內存分為兩部分：MemStore和BlockCache。 MemStore主要用於寫入數據，而BlockCache主要用於讀取數據。 首先將請求讀取到MemStore以檢查數據，檢查BlockCache檢查，然後檢查StoreFile，然後將讀取結果放入BlockCache。
5. HBase使用場景
半結構化或非結構化數據：對於沒有很好定義或混亂的數據結構字段，很難根據適用於HBase的概念來提取數據。 如果隨著業務增長存儲更多字段，則需要關閉RDBMS來維護更改表結構，並且HBase支持動態添加。
記錄非常稀疏：RDBMS行的多少列是固定的，而空列則浪費存儲空間。 HBase為空的列不會存儲，這樣可以節省空間並提高讀取性能。
多版本數據：根據RowKey和列標識符定位的值可以具有任意數量的版本值（時間戳是不同的），因此將HBase用於需要存儲更改歷史記錄的數據非常方便 。
大量數據：當數據量越來越大時，RDBMS數據庫將無法承受，並且存在讀寫分離策略。 通過一個主機，它負責寫操作，而多個從機則負責讀取操作，服務器成本增加了一倍。 隨著壓力的增加，船長無法承受壓力。 此時，將對庫進行劃分，並且將幾乎不相關的數據分別部署。 某些聯接查詢無法使用，並且需要使用中間層。 隨著數據量的進一步增加，表的記錄變得越來越大，查詢變得非常慢。
因此，有必要例如通過對ID進行模化將表劃分為多個表，以減少單個表的記錄數。 經歷過這些事情的人都知道如何拋棄這個過程。
HBase很簡單，只需將新節點添加到群集，HBase就會自動水平拆分，並且與Hadoop的無縫集成可確保數據可靠性（HDFS）和高性能的海量數據分析（MapReduce）。
6. HBase Map Reduce
HBase中的Table與Region之間的關係與HDFS中的File與Block之間的關係有些相似。 由於HBase提供了與MapReduce進行交互的API，例如TableInputFormat和TableOutputFormat，因此HBase數據表可以直接用作Hadoop MapReduce的輸入和輸出，這有利於MapReduce應用程序的開發，並且不需要注意HBase的處理。 系統本身的詳細信息。
如果您喜歡這個主題，可以看看我寫下的有關Hadoop的其他幾個主題。 如果您發現任何錯誤或有任何建議，請隨時通過我的LinkedIn與我聯繫。
(本文翻譯自Sahil Dhankhad的文章《HBase Working Principle: A part Hadoop Architecture》，參考：https://towardsdatascience.com/hbase-working-principle-a-part-of-hadoop-architecture-fbe0453a031b)
