在上半部分中，论文中主要介绍了Snowflake的整体、存储与计算结构，详情点击Snowflake弹性数仓论文翻译（上）。以下将继续Snowflake论文的后半部分。

四、亮点功能

Snowflake提供了关系型数仓所期望的许多特性：全面的SQL支持、ACID事务、标准接口、稳定性和安全性、用户支持，当然还有强大的性能和可扩展性。此外，它还引入了一些在相关系统中很少或没有的其他有价值的特性。本节介绍了其中一些我们认为有技术区别的特性。

4.1 Saas服务体验

正如大部分Saas服务一样，Snowflake可以通过浏览器直接与系统交互。一个WebUI是一个关键的区别。WebUI使得从任何位置和环境访问Snowflake都非常容易，同时由于云中已有大量数据，用户只需将Snowflake指向自己的数据并进行查询，而无需下载任何软件。

Snowflake的UI界面可以SQL操作，还可以访问数据库目录、用户和系统管理、监视、使用信息等。

4.2 持续可用性

在过去，数仓的解决方案一般是局域网内的隐藏较好的后端系统，与世界上大部分的网络隔离的。在这种环境中，计划内（软件升级或管理任务）和计划外（故障）的停机时间通常不会对操作产生很大影响。但是，随着数据分析对越来越多的业务任务变得至关重要，持续可用性成为数仓的一个重要需求。

Snowflake提供了满足这些期望的连续可用性。这方面的两个主要技术是故障恢复能力和在线升级能力。

4.2.1 故障恢复能力

Snowflake在体系结构的所有级别上都能容忍单个和相关的节点故障，如图2所示。如今，Snowflake的数据存储层是S3，它跨多个数据中心进行复制，在Amazon术语中称为“可用性区域”（availability zones）或AZs。跨AZs的复制允许S3处理完整的AZ故障，并保证99.99%的数据可用性和99.999999999%的持久性。与S3的体系结构相匹配，Snowflake的元数据存储也在多个AZ之间分布和复制。如果一个节点发生故障，其他节点可以在不影响终用户的情况下接管任务。云服务层的其余服务由多个AZ中的无状态节点组成，负载均衡器负责分发用户请求。因此，单个节点故障甚至是完全的AZ故障都不会对系统范围造成影响，可能是对当前连接到故障节点的用户的一些失败查询。这些用户将被重定向到另一个节点进行下一次查询。

相比之下，虚拟仓库（VM）并不分布在AZs中。这个选择是出于性能考虑。高吞吐是分布式查询执行的关键，而在同一个AZ中，网络吞吐量要高得多。如果其中一个工作节点在查询执行期间失败，则查询会失败，但会透明地重新执行，要么立即替换该节点，要么暂时减少节点数。为了加速节点更换，Snowflake维护了一个小的备用节点池。（这些节点还用于快速VW配置。）

如果全部的AZ变得不可用，那么在该AZ的给定VW上运行的所有查询都将失败，并且用户需要在不同的AZ中主动重新配置VW。由于全部的AZ故障是真正的灾难性和极为罕见的事件，我们今天接受这种部分系统不可用的情况，但希望在将来解决它。

4.2.2 在线升级能力

Snowflake不仅在发生故障时提供连续可用性，而且在软件升级期间也提供连续可用性。系统的设计允许同时部署服务的多个版本，包括云服务组件和虚拟仓库。这是因为所有服务实际上都是无状态的。所有的状态都保存在事务性KV存储服务中，并通过映射层进行访问，映射层负责元数据版本控制和模式演化。每当我们更改元数据模式时，我们都会确保与以前的版本向后兼容。

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

图3显示了正在进行的升级过程的快照。有两个版本的Snowflake运行并排，版本1（亮）和版本2（暗）。云服务有两个版本，控制两个虚拟仓库（vw），每个都有两个版本。负载平衡器将传入的请求定向到云服务的适当版本。一个版本的云服务只与一个匹配版本的通信。

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

在线升级也对我们的开发速度，以及如何处理Snowflake的关键bug产生了巨大的影响。在撰写本文时，我们每周升级一次所有服务。这意味着我们每周都会发布功能和改进。为了确保升级过程顺利进行，升级和降级都在一个特殊的预生产的Snowflake副本不断测试。在极少数情况下，如果我们在产品中发现了一个严重的bug（不一定是在升级过程中），我们可以很快地将其降级到以前的版本，或者实施一个修复程序并执行一个超出原计划的升级。这个过程并不像听起来那么可怕，因为我们不断地测试和使用升级/降级机制。这是高度自动化的和并且严格的。

