2024年Snowflake研究报告：关注产品成本优化、开放生态进度，短期受IT预算削减与监管趋严压制增速

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

市场关注 Snowflake 的核心主要是 AI 受益逻辑，其核心逻辑为：Snowflake 增强客户管理数据的能力，并 引入 AI/ML 等工具增强数据分析能力。1、AI 会加速数据从本地数仓向云数仓的迁移，理由是数据生成速度大 幅提升，且数据上云能最大化 AI 带来的价值。此外，与 MongoDB 在投资者日所提到的逻辑类似，Gen AI 将带 动应用技术栈转变。AI 可能会促进自动化开发，推动 1）应用开发数量的提升；2）数据密集型应用增加（数据 库支出占比提升）等。此外，AI 应用开发衍生出新需求（向量搜索），相当于 Snowflake 增加工作负载，会提 升客户的平均付费。2、数据迁移后基于 Gen AI 分析数据，这意味着企业 BI 端的支出比例提升。

经过深入的研究，我们认为 1）Snowflake 面向 AI/ML 领域的敞口很小，绝大多数都是通过 Snowpark 等处 理的，而这些产品多半处于 Preview 阶段或市场渗透率很低。考虑 Databricks/Spark 生态的积累，在短期内指望 Snowflake 在 AI/ML 赶超 Databricks 是不现实的。目前来看，Databricks 受益 AI/ML 的方面主要是大模型训练的 数据准备，AI+推荐/搜索引擎等用例尚不确定，可能与 Confluent 等竞争。2）Snowflake 的 AI 主要用于增强非 结构化数据的处理能力，从而增强 BI 洞察能力。关于 AI 应用开发，由于多模态大模型生成数据以非结构化为 主，Snowflake 的受益幅度可能较有限。

竞争逻辑方面，我们首先分析数仓性能，其次比较统一分析平台生态。核心结论是

单点数仓性能方面，Redshift/Databricks 在较大计算资源投入下具有较好的性能/成本优势，而 Snowflake/BigQuery 在中等及小型计算资源下具备较好的性能/成本优势，Synapse 几乎在各类场景下 均不具备额外的性能/成本优势。主要差异在于细颗粒度的并发缩放，例如集群内的并发缩放，实现难 度在于底层计算和存储资源的实时监控和精细化管理。Snowflake 依托于云厂商，通过 API 形式调用资源，但可能面临 API 调用频率的限制。为实现精细控制，Databricks 提出细颗粒度、自动化的资源配 置策略，这导致厂商在成本/性能可扩展方面的差异。但 Google BigQuery 工程师 Jordan Tigani 所观察 到的，99%的客户查询数据都小于 10GB，Databricks/Redshift 在公众宣传时强调大规模数据场景的高 性能表现本质是面向 Top 1%的客户，而忽略 99%的客户需求，在数仓领域 Snowflake 仍然具备较强的 性能和成本表现。

统一数据分析平台方面，Databricks 长期致力于构建开放、高性能的 Spark 生态，在数据目录方面提出 Unity Catalog，在表格式方面提出 Delta 等，占据主导地位。Snowflake 2022 年通过支持 Iceberg 向开放 生态迈出一步，但在数据目录/方面主要依托第三方工具。湖仓一体架构上，Snowflake 在数仓外构筑 独立的数据湖，并通过高速互联网络连通二者，而 Databricks 则在数据湖之上构筑数仓。考虑数据处 理的链路顺序，绝大多数用户都是将数据存储于 Databricks，经过 ETL 等处理后导入 Snowflake，其具 备一定优势，这也是市场对 Snowflake 的长期忧虑。中短期看，Snowflake 在实时处理、易用性方面具 备优势，能够稳住既有客户预算。

行业成长逻辑，上云仍然是数仓核心驱动力，2023 年上云率达 43.3%，相比于整体 50-60%的工作负载上云 率，仍有 25~50%的提升空间。据 IDC，Snowflake 所属的云关系型数据库市场 2022-27 年复合增长率预计达 20.6%，占数据管理领域的份额从 2022 年的 48.5%下降至 46.9%，略低于行业整体 21.4%的增速。

短期来看，Snowflake 受 IT 预算优化影响，客户在分析支出预算方面削减弹性大于存储，这导致 Snowflake 收入增速存在一定压力。另外，欧盟 AI 法案及数据合规监管趋严，很多企业都在暂停/放缓数据迁移上云，等待 监管落地及主要供应商如 Snowflake、AWS 等提供合规数据治理环境后再启动上云。竞争方面，如 Oracle 等竞 争对手通过激进折扣等方式延缓客户/工作负载的流失，从而导致新增负载方面存在一定压力。后续继续关注成 本优化及行业 IT 预算优化周期。

2. 引言：Snowflake 从何而来

Snowflake 的推出旨在解决大数据平台的潜在不足。Snowflake 团队在论文《The Snowflake Elastic Data Warehouse》提到，数据仓库面临 1）原有数据架构弹性不足，在云计算时代，大数据还是以固有的资源体系 架构进行设计，无法满足灵活的弹性伸缩能力；2）多种数据格式支持度不足等问题，在计算处理过程中，对 于半结构化和非结构化数据的处理不够友好。

对 1）的解释，所谓数据仓库弹性不足，指的是相对于底层 IaaS（计算、存储）。大数据是在 2008 年前后 发展起来，解决的是互联网时代数据量爆发引申出的大数据量数据分析和处理的问题，云计算的本质还是在于 硬件发展速度受限，摩尔定律失效如何提升整个资源利用率的问题。云计算通过分布式架构解决了扩展性问题， 但当时的问题是数据库/仓库没有更新架构，导致资源利用率不高。 大数据具备以下特点4：1）数据量（Volume）：大数据的规模庞大，可达到 TB、PB 甚至更高，传统数据 库无法有效处理如此规模的数据。2）多样性（Variety）：数据类型繁多，包括数值、文本、地理位置、图片、 音频、视频等。处理多样性数据对数据库架构提出较大挑战。3）价值（Value）：原始数据混乱无序，无法直接 提取有效信息。通过清洗、分类、汇总等处理，我们能够发现其中的规律，并将其转化为商业价值。4）速度 （Velocity）：早期的大数据处理框架只能进行离线批处理，无法实时处理数据。但互联网场景发展带来面向客 户报表需求增加，秒级、分钟级响应需求提升，对实时大数据处理提出需求。

