[Paper Reading]The Snowflake Elastic Data Warehouse

Date：2021.12

===== ABSTRACT

我们生活在一个黄金时代，Public cloud platform 提供了虚拟的无限的 计算和存储资源。此外 SaaS 模式 提供给用户企业级的系统，此前他们买不起这样的系统，因为其价格和复杂性。

【传统data warehouse存在的一些问题】传统的 data warehousing 系统都在尝试适应新的环境：

1. 一方面，他们都设计使用固定的资源，无法利用云的弹性；
2. 另一方面，他们依赖的 ETL pipeline 以及 physical tuning 对 云环境下新产生的半结构化数据以及迅速变化的负载 的 flexibility 和 freshness 要求是不同的

所以我们期望从根本上（fundamental）重新设计一个 enterprise-ready data warehousing 解决方案：Snowflake。

Snowflake 是一款 multi-tenant，transaction，secure，highly scalable and elastic 系统，并且支持 full SQL ，内置扩展支持 semi-structured and schema-less data

===== 1. INTRODUCTION

【Cloud带来的变化】Cloud 的到来，标志着 software 不再局限于在 local server 上调度&执行，而是走向 shared data center 以及 SaaS解决方案。

Cloud 这些共享 infrastructure 保证 更大的规模经济、极致的扩展性以及可用性，以及按需付费模型来应对 unpredictable 使用需求。

但是这些优势 只能被已经适配池化资源的软件所利用到。

【数据发生的变化】过去 data warehouse 中的数据主要来自企业：事务系统，ERP（enterprise resource planning），CRM（customer relationship management。数据结构、数据量都是都是可预见的。

然而随着云的到来，巨大且快速增长的数据来自于无法控制的外部资源：log、web应用、手机驱动等。除此之外，数据也更多以 schema-less / semi-structured 格式呈现。[3]

传统 数仓 为了应对上述变化都重度依赖 ETL pipeline & physical tuning

【大数据解决方案】为了应对上述问题，部分 data warehousing 社区转向大数据平台（Hadoop or Spark）。这些是数据处理中不可获取的工具，但是他们仍然缺少足够的效率以及特性来构建 data warehousing，此外更重要的是，他们需要付出巨大的工程能力来推出并使用[16]

我们相信有一大类 use case & workload 能从 云计算的 经济、弹性、服务方面获益，而这些场景不被 传统数仓 以及 大数据平台 的服务场景覆盖

所以，我们决定构建一个新的 data warehousing system：Snowflake。Snowflake的核心特性：

• Pure SaaS Experience：用户数据已经在云上或者将数据上传，随后他们就可以使用 Snowflake 图形页面或者 标准接口（ODBC）来访问数据。对用户来讲，no tuning knobs，no physical design，no storage grooming task
• Relational：完整支持 ANSI SQL & ACID transaction
• Semi-Structured：提供内置的 function & SQL extension 支持常见的 半结构化格式（JSON、Avro）。Automatic schema discovery & columnar storage 使得 对 schema-less&semi-structured 数据操作 像操作 relational 数据一样快
• Elastic：存储计算资源能够独立的扩展，并且不影响可用性以及当前查询的性能
• Highly Available：容忍 node、cluster、甚至 data center failure
• Durable：极高的数据持久性应对 偶发的数据丢失：cloning、undrop、cross-region backup
• Cost-efficient：Snowflake 有极高的CPU利用率以及数据压缩能力。用户只需要支付他们实际使用的存储&计算资源
• Secure：所有数据（包括 临时文件以及网络传输）都进行end-to-end 加密。RBAC 提供 细粒度的访问控制

===== 2. STORAGE VERSUS COMPUTE

【Shared-nothing架构流行及存在的一些问题】

Shared-nothing 架构已经成为 高性能 data warehousing 的主要架构，有2个原因：

• Scalability：这种设计很好的适配 star-schema queries。因为当 join 一个 小的（booadcast）demension table和一个大的（partitioned）fact table时可以有很小的网络流量
• Commodity hardware：由于只有极少的数据机构以及硬件资源争抢，所以不需要昂贵的硬件

