云環(huán)境下大規(guī)模分布式計(jì)算數(shù)據(jù)感知的調(diào)度系統(tǒng)

劉汪根，鄭淮城，榮國平

1. 星環(huán)信息科技（上海）有限公司，上海 200233；2. 南京大學(xué)軟件學(xué)院，江蘇 南京 210093

1 引言

隨著云計(jì)算、大數(shù)據(jù)與人工智能（artificial intelligence，AI）技術(shù)的發(fā)展以及行業(yè)對這3種技術(shù)的綜合應(yīng)用需求，目前國內(nèi)外出現(xiàn)了大數(shù)據(jù)、云計(jì)算、人工智能三者相互融合的技術(shù)發(fā)展趨勢。中國計(jì)算機(jī)學(xué)會大數(shù)據(jù)專家委員會在2019年大數(shù)據(jù)發(fā)展趨勢調(diào)查報(bào)告中指出：人工智能、大數(shù)據(jù)、云計(jì)算將高度融合為一體化系統(tǒng)[1]。

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

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

2 云原生

云原生（cloud native）[4]是指在應(yīng)用開發(fā)時(shí)，以云作為其生產(chǎn)部署方式，從而充分利用云的彈性、可擴(kuò)展、自愈等核心優(yōu)勢。區(qū)別于傳統(tǒng)的臃腫的單體應(yīng)用開發(fā)模式，云原生應(yīng)用因?yàn)槠溆行У膮f(xié)同開發(fā)、測試和運(yùn)維，極大地提高了軟件開發(fā)效率和質(zhì)量，支持產(chǎn)品快速地上線和迭代，已經(jīng)成為當(dāng)前主流的應(yīng)用開發(fā)模式。

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

一個(gè)大的云平臺可能需要高效穩(wěn)定地運(yùn)行數(shù)萬個(gè)容器，這就需要非常強(qiáng)大的服務(wù)編排系統(tǒng)。為了滿足日益增多的服務(wù)和任務(wù)的資源需求，Borg[5]、Mesos[6]、Omega[7]等一系列的集群資源調(diào)度系統(tǒng)相繼出現(xiàn)。其中，Borg是集中式調(diào)度器的代表，其作為集群調(diào)度器的鼻祖，在Google公司有超過10年的生產(chǎn)經(jīng)驗(yàn)，其上運(yùn)行了GFS[8]、BigTable[9]、Gmail、MapReduce[10]等各種類型的任務(wù)。Mesos是雙層調(diào)度器的代表，可以讓多個(gè)框架公平地共享集群資源。Omega則是共享狀態(tài)調(diào)度器的代表，它的特點(diǎn)是支持使用不同的調(diào)度器調(diào)度不同類型的任務(wù)，解決資源請求沖突的問題。

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

本文基于這些基礎(chǔ)技術(shù)開發(fā)了支持復(fù)雜應(yīng)用平臺的調(diào)度系統(tǒng)。

3 大數(shù)據(jù)和AI計(jì)算模型

分布式計(jì)算在復(fù)雜的工業(yè)應(yīng)用需求下快速迭代和發(fā)展，從離線處理的MapReduce[5]計(jì)算模型開始，逐漸發(fā)展出了以Spark為代表的在線計(jì)算（Spark、Tez[11]、Druid[12]等）以及實(shí)時(shí)計(jì)算模型（Flink[13]、Spark Streaming[14]等）。新的分布式計(jì)算模型開拓了新的應(yīng)用領(lǐng)域，同時(shí)也對大規(guī)模系統(tǒng)的管理、調(diào)度和運(yùn)維提出了較大的挑戰(zhàn)。

3.1 MapReduce

MapReduce框架是Hadoop技術(shù)的核心，它的出現(xiàn)在計(jì)算模式歷史上是一個(gè)重大事件，在此之前行業(yè)內(nèi)主要通過MPP的方式增強(qiáng)系統(tǒng)的計(jì)算能力，一般是利用復(fù)雜而昂貴的硬件加速計(jì)算，如高性能計(jì)算機(jī)和數(shù)據(jù)庫一體機(jī)等。而MapReduce是通過分布式計(jì)算來提高計(jì)算速度的，并且只需要廉價(jià)的硬件就可以實(shí)現(xiàn)可擴(kuò)展的、高并行的計(jì)算能力。

3.2 Spark

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

3.3 TensorFlow

