zookeeper和HBASE總結

時間 2019-11-24

標籤 zookeeper hbase 總結欄目 Zookeeper 简体版

原文原文鏈接

zookeeper快速上手
1. zookeeper的基本功能和應用場景

1. zookeeper的總體運行機制

1. zookeeper的數據存儲機制
  1. 數據存儲形式

zookeeper中對用戶的數據採用kv形式存儲node

只是zk有點特別：mysql

key：是以路徑的形式表示的，那就覺得着，各key之間有父子關係，好比redis

/ 是頂層key算法

用戶建的key只能在/ 下做爲子節點，好比建一個key： /aa 這個key能夠帶value數據sql

也能夠建一個key： /bbmongodb

也能夠建key： /aa/xxshell

zookeeper中，對每個數據key，稱做一個znode數據庫

綜上所述，zk中的數據存儲形式以下：api

1. 1. znode類型

zookeeper中的znode有多種類型：緩存

PERSISTENT 持久的：建立者就算跟集羣斷開聯繫，該類節點也會持久存在與zk集羣中
EPHEMERAL 短暫的：建立者一旦跟集羣斷開聯繫，zk就會將這個節點刪除
SEQUENTIAL 帶序號的：這類節點，zk會自動拼接上一個序號，並且序號是遞增的

組合類型：

PERSISTENT ：持久不帶序號

EPHEMERAL ：短暫不帶序號

PERSISTENT 且 SEQUENTIAL ：持久且帶序號

EPHEMERAL 且 SEQUENTIAL ：短暫且帶序號

1. zookeeper的集羣部署
上傳安裝包到集羣服務器
解壓
修改配置文件

進入zookeeper的安裝目錄的conf目錄

cp zoo_sample.cfg zoo.cfg

vi zoo.cfg

# The number of milliseconds of each tick

tickTime=2000

initLimit=10

syncLimit=5

dataDir=/root/zkdata

clientPort=2181

#autopurge.purgeInterval=1

server.1=hdp20-01:2888:3888

server.2=hdp20-02:2888:3888

server.3=hdp20-03:2888:3888

對3臺節點，都建立目錄 mkdir /root/zkdata

對3臺節點，在工做目錄中生成myid文件，但內容要分別爲各自的id： 1,2,3

hdp20-01上： echo 1 > /root/zkdata/myid

hdp20-02上： echo 2 > /root/zkdata/myid

hdp20-03上： echo 3 > /root/zkdata/myid

從hdp20-01上scp安裝目錄到其餘兩個節點

scp -r zookeeper-3.4.6/ hdp20-02$PWD

scp -r zookeeper-3.4.6/ hdp20-03:$PWD

啓動zookeeper集羣

zookeeper沒有提供自動批量啓動腳本，須要手動一臺一臺地起zookeeper進程

在每一臺節點上，運行命令：

bin/zkServer.sh start

啓動後，用jps應該能看到一個進程：QuorumPeerMain

可是，光有進程不表明zk已經正常服務，須要用命令檢查狀態：

bin/zkServer.sh status

能看到角色模式：爲leader或follower，即正常了。

1. zookeeper的命令行客戶端操做
  1. zookeeper的數據存儲形式：
zookeeper中存儲數據的基本形式爲： key ， value
zookeeper中的key是用路徑表示的：

/aa : 88888

/aa/bb : "xxoo"

/aa/cc : "edu360"

/tt: 9898

每個key-value稱爲一個znode（zookeeper數據節點）

zookeeper中的數據節點有4種類型：

持久節點：客戶端一旦創建，zk會持久保存，除非有客戶端手動刪除
短暫節點：建立這個節點的客戶端一旦斷開與zookeeper集羣的聯繫，zookeeper集羣就會自動將該節點刪除
帶序號的節點：在同一個父節點下，建帶序號的子節點，zk會自動給客戶端指定的子節點名後拼接一個自增的序號
不帶序號的節點：

上述4中類型，能夠有如下組合類型：

