Data Infra行业、CRM与安全行业一直是全球软件行业里排名前三的软件细分领域（Gartner 2023， 前三大软件垂直领域是Data Infra占比15%，CRM占比14%，网络安全10%）。在Data Infra领域里有Oracle这样的3000亿巨无霸，有Snowflake、Databricks、MongoDB这样的新一代技术栈，有三大云布局完整的产品图，也有DB-Engines.com里正在监控的几百家数据库。

如果说过去5年是Data Infra拥抱云原生的5年，那未来5年就是拥抱LLM变革的5年。

Snowflake换帅

2024年2月28日，Snowflake发布了其财年第四季度的财报，在给了令人尴尬的全年指引后，给出了另一个消息令美国Data Infra行业震惊。

美国软件史上最传奇的CEO之一Frank Slootman宣布从Snowflake CEO职位辞职，新CEO是Neeva的印度裔创始人Sridhar Ramaswamy。Sridhar在去年5月将公司Neeva卖给Snowflake后加入了该公司，并担任Snowflake的AI SVP，负责所有新AI业务，仅仅不到一年时间，从一位被收购公司的创业者成为了母公司的新晋CEO。

Snowflake CFO Michael Scarpelli在财报后一周的投资人沟通中，提到“我直到周二（财报是周三）才知道Frank离职”，“但去年随着Frank和董事会与Sridhar共处的时间越来越多，我们感觉他可能会成为Frank的继任者”。Scarpelli是Frank的老朋友，两人在ServiceNow就是黄金搭档，并跟随Frank一起加入Snowflake。在工作外他们也保持着很好的私人关系，都居住在蒙大拿州的Bozeman，Scarpelli可能与我们一样震惊。

Snowflake的天使投资人，以及首任CEO Mike Speiser随后也谈论到了Frank的卸任：

• Mike Speiser与公司的两位创始人一同成立Snowflake时，即约定了自己什么时候卸任，“等到交付一个产品的时候”。

  
  

• 随后Mike Speiser卸任了公司的CEO后，让微软的Bob Muglia接任自己，并提到这是一次“clear upgrade”，在这一时期的目标是将产品推向市场并且跑通商业模式。

  
  

• 之后董事会意识到上市以及Scale-up是下一个更大的挑战，遂迎来了Frank Slootman，Frank可以让全公司的所有人保持高强度和紧迫感，使业务加速增长，并最终迎来上市。

  
  

• Mike Speiser与Frank Slootman也相信Sridhar会是Snowflake在下一个LLM时代最适合的领导者。

换帅如换刀。在下一个Data Infra的大时代，LLM时代，Frank可能已经不再是最适合Snowflake的CEO。这也让每一次换人都能收获巨大效果的Mike Speiser感慨Sridhar可能更适合下一阶段的使命。

Sridha在日后也提到，除了Snowflake外，三大云厂商也邀请他去做AI负责人，但他最终选择了Snowflake。Sridha是市面上非常少有的Database+LLM+管理的复合型人才，他拥有Database相关的PHD学历，作为“King of Google Ads”，在Google管理着超过1万人的庞大团队，帮助Google在推荐算法追上Meta，为Google保持了推荐算法的领先立下汗马功劳。日后也成立了AI搜索公司Neeva。

不禁让人感慨，Data Infra在LLM时代也迅速被推入了拼刺刀的决战前夕。只有感受到了大战降临的紧迫感的公司，才会让管理层做出选择替换上个时代功勋卓著的Frank的决定。

这个变化可能不仅仅是Snowflake的选择，也可能是很多软件公司必须做出的选择。一位AI出身的CEO，可以清楚地知道需要在哪里投入AI，需要补齐什么产品和技术能力，可以在哪里找到能够一起运营这个事情的人才。

先到先得，时不我待。我们会在后面的章节更多展开。

Data Infra只有进入训练流程才能赚到钱

从去年1季度开始流行的Data Infra会获得收益的故事到现在，代表公司Snowflake与MongoDB都没有明确提过AI收入占比。

MongoDB在2023年4季度的财报中，第一次解释了为什么传统的Data Infra公司们到现在还没赚到大钱：

• Data Infra在大模型领域中会参与到三层：模型训练，Finetune和推理。

  
  

• MongoDB的现有技术栈主要与后两层相关（Finetune和推理），但从现在的客户用例来看，绝大部分客户都还在第一层（模型训练）。

  
  

