企业官网建设流程全解析

SeaTunnel Engine（Zeta）三种部署模式详解：Local、混合集群与分离集群实战指南

【免费下载链接】seatunnelSeaTunnel is a multimodal, high-performance, distributed, massive data integration tool.项目地址: https://gitcode.com/GitHub_Trending/se/seatunnel

SeaTunnel Engine（Zeta 引擎）是 SeaTunnel 自研的分布式数据集成引擎，本文以官方部署文档 docs/zh/engines/zeta/deployment.md 为核心，系统讲解其支持的本地模式（Local）、混合集群模式（Hybrid Cluster）和分离集群模式（Separated Cluster）三种部署形态的架构差异、适用场景、完整配置参数与集群启停操作。读完本文，你将能够根据业务规模与稳定性要求选择合适的部署模式，并独立完成从下载安装包、配置seatunnel.yaml/hazelcast*.yaml/ JVM 参数，到启动集群、提交与管理作业的完整闭环。

一、部署模式总览：三种模式如何选择

SeaTunnel Engine 基于 Hazelcast IMDG 实现集群管理，支持三种部署模式，每种模式在进程模型、职责划分和高可用能力上各不相同。

官方选型建议：优先分离集群模式

官方文档明确建议使用分离集群模式（separated-cluster-deployment.md）。原因在于混合集群模式下 Master 节点要同步运行任务，当任务规模较大时会影响 Master 节点的稳定性；一旦 Master 宕机或心跳超时，会触发 Master 切换，而 Master 切换会导致所有正在运行的任务进行容错恢复，进一步加重集群负载。

分离集群模式下 Master 的负载很小，拥有更多资源用于作业调度、任务容错、指标监控以及 REST API 服务，稳定性更高；同时 Worker 节点不存储 IMap 数据，即使 Worker 负载高或宕机，也不会导致 IMap 数据重新分布。

分离集群的最小化部署规划

初次部署可按以下节点规模规划（来自分离集群文档的部署建议）：

单个 Master 节点可以正常启动和运行，但不具备高可用能力。若需 HA，Master 至少部署 2 个：默认backup-count: 1要求至少 2 个 Master 节点才能存放 IMap 备份副本，否则单个 Master 宕机后集群无法自愈。

二、Local 模式部署：最轻量的作业运行方式

Local 模式下不需要部署集群，系统会在提交作业的进程中启动 SeaTunnel Engine（Zeta）服务来运行作业，作业完成后进程退出。该模式下只需将安装包拷贝到目标服务器，如需调整作业运行 JVM 参数，可修改$SEATUNNEL_HOME/config/jvm_client_options文件（对应仓库 config/jvm_client_options）。

Local 模式的限制

按官方文档，Local 模式有以下限制：

1. 不支持任务的暂停、恢复；
2. 不支持获取任务列表查看；
3. 不支持通过命令取消作业，只能通过 Kill 进程的方式终止任务。

但每个任务由独立进程控制，不会出现任务之间相互影响的情况，适合对任务稳定性有强烈要求的场景。

提交作业命令

$SEATUNNEL_HOME/bin/seatunnel.sh --config $SEATUNNEL_HOME/config/v2.batch.config.template -e local

其中-e local指定以本地（embedded）模式运行，v2.batch.config.template是仓库自带的批处理作业配置模板，见 config/v2.batch.config.template。

配置 Local 模式的 JVM 参数

Local 模式支持两种设置 JVM 参数的方式：

1. 将 JVM 参数添加到$SEATUNNEL_HOME/config/jvm_client_options文件中。注意：该文件中的 JVM 参数会应用到所有使用seatunnel.sh提交的作业，包括 Local 模式和集群模式；
2. 启动时通过-D临时指定，例如：

$SEATUNNEL_HOME/bin/seatunnel.sh --config $SEATUNNEL_HOME/config/v2.batch.config.template -m local -DJvmOption="-Xms2G -Xmx2G"

作业运维

Local 模式下作业在提交进程内运行，作业运行日志输出到提交进程的标准输出中，中止作业只需退出提交进程，除此之外不支持其他运维操作。

三、混合集群模式部署：Master 与 Worker 同进程

混合集群模式下，Master 服务和 Worker 服务混合在同一个进程中，所有节点都可以运行作业并参与选举成为 Master，即 Master 节点也在同时运行同步任务。在该模式下，IMap（保存任务状态信息、为任务容错提供支持）数据会分布在所有节点中。

