作者：陳璐，騰訊 CSIG 高級數據分析師

　　本文實踐了對于千萬級别的用戶，操作總數達萬級别，每日幾十億操作流水的留存分析工具秒級别查詢的數據構建方案。同時，除了留存分析，對于用戶群分析，事件分析等也可以嘗試用此方案來解決。

　　背景 你可能聽說過Growingio、神策等數據分析平台，本文主要介紹實現留存分析工具相關的内容。

　　留存分析是一種用來分析用戶參與情況/活躍程度的分析模型，可考查進行初始行為後的用戶中，有多少人會進行後續行為，這是衡量産品對用戶價值高低的重要指标。如，為評估産品更新效果或渠道推廣效果，我們常常需要對同期進入産品或同期使用了産品某個功能的用戶的後續行為表現進行評估 [1]。大部分數據分析平台主要包括如圖的幾個功能（以神策為例）：

　　本文主要介紹留存分析工具的優化方案（隻涉及數據存儲和查詢的方案設計，不涉及平台）。

　　我想每個數據/産品同學在以往的取數分析過程中，都曾有一個痛點，就是每次查詢留存相關的數據時，都要等到天荒地老，慢！而最近采用優化方案的目的也是為了提高查詢的效率和減少數據的存儲，可以幫助産品快速地查詢/分析留存相關的數據。

　　優化方案的核心是在Clickhouse中使用Roaringbitmap對用戶進行壓縮，将留存率的計算交給高效率的位圖函數，這樣既省空間又可以提高查詢速度。

　　希望本實踐方案可以給你帶來一些幫助和啟示。下面主要分3個部分詳細介紹：Roaringbitmap簡介、思路與實現、總結與思考。

　　Roaringbitmap簡介 下面先簡單介紹一下高效的位圖壓縮方法Roaringbitmap。先來看一個問題:

　　給定含有40億個不重複的位于[0,2^32-1]區間内的整數集合，如何快速判定某個數是否在該集合内？

　　顯然，如果我們将這40億個數原樣存儲下來，需要耗費高達14.9GB的内存，這是難以接受的。所以我們可以用位圖(bitmap)來存儲，即第0個比特表示數字0，第1個比特表示數字1，以此類推。如果某個數位于原集合内，就将它對應的位圖内的比特置為1，否則保持為0，這樣就能很方便地查詢得出結果了，僅僅需要占用512MB的内存，不到原來的3.4% [3]。但是這種方式也有缺點：比如我需要将1~5000w這5000w個連續的整數存儲起來，用普通的bitmap同樣需要消耗512M的存儲，顯然，對于這種情況其實有很大的優化空間。

　　2016年由S. Chambi、D. Lemire、O. Kaser等人在論文《Better bitmap performance with Roaring bitmaps》與《Consistently faster and smaller compressed bitmaps with Roaring》中提出了roaringbitmap，主要特點就是可以極大程度地節約存儲及提供了快速的位圖計算，因此考慮用它來做優化。對于前文提及的存儲連續的5000w個整數，隻需要幾十KB。

　　它的主要思路是：将32位無符号整數按照高16位分桶，即最多可能有2^16 =65536個桶，論文内稱為container。存儲數據時，按照數據的高16位找到container（找不到就會新建一個），再将低16位放入container中。也就是說，一個roaringbitmap就是很多container的集合 [3]，具體細節可以自行查看文末的參考文章 。

　　思路與實現 我們的原始數據主要分為：

