数据集成平台 - SeaTunnel V2 架构演进

jxy819

[礼物]关注大众号“大话数智”，回复常识地图，下载数据集成常识地图
?导读跟着大数据技术的开展，各种各样的数据库、数仓平台、数据湖等技术不停发生，如何将这些数据在各个数据源和指标端之间进行同步、集成曾经成了企业面临的最大的问题。伴有着 Sqoop 从 Apache 服役，实时同步，CDC、整库同步等场景也渐渐被企业所注重和需求。在这个配景下，下一代数据集成平台 Apache SeaTunnel 专一于解决数据集成畛域的中心需要，以反对的数据源多、同步速度快、简略易用被泛滥企业承受和使用。
明天的引见会环抱上面四点展开：
1. SeaTunnel 的设计指标
2. SeaTunnel 现状
3. SeaTunnel 总体设计
4. 近期布局
分享佳宾｜高俊 白鲸开源 架构师
编纂整顿｜李铭 多点dmall
出品社区｜DataFun
01
SeaTunnel 的设计指标
首先和大家分享下 SeaTunnel 的设计指标。
1. 总体指标


作为一个总体的数据平台，SeaTunnel 的整体设计指标是成为一个简略易用的、散布式、可扩展的、反对超大数据级的高吞吐低时延的数据集成平台。
以后，数据集成面临的问题次要有五个：
数据源多：已知的数据库、湖、仓等数据源类型十分多，包罗一些 saas 网站、软件等，总数量乃至抵达几百种，伴有着新技术的泛起，这个数字还在不停下跌；不同数据源之间也容易泛起版本不兼容的状况，为数据集成平台形成了一些难题；品质难以包管，监控缺失：最常泛起的问题是数据的丧失和反复，很难包管数据的统一性；另外一方面，在数据同步过程当中泛起问题无奈进行回滚或者断点履行；同步过程当中的监控缺失也会带来信息的不通明，例如不肯定曾经同步的数据数量等；资源使用高：关于 CDC 的同步来讲，多个表需求同步时，频繁读取 binlog 对数据源酿成的压力较大；数据源侧一些小事务或者 Schema 变卦等都会影响上游；JDBC 这种同步，当衔接数过量时，有时无奈包管数据及时抵达；办理保护难：得多企业离线同步和实时同步是离开的，乃至需求写两套代码，不只日常办理运维十分难题，在进行离线和实时切换时，数据割接乃至需求人工进行；技术栈繁杂：企业的技术栈差别十分大，选择同步组件时学习本钱较高。02
SeaTunnel 的现状
接上去和大家分享下 SeaTunnel 的现状。
1. 反对衔接器数量


目前 SeaTunnel 曾经反对 50+ 的衔接器数量，包罗 Source 和 Sink 的衔接器，例如 ClickHouse、ClickHouseFile、Doris 等；还有 10+ 的 Transform；固然，当初还有许多的衔接器正在开发。
2. 批流一体


针对同一个衔接器，只需求写一套代码，就能经过配置使用批处置或流处置的模式进行同步处置。流处置的形式中目前完成的纯流和微批两种模式，次要是斟酌到要同时反对以 Flink 为代表的纯流和以 Spark 为代表的微批的形式。
3. 多引擎反对


SeaTunnel 的多引擎反对次要是为了更好的兼容企业现有的技术栈，升高企业在引入 SeaTunnel 的技术本钱。以后次要反对的引擎为：
Flink：反对多个版本的 Flink 引擎，并反对 Flink 的散布式快照算法等。Spark：反对 Spark 的微批处置模式，并能像 Flink 同样保留 checkpoint，以反对断点续传和失败会滚。SeaTunnel Engine：为数据同步设计的公用引擎，次要用于企业环境中没有 Flink 和 Spark 的引擎状况下，想要简略使用 SeaTunnel 同步数据的场景。SeaTunnel Engine 解决了 Flink 和 Spark 等计算引擎中泛起的一些问题，例如容错粒度大，JDBC 衔接过量，binlog 反复读取等。4. 机能和统一性


SeaTunnel 具有高吞吐、准确性和低时延的特性。
高吞吐：以后 SeaTunnel 一切的衔接器都做了并行化处置，从而进步全部数据同步的吞吐量。准确性：SeaTunnel 反对散布式快照的算法，在衔接器外部完成了两阶段提交和幂等写入，包管数据只会处置一次。低提早：借助实时处置和微批处置的特性，完成数据低提早。5. 社区活泼


