数据孤岛一直是企业数字化历程的瓶颈，面临信息缺漏、业务流程难以优化、业务创新备受阻碍等几大难题。传统数据平台无法支撑企业数据的按需按时使用，导致多交互场景完全无法支持。本文从实时数据技术与实际案例展开说明，探究为企业关键业务提供实时数据支撑的高效技术。

　　分享嘉宾｜唐建法 钛铂数据 创始人&CEO

　　TapData 成立于 2019 年，是一家做实时数据的平台公司。公司成立的初衷就是为企业使用数据提供方便简易的工具，随时用到最新数据，解决数据孤岛问题。Tap 是指水龙头水管，企业的数据用水管连接起来，变成一个基础架构，可以随时打开水龙头获取数据。

　　从统计来看，大型企业平均业务系统有 315 套，中型企业平均 52 套。这些系统最开始从财务、ERP、MES 等都是为某一些业务准备，单一完成这些业务没问题。最近十几年，有很多企业在做数字化举措，涉及到洞察，对业务、客户、生产过程的理解，提高效率等等。近几年，AI 赛道火热，大家通过新技术为企业赋能，提高竞争力。实现以上任务都离不开企业核心数据资产，而这些数据资产目前都存在于二三十年前设计的多个单体式架构系统之内，导致获取数据困难，这对新业务创新、洞察带来非常大的挑战。

　　各类数据平台是目前主流的解决方案，从 20 年前的数据仓库到 10 年前的数据湖，以及最近五、六年出现数据中台，都是比较常见、主流、中央化的方案。能够把企业各个业务系统的数据，采集后放到中央化的分布式存储里面，在上面做数据分析计算，为洞察型业务分析提供支持。

　　以上主流方案的核心点是把数据从各个源系统中采集过来，进行加工处理，形成模型，定时采集和批量处理。

　　数据中台为什么不能做到很好的业务支撑？一是组织架构的问题，二是技术工具的不匹配度。数据中台号称支撑业务，但它采用了市面上常规的批量业务或定时采集能力，导致数据并不新鲜，无法支撑对实时要求较高的业务场景，比如实时 BI、实时 Dashboard，或交互式的、与客户、状态、订单相关的场景。

　　什么类型的业务是实时业务场景，跟传统的业务系统有什么区别？我们所说的业务，涉及到已有系统之外，利用企业的数据做新的事情。比如说实时驾驶舱，在企业内常见的，便于管理层第一时间了解企业情况。还有金融反欺诈，常见的如信用卡获取贷款、刷卡等。当一笔业务流水刷下去，可马上调取该卡号发生的交易类型、时间、地理区域。当出现不正常现象，则马上停止交易，这是实时数据引导的支持反欺诈行为的业务场景。

　　在产线上的实时数据运用也很多，当生产设备出现问题时，不及时发现会导致今日生产都是瑕疵品造成很大的损失。如果有实时预警，就可以马上停止，降低损失。

　　在服务、金融、保险等行业，对客户的实时数据采集提出了更高的要求。以前客户画像是静态的，现在要求知道客户当前在做什么？下过什么类型的订单？对什么产品感兴趣？最近打了什么电话？是否带有情绪？掌握了这些信息，能增强客户的体验，以便更好地留住客户促进再次消费。

　　以上场景都需要数据在源头与新场景的产生和使用，问题在于怎样在一套已经多年运行的系统上做创新。创新过程中不轻易对源系统进行更改，实现数据从已有的业务系统中实时传输到目标业务库里，同时要确保数据的准确一致性。这其中涉及两个技术难点，其一由于源系统和目标业务库是异构的、分库的两套系统，在没有数据库事务保证的基础上难以达到数据准确。其二，新业务使用的模型要通过预计算的方式才真正有效，这涉及到数据在变化、采集时，同时实时建成理想的业务模型。

　　这两项技术在近几年都在尝试解决，但由于技术问题，目前还没有前沿的解决方案。

　　对于实时业务场景的常见方案能否解决这些问题，几种主流实时数据流通企业级解决方案如下：

　　1、数据点到点的同步，从取数系统的源头打通端口，通过工具抓取数据。

　　2、通过企业总线链接所有系统。

　　3、基于 MQ 消息队列架构。

　　第一种点到点是最传统的，特点在于最简单直接，容易理解、实施。不足点在于重复劳动，往往一个业务需要 10 ~20 条链路，且链路都是临时拉的，没人管理它就会断裂，出了问题后也无法追溯源头。这些都会引起非常多的管理问题，且相互依赖，导致系统架构变得混乱，我们称为意大利面情况。特别是对大型企业来说，点到点集成极易形成复杂的意大利面架构，这是它的一个比较不好的点。

