HBase权威指南【中文版】
一、下載地址（永久有效）
?
?
?
百度云盤下載（公開永久）：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服務器?？梢詣討B地增加和移動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的接口?？蛻舳藙t直接與region服務器通信，處理所有數據相關的操作。
?
????????"數十億行 X 數百萬列 X 數千個版本 = TB級 或 PB級的存儲"
?
?
?
其余內容，請自行學習，學習使人快樂！
?
總結
以上是生活随笔為你收集整理的HBase权威指南【中文版】的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 配置mysql环境变量
- 下一篇： 友盟分享