TensorFlow[15]是Google公司開發(fā)的第二代人工智能學(xué)習(xí)系統(tǒng)，它可以將復(fù)雜的數(shù)據(jù)結(jié)構(gòu)傳輸至人工智能神經(jīng)網(wǎng)絡(luò)中進(jìn)行分析和處理，可用于語音識別、圖像識別等多項(xiàng)機(jī)器學(xué)習(xí)和深度學(xué)習(xí)任務(wù)，并且完全開源，目前也是開源社區(qū)活躍的開發(fā)項(xiàng)目之一。TensorFlow支持異構(gòu)設(shè)備的分布式計(jì)算，可以在各個(gè)平臺上自動運(yùn)行模型，支持在手機(jī)、單個(gè)CPU/GPU、大型數(shù)據(jù)中心服務(wù)器等各種設(shè)備上運(yùn)行。

4 原生云與大數(shù)據(jù)、AI融合的技術(shù)難點(diǎn)和解決思路

4.1 基于容器云開發(fā)大數(shù)據(jù)或AI產(chǎn)品的技術(shù)難點(diǎn)

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

大數(shù)據(jù)系統(tǒng)內(nèi)的服務(wù)有自己的服務(wù)重啟或者遷移邏輯，并且其配置或參數(shù)可能會隨著應(yīng)用或用戶的輸入而變化，而很多組件之間有很長的依賴鏈，如何及時(shí)地將某個(gè)參數(shù)的變化推送到所有的下游服務(wù)中，是調(diào)度系統(tǒng)的一個(gè)重要挑戰(zhàn)。

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

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

另外，大數(shù)據(jù)或者AI應(yīng)用都是資源密集型應(yīng)用，在運(yùn)行時(shí)會對CPU、GPU、內(nèi)存、磁盤、網(wǎng)絡(luò)等資源進(jìn)行動態(tài)申請和釋放。如某個(gè)應(yīng)用可能會根據(jù)用戶的輸入生成一個(gè)Spark的機(jī)器學(xué)習(xí)任務(wù)，在大數(shù)據(jù)平臺上生成若干個(gè)執(zhí)行任務(wù)（executor），并申請一定的CPU和內(nèi)存資源。及時(shí)地響應(yīng)這些短生命周期服務(wù)的資源需求，是當(dāng)前各種原生云的調(diào)度系統(tǒng)無法有效支持的功能。

4.2 融合大數(shù)據(jù)和AI的云調(diào)度系統(tǒng)的設(shè)計(jì)考量

為了有效解決各種實(shí)際技術(shù)難題，重新設(shè)計(jì)云平臺的調(diào)度系統(tǒng)成為必須考慮和完成的工作。相較于原生的Kubernetes調(diào)度系統(tǒng)，云平臺的調(diào)度系統(tǒng)需要從以下方面重新設(shè)計(jì)。

（1）基于資源需求的調(diào)度能力

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

（2）支持本地存儲并基于存儲感知的容器調(diào)度

為了有效支持有狀態(tài)的服務(wù)，如數(shù)據(jù)庫服務(wù)（MySQL）、分布式存儲服務(wù)，本文設(shè)計(jì)了基于本地存儲的存儲服務(wù)。云儲存將所有的存儲資源抽象為一個(gè)存儲池，每個(gè)節(jié)點(diǎn)的本地存儲抽象為若干持久化存儲池（persistence volume group），而單個(gè)可以被容器申請的存儲資源定義為存儲卷（persistence volume，PV）。每個(gè)PV只能被一個(gè)容器掛載，可以是任意大小，支持硬盤驅(qū)動器（hard disk drive，HDD）或固態(tài)硬盤（solid state drive，SSD），也支持HDD與SSD組成的分層式存儲。有狀態(tài)的容器服務(wù)在啟動時(shí)會申請需要的PV資源（如大小、IOPS要求、SSD或HDD），調(diào)度器需要在毫秒內(nèi)從平臺內(nèi)找到合適的機(jī)器，從而將容器調(diào)度起來；如果容器因?yàn)楦鞣N原因不能正常工作，調(diào)度器能夠檢測到不健康的狀態(tài)，同時(shí)根據(jù)數(shù)據(jù)的物理拓?fù)淝闆r，選擇合適的機(jī)器重啟相應(yīng)的容器。

（3）網(wǎng)絡(luò)物理拓?fù)涞母兄c實(shí)時(shí)調(diào)度能力

