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