但是单纯的 shared-nothing 架构也有一个致命的缺点：计算资源&存储资源紧密的结合在一起，可能这样的一些场景中存在问题：

• Heterogeneous（各种各样的） Workload：虽然 hardware 是同质（homogeneous）的，但 workload 通常不是。一个系统被配置的易于处理 bulk loading（high IO&light compute） 就很难适配 复杂查询（low IO&high compute）
• Membership Changes：当有一些节点发生变化时，会有大量的数据需要 reshuffle。有部分节点同时处理 data shuffling & query processing，所以会造成 显著的性能影响。
• Online Upgrade：小规模的membership changes可以通过 replication 解决，而软硬件升级则会影响系统中的每个节点。虽然可以通过 rolling upgrade 来解决，但是实际上会有些难度，因为everything 都是紧密结合的并且期望是同构的

内部环境对于上述问题可能还可以容忍。云上的环境会更加复杂，需要面临不同的节点类型：node failure & membership change 很频繁，对 online upgrade & elastic scaling 有极高的需求

• Online upgrade 缩短开发周期、提升可用性
• Elastic scaling 增加可用性，并为用户提供符合他们临时需求的资源

因此，Snowflake 拆分了计算&存储资源，计算资源由Snowflake 提供，存储资源由 云存储提供（Amazon S3）。为了降低计算存储之间的网络资源，每个计算节点在本地缓存部分数据。这个解决方案的另外一个优势是 local disk 无需花费在存储large&cold数据上，而只存储hot data（临时数据、cache）。

我们将这个新架构成为 multi-cluster， shared-data architechture

===== 3. ARCHITECTURE

Snowflake 是一个 service-oriented architecture，由 highly fault tolerant、independently、scalable services 组成。

Service 之间交互通过 RESTful 接口，被拆分为 3 层：

• Data Storage：使用 Amazon S3 存储 数据 以及 查询结果
• Virtual Warehouses：系统的 muscle。在 由虚拟机组成的 虚拟集群中 处理 query executiuon
• Cloud Services：系统的 brain。一组服务，负责管理 virtual warehouses、queries、transactions、以及 所有的metadata（data schema，access control information，encryption keys，usage statistics）

===== 3.1 Data Storage

【选择AWS】我们选择 AWS 作为 Snowflake 的 初始平台。有2个原因：1. AWS 是最成熟的云平台；2. AWS 提供了最大的潜在用户池

【选择S3】接下来是选择使用 S3 还是基于 HDFS 自研存储服务，尽管S3的性能有变化，但是其usability，high availability，strong durability 都难以战胜。所以我们选择投入更多的精力在 VW 层的 local caching & skew resilience 上

【S3 properties】和 local storage 相比，S3 有天然的访问延迟，以及（尤其在使用HTTPS链接的时候）有更高的CPU 负载。但 S3 是一款 blob store，通过 HTTP 接口暴露 PUT/GET/DELETE 接口。文件只可以被 全量的 over-write，不支持 append，支持 GET 文件的部分内容

【文件组织形式】S3 的这些特性对 Snowflake 的 文件组织形式 以及 并发控制 影响很大。Tables 被 水平拆分为 【table file】large、immutable files（类似于 传统数据库中的 blocks/pages）。在每个 file 内部，数据 按列 组织在一起，并高效压缩（类似 PAX 格式）。每个 file 都有 一个 header 记录每一列的 offset，便于利用 S3 能 GET 文件部分内容的特性

此外，当 local disk 磁盘满的时候，snowflake 还会将 operator 生成的 temp data 存储到 S3 上，以避免用户收到 out-of-memory 或者 out-of-disk 错误。将 查询结果 存储在 S3 也简化了 query processing，比如其消除了在server-side cursor 存储的问题

Metadata（比如 catalog objects，statistics、locks 等）存储在一个 transactional kv store 上，是 Cloud Services layer 的一部分。