為了支持靈活彈性的調(diào)度，一般情況下云原生平臺為容器設(shè)計(jì)專門的網(wǎng)絡(luò)空間，并且一般與主機(jī)網(wǎng)絡(luò)保持透明。通常一個(gè)服務(wù)器節(jié)點(diǎn)上會有多個(gè)容器服務(wù)，因此主機(jī)IP的數(shù)量遠(yuǎn)小于容器IP的數(shù)量。在MapReduce、Spark和TensorFlow的設(shè)計(jì)中，在啟動計(jì)算任務(wù)時(shí)，會根據(jù)數(shù)據(jù)存儲的物理拓?fù)錄Q定最終服務(wù)啟動在哪個(gè)服務(wù)器上。但是在容器平臺上，所有的任務(wù)都只能感知容器網(wǎng)絡(luò)，而不能感知物理機(jī)器的IP，無法了解數(shù)據(jù)分布的物理拓?fù)洌虼艘簿蜔o法保證計(jì)算和數(shù)據(jù)的局部性。為了解決這個(gè)問題，在調(diào)度系統(tǒng)內(nèi)增加了網(wǎng)絡(luò)物理拓?fù)淠K，實(shí)時(shí)地維護(hù)物理IP和容器IP的映射關(guān)系表。當(dāng)有狀態(tài)服務(wù)在申請調(diào)度的時(shí)候，可以通過IP映射表找到可用于最終調(diào)度的物理機(jī)器。

（4）動態(tài)標(biāo)簽?zāi)芰εc基于標(biāo)簽的調(diào)度能力

復(fù)雜的應(yīng)用系統(tǒng)對調(diào)度系統(tǒng)有更多細(xì)節(jié)的要求，如多租戶業(yè)務(wù)系統(tǒng)往往要求一個(gè)租戶的所有服務(wù)盡量調(diào)度在同一批物理機(jī)器中；支持高可用的服務(wù)往往要求調(diào)度系統(tǒng)有反親和性（anti-affinity）要求，即將一個(gè)服務(wù)的多個(gè)實(shí)例調(diào)度到不同的物理機(jī)器上，這樣就不會發(fā)生一個(gè)物理機(jī)器宕機(jī)后影響多個(gè)高可用實(shí)例，進(jìn)而導(dǎo)致服務(wù)不可用的情況。因此在調(diào)度系統(tǒng)中增加了動態(tài)標(biāo)簽?zāi)芰突跇?biāo)簽的調(diào)度能力，調(diào)度模塊可以根據(jù)運(yùn)行時(shí)的數(shù)據(jù)給物理機(jī)器和容器應(yīng)用動態(tài)增加或刪除標(biāo)簽，而調(diào)度系統(tǒng)根據(jù)標(biāo)簽的匹配度選擇更合適的調(diào)度策略。

（5）應(yīng)用依賴運(yùn)行參數(shù)的感知以及基于參數(shù)的調(diào)度能力

分布式應(yīng)用在微服務(wù)拆分后，每個(gè)服務(wù)都有比較復(fù)雜的依賴服務(wù)鏈以及影響的服務(wù)鏈，而每個(gè)微服務(wù)在運(yùn)行時(shí)都可能發(fā)生運(yùn)行參數(shù)變化、服務(wù)啟停、重新調(diào)度等操作，這些變化不僅影響當(dāng)前的微服務(wù)，還可能影響所有的依賴鏈的服務(wù)。因此調(diào)度系統(tǒng)中增加了應(yīng)用配置感知模塊，通過與全局的配置中心的數(shù)據(jù)交互，調(diào)度系統(tǒng)能夠?qū)崟r(shí)地感知一個(gè)應(yīng)用變化的事件的所有影響情況，并根據(jù)多個(gè)可能的狀態(tài)遷移圖選擇最合適的調(diào)度策略。

（6）不同優(yōu)先級下基于搶占的調(diào)度能力

在業(yè)務(wù)負(fù)載比較重并可能超過云系統(tǒng)內(nèi)資源總量的時(shí)候，需要有機(jī)制保證高優(yōu)先級的服務(wù)正常運(yùn)行，犧牲低優(yōu)先級應(yīng)用的服務(wù)質(zhì)量，也就是服務(wù)質(zhì)量等級保證（service level agreement，SLA），這是云平臺的一個(gè)重要特性。在調(diào)度系統(tǒng)內(nèi)增加了基于搶占的調(diào)度模式，將服務(wù)和資源按照優(yōu)先級進(jìn)行區(qū)分，如果出現(xiàn)資源不足以調(diào)度高優(yōu)先級應(yīng)用的情況，則通過搶占的方式調(diào)度低優(yōu)先級應(yīng)用的資源。

5 融合大數(shù)據(jù)和AI的云調(diào)度系統(tǒng)的實(shí)現(xiàn)

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

在此之上是云調(diào)度系統(tǒng)，它接收應(yīng)用的輸入，從配置中心、標(biāo)簽中心、云存儲服務(wù)和云網(wǎng)絡(luò)服務(wù)中實(shí)時(shí)獲取平臺運(yùn)行指標(biāo)，并從物理資源池中獲取資源的使用情況，從而根據(jù)運(yùn)行時(shí)的信息進(jìn)行精確的調(diào)度決策。云調(diào)度系統(tǒng)之上是各類應(yīng)用服務(wù)，包括大數(shù)據(jù)、AI、數(shù)據(jù)庫類以及各種微服務(wù)。

