分享嘉賓：陳楊 快手
編輯整理：Hoh Xil
內容來源：BigData NoSQL 12th Meetup
出品社區：DataFun
注：歡迎轉載，轉載請註明出處。
快手建設 HBase 差不多有2年時間，在公司裡面有比較豐富的應用場景：如短視頻的存儲、IM、直播裡評論 feed 流等場景。本次只分享其中的一個應用場景：快手 HBase 在千億級用戶特徵數據分析中的應用與實踐。為什麼分享這個 Topic？主要原因：對於大部分公司來說，這都是一個普適的場景，因為很普遍，所以可選擇的分析引擎也非常多，但是目前直接用 HBase 這種分析用戶特徵的比較少，希望通過今天的分享，大家在將來遇到這種場景時, 可以給大家提供一個新的解決方案。
本次分享內容包括：
- 業務需求及挑戰：BitBase 引擎的初衷是什麼；
- BitBase 解決方案：在 HBase 基礎上，BitBase 的架構是什麼樣；
- 業務效果：在快手的實際應用場景中，效果如何；
- 未來規劃：中短期的規劃。
▌業務需求及挑戰
1. 業務需求
分享嘉賓：陳楊 快手
編輯整理：Hoh Xil
內容來源：BigData NoSQL 12th Meetup
出品社區：DataFun
注：歡迎轉載，轉載請註明出處。
快手建設 HBase 差不多有2年時間，在公司裡面有比較豐富的應用場景：如短視頻的存儲、IM、直播裡評論 feed 流等場景。本次只分享其中的一個應用場景：快手 HBase 在千億級用戶特徵數據分析中的應用與實踐。為什麼分享這個 Topic？主要原因：對於大部分公司來說，這都是一個普適的場景，因為很普遍，所以可選擇的分析引擎也非常多，但是目前直接用 HBase 這種分析用戶特徵的比較少，希望通過今天的分享，大家在將來遇到這種場景時, 可以給大家提供一個新的解決方案。
本次分享內容包括：
- 業務需求及挑戰：BitBase 引擎的初衷是什麼；
- BitBase 解決方案：在 HBase 基礎上，BitBase 的架構是什麼樣；
- 業務效果：在快手的實際應用場景中，效果如何；
- 未來規劃：中短期的規劃。
▌業務需求及挑戰
1. 業務需求
用一句話來概括業務需求：在千億級日誌中，選擇任意維度，秒級計算7-90日留存。
如上圖所示。左邊是原始數據，可能跨90天，每一天的數據可以看作是一張 Hive 寬表，在邏輯上可以認為每行數據的 rowkey 是 userId（這裡不嚴謹，userId 可能是重複的），需要通過90天的原始數據計算得到右邊的表，它的橫軸和縱軸都是日期，每個格子表示縱軸日期相對於橫軸日期的留存率。
該需求的挑戰：
- 日誌量大，千億級；
- 任意維度，如 city、sex、喜好等，需要選擇任意多個維度，在這些維度下計算留存率；
- 秒級計算，產品面向分析師，等待時間不能過長，最好在1-2秒。
2. 技術選型
分享嘉賓：陳楊 快手
編輯整理：Hoh Xil
內容來源：BigData NoSQL 12th Meetup
出品社區：DataFun
注：歡迎轉載，轉載請註明出處。
快手建設 HBase 差不多有2年時間，在公司裡面有比較豐富的應用場景：如短視頻的存儲、IM、直播裡評論 feed 流等場景。本次只分享其中的一個應用場景：快手 HBase 在千億級用戶特徵數據分析中的應用與實踐。為什麼分享這個 Topic？主要原因：對於大部分公司來說，這都是一個普適的場景，因為很普遍，所以可選擇的分析引擎也非常多，但是目前直接用 HBase 這種分析用戶特徵的比較少，希望通過今天的分享，大家在將來遇到這種場景時, 可以給大家提供一個新的解決方案。
本次分享內容包括：
- 業務需求及挑戰：BitBase 引擎的初衷是什麼；
- BitBase 解決方案：在 HBase 基礎上，BitBase 的架構是什麼樣；
- 業務效果：在快手的實際應用場景中，效果如何；
- 未來規劃：中短期的規劃。
▌業務需求及挑戰
1. 業務需求
用一句話來概括業務需求：在千億級日誌中，選擇任意維度，秒級計算7-90日留存。
如上圖所示。左邊是原始數據，可能跨90天，每一天的數據可以看作是一張 Hive 寬表，在邏輯上可以認為每行數據的 rowkey 是 userId（這裡不嚴謹，userId 可能是重複的），需要通過90天的原始數據計算得到右邊的表，它的橫軸和縱軸都是日期，每個格子表示縱軸日期相對於橫軸日期的留存率。
該需求的挑戰：
- 日誌量大，千億級；
- 任意維度，如 city、sex、喜好等，需要選擇任意多個維度，在這些維度下計算留存率；
- 秒級計算，產品面向分析師，等待時間不能過長，最好在1-2秒。
2. 技術選型
面對這些問題，我們當時的技術選型：
① Hive，因為大部分數據可能是存在 Hive 裡，可以直接寫 SQL 計算，該方案不用做數據遷移和轉換，但是時延可能是分鐘到小時級別，因此否定了這個方案。
② ES，通過原始數據做倒排索引，然後做一個類似計算 UV 的方式求解，但是在數據需要做精確去重的場景下，它的耗時比較大，需要秒到分鐘級。
③ ClickHouse，ClickHouse 是一個比較合適的引擎，也是一個非常優秀的引擎，在業界被廣泛應用於 APP 分析，比如漏斗，留存。但是在我們的測試的中，當機器數量比較少時 ( <10臺 )，耗時依然在10秒以上。
立足於這種場景，是否存在其它解決方案，延遲可以做到2-3秒（複雜的場景10秒以下），同時支持任意維度組合？基於 HBase，結合業界簡單/通用的技術， 我們設計並實現了 BitBase 解決方案，用很少的資源滿足業務需求。
▌BitBase 解決方案
1. 數據模型
分享嘉賓：陳楊 快手
編輯整理：Hoh Xil
內容來源：BigData NoSQL 12th Meetup
出品社區：DataFun
注：歡迎轉載，轉載請註明出處。
快手建設 HBase 差不多有2年時間，在公司裡面有比較豐富的應用場景：如短視頻的存儲、IM、直播裡評論 feed 流等場景。本次只分享其中的一個應用場景：快手 HBase 在千億級用戶特徵數據分析中的應用與實踐。為什麼分享這個 Topic？主要原因：對於大部分公司來說，這都是一個普適的場景，因為很普遍，所以可選擇的分析引擎也非常多，但是目前直接用 HBase 這種分析用戶特徵的比較少，希望通過今天的分享，大家在將來遇到這種場景時, 可以給大家提供一個新的解決方案。
本次分享內容包括：
- 業務需求及挑戰：BitBase 引擎的初衷是什麼；
- BitBase 解決方案：在 HBase 基礎上，BitBase 的架構是什麼樣；
- 業務效果：在快手的實際應用場景中，效果如何；
- 未來規劃：中短期的規劃。
▌業務需求及挑戰
1. 業務需求
用一句話來概括業務需求：在千億級日誌中，選擇任意維度，秒級計算7-90日留存。
如上圖所示。左邊是原始數據，可能跨90天，每一天的數據可以看作是一張 Hive 寬表，在邏輯上可以認為每行數據的 rowkey 是 userId（這裡不嚴謹，userId 可能是重複的），需要通過90天的原始數據計算得到右邊的表，它的橫軸和縱軸都是日期，每個格子表示縱軸日期相對於橫軸日期的留存率。
該需求的挑戰：
- 日誌量大，千億級；
- 任意維度，如 city、sex、喜好等，需要選擇任意多個維度，在這些維度下計算留存率；
- 秒級計算，產品面向分析師，等待時間不能過長，最好在1-2秒。
2. 技術選型
面對這些問題，我們當時的技術選型：
① Hive，因為大部分數據可能是存在 Hive 裡，可以直接寫 SQL 計算，該方案不用做數據遷移和轉換，但是時延可能是分鐘到小時級別，因此否定了這個方案。
② ES，通過原始數據做倒排索引，然後做一個類似計算 UV 的方式求解，但是在數據需要做精確去重的場景下，它的耗時比較大，需要秒到分鐘級。
③ ClickHouse，ClickHouse 是一個比較合適的引擎，也是一個非常優秀的引擎，在業界被廣泛應用於 APP 分析，比如漏斗，留存。但是在我們的測試的中，當機器數量比較少時 ( <10臺 )，耗時依然在10秒以上。
立足於這種場景，是否存在其它解決方案，延遲可以做到2-3秒（複雜的場景10秒以下），同時支持任意維度組合？基於 HBase，結合業界簡單/通用的技術， 我們設計並實現了 BitBase 解決方案，用很少的資源滿足業務需求。
▌BitBase 解決方案
1. 數據模型
如上圖所示，首先將原始數據的一列的某個值抽象成 bitmap（比特數組），舉例：city=bj，city 是維度，bj (北京) 是維度值，抽象成 bitmap 值就是10100，表示第0個用戶在 bj，第1個用戶不在北京，依次類推。然後將多維度之間的組合轉換為 bitmap 計算：bitmap 之間做與、或、非、異或，舉例：比如在北京的用戶，且興趣是籃球，這樣的用戶有多少個，就轉換為圖中所示的兩個 bitmap 做與運算，得到橙色的 bitmap，最後，再對 bitmap 做 count 運算。count 表示統計“1”的個數，list 是列舉“1”所在的數組 index，業務上表示 userId。
2. BitBase 架構
分享嘉賓：陳楊 快手
編輯整理：Hoh Xil
內容來源：BigData NoSQL 12th Meetup
出品社區：DataFun
注：歡迎轉載，轉載請註明出處。
快手建設 HBase 差不多有2年時間，在公司裡面有比較豐富的應用場景：如短視頻的存儲、IM、直播裡評論 feed 流等場景。本次只分享其中的一個應用場景：快手 HBase 在千億級用戶特徵數據分析中的應用與實踐。為什麼分享這個 Topic？主要原因：對於大部分公司來說，這都是一個普適的場景，因為很普遍，所以可選擇的分析引擎也非常多，但是目前直接用 HBase 這種分析用戶特徵的比較少，希望通過今天的分享，大家在將來遇到這種場景時, 可以給大家提供一個新的解決方案。
本次分享內容包括：
- 業務需求及挑戰：BitBase 引擎的初衷是什麼；
- BitBase 解決方案：在 HBase 基礎上，BitBase 的架構是什麼樣；
- 業務效果：在快手的實際應用場景中，效果如何；
- 未來規劃：中短期的規劃。
▌業務需求及挑戰
1. 業務需求
用一句話來概括業務需求：在千億級日誌中，選擇任意維度，秒級計算7-90日留存。
如上圖所示。左邊是原始數據，可能跨90天，每一天的數據可以看作是一張 Hive 寬表，在邏輯上可以認為每行數據的 rowkey 是 userId（這裡不嚴謹，userId 可能是重複的），需要通過90天的原始數據計算得到右邊的表，它的橫軸和縱軸都是日期，每個格子表示縱軸日期相對於橫軸日期的留存率。
該需求的挑戰：
- 日誌量大，千億級；
- 任意維度，如 city、sex、喜好等，需要選擇任意多個維度，在這些維度下計算留存率；
- 秒級計算，產品面向分析師，等待時間不能過長，最好在1-2秒。
2. 技術選型
面對這些問題，我們當時的技術選型：
① Hive，因為大部分數據可能是存在 Hive 裡，可以直接寫 SQL 計算，該方案不用做數據遷移和轉換，但是時延可能是分鐘到小時級別，因此否定了這個方案。
② ES，通過原始數據做倒排索引，然後做一個類似計算 UV 的方式求解，但是在數據需要做精確去重的場景下，它的耗時比較大，需要秒到分鐘級。
③ ClickHouse，ClickHouse 是一個比較合適的引擎，也是一個非常優秀的引擎，在業界被廣泛應用於 APP 分析，比如漏斗，留存。但是在我們的測試的中，當機器數量比較少時 ( <10臺 )，耗時依然在10秒以上。
立足於這種場景，是否存在其它解決方案，延遲可以做到2-3秒（複雜的場景10秒以下），同時支持任意維度組合？基於 HBase，結合業界簡單/通用的技術， 我們設計並實現了 BitBase 解決方案，用很少的資源滿足業務需求。
▌BitBase 解決方案
1. 數據模型
如上圖所示，首先將原始數據的一列的某個值抽象成 bitmap（比特數組），舉例：city=bj，city 是維度，bj (北京) 是維度值，抽象成 bitmap 值就是10100，表示第0個用戶在 bj，第1個用戶不在北京，依次類推。然後將多維度之間的組合轉換為 bitmap 計算：bitmap 之間做與、或、非、異或，舉例：比如在北京的用戶，且興趣是籃球，這樣的用戶有多少個，就轉換為圖中所示的兩個 bitmap 做與運算，得到橙色的 bitmap，最後，再對 bitmap 做 count 運算。count 表示統計“1”的個數，list 是列舉“1”所在的數組 index，業務上表示 userId。
2. BitBase 架構
整個 BitBase 架構包括五部分：
- 數據存儲：主要存儲兩類數據，一類數據是 bitmap 索引和數據，另一類是轉換字典的歸檔文件（見後面描述）。
- 數據轉換：有兩種方式，第一種是通過 mrjob 轉換，第二種是在線計算或導入；
- 數據計算：負責計算和調度，並把 IO 數據計算結果返回給 Client；
- Client：站在業務的角度，把它們的業務邏輯分裝成一個個業務的接口；
- ZK：整個系統是一個分佈式的服務，用 ZK 做管理。
3. 存儲模塊
分享嘉賓：陳楊 快手
編輯整理：Hoh Xil
內容來源：BigData NoSQL 12th Meetup
出品社區：DataFun
注：歡迎轉載，轉載請註明出處。
快手建設 HBase 差不多有2年時間，在公司裡面有比較豐富的應用場景：如短視頻的存儲、IM、直播裡評論 feed 流等場景。本次只分享其中的一個應用場景：快手 HBase 在千億級用戶特徵數據分析中的應用與實踐。為什麼分享這個 Topic？主要原因：對於大部分公司來說，這都是一個普適的場景，因為很普遍，所以可選擇的分析引擎也非常多，但是目前直接用 HBase 這種分析用戶特徵的比較少，希望通過今天的分享，大家在將來遇到這種場景時, 可以給大家提供一個新的解決方案。
本次分享內容包括：
- 業務需求及挑戰：BitBase 引擎的初衷是什麼；
- BitBase 解決方案：在 HBase 基礎上，BitBase 的架構是什麼樣；
- 業務效果：在快手的實際應用場景中，效果如何；
- 未來規劃：中短期的規劃。
▌業務需求及挑戰
1. 業務需求
用一句話來概括業務需求：在千億級日誌中，選擇任意維度，秒級計算7-90日留存。
如上圖所示。左邊是原始數據，可能跨90天，每一天的數據可以看作是一張 Hive 寬表，在邏輯上可以認為每行數據的 rowkey 是 userId（這裡不嚴謹，userId 可能是重複的），需要通過90天的原始數據計算得到右邊的表，它的橫軸和縱軸都是日期，每個格子表示縱軸日期相對於橫軸日期的留存率。
該需求的挑戰：
- 日誌量大，千億級；
- 任意維度，如 city、sex、喜好等，需要選擇任意多個維度，在這些維度下計算留存率；
- 秒級計算，產品面向分析師，等待時間不能過長，最好在1-2秒。
2. 技術選型
面對這些問題，我們當時的技術選型：
① Hive，因為大部分數據可能是存在 Hive 裡，可以直接寫 SQL 計算，該方案不用做數據遷移和轉換，但是時延可能是分鐘到小時級別，因此否定了這個方案。
② ES，通過原始數據做倒排索引，然後做一個類似計算 UV 的方式求解，但是在數據需要做精確去重的場景下，它的耗時比較大，需要秒到分鐘級。
③ ClickHouse，ClickHouse 是一個比較合適的引擎，也是一個非常優秀的引擎，在業界被廣泛應用於 APP 分析，比如漏斗，留存。但是在我們的測試的中，當機器數量比較少時 ( <10臺 )，耗時依然在10秒以上。
立足於這種場景，是否存在其它解決方案，延遲可以做到2-3秒（複雜的場景10秒以下），同時支持任意維度組合？基於 HBase，結合業界簡單/通用的技術， 我們設計並實現了 BitBase 解決方案，用很少的資源滿足業務需求。
▌BitBase 解決方案
1. 數據模型
如上圖所示，首先將原始數據的一列的某個值抽象成 bitmap（比特數組），舉例：city=bj，city 是維度，bj (北京) 是維度值，抽象成 bitmap 值就是10100，表示第0個用戶在 bj，第1個用戶不在北京，依次類推。然後將多維度之間的組合轉換為 bitmap 計算：bitmap 之間做與、或、非、異或，舉例：比如在北京的用戶，且興趣是籃球，這樣的用戶有多少個，就轉換為圖中所示的兩個 bitmap 做與運算，得到橙色的 bitmap，最後，再對 bitmap 做 count 運算。count 表示統計“1”的個數，list 是列舉“1”所在的數組 index，業務上表示 userId。
2. BitBase 架構
整個 BitBase 架構包括五部分：
- 數據存儲：主要存儲兩類數據，一類數據是 bitmap 索引和數據，另一類是轉換字典的歸檔文件（見後面描述）。
- 數據轉換：有兩種方式，第一種是通過 mrjob 轉換，第二種是在線計算或導入；
- 數據計算：負責計算和調度，並把 IO 數據計算結果返回給 Client；
- Client：站在業務的角度，把它們的業務邏輯分裝成一個個業務的接口；
- ZK：整個系統是一個分佈式的服務，用 ZK 做管理。
3. 存儲模塊
用數據存儲設計的核心目的是讓計算更快。
如上圖，左邊為一天的原始數據，包括多個 table，通過 mrjob 或者 rpc 的方式轉換成中間的 bitmap。
bitmap 分為兩部分，第一部分為 meta 信息（橙色部分），第二部分是 data 信息：
- Meta 信息唯一定位一個 bitmap，db 可以認為是 hive 中的 db，table 也可以認為是 hive 中的 table，event 表示維度 (如:城市)，eventv 表示維度值 (如:bj)，entity 表示 userId（也可能是 photoId），version 表示版本。
- BitmapData 從物理上講是一個比特數組，把比特數組按照一定的大小進行切塊：b1，b2，b3，...，bn，從而實現分塊存儲，分塊計算。
最後把 bitmap 存在 HBase 的3張表中: 兩張核心表和一張輔助表。
- BitmapMeta， 保存 bitmap 的 meta 信息和一些 block 索引信息。
- BlockData， 直接保存 bitmap block 數據。
- BlockMeta，保存 block 的 meta 信息，起輔助作用。
4. 計算模塊
分享嘉賓：陳楊 快手
編輯整理：Hoh Xil
內容來源：BigData NoSQL 12th Meetup
出品社區：DataFun
注：歡迎轉載，轉載請註明出處。
快手建設 HBase 差不多有2年時間，在公司裡面有比較豐富的應用場景：如短視頻的存儲、IM、直播裡評論 feed 流等場景。本次只分享其中的一個應用場景：快手 HBase 在千億級用戶特徵數據分析中的應用與實踐。為什麼分享這個 Topic？主要原因：對於大部分公司來說，這都是一個普適的場景，因為很普遍，所以可選擇的分析引擎也非常多，但是目前直接用 HBase 這種分析用戶特徵的比較少，希望通過今天的分享，大家在將來遇到這種場景時, 可以給大家提供一個新的解決方案。
本次分享內容包括：
- 業務需求及挑戰：BitBase 引擎的初衷是什麼；
- BitBase 解決方案：在 HBase 基礎上，BitBase 的架構是什麼樣；
- 業務效果：在快手的實際應用場景中，效果如何；
- 未來規劃：中短期的規劃。
▌業務需求及挑戰
1. 業務需求
用一句話來概括業務需求：在千億級日誌中，選擇任意維度，秒級計算7-90日留存。
如上圖所示。左邊是原始數據，可能跨90天，每一天的數據可以看作是一張 Hive 寬表，在邏輯上可以認為每行數據的 rowkey 是 userId（這裡不嚴謹，userId 可能是重複的），需要通過90天的原始數據計算得到右邊的表，它的橫軸和縱軸都是日期，每個格子表示縱軸日期相對於橫軸日期的留存率。
該需求的挑戰：
- 日誌量大，千億級；
- 任意維度，如 city、sex、喜好等，需要選擇任意多個維度，在這些維度下計算留存率；
- 秒級計算，產品面向分析師，等待時間不能過長，最好在1-2秒。
2. 技術選型
面對這些問題，我們當時的技術選型：
① Hive，因為大部分數據可能是存在 Hive 裡，可以直接寫 SQL 計算，該方案不用做數據遷移和轉換，但是時延可能是分鐘到小時級別，因此否定了這個方案。
② ES，通過原始數據做倒排索引，然後做一個類似計算 UV 的方式求解，但是在數據需要做精確去重的場景下，它的耗時比較大，需要秒到分鐘級。
③ ClickHouse，ClickHouse 是一個比較合適的引擎，也是一個非常優秀的引擎，在業界被廣泛應用於 APP 分析，比如漏斗，留存。但是在我們的測試的中，當機器數量比較少時 ( <10臺 )，耗時依然在10秒以上。
立足於這種場景，是否存在其它解決方案，延遲可以做到2-3秒（複雜的場景10秒以下），同時支持任意維度組合？基於 HBase，結合業界簡單/通用的技術， 我們設計並實現了 BitBase 解決方案，用很少的資源滿足業務需求。
▌BitBase 解決方案
1. 數據模型
如上圖所示，首先將原始數據的一列的某個值抽象成 bitmap（比特數組），舉例：city=bj，city 是維度，bj (北京) 是維度值，抽象成 bitmap 值就是10100，表示第0個用戶在 bj，第1個用戶不在北京，依次類推。然後將多維度之間的組合轉換為 bitmap 計算：bitmap 之間做與、或、非、異或，舉例：比如在北京的用戶，且興趣是籃球，這樣的用戶有多少個，就轉換為圖中所示的兩個 bitmap 做與運算，得到橙色的 bitmap，最後，再對 bitmap 做 count 運算。count 表示統計“1”的個數，list 是列舉“1”所在的數組 index，業務上表示 userId。
2. BitBase 架構
整個 BitBase 架構包括五部分：
- 數據存儲：主要存儲兩類數據，一類數據是 bitmap 索引和數據，另一類是轉換字典的歸檔文件（見後面描述）。
- 數據轉換：有兩種方式，第一種是通過 mrjob 轉換，第二種是在線計算或導入；
- 數據計算：負責計算和調度，並把 IO 數據計算結果返回給 Client；
- Client：站在業務的角度，把它們的業務邏輯分裝成一個個業務的接口；
- ZK：整個系統是一個分佈式的服務，用 ZK 做管理。
3. 存儲模塊
用數據存儲設計的核心目的是讓計算更快。
如上圖，左邊為一天的原始數據，包括多個 table，通過 mrjob 或者 rpc 的方式轉換成中間的 bitmap。
bitmap 分為兩部分，第一部分為 meta 信息（橙色部分），第二部分是 data 信息：
- Meta 信息唯一定位一個 bitmap，db 可以認為是 hive 中的 db，table 也可以認為是 hive 中的 table，event 表示維度 (如:城市)，eventv 表示維度值 (如:bj)，entity 表示 userId（也可能是 photoId），version 表示版本。
- BitmapData 從物理上講是一個比特數組，把比特數組按照一定的大小進行切塊：b1，b2，b3，...，bn，從而實現分塊存儲，分塊計算。
最後把 bitmap 存在 HBase 的3張表中: 兩張核心表和一張輔助表。
- BitmapMeta， 保存 bitmap 的 meta 信息和一些 block 索引信息。
- BlockData， 直接保存 bitmap block 數據。
- BlockMeta，保存 block 的 meta 信息，起輔助作用。
4. 計算模塊
一個完整的計算流程涉及到三個組件：BitBase Client、BitBase Server 和 HBase regionServer。
① BitBase Client 首先把業務的需求封裝成計算表達式，然後把計算表達式發給 BitBase Server；
② BitBaseServe 接收到請求後，從 BitmapMeta 表中查詢 Block 索引，然後根據索引將表達式切分為 n 個子表達式；
③ 如果所有 bitmap 的 db 相同，則走 coprocessor 路由，否則按照數據親和性，將 block 計算分發到其它 bitbaseServer 中。
④ 根據第3步的調度策略，分兩條不同的路徑計算 block 表達式
⑤ BitBase Server 聚合 block 計算表達式的結果，然後返回給 BitBase Client。
兩種計算方式的對比：
- 非本地計算，解決跨 db 計算的需求，它主要的瓶頸在於網卡和 GC。
- 本地計算，解決同 db 計算的需求，它主要的瓶頸在 CPU 和 GC 上。整體上看本地計算的性能比非本地計算的性能提高3-5倍，所以要儘量採用本地計算方式。
5. DeviceId 問題
分享嘉賓：陳楊 快手
編輯整理：Hoh Xil
內容來源：BigData NoSQL 12th Meetup
出品社區：DataFun
注：歡迎轉載，轉載請註明出處。
快手建設 HBase 差不多有2年時間，在公司裡面有比較豐富的應用場景：如短視頻的存儲、IM、直播裡評論 feed 流等場景。本次只分享其中的一個應用場景：快手 HBase 在千億級用戶特徵數據分析中的應用與實踐。為什麼分享這個 Topic？主要原因：對於大部分公司來說，這都是一個普適的場景，因為很普遍，所以可選擇的分析引擎也非常多，但是目前直接用 HBase 這種分析用戶特徵的比較少，希望通過今天的分享，大家在將來遇到這種場景時, 可以給大家提供一個新的解決方案。
本次分享內容包括：
- 業務需求及挑戰：BitBase 引擎的初衷是什麼；
- BitBase 解決方案：在 HBase 基礎上，BitBase 的架構是什麼樣；
- 業務效果：在快手的實際應用場景中，效果如何；
- 未來規劃：中短期的規劃。
▌業務需求及挑戰
1. 業務需求
用一句話來概括業務需求：在千億級日誌中，選擇任意維度，秒級計算7-90日留存。
如上圖所示。左邊是原始數據，可能跨90天，每一天的數據可以看作是一張 Hive 寬表，在邏輯上可以認為每行數據的 rowkey 是 userId（這裡不嚴謹，userId 可能是重複的），需要通過90天的原始數據計算得到右邊的表，它的橫軸和縱軸都是日期，每個格子表示縱軸日期相對於橫軸日期的留存率。
該需求的挑戰：
- 日誌量大，千億級；
- 任意維度，如 city、sex、喜好等，需要選擇任意多個維度，在這些維度下計算留存率；
- 秒級計算，產品面向分析師，等待時間不能過長，最好在1-2秒。
2. 技術選型
面對這些問題，我們當時的技術選型：
① Hive，因為大部分數據可能是存在 Hive 裡，可以直接寫 SQL 計算，該方案不用做數據遷移和轉換，但是時延可能是分鐘到小時級別，因此否定了這個方案。
② ES，通過原始數據做倒排索引，然後做一個類似計算 UV 的方式求解，但是在數據需要做精確去重的場景下，它的耗時比較大，需要秒到分鐘級。
③ ClickHouse，ClickHouse 是一個比較合適的引擎，也是一個非常優秀的引擎，在業界被廣泛應用於 APP 分析，比如漏斗，留存。但是在我們的測試的中，當機器數量比較少時 ( <10臺 )，耗時依然在10秒以上。
立足於這種場景，是否存在其它解決方案，延遲可以做到2-3秒（複雜的場景10秒以下），同時支持任意維度組合？基於 HBase，結合業界簡單/通用的技術， 我們設計並實現了 BitBase 解決方案，用很少的資源滿足業務需求。
▌BitBase 解決方案
1. 數據模型
如上圖所示，首先將原始數據的一列的某個值抽象成 bitmap（比特數組），舉例：city=bj，city 是維度，bj (北京) 是維度值，抽象成 bitmap 值就是10100，表示第0個用戶在 bj，第1個用戶不在北京，依次類推。然後將多維度之間的組合轉換為 bitmap 計算：bitmap 之間做與、或、非、異或，舉例：比如在北京的用戶，且興趣是籃球，這樣的用戶有多少個，就轉換為圖中所示的兩個 bitmap 做與運算，得到橙色的 bitmap，最後，再對 bitmap 做 count 運算。count 表示統計“1”的個數，list 是列舉“1”所在的數組 index，業務上表示 userId。
2. BitBase 架構
整個 BitBase 架構包括五部分：
- 數據存儲：主要存儲兩類數據，一類數據是 bitmap 索引和數據，另一類是轉換字典的歸檔文件（見後面描述）。
- 數據轉換：有兩種方式，第一種是通過 mrjob 轉換，第二種是在線計算或導入；
- 數據計算：負責計算和調度，並把 IO 數據計算結果返回給 Client；
- Client：站在業務的角度，把它們的業務邏輯分裝成一個個業務的接口；
- ZK：整個系統是一個分佈式的服務，用 ZK 做管理。
3. 存儲模塊
用數據存儲設計的核心目的是讓計算更快。
如上圖，左邊為一天的原始數據，包括多個 table，通過 mrjob 或者 rpc 的方式轉換成中間的 bitmap。
bitmap 分為兩部分，第一部分為 meta 信息（橙色部分），第二部分是 data 信息：
- Meta 信息唯一定位一個 bitmap，db 可以認為是 hive 中的 db，table 也可以認為是 hive 中的 table，event 表示維度 (如:城市)，eventv 表示維度值 (如:bj)，entity 表示 userId（也可能是 photoId），version 表示版本。
- BitmapData 從物理上講是一個比特數組，把比特數組按照一定的大小進行切塊：b1，b2，b3，...，bn，從而實現分塊存儲，分塊計算。
最後把 bitmap 存在 HBase 的3張表中: 兩張核心表和一張輔助表。
- BitmapMeta， 保存 bitmap 的 meta 信息和一些 block 索引信息。
- BlockData， 直接保存 bitmap block 數據。
- BlockMeta，保存 block 的 meta 信息，起輔助作用。
4. 計算模塊
一個完整的計算流程涉及到三個組件：BitBase Client、BitBase Server 和 HBase regionServer。
① BitBase Client 首先把業務的需求封裝成計算表達式，然後把計算表達式發給 BitBase Server；
② BitBaseServe 接收到請求後，從 BitmapMeta 表中查詢 Block 索引，然後根據索引將表達式切分為 n 個子表達式；
③ 如果所有 bitmap 的 db 相同，則走 coprocessor 路由，否則按照數據親和性，將 block 計算分發到其它 bitbaseServer 中。
④ 根據第3步的調度策略，分兩條不同的路徑計算 block 表達式
⑤ BitBase Server 聚合 block 計算表達式的結果，然後返回給 BitBase Client。
兩種計算方式的對比：
- 非本地計算，解決跨 db 計算的需求，它主要的瓶頸在於網卡和 GC。
- 本地計算，解決同 db 計算的需求，它主要的瓶頸在 CPU 和 GC 上。整體上看本地計算的性能比非本地計算的性能提高3-5倍，所以要儘量採用本地計算方式。
5. DeviceId 問題
在引入 Bitmap 數據模型之後，我們隱含的也引入了一個非常大的問題：無法支持 deviceId。要支持 deviceId，首先需要將 deviceId 轉化為數字類型，並且轉換之後的 DeviceIdIndex 必須要滿足四個條件：
① 連續：deviceIdIndex 如果存在空洞，會降低壓縮效率，同時 Block 數量會增加，計算複雜度相應增加，最終計算變慢；
② 一致：deviceId 和 deviceIdIndex 必須是一一對應的，否則計算結果不準確；
③ 反解：根據 deviceIdIndex 能夠準確、快速地反解成原始的 deviceId；
④ 轉換快：在億級數據規模下，deviceId 轉化為 deviceIdIndex 的過程不能太長。
6. DeviceId 方案
連續、一致、支持反解：
分享嘉賓：陳楊 快手
編輯整理：Hoh Xil
內容來源：BigData NoSQL 12th Meetup
出品社區：DataFun
注：歡迎轉載，轉載請註明出處。
快手建設 HBase 差不多有2年時間，在公司裡面有比較豐富的應用場景：如短視頻的存儲、IM、直播裡評論 feed 流等場景。本次只分享其中的一個應用場景：快手 HBase 在千億級用戶特徵數據分析中的應用與實踐。為什麼分享這個 Topic？主要原因：對於大部分公司來說，這都是一個普適的場景，因為很普遍，所以可選擇的分析引擎也非常多，但是目前直接用 HBase 這種分析用戶特徵的比較少，希望通過今天的分享，大家在將來遇到這種場景時, 可以給大家提供一個新的解決方案。
本次分享內容包括：
- 業務需求及挑戰：BitBase 引擎的初衷是什麼；
- BitBase 解決方案：在 HBase 基礎上，BitBase 的架構是什麼樣；
- 業務效果：在快手的實際應用場景中，效果如何；
- 未來規劃：中短期的規劃。
▌業務需求及挑戰
1. 業務需求
用一句話來概括業務需求：在千億級日誌中，選擇任意維度，秒級計算7-90日留存。
如上圖所示。左邊是原始數據，可能跨90天，每一天的數據可以看作是一張 Hive 寬表，在邏輯上可以認為每行數據的 rowkey 是 userId（這裡不嚴謹，userId 可能是重複的），需要通過90天的原始數據計算得到右邊的表，它的橫軸和縱軸都是日期，每個格子表示縱軸日期相對於橫軸日期的留存率。
該需求的挑戰：
- 日誌量大，千億級；
- 任意維度，如 city、sex、喜好等，需要選擇任意多個維度，在這些維度下計算留存率；
- 秒級計算，產品面向分析師，等待時間不能過長，最好在1-2秒。
2. 技術選型
面對這些問題，我們當時的技術選型：
① Hive，因為大部分數據可能是存在 Hive 裡，可以直接寫 SQL 計算，該方案不用做數據遷移和轉換，但是時延可能是分鐘到小時級別，因此否定了這個方案。
② ES，通過原始數據做倒排索引，然後做一個類似計算 UV 的方式求解，但是在數據需要做精確去重的場景下，它的耗時比較大，需要秒到分鐘級。
③ ClickHouse，ClickHouse 是一個比較合適的引擎，也是一個非常優秀的引擎，在業界被廣泛應用於 APP 分析，比如漏斗，留存。但是在我們的測試的中，當機器數量比較少時 ( <10臺 )，耗時依然在10秒以上。
立足於這種場景，是否存在其它解決方案，延遲可以做到2-3秒（複雜的場景10秒以下），同時支持任意維度組合？基於 HBase，結合業界簡單/通用的技術， 我們設計並實現了 BitBase 解決方案，用很少的資源滿足業務需求。
▌BitBase 解決方案
1. 數據模型
如上圖所示，首先將原始數據的一列的某個值抽象成 bitmap（比特數組），舉例：city=bj，city 是維度，bj (北京) 是維度值，抽象成 bitmap 值就是10100，表示第0個用戶在 bj，第1個用戶不在北京，依次類推。然後將多維度之間的組合轉換為 bitmap 計算：bitmap 之間做與、或、非、異或，舉例：比如在北京的用戶，且興趣是籃球，這樣的用戶有多少個，就轉換為圖中所示的兩個 bitmap 做與運算，得到橙色的 bitmap，最後，再對 bitmap 做 count 運算。count 表示統計“1”的個數，list 是列舉“1”所在的數組 index，業務上表示 userId。
2. BitBase 架構
整個 BitBase 架構包括五部分：
- 數據存儲：主要存儲兩類數據，一類數據是 bitmap 索引和數據，另一類是轉換字典的歸檔文件（見後面描述）。
- 數據轉換：有兩種方式，第一種是通過 mrjob 轉換，第二種是在線計算或導入；
- 數據計算：負責計算和調度，並把 IO 數據計算結果返回給 Client；
- Client：站在業務的角度，把它們的業務邏輯分裝成一個個業務的接口；
- ZK：整個系統是一個分佈式的服務，用 ZK 做管理。
3. 存儲模塊
用數據存儲設計的核心目的是讓計算更快。
如上圖，左邊為一天的原始數據，包括多個 table，通過 mrjob 或者 rpc 的方式轉換成中間的 bitmap。
bitmap 分為兩部分，第一部分為 meta 信息（橙色部分），第二部分是 data 信息：
- Meta 信息唯一定位一個 bitmap，db 可以認為是 hive 中的 db，table 也可以認為是 hive 中的 table，event 表示維度 (如:城市)，eventv 表示維度值 (如:bj)，entity 表示 userId（也可能是 photoId），version 表示版本。
- BitmapData 從物理上講是一個比特數組，把比特數組按照一定的大小進行切塊：b1，b2，b3，...，bn，從而實現分塊存儲，分塊計算。
最後把 bitmap 存在 HBase 的3張表中: 兩張核心表和一張輔助表。
- BitmapMeta， 保存 bitmap 的 meta 信息和一些 block 索引信息。
- BlockData， 直接保存 bitmap block 數據。
- BlockMeta，保存 block 的 meta 信息，起輔助作用。
4. 計算模塊
一個完整的計算流程涉及到三個組件：BitBase Client、BitBase Server 和 HBase regionServer。
① BitBase Client 首先把業務的需求封裝成計算表達式，然後把計算表達式發給 BitBase Server；
② BitBaseServe 接收到請求後，從 BitmapMeta 表中查詢 Block 索引，然後根據索引將表達式切分為 n 個子表達式；
③ 如果所有 bitmap 的 db 相同，則走 coprocessor 路由，否則按照數據親和性，將 block 計算分發到其它 bitbaseServer 中。
④ 根據第3步的調度策略，分兩條不同的路徑計算 block 表達式
⑤ BitBase Server 聚合 block 計算表達式的結果，然後返回給 BitBase Client。
兩種計算方式的對比：
- 非本地計算，解決跨 db 計算的需求，它主要的瓶頸在於網卡和 GC。
- 本地計算，解決同 db 計算的需求，它主要的瓶頸在 CPU 和 GC 上。整體上看本地計算的性能比非本地計算的性能提高3-5倍，所以要儘量採用本地計算方式。
5. DeviceId 問題
在引入 Bitmap 數據模型之後，我們隱含的也引入了一個非常大的問題：無法支持 deviceId。要支持 deviceId，首先需要將 deviceId 轉化為數字類型，並且轉換之後的 DeviceIdIndex 必須要滿足四個條件：
① 連續：deviceIdIndex 如果存在空洞，會降低壓縮效率，同時 Block 數量會增加，計算複雜度相應增加，最終計算變慢；
② 一致：deviceId 和 deviceIdIndex 必須是一一對應的，否則計算結果不準確；
③ 反解：根據 deviceIdIndex 能夠準確、快速地反解成原始的 deviceId；
④ 轉換快：在億級數據規模下，deviceId 轉化為 deviceIdIndex 的過程不能太長。
6. DeviceId 方案
連續、一致、支持反解：
如何保證連續、一致、支持反解？解決方案非常簡單，利用 HBase 實現兩階段提交協議。如上圖中間實線部分所示，定義 deviceId 到 deviceIdIndex 的映射為字典。第一張表存儲字典的 meta 信息；第二張表存儲 index 到 deviceId 的映射；第三張表存儲 deviceId 到 index 的映射。
生成 Index 的過程。舉例說明, 假設我們已經生成了 1w 個 deviceId 映射，那麼此時 f:max=1w，現在將新生成 1k 條映射：
① 將 f:nextMax=f:max+1k=1.1w；
② 寫 Index 到 deviceId 的反向映射表，1k 條；
③ 寫 deviceId 到 Index 的正向映射表，1k 條；
④ 把 f:max=f:nextMax=1.1w 更新到 meta 表，生成過程結束。
如果在生成過程中出現異常或服務器宕機，則執行回滾流程：
① 如果我們檢測到 f:nextMax 不等於 f:max(f:nextMax>f:max)，則從表2中查詢 max 到 nextMax 的數據，從表3中刪掉相應的 deviceId 到 index 的映射記錄；
② 再刪掉表2中相應的 index 到 deviceId 的記錄；
③ 最後把 f:nextMax=f:max，從而實現數據100%一致。
用 HBase 實現兩階段提交協議要求 index 生成流程和回滾流程一定是單線程的，從而出現性能瓶頸，所以 BitBase 設計了歸檔流程，以支持快速轉換(見後面的描述)。Meta 表中有兩個字段，如果發現新產生的數據大於 f:archive_num 就發起歸檔，把表3中的新數據直接寫到 HDFS 中 archive_path 目錄下。
快速轉化：
分享嘉賓：陳楊 快手
編輯整理：Hoh Xil
內容來源：BigData NoSQL 12th Meetup
出品社區：DataFun
注：歡迎轉載，轉載請註明出處。
快手建設 HBase 差不多有2年時間，在公司裡面有比較豐富的應用場景：如短視頻的存儲、IM、直播裡評論 feed 流等場景。本次只分享其中的一個應用場景：快手 HBase 在千億級用戶特徵數據分析中的應用與實踐。為什麼分享這個 Topic？主要原因：對於大部分公司來說，這都是一個普適的場景，因為很普遍，所以可選擇的分析引擎也非常多，但是目前直接用 HBase 這種分析用戶特徵的比較少，希望通過今天的分享，大家在將來遇到這種場景時, 可以給大家提供一個新的解決方案。
本次分享內容包括：
- 業務需求及挑戰：BitBase 引擎的初衷是什麼；
- BitBase 解決方案：在 HBase 基礎上，BitBase 的架構是什麼樣；
- 業務效果：在快手的實際應用場景中，效果如何；
- 未來規劃：中短期的規劃。
▌業務需求及挑戰
1. 業務需求
用一句話來概括業務需求：在千億級日誌中，選擇任意維度，秒級計算7-90日留存。
如上圖所示。左邊是原始數據，可能跨90天，每一天的數據可以看作是一張 Hive 寬表，在邏輯上可以認為每行數據的 rowkey 是 userId（這裡不嚴謹，userId 可能是重複的），需要通過90天的原始數據計算得到右邊的表，它的橫軸和縱軸都是日期，每個格子表示縱軸日期相對於橫軸日期的留存率。
該需求的挑戰：
- 日誌量大，千億級；
- 任意維度，如 city、sex、喜好等，需要選擇任意多個維度，在這些維度下計算留存率；
- 秒級計算，產品面向分析師，等待時間不能過長，最好在1-2秒。
2. 技術選型
面對這些問題，我們當時的技術選型：
① Hive，因為大部分數據可能是存在 Hive 裡，可以直接寫 SQL 計算，該方案不用做數據遷移和轉換，但是時延可能是分鐘到小時級別，因此否定了這個方案。
② ES，通過原始數據做倒排索引，然後做一個類似計算 UV 的方式求解，但是在數據需要做精確去重的場景下，它的耗時比較大，需要秒到分鐘級。
③ ClickHouse，ClickHouse 是一個比較合適的引擎，也是一個非常優秀的引擎，在業界被廣泛應用於 APP 分析，比如漏斗，留存。但是在我們的測試的中，當機器數量比較少時 ( <10臺 )，耗時依然在10秒以上。
立足於這種場景，是否存在其它解決方案，延遲可以做到2-3秒（複雜的場景10秒以下），同時支持任意維度組合？基於 HBase，結合業界簡單/通用的技術， 我們設計並實現了 BitBase 解決方案，用很少的資源滿足業務需求。
▌BitBase 解決方案
1. 數據模型
如上圖所示，首先將原始數據的一列的某個值抽象成 bitmap（比特數組），舉例：city=bj，city 是維度，bj (北京) 是維度值，抽象成 bitmap 值就是10100，表示第0個用戶在 bj，第1個用戶不在北京，依次類推。然後將多維度之間的組合轉換為 bitmap 計算：bitmap 之間做與、或、非、異或，舉例：比如在北京的用戶，且興趣是籃球，這樣的用戶有多少個，就轉換為圖中所示的兩個 bitmap 做與運算，得到橙色的 bitmap，最後，再對 bitmap 做 count 運算。count 表示統計“1”的個數，list 是列舉“1”所在的數組 index，業務上表示 userId。
2. BitBase 架構
整個 BitBase 架構包括五部分：
- 數據存儲：主要存儲兩類數據，一類數據是 bitmap 索引和數據，另一類是轉換字典的歸檔文件（見後面描述）。
- 數據轉換：有兩種方式，第一種是通過 mrjob 轉換，第二種是在線計算或導入；
- 數據計算：負責計算和調度，並把 IO 數據計算結果返回給 Client；
- Client：站在業務的角度，把它們的業務邏輯分裝成一個個業務的接口；
- ZK：整個系統是一個分佈式的服務，用 ZK 做管理。
3. 存儲模塊
用數據存儲設計的核心目的是讓計算更快。
如上圖，左邊為一天的原始數據，包括多個 table，通過 mrjob 或者 rpc 的方式轉換成中間的 bitmap。
bitmap 分為兩部分，第一部分為 meta 信息（橙色部分），第二部分是 data 信息：
- Meta 信息唯一定位一個 bitmap，db 可以認為是 hive 中的 db，table 也可以認為是 hive 中的 table，event 表示維度 (如:城市)，eventv 表示維度值 (如:bj)，entity 表示 userId（也可能是 photoId），version 表示版本。
- BitmapData 從物理上講是一個比特數組，把比特數組按照一定的大小進行切塊：b1，b2，b3，...，bn，從而實現分塊存儲，分塊計算。
最後把 bitmap 存在 HBase 的3張表中: 兩張核心表和一張輔助表。
- BitmapMeta， 保存 bitmap 的 meta 信息和一些 block 索引信息。
- BlockData， 直接保存 bitmap block 數據。
- BlockMeta，保存 block 的 meta 信息，起輔助作用。
4. 計算模塊
一個完整的計算流程涉及到三個組件：BitBase Client、BitBase Server 和 HBase regionServer。
① BitBase Client 首先把業務的需求封裝成計算表達式，然後把計算表達式發給 BitBase Server；
② BitBaseServe 接收到請求後，從 BitmapMeta 表中查詢 Block 索引，然後根據索引將表達式切分為 n 個子表達式；
③ 如果所有 bitmap 的 db 相同，則走 coprocessor 路由，否則按照數據親和性，將 block 計算分發到其它 bitbaseServer 中。
④ 根據第3步的調度策略，分兩條不同的路徑計算 block 表達式
⑤ BitBase Server 聚合 block 計算表達式的結果，然後返回給 BitBase Client。
兩種計算方式的對比：
- 非本地計算，解決跨 db 計算的需求，它主要的瓶頸在於網卡和 GC。
- 本地計算，解決同 db 計算的需求，它主要的瓶頸在 CPU 和 GC 上。整體上看本地計算的性能比非本地計算的性能提高3-5倍，所以要儘量採用本地計算方式。
5. DeviceId 問題
在引入 Bitmap 數據模型之後，我們隱含的也引入了一個非常大的問題：無法支持 deviceId。要支持 deviceId，首先需要將 deviceId 轉化為數字類型，並且轉換之後的 DeviceIdIndex 必須要滿足四個條件：
① 連續：deviceIdIndex 如果存在空洞，會降低壓縮效率，同時 Block 數量會增加，計算複雜度相應增加，最終計算變慢；
② 一致：deviceId 和 deviceIdIndex 必須是一一對應的，否則計算結果不準確；
③ 反解：根據 deviceIdIndex 能夠準確、快速地反解成原始的 deviceId；
④ 轉換快：在億級數據規模下，deviceId 轉化為 deviceIdIndex 的過程不能太長。
6. DeviceId 方案
連續、一致、支持反解：
如何保證連續、一致、支持反解？解決方案非常簡單，利用 HBase 實現兩階段提交協議。如上圖中間實線部分所示，定義 deviceId 到 deviceIdIndex 的映射為字典。第一張表存儲字典的 meta 信息；第二張表存儲 index 到 deviceId 的映射；第三張表存儲 deviceId 到 index 的映射。
生成 Index 的過程。舉例說明, 假設我們已經生成了 1w 個 deviceId 映射，那麼此時 f:max=1w，現在將新生成 1k 條映射：
① 將 f:nextMax=f:max+1k=1.1w；
② 寫 Index 到 deviceId 的反向映射表，1k 條；
③ 寫 deviceId 到 Index 的正向映射表，1k 條；
④ 把 f:max=f:nextMax=1.1w 更新到 meta 表，生成過程結束。
如果在生成過程中出現異常或服務器宕機，則執行回滾流程：
① 如果我們檢測到 f:nextMax 不等於 f:max(f:nextMax>f:max)，則從表2中查詢 max 到 nextMax 的數據，從表3中刪掉相應的 deviceId 到 index 的映射記錄；
② 再刪掉表2中相應的 index 到 deviceId 的記錄；
③ 最後把 f:nextMax=f:max，從而實現數據100%一致。
用 HBase 實現兩階段提交協議要求 index 生成流程和回滾流程一定是單線程的，從而出現性能瓶頸，所以 BitBase 設計了歸檔流程，以支持快速轉換(見後面的描述)。Meta 表中有兩個字段，如果發現新產生的數據大於 f:archive_num 就發起歸檔，把表3中的新數據直接寫到 HDFS 中 archive_path 目錄下。
快速轉化：
這裡我們用到了 MRjob 中的 Join：
① 同時輸入原始數據和字典歸檔數據，在 MRjob 中根據 deviceId 做 join；
② 判斷 deviceId 是否 join 成功；
③ 如果成功了，直接寫 hdfs，這樣就得到了轉化後的數據；
④ 如果 join 失敗，直接請求單實例 BitBase Master，BitBase Master 通過兩階段提交協議生成新的映射；
⑤ 然後返回給 join task 執行替換 deviceId；
⑥ 把轉換後的數據寫入 hdfs。
反解的過程很簡單，直接多併發讀取 HBase。
▌業務效果
分享嘉賓：陳楊 快手
編輯整理：Hoh Xil
內容來源：BigData NoSQL 12th Meetup
出品社區：DataFun
注：歡迎轉載，轉載請註明出處。
快手建設 HBase 差不多有2年時間，在公司裡面有比較豐富的應用場景：如短視頻的存儲、IM、直播裡評論 feed 流等場景。本次只分享其中的一個應用場景：快手 HBase 在千億級用戶特徵數據分析中的應用與實踐。為什麼分享這個 Topic？主要原因：對於大部分公司來說，這都是一個普適的場景，因為很普遍，所以可選擇的分析引擎也非常多，但是目前直接用 HBase 這種分析用戶特徵的比較少，希望通過今天的分享，大家在將來遇到這種場景時, 可以給大家提供一個新的解決方案。
本次分享內容包括：
- 業務需求及挑戰：BitBase 引擎的初衷是什麼；
- BitBase 解決方案：在 HBase 基礎上，BitBase 的架構是什麼樣；
- 業務效果：在快手的實際應用場景中，效果如何；
- 未來規劃：中短期的規劃。
▌業務需求及挑戰
1. 業務需求
用一句話來概括業務需求：在千億級日誌中，選擇任意維度，秒級計算7-90日留存。
如上圖所示。左邊是原始數據，可能跨90天，每一天的數據可以看作是一張 Hive 寬表，在邏輯上可以認為每行數據的 rowkey 是 userId（這裡不嚴謹，userId 可能是重複的），需要通過90天的原始數據計算得到右邊的表，它的橫軸和縱軸都是日期，每個格子表示縱軸日期相對於橫軸日期的留存率。
該需求的挑戰：
- 日誌量大，千億級；
- 任意維度，如 city、sex、喜好等，需要選擇任意多個維度，在這些維度下計算留存率；
- 秒級計算，產品面向分析師，等待時間不能過長，最好在1-2秒。
2. 技術選型
面對這些問題，我們當時的技術選型：
① Hive，因為大部分數據可能是存在 Hive 裡，可以直接寫 SQL 計算，該方案不用做數據遷移和轉換，但是時延可能是分鐘到小時級別，因此否定了這個方案。
② ES，通過原始數據做倒排索引，然後做一個類似計算 UV 的方式求解，但是在數據需要做精確去重的場景下，它的耗時比較大，需要秒到分鐘級。
③ ClickHouse，ClickHouse 是一個比較合適的引擎，也是一個非常優秀的引擎，在業界被廣泛應用於 APP 分析，比如漏斗，留存。但是在我們的測試的中，當機器數量比較少時 ( <10臺 )，耗時依然在10秒以上。
立足於這種場景，是否存在其它解決方案，延遲可以做到2-3秒（複雜的場景10秒以下），同時支持任意維度組合？基於 HBase，結合業界簡單/通用的技術， 我們設計並實現了 BitBase 解決方案，用很少的資源滿足業務需求。
▌BitBase 解決方案
1. 數據模型
如上圖所示，首先將原始數據的一列的某個值抽象成 bitmap（比特數組），舉例：city=bj，city 是維度，bj (北京) 是維度值，抽象成 bitmap 值就是10100，表示第0個用戶在 bj，第1個用戶不在北京，依次類推。然後將多維度之間的組合轉換為 bitmap 計算：bitmap 之間做與、或、非、異或，舉例：比如在北京的用戶，且興趣是籃球，這樣的用戶有多少個，就轉換為圖中所示的兩個 bitmap 做與運算，得到橙色的 bitmap，最後，再對 bitmap 做 count 運算。count 表示統計“1”的個數，list 是列舉“1”所在的數組 index，業務上表示 userId。
2. BitBase 架構
整個 BitBase 架構包括五部分：
- 數據存儲：主要存儲兩類數據，一類數據是 bitmap 索引和數據，另一類是轉換字典的歸檔文件（見後面描述）。
- 數據轉換：有兩種方式，第一種是通過 mrjob 轉換，第二種是在線計算或導入；
- 數據計算：負責計算和調度，並把 IO 數據計算結果返回給 Client；
- Client：站在業務的角度，把它們的業務邏輯分裝成一個個業務的接口；
- ZK：整個系統是一個分佈式的服務，用 ZK 做管理。
3. 存儲模塊
用數據存儲設計的核心目的是讓計算更快。
如上圖，左邊為一天的原始數據，包括多個 table，通過 mrjob 或者 rpc 的方式轉換成中間的 bitmap。
bitmap 分為兩部分，第一部分為 meta 信息（橙色部分），第二部分是 data 信息：
- Meta 信息唯一定位一個 bitmap，db 可以認為是 hive 中的 db，table 也可以認為是 hive 中的 table，event 表示維度 (如:城市)，eventv 表示維度值 (如:bj)，entity 表示 userId（也可能是 photoId），version 表示版本。
- BitmapData 從物理上講是一個比特數組，把比特數組按照一定的大小進行切塊：b1，b2，b3，...，bn，從而實現分塊存儲，分塊計算。
最後把 bitmap 存在 HBase 的3張表中: 兩張核心表和一張輔助表。
- BitmapMeta， 保存 bitmap 的 meta 信息和一些 block 索引信息。
- BlockData， 直接保存 bitmap block 數據。
- BlockMeta，保存 block 的 meta 信息，起輔助作用。
4. 計算模塊
一個完整的計算流程涉及到三個組件：BitBase Client、BitBase Server 和 HBase regionServer。
① BitBase Client 首先把業務的需求封裝成計算表達式，然後把計算表達式發給 BitBase Server；
② BitBaseServe 接收到請求後，從 BitmapMeta 表中查詢 Block 索引，然後根據索引將表達式切分為 n 個子表達式；
③ 如果所有 bitmap 的 db 相同，則走 coprocessor 路由，否則按照數據親和性，將 block 計算分發到其它 bitbaseServer 中。
④ 根據第3步的調度策略，分兩條不同的路徑計算 block 表達式
⑤ BitBase Server 聚合 block 計算表達式的結果，然後返回給 BitBase Client。
兩種計算方式的對比：
- 非本地計算，解決跨 db 計算的需求，它主要的瓶頸在於網卡和 GC。
- 本地計算，解決同 db 計算的需求，它主要的瓶頸在 CPU 和 GC 上。整體上看本地計算的性能比非本地計算的性能提高3-5倍，所以要儘量採用本地計算方式。
5. DeviceId 問題
在引入 Bitmap 數據模型之後，我們隱含的也引入了一個非常大的問題：無法支持 deviceId。要支持 deviceId，首先需要將 deviceId 轉化為數字類型，並且轉換之後的 DeviceIdIndex 必須要滿足四個條件：
① 連續：deviceIdIndex 如果存在空洞，會降低壓縮效率，同時 Block 數量會增加，計算複雜度相應增加，最終計算變慢；
② 一致：deviceId 和 deviceIdIndex 必須是一一對應的，否則計算結果不準確；
③ 反解：根據 deviceIdIndex 能夠準確、快速地反解成原始的 deviceId；
④ 轉換快：在億級數據規模下，deviceId 轉化為 deviceIdIndex 的過程不能太長。
6. DeviceId 方案
連續、一致、支持反解：
如何保證連續、一致、支持反解？解決方案非常簡單，利用 HBase 實現兩階段提交協議。如上圖中間實線部分所示，定義 deviceId 到 deviceIdIndex 的映射為字典。第一張表存儲字典的 meta 信息；第二張表存儲 index 到 deviceId 的映射；第三張表存儲 deviceId 到 index 的映射。
生成 Index 的過程。舉例說明, 假設我們已經生成了 1w 個 deviceId 映射，那麼此時 f:max=1w，現在將新生成 1k 條映射：
① 將 f:nextMax=f:max+1k=1.1w；
② 寫 Index 到 deviceId 的反向映射表，1k 條；
③ 寫 deviceId 到 Index 的正向映射表，1k 條；
④ 把 f:max=f:nextMax=1.1w 更新到 meta 表，生成過程結束。
如果在生成過程中出現異常或服務器宕機，則執行回滾流程：
① 如果我們檢測到 f:nextMax 不等於 f:max(f:nextMax>f:max)，則從表2中查詢 max 到 nextMax 的數據，從表3中刪掉相應的 deviceId 到 index 的映射記錄；
② 再刪掉表2中相應的 index 到 deviceId 的記錄；
③ 最後把 f:nextMax=f:max，從而實現數據100%一致。
用 HBase 實現兩階段提交協議要求 index 生成流程和回滾流程一定是單線程的，從而出現性能瓶頸，所以 BitBase 設計了歸檔流程，以支持快速轉換(見後面的描述)。Meta 表中有兩個字段，如果發現新產生的數據大於 f:archive_num 就發起歸檔，把表3中的新數據直接寫到 HDFS 中 archive_path 目錄下。
快速轉化：
這裡我們用到了 MRjob 中的 Join：
① 同時輸入原始數據和字典歸檔數據，在 MRjob 中根據 deviceId 做 join；
② 判斷 deviceId 是否 join 成功；
③ 如果成功了，直接寫 hdfs，這樣就得到了轉化後的數據；
④ 如果 join 失敗，直接請求單實例 BitBase Master，BitBase Master 通過兩階段提交協議生成新的映射；
⑤ 然後返回給 join task 執行替換 deviceId；
⑥ 把轉換後的數據寫入 hdfs。
反解的過程很簡單，直接多併發讀取 HBase。
▌業務效果
如上圖所示，第一個圖是，2維度，不同時間跨度計算留存的時間延遲，第2個圖是15日留存在不同維度上的時延，時延並不會隨著維度的增長而增長，原因是維度越多，表達式中可能不需要計算的 block 塊也越多。
分享嘉賓：陳楊 快手
編輯整理：Hoh Xil
內容來源：BigData NoSQL 12th Meetup
出品社區：DataFun
注：歡迎轉載，轉載請註明出處。
快手建設 HBase 差不多有2年時間，在公司裡面有比較豐富的應用場景：如短視頻的存儲、IM、直播裡評論 feed 流等場景。本次只分享其中的一個應用場景：快手 HBase 在千億級用戶特徵數據分析中的應用與實踐。為什麼分享這個 Topic？主要原因：對於大部分公司來說，這都是一個普適的場景，因為很普遍，所以可選擇的分析引擎也非常多，但是目前直接用 HBase 這種分析用戶特徵的比較少，希望通過今天的分享，大家在將來遇到這種場景時, 可以給大家提供一個新的解決方案。
本次分享內容包括：
- 業務需求及挑戰：BitBase 引擎的初衷是什麼；
- BitBase 解決方案：在 HBase 基礎上，BitBase 的架構是什麼樣；
- 業務效果：在快手的實際應用場景中，效果如何；
- 未來規劃：中短期的規劃。
▌業務需求及挑戰
1. 業務需求
用一句話來概括業務需求：在千億級日誌中，選擇任意維度，秒級計算7-90日留存。
如上圖所示。左邊是原始數據，可能跨90天，每一天的數據可以看作是一張 Hive 寬表，在邏輯上可以認為每行數據的 rowkey 是 userId（這裡不嚴謹，userId 可能是重複的），需要通過90天的原始數據計算得到右邊的表，它的橫軸和縱軸都是日期，每個格子表示縱軸日期相對於橫軸日期的留存率。
該需求的挑戰：
- 日誌量大，千億級；
- 任意維度，如 city、sex、喜好等，需要選擇任意多個維度，在這些維度下計算留存率；
- 秒級計算，產品面向分析師，等待時間不能過長，最好在1-2秒。
2. 技術選型
面對這些問題，我們當時的技術選型：
① Hive，因為大部分數據可能是存在 Hive 裡，可以直接寫 SQL 計算，該方案不用做數據遷移和轉換，但是時延可能是分鐘到小時級別，因此否定了這個方案。
② ES，通過原始數據做倒排索引，然後做一個類似計算 UV 的方式求解，但是在數據需要做精確去重的場景下，它的耗時比較大，需要秒到分鐘級。
③ ClickHouse，ClickHouse 是一個比較合適的引擎，也是一個非常優秀的引擎，在業界被廣泛應用於 APP 分析，比如漏斗，留存。但是在我們的測試的中，當機器數量比較少時 ( <10臺 )，耗時依然在10秒以上。
立足於這種場景，是否存在其它解決方案，延遲可以做到2-3秒（複雜的場景10秒以下），同時支持任意維度組合？基於 HBase，結合業界簡單/通用的技術， 我們設計並實現了 BitBase 解決方案，用很少的資源滿足業務需求。
▌BitBase 解決方案
1. 數據模型
如上圖所示，首先將原始數據的一列的某個值抽象成 bitmap（比特數組），舉例：city=bj，city 是維度，bj (北京) 是維度值，抽象成 bitmap 值就是10100，表示第0個用戶在 bj，第1個用戶不在北京，依次類推。然後將多維度之間的組合轉換為 bitmap 計算：bitmap 之間做與、或、非、異或，舉例：比如在北京的用戶，且興趣是籃球，這樣的用戶有多少個，就轉換為圖中所示的兩個 bitmap 做與運算，得到橙色的 bitmap，最後，再對 bitmap 做 count 運算。count 表示統計“1”的個數，list 是列舉“1”所在的數組 index，業務上表示 userId。
2. BitBase 架構
整個 BitBase 架構包括五部分：
- 數據存儲：主要存儲兩類數據，一類數據是 bitmap 索引和數據，另一類是轉換字典的歸檔文件（見後面描述）。
- 數據轉換：有兩種方式，第一種是通過 mrjob 轉換，第二種是在線計算或導入；
- 數據計算：負責計算和調度，並把 IO 數據計算結果返回給 Client；
- Client：站在業務的角度，把它們的業務邏輯分裝成一個個業務的接口；
- ZK：整個系統是一個分佈式的服務，用 ZK 做管理。
3. 存儲模塊
用數據存儲設計的核心目的是讓計算更快。
如上圖，左邊為一天的原始數據，包括多個 table，通過 mrjob 或者 rpc 的方式轉換成中間的 bitmap。
bitmap 分為兩部分，第一部分為 meta 信息（橙色部分），第二部分是 data 信息：
- Meta 信息唯一定位一個 bitmap，db 可以認為是 hive 中的 db，table 也可以認為是 hive 中的 table，event 表示維度 (如:城市)，eventv 表示維度值 (如:bj)，entity 表示 userId（也可能是 photoId），version 表示版本。
- BitmapData 從物理上講是一個比特數組，把比特數組按照一定的大小進行切塊：b1，b2，b3，...，bn，從而實現分塊存儲，分塊計算。
最後把 bitmap 存在 HBase 的3張表中: 兩張核心表和一張輔助表。
- BitmapMeta， 保存 bitmap 的 meta 信息和一些 block 索引信息。
- BlockData， 直接保存 bitmap block 數據。
- BlockMeta，保存 block 的 meta 信息，起輔助作用。
4. 計算模塊
一個完整的計算流程涉及到三個組件：BitBase Client、BitBase Server 和 HBase regionServer。
① BitBase Client 首先把業務的需求封裝成計算表達式，然後把計算表達式發給 BitBase Server；
② BitBaseServe 接收到請求後，從 BitmapMeta 表中查詢 Block 索引，然後根據索引將表達式切分為 n 個子表達式；
③ 如果所有 bitmap 的 db 相同，則走 coprocessor 路由，否則按照數據親和性，將 block 計算分發到其它 bitbaseServer 中。
④ 根據第3步的調度策略，分兩條不同的路徑計算 block 表達式
⑤ BitBase Server 聚合 block 計算表達式的結果，然後返回給 BitBase Client。
兩種計算方式的對比：
- 非本地計算，解決跨 db 計算的需求，它主要的瓶頸在於網卡和 GC。
- 本地計算，解決同 db 計算的需求，它主要的瓶頸在 CPU 和 GC 上。整體上看本地計算的性能比非本地計算的性能提高3-5倍，所以要儘量採用本地計算方式。
5. DeviceId 問題
在引入 Bitmap 數據模型之後，我們隱含的也引入了一個非常大的問題：無法支持 deviceId。要支持 deviceId，首先需要將 deviceId 轉化為數字類型，並且轉換之後的 DeviceIdIndex 必須要滿足四個條件：
① 連續：deviceIdIndex 如果存在空洞，會降低壓縮效率，同時 Block 數量會增加，計算複雜度相應增加，最終計算變慢；
② 一致：deviceId 和 deviceIdIndex 必須是一一對應的，否則計算結果不準確；
③ 反解：根據 deviceIdIndex 能夠準確、快速地反解成原始的 deviceId；
④ 轉換快：在億級數據規模下，deviceId 轉化為 deviceIdIndex 的過程不能太長。
6. DeviceId 方案
連續、一致、支持反解：
如何保證連續、一致、支持反解？解決方案非常簡單，利用 HBase 實現兩階段提交協議。如上圖中間實線部分所示，定義 deviceId 到 deviceIdIndex 的映射為字典。第一張表存儲字典的 meta 信息；第二張表存儲 index 到 deviceId 的映射；第三張表存儲 deviceId 到 index 的映射。
生成 Index 的過程。舉例說明, 假設我們已經生成了 1w 個 deviceId 映射，那麼此時 f:max=1w，現在將新生成 1k 條映射：
① 將 f:nextMax=f:max+1k=1.1w；
② 寫 Index 到 deviceId 的反向映射表，1k 條；
③ 寫 deviceId 到 Index 的正向映射表，1k 條；
④ 把 f:max=f:nextMax=1.1w 更新到 meta 表，生成過程結束。
如果在生成過程中出現異常或服務器宕機，則執行回滾流程：
① 如果我們檢測到 f:nextMax 不等於 f:max(f:nextMax>f:max)，則從表2中查詢 max 到 nextMax 的數據，從表3中刪掉相應的 deviceId 到 index 的映射記錄；
② 再刪掉表2中相應的 index 到 deviceId 的記錄；
③ 最後把 f:nextMax=f:max，從而實現數據100%一致。
用 HBase 實現兩階段提交協議要求 index 生成流程和回滾流程一定是單線程的，從而出現性能瓶頸，所以 BitBase 設計了歸檔流程，以支持快速轉換(見後面的描述)。Meta 表中有兩個字段，如果發現新產生的數據大於 f:archive_num 就發起歸檔，把表3中的新數據直接寫到 HDFS 中 archive_path 目錄下。
快速轉化：
這裡我們用到了 MRjob 中的 Join：
① 同時輸入原始數據和字典歸檔數據，在 MRjob 中根據 deviceId 做 join；
② 判斷 deviceId 是否 join 成功；
③ 如果成功了，直接寫 hdfs，這樣就得到了轉化後的數據；
④ 如果 join 失敗，直接請求單實例 BitBase Master，BitBase Master 通過兩階段提交協議生成新的映射；
⑤ 然後返回給 join task 執行替換 deviceId；
⑥ 把轉換後的數據寫入 hdfs。
反解的過程很簡單，直接多併發讀取 HBase。
▌業務效果
如上圖所示，第一個圖是，2維度，不同時間跨度計算留存的時間延遲，第2個圖是15日留存在不同維度上的時延，時延並不會隨著維度的增長而增長，原因是維度越多，表達式中可能不需要計算的 block 塊也越多。
如上圖所示，BitBase 可以應用在 app 分析，用戶增長，廣告 DMP，用戶畫像等多個業務場景中。
▌未來規劃
分享嘉賓：陳楊 快手
編輯整理：Hoh Xil
內容來源：BigData NoSQL 12th Meetup
出品社區：DataFun
注：歡迎轉載，轉載請註明出處。
快手建設 HBase 差不多有2年時間，在公司裡面有比較豐富的應用場景：如短視頻的存儲、IM、直播裡評論 feed 流等場景。本次只分享其中的一個應用場景：快手 HBase 在千億級用戶特徵數據分析中的應用與實踐。為什麼分享這個 Topic？主要原因：對於大部分公司來說，這都是一個普適的場景，因為很普遍，所以可選擇的分析引擎也非常多，但是目前直接用 HBase 這種分析用戶特徵的比較少，希望通過今天的分享，大家在將來遇到這種場景時, 可以給大家提供一個新的解決方案。
本次分享內容包括：
- 業務需求及挑戰：BitBase 引擎的初衷是什麼；
- BitBase 解決方案：在 HBase 基礎上，BitBase 的架構是什麼樣；
- 業務效果：在快手的實際應用場景中，效果如何；
- 未來規劃：中短期的規劃。
▌業務需求及挑戰
1. 業務需求
用一句話來概括業務需求：在千億級日誌中，選擇任意維度，秒級計算7-90日留存。
如上圖所示。左邊是原始數據，可能跨90天，每一天的數據可以看作是一張 Hive 寬表，在邏輯上可以認為每行數據的 rowkey 是 userId（這裡不嚴謹，userId 可能是重複的），需要通過90天的原始數據計算得到右邊的表，它的橫軸和縱軸都是日期，每個格子表示縱軸日期相對於橫軸日期的留存率。
該需求的挑戰：
- 日誌量大，千億級；
- 任意維度，如 city、sex、喜好等，需要選擇任意多個維度，在這些維度下計算留存率；
- 秒級計算，產品面向分析師，等待時間不能過長，最好在1-2秒。
2. 技術選型
面對這些問題，我們當時的技術選型：
① Hive，因為大部分數據可能是存在 Hive 裡，可以直接寫 SQL 計算，該方案不用做數據遷移和轉換，但是時延可能是分鐘到小時級別，因此否定了這個方案。
② ES，通過原始數據做倒排索引，然後做一個類似計算 UV 的方式求解，但是在數據需要做精確去重的場景下，它的耗時比較大，需要秒到分鐘級。
③ ClickHouse，ClickHouse 是一個比較合適的引擎，也是一個非常優秀的引擎，在業界被廣泛應用於 APP 分析，比如漏斗，留存。但是在我們的測試的中，當機器數量比較少時 ( <10臺 )，耗時依然在10秒以上。
立足於這種場景，是否存在其它解決方案，延遲可以做到2-3秒（複雜的場景10秒以下），同時支持任意維度組合？基於 HBase，結合業界簡單/通用的技術， 我們設計並實現了 BitBase 解決方案，用很少的資源滿足業務需求。
▌BitBase 解決方案
1. 數據模型
如上圖所示，首先將原始數據的一列的某個值抽象成 bitmap（比特數組），舉例：city=bj，city 是維度，bj (北京) 是維度值，抽象成 bitmap 值就是10100，表示第0個用戶在 bj，第1個用戶不在北京，依次類推。然後將多維度之間的組合轉換為 bitmap 計算：bitmap 之間做與、或、非、異或，舉例：比如在北京的用戶，且興趣是籃球，這樣的用戶有多少個，就轉換為圖中所示的兩個 bitmap 做與運算，得到橙色的 bitmap，最後，再對 bitmap 做 count 運算。count 表示統計“1”的個數，list 是列舉“1”所在的數組 index，業務上表示 userId。
2. BitBase 架構
整個 BitBase 架構包括五部分：
- 數據存儲：主要存儲兩類數據，一類數據是 bitmap 索引和數據，另一類是轉換字典的歸檔文件（見後面描述）。
- 數據轉換：有兩種方式，第一種是通過 mrjob 轉換，第二種是在線計算或導入；
- 數據計算：負責計算和調度，並把 IO 數據計算結果返回給 Client；
- Client：站在業務的角度，把它們的業務邏輯分裝成一個個業務的接口；
- ZK：整個系統是一個分佈式的服務，用 ZK 做管理。
3. 存儲模塊
用數據存儲設計的核心目的是讓計算更快。
如上圖，左邊為一天的原始數據，包括多個 table，通過 mrjob 或者 rpc 的方式轉換成中間的 bitmap。
bitmap 分為兩部分，第一部分為 meta 信息（橙色部分），第二部分是 data 信息：
- Meta 信息唯一定位一個 bitmap，db 可以認為是 hive 中的 db，table 也可以認為是 hive 中的 table，event 表示維度 (如:城市)，eventv 表示維度值 (如:bj)，entity 表示 userId（也可能是 photoId），version 表示版本。
- BitmapData 從物理上講是一個比特數組，把比特數組按照一定的大小進行切塊：b1，b2，b3，...，bn，從而實現分塊存儲，分塊計算。
最後把 bitmap 存在 HBase 的3張表中: 兩張核心表和一張輔助表。
- BitmapMeta， 保存 bitmap 的 meta 信息和一些 block 索引信息。
- BlockData， 直接保存 bitmap block 數據。
- BlockMeta，保存 block 的 meta 信息，起輔助作用。
4. 計算模塊
一個完整的計算流程涉及到三個組件：BitBase Client、BitBase Server 和 HBase regionServer。
① BitBase Client 首先把業務的需求封裝成計算表達式，然後把計算表達式發給 BitBase Server；
② BitBaseServe 接收到請求後，從 BitmapMeta 表中查詢 Block 索引，然後根據索引將表達式切分為 n 個子表達式；
③ 如果所有 bitmap 的 db 相同，則走 coprocessor 路由，否則按照數據親和性，將 block 計算分發到其它 bitbaseServer 中。
④ 根據第3步的調度策略，分兩條不同的路徑計算 block 表達式
⑤ BitBase Server 聚合 block 計算表達式的結果，然後返回給 BitBase Client。
兩種計算方式的對比：
- 非本地計算，解決跨 db 計算的需求，它主要的瓶頸在於網卡和 GC。
- 本地計算，解決同 db 計算的需求，它主要的瓶頸在 CPU 和 GC 上。整體上看本地計算的性能比非本地計算的性能提高3-5倍，所以要儘量採用本地計算方式。
5. DeviceId 問題
在引入 Bitmap 數據模型之後，我們隱含的也引入了一個非常大的問題：無法支持 deviceId。要支持 deviceId，首先需要將 deviceId 轉化為數字類型，並且轉換之後的 DeviceIdIndex 必須要滿足四個條件：
① 連續：deviceIdIndex 如果存在空洞，會降低壓縮效率，同時 Block 數量會增加，計算複雜度相應增加，最終計算變慢；
② 一致：deviceId 和 deviceIdIndex 必須是一一對應的，否則計算結果不準確；
③ 反解：根據 deviceIdIndex 能夠準確、快速地反解成原始的 deviceId；
④ 轉換快：在億級數據規模下，deviceId 轉化為 deviceIdIndex 的過程不能太長。
6. DeviceId 方案
連續、一致、支持反解：
如何保證連續、一致、支持反解？解決方案非常簡單，利用 HBase 實現兩階段提交協議。如上圖中間實線部分所示，定義 deviceId 到 deviceIdIndex 的映射為字典。第一張表存儲字典的 meta 信息；第二張表存儲 index 到 deviceId 的映射；第三張表存儲 deviceId 到 index 的映射。
生成 Index 的過程。舉例說明, 假設我們已經生成了 1w 個 deviceId 映射，那麼此時 f:max=1w，現在將新生成 1k 條映射：
① 將 f:nextMax=f:max+1k=1.1w；
② 寫 Index 到 deviceId 的反向映射表，1k 條；
③ 寫 deviceId 到 Index 的正向映射表，1k 條；
④ 把 f:max=f:nextMax=1.1w 更新到 meta 表，生成過程結束。
如果在生成過程中出現異常或服務器宕機，則執行回滾流程：
① 如果我們檢測到 f:nextMax 不等於 f:max(f:nextMax>f:max)，則從表2中查詢 max 到 nextMax 的數據，從表3中刪掉相應的 deviceId 到 index 的映射記錄；
② 再刪掉表2中相應的 index 到 deviceId 的記錄；
③ 最後把 f:nextMax=f:max，從而實現數據100%一致。
用 HBase 實現兩階段提交協議要求 index 生成流程和回滾流程一定是單線程的，從而出現性能瓶頸，所以 BitBase 設計了歸檔流程，以支持快速轉換(見後面的描述)。Meta 表中有兩個字段，如果發現新產生的數據大於 f:archive_num 就發起歸檔，把表3中的新數據直接寫到 HDFS 中 archive_path 目錄下。
快速轉化：
這裡我們用到了 MRjob 中的 Join：
① 同時輸入原始數據和字典歸檔數據，在 MRjob 中根據 deviceId 做 join；
② 判斷 deviceId 是否 join 成功；
③ 如果成功了，直接寫 hdfs，這樣就得到了轉化後的數據；
④ 如果 join 失敗，直接請求單實例 BitBase Master，BitBase Master 通過兩階段提交協議生成新的映射；
⑤ 然後返回給 join task 執行替換 deviceId；
⑥ 把轉換後的數據寫入 hdfs。
反解的過程很簡單，直接多併發讀取 HBase。
▌業務效果
如上圖所示，第一個圖是，2維度，不同時間跨度計算留存的時間延遲，第2個圖是15日留存在不同維度上的時延，時延並不會隨著維度的增長而增長，原因是維度越多，表達式中可能不需要計算的 block 塊也越多。
如上圖所示，BitBase 可以應用在 app 分析，用戶增長，廣告 DMP，用戶畫像等多個業務場景中。
▌未來規劃
根據現在面臨的業務場景，BitBase 後續會在多個方面做優化。支持實時聚合，在一些業務場景下，如運營效果監測，導入時效需要 <5min，BitBase 需要支持實時聚合；支持 SQL 查詢，目前只支持 api 的接入方式，在一些簡單場景下比較複雜；開源，希望通過開源，和大家一起挖掘 BitBase 的業務場景。
相關推薦
