更新指针
目标数据库 - 删除重建数据缓冲表
如果临时表数据较多的话，关联删除的效能可能不太理想，或许会超时。给个小建议，区分临时表中数据的类型，明确 INSERT 类型以及 UPDATE 类型，关联删除操作只针对 UPDATE 类型数据
获取当前时段待处理的任务集合
扫描临时表获取同步状态
表输出 - 中间表
判断插入模式
字段映射
job_data_sync
中间处理表，推荐 Unlogged Table，可考虑用 CREATE TABLE LIKE 方式创建，分布式数据库需支持继承分布键
事务提交
批量加载
失败
成功
Transform
表输入 - 源表
讨论:1. 如果源端数据已经很久没更新了，则考虑采用指数退避算法更新任务下次可被调用的时间，减少不必要的调用2. 如何支持源端做了分表的场景？src_table_name 能否配置为查询表达式
空流判断
关联删除
Append
事务开启
- job_name- src_conn_id- src_db_name- src_schema_name- src_table_name- dst_schema_name- dst_table_name- field_mapping -- 原表目标表字段映射- src_incr_field- dst_pk -- merge 同步时必须字段- dst_distributed_by -- 保留字段- sync_mode (append | merge | full)- incr_point -- 增量指针值- cdt- udt- inuse
Merge
N
事务回滚
调度开始
配置中心
数据全量导入的时候应避免出现表锁，类似表重命名，以及 Truncate 等操作应规避。血的教训: 若干次因为表锁引起业务查询大面积阻塞
执行结束
获取任务列表
判断全量 or 增量
加载配置文件
full
Event Loop
Merge Table
INSERT INTO ... SELECT
可以考虑用 func 实现
判断是否有数据
判断执行结果
DELETE 全表
源端最好不排序，以避免对加重源端负担
