日前，火山引擎 E-MapReduce（简称“EMR”）正式上线无状态集群能力，由此拉开从云上 EMR 向 EMR Stateless 进化的新序幕。
大家都熟悉，开源大数据平台最早部署在传统 IDC 中，后随着云的普及，发展成为云上 EMR，如今，在技术进步和用户需求的双重驱动下，火山引擎率先提出了 EMR Stateless 的理念。
EMR Stateless 是什么，符合未来的趋势吗？EMR Stateless 的核心价值是什么？实现 EMR Stateless 的难度有多大？带着这些问题，笔者采访了火山引擎 EMR 研发负责人，答案渐渐清晰。
技术进步的根本动力源自用户需求，从自建 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 主张按需创建、按量付费，火山引擎测算大约能帮助用户节省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 是一个系统性的工程，背后涉及的产品、技术改造非常复杂，包括火山引擎目前也还是边推进边迭代，预计今年内实现 Metastore 服务、History 服务、日志服务、指标服务、配置服务的完全商用，支撑用户达到小时级别的生产能力。
难在哪？状态元素的抽离，因为状态种类多，而且每个状态的抽离又涉及诸多层面。就状态而言，Metastore 服务、History 服务、日志服务、指标服务、配置服务、调度服务、用户服务、权限服务等大大小小十几项，每一项的剥离都是一个复杂且考验能力的系统性工程。
以 Metastore 服务为例，云上 EMR 默认一个进程服务于一个集群实例，当将其从集群剥离到外部进行服务化部署后，需要同时考虑不同集群多达数十个引擎的类型和版本，需要逐一对其进行功能适配和兼容改造。
与此同时，抽离 Metastore 服务还需要考虑隔离性，包括权限的隔离、数据的隔离，以及资源的隔离。除此之外，还需要考虑服务的可用性，剥离之后在一个 Metastore 服务同时服务多个集群的情况下，能否保证服务的连续性。
这里仅以 Metastore 服务举例，对于 EMR Stateless 整体而言，每一个状态元素的抽离都需要考虑如此多的因素，其难度可想而知，需要投入的资源、精力是非常巨大的。因此，没有一定的实力很难在大数据平台这一领域再进一步。
总结全文，EMR Stateless 作为火山引擎提出的理念，站在 EMR 自身视角，是对“On Cluster”形态的极致优化，支撑火山引擎 EMR 迈向更高阶的云原生时代。站在用户视角，EMR Stateless 通过将状态剥离实现轻量化的集群交付，在为用户节约成本、提高资源利用率的同时，也能够让用户从繁重的运维工作中解脱，更加聚焦自身业务，真正做到降本增效，为企业赋能。