戰(zhàn))
最近有個(gè)項(xiàng)目要做離線日志分析和實(shí)時(shí)查詢數(shù)據(jù)量不大但增長很快我們最后選擇了CentOS 8.1 Hadoop MapReduce HBase這套組合。這套方案最直接的優(yōu)勢在于Hadoop負(fù)責(zé)海量文件的分布式存儲MapReduce處理批量計(jì)算HBase承接最終結(jié)果的高效查詢各司其職又天然配套。這篇文章就復(fù)現(xiàn)一下當(dāng)時(shí)從零搭建環(huán)境、跑通全流程的完整過程適合剛接觸大數(shù)據(jù)生態(tài)、或者準(zhǔn)備在本地/測試環(huán)境構(gòu)建這套技術(shù)棧的讀者參考。為了避免紙上談兵我會先講清楚技術(shù)選型的判斷邏輯再逐步拆解三節(jié)點(diǎn)集群的環(huán)境初始化、Hadoop核心配置、HBase與Hadoop的集成要點(diǎn)最后用一個(gè)可復(fù)現(xiàn)的離線訂單統(tǒng)計(jì)Demo串聯(lián)MapReduce讀寫HBase的代碼鏈路。整個(gè)過程盡量落在具體命令和參數(shù)上也會把踩過的坑原樣交代出來。1. 為什么選CentOS 8.1HadoopHBase從業(yè)務(wù)需求反推技術(shù)棧1.1 業(yè)務(wù)場景倒逼出的存儲與計(jì)算架構(gòu)先說背景。我們接到的任務(wù)是處理某智能硬件每日產(chǎn)生的設(shè)備上報(bào)日志單日數(shù)據(jù)量在2000萬條左右原始文件以JSON格式落盤總量約15GB。需求有兩層一是定期把這些日志做清洗、聚合算出一系列統(tǒng)計(jì)指標(biāo)二是運(yùn)營后臺要能按設(shè)備ID或時(shí)間范圍快速查出明細(xì)。針對這類場景我首先排除掉傳統(tǒng)關(guān)系型數(shù)據(jù)庫。按單日2000萬條來算一個(gè)月就是6億行MySQL即使分庫分表也扛不住這種寫入壓力更別說后臺還要求毫秒級的在線查詢。于是存儲層選擇了HBase理由很實(shí)際它天生支持稀疏寬表rowkey設(shè)計(jì)得當(dāng)就能讓查詢直接命中某個(gè)Region不需要像Hive那樣啟動一個(gè)大任務(wù)去掃全表同時(shí)它可以建立在HDFS之上直接復(fù)用Hadoop的副本機(jī)制不用額外維護(hù)一套持久化鏈路。計(jì)算層選MapReduce是因?yàn)檫@個(gè)項(xiàng)目對實(shí)時(shí)性沒有過高要求統(tǒng)計(jì)任務(wù)在每天凌晨跑一次T1出結(jié)果完全能接受。MapReduce雖被人詬病“笨重”但在這類離線批處理上是極其穩(wěn)定的提交一個(gè)作業(yè)YARN負(fù)責(zé)分配資源任務(wù)失敗自動重試不需要額外部署Spark之類的計(jì)算引擎?？紤]到團(tuán)隊(duì)后續(xù)還打算引入Hive做SQL化分析Hadoop這套底層更是繞不開的依賴。1.2 版本選擇與兼容性這道坎版本組合必須提前定死否則后面全是淚。我經(jīng)過踩坑后固定下來的版本是CentOS 8.1 JDK 1.88u212 Hadoop 3.2.4 HBase 2.4.17 ZooKeeper 3.6.3。有人可能問CentOS 8.1已經(jīng)停止維護(hù)了為什么還要選它。這里有個(gè)現(xiàn)實(shí)原因項(xiàng)目現(xiàn)場那批服務(wù)器出廠預(yù)裝的就是8.1且業(yè)務(wù)方短期沒有遷移計(jì)劃。如果你是從零規(guī)劃用CentOS 7.9或Rocky Linux完全沒問題本文的部署命令除了yum源細(xì)節(jié)外基本通用。兼容性上特別注意兩點(diǎn)Hadoop 3.2.x系列官方支持JDK 8必須避開JDK 11因?yàn)镠adoop 3.2雖然能在JDK 11上啟動但很多第三方插件會發(fā)現(xiàn)ClassNotFound或SecurityManager異常HBase 2.4.x官方兼容矩陣?yán)锩鞔_列出的Hadoop版本是3.2.x如果你硬要配Hadoop 3.3.x很可能在HBase Master啟動時(shí)碰到protobuf版本沖突。組件版本備注操作系統(tǒng)CentOS 8.1內(nèi)核4.18若生產(chǎn)環(huán)境建議7.9或更新替代版JDK1.8.0_212不要用JDK 11跑Hadoop 3.2Hadoop3.2.4含HDFS和YARN計(jì)算層用MRHBase2.4.17與Hadoop 3.2.x官方兼容ZooKeeper3.6.3用于HBase協(xié)調(diào)生產(chǎn)必須獨(dú)立部署部署方式三節(jié)點(diǎn)1臺Master 2臺Worker2. 三節(jié)點(diǎn)集群環(huán)境初始化那些不寫進(jìn)官方文檔的細(xì)節(jié)2.1 主機(jī)規(guī)劃與SSH免密登錄配置我這邊準(zhǔn)備了3臺虛擬機(jī)每臺分配4核CPU、8GB內(nèi)存、100GB磁盤。主機(jī)名分別規(guī)劃為node01、node02、node03其中node01跑NameNode、ResourceManager、HMasternode02和node03作為DataNode和RegionServer。ZooKeeper三臺都放一份構(gòu)成3節(jié)點(diǎn)ZooKeeper集群。開始部署前先把每臺機(jī)器的hostname和/etc/hosts整明白這個(gè)環(huán)節(jié)出問題會導(dǎo)致后面HBase RegionServer注冊不上我第7節(jié)會專門講。hostnamectl set-hostname node01 cat /etc/hosts EOF 192.168.10.11 node01 192.168.10.12 node02 192.168.10.13 node03 EOFSSH免密登錄是啟動Hadoop腳本的硬前提否則每次啟動都得輸密碼。我在node01上執(zhí)行ssh-keygen -t rsa -P -f ~/.ssh/id_rsa ssh-copy-id node01 ssh-copy-id node02 ssh-copy-id node03注意Hadoop部分命令是通過rpc遠(yuǎn)程調(diào)用執(zhí)行的所以node01必須能免密登錄到所有節(jié)點(diǎn)。HBase啟動時(shí)也會經(jīng)由Master去SSH到各臺RegionServer拉起進(jìn)程這個(gè)權(quán)限同樣需要提前打通。2.2 JDK安裝與系統(tǒng)參數(shù)調(diào)整Hadoop 3.x對系統(tǒng)的要求比舊版嚴(yán)格文件句柄打開數(shù)和進(jìn)程數(shù)必須改否則運(yùn)行一段時(shí)間后DataNode會報(bào)“Too many open files”。我用root用戶完成以下配置yum install -y java-1.8.0-openjdk java-1.8.0-openjdk-devel cat /etc/security/limits.conf EOF * soft nofile 65536 * hard nofile 131072 * soft nproc 65536 * hard nproc 131072 EOF同時(shí)三臺機(jī)器都執(zhí)行關(guān)閉防火墻和SELinux。很多初學(xué)者跳過這步然后發(fā)現(xiàn)9000端口、16010端口對外不通排查半天方向完全錯(cuò)了systemctl stop firewalld systemctl disable firewalld sed -i s/^SELINUX.*/SELINUXdisabled/ /etc/selinux/config setenforce 0時(shí)間同步是另一個(gè)大坑。HBase的RegionServer非常依賴集群時(shí)鐘一致如果節(jié)點(diǎn)間時(shí)間偏差超過30秒HBase Master會把RegionServer直接踢下線。我這里用最簡單的方式配置NTP指向一臺內(nèi)網(wǎng)時(shí)間源yum install -y chrony sed -i 3,6s/^pool/server 192.168.10.1 iburst/ /etc/chrony.conf sed -i s/^pool.*/# pool./ /etc/chrony.conf systemctl restart chronyd chronyc sources -v2.3 軟件包目錄規(guī)劃與環(huán)境變量統(tǒng)一Hadoop和HBase都解壓在/opt目錄下通過軟鏈指向具體版本這樣后續(xù)升級版本不用改一大堆配置。我按自己的習(xí)慣創(chuàng)建了如下布局/opt/hadoop-3.2.4 - /opt/hadoop /opt/hbase-2.4.17 - /opt/hbase /opt/zookeeper-3.6.3 - /opt/zookeeper環(huán)境變量統(tǒng)一寫入/etc/profile.d/bigdata.sh讓所有節(jié)點(diǎn)加載同一份內(nèi)容export JAVA_HOME/usr/lib/jvm/java-1.8.0-openjdk export HADOOP_HOME/opt/hadoop export HBASE_HOME/opt/hbase export ZOOKEEPER_HOME/opt/zookeeper export PATH$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin:$HBASE_HOME/bin:$ZOOKEEPER_HOME/bin這里有個(gè)建議不要用root用戶運(yùn)行大數(shù)據(jù)組件因?yàn)镠adoop在安全檢查上對root有額外限制。我創(chuàng)建了一個(gè)hadoop用戶把/opt/hadoop、/opt/hbase、/opt/zookeeper三目錄的屬主都改到該用戶下后續(xù)所有啟停操作都切到這個(gè)用戶執(zhí)行。3. Hadoop核心配置逐項(xiàng)拆解不只是照抄官方模板3.1 core-site.xml與hdfs-site.xml的關(guān)鍵參數(shù)Hadoop部署最忌諱拿一個(gè)模板到處拷貝卻不理解每個(gè)參數(shù)的含義。我這份配置是在排掉三個(gè)不同問題后最終定稿的。core-site.xml里最關(guān)鍵的是fs.defaultFS它決定了整個(gè)集群的“根文件系統(tǒng)”指向哪里。我設(shè)置為hdfs://node01:9000后面的9000是NameNode RPC端口。hadoop.tmp.dir則指定了HDFS元數(shù)據(jù)等臨時(shí)文件的存放路徑獨(dú)立掛載的磁盤比系統(tǒng)盤更穩(wěn)妥configuration property namefs.defaultFS/name valuehdfs://node01:9000/value /property property namehadoop.tmp.dir/name value/data/hadoop/tmp/value /property /configurationhdfs-site.xml這里重點(diǎn)配置了三項(xiàng)副本數(shù)、NameNode元數(shù)據(jù)目錄、DataNode數(shù)據(jù)目錄。由于節(jié)點(diǎn)數(shù)只有3我設(shè)置dfs.replication為2既保證容錯(cuò)又節(jié)省一半存儲若數(shù)據(jù)重要程度高保持默認(rèn)的3也不是問題configuration property namedfs.replication/name value2/value /property property namedfs.namenode.name.dir/name valuefile:///data/hadoop/namenode/value /property property namedfs.datanode.data.dir/name valuefile:///data/hadoop/datanode/value /property property namedfs.namenode.handler.count/name value100/value /property /configurationdfs.namenode.handler.count這項(xiàng)容易被忽略并發(fā)請求一多NameNode會成為瓶頸。經(jīng)驗(yàn)值上4核機(jī)器配100足夠線程過多反而加大上下文切換開銷。3.2 YARN資源削峰小內(nèi)存機(jī)器的保命配置Hadoop 3.2.4的默認(rèn)配置是按大內(nèi)存機(jī)器設(shè)計(jì)的ResourceManager默認(rèn)會為每個(gè)容器分配很大的內(nèi)存如果你直接在小內(nèi)存機(jī)器上提交任務(wù)會看到作業(yè)無限期pending。我在這臺8GB內(nèi)存的節(jié)點(diǎn)上做了如下收斂configuration property nameyarn.nodemanager.resource.memory-mb/name value6144/value /property property nameyarn.nodemanager.resource.cpu-vcores/name value4/value /property property nameyarn.scheduler.minimum-allocation-mb/name value1024/value /property property nameyarn.scheduler.maximum-allocation-mb/name value3072/value /property /configuration這里計(jì)算邏輯是系統(tǒng)自身占用約1.5GBZooKeeper和HBase還需要各自預(yù)留內(nèi)存真正能分給YARN的只有6GB左右。maximum-allocation-mb設(shè)得比剛提交的MR任務(wù)所需更大同時(shí)minimum設(shè)為1GB避免小任務(wù)也要湊出一個(gè)大容器。3.3 格式化NameNode與安全模式處置首次啟動HDFS前必須格式化NameNode這一步會在namenode目錄生成fsimage。格式化命令要注意只需在node01執(zhí)行一次執(zhí)行前確認(rèn)core-site.xml和hdfs-site.xml已經(jīng)分發(fā)到所有節(jié)點(diǎn)hdfs namenode -format格式化完成后在node01上執(zhí)行start-dfs.sh在node02和node03執(zhí)行start-yarn.sh。為什么分開因?yàn)槲覀儼裄esourceManager放在了node01但NodeManager需要在每個(gè)節(jié)點(diǎn)拉起。配置文件里通過yarn-site.xml的yarn.resourcemanager.hostname指定node01。啟動后第一件事不是急著看日志而是確認(rèn)HDFS狀態(tài)退出安全模式。安全模式是HDFS啟動后自動進(jìn)入的保護(hù)期此間不允許寫數(shù)據(jù)只能等待各DataNode上報(bào)塊信息hdfs dfsadmin -safemode get hdfs dfsadmin -safemode leave hdfs dfsadmin -report如果report里顯示的Live datanode數(shù)量小于3多半是DataNode沒起來或者被防火墻擋了。一個(gè)比較隱蔽的原因是DataNode進(jìn)程起來后遇到磁盤空間不足主動退出這時(shí)候datanode日志會顯示“Data volume failed”字樣我第7節(jié)會專門復(fù)盤。4. HBase集成Hadoop的版本兼容與參數(shù)調(diào)優(yōu)4.1 為什么非要獨(dú)立ZooKeeperHBase的HMasia正常情況下需要ZooKeeper來協(xié)調(diào)RegionServer與Master之間的心跳以及保存meta表的位置信息。HBase內(nèi)置ZooKeeper在開發(fā)環(huán)境圖省事可以直接啟用但生產(chǎn)環(huán)境三節(jié)點(diǎn)的集群我選擇獨(dú)立部署ZooKeeper否則一旦HBase一停ZooKeeper也跟著沒了后續(xù)想用HBASE自帶工具排查問題非常別扭。ZooKeeper的配置文件zoo.cfg里只改三個(gè)地方dataDir、clientPort、server列表。dataDir建議放在獨(dú)立磁盤server.1、server.2、server.3必須與三臺機(jī)器對應(yīng)每臺機(jī)器都要?jiǎng)?chuàng)建myid文件并寫入對應(yīng)數(shù)字。dataDir/data/zookeeper server.1node01:2888:3888 server.2node02:2888:3888 server.3node03:2888:3888ZooKeeper啟動順序也有講究三臺各自執(zhí)行zkServer.sh start后用zkServer.sh status確認(rèn)其中一臺leader、兩臺follower任何一個(gè)節(jié)點(diǎn)狀態(tài)為standalone都是沒搭成功。4.2 hbase-site.xml里容易被誤解的配置項(xiàng)HBase集成Hadoop的核心配置有四個(gè)維度rootdir、zookeeper地址、RegionServer相關(guān)調(diào)優(yōu)、以及容錯(cuò)參數(shù)。我貼一版實(shí)際穩(wěn)定運(yùn)行很久的配置configuration property namehbase.rootdir/name valuehdfs://node01:9000/hbase/value /property property namehbase.cluster.distributed/name valuetrue/value /property property namehbase.zookeeper.quorum/name valuenode01,node02,node03/value /property property namehbase.zookeeper.property.clientPort/name value2181/value /property property namehbase.regionserver.handler.count/name value30/value /property property namehbase.hregion.memstore.flush.size/name value134217728/value /property property namehbase.client.write.buffer/name value8388608/value /property /configurationhbase.rootdir必須帶上完整的HDFS路徑不要只寫到node01:9000這一層否則HBase會試圖把表數(shù)據(jù)寫到根路徑下與HDFS的目錄結(jié)構(gòu)混淆。hbase.cluster.distributed必須設(shè)為true否則HBase認(rèn)為你是單機(jī)模式根本不會往HDFS寫數(shù)據(jù)。hbase.regionserver.handler.count可以直接理解為RegionServer同時(shí)能處理的RPC請求數(shù)這個(gè)值設(shè)得太大沒什么意義因?yàn)镃PU核數(shù)有限并發(fā)請求再多也是排隊(duì)設(shè)得太小MR任務(wù)批量寫入時(shí)會頻繁報(bào)超時(shí)。30是我在4核環(huán)境下的經(jīng)驗(yàn)值。4.3 RegionServer的目錄分區(qū)與內(nèi)存比例HBase要求每臺RegionServer在本地保存寫前日志W(wǎng)AL這個(gè)路徑默認(rèn)在hbase.tmp.dir下通常會被系統(tǒng)盤限制住。我在每臺機(jī)器上單獨(dú)掛載了/data/hbase并在hbase-env.sh里設(shè)置HBASE_LOG_DIR和堆大小。內(nèi)存分配是HBase最容易崩潰的根源。默認(rèn)情況下HBase的RegionServer堆大小是1GB但面對較大的寫緩存或讀緩存時(shí)1GB完全不夠GC頻繁觸發(fā)stop-the-world最終被Master判定心跳超時(shí)而移除。我把HBASE_HEAPSIZE調(diào)到4GB同時(shí)確保YARN的NodeManager不會把內(nèi)存全部搶走畢竟它們在同一臺物理機(jī)上。這里有個(gè)細(xì)節(jié)如果你的MapReduce作業(yè)會直接讀寫HBase就必須在MR JVM和HBase RegionServer之間留出足夠空間。我當(dāng)時(shí)設(shè)置時(shí)每臺機(jī)器給YARN 6GB、給HBase 4GB再加系統(tǒng)1.5GB剛好超出8GB一點(diǎn)于是又把HBase堆降到3.5GB留出余量這才穩(wěn)定下來。5. MapReduce直連HBase讀寫兩端的代碼實(shí)現(xiàn)5.1 為什么要讓MR直接讀寫HBase離線統(tǒng)計(jì)任務(wù)的典型流程是先由MR讀取HDFS上的日志文件做清洗然后把聚合結(jié)果寫入HBase供查詢端讀取。這里有兩種方案一種是把MR結(jié)果落地成HDFS文件再由HBase做bulk load另一種是MR直接通過TableOutputFormat寫入HBase。我選擇后者因?yàn)轫?xiàng)目表數(shù)據(jù)量還達(dá)不到幾十TB需要bulk load的規(guī)模直接寫更省事代碼也更直觀。但前提是你得搞清楚TableOutputFormat和TableInputFormat的用法以及它們對MR job設(shè)置的特殊要求。5.2 寫入端用TableOutputFormat把計(jì)算結(jié)果落到HBase寫入端的核心思路是Mapper的輸出key為ImmutableBytesWritable或NullWritablevalue為Put對象。TableOutputFormat的OutputCommitter會把這些Put按所屬Region分發(fā)到正確的RegionServer整個(gè)過程不需要reduce參與。以下是我項(xiàng)目里把訂單統(tǒng)計(jì)結(jié)果寫入HBase訂單表的Mapper代碼核心部分public static class WriteMapper extends MapperLongWritable, Text, NullWritable, Put { private byte[] family Bytes.toBytes(detail); Override protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException { String[] fields value.toString().split(,); String orderId ord_ fields[0]; Put put new Put(Bytes.toBytes(saltKey(orderId) orderId)); put.addColumn(family, Bytes.toBytes(device_id), Bytes.toBytes(fields[1])); put.addColumn(family, Bytes.toBytes(status), Bytes.toBytes(fields[2])); put.addColumn(family, Bytes.toBytes(timestamp), Bytes.toBytes(Long.parseLong(fields[3]))); context.write(NullWritable.get(), put); } private String saltKey(String orderId) { int hash Math.abs(orderId.hashCode() % 8); return String.valueOf(hash); } }saltKey函數(shù)是rowkey預(yù)分區(qū)的一種簡單實(shí)現(xiàn)。HBase按rowkey的字典序把數(shù)據(jù)分布到各個(gè)Region如果直接用自增ID或時(shí)間戳當(dāng)rowkey寫入熱點(diǎn)會集中在最后一個(gè)Region。我按訂單ID哈希取0到7的前綴加上前綴后數(shù)據(jù)能均勻落到默認(rèn)8個(gè)預(yù)分區(qū)里。作業(yè)配置上關(guān)鍵點(diǎn)是必須指定輸出表名和輸出格式Job job Job.getInstance(conf, WriteOrderToHBase); job.setJarByClass(WriteOrderToHBase.class); job.setMapperClass(WriteMapper.class); job.setNumReduceTasks(0); job.setMapOutputKeyClass(NullWritable.class); job.setMapOutputValueClass(Put.class); job.setOutputFormatClass(TableOutputFormat.class); job.getConfiguration().set(TableOutputFormat.OUTPUT_TABLE, order_info);注意TableOutputFormat會主動讀取TableName參數(shù)如果你的代碼里沒有set輸出表運(yùn)行時(shí)大概率報(bào)“Cannot resolve output table”之類異常。另一個(gè)容易踩的坑是TableOutputFormat要求作業(yè)輸出Path不能重復(fù)文件所以每次跑任務(wù)前最好清理輸出目錄或使用動態(tài)路徑。5.3 讀取端用TableInputFormatScan做批量分析讀取端是另一個(gè)鏡像問題把一張HBase表作為MR的輸入源。關(guān)鍵API是TableMapReduceUtil.initTableMapperJob它會基于Scan自動創(chuàng)建InputFormat并切分InputSplitpublic static class ReadMapper extends TableMapperText, IntWritable { private Text outKey new Text(); Override protected void map(ImmutableBytesWritable rowKey, Result result, Context context) throws IOException, InterruptedException { String status Bytes.toString( result.getValue(Bytes.toBytes(detail), Bytes.toBytes(status))); outKey.set(status); context.write(outKey, new IntWritable(1)); } }作業(yè)初始化時(shí)需要構(gòu)建Scan對象并傳入需要讀取的列族Scan默認(rèn)全表掃描所有列族全部版本導(dǎo)致網(wǎng)絡(luò)IO暴增。推薦的寫法是Scan scan new Scan(); scan.addFamily(Bytes.toBytes(detail)); scan.setCaching(500); scan.setCacheBlock(false); TableMapReduceUtil.initTableMapperJob( order_info, scan, ReadMapper.class, Text.class, IntWritable.class, job);scan.setCaching默認(rèn)值是100設(shè)為500能減少客戶端與RegionServer的RPC次數(shù)代價(jià)是占用更多客戶端堆內(nèi)存。scan.setCacheBlock(false)是關(guān)鍵性能開關(guān)——它告訴RegionServer在掃描過程中不要將數(shù)據(jù)塊駐留在堆緩存中因?yàn)榇笈縎can很快就會把BlockCache擠滿導(dǎo)致熱點(diǎn)隨機(jī)讀性能大幅下降。對于離線MR任務(wù)這幾乎是必須調(diào)的一項(xiàng)。6. 離線訂單統(tǒng)計(jì)Demo從建表到MR任務(wù)結(jié)果全流程驗(yàn)證6.1 表設(shè)計(jì)rowkey鹽值前綴與列族規(guī)劃整個(gè)Demo圍繞一個(gè)虛構(gòu)的“設(shè)備訂單上報(bào)系統(tǒng)”展開。每天有設(shè)備上報(bào)訂單狀態(tài)我們需要在第二天凌晨統(tǒng)計(jì)每臺設(shè)備當(dāng)天的訂單總數(shù)以及各狀態(tài)占比。HBase里建兩張表order_info存訂單明細(xì)user_order_count存每個(gè)人/設(shè)備的統(tǒng)計(jì)結(jié)果。通過HBase Shell建表時(shí)我特意加了預(yù)分區(qū)和壓縮hbase shell EOF create order_info, {NAME detail, COMPRESSION SNAPPY, TTL 604800}, {SPLITS [0,1,2,3,4,5,6,7]} create user_order_count, {NAME cf}, {SPLITS [a,m,z]} EOF預(yù)分區(qū)數(shù)量不必太多8個(gè)Region對于一個(gè)測試集群足夠但已經(jīng)能演示“寫入分散到多個(gè)RegionServer”的效果。TTL設(shè)置為7天讓過期明細(xì)自動清理省去后續(xù)手動刪除數(shù)據(jù)的麻煩。SNAPPY壓縮是我強(qiáng)烈推薦在生產(chǎn)表開啟的選項(xiàng)它在CPU消耗和壓縮比之間平衡最好。需要說明的是如果你啟用SNAPPY所有RegionServer節(jié)點(diǎn)必須安裝libsnappy庫否則HBase寫入時(shí)會報(bào)壓縮編解碼器無法加載。6.2 造數(shù)腳本與數(shù)據(jù)導(dǎo)入鏈路的坑為了驗(yàn)證整條鏈路我寫了一個(gè)簡單的Python腳本生成100萬條模擬數(shù)據(jù)包括device_id、order_status、timestamp三個(gè)關(guān)鍵字段輸出成CSV格式python3 /opt/scripts/gen_data.py --rows 1000000 --output /data/input/orders.csv然后把CSV上傳到HDFS的/input目錄hdfs dfs -mkdir -p /input hdfs dfs -put /data/input/orders.csv /input/這時(shí)有個(gè)容易犯的錯(cuò)誤HDFS上的數(shù)據(jù)塊默認(rèn)副本數(shù)為2我們通過hdfs dfs -put上傳的文件實(shí)際會按當(dāng)前集群副本數(shù)存儲。如果需要保存原始日志長期不刪可以把這個(gè)文件目錄單獨(dú)設(shè)置更高的副本數(shù)。Demo階段無所謂但生產(chǎn)環(huán)境要留意。接著執(zhí)行第5節(jié)的寫入端MR作業(yè)將訂單數(shù)據(jù)批量寫入order_info表。提交命令走yarnhadoop jar /opt/jars/WriteOrderToHBase-1.0.jar com.example.WriteOrderToHBase6.3 統(tǒng)計(jì)任務(wù)運(yùn)行結(jié)果與驗(yàn)證寫入完成后執(zhí)行讀取端統(tǒng)計(jì)作業(yè)匯總每個(gè)狀態(tài)的數(shù)量再通過另一個(gè)Mapper按device_id聚合出各自的訂單數(shù)hadoop jar /opt/jars/CountOrderFromHBase-1.0.jar com.example.CountOrderFromHBase作業(yè)跑完我直接在HBase Shell里查詢統(tǒng)計(jì)表hbase shell EOF scan user_order_count, {LIMIT 5} EOF返回結(jié)果里每條rowkey對應(yīng)一個(gè)device_id列cf:order_count就是統(tǒng)計(jì)數(shù)。拿這些數(shù)和原始CSV做對照用wc -l統(tǒng)計(jì)各狀態(tài)總量結(jié)果一致鏈路驗(yàn)證通過。整個(gè)流程跑下來大約耗時(shí)12分鐘其中寫入作業(yè)5分鐘、統(tǒng)計(jì)作業(yè)6分鐘、其余為YARN調(diào)度和HBase flush時(shí)間。相比單機(jī)用awk處理100萬行數(shù)據(jù)這個(gè)速度沒有明顯優(yōu)勢但它的意義在于當(dāng)數(shù)據(jù)量從100萬漲到10億時(shí)這套架構(gòu)的擴(kuò)展性才真正體現(xiàn)出來。6.4 數(shù)據(jù)正確性校驗(yàn)MR結(jié)果與預(yù)期對不上怎么辦第一次跑統(tǒng)計(jì)作業(yè)時(shí)我注意到統(tǒng)計(jì)結(jié)果比預(yù)想的少了一部分?jǐn)?shù)據(jù)。檢查后發(fā)現(xiàn)是Scan的startRow和stopRow沒有設(shè)置好導(dǎo)致漏掉了開頭或結(jié)尾的Region數(shù)據(jù)。排查方法是拿同一批數(shù)據(jù)先后跑兩個(gè)不同Scan范圍的作業(yè)對比輸出條數(shù)與HBase表行數(shù)是否一致hbase org.apache.hadoop.hbase.mapreduce.RowCounter order_info detail:statusRowCounter是HBase自帶的行數(shù)統(tǒng)計(jì)工具它可以繞過MR直接讀取Region元數(shù)據(jù)做精確計(jì)數(shù)。用它作為基準(zhǔn)就能判斷自己的Scan寫漏了還是寫重了。另一個(gè)導(dǎo)致結(jié)果不一致的原因是InputSplit切分時(shí)正好跨越Region邊界某個(gè)分片包含了一個(gè)完整Region的掃描結(jié)果而另一個(gè)分片又從該Region讀了一次重復(fù)數(shù)據(jù)。遇到這種問題把作業(yè)的mapred.reduce.tasks暫時(shí)設(shè)為0觀察Map輸出條數(shù)與RowCounter結(jié)果是否吻合。7. 排障實(shí)錄四類高危問題與排查鏈路7.1 NameNode進(jìn)入安全模式且長時(shí)間不退現(xiàn)象是HDFS啟動后執(zhí)行hdfs dfs -put一直報(bào)錯(cuò)提示“Name node is in safe mode”。剛開始我以為等多一會兒就能自動退出但等了十分鐘依舊卡死。排查鏈路先hdfs dfsadmin -safemode get確認(rèn)狀態(tài)再hdfs dfsadmin -report看DataNode上報(bào)情況。結(jié)果發(fā)現(xiàn)有兩臺DataNode顯示為Dead原因是它們的/data/hadoop/datanode磁盤分區(qū)滿了。DataNode上報(bào)塊信息時(shí)發(fā)現(xiàn)剩余空間不足閾值就主動拒絕注冊NameNode等不到足夠數(shù)量的活動節(jié)點(diǎn)于是遲遲不退出安全模式。解決方式清理磁盤后重啟DataNode再手動執(zhí)行hdfs dfsadmin -safemode leave強(qiáng)制退出。之后的預(yù)防手段是把dfs.datanode.du.reserved設(shè)為一個(gè)絕對值比如10GB讓DataNode認(rèn)為磁盤已滿的空間預(yù)留出來避免磁盤被業(yè)務(wù)數(shù)據(jù)徹底寫滿才觸發(fā)保護(hù)。7.2 HBase RegionServer反復(fù)被移除時(shí)鐘偏移HBase集群另一個(gè)反復(fù)出現(xiàn)的怪象是RegionServer啟動后一兩分鐘就被Master標(biāo)記為DOWN并踢出集群日志顯示“RegionServer is not online”或“Clock skew too large”。根因在HBase的分布式協(xié)調(diào)機(jī)制RegionServer上報(bào)心跳時(shí)Master會校驗(yàn)該節(jié)點(diǎn)與自身的時(shí)間差一旦超過底層連接容忍范圍就判定異常。我在三臺機(jī)器上執(zhí)行date命令發(fā)現(xiàn)node03的系統(tǒng)時(shí)間比node01慢了接近40秒。原因是在部署虛擬機(jī)時(shí)班車時(shí)間同步服務(wù)沒有成功啟動。解決方式安裝chrony并強(qiáng)制校準(zhǔn)一次systemctl restart chronyd chronyc makestep校準(zhǔn)后連續(xù)觀察三天沒有再出現(xiàn)RegionServer掉線。7.3 MapReduce作業(yè)一直Pending不執(zhí)行作業(yè)提交到Y(jié)ARN后狀態(tài)始終停在ACCEPTEDResourceManager頁面顯示容器始終沒有被分配。這個(gè)問題的本質(zhì)是資源調(diào)度失效。排查鏈路先看yarn logs --applicationId檢查ApplicationMaster日志發(fā)現(xiàn)一直等待NODE_IDLE資源再看NodeManager配置發(fā)現(xiàn)yarn.nodemanager.resource.memory-mb默認(rèn)值8192MB大于物理機(jī)可用內(nèi)存NodeManager啟動時(shí)判定物理資源不足主動把可用資源標(biāo)記為0所有作業(yè)只能排隊(duì)。解決方式按第3.2節(jié)調(diào)的參數(shù)改小nodeManager資源上限并重啟NodeManageryarn nodemanager --daemon stop yarn nodemanager --daemon start這里也暴露了另一個(gè)隱藏問題如果你在yarn-site.xml里同時(shí)設(shè)置了yarn.scheduler.maximum-allocation-mb大于physical memory調(diào)度器也會直接拒絕分配容器。7.4 MR寫HBase時(shí)Put超時(shí)與批量重試風(fēng)暴跑寫入作業(yè)時(shí)Map端偶爾報(bào)“Call to node02/... failed on local exception: java.net.SocketTimeoutException”重試幾次后任務(wù)失敗。排查下來發(fā)現(xiàn)是RegionServer上的handler.count默認(rèn)為10而MR的Map Task數(shù)有32個(gè)寫請求并發(fā)一高RegionServer的RPC線程池被打滿SocketTimeout自然頻繁出現(xiàn)。把hbase.regionserver.handler.count調(diào)到30并把hbase.client.retries.number適當(dāng)調(diào)低避免無謂的重試風(fēng)暴property namehbase.client.retries.number/name value3/value /property重試次數(shù)默認(rèn)是10次在批量寫入場景里10次重試會拖慢整個(gè)作業(yè)。調(diào)到3次后失敗任務(wù)快速失敗并由MR框架重新調(diào)度整體成功率反而更高。注意這里的取舍在線查詢場景下重試次數(shù)不宜太低否則瞬時(shí)網(wǎng)絡(luò)抖動會直接丟請求。7.5 一個(gè)容易被忽視的元兇文件句柄耗盡最后說一個(gè)讓DataNode和RegionServer同時(shí)異常退出的共性問題文件句柄耗盡。我們有一臺機(jī)器曾經(jīng)在一周內(nèi)突然出現(xiàn)DataNode退出的告警但日志里沒有任何異常堆棧最后看了dmesg才發(fā)現(xiàn)大量“too many open files”信息。Linux默認(rèn)單進(jìn)程文件句柄限制是1024對HDFS這種大量打開小文件的系統(tǒng)來說遠(yuǎn)遠(yuǎn)不夠。按第2.2節(jié)的limits.conf提高上限后務(wù)必重啟DataNode、RegionServer等守護(hù)進(jìn)程因?yàn)閘imits.conf對已經(jīng)啟動的進(jìn)程不生效。我還額外在hbase-env.sh里加了一句ulimit -n 65536這確實(shí)是個(gè)偏門的兜底方式但能確保即使limits.conf被某些初始化腳本覆蓋HBase進(jìn)程依然有充足句柄額度。最后再分享兩個(gè)擴(kuò)展方向如果這篇文章只幫你把環(huán)境搭起來那任務(wù)只完成了一半。跑通Demo之后我強(qiáng)烈建議在同一個(gè)集群上嘗試兩個(gè)方向一是集成Hive把HBase通過StorageHandler映射成外部表這樣運(yùn)營同學(xué)能用SQL查HBase數(shù)據(jù)不需要寫Java代碼二是給HBase加Phoenix或換個(gè)思路直接用Spark讀取HBase這些上層引擎可以復(fù)用同一套HDFS存儲不會額外增加運(yùn)維復(fù)雜度。我在實(shí)際項(xiàng)目中因?yàn)樵诮ū黼A段就規(guī)劃好了預(yù)分區(qū)和壓縮后續(xù)接入Hive和Spark都沒有返工。愿這篇文章能讓你少走點(diǎn)彎路尤其是第7節(jié)那些問題趁早排查總比上線當(dāng)晚發(fā)現(xiàn)好。 Hadoop+MapReduce+HBase離線日志分析集群搭建實(shí)戰(zhàn)
最近有個(gè)項(xiàng)目要做離線日志分析和實(shí)時(shí)查詢數(shù)據(jù)量不大但增長很快我們最后選擇了CentOS 8.1 Hadoop MapReduce HBase這套組合。這套方案最直接的優(yōu)勢在于Hadoop負(fù)責(zé)海量文件的分布式存儲MapReduce處理批量計(jì)算HBase承接最終結(jié)果的高效查詢各司其職又天然配套。這篇文章就復(fù)現(xiàn)一下當(dāng)時(shí)從零搭建環(huán)境、跑通全流程的完整過程適合剛接觸大數(shù)據(jù)生態(tài)、或者準(zhǔn)備在本地/測試環(huán)境構(gòu)建這套技術(shù)棧的讀者參考。為了避免紙上談兵我會先講清楚技術(shù)選型的判斷邏輯再逐步拆解三節(jié)點(diǎn)集群的環(huán)境初始化、Hadoop核心配置、HBase與Hadoop的集成要點(diǎn)最后用一個(gè)可復(fù)現(xiàn)的離線訂單統(tǒng)計(jì)Demo串聯(lián)MapReduce讀寫HBase的代碼鏈路。整個(gè)過程盡量落在具體命令和參數(shù)上也會把踩過的坑原樣交代出來。1. 為什么選CentOS 8.1HadoopHBase從業(yè)務(wù)需求反推技術(shù)棧1.1 業(yè)務(wù)場景倒逼出的存儲與計(jì)算架構(gòu)先說背景。我們接到的任務(wù)是處理某智能硬件每日產(chǎn)生的設(shè)備上報(bào)日志單日數(shù)據(jù)量在2000萬條左右原始文件以JSON格式落盤總量約15GB。需求有兩層一是定期把這些日志做清洗、聚合算出一系列統(tǒng)計(jì)指標(biāo)二是運(yùn)營后臺要能按設(shè)備ID或時(shí)間范圍快速查出明細(xì)。針對這類場景我首先排除掉傳統(tǒng)關(guān)系型數(shù)據(jù)庫。按單日2000萬條來算一個(gè)月就是6億行MySQL即使分庫分表也扛不住這種寫入壓力更別說后臺還要求毫秒級的在線查詢。于是存儲層選擇了HBase理由很實(shí)際它天生支持稀疏寬表rowkey設(shè)計(jì)得當(dāng)就能讓查詢直接命中某個(gè)Region不需要像Hive那樣啟動一個(gè)大任務(wù)去掃全表同時(shí)它可以建立在HDFS之上直接復(fù)用Hadoop的副本機(jī)制不用額外維護(hù)一套持久化鏈路。計(jì)算層選MapReduce是因?yàn)檫@個(gè)項(xiàng)目對實(shí)時(shí)性沒有過高要求統(tǒng)計(jì)任務(wù)在每天凌晨跑一次T1出結(jié)果完全能接受。MapReduce雖被人詬病“笨重”但在這類離線批處理上是極其穩(wěn)定的提交一個(gè)作業(yè)YARN負(fù)責(zé)分配資源任務(wù)失敗自動重試不需要額外部署Spark之類的計(jì)算引擎?？紤]到團(tuán)隊(duì)后續(xù)還打算引入Hive做SQL化分析Hadoop這套底層更是繞不開的依賴。1.2 版本選擇與兼容性這道坎版本組合必須提前定死否則后面全是淚。我經(jīng)過踩坑后固定下來的版本是CentOS 8.1 JDK 1.88u212 Hadoop 3.2.4 HBase 2.4.17 ZooKeeper 3.6.3。有人可能問CentOS 8.1已經(jīng)停止維護(hù)了為什么還要選它。這里有個(gè)現(xiàn)實(shí)原因項(xiàng)目現(xiàn)場那批服務(wù)器出廠預(yù)裝的就是8.1且業(yè)務(wù)方短期沒有遷移計(jì)劃。如果你是從零規(guī)劃用CentOS 7.9或Rocky Linux完全沒問題本文的部署命令除了yum源細(xì)節(jié)外基本通用。兼容性上特別注意兩點(diǎn)Hadoop 3.2.x系列官方支持JDK 8必須避開JDK 11因?yàn)镠adoop 3.2雖然能在JDK 11上啟動但很多第三方插件會發(fā)現(xiàn)ClassNotFound或SecurityManager異常HBase 2.4.x官方兼容矩陣?yán)锩鞔_列出的Hadoop版本是3.2.x如果你硬要配Hadoop 3.3.x很可能在HBase Master啟動時(shí)碰到protobuf版本沖突。組件版本備注操作系統(tǒng)CentOS 8.1內(nèi)核4.18若生產(chǎn)環(huán)境建議7.9或更新替代版JDK1.8.0_212不要用JDK 11跑Hadoop 3.2Hadoop3.2.4含HDFS和YARN計(jì)算層用MRHBase2.4.17與Hadoop 3.2.x官方兼容ZooKeeper3.6.3用于HBase協(xié)調(diào)生產(chǎn)必須獨(dú)立部署部署方式三節(jié)點(diǎn)1臺Master 2臺Worker2. 三節(jié)點(diǎn)集群環(huán)境初始化那些不寫進(jìn)官方文檔的細(xì)節(jié)2.1 主機(jī)規(guī)劃與SSH免密登錄配置我這邊準(zhǔn)備了3臺虛擬機(jī)每臺分配4核CPU、8GB內(nèi)存、100GB磁盤。主機(jī)名分別規(guī)劃為node01、node02、node03其中node01跑NameNode、ResourceManager、HMasternode02和node03作為DataNode和RegionServer。ZooKeeper三臺都放一份構(gòu)成3節(jié)點(diǎn)ZooKeeper集群。開始部署前先把每臺機(jī)器的hostname和/etc/hosts整明白這個(gè)環(huán)節(jié)出問題會導(dǎo)致后面HBase RegionServer注冊不上我第7節(jié)會專門講。hostnamectl set-hostname node01 cat /etc/hosts EOF 192.168.10.11 node01 192.168.10.12 node02 192.168.10.13 node03 EOFSSH免密登錄是啟動Hadoop腳本的硬前提否則每次啟動都得輸密碼。我在node01上執(zhí)行ssh-keygen -t rsa -P -f ~/.ssh/id_rsa ssh-copy-id node01 ssh-copy-id node02 ssh-copy-id node03注意Hadoop部分命令是通過rpc遠(yuǎn)程調(diào)用執(zhí)行的所以node01必須能免密登錄到所有節(jié)點(diǎn)。HBase啟動時(shí)也會經(jīng)由Master去SSH到各臺RegionServer拉起進(jìn)程這個(gè)權(quán)限同樣需要提前打通。2.2 JDK安裝與系統(tǒng)參數(shù)調(diào)整Hadoop 3.x對系統(tǒng)的要求比舊版嚴(yán)格文件句柄打開數(shù)和進(jìn)程數(shù)必須改否則運(yùn)行一段時(shí)間后DataNode會報(bào)“Too many open files”。我用root用戶完成以下配置yum install -y java-1.8.0-openjdk java-1.8.0-openjdk-devel cat /etc/security/limits.conf EOF * soft nofile 65536 * hard nofile 131072 * soft nproc 65536 * hard nproc 131072 EOF同時(shí)三臺機(jī)器都執(zhí)行關(guān)閉防火墻和SELinux。很多初學(xué)者跳過這步然后發(fā)現(xiàn)9000端口、16010端口對外不通排查半天方向完全錯(cuò)了systemctl stop firewalld systemctl disable firewalld sed -i s/^SELINUX.*/SELINUXdisabled/ /etc/selinux/config setenforce 0時(shí)間同步是另一個(gè)大坑。HBase的RegionServer非常依賴集群時(shí)鐘一致如果節(jié)點(diǎn)間時(shí)間偏差超過30秒HBase Master會把RegionServer直接踢下線。我這里用最簡單的方式配置NTP指向一臺內(nèi)網(wǎng)時(shí)間源yum install -y chrony sed -i 3,6s/^pool/server 192.168.10.1 iburst/ /etc/chrony.conf sed -i s/^pool.*/# pool./ /etc/chrony.conf systemctl restart chronyd chronyc sources -v2.3 軟件包目錄規(guī)劃與環(huán)境變量統(tǒng)一Hadoop和HBase都解壓在/opt目錄下通過軟鏈指向具體版本這樣后續(xù)升級版本不用改一大堆配置。我按自己的習(xí)慣創(chuàng)建了如下布局/opt/hadoop-3.2.4 - /opt/hadoop /opt/hbase-2.4.17 - /opt/hbase /opt/zookeeper-3.6.3 - /opt/zookeeper環(huán)境變量統(tǒng)一寫入/etc/profile.d/bigdata.sh讓所有節(jié)點(diǎn)加載同一份內(nèi)容export JAVA_HOME/usr/lib/jvm/java-1.8.0-openjdk export HADOOP_HOME/opt/hadoop export HBASE_HOME/opt/hbase export ZOOKEEPER_HOME/opt/zookeeper export PATH$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin:$HBASE_HOME/bin:$ZOOKEEPER_HOME/bin這里有個(gè)建議不要用root用戶運(yùn)行大數(shù)據(jù)組件因?yàn)镠adoop在安全檢查上對root有額外限制。我創(chuàng)建了一個(gè)hadoop用戶把/opt/hadoop、/opt/hbase、/opt/zookeeper三目錄的屬主都改到該用戶下后續(xù)所有啟停操作都切到這個(gè)用戶執(zhí)行。3. Hadoop核心配置逐項(xiàng)拆解不只是照抄官方模板3.1 core-site.xml與hdfs-site.xml的關(guān)鍵參數(shù)Hadoop部署最忌諱拿一個(gè)模板到處拷貝卻不理解每個(gè)參數(shù)的含義。我這份配置是在排掉三個(gè)不同問題后最終定稿的。core-site.xml里最關(guān)鍵的是fs.defaultFS它決定了整個(gè)集群的“根文件系統(tǒng)”指向哪里。我設(shè)置為hdfs://node01:9000后面的9000是NameNode RPC端口。hadoop.tmp.dir則指定了HDFS元數(shù)據(jù)等臨時(shí)文件的存放路徑獨(dú)立掛載的磁盤比系統(tǒng)盤更穩(wěn)妥configuration property namefs.defaultFS/name valuehdfs://node01:9000/value /property property namehadoop.tmp.dir/name value/data/hadoop/tmp/value /property /configurationhdfs-site.xml這里重點(diǎn)配置了三項(xiàng)副本數(shù)、NameNode元數(shù)據(jù)目錄、DataNode數(shù)據(jù)目錄。由于節(jié)點(diǎn)數(shù)只有3我設(shè)置dfs.replication為2既保證容錯(cuò)又節(jié)省一半存儲若數(shù)據(jù)重要程度高保持默認(rèn)的3也不是問題configuration property namedfs.replication/name value2/value /property property namedfs.namenode.name.dir/name valuefile:///data/hadoop/namenode/value /property property namedfs.datanode.data.dir/name valuefile:///data/hadoop/datanode/value /property property namedfs.namenode.handler.count/name value100/value /property /configurationdfs.namenode.handler.count這項(xiàng)容易被忽略并發(fā)請求一多NameNode會成為瓶頸。經(jīng)驗(yàn)值上4核機(jī)器配100足夠線程過多反而加大上下文切換開銷。3.2 YARN資源削峰小內(nèi)存機(jī)器的保命配置Hadoop 3.2.4的默認(rèn)配置是按大內(nèi)存機(jī)器設(shè)計(jì)的ResourceManager默認(rèn)會為每個(gè)容器分配很大的內(nèi)存如果你直接在小內(nèi)存機(jī)器上提交任務(wù)會看到作業(yè)無限期pending。我在這臺8GB內(nèi)存的節(jié)點(diǎn)上做了如下收斂configuration property nameyarn.nodemanager.resource.memory-mb/name value6144/value /property property nameyarn.nodemanager.resource.cpu-vcores/name value4/value /property property nameyarn.scheduler.minimum-allocation-mb/name value1024/value /property property nameyarn.scheduler.maximum-allocation-mb/name value3072/value /property /configuration這里計(jì)算邏輯是系統(tǒng)自身占用約1.5GBZooKeeper和HBase還需要各自預(yù)留內(nèi)存真正能分給YARN的只有6GB左右。maximum-allocation-mb設(shè)得比剛提交的MR任務(wù)所需更大同時(shí)minimum設(shè)為1GB避免小任務(wù)也要湊出一個(gè)大容器。3.3 格式化NameNode與安全模式處置首次啟動HDFS前必須格式化NameNode這一步會在namenode目錄生成fsimage。格式化命令要注意只需在node01執(zhí)行一次執(zhí)行前確認(rèn)core-site.xml和hdfs-site.xml已經(jīng)分發(fā)到所有節(jié)點(diǎn)hdfs namenode -format格式化完成后在node01上執(zhí)行start-dfs.sh在node02和node03執(zhí)行start-yarn.sh。為什么分開因?yàn)槲覀儼裄esourceManager放在了node01但NodeManager需要在每個(gè)節(jié)點(diǎn)拉起。配置文件里通過yarn-site.xml的yarn.resourcemanager.hostname指定node01。啟動后第一件事不是急著看日志而是確認(rèn)HDFS狀態(tài)退出安全模式。安全模式是HDFS啟動后自動進(jìn)入的保護(hù)期此間不允許寫數(shù)據(jù)只能等待各DataNode上報(bào)塊信息hdfs dfsadmin -safemode get hdfs dfsadmin -safemode leave hdfs dfsadmin -report如果report里顯示的Live datanode數(shù)量小于3多半是DataNode沒起來或者被防火墻擋了。一個(gè)比較隱蔽的原因是DataNode進(jìn)程起來后遇到磁盤空間不足主動退出這時(shí)候datanode日志會顯示“Data volume failed”字樣我第7節(jié)會專門復(fù)盤。4. HBase集成Hadoop的版本兼容與參數(shù)調(diào)優(yōu)4.1 為什么非要獨(dú)立ZooKeeperHBase的HMasia正常情況下需要ZooKeeper來協(xié)調(diào)RegionServer與Master之間的心跳以及保存meta表的位置信息。HBase內(nèi)置ZooKeeper在開發(fā)環(huán)境圖省事可以直接啟用但生產(chǎn)環(huán)境三節(jié)點(diǎn)的集群我選擇獨(dú)立部署ZooKeeper否則一旦HBase一停ZooKeeper也跟著沒了后續(xù)想用HBASE自帶工具排查問題非常別扭。ZooKeeper的配置文件zoo.cfg里只改三個(gè)地方dataDir、clientPort、server列表。dataDir建議放在獨(dú)立磁盤server.1、server.2、server.3必須與三臺機(jī)器對應(yīng)每臺機(jī)器都要?jiǎng)?chuàng)建myid文件并寫入對應(yīng)數(shù)字。dataDir/data/zookeeper server.1node01:2888:3888 server.2node02:2888:3888 server.3node03:2888:3888ZooKeeper啟動順序也有講究三臺各自執(zhí)行zkServer.sh start后用zkServer.sh status確認(rèn)其中一臺leader、兩臺follower任何一個(gè)節(jié)點(diǎn)狀態(tài)為standalone都是沒搭成功。4.2 hbase-site.xml里容易被誤解的配置項(xiàng)HBase集成Hadoop的核心配置有四個(gè)維度rootdir、zookeeper地址、RegionServer相關(guān)調(diào)優(yōu)、以及容錯(cuò)參數(shù)。我貼一版實(shí)際穩(wěn)定運(yùn)行很久的配置configuration property namehbase.rootdir/name valuehdfs://node01:9000/hbase/value /property property namehbase.cluster.distributed/name valuetrue/value /property property namehbase.zookeeper.quorum/name valuenode01,node02,node03/value /property property namehbase.zookeeper.property.clientPort/name value2181/value /property property namehbase.regionserver.handler.count/name value30/value /property property namehbase.hregion.memstore.flush.size/name value134217728/value /property property namehbase.client.write.buffer/name value8388608/value /property /configurationhbase.rootdir必須帶上完整的HDFS路徑不要只寫到node01:9000這一層否則HBase會試圖把表數(shù)據(jù)寫到根路徑下與HDFS的目錄結(jié)構(gòu)混淆。hbase.cluster.distributed必須設(shè)為true否則HBase認(rèn)為你是單機(jī)模式根本不會往HDFS寫數(shù)據(jù)。hbase.regionserver.handler.count可以直接理解為RegionServer同時(shí)能處理的RPC請求數(shù)這個(gè)值設(shè)得太大沒什么意義因?yàn)镃PU核數(shù)有限并發(fā)請求再多也是排隊(duì)設(shè)得太小MR任務(wù)批量寫入時(shí)會頻繁報(bào)超時(shí)。30是我在4核環(huán)境下的經(jīng)驗(yàn)值。4.3 RegionServer的目錄分區(qū)與內(nèi)存比例HBase要求每臺RegionServer在本地保存寫前日志W(wǎng)AL這個(gè)路徑默認(rèn)在hbase.tmp.dir下通常會被系統(tǒng)盤限制住。我在每臺機(jī)器上單獨(dú)掛載了/data/hbase并在hbase-env.sh里設(shè)置HBASE_LOG_DIR和堆大小。內(nèi)存分配是HBase最容易崩潰的根源。默認(rèn)情況下HBase的RegionServer堆大小是1GB但面對較大的寫緩存或讀緩存時(shí)1GB完全不夠GC頻繁觸發(fā)stop-the-world最終被Master判定心跳超時(shí)而移除。我把HBASE_HEAPSIZE調(diào)到4GB同時(shí)確保YARN的NodeManager不會把內(nèi)存全部搶走畢竟它們在同一臺物理機(jī)上。這里有個(gè)細(xì)節(jié)如果你的MapReduce作業(yè)會直接讀寫HBase就必須在MR JVM和HBase RegionServer之間留出足夠空間。我當(dāng)時(shí)設(shè)置時(shí)每臺機(jī)器給YARN 6GB、給HBase 4GB再加系統(tǒng)1.5GB剛好超出8GB一點(diǎn)于是又把HBase堆降到3.5GB留出余量這才穩(wěn)定下來。5. MapReduce直連HBase讀寫兩端的代碼實(shí)現(xiàn)5.1 為什么要讓MR直接讀寫HBase離線統(tǒng)計(jì)任務(wù)的典型流程是先由MR讀取HDFS上的日志文件做清洗然后把聚合結(jié)果寫入HBase供查詢端讀取。這里有兩種方案一種是把MR結(jié)果落地成HDFS文件再由HBase做bulk load另一種是MR直接通過TableOutputFormat寫入HBase。我選擇后者因?yàn)轫?xiàng)目表數(shù)據(jù)量還達(dá)不到幾十TB需要bulk load的規(guī)模直接寫更省事代碼也更直觀。但前提是你得搞清楚TableOutputFormat和TableInputFormat的用法以及它們對MR job設(shè)置的特殊要求。5.2 寫入端用TableOutputFormat把計(jì)算結(jié)果落到HBase寫入端的核心思路是Mapper的輸出key為ImmutableBytesWritable或NullWritablevalue為Put對象。TableOutputFormat的OutputCommitter會把這些Put按所屬Region分發(fā)到正確的RegionServer整個(gè)過程不需要reduce參與。以下是我項(xiàng)目里把訂單統(tǒng)計(jì)結(jié)果寫入HBase訂單表的Mapper代碼核心部分public static class WriteMapper extends MapperLongWritable, Text, NullWritable, Put { private byte[] family Bytes.toBytes(detail); Override protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException { String[] fields value.toString().split(,); String orderId ord_ fields[0]; Put put new Put(Bytes.toBytes(saltKey(orderId) orderId)); put.addColumn(family, Bytes.toBytes(device_id), Bytes.toBytes(fields[1])); put.addColumn(family, Bytes.toBytes(status), Bytes.toBytes(fields[2])); put.addColumn(family, Bytes.toBytes(timestamp), Bytes.toBytes(Long.parseLong(fields[3]))); context.write(NullWritable.get(), put); } private String saltKey(String orderId) { int hash Math.abs(orderId.hashCode() % 8); return String.valueOf(hash); } }saltKey函數(shù)是rowkey預(yù)分區(qū)的一種簡單實(shí)現(xiàn)。HBase按rowkey的字典序把數(shù)據(jù)分布到各個(gè)Region如果直接用自增ID或時(shí)間戳當(dāng)rowkey寫入熱點(diǎn)會集中在最后一個(gè)Region。我按訂單ID哈希取0到7的前綴加上前綴后數(shù)據(jù)能均勻落到默認(rèn)8個(gè)預(yù)分區(qū)里。作業(yè)配置上關(guān)鍵點(diǎn)是必須指定輸出表名和輸出格式Job job Job.getInstance(conf, WriteOrderToHBase); job.setJarByClass(WriteOrderToHBase.class); job.setMapperClass(WriteMapper.class); job.setNumReduceTasks(0); job.setMapOutputKeyClass(NullWritable.class); job.setMapOutputValueClass(Put.class); job.setOutputFormatClass(TableOutputFormat.class); job.getConfiguration().set(TableOutputFormat.OUTPUT_TABLE, order_info);注意TableOutputFormat會主動讀取TableName參數(shù)如果你的代碼里沒有set輸出表運(yùn)行時(shí)大概率報(bào)“Cannot resolve output table”之類異常。另一個(gè)容易踩的坑是TableOutputFormat要求作業(yè)輸出Path不能重復(fù)文件所以每次跑任務(wù)前最好清理輸出目錄或使用動態(tài)路徑。5.3 讀取端用TableInputFormatScan做批量分析讀取端是另一個(gè)鏡像問題把一張HBase表作為MR的輸入源。關(guān)鍵API是TableMapReduceUtil.initTableMapperJob它會基于Scan自動創(chuàng)建InputFormat并切分InputSplitpublic static class ReadMapper extends TableMapperText, IntWritable { private Text outKey new Text(); Override protected void map(ImmutableBytesWritable rowKey, Result result, Context context) throws IOException, InterruptedException { String status Bytes.toString( result.getValue(Bytes.toBytes(detail), Bytes.toBytes(status))); outKey.set(status); context.write(outKey, new IntWritable(1)); } }作業(yè)初始化時(shí)需要構(gòu)建Scan對象并傳入需要讀取的列族Scan默認(rèn)全表掃描所有列族全部版本導(dǎo)致網(wǎng)絡(luò)IO暴增。推薦的寫法是Scan scan new Scan(); scan.addFamily(Bytes.toBytes(detail)); scan.setCaching(500); scan.setCacheBlock(false); TableMapReduceUtil.initTableMapperJob( order_info, scan, ReadMapper.class, Text.class, IntWritable.class, job);scan.setCaching默認(rèn)值是100設(shè)為500能減少客戶端與RegionServer的RPC次數(shù)代價(jià)是占用更多客戶端堆內(nèi)存。scan.setCacheBlock(false)是關(guān)鍵性能開關(guān)——它告訴RegionServer在掃描過程中不要將數(shù)據(jù)塊駐留在堆緩存中因?yàn)榇笈縎can很快就會把BlockCache擠滿導(dǎo)致熱點(diǎn)隨機(jī)讀性能大幅下降。對于離線MR任務(wù)這幾乎是必須調(diào)的一項(xiàng)。6. 離線訂單統(tǒng)計(jì)Demo從建表到MR任務(wù)結(jié)果全流程驗(yàn)證6.1 表設(shè)計(jì)rowkey鹽值前綴與列族規(guī)劃整個(gè)Demo圍繞一個(gè)虛構(gòu)的“設(shè)備訂單上報(bào)系統(tǒng)”展開。每天有設(shè)備上報(bào)訂單狀態(tài)我們需要在第二天凌晨統(tǒng)計(jì)每臺設(shè)備當(dāng)天的訂單總數(shù)以及各狀態(tài)占比。HBase里建兩張表order_info存訂單明細(xì)user_order_count存每個(gè)人/設(shè)備的統(tǒng)計(jì)結(jié)果。通過HBase Shell建表時(shí)我特意加了預(yù)分區(qū)和壓縮hbase shell EOF create order_info, {NAME detail, COMPRESSION SNAPPY, TTL 604800}, {SPLITS [0,1,2,3,4,5,6,7]} create user_order_count, {NAME cf}, {SPLITS [a,m,z]} EOF預(yù)分區(qū)數(shù)量不必太多8個(gè)Region對于一個(gè)測試集群足夠但已經(jīng)能演示“寫入分散到多個(gè)RegionServer”的效果。TTL設(shè)置為7天讓過期明細(xì)自動清理省去后續(xù)手動刪除數(shù)據(jù)的麻煩。SNAPPY壓縮是我強(qiáng)烈推薦在生產(chǎn)表開啟的選項(xiàng)它在CPU消耗和壓縮比之間平衡最好。需要說明的是如果你啟用SNAPPY所有RegionServer節(jié)點(diǎn)必須安裝libsnappy庫否則HBase寫入時(shí)會報(bào)壓縮編解碼器無法加載。6.2 造數(shù)腳本與數(shù)據(jù)導(dǎo)入鏈路的坑為了驗(yàn)證整條鏈路我寫了一個(gè)簡單的Python腳本生成100萬條模擬數(shù)據(jù)包括device_id、order_status、timestamp三個(gè)關(guān)鍵字段輸出成CSV格式python3 /opt/scripts/gen_data.py --rows 1000000 --output /data/input/orders.csv然后把CSV上傳到HDFS的/input目錄hdfs dfs -mkdir -p /input hdfs dfs -put /data/input/orders.csv /input/這時(shí)有個(gè)容易犯的錯(cuò)誤HDFS上的數(shù)據(jù)塊默認(rèn)副本數(shù)為2我們通過hdfs dfs -put上傳的文件實(shí)際會按當(dāng)前集群副本數(shù)存儲。如果需要保存原始日志長期不刪可以把這個(gè)文件目錄單獨(dú)設(shè)置更高的副本數(shù)。Demo階段無所謂但生產(chǎn)環(huán)境要留意。接著執(zhí)行第5節(jié)的寫入端MR作業(yè)將訂單數(shù)據(jù)批量寫入order_info表。提交命令走yarnhadoop jar /opt/jars/WriteOrderToHBase-1.0.jar com.example.WriteOrderToHBase6.3 統(tǒng)計(jì)任務(wù)運(yùn)行結(jié)果與驗(yàn)證寫入完成后執(zhí)行讀取端統(tǒng)計(jì)作業(yè)匯總每個(gè)狀態(tài)的數(shù)量再通過另一個(gè)Mapper按device_id聚合出各自的訂單數(shù)hadoop jar /opt/jars/CountOrderFromHBase-1.0.jar com.example.CountOrderFromHBase作業(yè)跑完我直接在HBase Shell里查詢統(tǒng)計(jì)表hbase shell EOF scan user_order_count, {LIMIT 5} EOF返回結(jié)果里每條rowkey對應(yīng)一個(gè)device_id列cf:order_count就是統(tǒng)計(jì)數(shù)。拿這些數(shù)和原始CSV做對照用wc -l統(tǒng)計(jì)各狀態(tài)總量結(jié)果一致鏈路驗(yàn)證通過。整個(gè)流程跑下來大約耗時(shí)12分鐘其中寫入作業(yè)5分鐘、統(tǒng)計(jì)作業(yè)6分鐘、其余為YARN調(diào)度和HBase flush時(shí)間。相比單機(jī)用awk處理100萬行數(shù)據(jù)這個(gè)速度沒有明顯優(yōu)勢但它的意義在于當(dāng)數(shù)據(jù)量從100萬漲到10億時(shí)這套架構(gòu)的擴(kuò)展性才真正體現(xiàn)出來。6.4 數(shù)據(jù)正確性校驗(yàn)MR結(jié)果與預(yù)期對不上怎么辦第一次跑統(tǒng)計(jì)作業(yè)時(shí)我注意到統(tǒng)計(jì)結(jié)果比預(yù)想的少了一部分?jǐn)?shù)據(jù)。檢查后發(fā)現(xiàn)是Scan的startRow和stopRow沒有設(shè)置好導(dǎo)致漏掉了開頭或結(jié)尾的Region數(shù)據(jù)。排查方法是拿同一批數(shù)據(jù)先后跑兩個(gè)不同Scan范圍的作業(yè)對比輸出條數(shù)與HBase表行數(shù)是否一致hbase org.apache.hadoop.hbase.mapreduce.RowCounter order_info detail:statusRowCounter是HBase自帶的行數(shù)統(tǒng)計(jì)工具它可以繞過MR直接讀取Region元數(shù)據(jù)做精確計(jì)數(shù)。用它作為基準(zhǔn)就能判斷自己的Scan寫漏了還是寫重了。另一個(gè)導(dǎo)致結(jié)果不一致的原因是InputSplit切分時(shí)正好跨越Region邊界某個(gè)分片包含了一個(gè)完整Region的掃描結(jié)果而另一個(gè)分片又從該Region讀了一次重復(fù)數(shù)據(jù)。遇到這種問題把作業(yè)的mapred.reduce.tasks暫時(shí)設(shè)為0觀察Map輸出條數(shù)與RowCounter結(jié)果是否吻合。7. 排障實(shí)錄四類高危問題與排查鏈路7.1 NameNode進(jìn)入安全模式且長時(shí)間不退現(xiàn)象是HDFS啟動后執(zhí)行hdfs dfs -put一直報(bào)錯(cuò)提示“Name node is in safe mode”。剛開始我以為等多一會兒就能自動退出但等了十分鐘依舊卡死。排查鏈路先hdfs dfsadmin -safemode get確認(rèn)狀態(tài)再hdfs dfsadmin -report看DataNode上報(bào)情況。結(jié)果發(fā)現(xiàn)有兩臺DataNode顯示為Dead原因是它們的/data/hadoop/datanode磁盤分區(qū)滿了。DataNode上報(bào)塊信息時(shí)發(fā)現(xiàn)剩余空間不足閾值就主動拒絕注冊NameNode等不到足夠數(shù)量的活動節(jié)點(diǎn)于是遲遲不退出安全模式。解決方式清理磁盤后重啟DataNode再手動執(zhí)行hdfs dfsadmin -safemode leave強(qiáng)制退出。之后的預(yù)防手段是把dfs.datanode.du.reserved設(shè)為一個(gè)絕對值比如10GB讓DataNode認(rèn)為磁盤已滿的空間預(yù)留出來避免磁盤被業(yè)務(wù)數(shù)據(jù)徹底寫滿才觸發(fā)保護(hù)。7.2 HBase RegionServer反復(fù)被移除時(shí)鐘偏移HBase集群另一個(gè)反復(fù)出現(xiàn)的怪象是RegionServer啟動后一兩分鐘就被Master標(biāo)記為DOWN并踢出集群日志顯示“RegionServer is not online”或“Clock skew too large”。根因在HBase的分布式協(xié)調(diào)機(jī)制RegionServer上報(bào)心跳時(shí)Master會校驗(yàn)該節(jié)點(diǎn)與自身的時(shí)間差一旦超過底層連接容忍范圍就判定異常。我在三臺機(jī)器上執(zhí)行date命令發(fā)現(xiàn)node03的系統(tǒng)時(shí)間比node01慢了接近40秒。原因是在部署虛擬機(jī)時(shí)班車時(shí)間同步服務(wù)沒有成功啟動。解決方式安裝chrony并強(qiáng)制校準(zhǔn)一次systemctl restart chronyd chronyc makestep校準(zhǔn)后連續(xù)觀察三天沒有再出現(xiàn)RegionServer掉線。7.3 MapReduce作業(yè)一直Pending不執(zhí)行作業(yè)提交到Y(jié)ARN后狀態(tài)始終停在ACCEPTEDResourceManager頁面顯示容器始終沒有被分配。這個(gè)問題的本質(zhì)是資源調(diào)度失效。排查鏈路先看yarn logs --applicationId檢查ApplicationMaster日志發(fā)現(xiàn)一直等待NODE_IDLE資源再看NodeManager配置發(fā)現(xiàn)yarn.nodemanager.resource.memory-mb默認(rèn)值8192MB大于物理機(jī)可用內(nèi)存NodeManager啟動時(shí)判定物理資源不足主動把可用資源標(biāo)記為0所有作業(yè)只能排隊(duì)。解決方式按第3.2節(jié)調(diào)的參數(shù)改小nodeManager資源上限并重啟NodeManageryarn nodemanager --daemon stop yarn nodemanager --daemon start這里也暴露了另一個(gè)隱藏問題如果你在yarn-site.xml里同時(shí)設(shè)置了yarn.scheduler.maximum-allocation-mb大于physical memory調(diào)度器也會直接拒絕分配容器。7.4 MR寫HBase時(shí)Put超時(shí)與批量重試風(fēng)暴跑寫入作業(yè)時(shí)Map端偶爾報(bào)“Call to node02/... failed on local exception: java.net.SocketTimeoutException”重試幾次后任務(wù)失敗。排查下來發(fā)現(xiàn)是RegionServer上的handler.count默認(rèn)為10而MR的Map Task數(shù)有32個(gè)寫請求并發(fā)一高RegionServer的RPC線程池被打滿SocketTimeout自然頻繁出現(xiàn)。把hbase.regionserver.handler.count調(diào)到30并把hbase.client.retries.number適當(dāng)調(diào)低避免無謂的重試風(fēng)暴property namehbase.client.retries.number/name value3/value /property重試次數(shù)默認(rèn)是10次在批量寫入場景里10次重試會拖慢整個(gè)作業(yè)。調(diào)到3次后失敗任務(wù)快速失敗并由MR框架重新調(diào)度整體成功率反而更高。注意這里的取舍在線查詢場景下重試次數(shù)不宜太低否則瞬時(shí)網(wǎng)絡(luò)抖動會直接丟請求。7.5 一個(gè)容易被忽視的元兇文件句柄耗盡最后說一個(gè)讓DataNode和RegionServer同時(shí)異常退出的共性問題文件句柄耗盡。我們有一臺機(jī)器曾經(jīng)在一周內(nèi)突然出現(xiàn)DataNode退出的告警但日志里沒有任何異常堆棧最后看了dmesg才發(fā)現(xiàn)大量“too many open files”信息。Linux默認(rèn)單進(jìn)程文件句柄限制是1024對HDFS這種大量打開小文件的系統(tǒng)來說遠(yuǎn)遠(yuǎn)不夠。按第2.2節(jié)的limits.conf提高上限后務(wù)必重啟DataNode、RegionServer等守護(hù)進(jìn)程因?yàn)閘imits.conf對已經(jīng)啟動的進(jìn)程不生效。我還額外在hbase-env.sh里加了一句ulimit -n 65536這確實(shí)是個(gè)偏門的兜底方式但能確保即使limits.conf被某些初始化腳本覆蓋HBase進(jìn)程依然有充足句柄額度。最后再分享兩個(gè)擴(kuò)展方向如果這篇文章只幫你把環(huán)境搭起來那任務(wù)只完成了一半。跑通Demo之后我強(qiáng)烈建議在同一個(gè)集群上嘗試兩個(gè)方向一是集成Hive把HBase通過StorageHandler映射成外部表這樣運(yùn)營同學(xué)能用SQL查HBase數(shù)據(jù)不需要寫Java代碼二是給HBase加Phoenix或換個(gè)思路直接用Spark讀取HBase這些上層引擎可以復(fù)用同一套HDFS存儲不會額外增加運(yùn)維復(fù)雜度。我在實(shí)際項(xiàng)目中因?yàn)樵诮ū黼A段就規(guī)劃好了預(yù)分區(qū)和壓縮后續(xù)接入Hive和Spark都沒有返工。愿這篇文章能讓你少走點(diǎn)彎路尤其是第7節(jié)那些問題趁早排查總比上線當(dāng)晚發(fā)現(xiàn)好。