在當(dāng)今數(shù)字化營銷時代，廣告業(yè)務(wù)的精準(zhǔn)度和時效性成為核心競爭力。實時廣告圈人（Real-Time Audience Targeting）作為精準(zhǔn)營銷的關(guān)鍵環(huán)節(jié)，要求系統(tǒng)能夠在極短時間內(nèi)，基于用戶實時行為數(shù)據(jù)，動態(tài)地篩選和圈定目標(biāo)人群，并觸發(fā)相應(yīng)的廣告投放。ClickHouse，作為一款開源的列式數(shù)據(jù)庫管理系統(tǒng)，憑借其卓越的實時分析能力和極高的查詢性能，已成為支撐此類業(yè)務(wù)場景的理想技術(shù)選型之一。本文將探討ClickHouse在實時廣告圈人業(yè)務(wù)中的最佳實踐。
一、 業(yè)務(wù)場景與挑戰(zhàn)
實時廣告圈人的典型流程是：用戶發(fā)生一個行為（如瀏覽商品、點擊廣告、加入購物車），該行為日志被實時采集；系統(tǒng)立刻根據(jù)預(yù)設(shè)的規(guī)則（如“過去24小時內(nèi)瀏覽過汽車資訊但未下單的用戶”）對該行為進(jìn)行判斷；若命中規(guī)則，則該用戶ID被歸入特定人群包，并實時同步給廣告投放平臺進(jìn)行定向展示。
面臨的挑戰(zhàn)主要包括：
- 數(shù)據(jù)量巨大：用戶行為日志每日可達(dá)千億級別。
- 查詢延時要求極低：圈人判斷需要在毫秒到秒級完成。
- 查詢模式復(fù)雜：多為多維度、帶有時間窗口的過濾與聚合查詢。
- 高并發(fā)點查：需要快速查詢單個用戶的歷史行為序列以進(jìn)行實時判斷。
- 數(shù)據(jù)實時更新：需要支持用戶標(biāo)簽、人群包關(guān)系的實時更新與查詢。
二、 ClickHouse的核心優(yōu)勢
針對以上挑戰(zhàn)，ClickHouse展現(xiàn)了其獨特優(yōu)勢：
- 列式存儲與壓縮：極高的壓縮比大幅減少I/O，非常適合對寬表進(jìn)行少量列聚合過濾的查詢。
- 向量化執(zhí)行引擎：利用CPU SIMD指令，在單個操作中處理大量數(shù)據(jù)，極大提升聚合計算性能。
- 豐富的表引擎：如MergeTree系列引擎支持高性能的實時插入與查詢；AggregatingMergeTree和SummingMergeTree可預(yù)聚合數(shù)據(jù)；ReplacingMergeTree支持去重更新，為不同數(shù)據(jù)場景提供靈活支持。
- 強(qiáng)大的分布式能力：通過分片（Shard）與復(fù)制（Replica）輕松實現(xiàn)水平擴(kuò)展，保障海量數(shù)據(jù)下的處理能力與高可用性。
三、 實時廣告圈人架構(gòu)最佳實踐
1. 數(shù)據(jù)分層與表設(shè)計
- 貼源層：使用Kafka等消息隊列接收實時行為日志。ClickHouse通過
Kafka表引擎或MaterializedView直接消費，并寫入核心明細(xì)表。明細(xì)表通常采用ReplicatedReplacingMergeTree引擎，按事件時間（如event_date）分區(qū)，按用戶ID排序鍵，以支持按用戶快速檢索行為序列。 - 聚合層：為加速頻繁查詢，可創(chuàng)建物化視圖（Materialized View）或使用AggregatingMergeTree表，對明細(xì)數(shù)據(jù)按分鐘/小時粒度進(jìn)行預(yù)聚合（如計算用戶在過去1小時內(nèi)的點擊次數(shù)）。物化視圖在后臺自動計算，對應(yīng)用透明。
- 圈人結(jié)果層：存儲最終的人群包關(guān)系。可使用
ReplicatedReplacingMergeTree引擎，以人群包ID和用戶ID作為組合主鍵，支持用戶進(jìn)出人群包的實時更新。
2. 索引與查詢優(yōu)化
- 主鍵（排序鍵）設(shè)計：這是最重要的優(yōu)化點。應(yīng)遵循“高基數(shù)字段在前”的原則，將最常用于WHERE過濾和GROUP BY的字段（如
user<em>id,event</em>time）作為排序鍵。對于圈人查詢WHERE user<em>id = ? AND event</em>time > now() - 3600，此設(shè)計能實現(xiàn)超高效查找。 - 跳數(shù)索引：對于非主鍵列的常用過濾條件（如
ad<em>campaign</em>id,city），可創(chuàng)建SET、Bloom Filter等類型的跳數(shù)索引，加速數(shù)據(jù)塊定位。 - 避免JOIN：ClickHouse的JOIN性能相對較弱。實踐中，應(yīng)盡量通過“大寬表”或“預(yù)關(guān)聯(lián)”的方式，將維度信息冗余到事實表中，或者通過
IN子查詢替代JOIN。 - 使用近似查詢：對于去重計數(shù)（如計算UV），在可接受誤差范圍內(nèi)，優(yōu)先使用
uniqCombined等近似計算函數(shù)，性能可提升數(shù)倍。
3. 實時數(shù)據(jù)更新與同步
- 用戶標(biāo)簽或人群包關(guān)系的更新，可通過
INSERT+ReplacingMergeTree的“插隊”方式實現(xiàn)。查詢時使用FINAL關(guān)鍵字或通過GROUP BY ... argMax()方式獲取最新狀態(tài)。對于更高頻的更新，可考慮使用CollapsingMergeTree或VersionedCollapsingMergeTree引擎。 - 圈人結(jié)果需要實時同步至Redis或廣告投放端。可通過監(jiān)聽ClickHouse的
CHANGELOG（如使用MaterializedPostgreSQL引擎或Debezium+CDC），或者通過定期查詢增量變化的方式實現(xiàn)。
4. 集群部署與運維
- 采用分片副本架構(gòu)，確保負(fù)載均衡和數(shù)據(jù)高可用。使用
Distributed表引擎作為統(tǒng)一查詢?nèi)肟凇?/li> - 根據(jù)查詢模式（偏重近期數(shù)據(jù)）合理設(shè)置數(shù)據(jù)分區(qū)策略（如按天分區(qū)），并配置TTL自動淘汰過期數(shù)據(jù)，降低成本并提升近期數(shù)據(jù)查詢性能。
- 監(jiān)控系統(tǒng)資源（CPU、內(nèi)存、磁盤I/O），特別是
Merge操作和查詢隊列狀態(tài)，防止慢查詢拖垮集群。
四、 實踐案例與效果
某頭部電商廣告平臺，將用戶實時點擊、瀏覽、搜索行為日志接入ClickHouse集群。通過上述最佳實踐：
- 數(shù)據(jù)入庫延遲控制在秒級。
- 針對“過去30天購買過母嬰用品但最近7天未登錄”的復(fù)雜圈人查詢，響應(yīng)時間從Hive時代的數(shù)分鐘提升至亞秒級。
- 系統(tǒng)可穩(wěn)定支撐每秒數(shù)萬次的用戶實時行為判斷與人群包更新。
- 存儲成本因高壓縮比而顯著降低。
五、 與展望
ClickHouse以其卓越的實時分析能力，為實時廣告圈人業(yè)務(wù)提供了堅實的技術(shù)底座。成功的核心在于：貼合業(yè)務(wù)特點的精準(zhǔn)數(shù)據(jù)建模、極致的索引與查詢優(yōu)化、以及合理的集群架構(gòu)。隨著業(yè)務(wù)發(fā)展，未來可進(jìn)一步探索與機(jī)器學(xué)習(xí)平臺的結(jié)合，實現(xiàn)更智能、動態(tài)的實時人群規(guī)則引擎，并持續(xù)優(yōu)化資源利用效率，在性能與成本間取得最佳平衡。
