一、下載地址（永久有效）

 

 

 

百度雲盤下載（公開永久）：HBase權威指南【中文版】.pdf

 

 

 

二、HBase產生的背景

 

 

 

        2003年，Google發表了一篇論文，叫"The Google File System"。這個分散式檔案系統簡稱GFS，它使商用硬體叢集儲存海量資料。檔案系統將資料在節點之間進行冗餘複製，這樣的話，即使一臺儲存伺服器發生故障，也不會影響資料的可用性。它對資料的流式讀取也做了優化，可以邊處理邊讀取。

                    （Hadoop的HDFS   參考  Google的 GFS）

        不久，Google又發表了另一篇論文，叫"MapReduce: Simpliied Data Processing on Large Clusters"。MapReduce是GFS架構的一個補充，因為它能夠充分利用GFS叢集中的每個商用伺服器提供的大量CPU。MapReduce加上GFS形成了處理海量資料的核心力量，包括構建Google的搜尋索引。

                    （Hadoop的MapReduce參考  Google的MapReduce）

        不過以上描述的兩個系統都缺乏實時隨機儲存資料的能力（意味著尚不足以處理Web服務）。GFS的另一個缺陷就是，它適合儲存少許非常非常大的檔案，而不適合儲存成千上千萬的小檔案，因為檔案的後設資料資訊最終要儲存在主節點（NameNode）的記憶體中，檔案越多主節點的壓力越大。

        因此，Google嘗試去找到一個能夠驅動互動應用的解決方案，例如，Google郵件或者Google分析，能夠同時利用這種基礎結構、依靠GFS儲存的資料冗餘和資料可用性較強的特點。儲存的資料應該拆分成特別小的條目，然後由系統將這些小記錄聚合到非常大的儲存檔案中，並提供一些索引排序，讓使用者可以查詢最少的磁碟（磁碟定址）就能夠獲取資料。最終，它應該能夠及時儲存爬蟲的結果，並跟MapReduce協作構建搜尋索引。

 

        意識到RDBMS（關係型資料庫）在大規模處理中的缺點，工程師們開始考慮問題的其他切入點：摒棄關係型的特點，採用簡單的API來進行增、查、改、刪（CRUD == Create、Read、Update and Delete）操作，再加一個掃描函式（scan），在較大的鍵範圍或全表上進行迭代掃描。這些努力的成果最終在2006年的論文"BigTable： A Distributed Storeage System for Structured Data" 中發表了。

        "BigTable" 是一個管理結構化資料的分散式儲存系統，它可以擴充套件到非常大：如在成千上萬的商用伺服器上儲存PB級的資料。......一個稀疏的、分散式的、持久化的多維排序對映"。

              （Hadoop的HBase參考  Google的BigTable）

 

 

 

 

三、HBase的主要主件

 

        HBase中有三個主要元件：客戶端庫、一臺主伺服器、多臺region伺服器。可以動態地增加和移動region伺服器，以適應不斷變化的負載。主伺服器主要負責利用Apache Zookeeper為region伺服器分配region，Apache Zookeeper是一個高可靠的、高可用的持久化的分散式協調系統。

 

 

 

 

        Zookeeper是Apache 軟體基金會旗下的一個獨立的開源系統，它是Google公司為解決BigTable中問題而提出的Chubby演算法的一種開源實現。它提供了類似檔案系統一樣的訪問目錄和檔案（稱為znode）的功能，通常分散式系統利用它協調所有權、註冊服務、監聽更新。

        每臺region伺服器在Zookeeper中註冊一個自己的臨時節點（客戶端開啟一個Session，一旦客戶端關閉，節點將會在ZK服務端被刪除），主伺服器會利用這些臨時節點來發現可用的伺服器，還可以利用臨時節點來跟蹤機器故障和網路分割槽。

 

        在Zookeeper伺服器中，每個臨時節點都屬於某一個會話，這個會話是客戶端連線上Zookeeper伺服器之後自動生成的。每個會話在伺服器中有一個唯一的id，並且客戶端會以此id不斷地向Zookeeper伺服器發生"心跳"，一旦發生故障Zookeeper客戶端程式死掉，Zookeeper伺服器會判定該會話超時，並自動刪除屬於它的臨時節點（節點類似於檔案系統中的資料夾）。

 

 

 

 

（1）zkServer.sh start   開啟ZK服務（ZK叢集中的每臺ZK服務都要開啟）

 

 

 

 

（2）zkCli.sh -server localhost:2181  ZK服務端開啟後，啟動ZK客戶端進行連線

 

 

 

 

最後定格在

 

 

 

 

 

 

（3）create -e /app1/ data-0 客戶端連線ZK服務後，在根目錄下建立一個臨時Znode節點叫"app1",其value值我們設定為"data-0"

 

 

 

 

建立之後，我們會發現叢集中其餘ZK服務會同步更新這個Znode節點（app1資料夾）

 

 

 

比如，我們在144的Zookeeper伺服器上進行"ls /" （列出ZK根目錄下面的檔案）如下

 

 

 

 

146的亦如此：

 

 

 

 

 

除了我們剛才建立的app1節點外，ZK叢集中還有Zk自己的節點zookeeper和kafka的brokers節點以及hbase節點（永久）等

 

 

我們可以利用get命令，來檢視節點（資料夾）app1的資訊如下（在144伺服器上程式操作）：

 

 

 

 

 

 

由於我們建立的znode是臨時節點，因此，當我們退出（quit）當前客戶端連線會話時，節點app1會被刪除，退出後，我們再次連線ZK服務進行查詢，發現已經沒有該節點了，效果如下：

 

 

 

 

 

 

 

 

 

 

        HBase還可以利用Zookeeper確保只有一個主服務在執行（HBaseMaster），儲存用於發現region的引導位置，作為一個region伺服器的登錄檔，以及實現其他目的。Zookeeper是一個關鍵組成部分，沒有它HBase就無法運作。Zookeeper使用分散式的一系列伺服器和Zap協議（確保其狀態儲存一致）減輕了應用上的負擔。

 

        master伺服器負責跨region伺服器的全域性region的負載均衡，將繁忙的伺服器中的region移動到負載較輕的伺服器中。主伺服器（HBaseMaster）不是實際資料儲存或者檢索路徑的組成部分，它僅提供了負載均衡和叢集管理，不為region伺服器或者客戶端提供任何的資料服務，因此是輕量級伺服器。此外，主伺服器還提供了後設資料的管理操作，例如，建表和建立列族（column family）。

 

        region伺服器負責為它們的服務的region提供讀和寫請求，也提供了拆分超過配置大小的region的介面。客戶端則直接與region伺服器通訊，處理所有資料相關的操作。

 

        "數十億行 X 數百萬列 X 數千個版本 = TB級 或 PB級的儲存"

 

 

 

其餘內容，請自行學習，學習使人快樂！