【原】BigData之Hbase：Hbase數(shù)據(jù)管理的簡介、下載、案例應用之詳細攻略

處女座的程序猿 2021-09-28

展開全文

BigData之Hbase：Hbase數(shù)據(jù)管理的簡介、下載、案例應用之詳細攻略

Hbase數(shù)據(jù)管理的簡介——基于Hadoop的非結構化、基于列的數(shù)據(jù)存儲的數(shù)據(jù)庫

? ? ? ? HBase – Hadoop Database，是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系統(tǒng)，利用HBase技術可在廉價PC Server上搭建起大規(guī)模結構化存儲集群。

HBase利用Hadoop HDFS作為其文件存儲系統(tǒng)；
Google運行MapReduce來處理Bigtable中的海量數(shù)據(jù)，HBase同樣利用Hadoop MapReduce來處理HBase中的海量數(shù)據(jù)
Google Bigtable利用 Chubby作為協(xié)同服務，HBase利用Zookeeper作為對應。

? ? ? ? HBase是一個分布式的、面向列的開源數(shù)據(jù)庫，該技術來源于 Fay Chang 所撰寫的Google論文“Bigtable：一個結構化數(shù)據(jù)的分布式存儲系統(tǒng)”。就像Bigtable利用了Google文件系統(tǒng)（File System）所提供的分布式數(shù)據(jù)存儲一樣，HBase在Hadoop之上提供了類似于Bigtable的能力。HBase是Apache的Hadoop項目的子項目。HBase不同于一般的關系數(shù)據(jù)庫，它是一個適合于非結構化數(shù)據(jù)存儲的數(shù)據(jù)庫。另一個不同的是HBase基于列的而不是基于行的模式。
? ? ? Hbase是一種No SQL數(shù)據(jù)庫，這意味著它不像傳統(tǒng)的RDBMS數(shù)據(jù)庫那樣支持SQL作為查詢語言。Hbase是一種分布式存儲的數(shù)據(jù)庫，技術上來講，它更像是分布式存儲而不是分布式數(shù)據(jù)庫。

Hadoop HDFS為HBase提供了高可靠性的底層存儲支持；
Hadoop MapReduce為HBase提供了高性能的計算能力；
Zookeeper為HBase提供了穩(wěn)定服務和failover機制。

1、HBase的架構體現(xiàn)及與HDFS、MapReduce、Zookeeper之間關系

? ? ? ? ?HBase位于結構化存儲層。Hadoop HDFS為HBase提供了高可靠性的底層存儲支持，Hadoop MapReduce為HBase提供了高性能的計算能力，Zookeeper為HBase提供了穩(wěn)定服務和failover機制。

Zookeeper，作為分布式的協(xié)調(diào)。RegionServer也會把自己的信息寫到ZooKeeper中。
HDFS是Hbase運行的底層文件系統(tǒng)
RegionServer，理解為數(shù)據(jù)節(jié)點，存儲數(shù)據(jù)的。
Master RegionServer要實時的向Master報告信息。Master知道全局的RegionServer運行情況，可以控制RegionServer的故障轉移和Region的切分。

2、Hbase的訪問接口

(1)、Native Java API，最常規(guī)和高效的訪問方式，適合Hadoop MapReduce Job并行批處理HBase表數(shù)據(jù)。
(2)、HBase Shell，HBase的命令行工具，最簡單的接口，適合HBase管理使用。
(3)、Thrift Gateway，利用Thrift序列化技術，支持C++，PHP，Python等多種語言，適合其他異構系統(tǒng)在線訪問HBase表數(shù)據(jù)。
(4)、REST Gateway，支持REST 風格的Http API訪問HBase, 解除了語言限制。
(5)、Pig，可以使用Pig Latin流式編程語言來操作HBase中的數(shù)據(jù)，和Hive類似，本質最終也是編譯成MapReduce Job來處理HBase表數(shù)據(jù)，適合做數(shù)據(jù)統(tǒng)計。
(6)、Hive，當前Hive的Release版本尚沒有加入對HBase的支持，但在下一個版本Hive 0.7.0中將會支持HBase，可以使用類似SQL語言來訪問HBase。

3、HBase中的所有數(shù)據(jù)文件都存儲在Hadoop HDFS文件系統(tǒng)上，主要包括上述提出的兩種文件類型：

(1)、HFile， HBase中KeyValue數(shù)據(jù)的存儲格式，HFile是Hadoop的二進制格式文件，實際上StoreFile就是對HFile做了輕量級包裝，即StoreFile底層就是HFile
(2)、HLog File，HBase中WAL（Write Ahead Log）的存儲格式，物理上是Hadoop的Sequence File。

4、Hbase與傳統(tǒng)的mysql、oracle的差別——列式數(shù)據(jù)與行式數(shù)據(jù)的區(qū)別——NoSql數(shù)據(jù)庫與傳統(tǒng)關系型數(shù)據(jù)的區(qū)別

參考文章：https://blog.csdn.net/yczws1/article/details/19178265#1536434-tsina-1-98976-66a1f5d8f89e9ad52626f6f40fdeadaa

4.1、Hbase VS Oracle