===== 3.2 Virtual Warehouses

Virtual Warehouses layer 层包含由 EC2 组成的多个 cluster。每个 cluster 归属于单个用户，称作 virtual warehouse（VM）。组成 VM 的每个 EC2 节点称作 work node。User 不和 worker nodes 交互，也不知道 VM 由怎样的 worker nodes 组成，VM呈现给用户的是 “T-Shirt sizes”的抽象： 从 X-Small 到 XX-Large。

===== 3.2.1 Esasticity and Isolation

VM 是 pure compute resource，可以被按需的 create、destory、resize。VM的增删不影响服务状态，用户可以在其没有query的时候关闭所有的VM。

每个 Query 都会独占 VM，worker nodes 不会在 VM 之间共享，这保证了良好的隔离性。（未来也会考虑 在 VM 之间共享 worker nodes，针对性能隔离不敏感的场景）

当一个 Query 提交后，其使用的 VM 的每个 worker node 都会启动一个 worker process。每个 worker process 只会在 query 的生命周期内存活。Worker process 本身永远不会造成外部可见性影响，因为 table files 是不可变的[Section 3.3.2]。 Worker failure 需要依靠 retry 来解决（Snowflake 目前不支持 partial retry，未来会考虑支持）

每个 user 在任意时间可能由多个 VM 运行查询，每个 VM 可能依次运行多个查询，每个VM 都访问 相同的共享的 table，所以不需要物理复制数据

// Q：不需要物理复制数据是因为有 local cache么？2个节点处理所有的数据和32节点处理这些数据还是需要数据移动的吧？还是说这里是指在 VM work process 初始化的时候按需加载所需数据，随后不会再加载？

// A：VM 的 worker nodes 数量是配置好的（“T-shirt” size），所以worker nodes cache的数据也是不变的，如果发生 worker nodes resizing，那么数据随着 LRU replacement 策略来逐步完成替换，[Section 3.2.2]

特点、优势：

1. 共享的无限的存储空间，意味着用户可以共享&集成他们所有的数据，这是 Data warehouse 最重要的特性之一
2. 同时，用户可以从 私有的计算资源 中受益，避免不同 workload & organizational unit 之间的影响

1. 不同的 organizational unit 用户可以有不同的 VM 来运行 query

1. 相同的价格可以获得更好的性能， 比如 需要 2个节点运行15h的作业，可以使用32节点只运行2h，价格相同。
   1. 我们认为 VM elasticity 是 Snowflake 架构最大的竞争点之一

===== 3.2.2 Local Caching and File Stealing

每个 worker node 会将 table 数据缓存在本地。过去被访问的数据都会被缓存起来，如果之前的query 只访问了 某个 table file 的部分列，那么缓存也只会有对应的列数据。

Cache 是缓存在 worker node 上的，被所有的 worker process 共享使用，并使用 LRU 的策略淘汰。（未来会适配不同的 workload 来使用不同的淘汰策略）

// TODO：这里利用了 S3 文件的不变性，如果文件有更新，那么会产生新的文件。这里VM 如何感知 文件有更新呢？还是需要访问 一些 metadata？

Sector 3.3.2 中提到，文件的增删都会记录到全局的kv中

为了避免 冗余cache，query optimizer 基于 table name 使用 consistent hashing 分配到对应的 worker node上处理，所有的请求都会按照这样的策略来分配，以保证cache 命中率。

Consistent hashing 是 lazy 完成的，当有节点变更的时候（node failure or VM resizing），不会有数据 shuffle，而是随着 LRU replacement 策略来最终完成。

【File staling】Skew handling，部分节点因为 virtualization issue or network contetion 处理较慢的解决手段：

1. 当有worker process 处理完其所应处理的 file 时，会向peer node请求 file 处理，称为 file stealing
2. 当 peer node 发现他有很多文件没有处理完时，响应 request，并将此次 query 的 部分file ownership transfer 给 requestor
3. Requestor 从 S3 download 对应的文件进行处理