如前所述，大数据平台/框架的发展基本是需求推动的，本质是硬件发展速度受限，行业起源来自 Google。 开源社区的大数据处理框架 Hadoop 源于 Google5的 GFS/MapReduce/BigTable。Hadoop 是一个可扩展的、分布 式的计算框架，它可以对大量的数据集进行并行处理。Hadoop 主要由以下三部分组成：1）分布式文件系统 HDFS；2）分布式计算框架 MapReduce；3）分布式资源调度框架 YARN。 Hadoop 的最大突破是引入了分布式处理架构，从而突破单台机器存储/计算能力的瓶颈。分布式处理架构底 层是 HDFS，HDFS 是一种设计用于在大规模硬件集群上可靠地存储大量数据的分布式文件系统。它的主要设计 目标是支持大规模离线计算和批处理6。 HDFS 采用主从架构。一个 HDFS 集群由一个 NameNode(名称节点)和多个 DataNode(数据节点)组成。 NameNode 是集群的主节点，负责管理整个文件系统的命名空间和客户端对文件的访问。它记录着所有文件的 元数据(文件名、目录、副本位置等)。DataNode 是从节点，负责实际存储数据块，并定期向 NameNode 发送心 跳和块报告。文件存储方面，HDFS 将每个文件切分成一个个小的数据块(默认 128M)，并在多个 DataNode 上存 储这些数据块的副本，以提供数据冗余和容错能力。数据块副本的存储遵循机架感知存储策略，即在不同机架 上各存储一份副本，以防止整个机架故障导致数据丢失7。

HDFS 的架构设计存在相应的问题：①通过冗余存储实现高可用性但导致高延迟和不支持随机写入，HDFS 将大文件切分成较小的数据块并分散存储在不同的节点上，且为简化数据管理，HDFS 中的数据块是不可修改 的，一旦写入后就不能再进行修改。由于写入时需要将文件分块并存储在不同 DataNode 上进行冗余存储，HDFS 的写入延迟较高。但由于分布式存储且存在多个副本，随机写入将很难确保数据一致性，在这种情况下实现随 机写入则需要将所有数据全部重新分块以实现写入。

②磁盘读取时间限制分块大小，架构设计导致难以兼顾不同大小文件的存储和计算。HDFS 的读取时间=读 取块数据时间+寻址时间，行业通行的经验规律是寻址时间为块读取时间的 1%时，集群读取效率较优，而一般 寻址时间为 10ms，那么块读取时间为 1s，而目前磁盘的传输速率普遍为 100M/s，因此块数据大小大致在 100M 范围。而由于主从架构，不论存储文件多小，都需要将元数据存储在 NameNode 中，导致小文件存储时 NameNode 空间使用效率不高。一些改进措施如多层次 NameNode 架构8、HBase9可以缓解小文件存储效率低的问题，但同 时降低了大文件存储和计算的效率。 计算侧，MapReduce 在实时处理及资源利用率方面也存在缺陷。由于 MapReduce 的计算是严格按照流 程，先进性数据映射、洗牌（Shuffle），最终进行规约，这种设计导致 MapReduce 无法提供毫秒级或秒级响 应时间。相似的，MapReduce 的输入数据集是静态的，这意味着它不适合处理动态变化的数据流。资源利用率 方面，由于 MapReduce 主要采取并行处理方式，针对 DAG（存在顺序依赖）任务，例如做饭需要先洗菜、切 菜、炒菜、装盘等步骤，无法同时处理，此时 MapReduce 一次只能处理一个环节，每次作业间的衔接都需要 通过 HDFS，下一个作业再从磁盘读取这些数据，在大型集群和海量数据背景下，这些特性降低 MapReduce 数 据处理效率。

Google 于 2004 年提出 MapReduce，主要用于大规模数据集的并行处理。MapReduce 模型的核心思想是将 复杂的数据处理任务分解成三个阶段：Map（映射）、Shuffle（规整）、Reduce（归约）。1）映射（Map）阶 段：首先，MapReduce 框架会将所有数据分割成多个数据块，并将这些数据块分配给集群中的不同计算节点。 每个节点上的 Map 任务会并行地读取它所分配的数据块，并执行特定的计算任务。例如，大家在图书馆找到所 有提到“月亮”这个词的书，每个人都负责检查一部分书籍，找到包含“月亮”这个词的书。2）洗牌（Shuffle） 阶段：MapReduce 框架会自动收集所有 Map 任务输出的中间结果，计算机会自动将所有中间结果中的相似部分 （比如所有提到“月亮”的句子）聚集在一起，为下一步的归约做准备。3）归约（Reduce）阶段：Reduce 任务 会对每个键对应的所有值进行归约操作。比如计算提到“月亮”的总次数，或者列出所有提到“月亮”的书籍。

后验视角看，Hadoop 流行度的下降主要是与需求场景不匹配。根据腾讯云《从 Clickhouse 到 Snowflake》， 数仓的重要变化是需求场景从后端走向前端。过往面向企业决策者的报表可以是低频的，但是面向外部客户、 用户、一线运营人员的报表往往是高频的，因此数仓实时性尤其重要。而 HDFS 的分布式架构不适应高频写入， 且分块处理导致延迟较高，根本上无法难以满足高频需求。另外，尽管 HDFS 本身可以处理大规模数据，但写 入延迟导致其可能成为系统的瓶颈之一，导致系统整体吞吐量受限。MapReduce 的批处理模式也更适应大规模 离线处理场景。

Spark 的发展主要聚焦 Hadoop 的潜在缺陷，对其做补充优化。Spark 最早源于 UCB AMP 实验室《Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing》，论文中提出了一种弹性分布 式数据集（即 RDD）的概念。RDD 是一种分布式内存抽象，其使得程序员能够在大规模集群中做内存运算， 并且有一定的容错方式。这是 Spark 的核心数据结构，Spark 整个平台都围绕着 RDD 进行。

Spark 通过引入 RDD，替换 MapReduce 作为数据接口，大幅提升集群处理效率。RDD 引入内存计算而非 磁盘计算，使得后续计算可以复用已经计算过的数据，减少从磁盘读取数据的 IO 开销，从而显著提高处理速度， 在迭代式计算和交互式查询等场景提升明显。另外，通过引入依赖关系和计算规则，RDD 实现高容错率（即 Resilient）。一旦数据丢失，RDD 可以通过中间变量+计算规则+依赖关系（即 DAG，有向无环图，或血统）恢 复丢失数据，而不必重新进行计算（MapReduce 的快照恢复则需要重新计算）。

易用性上 Spark 也较 MapReduce 大幅提升。MapReduce 框架下，开发者需要手动编写 Map 和 Reduce 函 数，通过 key-value 对的形式进行数据处理，这种方式在处理复杂查询和多步操作时，容易导致代码冗长且不易 维护。例如，如果要进行两次过滤、一次映射和一次聚合操作，需要分别编写四个函数，同时还需要处理数据 在不同阶段的读写和 shuffle 过程，这在大规模数据处理场景下繁琐且效率不高。Spark RDD 提供 Transformation 和 Action API，这些 API 允许开发者以一种声明式、函数式的风格编写代码12，即更关注“做什么”，而非“怎 么做”。

2012 年 Snowflake 开始立项，至 2015 年 6 月 Snowflake 向公众开放使用，站在当时的节点上看，Spark 在 1）内存管理上存在一定不稳定性；2）对 SQL 支持不足，且不满足 ACID 等要求等问题。因此 Snowflake 定位 上兼容数据库，且易用性高，这使得客户接受度较高，且迁移成本低。

