Forem: Apache SeaTunnel

A Practical DataOps Development Framework Based on WhaleStudio’s Three Layer Model

Apache SeaTunnel — Fri, 10 Apr 2026 09:37:01 +0000

As data platforms evolve from simply “getting jobs to run” to achieving stable and reliable operations, the challenges teams face also begin to shift. Early on, the focus is mainly on whether tasks execute successfully. As scale increases, the concerns move toward access control, clarity of data pipelines, manageability of changes, and the ability to recover from failures.

This is where DataOps starts to show its real value. It is not just a set of tool usage guidelines, but an engineering methodology that spans development, scheduling, and governance. Using WhaleStudio’s development management framework as an example, this article distills a set of practical standards drawn directly from real production experience.

The Three Layer Development Framework

In complex data platforms, managing everything through a single dimension quickly becomes insufficient as the system grows. WhaleStudio introduces a three-layer structure of Project, Workflow, and Task, which decouples governance, orchestration, and execution, creating clear boundaries for system management.

Project as the Governance Boundary

The project layer is the most fundamental part of the system, yet it is also the most commonly misused. In many teams, projects are treated merely as a way to organize directories. This approach often leads to problems later, such as unclear permissions, resource misuse, and ambiguous ownership.

In a well-designed system, projects should serve as governance boundaries. Everything related to access control should be scoped within a project, including user permissions, data source access, script resources, alerting strategies, and Worker group configurations.

A practical rule is simple. Whenever there is a scenario where certain users should not be able to view or modify specific resources, isolation must be enforced at the project level rather than relying on conventions or manual processes.

Workflow as the Business Pipeline

If projects define who can do what, workflows define how work is organized.

A workflow is essentially a DAG that represents dependencies between tasks. In a typical data pipeline, workflows connect data ingestion, SQL processing, script execution, and sub-process calls into a complete business flow.

Beyond orchestration, workflows also handle scheduling concerns such as dependency management, parallel and sequential execution strategies, retry mechanisms, and backfill logic. This means a workflow is not just a representation of execution logic, but also a key part of system stability design.

In practice, workflows should be treated as traceable and replayable pipelines rather than just collections of tasks.

Task as the Smallest Execution Unit

Under workflows, tasks represent the smallest unit of execution and have the most direct impact on system stability.

Common task types include SQL, Shell, Python, and data integration jobs. Despite their differences, they should follow consistent design principles such as traceability, retry capability, and recoverability.

In many production scenarios, issues do not originate from the scheduler itself, but from the tasks. For example, non-idempotent SQL logic, scripts without proper error handling, or strong dependencies on external systems can amplify risks during retries or backfills. Establishing standards at the task level is therefore critical to overall system reliability.

Once the responsibilities of the three layers are clearly defined, the next step is to manage permissions and design workflows effectively to prevent the system from becoming unmanageable as it scales.

Principles for Data Access and Workflow Design

As teams grow and business logic becomes more complex, access control and workflow design become key factors affecting both efficiency and stability. Without consistent standards, systems can quickly become chaotic.

Organize Projects by Business Domain

Projects should primarily be structured around business domains such as sales, risk control, or finance. This aligns naturally with organizational structure and helps clarify ownership.

When cross-team collaboration is required, resource sharing should be implemented through authorization mechanisms rather than placing everything into a single project. While the latter may seem convenient initially, it often leads to uncontrolled permissions over time.

Separate Responsibilities in Permission Design

Permissions should never default to giving everyone full access. Roles such as development, testing, operations, and auditing should be clearly separated, each with its own scope of authority.

This approach reduces the risk of accidental changes and helps standardize release processes, making system changes more controlled.

Balance Isolation and Reuse

Resource management must balance isolation with reuse. Data sources, scripts, resource pools, and Worker groups should be isolated by default to avoid unintended interference.

When reuse is necessary, it should be achieved through controlled authorization rather than duplicating configurations. This reduces maintenance overhead and avoids inconsistencies.

Resolve Permission Differences Through Projects

Whenever permission differences exist, they must be handled through project-level isolation. For example, if certain datasets should only be accessible to specific users, this must be enforced through system mechanisms rather than informal agreements.

Although this principle seems straightforward, it is often overlooked, leading to loss of control over the permission system.

Once the permission model is stable, workflow design becomes the key factor in maintainability.

Control Workflow Size

As the number of tasks grows, placing everything into a single workflow leads to rapidly increasing maintenance costs and higher risk during changes.

In practice, workflows should be split based on data layers or business domains, such as ODS, DWD, DWS, and ADS. The number of nodes within a workflow should remain within a manageable range to avoid excessive complexity.

Upgrade Governance When Complexity Increases

When the number of workflows grows too large or directory structures become unmanageable, relying on labels or folders is no longer sufficient. At this point, governance should be elevated to a higher level, such as introducing additional project segmentation.

This is not merely structural optimization, but an evolution of governance strategy.

Once design principles are clear, implementation should align with team size. There is no single solution that fits all teams.

Implementation Strategies for Different Team Sizes

DataOps does not have a universal solution. The right approach depends on team size and system complexity.

Large Teams with Layered Isolation

In large or complex data warehouse environments, multiple business domains, permission boundaries, and data pipelines coexist. In such cases, data warehouse layers such as ODS, DWD, DWS, and ADS should be mapped to different projects and workflows.

Dependencies across projects and workflows must be clearly defined. Impact analysis tools should be used for global governance to ensure changes do not introduce cascading failures.

Medium Sized Teams with Balanced Design

For medium-sized teams, the goal is to maintain stability while avoiding unnecessary complexity.

Projects should not be overly fragmented, and workflows should not be split excessively. Instead, different scheduling cycles such as daily and monthly jobs can be connected through well-defined dependencies.

The focus at this stage should be on unified scheduling strategies and resource pool management rather than introducing overly complex governance frameworks.

Small Teams with Fast Execution

For small teams or early-stage projects, the priority is to establish a working delivery pipeline.

A single workflow can be used to handle core business processes, supported by naming conventions, alerting mechanisms, and backfill strategies to ensure baseline quality. As complexity increases, the system can gradually evolve toward more fine-grained structures.

This approach keeps costs under control while avoiding overly heavy design in the early stages.

Conclusion

From Project to Workflow to Task, WhaleStudio’s three-layer model provides a clear division of responsibilities. Projects define governance boundaries, workflows manage business orchestration, and tasks handle execution.

With well-designed permission models and properly structured workflows, systems can remain stable and controllable even as complexity grows.

The essence of DataOps lies not in the tools themselves, but in building an engineering system that can evolve sustainably. Only when permissions, resources, and execution logic are governed under a unified framework can a data platform truly support long-term business growth.

(5)When Your Data Warehouse Breaks Down, It’s Probably a Naming Problem
(4)Why Your ADS Layer Always Goes Wild and How a Strong DWS Layer Fixes It
- (3) Key Design Principles for ODS/Detail Layer Implementation: Building the Data Ingestion Layer as a “Stable and Operable” Infrastructure
(I) A Complete Guide to Building and Standardizing a Modern Lakehouse Architecture: An Overview of Data Warehouses and Data Lakes

Coming Next

Part 7 Scheduling design best practices

You Don’t Apply to Become an ASF Member, You Grow Into It

Apache SeaTunnel — Fri, 10 Apr 2026 09:11:30 +0000

Very few people set “becoming an ASF Member” as a clear goal.

Not because it lacks appeal, but because there is no application process and no defined path. It is more of an outcome, something that happens after sustained contributions are naturally recognized within a community.

Fan Jia followed exactly that kind of path.

Recently, he was invited to join the Apache Software Foundation as a Member. Taking this opportunity, we had an in-depth conversation with him. More than a recognition of achievement, the discussion felt like a reflection on his journey—from data integration, to open source participation, to system design and community understanding—tracing how an engineer gradually arrives at this point.

Starting from Data Integration

Fan Jia’s current work focuses on data integration, particularly in areas such as data synchronization, Change Data Capture, and data infrastructure. As he describes it, his day-to-day work can be distilled into one core objective: enabling data to flow reliably across different systems.

In practice, this is far more complex than it sounds. It involves synchronizing data between heterogeneous systems, handling schema evolution, and ensuring stability in complex production environments. Alongside this, he has been actively contributing to the Apache SeaTunnel community over the long term.

What stands out is that his starting point was not open source itself, but a set of concrete and persistent engineering problems. Those problems became the foundation for his later involvement in open source.

How He Got Into Open Source

When asked how he first got involved in open source, his answer was straightforward—it started with his job. After joining WhaleOps, he became involved in the development, maintenance, and partial architectural design of Apache SeaTunnel.

In the early stage, his contributions were similar to those of most engineers, focusing on solving specific issues such as fixing bugs and improving features. Over time, however, his attention shifted toward system design and how the project could run reliably across broader and more diverse scenarios.

This transition did not happen overnight. It emerged gradually through continuous involvement. As his focus moved from isolated problems to the system as a whole, his role evolved along with it.

From User to Maintainer

He describes this phase as a shift in perspective and responsibility.

As a user, the focus is on whether a feature exists and whether it meets immediate needs. As a maintainer, the concerns expand to system stability, backward compatibility, adaptability across different use cases, and the real experience of community users.

At the same time, the sense of responsibility becomes more concrete. Writing code is no longer just about completing a task. It becomes part of maintaining a system that runs in real production environments, making every technical decision more deliberate.

Once this shift in perspective happens, the truly complex problems begin to surface.

A Memorable Technical Challenge

During his time contributing to SeaTunnel, one of the most memorable challenges was building the Zeta engine from scratch.

This was not about solving a single isolated issue, but about tackling a combination of complex system-level problems. At the execution model level, the engine needed to support both batch and stream processing, balancing throughput and latency while avoiding bottlenecks under high concurrency.

From a concurrency perspective, multi-threaded execution introduced challenges such as race conditions, deadlocks, and unpredictable execution order. These issues are often difficult to reproduce and tend to surface only after prolonged runtime.

In terms of resource management, real production workloads involve long-running tasks and large data volumes. Memory control, thread pool isolation, and backpressure handling become critical. Out-of-memory errors are especially dangerous, as they can impact not only individual tasks but the stability of the entire service process.

For stability and recoverability, the system must guarantee no data loss, avoid uncontrolled duplication, and correctly restore state after failures or restarts. This typically requires integrating checkpointing and state management mechanisms.

Overall, this was not a single technical problem, but a full-scale systems engineering challenge.

These experiences also shaped how he understands collaboration in open source.

The Most Important Skill in Open Source

When asked what matters most in an open source community, his answer was patience.

A pull request in open source rarely gets merged immediately. It usually goes through multiple stages, including initial implementation, community review, several rounds of revision, CI validation, and documentation updates. Along the way, various issues can arise. Without patience, it is easy to give up midway.