===== 3.2.3 Execution Engine

如果 10 个节点就能完成的事情，用 1000 个节点来做没有很高的价值，所以虽然提供了很强的 scalability ，单节点的 efficiency 仍然很重要。

【Execution Engine 特性】我们期望提供给用户最高性价比的 Database-as-a-service 服务，所以决定自建 SQL execution engine，该引擎构建在 columnar、vectorized、push-based 的特性之上：

• Columnar：列存储可以高效的利用CPU&SIMD指令集，且便于高效压缩
• Vectorized：使用Vectorized execution ，Snowflake 相较于 MR 可以避免 物化中间结果。Vectorized execution 对比与pipeline，可以节省IO 并能极大的提高 cache 利用率
• Push-based，push-based 的执行方式，相比于 volcano-style 的 pull data，可以提升 cache 效率，能更有效的处理 DAG

许多 传统数据库 query processing 的 overhead 在 Snowflake 上不会存在：

1. 执行期间不需要 transaction management，因为 query 时在 immutable file 上执行的
2. 不需要 buffer pool。因为大部分query都会 scan 大量的数据，将 内存 用于 table buffering & operation 是一个不好的决定。
   1. Snowflake 会在 内存不足的时候将 数据 spill 到磁盘，我们发现一个单纯的 main memory engine（可能更加精简也更快）无法很好的应对所有的workload

===== 3.3 Cloud Services

Virtual warehouse是ephemeral（短暂的），user-specific resource。而 Cloud Service 是 heavily multi-tenant。

Cloud Services layer 的服务（access control、query optimizer、transaction manager and other）都是 常驻的 多租户共享的服务。每个服务都是有副本的，以保证 high availability 和 scalability，因此任何一个服务节点异常都不会导致 data loss or loss of availability。

===== 3.3.1 Query Management and Optimization

Query 生命周期 的 早期阶段在 Cloud Services 上完成：parsing，object resolution，access control，plan optimization。

Snowflake query optimizater 遵循典型的级联式方法（Cascades-stype approch），具有 top-down cost-based optimization（自顶向下基于成本的优化器） 。Optimization 使用到所有的 statistics 都会在 data load&update 的时候自动加载。

【缩小plan search 空间】Snowflake 不使用 index，所以 plan search 的空间比其他系统要小，Plan 空间后续还会因为将许多决策推迟到执行阶段完成而进一步缩小。

这样的设计：

• 降低 optimizer 做出 bad decision 的数量
• 增加 在极致性能下的 cost of small loss 的 robustness
• 让系统 easier to use

Optimizer 完成后，执行计划会分发到各个 worker nodes 节点处理，Cloud Services 持续收集查询的状态、探测节点异常。所有的查询信息以及statistics 会存储起来，用于 audits and perfirmannce analysis。

===== 3.3.2 Concurrency Control

Concurrency control 完全由 Cloud Services layer 处理。

Snowflake 旨在处理 analytic workloads：large reads、bulk or trickle inserts、bulk updates。

事务基于 MVCC 实现 Snapshot Isolation（SI）隔离。Table file 是 immutable 的，所以对 MVCC 天然有着很好的支持（数据变化都会产生一个完整的新文件）。文件的增删记录在 metadata中，存储在 全局 kv 存储。

除了支持 SI，Snowflake 还支持使用这些 snapshot 来实现 time travel and efficient clone object。[Section 4.4]

===== 3.3.3 Pruning

只访问对应的数据对查询处理很重要（高效），传统数据库通过索引实现 限制数据访问，而这并不适用于 Snowflake

• 依赖大量的随机访问，这对 存储媒介（S3）和 数据格式（conpressed file）都很不友好
• 维护索引极大的增加了数据容量（the volume of data）以及数据加载时间（data loading time）
• 用户需要显式创建索引

一个可替代的方案最近变得越来越流行：基于min-max的pruning，已知的已经实现在 aggregates [28]，zone maps [29]，data skipping [49]。

