6月29日，Tapdata产品发布暨开源说明会线上开幕，围绕「Your Last ETL」这一主题，紧扣「实时数据」这一词眼，正式官宣自带 ETL 的实时数据平台 Tapdata Live Data Platform 上线，以及 Tapdata 核心功能的开源计划等重磅消息。
发布会现场，Tapdata 核心团队成员与多位数据行业专家、数据生态先行者、开源数据产品代表、企业客户代表及投资机构代表齐聚，着眼于“流动的”、“新鲜的”数据，结合历史解决方案与实践案例，站在生产、消费与资本等不同视角，共同探讨实时数据应用场景及技术变迁，深度剖析新一代实时数据平台的技术架构，深入洞察数据行业的发展现状与前沿优势，带来持续的干货内容和密集的精彩观点分享，高能不断，下面带您回顾本次活动亮点。
01
时代为何需要一个全新的实时数据架构？
离线分析场景的数据诉求是已经发生了的过去，而实时业务场景的数据需求是明确的未来。而场景差异已然足够孕育一个新的技术架构。
不断增长的数据孤岛和历史方案的局限性
在过去数十年间，企业搭建了非常多的业务系统，且数量仍在不断扩张。而随着数据架构日益低代码化和平台化，企业又可以以更低的成本创建更多新的业务系统。企业的数据和系统由此也越来越多，这就直接导致数据孤岛问题的产生。由于系统间彼此并不连通，取用数据的过程就变得复杂，在真正用上数据之前，还需要做很多“额外”的工作，包括数据的打通、集成、融合等等。
从历史信息系统到新的业务系统，企业数据集成的常见模式
企业数据集成的常见模式包括传统的 API、ETL，早期的 ESB，以及今天的主流 Kafka，在多种既有方案的影响下，企业内部产生了大量各种各样的数据集成链路。这些方案在满足了一部分技术需求的同时，也不可避免地在数据时代的演进中暴露出局限性。
历史数据集成解决方案及其局限性
其中，API 集成成本相对较低，只要具备一定的代码能力，无需第三方工具，即可由研发团队按照数据共享需求对系统进行 API 封装，为下游新业务供数。但直接在源库上构建 API 对性能的影响也比较大，且 API 通常会有 Rate Limit，难以支撑海量数据读写。此外，API 基本上只能对单库发布数据，难以跨库操作。
ETL 也是过去很长一段时间里的主推方案，这种方式的优势在于，不需要写太多 Java 代码或服务代码，而是通过工具或脚本的方式，来实现数据向下游系统的抽取复制。ETL 的局限性主要体现在不易管理上，因为太过简单且无法复用，导致每个新起业务都需要不少数量的 ETL 链路，最终散落在企业各处。
缺乏统一管理的的下场，就是痛苦的意大利面式结构状态。面对这一痛点，二十年前就出现了不错的架构解决方案——用 ESB/MQ 将数据都推到中央化的企业消息队列、服务总线上，然后将企业各个需要共享数据的系统，通过 API 和 Service 的方式连接起来，省去了多个系统之间两两交互的重复工作，降低了系统之间的对接成本。但整体成本仍较高，所以多用于商业化方案。而且开发复杂、系统耦合较高，性能又较低，很快就退热成了“明日黄花”，被类似于 Kafka 这样的分布式开源产品所取代。
大约十年前，Kafka 迅速流行起来，大量企业开始基于 Kafka 实现数据集成。但由于 Kafka 并非为此而生，最初只是一个分布式的日志存储，所以其架构设计特性更倾向于高并发、高性能、分布式。相较于数据集成要求的链路短、耗时短、延迟短，基于 Kafka 的 ETL 架构因节点较多，反而显露出长链路、数据容易中断、排查难等特性。如果想要实现，还需要做很多 Java 代码开发，使用复杂度很高。
最近十年，各种中央化数据平台打得火热，特别是以 Hadoop 为主的大数据平台，以及传统数仓、新一代数仓等代表，这一类方案的表现是将企业内散落在各个数据孤岛的数据集中化到一个平台里，从而实现通过中央平台统一获取需要的数据。但由于其技术架构多基于 Hadoop，本质上还是一个以离线分析为核心场景的技术栈，多用于对历史数据进行洞察、分析，数据不够实时，无法支撑对实时数据要求较高的一些 TP 型业务场景。
在综合考察了既有诸多解决方案背后的技术架构和局限性之后，Tapdata 开始思考用一种更好的方式来解决数据孤岛问题的可能性——做最后一次 ETL，也是实时的 ETL，通过数据镜像实现数据虚拟化，并对镜像数据进行中央化存储，经过一定的加工处理，形成一个可复用的数据 Copy 模型。然后在这个中央化平台上，以各种服务化方式为下游业务提供最新鲜的需求数据，本质上即 DaaS 概念的实现。基于此，Tapdata 自研了一套完整的产品化方案：Tapdata Live Data Platform。
Tapdata 选择了完全自研
优秀的开源组件如此多的今天，Tapdata 为什么不在这些优秀组建的基础上搭建解决方案，而是设计一套新架构呢？
诚然，沿用开源组件这样的模式的确可以在一定程度上解决一些问题，但并非最佳选择。Tapdata 之所以选择自研一套新的技术架构，除了想要让产品变得小而轻、更好维护之外，还包含了自身的技术认知和追求。
离线分析场景 vs 实时业务场景
在真实的案例场景中，Tapdata 发现，实时业务场景（OLTP）对数据的诉求与传统的离线分析（OLAP）具有本质不同。实时业务场景下，数据诉求一般是秒级；数据本身参与核心业务流转，每一条数据都与真实业务挂钩，单位价值高，对数据准确性的要求是 100%；业务数据量较之离线分析场景小很多。
如何更好地适应实时业务场景特性，并同时满足传统离线分析场景需求？Tapdata 基于 DaaS 架构的Live Data Platform 或将会是当前时代的最优解。Tapdata Live Data Platform 的重点在于 Live，在于数据的流动和鲜活，而这个一体化实时数据服务平台的技术架构，也是为了契合这个主题而设计的。
02
Tapdata Live Data Platform：首个基于 DaaS 架构的实时数据平台
事实证明，DaaS 体现了当下一种非常自然且合理的服务化趋势，即将数据抽象为服务，为下游的所有业务提供极易用的数据能力。Tapdata 的愿景就是构建一个以实时数据为 DNA 的 DaaS 平台，让用户无需关注底层技术，只需要关注业务逻辑和数据——像自来水一样，打开水龙头就能使用新鲜数据，就应该这样简单！
Tapdata 诞生于一个大家对 DaaS（Data as a Service）有了解但少有触及其本质的时期。彼时，将 DaaS 作为基础架构的数据产品可谓少之又少，但 Tapdata 认定了这个方向，并沿着这个方向不断努力。历时三年，精心打磨出首个基于 DaaS 架构的实时数据平台——Live Data Platform（LDP）。
三年锋芒初显：从 DaaS 先行者到自带 ETL 的实时数据平台
从锚定实时数据赛道迈出 DaaS 第一步开始，历时三年，Tapdata 目标中的数据服务化产品已初具规模。那么我们到底可以在哪些场景下用 Tapdata LDP 来完成怎样的工作？
场景1：实时数据集成平台
可将 Tapdata LDP 用作一个实时数据集成平台（Real Time Data Integration），用以替换升级老一代 ETL 工具，像是 Kettle、OGG、Kafka ETL 等相对复杂的方案，或是 ETL 脚本等。
场景2：实时数据服务平台
升级后的实时数据服务平台（Incremental DaaS），可以用来搭建企业级的数据共享中心，将企业核心数据放到中央化平台里，取代 ESB/MQ，在某些场景下还可以替代 Hadoop 大数据平台、数仓等，可以更好地为企业 BI 数据分析等下游业务提供数据服务支撑。
场景3：实时主数据服务
未来，Tapdata 还将推出实时主数据服务（Active Master Data Service），可以升级传统的以周或月为单位进行主数据更新的解决方案，Tapdata 的目标是通过实时的方式来更新主数据，并且借助 API 服务直接接入游业务中，让下游业务可以直接用上企业核心数据。
Tapdata LDP 是如何工作的？
Tapdata LIve Data Platform 的工作机制
如上图所示，左侧是企业的所有数据源，包括主流的 OLTP 数据库，以及业务系统、文件、信息流事件等等。Tapdata LDP 的工作机制是：
第一步，先基于日志解析的能力，通过开放式框架 Plugin Framework，以实时等方式，第一时间对这些数据源头中修改/更新/变动的数据进行采集并标准化，形成标准时间后进入流处理框架；
第二步，通过 Tapdata 自研方案，无需离开进程，在进程内即可完成数据计算、建模和转型，快速得出结果，进入 DaaS Storage 层；
第三步，在将数据放入 Storage 层时，实际上已经形成了一套逻辑模型，在这里，用户无需关心数据存储在哪里，只需要关注真正需要的是哪些数据信息；
第四步，也是 DaaS 的关键价值所在，在服务层，有两种主流的数据服务模式，分别是 Pull 和 Push。前者指的是 Tapdata 会自动发布一些 API，这些 API 支持低代码发布，可以按照具体需求发布数据。而当所需数据在业务系统中已有存储时，就可以通过 REVERSE ETL，反向把这些经过整理、治理的数据推送给用户，这也就是 Push 模式。
通过上图大家不难发现，所有数据驱动业务都在最右侧，并不包含在 Tapdata 四步工作流程之内。因为无论最终要用数据做什么样的业务，都是用户自身需要关注的事情，Tapdata 只专注于提供准确、一致的最新数据。这就是 DaaS 的精髓：我们不做业务，我们只为实时数据做准备。
【Tapdata 技术架构】
如下图所示，Tapdata 技术架构由一个大的插件体系、数据管理、系统和交互三部分构成。
Tapdata 技术架构概览：一图了解 Tapdata LDP 平台架构方案
其中，插件体系又包含数据和结构的集成、计算和算子集成、缓存集成等多个组成部分：
- 数据集成：用以对接各种数据源，包括平台主打的基于日志实时解析的数据库实时集成、以 API 和 Webhook 为特点的服务或应用的实时集成、来自 Excel/TXT 等文件的集成，以及来自 Kafka 等各种消息队列的集成等。目前，Tapdata 平台内已实现了对 40 不同数据源的支持，包括 Oracle、MySQL、PostgreSQL、SQLServer 等主流数据库、API、队列、物联网等，并且还在持续扩充更多的数据源和类型。
- 结构集成：与数据集成密不可分，提供数据结构的观察视图，可以帮助用户更理解自己的数据，了解数据结构自身的流动和变化。
- 计算和算子集成：对应引擎组件，承担了 LDP 的计算功能。是 Tapdata 专为实时数据服务场景打造的计算组件。在引擎中，用户可以完成拖拉拽、低代码构建 ETL 的任务，也可以基于 JS Python 等开发语言，可视化封装各种各样的操作组件，还能实现多流宽表流式聚合这样繁重的高阶能力，使用更方便。
相较于基于 Kafka 的 ETL，在使用上无需进行冗长的链路开发，链路更短、延迟更低、更易排查
- 缓存集成：对应缓存存储，是 Tapdata 基于流计算场景对于存储的独特诉求而特别设计的组件，是顺序和随机的矛盾结合体，代表了性能和准确性之间的高度平衡。
- 数据源插件：在完成数据计算之后，数据可以通过数据源插件写入用户需要的目标库，完成流转闭环。
- Data API：利用 Tapdata 内置的数据存储服务，还能直接将计算后的数据发布为 API 接口，做到了真正的数据即服务。
在数据管理部分，针对用户对数据探索和感知能力的诉求，LDP 提供了数据溯源、搜索和数据目录的功能。
在系统和交互的部分，系统模块主打企业特性，包括监控告警、全员审计等模块；交互部分则提供了基于浏览器的界面操作、交互式的命令行操作，以及可迁入 SDK 的集成操作，用来满足不同用户的需求。
初步了解 LDP 架构大框架之后，下文将基于几个重点模块来解析其设计原则的细节、搭建中遇到的问题和对应的解决思路。
【Tapdata 架构核心自研组建】
- Plugin Framework：插件化平台扩展体系设计
Tapdata 插件体系中的各个组件分别对应不同的扩展能力，“可扩展”这一原则体现在 Tapdata 架构设计的方方面面，为适应不同场景带来了便利。可以说 Tapdata 就是在插件体系上生长的平台。
选取几个具有代表性的数据连接插件（DataSource Plugin）为例：
① DATA：准确高效而稳健的数据接入
实时场景不仅对数据接入的性能和准确性要求高，对各种异常情况下的可排查性、可恢复能力的要求也很高。为此，Tapdata 在批流一体等常见接口之外，还提供了很多虽然不常见但非常有用的接口方法，共同支撑起一个能够提供企业级数据准确性和稳定性保障的实时数据平台。例如：
- 全量增量的断点续传：偶尔犯错, 快速恢复
- 数据回放：错已铸成, 快速回滚
- 获取源库最新事件时间：精准延迟判断
- 无条件心跳广播：避免稀疏事件的断点影响
- 幂等设计: 保证数据的最终准确性
② META：优雅的模型自动推断体系
在数据准确性这个问题上，数据本身外，数据结构的准确性也不容忽视。随着数据源数量和类型的不断扩展，异构复制等场景对 Tapdata LDP 造成的维护压力只会越来越大，编译成本也会越来越高。对于这个问题，常见的解法有两种。一是基于 JSON 类型或语言原生类型进行结构描述，其弊端是往往会导致异构同步表结构不准确，需要用户手动调整。二是基于一些开源框架，使用时需要先在目标端手动创建表，才可以开始做计算。显然都不是很好的方案。
为此，Tapdata 给出了创造性的新思路——引入一个抽象的中间层，只需要描述数据源到中间层的映射，就会自动匹配出最适合的目标类型，给出映射关系，并自动构建目标表模型。该系统上线之后，用户侧遇到的建表不准问题大幅减少，同时也从根本上解决了数据源数量扩展的一大难题。
