从 Hadoop 到 Data + AI Platform：大数据平台六阶段演进与现代化建设方法

第一部分：大数据平台演进的六个阶段

一、六阶段总览

阶段	核心问题	核心抽象	代表性开源产品	主要结果
第一阶段	数据超过单机容量，单机存不下、算不动	分布式文件块、Map/Reduce	HDFS、MapReduce	建立廉价服务器上的大规模分布式存储与批处理
第二阶段	MapReduce 开发门槛过高	Table、SQL、DSL、数据生态工具	Hive、Pig、HBase、Sqoop、Flume、Oozie	Hadoop 从计算框架变成数据平台
第三阶段	MapReduce 太慢，计算模型单一，资源管理与引擎绑定	Resource Manager、DAG、Stateful Stream	YARN、Spark、Flink、Kafka、Tez、Presto/Trino	资源调度与计算引擎解耦，批流计算体系成熟
第四阶段	固定集群运维重，弹性和异构资源能力不足	Pod、Container、Operator、CSI、CNI	Kubernetes、Operator、Volcano、Kueue、Argo	形成通用的云原生 Resource Runtime
第五阶段	对象存储上只有文件，缺少可靠的表、事务和版本管理	Table Format、Snapshot、Catalog、ACID	Iceberg、Delta Lake、Hudi、Paimon	Data Lake 演化为开放 Lakehouse
第六阶段	数据不再只是行列，还包括图片、视频、音频、向量和模型	Vector、Blob、Multimodal、AI Runtime	Ray、Milvus、vLLM、KServe、Paimon/Hudi 多模态能力	Data Platform 进一步演化为 Data + AI Platform

可以把六个阶段压缩成六个关键词：

1
2
3
4
5
6


第一阶段：Scale         解决规模问题
第二阶段：Abstraction   解决易用性问题
第三阶段：Compute       解决通用计算和实时性问题
第四阶段：Runtime       解决资源、部署和弹性问题
第五阶段：Table         解决开放数据管理问题
第六阶段：AI            解决多模态数据和 AI 计算问题

二、第一阶段：HDFS + MapReduce——解决“数据太大”的问题

1. 当时的核心问题

传统关系数据库和单机分析系统面对 TB、PB 级数据时，会同时遇到：

单机磁盘容量不足；
单机 CPU 无法在合理时间内完成计算；
高端专用设备扩展成本过高；
节点故障会导致长时间任务失败；
大规模数据跨网络移动成本很高。

Hadoop 给出的基本答案是：

1
2
3
4
5
6


                Hadoop
                   │
        ┌──────────┴──────────┐
        │                     │
       HDFS               MapReduce
  分布式文件系统          分布式批处理模型

HDFS 是一个面向高吞吐大文件访问的分布式文件系统，MapReduce 则把计算拆成 Map、Shuffle、Reduce 等阶段，在大量普通服务器上并行运行。Hadoop 官方今天仍把 HDFS、YARN、MapReduce 和 Common 作为核心模块。¹

HDFS 内部以 Block 组织文件，但它在存储分类上仍是分布式文件系统，不能等同于 Ceph RBD、EBS、SAN 这一类基础设施“块存储”。

2. 代表性开源产品

Apache Hadoop Common
HDFS
MapReduce
ZooKeeper
早期 HBase

3. 代表性商业产品和托管服务

Cloudera CDH / Cloudera Enterprise
Hortonworks Data Platform（HDP）
MapR Data Platform
IBM BigInsights
Oracle Big Data Appliance
Amazon EMR

这里的“商业产品”不一定意味着底层引擎完全闭源。很多产品的价值是把开源 Hadoop 组件与安装、监控、安全、管理、优化、技术支持和云服务组合起来。Amazon EMR 至今仍提供基于 Hadoop、Spark、Flink、Trino 等开源引擎的数据处理服务。²

4. 它解决了什么

把超大数据拆散到多台普通服务器存储；
把批处理任务拆成可并行执行的计算单元；
默认节点会故障，由软件自动恢复；
通过数据本地性减少网络搬运；
大幅降低 PB 级数据平台的建设门槛。

5. 它又引入了什么新问题

MapReduce 编程模型过于底层；
多阶段任务频繁落盘，性能较差；
只能较好地处理批任务；
HDFS、MapReduce 和资源管理早期绑定较紧；
NameNode 元数据、小文件和集群运维逐渐成为瓶颈。

6. 今天是否还有价值

有。HDFS 在已有大型 IDC、固定服务器、大量本地磁盘、重批处理和高吞吐顺序扫描场景中仍然合理；但新项目通常已经没有必要直接开发 MapReduce 程序。第一阶段留下来的核心价值主要是 HDFS 和分布式容错思想，而不是 MapReduce API 本身。

三、第二阶段：Hive、Pig 与 Hadoop 生态——解决“分布式计算太难用”的问题

1. 当时的核心问题

第一阶段已经能存、能算，但普通数据工程师为了完成一个聚合查询，仍然需要编写 Mapper、Reducer、InputFormat、OutputFormat 和大量配置代码。

第二阶段的目标是：

让使用者面向 SQL、表、字段、分区和数据流程，而不是直接面向分布式执行细节。

典型转换过程是：

1
2
3
4
5
6
7
8
9


SQL / DSL
    ↓
Hive / Pig
    ↓
执行计划
    ↓
MapReduce
    ↓
HDFS

2. 代表性开源产品

领域	代表产品
SQL / 数据仓库	Hive
数据处理 DSL	Pig
分布式 KV / NoSQL	HBase
数据导入导出	Sqoop
日志采集	Flume
工作流	Oozie
协调服务	ZooKeeper
序列化与文件格式	Avro、Parquet、ORC

3. 代表性商业产品和托管服务

Cloudera Enterprise / CDH
Hortonworks HDP
MapR
IBM BigInsights
Oracle Big Data Appliance
Amazon EMR

第一、第二阶段的商业产品高度重叠，因为当时商业化重点就是把整套 Hadoop Ecosystem 产品化。

4. 它解决了什么

SQL 用户不再需要手写 MapReduce；
Hadoop 从单一计算框架变成数据仓库、采集、NoSQL 和工作流平台；
建立了表、分区、Schema 和 Metastore 等关键概念；
数据工程岗位和大数据 SQL 生态迅速成熟。

5. 它又引入了什么新问题

上层虽然易用，底层大量作业仍然落到 MapReduce；
多阶段 SQL 会反复写磁盘；
交互式查询延迟很高；
资源管理仍然围绕 MapReduce；
生态组件数量迅速增加，安装和运维越来越复杂。

6. 今天是否还有价值

有，但价值发生了分化：

传统 Hive on MapReduce 的重要性明显下降；
Hive SQL、Hive 表模型和 Hive Metastore 的影响仍然很大；
Parquet、ORC、Avro 已成为后续 Lakehouse 的基础组成；
Pig、Sqoop、Oozie 等不应再作为新建平台的默认核心产品。

