1.業(yè)務(wù)背景

DMP（數(shù)據(jù)管理平臺）為廣告部門提供B站用戶數(shù)據(jù)的管理。主要功能包括用戶標(biāo)簽收集存儲，標(biāo)簽市場建設(shè)，人群包圈選，人群畫像分析，人群/特征定向幾大功能模塊。

其中人群包圈選和人群畫像分析是兩大核心功能。對設(shè)計，性能，擴(kuò)展性，可維護(hù)性都有比較高的要求。也是本文中要討論的ClickHouse技術(shù)的應(yīng)用場景。在實踐中，我們利用ClickHouse的bitmap相關(guān)功能，實現(xiàn)了人群包的實時預(yù)估和計算，也實現(xiàn)了人群包畫像的分鐘級計算。

下面先簡單介紹下人群包圈選和人群畫像兩個功能。

 1.1 人群圈選

所謂人群圈選，就是由用戶根據(jù)標(biāo)簽指定一系列規(guī)則，然后通過這個規(guī)則把滿足條件的人群圈選出來。假設(shè)我們用戶有“性別”，“年齡”，“地域”三個維度的標(biāo)簽，那么圈選規(guī)則就可以是“性別男，年齡>30，北京地區(qū)”。該系統(tǒng)需要根據(jù)圈選規(guī)則實時輸出滿足條件的人數(shù)和人群包。

圖片

如上圖所示，用戶使用了性別，年齡，地域三個標(biāo)簽取了交集，在下方實時顯示了對應(yīng)的覆蓋人數(shù)。

這里的技術(shù)難點在于

• 用戶的圈選的規(guī)則非常靈活，可能涉及數(shù)十種標(biāo)簽或人群包的交并運算，并且要求實時顯示計算結(jié)果。商業(yè)DMP中現(xiàn)有大約數(shù)百種標(biāo)簽，hive表中原始數(shù)據(jù)量PB級，如果采用直接查hive表的方式，顯然是無法滿足性能要求的。
• 人群包數(shù)量多，目前日新增數(shù)百個人群包，加上需要刷新的舊人群包，每天需要計算上萬個人群包。

因此基于以上需求，需要設(shè)計一種高效靈活，可擴(kuò)展的人群圈選手段。

 1.2 人群畫像

用戶打好人群包之后，可以對人群包中的用戶特征分析，如查看用戶的年齡，性別，地域分布，興趣愛好，up主關(guān)注，互動等等。例如下圖所示：

圖片

圖片

圖片

計算用戶畫像的基本原理是需要用人群包中的用戶id與每一個需要洞察的標(biāo)簽值所對應(yīng)的用戶id取交集，求出交集的人數(shù)后，計算該標(biāo)簽值在人群包中的百分比或TGI。例如：標(biāo)簽值"男"占比XX%, 標(biāo)簽值"女"占比XX% 。人群畫像的技術(shù)難點有：

• 人群包人數(shù)多，從數(shù)萬到億。
• 計算量大，目前畫像包含數(shù)十個維度，每日按人群包X維度計算百分比和tgi排名，涉及數(shù)億次bitmap交并運算。

最早的DMP使用離線hive sql進(jìn)行畫像計算，平均一個包畫像要等待2個小時，引入ClickHouse Bitmap技術(shù)后，畫像時間降到了分鐘級。

2.基于bitmap的人群圈選

2.1 bitmap基本原理及其在

人群圈選中的應(yīng)用

bitmap是一種數(shù)據(jù)結(jié)構(gòu)，可以用來表示一系列正整數(shù)的集合。底層是一系列連續(xù)的二進(jìn)制bit位，每個bit位有一個索引序號，依次用1,2,3,4,5...自然數(shù)編號。每個bit位有兩種狀態(tài)，0或1。如果bit位為0表示這一位對應(yīng)的索引序號的數(shù)字不在集合里，相反，如果bit位為1，表示對應(yīng)的索引序號的數(shù)字在集合中。例如bitmap內(nèi)容是01101,其中第2，3，5位（從左到右）是1，則該bitmap代表整數(shù)集合{2,3,5}。

