Snowflake 作为高需求 API 的后端

Question

在过去的八个月里，我和我的团队每天都在使用 Snowflake 来转换/丰富我们的数据（使用 DBT）并使其在其他工具中可用。虽然该平台似乎非常适合对大型数据集进行大量/长时间运行的查询以及支持 Metabase 和 Mode 等分析工具，但在我们需要运行非常小的查询的情况下，它似乎表现不佳（抓住我表 A 的一行）在高需求 API 背后，我的意思是，SF 有时在 XLARGE-2XLARGE 仓库上需要多达 100 毫秒甚至 300 毫秒的时间来获取相当小的表（200k 计算记录/聚合）中的一行，总计为当我们想要将其用作后端来支持高需求分析 API 时，网络延迟会导致设置非常糟糕。

我们已经使用 Nodejs + Fastify 以及 Python + Fastapi 测试了多个设置，使用连接池 (10-20-50-100)/不使用连接池（每个请求一个连接，根本不理想），部署在同一个 AWS 中区域作为我们的 SF 部署，但我们无法维持接近 50-100 个请求/秒和 1 秒的延迟（可接受），而是我们只能以高达 15-30 秒的延迟获得 10-20 个请求/秒. 这两种语言/框架各自表现良好，甚至只是获取/释放连接，实际上耗时最长且需要大量 IO 的是实际运行查询并等待响应。我们还没有尝试过 Golang 设置，但这一切似乎都归结为 Snowflake 为此类查询返回结果的速度。

我们真的很想使用 Snowflake 作为数据库来支持只读 REST API，该 API 预计每秒有 300 个请求，同时尝试将响应时间控制在 1 秒以内。（但也准备接受它只是不适合那个）

有人在类似的设置中使用 Snowflake 吗？在这种情况下，最能充分利用 Snowflake 的工具/配置是什么？我们是否应该启动许多服务器并希望我们能够达到一个不错的请求率？或者我们应该只是将转换后的数据复制到 Postgres 之类的东西上，以便能够获得更好的响应时间？

Answer 1

我并不声称自己是对此的权威答案，因此人们可以随时纠正我，但是：

归根结底，您正在尝试将 Snowflake 用于未针对其优化的内容。首先，我将运行SELECT 1;以演示您可以期望收到的延迟下限。结果需要 40ms 才能返回。查看查询编译器的 21 毫秒和执行它的 19 毫秒的细分。编译器旨在提出真正智能的方法来处理庞大的复杂查询；不要快速编译小的简单查询。

有了查询计划后，它必须找到工作节点来执行它。虚拟仓库是工作节点（服务器/云 VM）的集合，每个 VW 大小是它拥有多少工作节点的函数，不一定是每个工作节点的 VM 大小（例如 EC2 实例大小）。所以现在编译的查询被发送到另一台机器上运行，在那里启动一个工作进程。与查询计划器类似，工作进程不太可能优化以快速运行小查询，因此可能涉及该进程的启动和拆除（至少相对于 PostgreSQL 工作进程而言）。

把我的 SELECT 1;除了支持“真实”查询的示例之外，让我们谈谈缓存。首先，Snowflake 不像典型的 RDBS 那样在内存中缓冲表。RAM 是为计算资源保留的。这是有道理的，因为在传统用法中，您要处理大小为数 GB 到数 TB 的表，因此没有意义，因为典型的 LRU 缓存会在数据再次访问之前清除该数据。这意味着必须访问 SSD 磁盘。这是您的性能将开始取决于您的 API 查询的同质/异质程度的地方。如果你很幸运，你会在 SSD 上获得缓存命中，否则它会转到 S3 来获取你的表。表文件不会在所有工作节点上冗余缓存，因此，虽然查询计划器将尝试在最有可能在缓存中具有所需文件的节点上安排计算，但如果将第一个查询分配给一个，则不能保证后续查询将从第一个查询产生的缓存中受益不同的工作节点。如果您每秒在 VM 上触发 100 次查询，则发生这种情况的可能性会增加。

最后，这可能是您的大部分问题，但已将其保存到最后，因为我对此最不确定。一个小查询可以在虚拟仓库中的一部分工作人员上运行。在这种情况下，VH 可以在不同节点上运行具有不同查询的并发查询。但是，我不确定给定的工作节点是否可以一次处理多个查询。在这种情况下，您的并发性将受到 VH 中节点数量的限制，例如，具有 10 个工作节点的 VH 最多可以并行运行 10 个查询，并且您看到的是查询计划器阶段堆积的查询，而它等待工作节点释放。