4.3 半结构化和Schema-Less的数据

Snowflake将标准SQL类型系统扩展为三种半结构化数据类型：VARIANT、ARRAY和OBJECT。VARIANT类型的值可以存储本地SQL类型的任何值（DATE、VARCHAR等），也可以存储可变长度的数组，以及类似JavaScript的对象，字符串到VARIANT值的映射。后者在文献中也被称为documents，由此产生了文档存储的概念（MongoDB，Couchbase）。

数组和对象只是类型VARIANT的严格形式。内部表示是相同的：一个自描述的紧凑二进制序列化类型，它支持快速的键值查找，以及高效的类型测试、比较和hash。因此，VARIANT列可以像其他列一样用作join keys、gourping keys和ordering keys。

VARIANT类型允许Snowflake以ELT（Extract-Load-Transform）方式使用，而不是以传统的ETL（Extract-Transform-Load）方式使用。不需要指定数据的schema或在加载时进行转换。用户可以将JSON、Avro或XML格式的输入数据直接加载到变量列中；Snowflake处理解析和类型推断（参见第4.3.3节）。这种方法在文献中被恰当地称为“schema later”，它允许通过将信息生产者与信息消费者和任何中介分离来解决schema问题。相反，传统ETL管道中数据schema的任何更改都需要组织中多个部门之间的协调，这可能需要数月的时间来执行。

ELT和Snowflake的另一个优点是，以后如果需要转换，可以使用并行SQL数据库查询功能来执行转换，包括连接、排序、聚合、复杂谓词等操作，这些操作在传统ETL工具链中通常缺失或效率低下。在这一点上，Snowflake还具有自定义函数（udf），支持完整的JavaScript语法，并与VARIANT数据类型集成。对udf的支持进一步增加了可以在Snowflake中执行的ETL任务的数量。

4.3.1 后关系执行

对数据重要的操作是提取数据元素，可以按字段名（对于对象）提取，也可以按偏移量（对于数组）提取。Snowflake提供了函数式SQL和类JavaScript的路径标识来支持。内部编码也使得提取非常高效。子元素只是父元素中的指针；不需要复制。提取之后通常会将结果变量值转换为标准SQL类型。同样，编码也使强制转换非常有效。

第二种常见操作是展平数据，即将嵌套结构旋转到多行中。Snowflake使用SQL横向视图来表示展开操作。这种扁平化可以是递归的，允许将文档的层次结构完全转换为一个适合SQL处理的关系表。与展平相反的操作是聚合。Snowflake为此引入了一些新的聚合和分析函数，如ARRAY_ AGG和OBJECT_AGG。

4.3.2 列存及处理

将半结构化数据序列化（二进制）是将半结构化数据集成到关系数据库中的常规选择。不好的方面是，行存储的处理效率一般低于列存储，所以列式关系数据一般会将半结构化数据转换为关系数据。

Cloudera Impala[21]（使用Parquet[10]）和Google Dremel[34]已经证明，半结构化数据的列式存储是可能的，也是有益的。然而，Impala和Dremel（及其外部化BigQuery[44]）要求用户为列式存储提供完整的table schema。为了实现schema-less序列化仍然保持灵活性和列式关系数据库的性能，Snowflake引入了一种新的自动类型推断和列式存储方法。

如第3.1节所述，Snowflake以混合列格式存储数据。在存储半结构化数据时，系统会自动对单个表文件中的文档集合执行统计分析，以执行自动类型推断，并确定哪些（类型化的）类型是常见的。然后从文档中移除相应的列单独存储，单独存储的列使用与本地关系数据相同的列压缩方式。对于这些列，Snowflake甚至会计算物化聚合，以便通过修剪（参见第3.3.3节）使用，就像普通关系数据一样。

在扫描过程中，不同的列可以重新组合成一个VARIANT的列。然而，大多数查询只对原始文档的一部分列感兴趣。在这些情况下，Snowflake会将映射和强制转换表达式下推到scan中，只访问必要的列并将其直接强制转换到目标SQL类型中。

