習(xí)實(shí)戰(zhàn)筆記：從核心概念到RowKey設(shè)計(jì)與Java API應(yīng)用)
HBase這塊我前前后后啃了一個(gè)多月從懵懵懂懂看概念到在自己的筆記本上把偽分布式環(huán)境跑起來再到用Java API寫增刪改查中間踩了不少坑。這篇學(xué)習(xí)筆記就當(dāng)是給自己做個(gè)總結(jié)也希望能給正在學(xué)大數(shù)據(jù)、尤其是接觸HBase的朋友一些參考。我盡量把“為什么這么做”也寫清楚而不是只貼命令和代碼。1. 先搞清楚HBase到底是什么以及它憑什么在大數(shù)據(jù)圈里有一席之地很多初學(xué)者上來就背“HBase是一個(gè)高可靠、高性能、面向列、可伸縮的分布式數(shù)據(jù)庫(kù)”這句話每個(gè)字都認(rèn)識(shí)但連起來就不知道在說什么。我個(gè)人的理解是想象你有一張極其巨大的Excel表行數(shù)多到上億甚至幾十億普通Excel打開就卡死MySQL這種關(guān)系型數(shù)據(jù)庫(kù)要么存不下要么讀寫慢得讓人崩潰。HBase就是專門為這種場(chǎng)景設(shè)計(jì)的“超級(jí)大表”它有幾千幾萬(wàn)臺(tái)機(jī)器一起干活數(shù)據(jù)拆成很多份分布在這些機(jī)器上對(duì)外卻仍然像一張表一樣提供服務(wù)。1.1 從“面向列”這個(gè)特性說起“面向列”這個(gè)詞很容易誤解以為它是把數(shù)據(jù)豎著存。其實(shí)準(zhǔn)確的說法是“面向列族”HBase里最核心的存儲(chǔ)單元是列族Column Family一個(gè)列族里可以有成百上千個(gè)列。傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)是“行”為單位的一行數(shù)據(jù)必須一起寫、一起讀HBase在存儲(chǔ)時(shí)同一列族的數(shù)據(jù)物理上會(huì)放在一起如果你只查詢某一個(gè)列根本不需要把整行都讀出來。這就好比你去自助餐廳傳統(tǒng)數(shù)據(jù)庫(kù)是“必須買整份套餐”HBase是“想吃什么菜就單獨(dú)拿什么菜”節(jié)省了大量I/O開銷。另外一個(gè)關(guān)鍵點(diǎn)是稀疏存儲(chǔ)。傳統(tǒng)數(shù)據(jù)庫(kù)如果一行有10個(gè)字段你只填了3個(gè)另外7個(gè)往往要占空間或填NULLHBase里不存在的列不會(huì)占用任何物理空間這對(duì)實(shí)際業(yè)務(wù)中字段嚴(yán)重稀疏的場(chǎng)景特別友好。1.2 HBase在技術(shù)棧里的定位學(xué)習(xí)HBase一定要先理順?biāo)谡麄€(gè)大數(shù)據(jù)生態(tài)里的位置。HDFS是底層分布式文件系統(tǒng)負(fù)責(zé)海量數(shù)據(jù)存儲(chǔ)但它有個(gè)明顯短板不支持隨機(jī)讀寫只能追加寫入想做實(shí)時(shí)更新基本沒戲Hive是數(shù)據(jù)倉(cāng)庫(kù)工具跑的是離線批量分析底層依然是MapReduce或Spark你查一條數(shù)據(jù)可能要等幾分鐘而HBase就填補(bǔ)了“海量數(shù)據(jù) 實(shí)時(shí)隨機(jī)讀寫 低延遲”這塊空白。如果你手頭的數(shù)據(jù)只有幾百GB查詢又需要多表關(guān)聯(lián)、復(fù)雜事務(wù)那HBase不是合適的選擇MySQL或者PostgreSQL更省心如果你的數(shù)據(jù)量到了PB級(jí)需要毫秒級(jí)隨機(jī)查詢單條數(shù)據(jù)同時(shí)對(duì)并發(fā)寫入要求很高那HBase幾乎是繞不開的方案。網(wǎng)約車訂單軌跡存儲(chǔ)、電商用戶行為日志查詢、物聯(lián)網(wǎng)設(shè)備上報(bào)數(shù)據(jù)還有像阿里、美團(tuán)內(nèi)部的很多數(shù)據(jù)中臺(tái)系統(tǒng)都是HBase的典型應(yīng)用場(chǎng)。再說說HBase的架構(gòu)四個(gè)核心角色HMaster、RegionServer、ZooKeeper和Region。HMaster管的是“元數(shù)據(jù)”和“調(diào)度”比如表級(jí)別的增刪改、Region的分配與均衡真正干活的是RegionServer每臺(tái)RegionServer上可以掛很多Region每個(gè)Region管理一張大表的一部分?jǐn)?shù)據(jù)ZooKeeper負(fù)責(zé)協(xié)調(diào)比如HMaster的選舉、RegionServer上下線通知。你可以粗淺地理解成HMaster是項(xiàng)目經(jīng)理只管安排任務(wù)和記錄臺(tái)賬RegionServer是一線工人具體的讀寫操作都是工人干的ZooKeeper則是公司內(nèi)部的通知系統(tǒng)誰(shuí)來了誰(shuí)走了大家都得知道。有個(gè)概念特別重要數(shù)據(jù)真正存儲(chǔ)在Region里而Region底層是HFileHFile是存儲(chǔ)在HDFS上的。也就是說HBase不自己存文件文件全部借住在HDFS上。這樣設(shè)計(jì)的好處是數(shù)據(jù)天然多副本、高可用HDFS的datanode掛了影響也不大。2. 開始動(dòng)手HBase安裝與配置的完整復(fù)盤安裝HBase是新手的第一道坎。網(wǎng)上教程很多但版本組合五花八門一不小心就在環(huán)境依賴上折騰一整天。這一步我反復(fù)裝了三次才徹底理清下面把關(guān)鍵過程和我踩過的坑都記錄下來。2.1 環(huán)境準(zhǔn)備與版本搭配裝HBase之前必須先有Java環(huán)境同時(shí)最好有Hadoop環(huán)境因?yàn)镠Base要連ZooKeeper、要把數(shù)據(jù)落到HDFS上。版本搭配非常講究用官方二進(jìn)制包時(shí)Java和Hadoop必須都兼容。我這里用的是Hadoop 3.3.x搭配HBase 2.4.xJava版本選的JDK 8這組搭配經(jīng)過大量實(shí)踐驗(yàn)證最穩(wěn)。JDK 11或17也能用但在某些組件上可能遇到模塊限制問題沒必要給自己找麻煩。如果你只是單機(jī)學(xué)習(xí)不需要單獨(dú)安裝獨(dú)立的ZooKeeper集群HBase自帶ZooKeeper配置參數(shù)可以啟用內(nèi)置的但如果生產(chǎn)環(huán)境建議單獨(dú)部署ZooKeeper集群畢竟它也是HBase高可用的關(guān)鍵角色。2.2 配置文件的修改細(xì)節(jié)解壓安裝包后重點(diǎn)改兩個(gè)文件conf/hbase-env.sh和conf/hbase-site.xml。前者要設(shè)置JAVA_HOME同時(shí)建議把HBASE_MANAGES_ZK設(shè)為true單機(jī)學(xué)習(xí)時(shí)讓HBase自己管理ZooKeeper后者是整個(gè)配置的核心最基礎(chǔ)的內(nèi)容大概是這樣的configuration property namehbase.rootdir/name valuehdfs://localhost:9000/hbase/value /property property namehbase.cluster.distributed/name valuetrue/value /property property namehbase.zookeeper.quorum/name valuelocalhost/value /property property namehbase.zookeeper.property.dataDir/name value/home/hadoop/zookeeper-data/value /property /configuration有幾個(gè)容易被忽略的細(xì)節(jié)值得專門說。第一hbase.rootdir寫的是HDFS路徑如果你只是想讓HBase存本地文件做體驗(yàn)可以改成file:///home/hadoop/hbase-data但這樣就體驗(yàn)不到它對(duì)HDFS的依賴了還是建議把Hadoop搭起來第二hbase.cluster.distributed雖然叫“集群分布式”但單機(jī)偽分布式也要設(shè)為true把它理解為“是否依賴HDFS和ZooKeeper”更準(zhǔn)確第三hbase.zookeeper.property.dataDir最好改成非臨時(shí)目錄否則重啟機(jī)器后元數(shù)據(jù)丟了HBase會(huì)各種詭異報(bào)錯(cuò)。還有一個(gè)全局配置hbase.regionserver.handler.count它決定每個(gè)RegionServer能同時(shí)處理多少RPC請(qǐng)求默認(rèn)30。學(xué)習(xí)環(huán)境不用動(dòng)但在實(shí)際項(xiàng)目里你需要根據(jù)業(yè)務(wù)并發(fā)量調(diào)大或調(diào)小這個(gè)參數(shù)直接關(guān)系到高并發(fā)下的響應(yīng)速度。2.3 啟動(dòng)驗(yàn)證和端口說明啟動(dòng)前先確保Hadoop的NameNode和DataNode都活著然后執(zhí)行start-hbase.sh等十幾秒后訪問HBase自帶的Web界面。我整理了一份常見的端口清單這個(gè)列表是我自己在排查問題時(shí)反復(fù)用到的端口用途16010HMaster的Web UI在這里能看到RegionServer列表、表列表、Region分布16030RegionServer的Web UI能看到單個(gè)RegionServer的請(qǐng)求量、緩存命中率、Region詳情2181ZooKeeper端口客戶端連接HBase時(shí)要先連這里16020RegionServer的RPC端口Java客戶端或HBase Shell正是通過它讀寫數(shù)據(jù)16000HMaster的RPC端口主要用于管理操作第一次裝完后我卡在了一個(gè)特別低級(jí)的問題Web UI能打開但Shell里執(zhí)行l(wèi)ist命令報(bào)連接異常。排查了半天才發(fā)現(xiàn)是防火墻沒關(guān)端口或者是ZooKeeper的數(shù)據(jù)目錄被清了。這類問題后面放到第五部分統(tǒng)一說。啟動(dòng)完畢之后建議先跑一下hbase shell執(zhí)行status看到類似1 active master, 1 backup masters, 1 servers的輸出就說明環(huán)境基本通了。3. 從設(shè)計(jì)到落地表結(jié)構(gòu)設(shè)計(jì)與數(shù)據(jù)操作的完整思路環(huán)境通了之后真正考驗(yàn)人的是表和RowKey的設(shè)計(jì)。很多人在這一步開始犯迷糊因?yàn)闆]有現(xiàn)成的SQL語(yǔ)法可以參考一切都得自己設(shè)計(jì)。我選擇用一個(gè)簡(jiǎn)單但貼近實(shí)際場(chǎng)景的例子——網(wǎng)約車訂單軌跡表來把整個(gè)邏輯串起來。3.1 數(shù)據(jù)模型和幾個(gè)繞不開的基本概念HBase一條數(shù)據(jù)的完整定位需要四個(gè)維度行鍵RowKey、列族Column Family、列限定符Qualifier就是列名、時(shí)間戳Timestamp。RowKey是每行數(shù)據(jù)的唯一標(biāo)識(shí)查詢時(shí)最快的方式就是直接根據(jù)RowKey去Get同一RowKey下的數(shù)據(jù)可以有多個(gè)版本通過時(shí)間戳區(qū)分默認(rèn)保留最近三個(gè)版本。建表語(yǔ)句非常簡(jiǎn)潔核心就是指定列族比如create trip_order, info, location這就創(chuàng)建了一張名為trip_order的表它有兩個(gè)列族info和location。列族創(chuàng)建之后還能修改比如調(diào)整TTL、壓縮算法但列族數(shù)量一旦多了會(huì)有性能問題官方建議不超過2到3個(gè)。設(shè)計(jì)表的第一步是定列族不要想著像MySQL那樣建幾十個(gè)字段而是把字段按“訪問特性”和“存儲(chǔ)特性”劃進(jìn)少數(shù)幾個(gè)列族里。3.2 RowKey設(shè)計(jì)這是HBase的靈魂RowKey的設(shè)計(jì)直接影響讀寫性能這是我學(xué)習(xí)過程中印象最深的一點(diǎn)。最核心的原則有三個(gè)唯一性、散列性、長(zhǎng)度控制。唯一性容易理解散列性是為了防止數(shù)據(jù)熱點(diǎn)。舉個(gè)例子如果直接用車牌號(hào)當(dāng)RowKey那同一輛車的所有訂單都落在同一個(gè)Region上一旦某輛車高頻上報(bào)位置這個(gè)Region的寫入壓力會(huì)特別大而其他Region閑著。解決方法通常是在RowKey前面加鹽Salt或哈希前綴比如把車牌號(hào)的hashCode取模后拼在前面變成0a_京A12345_20240101103000這樣的格式長(zhǎng)度則是要盡可能短RowKey太長(zhǎng)會(huì)讓HFile的索引和內(nèi)存占用都上去除非業(yè)務(wù)確實(shí)需要否則不要超過一百字節(jié)。查詢模式也要在設(shè)計(jì)RowKey時(shí)提前想好。因?yàn)镽owKey是字典序存儲(chǔ)的如果你要查某輛車某天的所有軌跡可以設(shè)計(jì)成md5(車牌)前幾位_車牌_日期這樣同一輛車同一時(shí)段的數(shù)據(jù)在物理上是連續(xù)的Scan的效率會(huì)非常高。相反如果你把時(shí)間戳放在RowKey最前面然后Scan全表那就意味著查詢要走全表掃描設(shè)計(jì)等于失敗了。3.3 Shell環(huán)境下的常用數(shù)據(jù)操作HBase Shell是學(xué)習(xí)時(shí)最直觀的練習(xí)工具常用的命令最好全部親手敲一遍我總結(jié)了下面幾個(gè)典型操作# 建表預(yù)分區(qū)方式可以提前指定Region數(shù)量 create trip_order, {NAME info, VERSIONS 3}, {NAME location, VERSIONS 3} # 插入一條數(shù)據(jù) put trip_order, rowkey001, info:driver_id, 2001 put trip_order, rowkey001, location:lat, 39.9042 put trip_order, rowkey001, location:lng, 116.4074 # 查詢單行 get trip_order, rowkey001 # 按區(qū)間掃描指定行鍵范圍 scan trip_order, {STARTROW rowkey001, ENDROW rowkey010} # 刪除 deleteall trip_order, rowkey001 # 修改列族的版本數(shù) alter trip_order, {NAME info, VERSIONS 5}這里有個(gè)細(xì)節(jié)HBase Shell刪除一行默認(rèn)刪除的是最新的那個(gè)時(shí)間戳版本deleteall才是刪整行。Shell還會(huì)把類型信息顯示出來比如columninfo:driver_id, timestamp...這個(gè)timestamp就是數(shù)據(jù)寫入時(shí)自動(dòng)生成的版本號(hào)。預(yù)分區(qū)是個(gè)很容易被忽略但極其有用的操作。如果你創(chuàng)建表時(shí)不指定默認(rèn)只有1個(gè)Region數(shù)據(jù)量增加到一定程度會(huì)自動(dòng)分裂但在自動(dòng)分裂的過程中可能會(huì)有短暫的性能抖動(dòng)而且熱點(diǎn)問題往往從初期就埋下了。所以生產(chǎn)環(huán)境建表我習(xí)慣在create時(shí)直接用SPLIITS [rowkey001, rowkey002, ...]或者NUMREGIONS 20來指定預(yù)分區(qū)讓數(shù)據(jù)一開始就打散分布。3.4 我在表設(shè)計(jì)階段踩過的坑第一次做表設(shè)計(jì)時(shí)我犯過一個(gè)現(xiàn)在看來很幼稚的錯(cuò)。當(dāng)時(shí)給一張用戶行為日志表設(shè)計(jì)了5個(gè)列族理由是“不同業(yè)務(wù)線的字段分開管理”。結(jié)果Badge里每個(gè)列族都會(huì)單獨(dú)生成對(duì)應(yīng)的存儲(chǔ)文件多個(gè)列族意味著在讀寫一行數(shù)據(jù)時(shí)要訪問多個(gè)不同的文件RegionServer的壓力成倍增加。后來我們壓縮到2個(gè)列族性能明顯改善。另一個(gè)經(jīng)常出現(xiàn)的坑是過度設(shè)計(jì)。有人為了“考慮未來擴(kuò)展”把本來屬于同一個(gè)業(yè)務(wù)實(shí)體的數(shù)據(jù)分散到多張表里結(jié)果查詢時(shí)要跨表拼數(shù)據(jù)。HBase沒有原生join能力跨表關(guān)聯(lián)非常難受要么用MapReduce或Spark做離線加工要么在應(yīng)用層做多路查詢。在設(shè)計(jì)之初就要想清楚這張表是“服務(wù)查詢”的還是“服務(wù)分析”的兩種場(chǎng)景的表結(jié)構(gòu)很可能完全不一樣。4. 用Java操作HBase從連接客戶端到增刪改查的實(shí)戰(zhàn)記錄學(xué)習(xí)HBase的最終落點(diǎn)一定是要能寫代碼因?yàn)樯a(chǎn)環(huán)境永遠(yuǎn)是用程序去讀寫HBaseShell只用來做維護(hù)和快速驗(yàn)證。這一部分我完整記錄了一個(gè)最基礎(chǔ)的Java客戶端開發(fā)過程包含依賴、連接、建表、插入和查詢以及我實(shí)際開發(fā)中總結(jié)的規(guī)范。4.1 引入依賴和建立連接如果你的項(xiàng)目是Maven工程引入HBase客戶端依賴非常直接dependency groupIdorg.apache.hbase/groupId artifactIdhbase-client/artifactId version2.4.17/version /dependency建立連接時(shí)傳統(tǒng)寫法是每次操作都創(chuàng)建一個(gè)Connection這是絕對(duì)的反模式。因?yàn)镠Base的Connection底層維護(hù)了RPC連接池、ZooKeeper會(huì)話等重量級(jí)資源創(chuàng)建一次的成本很高。正確做法是全局只創(chuàng)建一個(gè)Connection實(shí)例在整個(gè)應(yīng)用生命周期里復(fù)用用完之后由應(yīng)用進(jìn)程退出時(shí)統(tǒng)一關(guān)閉。這一點(diǎn)和數(shù)據(jù)庫(kù)連接池的思路一致。Configuration public class HBaseConfig { Bean public Connection hBaseConnection() throws IOException { Configuration conf HBaseConfiguration.create(); conf.set(hbase.zookeeper.quorum, localhost); conf.set(hbase.zookeeper.property.clientPort, 2181); return ConnectionFactory.createConnection(conf); } }4.2 建表和寫入數(shù)據(jù)的代碼實(shí)現(xiàn)建表用Admin操作DML用Table操作兩者源頭都是Connection。下面是一段建表和插入數(shù)據(jù)的示例public void createTable(Connection connection, String tableName, String... columnFamilies) throws IOException { Admin admin connection.getAdmin(); TableName tn TableName.valueOf(tableName); if (admin.tableExists(tn)) { admin.disableTable(tn); admin.deleteTable(tn); } TableDescriptorBuilder builder TableDescriptorBuilder.newBuilder(tn); for (String cf : columnFamilies) { ColumnFamilyDescriptor cfd ColumnFamilyDescriptorBuilder.newBuilder(Bytes.toBytes(cf)).build(); builder.setColumnFamily(cfd); } admin.createTable(builder.build()); admin.close(); } public void putRow(Connection connection, String tableName, String rowKey, String cf, String col, String value) throws IOException { Table table connection.getTable(TableName.valueOf(tableName)); Put put new Put(Bytes.toBytes(rowKey)); put.addColumn(Bytes.toBytes(cf), Bytes.toBytes(col), Bytes.toBytes(value)); table.put(put); table.close(); }這里的坑有幾個(gè)。第一Bytes.toBytes這個(gè)工具類幾乎是所有操作的必經(jīng)之路HBase的所有讀寫API都是byte[]類型提交字符串之前要做字節(jié)轉(zhuǎn)換第二這里的putRow方法一次只插一列實(shí)際業(yè)務(wù)中強(qiáng)烈建議把多列拼到一個(gè)Put對(duì)象里一次提交因?yàn)橐淮尉W(wǎng)絡(luò)RPC和多次網(wǎng)絡(luò)RPC的開銷差距明顯第三大量寫入時(shí)建議使用BufferedMutator它就相當(dāng)于HBase客戶端的write buffer攢夠一批再發(fā)出去。數(shù)據(jù)量大時(shí)千萬(wàn)不要一行一行put尤其是循環(huán)里new Table性能會(huì)指數(shù)級(jí)下降。正確做法是復(fù)用一個(gè)Table實(shí)例批量把Put對(duì)象add到一個(gè)List里每攢到1000條或1MB左右提交一次這樣RegionServer也能更高效地批量寫HFile。4.3 查詢代碼和過濾器使用查詢分兩類精確查詢也就是Get和范圍/條件查詢也就是Scan。精確查詢是按RowKey直接用Get這是HBase最快的查詢方式建議線上接口盡量走這條路徑。public String getValue(Connection connection, String tableName, String rowKey, String cf, String col) throws IOException { Table table connection.getTable(TableName.valueOf(tableName)); Get get new Get(Bytes.toBytes(rowKey)); Result result table.get(get); Cell[] cells result.rawCells(); if (cells ! null cells.length 0) { Cell cell cells[0]; return Bytes.toString(CellUtil.cloneValue(cell)); } return null; }Scan的靈活之處在于配合過濾器使用。最常用的是RowKey范圍掃描setStartRow和setStopRow、列值過濾器SingleColumnValueFilter、行前綴過濾PrefixFilter。但需要記住一個(gè)原則能通過RowKey范圍解決的問題不要用過濾器。過濾器相當(dāng)于在RegionServer端逐行判斷如果過濾條件很弱它會(huì)拖慢整個(gè)查詢。HBase二面面試也喜歡在這里挖坑“Filter查詢快嗎”答案是不一定性能取決于你的rowkey設(shè)計(jì)能不能最大程度裁剪要掃描的數(shù)據(jù)范圍。4.4 開發(fā)中的幾個(gè)經(jīng)驗(yàn)心得我在寫Java客戶端時(shí)最常犯的錯(cuò)誤是忘關(guān)資源。createTable里的Admin調(diào)用完了要close但真正的高并發(fā)場(chǎng)景里反復(fù)開關(guān)Admin反而是浪費(fèi)正確思路是同一個(gè)Connection派生的輕量資源盡量復(fù)用重量級(jí)資源由容器管理生命周期。此外連接參數(shù)里有個(gè)zookeeper.retries默認(rèn)值偏大服務(wù)端ZooKeeper假死時(shí)客戶端會(huì)一直重試導(dǎo)致請(qǐng)求堆積。我習(xí)慣把它調(diào)整為3次超時(shí)時(shí)間設(shè)置短一些寧可快速失敗也不要讓上游接口掛死。5. 常見問題排查和面試高頻知識(shí)點(diǎn)整理最后這部分我把實(shí)際操作中最常見的問題和面試喜歡覆蓋的知識(shí)點(diǎn)放在一起說因?yàn)樗鼈儽举|(zhì)上是一回事搞懂了問題背后的原理面試題自然就通了。5.1 環(huán)境部署階段的典型報(bào)錯(cuò)和處理思路我遇到的第一個(gè)大問題是執(zhí)行start-hbase.sh后HMaster進(jìn)程起來了但幾秒鐘后又自動(dòng)退出。日志里報(bào)的卻是ZooKeeper連接超時(shí)。排查過程供參考第一先看hbase-site.xml里hbase.zookeeper.quorum配置是否正確我最初寫成了機(jī)器的主機(jī)名而/etc/hosts里沒做映射解析不了改成localhost立刻就好了第二確認(rèn)ZooKeeper數(shù)據(jù)目錄有寫權(quán)限如果你用root啟動(dòng)過集群再用hadoop用戶啟動(dòng)就會(huì)因?yàn)槟夸洐?quán)限不一致起不來第三查看logs目錄下的hbase-hadoop-master-xxx.log這個(gè)日志文件基本能定位90%的問題。第二個(gè)高頻問題Shell能連上但讀寫時(shí)報(bào)RegionServer is not online。這個(gè)大概率是RegionServer進(jìn)程沒有正常啟動(dòng)或者系統(tǒng)負(fù)載太高導(dǎo)致RegionServer宕機(jī)后又注冊(cè)不上。查看Web UI里的RegionServer列表找不到節(jié)點(diǎn)就說明進(jìn)程掛了。處理辦法是清掉ZooKeeper里遺留的HBase元數(shù)據(jù)重啟服務(wù)。但注意清元數(shù)據(jù)一定要先停掉HBase否則可能造成數(shù)據(jù)元信息錯(cuò)亂。5.2 HBase讀寫性能問題快速定位實(shí)際使用中經(jīng)常遇到“寫入很慢”或者“查詢很慢”的反饋。我的排查思路是分三步走第一步看RegionServer的Web UI關(guān)注Num. of requests這個(gè)指標(biāo)確認(rèn)是讀寫請(qǐng)求量太大導(dǎo)致線程池繁忙還是本身耗時(shí)長(zhǎng)第二步看Region Count和Storefile Count如果單個(gè)RegionServer上的Region太多超過幾百個(gè)說明負(fù)載不均衡或者預(yù)分區(qū)不合理第三步看緩存命中率也就是BlockCacheHitRatio命中率低于70%通常意味著Scan掃了太多不需要的數(shù)據(jù)或者BlockCache設(shè)得太小。調(diào)整方式一個(gè)是增大hfile.block.cache.size但這段空間是從堆內(nèi)存里劃分的給得太多會(huì)影響MemStore寫入需要找到平衡點(diǎn)另一個(gè)是優(yōu)化查詢邏輯讓Scan盡可能命中與RowKey前綴相同的連續(xù)數(shù)據(jù)。大數(shù)據(jù)量下的查詢卡頓也和大內(nèi)存GC相關(guān)。HBase是Java進(jìn)程堆內(nèi)存里既要存MemStore寫入緩沖區(qū)又要存BlockCache讀緩存兩者之間有個(gè)比例分配。默認(rèn)配置是MemStore占40%BlockCache占40%如果你發(fā)現(xiàn)讀多寫少可以把BlockCache調(diào)高一些反過來寫多讀少就調(diào)低。不要指望HBase自動(dòng)幫你優(yōu)化這些參數(shù)在生產(chǎn)環(huán)境必須手動(dòng)調(diào)。5.3 面試高頻問題速查學(xué)習(xí)HBase的過程中我順手整理了幾個(gè)高頻面試問題的回答思路按照“起因、對(duì)比、血淚坑”的方式背下來幾乎不會(huì)卡殼面試問題回答要點(diǎn)HBase和Hive有什么區(qū)別Hive是數(shù)倉(cāng)工具跑離線批處理延遲高HBase是NoSQL數(shù)據(jù)庫(kù)支持實(shí)時(shí)隨機(jī)讀寫延遲低Hive不擅長(zhǎng)單行查詢HBase不擅長(zhǎng)復(fù)雜分析為什么要用LSM樹而不是B樹B樹寫入需要隨機(jī)I/O海量寫入時(shí)磁盤性能跟不上LSM樹先把寫入放到MemStore內(nèi)存中攢夠再批量落盤成HFile把隨機(jī)寫變成順序?qū)憣懭胪掏铝看蠓嵘齊owKey設(shè)計(jì)怎么避免熱點(diǎn)加鹽、哈希前綴、反轉(zhuǎn)RowKey目標(biāo)都是讓RowKey的字典序分布均勻避免大量讀寫落到同一Region上Region分裂和合并是怎么發(fā)生的Region變大到閾值后自動(dòng)分裂成兩個(gè)由HMaster管理多個(gè)Region數(shù)據(jù)量小且連續(xù)時(shí)會(huì)合并減少元數(shù)據(jù)開銷HBase數(shù)據(jù)刪除是真刪除嗎不是標(biāo)記刪除給數(shù)據(jù)加一個(gè)Delete類型的墓碑標(biāo)記真正的物理刪除要等Major Compaction之后才會(huì)發(fā)生MemStore刷寫條件是什么達(dá)到hbase.hregion.memstore.flush.size默認(rèn)128MB或者M(jìn)emStore總大小占RegionServer堆內(nèi)存比例超限或者WAL文件數(shù)量過多時(shí)也會(huì)觸發(fā)刷寫其中LSM樹這個(gè)點(diǎn)值得多寫幾句。HBase寫操作先把數(shù)據(jù)寫進(jìn)WAL預(yù)寫日志再放到內(nèi)存MemStore里這不純粹是為了速度更重要的是保證數(shù)據(jù)不丟。機(jī)器突然斷電時(shí)WAL能幫你恢復(fù)還沒落盤的數(shù)據(jù)。理解了WAL就理解了為什么HBase在設(shè)計(jì)上是“寫快讀慢”寫只要寫一份順序日志加一份內(nèi)存讀可能要查MemStore、多個(gè)HFile文件真實(shí)工程里經(jīng)常需要引入布隆過濾器來加速讀路徑。5.4 學(xué)習(xí)路線和階段劃分建議我的建議是三個(gè)階段遞進(jìn)。第一階段能跑通環(huán)境會(huì)用Shell完成建表和增刪改查理解Region、Store、MemStore幾個(gè)核心概念第二階段能用Java客戶端完成常見讀寫操作理解RowKey設(shè)計(jì)、預(yù)分區(qū)優(yōu)化、批量讀寫能自主排查連接和端口問題第三階段深入源碼或官方文檔理解Region分裂合并流程、Compaction機(jī)制、HBase的備份與容災(zāi)方案。完成了前兩個(gè)階段應(yīng)付日常的開發(fā)和初級(jí)面試基本沒有問題。如果遇到看不懂源碼的時(shí)候我的辦法是抓主線而不是抓細(xì)節(jié)先弄明白一條Put請(qǐng)求從客戶端到服務(wù)端經(jīng)歷了哪些類、哪些步驟其他一切都能串起來。結(jié)尾我個(gè)人在反復(fù)實(shí)操中最想提醒的三件小事這一路學(xué)下來我自己印象最深的不是那些宏大的架構(gòu)概念反而是三個(gè)小到幾乎被人忽視的細(xì)節(jié)一是Connection要復(fù)用任何代碼里反復(fù)創(chuàng)建連接都是性能災(zāi)難的開始二是配好一套穩(wěn)定的版本組合后就別再亂動(dòng)HBase、Hadoop、JDK之間版本高高低低的坑足夠讓人陪上一整天三是遇到問題先看RegionServer和HMaster的日志不要盲目重啟集群日志文件里往往直接寫著原因。最后再分享一個(gè)小技巧學(xué)習(xí)時(shí)嘗試給自己出一道綜合題比如“模擬一個(gè)共享單車軌跡查詢系統(tǒng)”從表設(shè)計(jì)、預(yù)分區(qū)、RowKey規(guī)則到Java讀寫接口全流程做一遍比看十篇教程都管用。把這個(gè)過程踩過的坑都記錄下來這些比任何面試題答案都更有價(jià)值。 HBase學(xué)習(xí)實(shí)戰(zhàn)筆記：從核心概念到RowKey設(shè)計(jì)與Java API應(yīng)用
HBase這塊我前前后后啃了一個(gè)多月從懵懵懂懂看概念到在自己的筆記本上把偽分布式環(huán)境跑起來再到用Java API寫增刪改查中間踩了不少坑。這篇學(xué)習(xí)筆記就當(dāng)是給自己做個(gè)總結(jié)也希望能給正在學(xué)大數(shù)據(jù)、尤其是接觸HBase的朋友一些參考。我盡量把“為什么這么做”也寫清楚而不是只貼命令和代碼。1. 先搞清楚HBase到底是什么以及它憑什么在大數(shù)據(jù)圈里有一席之地很多初學(xué)者上來就背“HBase是一個(gè)高可靠、高性能、面向列、可伸縮的分布式數(shù)據(jù)庫(kù)”這句話每個(gè)字都認(rèn)識(shí)但連起來就不知道在說什么。我個(gè)人的理解是想象你有一張極其巨大的Excel表行數(shù)多到上億甚至幾十億普通Excel打開就卡死MySQL這種關(guān)系型數(shù)據(jù)庫(kù)要么存不下要么讀寫慢得讓人崩潰。HBase就是專門為這種場(chǎng)景設(shè)計(jì)的“超級(jí)大表”它有幾千幾萬(wàn)臺(tái)機(jī)器一起干活數(shù)據(jù)拆成很多份分布在這些機(jī)器上對(duì)外卻仍然像一張表一樣提供服務(wù)。1.1 從“面向列”這個(gè)特性說起“面向列”這個(gè)詞很容易誤解以為它是把數(shù)據(jù)豎著存。其實(shí)準(zhǔn)確的說法是“面向列族”HBase里最核心的存儲(chǔ)單元是列族Column Family一個(gè)列族里可以有成百上千個(gè)列。傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)是“行”為單位的一行數(shù)據(jù)必須一起寫、一起讀HBase在存儲(chǔ)時(shí)同一列族的數(shù)據(jù)物理上會(huì)放在一起如果你只查詢某一個(gè)列根本不需要把整行都讀出來。這就好比你去自助餐廳傳統(tǒng)數(shù)據(jù)庫(kù)是“必須買整份套餐”HBase是“想吃什么菜就單獨(dú)拿什么菜”節(jié)省了大量I/O開銷。另外一個(gè)關(guān)鍵點(diǎn)是稀疏存儲(chǔ)。傳統(tǒng)數(shù)據(jù)庫(kù)如果一行有10個(gè)字段你只填了3個(gè)另外7個(gè)往往要占空間或填NULLHBase里不存在的列不會(huì)占用任何物理空間這對(duì)實(shí)際業(yè)務(wù)中字段嚴(yán)重稀疏的場(chǎng)景特別友好。1.2 HBase在技術(shù)棧里的定位學(xué)習(xí)HBase一定要先理順?biāo)谡麄€(gè)大數(shù)據(jù)生態(tài)里的位置。HDFS是底層分布式文件系統(tǒng)負(fù)責(zé)海量數(shù)據(jù)存儲(chǔ)但它有個(gè)明顯短板不支持隨機(jī)讀寫只能追加寫入想做實(shí)時(shí)更新基本沒戲Hive是數(shù)據(jù)倉(cāng)庫(kù)工具跑的是離線批量分析底層依然是MapReduce或Spark你查一條數(shù)據(jù)可能要等幾分鐘而HBase就填補(bǔ)了“海量數(shù)據(jù) 實(shí)時(shí)隨機(jī)讀寫 低延遲”這塊空白。如果你手頭的數(shù)據(jù)只有幾百GB查詢又需要多表關(guān)聯(lián)、復(fù)雜事務(wù)那HBase不是合適的選擇MySQL或者PostgreSQL更省心如果你的數(shù)據(jù)量到了PB級(jí)需要毫秒級(jí)隨機(jī)查詢單條數(shù)據(jù)同時(shí)對(duì)并發(fā)寫入要求很高那HBase幾乎是繞不開的方案。網(wǎng)約車訂單軌跡存儲(chǔ)、電商用戶行為日志查詢、物聯(lián)網(wǎng)設(shè)備上報(bào)數(shù)據(jù)還有像阿里、美團(tuán)內(nèi)部的很多數(shù)據(jù)中臺(tái)系統(tǒng)都是HBase的典型應(yīng)用場(chǎng)。再說說HBase的架構(gòu)四個(gè)核心角色HMaster、RegionServer、ZooKeeper和Region。HMaster管的是“元數(shù)據(jù)”和“調(diào)度”比如表級(jí)別的增刪改、Region的分配與均衡真正干活的是RegionServer每臺(tái)RegionServer上可以掛很多Region每個(gè)Region管理一張大表的一部分?jǐn)?shù)據(jù)ZooKeeper負(fù)責(zé)協(xié)調(diào)比如HMaster的選舉、RegionServer上下線通知。你可以粗淺地理解成HMaster是項(xiàng)目經(jīng)理只管安排任務(wù)和記錄臺(tái)賬RegionServer是一線工人具體的讀寫操作都是工人干的ZooKeeper則是公司內(nèi)部的通知系統(tǒng)誰(shuí)來了誰(shuí)走了大家都得知道。有個(gè)概念特別重要數(shù)據(jù)真正存儲(chǔ)在Region里而Region底層是HFileHFile是存儲(chǔ)在HDFS上的。也就是說HBase不自己存文件文件全部借住在HDFS上。這樣設(shè)計(jì)的好處是數(shù)據(jù)天然多副本、高可用HDFS的datanode掛了影響也不大。2. 開始動(dòng)手HBase安裝與配置的完整復(fù)盤安裝HBase是新手的第一道坎。網(wǎng)上教程很多但版本組合五花八門一不小心就在環(huán)境依賴上折騰一整天。這一步我反復(fù)裝了三次才徹底理清下面把關(guān)鍵過程和我踩過的坑都記錄下來。2.1 環(huán)境準(zhǔn)備與版本搭配裝HBase之前必須先有Java環(huán)境同時(shí)最好有Hadoop環(huán)境因?yàn)镠Base要連ZooKeeper、要把數(shù)據(jù)落到HDFS上。版本搭配非常講究用官方二進(jìn)制包時(shí)Java和Hadoop必須都兼容。我這里用的是Hadoop 3.3.x搭配HBase 2.4.xJava版本選的JDK 8這組搭配經(jīng)過大量實(shí)踐驗(yàn)證最穩(wěn)。JDK 11或17也能用但在某些組件上可能遇到模塊限制問題沒必要給自己找麻煩。如果你只是單機(jī)學(xué)習(xí)不需要單獨(dú)安裝獨(dú)立的ZooKeeper集群HBase自帶ZooKeeper配置參數(shù)可以啟用內(nèi)置的但如果生產(chǎn)環(huán)境建議單獨(dú)部署ZooKeeper集群畢竟它也是HBase高可用的關(guān)鍵角色。2.2 配置文件的修改細(xì)節(jié)解壓安裝包后重點(diǎn)改兩個(gè)文件conf/hbase-env.sh和conf/hbase-site.xml。前者要設(shè)置JAVA_HOME同時(shí)建議把HBASE_MANAGES_ZK設(shè)為true單機(jī)學(xué)習(xí)時(shí)讓HBase自己管理ZooKeeper后者是整個(gè)配置的核心最基礎(chǔ)的內(nèi)容大概是這樣的configuration property namehbase.rootdir/name valuehdfs://localhost:9000/hbase/value /property property namehbase.cluster.distributed/name valuetrue/value /property property namehbase.zookeeper.quorum/name valuelocalhost/value /property property namehbase.zookeeper.property.dataDir/name value/home/hadoop/zookeeper-data/value /property /configuration有幾個(gè)容易被忽略的細(xì)節(jié)值得專門說。第一hbase.rootdir寫的是HDFS路徑如果你只是想讓HBase存本地文件做體驗(yàn)可以改成file:///home/hadoop/hbase-data但這樣就體驗(yàn)不到它對(duì)HDFS的依賴了還是建議把Hadoop搭起來第二hbase.cluster.distributed雖然叫“集群分布式”但單機(jī)偽分布式也要設(shè)為true把它理解為“是否依賴HDFS和ZooKeeper”更準(zhǔn)確第三hbase.zookeeper.property.dataDir最好改成非臨時(shí)目錄否則重啟機(jī)器后元數(shù)據(jù)丟了HBase會(huì)各種詭異報(bào)錯(cuò)。還有一個(gè)全局配置hbase.regionserver.handler.count它決定每個(gè)RegionServer能同時(shí)處理多少RPC請(qǐng)求默認(rèn)30。學(xué)習(xí)環(huán)境不用動(dòng)但在實(shí)際項(xiàng)目里你需要根據(jù)業(yè)務(wù)并發(fā)量調(diào)大或調(diào)小這個(gè)參數(shù)直接關(guān)系到高并發(fā)下的響應(yīng)速度。2.3 啟動(dòng)驗(yàn)證和端口說明啟動(dòng)前先確保Hadoop的NameNode和DataNode都活著然后執(zhí)行start-hbase.sh等十幾秒后訪問HBase自帶的Web界面。我整理了一份常見的端口清單這個(gè)列表是我自己在排查問題時(shí)反復(fù)用到的端口用途16010HMaster的Web UI在這里能看到RegionServer列表、表列表、Region分布16030RegionServer的Web UI能看到單個(gè)RegionServer的請(qǐng)求量、緩存命中率、Region詳情2181ZooKeeper端口客戶端連接HBase時(shí)要先連這里16020RegionServer的RPC端口Java客戶端或HBase Shell正是通過它讀寫數(shù)據(jù)16000HMaster的RPC端口主要用于管理操作第一次裝完后我卡在了一個(gè)特別低級(jí)的問題Web UI能打開但Shell里執(zhí)行l(wèi)ist命令報(bào)連接異常。排查了半天才發(fā)現(xiàn)是防火墻沒關(guān)端口或者是ZooKeeper的數(shù)據(jù)目錄被清了。這類問題后面放到第五部分統(tǒng)一說。啟動(dòng)完畢之后建議先跑一下hbase shell執(zhí)行status看到類似1 active master, 1 backup masters, 1 servers的輸出就說明環(huán)境基本通了。3. 從設(shè)計(jì)到落地表結(jié)構(gòu)設(shè)計(jì)與數(shù)據(jù)操作的完整思路環(huán)境通了之后真正考驗(yàn)人的是表和RowKey的設(shè)計(jì)。很多人在這一步開始犯迷糊因?yàn)闆]有現(xiàn)成的SQL語(yǔ)法可以參考一切都得自己設(shè)計(jì)。我選擇用一個(gè)簡(jiǎn)單但貼近實(shí)際場(chǎng)景的例子——網(wǎng)約車訂單軌跡表來把整個(gè)邏輯串起來。3.1 數(shù)據(jù)模型和幾個(gè)繞不開的基本概念HBase一條數(shù)據(jù)的完整定位需要四個(gè)維度行鍵RowKey、列族Column Family、列限定符Qualifier就是列名、時(shí)間戳Timestamp。RowKey是每行數(shù)據(jù)的唯一標(biāo)識(shí)查詢時(shí)最快的方式就是直接根據(jù)RowKey去Get同一RowKey下的數(shù)據(jù)可以有多個(gè)版本通過時(shí)間戳區(qū)分默認(rèn)保留最近三個(gè)版本。建表語(yǔ)句非常簡(jiǎn)潔核心就是指定列族比如create trip_order, info, location這就創(chuàng)建了一張名為trip_order的表它有兩個(gè)列族info和location。列族創(chuàng)建之后還能修改比如調(diào)整TTL、壓縮算法但列族數(shù)量一旦多了會(huì)有性能問題官方建議不超過2到3個(gè)。設(shè)計(jì)表的第一步是定列族不要想著像MySQL那樣建幾十個(gè)字段而是把字段按“訪問特性”和“存儲(chǔ)特性”劃進(jìn)少數(shù)幾個(gè)列族里。3.2 RowKey設(shè)計(jì)這是HBase的靈魂RowKey的設(shè)計(jì)直接影響讀寫性能這是我學(xué)習(xí)過程中印象最深的一點(diǎn)。最核心的原則有三個(gè)唯一性、散列性、長(zhǎng)度控制。唯一性容易理解散列性是為了防止數(shù)據(jù)熱點(diǎn)。舉個(gè)例子如果直接用車牌號(hào)當(dāng)RowKey那同一輛車的所有訂單都落在同一個(gè)Region上一旦某輛車高頻上報(bào)位置這個(gè)Region的寫入壓力會(huì)特別大而其他Region閑著。解決方法通常是在RowKey前面加鹽Salt或哈希前綴比如把車牌號(hào)的hashCode取模后拼在前面變成0a_京A12345_20240101103000這樣的格式長(zhǎng)度則是要盡可能短RowKey太長(zhǎng)會(huì)讓HFile的索引和內(nèi)存占用都上去除非業(yè)務(wù)確實(shí)需要否則不要超過一百字節(jié)。查詢模式也要在設(shè)計(jì)RowKey時(shí)提前想好。因?yàn)镽owKey是字典序存儲(chǔ)的如果你要查某輛車某天的所有軌跡可以設(shè)計(jì)成md5(車牌)前幾位_車牌_日期這樣同一輛車同一時(shí)段的數(shù)據(jù)在物理上是連續(xù)的Scan的效率會(huì)非常高。相反如果你把時(shí)間戳放在RowKey最前面然后Scan全表那就意味著查詢要走全表掃描設(shè)計(jì)等于失敗了。3.3 Shell環(huán)境下的常用數(shù)據(jù)操作HBase Shell是學(xué)習(xí)時(shí)最直觀的練習(xí)工具常用的命令最好全部親手敲一遍我總結(jié)了下面幾個(gè)典型操作# 建表預(yù)分區(qū)方式可以提前指定Region數(shù)量 create trip_order, {NAME info, VERSIONS 3}, {NAME location, VERSIONS 3} # 插入一條數(shù)據(jù) put trip_order, rowkey001, info:driver_id, 2001 put trip_order, rowkey001, location:lat, 39.9042 put trip_order, rowkey001, location:lng, 116.4074 # 查詢單行 get trip_order, rowkey001 # 按區(qū)間掃描指定行鍵范圍 scan trip_order, {STARTROW rowkey001, ENDROW rowkey010} # 刪除 deleteall trip_order, rowkey001 # 修改列族的版本數(shù) alter trip_order, {NAME info, VERSIONS 5}這里有個(gè)細(xì)節(jié)HBase Shell刪除一行默認(rèn)刪除的是最新的那個(gè)時(shí)間戳版本deleteall才是刪整行。Shell還會(huì)把類型信息顯示出來比如columninfo:driver_id, timestamp...這個(gè)timestamp就是數(shù)據(jù)寫入時(shí)自動(dòng)生成的版本號(hào)。預(yù)分區(qū)是個(gè)很容易被忽略但極其有用的操作。如果你創(chuàng)建表時(shí)不指定默認(rèn)只有1個(gè)Region數(shù)據(jù)量增加到一定程度會(huì)自動(dòng)分裂但在自動(dòng)分裂的過程中可能會(huì)有短暫的性能抖動(dòng)而且熱點(diǎn)問題往往從初期就埋下了。所以生產(chǎn)環(huán)境建表我習(xí)慣在create時(shí)直接用SPLIITS [rowkey001, rowkey002, ...]或者NUMREGIONS 20來指定預(yù)分區(qū)讓數(shù)據(jù)一開始就打散分布。3.4 我在表設(shè)計(jì)階段踩過的坑第一次做表設(shè)計(jì)時(shí)我犯過一個(gè)現(xiàn)在看來很幼稚的錯(cuò)。當(dāng)時(shí)給一張用戶行為日志表設(shè)計(jì)了5個(gè)列族理由是“不同業(yè)務(wù)線的字段分開管理”。結(jié)果Badge里每個(gè)列族都會(huì)單獨(dú)生成對(duì)應(yīng)的存儲(chǔ)文件多個(gè)列族意味著在讀寫一行數(shù)據(jù)時(shí)要訪問多個(gè)不同的文件RegionServer的壓力成倍增加。后來我們壓縮到2個(gè)列族性能明顯改善。另一個(gè)經(jīng)常出現(xiàn)的坑是過度設(shè)計(jì)。有人為了“考慮未來擴(kuò)展”把本來屬于同一個(gè)業(yè)務(wù)實(shí)體的數(shù)據(jù)分散到多張表里結(jié)果查詢時(shí)要跨表拼數(shù)據(jù)。HBase沒有原生join能力跨表關(guān)聯(lián)非常難受要么用MapReduce或Spark做離線加工要么在應(yīng)用層做多路查詢。在設(shè)計(jì)之初就要想清楚這張表是“服務(wù)查詢”的還是“服務(wù)分析”的兩種場(chǎng)景的表結(jié)構(gòu)很可能完全不一樣。4. 用Java操作HBase從連接客戶端到增刪改查的實(shí)戰(zhàn)記錄學(xué)習(xí)HBase的最終落點(diǎn)一定是要能寫代碼因?yàn)樯a(chǎn)環(huán)境永遠(yuǎn)是用程序去讀寫HBaseShell只用來做維護(hù)和快速驗(yàn)證。這一部分我完整記錄了一個(gè)最基礎(chǔ)的Java客戶端開發(fā)過程包含依賴、連接、建表、插入和查詢以及我實(shí)際開發(fā)中總結(jié)的規(guī)范。4.1 引入依賴和建立連接如果你的項(xiàng)目是Maven工程引入HBase客戶端依賴非常直接dependency groupIdorg.apache.hbase/groupId artifactIdhbase-client/artifactId version2.4.17/version /dependency建立連接時(shí)傳統(tǒng)寫法是每次操作都創(chuàng)建一個(gè)Connection這是絕對(duì)的反模式。因?yàn)镠Base的Connection底層維護(hù)了RPC連接池、ZooKeeper會(huì)話等重量級(jí)資源創(chuàng)建一次的成本很高。正確做法是全局只創(chuàng)建一個(gè)Connection實(shí)例在整個(gè)應(yīng)用生命周期里復(fù)用用完之后由應(yīng)用進(jìn)程退出時(shí)統(tǒng)一關(guān)閉。這一點(diǎn)和數(shù)據(jù)庫(kù)連接池的思路一致。Configuration public class HBaseConfig { Bean public Connection hBaseConnection() throws IOException { Configuration conf HBaseConfiguration.create(); conf.set(hbase.zookeeper.quorum, localhost); conf.set(hbase.zookeeper.property.clientPort, 2181); return ConnectionFactory.createConnection(conf); } }4.2 建表和寫入數(shù)據(jù)的代碼實(shí)現(xiàn)建表用Admin操作DML用Table操作兩者源頭都是Connection。下面是一段建表和插入數(shù)據(jù)的示例public void createTable(Connection connection, String tableName, String... columnFamilies) throws IOException { Admin admin connection.getAdmin(); TableName tn TableName.valueOf(tableName); if (admin.tableExists(tn)) { admin.disableTable(tn); admin.deleteTable(tn); } TableDescriptorBuilder builder TableDescriptorBuilder.newBuilder(tn); for (String cf : columnFamilies) { ColumnFamilyDescriptor cfd ColumnFamilyDescriptorBuilder.newBuilder(Bytes.toBytes(cf)).build(); builder.setColumnFamily(cfd); } admin.createTable(builder.build()); admin.close(); } public void putRow(Connection connection, String tableName, String rowKey, String cf, String col, String value) throws IOException { Table table connection.getTable(TableName.valueOf(tableName)); Put put new Put(Bytes.toBytes(rowKey)); put.addColumn(Bytes.toBytes(cf), Bytes.toBytes(col), Bytes.toBytes(value)); table.put(put); table.close(); }這里的坑有幾個(gè)。第一Bytes.toBytes這個(gè)工具類幾乎是所有操作的必經(jīng)之路HBase的所有讀寫API都是byte[]類型提交字符串之前要做字節(jié)轉(zhuǎn)換第二這里的putRow方法一次只插一列實(shí)際業(yè)務(wù)中強(qiáng)烈建議把多列拼到一個(gè)Put對(duì)象里一次提交因?yàn)橐淮尉W(wǎng)絡(luò)RPC和多次網(wǎng)絡(luò)RPC的開銷差距明顯第三大量寫入時(shí)建議使用BufferedMutator它就相當(dāng)于HBase客戶端的write buffer攢夠一批再發(fā)出去。數(shù)據(jù)量大時(shí)千萬(wàn)不要一行一行put尤其是循環(huán)里new Table性能會(huì)指數(shù)級(jí)下降。正確做法是復(fù)用一個(gè)Table實(shí)例批量把Put對(duì)象add到一個(gè)List里每攢到1000條或1MB左右提交一次這樣RegionServer也能更高效地批量寫HFile。4.3 查詢代碼和過濾器使用查詢分兩類精確查詢也就是Get和范圍/條件查詢也就是Scan。精確查詢是按RowKey直接用Get這是HBase最快的查詢方式建議線上接口盡量走這條路徑。public String getValue(Connection connection, String tableName, String rowKey, String cf, String col) throws IOException { Table table connection.getTable(TableName.valueOf(tableName)); Get get new Get(Bytes.toBytes(rowKey)); Result result table.get(get); Cell[] cells result.rawCells(); if (cells ! null cells.length 0) { Cell cell cells[0]; return Bytes.toString(CellUtil.cloneValue(cell)); } return null; }Scan的靈活之處在于配合過濾器使用。最常用的是RowKey范圍掃描setStartRow和setStopRow、列值過濾器SingleColumnValueFilter、行前綴過濾PrefixFilter。但需要記住一個(gè)原則能通過RowKey范圍解決的問題不要用過濾器。過濾器相當(dāng)于在RegionServer端逐行判斷如果過濾條件很弱它會(huì)拖慢整個(gè)查詢。HBase二面面試也喜歡在這里挖坑“Filter查詢快嗎”答案是不一定性能取決于你的rowkey設(shè)計(jì)能不能最大程度裁剪要掃描的數(shù)據(jù)范圍。4.4 開發(fā)中的幾個(gè)經(jīng)驗(yàn)心得我在寫Java客戶端時(shí)最常犯的錯(cuò)誤是忘關(guān)資源。createTable里的Admin調(diào)用完了要close但真正的高并發(fā)場(chǎng)景里反復(fù)開關(guān)Admin反而是浪費(fèi)正確思路是同一個(gè)Connection派生的輕量資源盡量復(fù)用重量級(jí)資源由容器管理生命周期。此外連接參數(shù)里有個(gè)zookeeper.retries默認(rèn)值偏大服務(wù)端ZooKeeper假死時(shí)客戶端會(huì)一直重試導(dǎo)致請(qǐng)求堆積。我習(xí)慣把它調(diào)整為3次超時(shí)時(shí)間設(shè)置短一些寧可快速失敗也不要讓上游接口掛死。5. 常見問題排查和面試高頻知識(shí)點(diǎn)整理最后這部分我把實(shí)際操作中最常見的問題和面試喜歡覆蓋的知識(shí)點(diǎn)放在一起說因?yàn)樗鼈儽举|(zhì)上是一回事搞懂了問題背后的原理面試題自然就通了。5.1 環(huán)境部署階段的典型報(bào)錯(cuò)和處理思路我遇到的第一個(gè)大問題是執(zhí)行start-hbase.sh后HMaster進(jìn)程起來了但幾秒鐘后又自動(dòng)退出。日志里報(bào)的卻是ZooKeeper連接超時(shí)。排查過程供參考第一先看hbase-site.xml里hbase.zookeeper.quorum配置是否正確我最初寫成了機(jī)器的主機(jī)名而/etc/hosts里沒做映射解析不了改成localhost立刻就好了第二確認(rèn)ZooKeeper數(shù)據(jù)目錄有寫權(quán)限如果你用root啟動(dòng)過集群再用hadoop用戶啟動(dòng)就會(huì)因?yàn)槟夸洐?quán)限不一致起不來第三查看logs目錄下的hbase-hadoop-master-xxx.log這個(gè)日志文件基本能定位90%的問題。第二個(gè)高頻問題Shell能連上但讀寫時(shí)報(bào)RegionServer is not online。這個(gè)大概率是RegionServer進(jìn)程沒有正常啟動(dòng)或者系統(tǒng)負(fù)載太高導(dǎo)致RegionServer宕機(jī)后又注冊(cè)不上。查看Web UI里的RegionServer列表找不到節(jié)點(diǎn)就說明進(jìn)程掛了。處理辦法是清掉ZooKeeper里遺留的HBase元數(shù)據(jù)重啟服務(wù)。但注意清元數(shù)據(jù)一定要先停掉HBase否則可能造成數(shù)據(jù)元信息錯(cuò)亂。5.2 HBase讀寫性能問題快速定位實(shí)際使用中經(jīng)常遇到“寫入很慢”或者“查詢很慢”的反饋。我的排查思路是分三步走第一步看RegionServer的Web UI關(guān)注Num. of requests這個(gè)指標(biāo)確認(rèn)是讀寫請(qǐng)求量太大導(dǎo)致線程池繁忙還是本身耗時(shí)長(zhǎng)第二步看Region Count和Storefile Count如果單個(gè)RegionServer上的Region太多超過幾百個(gè)說明負(fù)載不均衡或者預(yù)分區(qū)不合理第三步看緩存命中率也就是BlockCacheHitRatio命中率低于70%通常意味著Scan掃了太多不需要的數(shù)據(jù)或者BlockCache設(shè)得太小。調(diào)整方式一個(gè)是增大hfile.block.cache.size但這段空間是從堆內(nèi)存里劃分的給得太多會(huì)影響MemStore寫入需要找到平衡點(diǎn)另一個(gè)是優(yōu)化查詢邏輯讓Scan盡可能命中與RowKey前綴相同的連續(xù)數(shù)據(jù)。大數(shù)據(jù)量下的查詢卡頓也和大內(nèi)存GC相關(guān)。HBase是Java進(jìn)程堆內(nèi)存里既要存MemStore寫入緩沖區(qū)又要存BlockCache讀緩存兩者之間有個(gè)比例分配。默認(rèn)配置是MemStore占40%BlockCache占40%如果你發(fā)現(xiàn)讀多寫少可以把BlockCache調(diào)高一些反過來寫多讀少就調(diào)低。不要指望HBase自動(dòng)幫你優(yōu)化這些參數(shù)在生產(chǎn)環(huán)境必須手動(dòng)調(diào)。5.3 面試高頻問題速查學(xué)習(xí)HBase的過程中我順手整理了幾個(gè)高頻面試問題的回答思路按照“起因、對(duì)比、血淚坑”的方式背下來幾乎不會(huì)卡殼面試問題回答要點(diǎn)HBase和Hive有什么區(qū)別Hive是數(shù)倉(cāng)工具跑離線批處理延遲高HBase是NoSQL數(shù)據(jù)庫(kù)支持實(shí)時(shí)隨機(jī)讀寫延遲低Hive不擅長(zhǎng)單行查詢HBase不擅長(zhǎng)復(fù)雜分析為什么要用LSM樹而不是B樹B樹寫入需要隨機(jī)I/O海量寫入時(shí)磁盤性能跟不上LSM樹先把寫入放到MemStore內(nèi)存中攢夠再批量落盤成HFile把隨機(jī)寫變成順序?qū)憣懭胪掏铝看蠓嵘齊owKey設(shè)計(jì)怎么避免熱點(diǎn)加鹽、哈希前綴、反轉(zhuǎn)RowKey目標(biāo)都是讓RowKey的字典序分布均勻避免大量讀寫落到同一Region上Region分裂和合并是怎么發(fā)生的Region變大到閾值后自動(dòng)分裂成兩個(gè)由HMaster管理多個(gè)Region數(shù)據(jù)量小且連續(xù)時(shí)會(huì)合并減少元數(shù)據(jù)開銷HBase數(shù)據(jù)刪除是真刪除嗎不是標(biāo)記刪除給數(shù)據(jù)加一個(gè)Delete類型的墓碑標(biāo)記真正的物理刪除要等Major Compaction之后才會(huì)發(fā)生MemStore刷寫條件是什么達(dá)到hbase.hregion.memstore.flush.size默認(rèn)128MB或者M(jìn)emStore總大小占RegionServer堆內(nèi)存比例超限或者WAL文件數(shù)量過多時(shí)也會(huì)觸發(fā)刷寫其中LSM樹這個(gè)點(diǎn)值得多寫幾句。HBase寫操作先把數(shù)據(jù)寫進(jìn)WAL預(yù)寫日志再放到內(nèi)存MemStore里這不純粹是為了速度更重要的是保證數(shù)據(jù)不丟。機(jī)器突然斷電時(shí)WAL能幫你恢復(fù)還沒落盤的數(shù)據(jù)。理解了WAL就理解了為什么HBase在設(shè)計(jì)上是“寫快讀慢”寫只要寫一份順序日志加一份內(nèi)存讀可能要查MemStore、多個(gè)HFile文件真實(shí)工程里經(jīng)常需要引入布隆過濾器來加速讀路徑。5.4 學(xué)習(xí)路線和階段劃分建議我的建議是三個(gè)階段遞進(jìn)。第一階段能跑通環(huán)境會(huì)用Shell完成建表和增刪改查理解Region、Store、MemStore幾個(gè)核心概念第二階段能用Java客戶端完成常見讀寫操作理解RowKey設(shè)計(jì)、預(yù)分區(qū)優(yōu)化、批量讀寫能自主排查連接和端口問題第三階段深入源碼或官方文檔理解Region分裂合并流程、Compaction機(jī)制、HBase的備份與容災(zāi)方案。完成了前兩個(gè)階段應(yīng)付日常的開發(fā)和初級(jí)面試基本沒有問題。如果遇到看不懂源碼的時(shí)候我的辦法是抓主線而不是抓細(xì)節(jié)先弄明白一條Put請(qǐng)求從客戶端到服務(wù)端經(jīng)歷了哪些類、哪些步驟其他一切都能串起來。結(jié)尾我個(gè)人在反復(fù)實(shí)操中最想提醒的三件小事這一路學(xué)下來我自己印象最深的不是那些宏大的架構(gòu)概念反而是三個(gè)小到幾乎被人忽視的細(xì)節(jié)一是Connection要復(fù)用任何代碼里反復(fù)創(chuàng)建連接都是性能災(zāi)難的開始二是配好一套穩(wěn)定的版本組合后就別再亂動(dòng)HBase、Hadoop、JDK之間版本高高低低的坑足夠讓人陪上一整天三是遇到問題先看RegionServer和HMaster的日志不要盲目重啟集群日志文件里往往直接寫著原因。最后再分享一個(gè)小技巧學(xué)習(xí)時(shí)嘗試給自己出一道綜合題比如“模擬一個(gè)共享單車軌跡查詢系統(tǒng)”從表設(shè)計(jì)、預(yù)分區(qū)、RowKey規(guī)則到Java讀寫接口全流程做一遍比看十篇教程都管用。把這個(gè)過程踩過的坑都記錄下來這些比任何面試題答案都更有價(jià)值。