However, consistently pushing through these details is exactly what defines high-quality contributions.

This understanding of the process is also reflected in his advice to newcomers.

Advice for New Contributors

For developers just getting started in open source, he believes the most important things are curiosity and the willingness to act.

Often, the biggest barrier is not technical difficulty, but simply not getting started. Once you take the first step—submitting a small PR or joining a discussion—everything else tends to follow naturally.

He also emphasizes the importance of expressing your own ideas and even questioning existing designs. Open source communities are inherently open environments, and everyone starts as a beginner.

As participation deepens, feedback from the community becomes more visible.

The Moment He Became an ASF Member

When he learned that he had become an ASF Member, his first reaction was excitement and happiness.

Unlike many achievements, this is not something you apply for. It is a recognition from the community based on long-term contributions, which makes it especially meaningful.

At the same time, he sees it not just as an honor, but as an increase in responsibility.

What This Role Means

In his view, being an ASF Member is fundamentally about responsibility.

It is not only about continuing technical contributions, but also about fostering a healthy community, helping new contributors grow, and participating in higher-level governance. It also means being accountable to users, ensuring that projects run reliably in real-world environments.

As his role evolves, so does his understanding of the community.

Understanding The Apache Way

He summarizes his understanding of The Apache Way in one phrase: Community Over Code.

The long-term success of an open source project depends not only on its technology but also on whether it maintains open and transparent decision-making, encourages contributors from diverse backgrounds, and builds governance based on consensus.

These factors ultimately determine the vitality of a project.

With this perspective, he approaches projects from a broader viewpoint.

How He Sees SeaTunnel

In his view, SeaTunnel’s strengths lie in several areas.

From an architectural standpoint, it supports a multi-engine model, allowing users to choose the most suitable execution engine for different scenarios. From an ecosystem perspective, it provides a rich set of connectors, enabling integration with various databases, data lakes, and messaging systems.

In terms of capabilities, CDC is a key strength, supporting both data change capture and schema evolution, making the system more adaptable to complex production environments.

At the same time, despite these capabilities, SeaTunnel maintains a relatively lightweight design, allowing users to adopt and use it at a lower cost.

These insights come from long-term hands-on experience.

How Open Source Changed Him

Open source has had a significant impact on his career, especially in how he approaches problems.

Within a company, systems are usually designed around specific business needs. In open source, however, solutions must consider much broader and more general use cases, which pushes engineers to make longer-term architectural decisions.

Collaborating with developers from different companies and backgrounds also expands one’s technical perspective.

One Sentence About Open Source

When asked to summarize open source in one sentence, he said

Open source is not just about sharing code, it is a process where developers and communities grow together

It may sound simple, but when viewed in the context of his journey, it is less a conclusion and more a natural outcome.

From solving concrete data problems, to participating in system design, to thinking about how projects run reliably across different scenarios, and eventually to engaging in community collaboration and consensus building, there is no clear boundary between these stages.

It is a continuous process where perspective gradually expands through doing the work.

Becoming an ASF Member is not the end of this journey, but a milestone along the way. It reflects recognition of past contributions and signals greater responsibility ahead.

If there is one deeper takeaway from this experience, it may not be a specific technology or a single project, but a more enduring capability

The ability to keep investing in uncertainty and to continue doing the right thing even when there is no immediate reward

About Apache SeaTunnel
Apache SeaTunnel is an easy-to-use, ultra-high-performance distributed data integration platform that supports real-time synchronization of massive amounts of data and can synchronize hundreds of billions of data per day stably and efficiently.

Welcome to fill out this form to be a speaker of Apache SeaTunnel: https://forms.gle/vtpQS6ZuxqXMt6DT6 :)

Why do we need Apache SeaTunnel?
Apache SeaTunnel does everything it can to solve the problems you may encounter in synchronizing massive amounts of data.
Data loss and duplication
Task buildup and latency
Low throughput
Long application-to-production cycle time
Lack of application status monitoring

Apache SeaTunnel Usage Scenarios
Massive data synchronization
Massive data integration
ETL of large volumes of data
Massive data aggregation
Multi-source data processing

Features of Apache SeaTunnel
Rich components
High scalability
Easy to use
Mature and stable

How to get started with Apache SeaTunnel quickly?
Want to experience Apache SeaTunnel quickly? SeaTunnel 2.1.0 takes 10 seconds to get you up and running.
https://seatunnel.apache.org/docs/2.1.0/developement/setup

How can I contribute?
We invite all partners who are interested in making local open-source global to join the Apache SeaTunnel contributors family and foster open-source together!

Submit an issue:
https://github.com/apache/seatunnel/issues

Contribute code to:
https://github.com/apache/seatunnel/pulls

Subscribe to the community development mailing list :
dev-subscribe@seatunnel.apache.org
Development Mailing List :
dev@seatunnel.apache.org

Join Slack:
https://join.slack.com/t/apacheseatunnel/shared_invite/zt-3uouszk3m-PtLLNyZsJVqE5Gb6gn24mA

Join us now!❤️❤️

What Happened in Apache SeaTunnel? This March You Shouldn’t Miss

Apache SeaTunnel — Fri, 10 Apr 2026 07:06:02 +0000

Hey there! The March 2026 report is here. The Apache SeaTunnel community has been incredibly active. A total of 26 contributors participated, version 2.3.13 was released, five new connectors were added, and major improvements were made across the core engine, file connectors, CDC, and Transform modules. More than 20 bugs were also fixed.

On top of that, infrastructure upgrades were rolled out. Whether you’re an enterprise or individual user, it’s a great time to upgrade, explore new features, and stay in sync with the community momentum.

Reporting period March 1, 2026 to March 30, 2026

1. Release Overview

Version	Release Date	Notes
2.3.13	March 14, 2026	Released this month with 50+ new features and 20+ bug fixes

Download
https://seatunnel.apache.org/download

2. Key Updates in Version 2.3.13

2.1 New Connectors

Connector	Description	PR
HugeGraph Sink	Adds support for Apache HugeGraph	#10002
DuckDB	Introduces DuckDB as both Source and Sink	#10285
Lance	Adds support for writing to Lance datasets	#9894
AWS DSQL	Adds AWS DSQL Sink connector	#9739
IoTDB	Adds Source and Sink support for IoTDB 2.x	#9872

2.2 Core Engine Enhancements

Module	Feature	PR
Zeta Engine	Supports arbitrarily nested arrays and map types	#9881
Zeta Engine	Adds min-pause checkpoint configuration	#9804
Zeta Engine	Introduces REST API to inspect pending queue details	#10078
Flink	Adds support for Flink 1.20.1	#9576
Flink	Enables schema evolution for CDC sources	#9867
Metrics	Adds sink committed metrics and commit rate calculation	#10233

2.3 File Connector Improvements

Connector	Enhancement	PR
HdfsFile	Enables parallel reading for large files	#10332
LocalFile	Supports chunked parallel reading for CSV, TEXT, JSON files	#10142
Parquet	Adds logical partitioning support	#10239
HdfsFile and LocalFile	Adds sync_mode=update support	#10437, #10268
HBase	Supports time-range scanning	#10318
Hive	Supports automatic failover across multiple Metastore URIs	#10253

2.4 CDC Improvements

Feature	Description	PR
Maxwell Canal Debezium	Optimizes JSON format and supports merging update_before and update_after	#9805
Kafka	Adds Protobuf deserialization support via Schema Registry wire format	#10183
Kafka	Injects record timestamp as EventTime metadata	#9994
MySQL CDC	Optimizes wait time for schema evolution	#10040

2.5 Transform Enhancements

Transformation	Feature	PR
Multimodal Embeddings	Adds support for multimodal embeddings	#9673
RegexExtract	Introduces regex-based extraction transform	#9829
SQL to Paimon	Adds support for MERGE INTO syntax	#10206

3. Bug Fixes in Version 2.3.13

Module	Issue	PR
CSV Reader	Fixes parsing failure caused by empty first column	#10383
ClickHouse	Improves batch parallel reads by replacing limit offset with last batch sort value	#9801
PostgreSQL	Adds support for TIMESTAMP_TZ type	#10048
Redis	Fixes cluster mode bug and adds end-to-end tests	#9869
MongoDB	Improves writer close logic	#10051
Elasticsearch	Optimizes resource cleanup for Scroll API	#10124
MySQL CDC	Optimizes schema evolution wait time	#10040

4. Community Highlights

Contributors in March 2026

Rank	Contributor	PR Count	Role
🏅	@zhangshenghang	6	Contributor
🥈	@yzeng1618	4	Contributor
🥈	@davidzollo	4	Contributor
🥈	@chl-wxp	4	Contributor
🥉	@liunaijie	3	Contributor
🥉	@dybyte	3	Contributor
🥉	@ricky2129	3	Contributor
🥉	@corgy-w	3	Contributor
	@zooo-code	2	Contributor
	@kuleat	2	Contributor
	@LeonYoah	2	Contributor
	@OmkarK-7	1	Contributor
	@icekimchi	1	Contributor
	@assokhi	1	Contributor
	@Sephiroth1024	1	Contributor
	@Best2Two	1	Contributor
	@ic4y	1	Contributor
	@misi1987107	1	Contributor
	@CosmosNi	1	Contributor
	@chocoboxxf	1	Contributor
	@xiaochen-zhou	1	Contributor
	@qingzheguo-flash	1	Contributor
	@rameshreddy-adutla	1	Contributor
	@CNF96	1	Contributor
	@MuraliMon	1	Contributor
	@ocean-zhc	1	Contributor

A total of 51 PRs were merged in March. Huge thanks to all 26 contributors.

Full contributor list
https://github.com/apache/seatunnel/graphs/contributors

Infrastructure Updates

End-to-end test Docker images migrated to the seatunnelhub repository
JDK Docker images upgraded
CI timeout optimization with Kafka set to 140 minutes and Kudu to 60 minutes
Added Metalake support for managing data source metadata

5. Recommendations for Enterprises

Upgrade Guidance

Production environments are strongly recommended to upgrade to version 2.3.13
This release includes more than 50 new features and over 20 bug fixes

Features to Watch

New connectors including HugeGraph, DuckDB, IoTDB, AWS DSQL, and Lance
Improved large file processing with parallel chunked reads in HdfsFile and LocalFile
Enhanced CDC capabilities including schema evolution and multi-format Kafka support
Improved observability with new sink committed metrics
Support for Flink 1.20.1

Notes

Some connector APIs have changed, so reviewing the upgrade documentation is recommended
Using the seatunnelhub image repository is strongly encouraged

6. Key Metrics

Metric	March Data
Releases	1 release (2.3.13)
New Connectors	5+
Feature Enhancements	50+
Bug Fixes	20+
Contributors	50+

