快手建設(shè) HBase 差不多有2年時(shí)間，在公司里面有比較豐富的應(yīng)用場(chǎng)景：如短視頻的存儲(chǔ)、IM、直播里評(píng)論 feed 流等場(chǎng)景。本次只分享其中的一個(gè)應(yīng)用場(chǎng)景：快手 HBase 在千億級(jí)用戶特征數(shù)據(jù)分析中的應(yīng)用與實(shí)踐。為什么分享這個(gè) Topic?主要原因：對(duì)于大部分公司來(lái)說(shuō)，這都是一個(gè)普適的場(chǎng)景，因?yàn)楹芷毡�，所以可選擇的分析引擎也非常多，但是目前直接用 HBase 這種分析用戶特征的比較少，希望通過(guò)今天的分享，大家在將來(lái)遇到這種場(chǎng)景時(shí), 可以給大家提供一個(gè)新的解決方案。

本次分享內(nèi)容包括：

業(yè)務(wù)需求及挑戰(zhàn)：BitBase 引擎的初衷是什么;
BitBase 解決方案：在 HBase 基礎(chǔ)上，BitBase 的架構(gòu)是什么樣;
業(yè)務(wù)效果：在快手的實(shí)際應(yīng)用場(chǎng)景中，效果如何;
未來(lái)規(guī)劃：中短期的規(guī)劃。

▌業(yè)務(wù)需求及挑戰(zhàn)

1. 業(yè)務(wù)需求

 

 

用一句話來(lái)概括業(yè)務(wù)需求：在千億級(jí)日志中，選擇任意維度，秒級(jí)計(jì)算7-90日留存。

如上圖所示。左邊是原始數(shù)據(jù)，可能跨90天，每一天的數(shù)據(jù)可以看作是一張 Hive 寬表，在邏輯上可以認(rèn)為每行數(shù)據(jù)的 rowkey 是 userId(這里不嚴(yán)謹(jǐn)，userId 可能是重復(fù)的)，需要通過(guò)90天的原始數(shù)據(jù)計(jì)算得到右邊的表，它的橫軸和縱軸都是日期，每個(gè)格子表示縱軸日期相對(duì)于橫軸日期的留存率。

該需求的挑戰(zhàn)：

日志量大，千億級(jí);
任意維度，如 city、sex、喜好等，需要選擇任意多個(gè)維度，在這些維度下計(jì)算留存率;
秒級(jí)計(jì)算，產(chǎn)品面向分析師，等待時(shí)間不能過(guò)長(zhǎng)，最好在1-2秒。

2. 技術(shù)選型

 

 

面對(duì)這些問(wèn)題，我們當(dāng)時(shí)的技術(shù)選型：

① Hive，因?yàn)榇蟛糠謹(jǐn)?shù)據(jù)可能是存在 Hive 里，可以直接寫 SQL 計(jì)算，該方案不用做數(shù)據(jù)遷移和轉(zhuǎn)換，但是時(shí)延可能是分鐘到小時(shí)級(jí)別，因此否定了這個(gè)方案。

② ES，通過(guò)原始數(shù)據(jù)做倒排索引，然后做一個(gè)類似計(jì)算 UV 的方式求解，但是在數(shù)據(jù)需要做精確去重的場(chǎng)景下，它的耗時(shí)比較大，需要秒到分鐘級(jí)。

③ ClickHouse，ClickHouse 是一個(gè)比較合適的引擎，也是一個(gè)非常優(yōu)秀的引擎，在業(yè)界被廣泛應(yīng)用于 APP 分析，比如漏斗，留存。但是在我們的測(cè)試的中，當(dāng)機(jī)器數(shù)量比較少時(shí) ( <10臺(tái) )，耗時(shí)依然在10秒以上。

立足于這種場(chǎng)景，是否存在其它解決方案，延遲可以做到2-3秒(復(fù)雜的場(chǎng)景10秒以下)，同時(shí)支持任意維度組合?基于 HBase，結(jié)合業(yè)界簡(jiǎn)單/通用的技術(shù)， 我們?cè)O(shè)計(jì)并實(shí)現(xiàn)了 BitBase 解決方案，用很少的資源滿足業(yè)務(wù)需求。

▌BitBase 解決方案

1. 數(shù)據(jù)模型

 

 

如上圖所示，首先將原始數(shù)據(jù)的一列的某個(gè)值抽象成 bitmap(比特?cái)?shù)組)，舉例：city=bj，city 是維度，bj (北京) 是維度值，抽象成 bitmap 值就是10100，表示第0個(gè)用戶在 bj，第1個(gè)用戶不在北京，依次類推。然后將多維度之間的組合轉(zhuǎn)換為 bitmap 計(jì)算：bitmap 之間做與、或、非、異或，舉例：比如在北京的用戶，且興趣是籃球，這樣的用戶有多少個(gè)，就轉(zhuǎn)換為圖中所示的兩個(gè) bitmap 做與運(yùn)算，得到橙色的 bitmap，最后，再對(duì) bitmap 做 count 運(yùn)算。count 表示統(tǒng)計(jì)“1”的個(gè)數(shù)，list 是列舉“1”所在的數(shù)組 index，業(yè)務(wù)上表示 userId。

