我最近查看了 Snowflake 的季度财务报表，我意识到他们的产品非常受欢迎，以至于他们可以停止添加新客户，但仍能获得两位数的收入增长。这张来自 Clouded Judgment^[1] 的图表确实突出了产品的粘性：一年前加入并花费 1 美元的客户在一年后支付的费用远远超过 1.7 美元。Snowflake 还没有可以追加销售或交叉销售的广泛产品目录，因此大部分新收入是由于使用量增加、客户流失率低以及 Snowflake 的定价模式无法扩展。

想象一下在 Snowflake 工作的性能工程师和 RevOps 管理层之间的对话

工程师：“我想出了一种方法可以将查询性能提高 20%。” RevOps：“太好了，我们必须仔细权衡然后决定，因为它会影响我们的底线。”

Snowflake 推动性能优化的动机与收入目标完全相反。在典型的创新者困境中^[2]，Snowflake 优先考虑其他会生成更大计算选项菜单的东西，例如 Snowpark 和基于 Streamlit 构建的数据应用程序，这会让您的组织枯竭。这是 SaaS 模型发挥作用的自然过程，许多其他公司都有自己的不可扩展的定价结构。例如 Google 的哪个同学会认为运行此查询时让 BigQuery 执行全表扫描是个好主意？、

// most databases scan 10 rows of data when running this query while Biquery will scan the full table
select * from table limit 10 

扫描所有数据的选择可能看起来很愚蠢，但并不是当您意识到他们对扫描的每 Gb 数据收费时，留下优化小问题符合他们的利益。

Snowflake可以做得更好吗？

作为一名投资者，我预计 Snowflake 将展现出惊人的盈利能力和创纪录的收入数字。作为一名工程师，如果 Snowflake 继续走目前忽视性能的道路，我预计他们会失去开源社区或其他竞争对手的份额，最终走上 Oracle 和 Teradata 的道路。以下是我认为他们可以在五年内保持相关性的一些事情。

披露硬件规格

Snowflake根据您的消费向您收费。您无需购买任何特定的硬件，而是使用没有硬件定义的虚拟仓库积分随用随付。对于具有技术或工程背景的人来说，这是一个危险信号。无论您的查询是在具有 SSD 还是硬盘驱动器、低 RAM 还是高 RAM、慢速或快速 CPU、高或低网络带宽的机器上运行，都会对性能产生可衡量的影响。Snowflake 对他们的硬件非常保密，当我在从 Redshift 迁移期间与销售团队交流时，我永远无法获得任何有关其查询性能的 SLA，也无法获得有关硬件规格的信息。这与 Redshift、Firebolt 和 Databricks 明显不同，后者非常透明，在通过硬件自定义性能方面提供了更大的灵活性。缺乏透明度也可能导致不良的激励措施，Snowflake公司可能会因为内部压力提高利润率而恢复到不太理想的机器。

不采用基准

几个月前 DataBricks 发表了一项研究^[3]，强调它们在 TPC-DS 基准测试中的表现优于 Snowflake，Snowflake 对此发表了反驳^[4]。Snowflake 关于基准的声明非常明确：

就像我们对许多我们想做的事情很清楚一样，我们也对我们不想做的事情有信心。其中一件事是参与基准战争，并提出与现实世界经验脱节的竞争性能要求。这种做法根本不符合我们以客户为先的核心价值观。

这是一个非常短视的说法，与数据仓库为何如此受欢迎以及客户关心的内容相矛盾。数据仓库之所以流行，正是因为它们兑现了性能承诺，用户无需等待数天或数周即可完成报告。性能提高 100 倍不仅改善了现有的工作流程，而且使从业者能够发明与仓库交互的新方式。基准虽然不理想并且可以被玩弄，尽管可以脱离现实，尽管可能会受到再现性和普遍性的影响，但它们是推动围绕性能进行讨论的起点。如果我选择一项每年花费我的雇主超过 100 万美元的技术，我总是会坚持需要看到一些数字。我希望 Snowflake 扭转其立场，并可以开始实施基准作为其发行说明的一部分。当然一个总价值超过 $1T+ 的行业迫切需要关闭基准测试。

优化器小问题

