摘要：在数据仓库/剖析畛域，有传统厂商Oracle，Teradata，开源软件Hadoop，云厂商AWS Redshift，Google Bigquery，Snowflake胜利的技术起因是什么？
1.引子
云数据仓库Snowflake 9月份IPO的新闻引起了业界的关注。2012年才成立的Snowflake，一上市就来个惊雷，IPO筹资38亿美元，创近12年来最大IPO金额。
在数据仓库/剖析畛域，有传统厂商Oracle，Teradata，开源软件Hadoop，云厂商AWS Redshift，Google Bigquery，Snowflake胜利的技术起因是什么？
先从2016年Snowflake在SIGMOD上发表的论文动手。
2.The Snowflake Elastic Data Warehouse论文
注：文中局部图，论文中没有，我集体了解和补充的。
2.1.数据仓库架构比对
Share everything VS Share nothing
传统数仓架构
Share every everything的典型代表如Oracle 一体机
Share nothing的代表。例如Greenplum，ClickHouse，PGXC/XL
MPP架构(PGXL)
Snowflake的架构，强调多租和数据共享：
2.2.Snowflake的要害特色包含：
纯SaaS体验
反对关系型(ANSI)和事务
反对半结构化数据处理，例如JSON和Avro
弹性，存储和计算资源可独立扩大，不影响性能和并发查问
高牢靠，反对节点，集群，甚至整个数据中心down掉都没有问题
持久性，反对数据clone，删除撤回和跨region备份
平安，端到端数据加密，SQL级别基于角色的访问控制
Multi-Cluster, Shared Data Architecture
Snowflake架构分为三层，存储，计算和服务
Data Storage
This layer uses Amazon S3 to store table data and query results.
注：2016年的论文发表时的存储反对状况，以后除了反对S3，还反对 Google Cloud Storage， Microsoft Azure blob storage。防止了云服务商的lock in。
这也是共有云服务客户关怀的问题。
计算层
Virtual Warehouses
The “muscle” of the system. This layer handles query execution within elastic clusters of virtual machines, called virtual warehouses.
服务层
Cloud Services
The “brain” of the system. This layer is a collection of services that manage virtual warehouses,queries, transactions, and all the metadata that goes
around that: database schemas, access control information, encryption keys, usage statistics and so forth.
2.3存储层：
数据保留在S3上，和本地存储拜访相比，时延比拟高，S3反对PUT/GET/DELETE 简略的拜访形式。S3还有个特点是，文件不能在文件尾追加，只能删除或笼罩。S3反对GET接口获取文件的局部数据。
这些特点对Snowflake的表文件格式设计和并发拜访模式有重大影响。
表被程度分区成多个大的，不变的文件。文件等同于传统数据库系统的page或block。每个文件内，每个列被分组，并高度压缩。这种存储模式学名叫PAX或行列混合。每个表文件的文件头，蕴含元数据信息，包含每个列在文件中的偏移量。
Snowflake应用PAX存储格局
PAX存储格局，能够参考附件的参考论文。
2.4计算层：
计算层是通过虚构集群来对外提供逻辑上独立的数仓，叫虚构数仓。VW(虚构数仓)是纯的计算资源，能够按需创立或销毁。创立或销毁不影响数据库状态。
注：MPP或Hadoop体系的存算一体比存算拆散架构零碎有低时延的拜访劣势。
数据起源：见存算拆散性能参考
没有计算存储拜访本地文件系统的低时延的长处，Snowflake在计算层减少了一层cache来缓存文件和元数据，解决文件近程拜访带来的时延问题。
2.4.1计算层的弹性和隔离：
VM（虚拟机）分给一个独立的用户。VM（虚拟机）组成虚构数仓(VW)。组成虚构数仓的一个个虚拟机叫WorkNode，WorkNode不跨VM共享。这样能够保障查问时的性能隔离（会带来资源利用率低的问题，后续版本会思考共享）。
查问提交时，每个VW的worknode创立一个工作过程，工作过程的生命周期仅仅存活于查问时。
过程失败能够进行尝试。局部尝试后续版本会反对。
每个用户可能会有多个VW。每个VW能够访问共享的表，不须要物理的数据copy。
本地缓存和file stealing：
每个worknode在本地磁盘上保护了表数据的缓存。缓存是表文件的内容，也就是本节点过来拜访S3对象。准确的讲，缓存蕴含文件头和每个列对应文件。缓存在worknode的生命周期，在以后和随后的work process间共享。缓存采纳LRU算法进行治理。
为了晋升缓存命中率，防止VW内的work node建的表文件冗余，查问优化器依据表文件名称，采纳一致性哈希的算法把输出的文件？调配到work node。随后的或并发的查问，如果拜访同一个表文件，将调配到同一个worknode。
补一致性hash的图
一致性hash示意
在Snowflake中，一致性哈希的实现采纳懒实现的形式。当work node变动（例如节点失败或VM的规格调整），数据不会立即被调度（shuffle）。实际上，Snowflake依赖LRU替换策略来最终替换缓存内容。
这种解决方案缓解了替换多个查问缓存内容的代价，带来了更好的可用性。share nothing利用零碎是立即替换。
这种懒实现的形式对系统实现也带来了简化，零碎没有降级模式。
除了缓存，歪斜解决在云数仓中也特地重要。一些节点或者因为虚拟化或网络方面的起因导致比其余节点慢。Snowflake在扫描层进行解决切斜问题。当一个工作过程实现输出文件集的扫描，工作过程须要从其余工作过程申请额定的文件时，咱们采纳了一种 file stealing（Snowflake本人起的名字）的形式。
当一个工作过程发现在输出文件集中有多个残余的文件时，收到file stealing的申请时，会转移文件的所有权到申请工作过程。请求者间接从S3上下载文件。这种设计保障file stealing不会对被申请的工作过程带来额定的负载。
2.4.2执行引擎：
列式存储。列式存储被认为比行存储在数据分析中要好。
列式存储能够更充分利用CPU缓存，SIMD指令集，更多的压缩调优的机会。
向量执行。
Snowflake采纳向量化执行，与MapReduce相比，防止两头后果的物化。向量执行形式，数据按流水线形式执行，每批能够解决一个列的数千行记录。向量化执行（MonetDB/X100首先采纳），能够节俭IO，极大的改善缓存效率。
基于推的执行Push-based execution 是指关系算子把他们的后果推给上游的算子，而不是等这些上游算子来拉取数据（经典的火山模型采纳拉取数据的形式）。基于推的执行晋升缓存效率，因为节俭了控制流逻辑。基于推的执行也让Snowflake能够高效地解决DAG形态的执行打算，能够对共享/流水线的两头后果进行优化。
与传统查询处理相比，Snowflake没有额定的负载要解决，例如查问时不须要进行事务管理。
对查问引擎来讲，查问时，文件集是不变的。
同样，也没有缓冲池。
2.5云服务层：
Metadata such as catalog objects, which table consists of which S3 files, statistics, locks, transaction logs, etc. is stored in a scalable, transactional key-value store, which is part of the Cloud Services layer
云服务层是多租的。云服务层的每个服务（访问控制，查问优化，事务管理..）是长期存在并在多个用户间共享。
思考到高可用，每个服务都有正本。单个服务的失败不会影响数据的失落或可用。但能够会导致正在运行的查问失败。
2.5.1查问治理和优化
Snowflake的查问优化器遵循经典的 Cascades style，with top-down cost-based optimization
所有的统计信息当数据加载或更新时主动进行保护。
Snowflake不应用索引。执行打算的搜寻空间比其余零碎要小很多。
执行打算空间通过提早到执行工夫来进一步升高。例如join时的数据分布。
这种设计缩小了执行打算不准的状况。同时减少了健壮性。
一旦优化器实现，执行打算被散布到所有的work node。
当查问执行时，云服务继续跟踪查问状态，收集性能数据，检测节点失败。所有信息和统计信息被保留，用于审计和性能剖析。
2.5.2并发管制
通过SI（Snapshot Isolation）快照隔离形式来实现ACID事务。
SI在MVCC根底上进行实现。
除了SI,Snowflake也通过快照进行工夫旅行，高效的克隆数据库对象。
2.5.3修剪
Snowflake应用的修剪模式
传统的数据库数据拜访采纳基于B+Tree的索引来进行。传统索引形式依赖随机拜访，这种形式对S3和列压缩不敌对。同时保护索引会减少数据存储占用，减少数据加载工夫。
最初，索引治理是简单，低廉，有危险的操作。
Snowflake反对修剪的技巧是在元文件中保护文件头，文件最大，最小，count，avg，sum等元数据信息。
除了动态修剪，Snowflake也反对执行时动静修剪。例如再hash join时，snowflake收集build-side records的参加join的key的分布式信息，而后推送给probe side，用于过滤或跳过probe side侧的文件。
2.6重点个性
2.6.1纯的SaaS体验。
反对JDBC,ODBC, Python PEP-0249接口。反对第三方服务，例如Tableau, Informatica, Looker
无任何调优参数：
用户只有在洽购时才抉择一个数仓的大小T-SIZE模式。
2.6.2继续可用
Multi-Data Center Instance of Snowflake
Snowflake tolerates individual and correlated node failures at all levels of the architecture。
2.6.3在线降级
所有的服务时无状态的，都能够配置多版本。所有的有状态的数据被保留在基于key/value的存储中。状态数据通过映射层进行元数据版本和schema演进。任何时候更改元数据schema，保障后向兼容。
云服务的两个版本共享同样的元数据存储信息。
2.6.4半结构化和Schema-Less数据
Snowflake 通过三个数据类型来扩大SQL类型：VARIANT, ARRAY, and OBJECT。
VARIANT 能够保留任何原生SQL类型，也能够保留变长ARRAYs值，JavaScript相似的对象，string到VARIANT的映射信息
ARRAY 和OBJECT是限度版的VARIANT，外部实现是一样的：
a self-describing, compact binary serialization which supports fast key-value lookup, as well as efficient type tests, comparison, and hashing
列式存和解决
Cloudera Impala (using Parquet) and Google Dremel have demonstrated that columnar storage of semi-structured data is possible and beneficial. 、However,Impala and Dremel (and its externalization BigQuery)require users to provide complete table schemas for columnar storage.
To achieve both the flexibility of a schema-less serialized representation and the performance of a columnar
relational database, Snowflake introduces a novel automated approach to type inference and columnar storage
Snowflake 采纳新鲜的主动进行类型推断和列式数据存储的形式。
2.6.5 TCP-H性能
2.7平安
采纳AES 256强加密形式分层加密，下层加密上层的key。Rootkey 保留在AWS CloudHSM（硬件）中。
每个用户独立的account key。
Key反对生命周期治理：
3.理论性能
从SIGMOD2016的论文上只提到了一些含糊的数据
The system runs several million queries per day over multiple petabytes of data.
每天数百万查问，反对数PB数据。
2018年：每天数百Million的查问，数百PB数据量
2020年：每天500 Million的查问
从snowflake分享的宣传材料上，提到的3个行业的性能比对
420/26 =16倍
480/1.5 = 320倍
和传统数仓比最高快200倍。
Gigaom 公司2019年提供的性能比对数据（sponsored by Microsoft）
30TB的TPC-DS规范所有测试数据总共耗时
从测试后果来看，微软的Azure 的数据仓库性能排第一，Snowflake排第二。
2020年Fivetran公司提供的性能测试数据
1TB TPC-DS性能测试数据
此测试数据没有微软的Azure数仓的比对。
In April 2019, Gigaom ran a version of the TPC-DS queries on BigQuery, Redshift, Snowflake and Azure SQL Data Warehouse. This benchmark was sponsored by Microsoft. They used 30x more data (30 TB vs 1 TB scale). They configured different-sized clusters for different systems, and observed much slower runtimes than we did:
对于Gigaom2019的测试后果，Fivetran也感觉比拟奇怪。
注：Fivetran 是Snowflake的合作伙伴，做数据集成的。
4.性价比
从Gigaom报告看，微软云数仓性价比第一，Snowflake排第二
从Gigaom和Fivetran 的报告来看，Snowflake的性能都排在Google的BigQuery和Redshift之前。
5.客户
2018年是1000多个用户
2020.1超过3000个用户，56个价值用户
注：客户信息来自IPO说明书
6.Snowflake设计的教训
半结构化解决带来的成果超出预期。
弹性比性能更重要。
7.挑战
当反对上万用户的并发拜访时带来微小挑战，例如元数据层变的微小。
SQL性能调优，歪斜数据处理要继续优化。
8.后续布局（2018年的plan）
多云：（2020年反对微软 AWS Google）
从Snowflake的后续版本布局来看，也能够看出业界数仓产品的局部演进方向，例如 主动调优，物化视图，数据湖，流数据处理，时序数据处理（毕竟IOT大数据的剖析也是一个重点方向）。
9.总结
从技术角度，Snowflake值得咱们学习的技术点包含计算存储拆散，PAX列式存储，向量化执行，元数据管理和缓存机制。
从治理的角度，一个好的产品胜利。离不开牛人。
20多年的数据库设计教训
微软和oracle的大神
向量化查问的发明者。
10.附参考信息
SIGMOD 2016年的论文：
https://dl.acm.org/doi/pdf/10...
https://0xzx.com/202009202141...
snowflake相干
https://www.slideshare.net/sn...
https://www.slideshare.net/Vi...
https://www.slideshare.net/da...
https://www.slideshare.net/sn...
https://www.slideshare.net/sn...
https://www.youtube.com/watch...
https://docs.snowflake.com/en...
PAX相干
Weaving Relations for Cache Performance
https://research.cs.wisc.edu/...
Data Page Layouts for Relational Databases on Deep Memory Hierarchies
https://research.cs.wisc.edu/...
Spanner: Becoming a SQL System
https://static.googleusercont...
https://zhuanlan.zhihu.com/p/...
Data Blocks: Hybrid OLTP and OLAP on Compressed Storage using both Vectorization and Compilation
Snowflake参加编写
https://db.in.tum.de/download...
存算拆散性能参考
http://www.odbms.org/2018/01/...
IPO上市说明书
https://www.sec.gov/Archives/...
https://mp.weixin.qq.com/s/Be...
https://mp.weixin.qq.com/s/td...
https://zhuanlan.zhihu.com/p/...
https://segmentfault.com/a/11...
图解一致性hash算法：
https://segmentfault.com/a/11...
点击关注，第一工夫理解华为云陈腐技术~