1. 細粒度資源辦理與適用場景
2. Flink 資源調(diào)度結(jié)構(gòu)
3. 依據(jù) SlotSharinGroup 的資源裝備接口
4. 動態(tài)資源切開機制
5. 資源懇求戰(zhàn)略
6. 總結(jié)與未來展望

FFA 2021 直播回放 & 講演 PDF 下載

一、細粒度資源辦理與適用場景

在 Flink1.14 之前，運用的是一種粗粒度的資源辦理方式，每個算子 slot request 所需求的資源都是未知的，在 Flink 內(nèi)部用一個 UNKNOWN 的特殊值來表明，這個值能夠和恣意資源標(biāo)準(zhǔn)的物理 slot 來匹配。從 TaskManager (以下簡稱 TM) 的視點來說，它具有的 slot 個數(shù)和每個 slot 的資源維度都是依據(jù) Flink 裝備靜態(tài)決議的。

關(guān)于多數(shù)簡略作業(yè)，現(xiàn)有的粗粒度資源辦理現(xiàn)已能夠根本滿意對資源功率的要求。比方上圖作業(yè)，由 Kafka 讀入數(shù)據(jù)后經(jīng)過一些簡略的處理，終究將數(shù)據(jù)寫入到 Redis 中。關(guān)于這種作業(yè)，咱們很容易將上下流并發(fā)保持一致，并將作業(yè)的整個 pipeline 放到一個 SlotSharingGroup (以下簡稱 SSG) 中。這種狀況下，slot 的資源需求是根本相同的，用戶直接調(diào)整默許的slot裝備即可到達很高的資源運用功率，一同由于不同的 task 熱點峰值紛歧定相同，經(jīng)過削峰填谷效應(yīng)，將不同的 task 放到一個大的 slot 里，還能夠進一步下降全體的資源開支。

可是關(guān)于一些生產(chǎn)中或許遇到的雜亂作業(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é)果流入一個依據(jù) TensorFlow 的在線推斷模塊，終究儲存到 Reids 中。

在這個作業(yè)中粗粒度資源辦理就或許導(dǎo)致資源運用功率下降。

首要作業(yè)上下流并發(fā)紛歧致，假如想把整個作業(yè)放到一個 slot 中，只能和最高的 128 并發(fā)對齊，對齊的過程關(guān)于輕量級的算子沒有太大問題，可是關(guān)于比較重的資源消耗的算子，會導(dǎo)致很大的資源糟蹋。比方圖上的 Redis 維表，它將一切數(shù)據(jù)都緩存到內(nèi)存中來提高性能，而聚合算子則需求比較大的 managed memory 來存儲 state。關(guān)于這兩個算子，原本只需求別離懇求 32 和 16 份資源，對齊并發(fā)今后則別離需求懇求 128 份。

一同，整個作業(yè)的 pipeline 或許由于資源過大而無法放到一個 slot 或是 TM 中，比方上述算子的內(nèi)存，再比方 Tensorflow 模塊需求 GPU 來確保核算功率。由于 GPU 是一種十分昂貴的資源，集群上紛歧定有滿意的數(shù)量，從而導(dǎo)致作業(yè)由于對齊并發(fā)而無法懇求到滿意的資源，終究無法履行。

咱們能夠?qū)⒄麄€作業(yè)拆分紅多個 SSG。如圖所示，咱們將算子依照并發(fā)區(qū)分紅 4 個 SSG，確保每個 SSG 內(nèi)部的并發(fā)是對齊的?？墒怯捎诿總€ slot 只需一種默許標(biāo)準(zhǔn)，仍然需求將該 slot 的一切資源維度都對齊到各個 SSG 的最大值，比方內(nèi)存需求和 Redis 維表的需求對齊，managed memory 需求和聚合算子對齊，乃至擴展資源中都需求加入一塊 GPU，這仍然不能處理資源糟蹋的問題。

為了處理這個問題，咱們提出了細粒度資源辦理，其根本思想是，每個 slot 的資源標(biāo)準(zhǔn)都能夠單獨定制，用戶按需懇求，最大化資源的運用功率。

綜上，細粒度資源辦理便是經(jīng)過使作業(yè)各個模塊按需懇求和運用資源來提高資源的全體運用功率。它的適用場景包括以下幾種：作業(yè)中上下流 task 并發(fā)有顯著差異、pipeline 的資源過大或者其中包括比較昂貴的擴展資源。這幾種狀況都需求將作業(yè)拆分紅多個 SSG，而不同的 SSG 資源需求存在差異，這時經(jīng)過細粒度資源辦理就能削減資源糟蹋。此外，關(guān)于批使命，作業(yè)或許包括一個或多個 stage，不同 stage 之間資源消耗存在顯著差異，相同需求細粒度資源辦理來削減資源開支。

