如何高效整合分散数据，构建统一的实时数据平台？
数据孤岛一直是企业数字化历程的瓶颈，面临信息缺漏、业务流程难以优化、业务创新备受阻碍几大难题，传统数据平台无法支撑企业数据的按需按时使用，导致多交互场景完全无法支持。本文从实时数据技术与实际案例展开说明，探究为企业关键业务提供实时数据支撑的高效技术。
为企业使用数据提供方便易用的工具，随时简单用到新鲜数据是团队的愿景，我们希望把企业的数据用水管连接起来，变成基础架构，想用的时候数据就能过来。我们的使命也是解决企业数据孤岛问题。
从统计来看，大型企业平均业务系统有 315 套，中型企业平均 52 套。最近十几年，有很多企业在做数字化举措，涉及到洞察，对业务、客户、生产过程的理解，提高效率。近几年， AI 赛道火热，大家通过新技术为企业赋能，提高竞争力，但意识到离不开企业核心的数据资产，而这些数据目前都存在，二三十年前设计的架构。单体式架构封装在孤岛式的系统之内，导致获取数据困难，这对新的业务创新、洞察带来非常大的挑战。
各类数据平台是目前主流的解决方案，从 20 年前的数据仓库到 10 年前的数据湖，最近五、六年的数据中台，都是比较常见的、主流的方案，能够把企业各个业务系统的数据，采集放到中央化的分布式存储里面，在上面做数据分析计算，为洞察型业务分析提供能力。
其中的核心点是把数据从各个源系统中采集过来，进行加工处理，形成模型。核心技术是定时采集和批量处理。数据中台为什么不能做到很好的业务支撑。一是组织架构的问题，二是技术工具的不匹配度。数据中台号称支撑业务，但它采用了市面上常规的批量业务或定时采集能力，导致数据并不新鲜，无法为实时要求较高的业务场景，比如实时BI、实时Dashboard，或是交互式、跟客户、状态、订单相关的场景就不能起到支持作用。
什么类型的业务是实时业务场景，跟传统的业务系统有什么区别。我们说的业务，涉及到已有系统之外，利用企业的数据做新的事情，比如说实时驾驶舱等都在企业内常见的，便于让管理层第一时间了解企业情况。实时数据的获取和使用对此非常重要。
另一个典型场景是金融反欺诈，常见的信用卡，比如获取贷款，或刷信用卡。现在在金融行业，当一笔钱刷下去，会马上调取该卡号发生了什么交易，时间、地理区域，当发现不正常现象，马上停止交易，这就是实时数据引导的支持反欺诈行为的业务场景。
在产线上当生产设备出现问题时，若不及时发现，会导致今日生产都是瑕疵品。如果有实时的预警，则可以马上停止，降低损失。
在服务、金融、保险等行业，以前的客户画像是静态的，现在要求知道客户当下在做什么？下过什么类型的订单？对什么产品感兴趣？这样能增强客户的消费体验，同时提高对客户的实时数据进行采集的要求。
以上场景都需要数据的产生和使用，一个是源头，另一个是在新的场景使用，不是在源系统上做，要在新的地方做新业务，问题难点在于怎样在不改变运行多年系统的基础上做创新，涉及到数据要从已有的业务系统中实时传输到新库里，客户交互业务，要确保数据是准确的、一致的。但是因为异构分库是两套系统，在没有数据库事务的保证基础上达到数据准确是非常困难的事。新业务使用的模型要通过预计算的方式才能真正有效。这涉及到对数据在变化、采集时，实时地把它建成想要的业务模型。这两项技术在近几年都在尝试解决，但还没有前沿的解决方案，因为技术上确实比较困难。
对于实时业务场景的常见方案能否解决这些问题，几种主流实时数据流通企业级解决方案。
1、数据点到点的同步，告诉取数系统，无论是 ERP、CRM 也好，从源头打通端口，通过工具抓取数据。
2、通过企业总线链接所有系统。
3、基于 MQ 消息队列架构。
列举几种架构的特点。第一种点到点是最传统的，特点在于最简单直接，容易理解、实施。不足点在于重复劳动，往往一个业务需要 10 - 20 条链路，且链路都是临时拉的，没人管理它就会断裂，出了问题后也无法追溯源头，会引起非常多的管理问题，且存在相互依赖，会变得混乱——我们称为像意大利面情况——这在点到点集成中非常常见，特别是对大型企业来说，这是它比较突出的缺点。
ESB 企业总线是中央化架构，跟点对点区别在于可复用，企业所有数据集中到 Hub 上，所有人对接的链路条数跟系统数量是线性关系。线路数量会比较干净、清晰、合理。而且可在基础上按照统一标准的 API 接口、规范接口后不断将新业务持续接入。听上去很理想，但这套解决方案在最近十来年逐渐地被弃用了。有几大问题，一是 SOAP/ XML 的接口方式，开发、对接成本非常大，因为它非常繁琐，机制非常细致，导致会直接影响性能。在互联网时代还没爆发时还在使用。但在数据量爆发后，完全没法跟上时代，这些原因导致了它慢慢退场。
最近几年比较流行的是 Message Queue 方式， Kafka 是主流代表，特点是新一代的分布式架构，解决了性能问题。另一个非常重要的原因是开源，因为引入成本较低，在开始尝试时，不需要额外成本。弊端在于对代码对接要求比较高，架构维护成本高。
在了解到企业客户的痛点后，第一个出发点是简单易用，核心关键要让数据像在水管里流动一样，在这个基础之上，关键考虑希望用户容易使用，开源实时数据平台特点是具有多架构，支持低代码开发。技术架构所有的能力，都是围绕着这个链路开展。
平台多架构只是简单的场景，先做点对点的实时的数据流通。当进一步意识到更多的需求时。我们提供一个中央化的架构，叫实时数据服务。通过该方式把数据中央化，再用 API 的方式给到下游业务，另外一种场景就是用来做数仓的准备、做分析、做报表。分析场景里的实时分析是我们的特别关注，出发点是解决关键型的业务场景。
上图为 TapData 架构。首先最下层是企业已有的业务系统，左边是这些数据库，其中包括数据流。也有一些数据来自于业务系统，没法直接从数据层面对接，但会提供API，这些都是企业已有的数据源的存在。
第一个出发点是提供流式采集模块，基于 CDC 机制，核心是流包表或者表包流，把数据库的表转化成流，记录了源端不断发生的事件。如增加、修改、删除、更新状态，我们把它转化成流的事件，转化成流标准化，可以通过平台里面的复制模块，直接推送到下游的各实时数据库。
最难是采集，对于成熟度更高的客户，希望更优化的方式，比如对数据进行加工处理合并，我们提供的处理模块可做流式转化合并。主要能为两大类的业务场景提供支撑：分析类与业务类。分析类，TapData 数据平台可以配合数据仓库存储关系型用来做分析型场景。另外一大类是业务场景，业务场景指网页应用、手机应用、交互式应用、客户应用，需要核心数据，这是中台概念，我们把经过处理后的数据落地到存储里，直接实现轻量化的实时数据中台，马上为企业提供实时的数据服务。
第一步采集了数据以后核心点可以支撑三大类的业务场景。
1、点到下游的数据库 Kafka。
2、分析类的场景，例如实时湖仓、数据仓库或者数据湖。
3、提供企业级的核心主数据服务，这也是最为核心。
平台内有三大核心技术点，1、无代码实时采集，2、实时的物化视图能力，3、实时数据一致性保障。
实时采集能力也称为 CDC 机制，简单对该机制进行分析。左边是业务源系统，前面有业务应用，但不直接对接业务应用，因为无代码可低成本快速接入，只需要数据库账号，就会监听数据库的日志文件，把数据事件采集、分析，标准化成事件流，经过连锁处理。可以使简单的字段改名、改值或者是用 Python / Javascript 对数据进行自定义的加工，用目标连接器写到指定目标的数据库里，这是无代码采集能力的机制，整个过程部署完后，只需给到账号权限就可以完成数据链路的搭建。
物化视图能力非常关键，建数仓或建数据服务时，我们希望提供的数据给 BI 、看板或给 API 应用提供的已经是完整逻辑，直接可用的数据模型。我们平台提供部分能力，可以对几个表合并关联，一键启动，构建新的模型，通过预先计算、预先物化的方式，高效地在下游使用到数据，毫秒级查询，支撑实时交互式的业务。
主流的数据同步，现在多用 Kafka ETL ，用来做数据管道。用 Kafka 会涉及到几个模块，改写源端的业务应用，写 consumer 代码，采用 CDC 工具，要两三个方案合在一起才能解决问题，是个非常重开发的业务方案，对源系统也会侵入。TapData 方案是透明的，从已有库里采集增量日志，直接放到想要的地方，完成点对点。
某头部的内容平台最开始使用 Kafka ETL， 虽然目前还保留使用，但发现开发成本、维护成本都很高。当意识到很多业务用这种方案时，打算做小工具，帮助企业内部数据的流转，从已有业务系统搬迁到新业务系统，使用客户数据、会员数据、交互行为数据等等。考虑找实时数据的解决方案。经评估， TapData 使用后一年之内上线了大概接近 200 条数据链路，基本上节省了 70%- 75% 的成本增加，交给业务、开发团队，想要数据时，自助找源头，在获得权限的情况下把数据给接过来。
第二种场景是做中央化架构，作为 ESB 方案的替代，把数据从源头利用 CDC 机制中央化到分布式存储里。分布式数据库存储数据能达到高性能扩展。可为多个业务同时支撑，且数据足够新鲜，完全可以支撑交互式的手机应用或者网页应用。使用便捷，成本非常低。
另外用到表包流和流包表概念，不仅能取到流的数据，也可以在平台里取到表的数据， Kafka 大部分只能取到流的数据。TapData 解决方案提供两种可能性，根据业务场景的不同，按需选择。
以某珠宝零售品牌为例：有核心数据、商品数据、库存数据、客户数据、订单数据，分布在 9 套业务系统支撑门店运行。该品牌希望能有准时的、完整的、准确的系统，供总部知晓整个的商品的信息、库存状态等等。之前他们用 MQ 的方式，但很难管理、容易出错、没有统一监控、无法排查问题原因。利用无缝无代码方案把9套系统集成，在这过程中还形成了直观自然的模型，可以看到完整的商品信息，把属性加工处理好，快速配置API，一天之内给发布到测试环境，交给研发使用，效率提升非常明显。API 的开发生产力从以前的两三个月降到了一两周，流程上需要不断测试，再推到生产场景。那另外最核心的点，是终于有了全渠道商品平台，可交付给前端业务团队拿到所有数据。最大的特点是可以共享、重复使用。
最后一个案例是搭建实时数仓。某造船厂是人力密集型的企业，有几万员工，造船工序繁琐，管理难度非常大，内部很多系统投入运行，但相对孤立，没法串通做整体效率的提升。
所以他们试图做数据工作，但批量方式没法满足业务对实时性的要求，最后决定建立统一的数据平台。把业务系统集中到数仓后，主要用于实时 BI 场景，此场景非常关注实时性，因为要看效率分配情况，及时调配产线上的工人，所以只有实时数据有意义。这类分析更偏向经营性分析，所以对数据的时效性要求非常高的。
TapData 架构能为多种实时相关的企业的各种业务场景提供支持。较之当前平台方案，最大的核心区分点在于实时基础平台，可以为做升级的企业服务。升级后，除了已有的离线业务，可进一步地为企业的关键型业务提供实时数据的业务支撑。
产品优势：
- 开箱即用与低代码可视化操作
- 内置 100+ 数据连接器，稳定的实时采集和传输能力
- 秒级响应的数据实时计算能力
- 稳定易用的数据实时服务能力
【推荐阅读】
