由于流量紅利逐漸消退，越來越多的廣告企業(yè)和從業(yè)者開始探索精細(xì)化營銷的新路徑，取代以往的全流量、粗放式的廣告轟炸。精細(xì)化營銷意味著要在數(shù)以億計的人群中優(yōu)選出那些最具潛力的目標(biāo)受眾，這無疑對提供基礎(chǔ)引擎支持的數(shù)據(jù)倉庫能力，提出了極大的技術(shù)挑戰(zhàn)。

本篇內(nèi)容將聚焦字節(jié)跳動OLAP引擎技術(shù)和落地經(jīng)驗，以字節(jié)跳動內(nèi)部場景為例，具體拆解廣告業(yè)務(wù)的實現(xiàn)邏輯和業(yè)務(wù)效果。

廣告精準(zhǔn)投放場景

廣告投放過程一般包含數(shù)據(jù)收集->數(shù)據(jù)整合->人群圈選->廣告投放->反饋分析等關(guān)鍵流程，人群圈選是廣告精準(zhǔn)投放的關(guān)鍵步驟，它幫助確定廣告目標(biāo)受眾，輔助投放平臺根據(jù)不同受眾和廣告目標(biāo)優(yōu)化投放策略，提升廣告收益；

人群預(yù)估

人群預(yù)估主要是根據(jù)一定的圈選條件，確認(rèn)命中的用戶數(shù)目。在廣告精準(zhǔn)投放過程中，廣告主需要知道當(dāng)前選定的人群組合中大概會有多少人，用于輔助判斷投放情況進(jìn)而確定投放預(yù)算，通常要求計算時間不能超過 5 秒。

廣告投放

廣告精準(zhǔn)投放過程中遇到的問題與痛點：

1. 數(shù)據(jù)預(yù)估： 廣告主需要對選定的人群組合進(jìn)行預(yù)估，以便判斷投放情況并確定投放預(yù)算。但人群包數(shù)據(jù)量多，基數(shù)大。平臺的用戶數(shù)上億，僅抖音的 DAU 就幾億，抖音、頭條對應(yīng)的人群包在億級別，早期的預(yù)估版本采用ElasticSearch，但由于數(shù)據(jù)過于龐大，只能采用1/10抽樣存儲，導(dǎo)致10%的誤差，業(yè)務(wù)難以接受。

2. 查詢性能： 廣告主可以設(shè)定一個非常復(fù)雜的圈選條件，導(dǎo)致計算復(fù)雜（單次計算可能包含幾百上千個人群包），Hive和ES等方案在處理大數(shù)據(jù)量時，查詢速度會變得非常慢，如果需要查詢某個廣告主的所有用戶，需要掃描整個用戶庫，而這個過程可能需要幾分鐘甚至幾個小時，無法滿足實時性要求。

3. 存儲空間大： Hive和ES等方案需要額外的索引結(jié)構(gòu)，導(dǎo)致存儲空間變大，從而增加了存儲成本。例如，如果需要對用戶屬性進(jìn)行索引，就需要額外的存儲空間來存儲索引數(shù)據(jù)。

4. 不支持高并發(fā)： Hive和ES等方案在處理高并發(fā)請求時，容易出現(xiàn)性能問題，無法支持高效的廣告投放。例如，如果同時有多個廣告主需要查詢用戶信息，就可能會出現(xiàn)查詢阻塞或響應(yīng)延遲等問題。

5. 數(shù)據(jù)查詢效率： 采用ClickHouse支持預(yù)估，但隨著數(shù)據(jù)量的增長，ClickHouse在當(dāng)前存儲引擎的支持下也難以保證查詢時間。這導(dǎo)致了數(shù)據(jù)查詢效率的問題，影響了用戶體驗。

ByteHouse BitEngine方案

方案簡介

新查詢引擎

• 基于高性能、分布式特點，ClickHouse可以滿足大規(guī)模數(shù)據(jù)的分析和查詢需求，因此研發(fā)團(tuán)隊以開源ClickHouse為基礎(chǔ)，研發(fā)出火山引擎云原生數(shù)據(jù)倉庫ByteHouse，并在其中定制一套處理模型——BitEngine，用于解決集合的交并補計算在實時分析場景中的性能提升問題。