• 等到客户进入第三层（推理），才会有更大体量的AI收入进入MongoDB。

这也是现在Data Infra领域的商业现状。只有涉及训练技术栈的新一代Data Infra公司才从这个领域赚到了钱，这些典型的流程包括ETL/特征工程，数据湖，向量数据库，训练优化框架，以及在传统Machine Learning领域经常用到的生命周期管理和实验追踪工具。例如Databricks、Pinecone，以及中国的Zilliz、Myscale等新一代工具都赚到了AI训练的第一桶金。

（图：Relit训练技术栈示意图）

在最早Relit博客中提到的训练流程中，其大模型大量运用了Databricks的技术栈，并配合三大云的基础设施完成了模型训练流程。

Databricks十年磨一剑

Databricks是新一代Data Infra中最耀眼的主角之一。

在其新披露的业务数据中：

• Databricks在2023年营收达到了16亿美金，实现了~55%的同比增速。

  
  

• 虽然16亿美金营收仅占竞争对手Snowflake的不到60%，但其营收模式与Snowflake存在差异，除了对标Snowflake的SQL Serverless产品会包裹云厂商的计算与存储业务打包出售（赚软件的钱和计算存储的溢价），剩余的大部分产品仅出售软件价值（赚软件的钱）。

  
  

• 用两家公司的毛利来比较更加合理，都剔除云厂商的Pass-through收入，Databricks的毛利相当于Snowflake的~65%，考虑到其更快的增速，按照2023年4季度来看接近Snowflake毛利的70%（反映了更高毛利的软件部分在Databricks的占比更高）。

  
  

• 从趋势上来看，Databricks在2023年出现了收入加速趋势，并预估在2024年收入增速能加速到60%，为证明其合理性公司提到其2023年4季度的Booking订单同比增长接近100%。

与Databricks现在的成功相比，过去十年Databricks的发展却谈不上一帆风顺，堪称十年磨一剑。

Databricks从开源Spark起家，并在后面顺着Spark往存储延展做出了数据湖拳头产品Delta Lake。沿着Spark的发展史来看，Spark的发展一直处于高度竞争中：

• Spark是Databricks创业史中最早的产品，也仍是目前该公司最核心的产品，其开始的定位是做机器学习与数据工程的支撑平台。

  
  

• Spark出现时已经能覆盖深度学习流行前几乎所有的机器学习任务，但随着深度学习蓬勃发展，Spark不再是最主流的机器学习平台，Tensorflow以及之后的Pytorch更为主流。

  
  

• 但在成为独立的机器学习平台之外，Spark在数据工程领域独占鳌头，是市面上最主流的ETL工具，这也为Databricks在大模型时代靠ETL/Feature Engineering拿到了关键的门票。

另一个拳头产品Delta Lake也使其成为了最大的商业化数据湖服务商：

• 在处理机器学习数据时，已经需要大量的非结构化数据，数据湖成为了最理想的高性价比存储方法。

  
  

• 但在很长的一段时间里，数据湖的概念对于采购决策方-公司的CTO来说都很难理解，并且形成了搭建难、维护难的观感。

  
  

• 而随着Delta Lake走向闭源，开源的Open Format产品Icebeg、Hudi等也后来追上，这也最终推动了Delta Lake开放了开源产品，以及在Delta Lake 3.0中开始支持外部Format。

而在同期的发展中，与Databricks几乎同时成立的Snowflake因为其数据仓库理念更好理解、市场空间更大，在体量和增速上都快速拉开了和Databricks的差距，一度让Databricks感到黯然失色。

为了进攻“油水”更厚的数据仓库生意，Databricks提出了Lakehouse概念，一体化的产品既能做湖的Workload，也满足仓的Workload需求。且相比于Snowflake，Databricks中Lakehouse的SQL业务也有其特点：

• 因为支持湖的Open Format，数据在进入数仓运算的过程中不需要转化成数仓的专属格式，这为客户省去了存储成本（不需要同一份数据为数据湖和数据仓库都准备一份），以及传输所带来的额外Data Loading成本。

  
  

• 同时Databricks也给予客户更大的自主权，可以使用自己在三大云购买的计算与存储业务，这使得对超大客户尤其友好（因客户体量大，超大客户在三大云处可以拿到很低的折扣）。

  
  

