• 为什么开发自己的引擎
• SeaTunnel Engine 定位
• 设计思路
• 架构设计
• 独特优势和特点
• 目前基本功能和特性
• 未来优化方向

为什么我们要自研全球首款大数据同步引擎 SeaTunnel Engine？

1. 简单易用，新的引擎尽量减小第三方服务的依赖，可以不依赖zookeeper，hdfs等大数据组件实现集群管理、快照存储和集群HA功能。这对于那些没有大数据平台或者不愿意依赖大数据平台进行数据同步的用户非常有用。
2. 更省资源，在CPU层面SeaTunnel Engine内部使用dynamic thread sharing技术 ，在实时同步的场景下，如果表的数量很多但每张表的数据量又很小，SeaTunnel Engine会将这些同步任务在共享线程中运行，这种方式可以减少不必要的线程创建，节省系统资源。在读取和数据写入端，SeaTunnel Engine的设计目标是尽量减少JDBC连接的个数。在CDC的场景下SeaTunnel Engine会尽量复用日志读取解析资源。
3. 更稳定，在这个版本中，SeaTunnel Engine将数据同步的任务以Pipeline做为Checkpoint和容错的最小粒度，一个task的失败只会影响到和它有上下游关系的task，尽量避免task失败造成整个Job失败或回滚。同时对于那些源端数据有存储时间限制的场景，SeaTunnel Engine支持开启数据Cache，开启Cache后SeaTunnel Engine会自动将从源端读取的数据缓存起来，然后由下游任务读取缓存数据并写入目标端。这种场景下即使目标端出现故障导致数据无法写入，也不会影响源端的正常读取，防止源端数据过期被删除。
4. 更快速，SeaTunnel Engine的执行计划优化器会以减小数据可能的网络传输为目标来做执行计划的优化，从而降低数据序列化和反序列化带来的整体同步性能的损耗，更快地完成数据同步操作。当然我们也会支持速度限制，让同步作业以一个合理的速度进行。
5. 全场景数据同步支持。SeaTunnel的目标是支持离线批量同步下的全量同步和增量同步。支持实时同步。支持CDC。

1. JobMaster，负责单个作业的 LogicalDag 到 ExecutionDag，再到 PhysicalDag 的生成流程，并由 PipelineBaseScheduler 进行调度运行。
2. CheckpointCoordinator，负责作业的 Checkpoint 流程控制。
3. ResourceManager，负责作业资源的申请和管理，目前支持 Standalone 模式，未来会支持 On Yarn 和 On K8s。
4. Metrics Service，负责作业监控信息的统计和汇总。

• 支持单机运行
• 支持集群运行
• 自治集群（无中心化），不需要为SeaTunnel Engine集群指定Master节点，SeaTunnel Engine在运行中自行选举Master节点，Master节点挂掉后会自动选出新的Master节点。
• 集群节点自动发现，具体相同cluster_name的节点会自动组成集群。

• 支持以Local模式运行作业。作业运行完成后集群自动销毁。
• 支持以Cluster的模式（单机或集群）运行作业，通过SeaTunnel Client提交作业到SeaTunnel Engine服务中，作业运行完成后服务继续运行等待下次作业提交。
• 支持离线批量同步。
• 支持实时同步。
• 批流一体，所有SeaTunnel V2版本连接器都可以运行在SeaTunnel Engine中。
• 支持分布式快照算法，配合SeaTunnel V2连接器支持二阶段提交，保证数据的exactly-once。
• 支持以Pipeline级别的作业调用，保证在资源有限的情况下也能启动。
• 支持以Pipeline级别作业容错，Task失败只影响到它所在的Pipeline，只需要对该Pipeline下的Task进行回滚处理。
• 支持dynamic thread sharing，以实现大量小数据集的实时同步。

1. 支持Cache模式，并先支持Kafka做为Cache
2. 支持JobHistory，支持JobHistory的持久化。
3. 支持指标（Reader Rows, QPS, Reader Bytes）监控和指标查询
4. 支持动态修改执行计划。
5. 支持CDC。
6. 支持整库同步
7. 支持多表同步
8. 支持Schema Revolution

关注视频号预约直播！