戰(zhàn)：從建表到性能調(diào)優(yōu)的完整指南)
1. 為什么要在Java里直接操作HBase而不是繞道走很多剛接觸大數(shù)據(jù)存儲(chǔ)層的人會(huì)有一個(gè)疑問HBase本身已經(jīng)提供了Shell客戶端敲幾行命令就能建表、插數(shù)據(jù)、查記錄為什么還要費(fèi)勁用Java寫代碼去操作它這個(gè)問題我在帶新人的時(shí)候被問過不下十次。答案其實(shí)不復(fù)雜——Shell適合調(diào)試和臨時(shí)驗(yàn)證但真正落到生產(chǎn)系統(tǒng)里數(shù)據(jù)寫入、讀取、掃描這些動(dòng)作必須嵌入到業(yè)務(wù)邏輯中由程序自動(dòng)完成不可能靠人工敲命令。你總不能讓運(yùn)維同事半夜爬起來手動(dòng)往HBase里插一條記錄。HBase作為構(gòu)建在HDFS之上的分布式列式存儲(chǔ)系統(tǒng)天然適合海量數(shù)據(jù)的隨機(jī)讀寫。它的數(shù)據(jù)模型和傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)完全不同沒有固定的列定義每一行可以有任意多的列族和列限定符同一列族下的數(shù)據(jù)物理上存儲(chǔ)在一起。這種設(shè)計(jì)讓它在稀疏數(shù)據(jù)、寬表場(chǎng)景下表現(xiàn)非常出色。而Java API是HBase最原生、最完整的操作接口官方提供的客戶端就是Java寫的其他語(yǔ)言的客戶端本質(zhì)上也是通過Thrift網(wǎng)關(guān)做了一層封裝。所以如果你想真正吃透HBaseJava API是繞不開的一關(guān)。這篇文章面向的是已經(jīng)了解HBase基本概念表、行鍵、列族、時(shí)間戳但還沒動(dòng)手用Java寫過操作代碼的開發(fā)者。我會(huì)從環(huán)境依賴開始一步步把建表、寫入、查詢、掃描、刪除這些核心操作講清楚同時(shí)把我在實(shí)際項(xiàng)目中踩過的坑和總結(jié)的經(jīng)驗(yàn)一并分享出來。代碼可以直接復(fù)制到你的工程里跑參數(shù)和配置我會(huì)解釋清楚為什么這么設(shè)。2. 動(dòng)手之前依賴、配置與連接池的取舍2.1 Maven依賴到底該引哪些包用Java操作HBase第一步是把客戶端依賴引入工程。HBase的客戶端依賴并不算輕量因?yàn)樗鼤?huì)連帶拉入Hadoop相關(guān)的若干jar包。以HBase 2.x版本為例核心依賴是hbase-client但實(shí)際使用中往往還需要hbase-common和hadoop-common。如果你用的是Maven可以這樣配置dependency groupIdorg.apache.hbase/groupId artifactIdhbase-client/artifactId version2.4.11/version /dependency dependency groupIdorg.apache.hbase/groupId artifactIdhbase-common/artifactId version2.4.11/version /dependency這里有個(gè)容易踩的坑hbase-client的版本必須和服務(wù)端HBase的版本保持兼容。HBase 1.x和2.x的API差異不小比如Connection接口在1.x里還是HConnection到了2.x才統(tǒng)一成Connection。如果你拿2.x的客戶端去連1.x的服務(wù)端編譯能過但運(yùn)行時(shí)可能報(bào)各種奇怪的錯(cuò)。我的建議是客戶端版本和服務(wù)端大版本保持一致小版本盡量對(duì)齊。另外很多教程會(huì)讓你引入hbase-server這是不對(duì)的。hbase-server包含了RegionServer的實(shí)現(xiàn)體積巨大客戶端根本不需要。引入它只會(huì)讓你的工程打包出來多出幾十兆的無用依賴還可能引起類沖突。2.2 Configuration對(duì)象的正確構(gòu)造方式連接HBase需要一個(gè)Configuration對(duì)象它承載了ZooKeeper地址、端口等關(guān)鍵信息。最直接的方式是手動(dòng)設(shè)置Configuration conf HBaseConfiguration.create(); conf.set(hbase.zookeeper.quorum, zk-host-1,zk-host-2,zk-host-3); conf.set(hbase.zookeeper.property.clientPort, 2181);HBaseConfiguration.create()會(huì)自動(dòng)加載classpath下的hbase-site.xml如果這個(gè)文件存在里面的配置會(huì)覆蓋你手動(dòng)設(shè)置的值。這一點(diǎn)要特別注意有時(shí)候你代碼里明明設(shè)了正確的ZooKeeper地址但連上去發(fā)現(xiàn)是另一套集群八成就是hbase-site.xml在作怪。排查的時(shí)候可以先打印一下conf.get(hbase.zookeeper.quorum)看看實(shí)際生效的值是什么。ZooKeeper的地址建議寫全所有節(jié)點(diǎn)用逗號(hào)分隔。只寫一個(gè)節(jié)點(diǎn)雖然也能連上但那個(gè)節(jié)點(diǎn)掛了客戶端就找不到集群了。HBase客戶端會(huì)從ZooKeeper上讀取hbase:meta表的位置信息所以ZooKeeper的穩(wěn)定性直接決定了客戶端能否正常連接。2.3 Connection是重量級(jí)對(duì)象千萬(wàn)別每次new這是新手最容易犯的錯(cuò)誤也是性能殺手。Connection對(duì)象的創(chuàng)建涉及與ZooKeeper的握手、元數(shù)據(jù)表的讀取等一系列網(wǎng)絡(luò)交互開銷很大。如果你每次操作都ConnectionFactory.createConnection(conf)在高并發(fā)場(chǎng)景下會(huì)把ZooKeeper壓垮連接數(shù)暴漲最終導(dǎo)致整個(gè)集群響應(yīng)變慢。正確的做法是把Connection做成單例整個(gè)應(yīng)用生命周期內(nèi)只創(chuàng)建一次所有線程共享。Connection本身是線程安全的可以放心地在多線程環(huán)境下使用。但要注意從Connection獲取的Table對(duì)象不是線程安全的每個(gè)線程應(yīng)該自己從Connection里拿一個(gè)Table實(shí)例。public class HBaseConnector { private static volatile Connection connection; public static Connection getConnection() throws IOException { if (connection null || connection.isClosed()) { synchronized (HBaseConnector.class) { if (connection null || connection.isClosed()) { Configuration conf HBaseConfiguration.create(); conf.set(hbase.zookeeper.quorum, zk-host-1,zk-host-2,zk-host-3); connection ConnectionFactory.createConnection(conf); } } } return connection; } }這段代碼用了雙重檢查鎖來保證線程安全。volatile關(guān)鍵字不能省否則可能出現(xiàn)指令重排序?qū)е履玫轿闯跏蓟耆膶?duì)象。雖然看起來有點(diǎn)啰嗦但這是經(jīng)過驗(yàn)證的可靠寫法。3. 建表這件事表描述符與預(yù)分區(qū)的實(shí)際寫法3.1 TableDescriptor和ColumnFamilyDescriptor的構(gòu)建邏輯在HBase 2.x里建表用的是Admin對(duì)象配合TableDescriptorBuilder和ColumnFamilyDescriptorBuilder。這套Builder模式比1.x時(shí)代的HTableDescriptor要清晰不少但初次接觸的人容易被繞暈。核心邏輯是先構(gòu)建列族描述符再把列族加進(jìn)表描述符最后通過Admin創(chuàng)建表。Admin admin connection.getAdmin(); ColumnFamilyDescriptor cfDescriptor ColumnFamilyDescriptorBuilder .newBuilder(Bytes.toBytes(info)) .setMaxVersions(3) .setTimeToLive(7 * 24 * 60 * 60) .build(); TableDescriptor tableDescriptor TableDescriptorBuilder .newBuilder(TableName.valueOf(user_behavior)) .setColumnFamily(cfDescriptor) .build(); if (!admin.tableExists(TableName.valueOf(user_behavior))) { admin.createTable(tableDescriptor); }setMaxVersions(3)表示每個(gè)單元格保留最近3個(gè)版本的數(shù)據(jù)。HBase的版本控制是按時(shí)間戳來的每次寫入都會(huì)帶上時(shí)間戳不指定的話默認(rèn)用當(dāng)前時(shí)間。如果你只需要最新值設(shè)成1就行能省不少存儲(chǔ)空間。setTimeToLive設(shè)置的是數(shù)據(jù)的存活時(shí)間單位是秒上面設(shè)的是7天。超過這個(gè)時(shí)間的數(shù)據(jù)會(huì)在Major Compaction時(shí)被清理掉。3.2 預(yù)分區(qū)別讓所有數(shù)據(jù)擠在一個(gè)Region里新建的表默認(rèn)只有一個(gè)Region所有寫入都會(huì)落到這一個(gè)Region上。在數(shù)據(jù)量小的時(shí)候沒問題但當(dāng)寫入量上來之后單個(gè)Region會(huì)成為瓶頸而且自動(dòng)分裂的過程會(huì)引起短暫的不可用。所以生產(chǎn)環(huán)境建表時(shí)一定要做預(yù)分區(qū)。預(yù)分區(qū)有兩種常用方式。第一種是直接指定分割點(diǎn)byte[][] splitKeys new byte[][] { Bytes.toBytes(1), Bytes.toBytes(2), Bytes.toBytes(3), Bytes.toBytes(4), Bytes.toBytes(5), Bytes.toBytes(6), Bytes.toBytes(7), Bytes.toBytes(8), Bytes.toBytes(9) }; admin.createTable(tableDescriptor, splitKeys);這樣會(huì)創(chuàng)建10個(gè)Region行鍵以0開頭的落在第一個(gè)Region以1開頭的落在第二個(gè)以此類推。分割點(diǎn)的選擇取決于你的行鍵分布特征。如果行鍵是用戶ID的哈希值那均勻取模分割就行如果行鍵有時(shí)間前綴那就要小心熱點(diǎn)問題。第二種方式是用createTable的重載方法指定Region數(shù)量和分割算法但實(shí)際用得最多的還是手動(dòng)指定分割點(diǎn)因?yàn)榭煽匦宰顝?qiáng)。注意預(yù)分區(qū)的分割點(diǎn)必須是有序的而且不能重復(fù)。如果傳入無序的數(shù)組創(chuàng)建表時(shí)會(huì)直接拋異常。另外分割點(diǎn)的數(shù)量決定了Region的數(shù)量Region數(shù)量等于分割點(diǎn)數(shù)量加一。3.3 列族數(shù)量不是越多越好HBase的列族在物理上是分開存儲(chǔ)的每個(gè)列族對(duì)應(yīng)一組HFile。列族越多寫入時(shí)的flush和compaction開銷就越大。官方建議一張表的列族數(shù)量控制在2到3個(gè)以內(nèi)。我見過有人把每個(gè)字段都設(shè)成一個(gè)列族結(jié)果寫入性能慘不忍睹。列族的命名也有講究。用簡(jiǎn)短的英文單詞比如info、data、meta不要用中文或者特殊字符。雖然HBase底層用字節(jié)數(shù)組存儲(chǔ)理論上支持任意字符但列族名會(huì)出現(xiàn)在HFile路徑和監(jiān)控指標(biāo)里用奇怪的字符會(huì)給運(yùn)維帶來麻煩。4. 寫入與讀取Put、Get和批量操作的性能差異4.1 單條Put的寫法與時(shí)間戳控制寫入數(shù)據(jù)用Put對(duì)象指定行鍵、列族、列限定符和值Table table connection.getTable(TableName.valueOf(user_behavior)); Put put new Put(Bytes.toBytes(user_001)); put.addColumn(Bytes.toBytes(info), Bytes.toBytes(name), Bytes.toBytes(張三)); put.addColumn(Bytes.toBytes(info), Bytes.toBytes(age), Bytes.toBytes(28)); put.addColumn(Bytes.toBytes(info), Bytes.toBytes(city), Bytes.toBytes(北京)); table.put(put);addColumn有多個(gè)重載版本可以指定時(shí)間戳。如果不指定HBase會(huì)用RegionServer的當(dāng)前時(shí)間。在需要回放歷史數(shù)據(jù)或者做數(shù)據(jù)修正的場(chǎng)景下手動(dòng)指定時(shí)間戳很有用。但要注意時(shí)間戳是long類型單位是毫秒。如果你寫入的時(shí)間戳比已有數(shù)據(jù)的時(shí)間戳小那這條數(shù)據(jù)雖然寫進(jìn)去了但查詢時(shí)默認(rèn)返回的是時(shí)間戳最大的版本你可能看不到剛寫的數(shù)據(jù)。table.put(put)每次調(diào)用都是一次RPC請(qǐng)求。如果你要寫入大量數(shù)據(jù)一條一條put效率極低。這時(shí)候應(yīng)該用BufferedMutator或者批量put(ListPut)。4.2 批量寫入BufferedMutator與List 的選擇table.put(ListPut)會(huì)把一批Put打包成一個(gè)RPC請(qǐng)求發(fā)給RegionServer減少了網(wǎng)絡(luò)往返次數(shù)。但它的缺點(diǎn)是同步的調(diào)用線程會(huì)阻塞直到所有數(shù)據(jù)寫入完成。而且如果一批數(shù)據(jù)太大會(huì)導(dǎo)致單次RPC超時(shí)。BufferedMutator則是異步的它內(nèi)部維護(hù)了一個(gè)緩沖區(qū)數(shù)據(jù)先寫到緩沖區(qū)達(dá)到閾值后自動(dòng)批量發(fā)送。寫入線程不需要等待服務(wù)端確認(rèn)吞吐量更高。BufferedMutatorParams params new BufferedMutatorParams(TableName.valueOf(user_behavior)) .writeBufferSize(4 * 1024 * 1024); BufferedMutator mutator connection.getBufferedMutator(params); for (int i 0; i 100000; i) { Put put new Put(Bytes.toBytes(user_ i)); put.addColumn(Bytes.toBytes(info), Bytes.toBytes(age), Bytes.toBytes(String.valueOf(i % 100))); mutator.mutate(put); } mutator.flush(); mutator.close();writeBufferSize設(shè)的是緩沖區(qū)大小默認(rèn)是2MB。設(shè)大一點(diǎn)能提高吞吐量但也會(huì)增加內(nèi)存占用和丟數(shù)據(jù)的風(fēng)險(xiǎn)——如果客戶端進(jìn)程崩潰緩沖區(qū)里還沒發(fā)送的數(shù)據(jù)就丟了。所以BufferedMutator適合對(duì)可靠性要求不是極端高的場(chǎng)景比如日志采集。如果數(shù)據(jù)一條都不能丟還是老老實(shí)實(shí)用同步批量寫。4.3 Get查詢指定列族和列限定符的粒度控制讀取單行數(shù)據(jù)用GetGet get new Get(Bytes.toBytes(user_001)); get.addFamily(Bytes.toBytes(info)); get.addColumn(Bytes.toBytes(info), Bytes.toBytes(name)); Result result table.get(get); byte[] nameBytes result.getValue(Bytes.toBytes(info), Bytes.toBytes(name)); String name Bytes.toString(nameBytes);addFamily和addColumn是可選的。如果不指定Get會(huì)返回該行所有列族的所有列。在寬表場(chǎng)景下一行可能有上百個(gè)列全查出來既浪費(fèi)網(wǎng)絡(luò)帶寬又浪費(fèi)內(nèi)存。所以精確指定需要的列是一個(gè)好習(xí)慣。Result對(duì)象還提供了rawCells()方法可以拿到所有單元格的詳細(xì)信息包括時(shí)間戳。如果你需要做版本對(duì)比或者數(shù)據(jù)審計(jì)這個(gè)方法很有用。4.4 Scan掃描setStartRow和setStopRow的邊界陷阱Scan用于范圍查詢是HBase最強(qiáng)大的功能之一Scan scan new Scan(); scan.setStartRow(Bytes.toBytes(user_001)); scan.setStopRow(Bytes.toBytes(user_100)); scan.addFamily(Bytes.toBytes(info)); scan.setCaching(500); scan.setBatch(100); ResultScanner scanner table.getScanner(scan); for (Result result : scanner) { // 處理每一行 } scanner.close();這里有幾個(gè)關(guān)鍵點(diǎn)。setStartRow是包含的setStopRow是不包含的。也就是說上面的Scan會(huì)返回行鍵從user_001到user_099的數(shù)據(jù)user_100不會(huì)被返回。這個(gè)左閉右開的區(qū)間設(shè)計(jì)經(jīng)常讓人搞混我第一次用的時(shí)候就多查了一條數(shù)據(jù)。setCaching(500)控制的是每次RPC從服務(wù)端拉取多少行到客戶端。默認(rèn)值很小好像是100在掃描大量數(shù)據(jù)時(shí)會(huì)導(dǎo)致頻繁的RPC調(diào)用。設(shè)大一點(diǎn)能顯著提高掃描速度但也會(huì)增加客戶端內(nèi)存壓力。500到1000是一個(gè)比較平衡的值。setBatch(100)控制的是每行返回多少個(gè)單元格。這個(gè)參數(shù)只在行特別寬列非常多的時(shí)候才需要設(shè)置。如果一行有幾千個(gè)列一次性返回會(huì)導(dǎo)致單次RPC響應(yīng)過大甚至OOM。設(shè)成100表示每行分多次返回。注意ResultScanner使用完畢后必須關(guān)閉否則會(huì)泄漏連接資源。建議用try-with-resources或者try-finally保證關(guān)閉。5. 刪除操作與過濾器那些文檔里不會(huì)細(xì)說的細(xì)節(jié)5.1 Delete的三種粒度行、列族、列刪除數(shù)據(jù)用Delete對(duì)象粒度可以細(xì)到列// 刪除整行 Delete deleteRow new Delete(Bytes.toBytes(user_001)); // 刪除整個(gè)列族 Delete deleteFamily new Delete(Bytes.toBytes(user_001)); deleteFamily.addFamily(Bytes.toBytes(info)); // 刪除指定列 Delete deleteColumn new Delete(Bytes.toBytes(user_001)); deleteColumn.addColumn(Bytes.toBytes(info), Bytes.toBytes(city)); table.delete(deleteColumn);HBase的刪除并不是立即物理刪除數(shù)據(jù)而是寫入一個(gè)墓碑標(biāo)記tombstone。真正的數(shù)據(jù)清理發(fā)生在Major Compaction時(shí)。所以刪除操作本身很快但不會(huì)立刻釋放存儲(chǔ)空間。如果你刪了大量數(shù)據(jù)后發(fā)現(xiàn)磁盤沒降不要慌等compaction跑完就好了。還有一個(gè)容易忽略的點(diǎn)刪除操作也會(huì)帶上時(shí)間戳。如果你刪除時(shí)指定的時(shí)間戳小于數(shù)據(jù)的時(shí)間戳那刪除標(biāo)記不會(huì)生效數(shù)據(jù)依然能查到。默認(rèn)情況下Delete使用當(dāng)前時(shí)間戳所以一般不會(huì)有問題。但如果你在做數(shù)據(jù)修正手動(dòng)指定了舊時(shí)間戳就要小心這個(gè)坑。5.2 Filter的實(shí)戰(zhàn)用法PrefixFilter和RowFilter過濾器是HBase Scan的利器可以在服務(wù)端過濾數(shù)據(jù)減少網(wǎng)絡(luò)傳輸。常用的有PrefixFilter、RowFilter、SingleColumnValueFilter等。// 前綴過濾只返回行鍵以u(píng)ser_1開頭的行 PrefixFilter prefixFilter new PrefixFilter(Bytes.toBytes(user_1)); Scan scan new Scan(); scan.setFilter(prefixFilter); // 行鍵正則過濾 RowFilter rowFilter new RowFilter( CompareFilter.CompareOp.EQUAL, new RegexStringComparator(user_\\d{3}) ); scan.setFilter(rowFilter);PrefixFilter的效率很高因?yàn)樗梢灾苯佣ㄎ坏狡鹗夹腥缓箜樞驋呙璧讲粷M足前綴為止。RowFilter配合正則表達(dá)式則靈活得多但正則是逐行匹配的性能不如PrefixFilter。如果前綴能滿足需求優(yōu)先用PrefixFilter。SingleColumnValueFilter用于按列值過濾但要注意它的一個(gè)特性如果某行沒有指定的列默認(rèn)行為是跳過這行。如果你希望沒有該列的行也被返回需要調(diào)用setFilterIfMissing(false)。這個(gè)默認(rèn)行為坑過不少人。5.3 過濾器組合FilterList的AND與OR多個(gè)過濾器可以組合使用FilterList filterList new FilterList(FilterList.Operator.MUST_PASS_ALL); filterList.addFilter(new PrefixFilter(Bytes.toBytes(user_))); filterList.addFilter(new RowFilter( CompareFilter.CompareOp.EQUAL, new RegexStringComparator(.*_00[1-9]) )); scan.setFilter(filterList);MUST_PASS_ALL相當(dāng)于AND所有過濾器都通過才返回MUST_PASS_ANY相當(dāng)于OR任意一個(gè)通過就返回。過濾器組合的順序會(huì)影響性能把過濾力度大的放在前面能減少后續(xù)過濾器的計(jì)算量。6. 連接管理與異常處理生產(chǎn)環(huán)境必須考慮的事6.1 連接泄漏的常見原因與排查方法Connection和Table都是需要關(guān)閉的資源。雖然Connection建議做成單例長(zhǎng)期持有但Table對(duì)象在用完后應(yīng)該及時(shí)關(guān)閉。如果你在代碼里頻繁connection.getTable()卻不關(guān)閉RegionServer上的連接數(shù)會(huì)持續(xù)增長(zhǎng)最終達(dá)到上限后拒絕新連接。排查連接泄漏的一個(gè)實(shí)用方法是看RegionServer的Web UI里面有當(dāng)前活躍的RPC連接數(shù)。如果這個(gè)數(shù)字只增不減基本可以確定有泄漏。另一個(gè)方法是在代碼里加日志記錄每次getTable和close的調(diào)用對(duì)比數(shù)量是否匹配。6.2 RetriesExhaustedException的觸發(fā)條件與應(yīng)對(duì)RetriesExhaustedException是HBase客戶端最常見的異常之一通常意味著客戶端重試了多次仍然無法完成操作。觸發(fā)原因可能有很多RegionServer宕機(jī)、網(wǎng)絡(luò)抖動(dòng)、Region正在分裂、ZooKeeper會(huì)話超時(shí)等。應(yīng)對(duì)這個(gè)異常首先要看異常信息里的詳細(xì)描述它會(huì)告訴你重試了多少次、每次失敗的原因是什么。如果是短暫的網(wǎng)絡(luò)問題客戶端會(huì)自動(dòng)重試并恢復(fù)如果是RegionServer真的掛了那需要等Master把Region重新分配后才能恢復(fù)。調(diào)整重試參數(shù)可以改變客戶端的行為conf.set(hbase.client.retries.number, 5); conf.set(hbase.client.pause, 1000); conf.set(hbase.client.operation.timeout, 30000);hbase.client.retries.number是重試次數(shù)默認(rèn)是15次設(shè)小一點(diǎn)可以讓失敗更快暴露出來。hbase.client.pause是重試間隔的基數(shù)實(shí)際間隔會(huì)在這個(gè)基礎(chǔ)上做指數(shù)退避。hbase.client.operation.timeout是單次操作的超時(shí)時(shí)間單位毫秒。6.3 批量寫入時(shí)的部分失敗處理用table.put(ListPut)批量寫入時(shí)如果部分?jǐn)?shù)據(jù)失敗HBase會(huì)拋出RetriesExhaustedWithDetailsException。這個(gè)異常里包含了成功和失敗的記錄列表try { table.put(putList); } catch (RetriesExhaustedWithDetailsException e) { ListThrowable exceptions e.getCauses(); ListRow failedRows e.getFailedRows(); // 對(duì)失敗的行做重試或記錄 }拿到失敗的行之后可以根據(jù)異常類型決定是重試還是丟棄。如果是NotServingRegionException說明Region正在遷移等一會(huì)兒重試通常能成功如果是DoNotRetryIOException那重試也沒用需要檢查數(shù)據(jù)或表結(jié)構(gòu)。7. 我踩過的那些坑與性能調(diào)優(yōu)的實(shí)戰(zhàn)心得7.1 行鍵設(shè)計(jì)不當(dāng)導(dǎo)致的熱點(diǎn)問題行鍵設(shè)計(jì)是HBase使用中最重要的一環(huán)沒有之一。我見過一個(gè)項(xiàng)目用時(shí)間戳作為行鍵前綴結(jié)果所有寫入都集中在最后一個(gè)Region上其他Region閑著集群資源嚴(yán)重浪費(fèi)。這就是典型的熱點(diǎn)問題。解決熱點(diǎn)問題的常用方法是給行鍵加鹽或者做哈希。加鹽就是在行鍵前面拼一個(gè)隨機(jī)前綴比如(hash(userId) % 10) _ userId。這樣數(shù)據(jù)會(huì)均勻分布到10個(gè)Region上。但加鹽之后按userId范圍查詢就變得困難了因?yàn)橄嗤瑄serId的數(shù)據(jù)可能在不同的Region上。所以加鹽適合隨機(jī)讀寫的場(chǎng)景不適合范圍掃描。另一種方法是反轉(zhuǎn)行鍵。如果行鍵是遞增的ID反轉(zhuǎn)之后高位變化低位不變也能起到分散寫入的效果。比如user_0001反轉(zhuǎn)成1000_resu。這種方法適合ID長(zhǎng)度固定的場(chǎng)景。7.2 Scan時(shí)setCaching設(shè)太大反而變慢setCaching設(shè)大一點(diǎn)能減少RPC次數(shù)但并不是越大越好。如果設(shè)成10000客戶端一次要從服務(wù)端拉10000行數(shù)據(jù)這會(huì)導(dǎo)致單次RPC響應(yīng)非常大網(wǎng)絡(luò)傳輸時(shí)間長(zhǎng)客戶端內(nèi)存占用高。而且如果掃描到一半客戶端處理不過來服務(wù)端可能已經(jīng)超時(shí)了。我的經(jīng)驗(yàn)值是500到1000。在這個(gè)范圍內(nèi)RPC次數(shù)和單次數(shù)據(jù)量比較平衡。當(dāng)然具體值還要看單行數(shù)據(jù)的大小如果每行數(shù)據(jù)很大比如幾KB那caching設(shè)小一點(diǎn)更合適。7.3 客戶端版本與服務(wù)端不匹配的詭異報(bào)錯(cuò)前面提過版本兼容的問題這里再展開說一下。HBase 2.x的客戶端連1.x的服務(wù)端最常見的報(bào)錯(cuò)是NoSuchMethodError或者ClassNotFoundException。因?yàn)?.x的API里有些方法在1.x里不存在編譯時(shí)用的是2.x的jar所以能過運(yùn)行時(shí)加載的是1.x的類就找不到了。還有一種情況是Hadoop版本不匹配。HBase依賴Hadoop的Configuration類如果客戶端引入的Hadoop版本和服務(wù)端的差異太大Configuration的序列化格式可能不兼容導(dǎo)致連接建立后讀取配置出錯(cuò)。排查這類問題先確認(rèn)客戶端和服務(wù)端的版本矩陣然后看異常堆棧里是哪個(gè)類出的問題。7.4 關(guān)于Bytes工具類的使用建議HBase提供了Bytes工具類來做byte[]和基本類型之間的轉(zhuǎn)換。用的時(shí)候要注意Bytes.toBytes(String)用的是UTF-8編碼Bytes.toString(byte[])也是按UTF-8解碼。如果數(shù)據(jù)里包含非UTF-8的字節(jié)轉(zhuǎn)換會(huì)出問題。對(duì)于二進(jìn)制數(shù)據(jù)直接用byte[]操作不要經(jīng)過String轉(zhuǎn)換。另外Bytes.toBytes(int)和Bytes.toBytes(long)生成的字節(jié)數(shù)組長(zhǎng)度不同比較的時(shí)候要注意。行鍵比較是按字節(jié)序進(jìn)行的不是按數(shù)值大小。比如Bytes.toBytes(10)和Bytes.toBytes(9)比較結(jié)果是10小于9因?yàn)樽址?的ASCII碼小于9。如果行鍵是數(shù)值建議統(tǒng)一用固定長(zhǎng)度編碼或者用Bytes.toBytes(long)保證長(zhǎng)度一致。7.5 監(jiān)控與調(diào)優(yōu)的日常檢查項(xiàng)在生產(chǎn)環(huán)境跑HBase客戶端有幾個(gè)指標(biāo)需要定期關(guān)注。RegionServer的blockCacheHitRatio反映讀緩存命中率如果低于0.8說明緩存不夠或者訪問模式太隨機(jī)。compactionQueueSize如果持續(xù)大于0說明compaction跟不上寫入速度需要調(diào)整compaction策略或者增加RegionServer資源?？蛻舳说膔pcQueueSize如果經(jīng)常滿說明寫入壓力超過了RegionServer的處理能力需要考慮擴(kuò)容或者優(yōu)化行鍵設(shè)計(jì)。這些指標(biāo)可以通過HBase自帶的Web UI查看也可以接入監(jiān)控系統(tǒng)做告警。我的習(xí)慣是每天早上花五分鐘掃一眼關(guān)鍵指標(biāo)有異常趨勢(shì)就提前處理不要等到用戶反饋慢了才去查。7.6 一個(gè)實(shí)用的調(diào)試技巧用Shell驗(yàn)證Java代碼的結(jié)果當(dāng)你用Java代碼寫入數(shù)據(jù)后不確定是否成功最快的驗(yàn)證方式是用HBase Shell查一下scan user_behavior, {LIMIT 5} get user_behavior, user_001Shell的結(jié)果和Java API的結(jié)果應(yīng)該一致。如果不一致先檢查是不是連到了不同的集群ZooKeeper地址配錯(cuò)了再檢查表名和列族名是否拼寫正確。這個(gè)技巧在調(diào)試階段能省很多時(shí)間。代碼寫多了會(huì)發(fā)現(xiàn)HBase的Java API本身并不復(fù)雜難的是對(duì)數(shù)據(jù)模型的理解和對(duì)集群行為的把握。同樣的API調(diào)用在不同的行鍵設(shè)計(jì)和表結(jié)構(gòu)下性能可能差幾十倍。所以不要只盯著代碼怎么寫多想想數(shù)據(jù)怎么組織、訪問模式是什么、集群能不能扛住。這些才是決定項(xiàng)目成敗的關(guān)鍵。 Java操作HBase實(shí)戰(zhàn)：從建表到性能調(diào)優(yōu)的完整指南
1. 為什么要在Java里直接操作HBase而不是繞道走很多剛接觸大數(shù)據(jù)存儲(chǔ)層的人會(huì)有一個(gè)疑問HBase本身已經(jīng)提供了Shell客戶端敲幾行命令就能建表、插數(shù)據(jù)、查記錄為什么還要費(fèi)勁用Java寫代碼去操作它這個(gè)問題我在帶新人的時(shí)候被問過不下十次。答案其實(shí)不復(fù)雜——Shell適合調(diào)試和臨時(shí)驗(yàn)證但真正落到生產(chǎn)系統(tǒng)里數(shù)據(jù)寫入、讀取、掃描這些動(dòng)作必須嵌入到業(yè)務(wù)邏輯中由程序自動(dòng)完成不可能靠人工敲命令。你總不能讓運(yùn)維同事半夜爬起來手動(dòng)往HBase里插一條記錄。HBase作為構(gòu)建在HDFS之上的分布式列式存儲(chǔ)系統(tǒng)天然適合海量數(shù)據(jù)的隨機(jī)讀寫。它的數(shù)據(jù)模型和傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)完全不同沒有固定的列定義每一行可以有任意多的列族和列限定符同一列族下的數(shù)據(jù)物理上存儲(chǔ)在一起。這種設(shè)計(jì)讓它在稀疏數(shù)據(jù)、寬表場(chǎng)景下表現(xiàn)非常出色。而Java API是HBase最原生、最完整的操作接口官方提供的客戶端就是Java寫的其他語(yǔ)言的客戶端本質(zhì)上也是通過Thrift網(wǎng)關(guān)做了一層封裝。所以如果你想真正吃透HBaseJava API是繞不開的一關(guān)。這篇文章面向的是已經(jīng)了解HBase基本概念表、行鍵、列族、時(shí)間戳但還沒動(dòng)手用Java寫過操作代碼的開發(fā)者。我會(huì)從環(huán)境依賴開始一步步把建表、寫入、查詢、掃描、刪除這些核心操作講清楚同時(shí)把我在實(shí)際項(xiàng)目中踩過的坑和總結(jié)的經(jīng)驗(yàn)一并分享出來。代碼可以直接復(fù)制到你的工程里跑參數(shù)和配置我會(huì)解釋清楚為什么這么設(shè)。2. 動(dòng)手之前依賴、配置與連接池的取舍2.1 Maven依賴到底該引哪些包用Java操作HBase第一步是把客戶端依賴引入工程。HBase的客戶端依賴并不算輕量因?yàn)樗鼤?huì)連帶拉入Hadoop相關(guān)的若干jar包。以HBase 2.x版本為例核心依賴是hbase-client但實(shí)際使用中往往還需要hbase-common和hadoop-common。如果你用的是Maven可以這樣配置dependency groupIdorg.apache.hbase/groupId artifactIdhbase-client/artifactId version2.4.11/version /dependency dependency groupIdorg.apache.hbase/groupId artifactIdhbase-common/artifactId version2.4.11/version /dependency這里有個(gè)容易踩的坑hbase-client的版本必須和服務(wù)端HBase的版本保持兼容。HBase 1.x和2.x的API差異不小比如Connection接口在1.x里還是HConnection到了2.x才統(tǒng)一成Connection。如果你拿2.x的客戶端去連1.x的服務(wù)端編譯能過但運(yùn)行時(shí)可能報(bào)各種奇怪的錯(cuò)。我的建議是客戶端版本和服務(wù)端大版本保持一致小版本盡量對(duì)齊。另外很多教程會(huì)讓你引入hbase-server這是不對(duì)的。hbase-server包含了RegionServer的實(shí)現(xiàn)體積巨大客戶端根本不需要。引入它只會(huì)讓你的工程打包出來多出幾十兆的無用依賴還可能引起類沖突。2.2 Configuration對(duì)象的正確構(gòu)造方式連接HBase需要一個(gè)Configuration對(duì)象它承載了ZooKeeper地址、端口等關(guān)鍵信息。最直接的方式是手動(dòng)設(shè)置Configuration conf HBaseConfiguration.create(); conf.set(hbase.zookeeper.quorum, zk-host-1,zk-host-2,zk-host-3); conf.set(hbase.zookeeper.property.clientPort, 2181);HBaseConfiguration.create()會(huì)自動(dòng)加載classpath下的hbase-site.xml如果這個(gè)文件存在里面的配置會(huì)覆蓋你手動(dòng)設(shè)置的值。這一點(diǎn)要特別注意有時(shí)候你代碼里明明設(shè)了正確的ZooKeeper地址但連上去發(fā)現(xiàn)是另一套集群八成就是hbase-site.xml在作怪。排查的時(shí)候可以先打印一下conf.get(hbase.zookeeper.quorum)看看實(shí)際生效的值是什么。ZooKeeper的地址建議寫全所有節(jié)點(diǎn)用逗號(hào)分隔。只寫一個(gè)節(jié)點(diǎn)雖然也能連上但那個(gè)節(jié)點(diǎn)掛了客戶端就找不到集群了。HBase客戶端會(huì)從ZooKeeper上讀取hbase:meta表的位置信息所以ZooKeeper的穩(wěn)定性直接決定了客戶端能否正常連接。2.3 Connection是重量級(jí)對(duì)象千萬(wàn)別每次new這是新手最容易犯的錯(cuò)誤也是性能殺手。Connection對(duì)象的創(chuàng)建涉及與ZooKeeper的握手、元數(shù)據(jù)表的讀取等一系列網(wǎng)絡(luò)交互開銷很大。如果你每次操作都ConnectionFactory.createConnection(conf)在高并發(fā)場(chǎng)景下會(huì)把ZooKeeper壓垮連接數(shù)暴漲最終導(dǎo)致整個(gè)集群響應(yīng)變慢。正確的做法是把Connection做成單例整個(gè)應(yīng)用生命周期內(nèi)只創(chuàng)建一次所有線程共享。Connection本身是線程安全的可以放心地在多線程環(huán)境下使用。但要注意從Connection獲取的Table對(duì)象不是線程安全的每個(gè)線程應(yīng)該自己從Connection里拿一個(gè)Table實(shí)例。public class HBaseConnector { private static volatile Connection connection; public static Connection getConnection() throws IOException { if (connection null || connection.isClosed()) { synchronized (HBaseConnector.class) { if (connection null || connection.isClosed()) { Configuration conf HBaseConfiguration.create(); conf.set(hbase.zookeeper.quorum, zk-host-1,zk-host-2,zk-host-3); connection ConnectionFactory.createConnection(conf); } } } return connection; } }這段代碼用了雙重檢查鎖來保證線程安全。volatile關(guān)鍵字不能省否則可能出現(xiàn)指令重排序?qū)е履玫轿闯跏蓟耆膶?duì)象。雖然看起來有點(diǎn)啰嗦但這是經(jīng)過驗(yàn)證的可靠寫法。3. 建表這件事表描述符與預(yù)分區(qū)的實(shí)際寫法3.1 TableDescriptor和ColumnFamilyDescriptor的構(gòu)建邏輯在HBase 2.x里建表用的是Admin對(duì)象配合TableDescriptorBuilder和ColumnFamilyDescriptorBuilder。這套Builder模式比1.x時(shí)代的HTableDescriptor要清晰不少但初次接觸的人容易被繞暈。核心邏輯是先構(gòu)建列族描述符再把列族加進(jìn)表描述符最后通過Admin創(chuàng)建表。Admin admin connection.getAdmin(); ColumnFamilyDescriptor cfDescriptor ColumnFamilyDescriptorBuilder .newBuilder(Bytes.toBytes(info)) .setMaxVersions(3) .setTimeToLive(7 * 24 * 60 * 60) .build(); TableDescriptor tableDescriptor TableDescriptorBuilder .newBuilder(TableName.valueOf(user_behavior)) .setColumnFamily(cfDescriptor) .build(); if (!admin.tableExists(TableName.valueOf(user_behavior))) { admin.createTable(tableDescriptor); }setMaxVersions(3)表示每個(gè)單元格保留最近3個(gè)版本的數(shù)據(jù)。HBase的版本控制是按時(shí)間戳來的每次寫入都會(huì)帶上時(shí)間戳不指定的話默認(rèn)用當(dāng)前時(shí)間。如果你只需要最新值設(shè)成1就行能省不少存儲(chǔ)空間。setTimeToLive設(shè)置的是數(shù)據(jù)的存活時(shí)間單位是秒上面設(shè)的是7天。超過這個(gè)時(shí)間的數(shù)據(jù)會(huì)在Major Compaction時(shí)被清理掉。3.2 預(yù)分區(qū)別讓所有數(shù)據(jù)擠在一個(gè)Region里新建的表默認(rèn)只有一個(gè)Region所有寫入都會(huì)落到這一個(gè)Region上。在數(shù)據(jù)量小的時(shí)候沒問題但當(dāng)寫入量上來之后單個(gè)Region會(huì)成為瓶頸而且自動(dòng)分裂的過程會(huì)引起短暫的不可用。所以生產(chǎn)環(huán)境建表時(shí)一定要做預(yù)分區(qū)。預(yù)分區(qū)有兩種常用方式。第一種是直接指定分割點(diǎn)byte[][] splitKeys new byte[][] { Bytes.toBytes(1), Bytes.toBytes(2), Bytes.toBytes(3), Bytes.toBytes(4), Bytes.toBytes(5), Bytes.toBytes(6), Bytes.toBytes(7), Bytes.toBytes(8), Bytes.toBytes(9) }; admin.createTable(tableDescriptor, splitKeys);這樣會(huì)創(chuàng)建10個(gè)Region行鍵以0開頭的落在第一個(gè)Region以1開頭的落在第二個(gè)以此類推。分割點(diǎn)的選擇取決于你的行鍵分布特征。如果行鍵是用戶ID的哈希值那均勻取模分割就行如果行鍵有時(shí)間前綴那就要小心熱點(diǎn)問題。第二種方式是用createTable的重載方法指定Region數(shù)量和分割算法但實(shí)際用得最多的還是手動(dòng)指定分割點(diǎn)因?yàn)榭煽匦宰顝?qiáng)。注意預(yù)分區(qū)的分割點(diǎn)必須是有序的而且不能重復(fù)。如果傳入無序的數(shù)組創(chuàng)建表時(shí)會(huì)直接拋異常。另外分割點(diǎn)的數(shù)量決定了Region的數(shù)量Region數(shù)量等于分割點(diǎn)數(shù)量加一。3.3 列族數(shù)量不是越多越好HBase的列族在物理上是分開存儲(chǔ)的每個(gè)列族對(duì)應(yīng)一組HFile。列族越多寫入時(shí)的flush和compaction開銷就越大。官方建議一張表的列族數(shù)量控制在2到3個(gè)以內(nèi)。我見過有人把每個(gè)字段都設(shè)成一個(gè)列族結(jié)果寫入性能慘不忍睹。列族的命名也有講究。用簡(jiǎn)短的英文單詞比如info、data、meta不要用中文或者特殊字符。雖然HBase底層用字節(jié)數(shù)組存儲(chǔ)理論上支持任意字符但列族名會(huì)出現(xiàn)在HFile路徑和監(jiān)控指標(biāo)里用奇怪的字符會(huì)給運(yùn)維帶來麻煩。4. 寫入與讀取Put、Get和批量操作的性能差異4.1 單條Put的寫法與時(shí)間戳控制寫入數(shù)據(jù)用Put對(duì)象指定行鍵、列族、列限定符和值Table table connection.getTable(TableName.valueOf(user_behavior)); Put put new Put(Bytes.toBytes(user_001)); put.addColumn(Bytes.toBytes(info), Bytes.toBytes(name), Bytes.toBytes(張三)); put.addColumn(Bytes.toBytes(info), Bytes.toBytes(age), Bytes.toBytes(28)); put.addColumn(Bytes.toBytes(info), Bytes.toBytes(city), Bytes.toBytes(北京)); table.put(put);addColumn有多個(gè)重載版本可以指定時(shí)間戳。如果不指定HBase會(huì)用RegionServer的當(dāng)前時(shí)間。在需要回放歷史數(shù)據(jù)或者做數(shù)據(jù)修正的場(chǎng)景下手動(dòng)指定時(shí)間戳很有用。但要注意時(shí)間戳是long類型單位是毫秒。如果你寫入的時(shí)間戳比已有數(shù)據(jù)的時(shí)間戳小那這條數(shù)據(jù)雖然寫進(jìn)去了但查詢時(shí)默認(rèn)返回的是時(shí)間戳最大的版本你可能看不到剛寫的數(shù)據(jù)。table.put(put)每次調(diào)用都是一次RPC請(qǐng)求。如果你要寫入大量數(shù)據(jù)一條一條put效率極低。這時(shí)候應(yīng)該用BufferedMutator或者批量put(ListPut)。4.2 批量寫入BufferedMutator與List 的選擇table.put(ListPut)會(huì)把一批Put打包成一個(gè)RPC請(qǐng)求發(fā)給RegionServer減少了網(wǎng)絡(luò)往返次數(shù)。但它的缺點(diǎn)是同步的調(diào)用線程會(huì)阻塞直到所有數(shù)據(jù)寫入完成。而且如果一批數(shù)據(jù)太大會(huì)導(dǎo)致單次RPC超時(shí)。BufferedMutator則是異步的它內(nèi)部維護(hù)了一個(gè)緩沖區(qū)數(shù)據(jù)先寫到緩沖區(qū)達(dá)到閾值后自動(dòng)批量發(fā)送。寫入線程不需要等待服務(wù)端確認(rèn)吞吐量更高。BufferedMutatorParams params new BufferedMutatorParams(TableName.valueOf(user_behavior)) .writeBufferSize(4 * 1024 * 1024); BufferedMutator mutator connection.getBufferedMutator(params); for (int i 0; i 100000; i) { Put put new Put(Bytes.toBytes(user_ i)); put.addColumn(Bytes.toBytes(info), Bytes.toBytes(age), Bytes.toBytes(String.valueOf(i % 100))); mutator.mutate(put); } mutator.flush(); mutator.close();writeBufferSize設(shè)的是緩沖區(qū)大小默認(rèn)是2MB。設(shè)大一點(diǎn)能提高吞吐量但也會(huì)增加內(nèi)存占用和丟數(shù)據(jù)的風(fēng)險(xiǎn)——如果客戶端進(jìn)程崩潰緩沖區(qū)里還沒發(fā)送的數(shù)據(jù)就丟了。所以BufferedMutator適合對(duì)可靠性要求不是極端高的場(chǎng)景比如日志采集。如果數(shù)據(jù)一條都不能丟還是老老實(shí)實(shí)用同步批量寫。4.3 Get查詢指定列族和列限定符的粒度控制讀取單行數(shù)據(jù)用GetGet get new Get(Bytes.toBytes(user_001)); get.addFamily(Bytes.toBytes(info)); get.addColumn(Bytes.toBytes(info), Bytes.toBytes(name)); Result result table.get(get); byte[] nameBytes result.getValue(Bytes.toBytes(info), Bytes.toBytes(name)); String name Bytes.toString(nameBytes);addFamily和addColumn是可選的。如果不指定Get會(huì)返回該行所有列族的所有列。在寬表場(chǎng)景下一行可能有上百個(gè)列全查出來既浪費(fèi)網(wǎng)絡(luò)帶寬又浪費(fèi)內(nèi)存。所以精確指定需要的列是一個(gè)好習(xí)慣。Result對(duì)象還提供了rawCells()方法可以拿到所有單元格的詳細(xì)信息包括時(shí)間戳。如果你需要做版本對(duì)比或者數(shù)據(jù)審計(jì)這個(gè)方法很有用。4.4 Scan掃描setStartRow和setStopRow的邊界陷阱Scan用于范圍查詢是HBase最強(qiáng)大的功能之一Scan scan new Scan(); scan.setStartRow(Bytes.toBytes(user_001)); scan.setStopRow(Bytes.toBytes(user_100)); scan.addFamily(Bytes.toBytes(info)); scan.setCaching(500); scan.setBatch(100); ResultScanner scanner table.getScanner(scan); for (Result result : scanner) { // 處理每一行 } scanner.close();這里有幾個(gè)關(guān)鍵點(diǎn)。setStartRow是包含的setStopRow是不包含的。也就是說上面的Scan會(huì)返回行鍵從user_001到user_099的數(shù)據(jù)user_100不會(huì)被返回。這個(gè)左閉右開的區(qū)間設(shè)計(jì)經(jīng)常讓人搞混我第一次用的時(shí)候就多查了一條數(shù)據(jù)。setCaching(500)控制的是每次RPC從服務(wù)端拉取多少行到客戶端。默認(rèn)值很小好像是100在掃描大量數(shù)據(jù)時(shí)會(huì)導(dǎo)致頻繁的RPC調(diào)用。設(shè)大一點(diǎn)能顯著提高掃描速度但也會(huì)增加客戶端內(nèi)存壓力。500到1000是一個(gè)比較平衡的值。setBatch(100)控制的是每行返回多少個(gè)單元格。這個(gè)參數(shù)只在行特別寬列非常多的時(shí)候才需要設(shè)置。如果一行有幾千個(gè)列一次性返回會(huì)導(dǎo)致單次RPC響應(yīng)過大甚至OOM。設(shè)成100表示每行分多次返回。注意ResultScanner使用完畢后必須關(guān)閉否則會(huì)泄漏連接資源。建議用try-with-resources或者try-finally保證關(guān)閉。5. 刪除操作與過濾器那些文檔里不會(huì)細(xì)說的細(xì)節(jié)5.1 Delete的三種粒度行、列族、列刪除數(shù)據(jù)用Delete對(duì)象粒度可以細(xì)到列// 刪除整行 Delete deleteRow new Delete(Bytes.toBytes(user_001)); // 刪除整個(gè)列族 Delete deleteFamily new Delete(Bytes.toBytes(user_001)); deleteFamily.addFamily(Bytes.toBytes(info)); // 刪除指定列 Delete deleteColumn new Delete(Bytes.toBytes(user_001)); deleteColumn.addColumn(Bytes.toBytes(info), Bytes.toBytes(city)); table.delete(deleteColumn);HBase的刪除并不是立即物理刪除數(shù)據(jù)而是寫入一個(gè)墓碑標(biāo)記tombstone。真正的數(shù)據(jù)清理發(fā)生在Major Compaction時(shí)。所以刪除操作本身很快但不會(huì)立刻釋放存儲(chǔ)空間。如果你刪了大量數(shù)據(jù)后發(fā)現(xiàn)磁盤沒降不要慌等compaction跑完就好了。還有一個(gè)容易忽略的點(diǎn)刪除操作也會(huì)帶上時(shí)間戳。如果你刪除時(shí)指定的時(shí)間戳小于數(shù)據(jù)的時(shí)間戳那刪除標(biāo)記不會(huì)生效數(shù)據(jù)依然能查到。默認(rèn)情況下Delete使用當(dāng)前時(shí)間戳所以一般不會(huì)有問題。但如果你在做數(shù)據(jù)修正手動(dòng)指定了舊時(shí)間戳就要小心這個(gè)坑。5.2 Filter的實(shí)戰(zhàn)用法PrefixFilter和RowFilter過濾器是HBase Scan的利器可以在服務(wù)端過濾數(shù)據(jù)減少網(wǎng)絡(luò)傳輸。常用的有PrefixFilter、RowFilter、SingleColumnValueFilter等。// 前綴過濾只返回行鍵以u(píng)ser_1開頭的行 PrefixFilter prefixFilter new PrefixFilter(Bytes.toBytes(user_1)); Scan scan new Scan(); scan.setFilter(prefixFilter); // 行鍵正則過濾 RowFilter rowFilter new RowFilter( CompareFilter.CompareOp.EQUAL, new RegexStringComparator(user_\\d{3}) ); scan.setFilter(rowFilter);PrefixFilter的效率很高因?yàn)樗梢灾苯佣ㄎ坏狡鹗夹腥缓箜樞驋呙璧讲粷M足前綴為止。RowFilter配合正則表達(dá)式則靈活得多但正則是逐行匹配的性能不如PrefixFilter。如果前綴能滿足需求優(yōu)先用PrefixFilter。SingleColumnValueFilter用于按列值過濾但要注意它的一個(gè)特性如果某行沒有指定的列默認(rèn)行為是跳過這行。如果你希望沒有該列的行也被返回需要調(diào)用setFilterIfMissing(false)。這個(gè)默認(rèn)行為坑過不少人。5.3 過濾器組合FilterList的AND與OR多個(gè)過濾器可以組合使用FilterList filterList new FilterList(FilterList.Operator.MUST_PASS_ALL); filterList.addFilter(new PrefixFilter(Bytes.toBytes(user_))); filterList.addFilter(new RowFilter( CompareFilter.CompareOp.EQUAL, new RegexStringComparator(.*_00[1-9]) )); scan.setFilter(filterList);MUST_PASS_ALL相當(dāng)于AND所有過濾器都通過才返回MUST_PASS_ANY相當(dāng)于OR任意一個(gè)通過就返回。過濾器組合的順序會(huì)影響性能把過濾力度大的放在前面能減少后續(xù)過濾器的計(jì)算量。6. 連接管理與異常處理生產(chǎn)環(huán)境必須考慮的事6.1 連接泄漏的常見原因與排查方法Connection和Table都是需要關(guān)閉的資源。雖然Connection建議做成單例長(zhǎng)期持有但Table對(duì)象在用完后應(yīng)該及時(shí)關(guān)閉。如果你在代碼里頻繁connection.getTable()卻不關(guān)閉RegionServer上的連接數(shù)會(huì)持續(xù)增長(zhǎng)最終達(dá)到上限后拒絕新連接。排查連接泄漏的一個(gè)實(shí)用方法是看RegionServer的Web UI里面有當(dāng)前活躍的RPC連接數(shù)。如果這個(gè)數(shù)字只增不減基本可以確定有泄漏。另一個(gè)方法是在代碼里加日志記錄每次getTable和close的調(diào)用對(duì)比數(shù)量是否匹配。6.2 RetriesExhaustedException的觸發(fā)條件與應(yīng)對(duì)RetriesExhaustedException是HBase客戶端最常見的異常之一通常意味著客戶端重試了多次仍然無法完成操作。觸發(fā)原因可能有很多RegionServer宕機(jī)、網(wǎng)絡(luò)抖動(dòng)、Region正在分裂、ZooKeeper會(huì)話超時(shí)等。應(yīng)對(duì)這個(gè)異常首先要看異常信息里的詳細(xì)描述它會(huì)告訴你重試了多少次、每次失敗的原因是什么。如果是短暫的網(wǎng)絡(luò)問題客戶端會(huì)自動(dòng)重試并恢復(fù)如果是RegionServer真的掛了那需要等Master把Region重新分配后才能恢復(fù)。調(diào)整重試參數(shù)可以改變客戶端的行為conf.set(hbase.client.retries.number, 5); conf.set(hbase.client.pause, 1000); conf.set(hbase.client.operation.timeout, 30000);hbase.client.retries.number是重試次數(shù)默認(rèn)是15次設(shè)小一點(diǎn)可以讓失敗更快暴露出來。hbase.client.pause是重試間隔的基數(shù)實(shí)際間隔會(huì)在這個(gè)基礎(chǔ)上做指數(shù)退避。hbase.client.operation.timeout是單次操作的超時(shí)時(shí)間單位毫秒。6.3 批量寫入時(shí)的部分失敗處理用table.put(ListPut)批量寫入時(shí)如果部分?jǐn)?shù)據(jù)失敗HBase會(huì)拋出RetriesExhaustedWithDetailsException。這個(gè)異常里包含了成功和失敗的記錄列表try { table.put(putList); } catch (RetriesExhaustedWithDetailsException e) { ListThrowable exceptions e.getCauses(); ListRow failedRows e.getFailedRows(); // 對(duì)失敗的行做重試或記錄 }拿到失敗的行之后可以根據(jù)異常類型決定是重試還是丟棄。如果是NotServingRegionException說明Region正在遷移等一會(huì)兒重試通常能成功如果是DoNotRetryIOException那重試也沒用需要檢查數(shù)據(jù)或表結(jié)構(gòu)。7. 我踩過的那些坑與性能調(diào)優(yōu)的實(shí)戰(zhàn)心得7.1 行鍵設(shè)計(jì)不當(dāng)導(dǎo)致的熱點(diǎn)問題行鍵設(shè)計(jì)是HBase使用中最重要的一環(huán)沒有之一。我見過一個(gè)項(xiàng)目用時(shí)間戳作為行鍵前綴結(jié)果所有寫入都集中在最后一個(gè)Region上其他Region閑著集群資源嚴(yán)重浪費(fèi)。這就是典型的熱點(diǎn)問題。解決熱點(diǎn)問題的常用方法是給行鍵加鹽或者做哈希。加鹽就是在行鍵前面拼一個(gè)隨機(jī)前綴比如(hash(userId) % 10) _ userId。這樣數(shù)據(jù)會(huì)均勻分布到10個(gè)Region上。但加鹽之后按userId范圍查詢就變得困難了因?yàn)橄嗤瑄serId的數(shù)據(jù)可能在不同的Region上。所以加鹽適合隨機(jī)讀寫的場(chǎng)景不適合范圍掃描。另一種方法是反轉(zhuǎn)行鍵。如果行鍵是遞增的ID反轉(zhuǎn)之后高位變化低位不變也能起到分散寫入的效果。比如user_0001反轉(zhuǎn)成1000_resu。這種方法適合ID長(zhǎng)度固定的場(chǎng)景。7.2 Scan時(shí)setCaching設(shè)太大反而變慢setCaching設(shè)大一點(diǎn)能減少RPC次數(shù)但并不是越大越好。如果設(shè)成10000客戶端一次要從服務(wù)端拉10000行數(shù)據(jù)這會(huì)導(dǎo)致單次RPC響應(yīng)非常大網(wǎng)絡(luò)傳輸時(shí)間長(zhǎng)客戶端內(nèi)存占用高。而且如果掃描到一半客戶端處理不過來服務(wù)端可能已經(jīng)超時(shí)了。我的經(jīng)驗(yàn)值是500到1000。在這個(gè)范圍內(nèi)RPC次數(shù)和單次數(shù)據(jù)量比較平衡。當(dāng)然具體值還要看單行數(shù)據(jù)的大小如果每行數(shù)據(jù)很大比如幾KB那caching設(shè)小一點(diǎn)更合適。7.3 客戶端版本與服務(wù)端不匹配的詭異報(bào)錯(cuò)前面提過版本兼容的問題這里再展開說一下。HBase 2.x的客戶端連1.x的服務(wù)端最常見的報(bào)錯(cuò)是NoSuchMethodError或者ClassNotFoundException。因?yàn)?.x的API里有些方法在1.x里不存在編譯時(shí)用的是2.x的jar所以能過運(yùn)行時(shí)加載的是1.x的類就找不到了。還有一種情況是Hadoop版本不匹配。HBase依賴Hadoop的Configuration類如果客戶端引入的Hadoop版本和服務(wù)端的差異太大Configuration的序列化格式可能不兼容導(dǎo)致連接建立后讀取配置出錯(cuò)。排查這類問題先確認(rèn)客戶端和服務(wù)端的版本矩陣然后看異常堆棧里是哪個(gè)類出的問題。7.4 關(guān)于Bytes工具類的使用建議HBase提供了Bytes工具類來做byte[]和基本類型之間的轉(zhuǎn)換。用的時(shí)候要注意Bytes.toBytes(String)用的是UTF-8編碼Bytes.toString(byte[])也是按UTF-8解碼。如果數(shù)據(jù)里包含非UTF-8的字節(jié)轉(zhuǎn)換會(huì)出問題。對(duì)于二進(jìn)制數(shù)據(jù)直接用byte[]操作不要經(jīng)過String轉(zhuǎn)換。另外Bytes.toBytes(int)和Bytes.toBytes(long)生成的字節(jié)數(shù)組長(zhǎng)度不同比較的時(shí)候要注意。行鍵比較是按字節(jié)序進(jìn)行的不是按數(shù)值大小。比如Bytes.toBytes(10)和Bytes.toBytes(9)比較結(jié)果是10小于9因?yàn)樽址?的ASCII碼小于9。如果行鍵是數(shù)值建議統(tǒng)一用固定長(zhǎng)度編碼或者用Bytes.toBytes(long)保證長(zhǎng)度一致。7.5 監(jiān)控與調(diào)優(yōu)的日常檢查項(xiàng)在生產(chǎn)環(huán)境跑HBase客戶端有幾個(gè)指標(biāo)需要定期關(guān)注。RegionServer的blockCacheHitRatio反映讀緩存命中率如果低于0.8說明緩存不夠或者訪問模式太隨機(jī)。compactionQueueSize如果持續(xù)大于0說明compaction跟不上寫入速度需要調(diào)整compaction策略或者增加RegionServer資源?？蛻舳说膔pcQueueSize如果經(jīng)常滿說明寫入壓力超過了RegionServer的處理能力需要考慮擴(kuò)容或者優(yōu)化行鍵設(shè)計(jì)。這些指標(biāo)可以通過HBase自帶的Web UI查看也可以接入監(jiān)控系統(tǒng)做告警。我的習(xí)慣是每天早上花五分鐘掃一眼關(guān)鍵指標(biāo)有異常趨勢(shì)就提前處理不要等到用戶反饋慢了才去查。7.6 一個(gè)實(shí)用的調(diào)試技巧用Shell驗(yàn)證Java代碼的結(jié)果當(dāng)你用Java代碼寫入數(shù)據(jù)后不確定是否成功最快的驗(yàn)證方式是用HBase Shell查一下scan user_behavior, {LIMIT 5} get user_behavior, user_001Shell的結(jié)果和Java API的結(jié)果應(yīng)該一致。如果不一致先檢查是不是連到了不同的集群ZooKeeper地址配錯(cuò)了再檢查表名和列族名是否拼寫正確。這個(gè)技巧在調(diào)試階段能省很多時(shí)間。代碼寫多了會(huì)發(fā)現(xiàn)HBase的Java API本身并不復(fù)雜難的是對(duì)數(shù)據(jù)模型的理解和對(duì)集群行為的把握。同樣的API調(diào)用在不同的行鍵設(shè)計(jì)和表結(jié)構(gòu)下性能可能差幾十倍。所以不要只盯著代碼怎么寫多想想數(shù)據(jù)怎么組織、訪問模式是什么、集群能不能扛住。這些才是決定項(xiàng)目成敗的關(guān)鍵。