B站用戶id是一個64位正整數(shù)，從1開始編號，無限增加。根據(jù)前面的描述，可以用bitmap來代表一系列id的集合。也就是說每個人群包的id集合都可以用一個bitmap來表示。

我們可以在邏輯上給每個標(biāo)簽值創(chuàng)建一個bitmap，表示所有具有該標(biāo)簽屬性的人群。這樣人群包的圈選就等價于多個標(biāo)簽bitmap的交并差運算。以前面提到的規(guī)則”性別男，年齡>30，北京地區(qū)”為例，人群圈選過程如下：

圖片

如圖所示，系統(tǒng)預(yù)先分別給男，>30歲，北京地區(qū)建立三個bitmap索引，如果相應(yīng)索引位的id在集合中，則把對應(yīng)位置的bit位設(shè)置為1。根據(jù)人群圈選規(guī)則，對三個bitmap進(jìn)行AND位運算，得到最終bitmap結(jié)果，也就是最終的人群包中包含{2,5,7,9}四個id。

以上就是基于bitmap圈選人群包的基本原理，在具體應(yīng)用中，還解決了很多工程上的問題，例如：

• 支持可擴(kuò)展的，任意維度的標(biāo)簽圈選。目前支持標(biāo)簽數(shù)量>300種，總數(shù)據(jù)量>1PB
• 打通離線數(shù)倉與ClickHouse之間的數(shù)據(jù)流，實現(xiàn)數(shù)倉到ClickHouse和ClickHouse到數(shù)倉的雙向數(shù)據(jù)格式轉(zhuǎn)換和傳輸，以及標(biāo)簽元數(shù)據(jù)管理機(jī)制。
• 一個包含億級別的bitmap大小有數(shù)百MB，如果只存儲在單個bitmap中會導(dǎo)致計算效率下降，因此需要對bitmap的存儲方式進(jìn)行優(yōu)化。
• 開發(fā)相比原始ClickHouse sql更易于使用的DSL，通過DSL提高系統(tǒng)的易用性，擴(kuò)展性和執(zhí)行效率。

 2.2 實踐中遇到的bitmap相關(guān)問題

在具體實踐中，我們發(fā)現(xiàn)bitmap可以很好的解決離散標(biāo)簽值的計算，對于億級的人群計算通常可以在5秒內(nèi)完成。可以滿足大多數(shù)人群計算需求。但是仍然存在一些明顯的問題。

id不連續(xù)導(dǎo)致的性能問題

ClickHouse中使用Roaring Bitmap存儲bitmap數(shù)據(jù)，而在Roaring Bitmap內(nèi)部，數(shù)據(jù)存儲在不同類型的container中，不同類型的container具有不同的空間成本和計算時間復(fù)雜度。Roaring Bitmap內(nèi)的數(shù)據(jù)存儲為哪種類型的container是由數(shù)據(jù)特性決定的，其中一個重要特性就是數(shù)據(jù)的連續(xù)性。分布稀疏的數(shù)據(jù)連續(xù)性低，在Roaring Bitmap中消耗的空間成本和計算時間復(fù)雜度都會更高（有關(guān)Roaring Bitmap的內(nèi)部存儲結(jié)構(gòu)及其對計算存儲性能的影響在此不做詳細(xì)論述，有興趣的讀者可參見文章基于改進(jìn)字典的大數(shù)據(jù)多維分析加速實踐中的第4章節(jié)）。

B站用戶的id是整型數(shù)據(jù)，我們在實踐中發(fā)現(xiàn)，id的分布非常稀疏，連續(xù)性低，這就造成bitmap體積膨脹，無法達(dá)到最佳性能，尤其是在計算畫像時，需要對數(shù)百萬的bitmap進(jìn)行交并運算，bitmap體積過大，對磁盤IO和CPU都有很大的壓力。因此如何采用合適的方法讓bitmap中的id盡量連續(xù)分布，是我們的一個主要優(yōu)化方向。

對于非離散標(biāo)簽圈選支持受限

DMP的標(biāo)簽中大部分都是離散標(biāo)簽查詢，每個標(biāo)簽值對應(yīng)一個bitmap。所謂離散標(biāo)簽值是指枚舉類的標(biāo)簽值，例如性別，年齡，地域，關(guān)注的up主都屬于此類。對于這種標(biāo)簽，每個標(biāo)簽值對應(yīng)的id聚合成bitmap后寫入ClickHouse是比較自然的選擇，ClickHouse對此類標(biāo)簽的交并查詢支持也很好。