持久-帶序號

持久-不帶序號

短暫-帶序號

短暫-不帶序號

1. 數據管理功能：

建立節點： create /aaa 'ppppp'

查看節點下的子節點： ls /aaa

獲取節點的value： get /aaa

修改節點的value： set /aaa 'mmmmm'

刪除節點：rmr /aaa

1. 1. 數據監聽功能：

ls /aaa watch

## 查看/aaa的子節點的同時，註冊了一個監聽「節點的子節點變化事件」的監聽器

get /aaa watch

## 獲取/aaa的value的同時，註冊了一個監聽「節點value變化事件」的監聽器

注意：註冊的監聽器在正常收到一次所監聽的事件後，就失效

1. zookeeper圖形化客戶端插件

在Eclipse環境下安裝ZooKeeper狀態查看相關的插件步驟以下：

Step 1. 在 Eclipse 菜單打開Help -> Install New Software…
Step 2. 添加 url http://www.massedynamic.org/eclipse/updates/
Step 3. 選擇插件並安裝運行
Step 4. 在 Eclipse 菜單打開Window->Show View->Other…->ZooKeeper 3.2.2。
Step 5. 鏈接ZK 輸入正在運行的ZK server 地址和端口

鏈接成功後就就能夠在Eclipse裏查看ZK Server裏的節點信息。以下所示：

HBASE
1. 1/ 什麼是HBASE
  1. 概念特性

HBASE是一個數據庫----能夠提供數據的實時隨機讀寫

HBASE與mysql、oralce、db二、sqlserver等關係型數據庫不一樣，它是一個NoSQL數據庫（非關係型數據庫）

Hbase的表模型與關係型數據庫的表模型不一樣：
Hbase的表沒有固定的字段定義；
Hbase的表中每行存儲的都是一些key-value對
Hbase的表中有列族的劃分，用戶能夠指定將哪些kv插入哪一個列族
Hbase的表在物理存儲上，是按照列族來分割的，不一樣列族的數據必定存儲在不一樣的文件中
Hbase的表中的每一行都固定有一個行鍵，並且每一行的行鍵在表中不能重複
Hbase中的數據，包含行鍵，包含key，包含value，都是byte[ ]類型，hbase不負責爲用戶維護數據類型
HBASE對事務的支持不好

HBASE相比於其餘nosql數據庫(mongodb、redis、cassendra、hazelcast)的特色：

Hbase的表數據存儲在HDFS文件系統中

從而，hbase具有以下特性：存儲容量能夠線性擴展；數據存儲的安全性可靠性極高！

1. 1. 應用場景舉例

1. 2/ 安裝HBASE

HBASE是一個分佈式系統

其中有一個管理角色： HMaster(通常2臺，一臺active，一臺backup)

其餘的數據節點角色： HRegionServer(不少臺，看數據容量)

1. 1. 安裝準備：

首先，要有一個HDFS集羣，並正常運行； regionserver應該跟hdfs中的datanode在一塊兒

其次，還須要一個zookeeper集羣，並正常運行

而後，安裝HBASE

角色分配以下：

Hdp01: namenode datanode regionserver hmaster zookeeper

Hdp02: datanode regionserver zookeeper

Hdp03: datanode regionserver zookeeper

1. 1. 安裝步驟：
    1. 1.安裝zookeeper
    2. 2.安裝hbase

解壓hbase安裝包

修改hbase-env.sh

export JAVA_HOME=/root/apps/jdk1.7.0_67

export HBASE_MANAGES_ZK=false

修改hbase-site.xml

<name>hbase.rootdir</name>

<value>hdfs://hdp01:9000/hbase</value>

</property>

<name>hbase.cluster.distributed</name>

</property>

<name>hbase.zookeeper.quorum</name>

</property>

</configuration>

修改 regionservers

hdp01

hdp02

hdp03

啓動hbase集羣：

bin/start-hbase.sh

啓動完後，還能夠在集羣中找任意一臺機器啓動一個備用的master