Spark 支持 SQL 的思路来自 Hadoop 的 Hive，但相应的弊病仍然存在。在 2014 年 Spark 1.0 版之前，Spark 对 SQL 的支持来自 Hadoop 中的 Hive，并迁移至 Spark（Hive in Spark，即 Shark）。Hive 提供了一种类似 SQL 的查询语言（HiveQL），使得用户可以通过编写 SQL 语句来执行 MapReduce 任务，从而简化了对大规模数据 集的处理，但由于 Hive 底层使用 MapReduce 执行任务，每个查询都需要启动多个 MapReduce 任务，这导致了 较高的查询延迟。因此 Hive 存在对高延迟、不支持实时查询、复杂 SQL 支持度不足等问题15。Spark 引入 Hive 后，受益于底层内存计算的优化，Shark 整体计算速度大幅优于 Hive。 Shark 迁移适配成本逐步增加，Databricks 于 2014 年 7 月宣布转向 Spark SQL 开发，停止开发 Shark。由 于 MapReduce 与 Spark RDD 计算机制差异较大，如果将 Hive 的代码适配到 Spark，开发者需要确保所有在 Spark中运行的线程都能安全地访问和修改共享资源，以避免数据污染和不一致的问题。这就需要对 Hive 的代码进行 修改，增加适当的同步机制，以保证线程安全16。这增加了开发和维护的复杂性，并且是 Shark 面临的挑战之一。 由于适配成本随着 Hive 复杂化不断提升，Databricks 于 2014 年 7 月宣布停止开发 Shark，转向 Spark SQL 开发。

2015 年 4 月 Spark 1.3.0 引入 DataFrame API，在表结构方面实现改进，从而提升 SQL 查询性能。引入 DataFrame 之前，Spark 框架下缺乏预定义的表结构，因此处理结构化数据时需要开发者自己管理数据模式 （Schema），因此此前 RDD 模式下 Spark SQL 无法直接集成，而引入 DataFrame 后，由于 DataFrame 带有明确结构，且内嵌模式信息，这使得 Spark SQL 能够理解 DataFrame 中的数据结构。

Spark SQL 的核心是 Catalyst 优化器。①Catalyst 使用抽象的树结构来表示不同程序逻辑，包括 SQL 抽象 语法树（SQL AST）、DataFrame 或 Dataset API 的逻辑计划，以及最终生成的物理执行计划。采用树结构的原 因在于，树结构适合采用递归和模式匹配等算法进行遍历和转换，且具备足够通用性表达不同逻辑。场景上， SQL 查询和 DataFrame 操作可以转化为嵌套层次结构，例如嵌套的子查询、JOIN 操作等，树结构相比于 DAG 等更适合表达这类层次关系。 ②优化过程的关键在于规则的应用。Catalyst 引入了一系列规则，例如常量折叠、谓词下推18、投影剪枝19 等，可以将输入的树形结构映射到另一个经过优化的树形结构。其中，常见的优化手法是使用 Scala 的模式匹配 功能，对树的各个子树进行匹配，并根据匹配到的特定模式实施相应的优化转换。例如，当发现两个常量之间 的加法操作时，可以将其折叠为一个新的常量。以上优化均为基于规则优化，Catalyst 还引入基于成本的优化， 可在给定预算内寻找最优的执行计划。

Catalyst 优化器的工作流程分为以下几个阶段：如分析阶段（解析和类型推理）、逻辑优化阶段（如常量折 叠、谓词简化等）、物理计划阶段（生成具体的执行计划，考虑数据源格式、分区信息等因素，并基于成本估算 选择最佳执行路径）以及代码生成阶段（将部分查询转化为 Java 字节码以提高执行效率）。 通过分批执行规则集合直到达到稳定状态（即没有更多改变发生），Catalyst 可以逐步将用户的原始查询转 变为高效执行的物理计划。因此，即便加入新的运算符类型或数据源类型，Catalyst 也能够在不修改已有规则的 基础上，有效地利用扩展点来适应变化，持续提供优化服务。

经过 Catalyst 优化后，在 TPC-DC（数据库行业基准）方面，Databricks 在标准查询性能/成本方面均优于 Snowflake。但需要注意的是，Databricks 测试中采用的数据集大小为 100TB，远大于基准测试中 1TB 的规模。 另外，Databricks 采用了日期分区等高级调优功能，并且统计时报告总运行时间，而非几何平均/中位时间，总运 行时间可能受个别查询时长的影响。

支持 ACID 事务方面，Spark 的发展是渐进的： 1）Spark 早期版本（1.x）：Spark 早期版本主要关注于批处理和流处理，对 ACID 特性的支持有限。Spark SQL 提供了对结构化数据的处理能力，但其底层的数据抽象模型 RDD（弹性分布式数据集）并不支持直接的数 据更新和删除操作；

2）Spark 2.0：在 Spark 1.0 中，虽然批处理部分支持 ACID，但是流式计算是通过 Spark Streaming 实现的， 它将流数据按时间片切分，每个时间片中的数据都是无序且至多一次的处理语义，无法保证持久性。Spark 2.0通过引入结构化流处理25(Structured Streaming)确保 Spark 内核层面的 ACID 支持，后续在 2.2 版中引入 Kafka 集 成，确保从 Kafka 接收数据的 ACID 语义。

3）Spark 2.4 引入 Delta Lake：相比于 HDFS 仅支持文件级别的原子写入操作，Delta Lake 通过引入事务日 志实现对 ACID 的支持，例如在图书管理系统中 HDFS 仅支持对书籍层面的增删查改，而 Delta Lake 支持对书 本内部字句级别的增删查改，实现方式则是每当对表进行增删改操作时，Delta Lake 都会记录一个事务日志条 目，并且只有当事务成功提交时，这些更改才会被确认并添加到表的状态中。事务日志确保所有修改都是原子 性的27。除事务日志外，Delta Lake 还引入乐观并发控制（OCC）28、多版本并发控制29（MVCC）以及数据快照 和历史版本查询30等设计，提高事务吞吐量、动态解决冲突以及适应不同的工作负载，使得数据库系统能够在保 持数据完整性的同时，提供良好的性能和响应能力。

4）Spark 3.0：Spark 2.X 系列在 ACID 方面与专业数据库分析平台如 Snowflake 仍有一定差距，主要是端到 端的 ACID 支持，例如 1）微批处理的延迟32，结构化流处理采用的微批处理方式，虽然保证了每个批次内的 ACID，但会引入一定的延迟，无法做到低延迟处理；2）批流融合的困难33。结构化流处理流式计算设计，与批 处理存在一些区别和割裂，无法在批流两种模式间完全统一和无缝切换；3）中间状态的一致性34。结构化流处 理缺乏有效机制来保证作业中的中间状态在发生故障时的一致性，会影响端到端 ACID。 为了解决这些限制，1）Spark 3.0 通过缩小批次，引入自适应查询执行（Adaptive Query Execution, AQE）可 以动态调整执行计划以提高性能，缩短微批处理的延迟，但本质上仍存在一定延迟，无法达到真正的实时处理； 2）通过统一 API 解决批流融合，Spark 3.0 之前开发人员需要使用不同的 API 或逻辑来分别处理这两种情况。 在 Spark 3.0 中，通过统一的 DataFrame/Dataset API 以及集成 Delta Lake，都可以采用相同的编程模型进行数据 读取、写入及转换操作；3）Spark 3.0 通过整合 Delta Lake 或其他事务性存储层，能够更好地管理作业中的中间 状态并确保一致性。Delta Lake 的事务日志和检查点机制允许在发生故障时恢复作业状态，从而实现端到端的精 确一次语义（exactly-once semantics）。这意味着即使在系统出现故障的情况下，也能保持数据一致性，并且每 个事件仅被处理一次。