混合模式的部署流程与分离模式大部分一致，主要差异在于：所有节点使用同一份 config/seatunnel.yaml 和 config/hazelcast.yaml，统一通过seatunnel-cluster.sh启动，无需区分角色。

部署步骤

1. 下载安装包：参考 下载和制作 SeaTunnel 安装包；
2. 配置SEATUNNEL_HOME：在/etc/profile.d/seatunnel.sh中写入环境变量：

export SEATUNNEL_HOME=${seatunnel install path} export PATH=$PATH:$SEATUNNEL_HOME/bin

3. 配置 JVM 选项：修改$SEATUNNEL_HOME/config/jvm_options（对应 config/jvm_options），或在启动时通过seatunnel-cluster.sh -DJvmOption="-Xms2G -Xmx2G"临时指定；
4. 配置seatunnel.yaml与hazelcast.yaml（详见第四、五节）；
5. 启动节点：

mkdir -p $SEATUNNEL_HOME/logs ./bin/seatunnel-cluster.sh -d

日志写入$SEATUNNEL_HOME/logs/seatunnel-engine-server.log。

四、分离集群模式部署：官方推荐的 HA 方案

分离集群模式下，Master 服务和 Worker 服务分离，每个服务单独一个进程。Master 节点只负责作业调度、RESTful API、任务提交等，IMap 数据只存储在 Master 节点中；Worker 节点只负责任务的执行，不参与 Master 选举，也不存储 IMap 数据。

在所有 Master 节点中，同一时间只有一个 Master 处于 Active 状态，其余处于 standby 状态。当前 Master 宕机或心跳超时后，会从其他 Master 节点中选举出新的 Active 节点。

启动 Master 节点

Master 节点使用-r master参数启动，对应 config/jvm_master_options 与 config/hazelcast-master.yaml：

mkdir -p $SEATUNNEL_HOME/logs ./bin/seatunnel-cluster.sh -d -r master

日志写入$SEATUNNEL_HOME/logs/seatunnel-engine-master.log。

启动 Worker 节点

Worker 节点使用-r worker参数启动，对应 config/jvm_worker_options 与 config/hazelcast-worker.yaml：

mkdir -p $SEATUNNEL_HOME/logs ./bin/seatunnel-cluster.sh -d -r worker

日志写入$SEATUNNEL_HOME/logs/seatunnel-engine-worker.log。

角色专属的 JVM 参数

Master 与 Worker 的 JVM 参数分别在jvm_master_options与jvm_worker_options中配置，官方示例（16 GB 堆，大规模场景建议 32 GB）：

# JVM Heap -Xms16g -Xmx16g # JVM Dump -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/seatunnel/dump/zeta-server # Metaspace -XX:MaxMetaspaceSize=2g # G1GC -XX:+UseG1GC

分离模式下配置参数的角色生效范围

分离集群模式一个关键特点是：seatunnel.yaml中部分参数只在特定角色上生效，官方文档明确标注了每个参数的生效范围，汇总如下：

注意：如果 Master 和 Worker 进程在同一个机器上启动，它们会共用同一份seatunnel.yaml，此时各角色服务会自动忽略不属于自己的配置项。

五、核心配置详解：seatunnel.yaml 全参数说明

SeaTunnel Engine 的集群功能均在 config/seatunnel.yaml 中配置，这些选项在源码 ServerConfigOptions.java 中有完整定义，仓库默认配置示例见seatunnel-engine/seatunnel-engine-common/src/main/resources/seatunnel.yaml。以下逐项说明。

5.1 IMap 数据备份数（backup-count）

SeaTunnel Engine 基于 Hazelcast IMDG 实现集群管理，集群的状态数据（作业运行状态、资源状态）存储在 Hazelcast IMap 中，并分布存储在所有节点上。Hazelcast 对 IMap 数据分区存储，每个分区可指定备份数量，因此无需 Zookeeper 等外部服务即可实现集群 HA。

backup-count定义同步备份数量：设置为 1 时，分区的备份放置在一个其他成员上；设置为 2 时放置在两个其他成员上。官方建议值为max(1, min(5, N/2))，其中 N 为集群节点数（分离模式下为 Master 节点数）。

seatunnel: engine: backup-count: 1 # 其他配置

