共计 9355 个字符，预计需要花费 24 分钟才能阅读完成。
点亮 ⭐️ Star · 照亮开源之路
https://github.com/apache/inc…
讲师简介
毕博 马蜂窝 数据工程师
在 10 月 15 日，Apache SeaTunnel& IoTDB 联结 Meetup 期间，马蜂窝网数据工程师毕博给大家介绍了 SeaTunnel 的基本原理和相干企业实际思考、马蜂窝大数据开发调度平台典型场景下的痛点和优化思考，并分享了集体 参加社区奉献 的实践经验，心愿同时能帮忙大家疾速理解 SeaTunnel 及参加社区建设的门路和技巧。
✦SeaTunnel 的技术原理简介✦
SeaTunnel 是一个分布式、高性能的数据集成平台，用于海量数据（离线和实时）的同步和转换
下面这张图展现的是 SeaTunnel 的工作流程，简略来说蕴含 3 个局部：输出、转换、输入；更简单的数据处理，也无非是几种行为的组合。
以一个同步场景为例，比方将 Kafka 导入到 Elasticsearch，Kafka 就是 流程中的 Source，而 Elasticsearch 就是流程中的 Sink。
如果在导入的过程中，字段列跟待写入的内部数据列不匹配须要做一些列或者类型的转换，或者须要多数据源的 Join，而后做一些 数据打宽，扩大字段等解决，那么在这个过程中就须要减少一些 Transform，对应图片两头的局部。
由此可见 SeaTunnel 外围的局部 就是 Source、Transform 和 Sink 流程定义。
在 Source 外面咱们能够定义须要的读取数据源，在 Sink 定义数据 Pipeline 最终写出的内部存储，能够通过 Transform 进行两头数据的转换, 能够应用 SQL 或者自定义的函数等形式。
1.1 SeaTunnel 连接器 API V1 版本 架构分析
对于一个成熟组件框架来说，从设计模式到 API 的设计实现上，肯定有比拟独特的中央，从而使得框架有比拟好的扩展性。
SeaTunnel 的架构次要包含三局部：
1、SeaTunnel 根底 API；
2、SeaTunnel 根底 API 的实现；
3、SeaTunnel 的插件体系；
1.2 SeaTunnel 根底 API
Plugin 接口定义
上图为接口定义，Plugin 接口在 SeaTunnel 将数据处理的各种行为都形象为 Plugin。
下图的 5 个局部 Basesource、Basetransfform、Basesink、Runtimeenv 和 Execution 都继承了 Plugin 接口。
basesource、basetransfform、basesink 接口定义
作为流程定义插件，Source 负责读数据，Transform 负责转换，Sink 负责写入，Runtimeenv 是设置根底的环境变量。
SeaTunnel 根底 API 整体局部如下图
基于前三者用来构建整个数据流程的数据流构建器 Execution 也是根底 API 的一部分
Execution 接口定义
1.3 SeaTunnel 根底 API 实现
基于后面根底 API，SeaTunnel 别离针对不同计算引擎做了封装实现，目前有 Spark API 形象和 Flink API 形象，这一部分在逻辑上实现了数据 Pipeline 的构建流程。
因为篇幅无限，这里次要以 Spark 批处理 重点介绍。基于对后面根底 Api 的封装实现，首先是 Base spark source 实现了 Base source，base Spark transform 实现了 Base transform，Base Spark sink 实现了 Base sink。
办法定义中以 Spark 的 Dataset 作为数据的载体, 所有的数据处理都是基于 Dataset，包含读取、解决和导出。
其中对于 SparkEnvironment , 外部是将 Spark 的 Sparksession 封装在 Env 外面，不便各个插件应用。
上图是 SeaTunnel 根底 Api 实现
Spark 批处理 最初是 SparkBatchExecution(数据流构建器), 图中截取了外围的代码片段, 从性能上用来构建咱们的数据流 Pipline，也就是下图中右边最根底的数据流。
基于用户的对每一个流程组件的定义也就是 Source Sink、Transform 的配置。能够实现比较复杂的数据流的逻辑，例如 多数据源 Join、多 Pipline 解决等，都能够通过 Execution 来构建。
1.4 SeaTunnel 连接器 V1 API 架构总结
SeaTunnel 的 API 次要包含三个局部：
第一局部 是 SeaTunnel 根底 API，提供了 Source、Sink、Transform、Plugin 等根底形象接口。
第二局部 是基于 SeaTunnel 根底 API 提供的一组接口Transform、Sink、Source、Runtime、Execution，在 Flink 和 Spark 引擎的上别离做了相干封装和实现，也就是 Spark 引擎 API 层形象和 Flink 引擎 API 层形象。
Flink 和 Spark 引擎都是反对流解决和批处理，因而 Flink API 形象和 Spark 形象 API 下还别离对应流 / 批的不同应用形式，如 Flink 形象 API 上游 Flinkstream 和 Flinkbatch，Spark 形象 API 下有 Sparkbatch 和 Sparkstreaming。
第三局部 是插件体系, 基于 Spark 形象和 Flink API 形象，SeaTunnel 引擎实现了丰盛的连接器和解决的插件，同时对于开发者也能够基于不同引擎 API 形象、扩大实现本人的 Plugin。
1.5 SeaTunnel 执行原理
目前 SeaTunnel 提供 Flink、Spark、FlinkSQL 多种应用形式，因为篇幅无限，介绍对于应用 Spark 形式的执行原理。
首先入口 通过 Shell 启动命令 Start-seatunnel-spark.sh， 外部会调用 Sparkstarter 的 Class，Sparkstarter 去对 Shell 脚本传递 参数进行解析，同时还会解析 Config 文件，从而判断 Config 文件定义了哪些 Connector，比方 Fake、Console 等。
而后从 Connector plugin 目录 去找对应的 Connector 门路，通过 –jar 拼接到 Spark-submit 启动命令外面，这样能够把找到的 Plugin jar 包作为依赖传递到 Spark cluster。
对于 Connector plugin 来说，Spark 的 Connector 所有的 Connector 都会对立打包到发行包的 plugin 目录外面（这个目录做对立治理）。
执行 Spark-submit 后，工作提交到 Spark cluster，Spark 作业的 Driver 的 Main class 通过数据流构建器 Execution 并联合 Souce、Sink、Transform，来构建数据流 Pipline，至此整个链路串联起来了。
1.6 SeaTunnel 连接器 V2 API 架构
在社区最新公布的 SeaTunnel 2.2.0-beta 版本中，曾经实现对 Connectorapi 重构，也就是当初的 SeaTurnelV2 API！
咱们为什么要重构？
因为目前的 Container 是强耦合引擎的，也就是 Flink 和 Spark API，如果对 Flink 或者是 Spark 引擎降级的话，Connector 也要进行调整，可能是参数或接口的改变。
这会导致开发一个新的 Connector 须要针对不同引擎屡次实现，并且参数是不对立的。所以基于这些痛点，社区进行了 V2 版本 API 的设计和实现。
SeaTunnel V2 API 架构
Apache SeaTunnel(Incubating) API 总体构造的设计如上图，分为 4 个局部；
1、Table API
- DataType：定义 SeaTunnel 的数据结构 SeaTunnelRow，用于隔离引擎
- Catalog：用于获取 Table Scheme、Options 等；
- Catalog Storage: 用于存储用户定义 Kafka 等非结构化引擎的 Table Scheme 等；
- Table SPI：次要用于以 SPI 的形式裸露 Source 与 Sink 接口
2、Source & Sink API
定义 Connector 的外围编程接口，用于实现 Connector
3、Engine API
- Translation: 翻译层，将 Connector 实现的 Source 和 Sink API 翻译成引擎外部可运行的 API；
- Execution: 执行逻辑，用于定义 Source、Transform、Sink 等操作在引擎外部的执行逻辑；
其中 Source & Sink API 是实现连接器的根底，对于开发者来说是十分重要的。
上面着重介绍 v2 版本 Source & Sink API 的设计
1.7 SeaTunnel 连接器 V2 Source API
SeaTunnel 以后版本的 API 设计借鉴了一些 Flink 的设计理念，Source API 比拟外围的类如下图：
Source API 外围交互流程如上图，在并发读取的状况下，须要枚举器 SourceSplitEnumerator 实现工作的拆分，将 SourceSplit 下发给 SourceReader，Reader 接管这个 Split 并用于读取内部数据源。
同时为了反对断点续传和 Eos 语义，须要进行状态的保留和状态的复原，例如在每一个 Reader 里通过 Checkpoint state 和 Checkpoint 机制保留以后 Reader 的 Split 生产状态和失败后通过状态进行复原，保障能从能从失败的中央持续读取数据。
1.8 SeaTunnel 连接器 V2 Sink API
整体 Sink API 交互流程如下图，目前 SeaTunnel sink 设计 反对分布式事务，基于两阶段事务提交。
首先 SinkWriter 继续去像内部数据源写数据，而后在引擎做 Checkpoint 的时候，会触发第一阶段提交。
SinkWriter 须要做 Prepare commit，这是第一阶段提交。
同时会返回 Commit info 给引擎，引擎会去判断是否所有的 Wirter 的第一阶段都能胜利，如果都胜利, 引擎会联合 Subtask 的 Commit info 并通过 Commiter 的 Commit 办法，去做理论的事务提交，去操作数据库进行 Commit 也就是第二阶段的提交。
Sink API 交互流程
对于 Kafk sink connector 实现来说, 第一阶段通过调用 KafkaProducerSender.prepareCommit()去做预提交。
第二段提交通过 Producer.commitTransaction(); 进行事务提交。再通过 Producer.flush(); 将 Broker 端系统缓存的数据数据，强制刷新到磁盘.
最初值得注意的是!
SinkCommitter和 SinkAggregatedCommitter都能够进行第二阶段提交替换图中 Commiter 的地位，区别在于 SinkCommitter 只能做单个 Subtask 的 CommitInfo 的局部事务提交，有可能局部胜利局部失败，不能全局解决。
SinkAggregatedCommitter 是单并行，汇总所有 Subtask 的 CommitInfo，能够整体做第二阶段提交，要么都胜利要么都失败，能够防止阶段二局部失败导致状态不统一的问题。
所以倡议优先应用 SinkAggregatedCommitter。
1.9 SeaTunnel V1 与 V2 API 解决流程比照
咱们能够从数据处理角度看 V1 V2 降级前后的变动，这样更为直观，Spark 批处理为例：SeaTunnel V1: 整个数据处理过程都是基于 Spark dataset API 的，并且 Connector 和计算引擎强耦合。
SeaTunnel V2: 得益于引擎翻译的工作，在数据转换时，通过翻译层将 Connector API 和通过连接器接入的 SeaTunnel 外部数据结构的数据源 SeaTunnelRow，翻译成引擎外部可辨认可运行的 Spark api 和 spark dataset。
在数据写出时，通过翻译层将 Spark API 和 Spark dataset 翻译为 SeaTunnel 连接器外部可执行的连接器 API 和能够应用的 SeaTunnel 内部结构的数据源。
✦ ✦✦ ✦✦ ✦✦ ✦
总体来说，在 API 层和计算引擎层减少了翻译层，实现了 Connector API 和引擎的解耦，Connector 实现不再依赖于计算引擎，使扩大和实现更加灵便。
从社区规划来看，前面倒退会以 V2 API 为主，更多的性能个性会在 V2 上反对，V1 趋于稳定不再保护，因而倡议开发者和使用者将重心放在新版 API 上。
✦离线开发调度平台实际思考✦
2.1 离线开发调度平台简介
马蜂窝大数据开发平台，次要是提供一站式大数据开发与调度服务，帮忙业务解决离线场景下数据开发治理、任务调度、工作监控等简单问题。
从定位看离线开发调度平台次要起到承前启后的作用，呈上就是提供凋谢接口 API 和 UI 对接各个数据利用平台以及业务，启下就是驱动各个计算、存储，而后依照工作的依赖关系和调度工夫井井有条的运行。
平台能力
- 数据开发 工作配置、品质测试、公布上线
- 数据同步 数据接入、数据加工、数据散发
- 调度能力 反对定时调度、触发式调度
- 运维核心 作业诊断、工作运维、实例运维
- 治理 库表治理、权限治理、API 治理、脚本治理
概括来说，离线开发调度平台外围能力体现为凋谢能力、通用性、一站式。通过标准化流程，对整个工作开发周期进行治理、提供一站式的服务体验。
2.2 离线开发调度平台架构
马蜂窝大数据开发调度平台次要由工作组件层、调度层、服务层和监控层 4 个模块组成。
服务层 次要负责作业的生命周期治理(如作业的创立、测试、公布、下线)；airflow dagphthon 文件构建生成，工作血统依赖治理，权限治理、api(提供数据就绪、工作执行状态的查问)；
调度层 是基于 Airflow 的，负责所有离线工作的编排调度；
工作组件层，使用户能够通过已反对的组件进行数据开发，这些组件包含 SparkSQL/、HiveSQ、LMR)、StarRocks 导入等工具，间接对接底层 HDFS、MySQL 等存储系统；
监控层 负责对调度资源、计算资源、工作执行等进行全方位监控和预警。
2.3 凋谢数据同步能力场景
凋谢能力下的挑战: 须要反对多业务场景，满足灵便数据 Pipline 需要（即扩大反对更多的工作组件，如 hive2clickhourse、clickhourse2mysql 等）
基于 Airflow 扩大工作组件: 扩大保护老本比拟高，须要降本增效（基于 Airflow 提供的 providers 无限，从应用需要上不太实用，Airflow 是 Python 技术栈，而咱们团队次要以 Java 技术栈为主，所以技术栈差别带来的是较高的迭代老本）
自研工作组件： 平台交融老本高、开发周期长、工作组件应用配置老本高。（调研或本人实现工作组件，在服务层针对组件的参数进行不同形式的适配，没有的对立的参数配置化形式）
咱们心愿调研一款数据集成工具，首先反对的组件要丰盛，提供开箱即用的能力，易扩大、提供对立的参数配置化和对立应用形式不便平台集成和保护。
2.3.1 数据集成工具的选型
为了解决下面提到的痛点，咱们积极探索寻求解决方案，对多个业界支流数据集成产品进行选型剖析。从上图的比照能够看出，Datax 和 SeaTunnel 提供了都具备扩展性好、高稳定性的特点，反对丰盛的连接器插件，提供了脚本化、对立配置化的应用形式，并且社区沉闷也很高。
然而 Datax 受限于受限于分布式，在海量数据场景下不太适宜。相较而言，SeaTunnel 能够提供分布式执行、分布式事务的能力，可能解决的数据量级可扩大，还具备在数据同步场景下的对立技术解决方案的能力。
除了下面介绍的劣势特点及实用场景，更重要的是目前大数据的离线计算资源对立由 yarn 来治理，对于后续扩大的工作也心愿在 Yarn 上执行，最终针对咱们的应用场景，咱们偏向于 SeaTunnel。
前期咱们可能会对 SeaTunnel 进行进一步的性能测试和数据凋谢调度平台集成 SeaTunnel 的开发工作，逐步推广应用。
2.4 出仓场景：Hive 数据同步到 StarRocks
简略介绍一下背景, 目前大数据平台实现 OLAP 引擎层的对立，应用 StarRocks 引擎替换了之前的 Kylin 引擎，作为 OLAP 场景下的次要查问引擎。
在数据加工过程中，数据通过数仓建模后，须要将下层模型导入到 OLAP 引擎中，进行查问减速，因而每天会有大量的工作将数据从 Hive 推送到 StarRocks 外面，目前咱们形式是通过前置工作将 ETL 后的数据 Load 到 Hive 长期表，再通过 Hive2StarRocks 工作(基于 StarRocks Broker Load 导入形式的封装）批量导入到 基于 StarRocks 表中。
以后痛点有两个：
- 数据同步链路长: Hive2StarRocks 加工链路，至多须要两个工作，相对来说比拟冗余。
- 出仓提效: 从出仓提效的角度看，很多 Hive 模型自身通过 Spark SQL 进行加工，基于加工之后 内存中的 Spark Dataset 能够间接推送到 StarRocks 外面不进行落盘，晋升模型的区域工夫。
StarRocks 目前也是反对 Spark Load，基于 Spark 批量导入数据形式，然而咱们 etl 比较复杂，须要反对数据转换多表 Join、数据聚合运算等，所以临时不能满足。
从 SeaTunnel 社区理解到，目前有打算反对 StarRocks Sink Connector，同时咱们也在做这部分工作，所以前面会跟社区继续沟通共建。
✦如何参加社区建设✦
3.1 SeaTunnel 社区奉献
后面提到了, 社区实现了 V1 到 V2 API 的重构，须要在基于 V2 版本 连接器 API 去实现更多的连接器的插件，我有幸参加其中去奉献。
我目前负责大数据基础架构的工作，很多支流的大数据组件大数据也在应用，所以当社区提出 connector 的 isuue 后，本人也是十分感兴趣。
因为平台也在调研 SeaTunnel，并且通过学习并能向社区奉献 pr 也是理解 SeaTunnel 的一种很好的形式。
因为我刚入社区，所以后期抉择了由易到难的形式，我记得最开始提了一个难度比拟低的 pr，实现 wechat sink connector，然而在奉献的过程中遇到了很多问题，编码格调不好，呈现 codestyle 没有思考到扩大反对丰盛输入格局等状况，尽管过程没那么顺利，然而当 pr 被 mrege 后，真的十分兴奋并且有成就感。
在逐步相熟了整个流程之后，我提交 pr 的效率进步了很多，也有信念尝试高难度的 issue。
3.2 如何疾速参加社区奉献
Goodfirst issue
Goodfirst issue #3018 #2828 如果你是第一次加入社区奉献的话，倡议先关注 Goodfirst issue，因为这外面基本上都是比较简单并且对新人比拟敌对的 issue。
通过Good first issue，能够去相熟参加 githup 开源社区奉献的整个流程，比方首先 fork 我的项目，而后再把改变提交下来，最初再提交 pull request，期待社区同学 review，社区的同学会针对性给你提出一些改善倡议，间接会在上面留言，直到当你的 pr 被 merge 进去，这就走完了一个残缺的奉献的流程，你在这个过程中也会学习到很多货色。
订阅社区邮件
对奉献 pr 的流程相熟之后，你能够订阅社区邮件，实时的理解社区动静，比方社区以后在做什么性能、后续布局迭代的事件是什么？如果对某个性能感兴趣，能够联合本人的状况，就能够参加到奉献中来啦！
相熟 git 应用
开发中，罕用的 git 命令次要包含 git clone、git pull、git rebase 和 git merge。在社区开发标准中，举荐应用 git rebase，相较于 git merge 不会产生额定的 commit 提交记录.
相熟 github 我的项目合作流程
开源我的项目是多人合作开发的，github 上的合作形式 外围概括 fork 例如 apache st 我的项目，他在 apache 空间上面，首先要把我的项目 fork 到咱们 githup 本人的空间上面
而后批改实现，提一个 pull request，提交的 pullrequest 要关联到 issue，在提交时，如果咱们改了很久，在往上提交的话，指标分支有很多新的的 commit 尽来这个时候须要咱们做一个 pull& merge 或者 rebase。
源码编译我的项目
相熟源码编译很重要，通过本地源码编译，能够证实 我的项目增加的代码 是能够编译通过，能够在提交 pr 前做一个初步的测验。还有就是源码编译个别比较慢，能够应用 mvn -T 多线程并行编译减速.
编译查看
编译前查看相干包含 Licence header、Code checkstyle、Document checkstyle， 这些在 Maven 编译期间都会去查看, 并且失败的话 CI 是不能通过的. 所以倡议在 idea 中应用一些插件工具进行提效，例如 Code checkstyle 有主动查看代码标准的插件、Licence header 能够在 idea 增加代码模板，这些之前有社区同学也有分享过怎么做！
增加残缺的 E2E
增加残缺的 E2E 测试，并保障在 Pull request 之前 E2E 是通过的，通过 E2E 能够测试你增加的性能、缩小社区 Code review 老本，同时进步你奉献 PR 效率
我的分享到这里完结了，感激大家的浏览，也欢送来社区跟我获得交换，最初心愿更多的同学退出到 SeaTunnel 社区，在这里不仅能够深切感触到 Apache 的开源精力和文化，还能理解 Apache 我的项目的治理流程，学习到优良的代码设计思维。
心愿通过大家的致力，独特成长，将 SeaTunnel 打造成为顶级的数据集成平台。
Apache SeaTunnel(Incubating) 是一个分布式、高性能、易扩大、用于海量数据（离线 & 实时）同步和转化的数据集成平台
仓库地址： https://github.com/apache/inc…
网址：https://seatunnel.apache.org/
Proposal：https://cwiki.apache.org/conf…
衷心欢送更多人退出！
可能进入 Apache 孵化器，SeaTunnel(原 Waterdrop) 新的途程才刚刚开始，但社区的发展壮大须要更多人的退出。咱们置信，在 「Community Over Code」（社区大于代码）、「Open and Cooperation」（凋谢合作）、「Meritocracy」（精英治理）、以及「 多样性与共识决策」等 The Apache Way 的指引下，咱们将迎来更加多元化和容纳的社区生态，共建开源精力带来的技术提高！
咱们诚邀各位有志于让外乡开源立足寰球的搭档退出 SeaTunnel 贡献者小家庭，一起共建开源!
提交问题和倡议：https://github.com/apache/inc…
奉献代码：https://github.com/apache/inc…
订阅社区开发邮件列表 : [email protected]
开发邮件列表：[email protected]
退出 Slack:https://join.slack.com/t/apac…
关注 Twitter: https://twitter.com/ASFSeaTunnel
