第4章 ETL与数据同步技术
ETL是离线数仓的生命线，面试中重点考察你对全量/增量同步、一致性保障、延迟优化及高可用设计的理解。本章提供结构化问答框架与实战项目模板，助你快速拆解面试考点。
ETL同步回答框架：从数据源到性能优化，逐层拆解面试应答
高频面试问答卡片
1. 全量与增量同步的区别？如何选择？
| 面试官考察点 | 是否理解不同业务场景下的同步策略，以及增量同步的实现原理（如日期字段、日志解析、binlog等）。 |
| 回答框架 | （1）定义：全量一次性抽取全部数据，增量只抽取变更数据；（2）适用场景：初始化/小表用全量，大表且频繁变化用增量；（3）增量实现模式：max(id) / 时间戳 / binlog+CDC；（4）可补充混合策略：首次全量+后续增量。 |
| 简短示例回答 | 全量同步适合数据量小或首次加载的场景，比如维度表每天全量覆盖。增量同步通过max(event_time)或binlog监听实现，只同步新增/修改行，适合订单表等大表。实际项目常采用“首次全量+每日增量”的混合策略，并通过水位表记录偏移量。 |
| 可能追问 | ①增量同步如何保证数据不丢不重？②binlog模式对源库性能影响多大？③如果增量延迟如何处理？ |
| 避坑提醒 | 不要只说“全量简单、增量复杂”，要具体说明增量实现方案（如Spark增量读Hive分区表、Flink CDC）。避免回答“全量都是慢”的化言论，小表全量更稳定。 |
2. 如何设计数据同步的一致性保障机制？
| 面试官考察点 | 是否掌握分布式事务、两阶段提交、幂等性、校验纠偏等一致性策略。 |
| 回答框架 | （1）读取阶段：记录偏移量+快照隔离；（2）传输阶段：利用事务消息或两阶段提交保证不丢；（3）写入阶段：目标表采用主键去重+幂等写入；（4）校验机制：行数比对+校验和对比，异常触发重跑。 |
| 简短示例回答 | 我们使用Flink CDC读取binlog并记录LSN，输出到Kafka后配置Exactly Once语义；下游Hive表通过insert overwrite分区实现幂等写入。每天凌晨跑一次count校验，数据差超过阈值自动告警并触发全量重跑。 |
| 可能追问 | ①Exactly Once在分布式系统里真的能保证吗？②如何在不支持事务的存储（如HDFS）上做一致性？③校验失败后如何修复而不影响下游？ |
| 避坑提醒 | 避免只讲概念（“我们用了幂等”），要说出具体实现（如HDFS rename、HBase rowkey去重）。不要忽略监控环节，面试官会追问“你怎么知道数据一致了”。 |
3. 数据同步延迟高，如何排查和优化？
| 面试官考察点 | 是否具备端到端链路分析能力，以及优化实践经验（并行度、资源、瓶颈定位）。 |
| 回答框架 | （1）定位瓶颈：源端压力、网络带宽、计算资源、目标写入能力；（2）分步排查：源库慢SQL/连接数→Kafka积压→Spark/Flink背压→HDFS小文件；（3）优化手段：增大并行度、批量写入、调整调度窗口、增加资源。 |
| 简短示例回答 | 先查源库慢查询和无索引表，再监控Kafka Lag。若源端正常则看Spark执行阶段：shuffle倾斜导致数据倾斜，我们通过repartition+salting优化。目标端HDFS小文件过多则合并写入并调大文件大小，最终延迟从2h降到15min。 |
| 可能追问 | ①数据倾斜的具体表现和解决方案？②Kafka Topic分区数对并行度的影响？③如何设计告警策略自动处理延迟？ |
| 避坑提醒 | 不要只说“加机器”，要能说明延迟的具体表现（如积压量、背压指标）和针对性优化。避免把重点放在偏门组件上，优先讲熟知的Spark/Flink优化手段。 |
项目案例实战
| 项目名称 | 电商离线数仓数据同步平台 |
| 业务背景 | 电商业务每日产生数亿条订单、支付、用户行为日志，需从MySQL/埋点Kafka同步至Hive，支撑次日BI报表与算法训练。 |
| 规模指标 | 日均同步数据量：订单表2亿行+行为日志20亿条；源端MySQL 16节点集群，目标Hive 200节点；同步延迟SLA < 30分钟。 |
| 技术栈 | Flink CDC (Debezium) + Kafka + Spark Streaming + HDFS/Hive + OpenTelemetry + 自研水位表 |
| 核心难点 | ①MySQL binlog变更量大导致链路挤压 ②Spark写入HDFS产生小文件 ③跨机房网络抖动造成数据丢失 ④校验系统误报率高 |
| 面试高频追问 | ①为什么选择Flink CDC而非Canal？②如何保证Exactly Once？③小文件优化具体参数和效果？④网络抖动如何通过重试与检查点恢复？ |
| 可迁移回答话术 | “在xx项目中，我们遇到源端QPS持续飙升导致同步延迟的问题。通过将单流拆分为多流（按业务主题分区），并引入批量写入+异步提交机制，将延迟控制在15分钟内。” —— 适用于任何“高并发同步”场景回答。 |
💡 本章核心准则：ETL面试回答= 场景定义 + 实现方案 + 优化细节 + 监控校验。每一点都要落地到具体技术组件和参数，才能体现工程深度。