卷首语：“上云”到底改变了什么？
作者：耿立超
随着对云计算的深度应用，很快我们就会发现，上云所影响的并不仅仅是基础设施，上层应用系统的架构在基础设施“服务化”的影响下，也慢慢进化出了一些云上特有的架构模式和最佳实践，这些模式和实践在自建（on-premises）场景下并不适用，或效果不够显著，但是在云上则显示出了强大的威力。
本文，我想针对数据平台的架构设计，选择最具实质意义与深刻影响的几个方面分享一些个人观点。
存储与计算分离
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 等资源配置工具针对不同应用场景、不同用户制定资源分配策略，由于多场景叠加多租户，使得资源分配策略异常复杂，集群资源的整体利用率很难达到较高水平。
在实现存储与计算分离之后，“多集群”策略可以轻松解决上述问题，也就是面向特定应用场景和租户创建专职集群，针对使用场景进行最佳配置，同时，租户之间也实现了绝对的资源隔离。由于数据与元数据是共享的，且如前所述，创建集群可通过命令行一键完成，所以创建多集群的成本几乎可以忽略不计。
多集群策略可以有效地分解企业级架构上的复杂性，是应对复杂数据生态的强力措施。
“无服务器”架构
Serverless 服务是指那些在基础设施之上进一步将程序运行环境也虚拟化的云产品，使用 Serverless 服务，用户既不需要搭建服务器，也不需要构建运行应用所需的系统环境，他们只需要做一件事：编写代码。
Serverless 是一件美好的事吗？不同的用户态度可能会大相径庭，这取决于团队自身的背景和对云计算的拥抱程度。Serverless 的哲学在于“把精力用到最核心的问题上”，喜欢 Serverless 的用户会对其赞不绝口，因为它确实将团队从基础设施和运行环境的维护上彻底解放了出来，使得团队可以集中精力交付更多的开发任务。但是也有技术人员会对 Serverless 持一种轻蔑态度，认为这种服务只适合开发简单的应用，或者只有技术实力不强的团队才会选择。
对于后者我们不予置评，但是对“Serverless 服务只适用于中小规模开发”的言论，需要谨慎看待，从我过去接触到的大量企业用户来看，得出该结论的原因很有可能是对所使用的 Serverless 服务了解不深造成的。大部分初级用户是通过 Serverless 服务的控制台页面编写和调试程序的，这种图形化界面使用起来非常简单，在很短时间内就可以有所产出，这也是很多团队喜欢 Serverless 的原因之一，但是基于图形化界面进行开发有着无法克服的弊端，包括：代码缺乏版本控制，无法多人协作开发，程序规模变大后难以维护等等，这些并不是 Serverless 本身的问题，而是基于 Serverless 的开发没有进行“工程化”导致的。人们会将这些问题错误地归结到了 Serverless 上，进而得出了“Serverless 服务不适合大规模开发”的结论。
关于 Serverless 项目的工程化，我们有过很好的实践经验，通常 Serverless 服务都会提供 CLI 与 API 用于部署和运行程序，这些 CLI 与 API 与用户界面上的操作是等价的。一个非常好的做法是基于这些接口将部署和运行等操作编写成自动化脚本，脱离对用户界面的依赖，然后将这些脚本和程序代码一起组织成一个工程项目，放到 Git Repository 上，这样就可以对程序代码进行版本控制了，然后再利用构建工具打包，并通过 DevOps 工具自动化部署，这样一个 Serverless 项目就转换成了一个常规项目，可以复用所有常规项目的开发流程与规范，构建大规模 Serverless 项目将不是问题。
目录
热点 | Hot
Databricks 与 Snowflake 创始人开撕：“未来十年数据仓库要么不存在要么大变样”
理论派 | Theory
Service Mesh 终极指南（第二版）：次世代微服务开发
推荐文章 | Article
为什么 Netflix“永不宕机”？
从软件历史看架构的未来：编程不再是精英们的游戏
观点 | Opinion
Rethink：为什么微服务没有 sidecar 不行？
抛弃 Hadoop，数据湖才能重获新生
评论