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 技术路线的差异本质上是一种起点不同，叠加路径依赖造成的 结果，从后续的发展看，随着市场需求的融合，二者在产品功能上逐步趋同，但我们不能忽略底层架构存在根 本区别，这可能影响其在不同场景性能表现上难以弥补的差异。