因此，第二阶段不是被整体淘汰，而是其中有价值的抽象被后续系统继续继承。

四、第三阶段：YARN + Spark + Flink——解决“计算模型和资源管理受限”的问题

这一阶段实际上包含两次重要解耦。

1. 第一次解耦：资源管理与 MapReduce 分离

YARN 把 Hadoop 中的资源管理能力抽离出来：

1
2
3
4
5
6


                 YARN
          Cluster Resource Manager
                   │
       ┌───────────┼───────────┐
       ↓           ↓           ↓
   MapReduce      Spark       Flink

从此，资源管理器不再等于某一种计算引擎。

2. 第二次解耦：MapReduce 两阶段模型演化为 DAG 和 Stateful Stream

Spark 通过 DAG、内存缓存、SQL 优化器和统一 API 改善批处理、交互式分析和机器学习计算；Flink 则把有界流和无界流统一到流式运行时，并引入 State、Event Time、Watermark、Checkpoint 和 Exactly-Once 等能力。

Spark 当前仍正式支持 Standalone、YARN 和 Kubernetes 等部署模式；Flink 也同时支持 YARN、Kubernetes 和 Standalone。³⁴

3. 代表性开源产品

领域	代表产品
资源管理	YARN、Mesos（历史）
通用批处理 / SQL	Spark、Tez
流处理	Flink、Storm（历史）、Spark Structured Streaming
事件流平台	Kafka、Pulsar
交互式 SQL	Presto、Trino、Impala、Spark SQL
MPP 分析	ClickHouse、Doris、StarRocks 等逐渐兴起

4. 代表性商业产品和托管服务

Databricks
Confluent Platform / Confluent Cloud
Cloudera Data Platform
Amazon EMR
Google Dataproc / Managed Service for Apache Spark
阿里云实时计算 Flink
Starburst

5. 它解决了什么

资源调度与计算引擎解耦；
DAG 替代固定的 Map/Reduce 两阶段模型；
批处理、流处理、SQL 和机器学习计算逐渐统一；
长期运行的状态流任务成为主流；
Kafka 等系统成为实时数据事件主干。

6. 它又引入了什么新问题

YARN 更擅长数据计算，不适合统一管理数据库、Web 服务、AI 推理和各种云原生应用；
不同引擎拥有不同部署和运维方式；
固定集群资源利用率不高；
数据通常仍绑定 HDFS 或固定存储集群；
AI、GPU 和异构资源管理能力不足；
Spark、Flink、Kafka、MPP 数据库等大量长期服务需要独立运维。

7. 今天是否还有价值

这是今天仍然最重要的计算层。Spark 和 Flink 没有被 Kubernetes 或表格式替代，因为它们解决的是“怎么计算”，而 Kubernetes 解决“在哪里运行、资源如何管理”，Iceberg/Paimon 等解决“数据以什么表形式存在”。

Mesos 则基本已经退出新建平台选型；Spark 当前支持的主要集群管理器已经不包含 Mesos。

五、第四阶段：Kubernetes 云原生时代——解决“统一运行、弹性与异构资源”的问题

1. Kubernetes 解决的并不是下一代 SQL 或计算模型

Kubernetes 的核心定位是通用容器应用的部署、扩缩容和生命周期管理。⁵

它主要替代或扩展的是 YARN 所处的 Resource Runtime / Cluster Resource Management 位置，而不是替代 Spark、Flink 或 StarRocks：

1
2
3
4
5
6
7


YARN 世界                               Kubernetes 世界

Spark                                  Spark
Flink                                  Flink
MapReduce                              Ray / PyTorch / vLLM
                                       Kafka / StarRocks
其他长期服务单独部署                    Web / API / Database / Agent

2. 代表性开源产品

Kubernetes
containerd
Helm
CNI / CSI 生态
Prometheus
Argo CD、Argo Workflows
Spark Operator
Flink Kubernetes Operator
KubeRay
Volcano、Kueue
Cilium
Harbor

Flink 的原生 Kubernetes 集成能够直接向 Kubernetes 申请和释放 TaskManager，Flink Kubernetes Operator 又进一步负责声明式部署和生命周期管理。⁶

3. 代表性商业产品和托管服务

Amazon EKS
Google Kubernetes Engine（GKE）
Azure Kubernetes Service（AKS）
Red Hat OpenShift
SUSE Rancher Prime
VMware Tanzu
Amazon EMR on EKS

4. 它解决了什么

统一管理数据、AI、数据库、服务和平台组件；
通过容器和镜像实现环境一致性；
通过 Operator 把分布式系统生命周期声明化；
支持 CPU、GPU、网络、存储和各种异构资源；
支持弹性扩缩、多租户、Namespace、Quota 和 RBAC；
形成庞大的 CNCF 与云原生生态。

5. 它又引入了什么新问题

Kubernetes 自身复杂度高；
原生 kube-scheduler 对队列、公平共享、Gang Scheduling 和 GPU 拓扑支持并非覆盖所有数据/AI需求；
有状态系统迁移到 Kubernetes 后，存储、网络和故障域设计更复杂；
计算节点可以弹性消失，传统本地 Shuffle 和本地状态生命周期需要重新设计；
存算分离后，远端对象存储的延迟和吞吐会影响上层引擎。

6. Kubernetes 与存算分离的关系

需要特别说明：

Kubernetes 不是表格式出现的直接原因，也不是对象存储的发明者。

更准确的因果链是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


云计算和对象存储普及
       +
计算资源需要弹性扩缩
       +
多个计算引擎共享同一份数据
       ↓
存储与计算逐渐解耦
       ↓
对象存储缺少数据库表语义
       ↓
Iceberg / Delta / Hudi / Paimon 等表格式兴起

Kubernetes 使计算资源弹性化和统一运行更加自然，但表格式主要是在解决对象存储和多引擎共享数据的管理问题。

六、第五阶段：Lakehouse 与开放表格式——解决“文件不是表”的问题

1. 当时的核心问题

对象存储中可能只有大量 Parquet/ORC 文件：

1
2
3
4


bucket/warehouse/table/
├── part-0001.parquet
├── part-0002.parquet
└── part-0003.parquet

对象存储只负责保存 Object，并不知道：

哪些文件属于当前表；
哪些文件已经删除；
当前 Schema 和分区规则是什么；
多个写入者如何并发提交；
哪个 Snapshot 是当前版本；
如何做 Time Travel、Update、Delete、Upsert 和 CDC。

表格式在文件和计算引擎之间增加了一层数据管理协议：

1
2
3
4
5
6
7
8
9


Spark / Flink / Trino / StarRocks
                │
          Table Format
                │
  Iceberg / Delta / Hudi / Paimon
                │
       Parquet / ORC / Blob
                │
 HDFS / S3 / Ozone / JuiceFS / Object Store

