Presto-[10]-Administration-Spill to Disk

原文

https://prestodb.io/docs/current/admin/queue.html

Overview

 对于内存敏感型的operations，Presto允许将中间结果卸载到磁盘。这样保障内存消耗大的查询可以正常执行，

一些特性配置见： Spilling Properties.

Memory Management and Spill

默认Presto会kill掉超出 session properties  query_max_memory 或者 query_max_memory_per_node.参数配置的查询，

这种机制保证了查询见内存分配的公平性，防止内存分配导致的死锁，这在集群中有大量小查询时有效，

会杀掉超值的大查询，解决这个问题，引入可撤销内存的概念，一个大查询可以申请限制外的内存，

但这些内存又可以被 memory manager随时撤销，当内存被撤销，query runner 将中间数据从内存spills到disk，以后继续处理它。

实际中，当集群空闲，所有的内存可用，一个内存敏感型的大查询可以利用所有内存，

相反，当集群紧张时同样查询只能用磁盘存储中间结果。

当一个查询涉及大数据量的排序并且执行时间大于一般的直接内存运行的查询所用时间时 会被强制spill to disk。

注意：并不是使能spill-to-disk功能后就能保证内存敏感的大查询就可以执行，

可能存在 query runner不能将中间结果切分成足够小的chunks放在内存中导致Out of memory errors

Spill Disk Space

将中间结果spille到磁盘或者从磁盘检索回数据是耗费I/O很重的operations，

因此这类查询可能被disk扼杀掉。

为了提高查询性能建议提供多个用于spill的 local devices 的paths (propertyspiller-spill-path in Spilling Properties).

system drive不能用于spilling，尤其是JVM运行和写logs的drive 。

Supported Operations

并非所有的operations都支持spill，并且不同的operator实现方式可能不同

Joins

对于 join operation，其中被join的一个表被存储在内存中，

这张表被称为build table，其他表的rows如果和build table匹配的上就 以stream的形式被传递个下一个operator，

也即对于join operator 其中build table为内存敏感的部分。

当并发数大于1，这个build table被分区，

分区数等于ttask.concurrency configuration parameter (see Task Properties)的值

当build table被分区，spill-to-disk 机制将减小join operator需要的内存使用峰值

当查询达到memory的限制，build table的分区的子集将被spilled到磁盘，

同时其他表中匹配的rows也落在相同的分区中，其后，被spilled的分区在被一一读出来完成jion操作.

Aggregations

Aggregation functions 操作于一个group的数据，返回一个value，

如果group数据过大超过内存限制，中间的计算聚合结果存盘，然后被重新加载做merge操作，完成最终的聚合操作