[数据架构] AI 原生湖仓 · 企业数据架构参考手册

1 AI 原生湖仓 · 企业数据架构参考手册

湖仓一体（Lakehouse）× 存算分离 × 容器化（K8s）× Data+AI 深度融合 —— 分层设计、组件选型与演进路线

• 基线：2026-09 技术生态
• 适用：企业级 / 混合云 / 私有化
• 性质：架构建议（非唯一答案）

• 结论：以 开放表格式（Apache Iceberg 为主）+ 对象存储 + 无状态容器化计算（K8s + Volcano 统一调度）+ 统一元数据/治理控制面 为四根支柱，把数据湖、数据仓库、特征、向量、模型训练与推理收敛到【同一套数据资产】之上；【AI 应用】不再"搬运数据"，而是把【湖仓】当作受【治理的上下文层】与【操作层】直接消费。

【存储】与【计算】彻底解耦，任何【计算引擎】按需弹性伸缩、缩容到零；批、流、交互、AI 四类负载共享【同一底座】。

设计哲学：四根支柱 → 三个解耦 → 一个收敛

示意：四根支柱（开放格式、对象存储、容器化计算、统一治理）收敛出唯一数据资产，供批 / 流 / 交互 / AI 四类负载共享消费。

三个解耦

分层架构总览:L7 应用与接入层 + L6 数据资产与服务层 + L5 Data+AI 融合层 ★ 核心差异化 + L4 数据集成与编排层 + L3 计算引擎层（容器化 · 无状态 · 存算分离） + L2 湖仓管理层（Lakehouse 底座） + L1 存储层（存算分离） + L0 基础设施与容器底座

示意：纵向 8 层（L0 底座 → L7 应用），横向两条贯穿线（治理安全、可观测 DataOps）；L5 Data+AI 融合层是 2026 架构差异化的核心。

• L0 基础设施与容器底座：计算与调度 => 资源的全量容器化与弹性伸缩

• 架构要点：所有计算引擎（SQL/Spark/Ray）全部基于 Kubernetes 容器化部署，全面弃用传统 YARN。
• 统一调度机制：利用 Volcano 或 Kueue 解决大数据批处理（Gang Scheduling）与 AI 大模型 GPU 异构资源调度的混部冲突，提升集群整体 GPU/CPU 利用率。

• L1 存储层：存算分离 & L2 湖仓管理层: 统一开放湖仓底座

• 架构要点：通过分布式对象存储实现海量数据极低成本沉淀；利用 open table format 解决 Lakehouse 的 ACID 事务、Schema 演进与并发读写问题。
• Data+AI 融合突破：AI 不仅需要 Parquet 列存，还需要原生支持 Lance/Parquet 等多模态与向量数据，实现“非结构化数据与结构化元数据同湖存储”。

• L3 计算引擎层：流批一体与 AI 调度混合

• 分析引擎：StarRocks/Trino 提供高性能湖仓直连查询（Lakehouse Queries）。
• AI 引擎：引入 Ray 体系替代/互补 Spark。Ray 能够无缝对接 Python AI 生态（PyTorch, HuggingFace），解决传统 Spark 在深度学习/大模型分布式训练和推理中的效率痛点。

• L4 数据集成与编排层

• L5 Data + AI 深度融合层（核心创新点）

• 特征与数据供给：通过特征工程平台（Feature Store），将湖仓中的离线/实时特征无缝转化为 AI 模型输入。
• 向量与 RAG 集成：将大模型 Embedding 生成过程整合到湖仓 ETL 管线中（Spark/Ray Job），直接写回 Lakehouse 向量索引层或向量数据库。

• L6 数据资产与服务层

• L7 应用与接入层

• 治理 & 安全: 统一治理、安全与控制面 (Catalog & Governance)

• 核心挑战：多引擎（Spark, Trino, Ray, PyTorch）共享同一份 Lakehouse 数据时，权限与元数据容易碎片化。
• 选型思路：可引入 Apache Polaris (Iceberg REST Catalog) 或 Apache Gravitino 打造跨引擎的统一元数据中心，并配合 Apache Ranger 实现数据与 AI 模态的统一列级/行级权限控制。

• 【关键要点】

