【遇見 Doris】基于Doris建構的小程式私域流量增長

作者：趙煜楊 百度資深研發工程師 負責手百小程式資料産品工程架構

百度雲資料倉庫Doris是一款基于Apache Doris（百度自研分析型資料庫引擎）建構的企業級MPP雲資料倉庫。全面相容MySQL協定，提供快捷查詢UI，支援高并發低延時，支援PB級以上的超大資料集，可有效地支援線上實時資料分析。

現有新使用者免費試用3個月優惠活動，詳情請看：https://cloud.baidu.com/product/palo.html

本次分享大綱如下：

1. 小程式私域精細化營運能力介紹
2. 使用者分層技術難點
3. 使用者分層的架構和解決方案
4. 未來規劃

小程式目前使用百度雲 Palo（Apache Doris 企業版）承載其精細化營運業務。通過本文可以幫助大家了解在 Doris 中使用全局字典、BITMAP 等功能時遇到的問題、解決思路和優化方案。

1 小程式私域精細化營運能力介紹

1.1 能力介紹

首先，我們做私域精細化營運是因為兩個痛點

1. 私域使用者價值不突出。比如，我是個目前有100萬使用者的開發者，想推一款奢侈品包包給使用者裡面的高收入人群。但是我不知道這100萬人中，有多少人是高收入人群，是很難将他們找出來的。
2. 缺乏主動觸達能力，也就是觸達通路比較少。

針對這兩個問題，我們産品上提出了一個解決方案——分層營運。

分層營運分成兩部分，營運觸達和精細化人群。

如圖所示，從上往下看，比如我現在要推一個活動，營運同學會在消息、私信、卡券和小程式内這四個通路中選擇一個進行推送。選完通路之後，就要選擇人群。

精細化人群篩選是基于百度的大資料平台提供的畫像資料和行為資料去篩選特定的人群。

整個流程完成之後，我們會提供一個觸達效果的分析（主要包括下發量，點展和到達分析等），和一個群體分析（對整個使用者群的更細緻化的分析）。

從收益和價值上來看

對于開發者：

• 合理利用私域流量，提升資源價值
• 促進使用者活躍和轉換

對于整個生态:

• 提高私域池使用率和活躍度
• 激活開發者主動經營意願
• 促進生态良性循環

以上主要講了整個産品的方案，下面講一下具體的功能。

1.2 分層營運——B端視角

作為開發者，我要如何去建立使用者分分層？

入口在小程式開發者背景——營運中心——分層營運——分層管理——自定義篩選。

點選自定義篩選後會進入自定義篩選頁面，在這個頁面使用者可以選擇關注行為、卡券行為、交易行為等次元。

選擇完成之後，可以使用“預估人數”功能，實時計算一下圈選的人群人數有多少，如果覺得所選的人群人數比較合适就點選“生成人群”。

生成人群之後将會進入分層管理清單，在這裡可以發送消息或私信，還可以進行群體分析。

1.3 分層營運——C端視角

下圖是從C端視角來分層營運的功能，這裡截取了百度App的通知和私信的樣式。

1.4 分層營運經典案例

百度App在跟汽車大師合作的時候，汽車大師選擇近一周付費且活躍使用者開展“評價送券”活動。

如圖所示，使用場景是在百度App中向使用者推送一個通知，使用者在“我的”裡面打開，填寫評價之後可以領券。

這次活動的效果是：

• 準确判斷使用者需求，活躍使用者具有較高價值，頁面打開率達9.51%
• 使用者次均使用時長提升2.5倍
• 活動帶來新增付費轉化率達17.71%

這裡面有幾個營運技巧：

• 結合實際業務場景，無中間頁跳轉折損
• 拼接消息元件，自動發券場景過渡順滑
• 場景可定期複用，節省人力成本。也就是建立完人群之後，可以一直使用這個人群。
• “分享+使用”雙按鈕強勢引導

從上面分享給大家的案例可以看出，私域流量的使用者分層營運其實可以給開發者帶來營運效率和轉化效果的提升，進而促進使用者增長。

但是實作起來有很大的技術難點。

2 使用者分層難點

難點主要有四個：

首先，TB級資料，資料量特别大。我們基于畫像和行為做使用者分層，每天的資料量大概有1T+。

第二，查詢的頻響要求極高，要求毫秒到秒級的響應時間。比如剛剛提到的“預估人數”的功能，使用者在點選之後，我們需要在毫秒到秒的時間内，從TB級的資料中計算這個標明的人群數量結果。

第三，計算複雜，需要動态靜态組合查詢。很多元度的資料無法進行預聚合，必須要實時計算明細資料，是以計算是很複雜的，這點後面會詳細展開。

第四，産出使用者包要求實效性高。

針對上面的四個難點，我們的方法論如下：

