2025年Snowflake研究报告：产品迭代显著增强，渠道调整基本完毕，在预算波动环境下预计保持韧性

1. 投资亮点：AI 应用技术栈转型，非结构化数据管理需求提升

过去 1 年，Snowflake 在竞争格局及行业 IT 预算压力方面边际改善，其中

竞争格局上，Snowflake 拥抱 Iceberg+Polaris Catalog 后没有看到存储收入的压力，反而吸引更多客户 将负载迁移至 Snowflake 执行。成本优化方面，Snowflake 2022 年 8 月以来持续推动 SQL 引擎优化、 自动暂停长时间未活动负载等，年化成本节约达 20%（2023/10-2024/10），高于同行此前的水平（Mid to High single digits），我们认为大多数客户在 IT 预算优化方面实现绝大多数目标。后续的部分压力主 要来自 ETL向外部迁移，如采用云厂商或 Spark 生态的工具可以节约部分成本，但边际压力有所趋缓。

行业 IT 预算方面，Snowflake AI 敞口扩大，客户预算粘性增强。随着 Snowflake 过去 1 年大幅提升产 品&工程迭代速度，AI 产品线日趋丰富，工程环节的 Snowpark Container Service、Iceberg 等已经开始 产生收入，而应用环节的 Native App、Streamlit、Cortex AI 尚未明显贡献收入，预计 CY2H25/26 可能 开始贡献一定体量的收入（受益于 DeepSeek 降低成本）。 行业成长逻辑，上云仍然是数仓核心驱动力，2023 年上云率达 43.3%，相比于整体 50-60%的工作负载上云 率，仍有一定的提升空间。据 IDC，Snowflake 所属的云关系型数据库市场 2022-27 年复合增长率预计达 20.6%， 占数据管理领域的份额从 2022 年的 48.5%下降至 46.9%，略低于行业整体 21.4%的增速。

边际上，Snowpark 的流行度正在快速追进 Spark。2025 年 4 月 Snowpark 下载量大幅提升，4 月 1-11 日的 下载量大约为 PySpark 65.0%。这里的下载量是边际值，因此从存量的角度差距仍然较大，但边际提升趋势非常 积极，对于年内 Snowpark 商业化趋势具有一定前瞻性。Snowpark 客户基本上是客户转向 AI/ML的第一步，后 续是 Dynamics Tables/Cortex AI/Streamlit 等，其他 AI/ML产品主要处于产品打磨阶段，商业化预计仍需一定时 间。

2. 数据管理架构：从三层架构转向哑铃形分布，中间层面临持续压 力

数据管理从三层架构转向哑铃形（强化两端，弱化中间）。传统上，数据湖采用铜、银、金三层结构，其 中铜层主要存储未经处理或仅轻度处理的数据，银层将数据直接转换为高度优化的分析形态，金层则是所有消 费发生的地方，例如下游的 BI/ML场景。这一架构存在的问题包括 1）数据处理延迟：传统架构需经过原始数 据到中间层（银层）再到消费层（金层）的多级转换，导致数据可用性时间较长；2）复杂性高：需维护复杂 的中间层逻辑，涉及定制化处理和非通用数据模型，增加开发与维护成本；3）灵活性不足：未能同时满足交 互式工作负载（如仪表盘）与非交互式工作负载（如批处理分析）的需求。

针对这些问题的改进包括①分段优化（哑铃架构），具体来讲 1）跳过中间层：直接从原始数据区转换到 优化分析存储，缩短数据到洞察的时间；2）按需定制：针对特定工作负载（如威胁建模、实时分析）创建定 制化语义分析数据模型，提升效率2；3）成本优化：降低冗余存储需求，结合廉价云存储（如 Delta Lake）节 省原始存储层成本。②湖仓一体架构，涵盖 1）支持多模态数据：通过 Delta Lake 等开放格式，统一管理结构 化与非结构化数据，减少数据孤岛；2）实时处理能力：通过流式处理（如 Kafka + Iceberg）直接导入数据 湖，支持 AI/ML场景（如自动驾驶开发）。

