AI时代数据基础设施演进：从湖仓一体到向量检索与智能服务层-尧图网络科技

1. 从“存算”到“智算”：AI负载重塑数据基础设施的底层逻辑

最近和几个做数据平台和数据库内核的朋友聊天，话题总绕不开一个核心：AI。不是讨论哪个大模型又出了新版本，而是大家手头的活儿，从底层的存储、计算到上层的查询引擎，都在被AI工作流带来的新需求“推着走”。过去我们谈数据基础设施，核心是“存”和“算”——如何更高效地存储海量数据，如何更快地进行批量或交互式分析。但今天，当AI模型训练、推理、Agent应用成为业务的核心负载时，整个数据栈的需求图谱发生了根本性的偏移。这不再是简单的性能优化，而是一场从设计哲学到技术组件的系统性演进。

我理解这种演进，核心驱动力在于AI工作流与传统数据分析工作流在数据形态、处理范式、时效要求和资源消耗上的巨大差异。传统分析型数据库，比如我们熟悉的Apache Doris、ClickHouse，擅长处理规整的、结构化的表格数据，通过高效的列式存储和向量化引擎，在聚合、筛选、关联查询上做到极致。但AI，特别是大模型相关的工作流，处理的数据对象复杂得多：它可能是海量的非结构化文本、图像、音视频，需要先经过Embedding转换成高维向量；也可能是模型训练过程中产生的海量中间状态（Checkpoint）、参数和日志；还可能是Agent执行时动态生成的、带有复杂逻辑状态的交互数据。这些数据对基础设施提出了三个新要求：对多模态数据的原生支持、对高吞吐和低延迟的混合需求、以及对弹性与成本更精细的管控。

因此，当我们探讨“AI成为主流负载后，数据基础设施将如何演进”时，我们实际上是在探讨一套全新的技术栈如何从萌芽走向成熟。这个演进路径，并非一蹴而就地替换掉现有系统，而是一个在现有坚实基础上，通过架构解耦、组件增强和生态融合，逐步构建“AI原生”能力的过程。接下来，我将结合当前业界的实践和趋势，拆解这场演进中的几个关键战场。

2. 架构演进：从“紧耦合”到“湖仓管一体”的智能化融合

传统的数据仓库或数据湖架构，在面对AI负载时常常显得力不从心。数仓强于分析，但对半结构化、非结构化数据支持弱；数据湖虽能存万物，但缺乏高效的管理和查询能力。AI工作流恰恰需要同时跨越这两个世界：既要对原始的多模态数据进行预处理和特征提取（湖的能力），又要对结构化的特征数据、样本数据进行高效地迭代训练（仓的能力），还要对模型、向量等新型数据资产进行统一管理和服务（管的能力）。这催生了“湖仓管一体”（Lakehouse + AI Governance）架构的兴起与深化。

2.1 解耦与分层：应对AI负载的复杂性

AI负载的复杂性首先要求架构上的清晰解耦。一个面向AI的现代数据平台，其底层逻辑正在从“一个系统解决所有问题”转向“一组专门化组件通过开放协议协同工作”。

存储层：对象存储（如S3、OSS）因其无限的扩展性和成本效益，已成为存储原始数据、训练数据、模型Checkpoint的绝对主力。但在其上，需要一层智能的“数据管理层”，这不仅仅是元数据管理，更是对数据版本、血缘、质量以及访问策略的全面管控。例如，使用类似Delta Lake、Apache Iceberg这样的开源表格式，可以在对象存储之上构建出具有ACID事务、模式演进、时间旅行等数据库特性的数据表，这对于需要可重复实验和追溯的AI训练流程至关重要。

计算层：计算与存储的分离已是共识。针对AI的不同阶段，计算引擎进一步专业化：

数据预处理与特征工程：Spark、Flink等批流一体引擎仍是主力，但其生态正在积极集成机器学习库（如Spark MLlib）和向量计算能力。
模型训练：专用AI框架（PyTorch, TensorFlow）及其分布式训练框架（如DeepSpeed, FSDP）主导。它们与底层资源调度器（Kubernetes）和存储系统的协同效率，直接决定了训练集群的利用率。
模型推理与向量检索：这是在线服务的关键，需要极低的延迟和高吞吐。专门的模型服务框架（如Triton Inference Server）和向量数据库（如Milvus, Weaviate）在此扮演核心角色。它们需要与上层的应用和下游的分析系统紧密集成。

