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