数据基础设施与 AI 基础设施融合：湖仓一体的 AI 原生架构

为什么数据团队和 AI 团队总在互相迁就

很多公司里，数据平台和 AI 平台是两条并行的线。数据工程师维护 Hive、Spark、Flink，关心的是数据集成、ETL、指标口径；算法工程师则围着模型训练、特征工程、模型服务转，手里握着 Redis、HDFS、甚至自研的特征存储。两个团队用着不同的工具链，数据从仓库到模型训练环境要经过多次拷贝，特征计算逻辑在离线训练和在线推理时经常出现微小差异，排查起来两头推诿。这还不是最麻烦的——真正让人头疼的是，当模型需要回溯历史数据复现某个实验时，往往发现数据湖里的分区已经变了，或者某个特征的定义悄悄调整过，导致实验完全不可复现。

这种割裂的根源在于，过去数据基础设施和 AI 基础设施是独立演进的。数据仓库或数据湖主要面向 BI 报表、数据分析，而 AI 训练和推理的需求被当作“上层应用”来适配。但 AI 工程化越深入，就越发现这种适配是脆弱的。现在，湖仓一体（Lakehouse）架构的出现，加上 AI 原生理念的渗透，让这两个基础设施开始真正融合，而不是简单打通。

湖仓一体不是升级版数据湖

很多人把湖仓一体理解成“在数据湖上加了事务和 SQL 加速”，这其实只看到了表面。湖仓一体的核心意义在于，它让数据湖不仅能存储原始数据，还能像数据仓库一样提供 ACID 事务、Schema 约束、高性能查询，而这些能力对 AI 场景至关重要。比如，模型训练的数据集往往需要快照隔离，确保每次实验用的是同一份数据；特征工程需要读写的强一致性，否则训练出来的模型和线上实际使用的特征可能对不上。

以 Delta Lake 或 Apache Iceberg 这类湖仓格式为例，它们支持时间旅行（Time Travel），可以方便地回溯到某个历史版本的数据。这对于模型实验的可复现性来说，几乎是一个基础设施级别的保障。以前，算法工程师可能需要手动记录数据分区的快照时间，或者让数据团队专门导出一次数据集，现在只要在代码里指定一个版本号，就能读取到完全一致的数据。

但这还不够。当我们在湖仓之上构建 AI 工作时，需要的并不仅仅是“读得准”，还要“读得快”、“写得到处能用”。特征计算的逻辑往往是复杂的，可能涉及窗口聚合、实时特征拼接、 embedding 生成等。如果湖仓只提供批处理能力，那实时推理就无从谈起。所以，AI 原生的湖仓架构，必须将流批一体、实时计算、特征存储、模型服务这些能力纳入统一的设计中。

AI 原生需要哪些基础设施能力

这里要厘清一个概念：AI 原生不是把 AI 框架塞进数据平台，而是从数据全生命周期出发，重新设计那些支持模型训练、推理和治理的底层机制。具体来说，至少包含以下四个维度：

• 特征的一致性：离线训练和在线推理使用完全相同的特征计算逻辑，避免“训练-推理偏差”（Train-Serving Skew）。
• 数据的版本化：不只是代码需要版本管理，数据、特征、模型都需要有版本关联，能够快速回溯到任意一次实验的完整上下文。
• 实时性：越来越多的场景要求在线特征以毫秒级延迟提供，同时又要保证特征计算的准确性，这需要湖仓具备实时写入和快速读取能力。
• 治理与血缘：特征从原始数据到最终被模型消费，整条链路要可追踪，哪个模型依赖哪个特征，哪个特征依赖哪张表，必须清晰可查。

这些能力如果由不同组件拼凑，会带来巨大的运维成本和一致性问题。一个典型的例子是，某个推荐系统团队用 Spark 做离线特征计算，把结果导入 Redis 供在线服务使用。但 Redis 里的特征更新策略和离线计算的频率不匹配，导致线上模型看到的特征其实是几个小时前的，而离线训练时用的却是最新快照。这种不一致会让模型在线上表现大打折扣，排查起来却极其困难。

而湖仓一体架构下，可以设计一个统一的特征存储层，它既能在离线训练时提供高性能的批量读取，又能在在线推理时通过低延迟的 KV 接口提供实时特征。更关键的是，离线计算和在线服务的计算逻辑都定义在同一个描述文件中，由同一个引擎执行，从根本上消除了计算偏倚。

融合架构的工程难点

说起来清晰，做起来并不轻松。湖仓一体与 AI 基础设施的融合，在工程上至少有三道坎。

第一，性能的平衡。训练任务需要高吞吐的批量扫描，而在线推理需要低延迟的随机读取。同一份数据既要支持大宽表的全表扫描，又要支持根据主键快速查找，这需要湖仓底层有异构存储和索引能力。比如，Parquet 格式适合批量扫描，但对点查很不友好；如果引入 Delta Lake 的 Data Skipping 或 Iceberg 的 Partition Evolution，可以优化扫描，但随机读仍然需要借助额外的 Lakehouse 加速层（如 Alluxio 或本地 SSD 缓存）。