1. 坚持统一开放的数据标准，杜绝黑盒
  建议：数据存储格式坚定选择开放的列存格式（如 Parquet/ORC）和开源 Lakehouse 格式（Apache Iceberg）。这能保证以后无论想换用 Spark、StarRocks 还是 Python/Ray，都不需要搬迁数据。

2. 彻底走向 K8s 云原生，消除“两套资源池” / 计算与调度层：全量容器化与弹性伸缩
  避坑：不要再单独建一套 Hadoop/YARN 集群用于大数据，另一套 Kubernetes 用于 AI 训练。利用 Kueue / 【Volcano】 统一资源调度，将 AI 训练的夜间闲置 GPU/CPU 调度给大数据批处理，大幅降低 TCO。
  架构要点：所有计算引擎（SQL/Spark/Ray）全部基于 Kubernetes 容器化部署，全面弃用传统 YARN。
    统一调度机制：利用 Volcano 或 Kueue 解决大数据批处理（Gang Scheduling）与 AI 大模型 GPU 异构资源调度的混部冲突，提升集群整体 GPU/CPU 利用率。

3. 以 Apache Iceberg REST Catalog 为核心收拢权限
  避坑：多引擎混用最易导致数据越权。通过 Apache Polaris/Gravitino 等暴露统一的 REST Catalog 接口，并在控制层强制接入 Ranger，避免不同引擎绕过权限直接读底层的 S3 数据块。

4. 引入 Ray 补全 Python-Native 数据处理短板
    Ray: 一个开源的分布式计算框架，用于将Python代码轻松并行化和分布式运行，广泛应用于机器学习、AI训练和大规模数据处理。
    建议：传统 ETL 可以继续使用 Spark/SQL，但一旦涉及非结构化数据解析（如 PDF/OCR/语音）、大模型 Batch 推理和特征向量化，应优先引入 Ray Data，避免用 Spark-Python (PySpark) 带来的序列化与 JVM 性能开销。

各层职责与组件选型

L0 基础设施与容器底座

关注点	主选	备选/说明
K8s 发行版	OpenShift（私有化企业）/ ACK·TKE（公有云）	K3s/RKE（轻量）；多集群可用 KubeSphere/Rancher 管理
批 + AI 统一调度	Volcano（CNCF 唯一官方批处理调度器）	统一调度 Spark/Flink/Ray/PyTorch/TensorFlow/MindSpore/Argo
在线离线混部/超卖	Koordinator	提升资源利用率，AI 离线任务与在线服务混部
引擎生命周期	Spark Operator / Flink Operator	声明式管理作业与集群，支持动态 Executor
GPU 池化	Volcano Device Plugin + vGPU/MIG	训练/推理共享 GPU，按作业抢占与切分
网络/存储基础设施	CNI（Cilium/Calico）+ RDMA 可选	GPU 场景注意 RDMA/InfiniBand 与拓扑感知调度

L1 存储层（存算分离的数据底座）

组件	定位	选型建议
对象存储（主存储）	唯一持久化底座，PB~EB 级	公有云 OSS/S3/COS/OBS；私有化 MinIO / 兼容 S3 存储
缓存加速层	把对象存储"挂载"成高性能文件/缓存	JuiceFS / Alluxio / GooseFS；元数据 + 数据缓存两层
多级缓存	Memory → 本地 NVMe → 分布式缓存 → 远端	计算节点本地盘做近计算缓存，降低对象存储 IOPS 压力
分层存储策略	热/温/冷生命周期管理	对象存储分层 + 归档，压缩 + 生命周期规则，控成本
AI 数据分层（可选）	GPU 近算缓存→近端热→共享生产→企业资产	借鉴 G1~G5 分层思路，训练集放近 GPU 高速缓存层

L2 湖仓管理层（Lakehouse 底座）

组件	定位	选型建议
开放表格式	统一表语义：ACID/时间旅行/Schema演进	Iceberg 主选（最开放多引擎）；Delta 绑定 Databricks；Hudi 用于 CDC/高频 upsert；Paimon 用于流式实时入湖
统一 Catalog	所有引擎共用的元数据中心	Iceberg REST Catalog（自建高可用）/ 云上 Glue·DLF / 开源 Polaris
表维护	Compaction/Optimize/Snapshot清理	Spark 批任务或自动化优化服务；Hudi/Paimon 侧重 MoR 合并
多模态管理	文本/图片/音视频/JSON/向量统一入湖	同一元数据·权限·事务体系，为 Data+AI 打基础
数据入口统一	全量增量都落同一套表	避免"数仓一套+湖一套"双写；一切从 Iceberg 读

