这个文档的意思我理解是数据写入tidb，超长decimal的数据写入tidb阶段的处理逻辑。 我目前的阶段是已经完整写入tidb的数据，写出到kafka。两个阶段不一样的。

哪里改成字符串？业务数据库的字符类型吗？ 这个问题是发生在业务数据已经写入，精度位数比较大，cdc采集到kafka阶段

尝试了canal-json，发现canal-json的decimal是不丢失精度的，4种事件类型的值，也符合期望 但是canal-json和debezium的数据结构不一样，flink层做结构适配，或者结构转换 携带的信息也各有优劣，但是核心信息都是有的。 目前计划采用canal-json格式，不使用debezium，打算基于一个flink程序，同时兼容两种数据格式的转换，由于历史很多程序都是基于debezium格式做的，因此在数据转换的源头程序flink种，尝试将canal-json的结构粗略转换为debezium的结构，降低下游程序的数据结构适配。

好的，我去试试看

说错了 能不能改ticdc的源码

上游是业务库，很多涉及金额的字段，也不能改业务库的金额为string类型 ticdc同步到kafka，精度已经丢失，下游无法恢复精度。虽然这种精度丢的很小。原则上影响不大 但是ticdc集成demezium的配置貌似是把decimal转为float来出来，对位数很长的数，会精度丢失，另外float可能精度不准，1变成0.99999999这种，影响业务和测试理解 期望是 1， 能不能通过调整flink cdc的源码来使用decimal.handling.mode=string逻辑来控制数据转换逻辑 2， 未来能否开放或封装debezium的原生配置作为ticdc的配置，从而用户可以更灵…

decimal.handling.mode=string，这种是不丢失精度的 flink cdc mysql集成debezium可以通过debezium的这个参数来控制decimal类型的转换。 但是ticdc集成debezium没有看到这种类似的配置开放出来，控制debezium的行为。

[image] 写入tidb是正常的 精度没有丢失 kafka的数据精度对不上了 这三个字段都会出现截断

flink 任务采用streampark管理，这种方式不用手动执行mysql dump类似的导入导出操作。 避免了scp 几十上百G文档的操作，交给flink做快照慢慢抽取数据

实时采用了ticdc → kafka → flink → doris 这个kafka的数据结构和flink mysql cdc的数据结构和对时间类型的处理还不一样 ticdc的kafka数据是原生的debezium的消息结构 flink mysql cdc对debezium的数据做了封装，对4种时间类型的数据做了转换格式。 需要自己适配对时间类型的转换逻辑 离线采用的是flink mysql cdc snapshot模式的改造方案 大部分源码基于flink mysql cdc snapshot的代码， tidb的binlog和mysql的binlog差异比较大，部分需要的功能不存…

业务是打算把mysql换成tidb，分布式的，后面好扩缩容，但是下游大数据目前没有什么好的办法抽数到doris，抽到大数据做中心服务器的管理后台以及大数据实时和离线报表

而且是上千张表都要同步，需要通用，自动的操作，手动一个一个搞，搞不过来

全量导入是指dumping成文件，再scp到doris集群，然后导入到doris吗？ 不知道会不会文件太大，几十上百G，跨服务器（美国传到新加坡） 会对表的数据做处理，加几个额外常量字段，对date类型的业务字段，统一转为毫秒值 存在多个边缘集群往一个中心doris的同一张表写 故障恢复，比如极端情况ticdc的binlog接不起来，中间断了几分钟数据，此时要重跑全量，不然会丢

我们是多个边缘服务器服务器采用tidb，然后全量同步所有数据到中心服务器doris，增量应该可以走ticdc发kafka-》flink-》doris的模式 目前全量的还没有思路，尝试用flink cdc mysql source的snapshot模式来读tidb，底层报错，没搞定

怎么对tidb做历史全量同步呢？整实例同步到doris，上千张表