2. BitBase 架構(gòu)

 

 

整個(gè) BitBase 架構(gòu)包括五部分：

數(shù)據(jù)存儲(chǔ)：主要存儲(chǔ)兩類數(shù)據(jù)，一類數(shù)據(jù)是 bitmap 索引和數(shù)據(jù)，另一類是轉(zhuǎn)換字典的歸檔文件(見后面描述)。
數(shù)據(jù)轉(zhuǎn)換：有兩種方式，第一種是通過(guò) mrjob 轉(zhuǎn)換，第二種是在線計(jì)算或?qū)��?
數(shù)據(jù)計(jì)算：負(fù)責(zé)計(jì)算和調(diào)度，并把 IO 數(shù)據(jù)計(jì)算結(jié)果返回給 Client;
Client：站在業(yè)務(wù)的角度，把它們的業(yè)務(wù)邏輯分裝成一個(gè)個(gè)業(yè)務(wù)的接口;
ZK：整個(gè)系統(tǒng)是一個(gè)分布式的服務(wù)，用 ZK 做管理。

3. 存儲(chǔ)模塊

 

 

用數(shù)據(jù)存儲(chǔ)設(shè)計(jì)的核心目的是讓計(jì)算更快。

如上圖，左邊為一天的原始數(shù)據(jù)，包括多個(gè) table，通過(guò) mrjob 或者 rpc 的方式轉(zhuǎn)換成中間的 bitmap。

bitmap 分為兩部分，第一部分為 meta 信息(橙色部分)，第二部分是 data 信息：

Meta 信息唯一定位一個(gè) bitmap，db 可以認(rèn)為是 hive 中的 db，table 也可以認(rèn)為是 hive 中的 table，event 表示維度 (如:城市)，eventv 表示維度值 (如:bj)，entity 表示 userId(也可能是 photoId)，version 表示版本。

BitmapData 從物理上講是一個(gè)比特?cái)?shù)組，把比特?cái)?shù)組按照一定的大小進(jìn)行切塊：b1，b2，b3，...，bn，從而實(shí)現(xiàn)分塊存儲(chǔ)，分塊計(jì)算。

最后把 bitmap 存在 HBase 的3張表中: 兩張核心表和一張輔助表。

BitmapMeta， 保存 bitmap 的 meta 信息和一些 block 索引信息。
BlockData， 直接保存 bitmap block 數(shù)據(jù)。
BlockMeta，保存 block 的 meta 信息，起輔助作用。

4. 計(jì)算模塊

 

 

一個(gè)完整的計(jì)算流程涉及到三個(gè)組件：BitBase Client、BitBase Server 和 HBase regionServer。

① BitBase Client 首先把業(yè)務(wù)的需求封裝成計(jì)算表達(dá)式，然后把計(jì)算表達(dá)式發(fā)給 BitBase Server;

② BitBaseServe 接收到請(qǐng)求后，從 BitmapMeta 表中查詢 Block 索引，然后根據(jù)索引將表達(dá)式切分為 n 個(gè)子表達(dá)式;

③ 如果所有 bitmap 的 db 相同，則走 coprocessor 路由，否則按照數(shù)據(jù)親和性，將 block 計(jì)算分發(fā)到其它 bitbaseServer 中。

④ 根據(jù)第3步的調(diào)度策略，分兩條不同的路徑計(jì)算 block 表達(dá)式

⑤ BitBase Server 聚合 block 計(jì)算表達(dá)式的結(jié)果，然后返回給 BitBase Client。

兩種計(jì)算方式的對(duì)比：

非本地計(jì)算，解決跨 db 計(jì)算的需求，它主要的瓶頸在于網(wǎng)卡和 GC。

本地計(jì)算，解決同 db 計(jì)算的需求，它主要的瓶頸在 CPU 和 GC 上。整體上看本地計(jì)算的性能比非本地計(jì)算的性能提高3-5倍，所以要盡量采用本地計(jì)算方式。

5. DeviceId 問(wèn)題

 

 

在引入 Bitmap 數(shù)據(jù)模型之后，我們隱含的也引入了一個(gè)非常大的問(wèn)題：無(wú)法支持 deviceId。要支持 deviceId，首先需要將 deviceId 轉(zhuǎn)化為數(shù)字類型，并且轉(zhuǎn)換之后的 DeviceIdIndex 必須要滿足四個(gè)條件：

① 連續(xù)：deviceIdIndex 如果存在空洞，會(huì)降低壓縮效率，同時(shí) Block 數(shù)量會(huì)增加，計(jì)算復(fù)雜度相應(yīng)增加，最終計(jì)算變慢;

② 一致：deviceId 和 deviceIdIndex 必須是一一對(duì)應(yīng)的，否則計(jì)算結(jié)果不準(zhǔn)確;

③ 反解：根據(jù) deviceIdIndex 能夠準(zhǔn)確、快速地反解成原始的 deviceId;

