再见，组件地狱！我们将 7 个开源引擎替换成一个华为云 GaussDB(DWS)，数据中台彻底变轻了

📅 更新于 2026-05-18 | 🏷️ 数据中台 · 华为云 · GaussDB(DWS) · 架构升级 · MPP
摘要：维护 Spark、Flink、Trino、Iceberg、HMS、MinIO、Kyuubi 七个核心组件的痛苦，我们熬了两年。最终，我们做了一次大胆的“减法”：用华为云 GaussDB(DWS) 全托管 MPP 数仓一举替换掉全部七个组件，实现存储、计算、元数据、安全、高可用的全栈统一。本文毫无保留地公开这套新架构的设计细节、迁移路径、性能收益和血泪教训，为正在被开源组件堆叠折磨的团队提供一条切实可行的“轻量化”之路。

---

引言：当“湖仓一体”变成了“组件地狱”

两年前，我们满怀热情地基于开源技术栈构建了一套湖仓一体数据中台：MinIO 存数据、Iceberg 管表格式、Hive Metastore 管元数据、Spark 跑批、Flink 跑流、Trino 做交互分析、Kyuubi 做 SQL 网关。架构图一画，团队觉得这就是数字化的未来。

两年后，激情被现实磨平了棱角：

- **版本兼容性噩梦**：Spark 升级导致 Iceberg 读写异常；Flink Connector 小版本不匹配导致 checkpoint 频繁失败。
- **运维成本失控**：7 个组件的监控、告警、扩缩容、安全补丁，几乎拖垮了整个数据平台团队。
- **元数据瓶颈**：HMS 在高频 DDL 下频繁超时，导致下游任务雪崩。
- **排查一根问题要跨 4 个系统**：从调度日志跳到 Spark UI，再跳到 HMS 日志，最后还得去 MinIO 控制台检查文件。

我们终于明白了一个道理：在基础设施层追求“每个组件都用最好的开源项目”，结果往往是组合在一起变成最差的系统。 是时候做减法了。

经过严密的选型和 POC，我们决定将所有计算与存储组件全部收敛到华为云 GaussDB(DWS)——一个全托管、MPP 分布式、兼容标准 SQL 的云原生数仓。今天这篇文章，就是这次“大瘦身”的完整复盘。

---

一、旧架构之痛：我们到底被什么拖垮了？

在展示新架构之前，有必要先正视旧债。

| 组件 | 当初选择的理由 | 后来变成的负担 |
|------|----------------|----------------|
| MinIO | S3 兼容，存算分离 | 需单独维护纠删码、扩容；数据文件无事务保障 |
| Iceberg | ACID、时间旅行 | 快照过期要手动清理；小文件合并占资源；元数据文件膨胀 |
| HMS + MySQL | 统一元数据入口 | 高并发 Thrift 超时；需独立高可用；与各引擎版本绑定 |
| Spark + Kyuubi | 批处理与 JDBC 入口 | 资源消耗大；常驻进程浪费；与 Iceberg 适配脆弱 |
| Flink | 实时入湖 | 状态后端调优复杂；与 Iceberg 的 commit 冲突频发 |
| Trino | 低延迟交互分析 | 内存管理棘手；需单独配置数据源 |

七件兵器单独看都很锋利，但一起挥舞时，割伤的都是自己人。

---

二、新架构：一个 DWS 群集，终结一切

我们的目标极其明确：用一个全托管 MPP 数仓，替换掉整个计算引擎层和存储层，同时完整保留中台上层应用（采集、调度、开发、治理、服务、应用）。

新架构分层如下：

应用层（数据门户、BI、指标中心）
↓ JDBC
服务层（即席查询、API 网关、结果缓存）
↓ JDBC
治理层（元数据、质量、脱敏、权限、审计）
↓ JDBC
调度开发层（DolphinScheduler + 自研采集引擎 PSC + SQL 编辑器）
↓ JDBC
核心数仓层 —— 华为云 GaussDB(DWS)
├─ ELB 负载均衡
├─ CN 多副本（协调节点，SQL 入口）
├─ DN 集群（数据节点，行/列/混合存储，多副本）
├─ GTM 全局事务管理器
└─ CM 集群管理器
↓ 存储
EVS（热数据）+ OBS（冷数据 / 存算分离）

原来需要 Spark、Flink、Trino、Kyuubi、Iceberg、HMS、MinIO 七个组件协同才能完成的事，现在全部由 DWS 一个服务原生支持。

---

三、组件替换全景对比：从 7 到 1

旧组件	新架构中如何被 DWS 替换	额外收益
MinIO（对象存储）	数据直接存入 DWS 的 EVS 云盘或 OBS，无需关心底层文件格式	不再维护 MinIO 集群，表分区、压缩自动管理
Iceberg（表格式）	DWS 内核自带分布式表存储，ACID 由 GTM 全局事务保证	无快照清理、无小文件合并，事务强一致
HMS + MySQL（元数据）	DWS 内置 pg_catalog 系统表，元数据与数据在同一事务域	元数据查询性能毫秒级，无跨网络 Thrift 调用
Spark + Kyuubi（批处理）	DWS MPP 引擎，SQL 直接分发到 DN 并行执行	无额外常驻进程，资源利用率提升 50%+
Flink（流处理）	轻量保留 Flink 集群，通过 Flink SQL Connector 写入 DWS；或使用 DWS 内置流式导入	架构简化，实时写入链路更稳
Trino（交互分析）	DWS CN 节点直接承接即席查询，通过 WLM 区分长短查询	统一 JDBC 入口，延迟更低
Kyuubi/Trino JDBC 双入口	统一为 DWS JDBC，应用层只维护一套数据源	前端代码简化，路由逻辑消失