L3 计算引擎层（容器化 · 无状态 · 存算分离）

负载	引擎	容器化/弹性方式
批 / ETL / 特征预处理 / 数据科学	Apache Spark	Spark on K8s + Spark Operator，动态 Executor 0→N
实时流 / CDC	Apache Flink	Flink on K8s + Flink Operator，Reactive Mode 弹性
即席 / 联邦查询	Trino / Presto	无状态 Worker，Helm 部署，Worker 弹性伸缩
交互式 OLAP（存算分离）	StarRocks / Doris / ClickHouse	StarRocks/Doris cloud 模式（S3 + FoundationDB + MetaService），直读 Iceberg
AI 分布式计算	Ray / PyTorch / TF	Volcano VcJob 调度；训练、数据并行、RL、分布式推理

L4 数据集成与编排层

能力	主选	说明
实时/CDC 入湖	Flink CDC / Apache Paimon	数据库变更实时入湖，Paimon 提供流式湖仓
批量同步	SeaTunnel / DataX / Spark	多源异构批量抽取，全量+增量
工作流编排	DolphinScheduler / Airflow / Argo	DolphinScheduler 国产更贴合国内任务依赖；Argo 容器原生
数据开发平台	自研或商业（DataWorks 等）	统一开发/调试/发布/调度，与编排层打通

L5 Data+AI 融合层 ★（本架构差异化核心）

能力	主选	选型建议
特征平台	Feast / 自研	离线+在线特征统一，保证训练-服务一致性（training-serving skew）
向量数据库	Milvus 2.x	本身即存算分离微服务（etcd 元数据 + 对象存储持久化），承载 RAG/相似检索
MLOps / 模型管理	MLflow / Kubeflow	实验跟踪、模型注册、版本与上线审批
LLM/Agent 基础设施	vLLM + KServe / BentoML，Dify·OpenClaw 等	GPU 推理由 Volcano 调度；Agent 把湖仓当作受治理上下文
湖上训练直读	Spark/Ray 直读 Iceberg + 对象存储	训练集不复制、可版本化（Iceberg 时间旅行做数据版本）
在线学习/增量知识	Flink + 特征服务 + 推理链路	实时反馈进入特征与向量，模型知识更新不滞后

L6 数据资产与服务层 / L7 应用与接入层

层	能力	要点
L6	数据服务 API 网关 / 指标平台 / 语义层	把指标、标签、特征做成可复用数据产品
L6	实时特征服务 / 画像	在线 Serving 与离线训练同源
L7	BI/自助分析/大屏；风控/推荐/搜索/Agent	多类消费方共享一套资产，不各自建数仓

关键选型决策矩阵（重点）

开放表格式：Iceberg vs Delta vs Hudi vs Paimon

维度	Apache Iceberg	Delta Lake	Apache Hudi	Apache Paimon
定位	最开放·多引擎首选	Databricks/Spark 深度集成	流式 CDC·高频 upsert 最强	流式湖仓·实时入湖
更新/删除	Deletion Vectors (v3)	Deletion Vectors	原生 record-level 索引	LSM 式合并，强
增量处理	一般	一般	最强（增量查询）	强（流读）
多引擎生态	最广（Spark/Flink/Trino/Snowflake…）	UniForm 兼容层	广	广（偏 Flink）
归属治理	Apache，厂商中立	Databricks 主导（Linux Foundation）	Apache	Apache
2026 建议	默认，不确定就选它	Databricks 锚定才选	CDC 核心才选	实时链路补选

OLAP 引擎（存算分离 + 湖仓直查）

引擎	存算分离	湖仓直查(读Iceberg)	实时性	典型场景
StarRocks / Doris	cloud 模式（S3+FD+MetaService）	强，免搬迁直查	亚秒级	交互报表、实时分析、湖仓直查
Trino / Presto	天然无状态	强	秒级（查询型）	即席、联邦、大查询
ClickHouse	需改造/存算分离版	弱	极强	高并发点查、时序、监控分析
Spark SQL	无状态	强	批	批式复杂分析、ETL

要点：亚秒级在线（<100ms）仍建议 OLAP 引擎本地热数据 + 缓存；亚秒~秒级用湖仓直查即可，避免"为了实时复制一份库"。