7. What’s Coming Next

Further optimization of CDC performance
More cloud-native data source integrations
Improved metrics and monitoring capabilities

Compiled and edited by the SeaTunnel Community

(5)When Your Data Warehouse Breaks Down, It’s Probably a Naming Problem

Apache SeaTunnel — Fri, 03 Apr 2026 06:59:33 +0000

As a data warehouse grows, the first thing that tends to get out of control is not the data itself—but naming. Naming conventions may seem like a minor detail, but they directly determine whether data is easy to find, understand, and maintain. As the fifth article in the Data Lakehouse Design and Practice series, this article starts from real-world usage and summarizes core methods for table and field naming. By combining layered prefixes, unified terminology (word roots), and cycle encoding, table names become self-explanatory. Together with metric naming and governance processes, this helps build a clear and collaborative data system.

Goals and Methods of Naming Conventions: Make Table Names Self-Explanatory and Teams Work Automatically

In a data warehouse system, naming conventions are not just about form—they are foundational infrastructure that directly impacts collaboration efficiency and data quality. A good naming system has one core goal: make the table name itself carry enough information so that people can understand what the table is, where it comes from, and how to use it—without needing extra documentation. Ideally, a table name should be “readable at a glance” and include key information such as data layer, owning team, business domain, subject domain, core object meaning, and update cycle or data scope. When these elements are systematically encoded into table names, data discovery, metric interpretation, troubleshooting, and team handovers all become significantly more efficient, reducing communication costs.

A naming system is essentially a “word root system” that standardizes business language. For example, the same business object must use the same term consistently across tables (e.g., avoid mixing “rack” and “shelf”). Similarly, metric naming should follow unified rules—for instance, all ratio-type metrics should use the _rate suffix, avoiding ambiguity from mixing terms like ratio, percent, or rt.

Layer prefixes must be strictly standardized. They allow users to immediately identify the data layer and purpose of a table: ods_ for source-aligned data, dwd_ for detailed standardized data, dws_ for aggregated data, ads_ for application-facing outputs, and dim_ for shared dimensions. These prefixes are not just naming conventions—they directly reflect the data architecture.

Another often overlooked but critical aspect is encoding update cycles or data scope into table names. For example, _1d represents the last day, _td means up to today, and _7d means the last seven days. This prevents confusion between tables with the same name but different time semantics, reducing the risk of metric misuse.

At the asset management level, table types must be clearly distinguished. Production tables are long-term assets, intermediate tables serve only processing workflows and should have retention policies, and temporary tables are for one-time validation and must not enter production pipelines. Prefixes like mid_ and tmp_ help prevent data asset pollution at the source.

Finally, naming conventions must be integrated with governance processes. Any new table or field must include complete metadata such as owner, field definitions, metric definitions, update frequency, dependencies, and lifecycle. Tables without such metadata may be usable in the short term but will almost certainly become technical debt in the long run. In practice, it is best to standardize templates first—ensuring key fields like layer, domain, and cycle are strictly consistent—while allowing limited flexibility in non-critical parts.

Table Naming Conventions: Templates, Cycle Encoding, and Examples

In practice, table naming should follow a structured template to ensure completeness and consistency. A general template can be defined as {layer}_{dept}_{biz_domain}_{subject}_{object}_{cycle_or_range}, where each component has a clear role: layer indicates data level, dept indicates ownership, biz_domain defines the business domain, subject represents analytical abstraction, object defines the entity or behavior, and cycle_or_range specifies the time scope.

Cycle and range encoding is especially important. Common patterns include _1d (last day), _td (to date), _7d or _30d (last N days). Additional markers can distinguish data types or update modes, such as d for daily snapshots, w for weekly data, i for incremental tables, f for full tables, and l for slowly changing tables. These conventions allow users to quickly understand temporal semantics.

For example, in the aggregation layer, dws_asale_trd_byr_subpay_1d represents buyer-level, staged payment transactions aggregated over the last day, while dws_asale_trd_itm_slr_hh represents hourly aggregation at the seller-item level. Although long, such names are highly informative and readable.

Dimension tables follow a separate convention, using the dim_ prefix and a {scope}_{object} structure, such as dim_pub_area (public area dimension) or dim_asale_item (item dimension), emphasizing cross-domain reuse.

Intermediate tables should be tightly bound to their target tables, typically named as mid_{target_table}_{suffix}, such as mid_dws_xxx_01. Temporary tables must use the tmp_ prefix and are strictly limited to development or validation, never entering production dependencies. For manually maintained data, tables in the DWD layer can explicitly include manual, such as dwd_trade_manual_client_info_l.

Field and Metric Naming Conventions: Rules, Structure, and Examples

At the field level, naming must be strictly standardized. All field names should use lowercase with underscores—camelCase is not allowed. Readability should take priority over brevity, and consistent naming must be maintained for the same semantic meaning.

Partition fields should be unified globally—for example, dt for date, hh for hour, and mi for minute—with fixed formats. This improves development efficiency and avoids confusion across tables.

Field suffixes should clearly indicate meaning: _cnt for counts, _amt or _price for monetary values (choose one consistently), and boolean fields should use the is_ prefix and never be nullable. These conventions allow users to infer data types and meanings at a glance.

NULL handling must also follow consistent rules. Typically, dimension fields use -1 for unknown values, while metric fields use 0 to indicate no occurrence. This prevents NULL propagation in aggregations and improves data stability.

Metric naming should be structured as a combination of business qualifier, time qualifier, aggregation method, and base metric. For example, trade_amt represents transaction amount, install_poi_cnt represents installation point count, and pay_succ_rate represents payment success rate. Aggregation methods should use fixed terms like sum, avg, max, and min, avoiding inconsistent alternatives like “total.”

A full example from fields to metrics: in the detail layer, an incremental order table might be named dwd_trade_order_i, containing fields such as order ID, user ID, payment amount, order status, and partition keys. In the aggregation layer, dws_trade_user_pay_1d summarizes user-level payments over the last day, including metrics like payment success count, total payment amount, and success rate. Finally, in the application layer, a table like ads_fin_kpi_board_d provides business-facing dashboards with KPIs such as GMV, refund amount, net revenue, and number of paying users.

By standardizing naming across tables, fields, and metrics, a data warehouse can achieve clear semantics, consistent structure, and efficient collaboration. While such conventions may introduce some overhead initially, they are essential for scalability and team coordination in the long term.

Earlier Posts in This Series：
- (4)Why Your ADS Layer Always Goes Wild and How a Strong DWS Layer Fixes It
- (3) Key Design Principles for ODS/Detail Layer Implementation: Building the Data Ingestion Layer as a “Stable and Operable” Infrastructure
- (I) A Complete Guide to Building and Standardizing a Modern Lakehouse Architecture: An Overview of Data Warehouses and Data Lakes
Next Post:

- (6) DataOps Development Standards and Best Practices

Growing with the Community: Zhang Shenghang’s Path to Apache SeaTunnel PMC Member

Apache SeaTunnel — Fri, 03 Apr 2026 02:55:16 +0000

🎉 Hi Community—more exciting news! Zhang Shenghang has been invited to join the Apache SeaTunnel PMC in recognition of his outstanding contributions—well deserved!

Over the years, Zhang has been highly active in the Apache SeaTunnel community. From improving code quality, refining documentation, to engaging with the community and mentoring newcomers, his presence has been everywhere. He consistently embraces the Apache Way, contributing with dedication and passion to the growth of the project.

We took this opportunity to conduct an in-depth interview with him. Covering his background, open source journey, PMC role, and thoughts on community development and culture, this conversation offers a closer look at his story and his enthusiasm for open source.

Personal Background & Open Source Journey

Could you briefly introduce yourself and how you entered the big data and open source space? Name: Zhang Shenghang GitHub: zhangshenghang

When did you start contributing to Apache SeaTunnel, and what was the motivation?
I started contributing to Apache SeaTunnel in June 2024. Initially, I was using DataX, a classic standalone data integration tool. However, it lacks service-oriented and distributed capabilities, which creates limitations in large-scale data synchronization scenarios. That’s when I came across Apache SeaTunnel as a more comprehensive solution.
What key contributions or features have you worked on in SeaTunnel?
He has contributed to multiple core features and improvements, including adding a pending queue feature for SeaTunnel Engine task scheduling, enabling Kafka Protobuf format support, introducing Kerberos testing in e2e workflows, implementing a new resource scheduling algorithm in SeaTunnel Engine, adding TTL support for HBase Sink, introducing API-based log retrieval, fixing Flink source 100% busy issues, supporting the Typesense connector, enabling default value substitution for configuration variables, fixing Doris custom SQL execution issues, correcting Kafka consumer offset auto-commit logic, and resolving RabbitMQ checkpoint issues in Flink mode.

Open Source Contributions & Growth

Which contribution or experience impressed you the most?
What impressed me most was not just submitting a PR, but the full process—from discovering a problem, analyzing it, discussing solutions with the community, to finally implementing and validating the fix. Issues involving engine scheduling, resource allocation, and Flink stability often look simple on the surface but are deeply tied to framework mechanisms and runtime behavior. Solving them requires both deep code understanding and close collaboration.
What is the most important skill in open source collaboration?
All are important, but if I had to choose one, it would be the ability to collaborate continuously. Technical skills are foundational, but communication is equally critical—open source is not just about writing code, but explaining context, design decisions, and trade-offs clearly so others can understand.
What advice would you give to beginners in open source?
Don’t overestimate the difficulty. You don’t need to start with massive features or deep architectural changes. Fixing a bug, improving documentation, adding tests, or optimizing small features are all valuable contributions.

Becoming a PMC Member

Congratulations on becoming a PMC Member! What was your first reaction?
Thank you. My first reaction was both excitement and a strong sense of responsibility. It’s recognition of past contributions, but also a reminder that a PMC Member is not just a contributor, but a community builder.
What does becoming a PMC Member mean to you and the community?
To me, it represents recognition of long-term contributions, collaboration ability, and responsibility. Personally, it means thinking beyond individual modules and considering the project’s overall development, governance, and ecosystem. For the community, more PMC Members mean more people willing to take responsibility and drive sustainable growth.
How important is the Apache Way to open source success?
It emphasizes “Community Over Code.” A project succeeds not just because of good code, but because of an open, transparent, and sustainable collaboration culture.

SeaTunnel Community Development