针对 2），互联网的发展带动数据格式发生变化，过去数据仓库中的大部分数据都来自组织内部：事务系 统、ERP、CRM 等。结构、容量和速度都是可预测且已知的。但是云计算使得相当大且快速增长的数据量来自 于不太可控的外部来源：应用程序日志、网络应用、移动设备、社交媒体、传感器数据（物联网）。除了不断增 长的数量之外，这些数据经常以无模式的、半结构化格式出现。传统数据仓库解决方案正在努力解决这种新数 据。这些解决方案依赖于深入的 ETL 管道和物理调优，从根本上假定来自主要内部来源的可预测、缓慢变化且 易于分类的数据。

Spark 在早期阶段主要聚焦结构化数据的处理，在非结构化/半结构化数据的支持方面相对有限。但随着引 入 Spark DataFrame/Dataset，Spark 在支持非结构化/半结构化数据方面取得长足进步。 数据格式支持的原理基于数据序列化和反序列化的过程，以及数据存储39和检索的优化。序列化是将数据 结构（如对象、数组等）转换为一种可存储或传输的格式（如 JSON、XML、CSV 等）的过程。这使得数据可 以在不同的系统之间进行交换，或者被持久化存储。反序列化是将这些格式转换回原始数据结构的过程。 对数据格式的转换可以通俗理解为如下案例，想象一个图书馆管理系统，图书信息以不同的数据格式存储 在不同类型的卡片上。有的卡片是表格形式（类似 CSV 格式），每行记录一本书的信息；有的卡片是用更复杂 的语言描述书籍信息（类似 JSON 格式）。为统一管理这些卡片，系统需要一个“智能助手”，它能读懂所有卡 片上的信息并将它们整理成电子数据库。 对不同数据格式支持，其技术难度主要包括 1）语法解析：每种数据格式都有其特定的语法和结构，开发人 员需要编写解析器来正确识别并解析这些格式，并能处理边界情况(Corner Case)和异常输入；2）性能优化：对 于大量数据的处理，高效的内存管理和 IO 操作至关重要。例如，快速解析大量 JSON 文件而不耗尽系统资源是 一个挑战；3）兼容性和扩展性：随着数据格式的发展和版本更新，数据格式支持应当能够适应新特性和旧版向 后兼容，同时允许在未来添加对更多格式的支持；4）错误处理和恢复：确保在遇到损坏或不完整数据时，系统可以尽可能地进行错误恢复，并给出清晰的错误报告。

总体而言，越是结构化的数据格式支持难度通常越低。例如，①CSV 解析器只需按行读取，并按照分隔符 (如逗号)拆分每行为多个字段即可，主要难度在于处理一些 Corner Case，如含有引号的字段、缺失字段、数据 类型推断等；②JSON 解析器相对复杂一些，存在嵌套关系，而解析器处理时会将嵌套关系记录，最终统一处理， 因此一旦层级较多或数组较多时，可能导致内存不足。此时可以通过限制递归深度/流式解析/分块读取和存储等 方式解决问题，但相应也会牺牲 I/O 操作和即时查询的性能等；③Parquet 相比于 JSON 更复杂，JSON 的解析是 线性的，但 Parquet 的解析是非线性的。举例而言，JSON 文件信息按行记录，每行可能包含各种主题（列）的 数据，一条记录完整地写在一起。Parquet 文件按照不同的主题（列）把信息分开存放，因此解析时需首先通过 元数据（索引）定位信息，再进行解析。 对于非结构化数据暂时没有通用、有效的方式，Spark 通过开发者自定义/第三方库间接处理非结构化数据。 如前所述，数据格式的支持本质是一个序列化与反序列化的过程，而非结构化数据没有统一的结构模板，因此 在解析时难以通过确定地规则处理。

对比而言，Spark 更加偏向于数据处理管道中的转换阶段，能够适应多种数据源和格式，而 Snowflake 更注 重于长期存储和高效查询，尤其是在结构化和半结构化数据领域表现突出。

Spark 的策略为依托开发者生态的力量。1）引入 Schema-On-Read 模式，即允许数据在被读取和处理时才 确定其结构（Schema），而不是在写入时就强制定义和验证。2）提供 Spark MLlib 和 Spark NLP 等库，其 中 MLlib 主要引入机器学习，例如通过预处理和特征工程将文本数据转化为结构化数值，或通过分类器和 回归器可用于处理经特征提取后的文本数据，进行情感分析等。3）Spark 允许用户通过自定义函数（UDF） 来实现复杂的非结构化数据解析逻辑，或者使用 Scala、Java、Python 等编程接口编写自定义数据处理器。

Snowflake 的策略是引入外部转换、清洗工具。非结构化数据源通过 AWS Glue 或其他数据处理工具转换 和准备成结构化或半结构化格式，并存入云存储（如 S3），其次使用 Snowpipe 配置监控这个云存储中特 定路径的文件变化，新产生的文件会被 Snowpipe 自动检测并即时加载进 Snowflake。加载完成后，数据通 过 Snowflake Data Exchange 与其他组织分享和交换。

对于非结构化数据的支持，Spark 相较于 Snowflake 具有更多的灵活性和广泛性。但随着 Snowflake 功能 的发展和增强，其对非结构化数据的支持也在逐步增强。 Snowflake 对 ACID 的追求很大程度上受创始人经历影响40。Snowflake 两位创始人 Benoit Dageville、Thierry Cruanes 均曾是 Oracle 架构师。根据 Benoit Dageville 访谈41，2012 年前后是大数据兴起的时期，数据访问从面 向少数决策者，转向面向一线运维人员及用户，这带来大规模、实时数据处理需求，而 Oracle 的分系统进入瓶 颈期，Benoit Dageville 认为很难在 Oracle 内部掀起这场革命42，所以和 Thierry Cruanes 于 2012 年创立 Snowflake。