上面描述的优化对于每个表文件都是独立执行的，这使得即使在schema变化的情况下也可以有效地存储和提取。然而，它确实给查询优化带来了挑战，特别是剪枝。假设一个查询在路径表达式上有一个谓词，我们希望使用修剪来限制要扫描的文件集。路径和相应的列可能出现在大多数文件中，但频率仅足以保证某些文件中的元数据。保守的解决方案是简单地扫描没有合适元数据的所有文件。Snowflake通过计算所有路径上的Bloom过滤器（而不是值）来改进此解决方案存在于文件中。这些Bloom过滤器与其他文件元数据一起保存，并在修剪期间由查询优化器进行探测。可以安全地跳过不包含给定查询所需路径的表文件。

4.3.3 乐观转换

由于一些本地SQL类型（尤其是日期/时间值），比如常用的格式（如JSON或XML）中是字符串，因此需要在写入时（插入或更新期间）或读取时（查询期间）将这些值从字符串转换为其实际类型。如果没有schema的提示，这些字符串转换需要在读取时执行，而在以读取为主的查询中，这比在写入期间执行一次转换效率要低。没有类型的数据的另一个问题是缺少合适的元数据进行优化，比如对于日期比较重要。（分析工作通常在日期列上有范围查询。）

但在写入时，自动转换可能会丢失信息。例如，一些字段定义成数字实际上可能不是数字，比如前面填充0的字符串。又比如，看起来像是日期实际上可能是文本内容。Snowflake通过执行乐观数据转换来解决这个问题，并在单独的列中保存转换结果和原始字符串（除非是完全可逆的不保存原始字符串）。如果查询之后需要原始的字符串，则可以轻松地检索或重构。因为有不加载和不访问未使用的列，所以双存储对查询性能的影响是小的。

4.3.4 性能表现

为了评估列式存储、乐观转换和半结构化数据剪枝对查询性能的综合影响，我们使用TPC-H-like数据集和查询进行了测试。

我们创建了两种类型的数据库模式。首先，一个传统的关系型TPC-H模式。第二种是“schema-less”数据库模式，其中每个表都由一列VARIANT类型组成。然后，我们生成聚集（排序）的SF100和SF1000数据集（分别为100GB和1TB），以纯JSON格式存储数据集（即日期变成字符串），并使用关系数据库模式和schema-less数据库模式将数据加载到Snowflake中。我们没有将schema-less数据的字段、类型提供给系统，也没有进行调优。然后，我们在schema-less数据库定义了一些视图，以便能够对所有四个数据库运行完全相同的TPC-H查询集。（在撰写本文时，Snowflake不使用视图进行类型推断或其他优化。）

后，我们对这四个数据库运行了所有22个TPC-H查询，使用了一个中等标准的仓库。图4显示了结果。测试结果是通过三次热缓存运行的结果。标准误差是很少，因此省略了。

可以看出，除了两个查询（SF1000上的Q9和Q17）之外，其他所有查询的schema-less存储和查询处理的开销都在10%左右。对于这两个查询，我们确定了慢的原因是join顺序，这是由distinct的已知错误造成的。我们继续改进半结构化数据的元数据收集和查询优化。

总之，对于具有相对稳定和简单模式的半结构化数据（即在实践中发现的大多数机器生成的数据），其查询性能几乎与传统关系数据查询的性能相当，可以直接使用列存储、列执行和修剪的优势，而无需用户优化。

4.4 时间旅行和复制

在第3.3.2节中，我们讨论了Snowflake如何在多版本并发控制（MVCC）之上实现快照隔离（SI）。对表的写入操作（插入、更新、删除、合并）通过添加和删除整个文件来生成表的更新版本。

当文件被新版本删除时，它们将保留一段可配置的时间（当前长为90天）。文件保留允许Snowflake非常高效地读取表的早期版本；也就是说，在数据库上执行时间旅行。用户可以使用方便的AT或BEFORE语法从SQL访问此功能。时间戳可以是时间，相对时间，或者是相对之前查询语句中的时间（由ID引用）。

Select from my_table at (TIMESTAMP =>’Mon, 01 May 2015 16:20:00 -0700’::timestamp);
Select * from  my_table  at  (OFFSET => -60*5);   -- 5 min ago
Select * from my_table before (STATEMENT =>’8e5d0ca9-005e-44e6-b858-a8f5b37c5726’);

一个查询可以查询一个表的多个版本。

SELECT new.key, new.value, old.value FROM my_table new JOIN my_table AT(OFFSET => -86400) old -- 1 day ago ON new.key = old.key WHERE new.value <> old.value;

基于相同的底层元数据，Snowflake引入UNDROP关键字来快速恢复意外删除的表、schemas或整个数据库。

DROP DATABASE important_db;--whoops!
UNDROP DATABASE important_db;

