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