关于数据同步:可视化任务编排拖拉拽-Scaleph-基于-Apache-SeaTunnel的数据集成

这次在 6 月 Meetup 为大家带来的是 Scaleph 基于 Apache SeaTunnel (Incubating) 的数据集成介绍，心愿你有所播种。

本次演讲次要包含五个局部：

1. 对于 Scaleph
2. Scaleph 架构 & 性能简介
3. SeaTunnel 社区奉献
4. 零碎演示
5. 开发计划

https://www.bilibili.com/vide…

↑↑直播回放视频入口↑↑

王奇

Apache SeaTunnel Contributor

搜寻举荐工程师，大数据 Java 开发

01 Scaleph 的缘起

我最早是从事搜寻举荐工作，在团队外面负责保护 Dump 零碎，次要是为咱们的搜索引擎提供喂数据的性能，先给大家介绍在保护过程中次要的 5 个痛点问题：

及时性和稳定性

搜寻举荐是电商平台的外围在线零碎，尤其是对数据的及时性和稳定性要求十分高。因为搜寻举荐会接管整个电商平台 C 端的绝大部分流量，所以一旦服务呈现稳定的时候，可能就造成服务受损，导致用户的体验大打折扣。

业务简单 / 大宽表设计

Dump 零碎会将电商平台的商品、类目、品牌、店铺、商品标签、数仓的实时 / 离线数据及模型数据会通过一系列的预处理，最终输入成一张大宽表，在这个过程中，业务的复杂性和多变性，会侵入到 Dump 零碎中来，所以应答的技术挑战绝对就更高了。

全量 + 实时索引

全量索引每天跑一次，次要目标是更新 T+1 频率更新的数据。当全量索引完结之后，咱们会通过实时索引去刷新须要实时更新的数据，比如说商品的价格、库存变动相干的信息。

数据联动更新

咱们的上游数据起源十分多，有音讯队列、数据库、大数据相干的存储以及 dubbo 接口，因为是大宽表设计，以商品索引为例，大宽表会以商品为主，如果是店铺索引，会以店铺为主，依据数据的不同，上游的数据变动不肯定是商品或店铺维度的，数据也会产生肯定的联动更新。

数据兜底

搜寻举荐服务过后也承当着 C 端绝大部分的流量，当公司其余团队的性能跟不上的时候，他们个别会把数据通过 Dump 零碎送到搜索引擎，而后咱们团队代替他们返回给 Web 页面，防止后续对他们发动二次申请调用。

同时，如果其余团队的业务零碎产生了脏数据，也须要 Dump 零碎做数据保护，避免数据外泄给 C 端用户造成不好的影响，所以开发保护中的时候，也有很大的难度。

02 为什么引入 Flink？

作为国内 Flink 的晚期使用者，阿里巴巴在搜寻举荐畛域领有悠久的历史和胜利的教训，在搜寻举荐团队开发保护 Dump 零碎的职业经验促使我开始关注应用 Flink 做 A / B 试验的报表、数据实时流之外的相干工作，次要也就是用 Flink 来实现 Dump 零碎为搜寻去提供 Dump 平台的工作，应用 Flink 做数据集成有 5 个长处：

1. 人造的分布式反对：Flink 反对多种部署和运行形式，单机、yarn、Kubernetes；
2. 低提早、海量吞吐：在泛滥大厂中利用宽泛；
3. 生态反对：Flink 提供了泛滥开箱即用的 connector，反对 csv、avro 数据格式，kafka、pulsar 等音讯零碎以及泛滥的存储系统，和大数据生态紧密结合；
4. 基于分布式轻量异步快照机制实现 exactly-once 语义，为工作的失败、重启、迁徙、降级等提供数据一致性保障；
5. metrics。Flink 除了本身提供的 metrics 外，metrics 框架能够让用户为工作开发自定义的 metrics，丰盛监控指标；

03 为什么抉择 SeaTunnel？

起初接触到 SeaTunnel 的时候，很喜爱 SeaTunnel 的设计理念！SeaTunnel 是运行在 Flink 和 Spark 之上，高性能和分布式海量数据的下一代集成框架。

重要的是它是开箱即用的，并且针对现有的生态能够实现无缝集成，因为运行在 Flink 和 Spark 之上，能够很不便地接入公司现有的 Flink 和 Spark 的基础设施。另一方面 SeaTunnel 也有很多的生产案例，在进入 Apache 基金会孵化之后，社区十分沉闷，将来可期。

