从云上EMR到EMR Stateless，什么变了？

日前，火山引擎E-MapReduce(简称“EMR”)正式上线无状态集群能力，由此拉开从云上EMR向EMR Stateless进化的新序幕。

大家都熟悉，开源大数据平台最早部署在传统IDC中，后随着云的普及，发展成为云上EMR，如今，在技术进步和用户需求的双重驱动下，火山引擎率先提出了EMR Stateless的理念。

EMR Stateless是什么，符合未来的趋势吗？EMR Stateless的核心价值是什么？实现EMR Stateless的难度有多大？带着这些问题，笔者采访了火山引擎EMR研发负责人，答案渐渐清晰。

EMR Stateless符合未来趋势吗？

技术进步的根本动力源自用户需求，从自建IDC部署EMR到云上EMR，核心推动力其实就两个，“简化”和“降本”，简化部署流程，减轻运维压力，简化开发者和终端用户的使用难度，借助云的按需弹性能力降本增效。从云上EMR再到EMR Stateless，本质上是“简化”和“降本”的再度演进，以开发者和终端用户需求为核心，进一步增效降本。

为了更好的理解EMR Stateless，这里先简单介绍下自建、云上EMR，以及EMR Stateless三者的异同。 

自建和云上EMR都很好理解，自建就是用户自己建机房、搭平台，搭建和运维都非常复杂；云上EMR开箱即用，省去了建和搭的过程，数分钟就能构建一个大数据平台，按需付费，灵活且节省成本。

EMR Stateless呢？简单来说，就是无状态的EMR集群，低运维的使用形态。无状态是指将EMR集群的状态元素进行了剥离，包括状态Server（如HMS、History Server）、元数据、用户信息、权限配置、服务/作业/审计日志、集群配置、参数调优，以及监控指标数据等，这些状态元素抽离后，用户的集群进一步轻量化，同时可以做到无负担释放和按原状态拉起（即状态恢复）；低运维是指在将这些有状态的Server、数据交由EMR托管之后，用户可以从相关运维工作中解脱，更加专注于自身业务。

瞬态集群是EMR Stateless的核心应用场景之一，相对于长运行集群，瞬态集群能够根据用户的业务需求按需拉起集群运行作业，并在作业运行完成之后即释放。对于作业的数据输出、诊断等状态数据均剥离由集群外部Server承载，允许用户在集群释放之后仍然可以分析和查看，而作业运行期间用户对于集群几乎可以做到零运维。

从自建到云上EMR，再到EMR Stateless，在追求弹性的同时，逐步降低了用户的使用门槛和运维负担，成本优化效果越来越显著。事实上，不断的降本增效也正是数字经济时代下用户的不懈追求，体现在技术端，就是倒逼技术供应商持续的屏蔽技术的复杂性，这一过程没有止境。

Stateless和Serverless有什么异同呢？“On Cluster”是EMR产品的主要形态之一，而Stateless是这种形态下的极致云原生优化。Serverless是另外一种产品形态，在EMR这类产品中，Serverless形态更多的是“On Cluster”形态的一种补充。它们的根本目标都是一致的，即致力于更好的满足当下及未来的用户需求。

EMR Stateless能给用户带来什么？

笼统的说，EMR Stateless能够帮助用户降本增效。具体而言，可以从三个层面来分析，能为企业管理人员省多少钱？能为运维人员减多少负？能为业务人员增多少效？一个一个来看。

管理人员优先关注的肯定的是成本，EMR Stateless主张按需创建、按量付费，火山引擎测算大约能帮助用户节省40%-50%的成本。这其中是如何做到的？核心在于EMR Stateless比云上EMR更灵活，更轻量。

众所周知，云上EMR配置较为复杂，做不到集群收放自如，这使得很多用户尽管只有几个小时的任务，也不得不长时间运行集群，造成很多不必要的资源浪费。而EMR Stateless通过将状态与具体集群剥离，真正做到了分钟级拉起和释放，按需付费。

