隨著字節跳動旗下業務的快速發展，數據急劇膨脹，原有的大數據架構在面臨日趨復雜的業務需求時逐漸顯現疲態。而伴隨著大數據架構向云原生演進的行業趨勢，字節跳動也對大數據體系進行了云原生改造。本文將詳細介紹字節跳動大數據容器化的演進與實踐。

字節跳動大數據業務發展現狀

從2017年起，字節跳動陸續推出多款廣為人知的熱門應用，如抖音、今日頭條、西瓜視頻、剪映、番茄小說、懂車帝等。隨著行業的快速發展和業務的高速迭代，數據量也呈爆炸式增長，海量的數據規模、愈加復雜的場景使得各大業務對字節底層大數據運算能力的要求不斷提高。以抖音的實時推薦為例。系統需要從億萬級別的內容庫中選出用戶可能感興趣的內容，運用復雜的模型對內容進行打分排序，再通過廣告系統的處理，最后呈現給用戶，整個過程需要在300毫秒內完成。這就對背后的計算能力提出了很高的要求，只有龐大的計算資源和極致的性能優化，才能達到這一業務需求。目前字節跳動的大數據集群已經支持了 EB 級的海量存儲空間和千萬級 Core 的計算資源調度能力。

大數據業務容器化

傳統大數據組件繁多，安裝運維復雜，在生產使用中需要大量的人力支持，不僅集群搭建費時費力，還容易形成運維孤島和數據孤島現象。同時在資源利用、可觀測性等方面也存在諸多不足，已經越來越無法適應當下的發展需求。在此情況下，業界逐漸開始往云原生大數據方案發展。

云原生大數據是大數據平臺新一代架構和運行形態，是一種以平臺云原生化部署、計算云原生調度、存儲統一負載為特點，可以支持多種計算負載，計算調度更彈性，存儲效能更高的大數據處理和分析平臺。云原生大數據帶來了大數據在使用和運維方面的巨大變化，從以下兩個角度來看：

• 業務層面：傳統模式下，業務獨立占用資源，在低谷時段資源占用率可能只有20%-30%；云原生模式下的業務是混部的，比如在線和離線業務，它可以按分時復用的方式來調用資源，以此來提高集群利用率。
• 運維層面：傳統的大數據架構通常是基于物理硬件的，每個集群都需要單獨管理，擴展和升級非常困難。當需要增加更多的節點或更改硬件配置時，需要進行繁瑣的人工操作，而且很容易出現錯誤。云原生模式將平臺組件容器化后，可以利用彈性伸縮、自動化管理等特性，可以更好的進行集群的運維工作。

目前，新一代的字節跳動大數據平臺已全面擁抱云原生，支持“三大平臺和一大支撐體系”的功能架構：

• 平臺服務層：由開源組件插件化集成，支持靈活配置選用；
• 核心引擎層：包括 Flink、Spark、云原生消息引擎、實時服務分析引擎、云原生日志搜索和統一存儲 HDFS 等核心組件，支持存算分離和自動調優；
• 資源調度層：支持統一計算資源調度和統一引擎云原生生命周期管理。
• 運維管理平臺 ： 是集開源組件、服務生命周期、集群、容災、可觀測性于一體的一站式管理平臺。

大數據業務容器化實踐與探索

比較幸運的是，開源的大數據組件大部分將容器化基本做好了，如開源的 HDFS 其實已經可以直接基于 K8s 進行部署，像 Flink/Spark 這樣的計算引擎也早就支持了 on K8s 部署和運行。因此在大數據業務容器化的過程中，我們要解決的問題是如何更好地運行和管理這些大數據任務。由此延伸，在此過程中會遇到以下幾個主要問題：

• 容器化平臺不具備與 YARN 隊列類似的資源管控能力；
• 調度器吞吐能力差，不適用于任務量大且運行時間較短的大數據作業；
• 調度器不存在“作業”概念，不具備作業排隊能力，不具備作業級調度策略；
• 原生的大數據作業在容器化提交后，往往狀態信息獲取不準確；
• 大數據作業容器化部署后導致日志收集、監控告警變得復雜。

為了解決以上問題，字節跳動云原生大數據平臺引入大數據作業調度器 GRO 封裝 YARN 隊列，提升大數據作業吞吐能力，并抽象作業支持企業級調度；引入云原生大數據 Operator Arcee，用于解決狀態信息獲取不準確的問題；構建統一運維平臺，支持統一監控/日志等能力。以下我們將對這三部分進行展開介紹。

大數據作業的 Scheduler — — GRO

在大數據作業中，特別是批式計算的作業通常只會占用資源一段時間，在運行結束后即歸還資源。而用戶通常會提交多個作業，這就導致部分作業不能立即獲得資源，而需要排隊等待直到有作業結束退出后才能獲得資源開始運行。但原生 Kubernetes 調度器最初是針對在線服務設計的，沒有“隊列”和“作業”這兩個概念。為了更好地支持大數據場景資源分配，我們自研了高性能資源管理調度器 GRO，用于管控集群資源，并且新增了以下兩個重要概念：