一句话总结：除了轻量级的调度和采集仍在应用集群外，整个数据底座被压缩成了一个 DWS 集群。

---

四、新架构的数据流：原来可以这么简单

4.1 离线采集与入仓

业务库 (MySQL/Oracle/SAP)
↓ JDBC 批量读取
自研采集引擎 PSC（插件化，配置驱动）
↓ 字段映射、轻量清洗
DWS JDBC Writer（批量 INSERT / COPY）
↓
DWS CN → DN（ODS 层行存表）

整个链路不落盘，数据从源库直接流进 DWS，分钟级可见。

4.2 数据开发（ETL）

原来需要编写 Spark SQL、提交到 Kyuubi、再读取 MinIO 上的 Iceberg 表进行层层加工。现在：

DolphinScheduler 触发 → 中台微服务 → DWS JDBC 执行 SQL
↓
DWS CN 生成并行执行计划 → DN 本地计算
↓
ODS → DWD（列存） → DWS（宽表） → ADS（应用指标）

所有转换逻辑封装在 DWS SQL 或存储过程中，数据不出集群，计算本地化，性能大幅提升。

4.3 即席查询

用户在前端 SQL 编辑器输入查询，中台后端直接通过 DWS JDBC 提交。利用 DWS 的工作负载管理，短查询分配快速队列，长查询转入批量池，互不干扰。结果集写入 Redis 缓存，重复查询零延迟。

---

五、性能与成本：一次“大瘦身”的实际收益

迁移完成后，我们对比了核心指标：

指标	旧开源架构	新 DWS 架构	提升幅度
需维护核心组件数	7 个	1 个服务	运维人力下降 60%
日批处理平均耗时	4.2 小时	1.8 小时	性能提升 57%
即席查询平均响应	8.3 秒	2.1 秒	分析效率提升 75%
月度基础设施成本	较高（多集群常驻）	降低 35%（弹性伸缩）	成本大幅优化
元数据并发瓶颈	HMS 频繁超时	无	任务成功率 99.9%

更重要的是，告警数量下降了 70%，团队终于有精力去做数据治理和业务支持，而不是天天当“开源组件消防员”。

---

六、迁移经验：我们的五步走策略

如果你也打算从开源湖仓迁到全托管数仓，以下步骤或许能少走弯路。

1. SQL 兼容性扫描
   将原有 Hive/Spark SQL 语法与 DWS 的 PostgreSQL 兼容语法逐一映射，封装为转换工具，自动适配非标准函数和 DDL。

2. 历史数据平滑迁移
   利用原 Spark 集群将 Iceberg 历史数据导出到 OBS，通过 DWS 的 COPY 命令并行加载，验证数据一致性后切流。

3. 任务逐步切换
   先切测试域，再切边缘业务，最后核心链路。664 个离线采集任务仅需修改 Writer 类型；Spark SQL 开发任务转换为 DWS SQL 任务，提交方式改为 JDBC 调用。

4. 性能调优黄金项

   • 数据入库后立即执行 ANALYZE 收集统计信息
   • 为大表设置合理的分布键和分区键
   • 配置 WLM 资源池隔离 ETL 和查询负载

5. 轻量保留流处理
   保留一套最小规模的 Flink 集群处理要求毫秒级延迟的实时 CDC，通过官方 Flink SQL Connector 写入 DWS，其余全部走批量准实时链路。

---

七、未来展望：从统一数仓到 AI 数据基座

迁移完成后，我们获得的不只是一个更稳定的系统，更是一张通往 AI 化的入场券。DWS 的行列混合存储、内置 UDF、与 ModelArts 的深度集成，让下一步的特征工程实时化、模型推理在线化成为可能。数据从产生到变成模型输入，延迟正从小时级压向分钟级。

---

结语

技术的演进，不总是“加更多新东西”。有时候，敢于做减法，敢于用一套成熟、全托管、高度集成的平台去替代一堆看似灵活实则脆弱开源组件，才是真正的架构升维。

如果你也正在组件的海洋里挣扎，希望我们的这次实践能给你带来一点“断舍离”的勇气。

---

👍 如果你也想简化数据架构，或者正在选型数仓底座，点个赞让更多同行看到这份实战复盘。
💬 你的团队被多少个开源组件困扰着？评论区说出你的故事，我会结合经验给你建议。
⭐ 收藏本文，下次做架构减法时它就是你的参考手册。

🔗 延伸阅读：揭秘大型数据中台：湖仓一体架构如何支撑万亿级数据流转？
🔗 延伸阅读：从 Hadoop 到湖流一体：数据底座的三次革命与终极选型指南
🔗 延伸阅读：【运维必备】Docker/K8s/Linux 高频命令速查手册（持续更新）