04 对于 Scaleph

我的项目出发点

咱们最开始的想法就是为 SeaTunnel 提供 Web 页面，可能做一个数据集成的开源零碎。目前咱们最次要的指标还是想为 SeaTunnel 做一个开源可视化的数据开发和管理系统，前面冀望 Scaleph 可能最大水平的升高实时和离线数据工作的开发门槛，为开发人员提供一站式的数据开发平台。

我的项目亮点

在真正的生产利用中，进行数据集成的时候，以可视化工作编排或 SQL 开发为数据集成的次要模式，咱们认为 Drag and Drop 可视化工作编排能够最大水平加重用户做数据集成的累赘；

另外就是实现对作业进行多版本治理，数据源的反对；

• Flink 集群反对多版本 / 多部署环境；
• 实时 / 周期工作也有相干的反对。

下面是咱们零碎的架构图，用户次要应用 Web UI，通过作业管理性能封装的 SeaTunnel 算子，用户在页面进行利落拽配置，零碎主动生成 SeaTunnel 的配置文件，最初通过资源管理中用户上传的资源 jar 包一起通过 Flinkful 库提交到 Flink 集群中。资源管理的资源 jar 包的存在目标是反对用户能够上传自已研发的相干 jar 包，补足 SeaTunnel 相干的缺点，或对 SeaTunnel 和 Flink 自身的性能进行加强！

咱们用 quartz 开发了一个调度工作，当工作提交到 Flink 后，工作会定时去 Flink 集群将工作信息拉过来，存储到 MySQL 外面，最终用户在 Web UI 页面能够看到工作相干运行信息。

Scaleph 性能简介（数据开发）

01 项目管理

次要是用户创立数据同步工作的时候，可能依照不同的业务维度进行相干的管理工作。

02 作业管理

通过利落拽的操作能够创立 SeaTunnel 的数据工作，而后进行相应的提交运行。

03 资源管理

SeaTunnel 是以 Apache2.0 开源证书进行开源的，与 MySQL 的 JDBC 驱动包开源协定不兼容，SeaTunnel 的 jdbc connector 是不提供相干的 JDBC 驱动依赖的。当用户应用 jdbc connector 时，须要自行提供 JDBC 驱动包。咱们在这里提供了资源管理的性能，用户能够本人上传驱动包，而后再把 SeaTunnel 工作和 MySQL 驱动一起提交到集群中以保障工作的失常运行。

04 集群治理

次要是提供 Flink 集群信息的录入，目前能够反对 Standalone Session 集群录入，用户录入后，提交 SeaTunnel 作业时就能够抉择集群，工作就会在集群运行。

05 数据源治理

反对用户提前录入一些数据源信息，这样就不必每个工作都把数据源信息输出一遍。同时，还能够去实现数据源的共享和权限限度，避免数据源信息明文泄露。

Scaleph 性能简介（运维核心）

运维核心是一个实时工作和周期工作的运行日志，用户提交工作的时候看到工作相干的信息，咱们还提供了链接跳转操作，用户点击能够跳转到 Flink 的 Web UI 下面去，通过 Flink 官网的 Web UI 页面，能够看到工作具体的执行信息。

Scaleph 性能简介（数据规范）

01 数据元

数据治理是个大的体系，大家比较关心元数据、数据血统、数据资产，然而数据规范也是数据治理的重要一环，咱们把公司本人外部应用的规范零碎开源进去，给大家分享数据规范的相干常识。

在很少数仓的开发过程中，因为是多人合作的，同样一个含意的字段，在不同的模型表中，开发会定义不同的字段来表白同样的含意和业务。数据规范心愿能通过数据元，来对立数仓开发人员的模型字段定义。

02 参考数据

数仓中的数据是通过数据集成工具从业务零碎中拉过来的，会不可避免地呈现同样含意的字段在不同业务零碎中有不同的定义，而这些含意雷同定义不同的字段就须要数仓人员去进行保护，而且保护的过程以线下文档为主，可能存在保护过期的状况。

同时也会呈现业务知识无奈间接映射为数仓模型信息的问题，数据规范让用户能够在 Web 页面中对这些业务知识进行保护。

上图是一个具体案例。这里是定义的两个业务零碎，一个是零碎 A，一个是零碎 B，它们别离有不同的性别枚举值，同时 A / B 零碎的枚举形容也都不一样，那怎么办？