SeaTunnel 去年年底进入 Apache 孵化，Star 数量骤升，微信誉户群已达十多个，近五千人摆布的范围。
6. 用户单一


SeaTunnel 曾经被许多用户使用，包罗互联网企业、传统企业等。
03
SeaTunnel 总体设计
第三部份给大家引见下 SeaTunnel 的总体设计。
1. SeaTunnel 总体架构


从以前的引见中大家应该能感触到，SeaTunnel 的中心就是衔接器。SeaTunnel 设计了一套独立于引擎的 API，与引擎解耦，并包管基于 API 开发的衔接器都可以运转在多个引擎之上。在实际运转中，经过 Translation 层将衔接器包装成对应引擎的衔接器履行。例如针对 Spark 履行引擎，在实际履行中，衔接器会包装成 Spark 的 Source、Transform 和 Sink，一样的情理也合用于 Flink。固然针对后面提到的 SeaTunnel Engine，就不存在转换的这一步了。转换后，SeaTunnel 会将功课提交到对应的引擎中履行，将数据同步到对应的存储中。固然，作为一个残缺的零碎，以及为了用户的敌对水平，SeaTunnel 还提供了 Web 页面，包罗代码开发模式的提交，或者疏导式工作提交，调度办事，监控和报警办事等。
全部架构波及六大症结点：
Engine Independent Connector API：独立的衔接器 APIConnector Translation：衔接器翻译层Source Connector：Source 衔接器Transform Connector：Transform 衔接器Sink Connector：Sink 衔接器多引擎反对2. SeaTunnel 使用形式


SeaTunnel 的使用形式十分简略，只需求填写配置文件，SeaTunnel 会自动解析并生成工作，进行提交开启同步。
3. SeaTunnel 履行流程


首先会针对来源引擎不同的 Source Connector 进行翻译，翻译后由 Source Connector 开始读取数据。接上去由 Transform Connector 进行数据的规范化终究经过 Sink Connector 进行写收操作。固然上述流程中还波及到引擎外部的一些处置，包罗分流，Spark 和 Flink反对 SQL 的语法等。
4. Connector 履行流程


目前能够分为 Driver 端和 Worker 端。在 Driver 端存在SourceCoordinator 办理 Worker真个 Source Split，之后存在枚举器将拆分后的数据工作交给 SourceReader 进行读取。在读取之后会将数据发送给 SinkWriter，此时会对散布式快照进行处置，终究把数据写入指标端。
5. Engine Independent Connector API


独立于引擎的 API 是在往年 3 月份正式进行设计的，中心设计指标是与引擎解耦，专门为数据集成的场景设计。中心指标有下列四点：
多引擎反对：定义一套 SeaTunnel 本人的 API，解耦底层计算引擎多版本反对：由于 Connector 和不同引擎的 Connector 之间设计了 Transform 层，就能解决引擎多版本问题，Transform 能够针对不同的版本进行翻译。流批一体：一样的一套代码，反对在批处置的场景下使用，也反对在流处置的场景下使用。JDBC 复用/数据库日志多表解析：解决 JDBC 衔接过量的状况，尽量经过一个衔接同步多张表的数据。同理，关于一个库下的表，尽量也只同步一次，多个表独立解析便可。6. Connector Translation


正如以前引见了，使用 Spark Connector API 能够将独立 API 翻译成Spark 的衔接器进行履行，同理也合用于 Flink。
7. Source API


Source API 次要反对五个特性：
经过 Boundedness 接口，完成批流一致。经过 SourceReader 和 SourceSplit 反对并行读取。经过 SourceSplit 和 Enumerator 反对静态发现分片。这个在流处置中更加常见，需求及时发现新增的文件分片；还有一种场景是经过正则表白式婚配 Topic，当新的能够婚配上的 Topic 泛起的时分，能够自动读取。经过 SupportCoordinate 和 SourceEvent 反对协调读取。这个次要用于 CDC 同步场景，在首次同步数据时，需求以批处置的形式全量同步数据，同步实现后被动切换成流处置的形式同步增量数据。经过 SnapshotState 反对形态存储和恢复。以后针对 Flink 引擎是间接使用 Flink 自带的 Snapshot 功用，关于Spark引擎，SesTunnel 定制完成了 Snapshot 保留到 HDFS 的功用。8. CoordinatedSource Connector


