第2章：实时数仓基础概念与高频理论
本章聚焦面试中反复出现的实时数仓核心概念与高频理论，涵盖离线/实时对比、架构选型（Lambda vs Kappa）、流批一体、数据一致性等。回答时需体现“定义先行 → 架构对比 → 关键技术 → 工程权衡”的思维路径。
高频面试问答卡片
❓ 请解释实时数仓与离线数仓的区别，以及实时数仓的核心挑战。
🎯 考察点：基础知识广度、对时延&数据量的权衡理解、工程落地意识
| 回答框架 |
|
📝 简短示例回答：实时数仓与离线数仓最本质区别在于时效性：离线采用T+1批处理，实时要求秒级/分钟级输出。核心挑战包括乱序数据带来的一致性难题（如迟到数据处理）、端到端延迟控制以及资源成本升维。实践中常用Flink+Iceberg实现湖仓一体，配合Kappa架构简化链路。
🔍 可能追问：如何处理数据乱序和迟到数据？（Watermark + allowedLateness）
实时数仓分层如何设计？（ODS/DWD/DWS/ADS各层时效差异）
⚠️ 避坑提醒：避免只谈离线与实时的时间差异，必须提到“一致性”和“成本”这两个工程级挑战。不要给出“离线数仓将被淘汰”的极端观点，应强调两者互补。
❓ Lambda架构和Kappa架构的优缺点及适用场景？
🎯 考察点：架构设计能力、历史趋势理解、选型权衡意识
| 回答框架 |
|
📝 简短示例回答：Lambda架构同时维护批处理和实时两条链路，通过合并层保证最终一致性，但运维代价高。Kappa架构只用实时流，历史数据通过回放Kafka重算，统一技术栈，但对消息队列的存储和回溯能力要求高。当前生产环境更倾向Kappa + 数据湖（如Flink + Iceberg）实现流批一体。
🔍 可能追问：Kappa架构下如何保证历史数据重算时不影响实时作业？
有没有实际见过“混合架构”（批流并存但共享代码）？举例说明。
⚠️ 避坑提醒：不要直接判定“Kappa全面优于Lambda”，要承认Lambda在强一致性场景（如金融）仍然有价值。避免列举过于生僻的技术名词，只说Kafka/Flink即可。
❓ 实时数仓中如何保证数据一致性？常见方案有哪些？
🎯 考察点：一致性实现细节、端到端Exactly-Once理解、实战经验
| 回答框架 |
|
📝 简短示例回答：实时数仓一致性通常分为单链路和跨链路保证。单链路基于Flink Checkpoint + Kafka事务性写入实现端到端Exactly-Once；跨链路常用Lambda的Merge层修正或Kappa的幂等+重算。实际落地常接受“最终一致性”，通过实时层输出暂态结果，离线层修正后统一服务。
🔍 可能追问：Flink如何与Kafka配合实现事务写入？
Watermark延迟对数据一致性有何影响？
⚠️ 避坑提醒：不要只提理论概念（如CAP），要具体到Flink的Checkpoint机制和Kafka事务API。避免断言“实时数仓可以做到强一致”，应强调工程中多为“最终一致”并设计补偿逻辑。
知识结构表格：实时数仓技术选型对比
| 维度 | 离线数仓 | 实时数仓 |
|---|---|---|
| 处理引擎 | Hive、Spark SQL、Presto | Flink、Spark Streaming、Kafka Streams |
| 存储层 | HDFS、Hive表、ORC/Parquet | Kafka、Redis、Druid、ClickHouse |
| 数据延迟 | 半小时~天级 | 秒~分钟级 |
| 一致性模型 | 强一致（批处理幂等） | 最终一致或Exactly-Once（基于Checkpoint） |
| 典型场景 | 报表、BI、历史分析 | 实时大屏、风控、推荐特征 |
💡 面试加分提示：主动引出“流批一体”趋势（如Flink SQL + Iceberg / Hudi），并说明Kappa架构在数据量<10TB/天的中小型场景更受欢迎，大型金融场景仍保留Lambda混合方案。