auth:guochaoquncreatetime:2021-06-18
“Snowflake是将基础软件的服务，从传统的To-B的销售，变成了如同快消品一般，通过云原生一改数据仓库积弊；
纯粹的SaaS服务体验。用户不需要购买机器、雇佣数据库管理员或安装软件。用户要么已经在云中拥有数据，要么上传数据。然后，他们可以使用Snowflake的图形界面或ODBC等标准化接口立即操作和查询数据。与其他数据库即服务（DBaaS）产品不同，Snowflake的服务覆盖了整个用户体验。用户无需调优，无需物理设计，无需存储整理任务。
关系型。Snowflake几乎完整的支持了ANSI的SQL和ACID的事务。大部分的用户几乎无需改动或者很小的改动就能迁移已经存在的工作内容。
半结构化和schema-less。Snowflake提供了用于遍历、展平和嵌套半结构化数据的内置函数和SQL扩展，并支持JSON和Avro等流行格式。自动模式发现和列式存储使得对schema较少的半结构化数据的操作几乎与对普通关系数据的操作一样快，而无需用户额外的操作。
弹性。公有云平台几乎能够按需提供无限的计算和存储资源，存储和计算资源可以独立无缝地扩展，而不影响数据可用性或并发查询的性能。
高可用。Snowflake能够容忍节点，集群，甚至全部的数据中心失败。在软件和硬件更新的时候不会下线。
持续性。Snowflake的设计具有极高的持续性，可防止意外数据丢失：克隆、下线和跨区域备份。
经济节约。Snowflake具有很高的计算效率，所有的表数据都被压缩。用户只为他们实际使用的存储和计算资源付费。
安全。所有数据包括临时文件和网络流量都是端到端加密的。没有用户数据暴露在云平台上。此外，用户能够基于角色在SQL级别执行级别细粒度的访问控制。
作为SaaS，Snowflake技术完全通过Internet与客户共享。它使用基于公共云的基础设施与客户联系。
这些服务通过RESTful接口进行通信，分为三个体系结构层：
VirtualWarehouse概念
虚拟仓库：虚拟仓库层由EC2实例集群组成。每个这样的集群通过一个称为虚拟仓库（VW）的抽象呈现给用户。
每个虚拟仓库都是一个MPP（大规模并行处理）计算集群，该集群由Snowflake从云提供商分配的多个计算节点组成。
在以VW为虚拟分布式集群，可以添加多个资源相同的EC2实例计算节点
VW层弹性
可以按照需求创建、销毁或者在任意时刻改变大小。创建或者销毁一个VW对数据库状态没有任何影响。
当没有查询时候，用户可以关闭所有的VW资源（默认10分钟没有使用自动挂起，要使用时立马恢复）。
multi-cluster，如下图，我们可以看到一个VW中可以配置多个相同配置的集群，以此增加并发度；
标准的策略：
即发现有查询排队时，立即新增启动集群；
执行几次后会判断是否可以将负载最少的集群上的负载分配到其他集群，而无需再次启动集群
每个查询只在一个VW上运行
VW查询处理
使用的亚马逊S3云盘，共享存储，可以无限扩容；
AWSS3就是一个网络传输文件的工具，可以理解为命令行操作的百度云盘
存储
列存储压缩列：数据加载到Snowflake后，Snowflake会将数据重组为内部优化的压缩列式格式，然后存到云；
向量化执行：（简单理解为就是消除程序循环的优化）与MapReduce（分布式计算）相比，Snowflake避免了中间结果的物化。相反，数据是以pipeline方式处理的，每次以列成批处理几千行。这种方法由VectorWise（最初是MonetDB/X100）首创，这能节省了I/O并大大提高了缓存效率。
基于push的执行：（简单理解为列筛选、条件过滤等操作在更接近存放数据的层面完成）关系运算符将结果推送到其下游运算符，而不是等待这些运算符拉取数据（经典的火山式模型）。Push-based提高了缓存效率，因为他消除了循环中的控制逻辑。它还使Snowflake能够高效地处理DAG形式的计划，而不仅仅是树的结构，从而可能更好的采用共享和管道化的方式利用中间结果。
数据组织形式：Snowflake管理着如何存储此数据的所有方面-Snowflake处理数据的组织，文件大小，结构，压缩，元数据，统计信息以及其他方面的数据。Snowflake存储的数据对象不直接可见，客户也无法访问；它们只能通过使用Snowflake运行的SQL查询操作进行访问。
从业务角度来说
从性能、形式角度来说
一般情况下一个AZ（Amazonavailabilityzones），由多个相邻DataCenter组成
以AZ为运行单位：
如果发生完全的AZ故障，那么在该AZ的给定VW上运行的所有查询都将失败
并且用户需要在不同的AZ中主动重新配置VW，由于完全的AZ故障是真正的灾难性和极为罕见的事件，我们今天接受这种部分系统不可用的情况，但希望在将来解决它。
传统数仓：计算和存储耦合
shared-nothing架构
优点：
缺点：
数据量未必均匀：因为我们需要提前把数据分布到各个节点，而每个节点都只对自己拥有的数据负责
异构工作负载：虽然硬件是同样的，但工作负载通常不是。对于大容量加载（高I/O带宽，轻计算）来说，理想的系统配置不适合复杂查询（低I/O带宽，重计算），反之亦然。因此，硬件配置需要在平均利用率较低的情况下进行权衡。
节点关系变化：因为我们是需要提前把数据分布到各个节点，如果增加、删除节点，那么就要对数据分布进行重新洗牌（以便新节点可以发挥，或者删除节点后其他节点接收过来后可以相对分布较为均匀，才不会使得性能和数据分布出现极大不均衡）这种数据量一大则会引起大量带宽占用以及其他资源占用；
无法单独的增加计算资源和存储资源：
害怕木板短筒：所谓木桶的短板，遇到后整个engine的性能下降到该短板机器的能力这也是为什么MPP架构不适合异构的机器，要求各节点配置一样。
在线升级：虽然通过副本机制可以在一定程度上减轻节点关系变化更改的影响，但软件和硬件升级最终会影响系统中的每个节点。原则上是可能的，一个又一个节点在没有任何系统停机的情况下进行升级。但是由于所有节点都是紧密耦合的，并且都是同质的，这使得实现在线升级变得非常困难。
【3】中就说一说，snowflake是怎么优化解决shareddisk&sharednothing的缺点，合理利用优点的；
如【2.3】所说，使用了共享存储，那么共享存储必定是没有shared--nothing把数据分布式存储在各个节点的盘下效率高
snowFlake解决了传统数仓的痛点，但这种形式也丧失了传统数仓shared-nothing的优点，无法分布式高效访问磁盘数据；
可以说，这是它的缺点；但它有其他方式来解决这个问题；
所有表格文件在存储的时候，被横向切割成N块，然后每一块用列式存储文件块；
文件拆分与压缩：表被水平地划分成大的、不可变的文件，这些文件相当于传统数据库系统中的块或页。在每个文件中，每个属性或列的值都被分组在一起并进行了大量压缩，这是一种普遍采取的方案
标头(header)：每一个文件块/表文件都有一个header标头，其中包含文件中每列的偏移量offset以及其他元数据(metadata)
部分文件请求：因为S3允许对部分文件执行GET请求，所以查询只需要下载文件头和它们需要的列。
Metadata存储：例如目录(catalog)对象，table由哪些s3文件组成，统计，锁，事务日志保存在一个kv存储里面，这个kv存储作为CloudServiceslayer一部分。
最大亮点：弹性
数据共享
SaaS体验
分离计算和存储为您提供灵活性。它基本上可以说不需要DBA参与，因为它不需要任何性能调优。我们并没有真正进行任何性能调优，性能调优和SQL调优的全部负担都在Snowflake上。
它的易用性非常好。我不需要增加任何用户，而且它的入门更容易。您只需加入用户，就完成了。有简单的SQL和UI以及非常多的连接方式；人们可以轻松使用此解决方案。
共享和协作：
ETL
半结构化数据处理schema-less
以VARIANT，ARRAY，OBJECT拓展SQL类型
VARIANT类型可以存储任何SQL中的类型（DATEVARCHAR等）VARIANT列可以用作连接键、分组键、排序键，这使得可用于ETL用户可以从json、avro、xml格式转化为variant列
在线升级
升级的时候，首先部署新版本的服务，与老版本的服务并行，之前已经运行的请求，可以允许在之前的版本上运行完，一定所有的用户和请求在之前的版本上运行完，老版本的服务被终止和解散。
上图显示了这样的一个2个版本的VW同时允许的状态，上面有2个版本的cloudservice和virtualwarehouse，他们各自选择不同的服务。
这点非常重要，重要是能够支持快速迭代，但是对于传统数据库来讲非常难做到，因为传统的数据库都是有状态的，而snowflake的状态都保存在kvstorage，所有他除了kvstorage。
过于云依赖：依赖于Azure、AWS、GCS。每当这些云服务器之一发生独立中断时，支持就可能成为问题。
不支持地理空间数据：目前没有提供很多处理地理空间数据的选项。也许这在他们的计划中。
不支持非结构化数据：它目前没有支持非结构化数据的选项。也许他们很快就会添加。
连续加载数据限制：将数据从数据文件迁移到Snowflake文件时，有很多关于批量数据加载的支持和指导。如果需要连续加载，用户仅限于Snowpipe。
选中某个VW，调整大小、自动挂起策略、最大最小集群等等
可以创建各种报表，图标里面可以设置各类查询、报表样式等等