• 伴随而来的还有疯狂的宣传攻势，在节省一定成本的同时，也适当混淆了两者收费口径的不同，用不加存储计算以及Data Loading的成本对比Snowflake的全托管产品，并配合夸张的口风，比如一直标榜的“我们比Snowflake便宜10倍”的口号。

  
  

• 但归根结底，数据仓库领域仍然有非常多的特性优化，比如各种复杂Join同时发生的情况。刨除上面口径的不同，在数仓先天内功不足的Databricks SQL在大运算量的复杂场景仍与Snowflake的性价比实质有所差距。

  
  

Databricks的发展经历过几次起伏，但最终熬出了头，其一直宣扬的Spark和Lakehouse产品成为走向大模型时代的攻城利器：

• 目前阶段的技术栈需求，平台功能的完整（能够端到端实现目标）比单个功能的超群更加重要。
  

  
  

• 大模型时代对于非结构化数据的处理呈现爆炸式增长，Delta Lake + Databricks Spark作为非结构化数据处理的黄金搭档成为主流技术栈，并且占据了市面大量的ETL/Feature Engineering Workload。

  
  

• 通过其在机器学习上的全体系积累，在收购MosaicML后，Databricks成为了三大云和英伟达后又一个全栈大模型训练平台，几乎补齐了最后一块拼图。

  
  

• 而Lakehouse的路线之争，在Snowflake于2024年开始全面拥抱Open Format，并允许客户使用自己的存储负载后走向了尾声，Lakehouse成为大数据的时代主流，无论是从湖进入，还是从仓进入，最后都会成为Lakehouse方案。

Snowflake的追赶计划

与Databricks一直聚焦于非结构化数据与机器学习的工作不同，Snowflake的路线更加发散，中间在机器学习领域投入的精力并不多。

Snowflake的创始人Benoit Dageville一直在负责Snowflake的技术路线，在2023年之前的重点是Unistore与Snowpark，先谈谈Unistore：

• Unistore是一款类似于HTAP的产品，底层采用KV Store设计。Benoit希望这款产品能帮助Snowflake拓展向更大的数据库领域（OLTP）的市场机会。但因为其KV Store的设计，其方向仍然无法与Oracle等主流OLTP直接竞争，更加适合成为OLAP为主+OLTP为辅的公司所采用的解决方案。

  
  

• Unistore实现的技术难度也比较高，其不处于Snowflake所发家数据仓库领域，对于延迟和稳定性有着极高的要求。同时HTAP也是个新的技术方案，HTAP的先驱在这个领域里也一直碰壁，很难说HTAP在商业模式上跑通了。

相比Unistore，Snowpark的逻辑更加通顺：

• 而Snowpark则有着更顺的产品逻辑，客户在将数据转化进入Snowflake的时候，就需要进行ETL处理，而过去的主流处理方式就是Opensource Spark和Databricks Spark，现在用Snowflake原生的ETL工具，节省了传输成本，从功能上也没有区别，客户出于性价比转向Snowpark应该是顺理成章的选择。

  
  

• 相比Opensource Spark（在AWS客户中更多以EMR产品售卖），Snowpark的性价比优势非常明显。但相比优化后的商业化产品Databricks Spark，Snowpark更多还是在面向已经使用Snowflake产品的客户的数据处理上有一定优势。

  
  

• 虽然Snowpark可以很快赶上Data Engineering的工作量，其技术壁垒也不高。但在机器学习领域上仍然有非常多的工作要补齐，特别是面对Spark的开源优势，Snowpark更多还是面向特定的传统行业提供机器学习能力的支持。

Snowpark在2022年底商业化后，其收入体量差不多到Databricks ETL收入的5-10%，增长迅速。如果与Databricks推出面向与Snowflake竞争的产品Databricks SQL相比，其体量大概是Databricks SQL的1/3，推出也比Databricks SQL整整晚了一年。

Snowpark产品也为Snowflake保留了通向大模型时代的门票，Snowflake日后的大模型支持产品也都围绕Snowpark建立：

• Snowpark为Snowflake带来了非结构化数据处理的能力，在大模型时代其可以胜任ETL和Feature Engineering的需求。

  
  

• 通过Snowpark继续往外延伸，Snowflake开始支持Iceberg Openformat，这也为Snowflake吸引更多非结构化数据，构建完整的Lakehouse解决方案打下了基础。

  
  