但是在業(yè)務(wù)需求中，還存在一些非離散的指標(biāo)查詢，例如：“找出最近一個月某個廣告單元曝光次數(shù)大于N次的人”，“找出最近一個月某稿件播放時長大于N分鐘的人”。這些查詢的特點是需要在一定時間范圍內(nèi)對某個實體的相關(guān)指標(biāo)進(jìn)行聚合，以廣告曝光次數(shù)為例，對應(yīng)的hive sql大概如下所示：

SELECT
id
FROM (SELECT id, unit_id FROM ad_event_table WHERE
event='show' -- 曝光
AND unit_id IN (11111, 22222) -- 單元id列表
AND log_date >= '${yyyyMMdd, -360d}' -- 近一年
GROUP BY unit_id, id -- 按id + unit_id聚合
HAVING COUNT(1) > N -- 找出每個單元曝光次數(shù)大于N次的id ) t0
GROUP BY id -- 所有單元曝光次數(shù)>N的id進(jìn)行去重

如果直接執(zhí)行一個這樣一個hive sql，涉及的廣告曝光底表近一年的數(shù)據(jù)可能有數(shù)百G之多，至少要幾分鐘才會獲得結(jié)果，顯然是無法滿足dmp人數(shù)實時預(yù)估的要求的。

如果把一年的明細(xì)數(shù)據(jù)導(dǎo)入ClickHouse，在ClickHouse中做類似的查詢并把id實時聚合成bitmap，同樣面臨數(shù)據(jù)量大，無法滿足秒級人數(shù)預(yù)估的要求。作為一個折中的辦法，DMP中對于類似的查詢規(guī)定了一系列固定的時間窗口，如近30天，60天，90天，180天等等，事先通過離線任務(wù)按照固定的時間窗口對每個指標(biāo)進(jìn)行預(yù)聚合，把每個固定時間窗口內(nèi)滿足某個指標(biāo)的人事先聚合成bitmap寫入ClickHouse，用戶圈人的時候只能對固定的幾個時間窗口內(nèi)的指標(biāo)進(jìn)行圈選。還是以上面單元近一年曝光為例，ClickHouse中的查詢?nèi)缦拢?/p>

SELECT groupBitmapOr(uid_index) AS `uid_index` -- id bitmap
FROM tag_index_table
WHERE (tag_name='ad_show') -- 廣告曝光
AND (log_date='${yyyyMMdd}') -- 每天更新全量數(shù)據(jù)
AND (tag_value IN ('360D-11111','360D-22222')) -- 事先聚合好360天的單元曝光，把范圍查詢變成幾個固定時間區(qū)間的點查
AND (metric>=N) -- 曝光指標(biāo) > N

上述查詢是把采用預(yù)聚合的方法把標(biāo)簽值(單元id)+時間(天數(shù))+指標(biāo)值(metric)進(jìn)行聚合，可以把范圍查詢近似成點查，滿足實時計算的需求，通常也可以在秒級返回結(jié)果。但是這種方案仍然有以下問題：

• 預(yù)聚合數(shù)據(jù)量大，多個時間窗口存在數(shù)據(jù)冗余，某些標(biāo)簽要處理每天都要處理近一年的數(shù)據(jù)，有數(shù)百G到TB級，并且30，60，90等不同時間窗口存在重疊，有數(shù)據(jù)冗余。
• 標(biāo)簽值x指標(biāo)值造成標(biāo)簽數(shù)據(jù)膨脹。指標(biāo)值(metric)為非離散數(shù)據(jù), 如曝光次數(shù)，播放時長，指標(biāo)值可能在0到數(shù)千之間分布，假設(shè)某個廣告單元有1000個指標(biāo)值，那僅這一個廣告單元就會有1000個bitmap（每個bitmap對應(yīng)一個指標(biāo)值），這就造成表中的數(shù)據(jù)行數(shù)很多，索引變大，增加了內(nèi)存和緩存的開銷。
• 圈選方式不靈活。預(yù)處理的時間窗口只能處理一些典型的查詢，還有很多客戶就是要求實時圈選任意日期范圍內(nèi)的指標(biāo)，對于這部分需求ClickHouse無法滿足，只能采用spark離線計算。系統(tǒng)就分成了ClickHouse實時計算和spark離線計算兩個部分，增加了系統(tǒng)的復(fù)雜度和開發(fā)成本。

