实时数仓架构实战：Kafka → Flink → 湖仓 → Doris/ClickHouse

长文技术整理分类：实时数仓阅读 5160评论 362026-04-23

KafkaFlinkDorisClickHouse

用一条实时看板链路讲清 ODS Topic、DWD 清洗、DWS 聚合、OLAP 查询和补偿机制。

实时数仓分层怎么落地

实时数仓可以借鉴离线 ODS/DWD/DWS/ADS，但不要照搬。实时链路更怕复杂逻辑和外部依赖。ODS 尽量保留原始事件；DWD 做清洗、字段标准化、维表补充；DWS 做窗口聚合和轻度汇总；ADS/OLAP 面向看板和接口。

Topic 命名建议包含层级、业务域、事件名，例如 ods_trade_order_event、dwd_trade_order_pay。分区数按峰值吞吐估算，不要所有 Topic 统一 12 个分区。Key 要兼顾局部有序和均匀分布。

kafka-consumer-groups.sh --bootstrap-server kafka:9092   --describe --group flink-dwd-trade-order

实时看板经常遇到迟到数据。Watermark 设置太激进，结果会漏；设置太保守，延迟会高。支付、物流、埋点三类数据迟到特征不同，不能统一一个 watermark。

WATERMARK FOR event_time AS event_time - INTERVAL '2' MINUTE

高频看板不要直接查明细流。建议构建分钟级或小时级聚合表，维度固定的指标从聚合表出，临时分析再查明细。ClickHouse 要关注 parts 数，Doris 要关注 tablet、compaction 和导入队列。

SELECT partition, count() parts, sum(rows) rows
FROM system.parts
WHERE table='dws_order_1min' AND active
GROUP BY partition
ORDER BY parts DESC;

不要只说“实时延迟 1 分钟”。要拆成采集延迟、Kafka Lag、Flink 处理延迟、Sink 写入延迟、OLAP 查询延迟。每段都有指标，排障时才不会互相甩锅。

实时任务失败、上游补发、维表修正、OLAP 写入失败都会发生。没有补偿机制的实时数仓只能靠手工改数。建议保留 ODS 原始 Topic 足够时间，DWD/DWS 支持按时间段重放，OLAP 写入要有幂等键。

补偿流程：
1. 停止下游看板或标记数据延迟
2. 从 Kafka 指定 offset/time 重放
3. Flink 使用 savepoint 或临时补数任务
4. OLAP 目标分区覆盖/merge
5. 跑行数、金额、UV 对账

实时数仓最重要的不是链路图画得复杂，而是每一层都能解释、能重跑、能对账。否则延迟指标看起来正常，业务结果可能已经错了。

如果把这篇内容落到真实项目里，建议至少补齐三类信息：第一是基线数据，包括日均数据量、峰值 QPS、任务耗时、存储大小和失败频率；第二是关键配置，包括并行度、分区数、TTL、超时时间、批大小、索引字段；第三是验证结果，包括上线前后耗时对比、资源消耗对比、核心指标对账和异常回滚记录。

写技术博客时也可以按这个顺序组织：先讲业务背景，再讲为什么原方案不稳，然后贴出关键配置或 SQL，最后用对比数据说明优化是否有效。这样文章不会空，也不会像模板填空。

另外，实时数仓要保留链路级运行手册：Kafka offset 如何回退、Flink savepoint 存在哪里、OLAP 目标表如何覆盖、看板延迟如何标记。这些内容比单纯画架构图更有价值。

本文按公开技术资料和生产经验重新整理，没有复制原文。真正落地到你的环境时，建议补充：集群版本、资源规格、任务截图、SQL 执行计划、核心监控曲线、上线前后对比数据。这样文章会更像真实生产复盘，也更适合长期维护。