存算分离带来效率提升，成本优化空间较大

这一趋势背后仍然是存算分离带来的效率提升。以可观测性产品为例，如 Datadog/Elastic 往往主要采取存 算一体架构，即数据存储和处理都在同一个节点上进行，但存算分离则强化架构的可扩展性，增强资源利用率， 是经济效益驱动的选择。这种趋势下，底层的存储架构尤为重要，一些客户引入 Doris/Snowflake 等提供存储， 基于外部存储方案进行可观测分析，这对应整体成本的大幅下降。 Elastic/Datadog 等厂商目前在存算分离方面也有布局，但主要集中于开源方案和一站式方案。Elastic 提供 ES-Hadoop/Elastic 与 Snowflake 等集成/Elastic Cloud，分别对应完全自建/外部集成/一体化解决方案，其中 ES-Hadoop 需要客户自行构建和维护 Hadoop 集群和 Elasticsearch 集群，Elastic Cloud 则完全由 Elastic 构建和维护 基础设施，Elastic 与 Snowflake 集成则 介于两者之间。 Datadog 也有类似的方案，包括 Datadog Log Management/Archive to S3，即 Datadog 提供一站式解决方案或与 AWS 的 S3 存储集成。 对比 Snowflake + Elasticsearch 方案与 Elastic Cloud方案的成本：定性来看，Snowflake 在存储成本上低于 Elastic Cloud，主要由于列式存储架构的性能优势，但这会带来额外的网络传输成本，即将 Snowflake 的数据传 输至 Elastic 集群，这可能涉及数据跨云/跨地区迁移。定量来看，2024 年初 Snowflake 在美国北弗吉尼亚州/欧 洲地区的存储成本约为$40、$45/TB/月3，而 Elastic Enterprise 版北弗吉尼亚州冷存储价格为$217/TB/月，爱尔兰 （欧洲区数据中心）冷存储价格为$265/TB/月4。根据测算，Snowflake 存储+传输后平均比 Elastic 存储成本低 55%，如果考虑均存储于 AWS，仅在不同地区传输则成本平均低 64%。因此，Elastic 等可观测性厂商在存算分 离领域的布局尚不完善。但需要注意，将数据分布式存储可能带来响应时长提升，尽管运维分析并不需要毫秒 级别的响应，但也是需要分钟级的响应，大量数据的分布式存储可能会对响应速度构成挑战，因此客户并非完 全根据成本进行部署决策，而是首要考虑可靠性和稳定性，其次才是成本。

总结来看，尽管哑铃架构下增加了对于按需定制分析模型的需求，带来额外的开发及运维复杂度，导致① 模型碎片化：每个定制化分析模型仅适配特定业务需求（如 Atlassian 的故障定位、供应链预测等），导致大量 独立模型并存，需单独维护；②技术依赖增强：需集成多源数据（如 Splunk 日志、SignalFx 指标与自有应用数 据），依赖 Dremio、Starburst 等工具直接连接原始数据和优化端，增加了技术栈复杂度；③频繁调整需求：模 型需随数据特征变化迭代（如自动驾驶车辆传感器数据时效性要求），维护团队需持续监控与更新。但出于对 实时性要求的提升，企业仍然倾向于将部分数据切换至哑铃架构以应对业务需求，典型用例包括①超大规模数 据（如 PB 级车联网日志）下，模型需实时响应以支持高 SLA 的场景（如降级定位、自动驾驶决策）；②医疗 公司的实时患者数据分析，使用 Kafka + Iceberg 实时摄取心电图数据，直接写入 Databricks 分析层，将数据生 成到预警缩短至秒级，传统架构延迟则在分钟级。 新架构相应也带来一些问题，例如哑铃架构的维护负担可能随着数据规模增长而加剧，但企业可以选择利 用第三方工具优化和统一管理定制化负载，例如通过工具链标准化（如 Iceberg 统一数据格式）和自动化（如 Airflow 调度模型训练）缓解重复开发问题。 按需定制的哑铃式架构本质是企业在速度、成本、灵活性与复杂性、资源消耗间的战略性取舍。其核心逻 辑是：牺牲部分可维护性以换取业务敏捷性。随着数据规模扩大，开发负担可能上升，但通过优化工具链和采 用分层管理策略（如保留原始数据+部分中间缓存），企业可部分对冲负面影响。这一趋势反映了数据驱动时代 对实时性与垂直场景深耕的迫切需求。

