Zookeeper的基本原理(zk架構、zk存儲結構、watch機制、獨立安裝zk、集群間同步復制)

1、Hbase集群的高可用性與伸縮性

　　HBase可以實現對Regionserver的監控，當個別Regionserver不可訪問時，將其負責的分區分給其他Regionsever，其轉移過程較快，因為只需要將分區的相關信息轉移。Hlog和表中數據實際存儲在HDFS上，本身具有多副本機制容錯。

　　Master節點以及HDFS中的Namenode節點，如果只部署一個，可能造成單點故障，可以依托Zookeeper實現這兩種關系主節點的高可用性配置。

Zookeeper實現的方法是：部署多個Master或Namenode,並區別為活躍節點和待命節點。當活躍節點發生故障后，待命節點自動提升為活躍節點。由Zookeeper負責監控活躍節點、選擇新的活躍節點等功能。

• 活躍節點：接收讀寫操作。
• 待命節點：從活躍節點實現同步數據。

HBase還可以通過集群間的同步機制，實現（列族）數據的分布式熱備份。

2、Zookpeeper的基本原理

場景：為了實現分布式服務中的數據同步與一致性、群組管理監控、分布投票協商與鎖（如分布式事務中的二階段提交）、命令尋址等，需要在集群中提供分布式協調服務。

Zookeeper：一款提供分布式協調服務的開源軟件。Zookeeper以Fast Paxos算法為基礎，提供分布式協調、選舉和鎖服務，並基於此擴展出配置維護、組服務、分布式消息隊列、分布式通知/協調等功能。

2.1 Zookeeper架構

Zookeeper采用集群化部署方式，一般部署在多台服務器上，以防止單點失效。（一般采用奇數台服務器部署，目的是用於投票時收斂）

服務器可以看做是proposer和acceptor（Zookeeper稱為follower）角色的綜合。

• 1.在服務器中選出leader進行提案和主持投票，如果leader失效，就重新選舉。選舉可以通過paxos或fastpaxos進行。
• 2. 理論上全體服務器可以對提案投票，但為了控制網絡開銷，一般選擇部分節點進行投票，而其他節點稱為observer,只觀察結果進行同步。

 

 PS:Zookeeper會在集群內同步數據，並通過所謂的watch機制實現對數據更新的監控，因此客戶端可以連接到任何一台服務器來監測數據變化，以實現客戶端集群內數據的最終一致性、原子性和順序性等保障。

Zookeeper提供了分布式獨享鎖、選舉、隊列等API接口，可以實現配置同步、集群管理等協調性服務。

2.2 Znode存儲結構

Zookeeper采用層次化目錄結構存儲數據。目錄 ==節點，在zookeeper中稱為Znode。

Znode的特點：

• 一次寫入、多次讀取，數據寫入后不可更改。
• 可以存儲多個版本的數據，以實現更新順序性。
• 一次性讀取整個Znode，不支持部分讀取。
• 根據數據的生命周期，具有4種節點，在創建時確定並且不能再修改。
  • 臨時節點（EPHEMERAL）：不支持子節點，會在客戶端會話結束時被刪除。
  • 臨時順序節點（EPHEMERAL_SEQUENTIAL）:臨時節點，但父節點會為一級子節點記錄創建時間，記錄節點的創建順序。
  • 持久節點（PERSISTENT）:持久存儲，一般根據客戶端需求刪除。
  • 持久順序節點(PERSISTENT_SEQUENTIAL):持久節點，但父節點會為一級子節點記錄創建時間，記錄節點的創建順序。

 

2.3 Watch機制

客戶端可以通過watch機制關注Znode的信息變化，實現配置管理、數據同步和分布式鎖等功能。

客戶端首先需要注冊一個watch，來觀察某個Znode。當出現數據更新或被刪除、子節點發生變化等情況時，Zookeeper集群會通過異步消息向客戶端發送事件通知。通知發送后，該watcher就會失效，如果此時再發送信息變化，客戶端就無法獲取新的通知，除非客戶端在進行新的注冊。可見，watch機制能夠確保消息的順序性（舊消息被接收之前，客戶端無法獲得新消息）以及最終一致性，但無法確保所有的數據變化都能夠被觀察到。

2.4 Hadoop和HBase對Zookeeper的利用