这个时候，咱们通过数仓开发人员能够定一套对立的规范，比方把编码对立定为 0，1，2，相应的形容也定义好，通过两头的一个参考数据映射，用户就能够不便的去看。

03 后续构想

是否能在数据集成过程中，间接通过数据规范进行 Transform 操作，实现常识和模型主动保护和映射。

04 Scaleph 性能亮点

数据的可视化开发。咱们认为在数据同步畛域，可视化利落拽，能够帮忙用户疾速创立数据集成工作，用户利落拽出两个算子，填写相应的参数就能够创立数据集成工作。

Flinkful 是咱们为 Flink 开发的一个 Java 客户端。

Flink 作为一个风行的计算引擎，提供了很多形式让用户应用，比如说命令行接口、HTTP 接口等，通过命令行接口用户能够提交工作、创立工作及勾销工作；HTTP 接口次要是用于 Web UI 界面。

在对接 Flink 的过程，咱们发现 Flink 作为一个运行在 JVM 之上的一个利用与同样运行在 JVM 之上的 Scaleph 利用，二者的集成却要通过 shell 脚本，很不合理。所以咱们开发了 Flinkful，关上 Flink 在 Java 生态的凋谢能力，让用户通过 Flinkful，能够间接对 Flink 集群和工作做治理。

咱们认为 Flinkful 对 Flink 基础设施保护人员是比拟有意义的，所以从 Scaleph 仓库中剥离进去，独自开源。

插件体系。
咱们心愿通过定义插件，提供零碎扩大接口，用户和 Scaleph 开发者能够通过这些接口疾速加强 Scaleph 的性能和个性。目前咱们定义了两个插件，别离是数据源插件和 SeaTunnel 插件，通过数据源插件能够疾速扩大出 JDBC、ES、Kafka、Clinkhouse 之类的数据源，把这些数据源集中到 Scaleph 零碎进行对立的配置和应用。

目前 SeaTunnel 外面提供了很多 connector 和 transform 插件，如果逐个去开发页面的话，是比拟耗时的一个事件，咱们就想着用一种简略、申明式的形式，把 SeaTunnel 相干的参数定义进去，能疾速的把 SeaTunnel 相干的能力残缺的迁到 Scaleph 我的项目上来。

问题剖析

Flink-jdbc-connector 性能加强

SeaTunnel 官网文档中的很多案例，都是以 FakeSource 和 ConsoleSink 实现的，而咱们在开发中是以 jdbc-connector 为主的。在集成过程中，咱们发现 flink-jdbc-connector 插件的 JdbcSink 只反对 Stream 模式运行，起初咱们就给它实现了 Batch 模式。

JdbcSource 须要用户提供 sql，程序在外部通过正则表达式获取到 sql 的列、表信息，以生成 JdbcSource 的 RowTypeInfo。然而在定义简单 sql 的时候会呈现别名、子查问之类的状况，正则表达式难以笼罩所有场景。咱们应用 Jdbc 的 Connection 获取到 sql 的 ResultSet，从 ResultSet 间接获取 sql 的列信息，以生成 JdbcSource 的 RowTypeInfo。

Seatunnel-core-flink.jar 瘦身

SeaTunnel 是运行在 Flink 和 Spark 之上，二者会别离打成两个 jar 包，seatunnel-core-flink.jar 就是 Flink 对应的实现。在 2.1.1 版本中，Seatunnel 会把基于 flink 实现的 connector 都打进这个 fat jar 包中。

而真正去应用的时候，数据同步工作，可能只会应用其中的 1-2 种 connector。Seatunnel 工作提交的时候会有一定量的额定网络开销。

咱们想实现这种成果：有一个比拟 thin 的 core jar 包，而后再加上相干的 connector 的 jar 包。提交的时候，以 core-jar 包为主，加上相干的 connector 的 jar 包。同时后面介绍过的资源 jar 包上传，如 SeaTunnel 的 jdbc-connector 短少的 JDBC 驱动包，携带资源 jar 包和 connector jar 包的工作提交都是同一种解决形式。

起初社区在发展 connector 拆分的时候，咱们也踊跃在相干 issue 下分享了相干教训，当 Seatunnel 2.1.2 公布时，咱们的零碎也是很轻松地就适配了 seatunnel-core-flink.jar 和 connector jar 拆散的公布模式。同时用户没有在 Flink 集群提前准备 JDBC 驱动的状况下，也能够通过资源管理的性能，上传驱动包，在提交 SeaTunnel 工作时，带着驱动包一起提交。