• 同时，Snowflake推出了Snowpark Container Service，并成为了Snowflake日后的工作重心，为Snowflake引入了GPU Workload。允许客户在Container Service中Finetune和部署模型。

在Sridhar进入Snowflake后，其也将精力花在新产品Cortex上：

• Cortex为Snowflake引入了外部的大模型合作伙伴，这包括了其新投资的Mistral AI，该公司产品主要针对对话和相关分析。

  
  

• Cortex也包括了Document AI与Snowflake Copilot，这很像Databricks LakehouseIQ，并提供面向Text2SQL和知识库方案。

  
  

• 同时Sridhar也正在将过去Neeva所运用的RAG-Vector Search方案整合入Cortex，这也很快会为Snowflake带来Vector存储和处理能力。未来也可以支持更多的Container Service客户，允许客户在Container Service中直接部署+推理模型。

Sridhar非常清楚Snowflake缺什么，也知道该投入多少精力。这从Snowflake挖走DeepSpeed创始人以及其核心团队中可以看出：

• Snowflake CFO在后续的沟通中曾经提到从DeepSpeed挖走的5个人需要20mn USD的年成本，“非常令人惊讶，他们太贵太优秀了”。

  
  

• 但Sridhar很清楚知道为了成为End-to-End的训练/推理技术栈，Snowflake也必须能找到和MosaicML一样的优秀标的，如果不能收购那就直接挖人。DeepSpeed团队几乎是最好的选择，其也是现在最流行的大模型训练/推理框架。

  
  

• 这在Frank时期几乎难以想象，大成本+难以被公司“老人”理解的用途，只能在新CEO自上而下的推动中才得以实现。

更换CEO后，Snowflake也做出了All in AI的架势，全部产品都以AI为重心。

但在一家以数据仓库为主要业务的公司里做AI就相当于二次创业，Snowflake 任重而道远。

MongoDB的RAG故事

与Databricks、Snowflake不一样，MongoDB不在分析侧，其产品更加侧重于支撑业务数据流转和存储的OLTP。

在2023年初，MongoDB一度是Data Infra中的头号标的，当时的市场逻辑是：

• MongoDB基于文档数据库发展出来的，可以先不过多考虑数据结构（是否结构化、非结构化、半结构化等等），数据一股脑先进去再进行处理，有很高的易用性

  
  

• 大模型训练和推理会使用许多非结构化数据，而MongoDB的主要产品是做半结构化和非结构化数据的存储、读写、查询。

  
  

• 在训练侧可能会用到MongoDB作为非结构化数据的存储介质，这可能会进一步提高MongoDB在客户技术栈中的重要性。

  
  

• MongoDB有机会做自己的向量数据库，进入到模型推理侧。

  
  

• 更多的LLM应用也意味着更多的APP，他们不一定会在LLM流程中使用MDB，但还是需要通过MongoDB存储Chatbot聊天记录，以及传统的OLTP负载。

MongoDB也非常配合地在2023年1季度提到其有200个新客户是AI客户，这包括了Hugging Face、Tekion等知名公司。但在随后的季度里，MongoDB不再披露其AI客户信息。

MongoDB的发力点主要点在了推理侧，这也是其在最新季度里提到大模型场景还在训练侧，还未进入到推理侧，导致其收入贡献不明显。

审视MongoDB在推理侧的机会：

• 相比前面两家的推理侧更多还在Data Application和API层面，MongoDB可以面向终端用户提供服务，这与其OLTP的定位分不开。

  
  

• MongoDB的Atlas Vector Search服务最早GA提供向量搜索功能，在2024年初就已开始商业化。

  
  

• 面向其老客户，传统技术栈可能更值得信赖，特别在RAG要求、尚未大规模上量的时候，MongoDB的向量搜索服务可能已经满足要求。

但与其他RAG方案相比，MongoDB也仍然处于推理发展的早期：

• MongoDB在数据量和并发量大的场景，仍然距离AI Native的向量数据库仍有差距（主要是Mongo在vectordb的引擎算法方面积累较这些专业向量数据库还较弱，推理场景大规模推广后，数据量会显著增加，对于引擎能力的考量越发变多）。

  
  

• 新一代的RAG方法，不只依靠与向量数据库结合的Dense Embedding，还对传统的BM25有极高的要求，这方面可能也不如Elastic的方案。

  
  

• 对于MongoDB，仍然有大量需要追赶的功能点。