查询与服务层：这是用户和应用程序与数据交互的界面。传统的分析型数据库（如Apache Doris）在此层的演进尤为关键。它不再仅仅是一个SQL查询引擎，而是需要演变成一个“智能数据服务网关”。这意味着它需要具备：

联邦查询能力：能够无缝查询存储在数据湖（通过Iceberg等）、关系数据库、乃至向量数据库中的数据，为用户提供统一的访问入口。
内置AI函数：提供原生的向量相似度搜索函数（如cosine_distance）、模型推理函数（如调用部署好的模型进行实时预测），使得在SQL中直接进行AI应用开发成为可能。
高性能对接：优化与向量数据库、模型服务之间的数据交换协议，减少网络开销和序列化成本。

实操心得：在架构选型时，切忌追求“大一统”的万能系统。正确的思路是优先定义清晰的层次和接口，选择在每个层次上表现最优、生态最活跃的开源或商业组件。例如，用对象存储+Iceberg做统一存储层，用Kubernetes统一调度计算任务（Spark作业、PyTorch训练任务），再用Apache Doris作为统一的查询与服务入口。这种组合的灵活性和可扩展性远胜于单一系统。

2.2 Apache Doris的定位演进：从分析数据库到智能数据服务层

以Apache Doris为例，我们可以清晰地看到一个经典MPP分析型数据库在AI浪潮下的演进思路。它没有试图自己去存储非结构化数据或训练模型，而是通过持续增强其“连接器”和“计算能力”，稳固自身作为“智能数据服务层”的核心地位。

核心增强方向一：全方位的数据湖对接。Doris社区近年来大力投入了对Iceberg、Hudi等数据湖表格式，以及Hive、Delta Lake的直接对接能力。通过Multi-Catalog功能，用户可以在Doris中直接创建外部数据目录，像查询本地表一样查询数据湖中的表，数据无需移动。这对于AI场景至关重要，因为特征数据往往首先沉淀在数据湖中。Doris负责提供高性能的SQL分析能力，而海量原始数据仍由成本更低的对象存储来承载。

核心增强方向二：向量化搜索与AI函数集成。这是Doris迈向“AI原生”的关键一步。新版本中，Doris引入了原生的向量数据类型（ARRAY<FLOAT>）以及一系列向量函数，如cosine_similarity,l2_distance。这意味着，你可以将Embedding生成的向量直接存入Doris，并通过SQL进行快速的近似最近邻（ANN）搜索。虽然专业的向量数据库在超大规模、高维向量的检索上仍有优势，但对于许多将向量搜索与复杂属性过滤、聚合分析结合的场景（例如，“找到与这张图片相似且价格低于100元、上架时间在一周内的商品”），Doris这种在单一系统中完成混合查询的能力，极大地简化了架构和开发复杂度。

核心增强方向三：作为模型推理与特征服务的统一入口。通过UDF（用户自定义函数）框架，Doris可以方便地集成外部模型服务。例如，你可以部署一个PyTorch模型服务，然后在Doris中创建一个UDF来远程调用该服务。这样，在数据查询和分析的流水线中，可以实时调用AI模型进行情感分析、欺诈检测、推荐评分等，实现真正的“分析智能一体化”。这避免了将数据导出到专门的应用系统进行处理的繁琐步骤，让AI能力更贴近数据。

3. 核心组件革新：向量数据库、模型仓库与数据流水线

在解耦的架构下，一些为AI而生的新型组件正从“可选”变为“必选”。它们的成熟度直接决定了AI数据基础设施的效能上限。

3.1 向量数据库：非结构化数据的“索引器”与“连接器”

向量数据库的核心价值，在于为高维向量数据提供了高效的存储、索引和检索能力。你可以把它理解为非结构化数据（文本、图片、音频）的“搜索引擎索引”。它的出现，解决了传统关系型数据库在处理向量数据时“查得慢”、“查不准”的痛点。

技术选型考量点：