Hadoop在默認情況下並不會使用Zookeeper。

場景：HDFS和MapReduce采用主從結構，由主節點進行集群管理，子節點之間不會自主進行協調、同步和監控等。這種結構使得子節點易於橫向擴展，但主節點存在單點故障問題，即主節點宕機后，整個集群就失效了。Hadoop可以通過Zookeeper的協調能力實現主節點的高可用性，來解決這一個問題。

HBase中自帶Zookeeper服務，但也可以禁用后選擇外部獨立安裝的Zookeeper為其提供服務。HBase利用Zookeeper實現Regionserver監控、多Master高可用性管理以及META表入口存儲等功能。

3、基於Zookeeper的高可用性

由於HDFS采用分布式部署和數據多副本機制，因此當出現少量Datanode故障或少量機架故障時，並不會出現數據損失或數據處理任務失敗等情況。但Namenode角色在集群中只有一個，因此存在單點故障風險。HDFS的NamenodeHA(高可用性，High Available)方案：

該方案中存在2個Namenode,其中Active Namenode向集群提供服務，Stanby Namenode為待命狀態。Fsimage等信息存儲在一個可共享的網絡位置，Active Namenode寫入數據，Stanby Namenode則只能讀取，以防Fsimage出現多版本不一致的情況，即腦裂（brainsplit）。

Zookeeper分布式協調服務器可以監控Active Namenode的健康狀態，當發送故障時，通過分布式選舉機制將Stanby Namenode提升為Active Namenode,如果原Active Namenode從故障中恢復，則自動降級Stanby Namenode。整個過程自動進行，不需要人工干預。

HBase Hmaster 的高可用性原理與此類似，且在HBase中配置Master高可用性較為簡單，只需要在各節點的配置目錄下建立一個文本文件，命名為backup-masters,並在其中每行寫入一個主機名，即可完成配置。

//當執行start-hbase.sh命令時，直接在作為Master節點的主機上
hbase-daemon.sh start master 

4、獨立安裝Zookeeper

Zookeeper的基本安裝步驟：

1. 軟件部署
2. 軟件配置
3. 啟動與使用方法
4. HBase使用獨立的Zookeeper服務

4.1 軟件部署

　　獨立安裝Zookeeper是為向Hadoop和HBase共同提供服務的，Zookeeper對操作系統、軟件和網絡環境的要求與這些組件基本一致，能夠安裝Hadoop和HBase的節點也可以直接安裝Zookeeper。下載Zookeeper之后，可以得到一個壓縮包，將其解壓到權限合適的目錄即可完成基本部署。其中bin目錄下為可執行命令，conf目錄下為配置文件，lib目錄下為對應的庫包。

4.2 軟件配置

　　Zookeeper的配置文件為zoo.cfg,純文本格式。

PS:三台服務器的zoo.cfg文件配置內容完全一致，但在每台服務器的conf下還需要各建立一個myid文件，該文件為純文本文件，內容分別為1,2,3，對應下文配置的id與本機IP地址的關系。

//假設需要在三台服務器上部署Zookeeper，配置文件
tickTime =2000
dataDir = /zookeeper /data
dataLogDir = /zookeeper/logs
clientPort = 2181
initLimit = 5
syncLimit = 2
server.1=192.168.10.1:2888:3888
server.2=192.168.10.2:2888:3888
server.3=192.168.10.3:2888:3888

//tickTime=2000 配置內容為超時時間的基礎值，單位為毫秒。
//initLimit=5  配置follower與leader之間建立連接后進行同步的最長時間，數值5表示實際時間為5*tickTime。
//syncLimit=5 為leader和follower之間等待回復消息的最大時間，數值2表示2*tickTime。
//dataDir=/tmp/zookeeper  表示zookeeper服務器存儲快照文件的目錄
//dataLogDir 表示配置 zookeeper事務日志的存儲路徑，默認指定在dataDir目錄下 
//clientPort 表示客戶端和服務端建立連接的端口號： 2181,為Znode的訪問入口地址。
//server.id=host:port1:port2表示Zookeeper集群中有三個節點及其id、ip地址。port1是follower和leader交換消息的端口，port2表示follower選舉leader使用的端口。 

4.3 啟動與使用方法