世界需要End-to-End的技术栈

我们将三家公司的LLM进度列成了如下图表，第一张是训练侧：

• Databricks是全流程的训练技术栈，并且通过MosaicML补上最后一环。但在大模型训练上仍然较公有云有一定差距。

  
  

• Snowflake正在打补丁的过程中，在Notebook、数据湖、模型训练优化以及MLFlow层面仍然有很大差距，目前更多是允许客户在其Container Service里进行Finetune。

  
  

• MongDB的重点在推理侧，基本不涉及训练。

• Databricks的RAG方案仍然在公测，目前还不具备一站式推理能力，但有望年中补齐。

  
  

• Snowflake的Snowpark ML以及RAG方案也都在公测，未来更多支持部署在Container Service上Data Application的推理，这些可能是客服机器人、企业知识库等场景。

  
  

• MongoDB虽然在Finetune和容器上没有涉及，但更侧重于面向终端用户的RAG方案，面向的客户群体更加广泛。

科技领先的客户已经在采用三大云以及各类AI Native平台的LLM技术栈，三家公司未来的主要增量还是传统公司场景：

• 对于传统公司来讲，End-to-End的技术栈非常重要，客户在LLM人才紧缺时代，无法建立起最优秀的LLM团队，对于训练/推理流程，越简单越好。

  
  

• 传统公司也在增加LLM预算，这可能是自己通过开源模型训练例如客服等场景，也可能是购买其他第三方软件应用解决方案。

  
  

• 但从历史维度来看，一开始应用解决方案可能会提供其自己搭建的Data Infra，但随着生态系统打通，客户也更多用其自有的Data Infra支持所有第三方解决方案。

Data Infra的新产品

除了上面的训练推理流程，Data Infra公司还在知识库和Text2SQL领域准备新产品。

（图：Databricks LakehouseIQ介绍）

Databricks的LakehouseIQ就希望做成一个一体化的产品：

• 客户将其结构化数据、非结构化数据以及办公用的各类文档都可以存在其Lakehouse中，从而实现通过与Lakehoue IQ对话的方式获取信息，是相比上一代Sharepoint/FTP等更高效的文档搜索方式。

  
  

• 同时通过LakehouseIQ，客户可以以自然语言的方式撰写代表，实现Text2SQL。

  
  

• 在展示中，‍其进一步希望可以通过自然语言输入目标，然后将大目标拆解成几个小目标，分别进行数据分析，再Prompt给大模型得到完整答案。‍但目前还在早期阶段。

Snowflake的产品更加早期：

• 其知识库产品主要依靠其2022年收购的文本AI公司Applica，为其提供了Document AI产品，可以从文档中抓取结构化数据和文本数据。

  
  

• 结合Neeva团队为其做的Vector Search方案，有望打造成完整的知识库方案。

  
  

• ‍‍Snowflake Copilot是其定义的Text2SQL产品‍‍，更多是将自然语言翻译成SQL代码，但离做目标拆解进行复杂分析仍然比Databricks远得多。

决战也是迎来新篇章

过去几年围绕Data Infra的竞争一直都聚焦在：是云架构还是On-prem架构，是湖还是仓，是NoSQL TP还是SQL TP。

现在出现了LLM带动的新Data Infra需求后问题就变成了：

• 能不能最快速度做新产品，抢到增量蛋糕？

  
  

• 如果做不出新产品，挖不到LLM的团队，是不是就从此掉队，还要丢掉老产品份额？

所以才会看到类似于Snowflake这样不惜更换CEO来All in AI的举措。

我们难以想象在Databricks、Snowflake外还有哪家公司能够收购MosaicML，或者挖到Deepspeed的核心团队。新一批的LLM人才只有头部数据库公司才能吸引，这可能会进一步拉开和开源、OnPrem以及剩余数据库的距离。

是决战，但更可能是增量的大机会。

在6月份的年度产品会上，我们都会看到几家公司密集GA的新产品：

• Databricks可能会GA其Vector Search和Container Service方案。

  
  

• Snowflake可能会GA其部分Cortex功能、Container Service、SnowparkML、Notebook、Iceberg、Streamlit方案，如果进度赶得上也可能GA其Vector Search。

  
  

• 算上正在不断打磨RAG能力的MongoDB，每家公司都在上演生死时速。

本文来自微信公众号：共识粉碎机（ID：botaijin），作者：波太金、小熊猫