Snowflake中记录了 每个chunk的数据分布信息（minimum&maximum value），可以基于这些信息来判断是否需要访问某个chunk。

这种方式的 pruning 很好的适配 Snowflake 的设计：not rely on user input；scale well；easy to maintain；而且对 sequential access 处理的很好

Snowflake 对于每个 table file 都维护了 pruning 需要的 metadata（metadata 中不光包含了 plain relational columns，还包含了对 semi-structured data 自动探测的columns [Section 4.3.2]）。Optimizer 基于这些 metadata 进行 pruning。

除了 static pruning， Snowflake 还会进行 dynamic pruning，比如在进行 join 的时候，收集 join key 分布，可能会进行 bloom joins [40]

===== 4. FEATURE HIGHLIGHTS

Snowflake 提供了很多传统 data warehouse feature：comprehensive SQL support，ACID transaction，standard interfaces，stability and security，customer support，strong performance and scalability。

此外，Snowflake 还引入了很多 valuable feature（很少或者从未在 related system中见到）

===== 4.1 Pure Software-as-a-Service Experience

Snowflake 支持 standard database interface（JDBC、ODBC），并且可以和各种第三方工具&Service集成（Tableau，Informatica、Looker）。

此外，Snowflake 还支持用户通过 web browser 来和系统交互。这看起来不重要，但是却是很有力的竞争点：可以支持用户在不同的环境下快速访问Snowflake，降低了使用系统的成本。

Web UI 除了提供 SQL 操作外，还允许用户访问 database catalog、user、system management、monitoring、usage information等。我们将持续扩展 UI 能力，比如 online collaboration、user feedback and support

===== 4.2 Continuous Availability

过去 data warehousing 解决方案是一个后端的服务，任何（预期和非预期的）的downtime不会对 operation 造成影响。

但是随着 data analysis 对越来越多的 business task 越来越重要，continuous availability 也变得越来也重要。这和 SaaS服务有着相同的趋势（always-on、customer-facing application）

Snowflake 通过 2项 main technical feature 来提供 continuous availability：fault resilience and online upgrades

===== 4.2.1 Fault Resilience

Snowflake 容忍 all level 的 node failure（依赖 跨AZ部署）：

1. Data Storage layer：当前使用的是 S3，其在不同的 AZ 之间复制。Replication 保证 S3 可以处理AZ failure，提供 99.99%的可用性
2. Metadata store 同样存储在 S3 上，具备跨 AZ 复制能力，容忍节点异常
3. Cloud Services 层包含部署在不同 AZ 的多个 stateless node ，上层有 load balancer 负责分发用户请求

Virtual Warehouses层 考虑性能问题（网络吞吐），不是跨 AZ 部署的：

• 单节点异常：query 会 fail，但是可以透明的重试，节点会很快的被替换或者临时降低节点数量。为了加速 node replacement，Snowflake 维护一个 small pool of standby nodes
• AZ异常：所有运行在这个AZ的query会失败，需要用户提供 不同 AZ 的VM 来运行

===== 4.2.2 Online Upgrade

Snowflake 设计可以允许不同服务（CloudServices & VirtualWarehouses）的不同版本共存，这依赖于所有的服务都是无状态的，将状态分离到 transactional key-value store，并通过一个 mapping layer 来访问 kv store。

【online upgrade流程】首先部署新的CloudService & VirtualWarehouse 服务。随后用户的请求渐进的（progressively）切换到新版本 — 新的请求转发到新版本的服务上。老版本上运行的query 完成后，服务逐渐回收。

Load Balancer 将请求转发到对应版本的 Cloud Services上，Cloud Services 只和自己对应的 VMs 交互。

不同版本的 Cloud Services 之间共享 metadata store，不同的 VMs 之间共享 worker nodes以及他们对应的cache。

Online upgrade 落地：目前每周发布一次版本，而且为了保证upgrade & downgrade 运行顺利，在pre-production 环境持续的测试。