5.1 調(diào)度系統(tǒng)架構(gòu)

本文設(shè)計(jì)的云平臺的調(diào)度系統(tǒng)的內(nèi)部架構(gòu)如圖3所示，包含元信息模塊、對外服務(wù)模塊以及調(diào)度決策模塊。當(dāng)一個(gè)應(yīng)用通過Kubernetes API或者命令行（基于Kubectl）的方式啟動時(shí)，它會傳入一個(gè)指定服務(wù)編排方式的yaml文件以及啟動應(yīng)用需要的容器鏡像（docker image）。在yaml文件中會指定當(dāng)前應(yīng)用需要的資源、與調(diào)度相關(guān)的標(biāo)注信息（或標(biāo)簽信息）以及對其他應(yīng)用的依賴關(guān)系。

對外服務(wù)模塊負(fù)責(zé)解析編排文件，同時(shí)負(fù)責(zé)完成應(yīng)用的依賴解析和管理，生成對服務(wù)的依賴圖；參數(shù)計(jì)算模塊負(fù)責(zé)編排文件中與配置變量相關(guān)的計(jì)算，并生成最終的資源需求；實(shí)例渲染模塊最終生成一個(gè)完整的應(yīng)用描述，并將這個(gè)描述文件提交給調(diào)度決策模塊。

元信息模塊負(fù)責(zé)與Kubernetes平臺交互，實(shí)時(shí)地維護(hù)用于調(diào)度的各種元數(shù)據(jù)。資源池?cái)?shù)據(jù)主要包括當(dāng)前集群的各種資源總量以及當(dāng)前的使用情況，并可以精細(xì)到各個(gè)節(jié)點(diǎn)和硬盤級別；網(wǎng)絡(luò)拓?fù)淠K負(fù)責(zé)與容器網(wǎng)絡(luò)進(jìn)行交互，實(shí)時(shí)地維護(hù)當(dāng)前容器網(wǎng)絡(luò)與主機(jī)網(wǎng)絡(luò)的拓?fù)?；存儲拓?fù)淠K負(fù)責(zé)與云存儲服務(wù)交互，實(shí)時(shí)記錄當(dāng)前存儲池的各個(gè)存儲卷（PV）的容量使用情況和每秒進(jìn)行讀寫操作的次數(shù)（input/output operations per second，IOPS）；服務(wù)運(yùn)行指標(biāo)主要同步當(dāng)前集群各個(gè)物理節(jié)點(diǎn)上各個(gè)容器的運(yùn)行指標(biāo)以及各個(gè)物理機(jī)的各項(xiàng)資源的使用指標(biāo)；配置元數(shù)據(jù)模塊主要協(xié)助配置中心維護(hù)各個(gè)應(yīng)用的實(shí)時(shí)配置參數(shù)。因此，通過元信息模塊，調(diào)度器能夠維護(hù)當(dāng)前云平臺的各種調(diào)度決策數(shù)據(jù)，從而實(shí)時(shí)地根據(jù)運(yùn)行數(shù)據(jù)進(jìn)行最優(yōu)化調(diào)度。

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

5.2 服務(wù)的編排系統(tǒng)

應(yīng)用服務(wù)的調(diào)度需求包含依賴的服務(wù)、服務(wù)自身的Docker鏡像、資源需求、網(wǎng)絡(luò)與存儲需求、配置參數(shù)等各個(gè)方面的屬性，因此選擇Jsonnet語言進(jìn)行應(yīng)用的資源描述文件。Jsonnet是Google公司開源的新一代JSON協(xié)議，支持引用、算術(shù)運(yùn)算、條件操作符、函數(shù)、變量、繼承等強(qiáng)大的計(jì)算能力，可以描述多樣化的需求。

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

5.3 配置標(biāo)簽中心

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

由于配置和標(biāo)簽中心服務(wù)中包含了運(yùn)行時(shí)的各種配置和標(biāo)簽數(shù)據(jù)，因此調(diào)度器通過與配置標(biāo)簽中心交互就可以獲取整個(gè)云平臺的標(biāo)簽和配置元數(shù)據(jù)，從而可以支持基于標(biāo)簽的調(diào)度能力。

5.4 云存儲服務(wù)

云平臺中的存儲服務(wù)Warpdrive提供一個(gè)中心化的RESTful服務(wù)，可以支持外部服務(wù)對存儲卷的實(shí)際使用情況的實(shí)時(shí)查詢，因此調(diào)度器通過監(jiān)聽相關(guān)的接口來實(shí)時(shí)感知每個(gè)主機(jī)的存儲卷使用情況以及每個(gè)容器與物理節(jié)點(diǎn)的綁定關(guān)系。

5.5 云網(wǎng)絡(luò)服務(wù)