索引算法：是采用HNSW（图算法，查询快但内存占用高）、IVF（倒排文件，适合大规模数据）、还是PQ（乘积量化，有损压缩）？这需要根据数据规模、维度、查询精度和延迟要求来权衡。通常，HNSW适合中小规模、对延迟极度敏感的场景；IVF-PQ适合超大规模数据集。
持久化与可扩展性：向量数据库是否支持数据持久化到磁盘？分布式扩展能力如何？是Shared-Nothing架构吗？这对于生产环境的稳定性和成本至关重要。
生态集成：是否支持与主流AI框架（如LangChain, LlamaIndex）轻松集成？是否提供了丰富的SDK和API？这决定了开发的便利性。
混合查询：能否在向量相似度搜索的同时，高效地过滤标量属性（如日期、类别）？这是许多实际应用场景的刚需。

注意事项：不要盲目追求向量数据库的极致检索性能。在很多场景下，如果向量数据规模在千万级以内，且需要与大量结构化数据关联分析，像Apache Doris这样增强了向量能力的分析型数据库可能是更简洁、更经济的选择。只有当向量数据量极大（十亿级以上）、检索性能成为绝对瓶颈时，才需要考虑引入独立的、专业的向量数据库，并仔细评估其带来的架构复杂性和运维成本。

3.2 模型仓库与全生命周期管理

模型本身成为了核心的数据资产和产出物。模型仓库（Model Registry）的作用类似于代码仓库（Git），但管理的是模型的版本、元数据、血缘和部署状态。

一个成熟的模型管理系统需要支持：

版本控制：跟踪模型代码、训练数据、超参数和权重的任意组合，确保实验的可复现性。
元数据管理：记录模型的性能指标（准确率、F1分数）、训练环境、数据血缘、创建者等信息。
阶段管理：清晰定义模型从“开发”、“测试”、“预生产”到“生产”的生命周期状态。
部署与服务：能够一键将指定版本的模型部署到推理服务器（如Triton）或边缘设备。

MLflow和Kubeflow是这一领域的主流开源选择。它们与CI/CD流水线、数据流水线的集成，是实现MLOps（机器学习运维）的关键。

3.3 智能化与自动化的数据流水线

AI对数据流水线的要求远超传统的ETL。它需要处理更复杂的数据转换（如图像增强、文本分词、向量化），并且对流水线的敏捷性、可观测性和弹性有更高要求。

演进趋势：

从ETL到ELT再到ETLT：数据先被快速加载（Extract & Load）到数据湖，然后在湖内进行转换（Transform），最后将高质量的特征数据加载（Load）到特征库或分析平台进行训练或服务。这种模式更适应AI场景下数据探索和迭代的灵活性。
特征平台的核心化：特征工程是AI项目的成败关键。特征平台负责特征的定义、计算、存储、服务和监控，确保线上推理和线下训练使用的是一致的特征数据，避免“训练-服务偏斜”。
流水线即代码与自动化编排：使用Airflow、Dagster、Prefect等工具将数据流水线定义为代码，实现版本化、可测试和自动化调度。流水线需要能够动态感知数据变化、模型性能衰减，并触发重新训练或数据回填。

4. 运维与成本：AI负载下的新挑战与应对策略

AI工作流，尤其是大模型训练，是众所周知的“资源吞噬兽”。如何在高性能、高可用和可控成本之间取得平衡，是数据基础设施团队面临的最大挑战。

4.1 弹性计算与异构资源调度

训练任务对GPU资源的需求是爆发式且不连续的。固定的GPU集群要么在任务间隙大量闲置，要么在任务高峰时排队等待。

应对策略：

云原生与Kubernetes：利用Kubernetes的弹性伸缩能力，结合集群自动伸缩器（Cluster Autoscaler）和GPU虚拟化技术，实现训练任务的按需创建和销毁。任务排队时自动扩容节点，任务结束后自动缩容，最大化资源利用率。
Spot实例/抢占式实例：对于容错性较高的训练任务（支持从Checkpoint恢复），可以大量使用云上的Spot实例（AWS）或抢占式实例（GCP, Azure），成本可能降低60%-90%。关键在于设计好检查点保存策略和任务重启机制。
混合部署与分级调度：将在线推理服务（延迟敏感）和离线训练任务（吞吐敏感）混合部署在同一集群，但通过Kubernetes的优先级、资源配额和节点亲和性等策略进行隔离和调度，实现资源“错峰使用”。

