我为什么想把 SeaTunnel 做得更好用（7）：被忽略的数据同步体验

大家好，我是乐峰呀。

这篇文章，想聊一个我最近越来越强烈的感受：

数据同步工具其实并不少。

甚至可以说，选择很多。

DataX、Sqoop、Spark、Flink，还有各种商业化的数据集成平台、数据同步平台、数据开发平台。

但真正用下来，我发现一个问题：

工具很多，但真正站在使用者角度，把数据同步这件事做得足够顺手的工具，并不多。

这也是我为什么一直想把 SeaTunnel 做得更好用。

不是因为现在没有工具。

而是因为很多时候，我们缺的不是一个“能跑”的工具，而是一个“真的好用”的工具。

一个简单的市场调研

我也简单对比过一些常见的数据同步工具。

比如 DataX、Airbyte、Canal、Debezium、Fivetran，以及 Apache SeaTunnel。

从能力上看，每个工具都有自己的优势：有的稳定，有的生态丰富，有的专注 CDC，有的商业化体验成熟。但如果从“真实使用体验”来看，会发现一个共同问题：很多工具解决了同步能力，却没有完整解决从上手、配置、运行、排错到持续管理的体验问题。

所以我最后的感受是：

数据同步领域不是没有工具，而是缺少一个既有工程能力，又真正照顾使用体验的工具。

这也是我越来越觉得 SeaTunnel Web 有价值的原因。

它不是要替代 SeaTunnel 的底层能力，而是希望把 SeaTunnel 已经具备的批流一体、分布式、CDC、多源同步能力，用更清晰、更可视化、更容易管理的方式呈现出来。

一开始，我也只是想完成一次数据同步

很多人接触数据同步，最开始的诉求其实很简单。

比如：

把 MySQL 的数据同步到 MySQL。

把业务库的数据同步到数仓。

把几张表从一个环境迁移到另一个环境。

把数据定时抽取出来，给报表、质控、BI 或其他系统使用。

听起来并不复杂。

但真正开始做的时候，问题就来了。

你需要先选择工具。

选完工具之后，需要看文档。

看完文档之后，需要写配置。

写完配置之后，需要找插件。

插件装好了，还要处理连接参数、驱动、字段类型、时间格式、主键、增量字段、并行度、任务调度、运行日志、错误排查。

如果是实时同步，还会遇到 CDC、checkpoint、启动模式、表结构变更、断点恢复这些问题。

到最后，原本只是想做一次数据同步，却变成了：

我得先成为这个工具的熟练使用者。

这其实是很多数据同步工具长期存在的问题。

很多工具解决了“同步”，但没有解决“使用”

我并不是说这些工具不好。

相反，很多工具都很强。

DataX 很经典，Sqoop 曾经也很常用，Spark 和 Flink 的能力更不用说，很多商业产品也做了大量工程化能力。

但从一个普通使用者的角度来看，它们往往会遇到几个问题。

所以很多时候，工具本身是能完成同步的。

但用户真正痛苦的地方，不是“有没有同步能力”。

而是：

我怎么更快地配置？
我怎么知道配置对不对？
我怎么知道任务有没有跑成功？
我怎么排查失败原因？
我怎么持续管理这些同步任务？

这些问题，其实都属于“使用体验”。

而这部分，过去经常被忽略。

数据同步不只是写一份配置文件

以前我也觉得，数据同步嘛，本质上就是源端、目标端、字段映射、运行参数。

只要配置写对了，任务能跑起来，就可以了。

但后来真正做得多了，才发现不是这样。

对于开发人员来说，一份配置文件也许可以接受。

但对于更多使用者来说，他们需要的是一个完整的工作流。

一个真正好用的数据同步工具，不应该只关心任务能不能提交。

它还应该关心：

任务怎么创建。

数据源怎么维护。

连接是否可用。

表结构能否自动识别。

字段映射是否清晰。

配置能不能预览。

任务能不能发布和运行。

运行状态是否可见。

失败原因能不能快速定位。

历史记录能不能追踪。

指标能不能看懂。

这些事情看起来都不是“同步引擎”的核心能力。

但它们决定了一个工具到底好不好用。

我为什么觉得 SeaTunnel 值得继续做

后来我开始关注 SeaTunnel。

让我觉得很有意思的是，SeaTunnel 本身在数据同步这件事上，底座是比较扎实的。

它支持很多数据源。

也支持批同步和实时同步。

它的连接器体系、任务配置方式、Zeta 引擎、CDC 能力，都让它可以覆盖比较多的数据同步场景。

更重要的是，它是开源的。

这意味着它不是一个封闭的黑盒。

你可以理解它、调试它、扩展它，也可以根据真实场景去优化它。

这点对我来说很重要。

因为我不太喜欢那种“看起来什么都有，但出了问题完全不知道怎么办”的工具。