網(wǎng)絡(luò)服務(wù)也同樣提供RESTful API查詢服務(wù)，使得調(diào)度器可以知曉各個(gè)容器IP和物理IP的使用情況以及各個(gè)容器的網(wǎng)絡(luò)防火墻規(guī)則等實(shí)時(shí)數(shù)據(jù)，因此調(diào)度器能夠?qū)崟r(shí)地感知云平臺內(nèi)的網(wǎng)絡(luò)和存儲實(shí)際運(yùn)行情況。

5.6 計(jì)算調(diào)度過程中的數(shù)據(jù)拓?fù)涓兄?/h3>

在容器云計(jì)算環(huán)境下，分布式網(wǎng)絡(luò)中的各個(gè)主機(jī)可以是一個(gè)或多個(gè)獨(dú)立的網(wǎng)絡(luò)，每個(gè)網(wǎng)絡(luò)都可以包括一個(gè)或多個(gè)子網(wǎng)絡(luò)，網(wǎng)絡(luò)地址從該主機(jī)上的子網(wǎng)絡(luò)中獲得。當(dāng)容器銷毀時(shí)，容器的網(wǎng)絡(luò)地址被回收，等待下次使用。

應(yīng)用感知數(shù)據(jù)拓?fù)涞姆绞饺鐖D6所示，當(dāng)容器中的數(shù)據(jù)應(yīng)用（如Spark應(yīng)用）需要啟動計(jì)算任務(wù)時(shí)，調(diào)度器首先根據(jù)該服務(wù)的依賴關(guān)系找到其需要的數(shù)據(jù)應(yīng)用的容器（如HDFS數(shù)據(jù)節(jié)點(diǎn)），然后通過元信息模塊查詢其所在的物理節(jié)點(diǎn)的網(wǎng)絡(luò)和存儲信息。元信息模塊通過對存儲服務(wù)和網(wǎng)絡(luò)服務(wù)的實(shí)時(shí)查詢來獲取和維護(hù)最新的元數(shù)據(jù)。一般情況下，分布式存儲有多個(gè)存儲副本，會通過調(diào)度器的反親和性保證調(diào)度在不同的物理節(jié)點(diǎn)上，因此調(diào)度器會得到一個(gè)物理節(jié)點(diǎn)的列表。然后根據(jù)這幾個(gè)節(jié)點(diǎn)的實(shí)際資源使用負(fù)載情況，選擇當(dāng)前資源負(fù)載最低的節(jié)點(diǎn)來啟動對應(yīng)的計(jì)算服務(wù)容器。由于兩個(gè)容器都在一個(gè)主機(jī)上，計(jì)算服務(wù)可以與存儲服務(wù)通過本地網(wǎng)絡(luò)進(jìn)行數(shù)據(jù)傳輸，或者創(chuàng)建域套接字（domain socket）等機(jī)制來提高數(shù)據(jù)讀取速度，增強(qiáng)性能。

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

5.7 調(diào)度的總體流程

對于調(diào)度策略模塊，它的輸入是應(yīng)用的資源需求、標(biāo)簽屬性、依賴關(guān)系和輸入輸出參數(shù)等信息，輸出是選定的物理節(jié)點(diǎn)或者節(jié)點(diǎn)組以及對應(yīng)的容器的優(yōu)先級信息，同時(shí)，依賴元數(shù)據(jù)模塊提供的平臺運(yùn)行數(shù)據(jù)進(jìn)行調(diào)度決策支撐。調(diào)度器的決策流程如圖8所示。

調(diào)度器從任務(wù)調(diào)度隊(duì)列獲取待調(diào)度的任務(wù)，形成節(jié)點(diǎn)-任務(wù)映射表。其中，調(diào)度器持續(xù)對API服務(wù)器中創(chuàng)建的任務(wù)進(jìn)行監(jiān)聽，并讀取新的任務(wù)形成任務(wù)調(diào)度隊(duì)列。

（1）篩選階段

調(diào)度器根據(jù)映射表以及預(yù)設(shè)篩選條件確定一組符合條件的目標(biāo)物理節(jié)點(diǎn)。其中，預(yù)設(shè)篩選條件可以是當(dāng)前任務(wù)所需的資源與物理節(jié)點(diǎn)上的剩余資源之間的匹配條件、當(dāng)前任務(wù)所需的端口與物理節(jié)點(diǎn)上的端口之間的匹配條件以及是否帶有特殊標(biāo)簽等。如果當(dāng)前任務(wù)配置了對持久化存儲的需求或者對數(shù)據(jù)拓?fù)涞母兄?，調(diào)度器也會考慮滿足這些條件的節(jié)點(diǎn)。最終調(diào)度器會將滿足上述所有篩選條件的節(jié)點(diǎn)整理出來進(jìn)行下一步處理。

