# 1. 实时数仓与离线数仓的分层对比，Lambda 与 Kappa 架构在实时数仓中的取舍？ A Kappa 架构以单一流链路替代两套链路，口径统一但依赖消息回放能力，长周期批任务受限 ✓ 正确答案 B Kappa 架构需要同时维护实时与离线两套计算链路，成本更高 C 离线数仓采用 Lambda 架构，实时数仓采用 Kappa 架构，二者互不适用 D Lambda 架构只包含实时链路，不包含离线批量计算
# 2. Doris、StarRocks、ClickHouse、Hologres 的选型矩阵（查询模型/更新能力/生态）如何构建？ A Doris 与 StarRocks 均提供主键/唯一键模型支撑实时更新，而 ClickHouse 更新能力相对较弱 ✓ 正确答案 B Hologres 只能用于离线批处理，无法实时写入 C ClickHouse 的主键模型支持毫秒级高频 upsert D StarRocks 不支持物化视图
# 3. Flink 维表 Join 的实现（异步 IO、缓存、LRU）与维表更新策略 A 异步 IO 无法控制并发请求数 B LRU 缓存中的维表数据永远与源库一致 C LOOKUP JOIN 使用处理时间语义，每行数据触发维表查询，可通过异步 IO 与 LRU 缓存降低延迟 ✓ 正确答案 D 广播流维表只能用于大维表且无法感知维度变化
# 4. 实时数仓的"流表"与"维表"如何设计，Join 的延迟与状态管理如何权衡？ A 双流 Join 的状态可以无限增长而无需清理 B 维表数据量很大时通常采用内存广播方式，成本最低 C 流表与维表的 Join 只能使用处理时间 D 状态 TTL 越大，状态存储与 checkpoint 成本越高，但可覆盖更晚到达的乱序与迟到数据 ✓ 正确答案
# 5. 实时数仓的数据一致性，Flink 与 OLAP 引擎如何协同保证端到端 Exactly-Once？ A 端到端 Exactly-Once 需要 Flink Sink 与 OLAP 引擎的事务/幂等机制协同，主键 upsert 模型可作为幂等兜底 ✓ 正确答案 B Flink 的 checkpoint 机制可以自动保证端到端 Exactly-Once，无需 Sink 配合 C At-Least-Once 语义下数据一定不会重复 D 只要开启 checkpoint，重启后数据必然不重不丢
# 6. Lambda 与 Kappa 架构的演进，实时链路（Kafka→Flink→Doris/StarRocks）与离线链路（Hive/Spark）的数据一致性如何保证？ A 实时与离线双链路写同一张表时，无需任何机制也不会产生数据冲突 B 通过主键 upsert 与分区隔离可以降低双链路写入冲突，但仍需对账机制验证结果一致 ✓ 正确答案 C Lambda 架构不需要统一指标口径 D Kappa 架构无法保证实时与离线结果一致
# 7. 实时数仓分层，ODS/DWD/DWS/ADS 在实时场景的建模差异，宽表与明细层的取舍？ A 实时数仓必须完整保留 ODS/DWD/DWS/ADS 四层，缺一不可 B 实时宽表可以随意回刷重算，无需保留明细层 C 实时场景分层宜适度压缩，宽表面向高频查询、明细层面向灵活分析并互为补充 ✓ 正确答案 D 实时 ODS 层数据可以无限期保存在 Kafka 中
# 8. 实时数仓的链路，Kafka→Flink→Doris/StarRocks 的端到端延迟与容错？ A 端到端延迟只取决于 Flink 计算耗时 B Kafka→Flink→Doris 链路中，Flink checkpoint 可以完全替代 Doris 的导入事务保证不重 C 反压不会影响端到端延迟 D 端到端延迟由生产、计算、导入、可见性多个环节构成，提高导入频率与降低窗口等待是常见优化手段 ✓ 正确答案
# 9. Lambda 与 Kappa 架构对比，两套计算的成本与一致性？ A Lambda 架构只需要维护一套计算代码 B Kappa 架构无法统一实时与离线口径 C Kappa 架构通过消息队列重放实现重算，但大规模重算与长周期批任务成本高，实践中常与离线链路混合使用 ✓ 正确答案 D Lambda 架构不需要对账机制
# 10. 实时指标与离线指标的口径对齐（窗口边界、迟到数据、重算） A 实时指标与离线指标使用不同窗口边界不会影响口径 B 口径对齐需要统一统计时点与窗口定义，并用 allowed lateness 与对账机制处理迟到与偏差 ✓ 正确答案 C 事件时间窗口可以完全避免迟到数据的影响 D 离线结果永远比实时结果准确，不需要对账
# 11. Spark 4.0 的 VARIANT 半结构化类型、ANSI SQL 默认开启与 Spark Connect 对既有 Spark 3 批作业的迁移影响？ A ANSI SQL 默认开启后，除零等错误会返回 NULL 而非报错 B VARIANT 用于替代所有基本数据类型 C Spark 4.0 的 ANSI SQL 默认开启会改变类型不匹配等行为的容错语义，迁移时需审计 cast 与异常处理 ✓ 正确答案 D Spark Connect 会改变 Spark SQL 的执行引擎
# 12. Flink 2.0 的存算分离状态管理（Disaggregated State，以 DFS/对象存储为主存储）对状态规模、容错与资源弹性的影响？ A 存算分离后状态仍存储在 TM 本地磁盘 B 存算分离状态以 DFS/对象存储为主存储，支持超大规模状态与快速扩缩容，但状态访问存在网络延迟，需本地缓存优化 ✓ 正确答案 C 存算分离会增加状态迁移开销，扩容更慢 D Flink 2.0 存算分离与 checkpoint 机制无关
# 13. 实时数仓的指标口径与离线对账机制如何建立？ A 对账只需要对比一个总数，无需分维度 B 指标口径由实时团队独立定义，离线无需对齐 C 通过指标字典与共用 SQL 模板统一口径，并以离线为准进行定时对账与差异归因 ✓ 正确答案 D 对账发现差异只能人工手动修复，无法自动化
# 14. 选型决策，Doris/StarRocks/ClickHouse/Hologres 在实时数仓中的定位差异（导入能力、join 能力、高并发点查）？ A ClickHouse 的高并发点查能力最强 B Hologres 无法与 Flink 集成 C Doris/StarRocks 在实时导入、大表 Join 与高并发点查上综合均衡，ClickHouse 擅长宽表聚合但点查与更新弱 ✓ 正确答案 D Doris 不支持 Kafka 实时导入
# 15. 实时数仓 vs 离线数仓，口径统一与数据治理的挑战？ A 实时与离线各用各的口径是合理的，无需治理 B 实时数据无法做质量校验 C 数据血缘只对离线数仓有意义 D 双链路并存易造成口径漂移，需要指标字典、批流一体与对账机制统一治理 ✓ 正确答案
# 16. 实时数仓的数据建模，宽表 vs 明细+维度建模的实时适配？ A 实时数仓只能建宽表 B 明细+维度建模在实时场景下查询免 Join，性能最好 C 宽表查询免 Join 适合高频报表，但需处理维度变更级联更新，明细层保留用于回刷与灵活分析 ✓ 正确答案 D 实时宽表不需要主键
# 17. 实时数仓的监控，任务延迟、数据质量与对账机制？ A 实时监控只需要看 Kafka lag B 对账只能在离线数仓做 C 数据质量监控包括 schema 校验、主键重复与异常值比例，与延迟监控、对账机制共同构成实时数仓监控体系 ✓ 正确答案 D checkpoint 失败不影响实时任务正确性
# 18. 实时数仓的数据治理，口径统一与血缘追踪？ A 实时数据不需要血缘 B 血缘追踪只能离线实现 C 指标口径由各团队自由定义，无需字典 D 实时血缘可以通过解析 Flink SQL 作业自动生成，支撑口径变更的影响分析与溯源 ✓ 正确答案
# 19. 实时数仓的选型决策，写入延迟、查询并发与成本的综合评估？ A 选型只需要比较查询性能一个指标 B 成本因素可以完全忽略 C ClickHouse 的并发点查能力远超 Doris D 写入延迟、查询并发与成本三者需按业务 SLA 综合评估，并通过压测验证，不存在全能的引擎 ✓ 正确答案
# 20. 实时数仓的状态清理（TTL 与 state 膨胀治理） A 状态不需要清理，可以无限增长 B 通过 State TTL、合理的 Key 设计与状态监控可以控制状态膨胀，避免 checkpoint 变慢与内存压力 ✓ 正确答案 C TTL 只对窗口聚合生效 D 状态膨胀只会影响内存，不影响 checkpoint
