HBase 簡介
HBase（Hadoop database）是一個分散式、可擴充套件、面向列的 NoSQL 資料庫，本質上是一個 Key-Value 系統，底層儲存基於 HDFS，原生支援 MapReduce 計算框架，具有高吞吐、低延時的讀寫特點。
HBase 主要特性
HBase包含很多重要的特性，如下：
強一致性讀寫：HBase並不是最終一致性，而是強一致性的系統，這使得HBase非常適合做高速的聚合操作。
自動sharding：HBase的表在水平方向上以region為單位分散式儲存在各個節點上，當region達到一定大小時，就會自動split重新分佈資料。
自動故障轉移：這是HBase高可用的體現，當某一個節點故障下線時，節點上的region也會下線並會自動轉移到狀態良好的節點上線。
面向列的儲存：HBase是面向列的儲存系統，相同特徵（列族相同）的資料會被儘量放到一起，這有利於提高資料讀取的效率。
無縫結合Hadoop：HBase被定義為Hadoop database，就是基於HDFS做的資料儲存，同時原生的支援MapReduce計算引擎。
非常友好的API操作：HBase提供了簡單易用的Java API，並且提供了Thrift與REST的API供非Java環境使用。
Block Cache與Bloom Filter：查詢最佳化方面HBase支援Block Cache與Bloom Filter，使得HBase能夠對海量資料做高效查詢。
HBase作為一款NoSQL資料庫，並不能解決所有問題。關於我們在實際生產過程中滿足哪些條件的時候可以選擇HBase作為底層儲存，這裡給出幾點建議：
1、資料量規模非常龐大
一般而言，單表資料量如果只有百萬級或者更少，不是非常建議使用HBase而應該考慮關係型資料庫是否能夠滿足需求；單表資料量超過千萬或者十億百億的時候，並且伴有較高併發，可以考慮使用HBase。這主要是充分利用分散式儲存系統的優勢，如果資料量比較小，單個節點就能有效儲存的話則其他節點的資源就會存在浪費。
2、要求是實時的點查詢
HBase是一個Key-Value資料庫，預設對Rowkey即行鍵做了索引最佳化，所以即使資料量非常龐大，根據行鍵的查詢效率依然會很高，這使得HBase非常適合根據行鍵做單條記錄的查詢。值得說明的是，允許根據行鍵的一部分做範圍查詢，這裡涉及到Rowkey的設計問題，不再贅言。
3、能夠容忍NoSQL短板
前面提及了NoSQL並不能解決所有問題，HBase也是一樣，如果業務場景是需要事務支援、複雜的關聯查詢等，不建議使用HBase。HBase有它適合的業務場景，我們不能苛求它能夠幫我們解決所有問題。
4、資料分析需求並不多
雖然說HBase是一個面向列的資料庫，但它有別於真正的列式儲存系統比如Parquet、Kudu等，再加上自身儲存架構的設計，使得HBase並不擅長做資料分析，或者說資料分析是HBase的弱項，所以如果主要的業務需求就是為了做資料分析，比如做報表，那麼不建議直接使用HBase。
如果能夠滿足上述的幾點，硬體條件也滿足的情況下，強烈建議考慮使用HBase作為底層儲存解決你的問題。
由於HBase豐富的特性，加上自身的海量資料儲存能力與超大規模併發訪問能力，使得HBase應用非常廣泛。目前已經在金融、交通、醫療、車聯網、IoT等眾多領域有了最佳實踐，涉及到訂單/賬單儲存、使用者畫像、時空/時序資料、物件儲存、Cube分析等各個使用場景。
HBase 簡介
HBase（Hadoop database）是一個分散式、可擴充套件、面向列的 NoSQL 資料庫，本質上是一個 Key-Value 系統，底層儲存基於 HDFS，原生支援 MapReduce 計算框架，具有高吞吐、低延時的讀寫特點。
HBase 主要特性
HBase包含很多重要的特性，如下：
強一致性讀寫：HBase並不是最終一致性，而是強一致性的系統，這使得HBase非常適合做高速的聚合操作。
自動sharding：HBase的表在水平方向上以region為單位分散式儲存在各個節點上，當region達到一定大小時，就會自動split重新分佈資料。
自動故障轉移：這是HBase高可用的體現，當某一個節點故障下線時，節點上的region也會下線並會自動轉移到狀態良好的節點上線。
面向列的儲存：HBase是面向列的儲存系統，相同特徵（列族相同）的資料會被儘量放到一起，這有利於提高資料讀取的效率。
無縫結合Hadoop：HBase被定義為Hadoop database，就是基於HDFS做的資料儲存，同時原生的支援MapReduce計算引擎。
非常友好的API操作：HBase提供了簡單易用的Java API，並且提供了Thrift與REST的API供非Java環境使用。
Block Cache與Bloom Filter：查詢最佳化方面HBase支援Block Cache與Bloom Filter，使得HBase能夠對海量資料做高效查詢。
什麼時候使用 HBaseHBase作為一款NoSQL資料庫，並不能解決所有問題。關於我們在實際生產過程中滿足哪些條件的時候可以選擇HBase作為底層儲存，這裡給出幾點建議：
1、資料量規模非常龐大
一般而言，單表資料量如果只有百萬級或者更少，不是非常建議使用HBase而應該考慮關係型資料庫是否能夠滿足需求；單表資料量超過千萬或者十億百億的時候，並且伴有較高併發，可以考慮使用HBase。這主要是充分利用分散式儲存系統的優勢，如果資料量比較小，單個節點就能有效儲存的話則其他節點的資源就會存在浪費。
2、要求是實時的點查詢
HBase是一個Key-Value資料庫，預設對Rowkey即行鍵做了索引最佳化，所以即使資料量非常龐大，根據行鍵的查詢效率依然會很高，這使得HBase非常適合根據行鍵做單條記錄的查詢。值得說明的是，允許根據行鍵的一部分做範圍查詢，這裡涉及到Rowkey的設計問題，不再贅言。
3、能夠容忍NoSQL短板
前面提及了NoSQL並不能解決所有問題，HBase也是一樣，如果業務場景是需要事務支援、複雜的關聯查詢等，不建議使用HBase。HBase有它適合的業務場景，我們不能苛求它能夠幫我們解決所有問題。
4、資料分析需求並不多
雖然說HBase是一個面向列的資料庫，但它有別於真正的列式儲存系統比如Parquet、Kudu等，再加上自身儲存架構的設計，使得HBase並不擅長做資料分析，或者說資料分析是HBase的弱項，所以如果主要的業務需求就是為了做資料分析，比如做報表，那麼不建議直接使用HBase。
如果能夠滿足上述的幾點，硬體條件也滿足的情況下，強烈建議考慮使用HBase作為底層儲存解決你的問題。
HBase 使用場景由於HBase豐富的特性，加上自身的海量資料儲存能力與超大規模併發訪問能力，使得HBase應用非常廣泛。目前已經在金融、交通、醫療、車聯網、IoT等眾多領域有了最佳實踐，涉及到訂單/賬單儲存、使用者畫像、時空/時序資料、物件儲存、Cube分析等各個使用場景。