　　ESB 企业总线是中央化架构，跟点对点区别在于可复用，企业所有数据集中到 Hub 上，所有人对接的链路条数跟系统数量是线性关系。线路数量会比较干净、清晰、合理。而且可在基础上按照统一标准的 API 接口、规范接口后不断的将新业务持续接入。听上去很理想，但这套解决方案在最近十来年逐渐地被弃用了。因为这种方案存在的问题在于，其使用 SOAP/ XML 的接口方式，非常繁琐，机制非常细致，严重情况下会直接影响性能，并且带来的开发、对接成本非常大。这套方案在互联网时代还没爆发时还在使用，但在数据量爆发后，完全没法跟上时代，导致它慢慢退场。

　　最近几年比较流行的是 消息队列（Message Queue）方式， Kafka 是主流代表，特点是新一代的分布式架构，解决了性能问题。另一个非常重要的原因是开源，因为引入成本较低，在开始尝试时，不需要额外成本。弊端在于对代码对接要求比较高，架构维护成本高。

　　以上是当前主流实时数据流通企业级解决方案存在的局限性。

　　在了解到企业客户的痛点后， TapData 研发实时数据流通解决方案的核心关键要让数据简单易用，数据像水一样在水管里流动。开源实时数据平台，具有多架构，支持低代码开发的特点。实时是核心，技术架构所有的能力，都是围绕着实时链路开展。

　　平台支持多架构是如何展开？首先支持简单的场景，先做点对点的实时数据流通，当进一步有更多的需求时，我们提供一个中央化的架构，叫实时数据服务。通过该方式把数据中央化，再用 API 的方式给到下游业务。另外一种场景就是用来做数仓的准备，做分析、做报表，特别是细分领域里的实时分析，会解决一些关键的业务场景，我们的定位和出发点，建立一个实时数据平台为这几种架构服务。

　　上图为 TapData 架构。首先最下层是企业已有的业务系统，左边是数据库，有各类业务系统，还有一些来自数据流。有一些数据来自于业务系统，没法直接从数据层面对接，但会提供API，这些都是企业已有的数据源的存在。

　　第一个出发点是提供流式采集模块，基于 CDC（Change Data Capture ,数据变更捕获） 机制，核心是流包表或者表包流，把数据库的表转化成流，记录了源端不断发生的事件。如增加、修改、删除、更新状态，我们对数据进行标准化、流化处理后，可以通过平台里面的复制模块，直接推送到下游的各样实时数据库。

　　最难是采集，对于成熟度更高的客户，希望采用更优化的方式，比如事先想做一些计算，对数据进行加工处理合并。我们提供的处理模块可做流式转化合并，为两大类的业务场景提供支撑，分析类业务场景与业务类业务场景。

　　分析类业务场景中， 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 的方式，很难管理、容易出错、没有统一监控、无法排查问题原因。用 TapData 无缝无代码方案把9套系统集成，在这过程中还形成了直观自然的模型。可以看到完整的商品信息，把属性加工处理好，快速配置 API ，一天之内给发布到测试环境，交给研发使用，效率提升非常明显。API 的开发生产力从以前的两三个月降到了一两周，流程上需要不断测试，再推到生产场景。另外最核心的点，是终于有了全渠道商品平台，可交付给前端业务团队拿到所有数据，可以共享、重复使用。

　　最后一个案例是搭建实时数仓。某造船厂是人力密集型的企业，有几万员工，造船工序繁琐，管理难度非常大，内部很多系统投入运行，但相对孤立，没法串通做整体效率的提升。他们试图做数据工作，但批量方式没法满足业务对实时性的要求，最后决定建立统一的数据平台。把业务系统集中到数仓后，主要用于实时 BI 场景，此场景非常关注实时性，因为要看效率分配情况，及时调配产线上的工人，只有实时数据有意义。这类分析更偏向经营性分析，对数据的时效性要求非常高的。

　　TapData 架构能为多种实时相关的各种业务场景提供支持。架构跟当前平台方案本质上没什么区别，最大的核心区分点是实时基础平台，可以做升级的企业服务。升级后，除了已有的离线业务，可进一步地为企业的关键型业务提供实时数据的业务支撑。

　　在多变的市场环境下，实时性能支持企业即时响应市场动态、敏捷做出市场决策，对于企业市场竞争至关重要。传统的点到点数据同步、ESB 企业总线、消息队列等实时数据解决方案各有弊端或局限性，而多架构、低代码的现代化数据方案能够轻量、可扩展地支持多实时数据业务场景, 将成为未来企业布局实时数据业务的利器。