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

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

一、細(xì)粒度資源辦理與適用場(chǎng)景

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

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

可是關(guān)于一些生產(chǎn)中或許遇到的雜亂作業(yè)，粗粒度資源辦理并不能很好地滿意他們的需求。

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

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

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

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

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

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

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

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

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

JM 中的調(diào)度相關(guān)的組件是 Scheduler，它會(huì)依據(jù) JobGraph 生成一系列 SlotRequest，然后將這些 SlotRequest 進(jìn)行聚合，生成一個(gè) ResourceRequirement 發(fā)送給 RM，RM 接到資源聲明今后，首要會(huì)檢查集群中現(xiàn)有的資源能否滿意其需求，能夠的話就會(huì)向 TM 發(fā)出懇求，讓他給對(duì)應(yīng)的 JM 去 offer slot (這兒 slot 的分配由 SlotManager 組件來(lái)完成)。假如現(xiàn)有資源不行，它會(huì)經(jīng)過(guò)內(nèi)部的 driver 向外部的 K8s 或者 Yarn 懇求新的資源，終究 JM 接納滿意多的 slot 之后就會(huì)開(kāi)端布置算子，作業(yè)才干運(yùn)轉(zhuǎn)起來(lái)。

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

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

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

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

運(yùn)用這個(gè)粒度的優(yōu)點(diǎn)是，咱們能夠?qū)①Y源裝備與 chaining 和 slot sharing 的邏輯解耦，用戶只需求考慮當(dāng)前算子的需求，而無(wú)須考慮它是否和其他算子嵌在一同或者是否調(diào)度到一個(gè) slot 中。其次，它使 Flink 能夠更準(zhǔn)確地核算每個(gè)slot的資源。假如某一個(gè) SSG 中上下流算子具有不同的并發(fā)，那么或許 SSG 對(duì)應(yīng)的物理 slot 需求的資源也是有差異的；而假如 Flink 掌握了每個(gè)算子的資源，它就有機(jī)會(huì)進(jìn)一步優(yōu)化資源功率。

當(dāng)然它也存在一些缺點(diǎn)，首要是用戶裝備本錢過(guò)高，生產(chǎn)中的雜亂作業(yè)包括了大量算子，用戶很難逐個(gè)裝備。其次，這種狀況下，很難支撐粗細(xì)粒度混合資源裝備。一個(gè) SSG 中假如既存在粗粒度，又存在細(xì)粒度的算子，會(huì)導(dǎo)致 Flink 無(wú)法判別其所需求的資源究竟是多少。最后，由于用戶對(duì)資源的裝備或估量會(huì)存在必定程度的偏差，這種偏差會(huì)不斷累積，算子的削峰填谷效應(yīng)也無(wú)法被有用運(yùn)用。

第二種挑選是將算子 chaining 后形成的 task 作為資源裝備的粒度。這種狀況下，咱們有必要向用戶露出 Flink 內(nèi)部的 chaining 邏輯，一同 Flink 的 runtime 仍然需求依據(jù) task 的 slot sharing 的裝備進(jìn)一步將資源聚合成 slot 等級(jí)再進(jìn)行資源調(diào)度。

它的優(yōu)缺點(diǎn)和算子粒度大致相同，只不過(guò)相比算子，它在用戶的裝備本錢上有了必定程度的下降，但這仍然是一個(gè)痛點(diǎn)。一同它的價(jià)值是無(wú)法將資源裝備和 chaining 解耦，將 chaining 和 Flink 內(nèi)部的邏輯露出給用戶，導(dǎo)致內(nèi)部潛在的優(yōu)化受到約束。由于一旦用戶裝備了某個(gè) task 的資源，chaining 邏輯的改動(dòng)或許讓 task 分裂成兩個(gè)或者三個(gè)，形成用戶裝備不兼容。

第三種挑選是直接將 SlotSharingGroup 作為資源裝備的粒度，這樣對(duì) Flink 來(lái)說(shuō)資源裝備所見(jiàn)既所得，省略了前面的資源聚合邏輯。

一同這種挑選還有以下幾個(gè)優(yōu)點(diǎn)：

• 榜首，運(yùn)用戶的裝備更靈活。咱們將裝備粒度的挑選權(quán)交給用戶，既能夠裝備算子的資源，也能夠裝備 task 資源，乃至裝備子圖的資源，只需求將子圖放到一個(gè) SSG 里然后裝備它的資源即可。
• 第二，能夠較為簡(jiǎn)略地支撐粗細(xì)粒度混合裝備。一切裝備的粒度都是 slot，不必憂慮同一個(gè) slot 中既包括粗粒度又包括細(xì)粒度的 task。關(guān)于粗粒度的 slot，能夠簡(jiǎn)略地依照 TM 默許的標(biāo)準(zhǔn)核算它的資源巨細(xì)，這個(gè)特性也使得細(xì)粒度資源辦理的分配邏輯能夠兼容粗粒度調(diào)度的，咱們能夠把粗粒度看作是細(xì)粒度的一種特例。
• 第三，它使得用戶能夠運(yùn)用不同算子之間的削峰填谷效應(yīng)，有用削減偏差發(fā)生的影響。

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

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

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

四、動(dòng)態(tài)資源切開(kāi)機(jī)制

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

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

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

因而咱們提出了動(dòng)態(tài)資源切開(kāi)機(jī)制。slot 不再是 TM 發(fā)動(dòng)后就生成而且不變的，而是依據(jù)實(shí)踐 slot 的懇求動(dòng)態(tài)地從 TM 上切開(kāi)下來(lái)。TM 發(fā)動(dòng)時(shí)，咱們把能分配給 slot 的資源看作是一整個(gè)資源池，比方上圖有 1core，4G 內(nèi)存的資源，現(xiàn)在有一個(gè)細(xì)粒度的作業(yè)，Slot Manager 決議從 TM 上要一個(gè) 0.25core，1G 的 slot，TM 會(huì)檢查自己的資源池是否能夠切下這個(gè) slot，然后動(dòng)態(tài)生成 slot 并分配對(duì)應(yīng)的資源給 JM，接下來(lái)這個(gè)作業(yè)又懇求一個(gè) 0.5core，2G 的 slot，Slot Manager 還是能夠從同一個(gè) TM 上懇求 slot，只需不超過(guò)閑暇資源就能夠。當(dāng)某個(gè) slot 不再需求時(shí)，咱們能夠?qū)⑺N毀，對(duì)應(yīng)的資源會(huì)回到閑暇資源池。

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

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

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

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

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

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

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

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

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

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

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

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