Iceberg 的目标是让 Spark、Flink、Trino、Hive 等多种计算引擎安全访问同一批分析表；Delta Lake 强调 ACID、流批统一和运行时生态；Hudi 强调增量处理、更新和表服务；Paimon 则尤其强调 Flink、流式更新、CDC，并继续向多模态扩展。⁷⁸⁹¹⁰

2. 代表性开源产品

Apache Iceberg
Delta Lake
Apache Hudi
Apache Paimon
Parquet、ORC、Avro
Spark、Flink、Trino 等计算引擎

3. 代表性商业产品和托管服务

Databricks Data Intelligence Platform
Snowflake
Dremio
Starburst Galaxy
Onehouse
AWS Glue / Athena / EMR
Google BigLake / BigQuery
Microsoft Fabric / OneLake

Databricks 等商业平台的核心价值已经从单独提供 Spark，扩展到 Lakehouse、数据工程、SQL、治理和 AI 的统一平台。¹¹

4. 它解决了什么

把对象存储上的文件组织成可靠的表；
提供 Snapshot、版本、Schema Evolution 和事务；
让多个计算引擎共享统一数据层；
降低数据被单个计算引擎锁定的风险；
支持批、流、CDC、增量读取和数据回溯。

5. 它又引入了什么新问题

表格式、Catalog 和引擎兼容矩阵复杂；
Compaction、清理、索引和元数据维护需要持续运行；
四种主要表格式定位重叠，平台容易同时引入过多产品；
数据层虽然开放，性能仍受对象存储、文件布局和缓存策略影响；
Catalog、权限和多引擎一致性成为新的基础设施问题。

6. 今天如何看待四种表格式

新建平台没有必要把四种都作为同等级核心产品。更合理的做法是选一到两种主格式：

表格式	更突出的方向	适合的默认场景
Iceberg	开放规范、多引擎、分析型 Lakehouse	通用分析数据湖、跨引擎共享
Paimon	Flink、CDC、流式更新、主键表、多模态	实时湖仓、Flink 主导、AI 数据扩展
Hudi	Upsert、增量处理、索引和表服务	高频更新、增量数据管道
Delta Lake	Spark/Databricks、协议与运行时协同	Databricks 或 Spark 强生态

一种常见的收敛方式是：

Iceberg 作为通用开放分析表，Paimon 作为实时更新、CDC 和多模态表；Hudi、Delta 按客户和现有生态提供兼容。

七、第六阶段：AI Native 与多模态数据——解决“数据不再只是行列”的问题

1. 数据模型发生变化

传统大数据主要处理：

1

number / string / timestamp / row / column

AI 场景则需要处理：

1
2
3
4
5
6
7
8


结构化字段
+ 文本
+ 图片
+ 视频
+ 音频
+ 文档
+ Embedding / Vector
+ 模型与推理结果

一条数据可能同时包含业务字段、对象存储中的图片、向量表示和文本描述。

2. 查询方式发生变化

传统查询主要是：

1

SQL Filter + Join + Group By

AI 数据查询逐渐变成：

1
2
3
4
5


SQL
+ Full-text Search
+ Vector Search
+ Semantic Search
+ Model Inference

Paimon 当前文档已经把标量、文本、向量和 Blob 放到统一多模态表 API 中，并支持图片、视频、音频、向量和全文内容；Hudi 也在继续扩展向量、二进制对象和半结构化数据能力。¹²

3. 计算资源发生变化

1
2


传统大数据：CPU + Memory
AI 平台：CPU + GPU + HBM + RDMA + Local NVMe

Ray 成为 AI 分布式计算的重要代表，它为 Python 和 AI 应用提供从单机扩展到集群的统一计算框架，并覆盖数据处理、训练、调优和服务等场景。¹³

4. 代表性开源产品

领域	代表产品
AI 分布式计算	Ray、PyTorch、JAX、DeepSpeed
AI 数据处理	Ray Data、Spark、Paimon/Hudi 多模态能力
向量检索	Milvus、Qdrant、Weaviate、pgvector
模型推理	vLLM、SGLang、Triton、KServe、Ray Serve
K8s AI Runtime	KubeRay、Volcano、Kueue、GPU Operator

5. 代表性商业产品和托管服务

Anyscale
Zilliz Cloud
Databricks AI / Mosaic AI
Snowflake Cortex AI
Amazon SageMaker
Google Vertex AI
Azure AI
NVIDIA AI Enterprise

6. 它解决了什么

统一处理结构化与非结构化数据；
把向量、Blob、文本和业务字段关联起来；
支持大规模 AI 数据预处理和 GPU 任务；
连接 Lakehouse、RAG、模型训练和推理；
推动 Data Platform 演化为 Data + AI Platform。

7. 它又引入了什么新问题

GPU、网络和存储成本很高；
AI 数据集反复读取，对缓存和吞吐要求极高；
模型、向量、Blob、元数据和表之间需要一致管理；
AI 引擎和表格式仍处于高速演进期；
调度需要考虑 Gang、GPU 拓扑、配额、排队和抢占；
数据安全从表和列扩展到模型、向量和非结构化文件。

八、六个阶段之间不是替代关系，而是分层叠加

六阶段不能简单画成：

1
2
3
4


Hadoop 被 Hive 淘汰
Hive 被 Spark 淘汰
Spark 被 Kubernetes 淘汰
Kubernetes 被 Lakehouse 淘汰

正确的理解是：

flowchart BT
    S["存储层\nHDFS / Object Storage / Ozone / JuiceFS"]
    R["Resource Runtime\nYARN / Kubernetes"]
    C["计算层\nSpark / Flink / MPP / Trino / Ray"]
    T["数据抽象层\nIceberg / Paimon / Hudi / Delta"]
    A["AI 与多模态层\nVector / Blob / Model / RAG"]

    S --> C
    R --> C
    C --> T
    T --> A

一套现代系统可以同时使用第一、第三、第四、第五和第六阶段的技术，例如：

1
2
3
4
5


HDFS
+ Kubernetes
+ Spark / Flink
+ Iceberg / Paimon
+ Ray / Vector / Blob

或者：

1
2
3
4


Object Storage
+ YARN
+ Spark / Flink
+ Hudi / Delta

因此：

HDFS 不等于只能承载旧 Hadoop 技术。
Kubernetes 不等于必须使用对象存储。
YARN 不等于必须绑定 HDFS。
表格式不替代 Spark/Flink，而是服务于计算引擎。
AI 多模态建立在已有存储、计算和表格式之上。

计算层逐渐收敛，而底层仍有较大差异

计算领域目前已经形成较稳定的代表性产品：

计算类别	代表性产品
通用批处理 / SQL	Spark
有状态流处理	Flink
实时 MPP / OLAP	StarRocks、ClickHouse
联邦与交互式 SQL	Trino
AI 分布式计算	Ray
事件流平台	Kafka、Pulsar