基于以上原因，我們也需要尋找一種更高效，更靈活的非離散指標(biāo)標(biāo)簽圈選方案。

3.ClickHouse字典服務(wù)

ClickHouse字典服務(wù)是B站ClickHouse團(tuán)隊針對多個需要在ClickHouse中用Roaring Bitmap做交并補(bǔ)計算的場景而設(shè)計開發(fā)的一套字典映射服務(wù)。關(guān)于ClickHouse字典服務(wù)的架構(gòu)及實現(xiàn)，本文不做詳細(xì)介紹，感興趣的讀者可參見文章基于改進(jìn)字典的大數(shù)據(jù)多維分析加速實踐中的4.3章節(jié)，本文下一章節(jié)主要闡述該服務(wù)在DMP場景下的應(yīng)用姿勢及效果。

4.ClickHouse字典服務(wù)在DMP中的應(yīng)用

4.1 應(yīng)用姿勢

首先，使用ClickHouse字典服務(wù)對于DMP場景有以下兩個好處：

• 字典服務(wù)的id是按順序分配的，可以讓id集中到更小的空間里，對于bitmap來說，id越集中，所生成的bitmap體積越小，運算效率越高。
• 標(biāo)簽圈選不再局限于整數(shù)類型的id，通過字典服務(wù)把任意字符串映射成一個整數(shù)，比如設(shè)備號，buvid等等，為將來的產(chǎn)品功能擴(kuò)充提供了更大的可能性。

加入字典服務(wù)后，整個數(shù)據(jù)流程如下：

圖片

如圖所示，在原始的id明細(xì)表調(diào)用字典服務(wù)做一次id映射，然后把映射后的id聚合成bitmap。具體還做了以下優(yōu)化：

• 為了提高效率，減少線上壓力，字典服務(wù)每天導(dǎo)出一張離線hive表，業(yè)務(wù)方先關(guān)聯(lián)hive表獲取映射id，如果離線hive表中不存在，則通過RPC實時調(diào)用字典服務(wù)。字典初始化之后，離線表的映射率通常在90%以上，可以極大的減少線上服務(wù)的實時壓力。
• 優(yōu)化了ClickHouse中不同shard中id的分片算法，每個id是一個64位整數(shù)，給定N個分片，則取個id的高48位（17~64位）對N取模，模數(shù)相同的id屬于通一個bitmap分片。之所以采用這種方法分片，是考慮到ClickHouse bitmap存儲的特點，讓低16位連續(xù)的id盡量處于同一個分片中，因為bitmap中連續(xù)的bit位越多，可以采用壓縮算法減少體積，提高計算效率。經(jīng)過測試，在同等條件下，這種優(yōu)化的分片方式比id直接對分片數(shù)N取模，要節(jié)省30%的存儲，計算速度快一倍以上。

 4.2 優(yōu)化效果

引入ClickHouse字典服務(wù)后，我們在存儲成本、寫入性能、查詢性能等方面均取得了顯著收益，具體如下文所述。

存儲成本收益

存儲空間上，對于千萬到上億級別的bitmap，體積減少了約4.5倍，對于萬級別的小bitmap減少約1.4倍，平均減少3倍左右。bitmap越大，收益越大。

整體存儲空間收益如下圖所示：

圖片

查詢性能收益

對于查詢延遲較高的人群畫像計算，引入ClickHouse字典服務(wù)后查詢性能大幅提升，end2end查詢延遲由之前的20分鐘提升到3分鐘，提升了6.7倍。

從ClickHouse引擎?zhèn)扔^察，DMP場景整體查詢P50，P90延遲優(yōu)化效果如下圖所示：

圖片

寫入性能收益

在寫入方面，p90寫入延遲降低了2x+，p50寫入延遲降低了1.5x。

整體寫入P50，P90延遲優(yōu)化效果如下圖所示：

