行版安裝配置與核心原理詳解)
簡介這是為Ambari 2.7.5編譯環(huán)境準備的大數(shù)據(jù)組件離線包之一面向手動搭建HDP 3.1.4平臺、或經(jīng)常編譯Ambari相關項目的開發(fā)與運維人員。由于官方源下載極慢提前將HBase 2.0.2.3.1.4.0-315二進制壓縮包打包分享可大幅縮短編譯前的依賴準備時間。整個壓縮包共412個文件大小約211.57MB內(nèi)部以jar庫文件、rb腳本、sh啟動與配置腳本為主同時包含少量xml配置、cmd命令文件及前端樣式資源覆蓋HBase運行所需的可執(zhí)行程序、類庫與配置文件。目前已有2191人學習使用適合在離線或弱網(wǎng)環(huán)境中部署HBase時直接引用。作者還同步整理了Hadoop、Grafana、Phoenix等配套大包便于一次性備齊Ambari編譯所需依賴減少因網(wǎng)絡中斷導致的重復下載。 拿到這個安裝包的時候大多數(shù)人第一反應是“這不就是個HBase的tar包嘛”。但如果你仔細看文件名里的2.0.2.3.1.4.0-315會發(fā)現(xiàn)事情沒那么簡單——這個版本號其實是HDP發(fā)行版的命名規(guī)則而不是Apache社區(qū)版的純版本號。也就是說你拿到的不是原生Apache HBase 2.0.2而是hortonworks打包、基于HBase 2.0.2內(nèi)核、附帶一堆平臺適配和bugfix的企業(yè)發(fā)行版二進制包。這篇文章我就從安裝配置、端口清單、核心原理到面試高頻考點把hbase-2.0.2.3.1.4.0-315-bin.tar.gz這個包一次講透。無論你是剛入行的大數(shù)據(jù)工程師還是準備面試的候選人這篇都能幫你在實際部署和原理理解上少走彎路。1. 拿到這個tar包先搞明白它到底是什么1.1 版本號里的秘密2.0.2.3.1.4.0-315怎么讀這個版本號可以拆成兩段看。第一段2.0.2是Apache HBase社區(qū)版本號表示內(nèi)核基于HBase 2.0.2。第二段3.1.4.0-315是HDPHortonworks Data Platform的版本號其中3.1.4是HDP的大版本0-315是build號。這種雙版本號命名在CDH和HDP這類發(fā)行版里非常常見。對于直接使用Apache社區(qū)版的團隊來說版本就是2.0.2簡單干凈但如果你所在的公司用的是HDP全家桶那安裝包就必須要和HDP的元數(shù)據(jù)服務、Ambari管理平臺兼容不能隨便拿個社區(qū)版就往上懟。1.2 部署前必須確認的三件事第一確認JDK版本。HBase 2.0.2官方要求JDK 8實際部署中我建議用JDK 8u161以上版本。之前踩過坑用JDK 8u121跑HBase 2.0.2會偶發(fā)java.lang.IllegalArgumentException: Invalid character之類的異常查了半天最后發(fā)現(xiàn)是JDK老版本對TLS握手協(xié)議支持不完整導致的升級JDK小版本后問題消失。第二確認Hadoop版本兼容性。HBase 2.x對Hadoop 3.x的兼容做了大量適配但這個HDP 3.1.4.0發(fā)行包默認適配的是Hadoop 3.1.1。如果你硬要用它跑在Hadoop 2.7上大概率啟動時會報UnsupportedClassVersionError或者客戶端協(xié)議不匹配。最穩(wěn)妥的做法是去看安裝包里的hbase-shaded-client依賴確認里面打包的Hadoop client版本。第三確認ZooKeeper版本。HBase 2.0.2對ZooKeeper 3.4.x兼容性最好HDP 3.1.4.0自帶的是ZooKeeper 3.4.14。這里有個細節(jié)HBase 2.x以后的版本內(nèi)置了HBaseZK但默認還是使用外部ZK。如果你用ZK 3.5.x需要額外處理admin server端口沖突的問題因為ZK 3.5默認會在8080端口起一個管理服務和HBase的Master端口容易撞車。2. 安裝配置實操從解壓到集群跑起來2.1 解壓與目錄規(guī)劃拿到tar包后第一步是解壓到規(guī)范目錄。我習慣把大數(shù)據(jù)組件統(tǒng)一放在/opt下而不是用戶的home目錄這樣多個用戶都能訪問也方便統(tǒng)一管理權限。tar -zxvf hbase-2.0.2.3.1.4.0-315-bin.tar.gz -C /opt/ ln -s /opt/hbase-2.0.2.3.1.4.0-315 /opt/hbase之所以做個軟鏈是為了后續(xù)升級版本時不需要改一堆配置文件里的路徑。很多老手推薦的HBASE_HOME環(huán)境變量也直接指向軟鏈的路徑就行。cat /etc/profile EOF export HBASE_HOME/opt/hbase export PATH$PATH:$HBASE_HOME/bin EOF source /etc/profile然后編輯conf/hbase-env.sh這里有兩個關鍵配置必須改export JAVA_HOME/usr/local/jdk1.8.0_161 export HBASE_MANAGES_ZKfalseHBASE_MANAGES_ZKfalse的意思是讓HBase使用外部ZooKeeper而不是自己啟動內(nèi)置ZK實例。生產(chǎn)環(huán)境強烈建議用外部ZK否則RegionServer宕機恢復時內(nèi)置ZK的狀態(tài)一致性很難保證。2.2 hbase-site.xml核心參數(shù)逐一拆解hbase-site.xml是整個HBase部署的關鍵我直接給你一份生產(chǎn)可用配置再逐個解釋為什么這么設configuration property namehbase.rootdir/name valuehdfs://hadoop-cluster/user/hbase/value /property property namehbase.zookeeper.quorum/name valuenode01:2181,node02:2181,node03:2181/value /property property namehbase.zookeeper.property.clientPort/name value2181/value /property property namehbase.cluster.distributed/name valuetrue/value /property property namehbase.master.port/name value16000/value /property property namehbase.regionserver.port/name value16020/value /property /configurationhbase.rootdir指定了HBase數(shù)據(jù)在HDFS上的存儲路徑。注意這個路徑如果已經(jīng)存在且非空HBase啟動時會嘗試讀取里面的元數(shù)據(jù)。我見過有同學圖省事直接配成/hbase結果和HDFS根目錄下的其他目錄混在一起權限和垃圾文件問題一堆。建議單獨建一個用戶目錄。hbase.zookeeper.quorum填ZK集群地址生產(chǎn)環(huán)境至少3個節(jié)點。這里有個細節(jié)不需要填所有ZK節(jié)點HBase客戶端會通過ZK的hbase:meta節(jié)點定位元數(shù)據(jù)填3個就足夠了但如果你只有2個ZKHBase也能工作只是可用性差一些。關于hbase.master.port的默認值HBase 2.x是16000和160201.x是60000和60020很多網(wǎng)上老教程還在寫60000照著配會把端口搞混。我建議第一次部署的同學在Master和RegionServer節(jié)點上分別執(zhí)行netstat -anp | grep 160確認監(jiān)聽端口是否正確。2.3 regionservers與備份Master配置conf/regionservers文件里填寫所有RegionServer節(jié)點的主機名每行一個node02 node03 node04HBase啟動時會通過這個文件啟動對應的RegionServer進程。注意這里填的是主機名不是IP。主機名解析依賴/etc/hosts如果你在云環(huán)境里跑還要確保所有節(jié)點的hostname都是唯一的避免因為hostname重復導致RegionServer進程在同一臺物理機上重復啟動。如果你想啟用備份Master在conf/backup-masters文件里填上備用節(jié)點node05HBase的Active Master宕機后backup-masters里的節(jié)點會自動接管。這個機制和HDFS的NameNode HA類似都是通過ZK做選主。有一點要說明backup-masters文件并不是官方文檔里明確描述的機制而是HDP發(fā)行版在hbase-daemon.sh腳本里做的擴展。如果是純Apache社區(qū)版需要用hbase master backup命令手動啟動備份Master或者通過ZK選主機制自行管理。3. 端口清單與連通性自查3.1 一張表理清HBase各項服務端口端口清單是面試和排障的高頻考點我整理了一張實際部署中必須掌握的端口表服務組件默認端口說明HMaster RPC端口16000Master對外提供元數(shù)據(jù)管理、DDL操作的RPC端口HMaster Web UI16010查看Master狀態(tài)、Region分布、表列表的HTTP端口RegionServer RPC端口16020RegionServer對外提供數(shù)據(jù)讀寫RPC的端口RegionServer Web UI16030查看RegionServer負載、Region分布的HTTP端口ZooKeeper Client端口2181HBase通過ZK協(xié)調Master選舉和Region分配HDFS NameNode RPC端口8020 / 9000HBase底層數(shù)據(jù)存儲依賴HDFS不同發(fā)行版端口不同HDFS DataNode RPC端口9866RegionServer實際寫入數(shù)據(jù)時與DataNode通信的端口真實排障中最容易被忽略的是HDFS端口。HBase讀寫慢、寫入超時有時候不是HBase本身的問題而是HDFS DataNode節(jié)點掉線、副本數(shù)不足導致的。所以排查時要先把HDFS的hdfs dfsadmin -report跑一遍確認所有DataNode節(jié)點都是Live狀態(tài)。3.2 端口起不來怎么排查端口起不來的原因按發(fā)生率從高到低排列第一端口被占用。尤其是測試環(huán)境之前跑過別的HBase實例進程沒殺干凈。在啟動新實例前用jps確認沒有遺留的HMaster和HRegionServer進程再用netstat -anp | grep 16000看看端口是否被其他程序占用。第二ZK集群狀態(tài)異常。HBase Master啟動時需要連接ZK如果ZK的過半節(jié)點不可用Master會一直卡在Waiting for the ZooKeeper cluster to become available這個狀態(tài)。遇到這種情況先去zkCli.sh里執(zhí)行l(wèi)s /hbase如果命令卡住說明ZK本身有問題如果rs目錄下出現(xiàn)了臨時節(jié)點但很快消失說明RegionServer和Master之間的心跳有問題。第三Hostname解析不對。HBase集群節(jié)點之間通過hostname通信如果/etc/hosts里沒配置對應映射Master啟動時會報java.net.UnknownHostException。我見過一個詭異的情況所有節(jié)點的hostname都配了但Master節(jié)點上的/etc/hostname寫的是localhost導致HMaster把自己的地址注冊成localhost:16000其他節(jié)點根本連不上。這個問題很隱蔽啟動日志里可能看不到報錯但客戶端連接時就是超時。4. 弄懂讀寫鏈路配參不再靠猜4.1 四大組件各管什么HBase依賴四個核心組件的協(xié)作才能正常工作理解它們的職責是看懂讀寫鏈路的基礎。HMaster負責Table的DDL操作創(chuàng)建表、刪除表、修改列族以及Region的分配和遷移。它不參與具體的數(shù)據(jù)讀寫請求所以HBase的高可用瓶頸不在Master上。很多同學面試時會說“Master是單點”嚴謹來說Master有備份機制但數(shù)據(jù)讀寫不經(jīng)過Master所以Master宕機只影響DDL操作不影響已有數(shù)據(jù)的讀寫。RegionServer是真正干活的人負責管理若干個Region的數(shù)據(jù)讀寫處理客戶端的讀寫請求并定期將內(nèi)存中的數(shù)據(jù)刷寫到HDFS。一臺RegionServer常駐一個進程內(nèi)部維護多個Region實例。ZooKeeper承擔協(xié)調者的角色維護HBase的元數(shù)據(jù)位置?？蛻舳嗽诎l(fā)起任何請求前第一件事是連接ZK從ZK里找到hbase:meta表所在RegionServer的位置然后才能繼續(xù)后續(xù)操作。HDFS是底層的存儲底座HBase的HFile和WAL日志最終都落在HDFS上。HBase不自己管理磁盤就是因為它把一致性、副本和容錯全交給了HDFS處理。4.2 寫路徑與讀路徑的關鍵環(huán)節(jié)寫一條數(shù)據(jù)時客戶端先通過ZK找到meta表所在RegionServer再從meta表中查到目標region所在的RegionServer然后直接向該RegionServer發(fā)起寫請求。RegionServer收到寫請求后會做兩件事先寫入WAL日志在HDFS上再寫入MemStore內(nèi)存中。當MemStore達到閾值默認128MB時RegionServer會將其刷寫成HFile并最終合并Compact。這里要記住一個關鍵點WAL是寫路徑的性能瓶頸。如果集群的寫入延遲高先看HDFS的DataNode是否有節(jié)點異常再看WAL刷寫策略是否合理。HBase 2.0.2支持異步WAL通過hbase.regionserver.hlog.async.batcher.impl參數(shù)開啟可以顯著降低高并發(fā)下的寫入延遲但代價是同步內(nèi)存延遲和數(shù)據(jù)安全性有一定折中生產(chǎn)環(huán)境要評估風險再開啟。讀路徑的關鍵在于BlockCache。HBase讀數(shù)據(jù)時會優(yōu)先查BlockCache再查MemStore最后才查HFile。如果業(yè)務是點查為主的場景可以適當調大hfile.block.cache.size默認0.4即堆內(nèi)存的40%如果是寫多讀少的場景把這個值調低反而能減少GC壓力。5. 高頻問題與面試考點整理5.1 老生常談的Region分裂與熱點問題Region分裂是HBase運營中繞不開的話題。當Region的單個HFile大小超過hbase.hregion.max.filesize默認10GB時Region會自動分裂成兩個。聽起來很簡單但實際生產(chǎn)環(huán)境里頻繁分裂會導致集群不穩(wěn)定。原因在于Region分裂瞬間需要更新meta表同時父Region的引用文件要在所有RS節(jié)點上清理干凈這個過程中如果恰好有大量寫入請求很容易造成短暫的數(shù)據(jù)不一致。我建議在數(shù)據(jù)量可預估的情況下預建Region分區(qū)通過hbase shell的create命令指定SPLITS[a,b,c]把數(shù)據(jù)分散到多個Region里避免單點寫入過熱。熱點問題最常見的原因是RowKey設計不合理。比如用時間戳當RowKey會因為前綴相同導致大量寫入落在同一個Region上。典型解法是加鹽、哈希、反轉RowKey等策略。有一條經(jīng)驗規(guī)律RowKey的前綴必須足夠離散否則怎么調參都沒用。5.2 運維現(xiàn)場最常見的幾個坑坑一HBase版本和Hadoop版本不匹配導致客戶端報No FileSystem for scheme hdfs。這是因為HBase發(fā)行包的HDFS客戶端依賴和你的Hadoop集群不完全一致。解決辦法是檢查hbase classpath中是否包含匹配的hadoop-client jar或者把Hadoop的share/hadoop/common、share/hadoop/hdfs下的jar包軟鏈到HBase的lib目錄下?？佣egionServer頻繁Full GC導致ZooKeeper會話超時被踢出集群。RegionServer同時管理多個RegionMemStore和BlockCache都在JVM堆里如果堆大小設得不合理很容易OOM或Full GC頻繁。經(jīng)驗值是把HBASE_HEAPSIZE設置為16GB到32GB之間同時開啟hbase.regionserver.global.memstore.size限制默認0.4避免MemStore無限增長?？尤齽h除數(shù)據(jù)后磁盤空間沒有回收。HBase刪除數(shù)據(jù)不是直接刪除文件而是打一個Delete標記等到Major Compaction時才會物理刪除。所以你會發(fā)現(xiàn)刪了很多數(shù)據(jù)但HDFS使用率沒有下降。解決方法是手動觸發(fā)Major Compactionhbase shell執(zhí)行major_compact table_name但要注意執(zhí)行時機盡量在業(yè)務低峰期做因為Compaction會消耗大量CPU和磁盤IO。5.3 面試官愛問的幾個問題結合“hbase面試題”這個熱詞我整理了幾個出現(xiàn)頻率極高的考點為什么HBase的寫性能比讀性能好因為寫入是順序追加到WAL和MemStore的MemStore是內(nèi)存操作所以寫入本質上接近內(nèi)存速度而讀取需要先在BlockCache中查找miss后要落盤掃描HFile涉及隨機IO所以性能相對較低。HBase的Region分裂和合并有什么區(qū)別分裂是Region變大后自動拆成兩個子Region是HBase自動觸發(fā)、自動完成的合并是用戶或運維手動觸發(fā)的主要目的是回收大量空Region或解決Region數(shù)量過多的問題。HBase的RowKey設計原則有哪些核心原則是長度要短、前綴要離散、業(yè)務上唯一。還需要注意如果RowKey是按時間順序遞歸遞增的可以通過反向RowKey將時間戳取反來平衡熱點。HBase 2.x和1.x的區(qū)別是什么HBase 2.x引入了基于Procedure V2的分布式事務框架、支持Master和RegionServer的獨立RPC group、指派RPC和io進程的分離、以及更智能的Compaction策略。這些改進都是為了應對更大規(guī)模集群的穩(wěn)定性需求。6. 最后再分享一個部署上的小技巧如果你要在一套集群上同時跑HDFS和HBase啟動順序非常重要。HBase的RegionServer啟動時會在HDFS上創(chuàng)建hbase.rootdir指定的目錄如果此時HDFS的NameNode還沒進入SafeMode退出狀態(tài)會導致初始化失敗。所以一個穩(wěn)妥的啟動流程是先啟動ZooKeeper再啟動HDFS等hdfs dfsadmin -safemode get顯示Safe mode是OFF最后再啟動HBase。反向操作也一樣關閉時先停HBase再停HDFS。這個順序在Ambari里已經(jīng)被自動處理了但如果你手動部署這個順序踩過的坑不少。另外每次改完hbase-site.xml后最好在conf/目錄下執(zhí)行一次hbase-config.sh驗證配置格式是否正確避免因為XML語法錯誤導致進程起不來時還要去翻日志。本文還有配套的精品資源點擊獲取 HBase HDP發(fā)行版安裝配置與核心原理詳解
簡介這是為Ambari 2.7.5編譯環(huán)境準備的大數(shù)據(jù)組件離線包之一面向手動搭建HDP 3.1.4平臺、或經(jīng)常編譯Ambari相關項目的開發(fā)與運維人員。由于官方源下載極慢提前將HBase 2.0.2.3.1.4.0-315二進制壓縮包打包分享可大幅縮短編譯前的依賴準備時間。整個壓縮包共412個文件大小約211.57MB內(nèi)部以jar庫文件、rb腳本、sh啟動與配置腳本為主同時包含少量xml配置、cmd命令文件及前端樣式資源覆蓋HBase運行所需的可執(zhí)行程序、類庫與配置文件。目前已有2191人學習使用適合在離線或弱網(wǎng)環(huán)境中部署HBase時直接引用。作者還同步整理了Hadoop、Grafana、Phoenix等配套大包便于一次性備齊Ambari編譯所需依賴減少因網(wǎng)絡中斷導致的重復下載。 拿到這個安裝包的時候大多數(shù)人第一反應是“這不就是個HBase的tar包嘛”。但如果你仔細看文件名里的2.0.2.3.1.4.0-315會發(fā)現(xiàn)事情沒那么簡單——這個版本號其實是HDP發(fā)行版的命名規(guī)則而不是Apache社區(qū)版的純版本號。也就是說你拿到的不是原生Apache HBase 2.0.2而是hortonworks打包、基于HBase 2.0.2內(nèi)核、附帶一堆平臺適配和bugfix的企業(yè)發(fā)行版二進制包。這篇文章我就從安裝配置、端口清單、核心原理到面試高頻考點把hbase-2.0.2.3.1.4.0-315-bin.tar.gz這個包一次講透。無論你是剛入行的大數(shù)據(jù)工程師還是準備面試的候選人這篇都能幫你在實際部署和原理理解上少走彎路。1. 拿到這個tar包先搞明白它到底是什么1.1 版本號里的秘密2.0.2.3.1.4.0-315怎么讀這個版本號可以拆成兩段看。第一段2.0.2是Apache HBase社區(qū)版本號表示內(nèi)核基于HBase 2.0.2。第二段3.1.4.0-315是HDPHortonworks Data Platform的版本號其中3.1.4是HDP的大版本0-315是build號。這種雙版本號命名在CDH和HDP這類發(fā)行版里非常常見。對于直接使用Apache社區(qū)版的團隊來說版本就是2.0.2簡單干凈但如果你所在的公司用的是HDP全家桶那安裝包就必須要和HDP的元數(shù)據(jù)服務、Ambari管理平臺兼容不能隨便拿個社區(qū)版就往上懟。1.2 部署前必須確認的三件事第一確認JDK版本。HBase 2.0.2官方要求JDK 8實際部署中我建議用JDK 8u161以上版本。之前踩過坑用JDK 8u121跑HBase 2.0.2會偶發(fā)java.lang.IllegalArgumentException: Invalid character之類的異常查了半天最后發(fā)現(xiàn)是JDK老版本對TLS握手協(xié)議支持不完整導致的升級JDK小版本后問題消失。第二確認Hadoop版本兼容性。HBase 2.x對Hadoop 3.x的兼容做了大量適配但這個HDP 3.1.4.0發(fā)行包默認適配的是Hadoop 3.1.1。如果你硬要用它跑在Hadoop 2.7上大概率啟動時會報UnsupportedClassVersionError或者客戶端協(xié)議不匹配。最穩(wěn)妥的做法是去看安裝包里的hbase-shaded-client依賴確認里面打包的Hadoop client版本。第三確認ZooKeeper版本。HBase 2.0.2對ZooKeeper 3.4.x兼容性最好HDP 3.1.4.0自帶的是ZooKeeper 3.4.14。這里有個細節(jié)HBase 2.x以后的版本內(nèi)置了HBaseZK但默認還是使用外部ZK。如果你用ZK 3.5.x需要額外處理admin server端口沖突的問題因為ZK 3.5默認會在8080端口起一個管理服務和HBase的Master端口容易撞車。2. 安裝配置實操從解壓到集群跑起來2.1 解壓與目錄規(guī)劃拿到tar包后第一步是解壓到規(guī)范目錄。我習慣把大數(shù)據(jù)組件統(tǒng)一放在/opt下而不是用戶的home目錄這樣多個用戶都能訪問也方便統(tǒng)一管理權限。tar -zxvf hbase-2.0.2.3.1.4.0-315-bin.tar.gz -C /opt/ ln -s /opt/hbase-2.0.2.3.1.4.0-315 /opt/hbase之所以做個軟鏈是為了后續(xù)升級版本時不需要改一堆配置文件里的路徑。很多老手推薦的HBASE_HOME環(huán)境變量也直接指向軟鏈的路徑就行。cat /etc/profile EOF export HBASE_HOME/opt/hbase export PATH$PATH:$HBASE_HOME/bin EOF source /etc/profile然后編輯conf/hbase-env.sh這里有兩個關鍵配置必須改export JAVA_HOME/usr/local/jdk1.8.0_161 export HBASE_MANAGES_ZKfalseHBASE_MANAGES_ZKfalse的意思是讓HBase使用外部ZooKeeper而不是自己啟動內(nèi)置ZK實例。生產(chǎn)環(huán)境強烈建議用外部ZK否則RegionServer宕機恢復時內(nèi)置ZK的狀態(tài)一致性很難保證。2.2 hbase-site.xml核心參數(shù)逐一拆解hbase-site.xml是整個HBase部署的關鍵我直接給你一份生產(chǎn)可用配置再逐個解釋為什么這么設configuration property namehbase.rootdir/name valuehdfs://hadoop-cluster/user/hbase/value /property property namehbase.zookeeper.quorum/name valuenode01:2181,node02:2181,node03:2181/value /property property namehbase.zookeeper.property.clientPort/name value2181/value /property property namehbase.cluster.distributed/name valuetrue/value /property property namehbase.master.port/name value16000/value /property property namehbase.regionserver.port/name value16020/value /property /configurationhbase.rootdir指定了HBase數(shù)據(jù)在HDFS上的存儲路徑。注意這個路徑如果已經(jīng)存在且非空HBase啟動時會嘗試讀取里面的元數(shù)據(jù)。我見過有同學圖省事直接配成/hbase結果和HDFS根目錄下的其他目錄混在一起權限和垃圾文件問題一堆。建議單獨建一個用戶目錄。hbase.zookeeper.quorum填ZK集群地址生產(chǎn)環(huán)境至少3個節(jié)點。這里有個細節(jié)不需要填所有ZK節(jié)點HBase客戶端會通過ZK的hbase:meta節(jié)點定位元數(shù)據(jù)填3個就足夠了但如果你只有2個ZKHBase也能工作只是可用性差一些。關于hbase.master.port的默認值HBase 2.x是16000和160201.x是60000和60020很多網(wǎng)上老教程還在寫60000照著配會把端口搞混。我建議第一次部署的同學在Master和RegionServer節(jié)點上分別執(zhí)行netstat -anp | grep 160確認監(jiān)聽端口是否正確。2.3 regionservers與備份Master配置conf/regionservers文件里填寫所有RegionServer節(jié)點的主機名每行一個node02 node03 node04HBase啟動時會通過這個文件啟動對應的RegionServer進程。注意這里填的是主機名不是IP。主機名解析依賴/etc/hosts如果你在云環(huán)境里跑還要確保所有節(jié)點的hostname都是唯一的避免因為hostname重復導致RegionServer進程在同一臺物理機上重復啟動。如果你想啟用備份Master在conf/backup-masters文件里填上備用節(jié)點node05HBase的Active Master宕機后backup-masters里的節(jié)點會自動接管。這個機制和HDFS的NameNode HA類似都是通過ZK做選主。有一點要說明backup-masters文件并不是官方文檔里明確描述的機制而是HDP發(fā)行版在hbase-daemon.sh腳本里做的擴展。如果是純Apache社區(qū)版需要用hbase master backup命令手動啟動備份Master或者通過ZK選主機制自行管理。3. 端口清單與連通性自查3.1 一張表理清HBase各項服務端口端口清單是面試和排障的高頻考點我整理了一張實際部署中必須掌握的端口表服務組件默認端口說明HMaster RPC端口16000Master對外提供元數(shù)據(jù)管理、DDL操作的RPC端口HMaster Web UI16010查看Master狀態(tài)、Region分布、表列表的HTTP端口RegionServer RPC端口16020RegionServer對外提供數(shù)據(jù)讀寫RPC的端口RegionServer Web UI16030查看RegionServer負載、Region分布的HTTP端口ZooKeeper Client端口2181HBase通過ZK協(xié)調Master選舉和Region分配HDFS NameNode RPC端口8020 / 9000HBase底層數(shù)據(jù)存儲依賴HDFS不同發(fā)行版端口不同HDFS DataNode RPC端口9866RegionServer實際寫入數(shù)據(jù)時與DataNode通信的端口真實排障中最容易被忽略的是HDFS端口。HBase讀寫慢、寫入超時有時候不是HBase本身的問題而是HDFS DataNode節(jié)點掉線、副本數(shù)不足導致的。所以排查時要先把HDFS的hdfs dfsadmin -report跑一遍確認所有DataNode節(jié)點都是Live狀態(tài)。3.2 端口起不來怎么排查端口起不來的原因按發(fā)生率從高到低排列第一端口被占用。尤其是測試環(huán)境之前跑過別的HBase實例進程沒殺干凈。在啟動新實例前用jps確認沒有遺留的HMaster和HRegionServer進程再用netstat -anp | grep 16000看看端口是否被其他程序占用。第二ZK集群狀態(tài)異常。HBase Master啟動時需要連接ZK如果ZK的過半節(jié)點不可用Master會一直卡在Waiting for the ZooKeeper cluster to become available這個狀態(tài)。遇到這種情況先去zkCli.sh里執(zhí)行l(wèi)s /hbase如果命令卡住說明ZK本身有問題如果rs目錄下出現(xiàn)了臨時節(jié)點但很快消失說明RegionServer和Master之間的心跳有問題。第三Hostname解析不對。HBase集群節(jié)點之間通過hostname通信如果/etc/hosts里沒配置對應映射Master啟動時會報java.net.UnknownHostException。我見過一個詭異的情況所有節(jié)點的hostname都配了但Master節(jié)點上的/etc/hostname寫的是localhost導致HMaster把自己的地址注冊成localhost:16000其他節(jié)點根本連不上。這個問題很隱蔽啟動日志里可能看不到報錯但客戶端連接時就是超時。4. 弄懂讀寫鏈路配參不再靠猜4.1 四大組件各管什么HBase依賴四個核心組件的協(xié)作才能正常工作理解它們的職責是看懂讀寫鏈路的基礎。HMaster負責Table的DDL操作創(chuàng)建表、刪除表、修改列族以及Region的分配和遷移。它不參與具體的數(shù)據(jù)讀寫請求所以HBase的高可用瓶頸不在Master上。很多同學面試時會說“Master是單點”嚴謹來說Master有備份機制但數(shù)據(jù)讀寫不經(jīng)過Master所以Master宕機只影響DDL操作不影響已有數(shù)據(jù)的讀寫。RegionServer是真正干活的人負責管理若干個Region的數(shù)據(jù)讀寫處理客戶端的讀寫請求并定期將內(nèi)存中的數(shù)據(jù)刷寫到HDFS。一臺RegionServer常駐一個進程內(nèi)部維護多個Region實例。ZooKeeper承擔協(xié)調者的角色維護HBase的元數(shù)據(jù)位置?？蛻舳嗽诎l(fā)起任何請求前第一件事是連接ZK從ZK里找到hbase:meta表所在RegionServer的位置然后才能繼續(xù)后續(xù)操作。HDFS是底層的存儲底座HBase的HFile和WAL日志最終都落在HDFS上。HBase不自己管理磁盤就是因為它把一致性、副本和容錯全交給了HDFS處理。4.2 寫路徑與讀路徑的關鍵環(huán)節(jié)寫一條數(shù)據(jù)時客戶端先通過ZK找到meta表所在RegionServer再從meta表中查到目標region所在的RegionServer然后直接向該RegionServer發(fā)起寫請求。RegionServer收到寫請求后會做兩件事先寫入WAL日志在HDFS上再寫入MemStore內(nèi)存中。當MemStore達到閾值默認128MB時RegionServer會將其刷寫成HFile并最終合并Compact。這里要記住一個關鍵點WAL是寫路徑的性能瓶頸。如果集群的寫入延遲高先看HDFS的DataNode是否有節(jié)點異常再看WAL刷寫策略是否合理。HBase 2.0.2支持異步WAL通過hbase.regionserver.hlog.async.batcher.impl參數(shù)開啟可以顯著降低高并發(fā)下的寫入延遲但代價是同步內(nèi)存延遲和數(shù)據(jù)安全性有一定折中生產(chǎn)環(huán)境要評估風險再開啟。讀路徑的關鍵在于BlockCache。HBase讀數(shù)據(jù)時會優(yōu)先查BlockCache再查MemStore最后才查HFile。如果業(yè)務是點查為主的場景可以適當調大hfile.block.cache.size默認0.4即堆內(nèi)存的40%如果是寫多讀少的場景把這個值調低反而能減少GC壓力。5. 高頻問題與面試考點整理5.1 老生常談的Region分裂與熱點問題Region分裂是HBase運營中繞不開的話題。當Region的單個HFile大小超過hbase.hregion.max.filesize默認10GB時Region會自動分裂成兩個。聽起來很簡單但實際生產(chǎn)環(huán)境里頻繁分裂會導致集群不穩(wěn)定。原因在于Region分裂瞬間需要更新meta表同時父Region的引用文件要在所有RS節(jié)點上清理干凈這個過程中如果恰好有大量寫入請求很容易造成短暫的數(shù)據(jù)不一致。我建議在數(shù)據(jù)量可預估的情況下預建Region分區(qū)通過hbase shell的create命令指定SPLITS[a,b,c]把數(shù)據(jù)分散到多個Region里避免單點寫入過熱。熱點問題最常見的原因是RowKey設計不合理。比如用時間戳當RowKey會因為前綴相同導致大量寫入落在同一個Region上。典型解法是加鹽、哈希、反轉RowKey等策略。有一條經(jīng)驗規(guī)律RowKey的前綴必須足夠離散否則怎么調參都沒用。5.2 運維現(xiàn)場最常見的幾個坑坑一HBase版本和Hadoop版本不匹配導致客戶端報No FileSystem for scheme hdfs。這是因為HBase發(fā)行包的HDFS客戶端依賴和你的Hadoop集群不完全一致。解決辦法是檢查hbase classpath中是否包含匹配的hadoop-client jar或者把Hadoop的share/hadoop/common、share/hadoop/hdfs下的jar包軟鏈到HBase的lib目錄下?？佣egionServer頻繁Full GC導致ZooKeeper會話超時被踢出集群。RegionServer同時管理多個RegionMemStore和BlockCache都在JVM堆里如果堆大小設得不合理很容易OOM或Full GC頻繁。經(jīng)驗值是把HBASE_HEAPSIZE設置為16GB到32GB之間同時開啟hbase.regionserver.global.memstore.size限制默認0.4避免MemStore無限增長?？尤齽h除數(shù)據(jù)后磁盤空間沒有回收。HBase刪除數(shù)據(jù)不是直接刪除文件而是打一個Delete標記等到Major Compaction時才會物理刪除。所以你會發(fā)現(xiàn)刪了很多數(shù)據(jù)但HDFS使用率沒有下降。解決方法是手動觸發(fā)Major Compactionhbase shell執(zhí)行major_compact table_name但要注意執(zhí)行時機盡量在業(yè)務低峰期做因為Compaction會消耗大量CPU和磁盤IO。5.3 面試官愛問的幾個問題結合“hbase面試題”這個熱詞我整理了幾個出現(xiàn)頻率極高的考點為什么HBase的寫性能比讀性能好因為寫入是順序追加到WAL和MemStore的MemStore是內(nèi)存操作所以寫入本質上接近內(nèi)存速度而讀取需要先在BlockCache中查找miss后要落盤掃描HFile涉及隨機IO所以性能相對較低。HBase的Region分裂和合并有什么區(qū)別分裂是Region變大后自動拆成兩個子Region是HBase自動觸發(fā)、自動完成的合并是用戶或運維手動觸發(fā)的主要目的是回收大量空Region或解決Region數(shù)量過多的問題。HBase的RowKey設計原則有哪些核心原則是長度要短、前綴要離散、業(yè)務上唯一。還需要注意如果RowKey是按時間順序遞歸遞增的可以通過反向RowKey將時間戳取反來平衡熱點。HBase 2.x和1.x的區(qū)別是什么HBase 2.x引入了基于Procedure V2的分布式事務框架、支持Master和RegionServer的獨立RPC group、指派RPC和io進程的分離、以及更智能的Compaction策略。這些改進都是為了應對更大規(guī)模集群的穩(wěn)定性需求。6. 最后再分享一個部署上的小技巧如果你要在一套集群上同時跑HDFS和HBase啟動順序非常重要。HBase的RegionServer啟動時會在HDFS上創(chuàng)建hbase.rootdir指定的目錄如果此時HDFS的NameNode還沒進入SafeMode退出狀態(tài)會導致初始化失敗。所以一個穩(wěn)妥的啟動流程是先啟動ZooKeeper再啟動HDFS等hdfs dfsadmin -safemode get顯示Safe mode是OFF最后再啟動HBase。反向操作也一樣關閉時先停HBase再停HDFS。這個順序在Ambari里已經(jīng)被自動處理了但如果你手動部署這個順序踩過的坑不少。另外每次改完hbase-site.xml后最好在conf/目錄下執(zhí)行一次hbase-config.sh驗證配置格式是否正確避免因為XML語法錯誤導致進程起不來時還要去翻日志。本文還有配套的精品資源點擊獲取