增量数据与全量数据同步策略
请介绍大数据场景下增量数据同步和全量数据同步的常见策略、技术选型以及如何保证数据一致性。
回答
小字辈
一、全量同步（Full Snapshot）：
场景： 首次同步、数据量小的表、维度表初始化
实现方式：
- Sqoop/DataX：
--query 「SELECT * FROM source_table」 - Spark/Hive：直接全量覆盖写入目标表
- HDFS DistCp：文件级全量复制
问题： 全量扫描对源库压力大，全量写入耗时长
二、增量同步（Incremental）：
1. 时间戳/水位线：
- 源表有
update_time/modify_time字段 - 每次同步记录最大时间戳，下次拉取>该时间的记录
- 问题：必须保证时间戳正确更新，秒级精度问题，删除数据难处理
2. Binlog（CDC）：
- 通过Canal/Maxwell解析MySQL Binlog
- 实时捕获INSERT/UPDATE/DELETE
- 优点：实时、完整、无遗漏
- 缺点：需要开启Binlog、历史数据需要额外同步
3. 触发器/日志表：
- 在源库建立触发器，变更写入日志表
- 同步程序读取日志表
- 优点：对源表结构无侵入
4. 离线增量：
- Hive分区表：每天一个分区，按日期过滤增量数据
- 示例：
WHERE dt = '2025-05-25'
三、数据一致性保证：
| 方案 | 优势 | 劣势 |
|---|---|---|
| 全量覆盖 | 简单，一致性好 | 资源消耗大 |
| 增量+Merge | 效率高 | Merge冲突难处理 |
| CDP(Canal+Merge) | 实时完整 | 依赖Binlog |
| 拉链表 | 完整历史 | 查询复杂 |
四、大数据实践：
- 维度表：全量每日同步（数据量小）
- 大事实表：增量+分区覆盖
- 实时场景：Binlog+Kafka+Flink实时写入
- 一致性校验：对比源和目标记录数、checksum
五、工具选择： | 工具 | 适合场景 | |------|---------| | DataX | 离线批量同步（全量+增量）| | Canal/Maxwell | 实时Binlog同步 | | Sqoop | 传统Hadoop生态 | | Spark/Flink | 复杂ETL+同步 | | Kettle/Nifi | 可视化管理 |