簡介面向大數(shù)據(jù)開發(fā)工程師與數(shù)據(jù)倉庫工程師的用戶畫像標(biāo)簽數(shù)據(jù)存儲完整方案PDF適合正在規(guī)劃或優(yōu)化畫像平臺的團(tuán)隊(duì)參考。資源圍繞Hive、MySQL、Hbase、Elasticsearch四種存儲引擎展開講清各自在畫像場景中的定位與分工并給出用戶標(biāo)簽表、標(biāo)簽聚合表、人群計(jì)算表的字段設(shè)計(jì)與分區(qū)策略。壓縮包內(nèi)共1個(gè)PDF文件大小約1.34MB內(nèi)容全部集中在文檔中。目前已有211人學(xué)習(xí)使用。文檔覆蓋從Hive向Hbase、MySQL同步標(biāo)簽數(shù)據(jù)的完整流程包括Sqoop落地方式、數(shù)據(jù)量校驗(yàn)機(jī)制以及將圈定人群推送給廣告系統(tǒng)、Push系統(tǒng)、客服系統(tǒng)等業(yè)務(wù)方的調(diào)度思路。其中穿插tag表、tagmap表等真實(shí)表結(jié)構(gòu)示例與執(zhí)行過程說明可幫助讀者對照設(shè)計(jì)自己的畫像存儲層規(guī)避表結(jié)構(gòu)混亂與數(shù)據(jù)同步丟失等常見問題。1. 用戶畫像系統(tǒng)的標(biāo)簽數(shù)據(jù)存儲為什么同一套數(shù)據(jù)要拆進(jìn)四個(gè)數(shù)據(jù)庫很多剛接觸用戶畫像系統(tǒng)的人第一反應(yīng)是“標(biāo)簽不就是一張用戶表加幾個(gè)字段嗎MySQL 就夠了吧”。真正跑過生產(chǎn)環(huán)境的人都不會這么想。用戶畫像系統(tǒng)的核心是標(biāo)簽數(shù)據(jù)存儲一套標(biāo)簽從離線計(jì)算到線上服務(wù)至少要經(jīng)過 Hive、MySQL、Hbase、Elasticsearch 四個(gè)庫每個(gè)庫承擔(dān)完全不同的角色少一個(gè)都會出問題。這個(gè)結(jié)論不是設(shè)計(jì)文檔里拍腦袋定的而是由數(shù)據(jù)量、查詢時(shí)延、寫入頻率和業(yè)務(wù)系統(tǒng)的接入方式共同逼出來的。本文拆解的這份解決方案把四種數(shù)據(jù)庫的存儲定位、表結(jié)構(gòu)設(shè)計(jì)、同步鏈路和校驗(yàn)機(jī)制都講得很清楚適合正在搭畫像平臺的數(shù)據(jù)工程師、數(shù)倉開發(fā)以及準(zhǔn)備把標(biāo)簽服務(wù)線上化的后端同學(xué)。新手可以照表結(jié)構(gòu)復(fù)現(xiàn)熟手可以直接拿走里面的同步校驗(yàn)方案。2. Hive 主存標(biāo)簽結(jié)果集tag 表、tagmap 表與人群計(jì)算表的建表細(xì)節(jié)2.1 為什么畫像的“數(shù)據(jù)底座”必須放 Hive畫像相關(guān)的數(shù)據(jù)有一個(gè)共同特點(diǎn)數(shù)據(jù)量極大且計(jì)算邏輯復(fù)雜。一個(gè)中型的電商平臺每天活躍用戶百萬級每個(gè)用戶身上掛幾十個(gè)標(biāo)簽再按時(shí)間分區(qū)累積單日新增數(shù)據(jù)就是千萬甚至億級行。這種計(jì)算量下標(biāo)簽的生成作業(yè)跑的是 MapReduce 或者 Spark結(jié)果寫 HDFS。MySQL 扛不住這么大的寫入Hbase 雖然能扛寫入但跑批量作業(yè)時(shí)沒有 Hive 的 SQL 生態(tài)方便。所以 Hive 在畫像系統(tǒng)里的定位是“所有標(biāo)簽相關(guān)計(jì)算結(jié)果集的默認(rèn)落點(diǎn)”包括用戶標(biāo)簽表、標(biāo)簽聚合表、人群計(jì)算結(jié)果表全部先落在 Hive 數(shù)倉里。Hive 存儲的一個(gè)關(guān)鍵設(shè)計(jì)是分區(qū)。方案里明確提到tag 表按“日期 標(biāo)簽主題”雙分區(qū)設(shè)計(jì)。日期分區(qū)解決的是每天全量標(biāo)簽快照的隔離問題標(biāo)簽主題分區(qū)解決的是 ETL 調(diào)度時(shí)同時(shí)計(jì)算多個(gè)標(biāo)簽的并行插入問題。這里有一個(gè)細(xì)節(jié)值得注意如果只按日期分區(qū)那么同一天內(nèi)不同主題的標(biāo)簽寫入時(shí)需要反復(fù)動(dòng)態(tài)分區(qū)或覆蓋寫調(diào)度上非常被動(dòng)加了標(biāo)簽主題分區(qū)后每個(gè)標(biāo)簽作業(yè)可以獨(dú)立往自己的分區(qū)里寫互不干擾某個(gè)標(biāo)簽的計(jì)算失敗也只會影響它自己的分區(qū)重跑成本極低。2.2 tag 表一條用戶一個(gè)標(biāo)簽一行記錄用戶標(biāo)簽表tag 表是畫像系統(tǒng)最底層的表記錄的是“用戶 id、標(biāo)簽 id、標(biāo)簽權(quán)重”的最小粒度對應(yīng)關(guān)系。以下建表語句是這套方案的核心結(jié)構(gòu)幾乎所有標(biāo)簽結(jié)果都會落到這種格式里CREATE TABLE dw.profile_tag_userid ( user_id STRING COMMENT 用戶ID, tag_id STRING COMMENT 標(biāo)簽ID, tag_weight DOUBLE COMMENT 標(biāo)簽權(quán)重, tag_type STRING COMMENT 標(biāo)簽類型, data_date STRING COMMENT 數(shù)據(jù)日期分區(qū) ) PARTITIONED BY (data_date STRING, tag_type STRING) STORED AS ORC;向 Hive 插入測試數(shù)據(jù)的常見做法是INSERT OVERWRITE TABLE dw.profile_tag_userid PARTITION (data_date2024-05-20, tag_typeuserid_all_paid_money) SELECT user_id, userid_all_paid_money AS tag_id, sum(pay_amount) AS tag_weight FROM dwd_order_detail WHERE data_date2024-05-20 GROUP BY user_id;這段 SQL 的邏輯是從訂單明細(xì)表按用戶匯總支付金額把匯總結(jié)果作為標(biāo)簽權(quán)重寫入 tag 表分區(qū)字段 tag_type 取值為標(biāo)簽主題名。注意這里用了 INSERT OVERWRITE 而不是 INSERT INTO因?yàn)橥环謪^(qū)每天重復(fù)計(jì)算時(shí)需要保證冪等。tag_type 分區(qū)字段還有一個(gè)非常實(shí)用的功能不同類型的標(biāo)簽如消費(fèi)能力標(biāo)簽、活躍度標(biāo)簽、偏好標(biāo)簽可以并行向同一張表的不同分區(qū)寫入不需要鎖表也不會互相覆蓋。2.3 tagmap 表把同一個(gè)人身上的標(biāo)簽聚合成一條tag 表的粒度是一用戶一標(biāo)簽一行但查詢時(shí)往往是“一個(gè)用戶身上的全部標(biāo)簽”。如果每次查詢都掃 tag 表全分區(qū)性能非常差。于是方案里設(shè)計(jì)了 tagmap 表將同一個(gè)用戶的所有標(biāo)簽聚合到一行用 Map 或者拼接字符串的方式存儲。結(jié)構(gòu)類似CREATE TABLE dw.profile_user_map_userid ( user_id STRING COMMENT 用戶ID, tag_map MAPSTRING, DOUBLE COMMENT 標(biāo)簽ID到權(quán)重的映射, data_date STRING COMMENT 數(shù)據(jù)日期分區(qū) ) PARTITIONED BY (data_date STRING) STORED AS ORC;聚合執(zhí)行的思路是從 tag 表按 user_id 分組把 tag_id 和 tag_weight 收集成 Map。常見做法是寫一個(gè) HiveQL用 collect_list 和 map 函數(shù)組合構(gòu)造 Map或者直接用 Spark 的 mapFromEntries 函數(shù)處理。聚合的目的不是減少數(shù)據(jù)量而是把“用戶視角”的查詢從掃描 N 行變成掃描 1 行。這個(gè)表是后續(xù)人群圈選和畫像查詢的主力表。2.4 人群計(jì)算表從標(biāo)簽圈人到業(yè)務(wù)系統(tǒng)的數(shù)據(jù)出口人群表記錄的是圈人結(jié)果字段包括用戶 id、人群名稱 id、推送到的業(yè)務(wù)系統(tǒng)。這個(gè)表的典型特征是它需要關(guān)聯(lián)訂單表和用戶收貨信息表得到用戶的手機(jī)號等聯(lián)系信息推送給外呼中心或短信系統(tǒng)。核心 join 邏輯是人群表先 join 訂單表拿到訂單編號再 join 收貨信息表拿到手機(jī)號。三步 join 下來本質(zhì)上是從“標(biāo)簽篩選”過渡到“運(yùn)營觸達(dá)”。這個(gè)表的設(shè)計(jì)要點(diǎn)是它除了存 user_id還必須冗余業(yè)務(wù)系統(tǒng)需要的字段。因?yàn)橄掠蜗到y(tǒng)不一定能通過 user_id 反查用戶信息直接把手機(jī)號、訂單號冗余在人群結(jié)果表里同步到業(yè)務(wù)庫時(shí)可以減少一次 join。方案中給到的表結(jié)構(gòu)里人群名稱 id 和業(yè)務(wù)系統(tǒng)標(biāo)識是必備字段業(yè)務(wù)系統(tǒng)標(biāo)識決定了這條數(shù)據(jù)后面同步到 MySQL 還是 Hbase。3. MySQL 管元數(shù)據(jù)與校驗(yàn)畫像系統(tǒng)的“控制面”搭建3.1 MySQL 在畫像系統(tǒng)里的三個(gè)職責(zé)MySQL 在畫像系統(tǒng)里不存明細(xì)標(biāo)簽數(shù)據(jù)它管的是三類東西畫像標(biāo)簽的元數(shù)據(jù)、結(jié)果集校驗(yàn)信息、同步到業(yè)務(wù)系統(tǒng)的數(shù)據(jù)。一句話概括Hive 是數(shù)據(jù)面MySQL 是控制面。元數(shù)據(jù)維護(hù)著標(biāo)簽的 id、名稱、主題、一級二級分類、標(biāo)簽描述等。一個(gè)標(biāo)簽從需求提出到上線先在元數(shù)據(jù)表里登記然后才進(jìn)入 Hive 計(jì)算流程。結(jié)果集校驗(yàn)信息包括當(dāng)日標(biāo)簽覆蓋用戶量、當(dāng)日與前一日波動(dòng)比例、當(dāng)日標(biāo)簽覆蓋用戶占活躍用戶比例、任務(wù)是否繼續(xù)執(zhí)行的標(biāo)志位。這些校驗(yàn)表的存在是為了避免 0 點(diǎn)調(diào)度任務(wù)跑完之后沒人檢查是否產(chǎn)出正常就直接同步線上。3.2 元數(shù)據(jù)表與校驗(yàn)表的字段設(shè)計(jì)元數(shù)據(jù)表結(jié)構(gòu)設(shè)計(jì)上至少要包含這些字段字段名類型說明tag_idvarchar(64)標(biāo)簽唯一 ID與 Hive 中 tag_id 對齊tag_namevarchar(128)標(biāo)簽名稱tag_themevarchar(64)標(biāo)簽主題與 Hive 分區(qū)對應(yīng)level1_categoryvarchar(64)一級分類level2_categoryvarchar(64)二級分類tag_desctext標(biāo)簽描述包括口徑和計(jì)算邏輯ownervarchar(64)負(fù)責(zé)人用于標(biāo)簽運(yùn)維結(jié)果集校驗(yàn)表的核心字段是標(biāo)簽 id、數(shù)據(jù)日期、覆蓋用戶量、波動(dòng)比例、校驗(yàn)狀態(tài)。其中波動(dòng)比例的計(jì)算邏輯是當(dāng)日覆蓋用戶量 - 前日覆蓋用戶量/ 前日覆蓋用戶量超過閾值時(shí)就寫入告警標(biāo)志位。這個(gè)標(biāo)志位在調(diào)度系統(tǒng)里會被讀取決定下游任務(wù)是否繼續(xù)執(zhí)行。很多團(tuán)隊(duì)的調(diào)度依賴只用“前一個(gè)任務(wù)是否成功”但畫像場景更嚴(yán)謹(jǐn)?shù)淖龇ㄊ恰扒耙粋€(gè)任務(wù)成功且數(shù)據(jù)質(zhì)量校驗(yàn)通過”否則會帶著錯(cuò)誤數(shù)據(jù)一路同步到線上。3.3 從 Hive 同步 MySQLSqoop 命令與 Python 腳本的取舍同步到業(yè)務(wù)系統(tǒng)這一步方案里給了兩個(gè)路徑Sqoop 同步和 Python 腳本同步。Sqoop 適合一次性的、整表的同步命令示例sqoop export \ --connect jdbc:mysql://mysql-host:3306/user_profile \ --username root --password secret \ --table customer_push_list \ --export-dir /user/hive/warehouse/dw.db/customer_push_list \ --input-fields-terminated-by \001 \ --columns user_id,phone,order_id,campaign_id \ --batch \ --update-mode allowinsert \ --update-key user_id,campaign_id這段命令的邏輯說明從 Hive 的 customer_push_list 表導(dǎo)出數(shù)據(jù)到 MySQL 的 customer_push_list 表字段分隔符是 Hive 默認(rèn)的 \001update-mode 設(shè)置為 allowinsert 表示已存在的主鍵更新、不存在則插入。這個(gè)參數(shù)很關(guān)鍵——業(yè)務(wù)系統(tǒng)推送場景里同一個(gè)用戶可能被多個(gè)活動(dòng)圈中以 user_id 和 campaign_id 作為聯(lián)合主鍵才能避免數(shù)據(jù)互相覆蓋。日常維護(hù)中我更傾向于寫一個(gè) Python 腳本同步。因?yàn)?Sqoop 的缺字段、字符集問題在畫像這種多口徑場景里比較常見Python 腳本可以同步過程里做數(shù)據(jù)量對比、格式轉(zhuǎn)換和異常重試。腳本的核心邏輯是查 Hive 當(dāng)日分區(qū)總數(shù)查 MySQL 目標(biāo)表當(dāng)前總數(shù)兩數(shù)對不上就發(fā)告警不執(zhí)行寫入。4. Hbase 與 Elasticsearch圈人結(jié)果入庫與在線查詢的兩種路徑4.1 為什么圈人結(jié)果要推 Hbase線上服務(wù)的時(shí)延要求畫像系統(tǒng)產(chǎn)品化之后運(yùn)營人員圈完一個(gè)人群這批人需要進(jìn)入廣告系統(tǒng)、push 消息系統(tǒng)等線上服務(wù)。這類業(yè)務(wù)系統(tǒng)讀數(shù)據(jù)的特點(diǎn)是QPS 高、單次查詢要求毫秒級返回、數(shù)據(jù)量從幾十萬到幾千萬不等。Hive 完全扛不住這種查詢壓力MySQL 在千萬級數(shù)據(jù) 高并發(fā)場景下也容易出現(xiàn)連接打滿。Hbase 的隨機(jī)讀寫能力在這個(gè)場景里是剛需。同步鏈路一般是這樣運(yùn)營在頁面上配置規(guī)則規(guī)則和圈出的人群標(biāo)簽集存 MySQLSpark 作業(yè)讀取 MySQL 中的標(biāo)簽集信息去 Hive 的標(biāo)簽表計(jì)算具體人群計(jì)算結(jié)果寫入 Hive 當(dāng)日分區(qū)然后再由同步作業(yè)把該分區(qū)數(shù)據(jù)寫入 Hbase 對應(yīng)表。4.2 Hive 映射 Hbase 表的兩種建表方式同步 Hive 數(shù)據(jù)到 Hbase常見做法是創(chuàng)建 Hive 到 Hbase 的映射表。第一種方式是啟動(dòng) Hive創(chuàng)建一張映射到 Hbase 的 Hive 外部表然后向該映射表插入測試數(shù)據(jù)Hbase 側(cè)會自動(dòng)建表。第二種方式是直接在 Hbase 側(cè)建表然后用 Hive 關(guān)聯(lián)查詢。我實(shí)際落地更推薦第一種因?yàn)榭梢灾苯訌?fù)用 Hive 的 SQL 邏輯插入語句執(zhí)行起來就是一個(gè) MapReduce 作業(yè)跑完數(shù)據(jù)自然落在 Hbase 里。如果非要用 Hbase 原生 API 寫批量導(dǎo)入常見做法是使用 Hbase 的 BulkLoad 工具先讓 MapReduce 作業(yè)生成 HFile再加載到 Hbase 表。這個(gè)方式跳過了 WAL 寫入速度比直接 put 快很多適合千萬級以上的初始導(dǎo)入。但注意 BulkLoad 只適合一次性大批量導(dǎo)入不適合頻繁的小批量同步因?yàn)樯?HFile 和加載 HFile 的過程需要額外的 HDFS 空間操作不當(dāng)容易把 region 弄得不均勻。4.3 Hbase 同步的兩種數(shù)據(jù)校驗(yàn)方案這是整套方案里工程含金量最高的一段。因?yàn)楣嗳?Hbase 的數(shù)據(jù)直接應(yīng)用到線上反饋到用戶那里任何數(shù)據(jù)問題都會直接暴露所以同步必須加校驗(yàn)。方案里給了兩種做法。第一種Hive 同步 Hbase 后先在 Hbase 里建一個(gè) temp 臨時(shí)表數(shù)據(jù)寫入臨時(shí)表再校驗(yàn)臨時(shí)表和 Hive 表的數(shù)據(jù)量差異。如果差異在可接受范圍內(nèi)把 Hbase 臨時(shí)表 rename 成正式表。這利用了 Hbase 改表名的低成本特性但代價(jià)是同步期間線上讀不到當(dāng)天最新數(shù)據(jù)。第二種Hive 同步 Hbase 后直接寫入正式表同時(shí)建立一張狀態(tài)表。同步完成觸發(fā)校驗(yàn)校驗(yàn)通過后在狀態(tài)表寫入當(dāng)天日期和校驗(yàn)狀態(tài)。線上接口請求時(shí)只讀取狀態(tài)表中最近日期的數(shù)據(jù)。如果同步異常狀態(tài)表不更新線上繼續(xù)讀取前一天的數(shù)據(jù)。這種方案的優(yōu)點(diǎn)是不影響線上讀取缺點(diǎn)是數(shù)據(jù)質(zhì)量有問題時(shí)當(dāng)天數(shù)據(jù)可能已經(jīng)暴露給線上一段時(shí)間了所以校驗(yàn)任務(wù)必須緊跟在同步任務(wù)之后立刻執(zhí)行。我在生產(chǎn)上更傾向第二種方案配合告警同步完成立刻校驗(yàn)數(shù)量對不上馬上釘釘告警DBA 介入前線上可能只有幾分鐘的臟數(shù)據(jù)窗口但總比長時(shí)間沒有新鮮數(shù)據(jù)要好。4.4 Elasticsearch 在畫像里的真實(shí)定位不是替代 Hbase方案里對 Elasticsearch 的描述很務(wù)實(shí)一個(gè)開源的分布式全文檢索引擎近乎實(shí)時(shí)地存儲、檢索數(shù)據(jù)擴(kuò)展性好可以處理 PB 級別數(shù)據(jù)。對于用戶標(biāo)簽查詢、用戶人群計(jì)算、用戶群多維透視分析這類對響應(yīng)時(shí)間要求較高的場景可以考慮選用 Elasticsearch。實(shí)際工程中ES 在畫像系統(tǒng)里主要干兩類事。第一類是標(biāo)簽明細(xì)的快速查詢比如運(yùn)營輸入一個(gè)用戶 id 或 cookie立刻看到這個(gè)人的全部標(biāo)簽這個(gè)場景用 ES 的基于 user_id 的查詢毫秒級返回第二類是人群的多維透視分析比如圈選了“近 30 天有購買行為且客單價(jià)高于 500 元”的人群后想看這批人的年齡分布、城市分布ES 的聚合查詢aggs非常擅長這種場景一個(gè) JSON 查詢就能返回多維統(tǒng)計(jì)結(jié)果而 Hive 跑這種即席分析至少要分鐘級。ES 存儲畫像數(shù)據(jù)的索引結(jié)構(gòu)設(shè)計(jì)上常見做法是每個(gè)標(biāo)簽一個(gè)字段或者用 nested 對象存標(biāo)簽數(shù)組。前者適合標(biāo)簽數(shù)量少、結(jié)構(gòu)固定的場景后者適合標(biāo)簽動(dòng)態(tài)擴(kuò)展的場景。索引設(shè)計(jì)時(shí)一定要給 tag_id 字段設(shè)置 keyword 類型否則分詞后無法精確匹配。5. 標(biāo)簽數(shù)據(jù)同步避坑四個(gè)我實(shí)測過的生產(chǎn)環(huán)境問題5.1 Hive 同步 Hbase 后數(shù)據(jù)量對不上現(xiàn)象Hive 表統(tǒng)計(jì)有 5000 萬條同步到 Hbase 后 count 只有 1000 萬條。原因排查下來最常見的是 rowkey 設(shè)計(jì)沖突。Hbase 的 rowkey 如果只取 user_id那么同一用戶的多條標(biāo)簽記錄會互相覆蓋導(dǎo)致數(shù)據(jù)行數(shù)變少。解決方式分兩步第一確認(rèn)目標(biāo)表的 rowkey 是否包含區(qū)分字段同步前先預(yù)估同一 user_id 最多有幾條記錄用 user_id 標(biāo)簽類別或時(shí)間戳拼 rowkey第二同步完成后先查 Hbase 中目標(biāo)表的行數(shù)再查源 Hive 表行數(shù)兩者偏差超過 1% 時(shí)觸發(fā)告警而不是等業(yè)務(wù)方反饋數(shù)據(jù)缺失。5.2 分區(qū)字段寫錯(cuò)導(dǎo)致標(biāo)簽數(shù)據(jù)覆蓋現(xiàn)象某天標(biāo)簽計(jì)算結(jié)果異常發(fā)現(xiàn)大量用戶標(biāo)簽丟失。原因同一個(gè) tag 表按日期和標(biāo)簽主題分區(qū)寫 SQL 時(shí)把分區(qū)字段 tag_type 寫成了另一個(gè)主題的值插入后覆蓋了同主題前一天的數(shù)據(jù)。尤其是使用了 INSERT OVERWRITE 的分區(qū)表一旦分區(qū)條件寫錯(cuò)不會有任何報(bào)錯(cuò)數(shù)據(jù)就靜默覆蓋了。解決所有分區(qū)表寫入腳本里強(qiáng)制校驗(yàn) data_date 和 tag_type 是否為當(dāng)天預(yù)期的值腳本里寫死日期變量不允許用 current_date 之類的動(dòng)態(tài)值上線前先 SELECT COUNT(*) 看一眼目標(biāo)分區(qū)今天是否有數(shù)據(jù)有數(shù)據(jù)立刻停。5.3 MySQL 同步時(shí)主鍵沖突導(dǎo)致任務(wù)卡死現(xiàn)象Sqoop 同步 Hive 數(shù)據(jù)到 MySQL跑了一小時(shí)后任務(wù)失敗報(bào) duplicate entry。原因MySQL 目標(biāo)表主鍵設(shè)置不合理Hive 側(cè)同一 user_id 出現(xiàn)重復(fù)導(dǎo)致 MySQL 插入沖突。解決在 Sqoop 命令里加 update-key 參數(shù)把 sync 模式改為 upsert同時(shí)檢查源 Hive 表是否有重復(fù)有重復(fù)就在導(dǎo)出 SQL 里先去重。這條經(jīng)驗(yàn)也適用于 Python 腳本同步——腳本里必須寫 INSERT ... ON DUPLICATE KEY UPDATE 而不是 INSERT。5.4 校驗(yàn)標(biāo)志位與數(shù)據(jù)寫入不在同一事務(wù)里現(xiàn)象狀態(tài)表顯示當(dāng)天數(shù)據(jù)校驗(yàn)通過但線上接口讀到的還是舊數(shù)據(jù)。原因Hbase 數(shù)據(jù)先寫入正式表再寫狀態(tài)表兩步之間沒有原子性。如果中間有短暫的時(shí)間窗口狀態(tài)表里是當(dāng)天最新日期但 Hbase 正式表還在寫入過程中線上的查詢就可能讀到半新半舊的數(shù)據(jù)。解決把寫入順序反過來先寫狀態(tài)表再寫 Hbase 正式表或者利用 Hbase 的 timestamp 版本控制線上讀取時(shí)只取 status 表標(biāo)記的日期之前的數(shù)據(jù)。更穩(wěn)妥的方案是直接用 Hbase 的 coprocessor 或異步批處理框架把狀態(tài)更新和數(shù)據(jù)寫入包裝在同一個(gè)任務(wù)里失敗時(shí)統(tǒng)一回滾。6. 數(shù)據(jù)量校驗(yàn)?zāi)_本與臨時(shí)表雙寫基線不重跑全量作業(yè)的妥協(xié)方案前面講了那么多表結(jié)構(gòu)和同步鏈路最后分享一個(gè)我一直在用的具體技巧如何高效做 Hive 到 Hbase 的日常數(shù)據(jù)校驗(yàn)而不用每次重跑全量作業(yè)。先說基線。畫像系統(tǒng)里Hive 中的用戶標(biāo)簽表每天都在增量更新但 Hbase 中的線上標(biāo)簽表通常是全量覆蓋邏輯。全量覆蓋的問題在于每次同步都要把全部用戶的數(shù)據(jù)推一遍隨著用戶量增長同步時(shí)間越來越長。我的習(xí)慣是建一張基線表Hive 里維護(hù)一張最基礎(chǔ)的“離線用戶全量表”記錄 user_id、最近活躍日期、核心標(biāo)簽摘要。同步 Hbase 時(shí)只同步當(dāng)天有變化的用戶沒變化的用戶繼續(xù)沿用前一天 Hbase 里的數(shù)據(jù)。這樣把全量同步變成了增量同步同步時(shí)間從兩小時(shí)降到二十分鐘。增量同步帶來的新問題是怎么確認(rèn) Hbase 里的最終數(shù)據(jù)等于 Hive 全量數(shù)據(jù)的期望結(jié)果我用的校驗(yàn)策略是雙層比對import happybase from pyhive import hive # 1. 從 Hive 查詢當(dāng)天應(yīng)覆蓋的總用戶數(shù) conn hive.Connection(hosthive-server, port10000) cursor conn.cursor() cursor.execute( SELECT count(*) FROM dw.profile_tag_userid WHERE data_date 2024-05-20 ) hive_cnt cursor.fetchone()[0] # 2. 從 Hbase 查詢當(dāng)天同步后實(shí)際覆蓋的用戶數(shù) pool happybase.ConnectionPool(size3, hosthbase-server) with pool.connection() as hbase_conn: table hbase_conn.table(profile_tag_user) # 當(dāng)天同步的用戶都會帶上日期前綴 rowkey hbase_cnt 0 for _ in table.scan(row_prefixb2024-05-20): hbase_cnt 1 # 3. 計(jì)算偏差率超過閾值則寫告警狀態(tài)不更新狀態(tài)表 diff_ratio abs(hive_cnt - hbase_cnt) / max(hive_cnt, 1) if diff_ratio 0.01: print(f數(shù)據(jù)量偏差率達(dá)到 {diff_ratio:.2%}, 觸發(fā)告警)這段腳本的邏輯說明先從 Hive 拿到當(dāng)天的應(yīng)覆蓋用戶總量再根據(jù) rowkey 前綴從 Hbase 統(tǒng)計(jì)實(shí)際寫入量偏差率超過 1% 就觸發(fā)告警。這種做法比單獨(dú)依賴 Sqoop 日志或 Hbase 的計(jì)數(shù)統(tǒng)計(jì)更可靠因?yàn)樗腔?SQL 語義和數(shù)據(jù)落盤結(jié)果的雙向驗(yàn)證。參數(shù)上要關(guān)注兩個(gè)點(diǎn)。一個(gè)是 Hbase 的 scan 超時(shí)設(shè)置用戶量大時(shí)全表 scan 會很慢可以把 row_prefix 設(shè)計(jì)成按天加用戶 id 哈希前綴這樣每天的同步記錄分布在固定前綴下scan 范圍可控。另一個(gè)是校驗(yàn)的觸發(fā)時(shí)機(jī)不要等 Hbase 同步作業(yè)完成之后立刻校驗(yàn)建議加一個(gè)三分鐘的延遲確認(rèn) Hbase 的寫入已經(jīng)完成且 region 沒有在分裂合并時(shí)再校驗(yàn)減少誤報(bào)。這個(gè)方案不完美的地方在于臨時(shí)表雙寫會多耗一倍 Hbase 存儲空間。所以我在生產(chǎn)里不會天天用臨時(shí)表只在版本升級、計(jì)算口徑調(diào)整、Hbase 集群擴(kuò)容后做一次全量雙寫校驗(yàn)。日常增量同步就靠狀態(tài)表 數(shù)據(jù)量偏差告警兩條線兜底。從那以后我每次搭畫像系統(tǒng)都強(qiáng)制走一遍“Hive 明細(xì)落分區(qū)、校驗(yàn)表盯波動(dòng)、同步鏈路加狀態(tài)位、線下腳本做抽檢”這條流程少一步心里都不踏實(shí)。數(shù)據(jù)量對不上這種問題一旦漏到線上排查成本是同步成本的幾十倍。這套方案里最值得學(xué)的不是某個(gè)具體的 SQL而是那套“兩種校驗(yàn)方案并行”的思路——寧可多寫一個(gè)臨時(shí)表也別讓臟數(shù)據(jù)在線上裸奔。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取