5.2 Slot 配置（slot-service）

Slot 数量决定集群节点可以并行运行的任务组数量。一个任务需要的 Slot 个数公式为N = 2 + P（P 为任务配置的并行度）。默认情况下 Slot 个数为动态（不限制个数），建议设置为节点 CPU 核心数的 2 倍——这也是dynamic-slot: false且未设置slot-num时的默认值。

动态 Slot（默认）：

seatunnel: engine: slot-service: dynamic-slot: true # 其他配置

静态 Slot：

seatunnel: engine: slot-service: dynamic-slot: false slot-num: 20

5.3 检查点管理器（checkpoint）

与 Flink 一样，SeaTunnel Engine 支持 Chandy–Lamport 算法，可实现无数据丢失和无重复的数据同步。三个核心参数：

• interval：两个检查点之间的间隔（毫秒）。若作业配置文件的env中配置了checkpoint.interval，以作业配置为准；
• timeout：检查点超时时间（毫秒）。超时未完成则触发检查点失败、作业失败。若作业配置了checkpoint.timeout，以作业配置为准；
• min-pause：连续检查点之间的最小暂停时间（毫秒），防止检查点频繁触发。

seatunnel: engine: backup-count: 1 print-execution-info-interval: 10 slot-service: dynamic-slot: true checkpoint: interval: 300000 timeout: 10000 min-pause: 5000

checkpoint storage：检查点是一种容错恢复机制。检查点定时触发，每个 Task 将自己的状态信息（如读取 Kafka 时读到的 offset）上报给检查点线程，由该线程写入分布式存储（或共享存储）。当任务失败自动容错恢复，或通过seatunnel.sh -r恢复之前暂停的任务时，会从检查点存储加载对应作业的状态信息并恢复。若集群节点数大于 1，检查点存储必须是分布式存储或共享存储，以保证任意节点挂掉后其他节点仍能加载到任务状态。存储配置详见 Checkpoint Storage，仓库默认配置使用本地文件系统（fs.defaultFS: file:///tmp/），生产环境应替换为 HDFS/OSS 等共享存储。

5.4 历史作业过期配置

每个已完成作业的信息（状态、计数器、错误日志）都存储在 IMap 对象中，随作业数量增加内存会持续增长直至溢出。history-job-expire-minutes用于控制历史作业信息的保留时间，单位分钟，默认 1440（一天）：

seatunnel: engine: history-job-expire-minutes: 1440

此外，SeaTunnel 会在分布式 Map 中短暂保留终态作业状态（tombstone）再统一删除，保留窗口由state-cleanup-delay-ms控制，默认 60000 毫秒。保留 tombstone 可让晚到的异步回调读到终态而非缺失状态；设置为 0 会恢复更激进的清理策略，但会缩小终态竞态的保护窗口：

seatunnel: engine: state-cleanup-delay-ms: 60000

5.5 类加载器缓存模式（classloader-cache-mode）

此配置主要解决不断创建和销毁类加载器导致的资源泄漏问题。如果遇到 metaspace 空间溢出相关异常，可以尝试启用。启用后 SeaTunnel 在作业完成时不会释放对应类加载器，以便被后续作业复用——当作业使用的 Source/Sink 连接器类型不多时效果更佳。默认值为true：

seatunnel: engine: classloader-cache-mode: true

5.6 作业调度策略（job-schedule-strategy）

当资源不足时，作业调度策略有两种模式：

1. WAIT：等待资源可用；
2. REJECT：拒绝作业，默认值。

seatunnel: engine: job-schedule-strategy: WAIT

注意：当dynamic-slot: true时，job-schedule-strategy: WAIT会失效并被强制修改为REJECT，因为动态 Slot 下资源不设限，WAIT 策略没有意义。

5.7 Coordinator Service

CoordinatorService 提供每个作业从 LogicalDag → ExecutionDag → PhysicalDag 的生成流程，并最终创建作业的 JobMaster 进行作业的调度执行和状态监控。两个参数：

• core-thread-num：CoordinatorService 线程池核心线程数量；
• max-thread-num：同时可执行的最大作业数量。

coordinator-service: core-thread-num: 30 max-thread-num: 1000

5.8 作业指标分区数量（job-metrics-partition-count）

该参数用于控制在 Hazelcast IMap 中存储运行作业指标时使用的分区数量（在 Worker 节点上无效）：

