《HBase 不睡覺》第二章 - 讓 HBase 跑起來

《HBase 不睡覺書》是一本讓人看了不會睡着的 HBase 技術書籍,寫的很是不錯,爲了加深記憶,決定把書中重要的部分整理成讀書筆記,便於後期查閱,同時但願爲初學 HBase 的同窗帶來一些幫助。java

目錄

本文不會詳細介紹 HBase 的按照過程,主要介紹一些安裝的注意事項。node

1、小技巧

一、添加 hadoop 用戶並分配 sudo 權限

(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 環境變量設置

切換到 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-env.sh

編輯 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
複製代碼
  • JVM 運行的內存若是不設定佔用大小的話,要麼不夠,要麼就把機器的內存都佔滿了。只要用到 JVM 的地方都加入內存參數,至少內存多少本身內心有數,讓狀況可控。
  • 日誌文件路徑若是不設定的話,多半後期會遇到放日誌的分區滿了,各類奇怪故障層出不窮。

四、把 hbase 添加到 supergroup 組

因爲在僞分佈式和徹底分佈式的狀況下 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
複製代碼

六、HBase 讀取到 HDFS 的配置有三種方式

  • HADOOP_CONF_DIR 添加到 HBASE_CLASSPATH 中(推薦);
  • 把 HDFS 的配置文件複製一份到 HBase 的 conf 文件夾下,或者直接建一個 hdfs-site.xml 的軟連接到 hbase/conf下;
  • 把 HDFS 的幾個配置項直接寫到 hbase-site.xml 文件裏面去。

2、HBase 的基本架構

  • HBase 中有一個 Master 用來管理元數據,它就像 Hadoop 中的 namenode;
  • RegionServer 是用來存儲數據的,至關於 Hadoop 中的 datanode;
  • ZooKeeper 負責維護 HBase 的全部節點,若是 ZooKeeper 宕掉了,你一個節點都連不上;
  • 生產環境下的徹底部署模式是基於 HDFS 的,使用 HDFS 來存儲數據,可是在單機模式下 HBase 能夠直接使用普通文件系統來存儲數據;
  • 在使用中就算把 Master 關掉了,依舊能夠從 HBase 中讀取數據和寫入數據,只是不能建表或者修改表。這是由於客戶端讀取數據的時候只是跟 ZooKeeper 和 RegionServer 交互,因此,ZooKeeper 甚至比 Master 還重要。

HBase 的基本架構

3、啓用數據塊編碼

一、數據塊編碼

數據塊編碼主要是針對 Key/Value 中的 Key 進行編碼,減小 Key 存儲所佔用的空間,由於不少 Key 的前綴都是重複的。

假設有這樣一個表,它的行鍵(Rowkey)、列族(Column Family)、列(Column)的定義規則是:行鍵以 myrow 前綴打頭,後面跟上數字來組成行鍵,好比 myrow00一、myrow00二、myrow003 等,擁有一個列族叫 mycf,mycf 列族中有 5 個列,分別名叫 col一、col二、col三、col四、col5,它們的存儲結構以下所示。

原始編碼下的數據存儲格式

能夠看到這麼多行的 Key 其實有很大一部分的字符是重複的,若是咱們只存儲遞進值,就能夠避免存儲重複的前綴,這就是前綴編碼(Prefix)。

二、前綴編碼(Prefix)

若是使用前綴編碼做爲數據塊編碼方式,那麼它只會存儲第一個 Key 的完整字符串,後面的 key 只存儲跟第一個 key 的差別字符,從新編碼過的數據以下所示。

前綴編碼後的數據存儲格式

能夠看到 Key 的存儲空間極大地縮小了,編碼後的 Key 總存儲空間只用了 37 個字符,而未編碼前是 180 個字符,空間佔用減小了 79%。

三、差別編碼(Diff)

差別編碼(Diff)比前綴編碼更進一步,差別編碼甚至把如下字段也一塊兒進行了差別化的編碼。

  • 鍵長度(KeyLen);
  • 值長度(ValueLen);
  • 時間戳(Timestamp),也便是Version;
  • 類型(Type),也便是鍵類型。

採用了差別編碼後的 KeyValue 結構爲:

  • 1 byte:標誌位;
  • 1-5 bytes:Key 長度(KeyLen);
  • 1-5 bytes:Value 長度(ValLen);
  • 1-5 bytes:前綴長度(Prefix Len);
  • ... bytes:剩餘的部分;
  • ... bytes:真正的 Key 或者只是有差別的 key 後綴部分;
  • 1-8 bytes:時間戳(timestamp)或者時間戳的差別部分;
  • 1 byte:Key 類型(type);
  • ... bytes:值(value)。

前綴長度(Prefix Len)字段表示當前的 Key 跟與之相比的 Key 的相同前綴的長度。

差別編碼後的數據存儲格式

標誌位(Flag)

它是一個二進制數。好比,5=11,7=111。它的做用就是記錄當前這個 KeyValue 跟上一個 KeyValue 之間有哪幾個字段有差別,如下是產生標誌位的部分規則:

  • 若是當前 KeyValue 中的 KeyLen(Key的長度)跟上一個 KeyValue相等,則標誌碼爲 1。
  • 若是當前 KeyValue 中的 ValLen(Value長度)跟上一個 ValLen 相等,則標誌碼爲10。
  • 若是當前 KeyValue 中的 Type 跟上一個 Type 相等,則標誌碼爲100。

只須要把 flag 跟標誌碼作一個與(&)計算就能夠快速地知道這個字段跟上一個字段的差別在哪裏,即相同的位置標記爲 1

這樣編碼幾乎是最大程度地對數據進行了編碼壓縮,可是這個編碼方式默認是不啓用的。爲何?由於太慢了,每條數據都要這樣計算一下,獲取數據的速度很慢。除非你要追求極致的壓縮比,可是不考慮讀取性能的時候可使用它,好比你想要把這部分數據看成歸檔數據的時候,能夠考慮使用差別編碼。

四、快速差別編碼(Fast Diff)

快速差別編碼(Fast Diff)借鑑了 Diff 編碼的思路,也考慮到了差別編碼速度慢的致命缺陷。快速差別編碼的 KeyValue 結構跟差別編碼如出一轍,只有 Flag 的存儲規則不同,而且優化了 Timestamp 的計算。Fast Diff 的實現比 Diff 更快,也是比較推薦的算法。

若是你想用差別算法來壓縮你的數據,那麼最好用快速差別編碼,不過這個「快速」只是相對原本的差別算法而言的,因爲仍是有不少計算過程存在,因此快速差別算法的速度依然屬於比較慢的

五、前綴樹編碼(Prefix Tree)

前綴樹編碼(Prefix Tree)是前綴算法的變體,它是 0.96 版本以後才加入的特性。前綴樹編碼最大的做用就是提升了隨機讀的能力,可是其複雜的算法相對地下降了寫入的速度,消耗了更多的 CPU 資源,使用時須要在資源的消耗和隨機讀的性能之間進行取捨。

綜上,前綴編碼與快速差別編碼(Kylin 默認使用該方式)應該算是比較經常使用的兩種數據塊編碼方式了。

4、啓用壓縮器

一、壓縮器

壓縮器的做用是能夠把 HBase 的數據按壓縮的格式存儲,這樣能夠更節省磁盤空間。固然這徹底是可選的,不過推薦你們仍是安裝 Snappy 壓縮器,這是 HBase 官方目前排名比較高的壓縮器。

能夠經過修改列族描述啓用壓縮器:

hbase> alter 'mytable',{NAME =>'mycf',COMPRESSION=>'snappy'}
複製代碼

二、共享 Hadoop 內置的壓縮器

因爲 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 壓縮器

Snappy 是 Google 開發的壓縮器,有如下特色:

  • 快速:壓縮速度達到 250MB/s;
  • 穩定:已經用於 Google 多個產品長達數年;
  • 健壯:Snappy 的解壓器能夠保證在數據被損壞的時候也不會太糟;
  • 免費開源。

安裝完成後,須要在 hbase-env.sh 加入下面的語句:

export HBASE_LIBRARY_PATH=編碼器so文件所在路徑:$HBASE_LIBRARY_PATH
複製代碼

四、GZ 壓縮器

通常狀況下若是不是對速度要求很低的歸檔文件,通常不建議使用GZ壓縮器,GZ 壓縮器的特色:

  • GZ 壓縮器擁有最高的壓縮比;
  • 速度較慢,佔用較多CPU;
  • 安裝簡單。

Java 已經自帶了一個 GZ 壓縮器,因此 GZ 壓縮器雖然不是性能最好的,可是倒是最容易使用的,你什麼都不須要設置,只須要直接修改列族的 COMPRESSION 屬性爲 GZ 便可。

alter test1',{NAME=>'mycf',COMPRESSION=>'GZ'} 複製代碼

五、LZO 壓縮器

在 Snappy 推出以前,LZO 是 HBase 官方推薦的壓縮算法。主要緣由是 GZ 壓縮的速度太慢了,而 LZO 正好就是專一於速度,因此相比起來使用 LZO 會比 GZ 更好,不過自從 Snappy 出了以後,LZO 就沒有什麼優點了。

六、LZ4 壓縮器

LZ4 的特色:

  • 擁有低丟失率;
  • 速度很快,能夠達到400M/s每核。

LZ4 比 Snappy 更快,LZ4 壓縮器已經集成在 libhadoop.so 中,因此只須要讓 HBase 加載Hadoop 自帶的原生庫便可。

5、總結

使用數據塊編碼仍是壓縮器取決於你存儲的數據中是限定符佔的空間較大仍是值佔的空間較大。

  • 若是是限定符佔的空間較大,建議使用數據塊編碼。
  • 若是是值佔的空間較大,建議使用編碼器。

最開始學習 HBase 的時候,大多都是直接使用 Java API 去進行表操做,不多去關注 HBase 安裝相關的內容;經過上述的介紹,至少數據塊編碼和壓縮器在之後建表時候仍是能夠考慮的,官方推薦的 Snappy 壓縮器以及前綴編碼都是即簡單又有效的調優方法。


Any Code,Code Any!

掃碼關注『AnyCode』,編程路上,一塊兒前行。

相關文章
相關標籤/搜索