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