　　1.用戶操作行為數據table_oper_raw 包括時間分區(ds)、用戶标識id(user_id)和用戶操作行為名稱(oper_name)，如：20200701|6053002|點擊首頁banner 表示用戶6053002在20200701這天點擊了首頁banner（同一天中同一個用戶多次操作了同一個行為隻保留一條）。實踐過程中，此表每日記錄數達幾十億行。2.用戶屬性數據table_attribute_raw 表示用戶在産品/畫像中的屬性，包括時間分區(ds)、用戶标識(user_id)及各種用戶屬性字段（可能是用戶的新進渠道、所在省份等），如20200701|6053002|小米商店|廣東省。實踐過程中，此表每日有千萬級的用戶數，測試屬性在20 個。 現在我們需要根據這兩類數據，求出某天操作了某個行為的用戶在後續的某一天操作了另一個行為的留存率，比如，在20200701這天操作了“點擊banner”的用戶有100個，這部分用戶在20200702這天操作了“點擊app簽到”的有20個，那麼對于分析時間是20200701，且“點擊banner”的用戶在次日“點擊app簽到”的留存率是20%。同時，還需要考慮利用用戶屬性對留存比例進行區分，例如隻考慮廣東省的用戶的留存率，或者隻考慮小米商店用戶的留存率，或者在廣東的小米商店的用戶的留存率等等。

　　一般來說，求留存率的做法就是兩天的用戶求交集，例如前文說到的情況，就是先獲取出20200701的所有操作了“點擊banner”的用戶标識id集合假設為S1，然後獲取20200702的所有操作了“點擊app簽到”的用戶标識id集合假設為S2，最後求解S1和S2的交集：

　　可以看到，當s1和s2的集合中用戶數都比較大的時候，join的速度會比較慢。

　　在此我們考慮前文說到的bitmap，假若每一個用戶都可以表示成一個32位的無符号整型，用bitmap的形式去存儲，S1和S2的求交過程就是直接的一個位比較過程，這樣速度會得到巨大的提升。而Roaringbitmap對數據進行了壓縮，其求交的速度在絕大部分情況下比bitmap還要快，因此這裡我們考慮使用Roaringbitmap的方法來對計算留存的過程進行優化。

　　1.數據構建

　　整個過程主要是：首先對初始的兩張表——用戶操作數據表table_oper_raw和用戶篩選維度數據表table_attribute_raw中的user_id字段進行編碼，将每個用戶映射成唯一的id（32位的無符号整型），分别得到兩個新表table_oper_middle和table_attribute_middle。再将他們導入clickhouse，使用roaringbitmap的方法對用戶進行壓縮存儲，最後得到壓縮後的兩張表table_oper_bit和table_attribute_bit，即為最終的查詢表。流程圖如下：

　　(1).生成用戶id映射表 首先，需要構建一個映射表table_user_map，包含時間分區(ds)、用戶标識id(user_d)及映射後的id(id)，它将每個用戶(String類型)映射成一個32位的無符号整型。這裡我們從1開始編碼，這樣每個用戶的标識就轉化成了指定的一個數字。(2).初始數據轉化 分别将用戶操作數據表和用戶篩選維度數據中的imei字段替換成對應的數值，生成編碼後的用戶操作數據:和用戶篩選維度數據:(3).導入clickhouse 首先在clickhouse中創建相同結構的表，如table_oper_middle_ch。

　　同 樣的，在clickhouse中 創建表table_attribute_middle_ch。 然後用spark将這兩份數據分别導入這 兩張表。 這一步導入很快，幾十億的數據大概10分多鐘 就可以完成。

　　(4).Roaringbitmap壓縮 對于用戶操作流水數據，我們先建一個可以存放bitmap的表table_oper_bit，建表語句如下：用戶屬性數據table_attribute_bit也類似：這裡索引粒度可設置小值，接着用聚合函數groupBitmapState對用戶id進行壓縮：這樣，對于用戶操作數據表，原本幾十億的數據就壓縮成了幾萬行的數據，每行包括操作名稱和對應的用戶id形成的bitmap：同樣的，用戶屬性的數據也可以這樣處理，得到table_attribute_bit表，每行包括某個屬性的某個屬性值對應的用戶的id形成的bitmap：至此，數據壓縮的過程就這樣完成了。2. 查詢過程 首先，簡要地介紹下方案中常用的bitmap函數（詳細見文末的參考資料）：

　　1.bitmapCardinality 返回一個UInt64類型的數值，表示bitmap對象的基數。用來計算不同條件下的用戶數，可以粗略理解為count(distinct)

