文章目录
0 前言
数据仓库这个方向近两年再国内可以说是卷爆天际的一个数据库存储方向，其实也就是将数据库功能完全做到云上面。国内近两年各个有钱又有能力的厂商都在持续投入这个方向的研发，包括阿里云的 hologres，开源的 doris，starrocks，tidb 以及 其他有钱且有人的创业公司；而国外则更是有极度成熟的这个方向的系统为国内数据库从业者人员指出了一条可以财富自由的道路，比如 snowflake 以及 databricks。其中 snowflake 一个对外输出一个数仓产品的公司曾经市值一度超过两千亿美元，即使最近股市行情没有特别好，他们的市值也是超过五百亿美元的。
数据库国产化是国家推出的大潮，在这个大潮下 又有 国外前人的财富指引，投资者们一定是会抓住这个风口。当然，为什么云原生数据库 或者说 数仓存储 技术架构会 对资本有这样庞大的吸引力呢，本文希望通过 snowflake 2016年在 sigmod发表的这篇论文 作为切入点 The Snowflake Elastic Data Warehouse 来做一个学习记录，毕竟了解入门的话还是以最能产生实际收益的系统来进行。
近些年云计算以及云存储的高速发展 让如今的应用软件可以不再受到计算资源和存储资源的限制，而 SaaS(Software-as-a-Service) 模型则能够让用户选择自己能够接受的付费方式来为自己的软件选择合适的存储系统，不像从前应用软件 会和固有成本的硬件绑定起来，这一些成本对于部分 或者 绝大多数用户来说都不是一个长期需求。
所以 snowflake 当时提出了一种新型的数仓架构，能够提供包括多租户，事务型，安全，高可扩展 和 弹性 扩缩容 的 全SQL 支持的系统，这个系统支持存储半结构化数据存储 以及 无模式的数据存储。因为底层存储使用的是Amazon cloud(可能现在会支持多云选择，google 云等)，所以这个系统可以支持 pay-as-you-go 的付费模式，即用户想要用多少计算和存储资源，自己决定即可。大多原始数用户使用数据库的方式都被snowflake 无缝迁移到自己的系统之上，对用户来说，带来的收益就很明显了：比如之前用户使用mysql，自己需要去买固有的硬件服务器去部署，而买下来的硬件资源可能因为mysql 本身的设计 大多数的场景下cpu或者磁盘或者内存 中的某一个场景是用不完的，这种情况下的成本是比较高的，而 snowflake 则将数据库架构迁移到云上，硬件资源被云存储和云计算统一起来对外提供虚拟的计算和存储资源，用户只需要按照自己应用场景的需求买合适的 cpu/内存/磁盘的套餐即可，节省了用户非常庞大的成本开支。
1 基本介绍
snowflake 开发之前先做了一些痛点分析，毕竟当时 Hadoop 和 Spark 这样的大数据平台已经比较成熟了。
痛点来源于三个方面：
- 云平台的出现让 很多软件之前的架构需要重新设计，来更好得利用云平台提供的共享资源池。之前的架构可能是在小型的固有硬件资源的集群上运行，而云平台所提供的可以无限扩张的计算资源和存储资源对旧的软件架构来说是需要更全面的设计。
- 数据形态的变化对 在云上的软件设计提出了更加严苛的挑战。snowflake 希望所用的应用都使用基于云的存储软件，那就有大量且不可控的外部数据来源了：应用程序日志，基于web的应用，移动设备产生的数据，社交媒体应用 以及 物联网方面的应用。而且这一些数据还经常以 无模式(没有特征信息，就是基本的数据流) ，半结构化的数据到达存储端（web应用的json），想要高效得识别并存储这一些数据，旧的软件架构还是无法满足需求。
- 现有的大数据处理平台 像是 Hadoop 和 Spark无法满足以上数据存储的大部分功能和性能上的需求，原因可以参考 UC 大学的三位计算机科学家讨论的文章Big data platforms:What’s next?。
综上原因，snowflake 决定做一个完全基于云原生的数据仓库的系统，支持的核心特性如下：
- 完全支持 SaaS。用户不再需要自己购买物理机器，自己部署，自己运维。只需要将数据利用snowflake提供的工具导入，然后就可以利用snowflake 提供的web ui页面 或者 一些数据库接口(odbc / jdbc) 进行数据访问。任何的底层运维操作以及扩容缩容需求都由snowflake 完成。
- 完整支持关系型数据库的SQL语法 和 ACID 语义。
- 支持半结构化数据存储。支持主流的半结构化数据格式 JSON 以及 Avro 等数据类型的导入。snowflake 会自动识别这一些不同数据类型的导入，用户层是无感知的。
- 对用户无感知的弹性扩容或者缩容。
- 高可用。发生网络分区，集群节点宕机甚至整个数据中心宕机，不会体现在用户的可用性上（这个对工程化的要求可太高了）。
- 数据存储是持久化的。
- 成本低廉。所有存储的数据都是压缩的，用户只需要按照自己应用实际消耗的存储容量以及计算资源付费即可。
- 安全性高。所有存储在云平台的用户数据对云平台本身来说都是加密的，而且端到端的加密传输是贯穿整个云平台的网络传输过程中的。
2 为什么选择 存储计算分离
这一节主要介绍为什么 snowflake 在shared-nothing 的主流架构下 选择了 存储计算分离这样的形态(shared-storage)。
shared-nothing 的架构下存储系统的优势很明确：
- 每一个节点独享 计算资源和存储资源 引入了较为友好的的多表跨节点join过程中的查询性能。
- 可扩展性较强，在存储资源不够的情况下只需要扩展物理机器即可。
存在的问题也很明显：整个系统的计算资源和存储资源拥有较高的耦合度，从而在一些场景下会暴露较为明显且难以解决的问题：
- 异构workload。shared-nothing 能够独享一整个物理机器的计算和存储资源。但是实际用户的workload 却是复杂多变的，比如在 bulkload 场景下会消耗较高的 I/O 带宽资源，而CPU 利用率却会很低。而在复杂查询场景下却会消耗较高的CPU ，磁盘的利用率又会很低。这就导致用户需要自己承担这一些 物理资源利用不充分的成本。
- 集群成员变更。用户可能需要扩容和缩容集群，这种情况下整个集群的数据会做重新迁移（尽可能得保证分布在每一个存储节点的数据是均匀的，减少发生热点的概率），这个过程会对集群有较高的资源消耗，甚至影响用户的可用性。
- 在线升级。在线升级整个集群的 硬件和软件版本，并做到对系统无感知是可行的，但是因为硬件资源之间耦合过于紧密，导致升级其中一个硬件会影响整个节点的可用性，从而间接影响到用户的可用性（升级过程需要对整个集群进行）。
因为shared-nothing 在上面的场景下有很明显的问题，并且会造成用户成本较高，并且会影响用户的可用性和可扩展性。所以snowflake 设计的架构就是独立的 存储和计算。
其中， 计算资源 会通过snowflake的 shared-nothing 引擎对外提供；存储资源则会通过 Amazon S3 提供。为了减少 整个架构过程中的网络传输带宽的消耗，计算引擎 会在自己的本地磁盘上缓存一部分数据（热点场景较为友好）。
Snowflake 将这个架构成为 多集群、共享存储 架构。
3 架构介绍
因为snowflake的产品是非开源的，整个论文中对各层的细节介绍很少，都是一些基本的通用的设计方案介绍。
对于想要深入了解其底层架构细节的同学来说 可能只有通过加入 snowflake 公司 这个途径展开了。
整个snowflake 的多集群和共享存储架构形态如下：
- Data Storage 。最下层的存储层， 使用的是 Amazon的 S3存储表数据和查询结果。
- Virtual Warehouses。这一层snowflake 说是 自己的
Muscle，主要是在一个可以弹性扩缩容的虚拟机组成的集群中调度查询计划。 - Cloud Services，整个系统的
brain。是各个子组件的协调者，其中包含了非常多的子服务 分别用来管理 virtual warehouses, 事务，查询，以及集群的元信息(数据库数据类型、不同用户的加密密钥、使用指标、日志信息等等)。
接下来看看每一个组件的一些底层设计形态。
3.1 Data Storage
snowflake 当时选择使用 AWS(Amazon Web Services) 作为存储层的系统 原因主要有两个：
- AWS 是当时最为成熟的云平台存储服务。虽然，aws 的性能相比于本地存储的性能来说还是会差一些，但是aws 能够成熟得支持一些服务，比如 GET 操作可以读取一个存储在aws文件的部分数据（snowflake的表数据访问能够很好得利用这个特性），这个需求对于其他的 https 服务的系统来说是无法提供这样的需求的。
- AWS 能够提供超大规模的存储池，这能够非常方便得扩展大量用户，而不用受到存储池容量不足的影响（这个时候都想到以后用户高速增长的情况了，还是对自己的有信心）。因为有大容量的存储池的支持，snowflake 就能够为用户提供超大表的join操作。
关于存储层的一些表数据的元信息、事务日志、锁信息 等都会存储在在 Cloud Services 层的 分布式 k/v 存储系统中(貌似是 apple 的 foundationdb，具体论文中没有透露太多)。
3.2 Virtual Warehouses
virtual warehouses 层是由多个EC2 实例集群组成，每一个集群都被称为一个单独的 virtual warehouse。每一个 virtual warehouse 都会有多个work node。用户侧不会和work node直接交互，而是和 VM(virtual warehouse) 按照 T-Shirt sizes抽象出来的服务套餐进行交互(x-small – xx-large)，用户根据自己的需求选择对应的计算套餐即可。
这个页面是注册了snowflake 之后想要创建我自己的 warehose 时可以选择的套餐服务：
3.2.1 弹性和隔离性
VMS 是纯粹的计算资源，这一些集群 可以被做创建、销毁、扩容操作。用户可以根据自己的计算需求 调整VM的大小，甚至在没有查询需求的情况下将所有的 VMs 销毁掉都是可以的。
对于每一个独立的查询请求都会被分配到一个单独的 VM上去执行，不会影响其他的VM 的计算资源。每一个用户可以同时创建多个VMS ，每一个VM 上也可以同时执行多个查询请求。不同的VM可以访问同一个被共享的表数据，访问期间不需要产生数据拷贝。
用户的查询性能可以随着申请的 work nodes 也就是 VMS 个数的增加而增加，原本 4个 worknodes 加载数据需要15个小时，现在申请 32个worknodes 就可以将数据加载降低到2个小时了。
snowflake 利用这种可以弹性的计算资源池，能够极大得为用户节约存储成本，毕竟在 shared-data 的情况下，计算资源才是真正消耗用户成本的。
3.2.2 本地缓存和文件读取
每一个 worknode 都会利用本地磁盘缓存之前读取过的文件对象数据，cache 在 worker node 内部会被多个 worker process 共享，cache 的替代策略是通过简单的 LRU 方式实现的。
当一个query要执行时，有上层(Cloud Service）的query optimizer，对于query要访问的数据，通过consistent hashing将table data files分配到VW的各个worker中，形成一个暂时的share-nothing集群。
注意：这种consistent hashing是lazy的！worker process只确定自己所负责的data files集合，但不会立即去S3获取数据，而是借助LRU的策略，按需读取，逐渐替换掉local cache中的data，因此即使resizing也比较平滑。也就是这个一致性hash 的实现在 resize 的过层不会消耗过多的本地磁盘带宽的资源。
3.2.3 执行引擎
snowflake 所支持的查询能力能够跨越成千上万个节点，扩展性能够保证的情况下用户肯定就会更关注性能了，而snowflake 希望能够为用户提供性价比最高的 SaaS 服务，所以重新设计了自己的 执行引擎，主要特点如下：
- 面向列存储。(压缩 + SIMD指令 + CPU cache 提升效率)
- 向量化执行。（利用小型的流水线提升执行效率）
- Push-based。(避免iterator中那种tight loop，此外可以允许DAG形态的执行计划，一份数据可以推入到多个下游operator)
- 没有transaction 执行的消耗，事务层的处理完全在 Cloud Service层。
- 没有 Buffer pool，内存完全用于对算子的计算。
3.3 Cloud Services
这一层就是为了支持用户设计的多租户层，提供了很多重要的系统管理功能：
- 访问权限控制
- 查询优化
- 事务管理
- table --> files 映射管理 等
1. 查询优化
主要是使用了 Cascades cost-based optimization，细节可以参考这位大佬的文章The Cascades Framework for Query Optimization. 因为保存了足够多的统计信息，所以执行计划的生成会在实际的查询执行过程中才做的，利用充分的指标数据，保证了查询计划的执行性能是完全可预期的。执行过程中同样会收集查新指标信息和节点状态信息，这一些信息会被用来再次进行性能分析，为下一次的执行计划的优化做准备。
2. 并发控制
snowflake 主要的应用场景是AP 型的，基本的workload 形态就是大量的读取，批量插入和更新，也需要一定的事务需求，大多数的事务隔离级别需求还是 SI。所以,snowflake 通过实现SI 隔离级别来实现 ACID 语义。
在SI 隔离级别下，对于一个事务的所有的读请求，只能看到一个snapshot 之前的版本。所以，SI的实现是基于 多版本并发控制(MVCC)来做的，也就意味着 snowflake 需要根据用户设置的snapshot 来保存历史版本数据。
因为 Data Storage 层使用的是 S3，S3的更新特性是 COW ，即每一个 table file 产生变更的话就会生成一个新的文件，同时会生成一个 table version 作为元数据被 Cloud Services 管理起来，从而能够建立一个table file 更新的多版本映射关系。产生的版本映射就天然形成了 MVCC，用于对用户提供 SI 隔离级别。当然 S3 这样的更新方式 仅仅适用于 bukl load/ bulk update，随机更新的性能并不会很好。
3. Pruning
因为底层的 table file 是 immutable 不可变的，所以可以得到每一个文件更加精细的统计数据，利用这一些统计数据来作为数据访问的过滤条件 而不用维护 更为复杂的index。这样，就能够较为轻量得达到减少无用数据访问频率的目的。这一些针对文件的统计元数据 只会在新的文件生成 或者 旧的文件被删除得到更新，更新的频率不会很高，而且统计信息相比于table file的实际的大小来说占用存储空间较低，所以整体的存储和访问的overhead 都比较低。
4 高级特性
SnowFlake 在以上架构的基础上实现了一个引人注目的高级特性，可以说将工业化能力发挥到了极致。这也是snowflake能够在众多竞争对手之间脱颖而出的重心。
4.1 打造出了 企业级 SaaS 服务
Snowflake 支持了标准的数据库访问接口: JDBC, ODBC, Python PEP-0249 以及 各种各样的可以访问数据库的第三方工具和服务： Tableau, Informatica, Looker等。
更重要的是提供了可以直接访问的 web UI 页面，这让用户能够非常方便得在任何地方，任何环境下都能够对自己的数据服务进行查看以及操作（至少出门不用带电脑也能够解决线上问题了）。
4.2 持续高可用
随着 数据分析服务的持续运行在商业任务中变得越来越重要，用户也对持续可用性提出了越来越高的要求，比如服务 跨AZ 场景，出现某一个AZ 宕机 或者 整个集群做软硬件升级，那想要保证整个服务的可用性就需要更多的设计。 snowflake 主要通过如下两个方面进行：
4.2.1 容错能力
大体架构如上：
- 在 Cloud Services 层中的 元数据管理存储 使用了可以跨 AZ 复制的分布式k/v 存储系统 FoundationDB（论文里没有细说），FoundationDB 本身能够保证 跨AZ的高可用。
- 在 Data Storage 层则使用了 S3 shared-data 存储，本身也是能够保证高可用的。
- 对于中间层的 VW (Virtual Warehouses) 来说，其中的 work node 本身都是无状态的，中间如果某一个 worknode 挂掉上层直接做重试即可，而且 virtual WareHouse 设计还是不跨AZ的。
因为 上层和下层都能保证高可用的状态，所以整个系统其实都能够保证跨AZ 级别的高可用能力。
4.2.2 在线升级
snowflake 在在线升级场景提供了持续可用性，所有的服务进程本身都是无状态的，他们状态的表达是通过保存在 Cloud Services 层中的分布式 k/v 存储中。
在线升级过程大概分为如下几步：
- 基于当前服务 部署一个新的服务版本。
- 该账号下的所有用户调度的新的查询请求都会被路由到新的服务版本，对于还在旧版本查询的请求还会继续执行直到完成。
- 一旦所有针对旧服务版本的操作 或者 请求都执行完毕，旧的版本会被下线/标记终止使用。
大体流程如下：
开始调度升级的过程 会先为 除了 Data Storage 层之外（该层是 shared-data ，有自己的服务管理）的所有的服务创建一个新的版本，对于CloudServices 层的应用来说 不同版本的元数据都会存储在 meta data storage中，可以被所有的版本共享。可以利用 FoundationDB的 跨AZ 复制 以及 快速 recovery能力。
在 VM层中，不同的版本可以共享同一个 work nodes 以及 他们的本地 cache。这样，新的版本就不需要重新填充local cache，从而保障了对用户服务的高可用性，并且不影响用户的性能。
这里 snowflake 着重强调了一下 为什么他们想要发布新的版本的时候敢直接线上操作，而不用担心新的版本引入的一些核心路径上的bug。
- 他们内部会有一个 准生产环境，所有的新版本会先在准生产环境执行上下线演练，保证即使出现了关键路径上的bug 也能够快速下线，不影响对用户的服务。
- 他们将上下线的测试做的极为充分，且是自动的，足以保障关键路径的bug 能够在用户发现前下线。
感觉这里好像啥也没说，，，没有详细介绍底层如何去做的这一些测试，不过在线升级升级版版本不影响用户的任何服务 这一点来说确实是细节做的足够到位，在功能完备的情况下就是吸引用户的亮点。
总结
因为论文可能是因为商业化的限制，没有介绍太多的实现细节，但是能够看到 snowflake 作为一款千亿级别的数仓产品成功的因素：
- 充分利用了云基础设施的低成本，弹性 扩缩 的能力。
- 应用部署运维能力 加上多租户特性，极大得降低了服务成本。
- 不追求极致性能，而是利用 VM(vitrual warehouses) 的local cache来加速查询性能，并不是完全通过 S3去查，因为S3是对象存储， 其底层也有 逐层访问的网络 – 内存 – 磁盘，本身 S3不会有很好的性能。
- 极为强调易用性，在注册了一个snowflake的账户之后，能够用最少的选择框 非常快速的创建一套完整的自己的数据访问服务，而且搭配有完备的操作文档。这对用户来说，可是非常影响用户体验的，这方面做好了，能够留下不少用户。
- 对于 半结构化数据 和 无模式数据的导入支持。这样，许多 web 应用的用户可以无缝导入原有数据集到 snowflake。
snowflake 这种完整的存算分离设计对整个数据库存储行业来说影响非常大，基本所有的用户还是希望性能满足需求的情况下尽可能降低存储成本，并且将人力从无休止的运维体系中释放出来，所以目前业界基本所有的分布式数据库底层是 shared-nothing 架构的 ，都会想要做到上云的能力。
当然，shared-nothing 有自己的市场和应用场景（高性能），然而当云上也能选择更高性能的计算硬件和存储硬件的时候，那上云就必然是大趋势了。
