从数据仓库到AI数据云：Snowflake如何借AI重塑营收与技术版图

1. AI需求如何改写营收曲线1.1 一张财报里的AI需求密码关注数据平台这块时间久了你会发现一个规律云数据仓库这类公司日子好不好过看两个指标就够——存量客户的支出增长以及新客户进来的速度。Snowflake最近几个季度的财报恰恰在这两个指标上都有明显变化背后的推手几乎都指向同一个词AI。以前大家看Snowflake第一反应是“数据仓库”是跟Teradata、Redshift抢传统数仓预算的对手。但现在再看它给自己的定位已经是AI数据云。这个转变不是嘴上说说是实打实体现在产品线和客户付费结构里的。一个明显信号是越来越多的客户不是单纯为了存数、查数而来而是为了把数据喂给大模型、跑向量检索、构建RAG应用才把工作负载放到Snowflake上。靠这份AI需求单季营收同比增速连续多季保持在30%左右剩余执行义务RPO也水涨船高这表明客户签的是长期合同不是一次性尝鲜。另一个值得注意的数字是净收入留存率。虽然它从早年接近170%的高位有所回落但依然维持在120%上下说明老客户在持续增加支出而增加的部分大多数来自AI相关的新负载比如Cortex上的Serverless推理任务、文档解析、向量检索或者Snowpark跑机器学习特征工程。换句话说AI帮Snowflake稳住了存量盘的消费深度。1.2 营收增长背后的结构变化要理解这份增长不能只看总量还得看结构。Snowflake现在的营收结构早就不是早年那种“按存储和查询计费”的单一模式了。存储部分的单价压力一直存在但计算部分的价格弹性很大尤其是AI工作负载一个Embedding批量任务跑下来消耗的算力可能是普通BI查询的几十倍。这种结构变化带来的直接影响是客户不一定多存了数但一定多用了算。AI模型要么在数据所在的地方训练要么由平台直接提供推理能力这都天然推高计算消耗。Snowflake按秒计费的模式在高并发、长耗时的AI任务面前营收弹性就显现出来了。你会发现它的毛利率依然维持在75%左右这在云厂商里属于相当健康的水平说明这波增长不是靠补贴换来的。另外AI还带来了生态收入的扩围。以前做BI集成、数据管道合作伙伴和客户大多围绕SQL生态打转。现在做AI应用客户需要模型微调工具、向量数据库、Prompt编排层这些周边需求带动了Marketplace上的数据产品和函数交易也拉高了整体客单价。我接触过几个中型科技公司他们原来只买了Snowflake的标准版做报表后来为了做企业知识库追加购买了Cortex额度还从Marketplace买了第三方嵌入模型能力账户规模直接翻倍。2. 技术布局拆解从数据仓库到AI平台2.1 Cortex把AI拉进SQL的日常Snowflake这轮技术布局的核心Cortex绝对算一个。Cortex是什么简单说它把机器学习、向量搜索、LLM推理、文档处理这些能力直接作为SQL函数暴露给用户。比如你调用SNOWFLAKE.CORTEX.COMPLETE传一个模型名和Prompt进去它就能直接返回生成结果不需要单独搭一个GPU集群不需要自己写Python服务也不需要管模型部署的生命周期。这个设计的妙处在于它降低了AI的使用门槛。以前团队想用大模型能力得先有算法工程师还得有人会部署推理服务、处理OOM崩溃、做并发控制。现在这些底层事情Snowflake全包了分析师只要会写SQL就能把LLM接进数据处理流程。比如做客服工单分类过去要训练一个BERT模型折腾两周现在一条SQL加一个Prompt模板就能跑。这就是Cortex产品定位的聪明之处它不跟OpenAI抢着做大模型而是做大模型和企业数据之间的粘合剂。使用Cortex时大多数功能是按Serverless方式计费的用多少付多少。Embedding任务按token数和算力消耗计费COMPLETE调用按生成的token计费文档解析按处理页数计费。这种细粒度的计费模式对小微负载很友好小公司每个月花几十美元也能跑起来但大规模使用前必须做好预算评估我曾经见过一个团队用Cortex处理数百万份PDF一个月跑出了原本小半年的账单心里得有数。2.2 Snowpark和开源生态的取舍Cortex更像一个面向终端用户的AI功能集合底层的数据处理引擎则绕不开Snowpark。Snowpark是Snowflake推出的开发者框架支持Python、Java、Scala让用户把数据处理的代码搬到平台的虚拟仓库里执行。它的逻辑跟Spark很像但依赖的是Snowflake自己的计算引擎数据不用出平台就能完成ETL、特征工程和模型训练的数据准备。Snowpark的实际价值在于把AI管线和数据平台的技术栈统一了。以前做机器学习项目特征工程在S3里的EMR集群上跑特征存储放Redis训练在SageMaker上线还要再接回数据仓库做推理服务整条链路非常割裂。现在用了Snowpark至少在数据加工和特征生成这一段可以跟日常SQL任务共用一套基础设施和安全策略权限、血缘、审计都在一个平台上管理。这对企业合规部门来说是很加分的点。但Snowpark也不是没有槽点。它跟本地Spark在很多语法上并不完全兼容搬迁移成本并不低而且如果数据源不在Snowflake里硬把所有数据都导入进来再处理传输成本和时间成本会让人头疼。我的建议是Snowpark更适合那些数据治理要求高、数据已经集中在Snowflake的场景如果数据本身分布很散还是应该用Databricks或者定制化数据编排方案不必强行归一。再说开源生态的取舍。Snowflake一向是“商业产品优先”的思路不像Databricks直接开源了Delta Lake和MLflow也不像ClickHouse那样拥抱纯开源社区。这导致一些开发者觉得Snowflake的生态封闭。但它通过跟Hugging Face、LangChain等头部框架做集成把主流的开源模型和应用开发工具拉进来自己专注做平台层的数据管理与安全性。产品设计上不算追随也没有被落下。3. 实操视角我在Snowflake上落地AI工作负载的经验3.1 典型场景非结构化数据与LLM组合近几年企业数据中增长最快的其实是PDF、Word、聊天记录、工单文本、网页抓取内容这些非结构化数据。传统数仓完全不擅长处理这些既没有解析能力也没有地方存向量。Snowflake的Cortex系列函数里有不少针对这个场景的组件比如文档解析切片、Embedding向量化它们和原生向量类型配合得很紧密能把“非结构化数据入库”这件事拆成一套自带扩展能力的流程。我曾经帮一家客户搭建企业知识库问答系统就用到了这套能力。数据来源是几百份产品手册和售后文档处理流程大致是先把文档传到内部Stage再用文档切片函数拆成固定token长度的块紧接着用Embedding函数转成向量写入带VECTOR数据类型的表里最后通过Cortex的检索生成函数做回答。整个过程只需要写一串SQL和少许Python脚本比用LangChain在外部自己搭建再同步回数据库省事很多。这流程里有几个关键点要注意。第一是切片粒度切太细语义会断裂切太粗检索精度差需要根据文档结构和模型上下文长度测试调整。第二是元数据保留每条切片必须携带来源文档、页码、标题等信息否则回答时给出处溯源时会很麻烦。第三是权限管控不是所有人都有权调用所有文档的向量向量表要设计好访问控制避免敏感信息通过RAG泄露。3.2 成本与性能的平衡点AI负载上了生产环境之后最现实的问题就是成本和性能的平衡。Snowflake的计费逻辑很透明但也很“诚实”——你用的每一秒计算、每一个token它都算钱。Batch量的Embedding任务尤其要留意因为它的时间跨度长虚拟仓库需要一直处于运行状态尤其是选了大仓库同时跑大量并发任务时账单数字跳得很快。我的经验是能拆小就别跑大。如果一个Embedding任务可以按部门或日期范围切成多个小批次就尽可能拆分让每个批次跑在相对小的仓库上既能并发执行又不会因为单次任务量过大而被迫开大仓库。定价上Serverless功能按实际用量计费适合负载波动明显的场景固定虚拟仓库适合稳定的批处理。把这两类负载分开能省下不少预算。数据倾斜问题也需要提前考虑。做特征工程时如果某些用户的数据量异常大会导致部分Executor长期饱和其他Executor闲置仓库时长却一直在计费。我遇到过一份电信客户数据头部1%的用户占了80%的日志量跑Join的时候性能差到离谱。后来做了KEY级别的分桶和预聚合才把作业时间从40分钟压到9分钟。3.3 踩坑记录与排查技巧很多人以为把数据丢进Snowflake就万事大吉实际用下来坑并不少。我一个一个说。文档解析偶尔会丢字段。扫描件和复杂表格的OCR效果并不稳定纸质表格转出来的内容可能顺序错乱、字段缺失。上线前一定要抽检最好人工校对一批黄金文档算一下解析准确率不要盲目相信工具输出。向量检索的召回率会受Embedding模型影响。Snowflake支持多个Embedding选项也有通过外部函数接入其他模型的方案。不同模型在不同垂直域的差异很大通用模型在法律、医疗这类专业文本上很容易“翻车”有条件还是应该跑一下自己的评测集用模型跑一遍相似度排序看返回结果靠不靠谱。权限管理很容易被忽略。RAG系统最常见的泄露路径就是“检索时不过滤”。用户提出的问题触发了对所有文档向量的检索结果把不该看的内部数据带进了答案。解决方式不复杂但必须做向量表行级权限与文档密级映射到角色检索语句强制带上访问控制的过滤条件。还有一些小的环境教训。账户级默认参数、网络策略、外部Stage的存储集成这些在上生产之前就提前调好省得后面手忙脚乱。尤其是从本地读取数据时要确保IAM角色和存储桶策略配置正确否则一条简单的COPY命令都能让你排查一小时权限问题。4. 破局与隐忧Snowflake的AI竞赛4.1 护城河与软肋Snowflake面对AI浪潮是有底气的底气之一来自数据存储的盘子和生态粘性。数据平台这类产品天然有网络效应客户数据一旦沉淀进平台后续的ETL、可视化、机器学习、分享协作都会在同一个生态里进行批量迁移的成本极高。AI时代再热闹也绕不开数据这一层地基雪花手里这张牌打得好。它的软肋也同样明显。底层存储和对象存储绑得太深数据从外部进入Snowflake的成本仍然不低这会导致部分用户在初期选型时犹豫。同时AI时代真正赚钱的环节很多集中在GPU算力和模型层而这两块并不是Snowflake的核心。它更多是在平台层赚“数据连接模型”的钱跟英伟达、OpenAI动辄百亿美元的AI收入比起来体量还小得多。另外多云架构虽然能避免绑定单家云厂商但也让它在跟AWS、Azure自家的数据服务竞争时没有压倒性优势。客户如果把数据放在AWS上要决定是直接用Redshift搭配SageMaker还是多花一份钱上Snowflake的AI栈这时候产品体验和数据治理能力就成了关键。能否讲清楚“为什么多花这笔钱值得”是它必须持续回答的问题。4.2 生态竞争中的位置把Snowflake放到更大的框架里看AI数据平台的玩家如今已经分成好几派。Databricks靠开源模型和Unity Catalog抢了大量AI原生团队尤其在初创公司里渗透率很高。AWS和Azure把AI能力深度绑进自家云服务打包起来价格优势明显。Google BigQuery背靠Vertex AI和Gemini在AI推理与数据结合的便利度上也有自己的位置。Snowflake夹在中间更像是一个“中立的、跨云的数据AI工作台”。这个位置有好有坏。好处是中立性客户不管底下的基础设施用的是哪家云Snowflake都能提供一个统一的处理层和AI能力入口对大型跨国企业尤其有吸引力因为他们往往同时用多家云。坏处是跨云部署往往带来额外的延迟和数据传输费用如果处理不当“中立”反而会成为劣势。Snowflake很清楚自己的定位所以大力推安全的数据分享和合规治理能力这些领域恰恰是AI时代的刚需。企业不敢把数据随便交给模型厂商却依然需要一个平台来管理哪条数据、哪个模型可以访问什么东西Snowflake在“AI治理”上抓得相当紧。这跟早期它靠“数据共享”打天下的打法如出一辙本质思路是用平台和生态锁定企业级客户。5. 给团队的借鉴与思考5.1 数据平台如何承接AI需求看完Snowflake的打法我们团队内部复盘时聊到一个核心问题普通公司的数据平台怎么承接正在爆发的AI需求Snowflake的路径其实给出了很好的参考——不要把AI简单理解成“训练一个模型”而是要把AI能力无损地嵌入到现有数据处理流程里。具体操作层面建议分三步走。第一步先跑通非结构化数据的入库和检索这是大部分企业最先能用上的AI能力第二步在现有数仓旁边加一层向量数据和Prompt管理让业务分析师能直接通过SQL或者低代码方式调用大模型能力第三步把AI任务纳入成本和性能的监控体系像管理SQL查询一样管理AI任务从预算、优先级、资源配额三个维度做治理。这三步不需要一开始就推倒重来现有平台之上增加功能模块即可。即使你用的不是Snowflake这套思路照样适用AI和数据平台的融合终究是“能力内嵌”而非“架构重建”。我见过不少团队急着上全套AI平台最后重蹈数据仓库初期的覆辙技术顶级运维复杂业务根本没接住。5.2 避免AI概念空转最后必须要泼一盆冷水AI需求再热不能为了AI而AI。Snowflake能借AI实现营收增长核心原因是它的客户确实用这些能力解决了实际问题——降低了客服成本、提升了文档处理效率、让分析师能自己写模型推理——而不是为了在财报里写一句“我们支持AI”。这件事说起来简单做起来极考验团队对业务场景的判断力。我观察到一个比较普遍的失败模式是公司采购了AI平台、引进了算法团队、做了好几个炫酷的Demo但最终没有一个真正上线被业务方日常使用的模型。究其原因大多是需求不真、数据不齐、预期过高。如果你所在团队正准备布局类似技术建议用一个真实业务部门的小需求做切入点跑通从数据准备、模型选择到效果评估的完整闭环哪怕场景小一点也不要一开始就铺一个大中台。小场景能走出来扩规模才有底气小场景走不通就说明链路本身还存在问题这时候停下来调整比硬着头皮铺开更明智。我个人的体会是AI在企业里的落地本质是“把数据变成可行动的结果”。谁的平台能让这件事更简单、更可控谁就能在下一轮竞争里站住脚。Snowflake只是众多探索者里的一个样本但它证明了一件事AI不是独立于数据体系之外的新世界而是数据体系演进的方向本身。把这个逻辑想清楚再看各种各样的AI产品、技术标签你就不容易被带偏。