真正差异仍然很大的主要是两个基础维度：

Resource Runtime：YARN、Kubernetes 或其他运行环境；
Storage：HDFS、分布式文件系统、对象存储、对象存储之上的文件语义层，以及本地高速缓存。

对存量 Hadoop 集群来说，HDFS + YARN 仍可继续承载现代 Spark/Flink/Lakehouse；但对新建 Data + AI Platform 来说，Kubernetes 的通用性和 AI 生态优势更加明显。

第二部分：从零建设现代大数据平台，应当如何设计

九、总体原则：不是把所有开源项目都装一遍

新建平台最容易出现的错误，是把“生态完整”误解成“组件越多越好”。

现代平台应遵循几个原则：

Kubernetes First：统一资源、部署和生命周期底座。
一个领域一个主产品：可以兼容多个产品，但不要全部作为主力运营。
存储尽量收敛：不要同时维护 HDFS、Ozone、CephFS、JuiceFS、Alluxio、MinIO、RustFS 和多个对象存储。
本地热数据与远端持久数据分层：Local NVMe 负责 Shuffle、State、Cache 和 Spill；远端存储负责持久化。
接口优先：S3、POSIX、Hadoop FileSystem、SQL、OpenTelemetry、OCI 等标准接口比单个产品更重要。
先解决明确问题，再增加组件：Celeborn、Tempo、Ranger、Trino 等都应按需求引入，而不是默认全装。
兼容不等于产品化：平台可以兼容四种表格式，但只重点产品化一到两种。

十、推荐的整体架构

flowchart TB
    U["用户与应用\nSQL / ETL / BI / Streaming / ML / AI / RAG"]

    WF["工作流编排\nAirflow 或 Argo Workflows"]
    ING["数据采集与集成\nSeaTunnel / Flink CDC / Debezium / Kafka Connect"]
    BUS["事件与传输主干\nKafka 或 Pulsar"]

    subgraph COMPUTE["计算层"]
        SP["Spark\nBatch / SQL"]
        FL["Flink\nStreaming / CDC"]
        MPP["StarRocks 或 ClickHouse\nMPP / OLAP"]
        TR["Trino（可选）\nFederated SQL"]
        RAY["Ray\nAI Compute"]
    end

    subgraph TABLE["表与数据抽象层"]
        ICE["Iceberg"]
        PAI["Paimon"]
        HUDI["Hudi（兼容/按需）"]
        DELTA["Delta（兼容/按需）"]
    end

    subgraph STORAGE["收敛后的存储体系"]
        NVME["Local NVMe + emptyDir\nShuffle / State / Cache / Spill"]
        JFS["JuiceFS CSI / PVC\nPOSIX / Hadoop FS"]
        META["TiKV 或 MySQL/PostgreSQL\nJuiceFS Metadata"]
        OBJ["Ceph RGW 或 RustFS\nS3 Compatible Object Storage"]
    end

    subgraph RUNTIME["Resource Runtime"]
        K8S["Kubernetes"]
        QS["Volcano 或 Kueue（按需二选一）"]
        OP["Spark / Flink / Ray 等 Operators"]
    end

    subgraph OBS["可观测性"]
        PROM["Prometheus"]
        GRA["Grafana + Alerting"]
        OTEL["OpenTelemetry Collector"]
        FB["Fluent Bit"]
        LOKI["Loki"]
    end

    subgraph SEC["安全"]
        IDP["OIDC / Keycloak + LDAP/AD"]
        RBAC["K8s RBAC + Engine RBAC"]
        SECRET["Secrets / KMS / TLS / NetworkPolicy"]
    end

    subgraph DELIVERY["平台交付"]
        GIT["Git + CI"]
        HARBOR["Harbor"]
        HELM["Helm"]
        ARGOCD["Argo CD"]
    end

    U --> WF
    U --> ING
    ING --> BUS
    BUS --> COMPUTE
    WF --> COMPUTE
    COMPUTE --> TABLE
    COMPUTE --> NVME
    TABLE --> JFS
    TABLE --> OBJ
    JFS --> META
    JFS --> OBJ
    LOKI --> OBJ

    K8S --> QS
    K8S --> OP
    OP --> COMPUTE

    PROM --> GRA
    OTEL --> PROM
    FB --> LOKI

    IDP --> RBAC
    GIT --> HARBOR
    GIT --> HELM
    HELM --> ARGOCD
    ARGOCD --> K8S

十一、Resource Runtime：新建平台默认选择 Kubernetes

1. 为什么不再把 YARN 作为新平台默认底座

YARN 仍然适合存量 Hadoop 集群，也仍被 Spark/Flink 正式支持。但它的天然覆盖范围主要是数据计算作业。

Kubernetes 可以同时运行：

Spark、Flink、Ray；
Kafka、Pulsar；
StarRocks、ClickHouse、Trino；
数据库和缓存；
API、Web 服务和平台控制面；
GPU 训练、推理、模型服务和 Agent；
Prometheus、Loki、Harbor、Argo CD 等平台组件。

因此，新建平台的默认判断可以是：

1
2
3


存量 Hadoop：YARN 可以继续使用
新建 Data Platform：Kubernetes 优先
新建 Data + AI Platform：Kubernetes 应作为默认选择

2. 必须区分三种“调度”

层次	核心问题	代表产品
工作流编排	哪个任务先执行、什么时候执行、失败后怎么重试	Airflow、Argo Workflows
集群资源调度	Pod 使用哪些 CPU、内存、GPU 和节点	Kubernetes、Volcano、Kueue
引擎内部调度	一个 Job 内部的 Stage、Task、Operator 如何执行	Spark Scheduler、Flink Scheduler、MPP Scheduler

Airflow/Argo Workflows 不能替代 Kubernetes；Kubernetes 也不能替代 Spark/Flink 的内部调度。

3. Kubernetes 还需要什么增强

Kubernetes 原生调度足以覆盖大量普通工作负载，但大数据和 AI 可能需要：

Queue 与租户配额；
Fair Share；
Gang Scheduling；
Priority / Preemption；
GPU 拓扑与异构设备；
批任务排队和准入控制。

可以按需求在 Volcano 与 Kueue 中选择一个主方案，不建议默认同时维护两套。

Operator 则负责 Spark、Flink、Ray 等系统的声明式生命周期管理。

十二、存储：从“全都要”收敛为本地热层和统一持久层

1. 本地热层：Local NVMe + emptyDir

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


Kubernetes Worker
       │
   Local NVMe
       │
    emptyDir
       │
 ┌─────┼─────────┬─────────┐
 ↓     ↓         ↓         ↓
Shuffle State    Cache     Spill
Spark   Flink    Ray/MPP   Temporary Data

它的特点是：

延迟低、吞吐高；
不需要额外维护一个分布式存储产品；
适合临时数据，而不是唯一持久化副本；
Pod 或节点故障后可以丢失，业务必须能重算或从 Checkpoint 恢复。