難點1: 壓縮存儲，降低查詢數量級，選擇使用Bitmap存儲。無論目前市場上主流的OLAP引擎有多厲害，資料量越大，查詢速度就一定越慢，是以我們要降低存儲。

難點2、3: 我們調研了目前開源主流OLAP引擎ClickHouse, Doris, Druid等，最後選擇使用基于MPP架構的OLAP引擎Doris。在性能上其實ClickHouse, Doris, Druid都差不多。但是Doris有幾個優點，第一，Doris相容MySQL協定，學習成本非常低，基本上RD都會用。第二，Doris的運維成本很低，基本上是自動化運維，是以我們最後選擇了Doris。

難點4: 我們調研對比了spark，Doris 性能，最終也是選擇使用基于MPP架構的OLAP引擎Doris，這點在後面會詳細講。

3 使用者分層的架構和解決方案

下面我将會從架構和解決方案上講解上面這些難點是如何解決的。

3.1 分層營運架構

首先介紹一下分層營運的架構，分為線上部分和離線部分。

線上部分分為四層，服務層、解析層、計算層和存儲層，還有一個排程平台和一個監控平台。

服務層包含了權限控制（使用者權限和接口權限），分層管理（是對使用者篩選分層的增删改查的管理），中繼資料管理（對頁面元素和ID Mapping的管理）和任務管理（對排程平台任務的增删改查的管理）

解析層主要是對DSL的解析。比如，使用者要線上預估人數。走到解析層時，首先要進行DSL解析。然後對DSL優化，比如我想找到近7天活躍的使用者和近7天不活躍的使用者求一個交集，顯然結果是0，那麼在優化層被優化掉，返還給使用者結果為0，不會再往下走到計算引擎。優化之後會有DSL路由，這個路由的功能主要是判斷查詢的次元，路由到SQL模版進行模版的拼接。

計算引擎層主要有Spark和Doris。Spark主要用來做離線任務的計算，Doris用來做實時計算。

存儲層有MySQL（用來存使用者分層的資訊），Redis（主要用來緩存），Doris（存畫像資料和行為資料）和afs（存産出的使用者包資訊）。

排程平台用來管理離線任務的排程，監控平台用來對整體服務穩定性監控。

離線部分主要是對需要的資料源，比如畫像、關注、行為等資料進行ETL清洗，然後做一個全局字典，完成之後會寫入Doris。

在産出使用者包之後，會分發給小程式B端和百度統計。小程式B端會将消息推送到這些使用者的手機端；百度統計會用這個使用者包做群體分析。

以上就是整體的架構，圖中标紅的部分是針對之前的難點做的重點改造，下面我将針對這幾個重點子產品，依次展開講解。

3.1.1 全局字典

全局字典主要是用來解決難點一——資料量大，壓縮存儲的同時保證查詢性能。

這裡大家可能會有疑問，既然用Bitmap存，為什麼還需要全局字典？

因為Doris 的bitmap功能基于RoaringBitmap實作的。是以當使用者id 過于離散的時候，RoaringBitmap 底層存儲結構用的是Array Container, 而沒有用到Bitmap Container。Array Container性能遠遠差于Bitmap Container，是以我們使用了全局字典将使用者id轉換成連續遞增id。

下面介紹一下全局字典的邏輯。

畫像、關注、行為等資料源經過ETL處理之後會進入Spark中。Spark首先會加載全局字典表，這張表主要用來維護使用者ID和自增ID的映射關系，會做一次全量的加載。加載完成後會判斷使用者ID是否在這個全量的字典表中，如果存在則直接将ETL之後的資料寫入Doris，如果不存在則說明這是個新使用者，使用row_numebr（）over産生一個自增ID與使用者ID做一次映射，映射完成後會寫入這張表中，同時将ETL之後的資料寫入Doris。

3.1.2 Doris

Doris之分桶政策

首先講一下分桶政策，分桶政策主要用來解決難點二——查詢頻響要求高。

之前做全局字典是要保證使用者的連續遞增，但我們發現做完全局字典之後Bitmap的查詢性能并沒有達到我們預期中的速度。後來我們發現Doris是一個分布式的叢集，它會按照某些Key進行分桶，也就是說分桶之後使用者ID在桶内又是離散的了。

如圖中的例子所示，原始資料userid是連續的，在按照appkey和channel進行分桶之後，在桶内的userid就不是連續的了。但是不連續的話，Bitmap的性能不能很好的發揮出來。

那麼在這種情況下如何保證桶内的連續呢？

我們的方案如下：

首先我們在表中增加了hid的字段，并且讓Doris用hid進行分桶。

hid有一個算法：

hid = V/(M/N), 取整
V: 插件式全局字典生成的使用者ID對應的整數
M：預估的使用者總數，後續不變
N：資料庫中設定的分桶數
           

