🏢 公司C档 · NaN分

AI的记忆,正在搬回企业机房

··约1分钟阅读

📋 总体概括

开源权重模型逼近闭源前沿水平,私有化AI从试点走向生产,企业存储第一次被推上'AI记忆体'的位置。Apache Doris 5.0押注多模态湖仓,StarRocks 4.1押注生产简化,两条路线指向同一个判断:AI竞争的主战场,正在从模型层沉到数据基础设施层。

📄 正文

当企业存储成为AI的记忆:从Doris 5.0与StarRocks 4.1看数据基础设施的重排

模型够好之后,剩下的问题只有一个:数据放在谁手里。

SiliconANGLE最近的一篇报道点破了一个正在发生的转向:随着开源权重模型在性能上逼近闭源的前沿系统,企业第一次拥有了在自己硬件上跑生成式AI的可靠路径。这个转向的直接后果是——那些早就躺在企业存储里的数据,突然成了私有AI叙事的正中心。而几乎在同一时间,Apache Doris 5.0 预览版亮出了‘多模态湖仓’的牌,StarRocks 4.1 则把赌注押在‘为生产而生、为简化而设计’上。

三条线索,指向同一个判断:AI竞争的主战场,正在从模型层沉到数据基础设施层。

🔓 开源模型把AI从云上拽回机房

金句:模型平权之后,竞争的天平只剩一个砝码——数据的主权。

先看一个正在大量发生的场景。过去两年,几乎每家略具规模的企业都跑过AI试点:调一调云端API,做一个演示用的问答机器人,写进PPT,然后没有然后了。真正卡住从试点到生产的,从来不是模型不够聪明,而是两个更朴素的问题——数据不敢出内网,推理成本算不过账。

开源权重模型的快速逼近改变了这个局面。当私有部署的模型在能力上与闭源前沿系统的差距缩小到大多数业务场景可以接受的程度,‘数据不出门’和‘成本可控’这两笔账就都能算平了。于是我们看到,很多组织开始把AI从试点项目里搬出来,跑在自己的硬件上。

这个转向的产业含义,比‘省了API调用费’深刻得多。SiliconANGLE的判断是:企业存储正在变成AI的记忆(AI memory)。训练是一锤子买卖,推理和检索才是天天发生的日常——而日常依赖的语料、知识库、业务上下文,全部在企业自己的存储里。谁掌握了这层数据,谁就是私有AI链条上不可绕开的一环。

据多位接近企业客户的从业者反映,今年客户采购询价的话术已经变了:以前问‘能不能做数据分析’,现在直接问‘能不能给大模型供数’。这一句话的变化,正在重新定义存储和湖仓厂商的赛道位置。

🧠 Doris 5.0:湖仓要当多模态的统一记忆

金句:当AI成为最大的数据消费者,湖仓的边界必须跟着拓宽。

Apache Doris 5.0 预览版的标题很直白:A Unified Multimodal Lakehouse——统一的多模态湖仓,面向实时分析。按Apache基金会官方博客与发布说明披露的信息,这个预览版至少押了三注:

第一,开放格式集成。湖仓这条路线的核心主张从来不是‘另起炉灶’,而是把 Iceberg、Paimon 这类开放表格式上的数据直接纳入分析引擎的射程。值得注意的是,Doris 在这条路上已经走了几个版本:从早期的 Iceberg/Hudi/Paimon 只读联邦查询,到支持通过 External Catalog 直接读写 Iceberg 表,再到对 Iceberg REST Catalog 的对接——5.0 预览版把这条线进一步向前推,意味着存算两端的耦合被继续拆开。数据是客户的,引擎是可替换的——这在私有AI时代是关键的信任基础:没人愿意把喂给大模型的核心资产锁死在私有格式里。

第二,Variant 与向量分析。Variant 解决的是半结构化数据的灵活存取——AI 时代的输入输出充满不可预测的嵌套结构,一条 Agent 的调用日志、一份 LLM 的输出 JSON,字段说变就变,传统‘先建模再入库’的流程根本接不住;而 Variant 允许这类数据‘原样落库、按需取用’,并配合 JSON 子列物化等手段保住查询性能。向量分析则解决语义检索——RAG 架构里最基础的一环。Doris 从 2.1 起引入向量检索能力、随后迭代向量索引,到 5.0 预览版将其纳入‘多模态’叙事的核心,信号很明确:把这两类能力做进同一个实时引擎,企业就不需要再为‘分析’和‘检索’维护两套栈。

