📚 课程目录第3章实时数仓架构设计面试

第3章实时数仓架构设计面试：分层架构、Lambda vs Kappa、实时与离线融合

  本章核心考点：
  实时数仓架构选型（Lambda / Kappa / 混合）、分层设计原则、实时与离线数据一致性保障、双链路融合方案。

面试官考察点	是否理解实时数仓分层意义（复用、解耦、统一口径）；能否结合业务阐述分层细节
回答框架	总分层数 → 每层输入/输出 → 存储选型 → 实时与离线层差异
简短示例回答	我们采用 ODS-DWD-DWS-ADS 四层：ODS 用 Kafka 做消息缓冲；DWD 用 Flink 清洗 + 维表关联写 Kafka；DWS 用 Flink 预聚合写到 ClickHouse；ADS 直接供报表和接口。实时层数据保留周期较短，与离线层通过公共主题 Kafka Topic 打通。
可能追问	① 为什么 DWD 不写 HBase 而写 Kafka？② 实时层如何保证维表一致性？③ 离线层和实时层如何对齐粒度？
避坑提醒	不要照搬离线分层名称，要说明实时场景的特殊设计（如 Kafka 代替 Hive 做 ODS）；避免说“我们只用 Flink SQL 做所有事”，面试官会追问状态管理。

面试官考察点	是否理解两种架构的核心区别（批流分离 vs 批流一体）；能否结合实际业务场景做决策
回答框架	定义差异 → 延迟/复杂度/一致性需求 → 存量资产 → 团队能力 → 选型结论
简短示例回答	我们选用 Lambda + 融合层。离线用 Spark 跑 T+1 全量聚合，实时用 Flink 秒级增量。两个结果写入同一张 ClickHouse 宽表，应用层按时间戳取最新数据。核心原因：我们需要 7 天回溯修正历史数据，纯 Kappa 流计算回溯成本太高。
可能追问	① 融合层如何解决实时和离线数据“打架”？② 如果用 Kappa，如何解决数据回溯？③ 有没有考虑过 Flink + Hudi 方案？
避坑提醒	不要说“Kappa 更好”或“Lambda 过时”；重点讲清楚在什么条件下选择哪种，尤其是数据回溯和成本权衡。

面试官考察点	数据一致性保障方案（幂等写入、双写校验、merge 策略）；对实时离线双链路对账的理解
回答框架	原因（口径/延迟/异常）→ 保障策略（分级）→ 具体实现 → 监控告警
简短示例回答	我们采用三级校验：① 离线日切数据覆盖实时最近 24h 结果；② 业务自然键做幂等写入 ClickHouse；③ 每日凌晨对账脚本对比实时与离线聚合值，偏差超 1% 自动告警并触发离线补数。
可能追问	① 如果实时结果被离线覆盖后，用户查询到旧数据怎么处理？② 对账脚本的指标口径如何对齐？③ Flink 端到端 Exactly-Once 如何配置？
避坑提醒	不要只说“开启 Checkpoint 就行了”，要具体讲 Idempotent Sink 设计；对账脚本要说明口径对齐方式（比如按自然天的聚合逻辑）。

项目名称	某电商实时离线融合数据中台（双链路 + 统一服务层）
业务背景	运营需要分钟级大屏+小时级报表+T+1 深度分析，三种时效在一个数据产品里无感切换。
规模指标	日处理 150 亿条实时消息；离线 12 PB 数据；服务 2000+ 业务查询 QPS。
技术栈	Flink 1.15 + Kafka + ClickHouse + Spark 3.3 + Hudi + Druid
核心难点	① 实时离线两套计算口径天然不一致（如 UV 去重阈值）；② 实时数据延迟导致融合层出现“比较基准”错位；③ 双链路写入 ClickHouse 时出现脏数据覆盖。
面试高频追问	① 融合层如何设计？—— 在 ClickHouse 层使用 ReplacingMergeTree 按自然键去重，实时写入 + 离线覆盖。② 如何保证口径一致？—— 将聚合逻辑提取为公共 UDF，实时/离线共用同一套代码。③ 数据回溯怎么做？—— 离线重跑后触发 Kappa 模式写入 Kafka 主题，实时任务从指定 offset 消费补数。
可迁移回答话术	“我们通过‘公共口径层 + 幂等写入 + 对账闭环’解决实时离线融合的一致性问题，具体是在 ODS 层将 Kafka 消息按 Hudi 格式落盘，实现流批共享同一份原始数据。”

💡 面试加分技巧： 提到批流融合时，主动带出“我们已经在探索 Flink + Hudi / Iceberg 架构，目标是逐步淘汰 Lambda 的双套代码”，展示技术前瞻性。

⚠️ 常见扣分点：

第3章 实时数仓架构设计面试：分层架构、Lambda vs Kappa、实时与离线融合