AI Native 数据平台 · 存储智能系列前言在过去两年我们清晰地看到产业中生成式 AI应用经历了两波关键节奏。第一波是模型能力外溢包括智能助手、harness coding、RAG应用遍地开花。第二波是围绕 AI 的业务流程重构小团队开始借助 Agent 重新设计产品、运营、合规和数据工作流。走到这一步真正拖慢 AI 价值释放的不再是模型不够聪明而是企业的数据、权限、流程和评估机制还没来得及为 AI 的连续作业做好配套。传统数据架构是为人类低频分析设计的如数据仓库搞定结构化实时报表数据湖兜住海量原始数据搜索服务负责大规模日志分析模型平台负责训练和推理。每个系统都能独立运转可一旦进入 Agent 场景要求就变了Agent 需要在同一条任务链路里跨系统检索、对比、决策、写回。于是原本各自安好的系统之间开始摩擦数据复制的链路越拉越长索引和原始数据逐渐脱节权限和血缘断断续续任务执行过程也找不到完整的审计轨迹GPU 和计算资源在数据等待中白白消耗。到了这个阶段企业才真正发现AI 应用看起来是在和模型打交道真正决定它能不能进生产的却是背后的数据架构。这也是本系列上一篇《计算智能》之后我们要继续讨论存储智能的原因——如果说计算智能解决的是 Agent 跑得快不快存储智能回答的则是Agent 手上到底有没有一套可靠、可随时取用的数据上下文。一个正在被反复印证的判断是未来几年企业会启动一轮大规模数据架构重构让数据从结构化表扩展到文本、图片、音视频、向量并存真正变得 Agent-Ready。存储智能新一代Agent-Ready多模态数据底座这场重构的目标将会非常明确让数据平台真正变得Agent-Ready能持续被 Agent 发现、理解、调用、验证、复盘。在过去数据平台服务对象是人客户普遍关心查询效率、存储成本、系统稳定性。而未来数据平台的关键则在于企业的数据底座能否被 AI Agent 持续、安全、低成本地调用。这意味着存储不再只是“把数据放下”的基础设施而要成为能够理解数据、组织数据、加速数据、治理数据并为 Agent 提供长期上下文治理的智能底座。搞清楚这一点就很容易理解存储智能的本质定义。存储智能并不是给传统存储加个加速缓存也不是换个更高效的存储格式它要求存储层承担起以前不属于它的职能理解元数据、感知上层任务、编排数据流向、统一管理多模态资产、承载 Agent 的工作上下文。直白地讲存储层不再只是一个放数据的地方它要变成 Agent 可以持续调用的企业记忆和行动底座。如果我们回看数据平台这二十多年演进的话实际上我们会发现其关键推动力很朴素——谁在消费数据底座就要长成什么样子。数据仓库时代消费者是企业管理者和数据分析师平台解决好结构化查询就行。在数据湖时代数据工程师和算法团队加入进来平台要同时吞吐海量原始数据。湖仓一体出现后大家想在开放存储上兼顾仓库级分析和湖上计算。实时 Lakehouse 把流批一体和秒级新鲜度补了进来。到现在Agent 成为了新的消费主体它不是一个坐着等报表的人也不只是跑一次训练就结束的模型而是一套会持续规划、检索、计算、生成、复盘的自动化工作流。业界开始把这一代面向 Agent 的架构称为 Agentic Lakehouse腾讯云将其落地为 AI 多模态 Lakehouse。对比维度传统 LakehouseAI 多模态 Lakehouse主要消费者BI 用户、数据工程师、批流计算任务Agent 工作流、RAG、训练推理、多模态应用核心数据形态结构化、半结构化、湖仓表结构化 多模态对象 向量 模型资产 记忆关键目标分析一致性、开放存储、多引擎访问上下文一致性、权限继承、任务可追溯、Agent 一处可取治理重点表级/字段级权限、血缘和元数据跨表、跨对象、跨向量、跨模型、跨 Agent 调用链路治理腾讯云存储智能布局TCLake 多模态智能数据湖基于上述理解AI 多模态 Lakehouse 不是对上一代架构的修补和升级它将在 Agent 的工作方式倒逼之下被重新定义。同时它也不要求企业推倒已有的对象存储、湖仓表、大数据引擎和 AI 工具而是在这些已有投资之上建立一层统一控制面让企业以渐进的方式走向Agent-Ready。在腾讯云新一代AI Native 大数据平台中把能力分成了系统智能、计算智能、数据智能与存储智能四个方向如果说系统智能让平台自治、计算智能让 Agent 跑得更快数据智能让 Agent 学会分析那么存储智能回答的关键问题是Agent 手上到底有没有一套可靠的、可随时取用的数据上下文。TCLake 作为 AI 多模态 Lakehouse正是这条链路里的数据底座。腾讯云 TCLake核心定位为新一代 AI多模态智能数据湖底座整体实现结构化与多模态数据的统一管理对接 Data 与 AI 双引擎生态。从TCLake的架构图来看它不是一个单一的存储系统而是一套从底层到应用层贯通的底座组合。底层对接对象存储 COS 和第三方存储其上湖仓一体层由 TCIceberg、TCLance、Volume 和 Model 构成。元数据层由 TCCatalog 统一管控实现多模态数据的统一控制面和上下文管理。加速层由 TCQA 提供计算感知、智能分层和缓存加速上层连接腾讯云大数据包括EMR、DLC、TCHouse、ES、Xpark等基础产品以及各类原生或第三方Agent 应用。TCLake 多模态智能数据湖产品布局1. TCCatalog多模态数据的统一控制面在TCLake中TCCatalog 管的是企业全量数据资产的入口。TCCatalog整体覆盖结构化表、半结构化数据、非结构化对象和 AI 模型资产跨源、跨平台、跨引擎都能访问。在物理存储层TCLake可以纳管 COS、第三方对象存储、腾讯云数据库产品、文件、FTP、AI 大模型和第三方 GenAI 平台在计算侧TCLake可以原生服务 Spark、EMR、TCHouse、DLC、TensorFlow、PyTorch、Xpark 和 Agent 应用。对 Agent 而言统一 Catalog 的意义远不止找到数据在哪整体还解决了这份数据的业务含义是什么、我应该用哪个口径、访问权限是否沿链路继承、调用上下文如何保留等一系列问题。TCCatalog提供统一 Catalog Service、REST API 和独立 Console负责多模态元数据管理、统一权限管理、AI 资产支持和外部资产接入。对客户来说原来每个系统各管一套元数据Agent 做任务时要靠人工配置和脚本拼接现在可以在一个入口下统一发现、授权、审计和调用减少重复建目录、重复配权限和数据资产不可见的问题。TCCatalog 核心能力关键特性客户实际收益统一元数据服务表、文件、对象、模型、向量和外部资产纳入统一 Catalog降低找数、找文档、找模型的成本减少资产重复建设统一权限管理跨 COS、湖仓、AI 资产和 Agent 应用继承权限与审计避免 Agent 绕开权限体系提升生产环境可控性AI 资产支持管理 Model、AI Function、Agent 可调用数据和上下文、Agent 记忆让 AI 应用不再孤岛化方便复用和治理2. TCIceberg TCLance一张表装下音视图文数据格式是底座最核心的工程决策。TCLake 的结构化侧由 TCIceberg 承担整体兼容 Iceberg、Hudi、Delta 等主流湖仓生态支持流读流写、部分列更新、算子下推、数据裁剪、智能分层和动态列扩展。多模态侧由 TCLance 承担兼容 Lance 生态专攻图片、视频、音频和 Embedding 数据提供自适应索引、压缩、随机访问和部分列更新能力。这套 TCIceberg TCLance统一格式真正解决的是企业 AI 应用里最常见的“多系统拼接”问题。过去做一个知识问答、智能巡检或多模态分析任务结构化指标在数仓里原始图片和视频在对象存储里全文索引在搜索系统里向量索引在向量库里权限和审计又在另一套系统里。工程团队不仅要搬数据还要持续处理索引漂移、权限不一致和 Schema 变化。统一表格式把 id、user、image、video、audio、embedding、timestamp、JSON 属性、业务标签放到同一个逻辑 Schema 里让 Agent 可以围绕一份数据同时完成 SQL 分析、全文检索、语义召回和多模态处理。最终显著减少数据复制、降低索引维护成本、避免上下文在系统切换中丢失。统一格式能力关键特性客户实际收益流批一体与增量计算业务数据可流读流写数据入湖后保持一致性和可恢复性支撑分钟级/秒级新鲜度减少离线同步等待多模态存储同一张表承载音视图文、Embedding、引用和结构化字段RAG、训练、BI、Agent 共用一份数据减少副本膨胀多模态数据检索按访问模式优化索引、压缩和随机访问降低多模态检索成本提升高频知识检索体验一个直观的例子是城市智能巡检。过去要回答腾讯大厦周边 10 公里范围内、夜晚雨天、且包含施工区的所有图片这样一个问题结构化的地理位置和时间戳在数仓里、原始图片在对象存储里、天气和光照标签在另一套系统里、图像向量又在向量库里往往要串联三四个系统才能拼出结果。在 TCIceberg TCLance 统一表格式下frame_id、video_uri、天气、光照、地理坐标、图像向量和原始字节被放进同一张大宽表一条标准 SQL 就能完成这次跨模态检索——这正是一张表装下音视图文对 Agent 的真实价值。3. TCQA让存储层学会理解计算任务TCQA 是大数据原生加速引擎覆盖数据处理、数据分析和 AI 训练三种典型负载靠的是计算感知、冷热分层和缓存加速三重机制。计算感知这个思路特别值得展开传统存储层是等请求的模式任务来了再响应而 TCQA 会主动理解上层任务的逻辑和资源状态提前做 Filter 下推和元数据预解析来降低扫描量通过智能 IO 优化传输路径再用 AI Based 缓存预加载热点数据。TCQA具体的优化可分为三类第一是上文重点介绍的计算感知通过 Filter 下推和元数据预解析降低扫描量节省带宽和计算资源第二是智能 IO 和数据分层根据计算资源分布、冷热程度和数据访问路径优化布局缩短传输路径第三是 AI Based 数据缓存根据访问模式动态预加载热点数据提升缓存命中率。基于 TPC-DS 的测试结果显示在实际性能方面Spark等上层引擎在 TCLake开启 TCQA 后TPC-DS 等基准 Benchmark计算耗时降低 22%缓存命中率提升 10 个百分点另外在数据扫描量大、访问热点明显、多引擎复用频繁的场景中TCQA 的收益会更加明显。TCQA 核心能力关键特性客户实际收益计算感知识别查询逻辑、过滤条件和资源状态做 Filter 下推与元数据预解析减少无效扫描降低带宽和计算资源消耗智能 IO 与分层根据冷热数据和计算资源分布优化数据布局和传输路径缩短数据读取链路提升大规模分析和训练效率AI Based 缓存基于访问模式动态预加载热点数据提高缓存命中率减少 Agent/RAG 高频检索等待提升交互体验4. 实时入湖与智能管理数据跑起来才能被 AI 消费底座的价值最终要落在数据能不能以足够快的速度被消费。TCLake 的做法是把从产生到消费的整条链路连起来CDC 或 Kafka 把业务数据实时推进 TCIceberg 流批一体表格式后面跟着 AI Compact、分层、Z-Order 自适应等自动化管理再经过 TCQA 的缓存命中和数据裁剪最终被传统数据工程、RAG、训练和 Agent 统一取用。显而易见实时入湖与智能管理链路对客户的实际收益将很具体对业务侧来说Agent 能更快拿到最新知识、最新指标、最新上下文对平台侧来说重复同步链路减少运维脚本和手工调优工作下降数据资产从产生到被 AI 消费的过程更可控。结语AI Native 不是给传统大数据平台打几个补丁就能到达的终点它是一整套数据基础设施重构的起点。从传统 Lakehouse 到 Agentic Lakehouse变的不只是存储格式还有数据底座的服务对象。计算智能让 Agent 跑得更快数据智能让 Agent 学会协作分析而存储智能最终管的是 Agent 手里有没有一套可靠、实时、可治理、可复盘的数据上下文。对大多数企业而言建一个完整的Agent-Ready底座不需要一步到位。更务实的路径可能是先把 Catalog 和权限统一起来接着把高价值的多模态资产纳入统一表格式再逐步引入计算感知加速和 Agent 记忆治理让数据从可查询慢慢过渡到可行动。而未来在 AI 企业架构原生化路径上走得稳的企业往往不是在 AI 上砸钱最多的而是最先完成数据底座升级的那一批。