统一的数据表格式、数据治理工具也进一步标准化数据连接层

Snowflake 于 2Q24 加速支持 Iceberg 开放表格式。Snowflake 在 2023 年 7 月即开始通过 Iceberg Tables 更 新 支持数据湖工作负载，但当时主要面向早期用户。2024 年 6 月后，随着 Polaris Catalog 的开源和功能完善， 其支持范围显著扩大。Snowflake 于 2024 年 6 月 3 日正式发布 Polaris Catalog，这是一个支持跨引擎访问 Iceberg 数据的开源工具，标志着其对 Iceberg 技术的深度整合。截至 2025 年 3 月，Snowflake 已有约 500 个企业账户采 用 Iceberg 格式，表明其支持已进入规模化应用阶段。 Iceberg 支持 ACID 事务同时降低锁定风险，但相应牺牲专有引擎的性能优势。Iceberg 支持 ACID 事务、 模式演变（Schema Evolution）及时间旅行（Time Travel），解决了传统数据湖中原子性更新和一致性难题。另 外，Iceberg 采用 Parquet 文件存储数据，优化列式读取性能，并通过元数据抽象层（Table Metadata）实现数据 分区和文件粒度的索引管理。Iceberg 成为事实标准后（如 HTLF 选择 Polaris 与 Iceberg 结合），用户可脱离专 有存储（如 Delta Lake），降低迁移锁定的风险。相应地，采用通用格式后 Snowflake/Databricks 过去针对SQL/Photon 引擎的优化则影响降低，客户面临牺牲性能换取开放性的权衡。据腾讯 2023 年的分享5，Iceberg 依 赖对象存储（如 S3），在一些用例上存算分离导致本地计算性能损失约 30%，需更多计算资源弥补延迟。而 AW S 则分享6，对于实时摄入的场景，由于 Iceberg 元数据和版本管理的机制，会导致比较多的小文件，过多的小文 件会导致查询变慢，也会带来更多的 S3 请求数量，导致成本的增加，因此需要定时对 Iceberg 表已经维护。

Databricks 针对 Parquet 文件有针对性优化。Databricks 的 Delta Lake 通过优化 Parquet 文件（如 Z-Ordering） 提升查询效率，但传统上依赖自身生态，Iceberg 普及后逐步开放兼容（如收购 Tabular）。 数据格式通用性也意味着 ETL 的需求相应降低，节约成本。传统 ETL需在数据写入后进行修正，而 Iceberg 通过 ACID 事务直接保障数据一致性，减少额外 ETL 步骤7。在预处理方面，Iceberg 的元数据版本控制允许直 接查询原始数据，无需预先转换。例如，业务可直接分析 Iceberg 原始表，省去 ETL 中数据标准化的中间步骤。 元数据还支持快速分区过滤，避免全表扫描，降低 ETL对数据预处理的需求。在跨系统查询/修改时，Iceberg 作 为开放表格式，支持多引擎（如 Trino、Spark）直接读写，避免传统 ETL 中数据在不同系统间迁移的开销。例 如，数据可直接从 Iceberg 表供分析引擎消费，无需通过 ETL 导出到专用仓库。据小红书团队分享8，引入 Iceberg 并结合一系列数据同步策略/架构调整后存储/带宽成本优化 80%+。 但 ETL 在复杂场景/强监管的场景下仍具备不可替代性。ETL可嵌入数据质量校验规则 （如去重、空值填 充、异常值过滤）。例如，金融业务需通过 ETL 移除敏感信息以满足 GDPR 合规要求，而实时流处理可能无法 同步完成此类复杂清洗。另外，面向多种异构数据源（尤其是遗留系统）时，由于传统 ERP 系统接口封闭，需 ETL适配器完成数据抽取，无法直接对接 Iceberg 等现代格式。 总结来看，对于绝大多数业务场景，例如 1）存储成本主导型业务，例如大量社交、电商平台的用户行为数 据、交易数据占据大量存储资源，对于这类场景引入 Iceberg 结合其他优化策略，小红书团队实现存储/带宽成本 优化 80%+，高于此前腾讯团队测试下计算性能损失 30%的水平，也就是总体系统运行成本预计仍然是下降的； 2）中等实时分析场景，例如日志分析（运维/网络安全），结合 StarRocks 优化查询性能后，查询时长缩短 80%， 也好于计算性能的损失。但对于高并发且强实时性的场景，转变架构可能带来成本提升，例如金融防欺诈对于 延迟非常敏感，而 Iceberg 的小文件问题可能因频繁合并操作推高计算成本和延迟，相比于原有架构性能改善不 明显。