4.2 存储成本优化与数据生命周期管理

AI产生的数据量巨大，且不同数据的热度差异明显。训练用的原始数据集可能只需偶尔访问，而高频迭代的模型Checkpoint和线上服务的特征数据则需要毫秒级响应。

分层存储策略：

热层（Hot）：SSB或高性能云盘。存放正在被频繁访问的线上特征数据、高频查询的向量索引、以及当前活跃模型的参数。追求极致IOPS和低延迟。
温层（Warm）：标准云硬盘或高性能对象存储。存放近期的训练数据、历史特征版本、以及用于回溯分析的日志数据。平衡性能与成本。
冷层（Cold）：归档型对象存储或磁带。存放很少访问的原始历史数据、已完成项目的模型归档、合规要求的日志备份。成本最低。

关键在于实现数据在不同存储层之间的自动、策略化流动。例如，可以基于数据的最后访问时间、创建时间或业务标签，制定规则，自动将数据从热层迁移到温层再到冷层。

4.3 可观测性与全链路追踪

当问题发生时，在由数十个微服务和组件构成的复杂AI数据栈中定位根因，如同大海捞针。传统的监控指标（CPU、内存）已不够用。

需要构建的观测能力：

数据质量监控：监控特征数据的分布偏移、缺失率、异常值。一旦发现数据漂移，立即告警，因为这很可能导致模型性能下降。
模型性能监控：在线推理服务的预测延迟、吞吐量、错误率，以及业务指标（如推荐系统的点击率、转化率）的实时监控。
全链路追踪：一个用户请求从进入应用，到查询特征，到调用模型推理，再到返回结果，这整条路径的延迟分解。使用OpenTelemetry等标准，在Doris查询、向量检索、模型服务等各个组件中注入追踪信息，可以快速定位瓶颈是在数据库查询慢，还是向量检索耗时，或是模型推理卡顿。
资源利用率与成本归因：将云资源消耗（计算、存储、网络）精确地归因到具体的业务部门、项目甚至个人，实现成本的可视化和可控化。

5. 未来展望：Agent与自治化系统的基础设施需求

AI Agent的兴起，将数据基础设施的挑战推向了一个新高度。Agent不是单次调用的模型，而是具有记忆、规划和工具使用能力的持续运行的智能体。这对数据基础设施提出了“状态管理”和“实时交互”的新要求。

可能的基础设施演进方向：

Agent状态数据库：需要一种新型的数据库或存储系统，专门用于高效存储和检索Agent的长期记忆（Long-term Memory）、工作记忆（Short-term Memory）、执行历史和工作流状态。它需要支持复杂的、嵌套的、半结构化的状态数据，并能进行高效的相似性搜索（例如，“找到与我当前处境类似的历史记忆”）。
实时数据流与复杂事件处理（CEP）：Agent需要实时感知环境变化（如市场数据、用户行为流），并做出即时决策。这要求底层的数据管道具备极低的端到端延迟，并且流处理引擎能够支持基于时间窗口和模式的复杂事件序列检测。
工具调用与API生态的集成层：Agent需要通过调用各种工具（搜索引擎、数据库、业务API）来完成任务。基础设施需要提供一个安全、可靠、可观测的“工具调用网关”，对Agent的每一次外部调用进行认证、鉴权、限流、审计和结果规范化。

这场由AI驱动的数据基础设施演进，本质上是数据栈为了适应一种全新的、更复杂、更动态的计算范式而进行的自我革新。它没有终点，而是一个随着AI技术本身不断迭代的持续过程。对于从业者而言，理解从“存算分离”到“湖仓管一体”，再到“智能数据服务层”和“AI原生组件”这条演进主线，保持架构的开放性和组件的可插拔性，远比追逐某个单一的热门技术更为重要。未来的赢家，将是那些能够最优雅、最高效、最经济地让数据在存储、处理、AI模型和最终应用之间自由流动的平台。