What key milestones has SeaTunnel gone through?
SeaTunnel has evolved from a data synchronization tool into a more comprehensive data integration platform, expanding across connectors, orchestration, engines, and observability. The maturation of SeaTunnel Engine is a major turning point, enabling stronger unified execution capabilities. Additionally, increased community activity and internationalization have significantly boosted its impact.
How do you see SeaTunnel’s position and future?
SeaTunnel is building a unique position by balancing rich connectors, strong engine capabilities, scalability, and enterprise readiness. Compared to traditional tools, it fits modern data infrastructure better; compared to heavyweight platforms, it remains flexible and extensible. It has strong potential to become a leading global open source data integration project.
What are your future plans as a PMC Member?
I plan to focus on improving SeaTunnel Engine, scheduling, resource management, and system stability; strengthening connectors and production readiness; and helping new contributors onboard faster through issue guidance, PR reviews, and knowledge sharing.

Personal Growth & Open Source Culture

How has open source impacted your career and growth?
Professionally, it has exposed me to real-world complex problems and high-standard collaboration environments. Personally, it has deepened my understanding of collaboration, responsibility, and long-term thinking. Open source has shaped not only my technical skills but also my mindset and working style.
How would you summarize the spirit of open source in one sentence?
Open source is about collaboratively creating, improving, and sharing technology in an open and inclusive way for the benefit of everyone.

Rethinking ClassLoader Governance in Apache SeaTunnel

Apache SeaTunnel — Fri, 03 Apr 2026 02:45:04 +0000

Recently, while diving into the Apache SeaTunnel Zeta Engine codebase, I followed the ClassLoader thread and conducted a relatively systematic review.

Overall, the current design already has a clear foundational structure, especially the centralized management approach of ClassLoaderService, which is actually quite rare among similar systems 👍.

Here, I try to take a different perspective—starting from “ClassLoader governance in long-running runtimes”—to summarize some observations and outline a possible evolution path. These may not be entirely accurate, but are intended to spark discussion.

From “Usable” to “Governable”

Apache SeaTunnel already supports well: multi-connector coexistence and dynamic loading and execution. From a “functional availability” perspective, the mechanism works. But if we move one step further and ask: can ClassLoaders have a controllable lifecycle and verifiable reclamation? the evaluation criteria begin to change.

Observations (Runtime-Oriented)

1. The Semantic Gap Between “Release” and “Close”

Currently, releaseClassLoader() removes cache entries and performs some thread-level cleanup when the reference count drops to zero, but it does not explicitly call URLClassLoader.close(). For example: DefaultClassLoaderService.releaseClassLoader() (no close call observed) and DefaultClassLoaderService.close() mainly clears internal cache structures. This raises a noteworthy point: JAR handle release depends on GC timing, and in long-running scenarios or on certain platforms (such as Windows), files may not be released promptly. 👉 This is closer to “logical release” rather than “end of resource lifecycle”.

2. Class Loading Boundaries Can Still Change at Runtime

In some paths, dependencies are still injected into the current ClassLoader via addURL, such as: reflective calls to addURL in AbstractPluginDiscovery, and plugin dependency injection into the current loader in Flink execution paths. This leads to an interesting phenomenon: class loading boundaries are not only defined by loader structure, but also influenced by runtime behavior. While not problematic for a single job, under scenarios like repeated jobs in the same process or switching plugin combinations, boundaries may accumulate “historical residue”.

3. Some Residual Surfaces Are Not Fully Closed

There are multiple TCCL usage patterns in the codebase (synchronous / asynchronous / cross-thread), and some paths show: TCCL not restored in finally, or inconsistent baselines during cross-thread restoration. For example: TCCL usage in cooperative workers within TaskExecutionService, and asymmetric restoration in some operations (such as source / restore). Additionally, some typical ClassLoader retention points are not yet uniformly governed, such as JDBC Driver registration (e.g., TDengine-related implementations) and connectors directly setting TCCL without restoring it.

A Possible Evolution Path (For Reference)

Based on these observations, I’ve outlined a progressive governance path that avoids large-scale refactoring and can be implemented in phases.

Phase 1: Close the ClassLoader Lifecycle

Key ideas: explicitly call close() on URLClassLoaders created by SeaTunnel at the appropriate time, and define clear ownership—“who creates, who closes”. This shifts from “GC-dependent release” to “controlled release”.

Phase 2: Stabilize Loading Boundaries

Goals: avoid runtime addURL where possible, and determine the full classpath before loader creation. This ensures consistent behavior of the same loader over time.

Phase 3: Consolidate Common Residual Points

Standardize patterns such as: wrapping TCCL with try-with-resources, pairing JDBC Driver registration and deregistration, and clearly assigning ClassLoader ownership to threads and ThreadLocal. This turns implicit references into manageable resources.

Phase 4: Introduce Verifiable Reclamation

As an enhancement: use WeakReference + ReferenceQueue to track loaders, or expose simple runtime metrics (e.g., number of live loaders). The goal is not absolute precision, but the ability to reasonably judge whether resources have been released.

Why This Matters

These issues rarely surface in short-lived tasks. But in scenarios such as long-running engine nodes, repeated task scheduling, or frequent plugin switching, these boundary issues accumulate over time. The results may include Metaspace growth, inability to replace JARs, and occasional class conflicts.

One-Sentence Summary

From “class isolation” to “governable ClassLoaders with verifiable reclamation.”

The above reflects my current understanding and organization of the topic. Some points may not be entirely accurate—feedback and real-world scenarios are very welcome 🙌. If the community is interested, this could evolve into a more general and reusable infrastructure capability.

Appendix: Code References

Some code locations noted during analysis (not exhaustive): DefaultClassLoaderService (release/close), AbstractPluginDiscovery (addURL), Flink starter execution paths (plugin injection), TaskExecutionService (TCCL usage), various operations (source/restore), and connectors (Iceberg / Paimon / TDengine, etc.).

From Apache SeaTunnel to ASF Member: A Story of Long-Term Commitment

Apache SeaTunnel — Fri, 27 Mar 2026 03:15:17 +0000

Recently, after internal discussions, the Apache Software Foundation invited several PMC Members from the Apache SeaTunnel project to become ASF Members—one of the highest honors within the foundation. Among them is Wang Hailin.

Congratulations to @wang Hailin on becoming an ASF Member! As a key contributor to the SeaTunnel community, this recognition is not only a personal milestone, but also a moment of pride for the entire community.

Over the years, he has remained deeply involved in the community: from refining documentation to improving code, from participating in technical discussions to helping newcomers. His contributions can be seen across almost every corner of the project. Beyond SeaTunnel, he has also been actively contributing to multiple ASF projects, consistently practicing the Apache Way advocated by the foundation. It is this steady, long-term dedication that has led to this important recognition.

To mark the occasion, the community conducted an in-depth interview with him. This article is structured into five sections—personal background, open-source journey, the path to ASF Member, SeaTunnel community development, and open-source culture—to give a closer look at his growth, his experiences in open source, and the passion and persistence behind his contributions.

Personal Background & Open Source Journey

Q1: Could you briefly introduce yourself and how you got into big data and open source?

A: Hey guys, I’m Wang Hailin, and my GitHub ID is hailin0. I mainly work on data infrastructure, with a focus on data integration, data synchronization, and data platforms.

Outside of work, I enjoy engaging with open-source communities—sharing practical experience and exchanging ideas around data platforms and integration technologies.

My entry into big data and open source is closely tied to my earlier work experience. While working on systems like data development platforms and performance monitoring, I frequently dealt with data ingestion and synchronization challenges, which required exploring various data integration tools.

That’s when I came across SeaTunnel. What stood out to me was its extensible architecture—it supports a wide range of data sources and complex synchronization scenarios, making it well-suited for enterprise use. This sparked my interest, and I gradually started contributing to the community. Over time, through continuous contributions and discussions, I became one of the core contributors.

Q2: When did you start contributing to SeaTunnel, and what was the trigger?

A: It started from a practical need at work. At the time, I was building a data platform and needed a reliable data integration tool. During that evaluation process, I discovered SeaTunnel.

Back then, the project wasn’t as mature as it is today, but its architecture left a strong impression on me—especially the plugin-based Connector system and the flexible data synchronization model.

I began using SeaTunnel in real-world scenarios, and gradually got involved in contributing. Starting with small fixes and bug patches, I later participated in more feature development and community discussions, eventually becoming a long-term contributor.

Q3: What key areas or features have you contributed to in SeaTunnel?

A: My contributions mainly fall into a few areas.

Early on, I worked on Connector development and improvements. For a data integration platform, the Connector ecosystem is fundamental—it determines which data sources and systems the platform can connect to.

As I became more involved, I also contributed to framework-level and infrastructure work, such as improving the E2E testing system and refining the logging framework to make the project more robust and standardized.

Later, as I gained a deeper understanding of the synchronization engine, I started working on CDC (Change Data Capture) capabilities, including CDC read/write and DDL synchronization. In real production environments, schema changes (DDL) are unavoidable. If a system cannot handle schema evolution properly, data pipelines can easily break.

Overall, these efforts are driven by a single goal: to make SeaTunnel not just a data synchronization tool, but a reliable data integration infrastructure for enterprise environments.

Open Source Contributions & Growth

Q4: Which contribution or experience left the deepest impression on you?

A: One experience that stands out is working on DDL support in CDC scenarios.

At first glance, DDL may seem like a simple SQL parsing problem. But in a data synchronization system, it must flow correctly through the entire pipeline: from Source capturing the event, to passing it through the data stream, to executing schema changes on the Sink.

The real challenge lies in maintaining consistency between DDL and data changes. In practice, synchronization jobs run concurrently across multiple nodes, so DDL events must maintain a consistent order throughout the distributed pipeline.

This requires tight integration with state management mechanisms like Checkpoint and Savepoint, ensuring that after recovery or restart, DDL and data events remain in the correct order.

When you combine all these factors, DDL handling becomes a system-level challenge involving distributed data flow, state consistency, and multi-system compatibility.

This work took quite a long time and involved extensive discussions with other contributors. It’s one of the more complex aspects of many data synchronization systems, and we aimed to make SeaTunnel more reliable for enterprise real-time scenarios.

Q5: What do you think is the most important skill in open source collaboration?

A: I would say communication and collaboration are critical.

Technical skills are the foundation, but many decisions in open source are made through discussion and consensus. Being able to clearly express your ideas, understand others’ perspectives, and move toward agreement is essential.

Another important factor is patience and long-term commitment. Open source is not a short-term effort—it requires sustained involvement.

Q6: What advice would you give to newcomers in open source?

A: Start small. For example:

Fix a bug
Improve documentation
Submit a small feature enhancement

This helps you get familiar with the codebase and development workflow.

Also, participate in discussions. Even asking questions or joining simple conversations helps you understand the project’s design.

Open source is a long journey—you don’t need to aim for big features at the beginning. What matters more is understanding the architecture, not just the code.

Many core contributors grow over years—from users to contributors, and eventually to maintainers.

For me, the biggest gain from open source is not a specific piece of code, but the opportunity to collaborate with developers from different companies and backgrounds. That experience is incredibly valuable.