Snowflake还实现了一个我们称之为CLONE的功能，通过新的关键字CLONE来表示。CLONE表可以快速创建具有相同定义和内容的新表，而无需对表文件进行物理复制。CLONE操作只是复制源表的元数据。克隆完成后，两个表引用同一组文件，但此后可以独立修改这两个表。CLONE特性还支持整个schemas或数据库，这是非常高效的快照。在进行大量更新之前，或者在执行较为复杂的探索性数据分析时，快照是一种很好的做法。CLONE关键字甚至可以与AT和BEFORE组合使用，这样就可以在事后创建快照。

CREATE DATABASE recovered_db CLONE important_db BEFORE( STATEMENT => ’8e5d0ca9-005e-44e6-b858-a8f5b37c5726’);

4.5 安全性

Snowflake实现了双因素身份验证（客户端）加密数据导入和导出、安全数据传输和存储以及基于角色的数据库对象访问控制（RBAC）。在任何时候，数据在通过网络发送之前以及在写入本地磁盘或共享存储（S3）之前都是加密的。因此，Snowflake提供了完整的端到端数据加密和安全性。

4.5.1 密钥层次结构

Snowflake使用了加密性强的AES 256位加密，其分层密钥模型植根于AWS CloudHSM。加密密钥会key rotation并rekeying（“重新加密”），以确保密钥完成整个NIST 800-57加密密钥管理生命周期。加密和密钥管理对用户完全透明，不需要用户配置或管理。

Snowflake秘钥层次结构（如图5所示）有四个级别：根秘钥、帐户秘钥、表秘钥和文件秘钥。每层（父）密钥加密，即将下面的（子）密钥层包装起来。每个帐户键对应一个用户帐户，每个表秘钥对应一个数据库表，每个文件秘钥对应一个表文件。

分层密钥模型是很好的安全实践，因为它们限制了每个密钥保护的数据量。如图5中的框所示，每一层都缩小了它下面的键的范围。Snowflake的分层密钥模型确保了多租户体系结构中用户数据的隔离，因为每个用户帐户都有一个单独的帐户密钥。

4.5.2 密钥的生命周期

每个密钥保证了保护的数据量，Snowflake还保证了密钥可用时间。加密密钥经历四个阶段：（1）操作前创建阶段，（2）操作阶段，其中密钥用于加密（发起者使用期）和解密（接收者使用期），（3）操作后阶段，其中密钥不再使用，（4）销毁阶段。阶段1、3和4的实现非常简单。第2阶段需要限制发起者和接收者的使用期限。只有当一个密钥不再加密任何所需的数据时，它才能转到第3和第4阶段。Snowflake使用key rotation限制发起者的使用周期，使用rekeying限制收件人的使用周期。

key rotation。以固定的间隔（例如，一个月）创建秘钥的新版本。在每个这样的间隔之后，将创建密钥的新版本，并且密钥的先前版本将“失效”。失效的版本仍然可用，但仅用于解密数据。在密钥层次结构中包装新的子密钥或写入表时，仅使用密钥的新活动版本来加密数据。

rekeying。是用新密钥重新加密旧数据的过程。在特定的时间间隔（例如，一年）之后，使用失效密钥加密的数据将使用活动密钥重新加密。rekeying和key rotation不存在冲突。key rotation可确保密钥从活动状态（发起方使用）转移到失效状态（接收方使用），rekeying可确保密钥从失效状态转移到销毁状态。

图6显示了单个表秘钥的生命周期。假设每个月轮换一次秘钥，每年重新设置一次数据秘钥。表文件1和表文件2是在2014年4月创建的，使用键1版本1（k1v1）。2014年5月，将key1旋转为版本2（k1v2），并使用k1v2创建表文件3。2014年6月，key1被旋转到版本3（k1v3），并创建了另外两个表文件。2014年6月之后，不再对表进行插入或更新。2015年4月，k1v1已满一年，需要销毁。将创建一个新密钥，即密钥2版本1（k2v1），并使用k2v1重新设置与k1v1关联的所有文件的密钥。2015年5月，k1v2也发生了同样的情况，表文件3使用k2v2重新键入。2015年6月，表文件4和表文件5使用k2v3重新设置了密钥。

在帐户秘钥和表秘钥之间以及根秘钥和帐户秘钥之间实现了类似的方案。秘钥层次的每一级都会经历key rotation和rekeying，包括根秘钥。帐户密钥和根密钥的key rotation和rekeying不需要对文件进行重新加密。只需要重新加密较低级别的密钥。

