关于微服务:SeaTunnel从一个数据集成组件演化成企业级的服务

点亮 ⭐️ Star · 照亮开源之路

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

在 7 月 24 日 Apache SeaTunnel(Incubating)&Apache Doris 联结 Meetup 上，一个一般的社区贡献者狄杰，给大家带来的演讲主题是 SeaTunnel 的服务化之路，次要是和大家聊一下，SeaTunnel 如何从一个数据集成组件演化成企业级的服务。

明天的分享次要分为四个局部：

• 服务化的初衷与价值
• 服务的整体架构
• 社区的以后停顿
• Roadmap

为什么要做服务化？

从 2019 年开始，社区对于 Web 服务的呼声很高，过后就有人在 issue 外面提及 Web 服务的事件，始终到往年的 5 月份周会都还有人在探讨，也有人说在社区奉献，但可能因为种种原因没有了下文。

在之前的 Meetup 分享，也有同学分享基于 SeaTunnel 实现了可视化的数据集成服务。我始终从事数据中台的相干工作，感觉服务化对 SeaTunnel 来说是必不可少的局部，而且对开源也比拟感兴趣，所以就联合了社区的志愿，决定着手做这件事。

外围指标是什么？

​

脚本的管控

让用户通过 WebUI，以参数的模式配置工作信息，比方：输出 / 输入数据源、各种 transform 的配置、env 参数等等；总而言之，就是尽可能的让用户通过配置而非脚本的形式来表白本人的业务需要。

之前的公司没有数据平台，应用的是 Datax+Azkaban 别离作为 数据采集的组件和调度执行的组件 ，应用 Git 作为代码治理；一个生手配置一个数据集成工作大概通过 7 步： 编辑，Commit，Push，打包，上传，页面操作，数据校验；一个工作的开发最起码须要 30~60 分钟，还必须保障这两头不能被打搅，没有出现异常状况。起初咱们做了本人的数据平台之后，配置一个数据交换工作只须要分钟级别。

作业及实例的治理

这里讲一个基本概念，一个 SeaTunnel 的工作，在开发时，个别称说它为脚本，通过测试并公布后，咱们才会称其为作业。而作业通过触发后，具体的执行则被称为执行实例。

作业的管控：手动触发(蕴含补数据和单次触发)、暂停调度、查看上下游依赖、查看作业内容等等。

实例的管控：重跑、KILL、查看日志等等。

通常来说，这部分能力是由整个大数据生态体系中的调度零碎来承当，比如说 DolphinScheduler、Azkaban 等。那么，为什么咱们要在 SeaTunnel 里做这些事件？先临时留个悬念，等到整体架构时会跟大家解说我的想法。

​

当咱们实现了这两项的能力建设后，SeaTunnel 能够算上是个残缺的数据集成解决方案 ，任意一个人、或者企业，当实现下载和简略配置后，即可疾速的实现数据采集工作的定义，通过将工作公布到调度零碎或者内置的调度引擎中，即可实现工作的周期性调度， 疾速、精确、定时将业务数据、利用日志等数据同步到大数据存储平台或者 OLAP 引擎中，疾速进行数据分析，减速数据价值的产生；所以说，这两点是咱们最外围的指标

上述能够看成给用户的价值

那么服务化能给 SeaTunnel 本身带来什么呢？

在没有 SeaTunnel 或者说没有 waterdrop 的时候（ST 的曾用名），waterdrop 的开发同学一开始应用Spark 进行数据集成，发现能够通过对罕用的操作用代码积淀，对一些操作进行封装，长此以往就造成了晚期的 waterdrop，这便是从根底的数据开发组件 Spark 组件演化成数据集成工具的过程。

起初，SeaTunnel 开始做本人的运维管控平台，将 SeaTunnel 的脚本、开发工具、开发流程整合在一起，对立治理，造成体系化的运维开发管控一体化的平台。 而平台化带来了 管控、开发、运维 等能力，可能更好的吸引用户来应用 SeaTunnel，同样也会吸引一些同学退出 SeaTunnel 的社区，这对咱们社区的倒退无疑是极大的利好。

服务的整体架构

​

整体上来说，目前临时分为三个大部分

1. 管控：对数据源、用户、权限、脚本、作业、实例的管控，任何在 WebUi 上看到的内容都会被管控；
2. 调度：依据配置的不同，负责将工作丢至不同的调度零碎中进行调度与执行；下层的作业和实例的管控也依赖于具体的调度零碎；
3. 执行：工作具体执行时的一些事项，大家可能看到我在这做了 task-wrapper，作用上面跟大家具体讲；

管控简述

治理能力

​

针对于数据源的增删改查以及连接性测试，后续会反对 数据源的映射、数据探查 等的能力。

