雪花作为高需求 API 的后端

Question

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

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

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

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

Answer 1

也许对于这种类型的工作负载，新的 SF 功能 搜索优化服务 可以帮助您加快性能 (https://docs.snowflake.com/en/user-guide/search-optimization-service.html)。

Answer 2

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

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

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

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

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