不过，表秘钥和文件秘钥之间的关系是不同的。文件秘钥不由表秘钥包装。相反，文件密钥是从表密钥和（的）文件名的组合加密派生的。因此，每当表密钥更改时，其所有相关的文件密钥都会更改，因此需要对受影响的表文件重新加密。然而，密钥派生的大好处是，它消除了创建、管理和传递单个文件密钥的需要。像Snowflake这样的系统处理数十亿个文件，不然就必须处理GB级别的文件密钥。

我们选择这种设计也是因为Snowflake将存储和计算分离，它可以在不影响用户工作的情况下执行重新加密。rekeying是后台线程，rekeying与查询在不同的节点。在文件被重新加密之后，Snowflake会自动更新数据库表的元数据，以指向新加密的文件。所有正在进行的查询完成后，旧文件将被删除。

4.5.3 端到端的安全性

Snowflake使用AWS CloudHSM作为防篡改、高度安全的方法来生成、存储和使用密钥层次结构的根密钥。AWS CloudHSM是一组硬件安全模块（hsm），它们连接到AWS中的虚拟私有集群。根密钥永远不会离开HSM设备。所有使用根密钥的加密操作都在HSMs本身中执行。因此，在未经授权访问HSM设备的情况下，不能打开较低级别的密钥。hsm还用于在帐户和表级别生成秘钥，包括在秘钥rotation和重建秘钥控期间。我们使用其高可用性配置中配置了AWS CloudHSM，从而保证小化服务中断。

除数据加密外，Snowflake还通过以下方式保护用户数据：

• 通过访问S3时运用隔离存储策略。
• 用户帐户中基于角色的访问控制，用于对数据库对象进行细粒度的访问控制。
• 加密的数据导入和导出，云提供商（Amazon）也不知道数据的具体内容。
• 用于安全访问控制的双因素和联合身份验证。

总之，Snowflake提供了一个植根于AWS CloudHSM的分层密钥模型，并使用key rotation和rekeying来确保加密密钥遵循标准化的生命周期。密钥管理对用户完全透明，不需要配置、管理或下线。它是全面的安全策略的一部分，该策略支持完全的端到端加密和安全性。

五、相关工作

云上的数据系统。Amazon有许多DBaaS产品，其中amazon redshift是数仓产品。从并行数据库系统ParAccel演变而来，Redshift可以说是个真正的数据仓库系统，作为一种服务提供。Redshift使用了一个经典的 shared-nothing架构。因此，在可伸缩的同时，添加或删除计算资源需要重新分配数据。相比之下，Snowflake的多集群共享数据体系结构允许用户在不移动数据的情况下，立即从存储中独立地放大、缩小甚至暂停计算，包括跨孤立计算资源集成数据的能力。另外，遵循纯服务原则，Snowflake不需要物理调优、数据整理、手动收集表统计信息，也不需要用户进行表清理。尽管Redshift可以将JSON之类的半结构化数据作为VARCHAR来接收，但Snowflake对半结构化数据具有本地支持，包括列式存储这样重要的优化。

Google的云平台提供了一个完全托管的查询服务BigQuery，这是Dremel的实现。BigQuery服务允许用户快速在数TB的数据上运行查询，并在数千个节点上并行化。Snowflake的灵感之一是BigQuery对JSON和嵌套数据的支持，我们发现这是现代分析平台所必需的。但是，虽然BigQuery提供了一种类似SQL的语言，但它与ansi sql语法和语义有一些基本的偏差，这使得它很难与基于SQL的产品一起使用。此外，BigQuery表只能追加数据，需要schemas。相比之下，Snowflake提供了完整的DML（insert、update、delete、merge）、ACID事务，并且不需要对半结构化数据进行schema定义。

Microsoft SQL数据仓库（Azure SQL DW）是Azure云平台和基于SQL Server及其分析平台系统（APS）新添加的服务应用。类似于Snowflake，它将存储和计算分开。计算资源可以通过数据仓库单元（DWU）进行扩展。但是并发的程度是有限制的。对于任何数据仓库，并发执行的查询的大数量是32。相比之下，Snowflake通过虚拟仓库可以完全独立地扩展并发工作。Snowflake用户不需要分发密钥和管理其他任务。尽管Azure SQL DW确实支持通过PolyBase对非关系数据进行查询，但它不支持类似Snowflake对半结构化数据的VARIANT类型和相关优化。