如果使用 Snowflake 工作的时间足够长，您会发现一些会导致性能大幅下降的小问题。我举一个我亲身经历的例子。基于子查询中的谓词禁用微分区^[5]裁剪，即使子查询返回一个常量。像下面示例中的查询不会从快速裁剪中受益，即使您在 created_houret上进行分区，如果您构建增量模型或使用导入 CTE^[6]，这样的查询到处都是。

// this query will perform a full table scan even if you partition // on created_hour
select
count(*)
from table1 
where 
 created_hour > (select max(hour) from table2)

如果使用 DBT，你真的应该注意这个问题，因为这种查询模式非常常见，占查询成本的 50% 以上。我几乎从未在开源数据库中看到过这些类型的小问题（如果它们存在，它们会得到修复），但它们却一直存在于企业数据仓库中。这只是让我想知道是否有一个性能优化团队在 Snowflake 内部有发言权。

改进工作负载管理器以提高吞吐量

Snowflake 中的查询工作负载管理器效率低下。假设您有一个仓库和两个用户，一个用户提交一个计算密集型查询，而另一个用户提交一个扫描非常少数据的小查询。Snowflake 中的工作负载管理软件似乎基于 FIFO（先进先出）模式分配其所有资源。我真的希望不是这样，但是在盯着查询队列数十次之后，我认为这主要是 FIFO。如果大型查询首先运行，则将第二个用户留在队列中，从而大大降低吞吐量。更好的选择是暂停大查询并将资源重新定位到较小的查询或拆分资源消耗，以便 80% 的容量用于大查询，20% 的容量用于小查询。Snowflake 推荐了另外两种解决方案：

• • 横向/纵向扩展仓库，因此第二个用户不会遭受巨大的队列延迟。这迫使更多的支出。

• • 或者使用新发布的查询加速器，它允许您在每个查询的基础上进行扩展。如果没有良好的数据治理，这将再次迫使您增加支出。

从我管理 Redshift 的日子来看，我可以肯定地说 Redshift 的工作负载管理器在防止大量低效查询/用户导致系统停机并迫使您向外扩展方面要聪明得多。在一个机器学习如此先进的时代，我们在查询和表上拥有如此多的元数据，令我惊讶的是 Snowflake 没有构建智能管理查询工作负载的东西。如果我可以根据所需的列数、存在的连接以及所涉及的表的大小预测查询将需要一段时间才能运行，那么为什么工作负载管理器不能使用 ML 来做到这一点？我想这个想法是在 Snowflake 内部流传的，但因为它不是收入驱动因素，所以它不在任何路线图上。

不提供可观测性来监控和降低成本

Snowflake 提供了非常有限的工具来缩小您最大的成本驱动因素并执行每个角色/用户级别的查询超时或预算限制。例如我想做以下事情：

• • 列出负责我大部分费用的用户/系统。我是否在处理对 SQL 知之甚少、执行cross-join并让他们的查询超时的用户？我是否有人们忘记存在的 ETL 工作，但它们占据了我的大部分成本？除非您开始在 Snowflake 之上执行查询标记和构建工具，否则今天无法进行这种级别的成本归因。您只知道一个仓库的总成本，这需要您将工作负载拆分到多个仓库以获得更精细的归因。

• • 能够指定每个用户/角色的超时或约束。今天这仍然受到每个仓库的限制，限制了您控制成本的能力，因为它强制横向/纵向扩展模式。

• • 与 pagerduty/slack/email 紧密集成，提醒用户他们超出预算或让用户了解他们的查询模式是不可持续的。

我认为 Snowflake 可能会增加更好的可观测性，或者它将通过自定义工具创建，但是今天这些功能不存在，许多公司发现 Snowflake 账单出乎意料地大。

哪些使用 Snowflake 的公司可以做得更好？

与任何 SaaS 或 IaaS 一样，Snowflake 通常很昂贵，因为它是一种被滥用的工具。尽管我认为 Snowflake 对性能可扩展性负有责任，但消费者也存在一些责任。

不谈判

我们有 5-6 个非常好的开源数据仓库替代方案。我们有 Redshift、DataBricks、Firebolt、BigQuery 以及可能的其他一些企业产品，但令人惊讶的是大多数公司在谈判和重新谈判供应商合同或推动大幅折扣定价方面的培训很少。您不应该支付与使用量增加相同的费率。

