什麼是瞬态叢集？解讀火山引擎EMR Stateless 的創新理念以及應用

作者 | 火山引擎EMR團隊

衆所周知，基于 Hadoop 的 EMR 體系發展到現在，經曆了很多個階段。從基于 IDC 機房通過 CDH 去部署的 1. 0 階段，演進到在公有雲上面按照存算分離的辦法去進行的 2. 0 階段。

而在這些基礎上，火山引擎數智平台 VeDI 的 EMR 團隊又探索出了無狀态的 EMR 3.0 演進階段。上個月底，火山引擎 EMR 正式上線瞬态叢集新功能，該能力基于業界領先的 EMR Stateless 理念，可以實作叢集級别的彈性伸縮，即無業務需求時釋放叢集，有業務需求時再拉起叢集，進而幫助企業大幅降低産品使用和平台運維成本。

什麼是瞬态叢集，什麼是 Stateless 理念，本文從基礎概念、架構體系、演進過程、實際運用場景&使用價值等多個角度全方位介紹 EMR Stateless 的創新理念以及應用。

什麼是 Stateless？

Stateless——它的本質是一個瞬态叢集的概念，但又不完全是瞬态叢集，它屬于一個輕量級傳遞的、無狀态的瞬态叢集。那無狀态的瞬态叢集又是什麼意思呢？

首先，Stateless 的叢集是在存算分離的基礎上，進一步演化而得來的一個瞬态叢集。普通的存算分離叢集，像 Hadoop 體系裡的相關内容都是綁定在叢集中的，沒有徹底将這些有狀态的内容剝離出來成為一個獨立的服務。而 Stateless 是把 Hive Metastore 以及 History Server 等進行了服務化，也就是從計算叢集中把它們剝離出來了。

在 Stateless 的加持下，我們所指的 Hadoop 體系中的 Master、Core、Task 等節點就組成一個無狀态的輕量級瞬态叢集，可以被随時建立或釋放，并擁有多個副本，這無疑可以讓叢集具備一個更好的擴充性。基于此，接下來就能夠在雲原生的基礎上，以叢集的視野，去更好的做能力的成長以及成本的優化。

接下來，為大家對比一下 Stateful 模式和 Stateless 模式，它們兩個之間有什麼典型的差異點？

左邊這個流程圖，是一個傳統的 Stateful 模式。

在這個模式下，大家要送出一個任務的資料流程通常是這樣的，首先必須要有一個長時間運作的叢集，有了叢集以後，再将任務送出上去，接下來無論是通過 IO 的直接傳回，還是把資料寫入到 HDFS 或是對象存儲，執行結束後都将拿到曆史結果。

站在大資料維護視角來看，在送出任務的流程結束以後，運維長時間運作的叢集，無論是對它的運作狀态進行監控，看看它是否出現了故障，還是對它存在的服務進行日志采集，這些動作都會産生一定量的運維成本。同時，在任務結束後，這些叢集事實上變為了一個空置的叢集。站在總成本承受的角度上來講，這其實是一個不利的選項，以上就是典型的Stateful模式。

而在 Stateless 的模式下，這一切就會有所變化。

首先，操作的第一步直接變為了送出任務。在送出任務以後，叢集會被及時地、按需地建立出來用于運作任務。當任務運作完成以後，叢集将會被釋放掉。在使用者拿到計算結果之後，意味着整個的任務送出過程随之結束。

在這個過程中，由于 Stateless 已經把具有狀态屬性的，像日志服務之類的功能外置于叢集。在叢集釋放以後，使用者仍可以通過日志服務查詢到任何一個時間段内，在 Stateless 叢集模闆下面的叢集裡執行過的任何一個任務結果。

在這樣的流程中，使用者是不需要去運維執行叢集的。這就是 Stateful 和 Stateless 最大的不同點。

看了以上的内容，大家肯定會産生一些問題，有一些概念性的普遍問題，在這裡可以先跟大家講解一下。

1.Stateless 跟 Serverless 的差別？

首先，Serverless 相比于 Stateless，其實就是全托管和半托管的差別。在半托管的情況下，使用者需要自我的去運維一些叢集資源以及叢集配置相關的内容，而在全托管的情況下，使用者可以省去這部分的配置，但是也會失去了一些自定義配置叢集的靈活性。

