点亮??星·点亮开源GitHub：https://github.com/apache/inc...7月24日ApacheSeaTunnel(Incubating)&ApacheDorisJointMeetup，普通社区贡献者狄杰给大家做了SeaTunnel服务之路的演讲，主要是跟大家聊聊SeaTunnel是如何从一个数据集成组件进化到企业级服务的。今天的分享主要分为四个部分：服务化的初衷和价值服务的整体架构社区目前的进展Roadmap为什么要做服务化？自2019年以来，社区对Web服务的呼声一直很高。当时有人在issue中提到了Web服务。直到今年五月份的周会，还有人在讨论，也有人说自己为社区做了贡献，但也有可能因为种种原因没有发帖。在之前的Meetup分享中，也有同学分享了基于SeaTunnel的数据集成服务的可视化。一直从事数据中心相关的工作，觉得面向服务是SeaTunnel必不可少的一部分，而且自己对开源也比较感兴趣，所以结合社区的意愿，决定开始做这个。核心目标是什么？脚本控件允许用户通过WebUI以参数的形式配置任务信息，例如：输入/输出数据源、各种transform配置、env参数等方式来表达您的业务需求。之前公司没有数据平台，分别使用Datax+Azkaban作为数据采集组件和调度执行组件，Git作为代码管理；熟练人员通过编辑、提交、推送、打包、上传、页面操作、数据校验等7个步骤配置数据集成任务；一个任务的开发至少需要30到60分钟，而且必须保证中间没有中断，没有异常。后来我们搭建了自己的数据平台后，配置一个数据交换任务只需要几分钟。作业和实例的管理这是一个基本概念。SeaTunnel任务在开发时一般称为脚本，测试发布后我们称之为作业。作业被触发后，具体的执行称为执行实例。作业控制：手动触发（包括补数据和单次触发）、暂停调度、查看上下游依赖、查看作业内容等实例控制：rerun、KILL、查看日志等。一般来说，这部分能力是由整个大数据生态中的调度系统承担的，比如DolphinScheduler、Azkaban等。那么，我们为什么要在SeaTunnel中做这些事情呢？暂且留个悬念，待整体架构完成后，再跟大家说明我的想法。当我们完成这两项的能力建设后，SeaTunnel就可以算是一个完整的数据集成解决方案了。任何个人或企业都可以在下载和简单配置后快速完成数据采集任务的定义，通过发布任务到调度系统或内置调度引擎，完成任务的周期性调度，业务数据、应用日志、等数据可以快速、准确、定时同步到大数据存储平台或OLAP引擎进行快速数据分析，加速数据价值的产生；因此，这两点是我们的核心目标。以上这些都可以算是对用户的价值。那么面向服务能给SeaTunnel本身带来什么呢？在没有SeaTunnel或者waterdrop（ST的前身）的时候，waterdrop的开发同学一开始使用Spark进行数据集成，发现可以通过代码沉淀常用的操作来封装一些操作，久而久之就形成了早期的水滴，这是从基础的数据开发组件Spark组件，演变为数据集成工具的过程。后来，SeaTunnel开始搭建自己的运维管控平台，整合SeaTunnel的脚本、开发工具、开发流程进行统一管理，形成了一体化运维开发管控的系统化平台。平台化带来管控、开发、运维能力，可以更好的吸引用户使用SeaTunnel，也可以吸引部分同学加入SeaTunnel社区，这对我们社区的发展无疑是一个很大的利好。服务整体的总体结构目前分为三大块控制：数据源、用户、权限、脚本、作业、实例的控制，在WebUi上看到的任何内容都会被控制；scheduling：根据配置，负责将任务丢到不同的调度系统中进行调度执行；对上层作业和实例的管控也依赖于具体的调度系统；这是一个task-wrapper，下面会详细解释它的作用；管控管理能力简述针对数据源的增删改查和连通性测试，未来将支持数据源映射、数据探索等能力。除了增删改查，无非是注册、登录、注销等；但是如果SeaTunnel要做一个顶层的、自包含的、多租户环境下的多租户数据集成服务，那么用户管理就会更加复杂。可见的页面、菜单、按钮、数据等都应该纳入管理和控制。另外，肯定还有更多的东西可以包含在管理模块中，比如资源管理，自定义连接器，transform管理，项目空间等等，但是这些不在我们的主进程范围内，确实有没有用户要求，所以我们稍后再看。开发能力基本上是指增删改查脚本。最突出和重要的是脚本编辑能力：保存、执行、停止、测试、发布、基本参数展示、调度参数配置、告警参数调整、脚本内容、数据源、转换、并发等；这里其实要讲的东西很多，比如测试，通常就是更换输出源，通过控制台输出，手动判断脚本配置是否正确，如果想做的更智能，要简化它，它可以做成一个单元测试。每个脚本都必须通过单元测试才能发布上线，而单元测试就像我们平时用JAVA写的单元测试，Mock数据和验证的过程。说到出版，这是从剧本到工作的重要一步。只有发布成功的脚本才会真正同步到调度系统，我们在发布的过程中可以做很多事情，比如脚本必须经过测试才能发布。成功，提交发布申请后，会形成OA审批流程或工作流，审批通过后才能真正发布等；当然，因为SeaTunnel本身定位是一个弱T数据集成组件，我们不会有太多的ETL逻辑，我们只会有一种任务，SeaTunnel，这样我们就无法做文件夹管理之类的事情了和目录树。我觉得那种能力更适合单独的组件，比如开源的WEBIDE来做这些事情。运维能力作业运维和实例运维前面说过，作业运维一般是：手动触发（包括补充数据和单次触发）、暂停调度、查看作业内容等，而实例运维一般是：rerun、KILL、查看日志、等等，但是值得注意的是，我们的作业分为实时和离线，所以在作业和实例的运维上有不同的表现形式：实时任务没有调度周期，没有任务依赖，所以实时任务的运维会有不同的表现形式。SchedulingBrief调度是一个很关键的部分，分为两部分：调度agent想必大家都很困惑，为什么在SeaTunnel中做一些调度相关的东西，比如上面提到的job运维和实例运维，为什么不经过脚本推送到调度系统，是否可以直接实现调度系统中的管控运维能力？首先，我们希望SeaTunne是自成一体的，而不是依赖于其他组件来完成一些能力。其次，调度系统众多，各个API和能力的表现不一致。我们必须为每个调度系统实现集成。如果没有抽象的API层，整个代码会显得非常混乱，难以管理。最后，如果我们只练一个调度系统，难度自然会低很多，但难免会流失使用其他调度系统的用户；当然，他们也可以像过去一样通过Shell脚本进行任务调度，这样服务的意义就会丢失很多。crontabl-local有什么意义？对于小微用户，他们可能没有大数据平台或数据仓库方面的专业人员。过去，他们使用MYSQL或PYTHON脚本进行数据分析。随着数据量的增加，他们使用MYSQL和PYTHON来运行分析任务。它已经很慢并且很耗资源，所以他们可能会选择使用一些OLAP引擎；当他们要分析业务数据库中的数据时，自然需要使用SeaTunnel将数据同步到OLAP引擎；小微用户没有数据类型的专业人员，所以一定没有大数据平台，更谈不上调度系统。这个时候crontabl-local就体现了它存在的意义：我们的SeaTunnel是一个自包含的系统，我们提供了一个简单的定时调度能力。用户只需修改配置即可快速上手，完成时序数据集成。任务配置和发布。执行task-wrapper我们通过IDE打开它，我们会看到如图所示的目录结构：它提供了pre-task和post-task的能力。之所以设计这样的能力，是因为仅仅依靠SeaTunnel的原生Capability是不够的。例如schema-evolution、分库分表下的同步预处理、动态分区、数据质量等。当然用户自己也可以通过调度依赖来实现相应的能力，但是很多时候POST-TASK需要结合SEATUNNEL的执行脚本来保证事务的一致性，拆分成两个任务就无法保证。我们提供pre-task和post-task能力，可以和SeaTunnel的执行引擎进行组装，成为真正的执行内容；同时，我们也支持用户自己实现这两种任务类型来实现自己的业务流程。除了pre-task和post-task，还有一个关键就是真正的执行脚本，需要把我们的wizard模式和canvas模式翻译成真正的执行脚本，然后和pre-task和post-task一起打包传过去ontogether对于一个真正的调度系统；当前社区发展进度追踪可以通过Github上的issuenumber1947追踪进度。您可以在下图中看到发布的3个链接。第一个是整体设计和整体进度跟踪。第二个是脚本管理&用户管理相关的PR，已经合并。三是关于调度代理层的设计和DolphinScheduler的集成。相关内容已经开发完成，预计一个月内可以将PR发给MERGE。脚本编辑模式目前只支持脚本模式，我们可以在该页面编辑脚本开发，右侧的预览方便用户更好的定位自己的代码；但是目前缺少基本信息、参数配置、调度配置的入口。我们已经和社区产品的同学沟通过了，后面会在这里补充。保存脚本后，会来到上图，这也是创建脚本的入口，start/edit就是开始编辑；这里update改成publishlater，即发布；一个脚本只有在发布后才能进行启动、停止等操作；再看状态，这里的状态其实就是任务上次执行的状态，如果没有执行记录就是unstart，其他的比较容易理解，这里不再赘述。点击任意任务名称后，将进入该页面；在这里可以看到任务执行的索引信息，输入输出数据的个数，数据大小，耗时等；还有这个运行日志等；hereyoucansee更多历史执行记录的原型图请参考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版本】用户权限的控制，这里的顺序和工作内容是我的临时Shot，如果有更多的人加入，我觉得版本的内容可以更丰富，可以迭代的更快；而大家关心的精灵模式要到明年才能设计开发；因为这个对前端很重要&后端有很多依赖；整个2.0版本我们主要做了以下几件事：向导模式从零到完成，完成任务运维的全覆盖：即提升运维这个模块的能力；以及可能更多接入调度系统，比如Airflow、Azkaban等；通过pre-task和post-task能力来实现业务能力，并且随着我们SeaTunnel自身引擎的发展，相信会有利于我们的开发和运维带来更多的能力和便利；例如，脚本可以配置脏数据收集、流量控制等参数；在运维端，我们可以看到SeaTunnel有更专业更清晰的数据集成指标，当时可以直接将指标的展示集成在我们的SeaTunnelwebui上；我们预计需要花费6-10个月的时间来完成这些事情，需要在引擎端与社区贡献者进行合作。至于3.0版本，那是很久以前的事了，应该会有canvas模式、资源管理、流批一体化能力的全覆盖。最后，欢迎大家做出相关贡献，加入我们的ApacheSeaTunnel大家庭！感谢ApacheSeaTunnel//保持联系//微信号：Seatunnel快来和社区一起成长吧！ApacheSeaTunnel(Incubating)是一个分布式、高性能、可扩展的数据集成平台，用于海量数据（离线和实时）同步和转换。仓库地址：https://github.com/apache/inc...URL：https://seatunnel.apache.org/提案：https://cwiki.apache.org/conf...ApacheSeaTunnel(Incubating)2.1.0下载地址：https://seatunnel.apache.org/...真诚欢迎更多人加入！能够进入Apache孵化器，SeaTunnel（原Waterdrop）的新征程才刚刚开始，但社区的发展壮大需要更多人的加入。我们认为，在“CommunityOverCode”（社区大于代码）、“OpenandCooperation”（开放协作）、“Meritocracy”（精英管理）、“多元化和共识决策”等TheApacheWay的指导下——making”，我们将迎来更加多元包容的社区生态，共同打造开源精神带来的技术进步！我们诚邀所有有志于让本地开源全球化的伙伴加入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
