存储与计算分离
Snowflake的成功让业界看到了“储与计算分离”架构的巨大优势 ， 这一架构充分利用了云计算平台灵活的伸缩能力 ， 几乎成为了当前在云上构建数据平台的事实标准 。
【数据平台上云，变革远比想象的深刻】过去 ， 硬件资源的最小粒度是服务器 ， CPU、内存和硬盘之间是紧密耦合的 ， 系统基本是以服务器为单位进行伸缩的 ， 这本是平常不过的事情 ， 但是在云平台上 ， 当基础设施被“服务化”之后 ， 就出现了独立的存储服务(如AWS的S3和阿里云的OSS)和计算服务(如AWS的EMR和阿里云的EMR) ， 这给数据平台的架构设计开辟了新的思路 ， “存储与计算分离”就是最重要的一条架构准则 。
在存储与计算分离架构下 ， 所有数据将统一存放在对象存储服务上 ， 所有计算服务与对象存储服务无缝打通 ， 可以像读写本地磁盘一样读写上面的数据 。 如此一来 ， 计算资源和存储资源就可以在各自的维度上自由伸缩 ， 不再受彼此的制约 。
“无状态”集群
存储与计算分离之后 ， 衍生出了一系列强大而先进的新架构 ， 无状态集群就是其中最“酷”的一个 ， 这种集群在过去自建（on-premises）模式下是无法想象的 ， “无状态”意为着集群可以“即用即启 ， 用后释放” ， 很多云上的高阶用户已经在普遍使用这种模式处理他们的ETL作业了 ， 他们每天会在零时过后的某个时刻拉起一个临时集群 ， 执行所有的daily作业 ， 待全部执行完毕之后随即释放集群 ， 从而将批处理的计算成本压缩到了极致 。
这里需要知道一个技术细节：多数云平台都支持通过命令行或API启动一个集群 ， 所以创建集群的成本（工作量）几乎可以忽略不计（这与本地化搭建一个Hadoop集群是完全不同的） ， 研发团队可以将命令行或API调用写入到工作流中 ， 作为批处理的前置任务 ， 这样就可以实现上述做法了 。
特别地 ， 数据平台如果要实现集群“无状态” ， 还需要解决一个问题：即需要将数据的表结构等元数据以服务形式开放出来供计算服务使用 ， 只有这样 ， 当集群下次重建时才能接续此前的状态继续处理 。 通常 ， 云厂商都会提供与行业主流元数据接口（例如Hive的Metastore）兼容的元数据服务 ， 如AWS的Glue Data Catalog ， 阿里云的DLA Meta等 。
一些团队也会在自建（on-premises）模式下尝试存储与计算分离 ， 通常它们会选择兼容某种对象存储标准（如AWS的S3）的硬件设备作为统一的存储层 ， 将所有数据存放在此类设备上 。 客观地说 ， 这些尝试是值得肯定的 ， 但是在非云场景下 ， 其“收益”并不明显 ， 就是说“看不出好在哪里” 。 因为在自建（on-premises）模式下 ， 频繁地启停集群是非常罕见的 ， 也毫无意义 ， 暂停集群后释放的资源并不能分配给其他系统 ， 除非所有服务器被Kubenetes统一管理 ， 但这就是另一个故事了 。
“多集群”策略
通常 ， 不同的应用场景对计算集群有不同的需求 ， 例如批处理、实时处理以及Ad-Hoc/OLAP查询所使用的组件和配置都各不相同 ， 此外 ， 不同部门、不同团队在使用资源时经常会发生冲突 ， 导致作业阻塞 。 过去 ， 在单一集群模式下 ， 技术团队只能依赖Yarn等资源配置工具针对不同应用场景、不同用户制定资源分配策略 ， 由于多场景叠加多租户 ， 使得资源分配策略异常复杂 ， 集群资源的整体利用率很难达到较高水平 。
在实现存储与计算分离之后 ， “多集群”策略可以轻松解决上述问题 ， 也就是面向特定应用场景和租户创建专职集群 ， 针对使用场景进行最佳配置 ， 同时 ， 租户之间也实现了绝对的资源隔离 。 由于数据与元数据是共享的 ， 且如前所述 ， 创建集群可通过命令行一键完成 ， 所以创建多集群的成本几乎可以忽略不计 。