Flink jobId 获取问题

Flink 工作提交这一块的最外围形式是以命令行接口的模式去实现的，因而用户须要通过 shell 脚本去提交 Flink 工作。Flink 工作提交后，命令行客户端会把对应的工作 id 输入到控制台日志中，用户就须要捕捉输入到管制台上的日志，从中提取出工作 id。

因为咱们这个我的项目和 Flink 的所有交互全是通过 Flinkful 库实现，Flinkful 能够把这样一个 jobId 间接作为接口调用的返回值给发回来。所以咱们的实现相比捕捉控制台日志提取 jobId 还是比拟优雅的。

SeaTunnel 调用 System.exit() 问题

SeaTunnel 工作在去执行的时候，先会对用户编写的配置文件进行查看，如果查看失败，会间接调用 System.exit()，而后这个时候 JVM 也就退出了。SeaTunnel 自身的提交形式是以 shell 脚实现的，因而 JVM 退出是没有问题的。

然而当 Scaleph 零碎，把它集成到咱们利用外面的时候，在调用这个办法，就会导致咱们 Scaleph 这样的一个利用会间接挂掉，导致咱们服务的一个不可用。因而，咱们也是对工作提交的这一块代码，通过 SecurityManager，减少了相干的一个权限限度，而后规定 SeaTunnel 相干的提交工作程序，禁止调用 System.exit() 办法。

05 SeaTunnel 社区奉献

和我一起开发 Scaleph 一个敌人，这里是咱们俩的一些提交的 pr，比方下面说的 jdbc-connector 的性能加强。还有就是 jdbc-connector 的 upsert 性能的实现。flink-jdbc-connector 的 JdbcSink 的一个很大的缺点是只反对 insert 性能，无奈实现 update，这会相当限度这个 connector 的性能。咱们也是开发了 upsert 语义的反对，反对数据的反复同步。

01 零碎演示

这个我的项目工夫短缺的话是能够进行 Docker 环境和 IDE 环境演示的，这里工夫无限就抉择 Docker 环境给大家进行演示，演示视频（间接跳转 23’18s）：

https://www.bilibili.com/vide…

02 后续开发计划

目前咱们还是会尽快把 SeaTunnel 相干的 connector 和 transform 插件，全搬到咱们的可视化利落拽的页面下来，可能让用户残缺的感触到 SeaTunnel 的一个弱小。另外一个就是随着 SeaTunnel-connector 的相干插件丰盛，也要把 connector 对应的数据源品种给它丰盛下来。

咱们也心愿能为数据开发和数据集成做一些 DAG 相干的编排调度，同时也心愿可能在数据开发方面反对 SQL 的工作开发。

Apache SeaTunnel

//  放弃联系 //

小助手 : Seatunnel1 备注思否

来，和社区一起成长！

Apache SeaTunnel(Incubating) 是一个分布式、高性能、易扩大、用于海量数据（离线 & 实时）同步和转化的数据集成平台。

仓库地址：

https://github.com/apache/inc…

网址：

https://seatunnel.apache.org/

Proposal：

https://cwiki.apache.org/conf…

Apache SeaTunnel(Incubating) 2.1.0 下载地址：

https://seatunnel.apache.org/…

衷心欢送更多人退出！

可能进入 Apache 孵化器，SeaTunnel(原 Waterdrop) 新的途程才刚刚开始，但社区的发展壮大须要更多人的退出。咱们置信，在「Community Over Code」（社区大于代码）、「Open and Cooperation」（凋谢合作）、「Meritocracy」（精英治理）、以及「多样性与共识决策」等 The Apache Way 的指引下，咱们将迎来更加多元化和容纳的社区生态，共建开源精力带来的技术提高！

咱们诚邀各位有志于让外乡开源立足寰球的搭档退出 SeaTunnel 贡献者小家庭，一起共建开源!

提交问题和倡议：

https://github.com/apache/inc…

奉献代码：

https://github.com/apache/inc…

订阅社区开发邮件列表 :

dev-subscribe@seatunnel.apach…

开发邮件列表：

dev@seatunnel.apache.org

退出 Slack:

https://join.slack.com/t/apac…

关注 Twitter:

https://twitter.com/ASFSeaTunnel