数据工程大数据批处理流处理【免费下载链接】seatunnelSeaTunnel is a next-generation super high-performance, distributed, massive data integration tool.项目地址https://gitcode.com/gh_mirrors/sea/seatunnel点击查看免费下载本篇技术指南以 Apache SeaTunnel 官方文档 docs/en/seatunnel-engine/about.md 为核心骨架系统讲解 SeaTunnel EngineZeta的设计理念、集群管理、核心功能、三种部署模式与关键配置并结合仓库源码与真实配置文件深入验证其底层实现。读完本文你将掌握 SeaTunnel Engine 为什么更快、更稳定、更省资源、更易用以及如何从零搭建本地模式、混合集群模式与分离集群模式并熟练使用seatunnel.sh完成作业提交、暂停、恢复与取消等日常运维。一、SeaTunnel Engine 是什么SeaTunnel Engine 是社区为数据同步场景量身打造的数据同步引擎也是 SeaTunnel 的默认引擎。它专为大规模数据集成massive data integration设计支持高吞吐、低延迟、强一致的同步作业运行整体上比传统方案更快、更稳定、更节省资源并且开箱即用、易于上手。从定位上看SeaTunnel Engine 与 SeaTunnel V2 Connector 生态天然一体所有 SeaTunnel V2 连接器都可以直接跑在 SeaTunnel Engine 上实现离线批同步、实时同步与 CDC 同步的统一编排。它同时承担了集群管理、任务调度、检查点Checkpoint与容错恢复等引擎级能力而这些能力在仓库中分别由 seatunnel-engine 模块下的seatunnel-engine-core核心逻辑、seatunnel-engine-server服务端实现、seatunnel-engine-client客户端等子模块承载。二、四大设计理念更快、更稳、更省、更简SeaTunnel Engine 的整体设计遵循以下四条主线这也是理解其内部架构的钥匙。2.1 更快执行计划优化 限速SeaTunnel Engine 内置执行计划优化器execution plan optimizer核心目标是减少数据在网络中的传输量从而降低因数据序列化 / 反序列化带来的整体同步性能损耗让用户更快地完成数据同步同时支持**限速speed limit**能力允许以合理速度同步数据。从源码结构看作业从配置解析到真正执行需要经历逻辑 DAG 到物理计划的转化RestJobExecutionEnvironment#getLogicalDag负责产出逻辑 DAGJobMaster#getPhysicalPlan维护物理执行计划而CoordinatorService作为引擎侧的协调中枢统一管理 JobMaster、资源管理与任务执行状态的更新参见 CoordinatorService.java、JobMaster.java。这一逻辑计划 → 物理计划的编排路径正是优化器发挥作用的执行基础。2.2 更稳定Pipeline 级容错 数据缓存SeaTunnel Engine 以Pipeline 作为检查点Checkpoint与容错的最小粒度。某个任务的失败只会影响其上下游任务不会导致整个作业失败或整体回滚从而避免单点故障拖垮全作业的连锁反应。与此同时引擎针对源端数据有存储时限的场景提供了**数据缓存data cache**能力开启缓存后从源读取的数据会被自动缓存再由下游任务读取并写入目标端即便目标端故障导致暂时无法写入也不会影响源端的正常读取从而防止源端数据在过期时被删除。从源码看检查点与容错由CheckpointManager、CheckpointCoordinator等类协作完成包括TaskAcknowledgeOperation任务确认、PendingCheckpoint待完成检查点、CompletedCheckpoint已完成检查点等核心组件实现了分布式快照与两阶段提交的语义详见下文第六节。2.3 更省空间动态线程共享 资源复用引擎内部使用**动态线程共享Dynamic Thread Sharing**技术在实时同步场景下当表数量很多、但每张表数据量很小小表多时SeaTunnel Engine 会让这些同步任务共享线程运行减少不必要的线程创建从而节省系统空间。在读写侧引擎的设计目标是最小化 JDBC 连接数在 CDC 场景下SeaTunnel Engine 会复用日志读取与解析资源避免为每个任务重复创建昂贵的资源。仓库中TaskExecutionService提供了BlockingWorker、CooperativeTaskWorker、BlockingTaskThreadFactory、RunBusWorkSupplier等线程模型实现参见 TaskExecutionService.java线程共享模式可通过seatunnel.yaml中的task_execution_thread_share_mode取值ALL/OFF/PART默认OFF进一步调整相关选项定义在 ServerConfigOptions.java。2.4 更简单易用去第三方依赖独立完成集群管理SeaTunnel Engine大幅降低对第三方服务的依赖可以不借助 Zookeeper、HDFS 等大数据组件独立实现集群管理、快照存储与集群 HA。这对当前缺少大数据平台、或不愿依赖大数据平台做数据同步的用户非常友好。具体实现上SeaTunnel Engine 基于 Hazelcast IMDG 实现集群管理集群状态数据作业运行状态、资源状态存放在 Hazelcast IMap 中通过分布式分区与副本backup count机制实现高可用因此无需额外引入 Zookeeper 等协调服务详见 hybrid-cluster-deployment.md 与 separated-cluster-deployment.md。展望官方文档指出SeaTunnel Engine 未来还将进一步优化全面支持离线批同步的全量 / 增量同步、实时同步与 CDC变更数据捕获同步。三、集群管理单机、集群与自治集群SeaTunnel Engine 在集群管理层面提供三种能力支持单机运行standalone单节点即可完成作业运行适合测试与轻量场景支持集群运行cluster多节点组成集群协同工作支持自治集群autonomous / decentralized集群是去中心化的用户无需手动指定 Master 节点——集群在运行过程中自行选举出 Master当 Master 故障时会自动选出新的 Master 节点。自治集群还有一个关键特性节点自动发现——cluster_name相同的节点会自动组成一个集群。这正是通过 hazelcast.yaml 中的cluster-name配置实现的节点之间用cluster-name判断彼此是否属于同一集群名称不同则拒绝服务请求。节点间通过 TCP/IP 发现机制自动加入集群形成以 Hazelcast 为底座的分布式组网。四、核心功能清单SeaTunnel Engine 的核心功能可归纳为以下几点它们共同构成了完整的数据同步引擎能力矩阵能力维度功能说明本地模式运行支持以本地模式运行作业作业一旦完成集群自动销毁集群模式运行支持集群模式单机或集群通过 SeaTunnel 客户端向引擎服务提交作业作业完成后服务持续运行等待下一次提交离线批同步支持离线批量数据同步实时同步支持实时数据同步批流一体所有 SeaTunnel V2 连接器均可运行于 SeaTunnel Engine分布式快照支持分布式快照算法并与 V2 连接器配合实现两阶段提交确保数据只执行一次exactly-oncePipeline 级调度支持按 Pipeline 粒度调度作业保证在资源受限时也能启动Pipeline 级容错任务失败只影响其所在 Pipeline只需回滚该 Pipeline 下的任务动态线程共享实时同步大量小数据集时共享线程节省资源其中分布式快照 两阶段提交直接对应仓库中的CheckpointManager、CheckpointCoordinator、PendingCheckpoint与CompletedCheckpoint等检查点核心类参见 seatunnel-engine-server 下的 checkpoint 相关实现。Pipeline 级容错则在JobMaster#handleCheckpointError(pipelineId, neverRestore)、releasePipelineResource(SubPlan)等接口中体现容错与资源释放都以 Pipeline 为操作单元这与任务失败只影响所在 Pipeline的设计目标一一对应。五、三种部署模式Local、Hybrid 与 SeparatedSeaTunnel Engine 支持三种部署模式各有适用场景、优点与局限官方建议根据需求与环境选择详见 deployment.md5.1 本地模式Local Mode仅用于测试每个任务会启动一个独立进程任务完成后进程即退出。局限包括不支持暂停 / 恢复任务、不支持查看任务列表、无法通过命令取消作业只能杀死进程、不支持 REST API。部署只需将安装包拷贝到目标服务器可通过修改$SEATUNNEL_HOME/config/jvm_client_options调整作业执行的 JVM 参数提交命令为$SEATUNNEL_HOME/bin/seatunnel.sh --config $SEATUNNEL_HOME/config/v2.batch.config.template -m local作业在提交进程内运行运行日志输出到该进程的标准输出。完整说明见 local-mode-deployment.md。5.2 混合集群模式Hybrid Cluster ModeMaster 与 Worker 同进程Master 服务与 Worker 服务混合在同一个进程中所有节点都能运行作业也都能参与选举成为 Master即 Master 节点同时也在跑同步任务。此模式下Imap保存任务状态信息、为任务容错提供支撑数据会分布存储在所有节点上。需要特别注意的是混合模式下 Master 节点要同时运行同步任务当任务规模较大时会影响 Master 稳定性一旦 Master 崩溃或心跳超时引发主节点切换所有运行中任务都要做一次容错进一步加重集群负载。因此官方明确推荐使用分离集群模式。部署细节见 hybrid-cluster-deployment.md。5.3 分离集群模式Separated Cluster Mode实验特性官方首推Master 服务与 Worker 服务彻底分离各自独立进程Master 节点只负责作业调度、REST API、任务提交等Imap 数据仅存储在 Master 节点上Worker 节点只负责任务执行不参与选举成为 Master也不存储 Imap 数据。多个 Master 节点中同时只有一个处于 Active 状态其余为 Standby当前 Master 故障或心跳超时后会从其余 Master 中自动选举出新的 Active 节点。该模式下 Master 负载很低可将更多资源用于作业调度、容错指标监控与 REST API 服务稳定性更高同时 Worker 不存储 Imap 数据即使 Worker 高负载或崩溃也不会引发 Imap 数据重分布。部署细节见 separated-cluster-deployment.md。从源码看三种模式对应SeaTunnelServerStarter中的createMasterAndWorkerHazelcastInstance混合模式与createMasterHazelcastInstance/createWorkerHazelcastInstance分离模式等不同的 Hazelcast 实例创建路径参见 SeaTunnelServerStarter.java印证了不同部署模式在服务端确实是不同的进程模型。六、引擎核心配置seatunnel.yaml 逐项详解引擎的多数功能都在$SEATUNNEL_HOME/config/seatunnel.yaml中配置仓库默认示例见 config/seatunnel.yaml。下面按官方文档 hybrid-cluster-deployment.md 与 separated-cluster-deployment.md 的章节逐项展开并给出源码中的默认值与语义选项定义均位于 ServerConfigOptions.java。6.1 Imap 数据备份数backup-countSeaTunnel Engine 基于 Hazelcast IMDG 实现集群管理集群的状态数据作业运行状态、资源状态存放在 Hazelcast IMap 中数据被 Hazelcast 分区后分布存储在集群所有节点上每个分区可指定备份数量因此无需 Zookeeper 即可实现集群 HA。backup-count定义同步备份的数量设为 1 表示分区备份存放在另一个成员上设为 2 表示存放在另外两个成员上。官方建议取min(1, max(5, N/2))其中N为集群节点数。seatunnel: engine: backup-count: 1 # Other configurations源码中该选项默认值为 1ServerConfigOptions.java#L29-L33。注意分离集群模式下 Worker 不存储 Imap 数据因此 Worker 上的backup-count配置不生效若 Master 与 Worker 在同一台机器上共用seatunnel.yamlWorker 服务会忽略该配置。6.2 Slot 配置动态槽位与静态槽位Slot 数量决定了集群节点可并行运行的任务组数量。单个任务所需 Slot 数计算公式为N 2 PP 为任务配置的并行度。默认情况下 Slot 数是动态的即数量无上限官方建议设置为节点 CPU 核心数的两倍。动态 Slot默认seatunnel: engine: slot-service: dynamic-slot: true # Other configurations静态 Slotseatunnel: engine: slot-service: dynamic-slot: false slot-num: 20源码中dynamic-slot默认值为trueslot-num默认值为 2仅在关闭动态槽位时生效ServerConfigOptions.java#L61-L72。注意分离模式下 Master 不运行任务因此slot-service配置在 Master 上不生效同机共用配置时 Master 服务会忽略该配置项。Slot 的实际申请与释放由DefaultSlotService完成requestSlot/releaseSlot参见 DefaultSlotService.java。6.3 Checkpoint Managerinterval 与 timeout与 Flink 类似SeaTunnel Engine 支持Chandy–Lamport 分布式快照算法因此可以实现不丢失、不重复的数据同步。interval两次检查点之间的间隔单位毫秒。若作业配置文件env中配置了checkpoint.interval则以作业配置为准。timeout检查点超时时间单位毫秒。若检查点无法在超时时间内完成将触发检查点失败并使作业失败。若作业配置文件env中配置了checkpoint.timeout则以作业配置为准。完整示例seatunnel: engine: backup-count: 1 print-execution-info-interval: 10 slot-service: dynamic-slot: true checkpoint: interval: 300000 timeout: 10000源码中interval默认值为 3000005 分钟timeout默认值为 3000030 秒ServerConfigOptions.java#L74-L85。注意分离模式下检查点配置只由 Master 服务读取Worker 不读取同机共用配置时 Worker 忽略该配置。引擎的检查点机制运作流程如下检查点按固定周期触发每次执行检查点时每个 Task 需向检查点线程上报自身状态信息如读取 Kafka 时读到了哪个 offset检查点线程将其写入分布式存储或共享存储。当任务失败自动容错恢复或通过seatunnel.sh -r恢复此前暂停的任务时会从检查点存储加载对应作业的状态信息并据此恢复作业。若集群节点数大于 1检查点存储必须是分布式存储或共享存储以保证任一节点故障后任务状态信息仍能在其他节点上被加载。6.4 历史作业过期配置history-job-expire-minutes每个已完成作业的信息状态、计数器、错误日志等存放在 IMap 对象中。随着运行作业数量增多内存占用会不断上升最终可能导致内存溢出。history-job-expire-minutes用于控制历史作业信息的保留时长单位为分钟默认值 1440一天。seatunnel: engine: history-job-expire-minutes: 1440源码中默认值确为 1440ServerConfigOptions.java#L135-L139仓库默认配置 config/seatunnel.yaml 同样使用 1440。6.5 类加载器缓存模式classloader-cache-mode该配置主要解决持续创建并尝试销毁类加载器导致的资源泄漏问题。如果遇到 metaspace 溢出相关异常可以尝试开启此配置。开启后SeaTunnel 在作业完成时不会尝试释放对应类加载器而是让其被后续作业复用从而降低类加载器创建频率当运行作业中使用的 Source/Sink 连接器种类不多时效果更佳。默认值为false。seatunnel: engine: classloader-cache-mode: true源码中默认值为falseServerConfigOptions.java#L200-L205。6.6 其他引擎级配置除上述核心配置外仓库默认的 config/seatunnel.yaml 还包含几个官方文档提及之外的实用选项可直接参考queue-type: blockingqueue引擎内部数据缓存队列类型QueueType默认BLOCKINGQUEUEprint-execution-info-interval: 60打印执行信息的间隔秒默认 60print-job-metrics-info-interval: 60打印作业指标信息的间隔秒默认 60。七、网络与服务配置hazelcast.yamlSeaTunnel Engine 的所有网络相关配置都在hazelcast.yaml中混合模式仓库默认示例见 config/hazelcast.yaml分离模式下则拆分到 hazelcast-master.yaml 与 hazelcast-worker.yaml。7.1 cluster-name集群身份标识节点使用cluster-name判断另一节点是否与自己同属一个集群若两个节点集群名不同SeaTunnel Engine 将拒绝服务请求。客户端hazelcast-client.yaml也必须配置相同的cluster-name否则客户端请求会被拒绝。7.2 网络发现机制与 TCP 配置基于 Hazelcast 的发现机制SeaTunnel Engine 集群由运行着引擎服务器的成员自动加入组成。注意集群一旦形成成员间通信始终通过 TCP/IP与使用何种发现机制无关。TCP 方式配置示例如下TCP 是在独立 SeaTunnel Engine 集群中的推荐方式hazelcast: cluster-name: seatunnel network: join: tcp-ip: enabled: true member-list: - hostname1 port: auto-increment: false port: 5801 properties: hazelcast.logging.type: log4j2关于 TCP 发现的详细配置说明可参考 tcp.md。仓库默认配置在此基础上增加了 REST APICLUSTER_WRITE/DATA端点组与心跳检测参数phi-accrual 故障检测器、心跳间隔 2 秒、最大无心跳时间 180 秒等见 config/hazelcast.yaml。在分离集群模式下Master 与 Worker 使用不同端口如 Master5801、Worker5802并分别维护各自的 member-list示例可参考 separated-cluster-deployment.md 中的hazelcast-master.yaml与hazelcast-worker.yaml完整配置。7.3 IMap 持久化配置MapStoreSeaTunnel 用 IMap 存储每个任务的运行状态实现节点故障后的任务恢复与容错。默认情况下 Imap 数据仅保存在内存中可通过副本数即上文backup-count提升可靠性但当所有节点全部停止时Imap 数据会丢失重启后所有此前运行的任务会被标记为失败需要用户通过seatunnel.sh -r手动恢复。为解决该问题可将 Imap 数据持久化到外部存储如 HDFS、OSS这样即使所有节点停止Imap 数据也不会丢失集群重启后所有此前运行的任务会自动恢复。MapStore 配置各参数说明如下typeIMap 持久化类型目前仅支持hdfsnamespace用于区分不同业务数据的存储位置如 OSS bucket 名clusterName主要用于集群隔离可区分不同集群如 cluster1、cluster2也可用于区分不同业务fs.defaultFS引擎通过 hdfs api 读写文件使用该存储必须提供 hdfs 配置。HDFS 配置示例map: engine*: map-store: enabled: true initial-mode: EAGER factory-class-name: org.apache.seatunnel.engine.server.persistence.FileMapStoreFactory properties: type: hdfs namespace: /tmp/seatunnel/imap clusterName: seatunnel-cluster storage.type: hdfs fs.defaultFS: hdfs://localhost:9000无 HDFS 且集群仅单节点时可改用本地文件map: engine*: map-store: enabled: true initial-mode: EAGER factory-class-name: org.apache.seatunnel.engine.server.persistence.FileMapStoreFactory properties: type: hdfs namespace: /tmp/seatunnel/imap clusterName: seatunnel-cluster storage.type: hdfs fs.defaultFS: file:///使用 OSS 时的配置示例map: engine*: map-store: enabled: true initial-mode: EAGER factory-class-name: org.apache.seatunnel.engine.server.persistence.FileMapStoreFactory properties: type: hdfs namespace: /tmp/seatunnel/imap clusterName: seatunnel-cluster storage.type: oss block.size: block size(bytes) oss.bucket: oss://bucket name/ fs.oss.accessKeyId: OSS access key id fs.oss.accessKeySecret: OSS access key secret fs.oss.endpoint: OSS endpoint fs.oss.credentials.provider: org.apache.hadoop.fs.aliyun.oss.AliyunCredentialsProvider使用 OSS 时需确保lib目录下存在以下 jaraliyun-sdk-oss-3.13.2.jar hadoop-aliyun-3.3.6.jar jdom2-2.0.6.jar netty-buffer-4.1.89.Final.jar netty-common-4.1.89.Final.jar seatunnel-hadoop3-3.1.4-uber.jar八、Checkpoint 存储从 LocalFile 到 HDFS / S3 / OSSCheckpoint 是容错恢复机制Checkpoint Storage 则是存储检查点数据的存储机制。SeaTunnel Engine 支持以下检查点存储类型HDFS涵盖 OSS、S3、HDFS、LocalFile 四种存储后端LocalFile原生已废弃建议改用 HDFSLocalFile方式。引擎采用微内核设计模式将检查点存储模块与引擎解耦允许用户实现自己的检查点存储模块checkpoint-storage-api定义了存储模块的接口实现自定义模块需要实现CheckpointStorage并提供对应的CheckpointStorageFactory实现。检查点存储配置位于seatunnel.yaml中通用结构如下seatunnel: engine: checkpoint: storage: type: hdfs #checkpoint storage 插件名支持 hdfs(S3, local, hdfs)localfile(原生本地文件) 已废弃 plugin-config: namespace: #checkpoint storage 父路径默认值为 /seatunnel/checkpoint/ K1: V1 # 插件其他配置 K2: V2 # 插件其他配置注意namespace必须以 / 结尾。各存储后端的具体配置OSS、S3、HDFS、LocalFile完整示例见 checkpoint-storage.md这里摘取关键点OSSstorage.type: oss配合oss.bucket、fs.oss.accessKeyId、fs.oss.accessKeySecret、fs.oss.endpoint、fs.oss.credentials.provider使用org.apache.hadoop.fs.aliyun.oss.AliyunCredentialsProviderS3storage.type: s3配合s3.bucket、fs.s3a.access.key、fs.s3a.secret.key、fs.s3a.aws.credentials.provider如org.apache.hadoop.fs.s3a.SimpleAWSCredentialsProvider运行在 EC2 时也可用InstanceProfileCredentialsProvider使用兼容 S3 协议的 MinIO 时需配置fs.s3a.endpoint指向 MinIO 服务地址并确保密钥对 bucket 有写权限否则返回 403HDFSstorage.type: hdfs配合fs.defaultFS: hdfs://localhost:9000若使用 Kerberos可配置kerberosPrincipal与kerberosKeytabFilePath需要额外 hdfs-site 配置时可指定hdfs_site_pathHDFS 处于 HA 模式时可通过seatunnel.hadoop.dfs.nameservices、seatunnel.hadoop.dfs.ha.namenodes.*等以seatunnel.hadoop.为前缀的配置项覆盖hdfs-site.xml/core-site.xml中的其他配置LocalFilefs.defaultFS: file:///需确保目录有写权限。此外当storage.type为 hdfs 时缓存默认关闭如需开启设置disable.cache: falseseatunnel: engine: checkpoint: interval: 6000 timeout: 7000 storage: type: hdfs max-retained: 3 plugin-config: storage.type: hdfs disable.cache: false fs.defaultFS: hdfs:///源码层面max-retained保留的最大检查点数量默认值为 20type默认值为localfileServerConfigOptions.java#L94-L104。仓库默认配置 config/seatunnel.yaml 使用 hdfs 类型、max-retained: 3并将快照写到/tmp/seatunnel/checkpoint_snapshotfs.defaultFS: file:///tmp/适合本地快速验证。九、部署实操从下载到启动集群完整安装包制作流程见 download-seatunnel.md。部署通用步骤概括如下下载并制作安装包见 download-seatunnel.md将$SEATUNNEL_HOME配置到环境变量例如在/etc/profile.d/seatunnel.sh中加入export SEATUNNEL_HOME${seatunnel install path} export PATH$PATH:$SEATUNNEL_HOME/bin配置 JVM 参数混合模式修改 config/jvm_options或启动时追加如seatunnel-cluster.sh -DJvmOption-Xms2G -Xmx2G分离模式Master 使用 config/jvm_master_optionsWorker 使用 config/jvm_worker_options示例均包含堆大小、HeapDump、Metaspace 与 G1GC 配置。按需修改 config/seatunnel.yaml引擎功能与 config/hazelcast.yaml网络参数含义见本文第六、七节。启动引擎服务混合模式mkdir -p $SEATUNNEL_HOME/logs ./bin/seatunnel-cluster.sh -d日志写入$SEATUNNEL_HOME/logs/seatunnel-engine-server.log分离模式 Master./bin/seatunnel-cluster.sh -d -r master日志写入seatunnel-engine-master.log分离模式 Worker./bin/seatunnel-cluster.sh -d -r worker日志写入seatunnel-engine-worker.log。安装客户端将引擎节点上的$SEATUNNEL_HOME目录拷贝到客户端节点并同样配置SEATUNNEL_HOME客户端所有配置在 config/hazelcast-client.yaml 中需与引擎保持相同cluster-name并在network.cluster-members中填写所有引擎节点地址分离模式下填写所有 Master 节点地址如master-node-1:5801。十、作业提交与管理seatunnel.sh 命令行工具SeaTunnel Engine 提供命令行工具管理作业支持提交、停止、暂停、恢复、删除作业以及查看作业状态与监控指标等。先通过sh bin/seatunnel.sh -h获取帮助完整参数如下原文见 user-command.mdUsage: seatunnel.sh [options] Options: --async Run the job asynchronously. When the job is submitted, the client will exit (default: false). -can, --cancel-job Cancel the job by JobId. --check Whether to check the config (default: false). -cj, --close-job Close the client and the task will also be closed (default: true). -cn, --cluster The name of the cluster. -c, --config Config file. --decrypt Decrypt the config file. When both --decrypt and --encrypt are specified, only --encrypt will take effect (default: false). -m, --master, -e, --deploy-mode SeaTunnel job submit master, support [local, cluster] (default: cluster). --encrypt Encrypt the config file. When both --decrypt and --encrypt are specified, only --encrypt will take effect (default: false). --get_running_job_metrics Get metrics for running jobs (default: false). -h, --help Show the usage message. -j, --job-id Get the job status by JobId. -l, --list List the job status (default: false). --metrics Get the job metrics by JobId. -n, --name The SeaTunnel job name (default: SeaTunnel). -r, --restore Restore with savepoint by jobId. -s, --savepoint Savepoint the job by jobId. -i, --variable Variable substitution, such as -i citybeijing, or -i date20190318. We use , as a separator. When inside , , are treated as normal characters instead of delimiters. (default: []).10.1 提交作业sh bin/seatunnel.sh --config $SEATUNNEL_HOME/config/v2.batch.config.template--async使作业后台运行提交后客户端即退出sh bin/seatunnel.sh --config $SEATUNNEL_HOME/config/v2.batch.config.template --async-n/--name指定作业名称sh bin/seatunnel.sh --config $SEATUNNEL_HOME/config/v2.batch.config.template --async -n myjob仓库提供了可直接运行的模板配置 config/v2.batch.config.templateenv 中parallelism 2、job.mode BATCH、checkpoint.interval 10000source 为 FakeSource、sink 为 Console与 config/v2.streaming.conf.template流式模板可作为作业配置的起点。10.2 查看作业列表与状态# 输出当前集群所有作业含已完成的历史作业与运行中作业 sh bin/seatunnel.sh -l # 输出指定作业的状态信息 sh bin/seatunnel.sh -j jobId10.3 获取监控信息# 输出运行中作业的监控信息 sh bin/seatunnel.sh --get_running_job_metrics # 输出指定作业的监控信息 sh bin/seatunnel.sh --metrics jobId10.4 暂停作业sh bin/seatunnel.sh -s jobId暂停作业以split 为最小单位暂停后引擎会等待当前运行的 split 运行完毕再暂停任务恢复后从暂停的 split 继续运行。注意只有启用检查点的作业支持暂停实时同步作业默认开启检查点批作业默认不开启需在env中配置checkpoint.interval开启。10.5 恢复作业sh bin/seatunnel.sh -r jobId -c $SEATUNNEL_HOME/config/v2.batch.config.template恢复作业需要 jobId 与作业配置文件失败的作业和被-s暂停的作业都可以通过此命令恢复。同样只有启用检查点的作业支持恢复。10.6 取消作业sh bin/seatunnel.sh -can jobId取消后作业停止状态变为CANCELED且该作业的所有断点信息都会被删除无法再通过-r恢复。十一、快速上手与延伸阅读若想快速跑通一个 SeaTunnel Engine 作业可以按以下路径操作参照 download-seatunnel.md 制作安装包并配置环境变量以本地模式提交仓库自带的批量模板作业$SEATUNNEL_HOME/bin/seatunnel.sh --config $SEATUNNEL_HOME/config/v2.batch.config.template -m local详见 local-mode-deployment.md本地快速开始的更多指引位于 docs/en/start-v2/locally 目录。围绕 SeaTunnel Engine 的更多主题仓库还提供以下深度文档可继续阅读deployment.md三种部署模式总览与选型建议hybrid-cluster-deployment.md 与 separated-cluster-deployment.md两种集群模式的分步部署checkpoint-storage.md检查点存储各后端配置全集tcp.mdTCP/IP 成员发现机制细节rest-api.md引擎 REST APIsavepoint.md保存点Savepoint机制engine-jar-storage-mode.md连接器 Jar 存储模式resource-isolation.md资源隔离user-command.md命令行工具完整手册。结语SeaTunnel EngineZeta以更快、更稳、更省、更简为设计纲领通过执行计划优化、Pipeline 级检查点与容错、动态线程共享、去中心化自治集群等一系列机制为 SeaTunnel 提供了高性能、强一致且极易部署的默认同步引擎。无论是单机测试的本地模式、快速上手的混合集群模式还是官方推荐的分离集群模式都可以借助本文介绍的seatunnel.yaml、hazelcast.yaml与seatunnel.sh快速落地其检查点存储、IMap 持久化与丰富的命令行运维能力则进一步保证了大规模同步作业的可靠性与可运维性。结合本文引用的仓库源码seatunnel-engine-server下的CoordinatorService、JobMaster、CheckpointManager、TaskExecutionService、DefaultSlotService等与配置文件config/seatunnel.yaml、config/hazelcast.yaml你可以按需深入每一个组件的内部实现。赞分享数据工程大数据批处理流处理【免费下载链接】seatunnelSeaTunnel is a next-generation super high-performance, distributed, massive data integration tool.项目地址https://gitcode.com/gh_mirrors/sea/seatunnel点击查看免费下载相关推荐SeaTunnel EngineZeta引擎全解析SeaTunnel 原生执行引擎的架构设计与实战入门SeaTunnel EngineZeta引擎全解析SeaTunnel 原生执行引擎的架构设计与实战入门 SeaTunnel Engine 是 SeaTun数据集成ETL大数据批处理流处理变更数据捕获SeaTunnel核心引擎深度剖析Zeta Engine vs Flink vs SparkSeaTunnel核心引擎深度剖析Zeta Engine vs Flink vs Spark 本文深度解析了Apache SeaTunnel项目的三种核心执行数据集成ETL大数据批处理流处理变更数据捕获SeaTunnel 执行引擎选型指南SeaTunnel Engine (Zeta)、Flink 与 Spark 的对比与实战配置SeaTunnel 执行引擎选型指南SeaTunnel Engine Zeta 、Flink 与 Spark 的对比与实战配置 SeaTunnel 支持多种执数据集成ETL大数据批处理流处理变更数据捕获上一篇QtUnblockNeteaseMusic解锁网易云音乐的终极完整指南下一篇IntelliJ IDEA 教程开源项目贡献指南与 IDE 配置终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
