揭秘大型数据中台：湖仓一体架构如何支撑万亿级数据流转？

📅 更新于 2026-05-16 | 🏷️ 湖仓一体 · 数据中台 · 架构设计 · 大数据
摘要：打造一个既兼顾实时又支持海量离线分析的数据中台，是许多企业技术升级的终极目标。本文将首次公开一套经过大规模生产验证的湖仓一体架构设计，从分层逻辑到自研采集引擎，从任务编排到双集群隔离，深度拆解如何用统一湖格式、存算分离、流批一体的理念重构数据底座，为正在规划数据平台升级的团队提供可直接借鉴的实战蓝图。

---

引言：从“烟囱”到“湖仓一体”，我们为什么选择重构？

几年前，我们的数据平台还长着典型的“烟囱式”模样：离线报表一套 Hadoop，实时指标一套 Flink + Kafka，数据科学家再单独搭一套特征工程环境。三个团队维护四套存储，同一个业务指标经常对不上，半夜数据延迟更是不定时炸弹。

我们痛定思痛，决定用湖仓一体的理念，基于开源技术生态 + 核心自研组件，从头搭建了一套面向未来的统一数据中台。这套架构稳定运行至今，日处理 PB 级数据，支撑着百余个业务域的实时与离线融合分析。今天，我将把它的完整设计思路分享出来。

---

一、整体架构：七层分层，两大集群

我们将整个数据中台切分为清晰的功能层，由下至上依次为：
应用层 → 服务层 → 治理层 → 调度开发层 → 元数据与计算引擎层 → 存储层

text

同时，为了彻底隔离计算资源，我们设计了两套 Kubernetes 集群：

• 计算集群：承载 Spark、Flink、交互式分析引擎等重型计算任务
• 应用集群：部署数据服务、任务调度、自研采集引擎等中台应用与元数据服务

各层核心技术选型如下（以通用组件名描述）：

层级	核心组件	功能
数据应用层	数据门户、自研BI、第三方BI	报表、看板、大屏、自助分析
数据服务层	统一SQL网关、交互式分析引擎、缓存服务	即席查询、API接口、结果加速
数据治理层	元数据中心、质量引擎、脱敏服务	资产目录、模型规范、安全审计
调度开发层	自研任务编排引擎、自研数据采集引擎、统一服务平台	任务DAG、离线/实时采集、SQL开发
计算引擎层	统一SQL网关(Spark)、交互式MPP引擎、流批计算引擎	流批处理、即席分析
元数据层	HMS（3副本）、关系型数据库	湖表元数据管理
存储层	对象存储（MinIO兼容S3）、缓存服务	存算分离，Parquet数据湖

---

二、分层深度解析：每一层都在解决什么问题？

2.1 数据应用层：让业务人员也能玩转数据

应用层直接面对用户，我们提供了三种形态：

• 数据门户：以资产目录和看板的形式，帮助用户发现和理解数据
• 自研BI模块：满足日常报表、可视化大屏和自助分析，并可逐步替代旧版第三方工具
• 标准JDBC接口：供数据科学家直接连接 Trino 或 Spark SQL 进行探索式分析

2.2 数据服务层：统一查询入口，双引擎自动路由

我们实现了统一 SQL 网关，用户提交一条 SQL，后台会根据查询特征自动选择引擎：

• 交互式分析引擎（MPP）：处理秒级即席查询
• Spark SQL：处理重型批量查询和 ETL 加工任务

同时，查询结果通过缓存服务暂存，重复查询几乎零延迟。对外提供的 200+ API，全部经由网关统一鉴权与限流。

2.3 数据治理层：湖仓的灵魂

湖仓一体最容易忽视的是治理。我们内置了五大能力：

• 规范建模：数据域、分层（ODS/DWD/DWS/ADS）、逻辑模型到物理表的映射
• 自动化元数据采集：定时爬取表结构、分区、字段血缘
• 质量与安全：SQL 规则检查、敏感数据自动识别与脱敏
• 生命周期管理：自动清理过期快照，防止存储膨胀
• 权限审计：结合 Ranger 实现表级、列级权限，操作全程留痕

2.4 任务调度与开发层：平台的大脑

这是整个架构中最关键的自研部分，分为三大模块：

① 自研任务编排引擎
我们设计了一套主流程→子流程→任务节点的三级调度体系：

• 主流程可以跨项目、跨业务域进行顶层编排
• 每个子流程内部是有向无环图（DAG）的任务串
• 任务节点类型覆盖：数据采集、Spark SQL 开发、Shell/Python 脚本等

一个典型的日级调度链如下：