• 默认值：1（单个 key，向后兼容）；
• 用法：增加该值可将指标分布到多个分区，在大量任务同时更新指标时减少锁竞争。

seatunnel: engine: job-metrics-partition-count: 4

官方给出的调优参考：当任务数量超过约 20,000 时，增加分区数量可显著提高性能；分区数量约 1,000–2,000 往往在减少锁竞争和最小化开销之间提供最佳平衡。注意：设置过大反而会引入额外的分布与合并开销；且该配置必须在作业启动前完成，作业启动后更改可能导致指标键不匹配，建议修改后重启 SeaTunnel。

5.9 仓库默认配置参考

仓库自带的 config/seatunnel.yaml 给出了生产可用的基线配置，包含classloader-cache-mode、history-job-expire-minutes、backup-count、queue-type、print-execution-info-interval、slot-service、checkpoint以及 HTTP 服务（Web UI）等完整条目，可作为自定义配置的起点。

六、IMap 持久化配置：让集群状态跨重启存活

默认情况下 IMap 信息只存储在内存中。即使设置了副本数（如 2，代表每个数据同时存储在 2 个不同节点），一旦某个节点宕机，IMap 数据也会在其余节点自动补充到设置的副本数；但当所有节点都被停止后，IMap 数据会丢失——集群节点再次启动后，所有之前正在运行的任务都会被标记为失败，需要用户手工通过seatunnel.sh -r指令恢复。

要解决这个问题，可将 IMap 数据持久化到外部存储（HDFS、OSS 等）。这样即使所有节点都被停止，IMap 数据也不丢失，集群节点再次启动后所有之前正在运行的任务都会被自动恢复。

MapStore 持久化配置位于hazelcast*.yaml的map.engine*段，关键参数：

• type：IMap 持久化类型，目前仅支持hdfs；
• namespace：区分不同业务的数据存储位置，如 OSS 存储桶名称；
• 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 且集群只有一个节点，可配置为使用本地文件（fs.defaultFS: file:///）：

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

使用 OSS 时需确保lib目录下有如下 JAR（官方文档明确列出）：

aliyun-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-shade-hadoop3-uber-${seatunnel.shade.hadoop.version}-${seatunnel.shade.version}.jar

其中seatunnel-shade-hadoop3-uber是 Hadoop 客户端的 shaded（包重定位）版本，所有第三方类被重定位到org.apache.seatunnel.shade.*下，避免与 SeaTunnel 自身依赖产生类路径冲突；版本号格式为${library.version}-${seatunnel.shade.version}（例如3.1.4-3.0.0），具体以发行包中实际 JAR 文件名为准。

关于 running-job metrics 的持久化说明

engine_runningJobMetrics保存的是高频运行时指标快照。即使通过map.engine*配置了map-store，它也会被有意排除在持久化 IMAP 存储之外，以避免仅用于可观测性的状态导致 WAL 持续膨胀。Engine 重启后，running-job metrics 不会延续重启前的 snapshot，而是由后续 report 重新构建。

七、网络配置：hazelcast*.yaml 详解

所有 SeaTunnel Engine 网络相关配置都在hazelcast*.yaml文件中：混合模式使用 config/hazelcast.yaml，分离模式 Master 使用 config/hazelcast-master.yaml、Worker 使用 config/hazelcast-worker.yaml。

7.1 集群名称（cluster-name）

SeaTunnel Engine 节点使用cluster-name判断另一个节点是否与自己属于同一集群。若两个节点集群名称不同，引擎将拒绝服务请求。

7.2 网络与发现机制

基于 Hazelcast，一个 SeaTunnel Engine 集群由运行 Engine 服务器的集群成员组成，成员通过发现机制自动加入形成集群。集群形成后，成员间通信始终通过 TCP/IP 进行，与发现机制无关。SeaTunnel Engine 使用以下发现机制：

TCP：官方建议在独立集群中使用的方式，可配置为完整的 TCP/IP 集群，详细说明见 tcp.md。混合模式示例（对应 config/hazelcast.yaml）：

hazelcast: cluster-name: seatunnel network: join: tcp-ip: enabled: true member-list: - hostname1 port: auto-increment: false port: 5801 properties: hazelcast.logging.type: log4j2

