Snowflake Elastic Data WareHouse阅读笔记

0.前言

全文6k字，修修补补写了3天，阅读需要20~30分钟，是论文《Snowflake Elastic Data WareHouse》的精简笔记版，便于后续复习

如有不正确的地方，希望大家批评指正

1.摘要

新型数据仓库、DaaS、multi-cluster、shared-data architecture

传统的数据仓库被设计为用于固定资源，数据的结构、容量、传入速度是可预测的，不能使用云的弹性，随着数据种类的越来越多、数据量越来越大，需要新型数据仓库

那么，什么是Snowflake呢？
下面用一句话概括什么是Snowflake：

Snowflake是整套系统部署在云上的（云原生）、DaaS（dataware house as a service）、serverless、面向OLAP的（基于列大量数据分析）、分布式数据仓库

snowflake有以下特点：

• 多租户 multi-tenant，pay-as-you-go，pay for use
• pure service、SaaS（集群配置、调优、运维无需关心，Snowflake has only one tuning parameter: how much performance the user wants (and is willing to pay for).
• 事务型，支持SQL,ACID，支持ACID级别的事务一致性
• 内置半结构化和无结构化数据（semi-structure data、no schema data）
• 高度弹性（compute、store）和持续可用（resilient to node failure，no downtime upgrade）
• 高可拓展（算力VWs（ET2）可拓展、存储S3可拓展）
• 多集群-共享数据架构（multi-cluster，sharing-data architecture）
• 在sharing-disk的基础上，计算存储分离 （理解：两个架构其实是一回事？） 链接
• 计算上云（计算节点使用虚拟机，EC2）
• 存储上云（run on AWS cloud，AWS S3 对象存储）
• 不基于Hadoop，处理引擎自主研发
• 端对端安全 end-to-end encrypted

2.存储和计算

计算和存储，应该采用什么架构，以及背后选择的原因

那个年代（2012~2014） Shared-nothing architecture成为数据仓库主流（如Teradata、Vertica），原因1：可拓展，原因2：廉价硬件
（虽然是大流，可我们snowflake偏偏不随大流，不用sharing-nothing
商业上性价比最高的，是share-disk，全部用一块盘存，简单来说，是多台机器共享一个分布式存储的大硬盘

大流的share-nothing架构有什么特点呢？
每个query processor node有本地的磁盘，表是水平分区的、跨节点的（数据库分库分表），每个节点只负责本地磁盘上的行，适合星型图查询，每个节点在相同硬件上跑

计算存储耦合的缺点：
（补充，首先设计上不满足：高内聚，低耦合）

1. workload heterogeneous，不能弹性分配计算存储资源，需求变化不一致
2. 集群节点数改变：有的节点既要负责计算，又要负责数据转组（data shuffling），会大大影响弹性和可用性
3. 在线升级：如果需要频繁升级，频繁节点宕机，系统resizing，会对升级带来很大麻烦

考虑到大集群下的节点宕机频繁、集群节点数变更、满足在线升级这些需求
因此Snowflake采取计算存储分离的架构，资源解耦，计算存储松耦合，两者是独立可拓展的服务

• 计算：VW，Snowflake sharing-nothing engine
• 存储：AWS S3 对象存储（key-value），使用HTTP(s)即可，无限、可拓展，（采用友商亚马逊的存储服务，格局真大！）

多集群-共享数据架构

为了减少计算层和存储层的网络I/O通信，（虽然现在是万兆网卡，当然有本地存储空间还是用上一些），每个计算节点在本地磁盘缓存一些 table data，本地磁盘专门用来放置临时数据和缓存（建议用SSD），缓存变热后，性能将达到甚至超过share-nothing system，我们将这种架构称为multi-cluster，shared-data architecture （理解：①同一个虚拟仓库下，工作节点共享‘一块’cache，②由于采用S3，每个VM可以访问所有数据，这叫做共享数据sharing data）

3.架构

介绍了 “多集群-共享数据架构”

3.0
Snowflake提供高可用，高容错，独立可拓展的企业级服务，服务通过RESTful结构进行通信，并分为三层，如上图所示。

3.1 Data Storage层

采用AWS S3存储表数据和查询结果，也存放temp data & query results，！注意元数据不是存这的！

