Snowflake为自家分析引擎构建Spark客户端连接器

Snowflake推出客户端连接器，可在其云数据仓库中直接运行Apache Spark代码，无需集群设置。

这一设计旨在避免配置和维护运行热门开源分析引擎的集群。Apache Spark于2014年首次推出，用于解决Hadoop分布式文件系统上的大数据问题，但由于在分析和数据准备方面的广泛应用，它在云时代继续发展壮大。

而Snowflake则始于RDBMS数据仓库，属于为云端分离存储和计算的新一代产品。

Snowflake产品管理副总裁Chris Child表示，客户长期使用Spark处理数据并为分析或AI应用做准备。虽然一些客户指出在具有两种不同计算引擎、基础设施类型和治理层的独立系统中运行存在负担，但重写Spark代码（通常使用Java、Python或Scala，而非通用数据库语言SQL）的工作量太大，难以考虑迁移Spark工作负载。

"我们收到的反馈是，重写用户构建的转换类型往往非常困难，"Child告诉我们。

随后，Apache Spark社区推出了Spark Connect，采用客户端-服务器架构，允许任何客户端应用程序连接到远程Spark集群。

通过新的Snowpark Connector，Snowflake承诺为Spark用户提供在Spark客户端中运行Spark代码的相同能力，但连接到Snowflake分析引擎作为服务器，而不是独立的Spark集群。该公司也继续为开源Spark项目做出贡献。

"在我们预发布预览中运行此功能的客户，看到了平均5.6倍的性能提升——在相同数据上运行完全相同的代码——与传统spark相比，他们还看到了约40%的成本节约，"Child声称。

Snowflake声称这允许客户为其Spark代码使用其向量化引擎，同时避免维护或调优独立Spark环境的复杂性——包括管理依赖关系、版本兼容性和升级。"现在可以使用Snowflake运行所有现代Spark DataFrame、Spark SQL和用户定义函数代码，"该公司表示。

二合一的趋势

此举是跨越两个原本不同市场的更广泛整合的一部分：用于机器学习和临时分析的数据湖；用于可重复、查询优化的高并发BI和分析的数据仓库。

Databricks在创立时就围绕Spark构建以提供数据湖，但在过去五年中一直在扩展，通过"湖仓"概念将数据湖和数据仓库结合起来。与此同时，Snowflake已扩展到在其数据平台上提供数据湖。

两种方法都受到了批评。2021年，Gartner指出数据湖在支持"传统"数据仓库处理的并发用户数量方面可能存在困难。Databricks随后表示，通过其SQL Serverless改善了并发性，旨在为用户的BI和SQL工作负载提供即时计算。

Snowflake也因意外成本让用户感到惊讶而受到批评，因为计算资源会灵活扩展以支持更多用户。近年来，该公司一直试图通过优化策略解决这个问题，帮助客户减少账单，以至于一个重要用户——杂货配送服务公司InstaCart——出人意料地表示将在三年内从Snowflake账单中削减数千万美元，这让市场观察者感到惊讶。

与此同时，Snowflake一直试图执行一项旨在让客户使用其计算引擎处理数据的策略，无论数据存储在何处。Child告诉我们，客户希望存储比他们想要放入Snowflake的数据更多的数据。

"我们在Apache Iceberg上进行了巨大投资，使人们更容易做到这一点。我们从许多客户那里听到，他们希望处理数据，不仅仅是SQL，还有其他方式。因此，我们在Snowpark Connect上进行了大量投资，确保他们可以按照自己想要的方式带来代码，"他说。

Q&A

Q1：什么是Snowpark Connector？它有什么作用？

A：Snowpark Connector是Snowflake推出的客户端连接器，允许用户在Snowflake云数据仓库中直接运行Apache Spark代码，无需设置独立的Spark集群。它连接到Snowflake分析引擎作为服务器，避免了配置和维护单独Spark环境的复杂性。

Q2：使用Snowpark Connector相比传统Spark有什么优势？

A：根据Snowflake的数据，在预发布预览中使用该连接器的客户看到了平均5.6倍的性能提升，同时相比传统Spark节约了约40%的成本。用户可以运行相同的代码处理相同的数据，但获得更好的性能和成本效益。

Q3：为什么客户不直接将Spark代码重写为SQL？

A：重写Spark代码的工作量太大。Spark代码通常使用Java、Python或Scala编写，包含复杂的数据转换逻辑。客户反馈表明，重写这些已构建的转换类型往往非常困难，因此迁移Spark工作负载的成本过高。