导读：
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!