久草麻豆,福利在线看,免费电影、欧美色图、亚洲色图,欧美日本黄色,黄色成人在线免费播放,激情婷婷,韩国一区二区三区精品,99热这只有精品66

▼ 關(guān)注「Apache Flink」，獲取更多技術(shù)干貨?▼

摘要：本文整理自阿里巴巴高級開發(fā)工程師郭旸澤 (天凌) 在 Flink Forward Asia 2021 核心技術(shù)專場的演講。主要內(nèi)容包括：

細(xì)粒度資源管理與適用場景
Flink 資源調(diào)度框架
基于 SlotSharinGroup 的資源配置接口
動態(tài)資源切割機制
資源申請策略
總結(jié)與未來展望

Tips：點擊「閱讀原文」查看原文視頻 & 演講PDF～

一、細(xì)粒度資源管理與適用場景

在 Flink1.14 之前，使用的是一種粗粒度的資源管理方式，每個算子 slot request 所需要的資源都是未知的，在 Flink 內(nèi)部用一個 UNKNOWN 的特殊值來表示，這個值可以和任意資源規(guī)格的物理 slot 來匹配。從 TaskManager (以下簡稱 TM) 的角度來說，它擁有的 slot 個數(shù)和每個 slot 的資源維度都是根據(jù) Flink 配置靜態(tài)決定的。

對于多數(shù)簡單作業(yè)，現(xiàn)有的粗粒度資源管理已經(jīng)可以基本滿足對資源效率的要求。比如上圖作業(yè)，由 Kafka 讀入數(shù)據(jù)后經(jīng)過一些簡單的處理，最終將數(shù)據(jù)寫入到 Redis 中。對于這種作業(yè)，我們很容易將上下游并發(fā)保持一致，并將作業(yè)的整個 pipeline 放到一個 SlotSharingGroup (以下簡稱 SSG) 中。這種情況下，slot 的資源需求是基本相同的，用戶直接調(diào)整默認(rèn)的slot配置即可達到很高的資源利用效率，同時由于不同的 task 熱點峰值不一定相同，通過削峰填谷效應(yīng)，將不同的 task 放到一個大的 slot 里，還可以進一步降低整體的資源開銷。

然而對于一些生產(chǎn)中可能遇到的復(fù)雜作業(yè)，粗粒度資源管理并不能很好地滿足他們的需求。

比如圖上作業(yè)，有兩個 128 并發(fā)的 Kafka source 和一個 32 并發(fā)的 Redis 維表，上下兩路數(shù)據(jù)處理路徑。一條是兩個 Kafka source，經(jīng)過 join 以后再經(jīng)過一些聚合操作，最終將數(shù)據(jù) sink 到第三個 16 并發(fā)的 Kafka 中；另一條路徑則是 Kafka 和 Redis 維表進行 join，結(jié)果流入一個基于 TensorFlow 的在線推斷模塊，最終儲存到 Reids 中。

在這個作業(yè)中粗粒度資源管理就可能導(dǎo)致資源利用效率降低。

首先作業(yè)上下游并發(fā)不一致，如果想把整個作業(yè)放到一個 slot 中，只能和最高的 128 并發(fā)對齊，對齊的過程對于輕量級的算子沒有太大問題，但是對于比較重的資源消耗的算子，會導(dǎo)致很大的資源浪費。比如圖上的 Redis 維表，它將所有數(shù)據(jù)都緩存到內(nèi)存中來提高性能，而聚合算子則需要比較大的 managed memory 來存儲 state。對于這兩個算子，本來只需要分別申請 32 和 16 份資源，對齊并發(fā)以后則分別需要申請 128 份。

同時，整個作業(yè)的 pipeline 可能由于資源過大而無法放到一個 slot 或是 TM 中，比如上述算子的內(nèi)存，再比如 Tensorflow 模塊需要 GPU 來保證計算效率。由于 GPU 是一種非常昂貴的資源，集群上不一定有足夠的數(shù)量，從而導(dǎo)致作業(yè)因為對齊并發(fā)而無法申請到足夠的資源，最終無法執(zhí)行。

我們可以將整個作業(yè)拆分成多個 SSG。如圖所示，我們將算子按照并發(fā)劃分成 4 個 SSG，保證每個 SSG 內(nèi)部的并發(fā)是對齊的。但是由于每個 slot 只有一種默認(rèn)規(guī)格，依然需要將該 slot 的所有資源維度都對齊到各個 SSG 的最大值，比如內(nèi)存需要和 Redis 維表的需求對齊，managed memory 需要和聚合算子對齊，甚至擴展資源中都需要加入一塊 GPU，這依然不能解決資源浪費的問題。