第二，数据一致性的边界。在实时特征场景下，特征数据可能来自流处理和批处理的混合，如何保证同一个特征在不同存储层级（比如对象存储和缓存）的一致性？如果在线推理依赖的特征刚刚写入湖仓，但尚未刷新到缓存，就会读到旧值。这需要设计一个统一的元数据服务，协调缓存失效和版本更新，比单纯的数据仓库要复杂得多。

第三，特征计算逻辑的复用。很多团队尝试用 Python UDF 或 Spark MLlib 定义特征逻辑，但离线训练和在线推理往往运行在不同的运行时环境里（比如一个跑在 Spark 上，一个跑在 C++ 推理服务里）。想让同一份逻辑同时运行在批处理和实时引擎上，要么用标准化的特征 DSL（如 Feast 的 Feature View），要么就得接受维护两套代码的代价，而后者很快就会让特征漂移重新出现。

几种典型融合路径对比

基于团队规模、技术栈和实时性要求，目前常见的融合路径可以归纳为以下三种：

这三条路径没有绝对的好坏，关键在于团队能否驾驭相应的复杂度。对于已有成熟数据湖，且特征工程团队较强的组织，湖仓加独立特征存储可能是最务实的起点。如果是从零开始构建大规模 AI 平台，那么直接采用 AI 原生的湖仓一体方案，后期避免技术债务的可能性更大。

一个具体的落地切入点

假设你们团队目前有一个基于 Hive 的数据仓库，算法工程师用 Spark 生成训练样本，手动把特征灌入 Redis，在线推理服务再读 Redis。这种情况下，融合的第一步往往不是推翻重来，而是引入湖仓格式，让数据本身具备版本化和事务能力。

首先，把 Hive 表迁移到 Delta Lake 表（或者 Iceberg），这个过程可以保持存储在同一对象存储上，只需要更新表的元数据。然后，利用 Delta Lake 的时间旅行和 Schema 演化特性，让训练任务在读取数据时显式指定版本：

spark.sql("CREATE OR REPLACE TEMP VIEW training_features AS " +
  "SELECT * FROM delta.`/data/feature_store/user_features` " +
  "VERSION AS OF 20240501")

这样一来，每次实验都可以固定到某个数据快照，复现问题变得简单很多。接着，可以搭建一个轻量级的特征注册服务，用 YAML 描述特征计算逻辑，并让离线训练和在线推理两个管线都基于这个描述生成代码。例如，通过 Feast 定义 Feature View：

user_features = FeatureView(
    name="user_features",
    entities=[user],
    ttl=timedelta(days=1),
    batch_source=DeltaSource(
        path="/data/feature_store/user_features"
    ),
   
)

这样，在线服务可以通过 Feast 的 SDK 直接获取最新特征，而离线训练时也能从同一份 Delta 源读取数据，并保证计算逻辑一致。虽然这仍然需要维护特征存储服务，但特征计算的代码已经统一，数据版本也纳入了湖仓的管理范畴。

当这套体系稳定后，再逐步把实时特征也接入湖仓，利用流处理引擎直接写入 Delta 表，让在线存储层通过 CDC 机制同步更新，从而把整个链路收敛到一套存储底座上。

从“打通”到“原生”的思维转变

很多团队在融合数据基础设施和 AI 基础设施时，容易陷入一个误区：认为只要把两边的工具链打通，就算大功告成。但真正的挑战不在于技术联通，而在于组织协作和设计哲学。如果数据工程师仍然只关心表结构，算法工程师仍然只关心模型指标，那么即使上了湖仓一体，特征仍然会漂移，模型仍然会退化。

AI 原生架构的核心，是让数据基础设施具备“AI 感知”能力。例如，特征的血缘可以自动关联到模型版本，当数据表发生 Schema 变更时，能够自动通知依赖该表的模型，并触发重新训练或评估。这种能力，要求数据平台和 AI 平台共享元数据，而不是各自维护一份割裂的元数据。

另一个常见误区是，认为实时特征就是要把所有特征都变成实时计算。实际上，大多数场景下，离线批量特征加上少量高频实时特征才能平衡性能和成本。湖仓一体提供了流批一体的能力，但并不意味着要滥用。很多团队在引入实时特征后，发现特征存储的写入压力剧增，却并没有带来显著的线上效果提升，反而增加了系统复杂度。所以，分清哪些特征需要实时，哪些可以容忍分钟级延迟，是设计时必须取舍的。

最后，别忘了模型血缘和数据血缘的打通。当模型上线后出现效果衰减，排错的起点往往是“这个模型用了哪些特征，这些特征又来自哪些原始表”。如果湖仓能够提供端到端的数据血缘，并且与 MLflow 或 Kubeflow 等模型管理工具联动，那么从数据质量问题到模型效果波动的定位，就可以在一个统一的视图里完成，而不是靠多个团队翻日志。

湖仓一体的 AI 原生架构，目前还处在一个快速演进的阶段，但方向已经清晰：数据不再只是模型的外挂，而是模型的一部分。把数据基础设施和 AI 基础设施当成一个整体来设计，而不是两个需要拼命打通的系统，这才是未来几年 AI 工程化的核心命题。