（2）優(yōu)選階段

調(diào)度器根據(jù)篩選階段拿到的節(jié)點(diǎn)以及預(yù)設(shè)優(yōu)選條件對各個(gè)物理節(jié)點(diǎn)進(jìn)行評分，最終選擇分?jǐn)?shù)最高的作為目標(biāo)物理節(jié)點(diǎn)。其中優(yōu)選條件包括：節(jié)點(diǎn)空閑資源越多，評分越高；節(jié)點(diǎn)保存的任務(wù)鏡像越多，評分越高；任務(wù)親和性/反親和性越匹配，評分越高；同類任務(wù)分布越均勻，評分越高等。

通過上述兩次篩選，選擇出一個(gè)分?jǐn)?shù)最高的物理節(jié)點(diǎn)。調(diào)度器將當(dāng)前任務(wù)與目標(biāo)物理節(jié)點(diǎn)綁定，并將綁定的信息發(fā)送到API服務(wù)器。

5.8 基于優(yōu)先級的搶占式調(diào)度方法

在平臺的資源不足而有更高優(yōu)先級的服務(wù)需要被調(diào)度的情況下，調(diào)度器就需要進(jìn)行搶占式調(diào)度。在目前的實(shí)現(xiàn)中，搶占式調(diào)度提供了2種方式：調(diào)度階段的資源搶占和運(yùn)行階段的資源搶占。

調(diào)度階段的資源搶占即在調(diào)度器篩選節(jié)點(diǎn)階段，如果發(fā)現(xiàn)集群中所有節(jié)點(diǎn)都無法滿足當(dāng)前任務(wù)的資源需求，調(diào)度器會在集群中選擇節(jié)點(diǎn)，并試圖搶占其中正在運(yùn)行的低優(yōu)先級的任務(wù)的節(jié)點(diǎn)。搶占完成后，調(diào)度器會再次嘗試調(diào)度當(dāng)前任務(wù)到目標(biāo)節(jié)點(diǎn)上。調(diào)度階段的資源搶占策略如圖9所示。

調(diào)度階段的資源搶占實(shí)際上是一種邏輯層面的搶占，依據(jù)是任務(wù)在啟動時(shí)聲明的資源請求，它可以幫助系統(tǒng)避免任何資源超配的現(xiàn)象，但同時(shí)也會造成一定程度的資源浪費(fèi)。比如一個(gè)聲明了10 core CPU的任務(wù)可能當(dāng)前只消耗了2 core CPU，此時(shí)完全不需要搶占掉，它也可以讓別的任務(wù)運(yùn)行起來?；诖朔N考慮，又引入了運(yùn)行階段的資源搶占算法，如圖10所示。運(yùn)行階段的資源搶占的主線程邏輯如圖11所示。

運(yùn)行階段的資源搶占會忽略優(yōu)先級低于當(dāng)前任務(wù)的任務(wù)，即如果有必要，可以完全搶占這些低優(yōu)先級的任務(wù)，因此它們不在節(jié)點(diǎn)資源消耗的統(tǒng)計(jì)范圍內(nèi)。搶占階段發(fā)生在物理節(jié)點(diǎn)上，當(dāng)物理節(jié)點(diǎn)發(fā)現(xiàn)某種資源剩余小于預(yù)期值時(shí)，會對其上低優(yōu)先級的任務(wù)進(jìn)行清除，直到物理節(jié)點(diǎn)狀態(tài)恢復(fù)正常。此種搶占方式基于物理節(jié)點(diǎn)的資源真實(shí)使用情況，可以保證集群資源利用最大化。

6 實(shí)驗(yàn)評估

為了驗(yàn)證數(shù)據(jù)應(yīng)用尤其是大數(shù)據(jù)計(jì)算在云平臺上有良好的性能表現(xiàn)，選擇了3個(gè)基準(zhǔn)測試程序來驗(yàn)證所設(shè)計(jì)實(shí)現(xiàn)的系統(tǒng)的性能。

● TestDFSIO是Hadoop自帶的性能測試工具，主要為了測試Apache HDFS的I/O性能，采用MapReduce程序進(jìn)行并發(fā)讀寫并做結(jié)果統(tǒng)計(jì)，主要涉及讀、隨機(jī)讀、追加寫、寫等業(yè)務(wù)行為。

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

● TPC-DS[17]是事物處理性能委員會（Transaction Processing Performance Council，TPC）推出的用于數(shù)據(jù)決策支持系統(tǒng)的基準(zhǔn)測試，包含對大數(shù)據(jù)集的統(tǒng)計(jì)、報(bào)表生成、聯(lián)機(jī)查詢、數(shù)據(jù)挖掘等復(fù)雜應(yīng)用，包含了7張事實(shí)表、17張維度表和99個(gè)復(fù)雜SQL，是一個(gè)典型的數(shù)據(jù)倉庫的測試場景，可以用于衡量大數(shù)據(jù)分析數(shù)據(jù)庫的性能和魯棒性。

