百度MEG数据中台：ClickHouse实时分析架构实践-代码聚汇网

百度MEG数据中台：ClickHouse实时分析架构实践

超级飞侠Fly

1. 百度MEG数据中台的技术架构演进背景

百度MEG（Mobile Ecosystem Group）作为百度核心业务板块，承载着搜索、信息流、小程序等关键业务线。随着数据量从TB级向PB级跃迁，传统Hadoop生态的批处理模式已无法满足实时分析需求。2018年起，团队开始探索"T+0"数据服务能力，这直接推动了数据中台从Lambda架构向Kappa架构转型。

ClickHouse的引入并非偶然。在对比测试中，其单表查询性能达到Greenplum的8-12倍，在SSB（Star Schema Benchmark）测试中更是展现出对星型模型的天然亲和力。特别是在广告效果分析场景，面对日均千亿级的曝光-点击-转化事件流，ClickHouse的MergeTree引擎展现出惊人的吞吐能力。

2. ClickHouse在湖仓一体中的定位与选型

2.1 与现有技术栈的融合路径

百度数据中台原有技术栈包含：

数据湖：基于HDFS的原始数据存储
计算引擎：Spark/Flink混合部署
即席查询：Presto+Alluxio加速层

ClickHouse的定位是"实时分析加速层"，其部署模式具有三个显著特点：

冷热分离存储：最近7天数据存本地SSD，历史数据通过S3协议对接百度对象存储BOS
分层部署：设置shard层和merge层，shard节点承载原始数据写入，merge节点负责跨分片聚合
智能路由：查询优化器自动识别SQL模式，简单查询直连shard，复杂分析走merge层

2.2 关键性能指标对比

在广告CTR预测场景的测试数据：

指标	Hive 3.0	Spark SQL	ClickHouse
10亿数据扫描	78s	45s	6.2s
百维聚合	210s	92s	8.7s
99分位延迟	不稳定	35s	1.2s

3. 核心技术创新点解析

3.1 自适应数据分片策略

针对百度业务特性，研发了动态分片算法：

sql复制-- 分片键智能选择算法伪代码
FUNCTION chooseShardingKey(table):
    cardinality = SELECT count(DISTINCT column) FROM table 
                  FOR columns IN [dt,userid,deviceid,...]
    IF max(cardinality) > 10M THEN
        RETURN column WITH max(cardinality)
    ELSE
        RETURN hash_combine(dt, deviceid)

该策略使得广告效果分析查询的跨节点传输量减少62%，查询延迟降低40%。

3.2 混合存储引擎实践

创新性地组合使用多种表引擎：

实时流水表：使用ReplacingMergeTree+Version列处理重复数据
维度表：采用EmbeddedRocksDB引擎实现高效JOIN
中间结果表：配置Memory引擎作为临时计算缓存

典型建表示例：

sql复制CREATE TABLE ads_click_stream
(
    dt DateTime,
    user_id UInt64,
    ad_id UInt32,
    click_time DateTime,
    -- 其他字段...
    _version UInt64 MATERIALIZED toUnixTimestamp(now())
)
ENGINE = ReplacingMergeTree(_version)
PARTITION BY toYYYYMM(dt)
ORDER BY (ad_id, user_id)

4. 典型业务场景落地案例

4.1 实时广告效果分析

构建的Pipeline架构：

Flink消费Kafka原始日志
实时ETL后写入ClickHouse
基于物化视图预计算核心指标

sql复制CREATE MATERIALIZED VIEW ads_performance_mv
ENGINE = AggregatingMergeTree
PARTITION BY dt
ORDER BY (ad_id, platform)
AS SELECT
    ad_id,
    platform,
    dt,
    countState() AS impressions,
    sumState(click) AS clicks,
    sumState(conversion) AS conversions
FROM ads_click_stream
GROUP BY ad_id, platform, dt

该方案使广告主看板的数据延迟从小时级降至秒级，QPS峰值达到12万/秒。

4.2 用户行为路径分析

利用ClickHouse的Window函数实现：

sql复制SELECT
    user_id,
    sequenceMatch('(?1).*(?2).*(?3)')(dt, event_type = 'page_view', event_type = 'add_cart', event_type = 'checkout') AS is_converted
FROM user_events
GROUP BY user_id

相比原Hive方案，路径分析速度提升120倍，内存消耗降低75%。

5. 运维实践与性能调优

5.1 资源隔离方案

通过cgroups实现三级资源隔离：

查询级别：设置max_memory_usage_per_query
用户级别：配置quotas.xml限制业务线配额
物理资源：采用docker-compose部署，限制CPU shares

5.2 常见问题处理手册

案例1：写入瓶颈
现象：INSERT吞吐从50万行/秒降至8万行/秒
根因：大量小批量写入导致merge压力
解决方案：

xml复制<!-- config.xml 调整 -->
<merge_tree>
    <parts_to_delay_insert>500</parts_to_delay_insert>
    <parts_to_throw_insert>1000</parts_to_throw_insert>
</merge_tree>

案例2：JOIN性能劣化
优化前：

sql复制SELECT a.* FROM fact_table a
JOIN dimension_table b ON a.key = b.key

优化后：

sql复制SELECT a.* FROM fact_table a
WHERE a.key IN (SELECT key FROM dimension_table)

6. 未来演进方向

当前正在测试的Feature：

Projection功能：预计算常用维度组合，查询速度再提升3-5倍
Lightweight Delete：解决合规场景下的数据删除痛点
与Baidu AI平台集成：探索模型推理UDF在ClickHouse中的直接调用

在A/B测试场景的初步数据显示，将特征计算下沉到ClickHouse后，特征生成耗时从分钟级降至亚秒级，这为实时个性化推荐打开了新的可能性。