【51CTO.com原創(chuàng)稿件】想做營銷活動，如何找到目標(biāo)人群及用戶特征?人群的篩選通常離不開用戶畫像。
圖片來自 Pexels
用戶畫像就是根據(jù)用戶特征、業(yè)務(wù)場景和用戶行為等信息，構(gòu)建一個標(biāo)簽化的用戶模型。
比如消費者用戶畫像分為屬性和行為標(biāo)簽兩類。這兩類標(biāo)簽，一個是固定的，一個是可變的。
固定的屬性標(biāo)簽基本就是買家的性別，年齡段，會員等級，消費水平，購買力等。而可變的行為標(biāo)簽基本包括買家的瀏覽，加購物車，購買等行為。
通過多年的建設(shè)，蘇寧構(gòu)建了完整的用戶標(biāo)簽體系，覆蓋零售、金融、體育等多個產(chǎn)業(yè)。
同時搭建了標(biāo)簽服務(wù)平臺，通過開放豐富的標(biāo)簽數(shù)據(jù)能力，為廣告、推薦等提供智能化的標(biāo)簽中臺服務(wù)能力。
隨著數(shù)據(jù)的日益增多，如何對 6 億+用戶千億級別的標(biāo)簽數(shù)據(jù)進(jìn)行秒級用戶畫像?
本文將帶來用戶畫像技術(shù)的新發(fā)展和架構(gòu)實踐，介紹基于 ClickHouse 定制開發(fā)的標(biāo)簽平臺，真正做到海量標(biāo)簽數(shù)據(jù)的快速導(dǎo)入和秒級用戶畫像查詢分析，提供一整套從前期人群篩選到后期的營銷策略優(yōu)化的標(biāo)簽體系。
業(yè)務(wù)場景介紹
“雙 11”到了，假設(shè)需要發(fā)放 1000 萬張家電類優(yōu)惠券，那我們首先需要根據(jù)標(biāo)簽篩選出符合條件的人群，人數(shù)大約為 1000 萬左右，然后對選擇的人群進(jìn)行畫像分析，看是否符合預(yù)期的特征。
如果人群符合特征，系統(tǒng)將一鍵生成進(jìn)行營銷的人群包(userid 列表)，自動化發(fā)布和營銷。
圖 1：業(yè)務(wù)流程
預(yù)估人數(shù)
用戶選擇標(biāo)簽及標(biāo)簽之間的交并差關(guān)系，圈選出符合條件的人群，實時預(yù)估出人群的數(shù)量。
比如選擇：
圖 2：創(chuàng)建人群
上圖的標(biāo)簽選擇的含義為：“用戶年齡范圍為 25-36 歲”并且為“智能家居特征”的人群，排除最近 30 天消費小于 10 元的人群。
表示為集合運(yùn)算的公式為：
- { {用戶年齡 25-36} ∩ {智能家居人群} } - {30天消費小于10元}
技術(shù)難點有：
- 人群包的個數(shù)多。
- 每個人群包的用戶基數(shù)較大。
- 系統(tǒng)實時輸出計算結(jié)果，難度大。
畫像分析
當(dāng)篩選出用戶數(shù)與規(guī)劃的消費券的數(shù)量匹配時，需要對人群進(jìn)行特征分析，看看人群是否符合特征要求。
用戶畫像表的結(jié)構(gòu)舉例如下：
將篩選出的人群包與用戶畫像表進(jìn)行關(guān)聯(lián)，詳細(xì)分析關(guān)聯(lián)出的畫像特征。也可以進(jìn)一步對畫像特征進(jìn)行一些歷史數(shù)據(jù)分析。
我們之前的解決方案是將用戶標(biāo)簽存儲在 ElasticSearch 的大寬表中的。大寬表的結(jié)構(gòu)是：一個用戶下掛一堆 tag 的表結(jié)構(gòu)。
在向大寬表插入數(shù)據(jù)時，需要等待業(yè)務(wù)的數(shù)據(jù)都準(zhǔn)備好后，才能跑關(guān)聯(lián)表操作，然后將關(guān)聯(lián)的結(jié)果插入到 ES。
經(jīng)常遇到的情況是：某個業(yè)務(wù)方的任務(wù)延遲，導(dǎo)致插入 ES 的關(guān)聯(lián)任務(wù)無法執(zhí)行，運(yùn)營人員無法及時使用最新的畫像數(shù)據(jù)。
在 ES 中修改文檔結(jié)構(gòu)是比較重的操作，修改或者刪除標(biāo)簽比較耗時，ES 的多維聚合性能比較差，ES 的 DSL 語法對研發(fā)人員不太友好，所以我們將標(biāo)簽存儲引擎從 ES 替換為 ClickHouse。
ClickHouse 是近年來備受關(guān)注的開源列式數(shù)據(jù)庫，主要用于數(shù)據(jù)分析(OLAP)領(lǐng)域。憑借優(yōu)異的查詢性能，受到業(yè)界的青睞，各個大廠紛紛跟進(jìn)大規(guī)模使用它。
蘇寧大數(shù)據(jù)已將 ClickHouse 引入并改造，封裝成豐富的 Bitmap 接口，用來支撐標(biāo)簽平臺的存儲及分析。
ClickHouse 集成 Bitmap
我們在 ClickHouse 中集成了 RoaringBitmap，實現(xiàn)了 Bitmap 計算功能集，并貢獻(xiàn)給開源社區(qū)。
對 userid 進(jìn)行位圖方式的壓縮存儲，將人群包的交并差計算交給高效率的位圖函數(shù)，這樣既省空間又可以提高查詢速度。
圖 3：ClickHouse 集成 Bitmap
圍繞 Bitmap 對象實現(xiàn)了一套完善的計算函數(shù)。Bitmap 對象有兩種構(gòu)建方式，一種是從聚合函數(shù) groupBitmap 構(gòu)建，另一種是從 Array 對象構(gòu)建，也可以將 Bitmap 對象轉(zhuǎn)換為 Array 對象。
ClickHouse 的 Array 類型有大量的函數(shù)集，這樣可以更加方便的加工數(shù)據(jù)。
上圖的中間部分是 Bitmap 的計算函數(shù)集，有位運(yùn)算函數(shù)、聚合運(yùn)算函數(shù)、求值類運(yùn)算函數(shù)，比較豐富。
基于 ClickHouse 的新架構(gòu)
架構(gòu)介紹
架構(gòu)圖如下：
圖 4：標(biāo)簽架構(gòu)
ClickHouse Manager 是我們自研的 ClickHouse 管理平臺，負(fù)責(zé)集群管理、元數(shù)據(jù)管理和節(jié)點負(fù)載協(xié)調(diào)。
Spark 任務(wù)負(fù)責(zé)標(biāo)簽數(shù)據(jù)的生成和導(dǎo)入，當(dāng)某個業(yè)務(wù)方的任務(wù)跑完后，會立刻調(diào)用 tag-generate 生成標(biāo)簽數(shù)據(jù)文件，存放到 HDFS，然后在 ClickHouse 上執(zhí)行從 HDFS 導(dǎo)入到 ClickHouse 的 SQL 語句，這樣就完成了標(biāo)簽的生產(chǎn)工作。
標(biāo)簽生產(chǎn)是并發(fā)跑的，假設(shè)某個業(yè)務(wù)方的數(shù)據(jù)沒有準(zhǔn)備好，不影響其他業(yè)務(wù)的標(biāo)簽生產(chǎn)。
用戶畫像平臺通過 Proxy 從 ClickHouse 集群查詢標(biāo)簽數(shù)據(jù)。在查詢前，需要將查詢表達(dá)式轉(zhuǎn)換為 SQL，我們對這塊邏輯做了一個封裝，提供一個通用的轉(zhuǎn)換模塊，叫做：to-ch-sql。
業(yè)務(wù)層基本上不用修改就可以查詢 ClickHouse 了。
標(biāo)簽數(shù)據(jù)表的基本結(jié)構(gòu)
相對于 ElasticSearch 的存儲結(jié)構(gòu)，我們將標(biāo)簽存儲做了一個行轉(zhuǎn)列存儲。每個標(biāo)簽對應(yīng)一個 Bitmap 對象。
Bitmap 對象中存儲 userid 集合：
- CREATE TABLE ch_label_string
- (
- labelname String, --標(biāo)簽名稱
- labelvalue String, --標(biāo)簽值
- uv AggregateFunction( groupBitmap, UInt64 ) --userid集合
- )
- ENGINE = AggregatingMergeTree()
- PARTITION BY labelname
- ORDER BY (labelname, labelvalue)
- SETTINGS index_granularity = 128;
uv 字段為 Bitmap 類型的字段，將整形的 userid 存入，每個 userid 用一個 bit 位表示。
主鍵索引(index_granularity)默認(rèn)為 8192，修改為 128 或者其他數(shù)值，由于 Bitmap 占用的存儲空間比較大，修改為小數(shù)值，以減少稀疏索引的讀放大問題。
根據(jù)標(biāo)簽值的數(shù)據(jù)類型劃分為四種類型的表：
- String
- Integer
- Double
- Date
標(biāo)簽名稱作為 Partition。通過這樣的設(shè)計，增加或者刪除標(biāo)簽數(shù)據(jù)都比較方便，只需要修改 Partition 的數(shù)據(jù)就可以了。Partition 的管理有相應(yīng)的 SQL 語句，操作比較方便。
Userid 分片存儲
在標(biāo)簽數(shù)據(jù)導(dǎo)入時，按照 userid 分片導(dǎo)入，每臺機(jī)器僅存儲對應(yīng) userid 的標(biāo)簽數(shù)據(jù)。
每臺機(jī)器分別導(dǎo)入分片后的標(biāo)簽數(shù)據(jù)，實現(xiàn)了數(shù)據(jù)并行導(dǎo)入。在我們的環(huán)境上單機(jī)導(dǎo)入性能在 150 萬條/秒左右。
在根據(jù)標(biāo)簽篩選人群時，SQL 僅需要在單個 shard 上執(zhí)行，中間結(jié)果不需要返回給查詢節(jié)點。
在執(zhí)行“預(yù)估人數(shù)”計算時，優(yōu)勢特別明顯：每個 shard 僅需要返回符合條件的人數(shù)，在查詢節(jié)點做 sum 操作，然后將 sum 結(jié)果返回給客戶端。充分挖掘了 ClickHouse 分布式并行計算的能力。
查詢流程
采用 with 語句進(jìn)行計算出人群包的 Bitmap 對象，然后用 Bitmap 函數(shù)進(jìn)行交并差的計算。
當(dāng)需要計算的標(biāo)簽比較多時，標(biāo)簽查詢的 SQL 比較復(fù)雜，將標(biāo)簽查詢 SQL 包裝到分布式代理表的 SQL 中，分布式代理表本身不存儲數(shù)據(jù)，通過代理表標(biāo)識到哪些節(jié)點上查詢，分布式代理表所標(biāo)識的節(jié)點上執(zhí)行標(biāo)簽查詢 SQL。
然后在分布式代理表上匯總查詢結(jié)果。通過 ClickHouse 分布式表的自身特性，實現(xiàn)了標(biāo)簽查詢的 colocate 機(jī)制。
圖 5：查詢流程
示例 SQL 如下：
- -- 本地查詢代理
- CREATE TABLE ch_agent_user
- (
- agentname String
- )
- ENGINE = MergeTree()
- PARTITION BY agentname
- ORDER BY (agentname)
- SETTINGS index_granularity = 8192;
- -- 分布式代理表
- CREATE TABLE ch_agent_dist_user AS ch_agent_user
- ENGINE = Distributed('cluster_test', 'test', 'ch_agent_user', cityHash64(agentname))
- -- 查詢用戶數(shù)
- SELECT sum(user_number) AS user_number
- FROM ch_agent_dist_user
- RIGHT JOIN
- (
- WITH
- (
- SELECT groupBitmapState(userid) AS users0
- FROM ch_label_string
- WHERE labelname = 'T'
- ) AS users0
- SELECT
- 'agent' AS agentname,
- bitmapCardinality(users0) AS user_number
- ) USING (agentname) settings enable_scalar_subquery_optimization = 0;
ch_agent_user 表本身不存儲數(shù)據(jù)，當(dāng)與 with 語句進(jìn)行 right join 關(guān)聯(lián)查詢時，由于是右關(guān)聯(lián)查詢，查詢結(jié)果以 with 語句的結(jié)果集為準(zhǔn)。
各個節(jié)點的查詢結(jié)果返回給查詢節(jié)點，查詢節(jié)點進(jìn)行匯總計算。參數(shù) enable_scalar_subquery_optimization = 0 表示 with 語句的查詢結(jié)果不做優(yōu)化，每個節(jié)點都需要執(zhí)行。
默認(rèn)情況，在 ClickHouse 中 with 語句的結(jié)果作為標(biāo)量進(jìn)行緩存，會將查詢節(jié)點的標(biāo)量分發(fā)到其他服務(wù)器，當(dāng)發(fā)現(xiàn)已經(jīng)存在標(biāo)量時，就不會在本地節(jié)點執(zhí)行 with 語句。
我們期望 with 語句在每個節(jié)點都執(zhí)行，所以將這個參數(shù)設(shè)置為 0。
用戶畫像
用戶畫像對性能要求比較高，查詢平均響應(yīng)時間不能大于 5 秒。用戶在界面上任意圈選人群，然后實時對圈選后的人群進(jìn)行畫像分析。
用戶畫像技術(shù)進(jìn)行了三次架構(gòu)重構(gòu)：
①V1：大寬表模式
最早的方案是創(chuàng)建一張 userid 為主鍵的畫像表，表的其他字段為畫像的特征字段，將圈選的人群與畫像表進(jìn)行 in 操作，然后 group by 操作。
這種設(shè)計帶來兩個比較嚴(yán)重的問題：
- 當(dāng)增加或者刪除特征字段時，畫像表的表結(jié)構(gòu)需要修改。
- 當(dāng)圈選的人群數(shù)量比較大時，涉及到大記錄集的 group by 運(yùn)算，性能差。
②V2：Bitmap 模式
將一個特征值下的 userid 集合做為 Bitmap 對象存儲到一條記錄中，一條記錄的內(nèi)容如下：
用戶圈選的人群 Bitmap 對象與畫像表的 Bitmap 對象進(jìn)行與(AND)操作，返回圈選人群的畫像信息。
通過這樣設(shè)計，基本上滿足了性能要求，平均時間小于 5 秒，但是一些大的人群包，畫像的性能還是差，在 10 秒左右。
畫像表的記錄數(shù)據(jù)量不大，但畫像表的 Bitmap 字段在計算時需要從磁盤上反序列化出來。有的 Bitmap 對象占用幾百兆的空間，導(dǎo)致了性能的下降。
③V3：Join 表引擎模式
ClickHouse 的 Join 表引擎可以將數(shù)據(jù)常駐到內(nèi)存。當(dāng)插入數(shù)據(jù)時，數(shù)據(jù)先寫入內(nèi)存，然后刷到磁盤文件，系統(tǒng)重啟時，自動把數(shù)據(jù)加載回內(nèi)存。Join 表引擎可以說是常駐內(nèi)存的帶持久化功能的表。
我們把畫像表的數(shù)據(jù)保存到 Join 表引擎，畫像表的 Bitmap 字段就常駐內(nèi)存了，當(dāng)圈選的人群 Bitmap 對象進(jìn)行與(AND)操作時，兩個內(nèi)存中已經(jīng)加載的 Bitmap 對象之間的計算就非常快。
通過這次優(yōu)化平均查詢時間優(yōu)化到 1 到 2 秒，千萬級人群畫像分析不超過 5 秒。
總結(jié)
通過 ClickHouse 集成 Bitmap 功能，以及 Join 表引擎的應(yīng)用，對架構(gòu)進(jìn)行了一系列優(yōu)化后，極大的提升了標(biāo)簽平臺的數(shù)據(jù)分析能力。
新的架構(gòu)主要有以下優(yōu)勢：
- 標(biāo)簽數(shù)據(jù)可以并行構(gòu)建，加快標(biāo)簽數(shù)據(jù)生產(chǎn)速度。
- HDFS 文件并發(fā)導(dǎo)入 ClickHouse，加快標(biāo)簽數(shù)據(jù)的就緒速度。
- 查詢請求平均響應(yīng)時長在 2 秒以下，復(fù)雜查詢在 5 秒以下。
- 支持標(biāo)簽數(shù)據(jù)準(zhǔn)實時更新。
- 標(biāo)簽表達(dá)式和查詢 SQL 對用戶來說比較友好，提升系統(tǒng)的易維護(hù)性。
- 相對于 ElasticSearch 的配置，可以節(jié)約一半硬件資源。
未來規(guī)劃：
- 目前 ClickHouse 采用 RoaringBitmap 的 32 位版本，準(zhǔn)備增加 64 位版本。
- ClickHouse 查詢的并發(fā)性較低，增加更加智能的 Cache 層。
- 支持 ClickHouse 數(shù)據(jù)文件離線生成，進(jìn)一步提示標(biāo)簽的就緒速度。
參考：
- ClickHouse 官網(wǎng)：https://clickhouse.tech/
- ClickHouse 中文社區(qū)：http://www.clickhouse.com.cn/
- Bitmap PR：https://github.com/ClickHouse/ClickHouse/pull/4207
作者：楊兆輝
簡介：蘇寧科技集團(tuán)大數(shù)據(jù)中心高級架構(gòu)師，ClickHouse Contributor。在 OLAP 領(lǐng)域、大規(guī)模分布式計算領(lǐng)域有著深厚的技術(shù)積累，目前負(fù)責(zé)數(shù)據(jù)中臺、標(biāo)簽平臺相關(guān)的架構(gòu)工作。
編輯：陶家龍
征稿：有投稿、尋求報道意向技術(shù)人請聯(lián)絡(luò) editor@51cto.com
【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】