圖片

5  BSI原理簡介及其在ClickHouse中的功能實現(xiàn)

5.1 BSI原理簡介

BSI(Bit-slice index)的數(shù)據(jù)結(jié)構(gòu)由一組bitmap組成，其中每個bitmap用于表示二進(jìn)制整型metric在對應(yīng)比特位上取值為1的實體id集合。

下圖展示了將5個實體id及其對應(yīng)的整型metric value轉(zhuǎn)換成BSI表示形式后的效果：

圖片

從上圖的轉(zhuǎn)換中，我們可以總結(jié)出BSI數(shù)據(jù)結(jié)構(gòu)的以下特征：

• BSI的slice個數(shù)由最大整型值的二進(jìn)制位數(shù)決定
• 每個slice都是一個bitmap
• 每個slice對應(yīng)一個比特位：slice_i 存儲第i個比特位上取值為1的metric value對應(yīng)的所有實體id的集合

如上文所述，bitmap適用于離散值標(biāo)簽的人群圈選計算場景，而BSI則更適合針對連續(xù)值指標(biāo)的人群圈選計算場景。除此之外，BSI也適合用于人群圈選完成之后的人群效果指標(biāo)分析場景（比如，計算某個指定人群包的平均曝光次數(shù)）。

5.2 BSI在ClickHouse中的功能實現(xiàn)

BSI數(shù)據(jù)類型

在ClickHouse中，我們將BSI封裝成一個新的數(shù)據(jù)類型，用戶可以根據(jù)自己的需求定義BSI類型字段并配合ClickHouse中的aggregating mergetree引擎建表，建表示例如下：

CREATE TABLE test.bsi
(
    `log_date` Date,
    ...
    `ck_bucket` UInt32,
    `bsi_agg` AggregateFunction(bsi_merge_agg, BSI)
)
ENGINE = AggregatingMergeTree
PARTITION BY log_date
ORDER BY ck_bucket
TTL ...

具體實現(xiàn)上，BSI本質(zhì)上就是Bitmap Array，所以我們并沒有重新實現(xiàn)一個獨立的數(shù)據(jù)類型，而是基于ClickHouse內(nèi)部的自定義數(shù)據(jù)類型注冊機(jī)制，將Bitmap Array類型注冊為一個新的BSI數(shù)據(jù)類型。

除了各個比特位對應(yīng)的slice bitmaps之外，BSI類型數(shù)據(jù)中還存儲了一個existence bitmap（EBM），用于表示所有metric取值非空(not null)的實體id集合。EBM可用于加速某些BSI計算，并且對于某些BSI functions而言EBM是必需的。

BSI Functions

我們在ClickHouse中實現(xiàn)了許多BSI Functions，包括:

• 用于從明細(xì)數(shù)據(jù)構(gòu)建BSI的bsi_build
• 用于對單個BSI進(jìn)行過濾，求和等操作的bsi_filter, bsi_sum, bsi_range, bsi_lt, bsi_gt, bsi_topk, etc
• 用于對BSI數(shù)據(jù)列做聚合的bsi_add_agg, bsi_merge_agg, etc

關(guān)于各個BSI Function的功能細(xì)節(jié)這里不做詳細(xì)闡述，有興趣的讀者可參見引用[2]。

由于BSI Functions的底層實現(xiàn)上依賴于Roaring Bitmap的交并補(bǔ)計算，所以對組成BSI的Roaring Bitmap做ClickHouse字典服務(wù)映射也能夠大幅提升BSI Functions的計算性能。

6.BSI+字典服務(wù)方案在DMP場景的落地及效果

6.1 落地姿勢

針對DMP場景下連續(xù)值指標(biāo)圈選困難的問題，我們基于連續(xù)值指標(biāo)的明細(xì)數(shù)據(jù)構(gòu)建出連續(xù)值指標(biāo)的BSI數(shù)據(jù)，然后導(dǎo)入到ClickHouse中通過BSI Functions即可對連續(xù)值指標(biāo)進(jìn)行任意時間范圍內(nèi)的圈選，解決了原來只能預(yù)聚合固定時間窗口的查詢限制。

下圖是寫入與查詢BSI數(shù)據(jù)的整體流程：

圖片