采用S3对象存储的原因：发现尽管性能可能不同，但S3的高可用、耐用保障是无敌的，
选择S3“write once”、“append only”作为底层存储，而不采用Hadoop
和本地存储相比，S3有高出许多的访问延迟和更高的CPU开销，尤其是使用https时，但是更重要的是，S3是具有相对简单的基于HTTP的PUT\GET\DELETE的blob存储区

tables被水平划分到大块、等于块或者页的不可变的文件中，
S3支持GET请求得到部分数据，
查询query只需下载文件头和需要的列数据即可

Snowflake不仅将S3用于表数据，也用于查询生成的临时数据，一旦本地磁盘用尽，将数据spill（刷盘）到S3中

存储结果简单可见，可以用新形式的客户端交互并简化查询

表对象组成的元数据存储在第三层云服务层

3.2 Virtual Warehouses层

ET2实例集群，pure compute resource，在由虚拟机组成的弹性集群上执行查询操作（query execution），共享cache，VMs弹性拓展，面向列的引擎

一个虚拟仓库VM，是一个用户独享的cluster
virtual warehouse 由EC2实例集群组成 （1个VW = n个EC2虚拟机 ，一个EC2虚拟机称为一个工作节点）

3.2.1 弹性和隔离

弹性（VW elasticity）：
VWs是计算资源，可以创建并按需调整大小，当用户没有query时，甚至鼓励关闭VWs集群，弹性使用计算资源

隔离性：
每一个查询只允许在一个VW上，工作节点在VMs（集群）中不共享，属于哪个VM的工作节点就归哪个VW，这就是查询的隔离性
（共享节点是未来的研究方向，适用于不太关注隔离性的场景，简单理解为VMs组成一件T-shirt（different VMs for different uses），VM里的某一个节点是T-shirt上的一块布，布有隔离性，用户对衣服大小需求是弹性的，当用户不需要这么大的衣服，衣服会变小，其中多余的布块会组成别的T-shirt）

当有新查询，在对应的VM中各个工作节点产生工作进程，工作进程仅存活query任务中，工作进程不会造成外部可见性影响

（理解：VW是为了分布式计算，一个query交给一个VW处理，其中的多个工作节点MR处理任务，VWs集群的各个VW又可以并行运行，每个VW可以访问相同的数据，这就是存储共享，而这种存储共享是可无限拓展的）

3.2.2 本地缓存和文件窃取

每个工作节点在本地磁盘维持一个表数据的cache，记录工作节点过去访问过的S3对象数据，cache保存文件头和查询所用到的单独的列，cache在工作节点的生命周期内生存，在并发和后续工作进程中共享，采用LRU缓存置换算法，为了提高缓存命中率、避免cache冗余，对连续、或并发查询相同文件，一致性哈希映射到同一个工作节点上

• 懒惰的一致性哈希：
  当节点宕机或者VMs节点数改变（resize），不会马上data shuffle，通过多个查询替换cache内容
• 偏斜处理 skew handing：
  简单来说就是节点的工作量负载均衡处理，file stealing，当一个peer发现他的peer节点还有文件未读取，改变ownership到当前query下面，帮助其他节点分摊workload

3.2.3 执行引擎

• 柱状的（columnar）
  对于OLAP需要大量的数据分析的需求，面向列存储和执行能更好利用cpu缓存和SIMD指令

• vectorized向量化
  避免了中间结果，数据以流水线的形式，一批批以列的格式处理，节省I/O，提高cache效率

• 基于推送
  关系运算符将结果‘推’给下流运算符，而不是等待这些运算符拉取数据，从紧密的循环中删除了控制流，提高了cache efficiency

此外，还有以下特性：

• 查询过程中无需管理事务
• 查询在一组不可变文件上执行，也没有缓存池
• 当内存耗尽时，让大多操作（join、group by、sort）刷盘spill到磁盘

3.3 Cloud Service层

权限控制，查询优化，并发控制
always online
微服务，K/V store（hard state）

相比于VWs层是临时、用户专用的资源
权限控制、查询优化器、事务manager等是长期存在，并对多租户共享的
服务高可用（单个节点故障不会导致数据丢失）、高拓展
每个用户拥有这一层系统的一个镜像？？

3.3.1 查询管理和优化

用户所有的查询都要经过cloud service层，
查询处理过程：语法分析、对象解析、访问控制、优化

