背景：2020年9月16日，Snowflake成功IPO，交易首日市场估值达到704亿美元，募集资金34亿美元。Snowflake成为迄今为止规模最大的软件IPO，市值最高突破1200亿美元。Snowflake提供基于云的数据存储和分析服务，一般被称为 "数据仓库即服务"，它允许企业用户使用基于云的硬件和软件来存储和分析数据。Snowflake自2014年起在亚马逊S3上运行，自2018年起在微软Azure上运行，自2019年起在谷歌云平台上运行，其Snowflake Data Exchange允许客户发现、交换和安全地共享数据。[维基百科]
Snowflake取得了巨大的商业成功，技术是如何支撑起它的千亿美元市值呢？它技术强在哪？OLAP内核技术爱好者浙川为大家倾情解读Snowflake的核心技术原理。本文为该系列三。
云服务组件
多租户是Snowflake云服务组件非常重要的特点。云服务组件中的每一个组件，例如并发访问控制、优化器、事务管理器等，都是需要能够长期运行并可以被许多用户同时共享的。多租户的特性大大提升了系统的利用率，并且降低了系统的管理开销，相比于每个用户都会独立占用系统资源的传统架构，多租户可以降低系统的整体成本。
为了高可靠性和高可扩展性，每个云服务组件都会有自己的副本。因此，即便某个云服务组件挂掉，也不会导致数据丢失或者服务不可用。云服务组件挂掉可能会导致一些正在运行的查询任务失败，但由于数据没有丢失，Snowflake只需要简单地重新运行这些查询任务就行了。
查询管理与优化。用户的查询请求会首先发送到Snowflake的云服务组件上，云服务组件会对查询进行前期处理，包括查询解析、权限控制、查询计划优化、文件映射等。Snowflake的优化器采用了传统的自顶向下的瀑布模型（Cascades-style）和基于开销的优化（cost-based optimization，CBO）。优化器所依赖的统计数据，全部由Snowflake在数据加载和更新时进行自动统计。由于Snowflake并不支持索引，因此Snowflake搜索计划的空间会比较小。同时，Snowflake并不是在前期解析查询的是时候一并把所有计划都生成好，而是将一部分计划的生成推迟到执行阶段，比如针对join的数据分布计划就是在执行时才产生的。这样设计的优点是可以降低优化器生成低效计划的概率，同时也提升了系统的鲁棒性，而代价是可能查询执行的时候并不能获得极致的性能。更重要的是，这样的设计会使查询执行性能变得更加可预测，进而提升用户使用Snowflake的体验。
优化器产生的计划会下发给该查询对应虚拟仓库的所有计算节点上执行，当计划执行的过程中，云服务组件会持续不断地监测执行状态，统计性能指标并跟踪计算节点的健康情况。这些信息都是后续性能分析和日志审计的重要依据，并通过图形化接口向用户展示。
并发访问控制。Snowflake的并发访问控制也是在云服务组件中实现的。Snowflake的主要负载为分析型负载，分析型负载大多是复杂查询、批量插入、批量更新等。在这样的负载场景下，Snowflake通过ACID事务和快照隔离（snapshot isolation，SI）来实现并发访问控制。在快照隔离的机制下，一个事务内所有的读操作都会统一使用事务开始时的快照，这也意味着一个事务内所有的读操作都会看到同一个版本的数据，同时并发执行的另一个事务内的数据修改操作对这个事务的读操作来说是不可见的。
Snowflake的快照隔离机制是基于多版本并发控制（multi-version concurrency control,MVCC）实现的。由于Snowflake的表数据文件一旦存放到S3上，文件就不可以改变了，因此采用多版本并发控制是一个很自然的选择。在Snowflake中，如果想要修改一个文件，那么只能把这个文件删除，并用新的包含修改内容的文件来替换它。更进一步，在Snowflake中，如果对一个表做了写操作（数据插入、更新、删除），那么会对应产生一个新版本的表，旧版本表的文件都会被删除，新版本表的文件被重新添加进来。当然，除了涉及写操作的数据文件需要进行实际物理文件的删除和替换外，其他文件的删除和添加都是在元数据中进行操作。如前面章节所述，Snowflake的元数据管理就是key-value存储。
除了快照隔离外，Snowflake还使用快照来实现时间追踪和数据对象高效克隆。
剪枝。如何保证某个查询请求只访问和它相关的数据，是查询处理要解决的一个很重要的问题。传统数据库大多都会创建类似B+树索引来支持数据访问。尽管创建索引对于事务处理中的数据访问非常有效，对于类似Snowflake这样的系统来说，索引反而可能会带来很多问题。首先，索引会带来的很多的随机I/O访问请求，这对于采用列式存储（尤其带压缩）和S3的系统来说是一个非常严重的额外开销。其次，索引还会大幅增加实际存储的数据容量，以及增高数据加载时间。最后，索引还会降低用户的使用体验，尤其对于Snowflake来说：用户还需要花额外的时间和精力去主动地创建索引。
对于大规模数据分析场景来说，一个可以替代索引的技术为：min-max剪枝。对于一块数据来说（该块数据可以是一页，也可以是一个文件），系统会单独维护这块数据相关的元信息，其中最重要的元信息是这个块中数据的最大值和最小值。结合查询的过滤条件，这些min-max信息可以被用来判断该数据块内的数据是否会被查询用到。例如，假设数据块1中列x的min值是3、max值是5，数据块2中列x的min值是4、max值是6，那么对于包含where x>=6过滤条件的查询来说，数据块1中的数据肯定不会被用到，数据块2中的数据才会被用到。和索引不一样的是，类似min-max这样的元数据所消耗的空间非常小，而且访问会非常快。需要强调的是，这里的min-max不一定是数值（整数、浮点数）的min-max，还有可能是日期、字符等的min-max。
Snowflake非常适合采用这种剪枝技术：它不需要用户花时间和精力去做额外的操作；它所占空间比较小，具有良好的扩展性，并且易于维护；它非常适合大规模数据顺序访问的场景。另外，加载用来剪枝的元数据性能会非常快，而且分析这些元数据对于查询计划产生和执行来说开销并不大。Snowflake针对每个独立的表文件都会单独维护剪枝相关的元数据，元数据不仅会涉及到正常的关系型数据列，还会涉及到半结构化数据中的部分列。Snowflake会根据查询的过滤条件去检查对应的剪枝元数据，以便最小化查询执行时所需要的输入文件数。Snowflake的剪枝不仅能够处理简单的数值比较过滤条件，还能够处理类似in (5,6,7)这样的复杂过滤条件。除了上述的静态剪枝优化外，Snowflake还能够在执行时进行动态剪枝。例如，当在执行hash join的时候，Snowflake会收集build表数据中有关join键的分布信息，并将这些信息发送到probe表处理端，以便用来筛选和剔除probe表所不需要加载的数据文件。这些方案其实都是对现有技术（如bloom join）的扩展。
随时欢迎技术圈的小伙伴们过来交流^_^：
AnalyticDB详情见：产品详情
AnalyticDB产品试用：产品试用
AnalyticDB知乎公众号：云原生数据仓库
AnalyticDB开发者社区公众号：云原生数据仓库
AnalyticDB开发者钉钉群：23128105
AnalyticDB相关文章：
AnalyticDB MySQL拥抱云原生，强力支撑双十一
智稳双全--AnalyticDB如何助力菜鸟运配双十一
千万商家的智能决策引擎--AnalyticDB如何助力生意参谋双十一
AliExpress智能营销引擎大揭秘-AnalyticDB如何做到快准狠省
十万亿级OLAP引擎解读-AnalyticDB如何支撑数据银行超大规模低成本实时分析