这个衔接器反对协调器，次要用于 CDC 的场景。它的次要履行流程为：经过 SourceSplitEnumerator 将一些信息（包罗 checkpoint、批流状况等）散发到 ReaderThread 外面的 SourceReader 中。
9. ParallelSource Connector


这个衔接器不反对协调器，反对并行处置。详细完成中需求在衔接器中定义分区的逻辑，自定义分区的算法。该衔接器类型反对多并发。
10. Sink Api


Sink API 次要是配合 Source 反对 Exactly Once 的语义。Sink API 包孕几个部份：
Sink Writer，接纳下游数据并写入指标端。State 存储，反对形态存储，由 Connector 将形态存储在 HDFS 中，反对基于形态重启 Connector。反对散布式事务，反对两阶段提交的散布式事务，配合引擎的 checkpoint 机制，包管 Sink 数据只写一次。Co妹妹iter，反对每个 Task 独立进行事务的提交，次要依赖 Flink 提供的这样的功用。反对聚合提交，次要用于 Spark 场景下，checkpoint 形态保留，需求使用到。十一. GlobalCo妹妹it Run In Driver


Sink API 外部 Co妹妹it 的类型之一，在 Driver 端运转，也就是下面提到的聚合提交。在这类模式下，Global Co妹妹iter 运转在 Driver 端，然而SinkWriter 运转在 Worker 端，次要合用于 Spark v2.3+ 以及 Flink v1.十二+ 版本的状况。
十二. GlobalCo妹妹it Run In Worker


Sink API 外部 Co妹妹it 的类型之一。这类模式下，Global Co妹妹iter 和SinkWriter 均运转在 Worker 端，次要合用于 Flink v1.十一- 的版本，Spark 不合用。
13. Co妹妹it In Worker


Sink API 外部 Co妹妹it 的类型之一。这类模式下反对在 Worker 端，每个 Task 独自的 Co妹妹it 操作。这个模式合用于 Flink 一切版本，Spark 不合用。
14. SeaTunnel Table & Catalog API


这套 API 次要为面向运用的 API，可以简化同步配置，提供可视化功课配置的根底。次要包孕上面四个方面：
数据源办理：SeaTunnel 定义了一套 API 来反对创立数据源插件，基于 SPI 完成后便可集成该数据源的配置、衔接测试任务等。元数据获得：次要用于疏导式界面，选择数据源后，反对自动获得元数据的表构造，便利可视化的配置同步功课的源和指标真个表名映照，字段映照等。数据类型定义：一切衔接器都使用 SeaTunnel 定义的格局，在 Connector Translation 会转换为对应引擎的格局。衔接器创立：SeaTunnel 提供了一套 API 用于创立自动获得信息创立 Source、Sink 等实例。04
SeaTunnel 近期布局


SeaTunnel 的中心指标为更多、更快、更好用，为了达到这个指标，SeaTunnel 近期布局指标为下列三点：
衔接器数量翻倍，总共能反对 80+ 衔接器。公布 SeaTunnel Web，反对可视化功课办理，反对编程式和疏导式的功课配置，反对外部调度（处置简略工作，crontab 为主）和第三方调度（以 dolphin scheduler 为主）。公布 SeaTunnel Engine，反对经过增加 JDBC 的衔接和 binlog 的反复读取以达到更省资源的成果；经过拆分工作为 pipeline，pipeline 之间的报错不会互相影响，也反对独立重启操作；借助同享线程以及底层的处置，推进总体同步工作更快的实现；过程当中参加监控目标，监控同步工作运转中 Connector 的运转形态，包罗数据量和数据品质。明天的分享就到这里，谢谢大家。
｜分享佳宾｜


｜《数据智能常识地图》下载｜
上下滑动????，查看《数据智能常识地图》数据收集模块，残缺版请关注大众号“大话数智”下载


｜DataFun新媒体矩阵｜


｜对于DataFun｜
专一于大数据、人工智能技术运用的分享与交流。发动于2017年，在北京、上海、深圳、杭州等城市举行超过100+线下和100+线上沙龙、论坛及峰会，已约请超过2000位专家和学者参预分享。其大众号 DataFunTalk 累计出产原创文章900+，百万+浏览，16万+精准粉丝。