選定好基準(zhǔn)測試后，在50臺x86服務(wù)器上部署了云平臺，并且創(chuàng)建了3個(gè)不同的租戶用于測試，每個(gè)租戶都將部署Hadoop服務(wù)以及分析數(shù)據(jù)庫Inceptor，HBase分片服務(wù)器、HDFS數(shù)據(jù)節(jié)點(diǎn)和Inceptor任務(wù)執(zhí)行節(jié)點(diǎn)都有8個(gè)實(shí)例。本次測試的設(shè)計(jì)目標(biāo)和期望結(jié)果見表1。

● 第一個(gè)租戶：通過修改標(biāo)簽中心的配置參數(shù)讓其所有的服務(wù)只能在節(jié)點(diǎn)1～10上調(diào)度。

● 第二個(gè)租戶：通過修改標(biāo)簽中心的配置參數(shù)讓其可以在平臺的50臺機(jī)器上調(diào)度，同時(shí)設(shè)置其優(yōu)先級比其他微服務(wù)的優(yōu)先級高。

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

● 在8個(gè)節(jié)點(diǎn)的裸機(jī)上部署了Hadoop服務(wù)和Inceptor，采用主機(jī)的方式部署，每個(gè)節(jié)點(diǎn)上部署數(shù)據(jù)節(jié)點(diǎn)、HBase分片服務(wù)器和Inceptor任務(wù)執(zhí)行節(jié)點(diǎn)，所有的數(shù)據(jù)和計(jì)算服務(wù)都預(yù)先按照物理拓?fù)鋭澏ê?，因此沒有其他的調(diào)度開銷。

本文沒有單獨(dú)針對調(diào)度系統(tǒng)的每個(gè)設(shè)計(jì)指標(biāo)進(jìn)行測試，這些設(shè)計(jì)能力都會在這個(gè)綜合的性能測試?yán)锉或?yàn)證，如基于資源需求的調(diào)度能力、應(yīng)用依賴和運(yùn)行參數(shù)感知能力，因?yàn)榇髷?shù)據(jù)平臺本身是分布式系統(tǒng)，多個(gè)服務(wù)之間存在互相依賴（如HDFS依賴ZooKeeper）的關(guān)系，每個(gè)服務(wù)通過自己的編排文件指定自己需要的硬件資源以及依賴的服務(wù)，如果不具備這方面的能力，大數(shù)據(jù)服務(wù)就無法在平臺上運(yùn)行起來?；诰W(wǎng)絡(luò)拓?fù)浜臀锢泶鎯Φ恼{(diào)度能力以及不同優(yōu)先級的搶占能力會比較多地在性能測試結(jié)果中反映出來。

表1 測試項(xiàng)的設(shè)計(jì)原則與期望結(jié)果

按照預(yù)期，主機(jī)部署的模式應(yīng)該是性能最好的方式，其次是租戶1，因?yàn)樗荒茉谳^少的節(jié)點(diǎn)內(nèi)調(diào)度，發(fā)生計(jì)算數(shù)據(jù)分離的概率比較??；租戶2和租戶3在50個(gè)節(jié)點(diǎn)內(nèi)有8個(gè)數(shù)據(jù)節(jié)點(diǎn)，如果不用新的調(diào)度算法，發(fā)生計(jì)算和數(shù)據(jù)偏離的可能性比較大，但是期望租戶2的性能比較好，可以接近租戶1，因?yàn)檎{(diào)度系統(tǒng)可以支持計(jì)算來感知數(shù)據(jù)，而租戶3的性能會比較差，因?yàn)闆]有數(shù)據(jù)本地性的保證。

最終的測試結(jié)果如圖12所示，基本符合預(yù)期。在裸機(jī)上部署的集群在3個(gè)測試?yán)锏男阅芏际亲罴训模蛔鈶?和租戶2的3個(gè)測試的性能數(shù)據(jù)不相上下（差異可以認(rèn)為是數(shù)據(jù)波動），說明本文的調(diào)度算法有很好的可擴(kuò)展性，在集群規(guī)模擴(kuò)大5倍后可以保證性能沒有損失；租戶3的性能要差很多，因?yàn)橛?jì)算任務(wù)和數(shù)據(jù)分布是無序的，所以有很多遠(yuǎn)程讀寫帶來的性能損失。實(shí)驗(yàn)證明，有效的調(diào)度系統(tǒng)可以在保證云平臺的靈活性和彈性的同時(shí)，提供和物理平臺部署一樣的性能。

