Snowflake的竞争优势在哪？

数仓领域地位稳固，数据平台领域仍需补足技术空缺。

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 仍然具备较强的性能和成本表现。

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. 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 相 比提供组件更能实现社群增长的规模效益。