===== 4.3 Semi-Structured and Schema-Less Data

Snowflake 扩展了 standard SQL type，针对 semi-structured data 增加三种类型：VARIANT，ARRAY，OBJECT。

VARIANT 可以存储所有的 native SQL type（DATE、VARCHAR …），变长的 ARRAY，以及 OBJECT。（OBJECT 在一些文献中称为 document，比如 MongoDB [39], Couchbase [23]）

ARRAY & OBJECT 都只是更严格的 VARIANT

这几种数据类型内部表现（internal representation）都是一样的：self-describing，compact binary serialization，支持 fast key-value lookup、type test、comparison、hashing。因此可以被作为 join keys、grouping keys、ordering keys

VARIANT 类型让 Snowflake 被用作 ELT（Extract-Load-Transform） ，比 传统ETL（Extract-Transform-Load）更好。

• 不需要声明 data schema（或者在 load前进行transform），用户可以直接将 各种类型 直接 load 到 VARIANT 列。Snowflake 来进行类型 parsing & inference，这 decoupling producer & comsumer
• 此外如果需要进行 transformation，可以使用 Snowflake 提供的全部SQL能力，这往往在 传统 ETL 工具链中是缺失或者效率低下的。此外，Snowflake 还支持 UDF，具有完整的 JavaScript 语法并且与 VARIANT 集成。

===== 4.3.1 Post-relational Operations

【support extraction】

Snowflake 支持对 data elements 的 extraction，基于 field name（OBJECT）或者 offset（ARRAY），可以通过 SQL 方式 或者 JavaScript-like path 来 extract。

【效率】字段内部 encoding 让 exaction 更高效。Parent element 通过 pointer 指向 child element。

Cast 往往跟在 Extraction 之后来讲 VARIANT 转换为 SQL type

【support flattening】

Snowflake 使用 SQL lateral view 来表示 flattening，flattening 可以递归执行来支持多级的document结构。

与 flattening 相对的是 aggregation，Snowflake 引入一个 新的 aggregate function：ARRAY_AGG & OBJECT_AGG

===== 4.3.2 Columnar Storage and Processing

用 serialized（binary） representation 来表示 semi-structured data 是一个很便利的设计，但是基于行的数据组织比 columnar data 低效。

Cloudera Impala [21] （using Parquet [10]）and Google Dremel[34] 已经证明了 semi-structured data 存储在 columnar store 是possible and beneficial。但是 Impala and Dremel 要求用户提供负载的 schema。

为了同时保证 flexibility（schema-less） and performance（columnar store），Snowflake 引入自动的 type inference and columnar storage。

如 Section 3.1 中提到，Snowflake 存储数据使用 hybrid columnar format。

当存储 semi-structured data时，系统在 table file 内部自动分析统计信息，来进行 type inference 并确定常被访问的path。对应的列会从 document 中移除，使用同样的 compressed columnar format 来独立存储。甚至 Snowflake 将这些列的统计信息用在 pruning 上（Section 3.3.3）

scan的时候，这些列会重新 reassembled 到 VARIANT 的 column中。Snowflake 还会将 projection & cast 下推到 scan中，这样只有必要的 column 才会被访问并 cast 成目标类型。

上面提到的 optimization 都是对 每个 table file 独立执行的。但是上面的方式在 query optimization 时出现了一些挑战，尤其是 pruning。

比如，一个 query有一个对 path 的 predicate，我们期望用 meta 信息来进行pruning，这个path对应的column可能存在于大部分的file中，但是这需要path有足够的访问频率，有部分文件中可能是没有的。

最保险的方式是 scan 所有没有对应 metadata 的 file，但是Snowflake 引入了 Bloom filter（对所有的path），bloom filter和其他metadata存储在一起，是否skip这个文件通过 Bloom filter 来完成。

===== 4.3.3 Optimistic Conversion

一些 native SQL types，比如 date/time，在一些通用的外部格式（json、xml）中以string的方式存储。将这些 string value 转换为 actual value 会在 write 时（insert、update）或者 read 时（queries）时进行。如果没有 typed schema or equivalent hint，那么转换行为会在 read 时进行。

