什么是瞬态集群？解读火山引擎EMR Stateless 的创新理念以及应用( 三 ) _瞬态集群

上面的这个 case，讲的是单独一个任务的提交。但在实践的过程中，往往集群可能会被提交多个任务上来，这种情况下直到所有任务执行完毕，实体集群就会被释放。当集群释放完以后，如果又有任务需要提交了，同理，只需要再去起一个配置相同的集群，再来做任务的执行，执行完了以后再释放。这就是Stateless 体系运转的大致流程。
Stateless 演进过程
理解完概念性和结构性的内容以后，接下来再分享一下 EMR Stateless 的演进过程。EMR Stateless，听上去是一个比较新的东西，我们为什么要这么去做这个呢？

文章插图
在开篇中，跟大家分享了基于 Hadoop 的 EMR 体系的很多个阶段。
首先是基于 IDC 机房通过 CDH 去部署的 1. 0 阶段，到现在仍有不少的用户是基于1.0这个体系在做运营。它也有它的好处，无论加资源还是其他操作，是完全可控的。当然也存在很多问题，比如运维的复杂度很高，并且由于存算一体的架构，闲置了很大的计算资源，没有办法进行按需计算的场景。
基于这些问题，演进出了在公有云上按照存算分离的办法去建设的 2.0 阶段。通过把存储资源和计算资源分开，让计算资源尽量地做到按需分配。当然这也有限制和前提，它的计算资源是按照节点去做弹性的。所以在 2.0时代，它解决的最根本的问题还是一个计算和存储之间的解耦。
但是，火山引擎的 EMR 团队发现 2.0 时代的一些问题，影响到了日常的运维和集群的稳定性。基于这两点，我们首先考虑到了弹性的能力，对集群整体去做一个弹性的伸缩，而做这个的前提条件是要解耦集群和相关的集群元数据，在这些基础上做了集群无状态化，也就是集群服务的剥离。
谈到这里，Stateless的优势其实就体现出来了。首先，Stateless 集群是百分之百不用去运维的，因为它只在运行时瞬态地出现。其次，集群的服务也无需用户去担心，并且它还保留了半托管模式的优点。在经过技术研判和综合判断后，相比起 EMR 1.0时代的IDC机房线下部署模式，使用 EMR Stateless 的资源成本能够达到百分之四十以上的优化。
以上就是EMR Stateless 演进的过程，以及火山引擎EMR团队关于Stateless的考虑思路和历程。
接下来，再跟大家详细地分享一下各个feature是怎么去演进的。

文章插图
首先，存算分离其实是 EMR 2.0 时代的产物。到了Stateless的环境下，首先保留了所有EMR 2.0 里的一些 feature。而在新的这一层上面，最主要的功能就是对负载进行了优化加速，这个可以认为是本地的 local shuffer，这样速度会更快。

文章插图
并且进一步提供了冷热分层的管理，可以直接的去控制和定义冷热分层的行为，这也是成本节约的前提。计算资源已经做到极致优化，所以存储资源上面也需要及时优化。
首先平台会自动地去诊断用户的冷热分层，诊断的前提是什么？从上图中来看，用户在火山 EMR 这一侧的所有读写行为，会经过 Metastore 服务，了解哪些是冷数据，哪些是热数据。
基于用户对表的定义，接下来再做自动化的诊断，并且把这些诊断以及预测，暴露给运维的人员，让他们看到诊断的结果，并且给出平台的建议。再由人工的判断，三位一体的来让冷数据找到自己最终的归宿。在这个话题上面，Stateless提供的冷数据分层层次也是比较多的，从标准到低频，再到归档，再到冷藏，再到最后的删除，能够给不同特点的数据找到最合适的存储点。这个也是Stateless为用户赋能的一个方面。

文章插图
弹性伸缩，这也是演进 Stateless 产生出来的一个重大 feature 。
对于弹性伸缩，主流分成两种，第一种是基于时间的弹性伸缩，比如运维人员知道几点到几点是高峰，几点到几点是低谷。第二种是基于负载指标的一个弹性伸缩，因为可能会有特殊情况出现，比如说在一个时间范围内，数值突然变大或者变小，或者是基于负载情况。
关于这一点，火山引擎 EMR 有独有的设定，可以把时间和负载混合起来用。并且，这样的混合弹性模式除了作用在 Hadoop 集群的节点上以外，它还可以作用在整个的瞬态集群上面。