容器化调度与资源

组件	选型建议	理由
批量+AI 统一调度	Volcano	CNCF 唯一官方批处理调度器；Spark/Flink/Ray/PyTorch/TF/Argo 一个调度器统一，天然对齐"存算分离+容器化"
在线/离线混部	Koordinator	在线服务与离线 AI 任务混部，提高利用率、降成本
GPU 调度	Volcano Device Plugin + vGPU/MIG	异构资源感知、拓扑感知、抢占
引擎 Operator	Spark Operator + Flink Operator	声明式生命周期与弹性

Data+AI 组件

组件	主选	轻量/备选	定位
特征平台	Feast / 自研	在线特征表（StarRocks）	训练-服务一致
向量数据库	Milvus 2.x	pgvector / Elasticsearch	RAG、相似检索、AI 记忆
MLOps	MLflow / Kubeflow	自研轻量	实验、注册、部署
推理服务	vLLM + KServe	BentoML / Triton	LLM 高吞吐推理
Agent/编排	Dify / OpenClaw 等	自研 Agent	把湖仓当上下文与工具

演进路线（三步走）

Step1 湖仓一体化 + 存算分离 + 容器化（0~6 个月）

• 统一到 Iceberg + REST Catalog；对象存储为主存储 + 缓存加速；Spark/Flink/Trino 全部 Spark-on-K8s/Flink-on-K8s + Volcano 调度；重构存量数仓为"湖仓直查"。

Step2 Data+AI 融合（6~12 个月）

• 引入 Milvus 向量库 + 特征平台 + Ray + MLflow；训练集/Embedding 直读湖上数据；RAG 与 Agent 上线，数据与 AI 同源。

AI 原生 / Agentic（12 个月+）

• 湖仓成为 Agent 的操作层与上下文层：实时增量知识、在线学习、受治理的 Agent 执行与权限审计；数据团队从"做报表"转向"运营数据资产"。

落地注意（避坑）

• 入口统一：所有数据只从开放表格式读写，杜绝"湖一套仓一套"双写，否则存算分离白做。
• 缓存治理：对象存储 IOPS 有上限，按查询模式配置 JuiceFS/Alluxio 与本地 NVMe 缓存，避免热点打爆。
• Catalog 高可用：REST Catalog 是全架构元数据命脉，必须高可用 + 备份，否则单点故障全局瘫痪。
• 存算分离不是银弹：亚秒级在线分析仍需 OLAP 引擎本地热数据；纯湖仓直查适合秒级场景，两类并存并定义清晰 SLA。
• 成本与弹性：冷数据下沉对象存储、计算缩容到零；用 FinOps 可视化分租户成本。
• 信创/合规：私有化需验证 Iceberg/Volcano/Milvus 等对国产 CPU/OS/存储的兼容矩阵。
• AI 数据分层：GPU 训练数据放近算力高速缓存，避免每次都从对象存储拉全量。

数据流示例：一个"实时风控/推荐 + RAG"场景

示意：同一份湖上数据同时服务【实时特征】、【向量检索（RAG、长期记忆）】、【模型训练】与 【Agent 上下文】，无数据搬迁。

Y 推荐文献

• 基于 Docker + Flink + Iceberg + MinIO 构建湖仓一体架构的案例实践 - 博客园/千千寰宇
• [AI/Agent/架构] 企业级AI应用的架构设计（参考蓝图） - 博客园/数据知音

X 参考文献

• 腾讯云 TBDS 新一代数据湖仓产品与商业实践（K8s 存算解耦、无服务器形态）
• Kubernetes 上的存算分离大数据平台（Spark/Flink/Trino 容器化选型对照）
• Databricks Data+AI Summit 2026 综述：湖仓成为 Agentic AI 的操作层
• Iceberg vs Delta vs Hudi 2026 多篇选型综述（Algoscale / RisingWave / DataStackGuide / pdpspectra）
• Apache Hudi 官方博客：What is an Open Table Format
• Volcano 官方文档：统一调度（Spark/Flink/Ray/PyTorch/TF/Argo）
• 阿里云 OpenLake / 腾讯云 DLC / 数据湖计算产品架构
• Milvus 2.x 存算分离微服务架构资料（etcd 元数据 + 对象存储持久化）