阿里云DTS 我冤枉，其实我很委屈--客户大爷们，咱们换个位置也理解一下吧！-优快云博客

❝
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB专业学习群100+)

最近去了趟杭州，其实在沟通会上，我其实是看到一个老师的面目表情不太自然，算了咱们大白话，心生怨恨，我如果记得没错是DTS的开发同学。

其实我非常理解他，我最近的文章在DISS DTS，也就是阿里云的数据传输服务，估计是挨批了，换谁谁不生气，但和他们的大老板在会上沟通了，事情也基本说开了，同时我也准备不能蛮横不讲理，咱们的平心站在DTS的角度，看看。

其实DTS这个部分如果平心而论，非常难做，非常难做，非常难做，我说了三遍，这DTS放到谁身上都非常的难做。

为什么难做，不就是一个数据传输的服务吗？

单纯了同志，DTS是一个复合型的数据流转服务，我们可以叫他ETL软件，也可以叫综合数据库传输，复制服务。

我从一个外人来猜测一些事情，如果说的不对欢迎DTS的领导来批评。

DTS

1 DTS在设计时需要考虑和考量的部分是非常多，从兼容的数据库产品，DTS使用的通用性，可靠性，时延性，高可用性，安全性，数据过滤特性，以及DTS使用成本几个部分来看，这个产品的复杂程度他不一定低于数据库产品本身难度。

2 数据捕获的方式，说到这里，阿里云有多少种数据库，估计阿里云自己的人都得想想，反正目前DTS支持的东西，我知道的，Oracle,SQL SERVER,MYSQL PG MONGODB REDIS POLARDB 同构异构的，传输数据的方式也有从数据库中的单表逻辑数据传输到物理的整个库的传输，要做这个你需要研究，binlog,wal log,redo log archive log logminer CDC CT oplog 等等这些内部数据日志的结构

3 资源的使用的最小化，这点阿里云的DTS负责人是一定要考虑这个事情的，这就要说成本了，你们知道的 DTS迁移数据库全量是不收费的，而最耗费CPU 内存的，也是全量的。也就是如果DTS的负责人不考虑成本，在根本没有收入的情况下，去大量铺机器，那么将产生非常不好的结果，DTS就会变成一个负利润的部门。所以他很难，他要考虑成本的问题，如何用技术的手段来去弥补。

4 数据拓扑的复杂，DTS支持单对单，单对多，多对单，异地，跨云，高并发，源库的数据库性能，DTS告警，实时同步+全量同步，DTS失败后的断点续传，突发的数据增量，数据消费中的物理机突然失效后的接管问题，DTS的高可用，。。。。。。。。

考虑的问题非常的多，非常杂，同时非常的没有办法和大领导说明，要我看DTS 就是一个悲催的部门。干一堆活，但很难看到成绩。

5 数据校验的问题，这点我深有体会，我们在前一数据库的时候，经常有PG单表1 ，2 ，3 ，4 ，5 ，6亿单表的情况，一堆这样的表，要DTS做全量校验，我都觉得我壕无人性，DTS其实承受了很多，苦楚，且无处诉说。

6 在交流会上，DTS的大领导也说了一些问题，客户的复杂性，是的客户的复杂性，没主键是很平常的操作，我甚至听到，在数据库的字段里面存敏感字符，各种 UTFMB3到 UTRMB4的需求里面带有，笑脸，各种符号，从UTFMB4到UTFMB3希望DTS给解决了，咱们听着奇葩，但DTS的老师们天天都可能遇到这样的无厘头。

7 突发校验失败后的解决，程序不是不会死，DTS也曾经被我们搞垮过好几次，系统崩溃，系统内存不足等等各种问题，你们DTS是无法挑选他的源库和目的库的，公网直接从线下的数据库抽取，然后线下的数据库崩溃了，也要把责任怪罪到DTS上。其实我有心疼DTS的负责人，天天被委屈，应该是家常便饭。

8 数据写入的冲突，比如数据从源库到目的库，然后一个DDL，就把DTS的成果给毁掉了，再或者一个操作失误，把目的库的表的某个值给改掉了，还有DTS工作时的数据一致性的问题，比如是最终一致，单项一致，双向冲突后的问题解决，以及在校验一致，等等。

9 异构的数据传输，比如从PG 到MONGODB ，或者MYSQL 到PG 等等的需求。

10 DTS的告警设置，有的从云下到云上那么数据延迟的告警会不断出来，但你说调整时长太长，告警判断不需要告警，但实际上网络的链接都断了，如果调整的告警指标特别断，但告警没完没了，大家不看了，等真出问题，还是和没有告警一样，所以告警的设计也很难。

当然我不是搞DTS数据传输的，更多的玄妙估计只有DTS负责人知道，所以我现在非常理解那个DTS的开发在不经意的时候，露出了对我XX的表情，非常理解，如果是我我也会的，他心底估计对我已经有了非常多的,羊驼，他很克制了，可能换作是我，我早就开始语言攻击了。

无人理解，还要被误解，各种锅，各种的压力，每个数据库都可以指责他，每个客户都可以抱怨他，领导们在不理解他，施压，这日子没发过了，掀桌子是早晚的事情。

那么从我做起，我以后尽量要对DTS公证一些，不要去偏激的去诋毁人家，同时我也在会上提了小建议，DTS产品难做，的关键是需求太多，需求方太多，需求，需求，需求，千差万别，那么我们不如再开放一些，把一些功能做成两种，一种是阿里云DTS来总体负责，一种是给一个平台让客户自行配置检验，甚至接入自己的告警方式，自己对接自己的系统尤其线下到线上的，比如你可以写判断的SQL来自行进行数据完整性的判断，你可以加入一些脚本自行判断传输的正常与否。（其实就算这样也很难，因为客户的素质，比动物世界里面的动物种类比还多，再加上我这样的“大刺头”还能说会道的），DTS这个产品出门只能走中间，因为左也不对，右也不对，左右为难。

最后话好说，事情难做，希望DTS挺住，终究这世界有的时候还是公平的，苦难太多，终究成为福报，DTS的好日子我觉得有盼头，这里给DTS的同学道歉了。