很长一段时间，阿里开源的 DataX 是很多小公司或者说没有数据平台的公司的首选数据集成工具，通过简单的配置就可以实现数据传输，但是问题也比较多，社区活跃度很低、小 bug多、不支持分布式等等。再看大数据领域， Apache Sqoop 一直是一个不错的选择，虽然效率的问题一直被诟病， 去年也已经从 Apache 退役，但是仍有不少的公司在使用这辆“老爷车”。如今似乎有了一个更好的选择，Apache SeaTunnel 实现了自己的引擎不再绑定 Spark/Flink，无需部署复杂的环境、更多的connector选择、更好的性能、支持分布式、有 webUI 可视化操作（即将 Release）...... DataX or SeaTunnel？这变成了一道送分题。下面详细了解一下 Apache SeaTunnel 这个数据集成利器。
前几日 Apache SeaTunnel 官方账号发布了和 DataX 对比的性能测试报告，结果显示在相同测试环境下，最新发布的同步计算引擎 SeaTunnel Engine 均比DataX同步数据的速度更快，甚至在内存吃紧的情况下，内存的降低对 SeaTunnel Engine 没有显著影响。详情大家有兴趣可以去原文看看，这一篇主要来扒一扒 SeaTunnel 新引擎的新特性和设计原理。
在今年5月份第一次讨论 SeaTunnel Engine 的 issue 中（apache/incubator-seatunnel#1954）提到了为什么要自研 SeaTunnel Engine以及要解决的问题：
- Better resource utilization rate：更高的资源利用率
- Fewer database connectors：更少的数据库连接器
- Data Cache between Source and Sink：Source 和 Sink 之间的数据缓存
- Schema Evolution：允许用户更改表的 schema 以适应随时间变化的数据。
- Finer fault tolerance：新引擎应该提供更复杂的容错管理。它应该支持单个任务失败而不影响其他任务的执行。提供一个接口，以便用户可以手动重试失败的任务，而不是重试整个作业。
- Speed Control：在批处理作业中，我们需要支持速度控制。让用户选择他们想要的同步速度，以防止对源或目标数据库造成太大影响。
1. 版本特性
SeaTunnel Engine 发布的第一个版本是 2.3.0-beta-Release，我们来看看他的新特性。
- 集群管理
-
- 支持单机运行；
- 支持集群运行；
- 自治集群（无中心化），不需要为 SeaTunnel Engine 集群指定 Master 节点，其在运行中可以自行选举 Master 节点，Master 节点失败后会自动选出新的 Master 节点。
- 集群节点自动发现，相同的 cluster_name 的节点会自动组成集群。
- 核心功能
-
- 支持以 Local 模式运行作业，作业运行完成后集群自动销毁；
- 支持以 Cluster 模式（单机或集群）运行作业，通过 SeaTunnel Client 提交作业到 SeaTunnel Engine 服务中，作业运行完成后服务继续运行等待下次作业提交；
- 支持离线批量同步；
- 支持实时同步；
- 批流一体，所有 SeaTunnel V2 版本连接器都可以运行在 SeaTunnel Engine 中；
- 支持分布式快照算法，配合 SeaTunnel V2 连接器支持二阶段提交，保证数据只执行一次。
- 支持以 Pipeline 级别的作业调用，保证在资源有限的情况下也能启动；
- 支持以 Pipeline 级别作业容错，task 失败只影响到其所在的 Pipeline，只需要对该 Pipeline 下的 Task 进行回滚处理；
- 支持动态线程共享，实现大量小数据集的实时同步。
2. 设计原理
2.1. SeaTunnel Engine Server 端设计
以下图片引自：apache/incubator-seatunnel#2210
SeaTunnel Engine 分布式的特性是依赖 Hazelcast 的 NodeExtension 扩展引擎实现的，依赖于 Hazelcast 动态缩放、自动主选择和分布式内存。图中灰色部分为hezalcast，蓝色部分为 ST-engine。
-
job submit：客户端向 Master 节点的 ST-Service 提交一个job，Job 在 ST-Service 中生成一个物理执行计划 Task，提交给集群中其他节点的 ST-Service 执行。作业状态等信息保存在 Hazelcast 的 Imap（分布式存储）中。
-
容错性：ST-Service 实例是无状态的（状态保存在Hazelcast的分布式存储中），所以当 Master 节点挂了。Hazelcast 会自动选举另一个节点作为Master，这个节点上的 ST-Service 会继续提供服务。
2.2. 核心设计
-
CacheSink： Internal Sink，将数据写入缓存。
-
CacheSource： Internal Source，从缓存中读取数据。
-
Source(Custom)： SeaTunnel Connector 模块中定义的 Source Connector。
-
Sink(Custom)： SeaTunnel Connector模块中定义的Sink Connector。
-
Transform(Custom)： 在 SeaTunnel Connector 模块中定义的 Transform Connector。
-
Task：Task 一般包括一个source+transform+sink的操作。任务之间没有数据依赖或上游/下游关系。因此，一项任务的失败不会影响其他任务的结果是否正确
-
- 可以设置任务的失败重试次数。一般来说，建议批量运行3次左右，可以有更多的实时场景。每个作业都支持设置任务失败时作业是否失败的策略。一般来说，离线场景默认任务失败，实时场景默认任务失败。
- 在实时场景下，当job policy为任务失败，job仍在运行时，支持单个失败任务的“手动重试”操作，让失败的任务再次重试。
- 在实时场景下，当作业策略为任务失败，作业仍在运行时，支持单个任务的停止、启动和重启操作。
-
Job： 每个job都类似于Flink中的job。如果任何任务失败，调度程序负责失败任务的容错。因为任务之间没有数据依赖，其他任务正常运行。事务和状态的持久化也是任务粒度，不是作业粒度。
整体来看，这次 SeaTunnel Engine Release 对项目发展方向影响很大，SeaTunnel 定位更加明确，不再是 Spark/Flink 的封装层，且不久即将发布的web ui 也将让数据同步变得更加简单，用户量势必会爆增，小编后续也会持续关注 SeaTunnel 的发展，带来更多干货。
