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