Building An Elastic Query Engine on Disaggregated Storage

在分布式存储日益普及的背景下，数据查询面临存储与计算资源动态适配的挑战。为应对这一问题，本文聚焦于在分离式存储架构上构建弹性查询引擎。文章先阐述相关背景，接着介绍整体架构，分析数据集特征，详解临时存储系统、查询调度机制、资源弹性策略及多租户支持方案，旨在为分离式存储环境提供高效、灵活的查询解决方案。

背景

snowflake 基于云环境，创建的 OLAP 数据仓库，设计的动机包括

• 计算存储分离

• 多租户

• 高性能

传统的数据仓库使用的是 shared-nothing 架构，这种架构的问题是

• Hardware-workload mismatch：每个节点都是独立的配置，某些节点可能是高带宽低CPU，有些又是相反的，这样导致利用率就有问题，如果想配置起来不那么麻烦，则需要增加每个节点的配置，这样集群总资源需要更多，而且平均使用率则不高，花费也不小

• Lack of Elasticity，即使某个节点能匹配需求，他们的配置也是静态的，对于一段时间内大量的数据倾斜，CPU不断变化的场景也很难应对，这种架构一般是增加/删除一批机器，然后重新做数据shuffle，比如TeraData，这样不仅需要大量带宽也影响性能

shared-nothing这种架构适合比较明确的场景，比如在企业内部、政府机关，这种场景是可预测，使用多少资源，提前大概能知道
但现在很多场景都是很难预测的，而且场景越来越多，比如 应用日志、社交媒体、web应用，移动系统等等
这就好比是原来 B端 的场景，迁移到了 C端，场景丰富了很多就不适用了
snowflake 为了克服这些问题，提出了 存储计算分离的架构
其存储层使用的是

• Amazon S3

• Azure Blob Storage

• 谷歌云等

除此之外，还有两个系统设计关键

• 自定义的存储系统，用来管理查询期间计算节点之间的 临时/中间数据

• 因为直接使用对象存储来作为中间数据，性能和延迟可能跟不上

• 临时存储系统也作为缓存使用，用来弥补 存储结算分离后的性能问题

为了可能要做的

• Decoupling of compute and ephemeral storage，现在计算和临时存储是紧耦合的

• Deep storage hierarchy，包含内存、SSD两层临时存储，更多的层次如何利用和管理类

• Pricing at sub-second timescales，云厂商提供了亚秒级计费，未来snowflake也会跟进，设计上是一个挑战

公开的测量报告
https://github.com/resource-disaggregation/snowset

架构

snowflake 的数据包括三种

• 持久数据，用户的数据就存在这里，需要有持久性，可