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

字節(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ù)運(yùn)算能力的要求不斷提高。以抖音的實(shí)時(shí)推薦為例。系統(tǒng)需要從億萬級別的內(nèi)容庫中選出用戶可能感興趣的內(nèi)容，運(yùn)用復(fù)雜的模型對內(nèi)容進(jìn)行打分排序，再通過廣告系統(tǒng)的處理，最后呈現(xiàn)給用戶，整個(gè)過程需要在300毫秒內(nèi)完成。這就對背后的計(jì)算能力提出了很高的要求，只有龐大的計(jì)算資源和極致的性能優(yōu)化，才能達(dá)到這一業(yè)務(wù)需求。目前字節(jié)跳動的大數(shù)據(jù)集群已經(jīng)支持了 EB 級的海量存儲空間和千萬級 Core 的計(jì)算資源調(diào)度能力。

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

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

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

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

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

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

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

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

• 容器化平臺不具備與 YARN 隊(duì)列類似的資源管控能力；
• 調(diào)度器吞吐能力差，不適用于任務(wù)量大且運(yùn)行時(shí)間較短的大數(shù)據(jù)作業(yè)；
• 調(diào)度器不存在“作業(yè)”概念，不具備作業(yè)排隊(duì)能力，不具備作業(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 隊(duì)列，提升大數(shù)據(jù)作業(yè)吞吐能力，并抽象作業(yè)支持企業(yè)級調(diào)度；引入云原生大數(shù)據(jù) Operator Arcee，用于解決狀態(tài)信息獲取不準(zhǔn)確的問題；構(gòu)建統(tǒng)一運(yùn)維平臺，支持統(tǒng)一監(jiān)控/日志等能力。以下我們將對這三部分進(jìn)行展開介紹。

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

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

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

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

彈性隊(duì)列

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

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

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

調(diào)度策略

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

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

Quota 管控

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

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

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

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

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

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

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

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

監(jiān)控鏈路

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

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

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

日志鏈路

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

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

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

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

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

• 多環(huán)境管理

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

在此類業(yè)務(wù)場景中，容器化帶來的最大收益就是相較于傳統(tǒng)大數(shù)據(jù)平臺，容器化后的大數(shù)據(jù)作業(yè)，可移植性更強(qiáng)，真正實(shí)現(xiàn)了一次編寫、多處運(yù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ī)房高可用的實(shí)現(xiàn)需要從以下三個(gè)維度綜合考慮，分別是：服務(wù)的高可用、數(shù)據(jù)的高可用、作業(yè)的高可用。

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

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

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

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