bin/hbase-daemon.sh start master

新啓的這個master會處於backup狀態

啓動hbase的命令行客戶端

bin/hbase shell

Hbase> list // 查看錶

Hbase> status // 查看集羣狀態

Hbase> version // 查看集羣版本

1. HBASE表模型

hbase的表模型跟mysql之類的關係型數據庫的表模型差異巨大

hbase的表模型中有：行的概念；但沒有字段的概念

行中存的都是key-value對，每行中的key-value對中的key能夠是各類各樣，每行中的key-value對的數量也能夠是各類各樣

1. 1. hbase表模型的要點：
一個表，有表名
一個表能夠分爲多個列族（不一樣列族的數據會存儲在不一樣文件中）
表中的每一行有一個「行鍵rowkey」，並且行鍵在表中不能重複
表中的每一對kv數據稱做一個cell
hbase能夠對數據存儲多個歷史版本（歷史版本數量可配置）
整張表因爲數據量過大，會被橫向切分紅若干個region（用rowkey範圍標識），不一樣region的數據也存儲在不一樣文件中

hbase會對插入的數據按順序存儲：

要點一：首先會按行鍵排序

要點二：同一行裏面的kv會按列族排序，再按k排序

1. 1. hbase的表中能存儲什麼數據類型

hbase中只支持byte[]

此處的byte[] 包括了： rowkey,key,value,列族名,表名

1. 1. HBASE表的物理存儲結構

1. 3/ hbase命令行客戶端操做
  1. 1. 建表：

create 't_user_info','base_info','extra_info'

表名列族名列族名

1. 1. 1. 插入數據：

hbase(main):011:0> put 't_user_info','001','base_info:username','zhangsan'

0 row(s) in 0.2420 seconds

hbase(main):012:0> put 't_user_info','001','base_info:age','18'

0 row(s) in 0.0140 seconds

hbase(main):013:0> put 't_user_info','001','base_info:sex','female'

0 row(s) in 0.0070 seconds

hbase(main):014:0> put 't_user_info','001','extra_info:career','it'

0 row(s) in 0.0090 seconds

hbase(main):015:0> put 't_user_info','002','extra_info:career','actoress'

0 row(s) in 0.0090 seconds

hbase(main):016:0> put 't_user_info','002','base_info:username','liuyifei'

0 row(s) in 0.0060 seconds

1. 1. 1. 查詢數據方式一：scan 掃描

hbase(main):017:0> scan 't_user_info'

ROW COLUMN+CELL

001 column=base_info:age, timestamp=1496567924507, value=18

001 column=base_info:sex, timestamp=1496567934669, value=female

001 column=base_info:username, timestamp=1496567889554, value=zhangsan

001 column=extra_info:career, timestamp=1496567963992, value=it

002 column=base_info:username, timestamp=1496568034187, value=liuyifei

002 column=extra_info:career, timestamp=1496568008631, value=actoress

2 row(s) in 0.0420 seconds

1. 1. 1. 查詢數據方式二：get 單行數據

hbase(main):020:0> get 't_user_info','001'

COLUMN CELL

base_info:age timestamp=1496568160192, value=19

base_info:sex timestamp=1496567934669, value=female

base_info:username timestamp=1496567889554, value=zhangsan

extra_info:career timestamp=1496567963992, value=it

4 row(s) in 0.0770 seconds

1. 1. 1. 刪除一個kv數據

hbase(main):021:0> delete 't_user_info','001','base_info:sex'

0 row(s) in 0.0390 seconds

刪除整行數據：

hbase(main):024:0> deleteall 't_user_info','001'

0 row(s) in 0.0090 seconds

hbase(main):025:0> get 't_user_info','001'

COLUMN CELL

0 row(s) in 0.0110 seconds

1. 1. 1. 刪除整個表：

hbase(main):028:0> disable 't_user_info'

0 row(s) in 2.3640 seconds

hbase(main):029:0> drop 't_user_info'

