【统一存储技术专栏】60%的AI项目死于缺乏AI-Ready数据!企业如何正确搭建AI数据湖?
  

信服搬运工 348

{{ttag.title}}
2025年Gartner曾发出一则警示:60%的AI项目将因缺乏AI-Ready数据而被放弃

复盘近两年落地失败的AI知识助手、智能客服系统项目,同样会发现:模型没毛病,数据有毛病

随着Agent应用的集中爆发,整个AI产业链在加速发展,对企业数据基础设施提出了全新要求。想要支撑Agent自主运行与业务智能运营,企业亟需搭建AI-Ready数据底座。

这也意味着,企业数据平台迭代迫在眉睫,数据湖必须从湖仓一体(Lakehouse)演进为AI数据湖——在湖仓一体的基础上进一步迭代,同时承载分析与AI负载,加速模型训练与推理的效率


▲从传统数据湖到AI数据湖的演进过程


一、数据湖在AI时代面临的三重挑战

在AI深度赋能业务创新的当下,传统数据湖的建设方式面临诸多挑战,难以满足AI训练与推理、实时分析等需求。

分析侧:存算紧耦合,查询响应慢

大量企业在部署数据分析业务时,依然是按照业务需求采用烟囱式的建设方式——一个业务一套系统,一套系统融合了计算与存储,导致基础设施处于存算紧耦合状态,即使没有AI,分析负载本身也在挑战这套架构

扩展难:业务增长时,计算与存储必须同步扩容,成本按倍数放大,但性能特别是存储性能的提升大打折扣。

共享差:同一份数据要被BI、即席查询、机器学习样本仓共用,但每一处都要复制和重新治理。

以互联网即席查询场景为例,分析师在仪表盘上切换日期范围或维度,期望“点一下立刻出结果”。但底层数据分散在多个引擎和存储中,每次跨源查询都要拉取数据、转换格式、对齐时间窗——查询时间从“秒级”变成“分钟级”是常态

业界常见的应对方式是增加各种数据缓存来提升性能,实现秒级返回。但这反而增加了复杂度:缓存与底座之间需要额外的协调机制来保证数据的一致性与可靠性

AI训练侧:异构算力等数据,GPU利用率被拖累

一次完整训练涉及PB级多模态语料的持续加载、亿级小文件的随机访问、TB级Checkpoint的高频写入。任何I/O等待,都会被折算成昂贵的GPU空转。

2024年微软对400个真实深度学习作业的研究显示:约46%的低GPU利用率问题与数据操作有关,如数据加载、存储访问和小文件处理效率差,导致数据供给跟不上。

更难的是多模态:训练侧需要同时消费文本、文档、图像、视频、音频、向量索引。已有架构往往需要为每种模态新建一套数据流。训练前还要反复ETL搬运、整理、转换,GPU就只能空转,迭代速度变慢,训练成本被推高。算力越多,空转浪费问题越凸显。

AI推理侧:数据不新鲜,AI回答就不可信

像智能客服、运维助手这类RAG应用,用户关注“回答准不准”。如果AI看到的是旧数据、残缺数据,结果自然是不靠谱的。推理侧拼的不只是模型能力,更是数据能否快速共享、及时可用。

虽然数据湖现有的Catalog服务(Hive Metastore / Iceberg Catalog / Unity Catalog等)提供了数据治理和发现能力,但是完整集成这套体系的成本和适配复杂度都高。

更重要的是,Catalog体系本就是面向分析与合规场景设计的,注重Schema演进、SQL权限、审计追溯。这与AI场景下“快速圈选数据、新数据立即可见、数据集版本可回溯”的诉求存在明显分歧,难以满足Agent实时数据可见性的需求。


二、如何搭建AI数据湖,实现数据Ready?

要化解上述三重挑战,企业需要一个全新的数据底座,可从三方面重点发力。



架构选型:存算分离+生态兼容+TCO

首先在架构上选择存算分离。选择可实现PB级向EB级扩展的存储底座,支持海量数据,且性能随规模同步扩展,为未来的AI落地打下坚实基础。

其次坚持生态兼容性。数据格式上,支持结构化、半结构化、非结构化等数据类型,兼容开放表格式;业务承载上,支持训练(PyTorch / TensorFlow 等)、推理(TensorRT / vLLM 等)、数据预处理(Spark / Ray)、向量检索(Milvus)、以及分析(Trino / Presto)等多种引擎共用。

最后考虑TCO与已有投资复用。运营成本和已有投资需要纳入选型考量中:能否复用已有存储设备、支持数据从老系统纳管和迁移到新底座,避免建一套AI数据湖等于扔掉以前所有投资。

