The Snowflake Elastic Data Warehouse

Categories:  Scholar 2022-11-23

The Snowflake Elastic Data Warehouse

十问

Q1论文试图解决什么问题？

传统数据仓库体系结构不适合云, 本文提出了一个专门为云构建的数据仓库系统.

追问 : 传统数据仓库哪些方面不适合云

• 为固定资源而设计, 无法弹性伸缩，从而没办法利用云的弹性能力
• 面向的是内部的可预测、不易移动且易于分类的数据
  • 传统的数仓依赖复杂的 ETL 流水线, 无法处理云场景下存在的很多半结构化数据
  • 传统数仓依赖物理调优

追问: 为什么一定要上云(云环境的好处)

• 公有云平台能够按需提供几乎无限的计算和存储资源。

• SaaS 模型将企业级系统 带给了无法负担成本和相关系统复杂性的用户
• 云的共享基础设施保证了规模经济，极高的可扩展性和可用性，现收现付成本模式，以便适应不可预测的使用需求

追问 : 本文提到的适合云的系统是怎样的

• Snowflake 是一种多租户、事务性、安全、高度可扩展的弹性系统，具备完整的 SQL 支持和半结构化和 schema-less 数据模式支持。
• Snowflake 的关键特性：极致的弹性和可用性，半结构化和 schema-less 的数据支持，时间旅行，端到端的安全性。

Q2这是否是一个新的问题？

• 当年不知道, 现在云原生数据库已经是老生常谈的问题了.

Q3这篇文章要验证一个什么科学假设？

• 系统论文, 不涉及科学假设

Q4有哪些相关研究？如何归类？谁是这一课题在领域内值得关注的研究员？

• 有些其他云原生数据库系统研究
• 相关团队
  • Amazon Redshift
  • Firebolt
  • PolarDB-X
  • DeltaLake

Q5论文中提到的解决方案之关键是什么？

• 存算分离
  • 存储和计算资源可以独立无缝地扩展，而不影响数据可用性或并发查询的性能
  • 存储和计算分离的另一个好处是，本地磁盘空间不用存储整个数据，这些数据可能非常大，而且大部分是冷数据（很少访问）。本地磁盘专门用于临时数据和缓存，两者都是热数据（建议使用高性能存储设备，如 ssd）。因此，缓存了热数据，性能就接近甚至超过纯 shared-nothing 结构的性能。

追问: 存算不分离的缺点是什么?(Shared-nothing结构的缺点)

在一下场景存在问题

• 异构工作负载
  • 虽然硬件是同样的，但工作负载通常不是。对于大容量加载（高 I/O 带宽，轻计算）来说，理想的系统配置不适合复杂查询（低 I/O 带宽，重计算），反之亦然。因此，硬件配置需要在平均利用率较低的情况下进行权衡。
• 节点关系变化
  • 如果一些节点发生更改，或者是由于节点故障，或者是用户调整系统大小，则大量数据需要重新 shuffle。由于相同的节点同时负责数据 shuffle 和查询，因此会对性能由显著的影响，从而限制了灵活性和可用性
• 在线升级。
  • 虽然通过副本机制可以在一定程度上减轻节点关系变化更改的影响，但软件和硬件升级最终会影响系统中的每个节点。原则上是可能的，一个又一个节点在没有任何系统停机的情况下进行升级。但是由于所有节点都是紧密耦合的，并且都是同质的，这使得实现在线升级变得非常困难。

追问: 存算分离本身的缺点是什么

• 使用了共享存储，那么共享存储 必定是没有 shared–nothing 把数据分布式存储在各个节点的盘下效率高

Q6论文中的实验是如何设计的？

• 论文中只在4.3.4提到一个测试数据库查询性能实验
• 使用了TPC-H-like 数据集和查询进行了测试

生成两份SF100和SF1000的数据集, 每个数据集都分别以关系型和schema-less模式存储, 最后总共4个数据库, 都运行TPC-H查询

除Q9, Q17外, 两种量级的查询基本维持相同的耗时比例, 即10%, 并且关系型和schema-less的查询耗时几乎相当.

