ClickHouse 实时数仓架构实战：分层设计、实时管道与 Lambda/Kappa

离线数仓（T+1）：
□ 当天数据次日才能查（调度批处理）
□ 延迟：1 天 ~ 数小时
□ 适合：报表、月度统计、BI 宽表

实时数仓：
□ 数据产生后「分钟级/秒级」可查
□ 延迟：分钟级 ~ 秒级
□ 适合：实时看板、风控、运营决策、异常监控

核心转变：
□ 数据管道：批量 ETL → 流式管道（Kafka + 持续写入）
□ 计算模式：离线批处理 → 增量实时计算
□ 存储：分层离线仓库 → 实时明细 + 实时聚合共存

判断是否需要实时：
□ 决策时效：分钟级决策有价值 → 实时
□ 次日能接受 → 保持离线（实时是成本/复杂度）
□ 混合：热数据实时 + 冷数据离线（最常见的折中）

延迟对比：
离线：事件 → 当日批 → 次日查询（T+1）
实时：事件 → Kafka → 秒级入库 → 即时查询（秒~分钟）
→ 实时换的是「决策时效」，付的是「工程复杂度」

四层架构：
□ ODS（原始层）：原始数据贴源存放
  → Kafka → 实时落 ODS（明细原样）
□ DWD（明细层）：清洗、标准化、维度关联
  → 补全字段、统一口径、轻度加工
□ DWS（汇总层）：按主题/维度预聚合
  → 分钟级聚合、宽表（物化视图/聚合表）
□ ADS（应用层）：面向业务应用的最终结果
  → 指标卡片、榜单、风控特征

数据流：
Kafka → ODS（明细）→ DWD（清洗）→ DWS（聚合）→ ADS（应用）
每层都可能落在 ClickHouse 的不同表

分层的目的：
□ 口径统一：DWD 定义标准字段，下游一致
□ 故障隔离：ODS 原始可重放，上层可重算
□ 复用：DWS 预聚合服务多个 ADS

ClickHouse 中每层的形态：
ODS → MergeTree 明细表（append，可 TTL）
DWD → 清洗后的明细表（JOIN 字典补维度）
DWS → AggregatingMergeTree 预聚合表
ADS → 物化视图/结果表（直接供查询/展示）

实时数仓的组件拼图：
□ 消息队列：Kafka/Pulsar（数据缓冲、削峰）
□ 流计算：Flink/Spark Streaming（复杂计算、多流关联）
□ OLAP 引擎：ClickHouse（明细存储 + 实时聚合 + 查询）
□ 调度/编排：采集器（Debezium/Canal）、管道编排

ClickHouse 的定位：
□ 存储与查询「实时明细 + 实时聚合」
□ 擅长：高吞吐写入、秒级聚合、宽表扫描
□ 不擅长：复杂多流 join、事件时间窗口状态管理
  → 复杂流逻辑交给 Flink，ClickHouse 承接「存 + 查」

分工原则：
□ 简单过滤/聚合 → ClickHouse 直接做（物化视图）
□ 复杂关联/状态窗口 → Flink 算完落 ClickHouse
□ 海量明细归档 → ClickHouse TTL 分层

典型组合：
Kafka → Flink（复杂加工）→ ClickHouse（存储查询）
Kafka → ClickHouse Kafka 表引擎（简单导入，见 Kafka 篇）
→ 简单链路全在 ClickHouse，复杂链路加 Flink

三种接入方式：
□ Kafka 表引擎：ClickHouse 直接建 Kafka 引擎表消费
  → 简单、延迟低，但消费管理弱（见 Kafka 篇）
□ Flink 写入：Flink 消费 Kafka 加工后写 ClickHouse
  → 复杂加工/精确一次时用（配合 kafka connect）
□ Kafka Connect / 采集器：Debezium 等管道写入
  → 数据库 CDC 场景

链路可靠性的关键：
□ 幂等写入：ClickHouse 去重（Replacing/去重表）
  → 防 Kafka 重发导致的重复数据
□ 背压处理：Kafka 消费慢 → 队列堆积
  → 监控 lag，必要时扩容消费组
□ 数据格式：JSON/CSV 解析、类型对齐
  → 用 Kafka 引擎 + format 解析（JSONEachRow 等）

延迟链路：
□ 写入：批量 + 异步（每批几千行，秒级可见）
□ 聚合：物化视图在插入时增量更新（见下节）
→ 端到端：事件到可查 = 秒~分钟

-- Kafka 引擎消费（简单链路，示意）
CREATE TABLE kafka_events (
  ts DateTime, user_id UInt64, amount Float64
) ENGINE = Kafka
SETTINGS kafka_broker_list = 'kafka:9092',
  kafka_topic_list = 'events',
  kafka_format = 'JSONEachRow';

物化视图如何实现实时：
□ 普通查询：每次查询全量重算（慢）
□ 物化视图：插入时增量更新聚合结果（秒级）
  → 数据进表 → 物化视图同步更新 → 查询即最新

实时聚合的表引擎搭配：
□ AggregatingMergeTree：存聚合状态（sumState/countState）
  → 适合 group by 预聚合
□ SummingMergeTree：同键求和
□ 物化视图目标表 + 源表的「实时增量」

典型模式：
□ Kafka 数据 → 明细表（MergeTree）
□ 明细表 → 物化视图 → 聚合表（AggregatingMergeTree）
□ 查询直接查聚合表（秒级）

