B站基於Apache DolphinScheduler的一站式大資料叢集管理平臺（BMR）初窺

一、背景

大資料服務是資料平臺建設的基座，隨著B站業務的快速發展，其大資料的規模和複雜度也突飛猛進，技術的追求也同樣不會有止境。

B站一站式大資料叢集管理平臺（BMR），在千呼萬喚中孕育而生。本文簡單介紹BMR的由來、面臨的主要矛盾以及如何在變化中求得生存與發展。

下圖是截至2024年6月初，統計到B站大資料的服務規模：

大資料所需承載的業務種類愈加繁多，為更好地承接業務場景的訴求，同時提升穩定性要求，我們大資料叢集管理平臺的建設，經歷了以下主要幾個階段：

階段一（求生存）

1. 聚焦系統環境標準化、服務配置標準化，清掃野蠻成長過程中非標生產留下的債務（層出不窮的奇怪問題）。

2. 快速和花樣地迭代姿勢，滿足業務高速發展訴求。將各服務的安裝包、配置納入版本管理，服務狀態有效透出，完成狀態管理和分享。同時打通線上業務的門禁管理，快速迭代過程中不失穩定性考量。

（標準化工作嵌入迭代釋出、配置釋出、灰度釋出中，同時支援常用的新增節點、快速部署、節點上下線等能力。管理上支援機器分組、打標、自定義流程、異構配置管理等）

階段二（追溫飽）

1. 建設元倉，打通服務間資料互通，實現問題的快速診斷。
2. 場景化建設，如：機房遷移所需的大批次、持續性專案，故障自愈能力等。
3. 提升覆蓋面，邊緣場景或非高頻變更場景。如：Yarn佇列管理、Lable變更、主從切換、HDFS資料遷移、HMS後設資料管理等。

階段三（奔小康）

1. 擁抱雲原生，擴充容器化管理能力。更好利用在業務內和業務間的資源，實現降本增效。服務混部、潮汐退避 火力全開，追求更高的利用率的同時降低IT成本支出。

2. 建設容量管理，完善服務的異常預警、風險預測、故障自愈，進一步完善叢集自動化運維體系，進一步追趕業務對大資料賦能的預期。

階段四（共富裕）

1. 強化可觀測能力，資料更接近業務視角，自上而下清晰對齊、指引方向。

2. 化被動為主動，從異常監控到故障自愈，再從故障自愈走向故障預測。

3. 極致追求服務質量，度量服務質量、死磕服務質量。

二、面臨的挑戰

接下來，我將在大資料平臺化過程中遇到的典型問題和解決思路分享如下。

2.1、節點一致性問題

在後設資料未閉環聯動的情況下，一致性無法得到保障。B站的大資料叢集當前仍以物理機為主，正在逐步容器化的階段。大資料服務元件繁多，疊加多版本、混合部署、部分容器化等諸多因素，讓後設資料一致性的保障工作更加複雜。在完全平臺之前，還存在指令碼甚至人工操作，狀態的變更無法有效閉環。節點遺漏和資訊錯誤的情況時有發生，輕則伺服器未有效利用，重則叢集服務存在多個版本，留下穩定性隱患甚至直接影響業務生產。

不斷完善覆蓋面和使用場景的同時，一些重要的且短時間未實現資料閉環的場景，BMR在‘智慧運維’模組的‘巡檢’能力，去兜底去發現未知原因產生的髒資料或不一致的問題，讓風險儘早被發現、被幹預、被解決。

2.2、標準規範的制定和實施

叢集標準，需要結合歷史和當前情況來制定，並非設計而來。且實施過程，需要考慮相容、遷移的能力和資源、實施週期等因素。過程中要根據叢集支援的業務特點、環境、版本進行劃分，如：實時叢集、離線叢集（2.8版本和3.2版本）等， 線上存在多個生產叢集。在前期元件服務的部署規範和配置檔案的標準化不足，存在同一叢集內同一元件在不同節點部署環境都存在差異情況。在平衡標準化和差異化的過程中，‘小步快跑’地進行標準化的制定、試執行、修正、公示，技術項的標準最終固化到平臺功能中。

2.3、規模化的管理

當“量變引發質變”和“不必過度設計”遇到“業務飛速發展”時，及時調整管理策略滿足業務發展需求，極具挑戰。

