作者：趙煜楊? 百度資深研發(fā)工程師? 負責手百小程序數(shù)據(jù)產(chǎn)品工程架構(gòu)

本次分享大綱如下：

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

用戶分層技術(shù)難點

用戶分層的架構(gòu)和解決方案

未來規(guī)劃

小程序目前使用百度云 Palo（Apache Doris 企業(yè)版）承載其精細化運營業(yè)務。

通過本文可以幫助大家了解在 Doris 中使用全局字典、BITMAP 等功能時遇到的問題、解決思路和優(yōu)化方案。

1.1小程序私域精細化運營能力介紹

私域用戶價值不突出。比如，我是個目前有100萬用戶的開發(fā)者，想推一款奢侈品包包給用戶里面的高收入人群。但是我不知道這100萬人中，有多少人是高收入人群，是很難將他們找出來的。

缺乏主動觸達能力，也就是觸達通路比較少。

針對這兩個問題，我們產(chǎn)品上提出了一個解決方案——分層運營。

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



如圖所示，從上往下看，比如我現(xiàn)在要推一個活動，運營同學會在消息、私信、卡券和小程序內(nèi)這四個通路中選擇一個進行推送。選完通路之后，就要選擇人群。

精細化人群篩選是基于百度的大數(shù)據(jù)平臺提供的畫像數(shù)據(jù)和行為數(shù)據(jù)去篩選特定的人群。

整個流程完成之后，我們會提供一個觸達效果的分析（主要包括下發(fā)量，點展和到達分析等），和一個群體分析（對整個用戶群的更細致化的分析）。

從收益和價值上來看，對于開發(fā)者：

• 合理利用私域流量，提升資源價值

• 促進用戶活躍和轉(zhuǎn)換

對于整個生態(tài):

• 提高私域池利用率和活躍度

• 激活開發(fā)者主動經(jīng)營意愿

• 促進生態(tài)良性循環(huán)

以上主要講了整個產(chǎn)品的方案，下面講一下具體的功能。



1.2?分層運營——B端視角

作為開發(fā)者，我要如何去創(chuàng)建用戶分分層？

入口在小程序開發(fā)者后臺——運營中心——分層運營——分層管理——自定義篩選。點擊自定義篩選后會進入自定義篩選頁面，在這個頁面用戶可以選擇關(guān)注行為、卡券行為、交易行為等維度。選擇完成之后，可以使用“預估人數(shù)”功能，實時計算一下圈選的人群人數(shù)有多少，如果覺得所選的人群人數(shù)比較合適就點擊“生成人群”。生成人群之后將會進入分層管理列表，在這里可以發(fā)送消息或私信，還可以進行群體分析。

1.3?分層運營——C端視角

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



1.4?分層運營經(jīng)典案例

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



如圖所示，使用場景是在百度App中向用戶推送一個通知，用戶在“我的”里面打開，填寫評價之后可以領(lǐng)券。?

這次活動的效果是：

• 準確判斷用戶需求，活躍用戶具有較高價值，頁面打開率達9.51%

• 用戶次均使用時長提升2.5倍

• 活動帶來新增付費轉(zhuǎn)化率達17.71%?

這里面有幾個運營技巧：

• 結(jié)合實際業(yè)務場景，無中間頁跳轉(zhuǎn)折損

• 拼接消息組件，自動發(fā)券場景過渡順滑

• 場景可定期復用，節(jié)省人力成本。也就是創(chuàng)建完人群之后，可以一直使用這個人群。

• “分享+使用”雙按鈕強勢引導

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

但是實現(xiàn)起來有很大的技術(shù)難點。



2?用戶分層難點

難點主要有四個：

首先，TB級數(shù)據(jù)，數(shù)據(jù)量特別大。我們基于畫像和行為做用戶分層，每天的數(shù)據(jù)量大概有1T+。

第二，查詢的頻響要求極高，要求毫秒到秒級的響應時間。比如剛剛提到的“預估人數(shù)”的功能，用戶在點擊之后，我們需要在毫秒到秒的時間內(nèi)，從TB級的數(shù)據(jù)中計算這個選定的人群數(shù)量結(jié)果。

第三，計算復雜，需要動態(tài)靜態(tài)組合查詢。很多維度的數(shù)據(jù)無法進行預聚合，必須要實時計算明細數(shù)據(jù)，所以計算是很復雜的，這點后面會詳細展開。