//在各個節點的linux命令行依次執行啟動：
zkServer.sh start
//jps 或zkServer.sh status 命令查看進程是否成功啟動
zkServer.sh status
//進入zk命令行環境
zcCli.sh -server 192.168.10.1:2181
//help命令是查看命令列表
help
//ls <path> 指令，可以查看各個Znode信息
ls /hbase

4.4 HBase使用獨立的Zookeeper服務

默認情況下，HBase利用自帶的ZK提供分布式協調服務。默認使用自帶ZK命令參數為：HBASE_MANAGES_ZK=true，隨着HBase的啟動而啟動。

//手動控制其Zookeeper的啟停
hbase-daemons sh {start,stop} zookeeper

 如果使用獨立的ZK服務，則需要確保ZK集群先於HBase集群啟動。如果有多個HBase集群共享一個Zookeeper服務，則需要在各自的配置文件中，配置不同的Znode入口，方法是hbase-site.xml中配置'zookeeper.znode.parent'為不同的路徑。（默認值為/hbase）

5、集群間同步復制

　　集群間同步（Replication機制），指同時配置兩個HBase集群，其中一個為主集群，負責接收所有的寫操作。從集群不斷從主集群同步數據，但盡可讀取。類似於關系型數據庫中的讀寫分離。

　　集群間同步采用主集群推送方式進行，推送的過程：主集群節點進行flush時，向從集群某個節點發送同步通知，從集群節點獲取通知后，讀取主集群相應節點上的WAL預寫日志，在本地重建數據。

　　主集群節點發送通知之后，會在Zookeeper中記錄已備份WAL的偏移量，使得從集群可以確認備份的位置。如果主集群節點發現之前聯系的從集群節點無響應，則會更換另一個從集群節點再次發出備份通知，並回滾WAL的偏移量記錄信息。集群復制原理：

    同步工作是異步進行的，即主從集群之間只能保證數據的最終一致性。

配置集群間復制的基本方法：

1、要確保兩個集群之間的網絡互通。
2、在從集群建立同名、同結構（具有相同列族）的表。
3、主集群的hbase-site.xml中配置hbase.replication參數為true，即設置為允許跨集群同步。
4、在主節點集群的HBase Shell中修改表結構。

disable 'Test' //Test為表名
alter 'Test',{NAME =>'basic',REPLICAITON_SCOPE => '1'} //列族basic,集群復制的配置是針對列族的，REPLICATION_SCOPE屬性不能在建表時設置，只能通過alter命令設置。
enable 'Test'

5、在主集群節點HBase Shell中執行命令。

add_peer '1',"slave-zk-1,slave-zk-2,...:2181:/hbase"

　　讓主集群看到從集群的Zookeeper地址、端口、HBase使用的Znode入口（默認為/hbase）等。主從集群可以使用兩套Zookeeper，也可以使用同一套Zookeeper，但使用同一套Zookeeper時，主從集群的Znode入口必須是不同的，即hbase-site.xml中zookeeper.znode.parent配置內容是不同的，一般體現在/hbase這一部分不同。
　　使用編號1（peerid）可以用來完成復制同步的監控管理：

remove_peer '1'
enable_peer '1'
disable_peer '1'

此外，通過list_peers命令，可以查看復制同步關系列表。

通過stop_replication和start_replication命令用來控制主集群上所有的復制同步啟停。

6、HBase的擴展

HBase存在的問題：

1. 分布式數據處理和統計問題
2. 二級索引問題
3. 時序數據存儲問題
4. 提供類似關系型數據庫的功能和操作方式

6.1 協處理器機制（Coprocessor）

　　協處理器是一個類似於MapReduce的並行處理組件，其基本思想：移動計算的代碼遠比移動數據低。通過把子任務（類似Map）代碼分發到各個Regionserver上，讓子任務獨立地在各個服務器、表或分區上運行，來實現對數據的監控和操作。

　　協處理器機制提供了一套編程框架，用戶可以非常靈活地編寫自動給你一的Coprocessor任務，並且用戶還可以級聯使用多個Corprocessor組件，完成更復雜的自定義功能。

　　協處理器分別是Observer和Endpoint兩種模式，Observer模式就如同關系型數據庫中的觸發器，Endpoint模式就如同關系型數據庫中的存儲過程。Observer可以分給三種類型，分別為RegionObserver、MasterObserver、WALObserver。其中Regionserver是region上的觸發器，MasterObserver 是master服務器的觸發器，而WALObserver用於預寫日志的觸發器。