大資料玩的就是資料，硬碟少不了。當前我們的大資料叢集磁碟數量在十萬量級。每天磁碟正常故障超10塊， BMR在‘智慧運維’模組整合了‘硬碟故障自愈’的能力，打通各個平臺的資料和流程，實現業務無感式的換盤。還有作業系統層面的核心管理與升級，在面臨節點數量多、需要無感/無故障的管理，都會對平臺提出更高的要求。

而且在機房資源緊張的情況下，會涉及叢集遷移甚至機房遷移的工作。如何不停機實現遷移，BMR上也都做了適配。

2.4、提升迭代效率

單純提效不難，難的是在複雜場景中保證穩定的前提下。

生產不能停，迭代要繼續，規模同時要滿足發展需要。BMR在建設迭代能力的同時，透過後設資料的管理監測資源容量。本著儘可能地避免問題、儘早地暴露問題的原則，叢集資源做了分層、隔離以保安全，迭代過程也必備了‘灰度’、‘快速回滾’、‘異常探測’以便快速發現和快速解決問題。

同時多叢集、多元件、多角色的‘變更衝突’需要加以限制，變更資訊的‘透明化’和‘快速回滾’利於故障快速診斷與恢復。跨團隊協作中，複用線上業務平臺的通知與協同能力，實現訊息的精確觸達和快速應急響應。

2.5、削峰填谷

降本增效大背景的今天，資源有效利用也不是新話題。大資料業務和線上業務有著天然的資源錯峰潛質，BMR當然不會放過。我們已在2023年實現大資料業務與線上業務的資源潮汐退避，大資料業務白天出讓資源給線上業務使用，線上業務夜間歸還的同時也出讓冗餘的資源給到大資料，實現‘削峰填谷’和‘資源共贏’。

三、平臺實踐

秉著先解放雙手再系統閉環然後貼進業務的思路，BMR（大資料管理平臺）逐步拆招解招。

系統整體架構如下圖所示，BMR主要由叢集大盤、叢集管理、元件管理、變更管控和資源管理功能模組構成。

底層複用公司的‘Job任務’平臺，使用 DolphinScheduler 做邏輯排程。 業務資料和邏輯集中在‘後設資料’、‘配置中心’、‘主機管理’和‘釋出服務’四大模組中，對使用者由‘叢集大盤’、‘叢集管理’、‘元件管理’、‘變更管控’和‘資源管理’來呈現。

產品層本著‘一站式’的思想， 在操作叢集管理時， 使用者只需選擇釋出的元件、對應的主機節點， 及釋出策略， 即可快捷完成變更操作。把複雜的邏輯和後端留給BMR，讓使用者只關心他需要關心的。

  為更好適配不同元件和使用者的使用需求，變更流程設計整體分為節點選擇策略(分批執行)、執行前置操作、排程執行、執行後置操作幾個核心操作,流程示意圖如下:

3.1、叢集管理

為適配不同業務、不同規模、不同網路環境、不同用途的部署方式，同時考慮到開發週期和成本。底層功能模組儘可能的通用、可複用，上層應用區分使用者視角和管理視角。使用者視角僅顯示有許可權的叢集，更多展示檢視、監控類的例項。管理視角則可以快速新增建立並部署叢集。當前我們已經支援瞭如 HDFS、Spark、Flink、ClickHouse、Kafka等叢集管理能力。

3.2、元件管理

• 3.2.1、支援新增元件，檢視元件部署的節點及元件服務的執行狀態

在元件管理視角，我們優先支援了元件的‘增/刪/改’及‘狀態監控’的功能。這裡的難點是不同叢集部署的元件服務， 對應配置存在差異。為更好支援差異化管理訴求，叢集管理平臺支援不同叢集元件的自定義新增、元件變更管理及對應配置等管理需求。

• 3.2.2、支援元件服務的擴容、迭代、縮容等釋出操作

元件的‘擴縮容’和‘迭代變更’基礎能力具備後，上層即可包裝成各種應用需求。同時提供變更視覺化，也支援釋出策略定製。比如：

• 併發度設定: 一次同時變更多少臺節點，當前併發度最高限制200，避免一次同時變更過多，對線上任務造成影響。