為了解決這個問題，我們提出了細(xì)粒度資源管理，其基本思想是，每個 slot 的資源規(guī)格都可以單獨定制，用戶按需申請，最大化資源的利用效率。

綜上，細(xì)粒度資源管理就是通過使作業(yè)各個模塊按需申請和使用資源來提高資源的整體利用效率。它的適用場景包括以下幾種：作業(yè)中上下游 task 并發(fā)有顯著差異、pipeline 的資源過大或者其中包含比較昂貴的擴展資源。這幾種情況都需要將作業(yè)拆分成多個 SSG，而不同的 SSG 資源需求存在差異，這時通過細(xì)粒度資源管理就能減少資源浪費。此外，對于批任務(wù)，作業(yè)可能包含一個或多個 stage，不同 stage 之間資源消耗存在顯著差異，同樣需要細(xì)粒度資源管理來減少資源開銷。

二、Flink 資源調(diào)度框架

Flink 的資源調(diào)度框架中主要有三個角色，分別是 JobMaster (以下簡稱 JM)，ResourceManager (以下簡稱 RM) 和 TaskManager。用戶寫好的任務(wù)首先會被編譯成 JobGraph，注入資源后提交到 JM，JM 的作用就是管理 JobGraph 的資源申請以及執(zhí)行部署。

JM 中的調(diào)度相關(guān)的組件是 Scheduler，它會根據(jù) JobGraph 生成一系列 SlotRequest，然后將這些 SlotRequest 進行聚合，生成一個 ResourceRequirement 發(fā)送給 RM，RM 接到資源聲明以后，首先會檢查集群中現(xiàn)有的資源能否滿足其需求，可以的話就會向 TM 發(fā)出請求，讓他給對應(yīng)的 JM 去 offer slot (這里 slot 的分配由 SlotManager 組件來完成)。如果現(xiàn)有資源不夠，它會通過內(nèi)部的 driver 向外部的 K8s 或者 Yarn 申請新的資源，最終 JM 接收足夠多的 slot 之后就會開始部署算子，作業(yè)才能運行起來。

順著這個框架，接下來對細(xì)粒度資源管理中的技術(shù)實現(xiàn)細(xì)節(jié)和 design choice 進行分析闡述。

三、基于 SlotSharingGroup?的

資源配置接口

在入口處 Flink 需要將資源配置注入 JobGraph 中。這部分是 FLIP-156 中提出的基于 SlotSharingGroup 的資源配置接口，關(guān)于資源配置接口的設(shè)計選擇，主要問題是資源配置的粒度：

首先是最小的算子粒度 operator。如果用戶在 operator 上配置資源的話，F(xiàn)ilnk 需要根據(jù) chaining 和 slot sharing 進一步將資源聚合成 slot 級別再進行資源調(diào)度。

使用這個粒度的好處是，我們可以將資源配置與 chaining 和 slot sharing 的邏輯解耦，用戶只需要考慮當(dāng)前算子的需求，而無須考慮它是否和其他算子嵌在一起或者是否調(diào)度到一個 slot 中。其次，它使 Flink 可以更準(zhǔn)確地計算每個slot的資源。假如某一個 SSG 中上下游算子擁有不同的并發(fā)，那么可能 SSG 對應(yīng)的物理 slot 需要的資源也是有差異的；而如果 Flink 掌握了每個算子的資源，它就有機會進一步優(yōu)化資源效率。

當(dāng)然它也存在一些缺點，首先是用戶配置成本過高，生產(chǎn)中的復(fù)雜作業(yè)包含了大量算子，用戶很難一一配置。其次，這種情況下，很難支持粗細(xì)粒度混合資源配置。一個 SSG 中如果既存在粗粒度，又存在細(xì)粒度的算子，會導(dǎo)致 Flink 無法判斷其所需要的資源到底是多少。最后，由于用戶對資源的配置或估計會存在一定程度的偏差，這種偏差會不斷累積，算子的削峰填谷效應(yīng)也無法被有效利用。

第二種選擇是將算子 chaining 后形成的 task 作為資源配置的粒度。這種情況下，我們必須向用戶暴露 Flink 內(nèi)部的 chaining 邏輯，同時 Flink 的 runtime 依然需要根據(jù) task 的 slot sharing 的配置進一步將資源聚合成 slot 級別再進行資源調(diào)度。