• Queue CRD：描述了一個“隊列”，即 Quota（資源配額）的抽象；
• PodGroup CRD：描述了一個“作業”，用于標識多個 Pod 屬于同一個集合，從而可以把多個 Pod 看作整體進行調度。

GRO 組件給容器化平臺帶來了如彈性隊列、調度策略、Quota 管控等新的特性 。

彈性隊列

每個隊列可以設置兩個資源配額屬性：

• Min Quota，又稱為保障資源量。調度器為該隊列預留 Min Quota 的資源量，不允許其他隊列占用，以保障該隊列在需要使用時可以立刻獲得資源；
• Max Quota，又稱為資源使用上限。調度器限制該隊列使用資源不超過 Max Quota 的資源量。

GRO 將根據所有隊列的 Min-Max 屬性，將集群資源公平地分配給各個隊列，再根據不同的調度策略，將隊列資源公平地分配給隊列內的各個作業，再進一步分配給不同作業內的各個 Pod。

調度策略

在具備了隊列和作業兩個概念后，還可以支持以下常用的調度策略：

• 優先級調度：所有作業按照定義的優先級排序，調度器優先分配高優先級的作業；
• Gang 調度：調度器一次性為作業的所有 Pod 分配資源，或者一個 Pod 也不分配，保證不出現一個作業的部分 Pod 啟動，部分 Pod 排隊等待的情況；一個作業只有部分 Pod 啟動，有可能不能正常運行，這樣不僅浪費了集群資源，還可能存在多個類似作業相互死鎖，導致所有作業都不能正常運行；
• DRF 調度：調度器公平分配資源給各個作業的同時，兼顧多維度資源的比例，盡可能提升資源利用率；比如隊列剩余大量 CPU 和少量內存時，優先分配 CPU 需求多、內存需求少的作業，避免隊列的內存完全耗盡，大量 CPU 剩余，無法被利用的問題。

Quota 管控

GRO 也可以支持其他 Quota 管控策略：

• 隊列間搶占：隊列沒有使用的 Quota 允許臨時被其他隊列占用，當隊列有資源需求時，可以從其他隊列將資源搶占回來；
• 隊列內搶占：隊列沒有剩余 Quota，高優作業提交后可以將正在運行的低優作業占用的資源搶占回來；
• 大作業資源預留：資源需求較大的作業很有可能因為節點資源碎片而一直無法調度，通過調度器支持預留節點資源，可以保證大作業調度成功。

大數據作業的 Operator —— Arcee

為解決“原生的大數據作業在容器化提交后，往往狀態信息獲取不準確”的這個問題，我們通過自研的 Arcee Operator 作為大數據統一的 Operator ，從而實現統一管控多種計算引擎。

Arcee 借鑒了 YARN 的兩級管理模式，管理大數據作業的 Application Master，再由 AM 管理計算 Worker。AM 包括 Flink JobManager、Spark Driver 等，負責計算 Worker 的啟動、刪除、運行狀態采集及心跳檢測，橫向擴縮容等工作。并且由 Arcee 負責 AM Pod 的啟動、失敗重啟、結束刪除、運行狀態采集等整個生命周期管理。

在引入 Arcee 之后，給我們帶來了如下關鍵特性：

• 定義了統一的 Application： Arcee Application 通過相同的方式表達 Flink、Spark 等作業的配置、規格等描述，并且使用相同的狀態機，結合調度和引擎信息呈現準確、詳細的作業狀態。不同計算引擎的統一描述和狀態有利于業務上的統一表達和處理。
• Arcee 實現了作業異常處理 ： Arcee 實時監控所有 AM 狀態，具有豐富的異常處理策略，包括 AM 重啟、Worker 清理等，持續保障作業正常運行。
• Arcee 屏蔽了底層調度器 ： 作業通過 Arcee 可以輕松使用底層調度器支持的隊列調度、優先級調度、Gang 調度等多種調度策略。同時 Arcee 也可以采集并展示作業的調度信息。Arcee 降低了高級調度功能的接入門檻。
• 完整支持計算框架各種運行模式。例如：Flink Session Mode & Flink Application Mode、Spark Client Mode & Spark Cluster Mode。

運維管理平臺--監控鏈路

在具備 GRO 和 Arcee 之后，一個大數據任務已經可以容器化運行在我們的新一代大數據平臺之上了。那么接下來要面臨的就是如何運維，這其中的關鍵可以感知到該作業的監控和日志信息。

監控鏈路

服務監控指標的采集分為兩種：

• 常駐服務的監控數據：常駐服務集成了 Prometheus 的采集器，Prometheus 會做 Pod 服務的自動發現，并會周期性的同步這些服務的監控數據。
• Flink 任務的監控數據：由 Flink 程序主動 Push 監控數據到 Push-gateway 中，然后 Prometheus 可以周期性的同步 push-gateway 中的數據。

