共计 3063 个字符，预计需要花费 8 分钟才能阅读完成。
导读：
4 月 26 日晚，ChunJun 我的项目核心成员、袋鼠云数栈大数据引擎开发专家渡劫为大家带来分享《ChunJun 反对异构数据源 DDL 转换与主动执行》，咱们将直播精髓局部做了整顿，带大家再次回顾内容，加深技术细节的理解。
你能看到
▫ 数据还原介绍
▫ DDL 主动转换架构设计
▫ Calcite 解析 DDL 实战
直播课件获取：
关注公众号“数栈研习社”，后盾私信“ChunJun01”取得直播课件
直播视频回看：
点击“浏览原文”，观看精彩视频
https://www.bilibili.com/vide…
演讲 / 渡劫
整顿 / 花夏
数据还原介绍
ChunJun 实时同步反对 mysql oracle postgresql sqlserver 等数据源实时同步，然而同步之后的数据是以日志模式输入，数据还原在此基础上做到源数据的变动在指标表也产生对应变动，蕴含 DML 以及 DDL 的操作都会在指标表中执行对应的操作，保障源表和指标表 schema 统一 数据统一。
目前 ChunJun 数据还原曾经反对 mysql 到 rdb 类型数据源的数据还原，仅限于反对 DML 的还原，DDL 的主动执行下一版本反对。
实时还原减少了两个次要模块：
源表和指标表的映射 (database table column 信息的映射)
与内部交互，实现 DDL 状态更新，DML 数据从新下发
为了实现逻辑解耦，咱们减少了 2 个 flatMap 算子实现上述操作：
NameMappingFlatMap 依据映射关系对数据信息进行对应替换
RestorationFlatMap 对数据进行解决，对数据进行阻塞下发以及 DDL 状态监听
flatMap 算子介绍
接下来为大家介绍两个算子
01
NameMappingFlatMap
实时还原默认 source 端 schema table column 是和 sink 端统一的，然而在大多数状况下 source 和 sink 的映射并不是完全一致的，因而须要 NameMappingFlatMap 算子对 source 的 schema table column 进行替换。NameMapping 反对 schema table column 的映射，其映射关系如下图所示：
图中映射关系代表源表 schema 为 ChunJun_source 下的 source1 这个表对应对应于指标端 ChunJun_sink 下的 sink1，其中字段映射为 源表的 C1 字段对应指标 id 字段，C2 字段对应指标 name 字段
在创立 flink 同步工作的时候，会判断脚本里是否配置了 nameMapping 的配置，如果没有配置则不会存在 NameMappingFlatMap 算子。
02
RestorationFlatMap
在数据还原中肯定会波及到 DDL，然而目前 sink 端只反对 DML 的执行，因而在源表产生 DDL 之后的 DML 数据不能间接发给 sink 端执行，须要等到 sink 端对应的 DDL 执行完之后，DML 能力从新下发。
因而 RestorationFlatMap 设计次要是为了解决 数据的下发 何时下发问题，何时下发就是上游 sink 的 DDL 执行完，然而这个 sink 端 ddl 的执行不是 ChunJun 实现的，ChunJun 是无奈得悉实现工夫的。因而 RestorationFlatMap 会和内部交互 获取这个 DDL 执行状态 从而判断 DML 数据何时下发。
结构设计
RestorationFlatMap 外部会对每个表保护一个汇合，DML&DDL 数据都会存入此汇合。汇合会在非阻塞和阻塞状态间进行切换，同时外部会有两个组件别离为 workerManager 以及 Monitor 组件：
WorkerManager：监听非阻塞汇合数据，如果是 DML 下发，如果是 DDL 则将队列置为阻塞状态
Monitor：将 ddl 存储到内部数据源 以及监听阻塞队列的 ddl 执行状况，进行阻塞到非阻塞的扭转 store 监听阻塞状态队列的第一个 ddl 数据，将其存储到内部表 fetcher 监听内部表 DDL 数据的状态 如果为已执行，则将此表对应的汇合阻塞状态改为非阻塞
内部表设计
ChunJun 目前反对 DDL 数据存储内部 Mysql 数据源在数据还原中会将 DDL 数据写入到内部数据源，第三方批改此 DDL 数据的 status 为 2 后，ChunJun 会认为上游 DDL 已执行结束
数据还原脚本示例
脚本示例次要分为 nameMapping 及 restoration 两局部，别离对应 NameMappingFlatMap 及 RestorationFlatMap 算子参数。
留神 reader 的 split 须要设置为 true。
数据还原存在问题
binlog 反对 DDL 读取，logminer 暂未反对 须要所有数据源反对 DDL 的读取
RestorationFlatMap 会将数据存储在内存中，后续会进行内部长久化
checkpoint 反对有余，RestorationFlatMap 模块数据续跑后会失落
以后数据源产生 DDL 场景和内部交互过多，后续减少 DDL 主动执行，达到 DML&DDL 都由 chunjun 实现，用户无感知
DDL 主动转换架构设计
以后数据还原 DDL 执行依赖内部进行操作，ChunJun 仅依据 DDL 数据状态进行 DML 数据下发，为了做到整条链路由 ChunJun 闭环实现，缩小内部依赖以及运维老本，ChunJun 进行 DDL 主动转换操作，将 source 的 DDL 语法转换为 sink 的 DDL 语法，因而就有了 DDL 主动转换模块的设计。
DDL 主动转换解决下列问题：
以后 ddl 数据 ChunJun 上游不会主动执行
内部表存储的 DDL 数据状态是客户手动批改
次要结构设计：
将 DDL 主动转换逻辑放在 NameMappingFlatMap 中，NameMappingFlatMap 执行数据转换。
DDL 技术计划
数据还原主动转换性能次要是以下三局部：
1、解析 DDL 语句
源表 DDL SQL 转为一个两头对象以及两头对象转为指标端 DDL 语句。
2、异样数据管理
如果主动转换时失败，抛出 conventException 后，由对应的异样管理器解决。
3、DDL 数据状态主动批改
DDL SQL 在上游执行结束后，基于事件告诉形式将两头表存储的 DDL 状态改为已实现。
DDL 架构设计
因为 DDL 没有统一标准，每个数据源的 DDL 语法不同，因而须要依照每个数据源的 DDL 语法进行解析，并将其解析为一个两头数据，而后将这个两头数据转为指标类型数据源的 DDL 语句。
因而 DDLConvent 顶层接口会形象出三个根本办法：
1、RowData 转为两头数据
2、两头数据转为 DdlSql
3、获取数据源类型
Calcite 解析 DDL 实战
Calcite 解析 DDL 实战基于代码层面做此次演示，就不在公众号上做具体演示回顾，各位社区小伙伴们可返回 B 站查看视频直播回顾。
B 站直播回顾地址：
https://www.bilibili.com/vide…
结语
以上就是咱们在数据还原上减少的 DDL 主动执行设计思路，咱们布局将在上半年实现以上性能点，如果大家有好的想法也欢送给咱们提 issue 或者 pr。
issue 标准
在提交 issue 时须有对应脚本、提交模式、数据（非必要）、残缺日志（重要的货色）等内容
pr 提交标准
1、在 pr 里备注修复的 issue
2、pr commit 模版 hotfix/feat/docs-#issueID #fix-commit（尽量应用英文，内容形容分明）
3、批改内容尽量放弃与 issue 内容统一，如果呈现无关批改，在 pr 中备注进去；
社区文档核心
同时为了帮忙社区搭档更好的理解和应用 ChunJun，咱们上线了社区文档核心，欢送大家应用。
https://dtstack.github.io/chunj!
