# 1. Flink CDC 与离线同步工具（DataX/SeaTunnel）在实时/离线场景的选型？ A DataX 支持实时流式同步 B Flink CDC 面向实时变更捕获与加工，DataX 适合离线批量，SeaTunnel 批流一体，按实时/离线与加工需求选型 ✓ 正确答案 C Flink CDC 不支持断点续传 D SeaTunnel 只能做离线同步
# 2. Flink CDC 的全量+增量切换原理（无锁快照）与断点续传，DDL 变更如何感知与处理？ A Flink CDC 基于 MVCC 无锁快照记录位点，快照后从位点续增量，checkpoint 支持断点续传，DDL 需配置变更策略 ✓ 正确答案 B 全量快照阶段产生的变更会丢失 C 断点续传不需要 checkpoint D DDL 变更无需任何处理
# 3. 从 CDC 到下游的语义一致性，同一条数据先删后插的乱序问题与 upsert 语义 A 先删后插与先插后删的结果完全相同 B upsert 无法处理删除操作 C 同主键的删插乱序可能造成最终状态错误，需目标端主键 upsert 与版本裁决保证一致性 ✓ 正确答案 D 乱序只影响延迟不影响结果
# 4. "实时入湖"的 Schema 演进（DDL 变更）如何处理，同步链路如何感知？ A 加列会破坏历史数据 B 湖格式不支持 schema 演进 C 通过 CDC DDL 事件感知变更，加列自动演进，删列改类型需评估兼容性，湖格式原生支持 schema 演进 ✓ 正确答案 D DDL 只能人工手工同步
# 5. 同步链路的延迟监控与数据对账如何自动化？ A 数据对账只能人工执行 B 通过位点 lag 与新鲜度指标监控延迟，用周期任务自动对账并归因告警，形成自动化闭环 ✓ 正确答案 C 延迟监控只看目标侧即可 D 数据对账无法分表进行
# 6. 实时链路与离线链路的结果对账，数据不一致时的归因（延迟/丢失/口径）流程？ A 所有不一致都源于延迟 B 对账差异无法归因 C 口径差异无需修复 D 不一致先判断是否收敛（延迟），再核对数据量（丢失），最后核对定义（口径），分层归因并修复 ✓ 正确答案
# 7. 同步延迟监控与自愈，Source 堆积、反压、Checkpoint 失败如何告警与恢复？ A Checkpoint 失败不影响数据一致性 B 反压说明处理能力不足，需扩容或优化算子 ✓ 正确答案 C Source 堆积只影响延迟不影响告警 D 自愈恢复只能人工操作
# 8. 实时入湖技术选型，Flink CDC、Kafka Connect、Debezium 的差异，与 schema 演进如何处理？ A Debezium 内置流式计算能力 B Flink CDC 全量+增量且与计算一体，Debezium/Kafka Connect 侧重 CDC 管道，选型看是否需要加工，schema 演进需配套策略 ✓ 正确答案 C Kafka Connect 无法分发任务 D Flink CDC 不支持断点续传
# 9. CDC 的一致性，Exactly-Once 语义、binlog 位点管理、DDL 变更同步的工程坑？ A binlog 位点只需存到本地文件 B 位点与数据处理需原子提交，配合下游幂等实现 Exactly-Once，DDL 同步需策略化处理避免流中断与 schema 漂移 ✓ 正确答案 C DDL 不需要同步到下游 D 重放不会产生重复
# 10. CDC 的 Exactly-Once，binlog 位点与 Flink checkpoint 配合？ A Flink checkpoint 保存 binlog 位点使故障可续传，下游幂等/事务消除重放重复，实现端到端 Exactly-Once ✓ 正确答案 B 位点与 checkpoint 无关 C checkpoint 只能用于批作业 D 恢复后数据会全部丢失
# 11. 实时入湖到 Iceberg/Hudi 的 upsert 与 compaction 机制 A Iceberg 主键表只能追加不能更新 B 湖表不需要文件管理 C compaction 会删除合法数据 D 湖格式 upsert 通过 base 文件加 delete/log 实现，compaction 合并文件减少查询合并开销 ✓ 正确答案
# 12. 多源异构数据库到数仓的同步一致性（快照一致性/顺序一致性）如何保证？ A 多源同步无需关注一致性 B 快照一致性要求各表取同一时刻的数据，顺序一致性要求变更按序到达 ✓ 正确答案 C 顺序一致性只需主键即可 D 快照一致性无法实现
# 13. 多源异构（Oracle/MySQL/PG）同步到数仓的顺序一致性与幂等写入如何保证？ A 异构源统一为带位点的事件模型，目标主键幂等 upsert，配合类型映射与对账保证一致性 ✓ 正确答案 B 各源库的位点格式完全一致 C 幂等写入只对 MySQL 有效 D 顺序一致性无需考虑
# 14. 实时同步的延迟与成本，微批 vs 流式、批流一体（Flink/Spark）在入湖场景的取舍？ A 流式入湖一定比微批贵但文件质量更好 B 微批延迟比流式更低 C 微批延迟高成本低文件质量好，流式延迟低但文件碎成本高，按延迟 SLA 选择，批流一体统一代码 ✓ 正确答案 D 批流一体无法用于入湖
# 15. 实时入湖的 Schema 变更，如何处理上游 DDL？ A 上游 DDL 无需处理自动兼容 B DDL 处理与下游无关 C 所有 DDL 都必须重建数据 D 加列等安全 DDL 自动演进，删列改类型等风险 DDL 需评估与审批，并验证历史数据兼容 ✓ 正确答案
# 16. 入湖的格式选择，Parquet/ORC 与表格式（Iceberg/Hudi）？ A Iceberg 是一种文件编码格式 B 表格式不需要文件格式支撑 C ORC 是表格式 D Parquet/ORC 是列式文件格式，Iceberg/Hudi 是管理快照与演进的表格式，二者组合使用 ✓ 正确答案
# 17. 实时数仓与湖仓一体，Doris/StarRocks 的湖表访问？ A 湖表访问必须先导入数据 B 湖表无法与仓内表 Join C 通过 Catalog 映射湖表直接扫描，支持下推，实现仓湖统一查询，热数据可物化入仓加速 ✓ 正确答案 D 湖表查询不支持并行
# 18. 同步链路的容量与成本规划（source 连接数、带宽、目标写入并发） A 容量规划需按峰值估算连接、带宽与目标并发，结合压测与监控分阶段扩容控制成本 ✓ 正确答案 B source 连接数越多越好 C 带宽无需规划 D 目标写入并发越高成本越低