7 結(jié)束語

目前工業(yè)界在如何解決大數(shù)據(jù)和AI應(yīng)用在云上的開發(fā)和部署問題上，基本分為3種。

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

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

第三種是容器平臺只負(fù)責(zé)調(diào)度微服務(wù)等無狀態(tài)類應(yīng)用，而大數(shù)據(jù)、AI平臺運(yùn)行在傳統(tǒng)的基于虛擬化的云上。這樣可以保證良好的調(diào)度能力，但是犧牲了大數(shù)據(jù)或者AI平臺的穩(wěn)定性。這個(gè)方法最簡單，但是在現(xiàn)實(shí)案例中也發(fā)現(xiàn)這個(gè)方法因?yàn)榉€(wěn)定性等問題，幾乎沒有成功的落地案例。

本文討論了與以上3種云調(diào)度方案完全不同的全新的方式，即如何在容器云平臺上實(shí)現(xiàn)一個(gè)支持復(fù)雜的大數(shù)據(jù)和AI平臺服務(wù)的調(diào)度系統(tǒng)，既能保證復(fù)雜的平臺應(yīng)用的性能，又能夠有很好的調(diào)度靈活性和運(yùn)維便利性。從實(shí)驗(yàn)結(jié)果來看，本文的設(shè)計(jì)最終在生產(chǎn)平臺上取得了符合預(yù)期的業(yè)務(wù)性能數(shù)據(jù)，也證明了這個(gè)調(diào)度方法的有效性。不過受限于本系統(tǒng)的工程背景，本文是在實(shí)踐中逐步優(yōu)化了本調(diào)度系統(tǒng)，而不是從理論上根據(jù)調(diào)度系統(tǒng)的各個(gè)指標(biāo)來設(shè)計(jì)系統(tǒng)。另外由于業(yè)務(wù)需求的驅(qū)動，本文的設(shè)計(jì)強(qiáng)調(diào)數(shù)據(jù)的局部性和決策的實(shí)時(shí)性，要求所有的調(diào)度決策在毫秒級完成，弱化了調(diào)度的公平性設(shè)計(jì)，而另外一些調(diào)度算法更側(cè)重公平性[18]。

從另外一個(gè)維度，本文提出的調(diào)度系統(tǒng)的設(shè)計(jì)目標(biāo)是給應(yīng)用提供更好的性能，因此會犧牲一些其他的指標(biāo)，如低優(yōu)先級任務(wù)的可靠性。如為了在有數(shù)據(jù)節(jié)點(diǎn)的服務(wù)器上調(diào)度計(jì)算任務(wù)，會增加搶占對應(yīng)節(jié)點(diǎn)上其他低優(yōu)先級服務(wù)的概率，因而需要云平臺上的微服務(wù)有更好的容錯能力?？紤]到計(jì)算任務(wù)也會有一些數(shù)據(jù)的操作，根據(jù)HDFS的特性，一般情況下在有更多計(jì)算任務(wù)的節(jié)點(diǎn)上就可能有更多的數(shù)據(jù)寫入，這就要求平臺對數(shù)據(jù)的生命周期有良好的管理能力，否則可能會有部分節(jié)點(diǎn)數(shù)據(jù)量越積越多，從而使得整個(gè)云平臺出現(xiàn)數(shù)據(jù)分布不均衡的情況，需要定期進(jìn)行人為觸發(fā)的重新平衡行為。

本文主要描述了一個(gè)適用于容器云平臺的調(diào)度系統(tǒng)，它通過實(shí)時(shí)獲取Kubernetes集群的各種資源數(shù)據(jù)，結(jié)合數(shù)據(jù)和計(jì)算的拓?fù)涮匦?，可以在容器平臺上有效地支持大數(shù)據(jù)與人工智能的應(yīng)用和服務(wù)，在帶來彈性和靈活性的同時(shí)，提供了與裸機(jī)部署相同的性能，能夠同時(shí)提供云計(jì)算的彈性和大數(shù)據(jù)的計(jì)算能力。通過有效的調(diào)度設(shè)計(jì)，基于容器的云平臺不僅可以用于微服務(wù)類應(yīng)用的DevOps支持，還可以用于大數(shù)據(jù)平臺以及應(yīng)用的開發(fā)和部署，支持大規(guī)模數(shù)據(jù)服務(wù)和AI服務(wù)的自動化部署和靈活調(diào)度。云計(jì)算提供基礎(chǔ)，大數(shù)據(jù)提供生產(chǎn)資料，AI提供價(jià)值輸出，因此，能夠同時(shí)支持大數(shù)據(jù)+AI的云平臺是未來的趨勢，也是下一代數(shù)據(jù)中心的技術(shù)基礎(chǔ)平臺。

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

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