• 容錯度設定: 變更過程中失敗節點數到達容錯度後，釋出操作自動暫停，及時告警通知釋出者，並人工介入檢查，是否存在風險。

• 釋出暫停、繼續、跳過錯誤並繼續等釋出控制等。

• 3.2.3、元件配置管理

最早的配置檔案，多數是在git上管理，本地文字編輯。容易出現導致檔案格式、配置項錯誤等問題。也出現過叢集部分執行時配置和磁碟上對應配置不一致問題，和線上節點配置版本無聯動，給問題定位排查帶來風險和困難。

BMR的配置管理，支援版本快照功能，可按照配置項快速檢索，同時在修改儲存時有合法性檢查，週期性巡檢叢集節點磁碟上配置的版本和服務執行生效版本不一致的預警。

3.3、節點管理

不同角度和不同場景，也有對節點管理的需求。特別在差異化管理和問題診斷的場景，以及未閉環場景下的使用。

如：適配硬體配置差異而產生的應用配置差異、不同佇列使用不同配置、不同服務使用不同版本，同時也支援管理檢視節點服務執行情況， 服務版本部署監控狀態等。

3.4、佇列管理

線上Yarn資源排程採用Capacity模式，叢集根據不同部門、任務優先順序等規則會劃分多個佇列資源， 前期透過文字編輯的形式對配置進行修改調整，存在編輯繁瑣、易出錯等問題。BMR為此提供了Yarn佇列的線上視覺化編輯能力， 支援新增、刪減佇列、同時會對佇列資源的capactiy百分比合法性校驗， 也支援佇列配置項調整對全域性或部分佇列生效等快捷操作。如圖示意：

四、技術方案

透過大資料叢集管理平臺化的建設，解決我們遇到的迭代效率、穩定性等問題，主要圍繞叢集管理、節點管理、服務管理、元件管理、節點執行任務等幾個維度進行建設，整體邏輯關係如下：

當前線上存在多套大資料叢集，每套叢集都存在多個元件，在平臺落地的過程中。面對上述提及的問題和挑戰，我能透過元件工作量管理來應對。

4.1、元件流程管控

大資料叢集平臺不同元件管理的核心差異點，在於其變更執行流程差異，基於此我們構建了元件工作流的管理模組，同時支援不同元件的執行流程視覺化配置管理，基於Apache DolphinScheduler框架進行了二次開發， 利用其流程DAG視覺化編輯能力，擴充套件了TaskPlugin適配我們的叢集元件變更管理的業務場景。

4.2、變更影響可控

為了保證變更平穩可控， 減少因為變更帶來的叢集線上任務穩定性問題， 支援以下變更策略:

• 按批次灰度，可根據元件變更影響差異 ，支援自定義每批次變更節點數量， 當前每批次上限200節點。

• 批次之間有序執行，並相互隔離，出現異常僅影響本批次。

4.3、異常節點容錯

• 容錯策略

• 異常重試

• 工作流程執行時， 支援過濾異常錯誤節點

• 支援批次內異常跳過， 繼續執行下一批次

4.4、跨元件依賴和全域性變更

以DataNode節點縮容場景為例，DN涉及資料遷移問題，整個下線流程相對比較繁瑣， 如機房搬遷場景使用Fast Decommission方式快速遷移資料、 節點故障維修場景 透過Decommission方式遷移資料等，整體執行流程如下圖所示：

在DataNode下線流程中，同時涉及DataNode、NameNode元件的變更。縮容操作步驟中存在全域性變更(NameNode節點級別)、部分變更(DN節點即便)、阻塞等待等互斥操作。

針對這種複雜變更場景， 透過支援DN下線流程巢狀子流程，來操作不同的變更物件。透過子流程方式我們可以對所需的依賴元件同時進行變更， 可方便快捷進行操作。

五、未來規劃

• 降本：深化資源利用率提升，進一步榨取運算資源。

• 提效：增加故障自愈和故障預測的覆蓋面，降低風險的同時減少人力投入。

• 穩定性：大資料元件眾多，繼續提升覆蓋率，將標準化和迭代可控堅持到底。

• 穩定性：把控容量的可觀測性，將功能之外風險拒之門外。

• 服務質量：建立服務質量管理體系，指引技術改進與服務質量提升。

-End-

作者丨國輝

本文由 白鯨開源 提供釋出支援！