数据平台上云，变革远比想象的深刻

Posted 2023-02-27 Laurence Geng

版权声明：本文由本人撰写并发表于InfoQ官网以及公众号 https://www.infoq.cn/article/5t7w9H3LXSEujo1PCSIZ，本文版权归人个所有，未经许可不得转载。

“戒备”与“偏见”

几年前，我所在的一家传统行业的头部企业启动了一系列数字化转型项目，在配套的IT基础设施建设上，“上云”已是大势所趋。

在此前数年的工作中，我断断续续地使用着公有云产品，大多数情况下，我们只选择IaaS层级的服务，也就是只使用虚拟实例，对PaaS和云平台特定的Serverless服务敬而远之。作为一名架构师，我对公有云的此类产品一直怀有一种“戒备”心理。

一方面，从技术发展路线上，不管是个人还是团队，我们都希望学习并使用行业主流且平台中立的技术，这些技术大多数都是开源的，有着活跃的社区和良好的周边生态，包括高质量的文档，丰富的技术专著，以及互联网上大量的讨论文章等等；另一方面，从公司角度出发，我们也不希望企业与某一朵云深度绑定，这似乎总让人缺少一种“安全感”。

此外，对于还没有准备好拥抱云计算的技术人员来说，上云会给他们带来一种危机感：“既然你都已经做的这么好了，那以后还要我做什么呢”？这一感受最初产生于IT的基础设施团队，之后系统架构师也会有些许同感，这也是很多PaaS和Serverless服务“不受欢迎”的原因。但对于云厂商而言，由于这类服务的利润率更高，他们会更加热衷于推荐此类服务，这会让本已十分敏感的用户更加警惕，以至产生抗拒心理。

回到公司的数字化转型项目，在听取了多方意见之后，公司决定仅使用虚拟实例构建应用系统和数据平台，尽可能避免深度介入平台特定服务，甚至连非常基础的对象存储服务也没有采用。我们数据团队负责构建大数据平台，在一批虚拟实例上搭建了一个Hadoop/Spark集群后，就开始了长期的数仓建设工作。

之后，随着数据规模的不断上涨，集群也经历过几次扩容，得益于Hadoop集群管理工具和自动化运维工具的支持，每次扩容倒也不算麻烦。当时，我们对基础设施的总体状况是满意的：“你总得维护一堆机器，然后定期扩容，哪个系统不是这样呢？”

“上云”改变了什么？

几年后，机缘巧合，我去了一家业界知名的云计算公司。所谓“食君之禄，忠君之事”，入职后，我必须广泛而深入地学习这家公司的云产品，这些产品既有基于开源产品封装的“云化”版本，又有深度定制的PaaS和Serverless服务，这些产品都借助云平台的虚拟化能力，将动态伸缩与可维护性做到了极致。

随着对云平台和云系统架构的深入学习和应用，我开始越来越清晰地认识到，由于过去对云计算固有的偏见，阻碍了自己正确看待云计算对系统架构和开发模式带来的深刻影响，在走访了大量公有云企业用户之后，我真切地感受到了云之所以成功和必将成功的“关键”。

大多数用户选择上云的初衷是希望减轻在IT基础设施上的负担，避免在机房建设，网络规划和服务器采购上一次性投入大量资金，并且还将继续在后期投入资源去管理和维护。

随着对云计算的深度应用，很快我们就会发现，上云所影响的并不仅仅是基础设施，上层应用系统的架构在基础设施“服务化”的影响下，也慢慢进化出了一些云上特有的架构模式和最佳实践，这些模式和实践在自建（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项目将不是问题。

云计算 VS. 开源生态

我们已经说了很多云计算的“好”，最后回应一下对云计算与开源生态相左的“担忧”，从目前的行业态势来看，主流云厂商其实早已认识到这个问题，并在产品设计上努力向开源标准靠拢。只有使用行业广泛认可的技术，云计算才有活力，也才能缓解用户对云平台绑定的担忧，进而吸引更多的用户向云上迁移。

在数据领域，各主流云厂商都有基于Hadoop、Spark等主流开源大数据产品封装的“云化”版本，与Cloudera的CDH类似。同时，很多Serverless服务也大多基于主流开源产品封装，或者保持一致的编程接口，例如AWS的Glue就是基于Spark的Serverless服务，编程接口与开源Spark一致。

总的来说，云计算与开源生态不是也不应该是对立的，一方面，云厂商有向开源生态靠拢的商业驱动力，另一方面，有能力的云厂商也应该积极回馈开源社区，一起营造更好的双赢局面。

一点展望

由于过往的独特经历，我先后经历过“半云”，“全云”以及“非云”等多种环境，真切地体会到了云计算对数据平台的深刻影响，当今的数据平台建设，“云上”和“云下”已经几乎是两个赛道了，如果以个人的一点浅见展望一下的话，我认为上云是不可逆转的趋势，在云上构筑数据平台是未来绝大多数企业的首选。