Marcin Zukowski 引入列存储和矢量化执行，构建 Snowflake 技术架构底座。Marcin Zukowski 毕业于阿姆 斯特丹大学，2003-08 年博士期间在 Henri Bal 教授等建议下前往 CWI 进行数据库方向研究43，最终促成 Marcin Zukowski 发表论文《MonetDB/X100: Hyper-Pipelining Query Execution》44，这篇论文所提出的列存储和矢量化 执行成为后来 Snowflake 的两项核心技术。Marcin Zukowski 博士毕业后创立 Vectorwise（原 CWI X100 项目， 于 2008 年分拆出来的公司），但 2011 年 Vectorwise 被 Ingres 收购，2012 年 10 月 Marcin Zukowski 前往 Ingres 总部（美国加州）离职45，期间 Benoit Dageville 邀请 Marcin Zukowski 加入 Snowflake。 Benoit Dageville 研究方向为数据库性能优化，涵盖内存管理、SQL 性能及自调优技术。1996 年 Snowflake 联创 Benoit Dageville 加入 Oracle，2012 年离职创立 Snowflake。任职 Oracle 期间，Benoit Dageville 先后发布 《SQL Memory Management in Oracle9i》等46多篇论文，其主要聚焦内存管理、SQL 性能优化等领域，其中数据 库性能的核心瓶颈在于是内存和 I/O 带宽，SQL 性能优化则是在给定资源瓶颈下最大化资源效率，例如将热点 数据缓存以减少磁盘 I/O，或利用内存中缓存的查询计划，避免重复解析和编译 SQL 语句，提升 SQL 查询性能。 Thierry Cruanes 研究方向为 SQL 性能优化。1992 年 Thierry Cruanes 加入 IBM，主要负责数据挖掘，1999 年加入 Oracle，后于 2012 年离职创立 Snowflake。任职 Oracle 期间，Thierry Cruanes 先后发布《Parallel SQL Execution in Oracle 10g》等47多篇论文，其研究主要聚焦 SQL 性能优化(对应并行 SQL 执行、成本优化、查询转 换和统计信息收集)，其中并行 SQL 执行是将一个 SQL 查询划分为多个查询并行处理，提升资源利用率；成本 优化则基于给定成本约束优化 SQL 查询性能；查询转换是查询优化过程的一部分，包括重写查询、简化查询表达式、转换为等价但更高效的执行形式等；统计信息收集是为查询优化提供决策依据，包括记录表的大小、索 引状态、列的数据分布等信息。这些信息直接影响成本优化器能否准确地预测查询成本和选择最佳执行计划。

Snowflake 三位创始人的研究/工经历均聚焦于数据库分析领域，且 Benoit Dageville、Thierry Cruanes 主要聚 焦 SQL 查询性能优化，Benoit Dageville 的访谈48中提到当时大数据框架如 Hadoop 兴起，但其认为 Hadoop 存在 明显的局限性，例如复杂性较高、不适合实时处理、易用性不足等，因此 Snowflake 创始人实际上是希望在 Hadoop 和传统数据仓库之间提供一种既能通过云平台提供高性能处理大规模数据，又能易于使用并支持事务处理的数 据仓库解决方案。总结来看，Snowflake 和 Spark 技术路线的差异本质上是一种起点不同，叠加路径依赖造成的 结果，从后续的发展看，随着市场需求的融合，二者在产品功能上逐步趋同，但我们不能忽略底层架构存在根 本区别，这可能影响其在不同场景性能表现上难以弥补的差异。

3. 竞争逻辑：数仓领域地位稳固，数据平台领域仍需补足技术空缺

要想从竞争逻辑出发，我们首先要理解 Snowflake/Databricks/Redshift 等的产品战略。 Snowflake 从 Data Warehouse 转向 Data Cloud，力图构建双边网络效应。Snowflake 的产品愿景不止于云 数仓，根据《The Rise of Data Cloud》，Snowflake 在 2012-14 年 4 月均处于保密阶段获客(Stealth Mode)，直至 前微软 EVP Bob Muglia 加入，2014 年 5 月开始退出保密阶段，可是获取 EA Sports、Goldman Sachs 等大客户。 2016 年 Snowflake 发布《The Snowflake Elastic Data Warehouse》，此后开启扩张。至 2019 年 6 月，Snowflake 主要聚焦单点数仓的能力，2019 年 7 月 Snowflake 提出 Snowflake Data Exchange49，即数据交易机制，从数据仓 库拓展至数据云平台。 Snowflake 的战略定位就是中间层，不做基础设施，而是往数据平台发展。在 Benoit Dageville 访谈50中，其 提到“我们不建造基础设施，我们对成为 AWS、建立 EC2 和存储不感兴趣”，但希望“为数据云构建这个数据 云平台，这是一个面向全球的单一系统。”在这个数据云平台上，Snowflake 希望不断往平台添加功能，实现更 好的管理、整合、共享、分析等。供给侧 Snowflake 引入数据集提供商及允许客户共享平台上的数据，需求侧企 业逐步增强数据驱动的决策链路，带动数据需求增长，构建一个多边数据交易市场。

3.1 单点数仓的性能比较：Snowflake 在中小规模查询场景优势明显

Redshift/Databricks 强调大规模场景的扩展性和性价比

如何比较 Databricks 与 Snowflake、Redshift 的竞争优势？首先是单点数仓的性能比较，根据 Jim Gray， 计算机性能很难量化，相对合理指标是成本（价格/性能）和吞吐量51。TPC-DS52提供一个模拟现代数仓工作负 载的基准测试，包括数据挖掘、在线分析处理（OLAP）和决策支持等操作。从性能上看，BigQuery 在 1TB TPCDS 测试下性能领先 Snowflake，其次是 Redshift，但考虑成本后 BigQuery On Demand 价格远高于 Snowflake， 由于扩展性，响应时长可以通过增长计算节点压缩，这对应成本的提升，因此数仓的性能实际上是价格/性能。从价格/性能角度看，2020 年 6 月 1TB 规模测试下 Redshift>Snowflake>BigQuery，需要注意的是 BigQuery On Demand 极端高价导致 BigQuery 性价比不佳。

2020 年 6 月至今 Redshift/Snowflake/BigQuery 等均不断优化性能，因此我们引入 2022 年 12 月的测试。 根据 Fivetran，其于 2022 年 5-10 月基于 1TB 的 TPC-DS 进行评测，不同于 Grid Dynamics 的配置，Fivetran 对 不同型号的 Redshift/Snowflake/Databricks/Synapse/BigQuery 均进行测试。

Databricks 在云原生、查询引擎方面存在差异化探索。就云原生而言，Databricks 通过引入工作节点在同一 工作区中的多个计算之间提供隔离，这与 Redshift 的计算集群隔离类似。不同的是，Databricks 的计算资源隔离 是集群级别的59，而 Redshift 除了集群级别外，还在集群内部实现了较为细致的资源管理和控制； 查询方面，此前 Databricks SQL 通过 Catalyst 优化器利用 Scala 语言的特性进行逻辑和物理优化，例如 Catalyst 使用 Scala 的 Quasiquotes 功能生成新的 Scala AST（抽象语法树），这些 AST 可以被编译为执行查询 所需的 JVM 字节码，而 JVM 字节码可以被即时编译成机器语言，从而更快地执行查询，原理类似 Redshift 讲 SQL 查询转化为 C++语言。但 2022 年 8 月 Databricks 更进一步提出基于 C++语言60的 Photon 引擎，采用向量化 查询，从逐行处理改为批量处理一组数据项（向量），提升 CPU 缓存利用率。

