现在，数据的时效性会真正影响到一个企业的生存。
始终以来，以传统 BI 报表、数据大屏、标签画像等为代表的剖析型业务（OLAP），都是企业数据资源的重点利用场景。但 AP 型业务并不是企业的全副，同时还存在对数据实时性要求更高的新一代的经营型剖析（Operational Analytics）以及越来越多的交互型业务场景（OLTP 或 Operational Applications），更是企业的外围命根子。
本期分享将从企业以后的实时场景需要登程，围绕以下几个要点，具体解析实时数据的外延与新期间的计划抉择：
- 回顾当下企业的数据现状
- 介绍已有的实时数据集成场景
- 盘点罕用的实时数据集成架构和中间件
- 新老数据集成架构的技术比照，以及新一代企业级数据平台的技术架构详解
企业为什么越来越须要实时数据？
从依赖“人肉手工”写代码，到音讯总线开始呈现，再降级到起初的事件流中间件……数据集成架构在演进的过程中，解决了一些旧的问题，又逐步遇上一些新的问题。对数据实时性要求的进步，就是眼下很多企业遇到的一个新的挑战。
企业数据现状与实时数据场景
以制造业和批发行业实在环境下的典型场景为例：
① 高端制造业：影响工厂产能
- 企业类型：某国内大型半导体制造厂商
- 业务形容：通过 MES 对立调度生产线上的机械臂，实现芯片制作
- 实时问题：产能受限、基台告警不及时
不同于惯例生产流水线，半导体制作的无人实验室生产模式，高度依赖机械臂作业对复杂性与精密性工作的完成度，而这整个生产调度过程，又要通过 MES 零碎来实现。因而，MES 零碎数据推送或信号下发的工夫距离，间接关系到机械臂空转工夫，继而影响整个实验室的产能。这个距离个别是 10 分钟。
反过来说，如果能胜利缩短数据推送距离，就相当于晋升了机械臂的利用率；如果距离能达到秒级实时，生产速度则无望百倍增长，这其中蕴含的商业价值与竞争劣势显而易见。对于企业而言，最间接获益就是产能降级，充沛开掘实时数据劣势也一跃成为减速倒退的迫切需要。
② 高端批发：妨碍销售开单
- 企业类型：某珠宝行业
- 业务形容：店员通过商品核心实现调货 / 取货 / 查货
- 实时问题：商品信息不精确导致商机散失
不同于惯例快消品，珠宝因为本身客单价较高、交易频率较低、更多依赖线下门店的独特属性，在批发行业的细分畛域中更偏差传统、高端一类。也正是因为这样的非凡属性，对高端批发行业而言，单笔订单的成败，对销售额的影响也绝对较大，对门店销售服务的精确、疾速响应也有更高的要求。
在商品信息存储在多套零碎的状况下，门店一线销售人员就很难精确、实时地获取残缺的订单信息以及每一件商品的最新状态。如果不能在顾客提出需要后，第一工夫反馈商品是否有库存、是否须要调货，以及调货所需工夫等信息，就非常容易在信息查问与确认的“等待时间”里，导致潜在订单散失，对成交率造成不小的打击。这也是高端批发行业特地关注数据实时性的重要起因。
产能之于制造业；销量之于零售业——论断就是，实时数据，切实关乎企业的生死存亡。
不同数据集成计划在企业中的现状
① API 集成：开发太繁琐，对源端性能侵入影响高
- 劣势：不须要第三方工具，能够间接在源库上依据数据需要定制开发 API，随时调度扩大，间接从源端获取陈腐的业务数据。
- 毛病：对源端业务库产生较大压力，关系到外围业务零碎时尤为致命，以制造业为例，如果 MES 零碎因 API 调度解体，最间接的结果就是产能挂零。因而并不倡议在外围库上公布 API。
② ETL：实时性不够，无奈无效复用，造成意大利面的摊子
- 劣势：通过抽取的形式将须要的数据复制到上游零碎，对源库性能影响较小。能够通过本人写一些定期运行的脚本，或者应用一些成熟的 ETL 工具来实现，绝对简略。
- 毛病：实现原理是轮询，须要对源端数据库进行一些革新，例如要求源库有一个工夫戳字段，而后通过轮询的形式拿到近一段时间的变动数据，再把这些数据推到指标去，因而并不能达到真正意义上的实时，它达不到事实。定期执行，无奈撑持对数据时效性要求比拟高的场景。同时也无奈复用，每个新起业务都须要不少数量的 ETL 链路，治理艰难。
③ Kafka：架构简单，开发成本不低，要害数据排错很艰难
- 劣势：绝对成熟的数据集成计划抉择，能够用 Kafka 来搭建一个实时 ETL 链路，用事件流的形式可能捕捉到所有数据变动的每一个状态，并推到指标。
- 毛病：研发及运维治理老本较高。须要本人对接、实现数据采集的能力，很多时候意味着利用双写（代码侵入）或额定的开源组件；须要 Java 代码开发，超出个别数据工程师的能力范畴；节点多、链路长、数据容易中断、排查不容易，没有可视化治理，链路难以保护。
综上所述，随着新指标业务零碎的一直拓展，对源端业务的外围数据诉求越来越高，这三大类数据集成计划在企业中长期运行积淀的过程中，也产生了大量链路，而链路的复杂度、开发和保护老本，以及治理压力也逐步变得不可控起来。摊子越拉越大，工作难度一直降级——新的需要由此产生。这不是面向一个研发团队或是一个企业的挑战，这是新期间对数据集成解决方案的改革提出的要求。
矛盾决定需要：如何简化数据集成链路，实现疾速交付？
已知：实时场景普遍存在，对实时数据的需要很明确，开掘并充分利用实时数据来发明价值的指标也十分清晰。在这样的背景下，咱们要做的就是优化调整两头的实现过程。假如存在这样一个数据平台，可能解决当下数据集成面临的各种问题与实时需要，它应该如何设计？
新一代企业级数据集成平台：以服务化形式为上游业务提供数据
- 数据即服务的架构理念设计思路：节俭数据开发投入，专一业务翻新
造成一个数据集成平台，让企业可能在这个平台里疾速实现一系列的数据具加工、荡涤工作，从而得以更专一于业务开发自身，缩小大量繁琐的数据连贯、数据重试等数据层面的开发工作。
- 架构理念：数据即服务（Data as a Service, DaaS）
IT 服务化是一个十分明确的趋势，从 20 年前亚马逊把基础架构作为服务开始（IaaS, Infrastructure as a Service），到十多年前把数据库中间件作为服务（PaaS, Platform as a Service），再到近几年特地炽热的 SaaS（Software as a Service），“服务化”的倒退十分快，服务化价值也失去了历史的证实。
在这一趋势的启发下，咱们尝试将数据即服务的概念引入新一代数据集成解决方案，主张以服务化的形式来解决数据集成的问题。实质是将数据抽象为服务，为上游的所有业务提供极易用的数据能力。目标是以地方化的能力代替传统计划中的简单链路，更专一于计算解决环节。
-
外围劣势谋求：疾速、施行、简略、易用
最初一次 ETL：对源端系统只做最初一次数据同步。把源端业务库的数据 1:1 抽取过去之后，同步进来的数据将在两头的地方化存储里实现数据的全副荡涤、加工等解决，同时对源端的业务库不会再有任何抽取工作了。间接弱化了链路的复杂程度，极大升高对源端业务的侵入。
API 服务：最初能够通过 API 的形式将数据推送到指标端。这里能够设想一下，当咱们实现了一次订单的宽表或是订单的数据汇总之后，接下来所有业务零碎想要获取该订单的数据，都能够间接通过读取 API 取得，非常简单。甚至连存储都不须要，因为所有的数据都是实时的，又能够通过 API 服务的形式间接提供，这对于接下来要做的新的业务零碎来说都是十分不便的。
基于这样的计划构想，咱们设计了一套全新的数据架构：
如上图所示，从左至右，是这个数据集成平台的数据流向：左侧蕴含各种各样的业务零碎，在剖析型业务之外，更多的还是企业的要害业务零碎，例如 ERP、MES、供应链等企业外围命根子。右侧代表数据指标，平台要做的，就是将所需数据从左侧的业务零碎中实时采集、推送过去。
- CDC Capture（采集与同步）：基于 CDC 的无侵入数据实时采集与同步模块，以实时的形式，第一工夫对数据源头中批改 / 更新 / 变动的数据进行采集并标准化。
- Stream Process（计算与解决）：无需来到过程，在过程内即可实现数据计算、建模和转型，疾速得出后果，将存储过程对性能耗费极大的计算局部放到这一层来解决，也可缓解源库压力。Storage（地方化存储）：造成可能复用的对立的数据模型，提供对立的数据规范，反对按需取用。
- Service（公布与服务）：通过数据公布能力，以 API 的模式出现，或是间接按需传入数据指标，例如数据库、利用，或是 Web 服务等，从而达到更快获取所需数据的目标。
实时数据平台的核心技术路线
在推动新计划落地的过程中，咱们在技术层面遇到了如下四点挑战：
- 基于 WAL 日志的实时异构同步（实时异构同步的 CDC 能力）
- 数据开发建模
- 地方化存储
- 数据公布 API
① 重中之重：异构数据的实时同步（CDC）
CDC，即 Capture Data Change，捕获事件变动，不同于传统 ETL 定期执行轮询的形式，曾经齐全脱离了数据 SQL 的查问形式自身，间接监听日志变动，实时追踪数据记录的增删改。在实现 CDC 能力之前，其实曾经有很多实时同步的技术架构呈现，像是基于工夫戳或者增量字段的采集形式，以及 Trigger 推送等，但或多或少都存在一些局限性。在这些挑战中，首要一点就是连贯层（Connector）的问题。
如上图所示，Connector 层是数据实时同步的第一步，数据源不同，Connector 也不同。字段大小写转换、数据类型转换、荡涤、计算、加工……对于不同的数据对象，在将数据推送至指标库之前，还须要进行大量解决操作。而 CDC 实质是 WAL 日志的解析形式，其实曾经脱离了数据库类型的限度，是一种回归数据库日志自身的计划。
以数据源是 Oracle，数据指标是 MySQL 为例：如上图所示，写入 Oracle 的数据，最先会进入 Online Redo Log，即落入 Memory Buffer 中，这时就能够对这些数据进行开掘了。刚写入就抓取，像这样基于数据库事件的开掘，无疑是最实时的形式，比起轮询要快得多。
开掘之后，再对这些事件进行日志解析，解析进去的日志无非就是 Undo 和 Redo 两条 SQL，别离代表 delete 和 insert。再通过数据对象转换，匹配 Oracle 与 MySQL 的数据类型，实现整个事件流的回放，胜利将 Redo 日志推送到指标库。出于对数据平台集成能力的整体考量，在事件回放过程中，断点续传的能力也不容忽视。上图中的 OFFSET 就是用来记录事件偏移量的，是数据同步的准确性和正确性的重要保障。
② 最易用的数据开发体验：面向开发者、面向数据工程师
- 全程可视化：面向数据工程师，反对对企业的所有数据进行托拉拽式的加工、建模、解决、合并，所见即所得，疾速获取一个永恒实时更新的数据模型。
- 独创 Fluent ETL API：面向开发者，特地针对开源社区，无需 SQL，只须要写一段程序就能够领有数据集成能力，实现数据开发工作。
③ 地方化存储计划：DaaS
- 多源异构数据实时汇聚到地方化平台
- 为所有上游数据驱动业务提供实时、残缺、精确的企业数据
地方化存储面临的关键问题就是数据是否落地，因为落地代表着数据可复用，如果不能落地，实质就还是一个同步工具而非数据平台。为此，咱们将数据落在一个集中化的治理中，而不是像一些传统计划一样间接推到指标端。这样的益处是：一方面能够将对源库的压力降到最低，另一方面更便于数据的复用。
④ 数据公布 API
反对将各库各表的数据以 API 的模式公布，并作为一种资源供不同的业务方调用，在对立数据接入层的同时，也大大降低了运维的压力和工作负载。
分部 / 总部单点架构阐明:
- Tapdata Management：负责软件各模块调度和网页控制台展示
- Tapdata API Server：负责数据公布及 API 网关
- Tapdata Flow Engine：负责数据同步、荡涤、多表关联、聚合计算等
- MongoDB：Tapdata 数据库，两头缓存后果
2 节点可反对负载平衡及高可用，保障单点故障后的工作主动接管及断点续传
构想照进事实：Tapdata Live Data Platform
Tapdata：自带 ETL 的实时数据平台
DNA 品质：全链路实时的能力，反对 TP+AP 场景，施展更大的数据价值
Tapdata 全程面向具备最高价值的 TP 和实时剖析的 AP 场景，旨在施展更大的实时数据价值，次要体现在三个方面：
- 采集实时：Tapdata 反对超 40+ 个数据源，反对源到指标 Any to Any 的数据实时同步对接，接下来还将通过开源的形式，在 Tapdata 主力之余，让开发者们参加共创，一起致力让数据源幅员疾速拓展到 100+。
- 传输实时：从源端到指标端，精准管制，实现了低至亚秒级的传输提早。
- 计算实时：过程中须要计算时，Tapdata LDP 具备每秒数万条的实时流计算解决能力，单节点的状况下，通过并行分布式该能力还能够进一步晋升。
Tapdata 最佳实际
我的项目背景
- 客户简介：出名黄金珠宝企业，大陆门店数量上百家，年营业超百亿
- 业务形容：与第三方电商、社交、媒体平台买通；数百家门店线上线下流动过万；业务需要旺盛，产品疾速迭代实用商场
Tapdata 提供的整体解决方案
- 构建底层数据链路：在最底层的数据库和 Tapdata 的地方化存储之间搭建一条数据实时同步链路
- 进入贴源层，构建蕴含企业外围业务数据的主数据层；在主数据层之上业务模型，通常是不同我的项目对于主数据的复用需要，这个过程中须要用到 Tapdata 的数据集成能力、数据开发能力，以及数据的地方化存储。
最终的客户外围诉求实现
- 反对全渠道销售业务：实时对立多套零碎的库存和商品信息，从 0 到 1 撑持了全渠道营销业务
- 大幅晋升开发效率：撑持前端的数据 API 开发上线工夫从数星期降到到了 2 天
- 构建主数据库进步复用：数据不统一、地位凌乱的问题失去妥善解决，治理好的主数据进步了复用，缩小反复老本
Tapdata：Make Your Data on Tap
以全自动化的实时数据集成能力为根底，连贯并对立企业的数据孤岛，成为企业的主数据底座，为企业的数据驱动业务 “Warehouse Native” 提供全面，残缺，精确的数据撑持——这便是 Tapdata 的愿景与谋求。
还有更多无关实时数据集成的问题亟待解答？想要真正上手体验新一代实时数据平台？
欢送扫描上方二维码，注册成为 Tapdata LDP 首批体验官，获取体验官专属服务。咱们期待与您共创一个更加优雅易用的新一代实时数据平台，见证实时数据的更多可能。
原文链接：https://tapdata.net/enterpris…