【read 时转换】对于 read-dominated workload，这存在问题：

• Write 时转换只需要一次，所以 read-dominated workload场景下 read时转换很低效。
• 没有类型转换的数据不会有对应的 metadata，也就没法针对性的进行pruning。

【write 时转换】但是如果在 write 时就自动转化可能会 lose information，比如 产品identifier 的字段可能不是数字，而是string，其中的leading zeros 很重要

Snowflake 会积极的进行 data conversion，并保留转换前后的结果（除非这是一个完全可逆的转换）。如果这些 column 不被访问，那么带来的 double storage 对查询性能的影响是很小的。

===== 4.3.4 Performance

这里做了一个对比，用2种schema（relational schema、schema-less schema），数据量分别为 SF100（100G）&SF（1T），存储的内容都是单字段的（VARIANT），通过 TPC-H query 进行对比。

上面的测试区别在于 relational schema 包含了 schema 声明，所以测试结果可以证明 Snowflake 对 schema less 场景的优化效果

测试结论： 除了 SF1000 中 Q9&Q17 ，schema-less 的 overhead 大约为 10%。有问题的2个query是因为一个已知的 distinct value estimation bug 导致的。

总结：在 relatively stable and simple schema 场景下， 对 semi-structured 的查询性能和关系数据的性能相当。

===== 4.4 Time Travel and Cloning

Section 3.3.2 中介绍了 Snowflake 基于 MVCC 实现了 Snapshot Isolation。写操作会生成一个新版本的 table file。

当 table file 因为新版本产生而触发 remove 时，可以保留一定的时间（当前最大 90 天）。

保留的文件 允许 Snowflake 读取 table 之前的版本，通过 SQL 的 AT or BEFORE 语法，支持 绝对时间 或者 相对于之前 statementID 的版本