缺乏教育

关于滥用问题，如果您对基础架构进行了正确的监控，您通常会发现一个有趣的模式，即 5% 的内部用户驱动了 95% 的成本。让我举几个例子：

• • 几乎我认识的每个人都在工作中学习了 SQL，并犯了相当多的错误，包括使用cross-join编写查询、没有过滤正确的谓词、选择所有列或将大量数据提取到 R 和 Python 中，因为他们更喜欢那些语言。只有通过试验过程，用户才能学会如何更有效地工作。尽管如此，今天我可能会支付 25 美元，并请用户从 DataCamp 学习几天的在线 SQL 课程，然后高效且可扩展地学习这门手艺。

• • 当我以前的公司使用 Looker 时，我注意到有些人会继续添加大约 100 多个维度和度量，而不考虑后台发生的连接数量。然后他们会运行一个显然会达到我们内部超时的查询。这导致我们更改了有关如何使用 Looker 的政策，其中仪表板的创建者必须属于了解 SQL 的用户组。除非您是仪表板的被动消费者，否则 BI 工具不能替代缺乏教育。

一般来说找到 5% 的用户并简单地让他们知道他们正在做的事情是不可持续的，可以对成本产生有意义的影响。例如您可以设置一个 Slack 机器人，它会定期提醒用户他们消耗了大量资源，或者只是为团队提供有关成本归因的 Slack 报告。或者如果您有一个大型组织，您可以指定一个由 2-3 人组成的团队，使用以下 Cloud Finops^[7] 框架来优化整体基础架构成本。

还应该使用Snowflake吗？

如果您是一家小型公司，其仓库成本预算低于 50 万美元/年，我认为您别无选择，只能使用企业工具。像 Snowflake 这样的工具提供的功能数量、可用性以及不使用数据来推动更好的产品开发的机会成本将您推向了一个必须做出购买决定的角落。如果您的年度成本超过 50 万美元，那么考虑下坡道的好处是很有用的。我预计生态系统将在未来五年内发生变化，无论大小公司都将采用开源。我们有 DucksDB、Clickhouse、Pinot、Trino、Dremio、Druid、Iceberg、Doris、Starrocks、Delta Lake 以及可能在大小公司中使用的其他一些开源替代品。挑战在于其中一些工具尚未达到高度普及或易于开发人员体验的程度。随着事情的整合和可选性的缩小，随着越来越多的数据工程师熟悉一套核心工具，使用开源会便宜很多。同时为了让 Snowflake 具有相关性，他们需要确保其性能工程团队完全独立于负责收入驱动的团队，这样它才能真正进行自我改造。

引用链接

[1] Clouded Judgment: [https://cloudedjudgement.substack.com/p/a-look-back-at-q1-22-public-cloud](https://cloudedjudgement.substack.com/p/a-look-back-at-q1-22-public-cloud)
[2] 创新者困境中: [https://www.amazon.com/Innovators-Dilemma-Revolutionary-Change-Business/dp/00](https://www.amazon.com/Innovators-Dilemma-Revolutionary-Change-Business/dp/00)
[3] 研究: [https://www.databricks.com/blog/2021/11/02/databricks-sets-official-data-warehousing-performance-record.html](https://www.databricks.com/blog/2021/11/02/databricks-sets-official-data-warehousing-performance-record.html)
[4] 反驳: [https://www.snowflake.com/blog/industry-benchmarks-and-competing-with-integrity/](https://www.snowflake.com/blog/industry-benchmarks-and-competing-with-integrity/)
[5] 微分区: [https://docs.snowflake.com/en/user-guide/tables-clustering-micropartitions.html#query-pruning](https://docs.snowflake.com/en/user-guide/tables-clustering-micropartitions.html#query-pruning)
[6] 导入 CTE: [https://medium.com/@AtheonAnalytics/snowflake-query-optimiser-unoptimised-cf0223bdd136](https://medium.com/@AtheonAnalytics/snowflake-query-optimiser-unoptimised-cf0223bdd136)
[7] Cloud Finops: [https://www.finops.org/introduction/what-is-finops/](https://www.finops.org/introduction/what-is-finops/)