除增删改查之外，无非是 注册、登录、退出 等；然而如果要将 SeaTunnel 做到 顶级的、自成体系、多租户环境下 的数据集成服务，那么用户的治理会更加简单

页面上每个能看见的页面、菜单、按钮、数据等，都应该纳入管控，除此之外，必定还有更多货色能够纳入治理模块，比方 资源管理、自定义 connector、trasnform 治理、我的项目空间等等，不过这些都不在咱们的主流程范畴内，并且也的确没有用户提出这方面的需要，所以咱们之后再看。

开发能力

基本上就是针对的脚本的增删改查，最突出最次要的也就是脚本的编辑时的能力：保留、执行、进行、测试、公布、基本参数展现、调度参数配置、告警参数调整、脚本内容、数据源、transform、并发等；这外面其实有很多内容要讲，比方测试，通常来说是替换输入源，通过控制台输入，人工来判断脚本配置是否正确，而如果要做的更智能化一点，齐全能够做成单元测试一样，每个脚本必须通过单元测试之后才可能公布上线，而单元测试就像平时咱们写 JAVA 的单元测试一样，Mock 数据，验证过程。

再说到公布，这是从脚本演变成作业必不可少的一步，只有公布胜利的脚本才会真正的同步到调度零碎中，而公布中咱们能够做很多事件，比方必须通过测试的脚本才可能公布胜利，而在提交了公布申请后，会造成 OA 审批流或者工作流，只有通过审批后能力真正的公布等等；

当然，因为 SeaTunnel 自身的定位是一个弱 T 的数据集成组件，咱们不会有太多的 ETL 逻辑，而且咱们只会有 SeaTunnel 一种类型的工作，所以咱们不会做相似于文件夹治理、目录树那样的能力，那种能力我感觉还是更适宜有独自的组件，比方开源的 WEB IDE 来做这些事件。

运维能力

作业运维与实例运维 就像我之前说的那样，作业的运维个别是：手动触发 (蕴含补数据和单次触发)、暂停调度、查看作业内容等， 而实例的运维个别是：重跑、KILL、查看日志等，不过值得注意的是，咱们的作业有实时和离线之分，所以在作业和实例的运维上有不同的体现：实时工作不存在调度周期、不存在工作依赖，所以实时工作的运维会有不同的体现。

调度简述

​

调度是很要害的一环，分成两个局部：

调度代理

大家必定很纳闷，为什么要在 SeaTunnel 外面做一些调度相干的事件，比方下面说的作业运维与实例运维，为什么没有在脚本推送到调度零碎后，间接在调度零碎实现管控、运维的能力？

首先，咱们想 SeaTunne 自成体系，而不是依赖于别的组件能力实现一些能力。其次，调度零碎有很多且每个 API 和能力的体现是不统一的，咱们必须为每一种调度零碎实现一次集成，如果没有形象的 API 层，那么整个代码会显得十分凌乱并且难以治理。

最初，如果咱们只针对一种调度零碎做实际，那么难度天然会低很多，然而咱们就必然会失去应用其它调度的用户；当然，他们也能够像过来一样，通过 Shell 脚本的形式来进行任务调度，那样服务化的意义也就失去了很多。

crontabl-local 存在的意义是什么？

对小微型用户来说，他们可能都没有大数据平台或者数仓方面的专业人士，他们过来是 通过 MYSQL 或者 PYTHON 脚本进行数据分析 ，而随着数据量的增多，用 MYSQL 和 PYTHON 跑剖析型工作曾经又慢又费资源，所以可能抉择了 应用一些 OLAP 引擎；而他们想对业务库的数据进行剖析的时候，自然而然的须要用 SeaTunnel 去将数据同步到 OLAP 引擎中；

小微型用户没有数据类的专业人士，所以大数据平台必然是没有的，更别提调度零碎了。而这时 crontabl-local 就体现了他存在的意义：咱们的 SeaTunnel 自成体系，咱们本身就提供了简略的定时调度能力，用户只须要简略的 批改一下配置，即可疾速上手，实现定时数据集成工作的配置与公布。

执行态 task-wrapper

​

咱们通过 IDE 关上，会看到如图所示的目录构造：

它提供了 pre-task 和 post-task 的能力，之所以设计这么个能力，是思考到仅靠 SeaTunnel 原生的能力是不够的。

比方 schema-evolution、分库分表下的同步预处理、动静分区、数据品质等。当然，用户本人也能够通过调度的依赖来实现相应的能力，不过很多时候 POST-TASK 须要和 SEATUNNEL 的执行脚本合并在一起，保障事务的一致性， 如果拆成两个工作就无奈保障。 咱们提供了 pre-task 和 post-task 的能力，与 SeaTunnel 的执行引擎进行组装，变成真正的执行内容；同时咱们也反对用户本人实现这两种 task 类型，来实现他们的业务流程。