第四，產(chǎn)出用戶包要求實效性高。

?

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

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

難點2、3:?我們調(diào)研了當前開源主流OLAP引擎ClickHouse, Doris, Druid等，最后選擇使用基于MPP架構(gòu)的OLAP引擎Doris。在性能上其實ClickHouse, Doris, Druid都差不多。但是Doris有幾個優(yōu)點，第一，Doris兼容MySQL協(xié)議，學習成本非常低，基本上RD都會用。第二，Doris的運維成本很低，基本上是自動化運維，所以我們最后選擇了Doris。

難點4:?我們調(diào)研對比了spark，Doris 性能，最終也是選擇使用基于MPP架構(gòu)的OLAP引擎Doris，這點在后面會詳細講。



3?用戶分層的架構(gòu)和解決方案

下面我將會從架構(gòu)和解決方案上講解上面這些難點是如何解決的。

3.1?分層運營架構(gòu)

首先介紹一下分層運營的架構(gòu)，分為在線部分和離線部分。

在線部分分為四層，服務層、解析層、計算層和存儲層，還有一個調(diào)度平臺和一個監(jiān)控平臺。

服務層包含了權(quán)限控制（用戶權(quán)限和接口權(quán)限），分層管理（是對用戶篩選分層的增刪改查的管理），元數(shù)據(jù)管理（對頁面元素和ID Mapping的管理）和任務管理（對調(diào)度平臺任務的增刪改查的管理）

解析層主要是對DSL的解析。比如，用戶要在線預估人數(shù)。走到解析層時，首先要進行DSL解析。然后對DSL優(yōu)化，比如我想找到近7天活躍的用戶和近7天不活躍的用戶求一個交集，顯然結(jié)果是0，那么在優(yōu)化層被優(yōu)化掉，返還給用戶結(jié)果為0，不會再往下走到計算引擎。優(yōu)化之后會有DSL路由，這個路由的功能主要是判斷查詢的維度，路由到SQL模版進行模版的拼接。

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

存儲層有MySQL（用來存用戶分層的信息），Redis（主要用來緩存），Doris（存畫像數(shù)據(jù)和行為數(shù)據(jù)）和afs（存產(chǎn)出的用戶包信息）。

調(diào)度平臺用來管理離線任務的調(diào)度，監(jiān)控平臺用來對整體服務穩(wěn)定性監(jiān)控。

離線部分主要是對需要的數(shù)據(jù)源，比如畫像、關(guān)注、行為等數(shù)據(jù)進行ETL清洗，然后做一個全局字典，完成之后會寫入Doris。

在產(chǎn)出用戶包之后，會分發(fā)給小程序B端和百度統(tǒng)計。小程序B端會將消息推送到這些用戶的手機端；百度統(tǒng)計會用這個用戶包做群體分析。?

以上就是整體的架構(gòu)，圖中標紅的部分是針對之前的難點做的重點改造，下面我將針對這幾個重點模塊，依次展開講解。

3.1.1?全局字典

全局字典主要是用來解決難點一——數(shù)據(jù)量大，壓縮存儲的同時保證查詢性能。



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

因為Doris 的bitmap功能基于RoaringBitmap實現(xiàn)的。因此當用戶id 過于離散的時候，RoaringBitmap 底層存儲結(jié)構(gòu)用的是Array Container, 而沒有用到Bitmap Container。Array Container性能遠遠差于Bitmap Container，因此我們使用了全局字典將用戶id轉(zhuǎn)換成連續(xù)遞增id。

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

畫像、關(guān)注、行為等數(shù)據(jù)源經(jīng)過ETL處理之后會進入Spark中。Spark首先會加載全局字典表，這張表主要用來維護用戶ID和自增ID的映射關(guān)系，會做一次全量的加載。加載完成后會判斷用戶ID是否在這個全量的字典表中，如果存在則直接將ETL之后的數(shù)據(jù)寫入Doris，如果不存在則說明這是個新用戶，使用row_numebr（）over產(chǎn)生一個自增ID與用戶ID做一次映射，映射完成后會寫入這張表中，同時將ETL之后的數(shù)據(jù)寫入Doris。

3.1.2 Doris



Doris之分桶策略



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