除统一表格式外，Snowflake 于 2024 年 6 月 3 日首次发布 Polaris Catalog，并于 2024 年 10 月 18 日全面可 用（Generally Available），与 Unity Catalog 相比，Polaris Catalog 定位更加开放且中立9。但在产品功能方面，Polaris Catalog 尚处于追赶 Unity Catalog 的状态，例如在元数据管理方面，Unity Catalog 提供更全面的治理功 能（如行/列级权限、数据血缘），覆盖数据、模型、特征全生命周期，而 Polaris 仅专注数据层；在安全合规方 面，Unity Catalog 内置细粒度访问控制（如动态数据脱敏），更适合高监管行业，而 Polaris 依赖开源社区的安 全策略（如 Gravitino）及 Snowflake 原生安全策略。因此 Polaris Catalog 尚处于丰富工具箱的阶段，还没有达到 成熟的端到端解决方案，因此主要吸引 Snowflake 生态内的客户，而非竞争新客户。

后续关注 Polaris/Unity Catalog 在如下方面的改进：1）自动化爬虫遍历数据并注册至数据目录中，降低管 理/维护成本；2）Polaris 是否增加支持第三方身份验证产品，如 Okta、Google Auth 等；3）增强对于非 Iceberg 格式的支持；4）强化自动化数据治理工具，例如数据保留策略以符合外部合规要求，提供审计日志， 自动化检测并进行权限分类；5）强化与后端 MLOps 的集成。

从数据管理延伸至 MLOps，构建 AI 应用技术栈

由于对非结构化数据支持度不足，且下游模型部署依赖外部工具，全生命周期管理能力弱于 Databricks。 在 AI/ML功能集成方面，Databricks 通过统一的数据湖仓（Delta Lake）整合结构化与非结构化数据，直接支持 机器学习全流程（数据准备→特征工程→模型训练→部署监控），同时集成 MLflow（实验跟踪、模型注册）、 AutoML、Feature Store（特征管理）和向量索引服务，减少对外部工具的依赖；而 Snowflake 以 Snowpar k 为核 心，通过 Python/Java API 支持数据转换和机器学习，但依赖第三方工具（如 Nvidia NeMo、Dataiku）实现模型 部署和监控，由于对非结构化数据支持度不足，且数据目录 Polaris 聚焦于 Iceberg 格式管理，无法进行跨系统 的联邦查询和血缘追踪。 Databricks 在 MLOps 环节具备优势，但 DeepSeek、Qwen 等团队在 MLOps 方面的开源推动 SaaS 团队缩 小差距。2024 年 2 月 Databricks 宣布以 13 亿美元收购 MosaicML，主要考虑是纳入其 ML 团队（此前发布正交 微调框架，优化模型微调效率）。此后，Snowflake 于 2024 年 5 月考虑以 10 亿美元收购 Reka，强化自身 M L 团 队能力，提供自研模型训练/推理框架，但后续交易终止。目前 Snowflake 暂无原生的分布式训练框架16。但考虑 到 DeepSeek、Qwen、Google 等团队在 MLOps 方面持续的开源工作，大量中小 SaaS 厂商溢价收购模型团队的 意义正在缩小，跟随业界开源工作并做好与生态的集成适配就能够满足大多数客户的需求。 Databricks 和 Snowflake 在 SQL 引擎方面取向不同，但在复杂场景下 Databricks 路线具备优势。Databricks 的 Genie 工具适应于预定义语义层后进行自然语言转换 SQL，准确率较高，误报/后期验证成本较低；而 Snowfla ke Cortex AI 无需预定义语义层，但通过 LLM 解析转换 SQL效果弱于 Genie，容易导致后续审核/验证的额外成本。 换言之，在复杂场景下预定义语义层可以更精确地进行转换，Genie 的效果更佳，而标准化场景下双方差异不大。典型的复杂用例包括自动驾驶数据标注管道、实时视频流特征提取等，而简单用例包括财务部门报表自动化提 取。