数据同步这种事情，一旦进入真实业务环境，问题一定会出现。

连接问题、字段问题、权限问题、类型问题、性能问题、增量问题、实时同步问题，都会出现。

所以一个工具不仅要能跑，还要能被理解、能被观察、能被维护。

SeaTunnel 在底层能力上已经有了很好的基础。

但我一直觉得，它还差一个更友好的入口。

这个入口，就是 SeaTunnel Web 想做的事情

我做 SeaTunnel Web，并不是想重新造一个数据同步引擎。

SeaTunnel 已经做了引擎和连接器层面很重要的事情。

SeaTunnel Web 更想做的是：

把 SeaTunnel 的能力，以更容易理解、更容易操作、更容易管理的方式交给使用者。

比如数据源管理。

不需要每次都重新写连接信息，而是可以统一维护、测试连通性、复用连接。

比如单表同步。

不需要一上来就写完整配置，而是通过页面一步步选择源端、目标端、表结构和字段映射。

比如多表同步。

不需要复制很多份配置，而是可以批量选择表结构，快速生成同步任务。

比如字段映射。

不需要完全靠手写字段，而是可以自动解析源表字段，再可视化调整映射关系。

比如任务运行。

不只是提交任务，而是可以看到运行状态、运行历史、日志和指标。

比如 HOCON 配置预览。

对于熟悉 SeaTunnel 的用户，也可以继续查看和理解最终生成的配置。

这些功能单独看，可能都不是特别“炫”。

但它们解决的是一个很现实的问题：

让用户少踩坑，少查文档，少写重复配置，少在错误日志里迷路。

好用，不是降低专业性

有时候一提到“好用”，大家可能会觉得是不是把工具做简单了。

但我理解的“好用”，不是把专业能力拿掉。

而是把复杂度放在合适的位置。

对新手来说，可以通过可视化和引导流程快速开始。

对熟悉 SeaTunnel 的用户来说，可以看到配置、调整参数、理解执行逻辑。

对运维和平台人员来说，可以统一管理数据源、任务、实例、日志和指标。

对真实业务场景来说，可以减少重复劳动，提高稳定性和可维护性。

所以 SeaTunnel Web 并不是想把 SeaTunnel 变成一个“傻瓜工具”。

而是想让 SeaTunnel 的能力更容易被使用。

能简单开始，也能深入使用。

能可视化操作，也能保留配置能力。

能适合新手，也不限制专业用户。

这才是我理解的“更好用”。

一个工具真正被使用，才会暴露真正的问题

做 SeaTunnel Web 的过程中，我越来越觉得：

很多问题，只有真正被使用的时候才会出现。

写 demo 的时候，一切都很顺。

但一到真实环境，问题就多了。

不同数据库的字段类型不一样。

不同 JDBC 驱动的参数不一样。

Oracle、PostgreSQL、SQL Server、MySQL 的时间格式不一样。

批同步和实时同步不一样。

普通 JDBC 和 CDC 又不一样。

有些场景需要自动建表。

有些场景需要字段映射。

有些场景需要自定义 SQL。

有些场景需要看任务实例、运行日志和同步指标。

这些东西不是写一篇文档就能完全解决的。

它需要工具本身不断补齐能力。

也需要在真实使用中持续打磨。

所以我越来越觉得，SeaTunnel Web 的价值不只是“多了一个页面”。

而是让 SeaTunnel 更接近真实使用者的工作方式。

我想做的，不只是一个管理后台

如果只是做一个后台页面，其实意义不大。

真正有价值的是，把数据同步过程中那些容易出错、容易重复、容易让人困惑的地方，一点点收起来。

让用户从“我该怎么写配置”变成“我该同步哪些数据”。

从“这个任务为什么失败”变成“系统告诉我问题在哪里”。

从“我不知道有没有跑成功”变成“运行状态、日志、指标都能看见”。

从“每次都重新配置”变成“数据源、任务、模板都可以复用”。

这才是我想做 SeaTunnel Web 的原因。

它不是为了替代 SeaTunnel。

而是为了让更多人真正用起来 SeaTunnel。

写在最后

数据同步这个领域，其实已经不缺工具了。

但它仍然缺少一种体验：

一种真正为使用者考虑的体验。

不是只告诉你“这个工具很强”。

而是让你真的能用起来。

不是只提供一堆参数。

而是让你知道每一步该怎么走。

不是任务失败后丢给你一堆日志。

而是帮助你更快定位问题。

不是只解决“能不能同步”。

而是继续往前走一步，解决“能不能更容易、更稳定、更可控地同步”。

这就是我为什么想把 SeaTunnel 做得更好用。

SeaTunnel 已经有了很好的底座。

而我想做的，是把它变成一个更多人愿意用、用得懂、用得顺手的数据同步工具。

这件事不一定容易。

但我觉得，很值得继续做下去。

https://github.com/weifuwan/seatunnel-web