BigQuery 在查询引擎和存储架构方面有一定探索。Dremel 采用树形架构，相比于大规模并行处理架构，树 形架构 1）天然形成数据局部性，通过多级执行树结构，将数据分片存储，并在物理上靠近处理数据的节点，从 而减少数据在网络中的传输成本。类似于 Redshift 采用 RMS 在计算节点附近缓存热数据，并采用 AQUA 加速 层将部分计算任务下推至存储层。2）支持物理隔离，不同子树可以被视作独立的计算资源池。3）树状结构特 别适合处理嵌套数据和小到中等规模的聚合查询，因为它可以在不同层级进行局部处理和聚合，最终汇总全局 结果。 但 Dremel 也存在一些缺陷，如 1）树型结构层次是一种静态设计62，但数据增长和查询模式发生变化时，原有的层级结构可能不再是最优的。为了适应负载变化，Dremel 在必要时需要重新组织或平衡树状结构，例如 调整数据分区、重新分配计算任务等，这导致额外的系统开销。2）Dremel 主要为谷歌内部使用的嵌套数据格式 设计，在处理关系数据或其他格式数据时可能需要预处理转换；3）Dremel 侧重于读取和分析任务，并未提及数 据的并发更新控制和事务管理功能，而 Redshift/Snowflake/Databricks 在不同程度上支持在线更新和并发控制， 兼顾 HTAP 及 OLTP 场景。

一个延申的问题是计算资源细颗粒度的隔离，其技术壁垒是什么？直接原因在于 Redshift 支持集群内计算 资源的并发缩放(Concurrency Scaling)，当并发查询量超过单个集群的最大处理能力时，Redshift 会在后台动态添 加额外的计算集群，这些集群独立于主集群运行，并负责处理等待中的查询，从而在单个数据库集群内部实现 了计算资源的隔离和扩展。当工作负载需求增大时，Databricks 会扩展整个集群，而非扩展集群内的计算节点。 并发缩放的根本原因是对底层计算和存储资源的实时监控和精细化管理。技术难点在于 1)动态负载识别与 预测，系统需要实时监测当前的工作负载。2)数据局部性与再分布，在集群内部动态增减计算资源，需要重新分 布数据以保持数据局部性，降低跨节点通信成本。3)任务调度与状态同步，新增或移除计算资源后，需要重新调 度已有的工作任务，并确保任务之间的状态和结果能够同步。4)资源的高效分配与回收，需要资源管理框架，可 以立即启动或停止节点，并在资源释放时清理相关状态，确保资源被有效利用。 对于 Databricks/Snowflake 等基于 CSP 的数仓供应商而言，其主要通过 API 调度集群资源缩放，但存在 一些制约，如 1）API 调用频率限制、授权和权限管理等；2）自定义资源管理策略，由于不能直接控制 IaaS 层， 需要开发一套自己的资源调度算法和策略，该策略需要考虑计算资源与存储资源的协同作用，以及各种应用场 景下的最优资源分配方案。 关于终端使用场景的数据量级，据 BigQuery 创始工程师 Jordan Tigani64，绝大多数企业的数据仓库都小 于 1TB。而 Gartner/Forrester 分析师认为 100GB 是数据仓库的合理数量级。另一方面，Jordan Tigani 认为大数 据的定义是保存数据的成本低于丢弃数据的成本，即“人们选择大数据的原因。这并不是因为我们需要它，我 们只是懒得删除而已”。因此，Redshift/Databricks 在数仓性能方面的优势可能被过度放大，此外湖仓一体趋势 确定性高。

根据云器科技联创&CTO 关涛66，数据平台市场客户可大致分为四类：1）大型科技企业，这类企业通常有 很强技术创新的诉求/定制化需求，这些企业一般会选择自建。2）数据原生企业，通常规模中等，可能在 100- 1000 台物理服务器。之前国内某公司 A，大致需要 100 台物理服务器做数据平台，硬件成本年化大约 300 万/ 年，若选择自建，企业要把一整套数据体系做起来大概需要 10 个模块组件，需要 4-5 人的团队来维护，人力成 本也需要 300 万元一年。如果购买 SaaS 服务，含硬件成本也就 400 万。企业发现自建人力成本几乎和硬件成本 一样高，所以这类企业转向购买平台服务。3）有技术能力的传统企业，典型代表比如说银行、保险、车企，这 类企业有较强的数据需求/付费意愿。这类型客户大部分选择购买数据平台，像银行通常不会选择自建而是购买 平台服务，主要从安全性、稳定性、售后追责的角度考虑。4）传统企业及政府类机构，这些客户通常是纯粹的 使用者，不具备构建数据平台能力。总结来看，第一类企业可能追求自建和极致的定制化，中间两类企业可能 会购买平台服务。最后一类企业可能不会自建/采购平台服务，而是采购具体的解决方案。 总结来看，Snowflake 聚焦数据原生企业及有一定技术能力的传统企业，通过易用性吸纳这部分客户转型， 创设了云原生数仓市场，而 Databricks/Redshift 等追求极致性能受大型科技企业等高定制化客户认可，但如 Google BigQuery 创始工程师 Jordan Tigani 所观察到的，99%的客户查询数据都小于 10GB，Databricks/Redshift 在公众宣传时强调大规模数据场景的高性能表现本质是面向 Top 1%的客户，而忽略了 99%的客户需求，在数仓 领域 Snowflake 仍然具备较强的性能和成本表现。

3.2 统一数据分析平台的构建：Snowflake 支持 Iceberg 打破数据孤岛，逐步引 入 Snowpark/Unistore 拓展用例场景，追赶 Databricks

我们在前述分析对比了单点数仓的性能，其次转向大数据平台。Snowflake/Databricks 等均将自身定位为现 代大数据堆栈的核心：2019 年 7 月 Snowflake 提出 Snowflake Data Exchange67，即数据交易机制，从数据仓库拓展至数据云平台；2024 年 1 月 Databricks 提出 Data Intelligence Platform68，构建统一数据分析平台。 统一大数据平台的趋势本质是数据流通。所谓数据流通，就是针对 Jordan Tigani 所提到的大数据更多是存 储，而非利用历史数据产生价值。基于非结构化/半结构化数据，很难通过传统的 BI 工具进行处理，而更多通过 机器学习产生洞察。另外，从数据生产的角度，数据仓库更多是企业内部生产的数据（格式固定/模式预定义）， 但随着企业 IT 系统引入不同供应商，其产生的数据格式逐步复杂化，这导致数据仓库难以满足需求。另一方面， 数据湖对于企业基础的 BI 需求也无法像数据仓库一样满足，因此行业倾向于湖仓一体。