0 row(s) in 1.2950 seconds

hbase(main):030:0> list

TABLE

0 row(s) in 0.0130 seconds

=> []

1. 4/ Hbase重要特性--排序特性（行鍵）

插入到hbase中去的數據，hbase會自動排序存儲：

排序規則：首先看行鍵，而後看列族名，而後看列（key）名；按字典順序

Hbase的這個特性跟查詢效率有極大的關係

好比：一張用來存儲用戶信息的表，有名字，戶籍，年齡，職業....等信息

而後，在業務系統中常常須要：

查詢某個省的全部用戶

常常須要查詢某個省的指定姓的全部用戶

思路：若是能將相同省的用戶在hbase的存儲文件中連續存儲，而且能將相同省中相同姓的用戶連續存儲，那麼，上述兩個查詢需求的效率就會提升！！！作法：將查詢條件拼到rowkey內

1. 5/ HBASE客戶端API操做
  1. DDL操做
建立一個鏈接

Connection conn = ConnectionFactory.createConnection(conf);

二、拿到一個DDL操做器：表管理器admin

Admin admin = conn.getAdmin();

三、用表管理器的api去建表、刪表、修改表定義

admin.createTable(HTableDescriptor descriptor);

1. 1. DML操做
1. 6 HBASE運行原理
  1. 組件結構圖

1. 1. MASTER職責
管理HRegionServer，實現其負載均衡。
管理和分配HRegion，好比在HRegion split時分配新的HRegion；在HRegionServer退出時遷移其負責的HRegion到其餘HRegionServer上。
Admin職能

建立、刪除、修改Table的定義。實現DDL操做（namespace和table的增刪改，column familiy的增刪改等）。

管理namespace和table的元數據（實際存儲在HDFS上）。
權限控制（ACL）。
監控集羣中全部HRegionServer的狀態(經過Heartbeat和監聽ZooKeeper中的狀態)。
1. 1. REGION SERVER職責
管理本身所負責的region數據的讀寫。
讀寫HDFS，管理Table中的數據。
Client直接經過HRegionServer讀寫數據（從HMaster中獲取元數據，找到RowKey所在的HRegion/HRegionServer後）。

1. 1. Zookeeper集羣所起做用
存放整個HBase集羣的元數據以及集羣的狀態信息。
實現HMaster主從節點的failover。