Q7用于定量评估的数据集是什么？代码有没有开源？

• 数据集: TPC-H
• 没有开源

Q8论文中的实验及结果有没有很好地支持需要验证的科学假设？

• 本文只有一个实验, 评估列式存储、乐观转换和半结构化数据剪枝对查询性能的综合影响.
• 但无法直接支持系统架构的弹性特点

Q9这篇论文到底有什么贡献？

• 对于云原生数据库应该是什么样子, 本论文展示了一个具有得到市场认可的实际产品

Q10下一步呢？有什么工作可以继续深入？

• SaaS 和系统的多租户方面存在巨大的技术挑战。构建一个能够同时支持数百个用户的元数据层非常复杂
• 如何实现全自助模式, 用户可以在任何阶段注册并与系统交互，而无需我们的参与

重点关注

Snowflake的结构

• Data Storage
  • 该层使用 amazon s3 存储表数据和查询结果
  • 存储是通过亚马逊 S3 提供的，其实任何类型的对象存储都可以 ( Azure 对象存储，Google 云存储 )
• Virtual Warehouse
  • 系统的“肌肉”。该层通过弹性的虚拟集群（称为虚拟仓库），执行查询
  • Snowflake 的（专有的）shared-nothing 引擎提供的
• Cloud Services。
  • 系统的“大脑”。这一层是管理虚拟仓库、查询、事务和围绕虚拟仓库的所有元数据 的服务的集合，包含数据库元信息、访问控制信息、加密密钥、使用情况统计等

整体结构又称为multi-cluster 、 shared-data

存储为什么使用对象存储

• 这里并不是从技术层面考虑的, 主要只因为AWS是云平台最成熟的产品, 能提供最大的用户群体
• 而AWS正好是对象存储

追问 : 那这样”被迫”选择了对象存储, 带来哪些问题? 3.1

S3对象存储的特点

• S3 是一个对象存储，具有一个相对简单的基于 HTTP 的 PUT/GET/DELETE 接口. 对象（即文件）只能完全写入。甚至不可能将数据附加到文件的末尾。
• 文件的确切大小需要在 PUT 请求中前就确定。并且，S3 支持对部分（范围）文件的 GET 请求。

影响

• 存储结构
  • 表被水平地划分成大的、不可变的文件，这些文件相当于传统数据库系统中的块或页
  • 在每个文件中，每个属性或列的值都被分组在一起并进行了大量压缩，这是一种普遍采取的方案，在文献[2]中称为 PAX 或 hybrid columnar。
  • 每个表文件都有一个表头，其中包含文件中每列的偏移量，以及其他元数据。因为 S3 允许对部分文件执行 GET 请求，所以查询只需要下载文件头和它们需要的列。
• 并发控制
  • MVCC 是一个自然的选择，因为表文件是不可变的，这是使用 S3 存储的结果。只有将文件替换为包含更改的其他文件，才能对文件进行更改。因此，表上的写操作（insert、update、delete、merge）通过添加和删除相对于上一个表版本的整个文件来生成新版本的表。在元数据（在全局键值存储中）中跟踪文件的添加和删除，这种形式对属于特定表版本的文件集计算非常高效。

Virtual Warehouses 虚拟仓库具体是什么?

• 虚拟仓库层由 EC2 实例集群组成
• 虚拟仓库按照大家所熟悉的“T 恤尺寸”从 X-Small 到 XX-Large 不等来标识规模大小
• VM 层是纯计算资源，可以按照需求创建、销毁或者在任意时刻改变大小

弹性如何让性能与价格正相关 3.2.1

• 例如，在具有 4 个节点的系统上，数据加载需要 15 小时，而在具有 32 个节点的系统上，数据加载可能只需要 2 小时
• 由于计算时间是付费的，所以总体成本非常相似，但用户体验却截然不同

本地缓存的设计