而 Stateless 其實是處于一個半托管的場景下面，基于 on cluster 形态的雲原生優化體系，它和 Serverless 這種全托管的形态是沒有什麼本質聯系的。它們相似之處，是在對資源的使用上面都比較充分，隻有在執行任務時才會有計算資源存在。

2.Stateless 瞬态叢集，瞬态怎麼了解？

關于這個問題，更深層次的一個點就是瞬态，達到怎樣一種時間粒度才叫瞬态？

首先，我們來對比一下瞬态叢集和普通的雲上 EMR 叢集。普通 EMR 叢集是長時間部署的，可能會部署一周兩周，甚至一個月兩個月的時間。而瞬态叢集是當有任務到來時，我們為這些任務建立一個叢集，任務運作完就把叢集釋放掉。

同樣的，在第二次建立的時候，就可以直接進行一個類似複制的操作，叢集的配置和規格和之前都是一緻的。對使用者來講，做到這個程度是沒有任何代價的。使用者隻需要去定義這個叢集，Stateless 就能按需建立出這樣的一個瞬态叢集，并且這個瞬态叢集的時間粒度是分鐘級的，無需考慮間隔得太久會發生什麼錯誤。

3.Stateless 它适合哪些業務場景？

基于我們的實踐場景來談，首先它适合需要存算分離的使用者，并且更适合離線跑批的場景。計算量比較大，并且具有明顯的潮汐性質特征時，在節約成本上面的展現是非常明顯的。

4.Stateless是否需要使用者改變使用習慣？

在使用者使用方面，并不需要對流程進行改變。Stateless隻是在雲原生管控層面進行了優化，并且是在無狀态服務剝離層面的優化。對于使用者接口，無論是開源的 web UI還是開源引擎的對外接口，任務送出流程無任何變化，這些完全都是開源相容的，大家可以一直享受開源社群版本疊代所帶來的技術紅利。

Stateless 大資料體系

了解完以上内容，大家應該對 Stateless 有一個初步的認識了，接下來再給大家介紹該體系是怎麼實作的。

首先，在 Stateless 的架構體系裡，使用者叢集包含了離線分析（Hadoop 體系）、實時計算（ Flink 體系）、互動式分析、 NoSQL 資料庫以及機器學習等相關内容。這個是帶有計算特性的叢集中，所有帶有狀态部分的内容都被剝離了。Stateless把 History Serverhe 和 UI 相關的内容都剝離成為獨立服務，包含 Spark History Server， Presto History Server， YARN Timeline Server 等。不管叢集是否存在，這些服務都在。

其次，通過 Open API 做了統一的排程和開發封裝。同時将 EMR Studio服務化（ EMR Studio可以了解成類似于 Oozie、Airflow、 DolphinScheduler 等的排程引擎）。使用者可以在火山引擎 EMR 上面直接使用這些服務，而不需要通過送出機器來部署。

依托于火山引擎豐富的雲上生态，Stateless 還可以無縫對接資料研發類産品。除此以外，EMR 中繼資料，包括 Hive Metastore 内置中繼資料庫、外置的 RDS 等，也被抽取到統一的服務裡。相信使用過 Hive Metastore 的小夥伴，肯定沒有少被 Metastore 的 RDS 給坑過，RDS 有個風吹草動，那麼 Hive Metastore 就會有問題，但這些問題現在都可以被雲原生服務有效解決 。

同時，配置中心也對叢集做了一層叢集，如叢集配置、所需元件等，都會以虛拟形式存儲。同時，引擎的中繼資料做了服務化，包括權限管控、使用者體系等。

最後，Stateless 解決了非常困擾運維的一個問題——日志把本地磁盤寫滿。在 Stateless 體系下面不會再有這樣的問題，通過 TOS 對象存儲，日志都是落在一個按需的對象存儲上面。對象存儲可以被認為是無限大的，是以無需為它所占的磁盤空間去擔心，隻需要去定義好它的生命周期，這個問題就能被解決。

上文提到了 Stateless 基礎的大資料體系，現在就進入一個環節，在狀态流上用一個 case 為大家講解一下剛才的體系。

首先，從上圖可以看到，虛線框框住的就是 Stateless 從實體叢集裡抽象出來的，像中繼資料服務、管控服務等一系列服務，有 Web UI，也有 Open API。這些 Open API 會作為控制叢集建立和銷毀的 trigger，相關指令會交到排程平台上，例如 Airflow， DolphinScheduler 等。排程平台在送出任務的時候，會通過接口對叢集的生命周期做一些影響。