文档存储和大数据。MongoDB、Couchbase Server和Apache Cassandra等文档存储近年来越来越受到应用程序开发人员的欢迎，因为它们提供了可伸缩性、简单性和灵活的schema。然而，这些系统的简单key value和CRUD（create、read、update和delete）的API带来的一个挑战是难以表达更复杂的查询。我们看到了一些类似SQL的查询语言的出现，比如用于Couchbase的N1QL或用于apache cassandra的CQL。此外，许多“大数据”引擎现在支持了对嵌套数据的查询，例如Apache Hive、Apache Spark、Apache Drill、Cloudera Impala和Facebook Presto。我们相信，这显示了对schema-less和半结构化数据的复杂分析的真正需求，而我们的半结构化数据支持正是受到许多此类系统的启发。通过使用schema推测、乐观转换和列存储，Snowflake将这些系统的灵活性与面向列的关系数据库的存储效率和执行速度结合了起来。

六、经验和展望

当Snowflake在2012年成立时，数据库方面完全专注于Hadoop上的SQL，在短时间内出现了十几个系统。当时，决定朝着一个完全不同的方向努力，为云构建一个“经典”的数据仓库系统，似乎是一个冒险的举动。经过三年的发展，我们相信这是一个正确的。Hadoop并没有取代关系型数据库，而是对它们进行了补充。人们仍然想要一个关系数据库，它需要更高效、更灵活，更适合于云计算。

Snowflake实现了我们的希望，即为云构建的系统可以为其用户提供一些功能。弹性的多集群共享数据体系结构改变了用户处理数据任务的方式。SaaS模式不仅让用户很容易试用和采用该系统，而且极大地帮助了我们的开发和测试。通过单一的生产版本和在线升级，我们能够发布新功能、提供改进和修复问题，比传统开发模式下的速度要快得多。

虽然我们希望半结构化扩展被证明是有用的，但我们对采用的速度感到惊讶。我们发现了一个非常流行的模型，在该模型中，组织将使用Hadoop实现两个功能：存储JSON，以及将其转换为可以加载到RDBMS中的格式。通过提供一个能够高效存储和处理半结构化数据的系统，我们发现Snowflake不仅取代了传统的数据库系统，而且还可以取代Hadoop集群。

当然，这不是一次无痛的旅行。虽然我们的团队拥有超过100年的数据库开发经验，但我们在开发过程中确实犯了一些完全可以避免的错误，包括一些关系运算符的早期实现过于简单化，没有在引擎的早期集成所有数据类型，对资源管理的关注不够早，全面的日期和时间函数功能的延迟推出。同时，我们对避免调优的持续关注引发了一系列工程挑战，终带来了许多令人兴奋的技术解决方案。因此，如今，Snowflake只有一个调优参数：用户想要多少性能（并愿意为此付费）。

虽然Snowflake的性能已经非常有竞争力，特别是考虑到没有调优方面，但是我们知道有很多优化我们还没有时间去做。但有些出乎意料的是，对我们的用户来说，核心性能几乎从来都不是问题。原因是通过虚拟仓库进行弹性计算可以提供偶尔需要的性能提升。这使我们把发展方向集中在系统的其他方面。

我们面临的大技术挑战与SaaS和系统的多租户方面有关。构建一个能够同时支持数百个用户的元数据层是一项非常具有挑战性和复杂的任务。处理各种类型的节点故障、网络故障和服务支持是一场永无止境的战斗。安全性一直是并将继续是一个大话题：保护系统和用户的数据免受外部攻击。维护一个每天运行数百万条查询的数百个节点的实时系统，会很有成就感，同时也需要一种高度集成的开发、操作和支持的方法。

Snowflake用户继续向系统抛出越来越大、越来越复杂的问题，会决定系统的发展。我们目前正致力于通过提供额外的元数据结构和数据重新组织来提高数据访问性能，重点是小化或无用户交互。我们继续改进和扩展核心查询处理功能，包括标准SQL和半关系化数据结构的扩展。我们计划进一步改进倾斜处理和负载平衡策略，其重要性随着用户工作的规模而增加。我们致力于简化用户的工作管理，使系统更具弹性。我们致力于与外部系统的集成，包括数据高频加载等问题。

Snowflake未来面临的大挑战是向全自助模式的过渡，用户可以在任何阶段注册并与系统交互，而无需我们的参与。它将带来许多安全性、性能和支持方面的挑战。我们期待着这种功能的实现。

来源 https://zhuanlan.zhihu.com/p/366611048