　　2.bitmapAnd 為兩個bitmap對象進行與操作，返回一個新的bitmap對象。可以理解為用來滿足兩個條件之間的and，但是參數隻能是兩個bitmap

　　3.bitmapOr 為兩個bitmap對象進行或操作，返回一個新的bitmap對象。可以理解為用來滿足兩個條件之間的or，但是參數也同樣隻能是兩個bitmap。如果是多個的情況，可以嘗試使用groupBitmapMergeState

　　舉例來說，假設20200701這天隻有[1,2,3,5,8]這5個用戶點擊了banner，則有：

　　# 返回5

　　select bitmapCardinality ( user_bit )

　　from tddb . table_oper_bit

　　where ds = 20200701 AND oper_name =

　　點擊banner

　　又如果20200701從小米商店新進的用戶是[1,3,8,111,2000,100000]，則有：

　　# 返回3,因為兩者的重合用戶隻有1,3,8這3個用戶

　　select bitmapCardinality ( bitmapAnd (

　　( SELECT user_bit

　　FROM tddb . table_oper_bit

　　WHERE ( ds = 20200701 ) AND ( oper_name = 點擊banner )),

　　( SELECT user_bit

　　FROM tddb . table_attribute_bit

　　WHERE ds = 20200701 and ( attr_id = first_channel ) and ( attr_value IN ( 小米商店

　　)))))

　　有了以上的數據生成過程和bitmap函數，我們就可以根據不同的條件使用不同的位圖函數來快速查詢，具體來說，主要是以下幾種情況：

　　a. 操作了某個行為的用戶在後續某一天操作了另一個行為的留存：如“20200701點擊了banner的用戶在次日點擊app簽到的留存人數”，就可以用以下的sql快速求解:b. 操作了某個行為并且帶有某個屬性的用戶在後續的某一天操作了另一個行為的留存：如“20200701點擊了banner且來自廣東/江西/河南的用戶在次日點擊app簽到的留存人數”：c. 操作了某個行為并且帶有某幾個屬性的用戶在後續的某一天操作了另一個行為的留存：如“20200701點擊了banner、來自廣東且新進渠道是小米商店的用戶在次日點擊app簽到的留存人數”： 3. 實踐效果

　　根據這套方案做了實踐，對每日按時間分區、用戶、操作名稱去重後包括幾十億的操作記錄，其中包含千萬級别的用戶數，萬級别的操作數。最後實現了：

　　存儲 原本每日幾十G的操作流水數據經壓縮後得到的表table_oper_bit為4GB左右/天。而用戶屬性表table_attribute_bit為500MB左右/天查詢速度 clickhouse集群現狀：12核125G内存機器10台。clickhouse版本:20.4.7.67。查詢的表都存放在其中一台機器上。測試了查詢在20200701操作了行為oper_name_1(用戶數量級為3000 w)的用戶在後續7天内每天操作了另一個行為oper_name_2(用戶數量級為2700 w)的留存數據(用戶重合度在1000w以上)，耗時0.2秒左右反饋 最後和前端打通，效果也是有了明顯的優化，麻麻再也不用擔心我會轉暈~總結與思考 總的來說，本方案的優點是：

　　存儲小，極大地節約了存儲；查詢快，利用bitmapCardinality、bitmapAnd、bitmapOr等位圖函數快速計算用戶數和滿足一些條件的查詢，将緩慢的join操作轉化成位圖間的計算；适用于靈活天數的留存查詢；便于更新，用戶操作數據和用戶屬性數據分開存儲，便于後續屬性的增加和數據回滾。 另外，根據本方案的特點，除了留存分析工具，對于用戶群分析，事件分析等工具也可以嘗試用此方案來解決。

　　PS : 作者初入坑ch，對于以上内容，有不正确/不嚴謹之處請輕拍~ 歡迎交流~

　　參考文獻： [1] 解析常見的數據分析模型——留存分析：htt

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!