今年的开源之夏活动已渐近尾声，历经半年多的潜心开发，Apache SeaTunnel
接下来，让我们通过采访，走进这位来自北京科技大学的开发者的开源世界，看看她是如何兼顾繁重的学习任务，圆满完成这次开发任务的吧！
项目导师：Lucifer Tyrant
学校+专业 ：北京科技大学 大数据管理与应用
个人感兴趣或擅长的研究领域 ：大数据平台开发，曾在快手，美团的数据平台部做数据平台开发工作兴趣爱好 ：读一些技术文档，尝试业界新技术栈，看小说
Flink引擎CDC Source Schema Evolution支持
在实时数据同步场景中，源表的schema变更，如新增列、修改列类型等是常见需求。目前Apache SeaTunnel已经在自研引擎上支持了CDC schema evolution，但在Flink引擎上还没有实现这一特性，这导致用户在使用Flink引擎进行CDC同步时，一旦遇到schema变更就需要重启任务，非常影响数据同步的连续性和稳定性。
我的实现灵感主要来自于 Flink CDC项目 的设计思路。在研究Flink CDC的schema evolution实现后结合Apache SeaTunnel的架构特点，设计了一套适配Flink引擎的schema演化方案。
具体实现时序图如下：
核心架构设计包含以下几个关键组件：
SchemaCoordinato r
维护了schemaChangeStates映射表，记录每个表的schema变更状态
通过schemaVersions跟踪每个表的schema版本号
使用ReentrantLock锁机制保证多个并发schema变更请求的线程安全
维护pendingRequests队列，管理等待schema变更完成的CompletableFuture
SchemaOperator
在processElement()方法中检测SchemaChangeEvent
调用processSchemaChangeEvent()处理schema变更流程
维护currentSchemaChangeFuture用于支持schema变更的取消和回滚
通过lastProcessedEventTime防止重复处理旧的schema变更事件
遇到的关键问题及解决过程：
在开发过程中，我遇到了一个比较棘手的问题： 在processElement方法中处理schema变更事件时，整个流程会卡住，不再继续处理后续数据，只会不断地执行checkpoint流程 。
通过仔细分析日志，我发现了问题的根源：
2025 -08 -17 12 :33 :36 ,597 INFO FlinkSinkWriter - FlinkSinkWriter handled FlushEvent for table: .schema_test.products2025 -08 -17 12 :33 :36 ,597 INFO SchemaOperator - FlushEvent sent to downstream for table: .schema_test.products2025 -08 -17 12 :33 :36 ,597 INFO SchemaCoordinator - Processing schema change for table: .schema_test.products2025 -08 -17 12 :33 :36 ,598 WARN SchemaCoordinator - No schema change state found for table: .schema_test.products从这些日志可以看出，先发送了FlushEvent到下游，FlinkSinkWriter处理完FlushEvent后尝试通知SchemaCoordinator，但此时SchemaCoordinator还没有初始化schema change state（因为请求协调器的代码还没执行），导致通知失败。SchemaOperator中的 schemaChangeFuture.get() 方法会一直等待，直到60秒超时。
之后通过观察日志状态，我调整了执行顺序，将原本 “先发送FlushEvent，后请求SchemaCoordinator” 的逻辑，改为 “先请求SchemaCoordinator创建状态，后发送FlushEvent“ **，就比如这里：
CompletableFuture<SchemaResponse> schemaChangeFuture = schemaCoordinator.requestSchemaChange( tableId, jobId, schemaChangeEvent.getChangeAfter(), 1 ); currentSchemaChangeFuture.set (schemaChangeFuture); sendFlushEventToDownstream(schemaChangeEvent); 这样确保SchemaCoordinator先创建好schema change state，之后请求的时候就不会返回空，然后算子将FlushEvent被发送到下游，下游处理完FlushEvent后，因为此时state已经存在，就可以成功通知SchemaCoordinator，SchemaCoordinator收到通知后，完成schema change的CompletableFuture，之后processSchemaChangeEvent方法的等待结束，继续执行后续流程。
解决的问题：
实现了Flink引擎上的实时schema演化能力，用户在使用Flink引擎进行CDC同步时，源表发生schema变更后无需重启任务 提供了完整的schema变更协调机制，确保多算子之间的schema变更同步 为用户带来的好处：
业务连续性提升： schema变更不再需要停机，大大提高了数据同步的可用性 运维成本降低： 减少了人工干预，避免了频繁的任务重启 数据一致性保障： 通过FlushEvent机制确保schema变更前后的数据一致性 引擎选择灵活性： 用户可以根据自己的需要选择Flink引擎或SeaTunnel引擎，都能获得schema evolution能力 技术贡献：
新增了SchemaCoordinator全局协调器 在Flink translation层实现了完整的schema evolution适配 改进方向：
多并行度支持：设计并实现多并行度场景下的flush协调机制，可能需要引入并行度感知的计数器和更细粒度的状态管理 状态持久化：考虑将SchemaCoordinator改造为Flink的Operator或利用Flink的BroadcastState，使其状态能够参与checkpoint 同时，为了更好地了解同学们在参与开源之夏项目中的开发心得和感受，Apache SeaTunnel 对同学们进行了简短的采访，以下为 采访实录 ：
在众多项目中，为什么选择参与 Apache SeaTunnel 的项目？
我选择参与 Apache SeaTunnel 项目，主要有这样几点考虑：第一是它的技术方向和我已有的经验非常契合。之前在一家初创公司实习时，我们就是用SeaTunnel做数据集成，支持数据仓库的搭建。我自己也常用Flink开发数据处理管道、搭建实时血缘系统，对数据集成和实时同步这个领域很感兴趣。SeaTunnel作为新一代数据集成平台，技术栈新、架构清晰，我觉得很适合深入学习并做出贡献。
而且，Apache SeaTunnel 社区氛围特别好，社区非常活跃，大家响应也很及时，对像我这样初次参与开源的同学来说非常友好，CDC schema evolution 这个功能解决的是真实场景中的痛点，能看到自己写的代码真正帮助到用户，会很有成就感。
Apache SeaTunnel 的项目与你的学业有什么交集吗？
有挺多交集的。比如我们大数据处理课程中讲到的 Flink、StarRocks 等框架，在 SeaTunnel 里都有深入的应用。大二时为了处理 Spark 相关的微批次任务，我还用过 StreamPark，所以对数据集成这一块也比较熟悉。参与 SeaTunnel 项目，正好能把课堂上学到的理论知识在实际项目中落地，加深理解。
参与这个项目给你的学业和未来个人规划带来了哪些影响？
这个项目让我收获很大。比如，为了理解CDC的实现，我深入阅读了Flink CDC的源码，对Flink的运行机制、分布式协调、异步编程等有了更扎实的理解。
同时，在导师的指导下，我也学会了如何在大型开源项目中协作：包括代码规范、PR流程、测试覆盖等工程实践，为我未来的开源参与打下了很好的基础。更重要的是，通过这个项目，我明确了自己对数据基础架构方向的兴趣，未来也希望在这个领域继续深耕。
参与这个项目的过程中您遇到的最大的挑战是什么？是如何克服的？
最大的挑战是遇到一个比较棘手的技术问题：在实现过程中， processElement 方法会卡住，只做checkpoint却不继续处理数据。此外，在架构设计上，如何将新功能优雅地集成到现有系统中，也比我预想的要复杂。
为解决这些问题，除了自己反复调试、查阅资料，也积极向导师和社区伙伴请教。大家的建议给了我很多启发，也帮助我逐步理清了思路。
您参与开源有多长时间了？喜欢开源吗？开源给你带来了哪些改变？
这是我第一次正式参与开源。虽然之前在公司实习时也写过一些内部功能的代码，但向社区提交PR还是第一次。我非常喜欢开源。最吸引我的是那种开源的氛围——大家为了一个共同的目标，公开讨论、协作贡献，每个人都能在过程中学习和成长。这种开放、共享的精神，让我觉得特别有意义 。 您之前是否了解过或使用过 SeaTunnel或其他数据集成产品？
之前实习时就用过SeaTunnel，主要是做不同数据源之间的同步，比如从 Kafka 到 Hive，或者从 Kafka 到 StarRocks。Flink CDC 我也接触过，主要用在 CDC Source 的流式集成场景。相比之下，SeaTunnel 支持三种执行引擎，既能做流处理也能做批处理，覆盖的场景更全面。如果未来再选择数据集成工具，我会优先考虑 SeaTunnel——一是功能全面，二是配置起来也比较方便。 Apache SeaTunnel社区贡献给您的第一印象是怎样的？您希望在这里有何收获？
第一印象特别好：社区氛围友好，Mentor 响应及时，代码Review 也非常认真细致。我希望在这里能继续认识更多志同道合的朋友，为社区做出有价值的贡献，同时也精进自己的技术水平。 您后续还会持续在 Apache SeaTunnel社区活跃吗？
会的。关于我目前实现的功能，我还想再做些优化，更好地保证SeaTunnel on Flink 的精准一次语义。未来也希望能参与更多有意思的议题。 Apache SeaTunnel Apache SeaTunnel是一个云原生的多模态、高性能海量数据集成工具。北京时间 2023 年 6 月1 日，全球最大的开源软件基金会ApacheSoftware Foundation正式宣布Apache SeaTunnel毕业成为Apache顶级项目。目前，SeaTunnel在GitHub上Star数量已达8k+，社区达到6000+人规模。SeaTunnel支持在云数据库、本地数据源、SaaS、大模型等170多种数据源之间进行数据实时和批量同步，支持CDC、DDL变更、整库同步等功能，更是可以和大模型打通，让大模型链接企业内部的数据。
https://github.com/apache/seatunnel https://seatunnel.apache.org/ https://seatunnel.apache.org/download 我们相信，在 「 Community Over Code 」 （社区大于代码）、 「Open and Cooperation」 （开放协作）、 「Meritocracy」 （精英管理）、以及「 多样性与共识决策」 等 The Apache Way 的指引下，我们将迎来更加多元化和包容的社区生态，共建开源精神带来的技术进步！ 我们诚邀各位有志于让本土开源立足全球的伙伴加入 SeaTunnel 贡献者大家庭，一起共建开源! https://github.com/apache/seatunnel/issues https://github.com/apache/seatunnel/pulls dev-subscribe@seatunnel.apache.org https://join.slack.com/t/apacheseatunnel/shared_invite/zt-1kcxzyrxz-lKcF3BAyzHEmpcc4OSaCjQ https://x.com/ASFSeaTunnel