对于运维人员而言，EMR Stateless通过多个维度帮助他们减负。举几个例子，过去业务人员每构建一个集群，在开始使用之前都需要由运维人员对其进行一系列状态配置以保证其满足业务需求，而EMR Stateless形态下，运维人员需要做的只是为具体集群选择和关联状态即能够快速让集群达到交付状态；技术升级，不同于长运行的集群，EMR Stateless形态下由于状态外置，用户释放集群时没有状态迁移或丢失的负担，可以随时选择最合适的软件栈和硬件版本创建集群，享受软硬件更迭所带来的优势；弹性扩展，EMR Stateless提供多种策略的弹性规则，包括基于时间的，比如在指定时间点扩缩容，基于集群负载的，当某个指标大于设定值时执行扩缩容，基于混合策略的，以及基于集群粒度的，即直接以集群为单位扩缩容；另外，日志、监控指标都是脱离于集群实例存在的，集群释放之后依然可以轻松回放。

换句话说，EMR Stateless运维压力极小，尤其是瞬态集群几乎可以做到零运维，因为它只是在运行作业时被瞬态地拉起，并在作业完成之后即释放。

最后再看使用人员，EMR Stateless之前，无论是自建还是云上EMR，第一步其实都不是提交任务，而是创建集群，这体现的就是效率的差异，而EMR Stateless可以让使用人员更加聚焦业务，从繁重的集群运维工作中解脱。

显而易见，无论是管理人员、运维人员还是使用人员都能从EMR Stateless中受益，无论效率、工作量还是成本都能得到显著优化。特别值得一提的是，EMR Stateless尤其适用于计算量比较大，且具有明显潮汐性质特征的客户，在节约成本方面体现的非常明显。

据悉，目前已有多家客户正在测试火山引擎EMR Stateless的能力，并在成本上获得较大的优化受益，以其中一家客户为例，他们的大数据集群原本部署在IDC机房，业务负载高峰集中在白天的6小时内。该客户搬站上云至火山引擎EMR后，得益于其灵活的瞬态集群能力、计算存储分离架构以及智能分层存储，成本节省能达到40%。

实现EMR Stateless的难度有多大？

既然EMR Stateless能带来这么多价值，最后一部分探讨一下EMR Stateless的实现难度有多大，这关系到未来会有多少产品供用户选择。

直观而言，实现EMR Stateless是一个系统性的工程，背后涉及的产品、技术改造非常复杂，包括火山引擎目前也还是边推进边迭代，预计今年内实现Metastore服务、History服务、日志服务、指标服务、配置服务的完全商用，支撑用户达到小时级别的生产能力。

难在哪？状态元素的抽离，因为状态种类多，而且每个状态的抽离又涉及诸多层面。就状态而言，Metastore服务、History服务、日志服务、指标服务、配置服务、调度服务、用户服务、权限服务等大大小小十几项，每一项的剥离都是一个复杂且考验能力的系统性工程。

以Metastore服务为例，云上EMR默认一个进程服务于一个集群实例，当将其从集群剥离到外部进行服务化部署后，需要同时考虑不同集群多达数十个引擎的类型和版本，需要逐一对其进行功能适配和兼容改造。

与此同时，抽离Metastore服务还需要考虑隔离性，包括权限的隔离、数据的隔离，以及资源的隔离。除此之外，还需要考虑服务的可用性，剥离之后在一个Metastore服务同时服务多个集群的情况下，能否保证服务的连续性。

这里仅以Metastore服务举例，对于EMR Stateless整体而言，每一个状态元素的抽离都需要考虑如此多的因素，其难度可想而知，需要投入的资源、精力是非常巨大的。因此，没有一定的实力很难在大数据平台这一领域再进一步。

总结全文，EMR Stateless作为火山引擎提出的理念，站在EMR自身视角，是对“On Cluster”形态的极致优化，支撑火山引擎EMR迈向更高阶的云原生时代。站在用户视角，EMR Stateless通过将状态剥离实现轻量化的集群交付，在为用户节约成本、提高资源利用率的同时，也能够让用户从繁重的运维工作中解脱，更加聚焦自身业务，真正做到降本增效，为企业赋能。