如圖，使用者總數為6，M=6。分桶數為3，N=3。

這樣就将userid和hid做了對應，在用hid做分桶的時候，就可以保證桶内的連續。

Doris之使用者畫像标簽優化

以上講到的全局字典和分桶政策是通用的政策，是在做Bitmap時必須要考慮到的。但是隻考慮這兩點還不能達到性能的最優，還要結合實際的業務對業務進行優化。以下就是我們的具體業務——畫像标簽的存儲優化。

畫像标簽優化也是用來解決難點二——查詢頻響要求高。

當時有兩個方案，方案一是用tag_type和tag_value。tag_value用來記錄标簽的類型，tag_value用來記錄标簽的内容。方案二是将所有标簽放入一個寬表中。

我們選擇了方案二。因為方案一是一個标簽對應一個使用者，如果我想選取“性别男”，地域在“北京”的使用者，就需要把兩部分使用者做一個union，有一定的計算量，會更耗時。如果用方案二，可以根據使用者常用的查詢，建構對應的物化視圖，這樣使用者查詢的時候，命中物化視圖，就可以直接取出結果，而不必去計算，可以減少耗時。

在使用Doris的時候，大家要盡量命中字首索引和物化視圖，這樣會大大提升查詢效率。

Doris之動靜組合查詢

動靜組合查詢主要是解決難點三——計算複雜。

靜态查詢是使用者次元是固定的，可以進行預聚合的。比如“男性使用者”，這就是一個固定的群體，無論怎麼查這部分使用者是不會變的。動态查詢是偏向一些行為的，會根據使用者的不同而不同。比如“近30天收藏超過3次的使用者”，或“近30天收藏超過4次的使用者”，這種查詢無法進行預聚合，是以稱為動态的查詢。

小程式使用者分層相比于同類型的使用者分層功能，增加了使用者行為篩選（這也是小程式産品的特點之一），比如近30天使用者支付訂單超過30元的男性，20~30歲使用者。其中近30天使用者支付訂單超過30元使用者是Bitmap表無法記錄的，也不能提前預計算好，隻能線上去算。

這裡的難點是，如何進行非Bitmap表和Bitmap表的交并補集運算？

結合上面的例子，我們的解決方法是将查詢查分成四步。

Step1 先查20-30歲的男性使用者，這部分直接查Bitmap表就行。

Step2 查詢近30天使用者支付訂單超過30元使用者，這步需要去查行為表擷取使用者ID。

Step3 将使用者ID跟線上Bitmap的轉化，Doris提供了一個bitmap_union(to_bitmap(id)) 功能，可以線上将使用者id 轉換成bitmap。

Step4 是将Step1和Step3的結果求交集。

這裡的重點是Step3，Doris提供了to_bitmap的功能，幫我們解決了Bitmap表和非Bitmap表的聯合查詢的問題。

3.1.3 如何快速産出使用者包

快速産出使用者包是為了解決難點四——産出使用者包要求時效性高。

同樣有兩個方案，方案一是用排程平台+Spark。分成三步，首先産出分層使用者cuid，然後産出使用者uid，最後回調更新。方案二是用排程平台+solo，執行DAG圖是用solo産出cuid、uid和回調，這裡的solo是百度雲提供的Pingo單機執行引擎，類似一個虛拟機。

方案一由于spark自身yarn排程耗時，加上如何隊列資源緊張需要延遲等待等原因，即使産出0個使用者，也需要30分鐘才能跑完。

方案二我們利用了Doris的SELECT INTO OUTFILE産出結果導出功能：查出的使用者直接導出到afs上，百萬級使用者産出小于3分鐘。

最終我們選擇了方案二，因為Doris相比于spark導出結果到afs更快。

3.2 收益

Doris的使用者存儲方案還是非常有效的，整體方案的收益如下圖所示：

4 未來規劃

在産品上：

• 豐富分層應用場景， 拓展強關系次元， 豐富觸達形式
• 探索分層和商業的結合模式

在技術上：

• 時效性：交易，訂單， 關注等行為實時化
• 豐富性: 接入更多的使用者畫像标簽及行為
• 通用性: 全局字典插件化， 通用到各個業務

關于 Apache Doris(Incubating)

Apache Doris(Incubating)

一款基于大規模并行處理技術的互動式SQL分析資料庫，由百度于2018年貢獻給 Apache

基金會，目前在 Apache 基金會孵化器中。

Doris 官方網站： http://doris.incubator.apache.org/master/zh-CN/ Doris

Github： https://github.com/apache/incubator-doris

Doris Gitee 鏡像： https://gitee.com/baidu/apache-doris

Doris 開發者郵件組： http://doris.incubator.apache.org/master/zh-CN/community/subscribe-mail-list.html

Doris 微信公衆号：