Step 1

题目摘要引言

题目

SQL，的 Query 引擎，分布式存储器。

摘要

Snowflake，一个 cloud-based 数据仓库系统，提供最先进的数据库系统 SQL 支持。设计目标有如下三个

计算和存储弹性
支持 multi-tenancy（多租户，单一软件程序为多个客户的架构）
高性能

本文说明了 Snowflake 的设计和实现。给出云基础设施最近的发展对 Snowflake 设计与优化的影响。通过在执行大量查询过程中，收集到的系统各组件大量数据中，加深对现有问题的理解并突出新的研究挑战（包括存储系统设计，高性能查询执行引擎）。

引言

无共享架构：persistent data 被划分到多个计算节点，计算节点只对本地数据负责，不会进行共享。缺点与代价

Hardware-workload mismatch：硬件与工作流失配，无法针对计算节点的适合情况匹配合适的 workload（compute-extensive bandwith-light 还是 compute-light bandwith-extensive）
Lack of Elasticity：静态并行（static parallelism）和数据分区是（非弹性）无共享架构固有的，这限制了对数据和 time-varying workload 的适应。此外无共享架构也不支持节点的增删的弹性，因为一旦涉及此过程，数据需要 reshuffle，增大带宽压力同时反而降低性能，因为参与数据 reshuffle 的节点同时还负责查询过程。

传统数据仓库被设计用来进行可预测容量、速率的数据的查询（主要来自内部）。现在越来越多不可预测的来自外部的数据（应有程序日志、社交媒体、Web 应用程序）导致了不可预测的 query workloads。无共享架构应对此类效率较低。

SnowFlake：把计算和存储节点区分开。数据存储在提供高可用性和按需弹性分配的持久化数据仓库中（Amazon S3、Azure Blob Storage）。计算弹性使用预先预热（pre-warmed）节点，可以按需分配给用户。

Snowflake 有两个核心而后设计思想

定制设计的临时存储系统：管理临时/中间数据，在查询执行中与计算节点交换。必要性由于现有持久性存储的局限性：
- 无法提供必要的 latency 和 throughput 性能?（原因不大理解，为了避免计算任务称为瓶颈）
- 提供更强的可用性和持久性语义。
临时存储系统充当持久化数据的“缓存”：

未来可能感兴趣的研究方向：

Decoupling of compute and ephemeral storage（计算和临时存储解耦）
Deep storage hierarchy（深存储层次）

系统应用发现：

只读，只写，读写查询分别占比：_28%、13%、~59%
中间数据在不同查询中可能有数量级的差距，却对实际查询的持久化数据量、时间基本没有什么影响。
少量的本地存储容量，skewed access distributions 与 temporal patterns 可以为持久化数据访问提供相当高的缓存命中率：60-80%
部分用户使用到弹性支持。
峰值资源利用率很高，但平均资源利用率地行低下（极差大）

基本理论概况

结论部分

提供实操 Snowflake 数据仓库的经验，覆盖了设计实现概念中最终更关键的几个部分，实现计算和存储的弹性，以及实现多租户架构下的高性能。在 14 天内执行的 70 million 查询中，我们研究发现一些现有设计的缺点。

回答基本问题

类别

内容

正确性

创新点

清晰度

阅读选择

Step 2

细读笔记

问题记录

未读（且值得读）文献记录

关于作者提到计算-存储 disaggregation，原理上的内容再看。

[P. X. Gao, A. Narayan, S. Karandikar, J. Carreira, S. Han,R. Agarwal, S. Ratnasamy, and S. Shenker. Networkrequirements for resource disaggregation. InOSDI,2016]

[J. Gu, Y. Lee, Y. Zhang, M. Chowdhury, and K. G. Shin.Efficient memory disaggregation with infiniswap. InNSDI, 2017]

Step 3

思路复现

证明与推理复现

实验验证复现

ReadingGroup 会议

Introduction

什么是 Query Engine？
- 右边流程图
- 本文主要关注数据储存部分。
Store what
- Persistent data
  - Long-live
- Intermediate data
  - Short-live
- Metadata
Shared-nothing architecture
- 优势
- 劣势
  - 中间数据
  - Hardware-workload mismatch（较低的资源利用）
  - 弹性缺失

Solution

Snowflake 总览

Centralized Control
Compute Part
Local Ephemeral Storage（中间存储）
Remote Persistant Storage（持久化存储）

实现细节

Ephemeral Storage System

为什么要做这个？中间数据需要更低延迟更高的吞吐，Amazon S3 不支持。

Idea 1:
- Spill from mem to local SSD
- Spill from local SSD to remote S3
Motivation:
- Why not only mem?
- Why not spill to ohters?
  - 不用跟踪
  - 间接性
Idea 2:
- Caching persistent data
Motivation
- S3 太慢了
- 中间数据短寿命且 size varies
  - Peak Hith Average LOW
  - 内存和 SSD 可以更好的优化
- Workload
  - 一定的局部性
How：（不同的策略）
- Consistent hashing
- Write-through
- LRU

Caching Persistent Data

Strategy 1：Consistent hashing

基于一致性哈希的想法。
Strategy 2：Work stealing

一致性哈希对于静态，ok？
Strategy 3：Lazy consistent hashing

新添加一个 N6，Task6 转向 N6，N1 不用移动到 N6，

Cache 的效果

见图

Future Directions

将中间数据和 ephemeral storage 对应起来。
端到端的性能表现
- 中间数据的吞吐量
- Caching data 的命中率
Caching hierarchy
- Existing caching mechanisms are designed for 2-tier： Mem to SSD
Task Scheduling：
- 一个极端：co-locate the tasks with the files（current）
- 另一个极端：locate the tasks in a single node
- 有兴趣去找最优的方案。
Elasticity
- 粒度太不匹配了（query 的变化和虚拟性）。
- 李：感觉完全不能匹配，除非 serverless
- serverless：

USTCReadingGroup——Building-An-Elastic-Query-Engine