在血缘追踪方面，Snowflake 覆盖度不如 Databricks 全面。Databricks 通过 Unity Catalog（统一元数据管 理层）实现了跨数据湖、数据库和实时流数据的端到端血缘追踪能力，其中 1）包括非结构化数据处理（如 JSON、图像、文本）的元数据关联；2）Unity Catalog 基于 Delta Lake 的 ACID 事务特性，通过事务日志 （Transaction Log）记录所有数据操作（如 INSERT/UPDATE/MERGE）的上下游依赖关系，并实时更新血缘 图谱。Snowflake 血缘追踪主要通过 Snowflake Account Usage Schema 提供，但其设计更侧重于表级和查询级 的统计信息（如查询历史、访问日志），颗粒度弱于 Databricks，因此无法追溯 Python/Scala/Java 等代码中的 动态数据处理逻辑，且对 Airflow、dbt 等外部工具操作的元数据捕获能力较弱。在 AI/ML方面，Databricks 针 对生成式 AI 场景（如微调、模型部署）设计 MLflow Tracking17，可自动记录数据输入、模型版本、参数和输 出结果，形成完整的实验血缘；而 Snowflake 的 AI/ML功能（如 Snowpark ML）更依赖外部工具（如 AWS SageMaker），血缘信息需手动维护，难以自动化扩展。

在 AI 应用构建上，Snowflake 推出 Snowpark Container Services、Native App Framework、Streamlit 等工具， 而 Databricks 则依靠既有工具组合，例如 MLflow、Notebooks 等，成熟度低于 Snowflake（工具箱 vs 解决方案）。具体到 Snowflake AI 组件，根据一些早期反馈18，客户寻求将部分运维的工作负载迁移至 Snowpark 之上，在不 考虑折扣的情况下，Snowpark Container Services 的价格较 EKS 标价低~20%，但 Snowflake 不具备 EKS 的所有 功能，且面临低/中等吞吐量和高延迟（每笔交易 10-50 毫秒）的限制。而复杂工作负载下相比于 Databric ks 基 于 Phonton 引擎，Snowpark 的计算成本较高，目前更适应于简单负载。另外，更长远来看，在 Snowflake、Snowpar k 运行分析负载后无需支付 CSP 的数据传输费用，长期来看计算引擎的优化速度快于带宽19，就地处理负载的方 案性价比提升。

关于 Nativa App/Streamlit，二者均用于应用开发20，但 Native App 可将应用以包体形式组装便于分发和管 理版本，而 Streamlit 是一种更松散的形式，主要可用于内部应用。Snowflake 战略上倾向于引导合作伙伴/客户 构建 Native App 后在生态内销售，从而产生规模效应，降低中小客户的应用门槛。目前 Native App 的典型用 例21包括 1）财务报表实时分析；2）营销自动化；3）销售业绩洞察；4）实时整合商品库存及用户行为数据； 5）供应链报告自动化。Streamlit 此前一直是开源生态内 python app 开发的流行框架，成熟度相对较高，但企 业级安全等尚待改善。