工程上必须确保 emptyDir 的实际后端位于 NVMe/SSD，并配置 ephemeral-storage request、limit、容量水位和驱逐策略。仅仅在 YAML 中声明 emptyDir，并不能自动保证数据落到指定 NVMe。

2. 统一持久层：JuiceFS + Metadata Engine + Object Storage

推荐的收敛架构是：

1
2
3
4
5
6
7
8


                   JuiceFS
                      │
        ┌─────────────┴─────────────┐
        ↓                           ↓
    Metadata                       Data
        │                           │
 TiKV / MySQL / PostgreSQL    Ceph RGW / RustFS
                              S3-compatible Object

JuiceFS 把文件数据存入对象存储，把文件元数据存入独立的 Metadata Engine，并对上提供 POSIX、CSI/PVC 和 Hadoop FileSystem 等访问方式。¹⁴

Metadata Engine 如何选择

已有成熟 MySQL/PostgreSQL：可以复用，但要做好 HA、容量和事务性能评估；
需要分布式 KV 和更高元数据扩展：可以选择 TiKV；
不建议仅仅为了 JuiceFS 元数据而额外引入完整 TiDB SQL 层；如果企业已经有 TiDB，需要按照 JuiceFS 的正式兼容方式做验证，而不能只因为它兼容 MySQL 协议就默认完全等价。

Object Storage 如何选择

方案	优点	代价
Ceph RGW	S3 接口成熟；同一个 Ceph 还可提供 RBD，便于数据库类 PVC	Ceph 本身较重，规划、升级和故障处理要求高
RustFS	专注 S3-compatible Object Storage，架构相对纯粹	仍需单独解决 TiKV、PostgreSQL 等 Stateful 服务的块存储或 Local PV 问题
公有云 S3/OSS/GCS/Blob	不自建底层存储，弹性和可靠性由云服务承担	成本、网络、数据主权和供应商依赖需要评估

Ceph RGW 提供 S3-compatible 接口；RustFS 也把自己定位为面向 S3 工作负载的分布式对象存储。¹⁵¹⁶

3. 为什么不默认同时建设很多存储

新平台通常不应同时部署：

1

HDFS + Ozone + CephFS + JuiceFS + Alluxio + 多套 S3

这会产生：

多套监控和告警；
多套数据修复与扩容流程；
多套权限模型；
多套升级和兼容矩阵；
数据在不同系统间重复；
故障定位复杂。

更合理的初始方案是：

1
2
3
4


Local NVMe
+ JuiceFS
+ 一个 Metadata Engine
+ 一个 Object Store

HDFS 作为存量兼容和数据迁移来源存在，而不是新平台必须重新建设的默认存储。

4. 对象存储可以被多个平台组件共享

通过不同 Bucket、租户、密钥、生命周期和配额隔离，同一套对象存储可以承载：

1
2
3
4
5
6


lakehouse-data
juicefs-data
loki-logs
tempo-traces
workflow-artifacts
backup

共享物理底座不等于共享权限和故障域，仍需要独立 Bucket、访问策略、配额、版本控制和灾备策略。

5. Shuffle 也可以进一步解耦，但不应第一天就上

初始阶段：

1
2
3


Spark/Flink Batch
       ↓
Local NVMe + emptyDir

当出现以下问题时，再考虑 Apache Celeborn 等 Remote Shuffle Service：

Spark Executor 经常弹性扩缩；
节点经常被释放或抢占；
Shuffle 数据规模达到 TB/PB 级；
本地磁盘容量成为作业失败主因；
多引擎希望共享统一 Shuffle 基础设施。

Celeborn 当前支持 Spark，并对 Flink Batch 提供 Remote/Hybrid Shuffle 集成；Flink Streaming 的 Pipelined Exchange 与批 Blocking Shuffle 仍需要区别理解。¹⁷

十三、计算层：按领域选择标杆产品，不再建设“技术博物馆”

1. 推荐的计算产品线

领域	推荐主产品	说明
通用批处理 / 大规模 SQL	Spark	数据工程、批处理、SQL、机器学习预处理
有状态流处理	Flink	实时流、Event Time、State、Checkpoint、CDC
实时 MPP / OLAP	StarRocks 或 ClickHouse	二选一作为主力，避免重复产品化
联邦与数据湖交互式 SQL	Trino（可选）	需要跨多数据源查询时引入
AI 分布式计算	Ray	数据预处理、训练、调优、分布式 Python 和服务

StarRocks 是典型 MPP 分析数据库，并同时提供 Shared-Nothing 和 Shared-Data 架构；Trino 更适合无存储或弱存储绑定的分布式 SQL 与联邦查询，二者不能简单视为同类产品。¹⁸¹⁹

2. 旧产品如何处理

以下产品可以保留历史兼容，但不应成为新平台默认主产品：

MapReduce API
Pig
Storm
Oozie
Sqoop
Mesos

这不是说它们完全不能使用，而是它们所解决的核心需求已经有更成熟、更统一的替代方案。

3. 计算与底层高度解耦，但性能并非完全无关

Spark、Flink、Ray 和表格式都可以通过标准接口访问不同存储，但不同存储的以下特征仍会向上传导：

Range Read 和顺序吞吐；
Metadata 和 List 延迟；
Rename、Append 和一致性语义；
小文件行为；
本地性和缓存命中；
网络带宽和故障恢复。

因此更准确的说法是：

架构和接口已经解耦，但性能、成本和故障特征仍然耦合。

十四、表格式：支持四种，但只重点运营一到两种

Catalog、Metadata 与 Governance 的边界

本文把完整的数据目录、血缘、质量、资产门户和数据治理放入“数据中台”范围，不作为大数据计算平台的完整产品边界。

但是必须保留一个技术边界：

Iceberg、Paimon、Hudi、Delta 的运行仍然需要最小的技术型 Catalog、Metastore 或提交协调能力。

因此可以这样拆分：

能力	所属范围
表地址、Namespace、Schema、Snapshot、提交指针	大数据平台的技术依赖
数据资产门户、业务术语、血缘、质量、分级分类、治理流程	数据中台 / 数据治理平台

不能因为 Governance 不在大数据平台范围，就完全忽略表格式运行所需的 Catalog。

十五、数据采集与集成：按数据类型选工具，但仍要收敛

1. 可选组件

场景	可选组件	特点
批量文件、数据库、API、跨系统同步	Apache SeaTunnel	连接器多，覆盖 Batch、Streaming、CDC，多执行引擎
数据库全量 + 增量同步	Flink CDC	与 Flink 结合紧密，支持 Schema Evolution、转换和 Exactly-Once 管道
数据库变更捕获	Debezium	专注 CDC，常与 Kafka Connect 配合
Kafka 生态 Source/Sink	Kafka Connect	连接 Kafka 与外部系统的标准框架
日志采集	Fluent Bit	轻量日志 Agent，本文单独归入可观测性
复杂流程化数据搬运	Apache NiFi（可选）	可视化 Flow 与边缘/协议集成能力较强