它的優(yōu)缺點和算子粒度大致一樣，只不過相比算子，它在用戶的配置成本上有了一定程度的降低，但這依然是一個痛點。同時它的代價是無法將資源配置和 chaining 解耦，將 chaining 和 Flink 內(nèi)部的邏輯暴露給用戶，導(dǎo)致內(nèi)部潛在的優(yōu)化受到限制。因為一旦用戶配置了某個 task 的資源，chaining 邏輯的改變可能讓 task 分裂成兩個或者三個，造成用戶配置不兼容。

第三種選擇是直接將 SlotSharingGroup 作為資源配置的粒度，這樣對 Flink 來說資源配置所見既所得，省略了前面的資源聚合邏輯。

同時這種選擇還有以下幾個優(yōu)點：

第一，使用戶的配置更靈活。我們將配置粒度的選擇權(quán)交給用戶，既可以配置算子的資源，也可以配置 task 資源，甚至配置子圖的資源，只需要將子圖放到一個 SSG 里然后配置它的資源即可。

第二，可以較為簡單地支持粗細(xì)粒度混合配置。所有配置的粒度都是 slot，不用擔(dān)心同一個 slot 中既包含粗粒度又包含細(xì)粒度的 task。對于粗粒度的 slot，可以簡單地按照 TM 默認(rèn)的規(guī)格計算它的資源大小，這個特性也使得細(xì)粒度資源管理的分配邏輯可以兼容粗粒度調(diào)度的，我們可以把粗粒度看作是細(xì)粒度的一種特例。

第三，它使得用戶可以利用不同算子之間的削峰填谷效應(yīng)，有效減少偏差產(chǎn)生的影響。

當(dāng)然，也會引入一些限制，它將資源配置的 chaining 以及 Slot Sharing 耦合在了一起。此外如果一個 SSG 里算子存在并發(fā)差異，那么為了最大化資源利用效率，可能需要用戶手動拆組。

綜合考慮，我們在 FLIP-156 中，最終選擇了基于 SlotSharingGroup 的資源配置接口。除了上述提到的優(yōu)點，最重要的是從資源調(diào)度框架中可以發(fā)現(xiàn)，slot 實際上就是資源調(diào)度中最基本的單位，從 Scheduler 到 RM\TM 都是以 slot 為單位進行資源調(diào)度申請的，直接使用這個粒度，避免了增加系統(tǒng)的復(fù)雜度。

回到示例作業(yè)，在支持了細(xì)粒度資源管理配置接口后，我們就可以為 4 個 SSG 配置不同的資源，如上圖所示。只要調(diào)度框架嚴(yán)格按照這個原則進行匹配，我們就可以最大化資源利用效率。

四、動態(tài)資源切割機制

解決了資源配置以后，下一步就是為這些資源申請 slot，這一步需要用到 FLIP-56 提出的動態(tài)資源切割機制。

簡單回顧一下這幅圖，現(xiàn)在最左側(cè)的 JobGraph 已經(jīng)有資源了，往右走就進入了 JM、RM 和 TM 的資源調(diào)度。在粗粒度資源管理下，TM 的 slot 都是固定大小、根據(jù)啟動配置來決定的，RM 在這種情況沒法滿足不同規(guī)格的 slot 請求的，因此我們需要對 slot 的創(chuàng)建方式進行一定的改造。

先來看現(xiàn)有的靜態(tài) slot 申請機制。實際上 TM 啟動的時候 slot 就已經(jīng)劃分好了，并且標(biāo)記了編號。它會將這些 slot 上報給 Slot Manager，slot request 來臨時 Slot Manager 會決定申請 slot1、slot3，最后 slot1 上的 task 運行完以后會釋放 slot。這種情況下，只有 slot3 處于占用的狀態(tài)。我們可以發(fā)現(xiàn)，這時雖然 TM 有 0.75 core，3G 的空閑資源，但如果 job 去申請對應(yīng)資源大小的 slot，TM 也無法滿足它，因為 slot 已經(jīng)提前劃分好了。

因此我們提出了動態(tài)資源切割機制。slot 不再是 TM 啟動后就生成并且不變的，而是根據(jù)實際 slot 的請求動態(tài)地從 TM 上切割下來。TM 啟動時，我們把能分配給 slot 的資源看作是一整個資源池，比如上圖有 1core，4G 內(nèi)存的資源，現(xiàn)在有一個細(xì)粒度的作業(yè)，Slot Manager 決定從 TM 上要一個 0.25core，1G 的 slot，TM 會檢查自己的資源池是否能夠切下這個 slot，然后動態(tài)生成 slot 并分配對應(yīng)的資源給 JM，接下來這個作業(yè)又申請一個 0.5core，2G 的 slot，Slot Manager 還是可以從同一個 TM 上申請 slot，只要不超過空閑資源就可以。當(dāng)某個 slot 不再需要時，我們可以將它銷毀，對應(yīng)的資源會回到空閑資源池。

