Date:2021.12
===== ABSTRACT
我们生活在一个黄金时代,Public cloud platform 提供了虚拟的无限的 计算和存储资源。此外 SaaS 模式 提供给用户企业级的系统,此前他们买不起这样的系统,因为其价格和复杂性。
【传统data warehouse存在的一些问题】传统的 data warehousing 系统都在尝试适应新的环境:
- 一方面,他们都设计使用固定的资源,无法利用云的弹性;
- 另一方面,他们依赖的 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]
特点、优势:
- 共享的无限的存储空间,意味着用户可以共享&集成他们所有的数据,这是 Data warehouse 最重要的特性之一
- 同时,用户可以从 私有的计算资源 中受益,避免不同 workload & organizational unit 之间的影响
- 不同的 organizational unit 用户可以有不同的 VM 来运行 query
- 相同的价格可以获得更好的性能, 比如 需要 2个节点运行15h的作业,可以使用32节点只运行2h,价格相同。
- 我们认为 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 处理较慢的解决手段:
- 当有worker process 处理完其所应处理的 file 时,会向peer node请求 file 处理,称为 file stealing
- 当 peer node 发现他有很多文件没有处理完时,响应 request,并将此次 query 的 部分file ownership transfer 给 requestor
- 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 上不会存在:
- 执行期间不需要 transaction management,因为 query 时在 immutable file 上执行的
- 不需要 buffer pool。因为大部分query都会 scan 大量的数据,将 内存 用于 table buffering & operation 是一个不好的决定。
- 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部署):
- Data Storage layer:当前使用的是 S3,其在不同的 AZ 之间复制。Replication 保证 S3 可以处理AZ failure,提供 99.99%的可用性
- Metadata store 同样存储在 S3 上,具备跨 AZ 复制能力,容忍节点异常
- 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 个阶段:
- pre-operational creation phase
- operational phase,key 被用作 encrypt(originator-usage period) & decrypt(recipient-usage period)
- post-operational phase,key 不再被使用
- 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 有如下的安全策略:
- 使用 S3 的访问策略来隔离 storage
- RBAC
- 加密的数据导入导出时,云提供商从未在透明的环境中看到数据
- 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.