SeaTunnel 是面向多种数据工作负载的数据集成平台；Flink CDC 用 YAML 等方式描述实时数据集成管道；Debezium 专注于低延迟 CDC；Kafka Connect 则负责 Kafka 与外部系统之间的可复用连接器。²⁰²¹²²²³

2. 推荐收敛方式

不要默认同时把所有工具做成主力：

如果平台以 Flink 为实时核心，可优先 Flink CDC；
如果需要大量异构 Source/Sink 和批流一体同步，可优先 SeaTunnel；
如果已有成熟 Kafka Connect 生态，可采用 Debezium + Kafka Connect；
其他工具作为连接器补充和兼容，而不是重复建设三套任务管理平台。

十六、消息与传输层：Kafka 与 Pulsar 二选一作为主干

Kafka 和 Pulsar 都属于事件、消息和流数据的持久传输层，不是 Flink 的替代品。

1
2
3
4
5
6
7


Source
  ↓
Kafka / Pulsar
  ↓
Flink / Spark / Consumer
  ↓
Paimon / Iceberg / StarRocks

Kafka 官方定位为分布式 Event Streaming Platform；Pulsar 则定位为云原生的分布式 Messaging and Streaming Platform，并采用分层架构。²⁴²⁵

选择	更适合的条件
Kafka	生态成熟度、连接器、团队经验和兼容性优先
Pulsar	强多租户、跨地域复制、消息与流统一、计算存储分层需求突出

新平台应选一个作为默认 Event Backbone。除非有明确业务隔离或迁移要求，不建议长期并行运营两套同等规模的消息系统。

十七、工作流编排：Airflow 与 Argo Workflows 选择一个主系统

Airflow 与 Argo Workflows 都可以编排 Spark、Flink、Ray 和容器任务，但侧重点不同。

维度	Airflow	Argo Workflows
工作流定义	Python DAG	Kubernetes CRD / YAML、SDK
数据 ETL 生态	强	中等
外部系统 Provider	丰富	更多依赖容器或模板
Kubernetes 原生程度	中等	很强
AI / 容器任务	强	很强
平台对象模型	Airflow 自身对象	Kubernetes API 对象

Airflow 官方定位是编写、调度和监控工作流的平台；Argo Workflows 则是 Kubernetes 上的容器原生工作流引擎。²⁶²⁷

建议：

数据仓库、SQL、ETL 和大量外部系统连接器为主：Airflow 优先；
Kubernetes、容器任务、AI Pipeline 为主：Argo Workflows 优先；
第一阶段不要默认同时维护两套；确实出现明显分工后再考虑并存。

还要特别区分：

1
2


Argo Workflows：运行任务和 DAG
Argo CD：根据 Git 交付和同步 Kubernetes 应用

十八、安全体系：从 Kerberos 中心转向统一身份、分层授权

1. 传统 Hadoop 安全体系

1
2
3
4
5


OpenLDAP / AD
      ↓
Kerberos Authentication
      ↓
Ranger Authorization + Audit

它在传统 HDFS、Hive、HBase 和 Kafka 环境中仍然有效，但 Keytab、Ticket、KDC、SPNEGO、跨 Realm 和时间同步使其运维复杂。

2. 现代平台推荐架构

1
2
3
4
5
6
7


LDAP / AD
    ↓
Keycloak 或企业 IdP
    ↓ OIDC / OAuth2 / SAML
Kubernetes / Grafana / Airflow / Platform UI
    ↓
K8s RBAC + Engine RBAC + Object Policy

Kubernetes 原生支持 OIDC/JWT 等外部身份集成，并通过 RBAC API 进行资源授权；Keycloak 可以连接外部 OIDC/SAML IdP 和用户目录。²⁸²⁹³⁰

3. 安全能力应至少包括

层次	建议能力
身份	OIDC、Keycloak、LDAP/AD、SSO
K8s 资源授权	Namespace、Role、ClusterRole、ServiceAccount、Quota
数据授权	StarRocks/Trino/Kafka/Object Store 自身 RBAC 或 ACL
传统 Hadoop 兼容	Kerberos、Ranger 按需保留
Secret	Kubernetes Secrets、External Secrets、Vault/KMS 按需
网络	NetworkPolicy、Ingress、TLS、mTLS 按需
证书	cert-manager 或企业 PKI
审计	Kubernetes Audit、引擎访问审计、对象存储访问日志
供应链安全	Harbor 扫描、签名、镜像准入

Ranger 仍适合集中管理 Hadoop、Hive、HBase、Kafka 等系统的细粒度授权和审计，但不能假设它天然覆盖所有 Kubernetes、Lakehouse 和 AI 组件。³¹

推荐原则是：

统一 Identity，分层 Authorization；Kerberos 用于存量兼容，而不是新平台唯一入口身份。

十九、可观测性：Metrics、Logs、Traces 三条链路统一到 Grafana

1. 推荐组合

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


Metrics:
Exporter / OTel
      ↓
Prometheus
      ↓
Grafana + Alerting

Logs:
Fluent Bit
      ↓
Loki
      ↓
Object Storage
      ↓
Grafana

Traces:
OpenTelemetry SDK / Collector
      ↓
Tempo 或 Jaeger（按需）
      ↓
Grafana

Prometheus 是监控和时序数据系统；Grafana 可以查询、可视化并对 Metrics、Logs 和 Traces 告警；OpenTelemetry Collector 是接收、处理和导出 Telemetry 数据的厂商中立管道。³²³³³⁴

2. Metrics

建议至少覆盖：

Kubernetes Control Plane、Node、Pod、Container；
Spark Driver/Executor、Flink JM/TM；
Kafka/Pulsar Broker；
StarRocks/ClickHouse/Trino；
JuiceFS、TiKV、Ceph/RustFS；
Loki、Harbor、Argo CD、工作流系统；
GPU、NVMe、网络和对象存储请求。

Grafana Alerting 可以直接基于多个数据源配置告警。复杂的去重、抑制和通知路由需求出现后，可以增加或强化 Alertmanager；第一阶段无需为了“架构标准”重复建设多套告警控制面。

3. Logs

推荐采用：

1
2
3
4
5
6
7


Kubernetes / Hadoop / Platform Services
                 ↓
             Fluent Bit
                 ↓
                Loki
                 ↓
           Object Storage

Fluent Bit 内置 Loki Output，Loki 的可扩展模式可以把 Chunk 和索引数据放入对象存储。³⁵³⁶

如果已经确定 Fluent Bit 作为统一日志 Agent，就不要再让 OpenTelemetry Collector 重复采集同一批容器日志。OpenTelemetry 重点负责应用埋点、Trace 和部分 Metrics 即可。

4. Traces