④ 轉(zhuǎn)換快：在億級(jí)數(shù)據(jù)規(guī)模下，deviceId 轉(zhuǎn)化為 deviceIdIndex 的過(guò)程不能太長(zhǎng)。

6. DeviceId 方案

連續(xù)、一致、支持反解：

 

 

如何保證連續(xù)、一致、支持反解?解決方案非常簡(jiǎn)單，利用 HBase 實(shí)現(xiàn)兩階段提交協(xié)議。如上圖中間實(shí)線部分所示，定義 deviceId 到 deviceIdIndex 的映射為字典。第一張表存儲(chǔ)字典的 meta 信息;第二張表存儲(chǔ) index 到 deviceId 的映射;第三張表存儲(chǔ) deviceId 到 index 的映射。

生成 Index 的過(guò)程。舉例說(shuō)明, 假設(shè)我們已經(jīng)生成了 1w 個(gè) deviceId 映射，那么此時(shí) f:max=1w，現(xiàn)在將新生成 1k 條映射：

① 將 f:nextMax=f:max+1k=1.1w;
② 寫 Index 到 deviceId 的反向映射表，1k 條;
③ 寫 deviceId 到 Index 的正向映射表，1k 條;
④ 把 f:max=f:nextMax=1.1w 更新到 meta 表，生成過(guò)程結(jié)束。

如果在生成過(guò)程中出現(xiàn)異�；蚍�務(wù)器宕機(jī)，則執(zhí)行回滾流程：

① 如果我們檢測(cè)到 f:nextMax 不等于 f:max(f:nextMax>f:max)，則從表2中查詢 max 到 nextMax 的數(shù)據(jù)，從表3中刪掉相應(yīng)的 deviceId 到 index 的映射記錄;

② 再刪掉表2中相應(yīng)的 index 到 deviceId 的記錄;
③ 最后把 f:nextMax=f:max，從而實(shí)現(xiàn)數(shù)據(jù)100%一致。

用 HBase 實(shí)現(xiàn)兩階段提交協(xié)議要求 index 生成流程和回滾流程一定是單線程的，從而出現(xiàn)性能瓶頸，所以 BitBase 設(shè)計(jì)了歸檔流程，以支持快速轉(zhuǎn)換(見后面的描述)。Meta 表中有兩個(gè)字段，如果發(fā)現(xiàn)新產(chǎn)生的數(shù)據(jù)大于 f:archive_num 就發(fā)起歸檔，把表3中的新數(shù)據(jù)直接寫到 HDFS 中 archive_path 目錄下。

快速轉(zhuǎn)化：

 

 

這里我們用到了 MRjob 中的 Join：

① 同時(shí)輸入原始數(shù)據(jù)和字典歸檔數(shù)據(jù)，在 MRjob 中根據(jù) deviceId 做 join;
② 判斷 deviceId 是否 join 成功;
③ 如果成功了，直接寫 hdfs，這樣就得到了轉(zhuǎn)化后的數(shù)據(jù);
④ 如果 join 失敗，直接請(qǐng)求單實(shí)例 BitBase Master，BitBase Master 通過(guò)兩階段提交協(xié)議生成新的映射;
⑤ 然后返回給 join task 執(zhí)行替換 deviceId;
⑥ 把轉(zhuǎn)換后的數(shù)據(jù)寫入 hdfs。

反解的過(guò)程很簡(jiǎn)單，直接多并發(fā)讀取 HBase。

▌業(yè)務(wù)效果

 

如上圖所示，第一個(gè)圖是，2維度，不同時(shí)間跨度計(jì)算留存的時(shí)間延遲，第2個(gè)圖是15日留存在不同維度上的時(shí)延，時(shí)延并不會(huì)隨著維度的增長(zhǎng)而增長(zhǎng)，原因是維度越多，表達(dá)式中可能不需要計(jì)算的 block 塊也越多。

 

 

 

如上圖所示，BitBase 可以應(yīng)用在 app 分析，用戶增長(zhǎng)，廣告 DMP，用戶畫像等多個(gè)業(yè)務(wù)場(chǎng)景中。

▌未來(lái)規(guī)劃

 

根據(jù)現(xiàn)在面臨的業(yè)務(wù)場(chǎng)景，BitBase 后續(xù)會(huì)在多個(gè)方面做優(yōu)化。支持實(shí)時(shí)聚合，在一些業(yè)務(wù)場(chǎng)景下，如運(yùn)營(yíng)效果監(jiān)測(cè)，導(dǎo)入時(shí)效需要 <5min，BitBase 需要支持實(shí)時(shí)聚合;支持 SQL 查詢，目前只支持 api 的接入方式，在一些簡(jiǎn)單場(chǎng)景下比較復(fù)雜;開源，希望通過(guò)開源，和大家一起挖掘 BitBase 的業(yè)務(wù)場(chǎng)景。

 

 

 

嘉賓介紹

陳楊，快手大數(shù)據(jù)高級(jí)研發(fā)工程師。負(fù)責(zé)快手HBase以及相關(guān)生態(tài)組件的維護(hù)與研發(fā)。

標(biāo)簽： HBase 數(shù)據(jù)分析

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。