1. 从龙虾到数据：一场关于AI时代数据架构的深度思考

那天本来有个龙虾大餐的活动邀约，但我最终选择了参加Data For AI的技术分享会。这个决定背后是一个越来越清晰的认知：在AI时代，数据正在成为最核心的生产要素，而元数据则是这个要素的基石。正如我在开场时说的那句玩笑话："AI的燃料是数据，数据的燃料是元数据"——这句话看似调侃，却道出了当前技术演进的核心逻辑。

过去十年，我们见证了数据架构从传统数仓到数据湖，再到湖仓一体的演进。而现在，我们正站在一个新的转折点上：AI Agent的兴起正在彻底重构数据栈的设计理念和使用方式。这次活动让我深刻感受到，数据架构师的角色正在发生根本性转变——我们不再只是数据的"保管员"，更要成为AI系统的"营养师"。

2. AI Agent时代的数据架构革命

2.1 软件架构的三次进化

在Datastrato创始人堵俊平老师的分享中，我看到了软件架构演进的清晰脉络：

传统软件阶段（UI-Centric）：这是我们最熟悉的模式。用户通过界面操作系统，后端处理逻辑，前端展示结果。数据架构的核心是支持这种"命令-响应"模式，优化查询性能，确保报表生成效率。

AI Copilot阶段（Assisted interaction）：AI开始作为助手介入人机交互。典型代表是GitHub Copilot和各种代码补全工具。这个阶段，数据架构需要支持语义理解和上下文感知，但主动权仍在人类手中。

Agentic AI阶段（Agent-Centric）：这是真正的范式转变。AI Agent成为系统的主要接口，人类只需提供目标，Agent自主完成任务。这对数据架构提出了全新要求：

• 数据需要具备机器可读的语义
• 系统需要支持自主决策和任务分解
• 元数据需要提供足够的上下文和业务逻辑

2.2 数据架构的五大转向

面对Agent时代的挑战，数据架构正在发生五个根本性转变：

1. 从"人看"到"代理看"（Agent-driven Data Access）传统的数据可视化工具是为人类设计的，而Agent需要的是语义化的数据接口。这意味着我们需要：

   • 构建自然语言查询能力
   • 开发面向Agent的API
   • 优化语义检索性能

2. 元数据的语义化升级（Machine-readable Metadata）元数据不再只是数据字典，它需要：

   • 描述业务上下文和领域知识
   • 记录数据血缘和质量指标
   • 支持推理和决策

3. 自动化运维的闭环（Autonomous Data Operations）数据管道需要具备自愈和自优化能力：

   • 基于负载动态调整资源
   • 自动检测和修复数据问题
   • 优化数据新鲜度和成本

4. 全模态底座的融合（Multi-modal Data Platforms）结构化数据、向量和非结构化数据需要统一管理：

   • 支持跨模态关联查询
   • 优化多模态存储效率
   • 提供统一的访问接口

5. 治理模式的智能转型（Agent-aware Data Governance）安全合规需要适应Agent的工作方式：

   • 实时策略执行
   • 动态权限控制
   • 审计Agent行为

2.3 控制平面的崛起

在这些变化中，最引人注目的是"数据控制平面"概念的兴起。这个抽象层位于Agent和底层数据基础设施之间，提供：

• 统一目录服务：让Agent能发现和理解数据
• 元数据图谱：提供业务上下文和语义关系
• 多引擎协同：动态选择最佳执行引擎
• AI管道集成：支持数据到推理的端到端流程

这种架构实现了"逻辑统一，物理分散"的理想状态，让Agent能专注于业务目标，而不必操心底层复杂性。

3. 腾讯TBDS：AI时代的多模态数据湖实践

3.1 TBDS整体架构

腾讯大数据套件TBDS（Tencent Big Data Suite）展示了企业级多模态数据湖的完整实现。其核心组件包括：

• 存储层：支持HDFS、Iceberg和新兴的Lance格式
• 计算引擎：集成Spark、Flink、Presto、StarRocks等
• 元数据服务：统一管理各类数据资产
• 治理工具：提供血缘分析、权限控制等功能

3.2 Lance格式的创新

TBDS对Lance格式的深度集成特别值得关注。Lance是由前Pandas核心开发者创建的列式存储格式，专为AI场景设计：

• 存算分离架构：更易维护，成本优势明显
• 向量检索优化：支持高效的相似性搜索
• 多模态支持：统一管理结构化数据和向量

在实际测试中，Lance在千万级向量数据上的检索性能比传统方案快3-5倍，同时存储空间节省约40%。

3.3 Ray的增强集成

TBDS另一个亮点是对Ray框架的深度集成：

• 混合调度：支持跨K8s集群的CPU/GPU资源管理
• 弹性扩展：根据负载动态调整计算资源
• 多模态流转：优化数据在各类处理引擎间的流动

这种设计特别适合AI训练和推理场景，可以实现计算资源的精细化管控。

3.4 Gravitino的元数据统一

TBDS通过集成Gravitino实现了异构数据源的统一管理：

• 标准化接口：提供REST API访问各类数据
• 统一目录：打破数据孤岛
• 权限整合：集中管理访问控制

在实际部署中，这种方案将元数据管理效率提升了60%，同时降低了30%的运维成本。

3.5 Lakekeeper的智能治理

TBDS-Lakekeeper提供了完整的AI数据湖治理方案：

1. 自动化索引

   • 无人值守的IVF/HNSW向量索引构建
   • 实时统计和健康度评估
   • 持续覆盖保证

2. 表优化治理

   • 自动清理旧版本
   • 小文件合并
   • 存储空间回收

3. 高性能架构

   • 基于Ray的分布式计算
   • Lance检索服务常驻
   • 统一存储加速

