嗨，根据下面提到的链接 溢出描述为“当 Snowflake 无法在内存中进行操作时，它会首先将数据溢出到磁盘，然后再到远程存储。”
第 1 部分
-cannot fit an operation in memory : 这是否意味着仓库的内存大小不足以处理工作负载并且查询进入排队状态？
除了加入操作之外，还有哪些操作会导致这种情况？
第 2 部分
-它首先将数据溢出到磁盘，然后再到远程存储：在这种情况下，磁盘指的是什么，因为我们知道仓库只是其中没有磁盘的计算单元。
这是否意味着仓库内存放不下的数据会溢出到存储层？
-所谓的“远程存储”。这是否意味着内部阶段？
请帮助理解磁盘溢出雪花。
https://community.snowflake.com/s/article/Recognizing-Disk-Spilling
【问题讨论】：
标签： snowflake-cloud-data-platform
是的，远程溢出是 S3（本地是本地实例缓存） - 通常当事情发生远程溢出时，情况非常糟糕并且查询的性能受到影响。
除了重写查询之外，您始终可以尝试在文档中提到的更好的仓库上运行它 - 它会拥有更多自己的缓存，并且溢出应该会显着减少。
【讨论】：
内存是计算服务器内存（访问速度最快），本地存储是附加到 EC2 的 EBS 卷，远程存储是 S3 存储（访问速度最慢）。
这种溢出会对查询性能产生深远的影响（尤其是在使用远程磁盘进行溢出的情况下）。为了缓解这种情况，建议：
使用更大的仓库（有效地增加操作的可用内存/本地磁盘空间），和/或小批量处理数据。
文档参考：https://docs.snowflake.com/en/user-guide/ui-query-profile.html#queries-too-large-to-fit-in-memory
【讨论】：
像 FLATTEN 这样的 JOIN 变体会创建更多的行和像 COUNT DISTINCT 这样的聚合操作。
就在昨天，我做了一些 COUNT DISTINCTs 超过两年的数据，每月汇总一次，并且它正在溢出到本地和远程。
当我想要 COUNT(*) 时，我意识到正在做 COUNT(DISTINCT column1,column2)，因为所有那些已经不同的值对，并且停止了远程溢出，并且为了避免部分/大部分本地溢出，我将我的 SQL 拆分为批次1 年大小（数据按时聚集，因此读取不会浪费），并将结果集插入表中。最后，与中型相比，我在一个特大的仓库中运行批次。
我不知道本地/远程磁盘在哪里的确切答案，但是许多 EC2 实例有些带有本地磁盘，所以他们可能使用这些实例，否则很可能是 EBS。我相信遥控器是S3。
但是这个故事的寓意是，只是一台使用交换内存的 PC，不只是让操作立即失败是件好事，但大多数情况下，如果它失败了，你会更好，因为它需要多长时间痛苦。
【讨论】：