• 針對廣告人群預(yù)估業(yè)務(wù)開發(fā)的新查詢引擎，基于ByteHouse提供的MergeTree Family系列引擎，添加了新的bitmap64類型和一系列的相關(guān)聚合函數(shù)。BitEngine提供的bitmap64類型適合存儲和計算大量的用戶ID之間的關(guān)系；在廣告人群預(yù)估業(yè)務(wù)中，bitmap64類型用于存儲人群包數(shù)據(jù)，然后將人群包之間的交并補計算轉(zhuǎn)化為bitmap之間的交并補，從而達(dá)到遠(yuǎn)超普通查詢的性能指標(biāo)。

實現(xiàn)步驟

創(chuàng)建一個bitmap64類型，可以將用戶ID直接存儲在bitmap中，提供一系列交并補的聚合計算，并且還希望可以充分利用多核CPU的并行計算能力，由此我們設(shè)計了BitEngine。示例如下

CREATE?TABLE?cdp.tag_uids_map?(
tags?String,
uids?BitMap64?BitEngineEncode
)ENGINE?=?HaMergeTree('/clickhouse/xxxx/{shard}',?'{replica}')
ORDER?BY?tag

tag_uids_map存儲格式如下

tag	uids
A	{10001,20001,30001,40001,50001,60001,70001,80001,90001}
B	{10001,20001,20002,20003,20004,20005,20006,20007,20008}

要查詢 A&B 的結(jié)果 SQL 為

SELECT bitmapCount('A&B') FROM tag_uids_map

BitEngine實現(xiàn)邏輯

核心思想

1. 對數(shù)據(jù)做分區(qū)劃分和編碼，保證每個區(qū)間的數(shù)據(jù)之間不存在交集，然后使用roaring bitmap保存數(shù)據(jù)；

2. 計算時每個分區(qū)的數(shù)據(jù)可以獨立的做聚合計算，充分利用機(jī)器的并行能力，每個分區(qū)內(nèi)部的聚合計算就是多個bitmap之間的交并補，利用roaring bitmap高效的交并補計算降低CPU和內(nèi)存的使用；

3. 通過字典將編碼的結(jié)果反解回來，數(shù)據(jù)編碼是為了讓數(shù)據(jù)的分布盡可能稠密，roaring bitmap在存儲和計算的時候就可以獲得更好的性能。

業(yè)務(wù)應(yīng)用

業(yè)務(wù)關(guān)鍵要素

1. 人群包：廣告主自定義規(guī)則計算出來的人群數(shù)據(jù)，標(biāo)簽是dmp團(tuán)隊根據(jù)市場需求定義的人群數(shù)據(jù)。

2. 標(biāo)簽ID：每天定時根據(jù)產(chǎn)出規(guī)則更新一次，人群ID是自增的，每天根據(jù)廣告主需求進(jìn)行新建計算。

統(tǒng)一編碼

1. 為了對標(biāo)簽數(shù)據(jù)和人群數(shù)據(jù)的uid統(tǒng)一編碼，編碼服務(wù)先將標(biāo)簽數(shù)據(jù)中的uid和人群數(shù)據(jù)中的uid提取出來進(jìn)行統(tǒng)一編碼，將全量uid均勻hash到一萬個桶中，桶編號為i[0<=i<=9999]，uid在每個桶內(nèi)由1開始順序編碼，每個桶的范圍為i*2^40 - (i+1)*2^40。

2. uid數(shù)據(jù)每天都在增加，因此需要支持增量編碼， 編碼服務(wù)每天會先獲取增量uid，hash后順序放置到每個桶中。

數(shù)據(jù)存儲

1. 完成編碼后，會先把字典數(shù)據(jù)統(tǒng)一寫入hive表中，便于字典的各種使用場景。

2. 在數(shù)據(jù)經(jīng)過分區(qū)和編碼之后，ClickHouse可以以多種數(shù)據(jù)導(dǎo)入格式將數(shù)據(jù)以bitmap64類型存入磁盤。

數(shù)據(jù)計算