通過這種機制，我們解決了細(xì)粒度資源請求如何滿足的問題。

回到示例作業(yè)，我們只需要起 8 個同樣規(guī)格的 TM 就能調(diào)度作業(yè)，每個 TM 上帶一塊 GPU 來滿足 SSG4，之后將 CPU 密集型的 SSG1 和內(nèi)存密集型的 SSG2 和 SSG3 進行混布，對齊 TM 上整體的 CPU 內(nèi)存比即可。

五、資源申請策略

何謂資源申請策略？它包含 RM 與 Resource Provider 還有 TM 交互時的兩個決策，一個是從 Resource Provider 處申請什么資源規(guī)格的 TM 以及各個規(guī)格 TM 各需要幾個，另一個是如何將 slot 擺放到各個 TM 中。實際上這兩個決策都是在 Slot Manager 組件內(nèi)部進行的。

粗粒度的資源申請策略比較簡單，因為只存在一種規(guī)格的 TM，并且 slot 規(guī)格都是一樣的。在分配策略上只需要考慮是否將 slot 盡量平鋪到各個 TM。但在細(xì)粒度資源管理下的策略就需要考慮到不同的需求。

首先我們引入了動態(tài)資源切割機制。slot 的調(diào)度就可以看作一個多維裝箱問題，既需要考慮如何減少資源碎片，也需要保障資源調(diào)度效率。此外還有 slot 是否需要評估，以及集群可能對 TM 的資源規(guī)格有一些要求，比如不能過小，在 K8s 上如果 TM 資源過小，會導(dǎo)致啟動過慢，最后注冊超時，但也不能太大，會影響 K8s 的調(diào)度效率。

面對上述復(fù)雜性，我們將這個資源申請策略抽象出來，定義了一個 ResourceAllocationStrategy，Slot Manager 會將當(dāng)前的資源請求和集群中現(xiàn)有的可用資源告訴 strategy，strategy 負(fù)責(zé)決策并告訴 Slot Manager 現(xiàn)有資源如何分配、還需要申請多少個新的 TM 以及它們分別的規(guī)格，還有是否存在無法滿足的作業(yè)。

目前細(xì)粒度資源管理還處于 beta 版本，社區(qū)內(nèi)置了一個簡單的默認(rèn)資源管理策略。在這個策略下 TM 的規(guī)格是固定的、根據(jù)粗粒度的配置決定的，如果某個 slot 的請求大于資源配置，可能導(dǎo)致無法分配，這是它的局限性。在資源分配方面，它會順序掃描當(dāng)前空閑的 TM，只要滿足 slot 的請求就會直接切割，這種策略保障了資源調(diào)度即使在大規(guī)模的任務(wù)上也不會成為瓶頸，但代價是無法避免資源碎片的產(chǎn)生。

六、總結(jié)與未來展望

細(xì)粒度資源管理目前在 Flink 中還只是 beta 版本。上圖可以看到，對于 runtime 來說，通過 FLIP-56 與 FLIP-156，細(xì)粒度資源管理的工作已經(jīng)基本完成了。而從用戶接口的角度，F(xiàn)LIP-169 已經(jīng)開放了 Datastream API 上的細(xì)粒度配置，具體如何配置，可以參考社區(qū)的用戶文檔。

未來，我們的發(fā)展方向主要是以下幾個方面：

第一，定制更多的資源管理策略來滿足不同場景，比如 session 和 OLAP 等；
第二，目前我們是把擴展資源看作一個 TM 級別的資源，TM 上的每個 slot 都可以看到它的信息，之后我們會對它的 scope 進行進一步限制；
第三，目前細(xì)粒度資源管理可以支持粗細(xì)粒度混合配置，但是存在一些資源效率上的問題，比如粗粒度的 slot 請求可以被任意大小的 slot 滿足，未來我們會進一步優(yōu)化匹配邏輯，更好地支持混合配置；
第四，我們會考慮適配社區(qū)新提出的 Reactive Mode；
最后，對 WebUI 進行優(yōu)化，能夠展示 slot 的切分信息等。

往期精選

更多 Flink 相關(guān)技術(shù)問題，可掃碼加入社區(qū)釘釘交流群～

???戳我，查看原文視頻&演講PDF～

Flink 原理 | 深入解析 Flink 細(xì)粒度資源管理