Snowflake / Databricks 在架构迁移、成本优化及 AI 应用方面的进展

成本优化：过去 1 年稳定负载成本节约 20%

与 Databricks 引入 Catalyst 优化器对应，Snowflake 通过研发力量引入重大改进（成为平台默认配置）大 部分都是自动发生的，无需任何配置或额外的努力来修改代码。1）查询执行改进：缩短执行时间并更有效地处 理复杂的查询模式。示例包括优化连接查询、自动处理偏差和扩展对 Top-K 修剪的支持，以提高具有特定聚合 和过滤模式的查询的性能。2）数据提取和复制：减少元数据复制所花费的时间，加快克隆速度，并优化大型数 据集的提取，以更快、更可靠地将数据带入 Snowflake，从而简化工作流程和管道。3）自适应优化：推出一系 列自适应优化，使 Snowflake 能够更智能地选择最佳查询执行策略。例如，扩展 Top-K 修剪以包含更广泛的查 询。4）平台效率：Snowflake 继续提升平台的整体可靠性和速度。例如，团队缩短克隆操作所需的时间，提高压缩效率，从而减少资源消耗并使系统运行更加顺畅。

AI 技术栈成熟度：MLOps 方面 Snowflake 加速追赶 Databricks，应用组件领先 Databricks

Snowpark 的流行度正在快速追进 Databricks。从 Python 包体下载量看，Snowpark 相比于 PySpar k 的份额 大幅追进，2024 年 8 月 Snowpark 下载量大约为 PySpark 的 12.5%，而 2024 年 12 月就提升至 20.1%，处于稳步 提升状态。2025 年 4 月 Snowpark 下载量大幅提升，4 月 1-11 日的下载量大约为 PySpark 65.0%。结合 Snowpark 官方文档，我们摘取 Snowpark 下载量异动时的功能更新，对比如下。核心结论为 Snowpark 通过兼容 Pandas， 提升开发者体验等举措，已经吸引大量开发者基于 Snowpark 进行开发，边际上缩小和 Databricks 的差距，后续 关注在连接数据库操作及复杂数据处理上的性能/易用性提升。

Streamlit 方面，目前仍聚焦于支持私有云环境、强化数据传输安全等，对 AWS/Azure/GCP 环境的适配。在 产品功能方面于 2025Q1 开始迭代，支持文件上传、多种文件类型（如音视频），支持复杂页面管理和 Git 同步 （以便于版本控制），但仍然较为基础。我们预计 Streamlit 正在不断强化应用开发能力，有助于为后续 Snowfla ke 生态降低开发和部署门槛，但 1-2 个季度内可能不会看到商业化的明显信号。

运营效率：人员规模基本与 Databricks 同步增长，但在产品/工程方面仍然落后于 Databricks， 过去 1 年销售效率有所提升，领先同行

FY24-25 Snowflake 员工新增规模在 1000 人左右，且聚焦于 R&D 及 S&M，尤其是 AI/ML 部门的团队扩 张。FY26 管理层指引倾向于增加收入直接相关的部门员工（工程及销售团队）。产品侧过去几个季度管理层分 享的指标主要涉及 Iceberg、Notebooks、Cortex AI、Snowpark 等 Data Engineering 产品，其他诸如应用层 Native App/Streamlit 短期内无法产生实质性收入的产品优先级有所下降。因此，我们认为 AI 产品方面 Snowfla ke 目前 更多处于产品打磨阶段，而前述分析总结来看大多数产品处于“基本可用”（及格水平）、“难用”（不及格） 阶段，没有达到“易用”水平，缺乏足够多的标杆案例吸引客户投入预算进行 AI 流程改造。

（本文仅供参考，不代表我们的任何投资建议。如需使用相关信息，请参阅报告原文。）