Becoming an ASF Member

Q7: What was your first reaction when you were invited to become an ASF Member?

A: I was surprised and very grateful.

ASF Membership is not something you apply for—it comes through nomination and voting by existing members. So it represents recognition from the community for long-term contributions.

Q8: How closely is this achievement tied to your work in SeaTunnel?

A: Very closely.

The SeaTunnel community gave me many opportunities to grow—from contributing code to participating in community governance. Through this process, I gradually learned how Apache communities operate.

It’s not just about technical contributions, but also collaboration and governance, which are all important factors in becoming an ASF Member.

Q9: What does becoming an ASF Member mean to you?

A: To me, it represents responsibility.

It’s not only recognition of past contributions, but also a commitment to continue contributing to the Apache community—helping projects grow, supporting new projects entering the ecosystem, and promoting open-source culture.

Q10: How do you see the importance of the Apache Way?

A: The Apache community emphasizes “Community Over Code.”

A successful project needs not only strong technology, but also a healthy community, including:

Open and transparent decision-making
Consensus-driven governance
Encouraging participation from diverse contributors
Continuously welcoming new contributors

These are key reasons why Apache projects can succeed in the long run.

SeaTunnel Community Development

Q11: What are the key milestones in SeaTunnel’s growth?

A: Several milestones stand out:

Entering the Apache Incubator
Unifying APIs and introducing the Zeta engine
Graduating as a Top-Level Project (TLP)
Rapid iteration in the 2.3.x series with increasing stability

SeaTunnel was open-sourced in 2017, entered the Apache Incubator in 2021, and became a TLP in 2023. This journey reflects not only technical evolution but also the maturation of community governance.

Q12: How do you see SeaTunnel’s positioning in data integration?

A: In recent years, the demand for efficient data movement has grown significantly, and synchronization scenarios have become more complex.

SeaTunnel aims to be a high-performance, extensible platform that supports diverse data integration needs across different use cases.

It already supports multiple data sources, batch processing, real-time synchronization, and CDC.

Looking ahead, I believe it will continue to evolve in areas such as:

Expanding the connector ecosystem
Strengthening data transformation capabilities
Improving fault handling
Enhancing ecosystem integration

Open Source Culture & Personal Growth

Q13: How has open source influenced your career?

A: It has influenced me in two major ways.

First, it broadened my technical perspective. In company projects, decisions are often driven by specific business needs. In open source, designs must work across different use cases, systems, and organizations. This leads to a more comprehensive understanding of system design.

Second, it deepened my understanding of software engineering and collaboration. In open source, a feature goes through idea proposal, design discussion, review, and iteration before merging. This process emphasizes design and communication, not just coding.

Working with developers from different countries and backgrounds also brings fresh perspectives.

For me, the biggest gain is the opportunity to collaborate in an open environment and solve problems with talented engineers.

Q14: How would you summarize the spirit of open source in one sentence?

A: Based on my experience, the most valuable aspect of open source is that it provides a space for long-term participation and growth.

I started as a user, using tools to solve problems. Then I began contributing small fixes, and gradually got involved in feature development and core system design.

Looking back, it’s a journey from user → contributor → maintainer.

In a company, knowledge often stays within a team. In open source, your work can be seen, used, and improved by many others. As the project grows, so do the people involved.

So if I had to summarize it in one sentence:

Open source is not just about sharing code—it’s about growing together with the community.

Apache SeaTunnel Performance Tuning: How to Set JVM Parameters the Right Way

Apache SeaTunnel — Fri, 27 Mar 2026 03:13:13 +0000

As a high-performance distributed data integration platform, properly tuning JVM parameters for Apache SeaTunnel is essential if you want better throughput, lower latency, and stable execution.

So how should you tune JVM parameters?
In this article, we’ll walk through where to configure them, how precedence works, the key parameters to focus on, and some practical tuning strategies.

1. Configuration File Locations

SeaTunnel manages JVM parameters through configuration files under $SEATUNNEL_HOME/config/. Depending on the deployment role, there are four main files:

File Name	Scope	Default Example
`jvm_options`	Hybrid mode (`master_and_worker`), where Master and Worker run in the same process	`-Xms2g -Xmx2g -XX:+UseG1GC`
`jvm_master_options`	Dedicated Master node, responsible for scheduling and state management (no computation)	`-Xms2g -Xmx2g`
`jvm_worker_options`	Dedicated Worker node, responsible for data reading, transformation, and writing (main memory consumer)	`-Xms2g -Xmx2g`
`jvm_client_options`	Client side (`seatunnel.sh`), used to parse configs and submit jobs	`-Xms256m -Xmx512m`

2. Parameter Precedence

Understanding parameter precedence is critical when troubleshooting.

SeaTunnel loads JVM parameters in the following order, and later ones override earlier ones (for example, the last -Xmx wins):

Environment variable JAVA_OPTS
Loaded first. You can define it in system env variables or in config/seatunnel-env.sh.
Configuration files (config/jvm_*_options)
Loaded next, and override anything set in JAVA_OPTS.
Command-line parameters (-DJvmOption)
Loaded last, with the highest priority.

Example:
If JAVA_OPTS="-Xmx4g", the config file sets -Xmx2g, and the startup command includes -DJvmOption="-Xmx8g", then the effective value will be 8g.

3. Key JVM Tuning Parameters

3.1 Heap Memory

Heap memory is the most important part of JVM tuning. It directly determines how much data SeaTunnel can process in parallel without running into OOM (Out Of Memory).

-Xms: Initial heap size
-Xmx: Maximum heap size

Best practices:

Worker nodes:
It’s strongly recommended to set -Xms and -Xmx to the same value (for example, -Xms8g -Xmx8g).
This avoids runtime heap resizing, reduces performance fluctuations, and helps prevent memory fragmentation.
Master nodes:
Memory requirements are relatively low. In most cases, 2g–4g is sufficient. Increase it only if the cluster handles many jobs.
Client:
The default 512m is usually enough. If your job configuration (SQL/JSON) is very large (tens of thousands of lines), consider increasing it to 1g or more.

3.2 Off-Heap Memory

Important note:
You may notice that the actual physical memory (RSS) used by SeaTunnel is significantly larger than the -Xmx value.

Why?
SeaTunnel uses Netty for network communication, which relies heavily on off-heap (direct) memory for zero-copy data transfer.
In addition, thread stacks (-Xss * number of threads), Metaspace, and JVM overhead also consume non-heap memory.
Risk:
If the machine runs out of physical memory, the Linux OOM Killer may terminate the process (usually a Worker).

Recommendations:

Reserve memory for the OS:
On an 8GB machine, keep -Xmx below 5g, leaving around 3GB for off-heap memory and the operating system.
Docker/Kubernetes:
The container memory limit must be larger than -Xmx plus estimated off-heap usage.
A common rule is to set it to about 1.5× -Xmx.

3.3 Garbage Collector

SeaTunnel’s Zeta engine recommends using G1GC, which provides more predictable pause times for large heaps.

-XX:+UseG1GC: Enable G1 GC (enabled by default)
-XX:MaxGCPauseMillis=200: Target maximum GC pause time (in milliseconds)
- Real-time workloads: If latency is critical, you can lower this value (e.g., 100). Keep in mind this may increase GC frequency and slightly reduce overall throughput.
- Batch workloads: The default 200ms is usually a good balance.
-XX:InitiatingHeapOccupancyPercent=45:
Heap occupancy threshold that triggers concurrent GC.
If you observe frequent Full GC, try lowering it (e.g., 40) so GC starts earlier.

3.4 Metaspace

Metaspace stores class metadata. SeaTunnel consumes metaspace when loading connectors.

-XX:MaxMetaspaceSize: Maximum metaspace size

The default (2g) is usually sufficient.
If you encounter java.lang.OutOfMemoryError: Metaspace, increase it accordingly.

3.5 Troubleshooting

When OOM happens, heap dumps are extremely helpful for diagnosis.

-XX:+HeapDumpOnOutOfMemoryError: Generate a heap dump automatically on OOM
-XX:HeapDumpPath=/tmp/seatunnel/dump/: Path to store dump files

Notes:

Make sure the disk has enough space (at least larger than -Xmx)
In container environments, ensure the path is mounted to the host; otherwise, dumps will be lost after restart

4. JDK Compatibility

Recommended versions: Java 8 (JDK 1.8) or Java 11
These are the most thoroughly tested versions.
Java 17+:
Generally supported, but due to the module system introduced in Java 9+, you may encounter InaccessibleObjectException caused by restricted reflection access.

Solution:
If this happens, add --add-opens options in jvm_options, for example:

--add-opens java.base/java.lang=ALL-UNNAMED
--add-opens java.base/java.util=ALL-UNNAMED

5. Production Tuning Scenarios

Scenario 1: Large-Scale Batch Processing

Characteristics: Large data volume (TB scale), throughput is the priority

Worker recommendation:

-Xms8g -Xmx8g
-XX:+UseG1GC
-XX:ParallelGCThreads=8

Notes:

If the source reads data too quickly, memory may build up
Besides increasing heap size, consider:
- Limiting read_limit.rows_per_second
- Adjusting parallelism

Scenario 2: Real-Time CDC Synchronization

Characteristics: Long-running jobs, latency-sensitive, relatively stable memory usage

Worker recommendation:

-Xms4g -Xmx4g
-XX:+UseG1GC
-XX:MaxGCPauseMillis=100

Notes:

Checkpoint frequency also affects memory usage (state backend caching)
If memory pressure is high, consider increasing checkpoint.interval

Scenario 3: Low-Memory Deployment (e.g., 4GB)

Risk: High chance of being killed by the OS

Worker recommendation:

-Xmx2560m

Allocate about 2.5GB to heap
Leave the remaining 1.5GB for:
- Off-heap memory (Netty)
- OS
- Other processes

6. How to Verify Your Configuration

After starting SeaTunnel, run:

jps -v | grep SeaTunnel

Example output:

12345 SeaTunnelServer ... -Xms8g -Xmx8g -XX:+UseG1GC ...

Make sure your parameters (e.g., -Xmx8g) appear at the end of the list (or are not overridden by later ones).

7. Docker / Kubernetes-Specific Configuration

7.1 Recommended Approach: Container-Aware Memory

In Kubernetes, memory is typically controlled via resources.limits.memory.
Instead of hardcoding -Xmx, it’s better to use percentage-based settings so the JVM can adapt automatically.

Example:

env:
  - name: JAVA_OPTS
    value: "-XX:+UseContainerSupport -XX:MaxRAMPercentage=70.0 -XshowSettings:vm"

Explanation:

-XX:+UseContainerSupport: Allows JVM to detect container limits
-XX:MaxRAMPercentage=70.0: Sets heap to 70% of container memory

