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

2024年Snowflake研究报告：关注产品成本优化、开放生态进度_短期受IT预算削减与监管趋严压制增速1.投资亮点：AI应用技术栈转型，非结构化数据管理需求提升市场关注Snowflake的核心主要是AI受益逻辑，其核心逻辑为：Snowflake增强客户管理数据的能力，并引入AI/ML等工具增强数据分析能力。1、AI会加速数据从本地数仓向云数仓的迁移，理由是数据生成速度大幅提升，且数据上云能最大化AI带来的价值。此外，与MongoDB在投资者日所提到的逻辑类似，GenAI将带动应用技术栈转变。AI可能会促进自动化开发，推动1）应用开发数量的提升；2）数据密集型应用增加（数据库支出占比提升）等。此外，AI应用开发衍生出新需求（向量搜索），相当于Snowflake增加工作负载，会提升客户的平均。2、数据迁移后基于GenAI分析数据，这意味着企业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提出细颗粒度、自动化的资源配置策略，这导致厂商在成本/性能可扩展方面的差异。但GoogleBigQuery工程师JordanTigani所观察到的，99%的客户查询数据都小于10GB，Databricks/Redshift在公众宣传时强调大规模数据场景的高性能表现本质是面向Top1%的客户，而忽略99%的客户需求，在数仓领域Snowflake仍然具备较强的性能和成本表现。统一数据分析平台方面，Databricks长期致力于构建开放、高性能的Spark生态，在数据目录方面提出UnityCatalog，在表格式方面提出Delta等，占据主导地位。Snowflake2022年通过支持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团队在论文《TheSnowflakeElasticDataWarehouse》提到，数据仓库面临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最早源于UCBAMP实验室《ResilientDistributedDatasets:AFault-TolerantAbstractionforIn-MemoryClusterComputing》，论文中提出了一种弹性分布式数据集（即RDD）的概念。RDD是一种分布式内存抽象，其使得程序员能够在大规模集群中做内存运算，并且有一定的容错方式。这是Spark的核心数据结构，Spark整个平台都围绕着RDD进行。Spark通过引入RDD，替换MapReduce作为数据接口，大幅提升集群处理效率。RDD引入内存计算而非磁盘计算，使得后续计算可以复用已经计算过的数据，减少从磁盘读取数据的IO开销，从而显著提高处理速度，在迭代式计算和交互式查询等场景提升明显。另外，通过引入依赖关系和计算规则，RDD实现高容错率（即Resilient）。一旦数据丢失，RDD可以通过中间变量+计算规则+依赖关系（即DAG，有向无环图，或血统）恢复丢失数据，而不必重新进行计算（MapReduce的快照恢复则需要重新计算）。易用性上Spark也较MapReduce大幅提升。MapReduce框架下，开发者需要手动编写Map和Reduce函数，通过key-value对的形式进行数据处理，这种方式在处理复杂查询和多步操作时，容易导致代码冗长且不易维护。例如，如果要进行两次过滤、一次映射和一次聚合操作，需要分别编写四个函数，同时还需要处理数据在不同阶段的读写和shuffle过程，这在大规模数据处理场景下繁琐且效率不高。SparkRDD提供Transformation和ActionAPI，这些API允许开发者以一种声明式、函数式的风格编写代码12，即更关注“做什么”，而非“怎么做”。2012年Snowflake开始立项，至2015年6月Snowflake向公众开放使用，站在当时的节点上看，Spark在1）内存管理上存在一定不稳定性；2）对SQL支持不足，且不满足ACID等要求等问题。因此Snowflake定位上兼容数据库，且易用性高，这使得客户接受度较高，且迁移成本低。Spark支持SQL的思路来自Hadoop的Hive，但相应的弊病仍然存在。在2014年Spark1.0版之前，Spark对SQL的支持来自Hadoop中的Hive，并迁移至Spark（HiveinSpark，即Shark）。Hive提供了一种类似SQL的查询语言（HiveQL），使得用户可以通过编写SQL语句来执行MapReduce任务，从而简化了对大规模数据集的处理，但由于Hive底层使用MapReduce执行任务，每个查询都需要启动多个MapReduce任务，这导致了较高的查询延迟。因此Hive存在对高延迟、不支持实时查询、复杂SQL支持度不足等问题15。Spark引入Hive后，受益于底层内存计算的优化，Shark整体计算速度大幅优于Hive。Shark迁移适配成本逐步增加，Databricks于2014年7月宣布转向SparkSQL开发，停止开发Shark。由于MapReduce与SparkRDD计算机制差异较大，如果将Hive的代码适配到Spark，开发者需要确保所有在Spark中运行的线程都能安全地访问和修改共享资源，以避免数据污染和不一致的问题。这就需要对Hive的代码进行修改，增加适当的同步机制，以保证线程安全16。这增加了开发和维护的复杂性，并且是Shark面临的挑战之一。由于适配成本随着Hive复杂化不断提升，Databricks于2014年7月宣布停止开发Shark，转向SparkSQL开发。2015年4月Spark1.3.0引入DataFrameAPI，在表结构方面实现改进，从而提升SQL查询性能。引入DataFrame之前，Spark框架下缺乏预定义的表结构，因此处理结构化数据时需要开发者自己管理数据模式（Schema），因此此前RDD模式下SparkSQL无法直接集成，而引入DataFrame后，由于DataFrame带有明确结构，且内嵌模式信息，这使得SparkSQL能够理解DataFrame中的数据结构。SparkSQL的核心是Catalyst优化器。①Catalyst使用抽象的树结构来表示不同程序逻辑，包括SQL抽象语法树（SQLAST）、DataFrame或DatasetAPI的逻辑计划，以及最终生成的物理执行计划。采用树结构的原因在于，树结构适合采用递归和模式匹配等算法进行遍历和转换，且具备足够通用性表达不同逻辑。场景上，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特性的支持有限。SparkSQL提供了对结构化数据的处理能力，但其底层的数据抽象模型RDD（弹性分布式数据集）并不支持直接的数据更新和删除操作；2）Spark2.0：在Spark1.0中，虽然批处理部分支持ACID，但是流式计算是通过SparkStreaming实现的，它将流数据按时间片切分，每个时间片中的数据都是无序且至多一次的处理语义，无法保证持久性。Spark2.0通过引入结构化流处理25(StructuredStreaming)确保Spark内核层面的ACID支持，后续在2.2版中引入Kafka集成，确保从Kafka接收数据的ACID语义。3）Spark2.4引入DeltaLake：相比于HDFS仅支持文件级别的原子写入操作，DeltaLake通过引入事务日志实现对ACID的支持，例如在图书管理系统中HDFS仅支持对书籍层面的增删查改，而DeltaLake支持对书本内部字句级别的增删查改，实现方式则是每当对表进行增删改操作时，DeltaLake都会记录一个事务日志条目，并且只有当事务成功提交时，这些更改才会被确认并添加到表的状态中。事务日志确保所有修改都是原子性的27。除事务日志外，DeltaLake还引入乐观并发控制（OCC）28、多版本并发控制29（MVCC）以及数据快照和历史版本查询30等设计，提高事务吞吐量、动态解决冲突以及适应不同的工作负载，使得数据库系统能够在保持数据完整性的同时，提供良好的性能和响应能力。4）Spark3.0：Spark2.X系列在ACID方面与专业数据库分析平台如Snowflake仍有一定差距，主要是端到端的ACID支持，例如1）微批处理的延迟32，结构化流处理采用的微批处理方式，虽然保证了每个批次内的ACID，但会引入一定的延迟，无法做到低延迟处理；2）批流融合的困难33。结构化流处理流式计算设计，与批处理存在一些区别和割裂，无法在批流两种模式间完全统一和无缝切换；3）中间状态的一致性34。结构化流处理缺乏有效机制来保证作业中的中间状态在发生故障时的一致性，会影响端到端ACID。为了解决这些限制，1）Spark3.0通过缩小批次，引入自适应查询执行（AdaptiveQueryExecution,AQE）可以动态调整执行计划以提高性能，缩短微批处理的延迟，但本质上仍存在一定延迟，无法达到真正的实时处理；2）通过统一API解决批流融合，Spark3.0之前开发人员需要使用不同的API或逻辑来分别处理这两种情况。在Spark3.0中，通过统一的DataFrame/DatasetAPI以及集成DeltaLake，都可以采用相同的编程模型进行数据读取、写入及转换操作；3）Spark3.0通过整合DeltaLake或其他事务性存储层，能够更好地管理作业中的中间状态并确保一致性。DeltaLake的事务日志和检查点机制允许在发生故障时恢复作业状态，从而实现端到端的精确一次语义（exactly-oncesemantics）。这意味着即使在系统出现故障的情况下，也能保持数据一致性，并且每个事件仅被处理一次。针对2），互联网的发展带动数据格式发生变化，过去数据仓库中的大部分数据都来自组织内部：事务系统、ERP、CRM等。结构、容量和速度都是可预测且已知的。但是云计算使得相当大且快速增长的数据量来自于不太可控的外部来源：应用程序日志、网络应用、移动设备、社交媒体、传感器数据（物联网）。除了不断增长的数量之外，这些数据经常以无模式的、半结构化格式出现。传统数据仓库解决方案正在努力解决这种新数据。这些解决方案依赖于深入的ETL管道和物理调优，从根本上假定来自主要内部来源的可预测、缓慢变化且易于分类的数据。Spark在早期阶段主要聚焦结构化数据的处理，在非结构化/半结构化数据的支持方面相对有限。但随着引入SparkDataFrame/Dataset，Spark在支持非结构化/半结构化数据方面取得长足进步。数据格式支持的原理基于数据序列化和反序列化的过程，以及数据存储39和检索的优化。序列化是将数据结构（如对象、数组等）转换为一种可存储或传输的格式（如JSON、XML、CSV等）的过程。这使得数据可以在不同的系统之间进行交换，或者被持久化存储。反序列化是将这些格式转换回原始数据结构的过程。对数据格式的转换可以通俗理解为如下案例，想象一个图书馆管理系统，图书信息以不同的数据格式存储在不同类型的卡片上。有的卡片是表格形式（类似CSV格式），每行记录一本书的信息；有的卡片是用更复杂的语言描述书籍信息（类似JSON格式）。为统一管理这些卡片，系统需要一个“智能助手”，它能读懂所有卡片上的信息并将它们整理成电子数据库。对不同数据格式支持，其技术难度主要包括1）语法解析：每种数据格式都有其特定的语法和结构，开发人员需要编写解析器来正确识别并解析这些格式，并能处理边界情况(CornerCase)和异常输入；2）性能优化：对于大量数据的处理，高效的内存管理和IO操作至关重要。例如，快速解析大量JSON文件而不耗尽系统资源是一个挑战；3）兼容性和扩展性：随着数据格式的发展和版本更新，数据格式支持应当能够适应新特性和旧版向后兼容，同时允许在未来添加对更多格式的支持；4）错误处理和恢复：确保在遇到损坏或不完整数据时，系统可以尽可能地进行错误恢复，并给出清晰的错误报告。总体而言，越是结构化的数据格式支持难度通常越低。例如，①CSV解析器只需按行读取，并按照分隔符(如逗号)拆分每行为多个字段即可，主要难度在于处理一些CornerCase，如含有引号的字段、缺失字段、数据类型推断等；②JSON解析器相对复杂一些，存在嵌套关系，而解析器处理时会将嵌套关系记录，最终统一处理，因此一旦层级较多或数组较多时，可能导致内存不足。此时可以通过限制递归深度/流式解析/分块读取和存储等方式解决问题，但相应也会牺牲I/O操作和即时查询的性能等；③Parquet相比于JSON更复杂，JSON的解析是线性的，但Parquet的解析是非线性的。举例而言，JSON文件信息按行记录，每行可能包含各种主题（列）的数据，一条记录完整地写在一起。Parquet文件按照不同的主题（列）把信息分开存放，因此解析时需首先通过元数据（索引）定位信息，再进行解析。对于非结构化数据暂时没有通用、有效的方式，Spark通过开发者自定义/第三方库间接处理非结构化数据。如前所述，数据格式的支持本质是一个序列化与反序列化的过程，而非结构化数据没有统一的结构模板，因此在解析时难以通过确定地规则处理。对比而言，Spark更加偏向于数据处理管道中的转换阶段，能够适应多种数据源和格式，而Snowflake更注重于长期存储和高效查询，尤其是在结构化和半结构化数据领域表现突出。Spark的策略为依托开发者生态的力量。1）引入Schema-On-Read模式，即允许数据在被读取和处理时才确定其结构（Schema），而不是在写入时就强制定义和验证。2）提供SparkMLlib和SparkNLP等库，其中MLlib主要引入机器学习，例如通过预处理和特征工程将文本数据转化为结构化数值，或通过分类器和回归器可用于处理经特征提取后的文本数据，进行情感分析等。3）Spark允许用户通过自定义函数（UDF）来实现复杂的非结构化数据解析逻辑，或者使用Scala、Java、Python等编程接口编写自定义数据处理器。Snowflake的策略是引入外部转换、清洗工具。非结构化数据源通过AWSGlue或其他数据处理工具转换和准备成结构化或半结构化格式，并存入云存储（如S3），其次使用Snowpipe配置监控这个云存储中特定路径的文件变化，新产生的文件会被Snowpipe自动检测并即时加载进Snowflake。加载完成后，数据通过SnowflakeDataExchange与其他组织分享和交换。对于非结构化数据的支持，Spark相较于Snowflake具有更多的灵活性和广泛性。但随着Snowflake功能的发展和增强，其对非结构化数据的支持也在逐步增强。Snowflake对ACID的追求很大程度上受创始人经历影响40。Snowflake两位创始人BenoitDageville、ThierryCruanes均曾是Oracle架构师。根据BenoitDageville访谈41，2012年前后是大数据兴起的时期，数据访问从面向少数决策者，转向面向一线运维人员及用户，这带来大规模、实时数据处理需求，而Oracle的分系统进入瓶颈期，BenoitDageville认为很难在Oracle内部掀起这场革命42，所以和ThierryCruanes于2012年创立Snowflake。MarcinZukowski引入列存储和矢量化执行，构建Snowflake技术架构底座。MarcinZukowski毕业于阿姆斯特丹大学，2003-08年博士期间在HenriBal教授等建议下前往CWI进行数据库方向研究43，最终促成MarcinZukowski发表论文《MonetDB/X100:Hyper-PipeliningQueryExecution》44，这篇论文所提出的列存储和矢量化执行成为后来Snowflake的两项核心技术。MarcinZukowski博士毕业后创立Vectorwise（原CWIX100项目，于2008年分拆出来的公司），但2011年Vectorwise被Ingres收购，2012年10月MarcinZukowski前往Ingres总部（美国加州）离职45，期间BenoitDageville邀请MarcinZukowski加入Snowflake。BenoitDageville研究方向为数据库性能优化，涵盖内存管理、SQL性能及自调优技术。1996年Snowflake联创BenoitDageville加入Oracle，2012年离职创立Snowflake。任职Oracle期间，BenoitDageville先后发布《SQLMemoryManagementinOracle9i》等46多篇论文，其主要聚焦内存管理、SQL性能优化等领域，其中数据库性能的核心瓶颈在于是内存和I/O带宽，SQL性能优化则是在给定资源瓶颈下最大化资源效率，例如将热点数据缓存以减少磁盘I/O，或利用内存中缓存的查询计划，避免重复解析和编译SQL语句，提升SQL查询性能。ThierryCruanes研究方向为SQL性能优化。1992年ThierryCruanes加入IBM，主要负责数据挖掘，1999年加入Oracle，后于2012年离职创立Snowflake。任职Oracle期间，ThierryCruanes先后发布《ParallelSQLExecutioninOracle10g》等47多篇论文，其研究主要聚焦SQL性能优化(对应并行SQL执行、成本优化、查询转换和统计信息收集)，其中并行SQL执行是将一个SQL查询划分为多个查询并行处理，提升资源利用率；成本优化则基于给定成本约束优化SQL查询性能；查询转换是查询优化过程的一部分，包括重写查询、简化查询表达式、转换为等价但更高效的执行形式等；统计信息收集是为查询优化提供决策依据，包括记录表的大小、索引状态、列的数据分布等信息。这些信息直接影响成本优化器能否准确地预测查询成本和选择最佳执行计划。Snowflake三位创始人的研究/工经历均聚焦于数据库分析领域，且BenoitDageville、ThierryCruanes主要聚焦SQL查询性能优化，BenoitDageville的访谈48中提到当时大数据框架如Hadoop兴起，但其认为Hadoop存在明显的局限性，例如复杂性较高、不适合实时处理、易用性不足等，因此Snowflake创始人实际上是希望在Hadoop和传统数据仓库之间提供一种既能通过云平台提供高性能处理大规模数据，又能易于使用并支持事务处理的数据仓库解决方案。总结来看，Snowflake和Spark技术路线的差异本质上是一种起点不同，叠加路径依赖造成的结果，从后续的发展看，随着市场需求的融合，二者在产品功能上逐步趋同，但我们不能忽略底层架构存在根本区别，这可能影响其在不同场景性能表现上难以弥补的差异。3.竞争逻辑：数仓领域地位稳固，数据平台领域仍需补足技术空缺要想从竞争逻辑出发，我们首先要理解Snowflake/Databricks/Redshift等的产品战略。Snowflake从DataWarehouse转向DataCloud，力图构建双边网络效应。Snowflake的产品愿景不止于云数仓，根据《TheRiseofDataCloud》，Snowflake在2012-14年4月均处于保密阶段获客(StealthMode)，直至前微软EVPBobMuglia加入，2014年5月开始退出保密阶段，可是获取EASports、GoldmanSachs等大客户。2016年Snowflake发布《TheSnowflakeElasticDataWarehouse》，此后开启扩张。至2019年6月，Snowflake主要聚焦单点数仓的能力，2019年7月Snowflake提出SnowflakeDataExchange49，即数据交易机制，从数据仓库拓展至数据云平台。Snowflake的战略定位就是中间层，不做基础设施，而是往数据平台发展。在BenoitDageville访谈50中，其提到“我们不建造基础设施，我们对成为AWS、建立EC2和存储不感兴趣”，但希望“为数据云构建这个数据云平台，这是一个面向全球的单一系统。”在这个数据云平台上，Snowflake希望不断往平台添加功能，实现更好的管理、整合、共享、分析等。供给侧Snowflake引入数据集提供商及允许客户共享平台上的数据，需求侧企业逐步增强数据驱动的决策链路，带动数据需求增长，构建一个多边数据交易市场。3.1单点数仓的性能比较：Snowflake在中小规模查询场景优势明显Redshift/Databricks强调大规模场景的扩展性和性价比如何比较Databricks与Snowflake、Redshift的竞争优势？首先是单点数仓的性能比较，根据JimGray，计算机性能很难量化，相对合理指标是成本（价格/性能）和吞吐量51。TPC-DS52提供一个模拟现代数仓工作负载的基准测试，包括数据挖掘、在线分析处理（OLAP）和决策支持等操作。从性能上看，BigQuery在1TBTPCDS测试下性能领先Snowflake，其次是Redshift，但考虑成本后BigQueryOnDemand价格远高于Snowflake，由于扩展性，响应时长可以通过增长计算节点压缩，这对应成本的提升，因此数仓的性能实际上是价格/性能。从价格/性能角度看，2020年6月1TB规模测试下Redshift>Snowflake>BigQuery，需要注意的是BigQueryOnDemand极端高价导致BigQuery性价比不佳。2020年6月至今Redshift/Snowflake/BigQuery等均不断优化性能，因此我们引入2022年12月的测试。根据Fivetran，其于2022年5-10月基于1TB的TPC-DS进行评测，不同于GridDynamics的配置，Fivetran对不同型号的Redshift/Snowflake/Databricks/Synapse/BigQuery均进行测试。Databricks在云原生、查询引擎方面存在差异化探索。就云原生而言，Databricks通过引入工作节点在同一工作区中的多个计算之间提供隔离，这与Redshift的计算集群隔离类似。不同的是，Databricks的计算资源隔离是集群级别的59，而Redshift除了集群级别外，还在集群内部实现了较为细致的资源管理和控制；查询方面，此前DatabricksSQL通过Catalyst优化器利用Scala语言的特性进行逻辑和物理优化，例如Catalyst使用Scala的Quasiquotes功能生成新的ScalaAST（抽象语法树），这些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支持集群内计算资源的并发缩放(ConcurrencyScaling)，当并发查询量超过单个集群的最大处理能力时，Redshift会在后台动态添加额外的计算集群，这些集群独立于主集群运行，并负责处理等待中的查询，从而在单个数据库集群内部实现了计算资源的隔离和扩展。当工作负载需求增大时，Databricks会扩展整个集群，而非扩展集群内的计算节点。并发缩放的根本原因是对底层计算和存储资源的实时监控和精细化管理。技术难点在于1)动态负载识别与预测，系统需要实时监测当前的工作负载。2)数据局部性与再分布，在集群内部动态增减计算资源，需要重新分布数据以保持数据局部性，降低跨节点通信成本。3)任务调度与状态同步，新增或移除计算资源后，需要重新调度已有的工作任务，并确保任务之间的状态和结果能够同步。4)资源的高效分配与回收，需要资源管理框架，可以立即启动或停止节点，并在资源释放时清理相关状态，确保资源被有效利用。对于Databricks/Snowflake等基于CSP的数仓供应商而言，其主要通过API调度集群资源缩放，但存在一些制约，如1）API调用频率限制、授权和权限管理等；2）自定义资源管理策略，由于不能直接控制IaaS层，需要开发一套自己的资源调度算法和策略，该策略需要考虑计算资源与存储资源的协同作用，以及各种应用场景下的最优资源分配方案。关于终端使用场景的数据量级，据BigQuery创始工程师JordanTigani64，绝大多数企业的数据仓库都小于1TB。而Gartner/Forrester分析师认为100GB是数据仓库的合理数量级。另一方面，JordanTigani认为大数据的定义是保存数据的成本低于丢弃数据的成本，即“人们选择大数据的原因。这并不是因为我们需要它，我们只是懒得删除而已”。因此，Redshift/Databricks在数仓性能方面的优势可能被过度放大，此外湖仓一体趋势确定性高。根据云器科技联创&CTO关涛66，数据平台市场客户可大致分为四类：1）大型科技企业，这类企业通常有很强技术创新的诉求/定制化需求，这些企业一般会选择自建。2）数据原生企业，通常规模中等，可能在100-1000台物理服务器。之前国内某公司A，大致需要100台物理服务器做数据平台，硬件成本年化大约300万/年，若选择自建，企业要把一整套数据体系做起来大概需要10个模块组件，需要4-5人的团队来维护，人力成本也需要300万元一年。如果购买SaaS服务，含硬件成本也就400万。企业发现自建人力成本几乎和硬件成本一样高，所以这类企业转向购买平台服务。3）有技术能力的传统企业，典型代表比如说银行、保险、车企，这类企业有较强的数据需求/意愿。这类型客户大部分选择购买数据平台，像银行通常不会选择自建而是购买平台服务，主要从安全性、稳定性、售后追责的角度考虑。4）传统企业及政府类机构，这些客户通常是纯粹的使用者，不具备构建数据平台能力。总结来看，第一类企业可能追求自建和极致的定制化，中间两类企业可能会购买平台服务。最后一类企业可能不会自建/采购平台服务，而是采购具体的解决方案。总结来看，Snowflake聚焦数据原生企业及有一定技术能力的传统企业，通过易用性吸纳这部分客户转型，创设了云原生数仓市场，而Databricks/Redshift等追求极致性能受大型科技企业等高定制化客户认可，但如GoogleBigQuery创始工程师JordanTigani所观察到的，99%的客户查询数据都小于10GB，Databricks/Redshift在公众宣传时强调大规模数据场景的高性能表现本质是面向Top1%的客户，而忽略了99%的客户需求，在数仓领域Snowflake仍然具备较强的性能和成本表现。3.2统一数据分析平台的构建：Snowflake支持Iceberg打破数据孤岛，逐步引入Snowpark/Unistore拓展用例场景，追赶Databricks我们在前述分析对比了单点数仓的性能，其次转向大数据平台。Snowflake/Databricks等均将自身定位为现代大数据堆栈的核心：2019年7月Snowflake提出SnowflakeDataExchange67，即数据交易机制，从数据仓库拓展至数据云平台；2024年1月Databricks提出DataIntelligencePlatform68，构建统一数据分析平台。统一大数据平台的趋势本质是数据流通。所谓数据流通，就是针对JordanTigani所提到的大数据更多是存储，而非利用历史数据产生价值。基于非结构化/半结构化数据，很难通过传统的BI工具进行处理，而更多通过机器学习产生洞察。另外，从数据生产的角度，数据仓库更多是企业内部生产的数据（格式固定/模式预定义），但随着企业IT系统引入不同供应商，其产生的数据格式逐步复杂化，这导致数据仓库难以满足需求。另一方面，数据湖对于企业基础的BI需求也无法像数据仓库一样满足，因此行业倾向于湖仓一体。根据Databricks《Lakehouse:ANewGenerationofOpenPlatformsthatUnifyDataWarehousingandAdvancedAnalytics》，数据湖仓(LakehousePlatform)架构主要包括1）数据格式、2）元数据层、缓存与辅助数据结构、3）数据目录、4）SQL及DataFrameAPI支持。开放的数据格式是数据流动的基础，主流格式包括Iceberg、Hudi、Delta，分别由Netflix/Uber/Databricks主导研发并开源。从GithubStars来看，Delta的流行度略好于Iceberg及Hudi，但总体份额不到40%，三家大体上仍呈现均衡分布的格局。数据格式中，Iceberg相对中立，Delta与Databricks绑定明显，Hudi贴近Spark生态。不同数据格式在不同场景各有优劣69。据微软70测试，1）Hudi在读密集型场景中表现出最稳定的性能。DeltaLake和Iceberg在执行优化阶段时，性能波动较大。2）维护上，Hudi能够在不做定期维护的情况下保持稳定的性能，但需要提前完成更多前置工作来避免性能下降。DeltaLake/Iceberg在Optimize阶段后，查询性能恢复明显，但需要关注其默认的逐组数据压缩策略带来的潜在性能瓶颈。总体结论是Hudi性能相对最稳定，但不同数据格式都可以通过优化达到不错的性能，因此厂商部署时需要考虑实际业务场景，数据格式之间没有绝对优劣。具体而言，Hudi开放性最优，Delta易用性领先，Hudi则需要额外配置实现性能提升。据Walmart71在实际业务场景的测试，Iceberg数据结构的演变兼容性最优，但Hudi在对不同引擎的支持度方面表现优于Iceberg及Delta，整体开放性好于Iceberg及Delta。性能上，Delta在大多数查询中提供最佳性能，但Walmart团队通过为Hudi进行比Delta更复杂的配置实现显着的性能优化。数据目录主要解决数据治理问题，例如数据传输过程的合规，访问权限控制，数据和模型生成内容的关系等。Snowflake本身不提供数据目录产品，而是通过Marketplace向用户提供第三方产品/插件，如Dataedo、Lumada、Altlan、TreeSchema等75。Snowflake也支持外部数据目录工具，如AWSGlue76接入，但对于客户而言仍然存在不同数据平台数据不互通的问题，且不同业务系统的数据碎片化，Databricks提出UnityCatalog针对性解决数据碎片化分布，统一各平台数据治理。数据目录主要包括数据采集、元数据存储与管理、搜索和发现、权限管理、数据血缘和影响分析。对比结论是UnityCatalog整体优势是易用性，得益于对各种常用功能的深度集成和自动化处理，减轻用户的维护/配置负担。SQL及DataFrameAPI支持方面，湖仓一体架构下，面向BI等场景主要是SQL提供支持，而机器学习等场景则通过声明式DataFrame提供支持。Snowflake的理念是高效处理结构化和半结构化数据，因此原生支持JSON、Avro、Parquet等格式81，并提供高度优化的SQL接口、引擎和集成系统。与Databricks不同，其完全兼容ANSISQL，并通过Iceberg提供对ACID事物的完整支持82，实现与企业内部系统的紧密集成。这两点使得Snowflake在SQL领域的学习成本更低，扩大潜在客户群体。但对于非结构化数据，Snowflakes主要依靠辅助函数、存储转化和第三方工具，例如通过JDBC/ODBC连接Spark，将数据处理为DataFrame，效率相对较低。Databricks的理念在于推动现代大数据处理，主导Spark生态83。其原生支持DataFrameAPI。尤其在机器学习场景中，Databricks通过MLlib、DeltaLake、MLflow提供全栈ML/AI工作流，支持流式INSERT和UPDATE/DELETE工作负载84，并可使用StructuredStreaming提供实时流处理能力。相比之下，Snowflake缺乏原生的流处理能力，输入标准DML的操作在部分场景下也受到限制。总的来说，Databricks/Snowflake架构差异折射出对企业数据架构的分歧，即未来企业的数据分析场景/需求会朝着什么方向发展，前者不断强调非结构化数据占比提升，且面向业务的机器学习增加，后者则更多注重内部BI/结构化数据的分析，尽管也提供部分辅助性质的非结构化数据/ML支持。我们在两家公司在AI布局上也可以看出二者思路的差异。3.3AI催化：强化非结构化数据处理能力，并适当拓展AI/ML能力GenAI对于软件最大的机遇是自动化，体现在架构层面就是一体化。所谓自动化就是将过去预定义/自定义的操作交由GenAI决策，在过往专业化分工的基础上进一步解放人力，提升生产效率，理想情况即一人公司，由软件替代法务、财务、营销、管理、运维、研发等各部门人员。具体到湖仓架构层面则呈现统一趋势，由于数仓写入需预定义模式，且大量非结构化数据需ETL后移入数仓，且数据湖存储成本较低，导致客户往往将数据存储在数据湖中，进而使用数据仓，因此2019年Databricks提出的Lakehouse可视为对数据湖、数仓的一体化表达，由Snowflake主导的仓湖分离结构，和Databricks主导的仓湖一体结构相互竞争。竞争维度分为两层，即数据利用的竞争，以及工作流生态位的竞争。首先，GenAI无法改变两家公司在工作流上的定位。Databricks的优势在于数据准备和数据管道解决方案的一体性，其场景在分析周期的最初阶段，为客户节省的成本在于整合不同数据工程团队的流程。Snowflake的关键优势在于用例的易用性和可扩展性，其场景直接面向决策者。Snowflake在BI场景的壁垒稳固，受Databricks影响较小。其次，GenAI对非结构化数据使用的影响依旧体现在数据处理。尽管非结构化数据占数据总量的~80%，但绝大多数为医学影像和视频等私域数据，其基于ML提供业务洞察和价值需要严格的数据合规要求。这种情况下GenAI驱动本地非结构化数据上云从而引入ML的影响需要较长周期才能观察到显著变化。AI工作负载的增长体现在大规模训练数据集的生成、模型的快速迭代更新，以及对边缘计算和实时数据流处理的需求增加。数据湖的主要优势在于写入数据地灵活性，无需预定义模式，且Databricks依托Spark生态对几乎所有主流引擎开放，但其后续管理非常复杂，很容易陷入“数据沼泽”，而数仓由于预定义模式，且数据处理为结构化/半结构化，SQL引擎相对成熟，后续运维难度较低。双方的竞争是比较对手的壁垒，Snowflake意识到仅作为数仓供应商存在一个问题，数仓中的几乎所有数据都源自其他地方。就Snowflake而言，其战略方向不够坚定，各条战线均有一定布局，但布局都不深：1）向上游数据湖竞争意味着与Spark生态竞争，其发布的Snowpark一定程度上是对Spark的替代，但Snowpark功能尚不完善；2）23年6月与微软合作，集成AzureAI/ML/OpenAI/DataFactory服务，引入外部相对完善的服务满足客户需求；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，结合管理层对FY2