• 每一个 worker 节点在本地磁盘上缓存了一些表数据。缓存的文件是一些表文件，即节点过去访问过的 S3 对象
• 准确地说，缓存保存文件头和文件的各个列，因为查询只下载它们需要的列。
• LRU进行替换
• 文件读取工作的分配是基于表文件名进行hash分配给工作节点, 这样避免 VW 的工作节点之间对单个表文件进行冗余缓存
• lazy hash, 节点结构改变不会shuffle, 依赖LRU主键替换缓存

文件窃取 3.2.2

• 倾斜处理(某些节点的执行速度可能比其他节点慢得多)
• 每当工作进程完成对其输入文件集的扫描时，它就会从其对等进程请求其他文件，我们称之为文件窃取。当请求到达时，如果一个 worker 发现它的输入文件集合中还有许多文件要处理，这个时候又有其他 worker 请求帮助，这个 worker 将这个请求中他需要的查询的范围内的一个剩余文件的处理权力转移给其他 worker。然后其他 worker 直接从 S3 下载文件，而不是从这个 worker 下载。

实现高效的执行引擎 4.3.4性能表现

• 列存
• 向量化执行
• 基于push

云服务为什么是多租户的

• 多租户提高了利用率并减少了管理开销，这比传统体系结构中每个用户都有一个完全私有的系统在体系结构上具有更好的规模经济。

snowflake为什么没有索引

• 类似B+树结构索引的问题
  • 严重依赖随机访问，由于存储介质（S3）和数据格式（压缩文件），这将是一个问题
  • 维护索引显著增加了数据量和数据加载时间
  • 用户需要显式地创建索引，这与 Snowflake 的纯服务方法不一样, 即使在调优人员的帮助下，维护方面也可能是一个复杂、昂贵有风险的过程

但snowflake也不能说没有索引, 他还是使用了min-max索引

• 系统维护给定数据块（记录集、文件、块等）的数据分布信息，特别是块内的最小值和最大值
• 它不依赖于用户输入；它可以很好地扩展；并且易于维护。更重要的是，它可以很好地对大数据块进行顺序访问，并且在加载、查询优化和查询执行时间方面增加的开销很小。

在线升级

流程

• 为了执行软件升级，Snowflake 首先将新版本的服务与以前的版本一起部署。然后，用户帐户逐渐切换到新版本，这个时候，相应用户发出的所有新查询都被定向到新版本。同时，保证以前版本的所有查询都完成。一旦所有查询和用户在以前的版本没有查询后，以前版本的所有服务都将被终止和停用

性能

• 如前所述，两个版本的云服务共享相同的元数据存储。此外，不同版本的 vw 能够共享相同的工作节点及其各自的缓存。因此，升级后不需要重新填充缓存。整个过程对用户是透明的，没有停机或性能下降

时间旅行 4.4

• 能高效的读取表的早期版本

复制 4.4

• 使用clone关键字, 支持写时复制

关键词

SaaS

https://www.yuque.com/yongyule/xkp8qg/tuiryx92uco6t2ng?# 《SaaS》

time travel

https://www.yuque.com/yongyule/xkp8qg/evoagtuqbg2iwkk4?# 《什么是time travel》

Shared-nothing

https://www.yuque.com/yongyule/xkp8qg/cgb8pyauni9w5tot?# 《Shared Disk, Shared-nothing, 云原生》

Columnar 列式存储

https://www.yuque.com/yongyule/xkp8qg/gdex40oguafdoi9p?# 《行存和列存》

Vectorized 向量化执行

https://www.yuque.com/yongyule/xkp8qg/ig3k1lcul6szxbas?# 《什么是向量化执行》

Push-based 基于push的执行

https://www.yuque.com/yongyule/xkp8qg/wr7zhlnn9xu30fwh?# 《查询引擎: Push vs. Pull》

EC2

https://www.yuque.com/yongyule/xkp8qg/nrt3kv9gfpxnhvgz?# 《什么是EC2》

Snapshot Isolation

数据集市

参考文献

新一代数仓架构-Snowflake弹性数仓 - InfoQ 写作平台

• 原始论文翻译

snowflake数据仓库调研 - 郭大侠1 - 博客园