【增量同步】 多种增量同步方式对比

[zhengqiangtan]

我们遇到的数据同步痛点： 1、数据量2千万+ 2、数据经常变（包含删除动作），无法用传统的方式进行增量同步

可选CDC（CHANGE DATA CAPTURE）场景方案调研：

• 1、第一种方式(依赖开源组件较多，虽增加了复杂度，但比较适合当前的场景) MySQL binglog → canal/maxwell → kafka → sparkstreaming/flink → hbase → insert overwrite hive的分区表

• 2、第二种delta lake方案 1）批量更新方式
  数据流： mysql → sqoop批量同步更新 → spark merge delta table 使用场景：没有Delete 且实时性要求不那么高的场景
  不足之处：不能包含delete, 且需要业务额外增加一个增量更新字段， 最终的delta table 只能使用spark/spark-sql 去查询，无法兼容hive查询，除非开发任务使用spark读取插入到目标hive表给后续的依赖使用。 2）实时更新方式 数据流：MySQL（binglog）→ ali (dts,canal)/maxwell → kafka→ spark streaming (merge delta table ) 作业 使用场景：实时同步更新MySQL数据(update,delete,insert的基本场景) 不足之处： 1. 最终使用API merge的delta table 只能使用spark/spark-sql 去查询，无法兼容hive查询，除非开发任务使用spark读取插入到目标hive表给后续的依赖使用。 2.需要借助较多开源工具实现，流程较为复杂 3. MySQL shema的变更无法感知 其他：目前仅限于在EMR上使用hive读取delta table，不过官方已经给出connector 参考：https://github.com/delta-io/connectors

• 3、第三种 spark-binglog + delta plus

  数据流：MySQL（binlog）→ spark-binlog → delta table → compaction(delta plus) 所需组件：delta-plus+ spark-binlog + structure streaming (spark2.4+) 使用场景：适合离线、实时的数据同步，不需要依赖过多其他开源组件 优点：使用简单，依赖组件少，目前支持捕捉insert/update/delete 三种事件满足需求。 不足之处：文档示例较少,且结果表不能和hive打通， 弥补方式：使用定时任务读取delta表并写到hive中, 不过还是有一定的延迟，对于失效要求不敏感的可以考虑。 补充：性能需要结合自身情况进行实地测试。 参考：delta-plus spark-binlog

[allwefantasy]

compaction(delta plus) 在第三种方案里是不需要的。原因是因为在每次同步的时候，delta-plus会自动控制文件数目。 如果你的hive满足要求的话，官方已经提供了hive 读delta 的connector，并不需要再导入到hive， hive可以直接读取delta。 所以可以实现非常低的延时。