OpenTelemetry 只负责标准、采集、处理和导出，不是 Trace 的最终存储。如果平台需要 API、控制面和任务提交链路追踪，应选择 Tempo、Jaeger 或商业后端；如果第一阶段主要关注基础设施和计算任务，可将 Trace Backend 设为可选组件。

二十、平台交付能力：Git + CI + Harbor + Helm + Argo CD

完整平台不仅要运行用户任务，还要持续交付几十个 Operator、Controller、服务和配置。

推荐链路：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


Source Code / Config
        ↓
       Git
        ↓
       CI
   Build / Test / Scan
        ↓
      Harbor
 Image / OCI Artifact
        ↓
       Helm
        ↓
      Argo CD
        ↓
   Kubernetes Cluster

Git：代码和声明式配置的事实来源；
CI：构建、测试、安全扫描和制品发布；
Harbor：管理镜像与 OCI Artifact，并提供 RBAC、扫描和签名能力；
Helm：Kubernetes 应用打包、版本和升级；
Argo CD：持续比较 Git 期望状态与集群实际状态并执行同步。³⁷³⁸³⁹

平台应尽量避免管理员直接手工修改生产集群；紧急变更也应最终回写 Git，避免 GitOps 状态长期漂移。

二十一、推荐的最小产品集合

下面是一套强调“组件尽量少，但覆盖 Data + AI”的参考组合。

层次	默认选择	备注
Resource Runtime	Kubernetes	平台统一底座
Batch / SQL	Spark	主力通用批计算
Streaming / CDC	Flink	主力流计算
MPP / OLAP	StarRocks 或 ClickHouse	二选一作为主力
Federated SQL	Trino，可选	有跨源联邦查询再引入
AI Compute	Ray	平台明确承载 AI 时启用
Event Backbone	Kafka 或 Pulsar	二选一
Table Format	Iceberg + Paimon	Hudi/Delta 兼容或按需
Local Hot Tier	Local NVMe + emptyDir	Shuffle、State、Cache、Spill
File Semantics	JuiceFS CSI/PVC	POSIX、共享文件、Hadoop FS
Metadata Engine	TiKV 或成熟 SQL DB	只选一个主方案
Object Storage	Ceph RGW 或 RustFS	或直接使用公有云对象存储
Remote Shuffle	Celeborn，可选	规模和弹性问题出现后再上
Data Integration	SeaTunnel / Flink CDC / Debezium + Kafka Connect	选一条主路线
Workflow	Airflow 或 Argo Workflows	不默认两套并行
Identity	Keycloak/OIDC + LDAP/AD	统一用户身份
Authorization	K8s RBAC + Engine/Object ACL	Ranger 按传统生态需要
Metrics	Prometheus	指标存储和查询
Visualization / Alert	Grafana	Dashboard 与告警
Telemetry	OpenTelemetry Collector	统一应用 Telemetry 管道
Logs	Fluent Bit + Loki + Object Storage	平台统一日志链路
Trace	Tempo/Jaeger，可选	有链路追踪需求再引入
Registry	Harbor	镜像和 OCI 制品
Package	Helm	应用打包和版本化
GitOps	Argo CD	平台组件持续交付

不建议第一阶段同时建设的组件

1
2
3
4
5
6


HDFS + Ozone + CephFS + JuiceFS + Alluxio
Kafka + Pulsar 双主干
Airflow + Argo Workflows 双主工作流
Iceberg + Paimon + Hudi + Delta 全部深度产品化
StarRocks + ClickHouse 双主 MPP
Volcano + Kueue 双主调度增强

平台应当能够兼容多个生态，但核心运维链路必须收敛。

二十二、建议的分阶段建设路线

阶段 A：先建设平台基础

Kubernetes 集群和节点分池；
网络、Ingress、DNS、证书和基础安全；
Local NVMe 与 emptyDir 规划；
对象存储、JuiceFS 和 Metadata Engine；
Prometheus、Grafana、Fluent Bit、Loki；
Harbor、Helm、Argo CD；
OIDC、RBAC 和 Secret 管理。

阶段 B：建设数据计算能力

Spark Operator、Flink Kubernetes Operator；
Kafka 或 Pulsar；
StarRocks 或 ClickHouse；
Iceberg、Paimon 与最小技术型 Catalog；
SeaTunnel、Flink CDC 或 Debezium/Kafka Connect；
Airflow 或 Argo Workflows；
统一任务 API、日志、指标和权限映射。

阶段 C：扩展 AI 和高级能力

KubeRay、Ray Data、Ray Train/Serve；
GPU Operator、Volcano 或 Kueue；
多模态表、Blob、Vector 和向量索引；
vLLM/KServe 等推理服务；
OpenTelemetry Trace 与 Tempo/Jaeger；
Celeborn Remote Shuffle；
更完善的多集群、灾备、成本和容量管理。

这种顺序可以避免第一期就维护大量没有实际负载验证的组件。

二十三、最终结论

大数据六阶段的核心逻辑不是替代，而是持续分层：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


分布式存储与批处理
        ↓
SQL 与数据平台抽象
        ↓
通用批流计算引擎
        ↓
云原生 Resource Runtime
        ↓
开放 Lakehouse 表格式
        ↓
AI 与多模态数据平台

历史上的 Hadoop 把存储、计算、资源、安全和运维紧密组织在一个生态中；现代平台则把这些能力拆成相对独立、标准化和可替换的层：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


                     Data + AI Platform
                             │
         ┌───────────────────┼───────────────────┐
         │                   │                   │
       Compute             Table                AI
 Spark/Flink/MPP       Iceberg/Paimon        Ray/Vector
         │                   │                   │
         └───────────────────┼───────────────────┘
                             │
                 Kubernetes Resource Runtime
                             │
       Local NVMe + JuiceFS + Unified Object Storage

如果今天从零建设一套现代大数据平台，推荐的总体方向是：

以 Kubernetes 作为统一 Resource Runtime；以 Local NVMe 作为热数据和临时数据层；以一个对象存储、JuiceFS 和一个 Metadata Engine 构成收敛的持久存储体系；以 Spark、Flink、一个 MPP 引擎、Ray 和 Kafka/Pulsar 覆盖主要计算与传输场景；以 Iceberg/Paimon 为主要数据抽象；再通过工作流、安全、可观测性和 GitOps 形成完整的平台。

这套平台不是简单地“把 Hadoop 搬到 Kubernetes”，而是把 Hadoop 时代强绑定的能力重新分层，最终形成一套能够同时支撑批处理、实时流、交互式分析、Lakehouse、AI 和多模态数据的 Kubernetes-native Unified Data + AI Platform。

参考资料：官方文档与项目页面

