云環境下大規模分布式計算數據感知的調度系統

劉汪根¹,?鄭淮城¹,?榮國平²

1?星環信息科技（上海）有限公司，上海 200233

2?南京大學軟件學院，江蘇 南京 210093

?

摘要：介紹了新的調度系統，包括資源調度、應用編排、配置標簽中心、云網絡和云存儲服務等子系統。系統通過數據拓撲感知能力保證了計算和數據的局部性，節約網絡I/O開銷；通過優化點對點大數據量讀取的資源調度，解決網絡風暴造成的影響；通過網絡和磁盤隔離技術以及可搶占的方式來保證服務等級協議。

關鍵詞：?云計算?;?調度系統?;?大數據?;?AI平臺?;?數據局部性?;?分布式計算?;?搶占

論文引用格式：

劉汪根, 鄭淮城, 榮國平.云環境下大規模分布式計算數據感知的調度系統. ?大數據[J], 2020, 6(1）：81-98

LIU J G, ZHENG H?C,?RONG G P.A scheduler system for large-scale distributed data computing in cloud.?Big Data Research[J], 2020, 6(1):81-98

1 引言

隨著云計算、大數據與人工智能（artificial intelligence，AI）技術的發展以及行業對這3種技術的綜合應用需求，目前國內外出現了大數據、云計算、人工智能三者相互融合的技術發展趨勢。中國計算機學會大數據專家委員會在2019年大數據發展趨勢調查報告中指出：人工智能、大數據、云計算將高度融合為一體化系統。

2006年Hadoop項目的誕生標志著大數據技術時代的開始，而亞馬遜云計算服務（Amazon web services，AWS）商用則標志著云計算正式邁出了改變信息時代的步伐。自此之后，大數據和云計算成為最近十幾年十分火熱的技術，學術界和工業界都大力投入相關技術研發和落地應用中，并且創造了幾個學術界和工業界協作的經典之作。如2012年加州大學伯克利分校推出的新型計算引擎Spark技術迅速被工業界接受，并成為新一代的標準計算引擎。在云計算領域，更多的是企業級應用推動了技術的發展，如2014年開始興起的容器技術和編排系統，最終推進了新一代原生云平臺的快速發展，Docker和Kubernetes技術則成為新一代原生云的標準。

基礎軟件的研發不是簡單的功能堆積，必須經過詳細的架構設計和功能驗證。大數據和AI計算都是典型的分布式計算模型，是基于有向無環圖（directed acyclic graph，DAG）或者大規模并行處理（massive parallel programming， MPP）迭代的計算模式，意味著計算任務都是運行時才能生成的，因而難以進行預先調度，而分布式的特點又要求調度系統有更高的靈活性和自適應性。目前工業界在努力嘗試將大數據平臺和AI技術部署在原生云上，以做到更大的彈性和可擴展性。但是，目前全球范圍內在這個領域取得的突破性成就還比較少。本文將介紹核心創新：云平臺中的核心調度系統如何在原生云平臺上管理和調度大數據和AI應用。

2 云原生

云原生（cloud native）是指在應用開發時，以云作為其生產部署方式，從而充分利用云的彈性、可擴展、自愈等核心優勢。區別于傳統的臃腫的單體應用開發模式，云原生應用因為其有效的協同開發、測試和運維，極大地提高了軟件開發效率和質量，支持產品快速地上線和迭代，已經成為當前主流的應用開發模式。

通常稱能夠有效支撐云原生應用的平臺為原生云平臺，其主要特點是容器化的封裝、自動化的管理以及面向微服務的體系。Docker直接使用Linux Cgroup等技術提供邏輯上的虛擬化，因其系統開銷小、啟動快、隔離性較好、方便應用封裝等特點，Docker已經成為首選的應用容器技術。此外Docker技術支持跨平臺部署，能夠實現“一次編譯，多次部署”。基于虛擬機的技術對高負載的應用可能有30%的性能損耗，而Docker技術沒有硬件虛擬化，跟裸機相比幾乎沒有性能損耗，因此也可以用于部署類似大數據和AI應用的計算或者I/O資源密集型的應用。

一個大的云平臺可能需要高效穩定地運行數萬個容器，這就需要非常強大的服務編排系統。為了滿足日益增多的服務和任務的資源需求，Borg、Mesos、Omega等一系列的集群資源調度系統相繼出現。其中，Borg是集中式調度器的代表，其作為集群調度器的鼻祖，在Google公司有超過10年的生產經驗，其上運行了GFS、BigTable、Gmail、MapReduce等各種類型的任務。Mesos是雙層調度器的代表，可以讓多個框架公平地共享集群資源。Omega則是共享狀態調度器的代表，它的特點是支持使用不同的調度器調度不同類型的任務，解決資源請求沖突的問題。

Kubernetes是Google開源用來管理Docker集群的項目，繼承了Borg的優點，實現了編排、部署、運行以及管理容器應用的目的，Kubernetes的總體架構如圖1所示。Kubernetes提供資源池化管理，可以將整個集群內的中央處理器（center processing unit，CPU）、圖形處理器（graphic processing unit，GPU）、內存、網絡和硬盤等資源抽象為一個資源池，可以根據應用的資源需求、資源池中的實時資源情況進行靈活調度；Kubernetes包含一個統一的調度框架，最多可以管理數千個服務器和數萬個容器，同時提供插件化的接口，讓第三方來定制和擴展新的調度系統；此外Kubernetes支持通過ConfigMap等方式動態地調整應用配置，從而具備動態調配的基礎能力。

本文基于這些基礎技術開發了支持復雜應用平臺的調度系統。

圖1???Kubernetes的總體架構

3 大數據和AI計算模型

分布式計算在復雜的工業應用需求下快速迭代和發展，從離線處理的MapReduce計算模型開始，逐漸發展出了以Spark為代表的在線計算（Spark、Tez、Druid等）以及實時計算模型（Flink、Spark Streaming等）。新的分布式計算模型開拓了新的應用領域，同時也對大規模系統的管理、調度和運維提出了較大的挑戰。

3.1 MapReduce

MapReduce框架是Hadoop技術的核心，它的出現在計算模式歷史上是一個重大事件，在此之前行業內主要通過MPP的方式增強系統的計算能力，一般是利用復雜而昂貴的硬件加速計算，如高性能計算機和數據庫一體機等。而MapReduce是通過分布式計算來提高計算速度的，并且只需要廉價的硬件就可以實現可擴展的、高并行的計算能力。

3.2 Spark

隨著大量的企業開始使用Hadoop構建企業應用，MapReduce性能慢的問題逐漸成為研究瓶頸，MapReduce只能用于離線數據處理，而不能用于對性能要求高的計算場景，如在線交互式分析、實時分析等。在此背景下，Spark計算模型誕生了。雖然本質上Spark仍然是一個MapReduce計算模式，但是幾個核心的創新使得Spark的性能在迭代計算應用中比MapReduce快一個數量級以上：第一，數據盡量通過內存進行交互，相比基于磁盤的交換，能夠避免I/O帶來的性能問題；第二，采用延時評估（lazy evaluation）的計算模型和基于DAG的執行模式，可以生成更好的執行計劃。此外，通過有效的檢查點（check pointing）機制可以實現良好的容錯機制，避免內存失效帶來的計算問題。

3.3 TensorFlow

TensorFlow是Google公司開發的第二代人工智能學習系統，它可以將復雜的數據結構傳輸至人工智能神經網絡中進行分析和處理，可用于語音識別、圖像識別等多項機器學習和深度學習任務，并且完全開源，目前也是開源社區活躍的開發項目之一。TensorFlow支持異構設備的分布式計算，可以在各個平臺上自動運行模型，支持在手機、單個CPU/GPU、大型數據中心服務器等各種設備上運行。

4 原生云與大數據、AI融合的技術難點和解決思路

4.1 基于容器云開發大數據或AI產品的技術難點

原生云平臺的一個主要特點是面向微服務設計，使用容器的方式編排普通的Web應用或者微服務。但是大數據或者AI計算平臺本身并沒有采用微服務設計，各個系統都采用自身的分布式系統設計完成服務的管理和調度，并且執行時服務會一直變化。以MapReduce為例，每個MR程序啟動Map或者Reduce工作任務的數量是由應用本身來指定的（通過參數set mapreduce.reduce.tasks=N），調度器通過解析相關的參數來生成給定數量的工作任務，并在相關的任務完成后立即銷毀。

大數據系統內的服務有自己的服務重啟或者遷移邏輯，并且其配置或參數可能會隨著應用或用戶的輸入而變化，而很多組件之間有很長的依賴鏈，如何及時地將某個參數的變化推送到所有的下游服務中，是調度系統的一個重要挑戰。

對于沒有數據存儲的無狀態服務，容器有多種編排方式進行編排和管理。但是對于有數據狀態的服務，如數據庫（MySQL）或者分布式存儲服務（Hadoop distributed file system，HDFS），由于容器內的數據會隨著容器的銷毀而銷毀，因此采用傳統的編排方式無法保證數據狀態的一致性和數據持久化。

大數據和AI計算都涉及大量的數據和復雜的迭代運算，為了達到更好的性能，MapReduce、Spark和TensorFlow在架構中都特別注重“計算貼近數據”設計，一般會根據數據的位置選擇啟動相應的計算服務，盡量讓計算任務和數據節點在同一個節點上，這樣就可以避免網絡帶寬帶來的性能損失。而在容器模式下，不同的服務封裝在不同的容器內，并且使用容器自身的網絡；而容器網絡一般采用重疊網絡（overlay network）模式，因此容器內的應用并不能感知調度容器的機器的物理拓撲，因此也就無法確定從哪個節點調度計算任務所在的容器。為此，重新設計了云網絡服務，以有效解決相應的調度信息缺失問題。

另外，大數據或者AI應用都是資源密集型應用，在運行時會對CPU、GPU、內存、磁盤、網絡等資源進行動態申請和釋放。如某個應用可能會根據用戶的輸入生成一個Spark的機器學習任務，在大數據平臺上生成若干個執行任務（executor），并申請一定的CPU和內存資源。及時地響應這些短生命周期服務的資源需求，是當前各種原生云的調度系統無法有效支持的功能。

4.2 融合大數據和AI的云調度系統的設計考量

為了有效解決各種實際技術難題，重新設計云平臺的調度系統成為必須考慮和完成的工作。相較于原生的Kubernetes調度系統，云平臺的調度系統需要從以下方面重新設計。

（1）基于資源需求的調度能力

整個云平臺的資源從邏輯上被抽象為一個大的資源池，按照CPU、GPU、內存、存儲和網絡進行分類管理。一個容器在被調度的時候，通過編排文件或者配置來描述相應的資源需求。調度器需要根據資源池的實際資源情況和各個主機的物理資源情況，在毫秒級時延內找到合適的物理節點來調度當前容器。在超大規模的云集群里，調度器的效率、性能和負載均衡是重要的技術指標，最終會影響云平臺的資源使用率。

（2）支持本地存儲并基于存儲感知的容器調度

為了有效支持有狀態的服務，如數據庫服務（MySQL）、分布式存儲服務，本文設計了基于本地存儲的存儲服務。云儲存將所有的存儲資源抽象為一個存儲池，每個節點的本地存儲抽象為若干持久化存儲池（persistence volume group），而單個可以被容器申請的存儲資源定義為存儲卷（persistence volume，PV）。每個PV只能被一個容器掛載，可以是任意大小，支持硬盤驅動器（hard disk drive，HDD）或固態硬盤（solid state drive，SSD），也支持HDD與SSD組成的分層式存儲。有狀態的容器服務在啟動時會申請需要的PV資源（如大小、IOPS要求、SSD或HDD），調度器需要在毫秒內從平臺內找到合適的機器，從而將容器調度起來；如果容器因為各種原因不能正常工作，調度器能夠檢測到不健康的狀態，同時根據數據的物理拓撲情況，選擇合適的機器重啟相應的容器。

（3）網絡物理拓撲的感知與實時調度能力

為了支持靈活彈性的調度，一般情況下云原生平臺為容器設計專門的網絡空間，并且一般與主機網絡保持透明。通常一個服務器節點上會有多個容器服務，因此主機IP的數量遠小于容器IP的數量。在MapReduce、Spark和TensorFlow的設計中，在啟動計算任務時，會根據數據存儲的物理拓撲決定最終服務啟動在哪個服務器上。但是在容器平臺上，所有的任務都只能感知容器網絡，而不能感知物理機器的IP，無法了解數據分布的物理拓撲，因此也就無法保證計算和數據的局部性。為了解決這個問題，在調度系統內增加了網絡物理拓撲模塊，實時地維護物理IP和容器IP的映射關系表。當有狀態服務在申請調度的時候，可以通過IP映射表找到可用于最終調度的物理機器。

（4）動態標簽能力與基于標簽的調度能力

復雜的應用系統對調度系統有更多細節的要求，如多租戶業務系統往往要求一個租戶的所有服務盡量調度在同一批物理機器中；支持高可用的服務往往要求調度系統有反親和性（anti-affinity）要求，即將一個服務的多個實例調度到不同的物理機器上，這樣就不會發生一個物理機器宕機后影響多個高可用實例，進而導致服務不可用的情況。因此在調度系統中增加了動態標簽能力和基于標簽的調度能力，調度模塊可以根據運行時的數據給物理機器和容器應用動態增加或刪除標簽，而調度系統根據標簽的匹配度選擇更合適的調度策略。

（5）應用依賴運行參數的感知以及基于參數的調度能力

分布式應用在微服務拆分后，每個服務都有比較復雜的依賴服務鏈以及影響的服務鏈，而每個微服務在運行時都可能發生運行參數變化、服務啟停、重新調度等操作，這些變化不僅影響當前的微服務，還可能影響所有的依賴鏈的服務。因此調度系統中增加了應用配置感知模塊，通過與全局的配置中心的數據交互，調度系統能夠實時地感知一個應用變化的事件的所有影響情況，并根據多個可能的狀態遷移圖選擇最合適的調度策略。

（6）不同優先級下基于搶占的調度能力

在業務負載比較重并可能超過云系統內資源總量的時候，需要有機制保證高優先級的服務正常運行，犧牲低優先級應用的服務質量，也就是服務質量等級保證（service level agreement，SLA），這是云平臺的一個重要特性。在調度系統內增加了基于搶占的調度模式，將服務和資源按照優先級進行區分，如果出現資源不足以調度高優先級應用的情況，則通過搶占的方式調度低優先級應用的資源。

5 融合大數據和AI的云調度系統的實現

類似于操作系統的調度模塊，云平臺的調度是整個云平臺能夠有效運行的關鍵技術。云平臺的總體架構如圖2所示，最底層是Kubernetes服務，其上層運行著自研的幾個產品或服務。其中，配置中心用于實時地收集和管理云平臺內運行的所有服務的配置參數，支持運維人員手動地對一些服務進行參數設置或管理；物理資源池是通過各個服務進行池化后的邏輯資源，應用申請的物理資源都會從這個資源池中邏輯地劃分出去，在應用使用完結后再返還給資源池，平臺會給不同的租戶做資源配額限制；云存儲服務是基于本地存儲開發的分布式存儲服務，會保留狀態服務的數據，保證應用數據的最終持久化和災備能力；云網絡服務是自研的網絡服務，提供應用和租戶類似虛擬私有云（virtual private cloud，VPC）的網絡能力，可以做到完整的資源隔離和服務等級協議（service level agreement，SLA）管控；標簽中心用于實時地收集和管理各個應用、主機、資源的標簽，支持動態的標簽修改與實時調度觸發。

在此之上是云調度系統，它接收應用的輸入，從配置中心、標簽中心、云存儲服務和云網絡服務中實時獲取平臺運行指標，并從物理資源池中獲取資源的使用情況，從而根據運行時的信息進行精確的調度決策。云調度系統之上是各類應用服務，包括大數據、AI、數據庫類以及各種微服務。

圖2???調度系統的總體架構

5.1 調度系統架構

本文設計的云平臺的調度系統的內部架構如圖3所示，包含元信息模塊、對外服務模塊以及調度決策模塊。當一個應用通過Kubernetes API或者命令行（基于Kubectl）的方式啟動時，它會傳入一個指定服務編排方式的yaml文件以及啟動應用需要的容器鏡像（docker image）。在yaml文件中會指定當前應用需要的資源、與調度相關的標注信息（或標簽信息）以及對其他應用的依賴關系。

對外服務模塊負責解析編排文件，同時負責完成應用的依賴解析和管理，生成對服務的依賴圖；參數計算模塊負責編排文件中與配置變量相關的計算，并生成最終的資源需求；實例渲染模塊最終生成一個完整的應用描述，并將這個描述文件提交給調度決策模塊。

元信息模塊負責與Kubernetes平臺交互，實時地維護用于調度的各種元數據。資源池數據主要包括當前集群的各種資源總量以及當前的使用情況，并可以精細到各個節點和硬盤級別；網絡拓撲模塊負責與容器網絡進行交互，實時地維護當前容器網絡與主機網絡的拓撲；存儲拓撲模塊負責與云存儲服務交互，實時記錄當前存儲池的各個存儲卷（PV）的容量使用情況和每秒進行讀寫操作的次數（input/output operations per second，IOPS）；服務運行指標主要同步當前集群各個物理節點上各個容器的運行指標以及各個物理機的各項資源的使用指標；配置元數據模塊主要協助配置中心維護各個應用的實時配置參數。因此，通過元信息模塊，調度器能夠維護當前云平臺的各種調度決策數據，從而實時地根據運行數據進行最優化調度。

在對外服務模塊提交了實時渲染的應用描述請求后，調度決策模塊會根據請求中的資源大小，通過內部的6個調度器進行調度目標的選擇。依賴調度器會解析應用的需求，同時遍歷當前的服務元數據，查找是否有已經運行的可以給當前應用依賴的微服務。如果有，則直接使用該服務，并更新相應的配置參數；如果沒有，則解析被依賴的服務的參數，同時選擇運行一遍完整的調度流程。如果有嵌套服務依賴，則遞歸調用相關的調度邏輯，直至所有依賴鏈的服務都處于運行狀態。存儲調度器提供基于存儲感知的容器調度能力，它會解析應用是否有明確的本地數據的要求，如果有，則從存儲拓撲中找到合適的物理節點組，并將其他節點標記為此次調度無效；資源調度器負責找到有足夠資源啟動應用或者容器的物理節點組；網絡調度器負責根據應用的網絡IP要求選擇滿足網絡規則的物理節點組；標簽調度器負責選擇滿足各種標簽規則的物理節點組。通過這5個調度器選擇的物理節點如果有多個，調度器則根據負載均衡的原則選擇合適的物理節點，從而啟動這個容器；如果沒有任何節點有足夠的資源，SLA調度器會遍歷被選擇指定節點上已經在運行的所有容器，找到當前被優先級更低的應用占用的容器，并選擇kill等機制，循環此操作，直到資源滿足本次調度為止，從而實現高優先級應用的搶占式調度策略。

圖3???調度系統的內部架構

5.2 服務的編排系統

應用服務的調度需求包含依賴的服務、服務自身的Docker鏡像、資源需求、網絡與存儲需求、配置參數等各個方面的屬性，因此選擇Jsonnet語言進行應用的資源描述文件。Jsonnet是Google公司開源的新一代JSON協議，支持引用、算術運算、條件操作符、函數、變量、繼承等強大的計算能力，可以描述多樣化的需求。

一個簡單的基于Jsonnet的資源編排文件示例如圖4所示。其中app.yaml 描述依賴關系和依賴變量，config.jsonnet描述配置參數和定義輸入，而customizemain.jsonnet 定義模板入口和輸出變量。在運行時，通過服務模塊的實例渲染組件即可將這些編排文件和當前平臺內的運行參數進行實例化，渲染出一個可以被Kubernetes調度的service/replication controller或者deployment的描述文件。

圖4???基于Jsonnet的資源編排文件示例

5.3 配置標簽中心

由于每個服務運行時都可能發生重啟或者遷移，且API網關等可能會動態地設置運行參數，為了讓服務能夠及時地感知各種運行參數，創建了一個統一的配置標簽中心作為中心化的服務，提供配置和標簽元數據的管理和查詢。應用程序使用的配置基于Kubernetes ConfigMap的方式來實現配置與容器鏡像的解耦。ConfigMap的示例如圖5所示，包含了標簽和數據屬性，都是以鍵-值數據對的方式來保存的。容器可以直接引用相應的ConfigMap中的數據，而這些配置數據則存儲在配置標簽中心服務中。用戶可以通過界面或者命令行的方式修改配置的數值或者增加新的鍵-值對，并且當有任何配置數據修改后，Kubernetes會動態地修改每個節點的ConfigMap文件，并在短時間內讓容器知曉相應的數據變化，從而實現中心化的動態配置和標簽修改。

由于配置和標簽中心服務中包含了運行時的各種配置和標簽數據，因此調度器通過與配置標簽中心交互就可以獲取整個云平臺的標簽和配置元數據，從而可以支持基于標簽的調度能力。

圖5???ConfigMap的示例

5.4 云存儲服務

云平臺中的存儲服務Warpdrive提供一個中心化的RESTful服務，可以支持外部服務對存儲卷的實際使用情況的實時查詢，因此調度器通過監聽相關的接口來實時感知每個主機的存儲卷使用情況以及每個容器與物理節點的綁定關系。

5.5 云網絡服務

網絡服務也同樣提供RESTful API查詢服務，使得調度器可以知曉各個容器IP和物理IP的使用情況以及各個容器的網絡防火墻規則等實時數據，因此調度器能夠實時地感知云平臺內的網絡和存儲實際運行情況。

5.6 計算調度過程中的數據拓撲感知

在容器云計算環境下，分布式網絡中的各個主機可以是一個或多個獨立的網絡，每個網絡都可以包括一個或多個子網絡，網絡地址從該主機上的子網絡中獲得。當容器銷毀時，容器的網絡地址被回收，等待下次使用。

應用感知數據拓撲的方式如圖6所示，當容器中的數據應用（如Spark應用）需要啟動計算任務時，調度器首先根據該服務的依賴關系找到其需要的數據應用的容器（如HDFS數據節點），然后通過元信息模塊查詢其所在的物理節點的網絡和存儲信息。元信息模塊通過對存儲服務和網絡服務的實時查詢來獲取和維護最新的元數據。一般情況下，分布式存儲有多個存儲副本，會通過調度器的反親和性保證調度在不同的物理節點上，因此調度器會得到一個物理節點的列表。然后根據這幾個節點的實際資源使用負載情況，選擇當前資源負載最低的節點來啟動對應的計算服務容器。由于兩個容器都在一個主機上，計算服務可以與存儲服務通過本地網絡進行數據傳輸，或者創建域套接字（domain socket）等機制來提高數據讀取速度，增強性能。

在云平臺集群規模比較大的情況下，網絡IP數量和網段數量都比較大，而應用查詢的請求也有很高的并發度。為了保證高速的網絡檢索能力，使用基數樹（radix tree）對各個應用的網絡配置信息進行緩存，基于基數樹的快速匹配方法如圖7所示。查詢網絡地址172.16.1.23，對應的二進制是10101100000100000000000100 010111，在基數樹中可以很快匹配到對應的子網為172.16.1.0/24，并從該子網獲取所有必需的網絡信息，包括容器網段、主機信息、交換機號以及機架位等。

圖6???應用感知數據拓撲的方式

圖7???基于Radix Tree的快速匹配方法

5.7 調度的總體流程

對于調度策略模塊，它的輸入是應用的資源需求、標簽屬性、依賴關系和輸入輸出參數等信息，輸出是選定的物理節點或者節點組以及對應的容器的優先級信息，同時，依賴元數據模塊提供的平臺運行數據進行調度決策支撐。調度器的決策流程如圖8所示。

調度器從任務調度隊列獲取待調度的任務，形成節點-任務映射表。其中，調度器持續對API服務器中創建的任務進行監聽，并讀取新的任務形成任務調度隊列。

（1）篩選階段

調度器根據映射表以及預設篩選條件確定一組符合條件的目標物理節點。其中，預設篩選條件可以是當前任務所需的資源與物理節點上的剩余資源之間的匹配條件、當前任務所需的端口與物理節點上的端口之間的匹配條件以及是否帶有特殊標簽等。如果當前任務配置了對持久化存儲的需求或者對數據拓撲的感知，調度器也會考慮滿足這些條件的節點。最終調度器會將滿足上述所有篩選條件的節點整理出來進行下一步處理。

（2）優選階段

調度器根據篩選階段拿到的節點以及預設優選條件對各個物理節點進行評分，最終選擇分數最高的作為目標物理節點。其中優選條件包括：節點空閑資源越多，評分越高；節點保存的任務鏡像越多，評分越高；任務親和性/反親和性越匹配，評分越高；同類任務分布越均勻，評分越高等。

通過上述兩次篩選，選擇出一個分數最高的物理節點。調度器將當前任務與目標物理節點綁定，并將綁定的信息發送到API服務器。

圖8???調度器的決策流程

5.8 基于優先級的搶占式調度方法

在平臺的資源不足而有更高優先級的服務需要被調度的情況下，調度器就需要進行搶占式調度。在目前的實現中，搶占式調度提供了2種方式：調度階段的資源搶占和運行階段的資源搶占。

調度階段的資源搶占即在調度器篩選節點階段，如果發現集群中所有節點都無法滿足當前任務的資源需求，調度器會在集群中選擇節點，并試圖搶占其中正在運行的低優先級的任務的節點。搶占完成后，調度器會再次嘗試調度當前任務到目標節點上。調度階段的資源搶占策略如圖9所示。

圖9???調度階段的資源搶占策略

調度階段的資源搶占實際上是一種邏輯層面的搶占，依據是任務在啟動時聲明的資源請求，它可以幫助系統避免任何資源超配的現象，但同時也會造成一定程度的資源浪費。比如一個聲明了10 core CPU的任務可能當前只消耗了2 core CPU，此時完全不需要搶占掉，它也可以讓別的任務運行起來。基于此種考慮，又引入了運行階段的資源搶占算法，如圖10所示。運行階段的資源搶占的主線程邏輯如圖11所示。

圖10???運行階段的資源搶占算法

圖11???運行階段的資源搶占的主線程邏輯

運行階段的資源搶占會忽略優先級低于當前任務的任務，即如果有必要，可以完全搶占這些低優先級的任務，因此它們不在節點資源消耗的統計范圍內。搶占階段發生在物理節點上，當物理節點發現某種資源剩余小于預期值時，會對其上低優先級的任務進行清除，直到物理節點狀態恢復正常。此種搶占方式基于物理節點的資源真實使用情況，可以保證集群資源利用最大化。

6 實驗評估

為了驗證數據應用尤其是大數據計算在云平臺上有良好的性能表現，選擇了3個基準測試程序來驗證所設計實現的系統的性能。

● TestDFSIO是Hadoop自帶的性能測試工具，主要為了測試Apache HDFS的I/O性能，采用MapReduce程序進行并發讀寫并做結果統計，主要涉及讀、隨機讀、追加寫、寫等業務行為。

● HBase Performance Evaluation是Apache HBase自帶的性能測試工具，提供了順序讀寫、隨機讀寫、掃描等性能測試。

● TPC-DS是事物處理性能委員會（Transaction Processing Performance Council，TPC）推出的用于數據決策支持系統的基準測試，包含對大數據集的統計、報表生成、聯機查詢、數據挖掘等復雜應用，包含了7張事實表、17張維度表和99個復雜SQL，是一個典型的數據倉庫的測試場景，可以用于衡量大數據分析數據庫的性能和魯棒性。

選定好基準測試后，在50臺x86服務器上部署了云平臺，并且創建了3個不同的租戶用于測試，每個租戶都將部署Hadoop服務以及分析數據庫Inceptor，HBase分片服務器、HDFS數據節點和Inceptor任務執行節點都有8個實例。本次測試的設計目標和期望結果見表1。

● 第一個租戶：通過修改標簽中心的配置參數讓其所有的服務只能在節點1~10上調度。

● 第二個租戶：通過修改標簽中心的配置參數讓其可以在平臺的50臺機器上調度，同時設置其優先級比其他微服務的優先級高。

● 第三個租戶和第二個租戶配置相同，也可以在50臺機器上調度，但是通過修改云平臺的調度測試，讓其使用Kubernetes原生的調度系統，為了解決開源Kubernetes平臺沒有本地存儲的問題，在所有的節點上都部署了同樣的數據，保證任何調度到其他節點機器上的服務都能讀到數據，從而確保測試可以正常運行。

● 在8個節點的裸機上部署了Hadoop服務和Inceptor，采用主機的方式部署，每個節點上部署數據節點、HBase分片服務器和Inceptor任務執行節點，所有的數據和計算服務都預先按照物理拓撲劃定好，因此沒有其他的調度開銷。

本文沒有單獨針對調度系統的每個設計指標進行測試，這些設計能力都會在這個綜合的性能測試里被驗證，如基于資源需求的調度能力、應用依賴和運行參數感知能力，因為大數據平臺本身是分布式系統，多個服務之間存在互相依賴（如HDFS依賴ZooKeeper）的關系，每個服務通過自己的編排文件指定自己需要的硬件資源以及依賴的服務，如果不具備這方面的能力，大數據服務就無法在平臺上運行起來。基于網絡拓撲和物理存儲的調度能力以及不同優先級的搶占能力會比較多地在性能測試結果中反映出來。

按照預期，主機部署的模式應該是性能最好的方式，其次是租戶1，因為它只能在較少的節點內調度，發生計算數據分離的概率比較小；租戶2和租戶3在50個節點內有8個數據節點，如果不用新的調度算法，發生計算和數據偏離的可能性比較大，但是期望租戶2的性能比較好，可以接近租戶1，因為調度系統可以支持計算來感知數據，而租戶3的性能會比較差，因為沒有數據本地性的保證。

最終的測試結果如圖12所示，基本符合預期。在裸機上部署的集群在3個測試里的性能都是最佳的；租戶1和租戶2的3個測試的性能數據不相上下（差異可以認為是數據波動），說明本文的調度算法有很好的可擴展性，在集群規模擴大5倍后可以保證性能沒有損失；租戶3的性能要差很多，因為計算任務和數據分布是無序的，所以有很多遠程讀寫帶來的性能損失。實驗證明，有效的調度系統可以在保證云平臺的靈活性和彈性的同時，提供和物理平臺部署一樣的性能。

圖12???性能測試結果數據

7 結束語

目前工業界在如何解決大數據和AI應用在云上的開發和部署問題上，基本分為3種。

第一種是采用應用或者服務內多租戶的方式提供云服務，即一個數據庫或者AI服務的實例給用戶提供服務，用戶之間的隔離由數據庫或者AI平臺來提供，而不是由云平臺提供。比較典型的有AWS Aurora或者Google Cloud AutoML等產品。這類解決方案靈活性不高，而且由于本身計算復雜度不高或者通過SaaS服務的方式規避了復雜業務的提交，因此也可以適應業務的需求。但是這兩類產品更偏向于一類應用，而不是通用的大數據或者數據庫平臺，因此這種方式雖然解決了部署的問題，但是不通用，只能由云服務的運營商來提供相應的解決方案。

第二種是在云平臺中使用單獨的裸金屬機器提供大數據或者AI服務，這樣可以保證大數據或者AI平臺的性能，但是同時放棄了對彈性或者靈活性的要求，因此這部分裸金屬機器并不能實現良好的彈性調度和高效的運維能力。

第三種是容器平臺只負責調度微服務等無狀態類應用，而大數據、AI平臺運行在傳統的基于虛擬化的云上。這樣可以保證良好的調度能力，但是犧牲了大數據或者AI平臺的穩定性。這個方法最簡單，但是在現實案例中也發現這個方法因為穩定性等問題，幾乎沒有成功的落地案例。

本文討論了與以上3種云調度方案完全不同的全新的方式，即如何在容器云平臺上實現一個支持復雜的大數據和AI平臺服務的調度系統，既能保證復雜的平臺應用的性能，又能夠有很好的調度靈活性和運維便利性。從實驗結果來看，本文的設計最終在生產平臺上取得了符合預期的業務性能數據，也證明了這個調度方法的有效性。不過受限于本系統的工程背景，本文是在實踐中逐步優化了本調度系統，而不是從理論上根據調度系統的各個指標來設計系統。另外由于業務需求的驅動，本文的設計強調數據的局部性和決策的實時性，要求所有的調度決策在毫秒級完成，弱化了調度的公平性設計，而另外一些調度算法更側重公平性。

從另外一個維度，本文提出的調度系統的設計目標是給應用提供更好的性能，因此會犧牲一些其他的指標，如低優先級任務的可靠性。如為了在有數據節點的服務器上調度計算任務，會增加搶占對應節點上其他低優先級服務的概率，因而需要云平臺上的微服務有更好的容錯能力。考慮到計算任務也會有一些數據的操作，根據HDFS的特性，一般情況下在有更多計算任務的節點上就可能有更多的數據寫入，這就要求平臺對數據的生命周期有良好的管理能力，否則可能會有部分節點數據量越積越多，從而使得整個云平臺出現數據分布不均衡的情況，需要定期進行人為觸發的重新平衡行為。

本文主要描述了一個適用于容器云平臺的調度系統，它通過實時獲取Kubernetes集群的各種資源數據，結合數據和計算的拓撲特性，可以在容器平臺上有效地支持大數據與人工智能的應用和服務，在帶來彈性和靈活性的同時，提供了與裸機部署相同的性能，能夠同時提供云計算的彈性和大數據的計算能力。通過有效的調度設計，基于容器的云平臺不僅可以用于微服務類應用的DevOps支持，還可以用于大數據平臺以及應用的開發和部署，支持大規模數據服務和AI服務的自動化部署和靈活調度。云計算提供基礎，大數據提供生產資料，AI提供價值輸出，因此，能夠同時支持大數據+AI的云平臺是未來的趨勢，也是下一代數據中心的技術基礎平臺。

大規模的云平臺調度是一個非常復雜的技術問題，需要反復的基于經驗的調優和迭代才能夠達到比較好的效果。本文的方法和實驗是對多個實際運行項目中積累的觀測數據和性能指標進行迭代而最終成型的，目前本文的調度系統主要調優的場景是大數據平臺服務（如Spark、Hadoop、TensorFlow等）以及數據分析類微服務（如各種分析類報表、實時事件分析、在線模型等）在云平臺上的混合部署場景，而沒有考慮更多的復雜的服務混合場景（如復雜的OLTP數據庫業務），因此在其他的云業務場景下可能還有迭代的過程。希望在下一階段引入更多的負載場景使得調度算法更加通用化。

如何將人工智能應用在調度系統中是另外一個有價值的研究方向，調度系統能夠監控當前云平臺的各種資源指標以及服務的性能指標，可以通過對歷史調度數據引入AI分析能力，對各個服務進行畫像（如其生命周期可以分為活躍時間段和非活躍時間段等，不同的時間段對應不同的調度屬性），從而讓調度器可以更好地均衡調度所有的服務；預測節點以及平臺在某個時間段的負載分布，并基于這些數據進行決策，如提供服務的時分復用調度策略，從而進一步提高云平臺的資源使用率，降低企業的IT成本。

作者簡介

劉汪根（1985－），男，星環信息科技（上海）有限公司研發總監、總架構師，主要研究方向為新一代的大數據架構、分布式數據庫技術和容器云等 。

鄭淮城（1987-），男，星環信息科技(上海)有限公司軟件工程師，星環原生云操作系統研發負責人，主要研究方向為復雜業務場景的底層容器云技術工程化 。

榮國平（1977-），男，博士，南京大學軟件學院副研究員，主要研究方向為DevOps、微服務架構、虛擬化技術等 。

《大數據》期刊

《大數據（Big Data Research，BDR）》雙月刊是由中華人民共和國工業和信息化部主管，人民郵電出版社主辦，中國計算機學會大數據專家委員會學術指導，北京信通傳媒有限責任公司出版的中文科技核心期刊。

關注《大數據》期刊微信公眾號，獲取更多內容

往期文章回顧

基于安全壓縮感知的大數據隱私保護

基于同源策略的移動應用細粒度隱私保護技術

人工智能時代的數據隱私、壟斷與公平

人工智能風險分析技術研究進展

監督學習中的損失函數及應用研究

---

總結

以上是生活随笔為你收集整理的云环境下大规模分布式计算数据感知的调度系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。