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