发帖
雷达卡
婆厦倮痘多点DMALL数据平台的四次演变
多点 DMALL 的数据平台经历了四次变迁，始终围绕“更快速、更节省、更稳定”发展。
在多点 DMALL 的数据平台建设中，最初通过 AWS-EMR 快速搭建云端大数据能力，随后回归 IDC 自建 Hadoop 集群，结合开源内核和自研集成、调度及开发组件，将重资产转化为可复用的轻量服务。当业务需求低成本、高弹性时，团队采用存算分离与容器化重构基础架构，引入 Apache SeaTunnel 实现实时数据入湖；接着使用 Apache Iceberg 和 Paimon 统一存储格式，形成湖仓一体的新架构，为 AI 提供稳定且低耗的数据基座，实现了从利用云到自建云、从离线到实时的闭环。
存算分离架构
DMALL UniData（Data IDE）的存算分离架构以 Kubernetes 作为弹性基础，Spark、Flink 和 StarRocks 按需自动扩展，Iceberg+JuiceFS 统一湖存储，Hive Metastore 跨云管理元数据，Ranger 提供精细授权，确保存算分离且无厂商绑定，技术栈全链路可控。
这种架构带来了显著的业务效益：TCO 降低40-75%，资源秒级扩展，同一套 IDE 框架支持集成、调度、建模、查询和服务，交付快速、节省人力，多云环境畅通且安全。
一、旧架构的问题
在引入 Apache SeaTunnel 之前，多点 DMALL 数据平台已支持 MySQL、Hive 和 ES 等十几种存储的自助数据同步，基于 Spark 自研多种数据源，可按需定制接入，但仅限于批处理模式。
在数据导入方面，多点 DMALL 数据平台统一承载公司的 ODS 数据入湖，采用 Apache Iceberg 作为湖仓格式，支持小时级的数据下游可用性，数据复用率高，确保了数据质量。
过去我们依赖 Spark 自研同步工具，虽然稳定，但面临“启动慢、资源重、扩展难”的挑战。
“不是 Spark 不好，而是它太笨重。”
在降本增效的背景下，我们重新审视了原有的数据集成架构。尽管 Spark 批处理任务成熟，但在处理中小规模的数据同步时显得效率低下。启动时间长、资源占用高和开发周期长成为团队效率的瓶颈。更重要的是，面对日益增长的实时业务需求，Spark 的批处理模式已难以满足。
| 维度 | 旧 Spark 方案 | 业务影响 |
|---|---|---|
| 资源消耗高 | 2C8G 起步，空跑 40s | 对于大多数中小规模数据同步不友好 |
| 开发难度大 | 缺乏 Source/Sink 抽象，全链路开发 | 增加开发与维护成本，降低交付效率 |
| 不支持实时同步 | 新技术兴起，实时增量同步需求增加 | 现阶段仍需要开发人员用 Java/Flink 自行实现 |
| 数据源有限 | 商家私有化部署增多，数据源多样 | 新增数据源定制开发，难以快速满足业务需求 |
直到我们遇到了 Apache SeaTunnel，一切都开始改变。
二、为什么选择 SeaTunnel？
“我们不是在挑选工具，而是在为未来五年的数据集成架构做决策。”
面对多样的数据源、实时性需求和资源优化压力，我们需要一个“批流一体、轻量高效、易于扩展”的集成平台。SeaTunnel 以其开源特性、支持多种引擎、丰富的连接器和活跃的社区成为了我们的最终选择。它不仅解决了 Spark 的“笨重”问题，还为未来的湖仓一体和实时分析打下了基础。
引擎中立：内置 Zeta，并兼容 Spark/Flink，可根据数据量自动切换。
连接器官网已超过 200+，且插件化：新增数据源只需写 JSON，无需 Java 代码。
批流一体：同一套配置支持全量、增量和 CDC 模式。
社区活跃：GitHub 8.8k star，每周合并 PR 超过30个，我们提出的5个 Patch 均在7天内被合并到主干。
三、新平台架构：让 SeaTunnel 成为企业级解决方案
“开源不是拿来即用，而是在巨人肩膀上继续创新。”
尽管 SeaTunnel 功能强大，但要在企业级场景中真正落地，还需要一层“外壳”——统一的管理、调度、权限控制和监控等能力。我们围绕 SeaTunnel 构建了一套可视化、可配置、可扩展的数据集成平台，使其从一个开源工具成长为多点数据平台的“核心引擎”。
3.1 全局架构
以 Apache SeaTunnel 为基础，平台提供统一的 REST API，Web UI、商家交换和 MCP 服务等任何外部系统都可一键调用；内置连接器模板中心，新存储只需填写参数即可在几分钟内发布，无需编码。调度层兼容 Apache DolphinScheduler 和 Airflow 等主流编排工具，引擎层根据数据量智能路由至 Zeta/Flink/Spark，小任务轻量化快速执行，大任务分布式并行处理；镜像和运行环境全面云原生化，支持 K8s、Yarn 和 Standalone 多模式输出，商家私有化场景也能一键交付，实现“模板即服务、引擎可切换、部署无绑定”。
3.2 互导功能
数据源注册：地址、账号、密码一次录入，敏感字段加密，公共数据源（如 Hive）全租户可见。
连接器模板：通过配置新增连接器，定义 SeaTunnel 配置生成规则，控制任务界面 Source 和 Sink 显示。
离线任务：运行批处理任务支持 Zeta 和 Spark 引擎，通过 DAG 图描述同步任务，支持通配符变量注入。
实时任务：运行流处理任务支持 Zeta 和 Flink 引擎，通过 S3 协议存储 Checkpoint，可进行 CDC 增量同步。
接入功能
接入申请：用户提交同步表申请工单；管理员审批，以确保数据接入质量。
库表管理：按数据库同步，避免同步链路过载；统一管理链路，保证数据质量；支持分表合并成一张表。
基线拉取：通过批处理任务进行自动建表和初始化；超大表可依据规则拆分拉取；数据缺失可根据条件拉取补齐。
数据同步：同步任务通过 REST API 提交到集群；支持限流、打标特性，确保重要同步操作的执行；CDC 增量写入多种湖仓环境。
四、二次开发：让 SeaTunnel 说“多点方言”
“再优秀的开源项目，也听不懂你业务的‘方言’。”
SeaTunnel 的插件机制虽灵活，但面对多点自研的 DDH 消息格式、分库分表合并、动态分区等需求时，仍需我们进行代码调整。幸运的是，SeaTunnel 的模块化设计让二次开发变得高效且可控。以下是我们重点改进的几个模块，每一项都直接解决了业务痛点。
4.1 定制 DDH-Format CDC
多点自研 DDH 采集 MySQL binlog，以 Protobuf 推送至 Kafka。我们实现了 KafkaDeserializationSchema：
- 解析 Protobuf → SeaTunnelRow；
- DDL 消息直接构建 CatalogTable，在 Paimon 侧自动添加列；
- DML 打标“before/after”，下游 StarRocks 进行部分列更新。
4.2 Router Transform：多表合并+动态分区
场景：1200 张分库分表 t_order_00…t_order_1199 → 一张 Paimon 表 dwd_order。
实现：
- 正则表达式 t_order_(\d+) 映射目标表；
- 选择基准 Schema（字段最多的一张表），其余表缺失的字段补 NULL；
- 主键冲突使用 $table_name + $pk 生成新的 UK；
- 分区字段 dt 从字符串 create_time 截取，支持 yyyy-MM-dd 与 yyyyMMdd 两种格式自动识别。
配置片段：
4.3 Hive-Sink 支持 Overwrite
社区版只有 append 模式，我们基于 PR #7843 进行二次开发：
- 任务提交前，先根据分区值调用 FileSystem.listStatus() 获取旧路径；
- 新数据写完后原子删除旧路径，实现“幂等重跑”。
已贡献回社区，预计 2.3.14 版本发布。
4.4 其他补丁
- JuiceFS 连接器：支持挂载点缓存，提升 listing 性能 5 倍；
- Kafka-2.x 独立模块：解决 0.10/2.x 协议冲突；
- 升级 JDK11：Zeta 引擎 GC 时间减少 40%；
- 新增 JSON UDF json_extract_array/json_merge，日期 UDF date_shift()，已合并入主干。
五、踩坑实录
“每一个坑，都是通往稳定的必经之路。”
开源项目再成熟，在实际业务场景落地时也难免遇到问题。我们在使用 SeaTunnel 的过程中，遇到了版本冲突、异步操作、消费延迟等问题。以下是几个典型的“坑”及其最终解决方案，希望能帮助你少走弯路。
| 问题 | 现象 | 根因 | 解法 |
|---|---|---|---|
| S3 访问失败 | Spark 3.3.4 与 SeaTunnel 默认内置 Hadoop 3.1.4 冲突 | classpath 存在两份 aws-sdk | 排除 Spark 的 hadoop-client，改用 SeaTunnel uber jar |
| StarRocks ALTER 阻塞 | 写入时报 “column not found” | SR 的 ALTER 为异步操作，客户端继续写会失败 | 在 sink 中轮询 SHOW ALTER TABLE STATE，FINISHED 后再恢复写入 |
| Kafka 消费慢 | 每秒仅 3k 条，poll 到空消息线程 sleep 100ms | — | 提 PR #7821，支持“空轮询不 sleep”模式，吞吐量提升至 12w/s |
六、总结收益：三个月交卷
“技术价值，最终要用数字说话。”
我们用了 Apache SeaTunnel 不到三个月时间，完成了 3 套商家生产环境的迁移。结果不仅“运行更快”，还“运行更省”。
Oracle、云存储、Paimon、StarRocks 等源端需求得到一次性满足，实时同步不再依赖手动编写 Flink；通过模板化“零代码”接入方式，新增连接器的部署时间从过去的 N 周缩短至 3 天，资源消耗仅为原 Spark 的三分之一，相同数据量下运行更高效。
结合全新的用户界面和按需开放的数据源权限，商家 IT 可自行配置任务、查看链路，交付成本显著降低，使用体验大幅提升，真正实现了降本增效、灵活操作和稳定状态三大目标。
七、下一步：湖仓+ AI双轮驱动
京公网安备 11010802022788号