BSI數(shù)據(jù)寫入

我們的明細(xì)數(shù)據(jù)存儲在離線數(shù)倉Hive表中，利用Spark程序?qū)ive上的明細(xì)數(shù)據(jù)轉(zhuǎn)換成BSI（bitmap array）結(jié)構(gòu)后寫入到ClickHouse表中。其中，Spark數(shù)據(jù)同步程序會調(diào)用生成BSI數(shù)據(jù)的UDAF將明細(xì)數(shù)據(jù)組裝成為BSI，同時會調(diào)用ClickHouse字典服務(wù)進(jìn)行字典映射轉(zhuǎn)換，從而降低BSI的存儲成本和查詢延遲。

以上文提及的廣告曝光查詢?yōu)槔褂肂SI后，數(shù)倉開發(fā)在進(jìn)行數(shù)據(jù)處理時不再需要按照標(biāo)簽值(單元id)+時間(時間窗口天數(shù))+指標(biāo)值(metric)進(jìn)行聚合，每天只需要處理當(dāng)天的增量日志即可，把當(dāng)天增量的單元曝光聚合成一個BSI即可。

BSI數(shù)據(jù)查詢

上述BSI寫入ClickHouse后，業(yè)務(wù)方就可以通過bsi相關(guān)的函數(shù)在ClickHouse中實時查詢，以廣告曝光為例，一個典型的表結(jié)構(gòu)和查詢語句如下所示：

CREATE TABLE tag_bitmap_bsi
(
    `tag_name` String,
    `tag_value` String,
    `log_date` Date,
    `sp_bucket` UInt32,
    `sk_bucket` UInt32,
    `ck_bucket` UInt32,
    `bsi_agg` AggregateFunction(bsi_merge_agg, BSI)
)
ENGINE = ReplicatedAggregatingMergeTree(...)
PARTITION BY (toYYYYMMDD(log_date), tag_name)
ORDER BY (sp_bucket, tag_value, ck_bucket)
TTL ...
    
 
SELECT groupBitmapOr(bsi_ge(bsi_agg, N)) AS `uid_index` -- 180天內(nèi)曝光次數(shù)>N次的id組成的bitmap
FROM
(
   SELECT bsi_add_agg(bsi_agg) AS `bsi_agg`
   FROM
   (
      SELECT tag_value, bsi_merge_aggMerge(bsi_agg) AS `bsi_agg` -- 一天之內(nèi)的指標(biāo)合并（去重）
      FROM
        tag_bitmap_index_mapped_bsi
      WHERE (tag_name = 'ad_show') AND (log_date > '${yyyyMMdd}' - INTERVAL 180 DAY -- 近180天 ) AND (tag_value IN ('11111', '22222'))
              GROUP BY tag_value, log_date
   )
   GROUP BY
   tag_value -- 最終累加出180天內(nèi)所有的指標(biāo)
)

6.2 落地過程遇到的問題及其解決方案

在將BSI落地到，我們遇到了以下問題：

• 在Spark數(shù)據(jù)同步程序中生成的單個BSI過大，導(dǎo)致spark中的一個row對象過大，在Kryo Serializer做序列化的過程中出現(xiàn)buffer overflow的問題。
• 寫入到ClickHouse各個分片的BSI里的bitmap數(shù)據(jù)分布稀疏，影響B(tài)SI查詢性能。
• 寫入到ClickHouse單個分片的BSI的基數(shù)過大（即包含的實體id過多），導(dǎo)致單分片BSI的查詢性能較低。
• ClickHouse中由于分批寫入導(dǎo)致存儲的BSI個數(shù)過大，影響B(tài)SI的查詢性能。

為了解決上述問題，我們做了以下設(shè)計與優(yōu)化：

圖片