Apache Hadoop Modules：https://hadoop.apache.org/ ↩︎
Amazon EMR：https://aws.amazon.com/emr/ ↩︎
Apache Spark Cluster Mode Overview：https://spark.apache.org/docs/latest/cluster-overview.html ↩︎
Apache Flink Deployment Overview：https://nightlies.apache.org/flink/flink-docs-stable/docs/deployment/overview/ ↩︎
Kubernetes 官方网站：https://kubernetes.io/ ↩︎
Apache Flink Native Kubernetes：https://nightlies.apache.org/flink/flink-docs-stable/docs/deployment/resource-providers/native_kubernetes/ ↩︎
Apache Iceberg：https://iceberg.apache.org/ ↩︎
Delta Lake Documentation：https://docs.delta.io/ ↩︎
Apache Hudi：https://hudi.apache.org/ ↩︎
Apache Paimon：https://paimon.apache.org/docs/master/ ↩︎
Databricks Data + AI Platform：https://www.databricks.com/product/platform ↩︎
Apache Paimon Multimodal Table：https://paimon.apache.org/docs/master/multimodal-table/ ↩︎
Ray Overview：https://docs.ray.io/en/latest/ray-overview/index.html ↩︎
JuiceFS Architecture：https://juicefs.com/docs/community/architecture/ ↩︎
Ceph Object Gateway：https://docs.ceph.com/en/latest/radosgw/ ↩︎
RustFS Documentation：https://docs.rustfs.com/en ↩︎
Apache Celeborn Documentation：https://celeborn.apache.org/docs/latest/ ↩︎
StarRocks Architecture：https://docs.starrocks.io/docs/introduction/Architecture/ ↩︎
Trino Overview：https://trino.io/docs/current/overview.html ↩︎
Apache SeaTunnel：https://seatunnel.apache.org/ ↩︎
Apache Flink CDC：https://nightlies.apache.org/flink/flink-cdc-docs-stable/docs/get-started/introduction/ ↩︎
Debezium：https://debezium.io/ ↩︎
Apache Kafka Connect：https://kafka.apache.org/documentation/ ↩︎
Apache Kafka：https://kafka.apache.org/ ↩︎
Apache Pulsar：https://pulsar.apache.org/ ↩︎
Apache Airflow：https://airflow.apache.org/ ↩︎
Argo Workflows：https://argo-workflows.readthedocs.io/en/latest/ ↩︎
Kubernetes Authentication：https://kubernetes.io/docs/reference/access-authn-authz/authentication/ ↩︎
Kubernetes RBAC：https://kubernetes.io/docs/reference/access-authn-authz/rbac/ ↩︎
Keycloak：https://www.keycloak.org/ ↩︎
Apache Ranger：https://ranger.apache.org/ ↩︎
Prometheus Overview：https://prometheus.io/docs/introduction/overview/ ↩︎
Grafana Introduction：https://grafana.com/docs/grafana/latest/introduction/ ↩︎
OpenTelemetry Collector：https://opentelemetry.io/docs/collector/ ↩︎
Fluent Bit Loki Output：https://docs.fluentbit.io/manual/data-pipeline/outputs/loki ↩︎
Grafana Loki Storage：https://grafana.com/docs/loki/latest/configure/storage/ ↩︎
Harbor：https://goharbor.io/ ↩︎
Helm：https://helm.sh/ ↩︎
Argo CD：https://argo-cd.readthedocs.io/ ↩︎

从 Hadoop 到 Data + AI Platform：大数据平台六阶段演进与现代化建设方法

第一部分：大数据平台演进的六个阶段

一、六阶段总览

二、第一阶段：HDFS + MapReduce——解决“数据太大”的问题

1. 当时的核心问题

2. 代表性开源产品

3. 代表性商业产品和托管服务

4. 它解决了什么

5. 它又引入了什么新问题

6. 今天是否还有价值

三、第二阶段：Hive、Pig 与 Hadoop 生态——解决“分布式计算太难用”的问题

1. 当时的核心问题

2. 代表性开源产品

3. 代表性商业产品和托管服务

4. 它解决了什么

5. 它又引入了什么新问题

6. 今天是否还有价值

四、第三阶段：YARN + Spark + Flink——解决“计算模型和资源管理受限”的问题

1. 第一次解耦：资源管理与 MapReduce 分离

2. 第二次解耦：MapReduce 两阶段模型演化为 DAG 和 Stateful Stream

3. 代表性开源产品

4. 代表性商业产品和托管服务

5. 它解决了什么

6. 它又引入了什么新问题

7. 今天是否还有价值

五、第四阶段：Kubernetes 云原生时代——解决“统一运行、弹性与异构资源”的问题

1. Kubernetes 解决的并不是下一代 SQL 或计算模型

2. 代表性开源产品

3. 代表性商业产品和托管服务

4. 它解决了什么

5. 它又引入了什么新问题

6. Kubernetes 与存算分离的关系

六、第五阶段：Lakehouse 与开放表格式——解决“文件不是表”的问题

1. 当时的核心问题

2. 代表性开源产品

3. 代表性商业产品和托管服务

4. 它解决了什么

5. 它又引入了什么新问题

6. 今天如何看待四种表格式

七、第六阶段：AI Native 与多模态数据——解决“数据不再只是行列”的问题

1. 数据模型发生变化

2. 查询方式发生变化

3. 计算资源发生变化

4. 代表性开源产品

5. 代表性商业产品和托管服务

6. 它解决了什么

7. 它又引入了什么新问题

八、六个阶段之间不是替代关系，而是分层叠加

计算层逐渐收敛，而底层仍有较大差异

第二部分：从零建设现代大数据平台，应当如何设计

九、总体原则：不是把所有开源项目都装一遍

十、推荐的整体架构

十一、Resource Runtime：新建平台默认选择 Kubernetes

1. 为什么不再把 YARN 作为新平台默认底座

2. 必须区分三种“调度”

3. Kubernetes 还需要什么增强

十二、存储：从“全都要”收敛为本地热层和统一持久层

1. 本地热层：Local NVMe + emptyDir

2. 统一持久层：JuiceFS + Metadata Engine + Object Storage

Metadata Engine 如何选择

Object Storage 如何选择

3. 为什么不默认同时建设很多存储

4. 对象存储可以被多个平台组件共享

5. Shuffle 也可以进一步解耦，但不应第一天就上

十三、计算层：按领域选择标杆产品，不再建设“技术博物馆”

1. 推荐的计算产品线

2. 旧产品如何处理

3. 计算与底层高度解耦，但性能并非完全无关

十四、表格式：支持四种，但只重点运营一到两种

推荐策略

Catalog、Metadata 与 Governance 的边界

十五、数据采集与集成：按数据类型选工具，但仍要收敛

1. 可选组件

2. 推荐收敛方式

十六、消息与传输层：Kafka 与 Pulsar 二选一作为主干

十七、工作流编排：Airflow 与 Argo Workflows 选择一个主系统

十八、安全体系：从 Kerberos 中心转向统一身份、分层授权

1. 传统 Hadoop 安全体系

2. 现代平台推荐架构

3. 安全能力应至少包括