为了更好地倾听开发者们的声音，共创优雅易用、功能完备的实时数据平台，Tapdata 现公开征集开源项目体验官，抢鲜体验优质开源项目 Tapdata ，成为社区首批成员，结识更多开发者同路人，与 Tapdata 携手挖掘数据潜能，第一时间获取项目最新资讯。
-
- 获得 Tapdata 开源 Issue、需求的特殊优先级
- 第一时间收获社区最新资讯（包括但不限于开发计划、核心技术、业务场景等）
- 参与活动、领取开源体验官新手任务、获得上午双肩包、潮牌 T 恤等更多好礼
- 有机会受邀加入 Tapdata Committer Program，成为正式的 Tapdata Committer
-
6月29日，Tapdata产品发布暨开源说明会线上开幕，围绕「Your Last ETL」这一主题，紧扣「实时数据」这一词眼，正式官宣自带 ETL 的实时数据平台 Tapdata Live Data Platform 上线，以及 Tapdata 核心功能的开源计划等重磅消息。
发布会现场，Tapdata 核心团队成员与多位数据行业专家、数据生态先行者、开源数据产品代表、企业客户代表及投资机构代表齐聚，着眼于“流动的”、“新鲜的”数据，结合历史解决方案与实践案例，站在生产、消费与资本等不同视角，共同探讨实时数据应用场景及技术变迁，深度剖析新一代实时数据平台的技术架构，深入洞察数据行业的发展现状与前沿优势，带来持续的干货内容和密集的精彩观点分享，高能不断，下面带您回顾本次活动亮点。
离线分析场景的数据诉求是已经发生了的过去，而实时业务场景的数据需求是明确的未来。而场景差异已然足够孕育一个新的技术架构。
不断增长的数据孤岛和历史方案的局限性
在过去数十年间，企业搭建了非常多的业务系统，且数量仍在不断扩张。而随着数据架构日益低代码化和平台化，企业又可以以更低的成本创建更多新的业务系统。企业的数据和系统由此也越来越多，这就直接导致数据孤岛问题的产生。由于系统间彼此并不连通，取用数据的过程就变得复杂，在真正用上数据之前，还需要做很多“额外”的工作，包括数据的打通、集成、融合等等。
企业数据集成的常见模式包括传统的 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 之所以选择自研一套新的技术架构，除了想要让产品变得小而轻、更好维护之外，还包含了自身的技术认知和追求。
在真实的案例场景中，Tapdata 发现，实时业务场景（OLTP）对数据的诉求与传统的离线分析（OLAP）具有本质不同。实时业务场景下，数据诉求一般是秒级；数据本身参与核心业务流转，每一条数据都与真实业务挂钩，单位价值高，对数据准确性的要求是 100%；业务数据量较之离线分析场景小很多。
如何更好地适应实时业务场景特性，并同时满足传统离线分析场景需求？Tapdata 基于 DaaS 架构的Live Data Platform 或将会是当前时代的最优解。Tapdata Live Data Platform 的重点在于 Live，在于数据的流动和鲜活，而这个一体化实时数据服务平台的技术架构，也是为了契合这个主题而设计的。
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 来完成怎样的工作？
可将 Tapdata LDP 用作一个实时数据集成平台（Real Time Data Integration），用以替换升级老一代 ETL 工具，像是 Kettle、OGG、Kafka ETL 等相对复杂的方案，或是 ETL 脚本等。
升级后的实时数据服务平台（Incremental DaaS），可以用来搭建企业级的数据共享中心，将企业核心数据放到中央化平台里，取代 ESB/MQ，在某些场景下还可以替代 Hadoop 大数据平台、数仓等，可以更好地为企业 BI 数据分析等下游业务提供数据服务支撑。
未来，Tapdata 还将推出实时主数据服务（Active Master Data Service），可以升级传统的以周或月为单位进行主数据更新的解决方案，Tapdata 的目标是通过实时的方式来更新主数据，并且借助 API 服务直接接入游业务中，让下游业务可以直接用上企业核心数据。
Tapdata LDP 是如何工作的？
如上图所示，左侧是企业的所有数据源，包括主流的 OLTP 数据库，以及业务系统、文件、信息流事件等等。Tapdata LDP 的工作机制是：
第一步，先基于日志解析的能力，通过开放式框架 Plugin Framework，以实时等方式，第一时间对这些数据源头中修改/更新/变动的数据进行采集并标准化，形成标准时间后进入流处理框架；
第二步，通过 Tapdata 自研方案，无需离开进程，在进程内即可完成数据计算、建模和转型，快速得出结果，进入 DaaS Storage 层；
第三步，在将数据放入 Storage 层时，实际上已经形成了一套逻辑模型，在这里，用户无需关心数据存储在哪里，只需要关注真正需要的是哪些数据信息；
第四步，也是 DaaS 的关键价值所在，在服务层，有两种主流的数据服务模式，分别是 Pull 和 Push。前者指的是 Tapdata 会自动发布一些 API，这些 API 支持低代码发布，可以按照具体需求发布数据。而当所需数据在业务系统中已有存储时，就可以通过 REVERSE ETL，反向把这些经过整理、治理的数据推送给用户，这也就是 Push 模式。
通过上图大家不难发现，所有数据驱动业务都在最右侧，并不包含在 Tapdata 四步工作流程之内。因为无论最终要用数据做什么样的业务，都是用户自身需要关注的事情，Tapdata 只专注于提供准确、一致的最新数据。这就是 DaaS 的精髓：我们不做业务，我们只为实时数据做准备。
【Tapdata 技术架构】
如下图所示，Tapdata 技术架构由一个大的插件体系、数据管理、系统和交互三部分构成。
其中，插件体系又包含数据和结构的集成、计算和算子集成、缓存集成等多个组成部分：
-
数据集成：用以对接各种数据源，包括平台主打的基于日志实时解析的数据库实时集成、以 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）为例：
实时场景不仅对数据接入的性能和准确性要求高，对各种异常情况下的可排查性、可恢复能力的要求也很高。为此，Tapdata 在批流一体等常见接口之外，还提供了很多虽然不常见但非常有用的接口方法，共同支撑起一个能够提供企业级数据准确性和稳定性保障的实时数据平台。例如：
- 全量增量的断点续传：偶尔犯错, 快速恢复
-
-
-
- 幂等设计: 保证数据的最终准确性
② META：优雅的模型自动推断体系
在数据准确性这个问题上，数据本身外，数据结构的准确性也不容忽视。随着数据源数量和类型的不断扩展，异构复制等场景对 Tapdata LDP 造成的维护压力只会越来越大，编译成本也会越来越高。对于这个问题，常见的解法有两种。一是基于 JSON 类型或语言原生类型进行结构描述，其弊端是往往会导致异构同步表结构不准确，需要用户手动调整。二是基于一些开源框架，使用时需要先在目标端手动创建表，才可以开始做计算。显然都不是很好的方案。
为此，Tapdata 给出了创造性的新思路——引入一个抽象的中间层，只需要描述数据源到中间层的映射，就会自动匹配出最适合的目标类型，给出映射关系，并自动构建目标表模型。该系统上线之后，用户侧遇到的建表不准问题大幅减少，同时也从根本上解决了数据源数量扩展的一大难题。
-
Incremental Engine：分布式轻量实时计算引擎
Tapdata LDP 的计算引擎全称是 Incremental Engine，顾名思义，专为增量实时计算设计，也是我们目前发现的最适合实时数据服务的引擎架构。引擎是一体化设计，相较于传统架构的多进程数据互通模式，Tapdata LDP 将链路变得极其简单。
源→引擎→目标，所有工作都在一个进程内完成，极大地降低了用户的使用负担。而极简并不意味着功能上的代偿，LDP 引擎的功能齐全。从基本的同步、转换，到高级的多流合并、多种聚合计算，LDP 引擎都有能力支持；数据来源、计算、算子、存储也都可以实现插件化扩展。此外，多个计算引擎之间，还实现了任务的自动故障转移，具备分布式高可用的优势。而且在多流无窗合并场景下，Tapdata 在满足数据准确性的前提下数十倍降低了资源消耗，这也是 LDP 的一项特色能力。引擎为 Tapdata LDP 提供了核心动力，完美适配实数据服务平台计算框架的需求。
-
CDC CACHE STORE：专为流计算场景优化的缓存引擎
CDC Cache Store 组件的设计初衷是用来缓存 CDC 增量事件。如下表所示，市面上常见的几种数据库，在增量订阅方面的表现，或多或少都存在一些缺陷，并不能很好地满足实时数据服务场景的需求。
面对流计算对存储引擎提出的顺序订阅和随机读写的矛盾诉求，Tapdata 选择对缓存存储进行抽象，自主开发了一个缓存引擎，在具备一定高可用性能的随机读写基础上，对事件定义的并发性能做了很大的提升，在支撑平台处理更多预算任务的同时，也让整个平台的技术架构变得更加干净。
-
API Service：打造端到端完整闭环产品方案
面对如黄金般珍贵的实时数据，Tapdata 力求将数据获取的便利性最大化。作为一体化解决方案，LDP 已实现如下能力：宽表直接发布为接口，帮助业务快速上线；数据库类型上层抽象，屏蔽接口差异；支持在线接口调试、运行；支持企业级管理，审计与监控功能一应俱全……由此，Tapdata LDP 让数据价值的发挥实现了完美闭环，这也是 Tapdata 的一个设计目标。
Tapdata 优势特性
作为新一代数据平台，Tapdata LDP 具有以下三大特征：
服务化架构意味着，我们能够把数据同步到中台中央化平台里进行复用，从而大幅减少从源头发出的数据链路，把链路的数量从数百降到数十甚至更少，降低对源头源库的影响。从数实数据集成角度来看，Tapdata LDP 需要更少的节点，可以从十几个进程降到两三个进程。而且边界清晰，专注于数据的第一公里或者前几公里，拒绝全家桶，专注基础能力。
② 全链路实时的能力：支持 TP+AP 场景，发挥更大的数据价值
这也是 Tapdata 主打的 DNA 品质，从 LDP 的命名就能看出 Tapdata 对 Live 的高度重视。Live 即鲜活、新鲜，Tapdata 全程面向具有最高价值的 TP 和实时分析的 AP 场景，旨在发挥更大的实时数据价值，主要体现在这几个方面：
-
采集实时：Tapdata 支持超 40+个数据源，支持源到目标 Any to Any 的数据实时同步对接，接下来还将通过开源的方式，在 Tapdata 主力之余，让开发者们参与共创，一起努力让数据源版图快速拓展到 100+。
-
传输实时：从源端到目标端，精准控制，实现了低至亚秒级的传输延迟。
-
计算实时：过程中需要计算时，Tapdata LDP 具有每秒数万条的实时流计算处理能力，单节点的情况下，通过并行分布式该能力还可以进一步提升。
③ 最易用的数据开发体验：面向开发者、面向数据工程师
站在审视一个数据产品的角度，Tapdata 非常关注 LDP 的易用性和灵活性，无需部署十几个节点，开发者、数据工程师直接下载就可以非常方便地使用起来，打造卓越的使用体验。Tapdata 提供了两种使用交互的方式：
-
全程可视化：面向数据工程师，支持对企业的所有数据进行托拉拽式的加工、建模、处理、合并，所见即所得，快速获取一个永久实时更新的数据模型。
-
首创 Fluent ETL API：面向开发者，特别针对开源社区，无需 SQL，只需要写一段程序就可以拥有数据集成能力，完成数据开发工作。
Tapdata 相信，IT 服务化是一个非常明确的趋势，从 20 年前亚马逊把基础架构作为服务开始（IaaS, Infrastructure as a Service），到十多年前把数据库中间件作为服务（PaaS, Platform as a Service），再到近几年特别火热的 SaaS（Software as a Service），“服务化”的发展非常快，服务化价值也得到了历史的证明。而如今的趋势，就是将数据抽象为一种服务，为下游的一切业务提供支撑。让数据使用像打开水龙头使用自来水一样简单，这是 Tapdata 的愿景，也是 Tapdata 命名的初衷——Make Your Data on Tap。
与此同时，我们也欣慰地发现，行业中已经有越来越多的视线开始投向这一赛道，期待集结更多力量推动数据技术的发展更进一步。
Tapdata LDP 现已开放自助体验通道
读到这里，相信大家对 Tapdata LDP 已经有了一定的认知。想要进一步了解更多相关信息？想要真正上手体验 LDP 产品功能？欢迎注册成为 Tapdata LDP 首批体验官，获取体验官专属服务：
“鱼”与“熊掌”兼得：Tapdata 并驾齐驱的开源与商业化
Tapdta 创始人 TJ 从写下 Tapdata 的第一行代码开始，就决定一定要将源代码开放出去。
6月的最后一天，Tapdata 开源版本正式上线。
无论是从公司的角度还是从行业生态的角度，开源与商业化从来都不是“鱼”与“熊掌”的关系，而是互为引擎的相辅相成。开源带来技术创新，为 Tapdata 输送生生不息的迭代动力；商业化收益反哺开源社区，又将为开源模式持续运转提供稳定的基础支撑。“开放”与“开源”正是 Tapdata 刻进 DNA 里的战略坚持。
Tapdata 为什么要做开源？
今天，已经有越来越多的企业和用户意识到了数据的价值。但复杂且繁琐的既有开源解决方案往往让很多用户望而却步。面对现存数据平台开源解决方案存在的链路长、非实时、成本高、难维护等缺陷，Tapdata 正在全力打造与之相对的一种快速、实时、简单、易用的新平台。Tapdata 希望以全自动化的实时数据集成能力为基础，连接并统一企业的数据孤岛，成为企业的主数据底座。
同时我们也深知：一个人、一个公司的力量是有限的，而 Tapdata 的愿景是远大的，在通往目标的路上，有大量挑战在等待着我们。我们需要社区的声音、用户的鞭策、积极的参与以及多方的帮助，一同将产品打造得更强。我们希望通过开源，让越来越多的开发者参与到 Tapdata 的使用与开发中来，帮助 Tapdata 开源项目实现更快的成长，更快地满足更多用户的诉求，让更多用户能够获得新鲜数据的价值，并带来更多的需求与场景。
Tapdata 创始人TJ 从写下第一行代码开始，就决定一定要将我们的源代码开放出去。我们已经准备好了——让 Tapdata 开源版本，为更多开发者输送实时数据的新鲜血液。
Tapdata 开源 RoadMap
如上面的开源路线图所示，6月30日发布的首个开源版本核心覆盖的场景是：实时数据同步、开发和 Fluent ETL。3个月之后，我们将发布 Tapdata 1.5 版本，预计新增实时数据校验、增量数据校验、自定义函数与聚合算子场景支持，同时将数据源补充到 50 个以上。
预计将于 2022年11月30日正式发布的 2.0 版本补充的核心能力包括：Any DB-To-API，数据目录、数据发现、数据溯源，并将支持的数据源数量提升至 80+。除此之外，我们还有非常多想要和所有社区开发者在演进过程中一同探索实现的能力，和共同交流解决的问题。在未来，Tapdata 开源版本还将推出 Open API、流式存储引擎、Open Metadata、Master Data 等多重重磅能力，敬请期待！
为了让社区组委会成员和志愿者朋友们灵活参与，同时我们为想要深度参与社区建设的伙伴们开设了“招募通道”，如果您想要在社区里面结交志同道合的技术伙伴，想要通过在社区沉淀有价值的干货内容，想要一个展示自己的舞台，提升自身的技术影响力，即刻加入社区贡献队伍~ 点击链接提交申请：
接下来我们会在诸多城市举办技术大会，如果您有优质的议题和 MongoDB 相关经验的嘉宾可以与我们分享，或者有赞助合作意向的小伙伴，包含但不限制于联合主办方、媒体合作等，都可以随时联系我们的社区助手小芒果（微信ID：mongoingcom）沟通具体事宜。
感谢大家一直以来对社区的关注与支持！社区在大家共同的努力下不断的发展与壮大，为了给大家营造更便捷的交流环境，QQ 技术交流群将同步在“微信技术交流群”中。扫描下方二维码添加小芒果微信发送“mongo”即可进入技术交流群。
MongoDB中文社区
评论前必须登录！
注册