隨著字節(jié)跳動旗下業(yè)務(wù)的快速發(fā)展，數(shù)據(jù)急劇膨脹，原有的大數(shù)據(jù)架構(gòu)在面臨日趨復(fù)雜的業(yè)務(wù)需求時逐漸顯現(xiàn)疲態(tài)。而伴隨著大數(shù)據(jù)架構(gòu)向云原生演進(jìn)的行業(yè)趨勢，字節(jié)跳動也對大數(shù)據(jù)體系進(jìn)行了云原生改造。本文將詳細(xì)介紹字節(jié)跳動大數(shù)據(jù)容器化的演進(jìn)與實踐。

字節(jié)跳動大數(shù)據(jù)業(yè)務(wù)發(fā)展現(xiàn)狀

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

大數(shù)據(jù)業(yè)務(wù)容器化

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

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

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

目前，新一代的字節(jié)跳動大數(shù)據(jù)平臺已全面擁抱云原生，支持“三大平臺和一大支撐體系”的功能架構(gòu)：

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

大數(shù)據(jù)業(yè)務(wù)容器化實踐與探索

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

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

為了解決以上問題，字節(jié)跳動云原生大數(shù)據(jù)平臺引入大數(shù)據(jù)作業(yè)調(diào)度器 GRO 封裝 YARN 隊列，提升大數(shù)據(jù)作業(yè)吞吐能力，并抽象作業(yè)支持企業(yè)級調(diào)度；引入云原生大數(shù)據(jù) Operator Arcee，用于解決狀態(tài)信息獲取不準(zhǔn)確的問題；構(gòu)建統(tǒng)一運維平臺，支持統(tǒng)一監(jiān)控/日志等能力。以下我們將對這三部分進(jìn)行展開介紹。

大數(shù)據(jù)作業(yè)的 Scheduler — — GRO

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

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

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

彈性隊列

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

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

GRO 將根據(jù)所有隊列的 Min-Max 屬性，將集群資源公平地分配給各個隊列，再根據(jù)不同的調(diào)度策略，將隊列資源公平地分配給隊列內(nèi)的各個作業(yè)，再進(jìn)一步分配給不同作業(yè)內(nèi)的各個 Pod。

調(diào)度策略

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

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

Quota 管控

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

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

大數(shù)據(jù)作業(yè)的 Operator —— Arcee

為解決“原生的大數(shù)據(jù)作業(yè)在容器化提交后，往往狀態(tài)信息獲取不準(zhǔn)確”的這個問題，我們通過自研的 Arcee Operator 作為大數(shù)據(jù)統(tǒng)一的 Operator ，從而實現(xiàn)統(tǒng)一管控多種計算引擎。

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

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

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

運維管理平臺--監(jiān)控鏈路

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

監(jiān)控鏈路

服務(wù)監(jiān)控指標(biāo)的采集分為兩種：

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

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

日志鏈路

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

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

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

業(yè)務(wù)案例

基于原生大數(shù)據(jù)組件自身的容器化能力，以及 GRO、Acree、監(jiān)控、日志這幾個平臺級別的優(yōu)化，平臺可以基本達(dá)到完全容器化的狀態(tài)。以某頭部證券客戶的大數(shù)據(jù)作業(yè)容器化實踐為案例，客戶希望基于云原生構(gòu)建業(yè)務(wù)敏捷和運維便捷的基礎(chǔ)設(shè)施。結(jié)合大數(shù)據(jù)云原生化已被作為企業(yè)的重要戰(zhàn)略方向，實現(xiàn)流式計算 Flink 的云原生化是其中的一個重要里程碑。

• 多環(huán)境管理

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

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

• 跨數(shù)據(jù)中心高可用

除了對生產(chǎn)測試的多環(huán)境管理剛需之外，金融行業(yè)普遍對跨數(shù)據(jù)中心的高可用也非常關(guān)注。

在大數(shù)據(jù)場景中，跨機(jī)房高可用的實現(xiàn)需要從以下三個維度綜合考慮，分別是：服務(wù)的高可用、數(shù)據(jù)的高可用、作業(yè)的高可用。

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

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

云原生時代下的數(shù)據(jù)計算基礎(chǔ)設(shè)施

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