摘要：企业信息化过程形成了大量的数据孤岛，这些并不连通的数据孤岛是企业数字化转型的巨大挑战。Tapdata Real Time DaaS 采用的CDC模式，具有巨大的优势，同时是一个有技术壁垒的活。当然，我们应对数据挑战的方式不止于此。
关键词：Tapdata,DaaS,实时数据同步,数据孤岛,CDC模式
（这部分放在文章的摘要和关键词那里）
随着信息化的日渐成熟，企业构建的相对孤立的数据系统也逐渐增多，从数十到数百，在大中型企业已经比比皆是。在这种情况下，想要使用企业的一些关键数据来做一些新业务，无论是可视化运营面板，还是建立一个新的CRM，都面临着企业数据难以获取的难题。
Tapdata 就致力于解决企业日趋严重的数据孤岛问题。我们的愿景是让这些企业可以像自来水(Tap Water)一样简单的使用数据。
那我们如何实现简单使用数据呢？
Tapdata DaaS 架构
类似与 IaaS，PaaS 或者 SaaS，Tapdata 给你提供一个 DaaS (Data as a Service) ，把你想要的数据作为一个服务提供出来。Tapdata 将企业各个业务系统的数据汇总到一个中央化平台，经过低代码方式治理以后，形成可复用的企业数据资产，通过无代码数据接口方式提供给业务使用方。
那 Tapdata 和其他数据平台的核心区别点和创新点是什么呢？Tapdata 做的是一个实时同步+实时处理+实时服务三位一体的全链路实时数据处理及服务平台。在Tapdata，我们坚信，实时的数据，才更有价值（查看Tapdata 产品理念）。
举个栗子：保险公司如何解决数据孤岛问题？
想象一下你在一家保险公司做研发。这家保险公司有若干套业务系统，寿险，财产险，特殊险等等。因历史原因系统是由不同业务部门分别建设的，所以各个业务系统都在各自管理自己业务的客户和保单数据。领导说为了提高客户体验，希望做一个微信小程序来让公司的客户可以通过小程序端来管理他们的所有保单，包括基本信息维护，保单一览表，保单付费管理等功能。基本的诉求就是要能够在一个地方看到不同保险业务系统的数据。为了做到这一点，你需要一个聚合表
CombinedPolicyTable，需要将来自Life, Property 和 Specialty系统内的保单数据全部集中放到一个中央的表里，然后让小程序来访问。
如何将不同业务系统的数据抽取到合并的CombinedPolicyTable？
方法有不少。
脚本方式
数据库导出脚本，ETL工具，自己写个SQL脚本。
通常这种脚本或者ETL都是定期执行的，比如说每天晚上会去各个业务系统库里运行这条命令：
SELECT * FROM POLICY;
将每个业务库的全量结果取出来写到CombinedPolicyTable里。
上面主流的模式香不香？
不香。
为什么？
其一，如果源库数据量大的话，这个是非常消耗资源的。每天晚上要对全量数据读一遍（源库），写一遍（目标库），哪怕白天只有100个保单更新。
其二，数据不及时。想象下如果小明同学在寿险系统里交了保费，但是要到第二天他才能在小程序中看到更新的状态（已支付），这个体验不连贯。
有没有体验好一点，源库的数据可以更加及时一点的方式？有。
双写方案
找业务同学改下代码，来个双写方案呗！当用户在源业务系统提交一个更新，先写原业务系统的表，紧接着把数据写到聚合表。
这种方式无疑是可以做到第一时间就把业务库的数据更新写入到目标表，然后给小程序提供最及时最新的客户及保单数据。
但也让人头疼：你要找原来的业务团队更新原有业务代码，并且这种方案对源系统有很大的侵入性。对于老大关注的顶级项目，没问题可以调动资源。但是如果类似的需求多了，就会出现不可管理，风险极高的后果。
有什么更好的解决方案呢？
认识更好的方案：Tapdata Real Time DaaS
Tapdata 的 Real Time DaaS 架构可以比较理想的解决上述问题。
CDC模式
从本质上，Tapdata的第一步就是将批量、滞后的ETL换成了CDC方式。
什么是CDC？
CDC 全称 Change Data Capture， 是基于数据库 Write Ahead Log 日志同步监听的方式来进行在不同系统之间的数据复制。 和传统ETL方式批量抽数不同，它能够在源库事件产生时候第一时间获知到相应的数据库增删改，并通过日志文件获取到该次更新的具体命令，然后在将这些改动通过一些处理后应用到目标库，目的是保持目标库和源库的高度一致。如下图，如果有一条写入，比如新增保单，首先这个写入操作就会以追加些模式写到WAL日志文件，然后才是写到数据文件。Log Collector 在无时不刻的监听日志文件（类似与linux 的tail命令一样），一旦发现日志文件有写入，马上将新改动的日志部分读取出来，解析成为可理解的SQL，然后写到目标库。
CDC模式的优势
CDC模式的优势很明显：
- 对源库性能影响小。取决于实现方式，有可能在单独读取日志文件，对源库主进程无影响。
- 只需要读取、处理数据库的变更事件（增删改），所需要资源消耗远小于全量跑批需要的资源
- 最重要的是，从事务在源端提交开始到更新写入同步的目标库，延迟可以小于1秒。这种准实时数据复制可以解锁大量对实时性要求较高的业务场景。
CDC 同步是一个有技术壁垒的活：
- 缺乏标准。大部分数据库都会提供标准的访问操作接口，如SQL。但是WAL日志属于各家内部实现，99.99%的程序员也不需要了解这个机制。
- 分布式下处理复杂。新一点的数据库都是分布式，如何在集群存在多个写节点的情况下保证WAL日志的顺序一致性和事务性？
- 日志的格式都会比较复杂，特别是涉及到事务提交及回滚的情况。
应对数据挑战不止于此
这听上去就是一个数据库实时同步的工作，那我是不是找一个同步工具就可以了呢？非也非也。
确实到目前为止，我们只是把需要的数据从源库里面无侵入，准实时的抽取了出来。这个也是Tapdata 数据平台的第一个核心部分：实时数据同步。 数据抽出来后，接下来的工作还包括：
- 如果数据来自多个库，往往需要对这些数据进行合并；
- 如果数据来自一个很老很复杂的关系型设计，往往需要对不太容易理解的表结构进行重构，组成新的模型；
- 如果数据来自一个主表（比如Policy），但是我们希望借这个动作，把Policy里面的客户信息也补齐进去。
这就涉及到一些实时的数据处理技术。欢迎继续关注 Tapdata 实时数据平台的第二环节：实时流数据处理。下期见！
本文作者：TJ 唐建法
2010-2019年 TJ 先后任职联邦快递首席架构师和MongoDB大中华区首席架构师，2019年至今于深圳创立Tapdata 并获千万美元融资。TJ 是具有丰富海内外工作经验的大数据领域专家，获得了阿里云 MVP、 腾讯云 TVP、极客时间 MongoDB 高手课金牌讲师等荣誉，创建了全球最大的MongoDB 技术社区，并引领国内实时数据服务技术发展。
也许你还想了解
Tapdata 数据库实时同步的技术要点
实时数据服务平台 Tapdata 产品简介
关系型数据库到MongoDB实时数据同步解决方案
招人小广告：我们现在迫切需要更多的工程师来加入我们一起，把 Tapdata 打造成一个世界级的实时数据处理平台，欢迎各位朋友一起过来撸代码，冲浪和定义平台未来。
我们亟需这些岗位的朋友加入我们：研发Leader，Java 中间件研发工程师，测试Leader，产品经理/总监，MongoDB数据库研发工程师，MongoDB 高级DBA，Oracle 高级DBA 查看详细岗位介绍