ClickHouse在实时数仓中的架构定位：从Lambda到Kappa架构的存储层演进分析
一、"我们的实时数仓真的实时吗？"
产品团队质疑我们的"实时数据看板"为什么显示的大盘数据比业务系统慢了3分钟，而宣传上说的是"实时"。技术上的真实原因是：我们使用的是Lambda架构——批处理层（每天凌晨的Spark ETL）负责全量数据、流处理层（Kafka→Flink→ClickHouse）负责增量数据。两套逻辑、两套代码，同步延迟从Kafka消费到ClickHouse写入累积了3分钟。
"实时数仓"不只是一个产品概念，更是一系列架构选择的结果。理解ClickHouse在Lambda和Kappa两种架构中的不同定位，是建设真正的实时数仓的前提。
二、Lambda架构中ClickHouse的角色与瓶颈
在Lambda架构中，ClickHouse通常作为"加速查询层"或"实时数据层"，承担实时数据写入和OLAP查询的职责。
角色定位：流处理结果（如Flink计算的5分钟窗口聚合）实时写入ClickHouse，批处理结果（如Spark的T+1全量计算）通过INSERT SELECT批量导入ClickHouse。ClickHouse负责统一的数据查询服务，面向BI和分析用户。
核心瓶颈：双写一致性。流处理结果和批处理结果在ClickHouse中同时存在时，查询层需要处理重叠时间窗口的数据去重和合并。这个"数据合并"逻辑是在查询时处理（通过argMax+版本号字段），增加了查询复杂度和延迟。
数据质量的挑战：流处理无法处理迟到数据（late arriving data），批处理可以覆盖这些数据。当流和批的结果不一致时，需要人工介入定位数据差异——这是Lambda架构运维成本的主要来源。
三、Kappa架构：用Kafka+ClickHouse替代批处理层
Kappa架构的核心思路是"一切皆流"——废除独立的批处理层，用Kafka保留全量数据，流处理引擎（Flink）统一处理实时和历史数据（通过Kafka重放）。
ClickHouse的新定位：在Kappa架构中，ClickHouse不再只是"加速查询层"，而是"统一持久化存储层"——所有处理结果（无论来自实时流还是重放历史流）都写入ClickHouse。ClickHouse承担了Lambda架构中HDFS/Hive的持久化存储职责。
关键挑战：Kafka的历史数据重放。当需要重新计算过去一周的指标时（因为业务逻辑变更），Flink需要重放Kafka中保存的一周原始数据。这要求Kafka的保留周期足够长，且ClickHouse能接受大量历史数据的Backfill写入而不影响正常查询。
四、从实践出发的架构建议
存量系统迁移：如果已经有Lambda架构在运行，不要急于切换到Kappa。先在局部场景（如实时风控、实时大屏）验证Kappa方案，积累经验后再考虑全面迁移。
ClickHouse的写入优化：在Kappa架构中，ClickHouse面临同时处理高吞吐实时写入和历史重放写入的情况。通过Buffer引擎表缓冲高频写入、通过Distributed表引擎分散写入负载、设置合理的TTL策略自动清理无需长期保留的流式数据。
查询层的统一：无论采用哪种架构，查询层都应提供统一的数据访问接口。ClickHouse的VIEW和MATERIALIZED VIEW可以用来在查询时处理数据的合并和去重逻辑，屏蔽底层架构的复杂性。
五、总结
ClickHouse在实时数仓中的定位正在从"加速查询层"向"统一存储层"演进。Lambda架构代表的是"流批分离"的设计哲学，Kappa架构代表的是"流批一体"的理想。选择哪种架构取决于团队对流处理和批处理的掌控能力。
对于正在建设实时数仓的团队，建议以Lambda架构起步（分工明确、风险可控），在实践中积累流处理和ClickHouse运维经验，再评估是否需要向Kappa架构演进。架构选型最重要的因素不是理论上的先进性，而是团队的驾驭能力。