Why 70%?
The remaining 30% is needed for:

Direct memory (Netty)
Metaspace
Thread stacks
JVM overhead

7.2 Resource Limits

Make sure Kubernetes resource settings align with JVM needs.

Example: Want 8GB heap

JVM: 70%
K8s limit: 8 / 0.7 ≈ 11.5GB → set to 12Gi

resources:
  requests:
    memory: "12Gi"
    cpu: "4"
  limits:
    memory: "12Gi"
    cpu: "4"

7.3 Overriding Default Config

If default config files already define memory settings, they may override JAVA_OPTS.

To ensure your settings take effect:

Use command-line parameters (highest priority):

args: ["-DJvmOption=-XX:MaxRAMPercentage=70.0"]

Mount custom config files via ConfigMap

7.4 Common Pitfalls

❌ Setting limits.memory = 4Gi and -Xmx4g
→ No space left for non-heap memory → process will be killed
❌ Not setting requests
→ Pod may be scheduled on a node without enough memory

Code References

jvm_options
seatunnel-cluster.sh
values.yaml

Why Your ADS Layer Always Goes Wild and How a Strong DWS Layer Fixes It

Apache SeaTunnel — Fri, 20 Mar 2026 10:13:54 +0000

In a data warehouse system, the DWS and ADS layers mark the critical boundary between “data modeling” and “data delivery.” The former carries shared aggregation and metric reuse capabilities, determining the stability and efficiency of the data system; the latter is oriented toward specific consumption scenarios, directly impacting business delivery efficiency and user experience.

If the DWS layer is poorly designed, metrics will be repeatedly produced in the ADS layer, ultimately leading to inconsistent definitions and siloed data; if the ADS layer runs out of control, it can even backfire on the shared layer, forming unmanageable data assets. Therefore, a healthy data system must establish a clear boundary and evolution mechanism between “shared foundation” and “flexible delivery.”

As the fourth article in the Data Lakehouse design and practice series, this piece systematically summarizes the core design principles of the DWS/ADS delivery layer, including methods for shared aggregation and subject-wide table modeling, metric definition frameworks, delivery layer strategies, and lifecycle governance practices. It also addresses common issues, helping teams build a highly reusable, governable, and sustainable data delivery system.

Why DWS Must Be “Thick Enough”

In many team data systems, the DWS layer is often underestimated or even weakened, resulting in all requirements being pushed to the ADS layer. In the short term, this seems flexible, but over time it quickly spirals out of control.

The core positioning of DWS is as a shared aggregation and reuse layer. It is not designed to serve a single report, but to provide a unified data foundation for multiple applications to share. If this layer is underdeveloped, every new requirement will trigger recalculation and redefinition of metrics, resulting in a bunch of incompatible results.

In practice, a healthy state is: about 70% of analytical needs can be directly fulfilled by combining DWS tables. This means most scenarios do not require creating new tables, but rather combining existing shared capabilities. This “ready-to-use” capability is the core of reuse value.

Conversely, if each department has its own ADS tables and each report has its own metric definitions, typical silo problems emerge: metrics with the same name do not match, computations are duplicated, and data cannot be aligned. Teams spend most of their time reconciling definitions instead of analyzing business.

The value of DWS lies precisely in solving these common issues. By precomputing aggregated results of high-frequency dimension combinations, building subject-wide tables, and unifying metric outputs, DWS moves dispersed computations to the offline layer. As a result, online queries no longer rely on temporary large-scale joins or full table scans, making performance and cost more controllable.

More importantly, it changes team collaboration. Metrics no longer depend on verbal agreements—they exist as data assets: with owners, definitions, lineage, and quality rules. So-called “metric disputes” essentially become “asset governance issues.”

But there is a prerequisite: DWS must be governable. If fields lack explanations, metrics lack definitions, update frequency is unclear, or quality rules are missing, this layer will become a “wide-table collection nobody dares to use,” reducing reuse rates.

Shared Aggregation and Subject-Wide Tables: Balancing Reuse and Performance

DWS design revolves around two types of tables: shared aggregation tables and subject-wide tables.

Shared aggregation tables hinge on clarity. They must clearly define aggregation granularity (e.g., daily, weekly, monthly, or cumulative), dimension combinations (e.g., time, organization, channel, category), and metric calculation scope (e.g., amount, count, or frequency). Without clear boundaries, downstream reuse becomes unreliable.

Subject-wide tables emphasize usability. They usually focus on a business domain, e.g., users, transactions, or products, flattening frequently joined dimensions in advance to reduce query complexity. Importantly, wide tables are a result-oriented form for analytics—they are not a replacement for fact tables and must be traceable back to underlying models.

A common practical problem is wide tables continually growing. To mitigate this, fields can be governed based on usage frequency: retain high-frequency fields in the main wide table, split or join low-frequency fields on demand, and regularly slim tables according to usage.

Another common pitfall is mixing different aggregation levels in the same table, e.g., daily and monthly data together. This greatly increases misuse risk and complicates maintenance. A better approach is to split tables by level or at least enforce strict naming conventions.

All these designs assume consistent dimensions exist. Core dimensions such as user, organization, channel, and time must have unified codes and definitions, otherwise cross-table reuse fails.

From a performance perspective, DWS’s core strategy is always pre-aggregation first. Reduce data scan scale via offline computation before applying indexing, partitioning, or materialized views. Otherwise, all optimizations become remedial measures.

Metric Framework: Layered Design from Atomic to Composite

If DWS solves data reuse, then the metric framework ensures definition consistency.

A governable metric system typically has three levels: atomic metrics, derived metrics, and composite metrics.

Atomic metrics are the fundamental units. They must clearly define the target, scope, filters, and time granularity. For example, “successful payment amount” must clearly count only successful payments and use the payment completion time.

Derived metrics are calculated from atomic metrics. For example, average order value = “successful payment amount / number of successful orders.” Key here: derived metrics must inherit atomic metric definitions, or bias will occur.

Composite metrics span multiple processes or business domains, e.g., conversion rate, retention, or repeat purchase. These rely heavily on a consistent dimension system and event definitions, making them the most prone to ambiguity.

To avoid confusion, every metric must have four elements: business definition, calculation formula, scope, and time granularity. This is not just documentation—it is the basis for traceability and auditability.

Metrics must also support version control. Changes to definitions cannot overwrite historical results directly; versions or effective dates should be used to prevent “historical data being rewritten.”

In terms of layering, atomic metrics should reside in DWS (or traceable to DWD), while ADS handles only lightweight combination and presentation. If ADS takes on definition duties, it quickly becomes a new “metric generation layer.”

ADS and Data Marts: Delivery for Consumption

If DWS is about accumulation, ADS is about delivery.

ADS (or DM, data marts) aims to provide data products for specific consumption scenarios, e.g., BI reports, API services, or analytical datasets. Structures here emphasize usability, not generality.

Delivery tables should follow a “one table, one scenario” principle. Field names can be closer to business semantics, and additional display, sort, or status fields can be added to improve user experience.

But one bottom line must be enforced: delivery should not invent metrics. All core metrics must come from DWS or the metric system; ADS only handles combination, formatting, and lightweight calculation. Violating this quickly returns to “one metric per report.”

Update frequency must respect business SLA. Daily, hourly, or minute-level updates directly affect compute chains and resource costs. The higher the frequency, the more careful you must be with field scale and calculation complexity.

Governance of data marts is also crucial. They can be department- or scenario-specific, but must be built on a unified dimension and metric framework. Views or semantic layers may meet variation needs, but duplicating underlying logic is not allowed.

From “Fast Delivery” to “Sustainable Evolution”

Early on, many teams experience a phase: stacking tables in ADS for fast delivery. Initially responsive, but over time, problems emerge—delivery layers balloon, shared layers hollow out, and maintenance costs soar.

A healthier model: gradually thicken the shared layer (DWS), keep the delivery layer light, and continuously recover general capabilities back to DWS.

This also implies delivery tables must support lifecycle management. Track usage frequency, retire low-value tables, or recycle general fields and metrics back to the shared layer to avoid duplication.

Ultimately, a mature data system is not “built fast,” but “used long.” Layered DWS and ADS design underpins this long-term evolution.

SeaTunnel Gravitino: Schema URL–Driven Automatic Table Structure Detection

Apache SeaTunnel — Fri, 20 Mar 2026 09:53:29 +0000

Recently, the community published an article titled “Say Goodbye to Hand-Written Schemas! SeaTunnel’s Integration with Gravitino Metadata REST API Is a Really Cool Move”, which drew strong reactions from readers, with many saying, “This is really awesome!”

The contributor behind this feature is extremely proactive, and it’s expected to be available soon (according to reliable sources, likely in version 3.0.0). To help the community better understand it, the contributor wrote a detailed article explaining the initial capabilities of the Gravitino REST API and how to use it—let’s take a closer look!

1. Background and Problems to Solve

When using Apache SeaTunnel for batch or sync tasks, if the source is unstructured or semi-structured, the source usually requires an explicit schema definition (field names, types, order).

In real production environments, this leads to several typical issues:

Tables have many fields and complex types, making manual schema maintenance costly and error-prone
Upstream table structure changes (adding fields, changing types) require corresponding updates to SeaTunnel jobs
For existing tables, simply syncing data still requires repeated metadata description, leading to redundancy

Thus, the core question is:

Can SeaTunnel directly reuse table structure definitions from an existing metadata system, instead of declaring schema repeatedly in jobs?

This feature was introduced to solve this problem.

2. Introduction to Gravitino (Relevant Capabilities)

Gravitino is a unified metadata management and access service, providing standardized REST APIs to manage and expose the following objects:

Metalake (logical isolation unit)
Catalogs (e.g., MySQL, Hive, Iceberg)
Schema / Database
Table and its field definitions

With Gravitino:

Table structures can be centrally managed
Downstream systems can dynamically fetch schema definitions via HTTP APIs
No need to maintain field information in every compute or sync job

The new capability introduced in SeaTunnel is:

Support for automatically pulling table structures via schema_url provided by Gravitino in the source schema definition.

3. Local Test Environment Setup

3.1 Prepare MySQL Environment

3.1.1 Create Target Table

Pre-create the target table test.demo_user in MySQL with the following SQL:

CREATE TABLE `demo_user` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT,
  `user_code` varchar(32) NOT NULL,
  `user_name` varchar(64) DEFAULT NULL,
  `password` varchar(128) DEFAULT NULL,
  `email` varchar(128) DEFAULT NULL,
  `phone` varchar(20) DEFAULT NULL,
  `gender` tinyint DEFAULT NULL,
  `age` int DEFAULT NULL,
  `status` tinyint DEFAULT NULL,
  `level` int DEFAULT NULL,
  `score` decimal(10,2) DEFAULT NULL,
  `balance` decimal(12,2) DEFAULT NULL,
  `is_deleted` tinyint DEFAULT NULL,
  `register_ip` varchar(45) DEFAULT NULL,
  `last_login_ip` varchar(45) DEFAULT NULL,
  `login_count` int DEFAULT NULL,
  `remark` varchar(255) DEFAULT NULL,
  `ext1` varchar(100) DEFAULT NULL,
  `ext2` varchar(100) DEFAULT NULL,
  `ext3` varchar(100) DEFAULT NULL,
  `ext4` varchar(100) DEFAULT NULL,
  `ext5` varchar(100) DEFAULT NULL,
  `created_by` varchar(64) DEFAULT NULL,
  `updated_by` varchar(64) DEFAULT NULL,
  `created_time` datetime DEFAULT NULL,
  `updated_time` datetime DEFAULT NULL,
  `birthday` date DEFAULT NULL,
  `last_login_time` datetime DEFAULT NULL,
  `version` int DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_user_code` (`user_code`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

3.1.2 Create the Table Schema to Sync

In practice, table structures might be managed centrally in components like paimon, hive, or hudi. For testing, the table schema points to the target table test.demo_user created in the previous step.

3.2 Register the Table Schema in Gravitino

Gravitino supports direct database connections and scans all tables in a database

This table is managed in Gravitino as a table under the local-mysql catalog.

Metalake: test_Metalake

3.3 Table Structure Access Explanation

Table structures in Gravitino can be accessed via the REST API:

http://localhost:8090/api/metalakes/test_Metalake/catalogs/${catalog}/schemas/${schema}/tables/${table}

In this test, the actual schema_url used is:

http://localhost:8090/api/metalakes/test_Metalake/catalogs/local-mysql/schemas/test/tables/demo_user

The returned JSON contains the complete field definitions of the demo_user table.

3.4 Local Deployment of SeaTunnel

Since this feature hasn’t been officially released, you need to manually compile the latest dev branch and deploy it locally.

3.5 Prepare Data Files

This test case uses a CSV file containing 2,000 records.

4. SeaTunnel Job Configuration

4.1 Core Configuration Example

env {
  parallelism = 1
  job.mode = "BATCH"
}
source {
  LocalFile {
    path = "/Users/wangxuepeng/Desktop/seatunnel/apache-seatunnel-2.3.13-SNAPSHOT/test_data"
    file_format_type = "csv"
    schema {
      schema_url = "http://localhost:8090/api/metalakes/test_Metalake/catalogs/local-mysql/schemas/test/tables/demo_user"
    }
  }
}
sink {
  jdbc {
    url = "jdbc:mysql://localhost:3306/test"
    driver = "com.mysql.cj.jdbc.Driver"
    username = "root"
    password = "123456"
    database = "test"
    table = "demo_user"
    generate_sink_sql = true
  }
}

4.2 Key Configuration Notes

schema.schema_url
- Points to the table metadata REST API in Gravitino
- SeaTunnel automatically fetches the table schema at job start
- No need to manually declare field lists in jobs
generate_sink_sql = true
- Sink automatically generates INSERT SQL based on the parsed schema

5. Data and Job Execution Results

Log screenshot:

During job execution:

Source automatically parses field structure via schema_url
CSV fields automatically align with the table schema
Data successfully written to MySQL demo_user table

6. FAQ

6.1 Supported Connectors

Currently, the dev branch supports file-type connectors including local, hdfs, s3, etc.

6.2 Does `schema_url` support multiple tables?

The feature does not affect multi-table functionality and can be used in combination, e.g.:

source {
  LocalFile {
    tables_configs = [
      {
        path = "/seatunnel/read/metalake/table1"
        file_format_type = "csv"
        field_delimiter = ","
        row_delimiter = "\n"
        skip_header_row_number = 1
        schema {
          table = "db.table1"
          fields {
            c_string = string
            c_int = int
            c_boolean = boolean
            c_double = double
          }
        }
      },
      {
        path = "/seatunnel/read/metalake/table2"
        file_format_type = "csv"
        field_delimiter = ","
        row_delimiter = "\n"
        skip_header_row_number = 1
        schema {
          table = "db.table2"
          schema_url = "http://gravitino:8090/api/metalakes/test_metalake/catalogs/test_catalog/schemas/test_schema/tables/table2"
        }
      }
    ]
  }
}

7. Feature Summary

By introducing Gravitino schema_url–based automatic schema parsing, SeaTunnel gains the following advantages in data sync scenarios:

Eliminates repeated schema definitions, reducing job configuration complexity
Reuses a unified metadata management system, improving consistency
Job-friendly in case of table structure changes, significantly lowering maintenance costs

This feature is ideal for:

Enterprises with mature metadata platforms
Large tables with many fields or frequent schema changes
Users seeking improved maintainability of SeaTunnel jobs

8. References

Code PR:
https://github.com/apache/seatunnel/pull/10402
schema_url Configuration Docs:
https://seatunnel.apache.org/zh-CN/docs/introduction/concepts/schema-feature#schema_url

Apache SeaTunnel 2.3.13 Major Release! Top 10 Features You Should Know

Apache SeaTunnel — Fri, 20 Mar 2026 09:40:59 +0000

Apache SeaTunnel community officially released version 2.3.13! This release is a milestone for Apache SeaTunnel, bringing important features such as Checkpoint API, Flink engine upgrade, large file parallel processing, multi-table sync, AI Embedding Transform, and richer connector extensions. Whether for batch processing or real-time CDC syncing to Lakehouse, SeaTunnel can now support your data integration tasks more efficiently, stably, and intelligently.

Thanks to 50+ community contributors, this release includes 100+ PRs of new features, optimizations, and bug fixes. If you are building data warehouses, real-time sync platforms, or AI data pipelines, this release is worth your attention.

No time to read the full Release Notes? No worries, here are the Top 10 features of this release with PR references for your reference.

Full Release Note: https://github.com/apache/seatunnel/releases/tag/2.3.13

01 New Checkpoint API Enhances Task Fault Tolerance

In data sync tasks, checkpoints are one of the core mechanisms to ensure task reliability. SeaTunnel 2.3.13 introduces Checkpoint API (#10065), making task state management more flexible and providing a solid foundation for future scheduling and operation capabilities. The Zeta engine supports min-pause configuration (#9804) to avoid system pressure caused by frequent checkpoints.

Monitoring has also been enhanced, such as adding Sink commit metrics and calculating commit rate (#10233), returning PendingJobs information in the task overview interface (#9902), and providing REST API to view the Pending queue (#10078).

These capabilities help users better understand task execution status and optimize checkpoint strategies.

02 Flink 1.20.1 Support and Enhanced CDC

On the engine side, this version improves Apache Flink support. SeaTunnel now supports Flink 1.20.1 (#9576), and CDC sync capabilities have been enhanced. CDC Source now supports Schema Evolution (#9867), automatically adapting sync tasks to source table structure changes.

Additionally, NO_CDC Source also supports checkpoints (#10094), improving task recovery. These changes make SeaTunnel more stable in scenarios with frequent database schema changes.

03 Large File Parallel Reading Significantly Improved

In real data platforms, large amounts of data often exist as files, such as HDFS, object storage, or local file systems.

This release significantly optimizes file processing performance. HDFS File Connector supports true large file parallel splitting (#10332), LocalFile Connector supports CSV, Text, JSON large file parallel reading (#10142), and Parquet files now support Logical Split (#10239).

HDFS File also supports multi-table reading (#9816). These improvements significantly increase throughput for TB-scale file processing.

04 File Connector Adds Update Sync Mode

Previously, file sync tasks only supported append or overwrite. In this version, multiple file connectors add sync_mode=update, including FTP, SFTP, and LocalFile Source (#10437), and HdfsFile Source (#10268). This allows file sync tasks to support update semantics, better fitting incremental data processing scenarios.

05 Connector Ecosystem Expansion

SeaTunnel 2.3.13 continues to expand and enhance the connector ecosystem. For analytical databases, it adds DuckDB Source and Sink support (#10285), suitable for local analysis and data exploration.

New or enhanced connectors include Apache HugeGraph Sink (#10002), AWS DSQL Sink (#9739), Lance Dataset Sink (#9894), IoTDB 2.x Source and Sink (#9872).

Existing connectors have also been improved: PostgreSQL supports TIMESTAMP_TZ (#10048), Hive Sink supports SchemaSaveMode and DataSaveMode (#9743), MongoDB Sink supports multi-table writing and adds SaveMode (#9958 / #9883).

These updates significantly improve SeaTunnel’s adaptability in database and Lakehouse scenarios and the efficiency of building data pipelines.

Category	Connector	Type	Feature Highlights	PR
Analytical DB	DuckDB	Source/Sink	Read and write data from DuckDB, suitable for local analysis and exploration	#10285
Graph DB	Apache HugeGraph	Sink	Write data into HugeGraph	#10002
SQL Lakehouse	AWS DSQL	Sink	Write data into AWS DSQL	#9739
File/Dataset	Lance Dataset	Sink	Write data into Lance Dataset	#9894
Time Series DB	IoTDB 2.x	Source/Sink	Add IoTDB 2.x source and sink support	#9872
Relational DB	PostgreSQL	Source	Support TIMESTAMP_TZ type	#10048
Data Warehouse	Hive	Sink	Support SchemaSaveMode and DataSaveMode	#9743
Document DB	MongoDB	Sink	Support multi-table write and new SaveMode	#9958 / #9883

06 Kafka Supports Protobuf Schema Registry

In real-time scenarios, Kafka often uses Schema Registry. This release adds Protobuf Schema Registry Wire Format support (#10183) to Kafka Connector, allowing SeaTunnel to directly parse Protobuf data managed via Schema Registry, making real-time pipeline construction easier.

07 New AI Embedding Transform

With AI and data engineering integration, more companies need vector data pipelines.

SeaTunnel adds Multimodal Embedding Transform (#9673) in the Transform component, generating vector data directly in pipelines for vector databases, RAG systems, and AI retrieval applications. RegexExtract Transform (#9829) further enhances data cleaning.

08 Markdown Parser Supports RAG Scenarios

Markdown documents are common in AI data preparation. This release adds Markdown Parser (#9760) and related documentation (#9834) for parsing and structuring Markdown, facilitating RAG pipeline construction.

09 Stability and Performance Improvements

This release includes numerous stability and performance optimizations, such as ClickHouse Connector parallel read strategy (#9801), MySQL Connector shard calculation (#9975), JSON parsing for nested structures (#10000), Zeta engine task metrics (#9833), and more.

It also fixes production issues like Zeta engine memory leak on task cancellation (#10315), ClickHouse ThreadLocal memory leak (#10264), MongoDB multi-task submit (#10116), HBase Source scan exception (#10287), Hive Sink init failure (#10331), etc.

10 Bug Fixes and Documentation Updates

Fixes include CDC Snapshot Split null pointer (#10404), ClickHouse memory leak (#10264), MongoDB multi-task submit (#10064, #10116), HBase scan exceptions (#10336, #10287), JDBC schema merge overflow (#10387, #9942, #10093), Hive Sink overwrite semantics (#10279, #9823, #9743), Elasticsearch Sink task exit issue (#10038), and other Connector, Transform, Engine, UI, CI fixes (#10422, #10013, etc.).

Documentation improvements include SeaTunnel MCP & x2SeaTunnel docs (#10108), connector config examples (#10283, #10250, #10241, #10202), multi-table sync examples (#10241), upgrade incompatibility notes (#10068), and doc structure optimizations (#10262, #10395, #10351, #10420, #10438, #10424, #10109, #10382, #10385), helping new users get started and developers better understand architecture and features.

Thanks to Contributors ❤️

Special thanks to release manager @xiaochen-zhou for strong support in planning and execution. Thanks to all volunteers; your efforts keep the SeaTunnel community growing!

Adam Wang, AzkabanWarden.Gf, Bo Schuster, cloud456, CloverDew, corgy-w, CosmosNi, Cyanty, David Zollo, dotfive-star, dy102, dyp12, Frui Guo, Jarvis, Jast, Jeremy, JeremyXin, Jia Fan, Joonseo Lee, krutoileshii, 老王, Leon Yoah, Li Dongxu, LiJie20190102, limin, LimJiaWenBrenda, liucongjy, loupipalien, mengxpgogogo-eng, misi, 巧克力黑, shfshihuafeng, silenceland, Sim Chou, Steven Zhao, wanmingshi, wtybxqm, yzeng1618, zhan7236, zhangdonghao, zhuxt2015, zy

Download & Try

Download: https://seatunnel.apache.org/download
Upgrade Guide: https://seatunnel.apache.org/docs/upgrade-guide

Upgrade Note: If you are on SeaTunnel 2.3.x, upgrading to 2.3.13 is generally safe as it focuses on feature enhancement and stability. Back up config files and test in staging. For tasks using checkpoints, stop tasks and confirm state consistency to avoid checkpoint conflicts. Check connector config changes (Hive, MongoDB, Kafka). If using Flink engine, consider upgrading to Flink 1.20.x for better compatibility and CDC support.

Apache DolphinScheduler 3.4.1 Released with Task Dispatch Timeout Detection

Apache SeaTunnel — Fri, 13 Mar 2026 08:02:50 +0000

The 3.4.1 version of Apache DolphinScheduler has been officially released by the community. As a maintenance release in the 3.4.x series, this update focuses on improving scheduling stability, enhancing task execution control, and fixing system issues.

The new version introduces a task dispatch timeout detection mechanism and maximum runtime control for tasks, while also resolving multiple issues in scheduling logic, plugin functionality, and API behavior. In addition, system documentation, development processes, and project structure have been further optimized.

For more details, see the Release Note: https://github.com/apache/dolphinscheduler/releases/tag/3.4.1
Source code download: https://dolphinscheduler.apache.org/zh-cn/download/3.4.1

Key Highlights

Task Dispatch Timeout Detection Mechanism

A task dispatch timeout checking logic has been added to the Master scheduling module. When a task is dispatched to a Worker for execution, if the Worker Group does not exist or no Worker nodes are available, the scheduler can detect the dispatch exception within a certain period and handle it accordingly.

This mechanism prevents tasks from remaining in a waiting state for an extended time and improves the system’s fault tolerance in scenarios involving resource anomalies (#17795, #17796).

Support for Configuring Maximum Runtime for Workflow and Task Instances

The new version allows users to configure a maximum runtime for both Workflow Instances and Task Instances.

Users can define the maximum execution duration for tasks or workflows. If the runtime exceeds the configured threshold, the system can trigger timeout handling mechanisms, preventing tasks from hanging or occupying resources indefinitely and improving overall operational controllability (#17931, #17932).

Key Fixes and Improvements

Scheduling System Stability Fixes

Fixed an issue where task timeout alerts were not triggered (#17820, #17818)
Fixed the issue where the workflow failure strategy did not take effect (#17834, #17851)
Automatically mark a task as failed when task execution context initialization fails (#17758, #17821)
Fixed incorrect parallelism calculation in backfill tasks under parallel execution mode (#17831, #17853)

Database and Compatibility Fixes

Fixed SQL execution errors for dependent tasks in PostgreSQL environments (#17690, #17837)
Fixed mismatched INT/BIGINT column types in database tables (#17979, #17988)

API and Permission Fixes

Removed the WAIT_TO_RUN state and added a FAILOVER state when querying workflow instances (#17838, #17839)
Added tenant validation for the Workflow API (#17969, #17970)
Fixed an issue where non-admin users could not delete their own Access Tokens (#17995, #17997)

Plugin and Task Execution Fixes

Fixed incorrect JVM parameter position in Java Task (#17848, #17850)
Fixed an issue where Procedure Task parameters could not be passed correctly (#17967, #17968)
Fixed the issue where ProcedureTask could not return parameters or execute query stored procedures (#17971, #17973)
Fixed an issue where the HTTP plugin could not send nested JSON structures (#17912, #17911)
Fixed inconsistent timeout units in the HTTP alert plugin (#17915, #17920)

UI and Documentation Fixes

Removed the STOP state from task instances in the UI (#17864, #17865)
Fixed an issue where locks were not released when workflow definition list loading failed (#17984, #17989)
Fixed the Keycloak login icon 404 issue (#18006, #18007)
Corrected errors in the installation documentation (#17901, #17903)
Fixed a SeaTunnel documentation link 404 issue (#17904, #17905)

In-Depth Feature Analysis

In modern data platform architectures, scheduling systems often serve as key infrastructure connecting various computing engines. Tasks from systems such as Apache Spark, Apache Flink, and Apache Hive are commonly orchestrated through a unified scheduler.

However, in production environments, scheduling systems often face challenges such as:

Worker resource anomalies preventing tasks from being scheduled
Uncontrollable task execution time
Unstable plugin execution behavior

The newly introduced task dispatch timeout detection mechanism enables the scheduler to quickly identify anomalies when Workers do not exist or resources are unavailable, preventing tasks from waiting indefinitely (#17795, #17796).

At the same time, the maximum runtime control capability provides a more flexible management approach for task execution. By setting a maximum runtime for workflows or tasks, the system can take action when tasks hang or run abnormally long, preventing resources from being occupied for extended periods (#17931, #17932).

These improvements further enhance DolphinScheduler’s stability and controllability in production-grade data platform environments.

Acknowledgements

The release of Apache DolphinScheduler 3.4.1 would not have been possible without the contributions of community developers. Special thanks to the release manager @ruanwenjun and the following contributors for their work on this version:

SbloodyS
njnu-seafish
Mrhs121
ylq5126
qiong-zhou
XpengCen
iampratap7997-dot
yzeng1618
Alexander1902
maomao199691
asadjan4611
dill21yu

Final Thoughts

Apache DolphinScheduler 3.4.1 is a maintenance release focused on improving scheduling stability and enhancing task runtime control.

With the introduction of scheduling fault-tolerance mechanisms, maximum task runtime control, and numerous bug fixes, this version further strengthens the system’s reliability in production environments.

As the community continues to grow, Apache DolphinScheduler is steadily improving its capabilities in the data workflow orchestration space, providing enterprises with a more stable and efficient infrastructure for building modern data platforms. We welcome more contributors to join the community and help drive the development of the project forward.

Forem: Apache SeaTunnel

A Practical DataOps Development Framework Based on WhaleStudio’s Three Layer Model

The Three Layer Development Framework

Project as the Governance Boundary

Workflow as the Business Pipeline

Task as the Smallest Execution Unit

Principles for Data Access and Workflow Design

Organize Projects by Business Domain

Separate Responsibilities in Permission Design

Balance Isolation and Reuse

Resolve Permission Differences Through Projects

Control Workflow Size

Upgrade Governance When Complexity Increases

Implementation Strategies for Different Team Sizes

Large Teams with Layered Isolation

Medium Sized Teams with Balanced Design

Small Teams with Fast Execution

Conclusion

Previous Articles

Coming Next

You Don’t Apply to Become an ASF Member, You Grow Into It

Starting from Data Integration

How He Got Into Open Source

From User to Maintainer

A Memorable Technical Challenge

The Most Important Skill in Open Source

Advice for New Contributors

The Moment He Became an ASF Member

What This Role Means

Understanding The Apache Way

How He Sees SeaTunnel

How Open Source Changed Him

One Sentence About Open Source

What Happened in Apache SeaTunnel? This March You Shouldn’t Miss

1. Release Overview

2. Key Updates in Version 2.3.13

2.1 New Connectors

2.2 Core Engine Enhancements

2.3 File Connector Improvements

2.4 CDC Improvements

2.5 Transform Enhancements

3. Bug Fixes in Version 2.3.13

4. Community Highlights

Contributors in March 2026

Infrastructure Updates

5. Recommendations for Enterprises

Upgrade Guidance

Features to Watch

Notes

6. Key Metrics

7. What’s Coming Next

(5)When Your Data Warehouse Breaks Down, It’s Probably a Naming Problem

Goals and Methods of Naming Conventions: Make Table Names Self-Explanatory and Teams Work Automatically

Table Naming Conventions: Templates, Cycle Encoding, and Examples

Field and Metric Naming Conventions: Rules, Structure, and Examples

- (6) DataOps Development Standards and Best Practices

Growing with the Community: Zhang Shenghang’s Path to Apache SeaTunnel PMC Member

Personal Background & Open Source Journey

Open Source Contributions & Growth

Becoming a PMC Member

SeaTunnel Community Development

Personal Growth & Open Source Culture

Rethinking ClassLoader Governance in Apache SeaTunnel

From “Usable” to “Governable”

Observations (Runtime-Oriented)

1. The Semantic Gap Between “Release” and “Close”

2. Class Loading Boundaries Can Still Change at Runtime

3. Some Residual Surfaces Are Not Fully Closed

A Possible Evolution Path (For Reference)

Phase 1: Close the ClassLoader Lifecycle

Phase 2: Stabilize Loading Boundaries

Phase 3: Consolidate Common Residual Points

Phase 4: Introduce Verifiable Reclamation

Why This Matters

One-Sentence Summary

Appendix: Code References

From Apache SeaTunnel to ASF Member: A Story of Long-Term Commitment

Personal Background & Open Source Journey

Open Source Contributions & Growth

Becoming an ASF Member

6.2 Does `schema_url` support multiple tables?