《HBase 不睡覺書》是一本讓人看了不會睡着的 HBase 技術書籍,寫的很是不錯,爲了加深記憶,決定把書中重要的部分整理成讀書筆記,便於後期查閱,同時但願爲初學 HBase 的同窗帶來一些幫助。java
本文不會詳細介紹 HBase 的按照過程,主要介紹一些安裝的注意事項。node
(1)切換到root用戶,而後創建hadoop用戶。算法
# useradd hadoop
# passwd hadoop
複製代碼
(2)添加 hadoop 到sudoers 列表。shell
# chmod u+w /etc/sudoers
# vi u+w /etc/sudoers
-- 添加下面的代碼 --
hadoop ALL=NOPASSWD:ALL
複製代碼
切換到 hadoop 用戶,並編輯 ~/.bashrc
文件,添加如下環境變量:apache
export HADOOP_HOME=/usr/local/hadoop
export HADOOP_PREFIX=$HADOOP_HOME
export HADOOP_MAPRED_HOME=$HADOOP_HOME
expOrt HADOOP_COMMON_HOME=$HADOOP_HOME
export HADOOP_HDES_HOME=$HADOOP_HOME
eXpOrt YARN_HOME=$HADOOP_HOME
export HADOOP_COMMON_LIB_NATIVE_DIR=$HADOOP_HOME/lib/native
export PATH=$PATH:$HADOOP_HOME/sbin:$HADOOP_HOME/bin
export HADOOP_INSTALL=$HADOOP_HOME
複製代碼
有的教程提到配置
HADOOP_HOME
,而官方教程說是配置HADOOP_PREFIX
,那麼究竟 Hadoop 是用哪一個環境變量來標定 Hadoop 的程序文件夾位置?實際上,早期 Hadoop 主要用HADOOP_HOME
來標定程序文件夾位置,後來改爲了HADOOP_PREFIX
,因此爲了兼容性,乾脆都設置上,而且保持同樣的值吧。編程
編輯 hadoop 的 $HADOOP_PREFIX/etc/hadoop/hadoop-env.sh
文件,在文件開頭添加如下變量:bash
export HADOOP_NAMENODE_OPTS="-Xms1024m -Xmx1024m -XX:+UseParallelGC"
export HADOOP_DATANODE_OPTS="-Xms1024m-Xmx1024m"
export HADOOP_LOG_DIR=/data/1ogs/hadoop
複製代碼
因爲在僞分佈式和徹底分佈式的狀況下 HBase 會直接在 HDFS 的根目錄下創建 /hbase
文件夾,在根目錄下要創建文件夾須要超級用戶組權限。超級用戶組權限由 hdfs-site.xml
中的 dfs.permissions.supergroup
來定義,若是你不設定這個參數,默認的超級用戶組組名是 supergroup。假定你們都沒有設定 dfs.permissions.supergroup
屬性,如今須要把 hbase 添加到 Linux 的 supergroup 組去。CentOS 系統可執行下面的語句:架構
# groupadd supergroup
# groupmems -g supergroup -a hbase
複製代碼
HBase 自帶了一個 ZooKeeper,並且會默認啓動本身的 ZooKeeper,若是 HBase 用的是本身的 ZooKeeper,那你在 jps 中看到的 ZooKeeper 名字是 HQuorumPeer。若是你使用的是外部的 ZooKeeper 集羣,那麼它的名字叫 QuorumPeer 或者 QuorumPeerMain。app
是否開啓自帶的 ZooKeeper 由 conf/hbase-env.sh
中定義的 HBASE_MANAGES_ZK
變量定義。這個變量默認爲 true,若是不想使用自帶的 ZK 你能夠將值改成 false。分佈式
# Tell HBase whether it should manage it's own instance of Zookeeper or not.
export HBASE_MANAGES_ZK=false
複製代碼
HADOOP_CONF_DIR
添加到 HBASE_CLASSPATH
中(推薦);hdfs-site.xml
的軟連接到 hbase/conf
下;數據塊編碼主要是針對 Key/Value 中的 Key 進行編碼,減小 Key 存儲所佔用的空間,由於不少 Key 的前綴都是重複的。
假設有這樣一個表,它的行鍵(Rowkey)、列族(Column Family)、列(Column)的定義規則是:行鍵以 myrow 前綴打頭,後面跟上數字來組成行鍵,好比 myrow00一、myrow00二、myrow003 等,擁有一個列族叫 mycf,mycf 列族中有 5 個列,分別名叫 col一、col二、col三、col四、col5,它們的存儲結構以下所示。
能夠看到這麼多行的 Key 其實有很大一部分的字符是重複的,若是咱們只存儲遞進值,就能夠避免存儲重複的前綴,這就是前綴編碼(Prefix)。
若是使用前綴編碼做爲數據塊編碼方式,那麼它只會存儲第一個 Key 的完整字符串,後面的 key 只存儲跟第一個 key 的差別字符,從新編碼過的數據以下所示。
能夠看到 Key 的存儲空間極大地縮小了,編碼後的 Key 總存儲空間只用了 37 個字符,而未編碼前是 180 個字符,空間佔用減小了 79%。
差別編碼(Diff)比前綴編碼更進一步,差別編碼甚至把如下字段也一塊兒進行了差別化的編碼。
採用了差別編碼後的 KeyValue 結構爲:
前綴長度(Prefix Len)字段表示當前的 Key 跟與之相比的 Key 的相同前綴的長度。
它是一個二進制數。好比,5=11,7=111。它的做用就是記錄當前這個 KeyValue 跟上一個 KeyValue 之間有哪幾個字段有差別,如下是產生標誌位的部分規則:
只須要把 flag 跟標誌碼作一個與(&)計算就能夠快速地知道這個字段跟上一個字段的差別在哪裏,即相同的位置標記爲 1。
這樣編碼幾乎是最大程度地對數據進行了編碼壓縮,可是這個編碼方式默認是不啓用的。爲何?由於太慢了,每條數據都要這樣計算一下,獲取數據的速度很慢。除非你要追求極致的壓縮比,可是不考慮讀取性能的時候可使用它,好比你想要把這部分數據看成歸檔數據的時候,能夠考慮使用差別編碼。
快速差別編碼(Fast Diff)借鑑了 Diff 編碼的思路,也考慮到了差別編碼速度慢的致命缺陷。快速差別編碼的 KeyValue 結構跟差別編碼如出一轍,只有 Flag 的存儲規則不同,而且優化了 Timestamp 的計算。Fast Diff 的實現比 Diff 更快,也是比較推薦的算法。
若是你想用差別算法來壓縮你的數據,那麼最好用快速差別編碼,不過這個「快速」只是相對原本的差別算法而言的,因爲仍是有不少計算過程存在,因此快速差別算法的速度依然屬於比較慢的。
前綴樹編碼(Prefix Tree)是前綴算法的變體,它是 0.96 版本以後才加入的特性。前綴樹編碼最大的做用就是提升了隨機讀的能力,可是其複雜的算法相對地下降了寫入的速度,消耗了更多的 CPU 資源,使用時須要在資源的消耗和隨機讀的性能之間進行取捨。
綜上,前綴編碼與快速差別編碼(Kylin 默認使用該方式)應該算是比較經常使用的兩種數據塊編碼方式了。
壓縮器的做用是能夠把 HBase 的數據按壓縮的格式存儲,這樣能夠更節省磁盤空間。固然這徹底是可選的,不過推薦你們仍是安裝 Snappy 壓縮器,這是 HBase 官方目前排名比較高的壓縮器。
能夠經過修改列族描述啓用壓縮器:
hbase> alter 'mytable',{NAME =>'mycf',COMPRESSION=>'snappy'}
複製代碼
因爲 Hadoop 的共享庫(shared Library)擁有不少資源,包括壓縮器,因此能夠直接將它們用在 HBase中。能夠經過如下命令檢查 Hadoop 目前有用的壓縮器:
$ hbase --config $HBASE_HOME/conf org.apache.hadoop.util.NativeLibraryChecker
複製代碼
若是遇到下面的報錯信息,則表示 NativeLibraryChecker 沒法讀取到 Hadoop 的 native 庫。
util.NativeCodeLoader: Unable to load native-hadoop library for your platform...
using builtin-java classes where applicable
Native library checking:
hadoop: false
zlib: false
snappy: false
1z4: false
bzip2: false
複製代碼
常規的解決方法是在 hbase-env.sh
加入下面的語句:
export HBASE_LIBRARY_PATH=Hadoop的Native包所在路徑
複製代碼
Snappy 是 Google 開發的壓縮器,有如下特色:
安裝完成後,須要在 hbase-env.sh
加入下面的語句:
export HBASE_LIBRARY_PATH=編碼器so文件所在路徑:$HBASE_LIBRARY_PATH
複製代碼
通常狀況下若是不是對速度要求很低的歸檔文件,通常不建議使用GZ壓縮器,GZ 壓縮器的特色:
Java 已經自帶了一個 GZ 壓縮器,因此 GZ 壓縮器雖然不是性能最好的,可是倒是最容易使用的,你什麼都不須要設置,只須要直接修改列族的 COMPRESSION 屬性爲 GZ 便可。
alter test1',{NAME=>'mycf',COMPRESSION=>'GZ'} 複製代碼
在 Snappy 推出以前,LZO 是 HBase 官方推薦的壓縮算法。主要緣由是 GZ 壓縮的速度太慢了,而 LZO 正好就是專一於速度,因此相比起來使用 LZO 會比 GZ 更好,不過自從 Snappy 出了以後,LZO 就沒有什麼優點了。
LZ4 的特色:
LZ4 比 Snappy 更快,LZ4 壓縮器已經集成在 libhadoop.so 中,因此只須要讓 HBase 加載Hadoop 自帶的原生庫便可。
使用數據塊編碼仍是壓縮器取決於你存儲的數據中是限定符佔的空間較大仍是值佔的空間較大。
最開始學習 HBase 的時候,大多都是直接使用 Java API 去進行表操做,不多去關注 HBase 安裝相關的內容;經過上述的介紹,至少數據塊編碼和壓縮器在之後建表時候仍是能夠考慮的,官方推薦的 Snappy 壓縮器以及前綴編碼都是即簡單又有效的調優方法。
Any Code,Code Any!
掃碼關注『AnyCode』,編程路上,一塊兒前行。