• 采用自上而下基于成本的优化，优化的信息会自动保存到数据加载和更新中
• 没有使用索引
• 推迟执行，减少optimizor的错误
• 持续收集state of query、performance counter、detect node failure
• 用户通过图形界面监视、分析过去和正在进行的查询

3.3.2 并发控制

通过快照隔离（snapshot isolation），实现ACID事务
事务读取会看到数据库的一致性快照
快照隔离是实施在MVCC上的，每个更改的数据库对象会保存一段时间，
对表的（插入、更新、删除、合并）会产生一个新的表对象，（理解：复制表对象t得到t‘，在t‘上进行操作，删除t，然后呢，t对象也不是真正删除，会最多保留90天，这样可以通过SQL读取早期的版本）
文件的增加和删除记录在元数据中（一个全局的K/V strore）

time travel功能示例

此外，还提供CLONE关键字来快速存储table，（不是物理clone，只是metadata clone），可以非常方便的提供数据库快照（snapshot

3.3.3 MAX-MIN剪枝

需要限制相关查询的数据的访问，以往都使用B+树当索引，限制数据访问，这种方法对事务处理很有效，而在Snowflake中会带来诸多问题，
① 依赖于随机访问，由于S3存储和数据压缩？
② 保存索引很占空间，也占数据加载时间
③ 需要用户显示创建索引，与云原生服务的理念大相径庭

采用MAX-MIN剪枝
做区间判断是否可以跳过文件
优点：pure PaaS experience，对于顺序访问非常有效，可拓展性好，会给每个单独的表文件保留剪枝相关元数据

4.功能亮点

Snowflake提供了关系型数据仓库的很多功能：全面的SQL支持，ACID事务，强大的性能和可拓展性，和接下来介绍它额外的独到之处

4.1 纯粹的 PaaS
用户可以从任何地方任何环境访问Snowflake，通过web UI
集群不需要关心配置、扩缩容、调优、后期运维

4.2 持续可用性

无停机时间，容错，在线升级

可用区（AZ availability zone）指的是跨越地区的数据中心
节点故障，其他节点会接管任务
云服务层其余服务由多个可用区的无状态节点组成
loader balancer负责负载均衡，平衡请求的服务
snowflake的元数据也存储在S3中
出于性能考虑，虚拟仓库VW不跨可用区（AZ）,跨区需要网络I/O开销过大

所有的服务是无状态的
hard state存储到 事务型K/V store中，kv store 也是通过映射层 mapping layer来访问，使用元数据版本、结构演变
改变元数据结构，向前兼容

在线升级过程：
两个版本snowflake并行运行，一个版本的云服务层只和匹配的VWs通信，
两个版本的云服务层共享相同数据，不同版本的VWs（虚拟仓库集群）共享相同的工作节点和缓存，升级后无需重新装填缓存

4.3 半结构化和无结构化数据

以VARIANT，ARRAY，OBJECT拓展SQL类型

VARIANT类型可以存储任何SQL中的类型（DATE VARCHAR等）
VARIANT列可以用作连接键、分组键、排序键，这使得可用于ETL
用户可以从 json、avro、xml格式转化为variant列

如果需要transformation，可以使用并行数据库，包括join、sorting、aggregatation等操作

4.3.1关系型操作

• extraction提取操作
  可以通过字段名或者偏移量提取，支持SQL语法、JavaScript语法类似的提取操作
• flattening展平操作
  旋转嵌套的文档分成多行，flattening操作可递归，将文档层次结构转化为适合SQL操作的关系表
• aggregatation聚合操作
  与展平操作功能相反

4.3.2面向列的存储和处理

面向列的数据库更适合OLAP
面向行的数据库更适合OLTP

Snowflake采用新型自动类型推断和列存储的方法
将数据存储在混合列格式中
同一类型的数据，系统会从表中删除列，提取出来单独存储

4.3.3 乐观转换

一些SQL里面的类型如（date、time）在JSON、XML里面表示为字符串，在写入、读取时需要反复转化，写入：字符串–>实际类型，读取：实际类型–>字符串，实际情况是读多写少，那么写入时转化一次就行
自动转化过程中，一些模棱两可的字段保留转化后的数据和原始数据（双重存储）

5.展望

The biggest future challenge for Snowflake is the transition to a full self-service model, where users can sign up
and interact with the system without our involvement at
any phase.

It will bring a lot of security, performance, and
support challenges. We are looking forward to them.