在分离集群模式下，Master 和 Worker 使用不同的端口。Master 节点网络配置（config/hazelcast-master.yaml 为基础，生产环境按需放开 REST API 并将member-list替换为实际主机名）：

hazelcast: cluster-name: seatunnel network: rest-api: enabled: true endpoint-groups: CLUSTER_WRITE: enabled: true DATA: enabled: true join: tcp-ip: enabled: true member-list: - master-node-1:5801 - master-node-2:5801 - worker-node-1:5802 - worker-node-2:5802 port: auto-increment: false port: 5801 properties: hazelcast.heartbeat.failuredetector.type: phi-accrual hazelcast.heartbeat.interval.seconds: 2 hazelcast.max.no.heartbeat.seconds: 180 hazelcast.heartbeat.phiaccrual.failuredetector.threshold: 10 hazelcast.heartbeat.phiaccrual.failuredetector.sample.size: 200 hazelcast.heartbeat.phiaccrual.failuredetector.min.std.dev.millis: 100

Worker 节点网络配置（config/hazelcast-worker.yaml）：

hazelcast: cluster-name: seatunnel network: join: tcp-ip: enabled: true member-list: - master-node-1:5801 - master-node-2:5801 - worker-node-1:5802 - worker-node-2:5802 port: auto-increment: false port: 5802 properties: hazelcast.heartbeat.failuredetector.type: phi-accrual hazelcast.heartbeat.interval.seconds: 2 hazelcast.max.no.heartbeat.seconds: 180 hazelcast.heartbeat.phiaccrual.failuredetector.threshold: 10 hazelcast.heartbeat.phiaccrual.failuredetector.sample.size: 200 hazelcast.heartbeat.phiaccrual.failuredetector.min.std.dev.millis: 100

上述 heartbeat 相关properties配置了 phi-accrual 故障检测器的参数，用于更快、更准确地识别节点故障并触发 Master 切换，在分离集群的 HA 场景中尤为关键。Hazelcast 还提供其他服务发现方法，可参考官方 Hazelcast Network 文档。

八、客户端配置与作业提交

8.1 配置 SeaTunnel Engine 客户端

所有客户端配置都在hazelcast-client.yaml（对应 config/hazelcast-client.yaml）中：

• cluster-name：客户端必须与 SeaTunnel Engine 具有相同的cluster-name，否则引擎拒绝客户端的请求；
• network.cluster-members：需要将所有 SeaTunnel Engine 服务器节点的地址添加到这里（分离模式下为所有 Master 节点地址）。

hazelcast-client: cluster-name: seatunnel properties: hazelcast.logging.type: log4j2 network: cluster-members: - master-node-1:5801 - master-node-2:5801

8.2 安装客户端与提交作业

客户端安装很简单：将 SeaTunnel Engine 节点上的$SEATUNNEL_HOME目录复制到客户端节点，并按服务器节点方式配置SEATUNNEL_HOME（写入/etc/profile.d/seatunnel.sh，内容同前文）。集群部署完成后，可通过以下两种方式提交和管理作业：

1. SeaTunnel Engine 客户端命令行：参考 提交和管理作业；
2. REST API：SeaTunnel Engine 提供 REST API 用于提交作业，详见 REST API V2。

8.3 从源码验证配置体系

以上所有配置项均在 ServerConfigOptions.java 中定义，仓库同时提供了服务端默认配置（seatunnel-engine/seatunnel-engine-common/src/main/resources/seatunnel.yaml）和客户端测试用配置（seatunnel-engine/seatunnel-engine-client/src/test/resources/seatunnel.yaml），读者可对照源码与配置文件交叉验证每个参数的类型、默认值与解析逻辑，便于在生产环境做精细调优。

九、总结：部署模式选择矩阵

无论选择哪种模式，seatunnel.yaml（引擎功能）、hazelcast*.yaml（网络与 IMap 持久化）、hazelcast-client.yaml（客户端）与各jvm_*_options文件构成了完整的部署配置体系。建议按官方建议优先采用分离集群模式，并根据节点规模设置backup-count、Slot 数量与检查点参数，同时在多节点环境下务必配置分布式/共享的检查点存储与 IMap 持久化，才能获得真正的容错与高可用能力。

【免费下载链接】seatunnelSeaTunnel is a multimodal, high-performance, distributed, massive data integration tool.项目地址: https://gitcode.com/GitHub_Trending/se/seatunnel