之前做全局字典是要保證用戶的連續(xù)遞增，但我們發(fā)現(xiàn)做完全局字典之后Bitmap的查詢性能并沒有達到我們預期中的速度。后來我們發(fā)現(xiàn)Doris是一個分布式的集群，它會按照某些Key進行分桶，也就是說分桶之后用戶ID在桶內(nèi)又是離散的了。



如圖中的例子所示，原始數(shù)據(jù)userid是連續(xù)的，在按照appkey和channel進行分桶之后，在桶內(nèi)的userid就不是連續(xù)的了。但是不連續(xù)的話，Bitmap的性能不能很好的發(fā)揮出來。?

那么在這種情況下如何保證桶內(nèi)的連續(xù)呢？

我們的方案如下：

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

hid有一個算法：

hid?=?V/(M/N),?取整V:?插件式全局字典生成的用戶ID對應的整數(shù)M：預估的用戶總數(shù)，后續(xù)不變N：數(shù)據(jù)庫中設定的分桶數(shù)

如圖，用戶總數(shù)為6，M=6。分桶數(shù)為3，N=3。

這樣就將userid和hid做了對應，在用hid做分桶的時候，就可以保證桶內(nèi)的連續(xù)。



Doris之用戶畫像標簽優(yōu)化

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



畫像標簽優(yōu)化也是用來解決難點二——查詢頻響要求高。



當時有兩個方案，方案一是用tag_type和tag_value。tag_value用來記錄標簽的類型，tag_value用來記錄標簽的內(nèi)容。方案二是將所有標簽放入一個寬表中。

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

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



Doris之動靜組合查詢

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



靜態(tài)查詢是用戶維度是固定的，可以進行預聚合的。比如“男性用戶”，這就是一個固定的群體，無論怎么查這部分用戶是不會變的。動態(tài)查詢是偏向一些行為的，會根據(jù)用戶的不同而不同。比如“近30天收藏超過3次的用戶”，或“近30天收藏超過4次的用戶”，這種查詢無法進行預聚合，所以稱為動態(tài)的查詢。



?



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

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

結(jié)合上面的例子，我們的解決方法是將查詢查分成四步。

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

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

Step3?將用戶ID跟在線Bitmap的轉(zhuǎn)化，Doris提供了一個bitmap_union(to_bitmap(id)) 功能，可以在線將用戶id 轉(zhuǎn)換成bitmap。

Step4?是將Step1和Step3的結(jié)果求交集。?

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

3.1.3?如何快速產(chǎn)出用戶包

快速產(chǎn)出用戶包是為了解決難點四——產(chǎn)出用戶包要求時效性高。



同樣有兩個方案，方案一是用調(diào)度平臺+Spark。分成三步，首先產(chǎn)出分層用戶cuid，然后產(chǎn)出用戶uid，最后回調(diào)更新。方案二是用調(diào)度平臺+solo，執(zhí)行DAG圖是用solo產(chǎn)出cuid、uid和回調(diào)，這里的solo是百度云提供的Pingo單機執(zhí)行引擎，類似一個虛擬機。



方案一由于spark自身yarn調(diào)度耗時，加上如何隊列資源緊張需要延遲等待等原因，即使產(chǎn)出0個用戶，也需要30分鐘才能跑完。方案二我們利用了Doris的SELECT INTO OUTFILE產(chǎn)出結(jié)果導出功能：查出的用戶直接導出到afs上，百萬級用戶產(chǎn)出小于3分鐘。

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

3.2?收益

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



4 未來規(guī)劃

首先在產(chǎn)品上：

豐富分層應用場景， 拓展強關(guān)系維度， 豐富觸達形式

探索分層和商業(yè)的結(jié)合模式

在技術(shù)上：

時效性：交易，訂單， 關(guān)注等行為實時化

豐富性:? 接入更多的用戶畫像標簽及行為

通用性:? 全局字典插件化， 通用到各個業(yè)務

期待你的加入

百度開發(fā)者中心已開啟征稿模式，歡迎開發(fā)者登錄developer.baidu.com進行投稿，優(yōu)質(zhì)文章將獲得豐厚獎勵和推廣資源。

總結(jié)

以上是生活随笔為你收集整理的技术干货 | 基于 Doris 构建的小程序私域流量增长的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。