共计 2754 个字符，预计需要花费 7 分钟才能阅读完成。
1 前言
“世上无难事，只有不集成。”
数据中台开发阶段的前期工作，最艰难就是数据集成了。刚开始数据建模做的好坏，业务做的好坏，仿佛都有情可原，然而数据集成不上来，所有业务近景就如地基不牢的高楼随时都可能倾覆。
从之前的我的项目教训来看，数据加工的建模办法和 SQL 语言都是较为标准化的，在我的项目中与阿里云第一次单干的搭档和客户对于数据集成的学习和把握都是较为艰难。尤其是之前没有相似须要数据集成系统的企业，对数据集成工作的了解不是过于简略，就是过于担心，又或者过于严苛。究其原因，还是对数据集成工作做什么都不理解，进而有很多误会。
2 DataWorks 的数据集成
早年 DataWorks 是只有离线集成，没有实时集成的性能，因为其定位次要是基于 MaxCompute 的离线开发平台。然而这几年在面向 DataOps 的倒退上，定位曾经是全能的大数据开发平台，能够基于多种引擎做数据开发。例如 holo 这种实时数仓的产品。所以，实时数据集成也是箭在弦上，终于做了一些对应的性能，作为一个资深用户还是很惊喜。
然而目前从理论应用上来看，实时集成性能尽管补救了性能上的缺点，然而与离线集成的弱小比起来，还是有所欠缺。
首先是惊喜的局部。实时数据集成的间接构建了一键同步的性能，把简单的配置实时同步工作，归档到 log 表，而后从 Log 表又 merge 到全量表的所有逻辑都蕴含在内了，真的实现了一步取得数据。从理论应用上来看，客户和搭档学习配置一个实时数据集成工作与学习配置一个离线工作的成比起来更低。大部分人一次就配置胜利，取得感很强。从资深用户的角度看，这种弱小的整合能力也让理论运维的工作变得非常少，能够大大加重开发人员的工作量，几乎是幻想的此岸。之前在一个部委大型项目上，咱们的数据集成表高达几十万，每天调度运行的工作都是以十万计，有效运维压力山大。
而后是欠缺的局部。从理论应用上来看，单个一键同步工作所承载的工作数量还是须要限度。整合尽管带来了益处，屏蔽了细节，然而工作太多在一起部分异样会影响全局，影响范畴也会变大。再就是目前实时集成并没有缓冲的机制，再遇到源端数据库批量解决的时候，比拟容易过程异样，须要针对性的调整内存参数后才能够复原，也影响了数据产出的时效。再就是目前实时集成在混合云只反对 oracle 和 mysql 这两种数据库，反对的数据库品种还是十分的少。
3 实时集成就能够解决全副问题
我敢置信，在设计之初，开发人员肯定是想用实时集成代替离线集成，因为相比离线集成实时集成更加完满。而且，我在之前的文章中也讲过实在的集成场景，实时数据集成肯定是支流，离线集成应该是辅助。
数据自身就是实时产生的，没有哪个原始数据不是实时产生的，只有后续的数据处理过程才可能离线。所以，实质上来说，原始的数据都是实时的，只有实时集成能力提供更高时效的数据用于数据分析。
以最罕用的数据库实时集成为例。数据库记录了业务零碎的操作型数据，业务零碎自身就是实时在变动的。网页日志记录了网页拜访的信息，这个过程产生的数据也是实时的。音视频数据流也是实时产生并且存储传输的。
那么离线数据是怎么来的呢？离线数据只是实时在变动的数据在某个时点的一个切片。咱们在做离线集成的时候，其实是向数据源端发动了一个某个时点数据的拜访申请。例如向某个数据库提交了一个 SQL，数据库会返回提交这个时点数据表的一个时点切片。这只是这个数据库表的某个时点状态，过了这个时点再提交，数据表返回就可能不同。
实时集成就像接了一个石油管道，石油会源源不断的从数据源流到数据中台中去。然而这个管道投资是微小的，如果管道中的油始终都是满载的传输还能够，实际上的数据产生更像是变幻莫测的天气，白天热早晨冷，偶然刮风下雨，偶然气候灾害。所以，实时集成也有本人的缺点。
相比之下离线集成占用管道的工夫是短暂的，然而都是满载的，效率上会更高。
实时集成的次要缺点就是投资大，不足灵活性。为实时集成配置的资源不能够依照最小评估，必须依照最高的去评估。不论是传统的 OGG 这种历史长达几十年的产品，还是 DataWorks 这种新秀，都是会常常遇到突发的数据洪流导致过程解体。很多 DBA 或者数据库从业人士，一提到 OGG 就都头大，运维简单压力大，稳定性也是差强人意。集体认为这次要还是因为老本效率的问题，经济划算的去运行，就得承受局部状况下的异样。
那么是什么起因导致的异样呢？一般来说，很少是因为业务零碎自身的起因，因为大部分交易型零碎不是双十一那种场景，数据库系统个别都被用来做与人相干的解决，自身就是离散的。我遇到的 100% 的数据库实时集成问题的起因无外乎两种，一种是后盾运维批量更新，另外一种是后盾批量数据处理（存储过程出个报表，做批量计算）。所以实质的起因是：数据库没有做交易型的业务，去做了批量型零碎。在遇到这种场景，实时同步就会很解体，因为大部分时候都是乖乖宝，然而忽然就变身了绿巨人，一下子就能够把实时同步过程搞解体。而且，这种状况，因为有人的参加，变得不可预测。
4 要为你的零碎做出抉择
谈到这里，你就晓得应该怎么做了。交易型可预测的局部做实时，因为实时简略牢靠，运维起来容易。不可预测的批量运维，和批量数据处理应该走离线，因为这两种操作自身就是一种离线解决。
再就是经济性，如果不思考老本，那其实能够尽可能全搞成实时，我用超大的资源节约来满足各种不可预测的异样，来保障我的运行。就像咱们国家的春运，是不是要把零碎设计成春运不堵车的模式，还是设计成平时不堵车的模式，还是看够不够豪。
而咱们做个别的小我的项目还是要考量一下的，上面是总结：
集成准则：
1 费用缓和，资源无限，尽可能应用离线集成。
2 批处理数据（次要指源端数据是批量产生，或者双十一式爆发式产生）集成，尽量走离线。如果的确估算十分短缺，资源十分丰盛，也能够走实时集成（很多时候，源端都可能扛不住）。
3 交易型数据集成，尽量走实时，如果资源无限能够走离线。
4 大表，例如数据超过 200W、存储超过 1G，尽量走实时，这种表个别在业务零碎中数量不会超过表数量的 20%。离线集成时效性很难满足要求，当然也不是不行。个别离线集成的表在 1 -10 亿这个级别也是能够一战（与系统资源相干）。再大基本上就很难了，集成工夫过久，业务零碎没有足够的快照空间，事务会报错，集成就会失败。
5 小表，例如长年不动的代码表，10W 以下的小表，大略都能在 30 秒 - 3 分钟内实现，倡议走离线。毕竟实时挺贵，这些小表，还是打包搞过来比拟适宜。
就到这里了，我为什么写这么多集成的文章，真的很头疼。我每年都要给新的搭档和客户教集成，每次还总能遇到新问题，把我搞的很狼狈。尽管集成看起来如同简略，然而真正客户化的把集成方案设计好，真的还是须要下一番功夫。
原文链接
本文为阿里云原创内容，未经容许不得转载。