在实际生产环境中，Lakekeeper帮助某客户将存储成本降低了35%，查询性能提升了2倍。

3.6 TBDS的AI湖仓架构

TBDS的完整架构可以从三个维度理解：

核心底座：

• 多模态存储：TBDS-FS + Iceberg + Lance
• 多模态元数据：表、函数、文件集、模型统一管理
• 多模态计算：数据引擎与AI引擎融合

治理服务：

• MetaService统一元数据
• Lakekeeper自动化治理
• 开放API生态

应用场景：

• 传统BI和数据工程
• Data Agent支持
• AI增强分析

4. OPPO的多模态数据湖实践

4.1 数据湖仓的演进路径

OPPO的分享展示了数据湖仓的典型发展路径：

1. 原始数据湖：简单存储，有限治理
2. 湖仓一体：事务支持，ACID保证
3. AI湖仓：多模态支持，向量集成
4. 智能湖仓：Agent原生，自主运维

4.2 OPPO的架构设计

OPPO的多模态数据湖架构分为四层：

存储层：

• 结构化：Hive、Hudi、Trino
• 非结构化：Lance格式专为PDF、图片等设计

处理层：

• 统一元数据与治理
• 多模态算子引擎
• Spark批处理 + LanceDB向量计算
• 完整MLOps支持

检索层：

• 全文索引 + 向量索引
• 混合检索与重排序
• 效果评估体系

应用层：

• 全模态数据挖掘
• 算法开发平台
• 搜索服务

4.3 Gravitino的深度应用

OPPO通过Gravitino实现了：

• 统一元数据：Hive和Lance表统一管理
• 联邦查询：一条SQL关联结构化与非结构化数据
• 标准化对接：各类计算引擎无缝集成

在实际场景中，这种方案使跨模态查询开发效率提升了50%。

4.4 Curvine缓存加速

OPPO开源的Curvine分布式缓存解决了多模态数据的I/O瓶颈：

• 智能缓存：热数据预加载
• 索引加速：毫秒级检索响应
• 训练优化：Checkpoint写入加速
• 资源隔离：计算与存储解耦

性能测试显示，Curvine将模型训练的数据读取速度提升了3倍。

5. Apache Gravitino：AI原生的元数据平台

5.1 AI Agent的数据挑战

传统数据治理关注"物理孤岛"，而AI时代需要解决"语义对齐"问题：

• 模型微调：需要高质量的行业知识
• RAG流程：依赖实时索引和语义检索
• Agent行动：要求数据具备可操作性

5.2 Gravitino的架构设计

Gravitino采用分层架构：

连接层：

• 适配各类存储协议
• 统一四种核心资源：表、文件、模型、消息

对象模型：

• Metalake → Catalog → Schema → Entity
• 标准化实体：Table、Fileset、Model、Topic
• 独立元数据存储

接口层：

• 统一REST API
• 兼容Iceberg/Lance协议
• 计算引擎无需修改即可接入

功能层：

• 统一处理
• 统一治理
• 全局RBAC和安全审计

5.3 核心创新点

Gravitino的两个关键创新：

1. 虚拟文件系统(GVFS)：

   • 让AI框架无感访问异构存储
   • 位置透明性
   • 标准化文件操作

2. 多层级元数据模型：

   • 结构化与非结构化统一管理
   • 精细化权限控制
   • 完整血缘追踪

6. ScopeDB：云上实时数据分析新范式

6.1 模式演进：从刚性到即时

ScopeDB提出了"即时模式(Schema On The Fly)"的创新理念：

• 刚性模式：严格预定义，变更成本高
• 无模式：灵活但难以维护
• 即时模式：动态适应，平衡灵活与治理

6.2 云原生架构

ScopeDB的云原生设计体现在：

• 计算存储分离：弹性扩展
• 资源隔离：不同负载互不干扰
• 共享存储：S3/GCS作为唯一数据源
• 状态可选：无状态计算+可选缓存

6.3 Language Integrated Cabel API

这种创新API设计：

• 在应用代码中直接定义数据处理逻辑
• 消除中间件层
• 实现"数据即代码"
• 支持实时写入与分析

6.4 ScopeQL查询语言

ScopeQL的特点：

• 读写路径统一
• 操作符正交组合
• 原生表达式复用
• 关系代数基础

7. 思考与展望：AI Agent时代的数据架构师

参加完这次活动，我对数据架构的未来有几个关键观察：

1. 多模态融合成为标配：

   • 结构化与非结构化数据的界限正在消失
   • 向量检索将成为基础能力
   • 统一元数据层不可或缺

2. 语义理解能力至关重要：

   • 数据需要自带业务上下文
   • 元数据需要支持推理决策
   • 语义检索性能是关键指标

3. 自主运维成为趋势：

   • 数据管道需要自愈能力
   • 资源调度应该动态优化
   • 成本与性能需要自动平衡

4. Agent原生设计原则：

   • 为机器消费优化接口
   • 支持目标导向的数据访问
   • 确保治理策略的实时性

5. 云原生架构优势明显：

   • 弹性扩展应对不确定负载
   • 计算存储分离提升效率
   • 按需付费优化成本

作为数据架构师，我们需要重新思考自己的角色：

• 从数据建模师变为语义工程师
• 从ETL开发者变为AI管道设计师
• 从系统管理员变为自主运维专家

这次活动最让我兴奋的不是某个具体技术，而是看到了整个行业正在形成的共识：AI时代需要全新的数据栈。从腾讯的TBDS到OPPO的实践，从Gravitino到ScopeDB，不同的团队正在从不同角度解决相同的问题。

未来的数据架构将更加智能、更加自主、更加贴近业务目标。而作为这个变革的参与者和推动者，我们需要保持开放心态，持续学习，才能不被时代淘汰。