高性能存储底座:做好数据分层管理

高性能介质(如全闪存)正成为AI数据湖底座的事实选择。在选型时,除了介质指标外,更应该结合业务负载验证:分析、训练、推理过程中存储是否成为瓶颈?GPU利用率是否被压低?

在数据管理方面,做好数据分层,让频繁访问的数据始终存储在高性能介质。对于历史分析数据、训练数据集、过期模型版本和标注数据等低性能要求的数据,保存到HDD机械硬盘或低成本存储(包括已有老旧设备);将全闪存储的容量集中用在对性能最渴求的业务环节。

数据实时可见:多协议共享与数据视图

一份数据原地承载,不再为不同应用复制副本,同时支持文件、对象等多种协议对同一份数据的访问。新数据落入底座后,对所有应用立即可见;数据变化(新增、更新、删除)能被轻量数据视图(类似Catalog)实时捕获,避免AI看到的数据已经过时。

具体落地时,企业数据存储应具备以下能力:
(1)同一份数据多协议共享:同一个对象既能通过S3 API被训练框架读取,也能通过POSIX被传统应用读取。
(2)元数据与数据原子一致:写入即可见,多协议视角下的元数据视图保持同步。
(3)轻量数据视图:存储侧原生提供集合、视图、标签的轻量元数据管理,支持按namespace/tag快速圈选数据集,不依赖外部重型Catalog服务。
(4)数据变化事件可订阅:当数据新增、更新、删除时,系统以事件形式推送给下游应用(RAG索引、训练Pipeline、Agent工具),让“实时可见”真正落地。
(5)数据集版本快照:任意时间点可创建轻量快照,记录“这次训练用了哪个版本”,支持可回溯、可复现,简化数据集管理。


三、展望未来:数据不止于存储,更要被AI持续用起来

未来企业的核心竞争力,不在于谁的模型更大,而在于谁能更快、更稳地把数据转化为AI能力。

湖仓一体(Lakehouse)解决了一份数据如何被多种引擎分析的问题,而AI数据湖则进一步解决了一份数据如何被多种AI负载持续消费、持续沉淀的问题,最终形成AI-Ready数据底座

放眼未来,当业务应用全面走向AI原生时,BI分析能力被集成到Agent工具集里,SQL查询变成大模型在后台自动调用。业务负载也将进一步收敛:分析负载被Agent负载吸收,最终留下的只有“数据底座”和“AI应用”两层核心结构。

而AI数据湖,正是这一收敛过程的关键起点。


参考资料:
1、Gartner(2025): 60%的AI项目因缺少AI-Ready Data而被放弃,Lack of AI-Ready Data Puts AI Projects at Risk
2、Microsoft Research / ICSE 2024:GPU利用率低的问题中约46%与数据操作有关,https://www.microsoft.com/en-us/ ... u-util-icse2024.pdf

打赏鼓励作者,期待更多好文!

打赏
暂无人打赏

发表新帖
热门标签
全部标签>
信服课堂视频
功能体验
新版本体验
GIF动图学习
纪元平台
大规模VMware迁移替代
标准化排查
2025年技术争霸赛
案例实践挑战
破雾实践案例
每日一问
安装部署配置
技术盲盒
每周精选
场景专题
高手请过招
【 社区to talk】
产品连连看
畅聊IT
答题自测
专家问答
技术笔记
技术圆桌
在线直播
MVP
网络基础知识
升级
安全攻防
上网策略
测试报告
日志审计
问题分析处理
流量管理
每日一记
运维工具
用户认证
原创分享
解决方案
sangfor周刊
VPN 对接
项目案例
SANGFOR资讯
专家分享
技术顾问
信服故事
SDP百科
功能咨询
终端接入
授权
设备维护
资源访问
地址转换
虚拟机
存储
迁移
排障笔记本
产品预警公告
玩转零信任
S豆商城资讯
技术争霸赛
「智能机器人」
追光者计划
2023技术争霸赛专题
卧龙计划
华北区拉练
天逸直播
以战代练
秒懂零信任
技术晨报
平台使用
山东区技术晨报
文档捉虫
齐鲁TV
华北区交付直播
2024年技术争霸赛
北京区每日一练
故障笔记
排障那些事
西北区每日一问
升级&主动服务
高频问题集锦
社区新周刊
POC测试案例
全能先锋系列
安全效果
云化安全能力
专家说
热门活动
产品动态
行业实践
产品解析
关键解决方案
声音值千金
工具体验官
产品知识周周练
产品体验官
有一说一
VMware替换
王者破雾峡谷
知识大闯关
课后茶话社

本版版主

105
38
12

发帖

粉丝

关注

本版达人