其次，再到 trigger 這一層，主要通過雲原生提供的 Open API 就能夠去控制叢集了。如果要送出任務，就會去新起一個叢集，并且對叢集做一個狀态的恢複，這是指任務希望有一個什麼樣的叢集配置。這個配置可能是版本參數，也有可能是一些機型的配置。無論是什麼樣的配置，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 叢集的節點上以外，它還可以作用在整個的瞬态叢集上面。

Hive Metastore 服務上文也有提到過，無論是離線任務的中繼資料也好，或者是對實時以及實時離線混部，它的中繼資料其實都是可以托管至 Hive Metastore 。

目前，Stateless 已經實作了 Public History Server 一系列的服務。它是可以獨立于叢集實體而存在的，并且在叢集運作的時候，這些作業就會上報資料到 Public History Server 服務。使用者可以直接地通過域名去通路，不用進行綁定 IP 這些比較繁雜的一些環節。

依托于雲上産品生态，Stateless 也更新了日志服務，它基于 OpenSearch，最終資料落地在 TOS 上面。面對資料的丢失，或者是資料磁盤的影響，這些使用者都不需要去考慮和運維，但目前這部分功能還沒有徹底的成熟，還需要一段時間完善。

關于排程服務，我們對 DolphinScheduler， Airflow 等這些具備排程能力的服務也做到了內建，為什麼會去內建這些内容？是因為這些元件會去調建立叢集的 API 任務，會随着排程系統裡邊的任務送出去觸發，Stateless 把這些方法全部都內建服務化，使用者無需自己去部署，可以直接做到一個開箱即用。

最後，把使用者服務化以及鑒權服務化的内容合并分享給大家。第一是使用者的服務化以及使用者權限的服務化。使用者的服務化，就是把 LDAP 內建為統一的使用者管理服務。當然還是保留 LDAP 這一層級的，比如使用者習慣用 LDAP 的 UI ，這些使用者自己操作也沒有任何問題，不用反複操作一個叢集去導入使用者的體系，這是收益最大的一件事。

同理，Stateless 鑒權服務使用 Ranger ，因為 Ranger是 RBAC 的概念，而在 RBAC 的概念上面，Stateless還抽象了 RBAC 的這一層概念，讓使用者可以去做更豐富的權限的一套配置。并且，這個權限和使用者的系統是互通的，做到了一套使用者系統加一套權限，可以覆寫所有的跟使用者和角色權限相關的 RPC 模型，這也是Stateless演進過程中很重要的一個能力。

Stateless 業務價值

最後跟大家分享一下 Stateless 的業務價值。

首先介紹下展現業務價值的一個典型場景——

無狀态叢集是一些什麼樣的叢集？如何把成本做到優化呢？

第一，為使用者建立的無狀态叢集時，所選雲伺服器的機型可能會不一樣。首先它是一個金字塔結構，在最下面一層，首先保證使用者的計算資源。

第二，盡量滿足使用者的計算特性。比如 word count 或者 CPU 密集型的計算用不了多少記憶體，我們會盡量幫使用者節約記憶體的資源，選擇 CPU 和記憶體比例比較接近的機型。

第三，幫使用者做成本優化。兩種計價模型，一種是按需、一種是競價。原則上來講，競價比按需便宜，且因為無狀态叢集時間短，我們會盡量地給使用者選便宜機型。比如說使用者傾向的一個機型無庫存了，怎麼辦？我們盡量在價格以及配置上面選擇跟使用者定義類似的機型，以保證使用者的計算任務是能夠執行的。

最後，做一個簡單的總結，Stateless 都有什麼好處？

首先，其實就是很簡單的按量付費。按需建立，自動銷毀，使用者無需關心叢集的狀态，因為它随着任務總會有的。其次，它永遠處于一個疊代的狀态，大家可以永遠地去享受開源社群版本疊代帶來的一個紅利，因為我們是永遠擁抱開源的，這也是我們火山引擎 EMR 不會放棄的一個初心。

然後就是存算分離和彈性擴充，彈性擴充具有一定先進性，可以在叢集的力度上完成。日志是幂等的且上雲的，随時都能看到，使用者不用對日志有過多的運維。

最後，談到運維，Stateless把有狀态的服務抽取出來，使用者無需再去關心跟叢集服務相關的内容，隻用關心運作計算、計算debug和計算診斷這些方面就足夠了。