主流程：某业务域数据更新
├── 子流程A：数据采集
│ ├── 采集任务1：离线抽取 MySQL 订单表 → 写入 Iceberg
│ └── 采集任务2：实时 CDC 接入日志表
│
└── 子流程B：数据加工
├── 开发任务1：ODS → DWD 明细层
├── 开发任务2：DWD → DWS 汇总层
└── 质量检查任务

② 自研数据采集引擎
我们自研了一套插件化的数据集成引擎，替代传统的 DataX/Sqoop，具备以下特征：

• 配置驱动：从对象存储下载任务配置文件，无须重启
• 插件化加载：Reader、Transformer、Writer 均为独立模块，动态加载
• 全链路安全：通过 OAuth2 认证，敏感配置加密存储
• 海量并发：每个采集任务都以独立容器运行，横向伸缩

支持的典型链路：JDBC Reader → 字段映射转换器 → Iceberg Writer → 对象存储
一条采集任务完成后，元数据自动同步到 HMS，采集日志实时输出到集中日志系统，任务状态上报至调度平台。

③ 数据开发平台
提供在线 SQL 编辑器，用户可直接编写 Spark SQL 或 Flink SQL，通过统一 SQL 网关提交执行。调度系统能够将开发好的 SQL 拖拽式编排进 DAG，实现加工流程的完全可视化。

2.5 计算引擎层：湖仓一体的心脏

底层采用开放湖仓表格式 Iceberg 管理所有数据，结合对象存储实现存算分离。计算引擎统一使用容器化部署在 K8s 集群上：

引擎	角色	部署方式
统一 SQL 网关（Spark Thrift Server）	批量 ETL 和重型 JDBC 查询入口	5 副本高可用 Deployment
交互式 MPP 引擎	即席分析	多副本 Coordinator + Worker
Spark/Flink 作业	批处理和流处理	通过 Operator 管理，按需启停 Pod

所有引擎共享同一份 HMS 元数据，读写的也是同一份 Iceberg 表。流的实时写入和批的离线处理第一次在存储层达成了真正的统一。

---

三、核心数据流：一次查询和一条采集链路背后的全流程

3.1 离线采集任务如何跑通？

1. 任务编排引擎触发采集任务
2. 采集引擎容器启动，从对象存储拉取配置和组件
3. JDBC Reader 连接业务数据库（MySQL/Oracle 等），分批抽取数据
4. 字段映射转换器进行轻量清洗
5. Iceberg Writer 将数据以 Parquet 格式直接写入对象存储
6. 提交 Commit，更新 HMS 元数据
7. 采集引擎上报完成状态，日志集中归档

整个过程无需任何中间文件落地，数据直写入湖，分钟级即可查询。

3.2 即席查询内部机制

1. 用户在中台界面或 BI 工具输入 SQL
2. 统一服务后端将 SQL 路由至交互式分析引擎（或 SQL 网关）
3. 引擎解析 SQL，利用 Iceberg 的文件统计信息进行分区裁剪和列裁剪
4. 直接读取对象存储上的 Parquet 文件
5. 结果写入缓存，返回前端展示

Iceberg 的隐式分区和文件级统计让我们在百亿级表上仍能获得亚秒级响应。

---

四、架构的四大核心优势

优势	技术支撑
存算分离，成本可控	数据全部在对象存储，计算集群可弹性伸缩，夜间批处理高峰过后缩容
流批一体，数据统一	Flink 流写入 + Spark 批处理共用 Iceberg 表，彻底消灭 Lambda 架构
任务编排，三级调度	主流程→子流程→任务节点，跨业务编排异常灵活
双集群隔离，生产稳定	计算集群与应用集群物理隔离，采集引擎、调度平台等核心服务不受计算任务影响

---

五、未来演进：向实时智能底座迈进

随着业务对时效性要求越来越高，我们正在将部分批处理链路升级为流处理，并在湖格式之上构建实时特征工程，让数据在写入湖的下一秒就能被 AI 模型消费。同时，计划引入联邦查询能力，打通湖、仓、API 多源数据的统一分析。

---

结语

湖仓一体不是简单的技术拼装，而是一场涉及存储、计算、调度、治理的全方位重构。我们希望这套公开的架构设计，能为同样在路上探索的你提供一张可靠的地图。

---

👍 如果你正在做数据平台建设或湖仓升级，点个赞让更多同行看到这套实战方案。
💬 你们团队的数据中台现在卡在哪一层？评论区留言，我可以结合经验帮你分析破局思路。
⭐ 收藏本文，下次做架构设计时它就是你的速查手册。

🔗 延伸阅读：【运维必备】Docker/K8s/Linux 高频命令速查手册（持续更新）
🔗 延伸阅读：从 Hadoop 到湖流一体：数据底座的三次革命与终极选型指南