共计 7620 个字符，预计需要花费 20 分钟才能阅读完成。
摘要：在数据仓库 / 剖析畛域，有传统厂商 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…
点击关注，第一工夫理解华为云陈腐技术~