(1)、Hbase適合大量插入同時又有讀的情況。輸入一個Key獲取一個value或輸入一些key獲得一些value。
(2)、Hbase的瓶頸是硬盤傳輸速度。Hbase的操作，它可以往數(shù)據(jù)里面insert，也可以update一些數(shù)據(jù)，但update的實際上也是insert，只是插入一個新的時間戳的一行。Delete數(shù)據(jù)，也是insert，只是insert一行帶有delete標記的一行。
? ? ? ?Hbase的所有操作都是追加插入操作。Hbase是一種日志集數(shù)據(jù)庫。它的存儲方式，像是日志文件一樣。它是批量大量的往硬盤中寫，通常都是以文件形式的讀寫。這個讀寫速度，就取決于硬盤與機器之間的傳輸有多快。
? ? ? ??而Oracle的瓶頸是硬盤尋道時間。它經(jīng)常的操作時隨機讀寫。要update一個數(shù)據(jù)，先要在硬盤中找到這個block，然后把它讀入內(nèi)存，在內(nèi)存中的緩存中修改，過段時間再回寫回去。由于你尋找的block不同，這就存在一個隨機的讀。硬盤的尋道時間主要由轉速來決定的。而尋道時間，技術基本沒有改變，這就形成了尋道時間瓶頸。
(3)、Hbase中數(shù)據(jù)可以保存許多不同時間戳的版本（即同一數(shù)據(jù)可以復制許多不同的版本，準許數(shù)據(jù)冗余，也是優(yōu)勢）。數(shù)據(jù)按時間排序，因此Hbase特別適合尋找按照時間排序尋找Top n的場景。找出某個人最近瀏覽的消息，最近寫的N篇博客，N種行為等等，因此Hbase在互聯(lián)網(wǎng)應用非常多。
(4)、Hbase的局限是只能做很簡單的Key-value查詢。它適合有高速插入，同時又有大量讀的操作場景。而這種場景又很極端，并不是每一個公司都有這種需求。在一些公司，就是普通的OLTP（聯(lián)機事務處理）隨機讀寫。在這種情況下，Oracle的可靠性，系統(tǒng)的負責程度又比Hbase低一些。而且Hbase局限還在于它只有主鍵索引，因此在建模的時候就遇到了問題。比如，在一張表中，很多的列我都想做某種條件的查詢。但卻只能在主鍵上建快速查詢。所以說，不能籠統(tǒng)的說那種技術有優(yōu)勢。
(5)、Oracle是行式數(shù)據(jù)庫，而Hbase是列式數(shù)據(jù)庫。列式數(shù)據(jù)庫的優(yōu)勢在于數(shù)據(jù)分析這種場景。數(shù)據(jù)分析與傳統(tǒng)的OLTP的區(qū)別。數(shù)據(jù)分析，經(jīng)常是以某個列作為查詢條件，返回的結果也經(jīng)常是某一些列，不是全部的列。在這種情況下，行式數(shù)據(jù)庫反應的性能就很低效。

4.2、列式數(shù)據(jù)庫(Hbase) VS 行式數(shù)據(jù)庫(Oracle)

列式數(shù)據(jù)庫：是以列作為元素存儲的。同一個列的元素會擠在一個塊。當要讀某些列，只需要把相關的列塊讀到內(nèi)存中，這樣讀的IO量就會少很多。通常，同一個列的數(shù)據(jù)元素通常格式都是相近的。這就意味著，當數(shù)據(jù)格式相近的時候，數(shù)據(jù)就可以做大幅度的壓縮。所以，列式數(shù)據(jù)庫在數(shù)據(jù)壓縮方面有很大的優(yōu)勢，壓縮不僅節(jié)省了存儲空間，同時也節(jié)省了IO。（這一點，可利用在當數(shù)據(jù)達到百萬、千萬級別以后，數(shù)據(jù)查詢之間的優(yōu)化，提高性能，示場景而定）
行式數(shù)據(jù)庫：Oracle為例，數(shù)據(jù)文件的基本組成單位：塊/頁。塊中數(shù)據(jù)是按照一行行寫入的。這就存在一個問題，當我們要讀一個塊中的某些列的時候，不能只讀這些列，必須把這個塊整個的讀入內(nèi)存中，再把這些列的內(nèi)容讀出來。換句話就是：為了讀表中的某些列，必須要把整個表的行全部讀完，才能讀到這些列。這就是行數(shù)據(jù)庫最糟糕的地方。

5、什么時候使用Hbase？

Hbase不適合解決所有的問題：

適合數(shù)據(jù)庫量要足夠多的場景——盡可能使所有機器高效利用。如果有十億及百億行數(shù)據(jù)，那么Hbase是一個很好的選項。如果只有幾百萬行甚至不到的數(shù)據(jù)量，RDBMS是一個很好的選擇。因為數(shù)據(jù)量小的話，真正能工作的機器量少，剩余的機器都處于空閑的狀態(tài)。
適合不需要輔助索引，靜態(tài)類型的列，事務等特性的場景。一個已經(jīng)用RDBMS的系統(tǒng)想要切換到Hbase，則需要重新設計系統(tǒng)。
保證硬件資源足夠，每個HDFS集群在少于5個節(jié)點的時候，都不能表現(xiàn)的很好。因為HDFS默認的復制數(shù)量是3，再加上一個NameNode。

Hbase數(shù)據(jù)管理的下載

官方下載地址：http://www./dyn/closer.cgi/hbase/
推薦下載地址：https://mirrors./apache/hbase/

Hbase數(shù)據(jù)管理的案例應用

1、內(nèi)部應用

存儲業(yè)務數(shù)據(jù):車輛GPS信息，司機點位信息，用戶操作信息，設備訪問信息。
存儲日志數(shù)據(jù):架構監(jiān)控數(shù)據(jù)（登錄日志，中間件訪問日志，推送日志，短信郵件發(fā)送記錄等），業(yè)務操作日志信息。
存儲業(yè)務附件：UDFS系統(tǒng)存儲圖像，視頻，文檔等附件信息。

參考文章
入門HBase，看這一篇就夠了