• my_table AT(TIMESTAMP => ' xxx ' )
• my_table AT(OFFSET => -60*5) -- 5 min ago
• my_table BEFORE(STATEMENT => 'statementID')
• my_table new JOIN my_table AT(OFFSET => -86400 old -- 查询同table的不同version

基于上面的机制，Snowflake 还支持：

• UNDROP 来 restore tables，schemas：UNDROP DATABASE important_db;
• CLONE 来 clone 一个 table 而无需 physical copy（只 copy metadata）：CREATE DATABASE new_db CLONE old_db BEFORE(STATEMENT => 'xxx')

===== 4.5 Security

Snowflake 实现 two-factor authentication & (client-side) encrypted data import and export & secure data transfer and storage & role-based access control(RBAC [26]) 来保证数据安全。

数据被 发送到 network 前，写入 local disk 或者 S3 前的都是加密过的，所以 Snowflake 提供 完全的 end-to-end data encryption

===== 4.5.1 Key Hierarchy

Snowflake 使用 256-bit AES 加密，结合基于 AWS CloudHSM [12] 的分层秘钥模型。

Encryption key 自动的 rotated and re-encrypted（rekeyed）来保证加密机制安全，并且 encryption & key management 是对用户透明的并且无须管理

Snowflake key hierarchy 有 4 级：root keys、account keys、table keys、file keys。

Parent key 用于加密 child key。

===== 4.5.2 Key Life Cycle

与 约束 每个key保护数据量正交的是，约束 key 的生命周期。

Encryption key 经历 4 个阶段：

1. pre-operational creation phase
2. operational phase，key 被用作 encrypt（originator-usage period） & decrypt（recipient-usage period）
3. post-operational phase，key 不再被使用
4. destroyed phase

Phase 2 是核心使用阶段，Snowflake 在 originator-usage period 使用 key rotation，在 recipient-usage period 使用 rekeying。

【Key rotation】 会 定期（比如 每月）创建一个新版本的key，每次有新版本的key创建后，之前版本的key就会进入 retired 状态。Retired version 仍然被使用，但只用作 decrypt data。只有最新的 active version 的key 才会被用作 encrypt data

【Rekeying】 负责将 old data 使用 new key 重新加密，每隔一段时间（比如 每年），数据将被使用 new key 重新进行加密。

Key rotation & Rekeying 是正交的，key rotation 将 key 从 active 置为 retired；rekeying 将 key 从 retired 置为 destoryed

其他key的生命周期也是类似的逻辑，比如 account key - table key & root key - account key。每一级的key 都会进行 key rotation & rekeying（包括 root key）。只不过 account key & root key 的 key rotation & rekeying 不需要重新加密file

Table key - file key 之间的关系有点不同，file key 不由 table key 包装（wrapped），而是由 table key & file name 组合衍生而来。这样保证了 table key 发生变化时，相关的 file key 都会变化，因此，所有的table file 都需要 re-encrypted。

选择上面这样设计的原因：

• 不需要对key 进行管理，因为 snowflake 可能管理很多文件
• Snowflake 的 存计分离的架构 不对用户 workload 造成影响：Rekeying 在后台运行，且运行在与 query 不同的 worker node上。当 rekeying 完成后，系统自动更新 metadata，old file 会在 query 运行完成后 删除

===== 4.5.3 End-to-End Security

所有的 key 都基于 AWS CloudHSM 来管理，保证不会被篡改。

除了数据加密，Snowflake 有如下的安全策略：

1. 使用 S3 的访问策略来隔离 storage
2. RBAC
3. 加密的数据导入导出时，云提供商从未在透明的环境中看到数据
4. Two-factor- and federated authentication

===== 5. RELATED WORK

===== Cloud-based Parallel Database System

【v.s. Redshift】Redshift [30] 是第一个提供 data warehouse 服务的产品

• 【架构不同】Redshift使用 shared-nothing 架构，因此 scalable、增删计算资源都需要 data redistribution。而 Snowflake shared-everything架构可以迅速的 scale up/down，无须 data movement
• Snowflake 遵循 pure service 原则，无须用户进行 管理
• Redshift 可以将 semi-structured data 作为 VARCHAR，Snowflake 也有 native support

【v.s. BigQuery】BigQuery [44] 支持用户快速的在 TB 级别数据上进行查询

Snowflake 的一个灵感来自于 BigQuery：支持 JSON 以及 nested data，这对 分析场景 很实用。

【SQL能力以及schema支持】BigQuery 提供 SQL-like language，但是相对于 ANSI SQL 有根本上的偏离，此外 BigQuery table 是 append-only 的 而且要求 schema。

Snowflake 提供完整的 DML、ACID transaction，而且对 semi-structured data 无须 schema

【v.s. Azure】Azure SQL DW 基于 SQL Server and its Analytics Platform System

• 与 Snowflake 类似，也是 存计分离 的架构
• 【单query并发】最大的并发 query 为 32，而 Snowflake 在 VM 上的扩展性是完全独立的

===== Document Store and Big Data

像 MongoDB [39]、Couchbase Server [23]、Cassandra [6] 这类 Document store 变得越来越流行，因为他们的 scalability、simplicity、schema flexibility。然而这类 simple key-value and CRUD API 带来的问题是，他们很难表达 complex query。因此 出现了很多 SQL-like query language（N1QL for Couchbase、CQL for Cassandra）

此外，许多 Big Data engine也支持 nested data，比如 Hive [9]、Spark [11]、Drill [7]、Impala [21] 、Presto [43]。

因此，我们相信对 schema-less and semi-structured data 上进行 复杂分析 有 真实的需求

===== 6. LESSONS LEARNED AND OUTLOOK

略

REFERENCES

[1] Column-stores vs. row-stores: How different are they really?

[16] Big data platforms: What’s next?

[17] Serializable isolation for snapshot databases.

[25] How to build a high-performance data warehouse.

[27] Volcano: An extensible and parallel query evaluation system.

[28] The cascades framework for query optimization.