數據面支持多套計算集群，不同的計算集群都部署了一套 Prometheus ，從而使不同集群的 Prometheus 在采集到監控指標之后，用 Remote Write 的方式將監控指標數據寫入到控制面的 Storeage 上，這里的 Storage 是一個抽象的接口，可以支持火山引擎的云監控存儲、S3 存儲、CloudFS 存儲及其他的自定義存儲等。

日志鏈路

日志的來源分為兩種，一種是直接將服務的日志寫入本地文件，然后通過 Filebeat 收集路徑文件并推送到 LogProxy 上；另一種是作業通過集成 Collector 將日志遠程寫入到 LogProxy 上。

Log Proxy 是日志的一個代理服務，內置在每個 K8s 集群中，負責該集群內所有日志數據的匯聚、整理及寫入到 Kafka 上的工作。Kafka 在這里可以完成日志轉存的操作，用于避免短時間內大流量的日志信息將下游的日志存儲服務打爆。同時考慮到日志服務本身的監控和運維能力，我們在 Kafka 側也暴露了一些指標用于監控 Kafka 上日志消息堆積的情況。同時在 Kafak 往下游寫數據的過程中還額外做了動態限流的相關工作，通過自動感知到下游服務的吞吐量來進行流量的動態調整，在保證穩定性的同時，盡可能的將日志文件快速寫入到下游平臺上。

日志數據寫入到日志存儲服務后，為了方便用戶通過頁面或者接口的方式進行日志查看，我們也研發了一個獨立的、對外提供統一的日志搜索 API 模塊。無論是前端用戶還是 OpenAPI 用戶都可以使用該服務的 API 進行相關大數據作業日志的搜索事宜。

業務案例

基于原生大數據組件自身的容器化能力，以及 GRO、Acree、監控、日志這幾個平臺級別的優化，平臺可以基本達到完全容器化的狀態。以某頭部證券客戶的大數據作業容器化實踐為案例，客戶希望基于云原生構建業務敏捷和運維便捷的基礎設施。結合大數據云原生化已被作為企業的重要戰略方向，實現流式計算 Flink 的云原生化是其中的一個重要里程碑。

• 多環境管理

基于銀監會的政策性指導文件，我們需要進行多環境的管理，支持生產和測試雙集群的能力。如下架構圖所示，在測試集群和生產集群分別部署了一套平臺，每個平臺都有自己獨立的入口，具備完全相同的業務能力。為了平臺的易用性，通過新增一個輔助服務的組件，可以用來處理產品同步、上線審批、任務同步等操作。

在此類業務場景中，容器化帶來的最大收益就是相較于傳統大數據平臺，容器化后的大數據作業，可移植性更強，真正實現了一次編寫、多處運行。減少或避免了在傳統大數據平臺場景下，測試環境完成的研發工作上線到線上環境后出現的 Jar 沖突或者其他環境問題。

• 跨數據中心高可用

除了對生產測試的多環境管理剛需之外，金融行業普遍對跨數據中心的高可用也非常關注。

在大數據場景中，跨機房高可用的實現需要從以下三個維度綜合考慮，分別是：服務的高可用、數據的高可用、作業的高可用。

• 服務高可用：業內已經有非常成熟的方案了，因此在本篇中不再過多贅述。
• 數據高可用：通過依靠字節跳動大數據文件存儲系統 CloudFS 實現的，和 HDFS 架構基本類型，具備 NN 和 DN 組件，在容災場景下 CloudFS 可以橫跨數據中心進行部署，在不同的集群上部署 NN 和 DN 組件，當寫入一個文件塊的時候，會同步寫入到多個數據中心的集群上，以保障數據的高可用性。
• 作業高可用：通過引入 Reslake 組件，幫助平臺屏蔽底層的計算資源，該組件具有資源的全局視圖，擁有全局資源池 Quota 管控，可以不限機房、不限集群、以最優化資源利用率為最終的調度目標。于此同時還具備對數據中心、機房、集群的存活狀態自動感知的特性，當發現其中某個節點出現停機故障時會進行任務的遷移，將相關的任務遷移到其他可用的集群、機房或數據中心，以達到作業的高可用性。

在這個場景下，容器化帶來的最大收益就是相較于傳統大數據平臺，容器化后的大數據平臺可運維性更強，可以做到無需額外操作即可自動恢復的能力，真正做到省心，省力。

云原生時代下的數據計算基礎設施

在前文中，我們對云原生大數據平臺實踐進行了一些探討。在6月10日上海，來自字節跳動云原生大數據的技術專家們將在此基礎之上，進一步帶來包括 Flink、RAY、Elasticsearch 項目等大數據主流數據計算基礎設施在云原生場景下的實踐與解析。歡迎一鍵報名～