第三,Physical AI 与 Agent 场景。这两个关键词值得关注:当智能体需要实时读取业务状态、当机器人需要处理传感器与多模态数据,‘湖仓’的消费者就不再只是 BI 报表,还包括模型本身。这正是‘存储即AI记忆’这个叙事的技术落点。

需要提醒的是,5.0 目前仍是预览版(Preview),上述能力进入生产可用的稳定形态还需要一到两个正式版的迭代周期,团队可以现在跟进测试,但不建议直接压生产流量。

从架构视角看,这条路线的野心是清晰的:让湖仓从‘人看数据的仓库’,升级为‘人和AI共同读取的记忆体’。

⚙️ StarRocks 4.1:别炫技了,先把生产做好

金句:Demo 阶段拼功能清单,生产阶段拼的是谁能少出事故。

与 Apache Doris 的高举高打不同,StarRocks 4.1 的标题透着一股克制:Built for Production, Designed to Simplify——为生产而建,为简化而设计。

这不是一句套话,而是一个精准的卡位判断。按 StarRocks 官方发布说明,4.1 在‘简化’上的投入主要集中在几个工程侧的真痛点上:

  • 存算分离的持续完善。 StarRocks 的 shared-data 模式让计算节点可以无状态弹性伸缩、存储直接落在对象存储上——扩缩容不再需要繁重的数据重分布,这是‘运维累不累’问题最硬的一个答案。
  • 物化视图的自动化程度提升。 查询自动改写、刷新策略更智能,意味着数据团队不用再手写大量聚合表和同步脚本——这是很多生产事故和深夜告警的直接来源。
  • 资源隔离与查询管理。 Workload Group、查询队列这类能力,决定了当 AI Agent 以高出人类几个量级的并发来‘轰炸’数据平台时,报表流量不会被挤垮、关键查询不会被饿死。
  • 向量检索能力的持续迭代。 StarRocks 在 3.x 系列就已引入向量索引与近似检索,4.1 延续这条线——同样的逻辑:RAG 的检索层和分析层收进一个引擎。

私有AI落地进入深水区之后,企业最大的痛点从‘功能有没有’变成了‘运维累不累’:版本升级要停机吗?扩缩容要人工介入吗?跨集群的表同步要写多少脚本?这些问题的答案,直接决定了平台团队敢不敢把AI的生产流量压上去。

从工程视角看,实时分析引擎走到 4.x 这个阶段,功能大盘基本齐了,比拼的恰恰是生产的摩擦力。每降低一分运维复杂度,就降低一分客户的采用门槛——尤其是在数据团队普遍被要求‘用更少的人干更多的事’的当下。

业界私下有个说法流传颇广:实时引擎的胜负手,不在发布会,在客户的凌晨三点告警群里。谁在告警群里出现的次数少,谁就能笑到最后。StarRocks 把 4.1 的主题定为‘简化’,本质上是承认了这个现实。

两条路线放在一起看很有意思:Doris 在拓宽湖仓的能力边界,StarRocks 在收敛生产的使用成本。看似方向不同,实则是在同一块阵地上从两端包抄——这块阵地,就是‘私有AI的实时数据底座’。

🗺️ 格局重排:谁站在AI记忆体的关键位上

金句:技术门槛决定你能走多快,商业价值决定你能站多久。

把这次变局里的主要玩家放到坐标系上看,可以观察到明显的分化。云数仓厂商手握技术与规模,但恰恰在‘数据主权’这个私有AI的核心诉求上天然别扭;实时OLAP引擎技术门槛不低,且正踩在实时供数的风口上;传统存储厂商坐拥企业最底层的数据资产,但需要补上分析与AI的软件能力;而企业自建的脚本化数据栈,正在被这轮变局加速淘汰。

需要说明的是,以下定位图与相关判断,是作者基于 SiliconANGLE 报道、Doris/StarRocks 官方发布资料及行业观察整理出的个人推断,并非任何权威机构的市场分析结论,供读者参考和批判:

几个判断值得展开(以下均属作者推测,欢迎读者用自己的一线观察校验):

其一,存储厂商的翻身机会来了,但窗口不长。 私有AI让‘数据就地消费’成为刚需,靠近存储的人有天然的位置优势——NetApp 等厂商近两年公开谈论 AI memory(AI数据管道与RAG基础设施方向的产品布局),即是一个信号。但如果软件能力跟不上,位置优势会迅速被湖仓厂商的开放格式兼容策略稀释。