根据 Databricks《Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics》，数据湖仓(Lakehouse Platform)架构主要包括 1）数据格式、2）元数据层、缓存与辅助数据结构、 3）数据目录、4）SQL 及 DataFrame API 支持。 开放的数据格式是数据流动的基础，主流格式包括 Iceberg、Hudi、Delta，分别由 Netflix/Uber/ Databricks 主导研发并开源。从 Github Stars 来看，Delta 的流行度略好于 Iceberg 及 Hudi，但总体份额不到 40%，三家大 体上仍呈现均衡分布的格局。数据格式中，Iceberg 相对中立，Delta 与 Databricks 绑定明显，Hudi 贴近 Spark 生 态。 不同数据格式在不同场景各有优劣69。据微软70测试，1）Hudi 在读密集型场景中表现出最稳定的性能。Delta Lake 和 Iceberg 在执行优化阶段时，性能波动较大。2）维护上，Hudi 能够在不做定期维护的情况下保持稳定的 性能，但需要提前完成更多前置工作来避免性能下降。Delta Lake/Iceberg 在 Optimize 阶段后，查询性能恢复明 显，但需要关注其默认的逐组数据压缩策略带来的潜在性能瓶颈。总体结论是 Hudi 性能相对最稳定，但不同数 据格式都可以通过优化达到不错的性能，因此厂商部署时需要考虑实际业务场景，数据格式之间没有绝对优劣。 具体而言，Hudi 开放性最优，Delta 易用性领先，Hudi 则需要额外配置实现性能提升。据 Walmart71在实际业务场景的测试，Iceberg 数据结构的演变兼容性最优，但 Hudi 在对不同引擎的支持度方面表现优于 Iceberg 及 Delta，整体开放性好于 Iceberg 及 Delta。性能上，Delta 在大多数查询中提供最佳性能，但 Walmart 团队通过 为 Hudi 进行比 Delta 更复杂的配置实现显着的性能优化。

数据目录主要解决数据治理问题，例如数据传输过程的合规，访问权限控制，数据和模型生成内容的关系 等。Snowflake本身不提供数据目录产品，而是通过Marketplace向用户提供第三方产品/插件，如Dataedo、Lumada、 Altlan、Tree Schema 等75。Snowflake 也支持外部数据目录工具，如 AWS Glue76接入，但对于客户而言仍然存在 不同数据平台数据不互通的问题，且不同业务系统的数据碎片化，Databricks 提出 Unity Catalog 针对性解决数 据碎片化分布，统一各平台数据治理。数据目录主要包括数据采集、元数据存储与管理、搜索和发现、权限管 理、数据血缘和影响分析。对比结论是 Unity Catalog 整体优势是易用性，得益于对各种常用功能的深度集成和 自动化处理，减轻用户的维护/配置负担。

SQL 及 DataFrame API 支持方面，湖仓一体架构下，面向 BI 等场景主要是 SQL 提供支持，而机器学习 等场景则通过声明式 DataFrame 提供支持。Snowflake 的理念是高效处理结构化和半结构化数据，因此原生支 持 JSON、Avro、Parquet 等格式81，并提供高度优化的 SQL 接口、引擎和集成系统。与 Databricks 不同，其完 全兼容 ANSI SQL，并通过 Iceberg 提供对 ACID 事物的完整支持82，实现与企业内部系统的紧密集成。这两点 使得 Snowflake 在 SQL 领域的学习成本更低，扩大潜在客户群体。但对于非结构化数据，Snowflakes 主要依靠 辅助函数、存储转化和第三方工具，例如通过 JDBC/ODBC 连接 Spark，将数据处理为 DataFrame，效率相对较 低。 Databricks 的理念在于推动现代大数据处理，主导 Spark 生态83。其原生支持 DataFrame API。尤其在机器学 习场景中，Databricks 通过 MLlib、Delta Lake、MLflow 提供全栈 ML/AI 工作流，支持流式 INSERT 和 UPDATE/DELETE 工作负载84，并可使用 Structured Streaming 提供实时流处理能力。相比之下，Snowflake 缺乏 原生的流处理能力，输入标准 DML 的操作在部分场景下也受到限制。

总的来说，Databricks/Snowflake 架构差异折射出对企业数据架构的分歧，即未来企业的数据分析场景/需求 会朝着什么方向发展，前者不断强调非结构化数据占比提升，且面向业务的机器学习增加，后者则更多注重内 部 BI/结构化数据的分析，尽管也提供部分辅助性质的非结构化数据/ML 支持。我们在两家公司在 AI 布局上也 可以看出二者思路的差异。

3.3 AI 催化：强化非结构化数据处理能力，并适当拓展 AI/ML 能力

GenAI 对于软件最大的机遇是自动化，体现在架构层面就是一体化。所谓自动化就是将过去预定义/自定义 的操作交由 Gen AI 决策，在过往专业化分工的基础上进一步解放人力，提升生产效率，理想情况即一人公司， 由软件替代法务、财务、营销、管理、运维、研发等各部门人员。具体到湖仓架构层面则呈现统一趋势，由于数 仓写入需预定义模式，且大量非结构化数据需 ETL 后移入数仓，且数据湖存储成本较低，导致客户往往将数据 存储在数据湖中，进而使用数据仓，因此 2019 年 Databricks 提出的 Lakehouse 可视为对数据湖、数仓的一体化 表达，由 Snowflake 主导的仓湖分离结构，和 Databricks 主导的仓湖一体结构相互竞争。 竞争维度分为两层，即数据利用的竞争，以及工作流生态位的竞争。首先，Gen AI 无法改变两家公司在工 作流上的定位。Databricks 的优势在于数据准备和数据管道解决方案的一体性，其场景在分析周期的最初阶段， 为客户节省的成本在于整合不同数据工程团队的流程。Snowflake 的关键优势在于用例的易用性和可扩展性，其 场景直接面向决策者。Snowflake 在 BI 场景的壁垒稳固，受 Databricks 影响较小。 其次，Gen AI 对非结构化数据使用的影响依旧体现在数据处理。尽管非结构化数据占数据总量的~80%， 但绝大多数为医学影像和视频等私域数据，其基于 ML 提供业务洞察和价值需要严格的数据合规要求。这种情 况下 Gen AI 驱动本地非结构化数据上云从而引入 ML 的影响需要较长周期才能观察到显著变化。AI 工作负载 的增长体现在大规模训练数据集的生成、模型的快速迭代更新，以及对边缘计算和实时数据流处理的需求增加。

数据湖的主要优势在于写入数据地灵活性，无需预定义模式，且 Databricks 依托 Spark 生态对几乎所有主流 引擎开放，但其后续管理非常复杂，很容易陷入“数据沼泽”，而数仓由于预定义模式，且数据处理为结构化/ 半结构化，SQL 引擎相对成熟，后续运维难度较低。双方的竞争是比较对手的壁垒，Snowflake 意识到仅作为 数仓供应商存在一个问题，数仓中的几乎所有数据都源自其他地方。 就 Snowflake 而言，其战略方向不够坚定，各条战线均有一定布局，但布局都不深：1）向上游数据湖竞争 意味着与 Spark 生态竞争，其发布的 Snowpark 一定程度上是对 Spark 的替代，但 Snowpark 功能尚不完善；2） 23 年 6 月与微软合作，集成 Azure AI/ML/OpenAI/Data Factory 服务，引入外部相对完善的服务满足客户需求； 3）21 年 6 月发布 Unistore，切入事务处理市场，但与 Oracle 等相比，Unistore 远未成熟；4）收购 Streamlit、 Applica、Neeva、Myst.ai 等，布局应用开发、文档识别、时序分析、AI 搜索等。