二、Flink 資源調(diào)度結(jié)構(gòu)

Flink 的資源調(diào)度結(jié)構(gòu)中首要有三個角色，別離是 JobMaster (以下簡稱 JM)，ResourceManager (以下簡稱 RM) 和 TaskManager。用戶寫好的使命首要會被編譯成 JobGraph，注入資源后提交到 JM，JM 的效果便是辦理 JobGraph 的資源懇求以及履行布置。

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)有資源不行，它會經(jīng)過內(nèi)部的 driver 向外部的 K8s 或者 Yarn 懇求新的資源，終究 JM 接納滿意多的 slot 之后就會開端布置算子，作業(yè)才干運轉(zhuǎn)起來。

順著這個結(jié)構(gòu)，接下來對細粒度資源辦理中的技術(shù)實現(xiàn)細節(jié)和 design choice 進行分析論述。

三、依據(jù) SlotSharingGroup 的資源裝備接口

在入口處 Flink 需求將資源裝備注入 JobGraph 中。這部分是 FLIP-156 中提出的依據(jù) SlotSharingGroup 的資源裝備接口，關(guān)于資源裝備接口的規(guī)劃挑選，首要問題是資源裝備的粒度：

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

運用這個粒度的優(yōu)點是，咱們能夠?qū)①Y源裝備與 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)中的雜亂作業(yè)包括了大量算子，用戶很難逐個裝備。其次，這種狀況下，很難支撐粗細粒度混合資源裝備。一個 SSG 中假如既存在粗粒度，又存在細粒度的算子，會導(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 里然后裝備它的資源即可。
• 第二，能夠較為簡略地支撐粗細粒度混合裝備。一切裝備的粒度都是 slot，不必憂慮同一個 slot 中既包括粗粒度又包括細粒度的 task。關(guān)于粗粒度的 slot，能夠簡略地依照 TM 默許的標(biāo)準(zhǔn)核算它的資源巨細，這個特性也使得細粒度資源辦理的分配邏輯能夠兼容粗粒度調(diào)度的，咱們能夠把粗粒度看作是細粒度的一種特例。
• 第三，它使得用戶能夠運用不同算子之間的削峰填谷效應(yīng)，有用削減偏差發(fā)生的影響。

當(dāng)然，也會引進一些約束，它將資源裝備的 chaining 以及 Slot Sharing 耦合在了一同。此外假如一個 SSG 里算子存在并發(fā)差異，那么為了最大化資源運用功率，或許需求用戶手動拆組。

歸納考慮，咱們在 FLIP-156 中，終究挑選了依據(jù) SlotSharingGroup 的資源裝備接口。除了上述說到的優(yōu)點，最重要的是從資源調(diào)度結(jié)構(gòu)中能夠發(fā)現(xiàn)，slot 實踐上便是資源調(diào)度中最根本的單位，從 Scheduler 到 RM\TM 都是以 slot 為單位進行資源調(diào)度懇求的，直接運用這個粒度，防止了添加系統(tǒng)的雜亂度。

回到示例作業(yè)，在支撐了細粒度資源辦理裝備接口后，咱們就能夠為 4 個 SSG 裝備不同的資源，如上圖所示。只需調(diào)度結(jié)構(gòu)嚴厲依照這個原則進行匹配，咱們就能夠最大化資源運用功率。

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

處理了資源裝備今后，下一步便是為這些資源懇求 slot，這一步需求用到 FLIP-56 提出的動態(tài)資源切開機制。

簡略回顧一下這幅圖，現(xiàn)在最左邊的 JobGraph 現(xiàn)已有資源了，往右走就進入了 JM、RM 和 TM 的資源調(diào)度。在粗粒度資源辦理下，TM 的 slot 都是固定巨細、依據(jù)發(fā)動裝備來決議的，RM 在這種狀況沒法滿意不同標(biāo)準(zhǔn)的 slot 懇求的，因而咱們需求對 slot 的創(chuàng)建方式進行必定的改造。

先來看現(xiàn)有的靜態(tài) slot 懇求機制。實踐上 TM 發(fā)動的時候 slot 就現(xiàn)已區(qū)分好了，而且標(biāo)記了編號。它會將這些 slot 上報給 Slot Manager，slot request 來暫時 Slot Manager 會決議懇求 slot1、slot3，最后 slot1 上的 task 運轉(zhuǎn)完今后會開釋 slot。這種狀況下，只需 slot3 處于占用的狀況。咱們能夠發(fā)現(xiàn)，這時盡管 TM 有 0.75 core，3G 的閑暇資源，但假如 job 去懇求對應(yīng)資源巨細的 slot，TM 也無法滿意它，由于 slot 現(xiàn)已提前區(qū)分好了。

因而咱們提出了動態(tài)資源切開機制。slot 不再是 TM 發(fā)動后就生成而且不變的，而是依據(jù)實踐 slot 的懇求動態(tài)地從 TM 上切開下來。TM 發(fā)動時，咱們把能分配給 slot 的資源看作是一整個資源池，比方上圖有 1core，4G 內(nèi)存的資源，現(xiàn)在有一個細粒度的作業(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 不再需求時，咱們能夠?qū)⑺N毀，對應(yīng)的資源會回到閑暇資源池。

經(jīng)過這種機制，咱們處理了細粒度資源懇求怎么滿意的問題。

回到示例作業(yè)，咱們只需求起 8 個相同標(biāo)準(zhǔn)的 TM 就能調(diào)度作業(yè)，每個 TM 上帶一塊 GPU 來滿意 SSG4，之后將 CPU 密集型的 SSG1 和內(nèi)存密集型的 SSG2 和 SSG3 進行混布，對齊 TM 上全體的 CPU 內(nèi)存比即可。

五、資源懇求戰(zhàn)略

何謂資源懇求戰(zhàn)略？它包括 RM 與 Resource Provider 還有 TM 交互時的兩個決策，一個是從 Resource Provider 處懇求什么資源標(biāo)準(zhǔn)的 TM 以及各個標(biāo)準(zhǔn) TM 各需求幾個，另一個是怎么將 slot 擺放到各個 TM 中。實踐上這兩個決策都是在 Slot Manager 組件內(nèi)部進行的。

粗粒度的資源懇求戰(zhàn)略比較簡略，由于只存在一種標(biāo)準(zhǔn)的 TM，而且 slot 標(biāo)準(zhǔn)都是相同的。在分配戰(zhàn)略上只需求考慮是否將 slot 盡量平鋪到各個 TM。但在細粒度資源辦理下的戰(zhàn)略就需求考慮到不同的需求。

首要咱們引進了動態(tài)資源切開機制。slot 的調(diào)度就能夠看作一個多維裝箱問題，既需求考慮怎么削減資源碎片，也需求保證資源調(diào)度功率。此外還有 slot 是否需求評價，以及集群或許對 TM 的資源標(biāo)準(zhǔn)有一些要求，比方不能過小，在 K8s 上假如 TM 資源過小，會導(dǎo)致發(fā)動過慢，最后注冊超時，但也不能太大，會影響 K8s 的調(diào)度功率。

面臨上述雜亂性，咱們將這個資源懇求戰(zhàn)略抽象出來，定義了一個 ResourceAllocationStrategy，Slot Manager 會將當(dāng)前的資源懇求和集群中現(xiàn)有的可用資源告知 strategy，strategy 負責(zé)決策并告知 Slot Manager 現(xiàn)有資源怎么分配、還需求懇求多少個新的 TM 以及它們別離的標(biāo)準(zhǔn)，還有是否存在無法滿意的作業(yè)。

現(xiàn)在細粒度資源辦理還處于 beta 版本，社區(qū)內(nèi)置了一個簡略的默許資源辦理戰(zhàn)略。在這個戰(zhàn)略下 TM 的標(biāo)準(zhǔn)是固定的、依據(jù)粗粒度的裝備決議的，假如某個 slot 的懇求大于資源裝備，或許導(dǎo)致無法分配，這是它的局限性。在資源分配方面，它會順序掃描當(dāng)前閑暇的 TM，只需滿意 slot 的懇求就會直接切開，這種戰(zhàn)略保證了資源調(diào)度即便在大規(guī)模的使命上也不會成為瓶頸，但價值是無法防止資源碎片的發(fā)生。

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

細粒度資源辦理現(xiàn)在在 Flink 中還只是 beta 版本。上圖能夠看到，關(guān)于 runtime 來說，經(jīng)過 FLIP-56 與 FLIP-156，細粒度資源辦理的工作現(xiàn)已根本完成了。而從用戶接口的視點，F(xiàn)LIP-169 現(xiàn)已開放了 Datastream API 上的細粒度裝備，詳細怎么裝備，能夠參閱社區(qū)的用戶文檔。

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

• 榜首，定制更多的資源辦理戰(zhàn)略來滿意不同場景，比方 session 和 OLAP 等；
• 第二，現(xiàn)在咱們是把擴展資源看作一個 TM 等級的資源，TM 上的每個 slot 都能夠看到它的信息，之后咱們會對它的 scope 進行進一步約束；
• 第三，現(xiàn)在細粒度資源辦理能夠支撐粗細粒度混合裝備，可是存在一些資源功率上的問題，比方粗粒度的 slot 懇求能夠被恣意巨細的 slot 滿意，未來咱們會進一步優(yōu)化匹配邏輯，更好地支撐混合裝備；
• 第四，咱們會考慮適配社區(qū)新提出的 Reactive Mode；
• 最后，對 WebUI 進行優(yōu)化，能夠展示 slot 的切分信息等。