注： HMaster經過監聽ZooKeeper中的Ephemeral節點(默認：/hbase/rs/*)來監控HRegionServer的加入和宕機。

在第一個HMaster鏈接到ZooKeeper時會建立Ephemeral節點(默認：/hbasae/master)來表示Active的HMaster，其後加進來的HMaster則監聽該Ephemeral節點

若是當前Active的HMaster宕機，則該節點消失，於是其餘HMaster獲得通知，而將自身轉換成Active的HMaster，在變爲Active的HMaster以前，它會在/hbase/masters/下建立本身的Ephemeral節點。

1. 1. HBASE讀寫數據流程

1、在HBase 0.96之前，HBase有兩個特殊的Table：-ROOT-和.META. 用來記錄用戶表的rowkey範圍所在的的regionserver服務器；

於是客戶端讀寫數據時須要經過3次尋址請求來對數據所在的regionserver進行定位，效率低下；

二、而在HBase 0.96之後去掉了-ROOT- Table，只剩下這個特殊的目錄表叫作Meta Table(hbase:meta)，它存儲了集羣中全部用戶HRegion的位置信息，而ZooKeeper的節點中(/hbase/meta-region-server)存儲的則直接是這個Meta Table的位置，而且這個Meta Table如之前的-ROOT- Table同樣是不可split的。這樣，客戶端在第一次訪問用戶Table的流程就變成了：

從ZooKeeper(/hbase/meta-region-server)中獲取hbase:meta的位置（HRegionServer的位置），緩存該位置信息。
從HRegionServer中查詢用戶Table對應請求的RowKey所在的HRegionServer，緩存該位置信息。
從查詢到HRegionServer中讀取Row。

注：客戶會緩存這些位置信息，然而第二步它只是緩存當前RowKey對應的HRegion的位置，於是若是下一個要查的RowKey不在同一個HRegion中，則須要繼續查詢hbase:meta所在的HRegion，然而隨着時間的推移，客戶端緩存的位置信息愈來愈多，以致於不須要再次查找hbase:meta Table的信息，除非某個HRegion由於宕機或Split被移動，此時須要從新查詢而且更新緩存。

1. 1. hbase:meta表

hbase:meta表存儲了全部用戶HRegion的位置信息：

Rowkey：tableName,regionStartKey,regionId,replicaId等；

info列族：這個列族包含三個列，他們分別是：

info:regioninfo列：

regionId,tableName,startKey,endKey,offline,split,replicaId；

info:server列：HRegionServer對應的server:port；

info:serverstartcode列：HRegionServer的啓動時間戳。

1. 1. REGION SERVER內部機制

WAL即Write Ahead Log，在早期版本中稱爲HLog，它是HDFS上的一個文件，如其名字所表示的，全部寫操做都會先保證將數據寫入這個Log文件後，纔會真正更新MemStore，最後寫入HFile中。WAL文件存儲在/hbase/WALs/${HRegionServer_Name}的目錄中

BlockCache是一個讀緩存，即「引用局部性」原理（也應用於CPU，分空間局部性和時間局部性，空間局部性是指CPU在某一時刻須要某個數據，那麼有很大的機率在一下時刻它須要的數據在其附近；時間局部性是指某個數據在被訪問過一次後，它有很大的機率在不久的未來會被再次的訪問），將數據預讀取到內存中，以提高讀的性能。

HRegion是一個Table中的一個Region在一個HRegionServer中的表達。一個Table能夠有一個或多個Region，他們能夠在一個相同的HRegionServer上，也能夠分佈在不一樣的HRegionServer上，一個HRegionServer能夠有多個HRegion，他們分別屬於不一樣的Table。HRegion由多個Store(HStore)構成，每一個HStore對應了一個Table在這個HRegion中的一個Column Family，即每一個Column Family就是一個集中的存儲單元，於是最好將具備相近IO特性的Column存儲在一個Column Family，以實現高效讀取(數據局部性原理，能夠提升緩存的命中率)。HStore是HBase中存儲的核心，它實現了讀寫HDFS功能，一個HStore由一個MemStore 和0個或多個StoreFile組成。

MemStore是一個寫緩存(In Memory Sorted Buffer)，全部數據的寫在完成WAL日誌寫後，會寫入MemStore中，由MemStore根據必定的算法將數據Flush到地層HDFS文件中(HFile)，一般每一個HRegion中的每一個 Column Family有一個本身的MemStore。

HFile(StoreFile) 用於存儲HBase的數據(Cell/KeyValue)。在HFile中的數據是按RowKey、Column Family、Column排序，對相同的Cell(即這三個值都同樣)，則按timestamp倒序排列。

FLUSH詳述

每一次Put/Delete請求都是先寫入到MemStore中，當MemStore滿後會Flush成一個新的StoreFile(底層實現是HFile)，即一個HStore(Column Family)能夠有0個或多個StoreFile(HFile)。

當一個HRegion中的全部MemStore的大小總和超過了hbase.hregion.memstore.flush.size的大小，默認128MB。此時當前的HRegion中全部的MemStore會Flush到HDFS中。

當全局MemStore的大小超過了hbase.regionserver.global.memstore.upperLimit的大小，默認40％的內存使用量。此時當前HRegionServer中全部HRegion中的MemStore都會Flush到HDFS中，Flush順序是MemStore大小的倒序（一個HRegion中全部MemStore總和做爲該HRegion的MemStore的大小仍是選取最大的MemStore做爲參考？有待考證），直到整體的MemStore使用量低於hbase.regionserver.global.memstore.lowerLimit，默認38%的內存使用量。