与 Spark 相比，Snowpark 在一些小规模用例上的处理速度和成本均有一定优势，其在 Python 社区的下载量 也达到 Pyspark 的~5%。在 Snowflake 投资者日上，截止 2023 年 4 月底，Snowpark 的总体采用率达到 35%， AI/ML 功能渗透率 20%，其中年开支超过 1 百万美元的大客户 Snowpark 的总体采用率达到 85%，AI/ML 功能 渗透率 65%。但我们仍然要注意 Snowpark 的一些限制，即例如 Snowpark 内存和计算环境在大型数据集中较为 受限90，需要将数据导入计算外部平台，这涉及额外的 ETL 处理时间及成本，更重要的是生态的开放性。此外， 采用率不涉及量，不等于工作负载从 Spark 迁移至 Snowpark，结合管理层对 FY25 Snowpark 的收入指引，我们 预计 Snowpark 的推广渗透仍处于非常初期的阶段。

Gen AI 方面，一个典型用例是引入 Streamlit 结合 LLM 快速构建对话式应用开发，Document AI 则提供将 非结构化数据转化为结构化数据以便利 BI 分析，从 LLM 与数据之间的交互，过去 Snowflake 不支持 Python 等 语言，目前通过 Snowpark 可支持 Python/Java/Scala 等语言进行调度。 核心功能 Cortex 包括 1）General-Purpose Functions，一组对话功能，可将 SQL 文本转换为代码，并通过向 量搜索和向量嵌入提供上下文信息以进行响应；2）Snowflake Copilot，支持自然语言查询和编码；3）Universal Search，来自对 Neeva 的整合，允许用户跨数据库和数据存储查找相关数据；4）Document AI，帮助用户从文档 中的文本中提取数据；5）Specialized Functions，这个工具允许用户访问现有 LLM 和 AI 模型以加速分析。

Databricks 的动向集中于知识引擎 Lakehouse IQ，利用 RAG 框架实现功能增强。在开发流程自动化方面， 其推出 Lakehouse AI，允许在 Lakehouse 中直接开发 Gen AI 应用。Databricks 选择 RAG 作为战略主线，一方面 基于数据管理、索引及向量化方面的积累，另一方面在于 Databricks 长期聚焦数据科学家和工具生态，RAG 相 比提供组件更能实现社群增长的规模效益。

4. Snowflake 正处于经营拐点，尚需外部环境优化&成本管理效率提 升

Snowflake 过去存在的问题：1）成本优化不透明，自动化不足。为实现易用性，Snowflake 实际上将客户所 需资源与计算、存储等资源分离，降低配置/部署门槛，但也带来资源计费的不透明。相比于 Databricks/Redshift 的 Serverless 模式，其提供更精确的资源控制，同时在达到一定阈值后集群自动停止运行/计费，而 Snowflake 则 需要手动配置，这导致客户实际支出容易超出预算。为优化数仓支出，客户需要引入外部如 Slingshot 等工具， Snowflake 内置成本优化工具完善度不高，这又带来额外的维护成本。因此 Snowflake 可能需要为大型客户提供 底层资源控制，或提供更完善的成本优化工具。 积极的因素是 Snowflake 于 2023 年 6 月与微软深化多年战略合作协议94/ 95，此次合作帮助 Snowflake 1）获 取 OpenAI 服务，2）并引入 Azure AI/ML 服务以支持 Snowflake 客户进行非结构化数据的 AI/ML 处理任务，3） Azure Data Factory，提供 ETL 服务集成。此外，Snowflake 于 2023 年 11 月的 Snowday 推出统一成本管理界面 96，将账户指定时间段内花费、平均每日支出、按成本排列的仓库、最昂贵的查询进行可视化，并允许管理员在 帐户级别设置支出控制等，进一步简化和提升成本预算管理效率。

2）销售诉求与客户诉求不一致，即成本优化与承诺消费的冲突。销售策略上鼓励预购/承诺付费，表现为按 需付费价格远高于预购/长期合同价格，这与行业惯例一致，但不同点在于年度预购积分未消耗后需要 100%续 约以换取积分使用权，这导致客户支出的浪费。例如某客户签订一份承诺消费 1 万美元的合同，实际消费额度 80%，剩余 2000 元的等值积分，一年后剩余积分到期，为激活这些积分，客户需要至少签订 0.8 万美元（上年 实际消费额度）及以上的合同，否则无法滚动激活剩余积分97。这种合同设置意味着如果初始设定额度高于实际 需求，将持续导致资源浪费而无法弥补（不论是积分过期未激活，或过度承诺额度），这实际上将 Snowflake 利 益置于客户之上98。在 IT 预算优化及竞对推动 Lakehouse 融合背景下，客户/工作负载流失压力较大。 3）成本优化过程中削弱销售激励。销售激励制度从过去的加速器无上限，转为有上限，激励幅度实际上在 弱化。例如，如果一个销售代表在 Q1 和 Q2 的业绩是目标的 150%，他们并不会获得乘以 150%的奖金，而是仍 然只能获得基础奖金。但是，如果他们在后续的季度中业绩下滑，比如说在 Q3 和 Q4 分别只完成 20%的目标， 那么他们将分别获得基础奖金的 20%，这实质设定了员工激励的上限，这也导致一些销售从 Snowflake 离职转 投 Databricks 或其他云厂商。 4）生态不够开放，如果持续聚焦成本优化（如 AWS），低成本&闭环生态更容易令人接受，但高成本&闭 环生态对于构建长期技术栈的客户而言是一个较疑虑的选择。但积极的是，我们看到 2022 年 Snowflake 宣布支 持 Iceberg 表格式，打破数据孤岛，并引入 Snowpark 支持 Python 语言和 AI/ML 工作负载，尽管成熟度较 Spark 仍有较大差距，但后续发展有望弥补 Snowflake 在生态支持方面的短板。

短期来看，Snowflake 受 IT 预算优化影响，客户在分析支出预算方面削减弹性大于存储，这导致 Snowflake收入增速存在一定压力。另外，欧盟 AI 法案及数据合规监管趋严，很多企业都在暂停/放缓数据迁移上云，等待 监管落地及主要供应商如 Snowflake、AWS 等提供合规数据治理环境后再启动上云。竞争方面，如 Oracle 等竞 争对手通过激进折扣等方式延缓客户/工作负载的流失，从而导致新增负载方面存在一定压力。后续继续关注成 本优化及行业 IT 预算优化周期。

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