除了 pre-task 和 post-task，另外一块比拟要害的是真正的执行脚本，它须要将咱们 向导模式和画布模式翻译成真正的执行脚本，再与 pre-task 和 post-task 进行打包，一起传递给真正的调度零碎；

社区以后的进度

开发进度追踪

​

大家能够通过 Github 上的 1947issue 号 进行进度追踪，大家能够看到在下图贴的 3 个链接，第一个是总体的设计以及整体的进度追踪。第二个是有对于脚本治理 & 用户治理相干的 PR，曾经 MERGE。第三个是有对于调度代理层的设计以及 DolphinScheduler 的集成，相干内容曾经开发结束，预计月内可能把 PR 给 MERGE.

脚本编辑模式

​

目前只反对脚本模式，咱们能够在这个页面进行脚本的编辑开发，右侧这个预览不便于用户更好的定位本人的代码；不过目前这里短少了根本信息、参数配置、调度配置的入口，曾经和社区产品的同学在沟通，后续这边也会加上去.

​

在保留完脚本后，会来到上图，这里也是创立脚本的入口，start/edit 是启动和编辑；这里的 update 后续会改为 publish，也就是公布；一个脚本被公布了之后能力进行启动、进行等操作；再看看状态，这里的状态其实是取的这个工作最近一次执行的状态，如果没有执行记录就是 unstart，其它的比拟好了解，就不再赘述了。

​

点击任何一个工作名称后，会进到这个页面；这里能看到 工作执行的指标信息、输入输出数据条数、数据大小、消耗工夫等；另外还有本次的运行日志等；这里可能看到历史的执行记录

更多的产品原型图能够参考 issue-2100 的内容，咱们产品的同学外面有更多的图片展现

什么时候能用上 SeaTunnel-Server？

罗马不是一天能够建成的，咱们会做出一个稳固可用的最小 MVP 版本，MVP 版本都蕴含哪些内容？

​

1、用户治理：蕴含对用户的增删改查以及登录、退出能力；

2、脚本开发 ：蕴含对脚本的增删改查，其中脚本开发只反对脚本模式，我之前在 issue 外面也有说过，别离有三种模式： 向导模式 也就是配置化的形式——先选输出源，再输入输出源，再配置字段映射等等；脚本模式 就是间接将 SeaTunnel 的脚本贴进来；画布模式 就是俗称的利落拽；

3、工作运维：针对于公布后的脚本进行执行、进行、查看记录、查看日志相干操作；

ROADMAP

咱们当初最要害的是实现 MVP 版本的设计与开发，包含用户、脚本、工作运维，相当于是 1.0 版本之后咱们大略是 2 个月实现一次迭代，预计到年底可能实现 2 个小版本的迭代。

【1.1 版本】将数据源治理纳入，让用户更加专一于业务代码开发；

【1.2 版本】实时工作的开发、管控、运维，为什么要先将实时和离线离开来做呢？次要是因为实时工作通常时 7 *24 的模式，它的运行状态和在调度零碎上体现的实例状态其实是不统一的；

【1.3 版本】用户权限的管控，这里的程序和工作内容都是我临时拍的，如果有更多的人退出进来，我想版本的内容能够更丰盛，能够更快的迭代；

​

而大家关怀的向导模式，会在明年的时候才进行设计 & 开发；因为这个对前端 & 后端都有比拟多的依赖；整个 2.0 版本咱们次要做好这几件事：

1. 向导模式的从零到有到欠缺
2. 工作运维的全笼罩：也就是欠缺对运维这个模块的能力；并且可能会有更多的调度零碎接入，比方 Airflow、Azkaban 等等；
3. 通过 pre-task 和 post-task 的能力来实现业务能力

​

并且，随着咱们 SeaTunnel 本身引擎的倒退，我置信会对咱们的开发、运维带来更多的能力和便利性；

比方 脚本能够配置脏数据收集、流控等参数；运维侧咱们能够看到SeaTunnel 更加业余、更加明确的数据集成指标，到时候能够间接将指标的展现集成在咱们的 SeaTunnel webui 上；

咱们预计用 6~10 个月的事件来做欠缺这些事件，并且须要与引擎侧的社区贡献者们配合.

至于 3.0 版本就是很长远的事件了，应该是会有 画布模式、资源管理、流批一体能力的全方面笼罩，最初，也欢送大家来做相干奉献，退出咱们 Apache SeaTunnel 小家庭！谢谢大家

Apache SeaTunnel

// 放弃联系 //

微信号 : Seatunnel

来，和社区一起成长！

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/ASFSeaTunne