“如果我看得更远，那是因为我站在巨人的肩膀上。” —— 艾萨克·牛顿
在大语言模型、向量数据库和 AI 智能体的热潮中，我们很容易忘记：现代 AI 并非凭空出现。今天的 AI 革命建立在数十年基础设施工作之上——分布式系统、数据管道、搜索引擎和编排平台，这些都是在"AI Native"成为流行语之前就已存在的技术。
这篇文章致敬那些传统开源项目，它们成为了 AI 基础设施的隐形基石。它们本身不是"AI 项目"，但没有它们，我们今天所知的 AI 革命就不会存在。
演进之路：从大数据到 AI
| 时代 | 关注点 | 核心技术 | AI 关联 |
|---|---|---|---|
| 2000 年代 | 网络搜索与索引 | Lucene、Elasticsearch | 语义搜索基础 |
| 2010 年代 | 大数据与分布式计算 | Hadoop、Spark、Kafka | 规模化数据处理 |
| 2010 年代 | 云原生 | Docker、Kubernetes | 模型部署平台 |
| 2010 年代 | 流处理 | Flink、Storm、Pulsar | 实时 ML 推理 |
| 2020 年代 | AI Native | Transformers、向量数据库 | 建立在上面所有技术之上 |
大数据框架：数据引擎
在我们能够对 PB 级数据训练模型之前，我们需要存储、处理和移动这些数据的方法。
Apache Hadoop (2006)
GitHub: https://github.com/apache/hadoop
Hadoop 通过让分布式计算大众化，证明了普通硬件可以处理网络规模的数据集。其 HDFS 文件系统和 MapReduce 范式成为大数据处理的基石。
对 AI 的意义：
- 现代机器学习训练数据集存储在与 HDFS 兼容的存储中
- 基于 Hadoop 构建的数据湖成为训练数据仓库
- 证明了分布式计算可以水平扩展
Apache Kafka (2011)
GitHub: https://github.com/apache/kafka
Kafka 以其基于日志的架构重新定义了数据流。它成为全球企业实时数据流的神经系统。
对 AI 的意义：
- 机器学习模型的实时特征管道
- AI 智能体系统的事件驱动架构
- 流式推理管道
- 模型遥测和监控骨干网
Apache Spark (2014)
GitHub: https://github.com/apache/spark
Spark 将内存计算带入大数据，使迭代算法（如 ML 训练）能够规模化运行。
对 AI 的意义：
- MLlib 使数据工程师能够使用机器学习
- 模型训练的分布式数据处理
- Spark ML 成为大数据库机器学习的事实标准
- 证明了内存计算可以加速机器学习工作负载
搜索引擎：检索基础
在 RAG（检索增强生成）成为流行语之前，搜索引擎已经在解决规模化检索问题。
Elasticsearch (2010)
GitHub: https://github.com/elastic/elasticsearch
Elasticsearch 通过其分布式架构和 RESTful API 使全文搜索易于访问和扩展。它成为搜索的标准。
对 AI 的意义：
- 开创了分布式倒排索引结构
- 证明了搜索工作负载可以水平扩展
- 许多"AI 搜索"系统实际上在底层使用 Elasticsearch
- 查询 DSL 影响了现代向量数据库查询语言
OpenSearch (2021)
GitHub: https://github.com/opensearch-project/opensearch
当 AWS 分叉 Elasticsearch 时，它确保了搜索基础设施保持真正的开源。OpenSearch 继续着可访问、可扩展搜索的使命。
对 AI 的意义：
- 保持搜索的开源创新
- 2023 年添加了向量搜索功能
- 展示了社区分叉的韧性
数据库：从 SQL 到向量
从关系数据库到向量数据库的演变代表了范式转变——但两者都与 AI 相关。
铺路的传统数据库
- Dgraph (2015) - 图数据库，证明专门的数据结构能够实现新的用例
- TDengine (2019) - 用于物联网机器学习工作负载的时序数据库
- OceanBase (2021) - 证明 ACID 事务可以扩展的分布式数据库
对 AI 的意义：
- 证明专门的数据库引擎可以超越通用数据库
- 数据库内部技术（索引、分片、复制）现在应用于向量数据库
- 多模型数据库（图 + 向量 + 关系）正在成为 AI 应用的标准
云原生：运行时基础
当 Docker 和 Kubernetes 出现时，它们并非为 AI 而构建——但没有它们，AI 无法规模化。
Docker (2013) & Kubernetes (2014)
GitHub: https://github.com/kubernetes/kubernetes
Kubernetes 成为云原生应用程序的操作系统。其声明式 API 和控制器模式使其非常适合 AI 工作负载。
对 AI 的意义：
- 模型部署平台（KServe、Seldon Core）运行在 K8s 上
- GPU 编排（NVIDIA GPU Operator、Volcano、HAMi）扩展了 K8s
- Kubeflow 使 K8s 成为机器学习管道的标准
- 微服务模式支持模块化 AI 智能体架构
服务网格与无服务器
Istio (2016)、Knative (2018) - 服务网格和无服务器平台，证明了：
- 网络级可观察性适用于 AI 模型调用
- 零扩展是成本效益推理的必要条件
- 流量分割实现机器学习模型的 A/B 测试
对 AI 的意义：
- AI 网关模式从 API 网关 + 服务网格演变而来
- 无服务器推理平台使用 Knative 风格的自动扩展
- 可观察性模式（追踪、指标）现在是机器学习系统的标准
API 网关：从 REST 到 LLM
API 网关并非为 AI 设计，但它们成为 AI 网关模式的基础。
Kong、APISIX、KGateway
这些 API 网关解决了规模化限流、认证和路由问题。当大语言模型出现时，同样的模式适用：
AI 网关演进：
传统 API 网关 (2010 年代)
↓
限流 → 令牌桶限流
认证 → API 密钥 + 组织管理
路由 → 模型路由（GPT-4 → Claude → 本地模型）
可观察性 → LLM 特定遥测（令牌使用、成本）
↓
AI 网关 (2024)
对 AI 的意义：
- 证明了集中式 API 管理可以规模化
- 插件架构支持 LLM 特定功能
- 流量管理模式适用于提示路由
- 安全模式（mTLS、JWT）现在保护 AI 端点
工作流编排：管道骨干
数据工程需要管道。机器学习工程需要管道。AI 智能体需要工作流。
Apache Airflow (2015)
GitHub: https://github.com/apache/airflow
Airflow 通过其基于 DAG 的方法使管道编排易于访问。它成为 ETL 和数据工程的标准。
对 AI 的意义：
- 机器学习管道编排（特征工程、训练、评估）
- 证明了基于 DAG 的工作流定义可以规模化
- 提示工程管道使用 Airflow 风格的编排
- 调度器模式现在应用于 AI 智能体工作流
n8n、Prefect、Flyte
从 Airflow 基础演进而来的现代工作流平台：
- n8n (2019) - 具有 AI 功能的可视化工作流自动化
- Prefect (2018) - 面向机器学习的 Python 原生工作流编排
- Flyte (2019) - 面向机器学习/数据的 Kubernetes 原生工作流编排
对 AI 的意义：
- 多模态智能体需要工作流编排
- RAG 管道本质上是嵌入的 ETL 管道
- 提示链是基于 DAG 的编排
数据格式：湖屋基础
在我们能够对海量数据集进行训练之前，我们需要支持 ACID 事务和模式演进的格式。
Delta Lake、Apache Iceberg、Apache Hudi
这些表格式为数据湖带来了可靠性：
对 AI 的意义：
- 训练数据集需要版本控制和可重现性
- 特征存储使用 Delta/Iceberg 作为存储格式
- 证明"大数据"可以具有事务语义
- 模式演进处理机器学习特征漂移
隐形线索：为什么这些项目重要
所有这些项目有什么共同点？
- 它们首先解决了规模化问题 - AI 训练/推理需要水平扩展
- 它们证明了分布式系统可行 - 现代 AI 本质上是分布式的
- 它们创建了生态系统模式 - 插件系统、扩展点、API
- 它们建立了最佳实践 - 可观察性、安全性、CI/CD
- 它们培养了开发者习惯 - YAML 配置、声明式 API、CLI 工具
AI Native 连续体
现代"AI Native"基础设施没有取代这些项目——它建立在这些项目之上：
| 传统项目 | AI Native 演进 | 示例 |
|---|---|---|
| Hadoop HDFS | 分布式模型存储 | 数据集用 HDFS，检查点用 S3 |
| Kafka | 实时特征管道 | Kafka → 特征存储 → 模型服务 |
| Spark ML | 分布式机器学习训练 | MLlib → PyTorch 分布式 |
| Elasticsearch | 向量搜索 | ES → Weaviate/Qdrant/Milvus |
| Kubernetes | 机器学习编排 | K8s → Kubeflow/KServe |
| Istio | AI 网关服务网格 | Istio → 带有 mTLS 的 LLM 网关 |
| Airflow | 机器学习管道编排 | Airflow → 面向机器学习的 Prefect/Flyte |
我们为什么要从 AI 资源列表中移除它们
这篇文章致敬这些项目，但我们也要将它们从我们的 AI 资源列表中移除。原因如下：
它们不是"AI 项目"——它们是基础基础设施。
- Hadoop、Kafka、Spark 是数据工程工具，不是机器学习框架
- Elasticsearch 是搜索，不是语义搜索
- Kubernetes 是通用编排
- API 网关服务 REST/GraphQL，不仅仅是 LLM
但它们的存在并不影响其重要性。
通过移除它们，我们要承认：
- AI 有自己的生态系统 - Transformers、向量数据库、大模型运维
- 传统基础设施有自己的领域 - 数据工程、云原生
- 交叉点是创新发生的地方 - AI 原生数据平台、基于 K8s 的大模型运维
我们站立的巨人
下次当你：
- 在 Kubernetes 上部署模型
- 通过 Kafka 流式传输特征
- 使用向量数据库搜索嵌入
- 使用 Prefect 编排 RAG 管道
记住：你站在 Hadoop、Kafka、Elasticsearch、Kubernetes 和无数其他项目的肩膀上。它们铺设了我们现在行驶的道路。
未来：建造新的巨人
正如 Hadoop 和 Kafka 使现代 AI 成为可能，今天的 AI 基础设施将成为明天的基础：
- 向量数据库 可能成为所有搜索的新标准
- 大语言模型可观察性 可能演变为通用分布式追踪
- AI 智能体编排 可能重新发明工作流自动化
- GPU 调度 可能影响通用资源管理
循环继续。今天的巨人将成为明天的基础。
结语：感恩与延续
当我们清理 AI 资源列表以专注于 AI 原生项目时，我们不会忘记我们的起源。传统大数据和云原生基础设施使 AI 革命成为可能。
致 Hadoop 贡献者、Kafka 维护者、Kubernetes 贡献者和所有构建基础的人：谢谢。
你们的工作使 ChatGPT、Transformers 以及我们现在称之为"AI"的一切成为可能。
站在你们的肩膀上，我们看得更远。
致谢：这篇文章受到需要重构我们的 AI 资源列表的启发。这里提到的 27 个项目将被移除——不是因为它们不重要，而是因为它们值得有自己的类别：基石。