• 在Spark數(shù)據(jù)同步程序中對明細(xì)數(shù)據(jù)做分桶處理，以避免單條BSI記錄過大導(dǎo)致Kryo Serializer的buffer overflow問題。
• 在Spark數(shù)據(jù)同步程序中引入ClickHouse字典服務(wù)，對分布稀疏的實體id做字典映射，提高BSI內(nèi)數(shù)據(jù)的連續(xù)性，從而提升BSI查詢性能。
• 使用實體id的高48位做sharding，讓實體id高48位相同的數(shù)據(jù)都寫入到相同的ClickHouse分片中，降低單個分片中BSI的基數(shù)，同時進(jìn)一步提高BSI內(nèi)數(shù)據(jù)的連續(xù)性，從而提升BSI查詢性能。
• 使用AggregatingMergeTree作為表引擎，分批寫入的小BSI數(shù)據(jù)異步聚合成更大的BSI數(shù)據(jù)，減少ClickHouse中的BSI記錄個數(shù)，從而提升BSI查詢性能。

6.3 落地效果與收益

產(chǎn)品功能增強(qiáng)

引入BSI后，DMP在產(chǎn)品功能上得到以下增強(qiáng)與優(yōu)化：

• 實現(xiàn)了任意日期的指標(biāo)人群圈選，不再局限于幾個固定的時間窗口，擴(kuò)展了業(yè)務(wù)的應(yīng)用場景。
• 去除了部分通過spark sql離線計算流程，把所有人群包相關(guān)的計算統(tǒng)一到ClickHouse里，簡化了系統(tǒng)設(shè)計。
• 對于廣告曝光，稿件播放這種數(shù)據(jù)量大標(biāo)簽時間范圍從30天提升到一年，提升了產(chǎn)品的能力。

整體場景查詢性能

圖片

受益于BSI和字典服務(wù)對查詢性能和存儲成本的優(yōu)化，生產(chǎn)業(yè)務(wù)在使用BSI+字典服務(wù)的方案后，將之前30天~90天的時間范圍圈選擴(kuò)大到了一年，目前整體的p50查詢延遲可以保證在500ms左右，p90查詢延遲可以保證在5s左右。

存儲成本收益

相較于通過預(yù)聚合不同時間范圍的bitmap數(shù)據(jù)來支持任意日期范圍的人群圈選，BSI+字典服務(wù)的方案在存儲成本上具有顯著優(yōu)勢，以下是一個支持5天內(nèi)任意日期范圍圈選場景下，預(yù)聚合bitmap方案和BSI方案的存儲成本對比：

可以看到，BSI+字典服務(wù)的方案與預(yù)聚合Bitmap方案的存儲比約為1:21。

查詢性能收益

相較于原Bitmap方案，BSI+字典服務(wù)的方案在查詢性能方面也有明顯優(yōu)勢。下圖為一個90天范圍內(nèi)圈選場景，原Bitmap方案和BSI方案的查詢延遲對比：

圖片

7.總結(jié)與展望

本文重點介紹了DMP場景的業(yè)務(wù)需求及實踐過程中遇到的問題，并詳細(xì)闡述了我們?nèi)绾卫肅lickHouse字典服務(wù)和BSI技術(shù)優(yōu)化增強(qiáng)DMP產(chǎn)品功能，提升整體查詢性能，降低資源成本。

目前BSI+字典服務(wù)方案已經(jīng)在B站商業(yè)化DMP場景完成落地上線，未來我們將重點在以下方向完善增強(qiáng)我們的產(chǎn)品功能：

• 工程化BSI+字典服務(wù)方案的數(shù)據(jù)接入流程，為用戶提供更為便利的接入體驗，讓BSI+字典服務(wù)方案賦能更多商業(yè)化業(yè)務(wù)場景。
• 探索BSI+字典服務(wù)的實時鏈路建設(shè)，在低成本低查詢延遲的前提下，為用戶提供更高的end2end數(shù)據(jù)時效性。
• 得益于字典對人群圈選性能的提升，商業(yè)化業(yè)務(wù)正在嘗試擴(kuò)展人群圈選的業(yè)務(wù)范圍，例如投放端定向人數(shù)預(yù)估，預(yù)計24年Q4可以落地。
• 商業(yè)化DMP中嘗試BSI的更多應(yīng)用場景，例如用于多維度廣告相關(guān)指標(biāo)人群的畫像分析。

引用

• BSI Introduction From Hologres（https://www.alibabacloud.com/help/en/hologres/use-cases/profile-analysis-bsi-optimization-beta）
• BSI Function Introduction From Hologres（https://www.alibabacloud.com/help/en/hologres/user-guide/bsi-functions）