應用協處理器機制可以極大地擴展HBase的能力，舉例來說，用戶可以通過三種思路，以自動開發協處理器的方式建立二級索引。

• 1.基於WALObserver在一個索引表內生成索引，通過攔截預寫日志的寫入操作，把相應的鍵值對更新信息存儲到索引表中。
• 2.基於RegionObserver在同一個分區內維護一個索引列族，通過攔截分區的put、delete等操作，提取相應信息存儲到同一個分區的索引列族中，這種方式的索引是局部索引，不支持全局排序。
• 3.基於RegionObserver在一個索引表內生成索引，通過攔截put、delete等操作，提取相應數據更新信息存儲到索引表中。

HBase中已經實現了集合函數組件、多行事務組件、多行條件刪除組件等基於協處理器框架的組件。如phoenix、openTSDB等獨立的HBase擴展軟件也通過利用協處理器機制，實現更豐富的功能。

6.2 基於HBase的分布式處理

HBase只提供了數據管理和查詢功能，如果對數據進行統計、聚合等操作則需要借助分布式處理架構。

大數據領域常見的分布式處理架構：MapReduce、Spark等的輸入輸出一般都是HDFS上的文件，但也可設置為從HBase表讀取數據，或將數據寫入HBase.

1.基於MapReduce的分布式處理

　　HBase中的數據導入導出、行計數操作等都是調用MapReduce實現的。

　　用戶也可以自定義開發MapReduce程序，指示器連接HBase的Zookeeper地址，並獲得目標表格和分區信息。通過在MapReduce代碼中嵌入scan和put的方法，實現並行從HBase表中查詢數據，或將數據並行寫入到HBase表中。

2.基於Spark的分布式處理

　　Spark是一種新興的開源分布式處理框架，其性能優於MapReduce。

3.與Hive工具聯合使用

　　Hive是基於Hadoop系統的分布式數據倉庫，能夠提供增刪改查等數據操作。它將結構化的數據文件映射為一張數據庫表，並提供簡單的類似SQL中語法的HiveQL語言進行數據查詢。Hive通過對Hive QL語句進行語法分析、編譯、優化、生成查詢計划、最后大部分任務轉換為MapReduce或Tez任務，小部分Hive QL語句直接進行處理，不轉化為MapReduce。

　　Hive和HBase可以很方便的結合使用，其方式是使用Hive自帶的hive-hbase-handler組件把hive和hbase結合起來。將數據存儲到HBase,在進行復雜數據處理時，通過使用hive對hive QL語句進行操作，把Hive QL命令轉化為操作Hbase指令或MapReduce任務，實現數據的寫入、查詢或其他復雜操作。

 　　Hive工具提供了類似HBase Shell的命令行環境，通過下面的命令可以在啟動Hive的Shell環境時，建立和HBase主節點或Zookeeper集群中的META表的聯系：

//在Hive的shell環境下執行Hive QL語句
hive --hiveconfhbase.master=nodel:16000
hive --hiveconfhbase.zookeeper.quorum=node1

CREATE TABLE thehivetable(key int,value string) STORED BY 'org.apache.hadoop.hive.hbase.HBaseStorageHandler'  
WITH SERDEPROPERTIES ("hbase.columns.mapping"=":key,cf1:val") TBLPROPERTIES ("hbase.table.name" = "thehbasetable ");
//建立一個Hive-HBase聯合表，關鍵參數：STORED BY 'org.apache.hadoop.hive.hbase.HBaseStorageHandler'，指明了存儲方式。
//該表在Hive中的表名為thehivetable,可以看做一個普通的面向行的表（即類似關系型數據庫表）。具有key 和 value兩個列，前者為整型，后者為字符串類型。
//hbase的表名為thehbasetable,將thehivetable表中的第一列映射為行鍵，第二列映射列族cf1中的列val

//在Hive的Shell，通過下面命令看到thehivetable表，描述其結構
showtables
describethehivetable

//在hive中刪除表,hbase的表也會被刪掉
droptablethehivetable

//在hbase的shell命令
list
desc 'thehbasetable'