BitEngine如何充分利用計算機(jī)的并行能力完成每個分區(qū)多個bitmap之間的交并補計算？

存在問題：

假設(shè)存在四個bitmap，分別為a，b，c，d；則(a | c) & (b | d)不一定等于(a & b) | (c & d)。

人群包

人群包A = [10001, 20001，30001，40001，50001]，人群包B = [10001, 20001，20002，20003，20004]

期望結(jié)果

通過BitEngine計算A&B = [10001, 20001]

設(shè)計方案

• 人群包按照一定的規(guī)則劃分為多個區(qū)間，任意兩個區(qū)間之間的人群包沒有交集

• 一個計算線程只讀取同一個區(qū)間的人群包進(jìn)行計算，得到一個中間結(jié)果

• 最終的中間結(jié)果只需要簡單的進(jìn)行bitmap or計算即可

對于這個設(shè)計，BitEngine需要保證數(shù)據(jù)的讀取和計算是嚴(yán)格按照區(qū)間進(jìn)行。BitEngine在數(shù)據(jù)讀取時會為每一個文件構(gòu)建一個讀任務(wù)，由一個線程調(diào)度模塊完成整個任務(wù)的調(diào)度和讀取，這個線程調(diào)度模塊的調(diào)度原則是：

• 不同分區(qū)的文件不會交叉讀?。–lickHouse的文件讀取粒度小于文件粒度，會存在多個線程先后讀一個文件的情況，一個分區(qū)也可能由多個文件組成），即一個線程只會讀A_1，B_1，不會在這之間讀取A_2或者B_2。

• 一個分區(qū)讀取完成后，可以立即觸發(fā)聚合計算，執(zhí)行bitmap之間的計算邏輯，獲得中間結(jié)果。即A_1，B_1 讀取完成后，可以立即計算A_1 & B_1。

• 線程計算完中間結(jié)果后，可以繼續(xù)讀其他文件

BitEngine完成所有中間結(jié)果的計算后，會按照結(jié)果的輸出要求做一次數(shù)據(jù)合并：

• 如果需要計算的結(jié)果是bitmap的基數(shù)的時候，BitEngine直接將各個中間結(jié)果的基數(shù)相加

• 如果計算結(jié)果需要的是bitmap，BitEngine直接將所有的bitmap合并起來，這里合并指的是bitmap or計算

業(yè)務(wù)效果

廣告業(yè)務(wù)效果

1. 數(shù)據(jù)存儲空間縮小了 3 倍+

2. 導(dǎo)入時間縮小了 3 倍+

3. 查詢 avg/pct99/max 都下降明顯，pct99 從 5 s 降低到 2 s

4. CPU 使用下降明顯，PageCache 節(jié)省 100 G+

5. 查詢誤差從10% 下降到 0%

BitEngine上線前后查詢耗時監(jiān)控

BitEngine上線后CPU負(fù)載對比

PageCache 使用情況（lower is better)

案例總結(jié)

BitEngine上線使用后，經(jīng)過大量調(diào)優(yōu)，在廣告人群預(yù)估業(yè)務(wù)上取得了良好收益。目前，BitEngine已經(jīng)集成在火山引擎云原生數(shù)據(jù)倉庫ByteHouse中對外輸出。火山引擎ByteHouse主要為用戶提供極速分析體驗，能夠支撐實時數(shù)據(jù)分析和海量數(shù)據(jù)離線分析，具備便捷的彈性擴(kuò)縮容能力，極致分析性能和豐富的企業(yè)級特性，目前已經(jīng)與中國地震臺網(wǎng)中心、海王集團(tuán)、莉莉絲游戲、極客邦科技等諸多行業(yè)企業(yè)達(dá)成合作，深度助力各個行業(yè)數(shù)字化轉(zhuǎn)型。未來，BitEngine將繼續(xù)增強功能以支撐廣告業(yè)務(wù)場景，包括：引擎集成數(shù)據(jù)編碼，使編碼對用戶透明；提供細(xì)粒度的緩存以緩存部分重復(fù)表達(dá)式的計算結(jié)果；優(yōu)化表達(dá)式解析等。文章來源地址http://www.zghlxwxcb.cn/news/detail-660317.html