業(yè)內(nèi)做海量數(shù)據(jù)存儲(chǔ)的團(tuán)隊(duì)這幾年十有八九都遇到過(guò)這類場(chǎng)景業(yè)務(wù)量一上來(lái)傳統(tǒng)關(guān)系庫(kù)撐不住了分庫(kù)分表又麻煩得要命最終把目光放到 HBase 上。但 HBase 這套東西網(wǎng)上資料碎片化嚴(yán)重真要?jiǎng)邮执罱?、調(diào)優(yōu)、排障坑一個(gè)接一個(gè)。我以多年實(shí)操經(jīng)驗(yàn)把 HBase 從入門到落地全流程梳理一遍把那些文檔里沒(méi)寫(xiě)透的原理、參數(shù)取舍、踩坑記錄一次講清。這套內(nèi)容適合誰(shuí)準(zhǔn)備引入列式存儲(chǔ)方案的架構(gòu)師、被線上 HBase 性能問(wèn)題折磨的運(yùn)維和開(kāi)發(fā)、想系統(tǒng)補(bǔ)齊分布式數(shù)據(jù)庫(kù)知識(shí)的學(xué)生?？赐昴隳苊靼?HBase 演進(jìn)的邏輯、底層存儲(chǔ)機(jī)制、讀寫(xiě)全鏈路原理以及高頻問(wèn)題的排查方向照著實(shí)操路徑去搭一套可用集群?jiǎn)栴}不大。1. HBase 到底是什么它解決了哪些問(wèn)題1.1 HBase 在分布式數(shù)據(jù)庫(kù)里的身位先給 HBase 一個(gè)通俗定位它是運(yùn)行在 Hadoop 生態(tài)之上的分布式、面向列族的 NoSQL 數(shù)據(jù)庫(kù)定位是海量結(jié)構(gòu)化大表的實(shí)時(shí)讀寫(xiě)。注意幾個(gè)關(guān)鍵詞分布式、列族、海量、實(shí)時(shí)。分布式它把一張表在物理上拆成多個(gè)分片分布在不同節(jié)點(diǎn)上并行服務(wù)。列族它的數(shù)據(jù)按列族物理隔離同一列族內(nèi)的列往往有相似的訪問(wèn)模式或數(shù)據(jù)特性。海量單表百億行、PB 級(jí)數(shù)據(jù)是它擅長(zhǎng)的場(chǎng)景。實(shí)時(shí)這里的實(shí)時(shí)指毫秒到秒級(jí)延遲的隨機(jī)讀寫(xiě)區(qū)別于離線批量處理。它擅長(zhǎng)什么不擅長(zhǎng)什么一開(kāi)始就要心里有數(shù)。HBase 適合海量明細(xì)數(shù)據(jù)的寫(xiě)入與按 RowKey 查詢比如訂單流水、日志明細(xì)、用戶行為軌跡、設(shè)備上報(bào)數(shù)據(jù)。它天生不適合復(fù)雜的關(guān)聯(lián)查詢、聚合分析、事務(wù)型強(qiáng)一致場(chǎng)景。把 HBase 當(dāng)關(guān)系庫(kù)用方向就錯(cuò)了。HBase 實(shí)際上是 Google BigTable 模型的開(kāi)源實(shí)現(xiàn)。Google 當(dāng)年面對(duì)海量網(wǎng)頁(yè)數(shù)據(jù)的存儲(chǔ)和分析需求發(fā)現(xiàn)傳統(tǒng)數(shù)據(jù)庫(kù)根本無(wú)法支撐這種量級(jí)于是提出了 BigTable 的分布式存儲(chǔ)模型。HBase 借鑒了這一模型把稀疏、多維、有序的 Map 作為核心數(shù)據(jù)模型配合 Hadoop HDFS 作為底層存儲(chǔ)解決了海量數(shù)據(jù)水平擴(kuò)展的問(wèn)題。這個(gè)“借鑒”不是簡(jiǎn)單的拷貝HBase 團(tuán)隊(duì)基于 JVM 生態(tài)和 Hadoop 生態(tài)做了大量工程化落地的工作才形成了我們今天看到的這套系統(tǒng)。1.2 HBase 和傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)的本質(zhì)差異很多剛接觸 HBase 的人會(huì)用關(guān)系庫(kù)的思維去套它結(jié)果處處碰壁。這里把最關(guān)鍵的差異列出來(lái)能省下你后面至少三個(gè)月的摸索時(shí)間。存儲(chǔ)模型關(guān)系庫(kù)是行式存儲(chǔ)一張表的所有列物理上連續(xù)存儲(chǔ)適合整行讀取和事務(wù)性操作HBase 是列族式存儲(chǔ)同一列族的數(shù)據(jù)連續(xù)存儲(chǔ)但不同列族各自獨(dú)立適合按列族的局部讀取和批量掃描。索引機(jī)制關(guān)系庫(kù)靠二級(jí)索引任意列都可以建索引加速查詢HBase 只認(rèn) RowKey 這一個(gè)天然索引按 RowKey 的查詢性能最高其他列的查詢要么全表掃描要么依賴額外方案。事務(wù)能力關(guān)系庫(kù)支持 ACID 事務(wù)多行多表操作可以保持強(qiáng)一致HBase 只支持行級(jí)別的 ACID跨行、跨表的事務(wù)能力非常弱業(yè)界通常用“單行事務(wù) 業(yè)務(wù)補(bǔ)償”的方式來(lái)處理。擴(kuò)展方式關(guān)系庫(kù)的擴(kuò)展以垂直擴(kuò)展為主數(shù)據(jù)量到一定程度就得換更強(qiáng)的硬件HBase 天然支持水平擴(kuò)展數(shù)據(jù)量大了直接加 RegionServer 節(jié)點(diǎn)就行擴(kuò)容過(guò)程中基本不需要停機(jī)。這個(gè)對(duì)比不是說(shuō) HBase 比關(guān)系庫(kù)強(qiáng)或弱而是讓你知道在什么場(chǎng)景下該選誰(shuí)。一個(gè)常見(jiàn)的合理架構(gòu)是關(guān)系庫(kù)負(fù)責(zé)核心交易類數(shù)據(jù)HBase 負(fù)責(zé)海量明細(xì)數(shù)據(jù)和各類流水?dāng)?shù)據(jù)的存儲(chǔ)與查詢兩者配合使用。1.3 HBase 的生態(tài)位置和應(yīng)用場(chǎng)景圖譜從生態(tài)位置來(lái)看HBase 是 Hadoop 體系里唯一能提供實(shí)時(shí)隨機(jī)讀寫(xiě)能力的組件。HDFS 解決存儲(chǔ)問(wèn)題但不支持隨機(jī)更新Hive 解決離線分析問(wèn)題但延遲太高HBase 補(bǔ)上了“實(shí)時(shí)隨機(jī)讀寫(xiě)”這塊拼圖。在實(shí)際應(yīng)用中比較典型的幾個(gè)場(chǎng)景訂單流水存儲(chǔ)某電商平臺(tái)的訂單表每天新增幾千萬(wàn)條記錄總量達(dá)到幾十億行。這些數(shù)據(jù)按用戶維度查詢頻率高按時(shí)間范圍掃描也是常態(tài)。HBase 的 RowKey 設(shè)計(jì)成“用戶 ID 反轉(zhuǎn) 時(shí)間戳”的格式既能按用戶查也能按時(shí)間范圍掃。用戶行為軌跡記錄用戶點(diǎn)擊、瀏覽、搜索行為每天產(chǎn)生海量日志。這類數(shù)據(jù)寫(xiě)入量極大但單條數(shù)據(jù)價(jià)值密度低適合先寫(xiě)入 HBase 存儲(chǔ)后續(xù)再通過(guò)其他渠道分析。物聯(lián)網(wǎng)設(shè)備數(shù)據(jù)上報(bào)設(shè)備每秒上報(bào)一次狀態(tài)數(shù)據(jù)一天下來(lái)單設(shè)備就有 86400 條記錄百萬(wàn)級(jí)設(shè)備就是每天數(shù)億條。HBase 的高吞吐寫(xiě)入能力在這里發(fā)揮得淋漓盡致RowKey 設(shè)計(jì)成“設(shè)備 ID 日期 時(shí)間桶”的格式讓寫(xiě)入壓力均勻分散。消息類數(shù)據(jù)的暫存區(qū)某些場(chǎng)景下需要短期存儲(chǔ)大量消息數(shù)據(jù)消費(fèi)者異步消費(fèi)。HBase 適合做這類暫存和回溯查詢的場(chǎng)景。上面這些場(chǎng)景有幾個(gè)共同點(diǎn)寫(xiě)入量大數(shù)據(jù)量增長(zhǎng)快按 Key 查詢?yōu)橹髋紶栃枰秶鷴呙?。這些特征正好就是 HBase 的舒適區(qū)。2. HBase 核心架構(gòu)與數(shù)據(jù)模型2.1 主從架構(gòu)里的角色分工HBase 采用典型的主從架構(gòu)主要由 HMaster 和 RegionServer 兩類核心服務(wù)組成另外還要依賴 ZooKeeper 和 HDFS。這里講清每個(gè)角色各自管什么。HMaster 負(fù)責(zé)管理整個(gè)集群的元數(shù)據(jù)信息、Region 的分配與遷移、表的創(chuàng)建與刪除、RegionServer 的負(fù)載均衡與故障恢復(fù)。注意HMaster 并不直接參與數(shù)據(jù)的讀寫(xiě)請(qǐng)求數(shù)據(jù)讀寫(xiě)都由 RegionServer 處理。這意味著 HMaster 掛了集群的讀寫(xiě)在短期內(nèi)不受影響只是不能做 DDL 操作和 Region 管理了。RegionServer 是真正干活的節(jié)點(diǎn)每個(gè) RegionServer 管理多個(gè) Region?？蛻舳俗x寫(xiě)數(shù)據(jù)時(shí)先根據(jù)元數(shù)據(jù)找到對(duì)應(yīng) Region 所在的 RegionServer然后直接與 RegionServer 通信。每個(gè) RegionServer 內(nèi)部包含多個(gè)核心組件WAL寫(xiě)前日志、BlockCache讀緩存、MemStore寫(xiě)緩存以及管理多個(gè) HFile 文件的 Store。ZooKeeper 在 HBase 里的作用像一個(gè)分布式協(xié)調(diào)中心。它維護(hù)著 HBase 的元數(shù)據(jù)入口監(jiān)控 RegionServer 的在線狀態(tài)負(fù)責(zé) HMaster 的選主以及元數(shù)據(jù)表的定位信息。HBase 集群?jiǎn)?dòng)時(shí)先由 ZooKeeper 選出 Active HMaster然后 RegionServer 向 ZooKeeper 注冊(cè)。HDFS 在最底層負(fù)責(zé)最終的數(shù)據(jù)落盤(pán)存儲(chǔ)。RegionServer 接收的寫(xiě)入數(shù)據(jù)先寫(xiě)入 HDFS 上的 WAL 文件最終 HFile 文件也是存儲(chǔ)在 HDFS 上的。HDFS 的副本機(jī)制保證了數(shù)據(jù)的可靠性默認(rèn)三副本存儲(chǔ)。HMaster集群管理者負(fù)責(zé)元數(shù)據(jù)、Region 管理、負(fù)載均衡。RegionServer數(shù)據(jù)讀寫(xiě)服務(wù)者負(fù)責(zé)處理客戶端的實(shí)際請(qǐng)求。ZooKeeper分布式協(xié)調(diào)者負(fù)責(zé)元數(shù)據(jù)入口、狀態(tài)監(jiān)控、選主。HDFS底層存儲(chǔ)者負(fù)責(zé)數(shù)據(jù)的最終落地和多副本保障。2.2 Region 與 RegionServer 的關(guān)系把表數(shù)據(jù)量變大之后HBase 會(huì)自動(dòng)把一張表從行方向切成多個(gè) Region。每個(gè) Region 包含一段連續(xù)的行鍵范圍由起始 RowKey 和結(jié)束 RowKey 定義。比如一張訂單表有 1 億行數(shù)據(jù)按照 RowKey 范圍被切成 10 個(gè) Region每個(gè) Region 負(fù)責(zé) 1000 萬(wàn)行的數(shù)據(jù)。Region 是 HBase 數(shù)據(jù)分布和負(fù)載均衡的最小單位。RegionServer 啟動(dòng)時(shí)會(huì)加載分配給自己的 Region客戶端讀寫(xiě)數(shù)據(jù)時(shí)必須路由到對(duì)應(yīng)的 RegionServer。數(shù)據(jù)量增長(zhǎng)后Region 會(huì)不斷分裂成子 Region分裂出去的 Region 可能被分配給其他 RegionServer以此實(shí)現(xiàn)負(fù)載均衡。Region 分裂是一個(gè)高頻且重要的操作。默認(rèn)情況下當(dāng)單個(gè) Region 的數(shù)據(jù)量超過(guò)一定閾值由hbase.hregion.max.filesize參數(shù)控制默認(rèn) 10GBRegion 會(huì)觸發(fā)分裂。分裂時(shí)原有 Region 會(huì)先離線然后被切成兩個(gè)子 Region底層 HFile 文件會(huì)被分成引用文件。這個(gè)過(guò)程中對(duì)正在進(jìn)行讀寫(xiě)請(qǐng)求的客戶端會(huì)有短暫影響所以在流量高峰期要注意控制分裂頻率。2.3 數(shù)據(jù)模型表、行、列族、單元格、時(shí)間戳HBase 的數(shù)據(jù)模型是很多人最容易繞暈的地方這里把它掰開(kāi)揉碎講。一張表由若干行組成每行由 RowKey行鍵唯一標(biāo)識(shí)。行與行之間按 RowKey 字典序排列這個(gè)順序決定了數(shù)據(jù)在物理存儲(chǔ)上的位置。每行數(shù)據(jù)被劃分到一個(gè)或多個(gè)列族Column Family中。列族是列的集合屬于同一列族的所有列在物理上存儲(chǔ)在一起。列族需要在建表時(shí)預(yù)先定義好而且盡量穩(wěn)定不變因?yàn)檎{(diào)整列族是非常重的操作。一個(gè)常用的設(shè)計(jì)原則是把訪問(wèn)模式相似的列放到同一列族不同訪問(wèn)模式的列放到不同列族。比如“用戶基本信息”放一個(gè)列族“用戶擴(kuò)展屬性”放另一個(gè)列族因?yàn)榛拘畔⒌牟樵冾l率遠(yuǎn)高于擴(kuò)展屬性。列Column由“列族:列標(biāo)識(shí)”這樣的格式組成例如info:agedata:score。這個(gè)設(shè)計(jì)意味著每一行的列可以是稀疏的某些行可以有某些列某些行可以沒(méi)有這些列空值不占用存儲(chǔ)空間。單元格Cell是真正存儲(chǔ)數(shù)據(jù)的地方由 RowKey、列族、列、時(shí)間戳版本號(hào)唯一確定。每個(gè)單元格可以保存同一數(shù)據(jù)的多個(gè)歷史版本版本數(shù)由VERSIONS參數(shù)控制默認(rèn)是 1也就是只保留最新一個(gè)版本。可以通過(guò)設(shè)置VERSIONS為 3 或更高來(lái)保存歷史數(shù)據(jù)。例如設(shè)置VERSIONS 3之后對(duì)同一個(gè) RowKey 的同一個(gè)列進(jìn)行三次修改查詢時(shí)可以讀取到三個(gè)歷史版本。存儲(chǔ)順序方面HBase 的數(shù)據(jù)整體按 RowKey 字典序排列同一行內(nèi)按列族排序同一列族內(nèi)按列標(biāo)識(shí)排序同一單元格內(nèi)按版本號(hào)倒序排列最新版本在前。這個(gè)排序規(guī)則直接影響 RowKey 的設(shè)計(jì)策略。3. 存儲(chǔ)機(jī)制與讀寫(xiě)鏈路詳解3.1 寫(xiě)入鏈路WAL、MemStore 與 HFile 的三角關(guān)系理解 HBase 的寫(xiě)入流程需要先建立三個(gè)關(guān)鍵組件的印象WALWrite-Ahead Log預(yù)寫(xiě)日志HBase 寫(xiě)入數(shù)據(jù)時(shí)先寫(xiě) WAL再寫(xiě)內(nèi)存。這樣即使節(jié)點(diǎn)宕機(jī)也可以從 WAL 恢復(fù)數(shù)據(jù)。MemStore每個(gè) Region 的每個(gè)列族對(duì)應(yīng)一個(gè) MemStore它是一塊內(nèi)存區(qū)域?qū)懭霐?shù)據(jù)先在這里緩沖。HFile數(shù)據(jù)最終落盤(pán)的存儲(chǔ)文件格式存儲(chǔ)在 HDFS 上。寫(xiě)入流程是這樣的客戶端發(fā)起 Put 請(qǐng)求先通過(guò)元數(shù)據(jù)定位到目標(biāo) Region 所在的 RegionServer然后寫(xiě)入流程開(kāi)始。第一步寫(xiě) WAL把數(shù)據(jù)追加到 WAL 文件末尾第二步寫(xiě)入 MemStore把數(shù)據(jù)更新到內(nèi)存結(jié)構(gòu)中。寫(xiě) WAL 成功之后客戶端就會(huì)收到成功響應(yīng)。這里有個(gè)值得注意的細(xì)節(jié)HBase 默認(rèn)開(kāi)啟了 WAL但有些業(yè)務(wù)場(chǎng)景為了追求極致的寫(xiě)入性能可以關(guān)閉 WAL。關(guān)閉 WAL 的代價(jià)是數(shù)據(jù)可靠性大幅下降一旦節(jié)點(diǎn)宕機(jī)內(nèi)存中尚未落盤(pán)的數(shù)據(jù)會(huì)全部丟失。我通常給出的建議是能開(kāi) WAL 就開(kāi)不要為了那點(diǎn)性能去賭節(jié)點(diǎn)穩(wěn)定性。當(dāng) MemStore 的數(shù)據(jù)量達(dá)到某個(gè)閾值hbase.hregion.memstore.flush.size默認(rèn) 128MB時(shí)MemStore 里的數(shù)據(jù)會(huì)被刷寫(xiě)成一個(gè)個(gè) HFile 文件。這個(gè)過(guò)程叫 Flush。隨著 HFile 文件越來(lái)越多后臺(tái)的合并線程會(huì)周期性地把多個(gè) HFile 合并成一個(gè)大的 HFile這個(gè)過(guò)程叫 Compact。合并會(huì)減少文件數(shù)量提高讀取性能但合并過(guò)程本身消耗 I/O所以需要在合并頻率和讀取性能之間找到平衡。3.2 讀取鏈路BlockCache 與布隆過(guò)濾器的加速機(jī)制讀取流程相對(duì)復(fù)雜因?yàn)?HBase 需要在內(nèi)存和磁盤(pán)之間做多級(jí)查找。客戶端發(fā)起 Get 請(qǐng)求后首先從 BlockCache讀緩存中查找。BlockCache 會(huì)緩存最近讀取過(guò)的 HFile 數(shù)據(jù)塊命中緩存則直接返回未命中則繼續(xù)向 MemStore 和 HFile 層查找。MemStore 中保存了尚未落盤(pán)的最新數(shù)據(jù)這部分?jǐn)?shù)據(jù)一定是最新的所以要優(yōu)先檢查。然后才是 HFile 層這也是最耗時(shí)的部分。HFile 文件內(nèi)部按塊Block組織默認(rèn)塊大小是 64KB。為了提升查找效率HBase 引入了布隆過(guò)濾器Bloom Filter機(jī)制它能在查找某個(gè) RowKey 時(shí)快速判斷某個(gè) HFile 文件中是否可能存在該數(shù)據(jù)如果判斷不存在就跳過(guò)該文件避免無(wú)效掃描。讀取流程還有一層關(guān)鍵設(shè)計(jì)反向合并。HBase 會(huì)從新到舊反向合并所有可能包含目標(biāo)數(shù)據(jù)的文件最新的數(shù)據(jù)優(yōu)先返回保證讀到的是最新版本。如果某個(gè) RowKey 的數(shù)據(jù)分布在多個(gè) HFile 中HBase 需要比較多個(gè)文件中同一 RowKey 的數(shù)據(jù)取出版本號(hào)最大的那個(gè)返回這一過(guò)程會(huì)有額外的 I/O 開(kāi)銷也是合并操作存在的原因。3.3 合并與分裂Compaction 對(duì)性能的雙刃劍效應(yīng)合并分為兩種Minor Compaction 和 Major Compaction。Minor Compaction 是自動(dòng)觸發(fā)的小規(guī)模合并通常合并幾個(gè)較小的 HFile代價(jià)較小。Major Compaction 是重寫(xiě)所有 HFile 的大規(guī)模合并會(huì)清理刪除標(biāo)記和過(guò)期版本代價(jià)很大通常在業(yè)務(wù)低峰期手動(dòng)觸發(fā)。Major Compaction 是雙刃劍一方面它能大幅提高讀取性能清理垃圾數(shù)據(jù)減少文件數(shù)量另一方面它會(huì)產(chǎn)生大量的磁盤(pán) I/O占用 CPU 和帶寬資源。如果集群性能本來(lái)就緊張一次大的 Major Compaction 可能引發(fā)一系列連鎖問(wèn)題甚至影響在線業(yè)務(wù)。在實(shí)際運(yùn)維中我通常建議控制 Major Compaction 的頻率和窗口。可以把自動(dòng) Major Compaction 關(guān)閉改成每天凌晨業(yè)務(wù)低峰期定時(shí)執(zhí)行。相關(guān)參數(shù)是hbase.hregion.majorcompaction默認(rèn)值是 7 天執(zhí)行一次可以設(shè)置為 0 關(guān)閉自動(dòng)模式。Region 分裂我之前提過(guò)這里再補(bǔ)充一個(gè)操作細(xì)節(jié)當(dāng)單 Region 數(shù)據(jù)量超過(guò)閾值時(shí)Region 自動(dòng)分裂原 Region 的 HFile 會(huì)被拆成引用文件供子 Region 使用。后續(xù)讀寫(xiě)過(guò)程中子 Region 的數(shù)據(jù)會(huì)逐漸寫(xiě)入自己的新 HFile引用文件最終會(huì)被清理掉。分裂過(guò)程中會(huì)短暫暫停該 Region 的寫(xiě)入所以建議在高寫(xiě)入壓力集群中提前規(guī)劃好 Region 的預(yù)分裂讓數(shù)據(jù)均勻分布在多個(gè) Region 上而不是等數(shù)據(jù)量增長(zhǎng)后再自動(dòng)分裂。4. 環(huán)境搭建與使用入門基于模擬項(xiàng)目X4.1 從零搭建 HBase 集群的關(guān)鍵步驟下面以一套三節(jié)點(diǎn)的模擬集群為例演示從零搭建的過(guò)程。環(huán)境基于主流開(kāi)源組件版本組合Hadoop 3.x HBase 2.x ZooKeeper 3.xJDK 統(tǒng)一為 8 或 11。第一步是時(shí)間同步與主機(jī)名配置。分布式系統(tǒng)對(duì)時(shí)間同步要求很高HBase 的寫(xiě)入時(shí)間戳依賴客戶端和服務(wù)器的時(shí)間一致。用 NTP 或 chrony 保證三臺(tái)機(jī)器時(shí)間誤差在 50ms 以內(nèi)。主機(jī)名解析要寫(xiě)進(jìn) /etc/hosts不能用 IP 直連的配置方式避免后續(xù)擴(kuò)容和元數(shù)據(jù)交換出問(wèn)題。第二步是部署 HDFS。HBase 依賴 HDFS 存儲(chǔ)數(shù)據(jù)需要先搭建一個(gè)可用的 HDFS 集群。核心配置項(xiàng)包括dfs.replication副本數(shù)生產(chǎn)環(huán)境建議 3、dfs.namenode.name.dir元數(shù)據(jù)存儲(chǔ)路徑建議用獨(dú)立磁盤(pán)閃存盤(pán)、dfs.datanode.data.dir數(shù)據(jù)存儲(chǔ)路徑可以配置多個(gè)磁盤(pán)目錄實(shí)現(xiàn)負(fù)載分擔(dān)。HDFS 部署完成后用hdfs dfsadmin -report確認(rèn)所有 DataNode 在線再進(jìn)行下一步。第三步是部署 ZooKeeper。ZooKeeper 集群建議奇數(shù)節(jié)點(diǎn)最少 3 個(gè)。配置文件 zoo.cfg 里的dataDir要放在獨(dú)立磁盤(pán)上不跟系統(tǒng)盤(pán)共用。ZooKeeper 的日志和數(shù)據(jù)也建議分離存儲(chǔ)。第四步是安裝 HBase。下載二進(jìn)制包解壓修改hbase-env.sh設(shè)置 JAVA_HOME修改hbase-site.xml配置核心參數(shù)property namehbase.rootdir/name valuehdfs://namenode:8020/hbase/value /property property namehbase.zookeeper.quorum/name valuenode1,node2,node3/value /property property namehbase.cluster.distributed/name valuetrue/value /property第五步是配置 regionservers 文件把三臺(tái)節(jié)點(diǎn)都寫(xiě)進(jìn)去然后啟動(dòng)集群。先啟動(dòng) Hadoop再啟動(dòng) ZooKeeper最后啟動(dòng) HBase。用hbase shell進(jìn)入命令行執(zhí)行status命令看到多臺(tái) RegionServer 在線集群就基本就緒了。4.2 建表與數(shù)據(jù)操作常用命令逐個(gè)過(guò)HBase 的交互操作主要走 HBase Shell雖然生產(chǎn)環(huán)境一般用 Java API 或者各類框架封裝但 Shell 是理解數(shù)據(jù)模型和排查問(wèn)題的最好工具。建表的基本語(yǔ)法是這樣的create user_profile, {NAME info, VERSIONS 3}, {NAME data}這條命令創(chuàng)建了一張名為 user_profile 的表包含兩個(gè)列族info 和 data。info 列族保留 3 個(gè)歷史版本。創(chuàng)建成功后用list查看當(dāng)前所有表用describe user_profile查看表的詳細(xì)結(jié)構(gòu)包括各列族的屬性、TTL、布隆過(guò)濾器類型等。插入數(shù)據(jù)的語(yǔ)法用 put 命令put user_profile, rowkey_001, info:age, 28 put user_profile, rowkey_001, info:name, 張三 put user_profile, rowkey_001, data:score, 95這里的邏輯是向 user_profile 表的 rowkey_001 行寫(xiě)入 info:age 列值為 28。同一個(gè) RowKey 的多個(gè) put 操作不需要在一個(gè)事務(wù)里執(zhí)行因?yàn)?HBase 的單行操作天然是原子的。查詢數(shù)據(jù)用 get 和 scanget user_profile, rowkey_001 get user_profile, rowkey_001, {COLUMN info:age} scan user_profile, {STARTROW rowkey_001, STOPROW rowkey_002}get 按 RowKey 精確查詢性能最高。scan 按范圍掃描STARTROW 是起始行包含STOPROW 是結(jié)束行不包含。scan 時(shí)可以指定列族、列、版本數(shù)、緩存大小等參數(shù)控制掃描的數(shù)據(jù)量。刪除數(shù)據(jù)的語(yǔ)法delete user_profile, rowkey_001, info:age deleteall user_profile, rowkey_001delete 刪除指定列deleteall 刪除整行。注意HBase 的刪除操作只是打一個(gè)刪除標(biāo)記并不會(huì)立即物理刪除數(shù)據(jù)要到 Major Compaction 時(shí)才會(huì)真正清理。4.3 常用過(guò)濾器與參數(shù)調(diào)優(yōu)HBase 的查詢能力遠(yuǎn)不止 get 和 scan過(guò)濾器Filter才是擴(kuò)展查詢能力的關(guān)鍵。單列值過(guò)濾器可以按列的值過(guò)濾行鍵前綴過(guò)濾器可以按 RowKey 前綴匹配分頁(yè)過(guò)濾器可以實(shí)現(xiàn)分頁(yè)查詢列值比較器可以配合多種比較操作符使用。使用過(guò)濾器時(shí)要注意大多數(shù)過(guò)濾器會(huì)導(dǎo)致全表掃描性能開(kāi)銷非常大。在千萬(wàn)級(jí)以上數(shù)據(jù)的表上執(zhí)行帶過(guò)濾器的 scan耗時(shí)會(huì)明顯拉長(zhǎng)。如果業(yè)務(wù)上確實(shí)需要按非 RowKey 列查詢建議考慮引入二級(jí)索引方案或者設(shè)計(jì)好 RowKey 讓查詢直接命中。關(guān)于 Shell 之外的開(kāi)發(fā)接口最常用的是 Java API。核心類包括 Connection、Table、Put、Get、Scan、ResultScanner。讀寫(xiě)頻繁的代碼段要復(fù)用 Connection 和 Table 實(shí)例因?yàn)閯?chuàng)建連接和獲取 Table 對(duì)象是重量級(jí)操作頻繁創(chuàng)建對(duì)性能影響很大。連接參數(shù)建議設(shè)置合理的超時(shí)時(shí)間和 RPC 重試次數(shù)。Connection conn ConnectionFactory.createConnection(conf); Table table conn.getTable(TableName.valueOf(user_profile)); Put put new Put(Bytes.toBytes(rowkey_001)); put.addColumn(Bytes.toBytes(info), Bytes.toBytes(age), Bytes.toBytes(28)); table.put(put);這段代碼完成了之前 Shell 里的寫(xiě)入操作注意所有維度信息都要通過(guò) Bytes 工具類轉(zhuǎn)成字節(jié)數(shù)組。讀寫(xiě)完畢記得關(guān)閉 Table 和 Connection。5. RowKey 設(shè)計(jì)HBase 性能的分水嶺5.1 設(shè)計(jì)原則與常見(jiàn)風(fēng)格RowKey 設(shè)計(jì)是整個(gè) HBase 建模中最關(guān)鍵的環(huán)節(jié)沒(méi)有之一。RowKey 決定了數(shù)據(jù)分布方式、查詢效率、寫(xiě)入吞吐甚至決定了 Region 會(huì)不會(huì)出現(xiàn)熱點(diǎn)。第一條原則是長(zhǎng)度盡量短。RowKey 是每行數(shù)據(jù)的唯一標(biāo)識(shí)長(zhǎng)度越長(zhǎng)存儲(chǔ)開(kāi)銷和比較開(kāi)銷越大。雖然 HBase 沒(méi)有強(qiáng)制限制 RowKey 長(zhǎng)度但實(shí)踐中建議控制在幾十字節(jié)以內(nèi)。一個(gè)常見(jiàn)的誤區(qū)是使用業(yè)務(wù)主鍵直接拼接比如訂單號(hào)加用戶 ID 再加時(shí)間戳結(jié)果 RowKey 長(zhǎng)度到了上百字節(jié)。第二條原則是散列與有序的平衡。HBase 按 RowKey 字典序排列單調(diào)遞增的 RowKey比如純時(shí)間戳?xí)屗袑?xiě)入都集中在最后一個(gè) Region 上形成寫(xiě)熱點(diǎn)。解決方案是在 RowKey 前綴加入散列字段比如用戶 ID 反轉(zhuǎn)、MD5 前綴截取。第三條原則是查詢與存儲(chǔ)的權(quán)衡。設(shè)計(jì) RowKey 時(shí)要考慮最常用的查詢場(chǎng)景。比如訂單表最常用的查詢是按用戶 ID 查最近訂單RowKey 可以設(shè)計(jì)成“反轉(zhuǎn)用戶 ID 時(shí)間戳倒序”這樣同一用戶的所有訂單在物理存儲(chǔ)上連續(xù)按用戶查詢時(shí)只需一次 scan。業(yè)務(wù)上常見(jiàn)的 RowKey 風(fēng)格有這么幾種反轉(zhuǎn)補(bǔ)零法把用戶 ID 反轉(zhuǎn)比如 12345 變成 54321保證前綴分散MD5 散列法取 MD5 的前幾位作為前綴打散寫(xiě)入時(shí)間戳倒序法配合前綴使新數(shù)據(jù)排在前部適合讀取最新數(shù)據(jù)的場(chǎng)景。每種方案都有適用的場(chǎng)景需要結(jié)合業(yè)務(wù)特點(diǎn)選型。5.2 熱點(diǎn)問(wèn)題寫(xiě)入傾斜與讀取傾斜熱點(diǎn)主要指兩種情況寫(xiě)入熱點(diǎn)和讀取熱點(diǎn)。寫(xiě)入熱點(diǎn)是因?yàn)?RowKey 單調(diào)遞增所有新寫(xiě)入的數(shù)據(jù)都被路由到同一個(gè)或少數(shù)幾個(gè) Region 上。應(yīng)對(duì)方法就是加鹽Salting在 RowKey 前面拼一個(gè)隨機(jī)數(shù)或取模值比如把訂單號(hào)散列到 10 個(gè)桶桶號(hào)作為前綴。散列之后寫(xiě)入壓力均勻分散到 10 個(gè) Region 上。讀取熱點(diǎn)是大部分查詢都命中了某幾個(gè)固定 RowKey 或固定范圍導(dǎo)致這些 Region 所在節(jié)點(diǎn)的負(fù)載過(guò)高。這種情況單純調(diào) RowKey 解決不了需要從業(yè)務(wù)層面做緩存、分流或者把熱數(shù)據(jù)的 RowKey 進(jìn)一步細(xì)分比如按時(shí)間維度拆分。另一個(gè)經(jīng)常被忽略的細(xì)節(jié)RowKey 的前綴如果固定不變后面跟的業(yè)務(wù)字段即使長(zhǎng)度很大也會(huì)因?yàn)樽值湫蚺判驅(qū)е戮植繑?shù)據(jù)堆積。理想的設(shè)計(jì)是所有 RowKey 的前幾位都有足夠的離散度讓數(shù)據(jù)的分布盡可能均勻。5.3 預(yù)分區(qū)與桶表設(shè)計(jì)實(shí)操創(chuàng)建一張新表時(shí)默認(rèn)只有一個(gè) Region數(shù)據(jù)量上來(lái)后才慢慢分裂。如果一開(kāi)始就知道這張表數(shù)據(jù)量會(huì)很大建議直接預(yù)分區(qū)。預(yù)分區(qū)的操作是建表時(shí)指定 SPLITS 參數(shù)把 RowKey 范圍切割成多個(gè)區(qū)間。比如按 RowKey 前綴 0000-9999 均勻切割成 100 個(gè) Regioncreate big_table, info, {NUMREGIONS 100, SPLITALGO HexStringSplit}HexStringSplit 算法會(huì)把 RowKey 看成一串十六進(jìn)制字符均勻切割成給定數(shù)量的 Region。另一種手工指定關(guān)鍵邊界的方式是直接在 SPLITS 參數(shù)里寫(xiě)清楚區(qū)間邊界數(shù)組。預(yù)分區(qū)的意義在于數(shù)據(jù)寫(xiě)入一開(kāi)始就能均勻分布到多個(gè) RegionServer避免前期數(shù)據(jù)集中在一個(gè)節(jié)點(diǎn)上。同時(shí)還能避免高峰期自動(dòng)分裂帶來(lái)的性能抖動(dòng)。預(yù)分區(qū)數(shù)量不是越多越好Region 過(guò)多會(huì)帶來(lái)元數(shù)據(jù)管理開(kāi)銷和合并頻率上升的問(wèn)題。經(jīng)驗(yàn)值是按照未來(lái)半年到一年的數(shù)據(jù)量預(yù)估讓每個(gè) Region 的數(shù)據(jù)量在 5-10GB 之間比較合適。如果業(yè)務(wù)的 RowKey 分布不均勻還可以用桶表設(shè)計(jì)把 RowKey 先散列到 N 個(gè)桶每個(gè)桶對(duì)應(yīng)一個(gè)固定 Region 范圍。這樣即使原始 RowKey 分布不均經(jīng)過(guò)桶的散列后也能均勻分布。6. 核心參數(shù)配置與性能調(diào)優(yōu)6.1 內(nèi)存規(guī)劃RegionServer 堆內(nèi)堆外分配HBase 的內(nèi)存配置直接決定了讀寫(xiě)性能的上限。RegionServer 的內(nèi)存主要分為三塊堆內(nèi)內(nèi)存中的 MemStore 占比、BlockCache 占比以及堆外內(nèi)存用于網(wǎng)絡(luò)通信和部分?jǐn)?shù)據(jù)讀寫(xiě)。典型的堆內(nèi)存分配方式是把可用堆內(nèi)存按比例劃分給 MemStore 和 BlockCache但兩者之間需要預(yù)留一定余量避免某一塊被占滿后無(wú)法動(dòng)態(tài)調(diào)配。相關(guān)參數(shù)hbase.regionserver.global.memstore.size默認(rèn) 0.4表示 MemStore 占堆內(nèi)存的最大比例。寫(xiě)入密集場(chǎng)景可以調(diào)高到 0.5 以上但要注意留給 BlockCache 的空間不能過(guò)小。hbase.regionserver.global.memstore.size.lower.limit默認(rèn) 0.38表示觸發(fā)強(qiáng)制刷寫(xiě)的 MemStore 比例下限。hfile.block.cache.size默認(rèn) 0.4表示 BlockCache 占堆內(nèi)存的比例。實(shí)際調(diào)優(yōu)時(shí)可以用公式估算RegionServer 堆內(nèi)存 MemStore BlockCache 其他默認(rèn)約 20% 余量。如果寫(xiě)入壓力大MemStore 給 0.5、BlockCache 給 0.3如果讀取壓力大MemStore 給 0.3、BlockCache 給 0.5?？偟脑瓌t是不能讓兩者相加接近 1否則 GC 壓力會(huì)非常大。堆外內(nèi)存方面HBase 默認(rèn)使用堆外內(nèi)存用于 RPC 層面的 ByteBuffer 緩沖效果是減少 GC 壓力和數(shù)據(jù)拷貝次數(shù)。一般不需要手動(dòng)改保持默認(rèn)配置即可。6.2 關(guān)鍵寫(xiě)路徑參數(shù)與讀路徑參數(shù)寫(xiě)路徑的核心參數(shù)控制的是 MemStore 何時(shí)刷寫(xiě)、WAL 同步方式、Region 分裂閾值。這些參數(shù)直接決定了寫(xiě)入吞吐量和數(shù)據(jù)安全性。hbase.hregion.memstore.flush.size默認(rèn) 128MB單個(gè) MemStore 大小達(dá)到該值后觸發(fā)刷寫(xiě)。hbase.regionserver.global.memstore.size默認(rèn) 0.4RegionServer 所有 Region 的 MemStore 總大小達(dá)到堆內(nèi)存比例后觸發(fā)強(qiáng)制刷寫(xiě)。hbase.regionserver.wal.codecWAL 文件編碼相關(guān)配置默認(rèn)使用WALCellCodec。hbase.wal.provider默認(rèn)使用AsyncFSWALProvider異步刷寫(xiě)模式性能更好。hbase.hregion.max.filesize默認(rèn) 10GB單個(gè) Region 的 Store 文件總大小超過(guò)該值觸發(fā)分裂。讀路徑的核心參數(shù)控制的是 BlockCache 容量、掃描緩存大小、RPC 超時(shí)等。hbase.client.scanner.cachingscan 時(shí)每次 RPC 請(qǐng)求返回給客戶端的行數(shù)默認(rèn) 100。值太大會(huì)增加單次 RPC 的數(shù)據(jù)量但能減少 RPC 次數(shù)值太小會(huì)導(dǎo)致頻繁請(qǐng)求性能下降。hbase.client.scanner.blockcachescan 時(shí)是否使用 BlockCache默認(rèn) true。全表掃描類場(chǎng)景建議關(guān)閉因?yàn)榇罅繑?shù)據(jù)涌入會(huì)污染緩存。hbase.rpc.timeoutRPC 超時(shí)時(shí)間默認(rèn) 60000ms高延遲場(chǎng)景需要適當(dāng)調(diào)大。6.3 GC 調(diào)優(yōu)與 JVM 參數(shù)最佳實(shí)踐HBase 是 Java 系服務(wù)GC 調(diào)優(yōu)是性能優(yōu)化的重要一環(huán)。RegionServer 節(jié)點(diǎn)上如果頻繁發(fā)生 Full GC整個(gè)節(jié)點(diǎn)的讀寫(xiě)請(qǐng)求都會(huì)出現(xiàn)卡頓表現(xiàn)為明顯的毛刺延遲。常見(jiàn)的 GC 問(wèn)題集中在 MemStore 上的對(duì)象過(guò)多導(dǎo)致年輕代回收頻繁。優(yōu)化方向是調(diào)整新生代大小讓短生命周期對(duì)象盡量在 Minor GC 階段就被回收合理使用 CMS 或 G1 垃圾回收器。對(duì)于 HBase 2.x 版本G1 是比較推薦的選擇。核心參數(shù)可以這樣設(shè)置export HBASE_REGIONSERVER_OPTS-Xms16g -Xmx16g -XX:UseG1GC -XX:MaxGCPauseMillis100Xms 和 Xmx 設(shè)置為相同值避免堆內(nèi)存動(dòng)態(tài)伸縮帶來(lái)的性能損失。MaxGCPauseMillis 設(shè)置目標(biāo)停頓時(shí)間G1 會(huì)盡量控制在這個(gè)范圍內(nèi)。如果 Full GC 仍然頻繁需要檢查是否有大對(duì)象分配、MemStore 是否過(guò)大、HFile 過(guò)多導(dǎo)致的合并壓力。一個(gè)容易忽視的地方HDFS 的 DataNode 進(jìn)程和 RegionServer 進(jìn)程混布在同一臺(tái)機(jī)器上時(shí)兩者的內(nèi)存和磁盤(pán) I/O 會(huì)互相爭(zhēng)搶。實(shí)際部署時(shí)要根據(jù)物理機(jī)內(nèi)存合理分配總內(nèi)存 64GB 的機(jī)器可以給 RegionServer 分配 24GB給 DataNode 分配 8GB其余留給操作系統(tǒng)頁(yè)緩存。6.4 讀寫(xiě)分離與熱點(diǎn)數(shù)據(jù)緩存HBase 層面沒(méi)有嚴(yán)格意義上的讀寫(xiě)分離但可以通過(guò)參數(shù)和架構(gòu)手法實(shí)現(xiàn)近似效果。一個(gè)常用方式是使用 Buffer 機(jī)制寫(xiě)入時(shí)批量提交降低 RPC 次數(shù)讀取時(shí)增加 BlockCache 命中率減少磁盤(pán) I/O。對(duì)于熱點(diǎn)數(shù)據(jù)的讀取可以在業(yè)務(wù)層加一層緩存。比如按用戶 ID 查詢的數(shù)據(jù)可以把查詢結(jié)果緩存在應(yīng)用層或 Redis 中緩存過(guò)期時(shí)間按數(shù)據(jù)更新頻率設(shè)置。HBase 底層的 BlockCache 也可以優(yōu)化如果某類數(shù)據(jù)查詢頻率極高可以通過(guò)參數(shù)調(diào)整讓這類數(shù)據(jù)的 Block 更長(zhǎng)時(shí)間留在緩存里。另一個(gè)實(shí)踐是把熱數(shù)據(jù)和冷數(shù)據(jù)拆分到不同表或不同列族。熱數(shù)據(jù)保留高版本數(shù)、短 TTL冷數(shù)據(jù)保留低版本數(shù)、長(zhǎng) TTL。這樣熱數(shù)據(jù)的查詢和寫(xiě)入都不受冷數(shù)據(jù)量大、合并頻繁的影響。7. 常見(jiàn)問(wèn)題與故障排查7.1 集群?jiǎn)?dòng)失敗與元數(shù)據(jù)異常集群?jiǎn)?dòng)失敗是每個(gè)人都會(huì)遇到的第一個(gè)坎。最常見(jiàn)的癥狀是啟動(dòng)后 HMaster 進(jìn)程自動(dòng)退出或者 RegionServer 注冊(cè)不上。排查第一步就是看日志。HBase 的日志放在$HBASE_HOME/logs目錄下HMaster 的日志文件是hbase-hmaster-xxx.logRegionServer 的是hbase-regionserver-xxx.log。打開(kāi)日志文件快速搜索 ERROR 和 FATAL 級(jí)別的信息。常見(jiàn)原因之一是 ZooKeeper 連接失敗日志里會(huì)出現(xiàn)ConnectionLossException或KeeperException。檢查 ZooKeeper 服務(wù)是否正常hbase.zookeeper.quorum配置的地址是否可達(dá)端口是否被防火墻攔截。另一個(gè)常見(jiàn)問(wèn)題是 HDFS 目錄權(quán)限不對(duì)。HBase 首次啟動(dòng)需要在 HDFS 上創(chuàng)建根目錄如果hbase.rootdir指向的路徑?jīng)]有寫(xiě)權(quán)限啟動(dòng)必然失敗。解決辦法是先在 HDFS 上mkdir -p并授權(quán)。元數(shù)據(jù)異常是更嚴(yán)重的問(wèn)題。HBase 的元數(shù)據(jù)存放在hbase:meta表中如果這個(gè)表的數(shù)據(jù)損壞整個(gè)集群都無(wú)法正常工作。日常運(yùn)維要監(jiān)控hbase:meta表所在 RegionServer 的健康狀態(tài)定期檢查 Region 是否卡在 RITRegion In Transition狀態(tài)。RIT 狀態(tài)卡住時(shí)用命令hbase hbck檢查并修復(fù)。7.2 讀寫(xiě)性能驟降的排查思路讀寫(xiě)性能驟降是運(yùn)維中最常見(jiàn)也最頭疼的問(wèn)題。引發(fā)原因通常有幾個(gè)GC 異常、磁盤(pán) I/O 打滿、Region 熱點(diǎn)、合并風(fēng)暴。GC 異常通過(guò)監(jiān)控面板看 RegionServer 的 GC 時(shí)間和頻率如果 Full GC 頻繁按前面說(shuō)的 JVM 調(diào)優(yōu)方向處理。磁盤(pán) I/O 打滿用iostat或dstat看磁盤(pán)的讀寫(xiě)速率和等待時(shí)間。如果磁盤(pán)持續(xù)高負(fù)載重點(diǎn)檢查是否有大合并任務(wù)在執(zhí)行必要時(shí)把 Major Compaction 挪到低峰期。Region 熱點(diǎn)檢查是否某個(gè) Region 的讀寫(xiě)請(qǐng)求量遠(yuǎn)高于其他 Region。熱點(diǎn)通常由 RowKey 設(shè)計(jì)不合理引起先查詢各 Region 的請(qǐng)求分布。合并風(fēng)暴RegionServer 上的 HFile 數(shù)量突然激增大量合并任務(wù)同時(shí)執(zhí)行。這種情況一般發(fā)生在大量寫(xiě)入后MemStore 頻繁刷寫(xiě)導(dǎo)致 HFile 文件數(shù)過(guò)多。排查思路可以按順序走先看監(jiān)控面板確認(rèn)問(wèn)題節(jié)點(diǎn)再看 GC 日志確認(rèn) JVM 狀態(tài)再用系統(tǒng)命令查看磁盤(pán)和網(wǎng)絡(luò) I/O最后分析 HBase 層的 Region 分布和請(qǐng)求量。7.3 數(shù)據(jù)不一致與 Region 遷移故障處理HBase 的數(shù)據(jù)不一致問(wèn)題相對(duì)少見(jiàn)但一旦出現(xiàn)影響很大。常見(jiàn)場(chǎng)景是在 Region 遷移或故障恢復(fù)期間客戶端訪問(wèn)到舊路由導(dǎo)致查詢失敗。這類問(wèn)題通常通過(guò)重試機(jī)制解決客戶端配置了合理的 RPC 重試次數(shù)后短暫的路由抖動(dòng)是可以容忍的。但如果持久不一致就需要檢查元數(shù)據(jù)表和實(shí)際 Region 分布是否匹配。Region 遷移故障的典型表現(xiàn)是某個(gè) Region 長(zhǎng)時(shí)間停留在 RIT 狀態(tài)。處理辦法是先檢查該 Region 涉及的 RegionServer 是否在線日志中有沒(méi)有異常堆棧。必要時(shí)手動(dòng)觸發(fā)assign操作assign region_encoded_name如果持續(xù)失敗檢查 ZooKeeper 中的節(jié)點(diǎn)狀態(tài)以及在 HDFS 上確認(rèn)對(duì)應(yīng) Region 的目錄是否完整。7.4 監(jiān)控體系搭建與告警策略沒(méi)有監(jiān)控就去運(yùn)維 HBase等于閉著眼睛開(kāi)車。必要的基礎(chǔ)監(jiān)控指標(biāo)包括集群層面RegionServer 在線狀態(tài)、HMaster 存活狀態(tài)、Region 總數(shù)、RIT 數(shù)量。節(jié)點(diǎn)層面CPU、內(nèi)存、磁盤(pán) I/O、網(wǎng)絡(luò)帶寬。HBase 內(nèi)部MemStore 大小、BlockCache 命中率、HFile 文件數(shù)、寫(xiě)延遲、讀延遲、Region 熱點(diǎn)分布、GC 暫停時(shí)間。推薦的監(jiān)控方案是把 HBase 的指標(biāo)暴露出來(lái)用主流監(jiān)控系統(tǒng)采集再配置告警規(guī)則。關(guān)鍵告警項(xiàng)包括RegionServer 宕機(jī)、HMaster 主備切換、RIT 數(shù)量大于 0、寫(xiě)阻塞或讀阻塞超過(guò)閾值、GC 暫停時(shí)間超過(guò) 5 秒、磁盤(pán)使用率超過(guò) 80%。有個(gè)運(yùn)維心得告警規(guī)則不是越多越好告警噪音太大會(huì)導(dǎo)致真正的問(wèn)題被淹沒(méi)。核心告警控制在 10 條以內(nèi)每條告警都要附帶排查文檔鏈接讓值班同學(xué)拿到告警就能按步驟處理。8. HBase 調(diào)優(yōu)與優(yōu)化的進(jìn)階路線8.1 基于業(yè)務(wù)特征的讀寫(xiě)優(yōu)化策略調(diào)優(yōu)不能脫離業(yè)務(wù)場(chǎng)景空談。同一套參數(shù)寫(xiě)入密集的日志場(chǎng)景和讀密集的查詢場(chǎng)景優(yōu)化方向完全是相反的。寫(xiě)入密集場(chǎng)景適當(dāng)增大 MemStore 刷寫(xiě)閾值減少小文件數(shù)量。合理配置 HDFS 的寫(xiě)入緩沖提升寫(xiě)吞吐。避免單個(gè) Region 同時(shí)接收過(guò)多寫(xiě)入請(qǐng)求預(yù)分區(qū)要到位?？梢园葱桕P(guān)閉 WAL但必須清楚數(shù)據(jù)丟失的風(fēng)險(xiǎn)。讀密集場(chǎng)景增大 BlockCache 比例提升緩存命中率。減少 HFile 數(shù)量壓縮文件必要時(shí)手動(dòng)觸發(fā) Major Compaction。設(shè)計(jì)高效的 RowKey讓查詢盡量走精確 Get 而非全表 Scan。對(duì)熱點(diǎn)查詢?cè)黾訕I(yè)務(wù)層緩存。8.2 表結(jié)構(gòu)層面的優(yōu)化手段表結(jié)構(gòu)的優(yōu)化主要圍繞列族、壓縮、TTL 展開(kāi)。列族數(shù)量一張表不建議設(shè)置太多列族HBase 官方建議 1-3 個(gè)。列族過(guò)多會(huì)導(dǎo)致每個(gè) MemStore 都要占用內(nèi)存Region 的數(shù)據(jù)分布邏輯變復(fù)雜。壓縮算法HBase 支持 GZ、LZO、SNAPPY 等壓縮算法。不同算法的壓縮比和 CPU 消耗不同。SNAPPY 是平衡壓縮比和 CPU 開(kāi)銷的常用選擇。設(shè)置壓縮的語(yǔ)句示例alter user_profile, {NAME info, COMPRESSION SNAPPY}壓縮設(shè)置修改后后續(xù)的 HFile 文件會(huì)按新算法生成但已有的舊文件不會(huì)立即轉(zhuǎn)換需要觸發(fā)一次 Major Compaction 才能真正生效。TTL 設(shè)置HBase 支持按列族設(shè)置數(shù)據(jù)的存活時(shí)間超時(shí)數(shù)據(jù)會(huì)被自動(dòng)清理。日志類數(shù)據(jù)建議設(shè)置 TTL既能控制存儲(chǔ)成本又能減少數(shù)據(jù)量大帶來(lái)的合并壓力。create log_table, {NAME info, TTL 604800}上面例子表示 info 列族的數(shù)據(jù)保存 7 天604800 秒到期后自動(dòng)過(guò)期。8.3 數(shù)據(jù)遷移與備份恢復(fù)方案HBase 數(shù)據(jù)遷移的常用工具有很多但不同場(chǎng)景有不同選型Export 工具把表數(shù)據(jù)導(dǎo)出為 SequenceFile適合跨版本或跨集群遷移。缺點(diǎn)是速度較慢適合中小表。CopyTable直接跨集群拷貝數(shù)據(jù)支持在線操作但對(duì)網(wǎng)絡(luò)帶寬要求高。Snapshot對(duì)表做快照基于快照做 bulkload 或克隆。這是目前比較推薦的方式速度快且對(duì)在線業(yè)務(wù)影響小。雙寫(xiě)方案在新集群上線初期業(yè)務(wù)層同時(shí)向新舊集群寫(xiě)數(shù)據(jù)讀的時(shí)候先讀新集群回退到舊集群。適合對(duì)遷移窗口要求高的場(chǎng)景。備份層面HBase 的 Snapshot 是最常用的備份方式。定期對(duì)關(guān)鍵業(yè)務(wù)表做快照快照文件放在 HDFS 上不會(huì)影響線上讀寫(xiě)?；謴?fù)時(shí)直接restore_snapshot即可。實(shí)操中建議每日低峰期對(duì)核心表做一次快照快照保留周期根據(jù)業(yè)務(wù)需求設(shè)置。8.4 常見(jiàn)性能優(yōu)化場(chǎng)景實(shí)例復(fù)盤(pán)這里分享一個(gè)模擬項(xiàng)目中的真實(shí)調(diào)優(yōu)案例具備一定的普適性。背景某用戶行為分析系統(tǒng)將用戶行為日志寫(xiě)入 HBase每天新增約 5000 萬(wàn)行單表總量超過(guò) 20 億行。業(yè)務(wù)方要求查詢延遲在 100ms 以內(nèi)。上線初期寫(xiě)入吞吐量指標(biāo)不理想部分時(shí)段寫(xiě)阻塞延遲抖動(dòng)明顯。排查發(fā)現(xiàn)三個(gè)問(wèn)題RowKey 設(shè)計(jì)不合理。原設(shè)計(jì)是用戶ID:時(shí)間戳但用戶 ID 前幾位高度集中導(dǎo)致部分 Region 寫(xiě)入量遠(yuǎn)高于其他節(jié)點(diǎn)形成寫(xiě)熱點(diǎn)。修改為反轉(zhuǎn)用戶ID:時(shí)間戳后熱點(diǎn)消失。HFile 數(shù)量過(guò)多。MemStore 頻繁刷寫(xiě)Minor Compaction 跟不上小文件產(chǎn)生的速度。調(diào)大了刷寫(xiě)閾值同時(shí)關(guān)閉自動(dòng) Major Compaction改為每天凌晨手動(dòng)觸發(fā)一次。BlockCache 命中率偏低。部分報(bào)表場(chǎng)景進(jìn)行全表掃描污染了緩存。把這些掃描任務(wù)改成在專用查詢集群上執(zhí)行線上集群只承載實(shí)時(shí)查詢。經(jīng)過(guò)三天迭代調(diào)優(yōu)后寫(xiě)入吞吐提升了兩倍P99 延遲降到 50ms 以內(nèi)。整個(gè)調(diào)優(yōu)過(guò)程是典型的三步走先解決熱點(diǎn)分布再調(diào)整合并策略最后隔離查詢負(fù)載。9. 經(jīng)驗(yàn)沉淀與建議踩過(guò)的坑多了有些經(jīng)驗(yàn)還是想記錄下來(lái)給后來(lái)人一個(gè)參考。首先是 HBase 的版本選擇不要追新生產(chǎn)環(huán)境用社區(qū)廣泛驗(yàn)證的穩(wěn)定版本即可新版本雖然特性多但遇到的坑需要社區(qū)時(shí)間去填平。其次是監(jiān)控體系一定要在業(yè)務(wù)上線前就搭好不要等出了問(wèn)題才去補(bǔ)監(jiān)控。HBase 調(diào)優(yōu)不是一次性工作它會(huì)隨著數(shù)據(jù)量增長(zhǎng)和業(yè)務(wù)變化持續(xù)進(jìn)行。定期審視 Region 數(shù)量、HFile 文件數(shù)、熱點(diǎn)分布、GC 情況把優(yōu)化變成常態(tài)化機(jī)制比出事再救火有效得多。最后再分享一個(gè)小技巧每次表和 RowKey 設(shè)計(jì)評(píng)審時(shí)花十分鐘按照未來(lái)一年數(shù)據(jù)量模擬一遍寫(xiě)入分布和查詢路徑能提前篩掉大部分設(shè)計(jì)缺陷。這個(gè)習(xí)慣我堅(jiān)持了很多年價(jià)值非常大。