摘要：企业信息化过程造成了大量的数据孤岛，这些并不连通的数据孤岛是企业数字化转型的微小挑战。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 查看具体岗位介绍
原文地址：http://tapdata.net/tapdata-re…