引擎吃引擎，数据栈正在悄悄合体

最近一个月，三件看似不相干的事先后发生：Databricks 在运行时里做了一场名为 NEAREST BY 的向量检索 Join；美团 把 Hadoop、Apache Kylin 和 Druid 三套引擎替换成了单一 Apache Doris 平台，横跨 300 多个集群、数十 PB 数据；NetApp 干脆把自家的 ONTAP 存储塞进了 Oracle 的云里，做成原生托管服务。

三家公司，三个赛道，一个方向。

我的核心判断是：数据基础设施正在进入一轮明确的收敛周期。过去十年，行业的游戏规则是"拆"——把数据栈拆成湖、仓、向量库、流处理、ETL、目录，每一层都长出了一批公司。而现在，规则正在反转成"合"。向量检索变成一个 Join，三套 OLAP 变成一个引擎，外挂存储变成云原生服务。这不是巧合，是结构性趋势。

🎯 向量检索，正在失去"独立数据库"身份

当一个场景从"专项能力"变成"标准操作"，它就会被吃进主引擎。

向量检索的出身很 humble。它最初是个服务侧问题——经典场景就是聊天机器人：用户提问，系统去向量库里召回相似片段，拼进提示词，交给大模型生成回答。于是过去两年，一大批专用向量数据库公司拿到了融资，卖的是"我的索引更快、召回更准"。

但 Databricks 的 NEAREST BY Join 传递了一个不太客气的消息：向量检索正在从"一个独立系统"降格为"查询计划里的一种 Join 算子"。

这件事为什么重要？看看传统的 RAG 架构就明白了：

问题一目了然：向量库和业务库是两套系统，同一条查询要在两个引擎之间反复搬运和拼接。数据要同步，口径要对齐，故障域是两个，运维团队也是两个。RAG 变成生产系统之后，最大的成本不在索引，而在胶水。

而向量检索进了运行时，画风就变了：

同一条 SQL 里，向量召回和业务过滤、聚合在同一份数据上完成。没有数据同步，没有跨系统一致性，没有额外的运维对象。

产业逻辑很清晰：当 AI 应用开始大规模读企业数据时，"企业数据在哪，检索能力就得长在哪"。 专用向量数据库不会消失——极端延迟和超大规模场景仍然需要它——但它服务的那一大片"普通企业 RAG"市场，正在被湖仓运行时整片吃掉。

🧮 美团做减法：三条管道并成一条

真正的架构能力不是能加多少引擎，而是敢减掉几个。

美团这轮整合，规模是实打实的：用一个 Apache Doris 平台替换掉 Hadoop、Kylin、Druid 组成的多引擎分析栈，覆盖 300 多个集群、数十 PB 数据。

这三套引擎在传统数仓体系里各有分工，大致是：

三套引擎意味着什么？三套部署、三套监控告警、三套人才储备、三份数据拷贝，以及最难缠的——同一个指标，可能在三个引擎里算出三个数。

整合之后，这条链路被压扁了：

这不是美团一家的事。过去几年，多家头部互联网和金融公司都在做类似的"多引擎合一"，方向高度一致：用一台融合引擎吃掉批处理和交互式分析之间的那条 ETL 缝隙。

据多位关注美团技术体系的社区开发者反馈，这次整合最被称道的不是性能数字，而是"减掉的运维对象"——300 个集群背后，是几十上百人的平台团队从"养引擎"中解放出来，转去做更靠近业务的事。

产业逻辑：当计算引擎本身足够快、足够统一，"为不同场景选不同引擎"就从一个技术决策退化成一个历史包袱。 中间那层数据搬运管道，是最先被牺牲的。

🏦 存储的原生之战：NetApp 把 ONTAP 塞进 Oracle 云

上云十年来，最硬的那块骨头终于有人啃了——数据不动，能力进去。

基础设施现代化有个老大难：很多企业级应用一上云就得推倒重写，而卡点往往在存储层。核心业务系统几十年沉淀的数据格式、快照语义、灾备流程，全绑在老存储上。迁移成本高到让大多数企业选择"再等等"。

AI 把"再等等"变成了"等不起"。企业正在把几十年的数据资产推进生产级 AI 应用，这些数据如果还锁在旧存储里、或者只能通过外挂方式接云，现代化就无从谈起。

NetApp 和 Oracle 的解法很直接：把 ONTAP 做成一个入站式、全托管的存储服务，原生跑在 Oracle 云内部。注意"原生"这个词——它和过去那种"在云旁边挂一个合作伙伴存储网关"的外挂模式，是两种完全不同的生意：