注意：
□ 物化视图增量 = 有状态，重建需重算
□ 聚合粒度先想好（分钟/小时/天），后续加粒度要新视图

-- 分钟级聚合物化视图（示意）
CREATE MATERIALIZED VIEW mv_minute_agg
ENGINE = AggregatingMergeTree ORDER BY (day, hour, minute)
AS
SELECT toStartOfMinute(ts) AS minute, user_id,
  sumState(amount) AS amount_sum, countState() AS cnt
FROM events GROUP BY minute, user_id;

挑战一：一致性（Exactly-once）
□ Kafka 至少一次 + 重发 → 重复数据
□ 解法：幂等写（去重表）、唯一键去重（Replacing）
□ 聚合去重：物化视图用 uniqState 防重复计数

挑战二：迟到数据（Late Arrival）
□ 事件乱序/迟到 → 实时聚合「先看到的部分」
□ 解法：窗口容忍延迟（Flink 侧）、兜底重算
□ ClickHouse：允许事后插入 + 重算聚合（对齐到窗口）

挑战三：重放（Replay）
□ 出 bug/口径变更 → 要从 ODS 重算
□ 解法：ODS 留原始明细（可 TTL 但保底期）
  → 重放 = 重建物化视图 + 回灌历史
□ 设计时就要「能重算」：源数据可重放、聚合可重建

工程启示：
□ 实时口径「先可用后精确」：迟到/乱序会短暂不准
□ 关键指标要有「离线校准」：实时 vs T+1 对账

对账机制：
实时聚合（分钟级） vs 离线 T+1 汇总 → 偏差归因
→ 校准迟到数据 / 修复口径 / 定位重复
→ 实时数仓必须配离线对账兜底

宽表 vs 窄表：
□ 宽表：一行包含所有维度+指标（大宽表）
  → 查询快（少 join）、适合固定报表
  → 代价：字段冗余、更新成本高、建宽表要先定维度
□ 窄表：细粒度明细 + 维度外键
  → 灵活（join 维度）、存储省
  → 代价：查询要 join、实时 join 复杂

实时数仓的建模倾向：
□ 实时场景多「固定指标看板」→ 倾向宽表（预聚合 + 明细宽表）
□ 维度变化少、能提前定 → 宽表（维度字典 join 后固化）
□ 维度多且变 → 窄表 + 字典（Dictionary 关联，见字典篇）

建模步骤：
1. 定分析主题（看哪些指标）
2. 定维度（时间/用户/商品/渠道）
3. 定粒度（明细/分钟/小时/天）
4. 定宽窄（固定报表宽表，灵活分析窄表）

实践原则：
实时聚合表 → 按主题宽表（一行一维度组合）
实时明细表 → 保留必要的宽字段（减少下游 join）
维度 → Dictionary 存 ClickHouse 内存（join 变字典关联）

Lambda 架构：
□ 双轨：离线批处理（T+1 准确）+ 实时流处理（快但不准）
□ 查询合并：实时结果 + 离线结果（或实时优先、离线校准）
□ 优点：准确（离线兜底）+ 快（实时）
□ 缺点：两套代码、两套口径，维护成本高

Kappa 架构：
□ 单轨：只做流处理（Kafka 重放实现历史）
□ 数据保留在 Kafka/对象存储 → 重放算历史
□ 优点：一套代码、口径统一
□ 缺点：流处理全量重放有成本、不适合超深历史分析

选型：
□ 已有成熟离线体系 → Lambda（渐进式）
□ 全新建设 + 数据量可控 → Kappa（简化）
□ 多数团队：Lambda 起步，实时/离线口径对齐是关键

实践：
□ 统一口径：实时 SQL 与离线 SQL 同一逻辑（SQL 复用）
□ 对账：实时 vs 离线差异监控（见第 6 节）

决策：
已有离线数仓？→ Lambda（加实时轨，离线兜底）
全新 + Kafka 保留久？→ Kappa（一套流代码）
→ 口径统一是灵魂，架构只是载体

监控清单：
□ Kafka lag：消费积压是实时掉队的头号信号
□ 写入延迟：事件时间 vs 入库时间（端到端延迟）
□ 写入吞吐：QPS/行数（峰值预期）
□ 查询延迟：看板查询 P95（聚合是否生效）
□ 数据质量：重复率、迟到率、字段缺失率

扩展：
□ 写入扩展：分片（分布式表）+ 均衡（按 key）
□ 查询扩展：副本 + 读写分离
□ 聚合扩容：分片聚合再汇总（物化视图在分片各自算）

容错：
□ Kafka 重放：消费位点重置（回退重算）
□ 物化视图重建：drop + 回灌历史数据
□ 数据恢复：副本 + 备份（见备份篇）
□ 幂等：重放/重灌不产生重复（去重表兜底）

稳定性设计：
□ 削峰：Kafka 缓冲（写入峰值不压垮 ClickHouse）
□ 熔断：写入失败退避重试 + 队列暂存
□ 降级：实时挂了 → 查询退化离线表（不黑屏）

实时健康检查：
Kafka lag 长期 > 阈值 → 消费慢（扩容 or 优化写入）
端到端延迟 > 5 分钟 → 管道某环节堵了
查询 P95 上升 → 聚合被绕过（查了明细层）
→ 实时系统要「一眼看出堵在哪」