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分钟内完成，建议走离线。毕竟实时挺贵，这些小表，还是打包搞过来比较适合。
就到这里了，我为什么写这么多集成的文章，真的很头疼。我每年都要给新的伙伴和客户教集成，每次还总能遇到新问题，把我搞的很狼狈。虽然集成看起来好像简单，但是真正客户化的把集成方案设计好，真的还是需要下一番功夫。
本文为阿里云原创内容，未经允许不得转载。