snowflake

[levy5307]

https://levy5307.github.io/blog/snowflake/

Introduction

云技术来临了，然而传统的数仓是在云时代之前创建的，他们被设计为在小型静态集群上运行，其架构完全不适合云。

不仅平台发生了改变，数据也在改变。过去数仓要处理的数据主要来自于组织内部，他们的结构、容量和产生速度都是可预知的。随着云技术的发展，大量且快速增长的数据来自于不容易控制的外部，而且经常以schema-less、半结构化的格式存储。面对这些数据时，传统数仓则明显力不从心。

为了应对这些缺点，部分数仓社区已经转向Hadoop或Spark等大数据平台。尽管这些工具是不可或缺的，开源社区也在不断地进行重大改进，如Stinger Initiative（号称让Hive提速100倍），但它们仍然缺乏现有数仓的效率和功能。但最重要的是，他们需要大量的努力来推广和使用。

Snowflake是真正利用云设施的经济、弹性、服务化等优点的数仓产品。它的关键特性如下：

纯正的SaaS体验

用户不需要关心机器、运维、调优、扩容，只要数据上传到Snowflake，立即就可以开始分析。

Retional

支持ANSI SQL和ACID的事务。大部分用户几乎无需改动或者很小的改动就可以迁移其workloads

Semi-Structured

Snowflake提供了用于遍历、展平和嵌套半结构化数据的内置函数和SQL扩展，并支持JSON和Avro等流行格式。自动模式发现和列式存储使得对schema较少的半结构化数据的操作几乎与对普通关系数据的操作一样快，而无需用户额外的操作

Elastic

存储和计算资源可以独立地、无缝地扩展，而不影响数据可用性或者并发查询的性能。

Highly Available

Snowflake能够容忍节点，集群，甚至全部的数据中心失败。在软件和硬件更新的时候不会下线。

Durable

Snowflake的设计具使数据具有极高的持久性，并具有防止意外数据丢失的额外保障：克隆、下线和跨区域备份。

Cost-efficient

Snowflake具有很高的计算效率，所有的表数据都被压缩。用户只为他们实际使用的存储和计算资源付费

Secure

所有数据包括临时文件和网络流量都是端到端加密的。没有用户数据暴露在云平台上。此外，基于角色的访问控制使用户能够在SQL级别执行级别细粒度的访问

Storage v.s. Compute

Shared-nothing结构已经成为高性能数据仓库的主流体系结构，主要原因有两个：可扩展性和商用硬件。在Shared-nothing结构中，每个查询处理器节点都有自己的本地磁盘。表是跨节点水平分区的，每个节点只负责其本地磁盘上的rows。这种设计可以很好地扩展星型模式查询，因为将一个小的（广播的）维度表与一个大的（分区的）事实表进行join需要很少的带宽。而且，由于共享数据结构或硬件资源几乎没有争用，因此不需要昂贵的定制硬件。

在Shared-nothing结构中，每个节点都有相同的功能并在相同的硬件上运行。这种结构设计无疑是良好的。不过有一个重要的缺点：它将计算资源和存储资源紧密耦合，这在某些场景中会导致问题：

Heterogeneous Workload

尽管硬件是同构的，然而workload却不是。对bulk load（高IO带宽，轻计算）场景很适合的配置，却不适合负载查询（低IO、重计算），反之亦然。这使得硬件总体利用率不高

Membership Changes

如果发生节点更改、节点故障，或是用户主动进行了系统调整，则大量数据需要reshuffle。由于相同的节点同时负责数据reshuffle和查询，因此会对性能有显著的影响，从而限制了灵活性和可用性。

Online Upgrade

各种资源耦合在一起，并且是同质化的，因此在线升级想要完全不影响系统变得很困难。

在on-premise环境中（内部部署），这些问题都可以忍受。虽然负载是异构的，但是仅有固定、少量的节点池可供选择，你也没什么可做的。另外升级、扩容或者节点故障发生的概率很低。

但是在云上情况则大不相同了：

像Amazon EC2这样的平台上拥有多种多样的节点类型。要利用其优势，只需要将数据带到正确类型的节点上。


节点故障更为频繁，会导致性能发生巨大变化。membership的改变不是偶然，而是常态。


在线升级和弹性扩展逐渐成为了当下客户的一个重大痛点。在线升级能够大幅缩短软件开发周期，提升系统的可用性

基于此，Snowflake实现了存储和计算分离。存储和计算由两个松耦合、独立可扩展的服务来处理。计算是通过Snowflake专有的shared-nothing引擎提供。存储是通过亚马逊S3提供的，同时支持多类型的对象存储（Azure 对象存储，Google云存储）。

并且每个计算节点在本地磁盘上（推荐SSD）缓存了一些表的数据，这样做有两个好处：

减少计算节点和存储节点之间的网络流量


实现了数据的冷热分离，本地磁盘空间不用存储整个数据，这些数据可能非常大，而且大部分是冷数据（很少访问）。本地磁盘专门用于临时数据和缓存，两者都是热数据。因此，缓存了热数据，性能就接近甚至超过纯shared-nothing结构的性能。

我们称这种新的体系结构为multi-cluster、 shared-data结构。

Architecture

Snowflake的目标是成为企业级的服务，除了易用性和相互操作性之外，还需要有高可用性。整个Snowflake分为三层：

Data Storage

该层使用Amazon S3来存储table data和query result

Virtual Warehouses

系统的“肌肉”。该层通过弹性的虚拟集群（称为virtual warehouse），执行查询

Cloud Services

系统的“大脑”。这一层是管理virtual warehouse、查询、事务和围绕virtual warehouse的所有元数据的服务的集合，包含数据库元信息、访问控制信息、加密密钥、使用情况统计等。

Data Storage

AWS被选为Snowflake的初始平台主要有两个原因。首先，AWS是云平台市场上最成熟的产品。其次（与第一点相关），AWS提供了最大的潜在用户资源。

在S3或者使用HDFS等类似技术开发自己的存储服务的选择中，Snowflake发现S3虽然性能不太稳定，但它的易用性、高可用、强数据可靠性都是很难被替代的。因此Snowflake没有开发自己的存储服务，转而将精力花在了VW层的本地cache和弹性处理倾斜的技术上了。

S3有如下特点：

相对local storage，延迟高，并且有比较高的CPU负载，尤其在使用HTTPS时。


文件只能覆盖写，不能追加写


GET支持读部分文件

这些属性对Snowflake的table file format和并发控制方案有很大的影响。表被水平地划分成大的、不可变的文件，这些文件相当于传统数据库系统中的block或page。在每个文件中，每个属性或列的值都被分组在一起并进行了大量压缩。每个表文件都有一个表头，其中包含文件中每列的偏移量，以及其他元数据。因为S3允许对部分文件执行GET请求，所以查询只需要下载文件头和它们需要的列。

snowflake不仅在表数据上使用S3。当本地磁盘空间耗尽时，它还使用S3存储由查询（例如，大量连接）生成的临时数据，以及大型查询结果。将temp数据溢出到S3，系统可以计算任意大的查询，而不会出现内存不足或磁盘不足的错误。将查询结果存储在S3中，实现了客户端交互新方式并简化查询处理，因为不再需要像传统数据库那样在server端维护query的游标了。

元数据，例如catalog信息，由S3文件、统计信息、锁、事务日志等组成，存储在可伸缩的事务KV存储中，这也是云服务的一部分。

Virtual Warehouse