杂谈 | Snowflake是一种怎样云数据库？
如果说到Snowflake，那就势必得扯出SaaS来了，如果说传统的AWS、GCP、Azure创建出的ECS实例是IaaS的话，那么Snowflake能够做的事情就是在云上再建”云“。
大家都称Snowflake好，那么它究竟好在何处？这样操作优势在哪呢？
如果将这些要存储的数据或文件打个比方视作”车“，那么此时的数据库就形如停车场，而无论你车的”型号“、”大小“、”尺寸“，但是你将不得不考虑于高昂的数据存储成本。
出于节省，人们或许会按照类别来划分，也就是将这辆车，分门别类的拆卸并将同类堆积在一起，如：奔驰的都在一起，奥迪都在一起，轮胎都在一起，机油都在一起，这样按照特定领域划分的来进行存储，各个零部件之间都有自己的领地划分，但是又有系统性的关联。这边也是“关系型”数据存储的原貌，这个大停车场便也就可以称作“关系型数据库”。
关系型数据增长来源于金融行业，大量的数据读写被用来记录相关联的交易，并被及时和准确保存，不同数据库之间也需要建立某种关系便于交叉计算。但此时数据格式比较单一，以数字、文本等结构化信息为主。而这种数据处理形式也就是OLTP（On-Line Transactional Processing | 在线交易处理）而这种数据存储最主要的消耗在于存储。
然而，随着数据用途的多样化，数据格式也更加复杂，包括图片、声音或视频等非结构化类型。就好像停完车，以前用笔把车位编号记在纸上，现在直接拍张照片或录制了视频存放于在手机里。在回到停车场取车，直接将将相册中的视频导入某个应用，便马上得到导航路线。
这时便需要一种能同时保存结构化和非结构化数据的新型存储架构，便是我们熟知的“数仓(Data warehouse)”。这个概念由Teradata公司提出，核心目的就是为了支持日益激增的商业智能分析(BI Analysis)，以及如今复杂的大数据和机器学习等运算。同时，这种数据处理形式就是我们常听到的OLAP(On-Line Analytical Processing，在线分析处理)，主要消耗的是计算(Compute)资源即CPU甚至GPU。
传统数仓仍部署在本地的硬盘内，并且存储的空间远高于计算空间，且比例是固定的。这好比在一个固定的停车场里，存储就是里面车位的数量，计算则是车辆进出的道闸系统。
在数字化的时代，对数据分析的请求开始远超过对存储的需求，导致对数仓的需求激增。但是，对存储和计算的需求并不是同比例增加的，即同一个数据库可能从一分钟被调用数次瞬间增加到数百次，那计算速度就可能成了分析的瓶颈。
好比我们经常在高峰时段停车时，看到道闸出入两边都排着长队的情形——司机缴费和升降道闸杆都消耗了太多时间。
Shared-Disk，是数据存储在同一位置，大家享用同样的资源。这种架构很容易在多用户访问的情况下导致系统崩溃，同时也难以满足高频读写、数据复制与迁移等需求。Oracle Exadata采用了这种传统的数据仓库架构，几乎在延展性和并发性上都落后于时代的发展。
Shared-Nothing，则是近年来更主流的一种做法。系统通过优化规则将资源分摊到各个节点，而每个节点不共享任何数据。这样一来，数据的处理过程就不存在争抢资源的情况，从而提供更有效率的延展性和并发性。像Netezza，Teradata，以及Redshift都采用了这样的架构，这也是Hadoop工作的基本原理。
但是对于Shared-Nothing这种架构，对数据仓库应用来说有独特的问题，那就是节点资源，却没有将存储和计算分开。举个例子，当升级或者扩容发生时，系统需要重新分配节点资源，那么数据本身就会面临大量的迁移。这样的操作不仅费时费力费钱，也会大概率降低甚至暂停数据的查询功能，给终端用户造成使用上的影响。
Snowflake在其中做出几个至关重要的改进：
Snowflake在Shared-nothing的基础上提出了Multi-cluster, shared data的概念。这种架构的关键在于将存储和计算彻底分离，从本质上解决了传统架构的痛点。
1、存储层（Storage），存储层目前支持AWS S3和Azure Blob，以及Google Storage。所有数据在存储层被全部加密以及columnar压缩，最大限度的优化存储效率。理论上讲，存储层可以在无关计算资源的情况下进行无限扩容，所以我们不需要加任何节点就能自动沉淀所有数据，这也是为什么Snowflake也可以作为Data Lake的原因。从表结构上讲，Snowflake将所有表自动划分为接近固定大小的Micro-partition，用以支持更加高级的Time travel和data sharing功能。举个例子，即使对数据库进行了clone，在逻辑上有了两个数据库，而底层的存储仍然只有一个版本。这也很好契合了数据仓库在并发性上的业务逻辑。
2、计算层（Compute），计算层由诸多Virtual Warehouse组成，其本质就是处理数据的虚拟机节点。Snowflake很贴心地用T-shirt尺寸定义了算力，相比较其他云计算资源，极大地简化了Provision的过程。由于计算层独立于存储层存在，我们可以想象出很多传统架构中遇到瓶颈的应用场景。譬如可以随时提高或降低计算资源以应对需求，可以在搬运数据的同时进行查询，可以给各个LOB提供合适的资源并独立出ETL和DevOps的处理需求。而最令人兴奋的是，这些不同计算资源看到的都是同一版本的数据。
3、服务层（Services），服务层的独立是另一个让Snowflake走在正确道路上的原因。它由众多Global Services组成，涵盖了我们传统意义上数据仓库的诸多Admin任务，包括operation，management，optimization，tuning，security，availability，metadata，caching等。这一层还有Transaction Management这个重要的使命，对所有计算层的Virtual Warehouse进行管理，保证不同的数据处理请求被高效稳定地应用在存储层的同一数据上。服务层解决了数据仓库易用性的问题，目前我还没有看到任何一款数据平台产品能够帮用户处理这么多的非功能性任务。即使是同为云数据仓库的Azure Data Warehouse，需要的管理和运维成本不可同日而语。
同时从价格上来看，各个层次的部件都是采用的粒度计费，相较于原市面主流Shared-Nothing的做法，无论是在于直接使用的过程种，还是对于企业未来长效性发展的拓容阶段发展都有着无与伦比的优势。
同时驱动了几大核心公有云服务商去直冲Snowflake发展而不是制约的重要原因之一是，它的底层采用了自己的公有云的存储，即数据回归了AWS S3，Azure Blob和GCP Storage。
形象点来看，未来趋势是Multi-Cloud，也就是说尽量不把鸡蛋放一个篮子里，用来分摊技术和商业的风险。Multi-Cloud解决方案的关键就是要Easy to migrate，如果微软只想着防守，那客户就永远不能从AWS转到Azure上，相反，提供Snowflake on Azure，就是给AWS客户转化的机会。
顺掐一手瓜，Snowflake的两位创始人是从Oracle里走出来的，而如今却丝毫没有要加入对甲骨文云对象存储支持的意思，这可以说是Oracle在云计算大厂面前是多么的瘦小呢，哈哈哈。
当然，对于Snowflake更加深入的理解可以去YouTube上看看Zero to Snowflake in 90 minutes。
信息参考：
知乎 —— Snowflake：数据仓库的终极形态？
智通财经 —— Snowflake(SNOW.US)超越的不是AWS，而是SAAS
Youtube|Snowflake —— What is Snowflake's Data Cloud? | Snowflake Inc.
Youtube|YC TalkTalk —— Snowflake (SNOW) 基本面分析
不错