其二,实时引擎是本轮变局里弹性最大的一层。 Agent 和 Physical AI 场景对数据时效性的要求,恰好落在实时OLAP的能力甜区。Doris 和 StarRocks 同时在这个位置上重兵投入——从各自 2025 年下半年相继发布的版本主题即可印证——不是巧合,是对同一个趋势的独立确认。这一‘双引擎独立确认’本身,比任何单独一家的发布会更有说服力。

其三,云数仓不会坐视不管。 从公开动向看,头部云数仓近两年都在推开放表格式(Iceberg)兼容与混合部署能力,方向与本文推测一致;它们大概率会继续用‘混合部署+开放格式兼容’,以自身的工程成熟度对冲客户的主权焦虑。未来两年的竞争焦点,会从‘谁的查询更快’转向‘谁能让数据主权和工程效率同时成立’。

私有AI落地的真实卡点,也值得每个建设者对照自查:

私有AI数据底座的卡点与解法
痛点 1
核心数据不敢出内网
→
解法
开源权重模型私有化部署,数据就地消费
痛点 2
分析与检索两套栈难维护
→
解法
Variant与向量能力并入统一实时引擎
痛点 3
数据锁死在私有格式里
→
解法
拥抱Iceberg等开放表格式,引擎可替换
痛点 4
平台运维复杂度拖垮团队
→
解法
生产化与简化优先,压低使用摩擦
痛点 5
试点与生产之间断档
→
解法
让实时湖仓同时服务人和模型两类消费者

🔋 给实战者的三个动作

金句:别等架构完美的那一天,数据主权的账要先算清。

如果以上判断成立,正在搭建数据平台和AI基础设施的团队,有三个动作值得现在就做:

第一,盘点你的‘AI记忆’资产。 私有AI的竞争力等于模型能力乘以数据质量。模型能力大家都在收敛趋同,数据质量才是分差所在。哪些数据可以直接喂检索,哪些需要清洗治理,哪些根本拿不出来——这张清单决定了私有AI项目的天花板。

第二,把开放格式当战略决策,而不是技术偏好。 表格式决定了十年后你的数据还搬不搬得动。在‘存储即AI记忆’的时代,被格式锁死等于把未来议价权拱手让人。Doris 5.0 主打开放格式集成,StarRocks 也在开放生态上持续跟进,厂商已经用行动投票,客户侧更没有理由反向押注私有格式。

第三,为两类消费者同时设计你的管道。 过去数据平台的服务对象是人——分析师、报表、看板;现在多了一类不知疲倦、调用频次高出几个量级的消费者:模型和Agent。实时性、并发性、成本模型都要按新的负载画像重新校准。下表是本轮两个版本迭代的能力对照,可以作为选型讨论的起点:

维度**Apache Doris** 5.0 预览版**StarRocks** 4.1
核心主张统一多模态湖仓 + 实时分析为生产而建,为简化而设计
关键能力开放格式集成(Iceberg读写、REST Catalog)、Variant、向量检索存算分离(shared-data)、物化视图自动化、资源隔离与查询管理
新场景指向Physical AI、Agent 供数大规模生产环境稳定运行
版本状态预览版,能力尚待正式版收敛正式版,主打生产化打磨
路线风格拓宽能力边界收敛使用成本
共同指向私有AI的实时数据底座私有AI的实时数据底座

一句话概括:Doris 在回答‘湖仓还能做什么’,StarRocks 在回答‘引擎能不能用得省心’。而客户真正要回答的问题是——我的数据,准备好成为AI的记忆了吗?

小结

开源权重模型逼近前沿,把AI拉回企业机房,也让‘存储即AI记忆’从比喻变成了产品路线:NetApp 等存储厂商在谈AI memory,Apache Doris 5.0 在做多模态湖仓,StarRocks 4.1 在做生产简化——三层玩家,同一个战场。

需要保持清醒的是:5.0 还是预览版,4.1 的简化效果要靠生产环境验证,存储厂商的AI叙事多数仍停留在路线图层面。今天的一切格局判断——包括本文的所有推断——都只是起点而非终点。接下来两年,决定胜负的不是谁的发布会更响,而是谁能让企业敢把核心数据压上私有AI的生产链路。

对建设者而言,最好的策略是双向下注:在数据侧拥抱开放格式,保住搬得动的自由;在引擎侧保持小规模试点,用真实负载验证再决定重仓。数据主权是这轮变局的锚点,谁守住锚点,谁就拿到船票——而船票的验票口,不在发布会上,在你自己的机房里。

本文由本站 AI 辅助聚合生成,原始来源如下:

🔎 本文基于以下资讯(素材溯源 · 信息来源)

📰 相关阅读推荐(与本文相关的其他资讯)