摘要：追蹤正在進(jìn)行的計算的狀態(tài)。為了知道作業(yè)的進(jìn)度，通過監(jiān)聽端口來接受二進(jìn)制文件發(fā)來的信息。子系統(tǒng)監(jiān)聽的子系統(tǒng)包括多種預(yù)編譯二進(jìn)制文件。這些二進(jìn)制文件被分配給對應(yīng)的在應(yīng)用層定義好的計算模版。

MPI（信息傳遞接口） 是真正的并行編程標(biāo)準(zhǔn)，包括多節(jié)點集群和多核 CPU 節(jié)點。

MPI 基于分布式內(nèi)存系統(tǒng)和并行處理的概念

進(jìn)程間通信通過使用信息傳遞和大量通信 API 庫

對于低級的通用 GPU 編程，最流行的是 CUDA 和 OpenCL。大致思路是

以網(wǎng)格形式對處理過程進(jìn)行建模。一個網(wǎng)格中包含線程塊，線程塊中包含若干個線程

塊中的線程并行執(zhí)行，且可以相互之間進(jìn)行同步

塊和塊之間獨立運行

CUDA 在 GPU 方面只針對 NVIDIA 的 GPU， OpenCL 可以在多種 GPU 和 CPU 上運行

新的解決方案要滿足的條件

一個新的統(tǒng)一的、多層次的、具有自適應(yīng)能力的框架。該框架能夠?qū)唵蔚暮蛷?fù)雜的處理流進(jìn)行建模和執(zhí)行，同時能夠在由 CPU 和 GPU 組成的的節(jié)點組成的集群中實現(xiàn)跨集群計算

易于使用的 GUI。它能設(shè)計和重用并行應(yīng)用

自動調(diào)度

能插入專用的調(diào)度算法

多種可重用的組件庫。上至高級應(yīng)用，下至底層的 CPU 和 GPU 內(nèi)核

創(chuàng)新點

框架更具有一般性 —— 考慮到了集群中的接入節(jié)點和計算節(jié)點

在內(nèi)部網(wǎng)絡(luò)中，只有接入節(jié)點能訪問多個節(jié)點

能通過使用 GUI 將應(yīng)用定義為一個工作流

可以插入各種優(yōu)化器，從而調(diào)節(jié)性能

以圖形方式建立并行應(yīng)用模型。圖中節(jié)點對應(yīng)計算任務(wù)，邊代表任務(wù)間的依賴關(guān)系

負(fù)責(zé)將并行應(yīng)用映射到底層集群

對集群網(wǎng)絡(luò)暴露出一個統(tǒng)一的 API。其中，每個集群由一個或多個節(jié)點組成，每個節(jié)點包含一個或多個處理器和0個或多個 GPU

說明：用戶將計算應(yīng)用定義為工作流，這會用到用戶圖形界面，同時也可能會用到模板庫中的可用組件。然后，應(yīng)用被傳送到執(zhí)行引擎層。該層會為應(yīng)用啟動某個優(yōu)化器。優(yōu)化器通過給定的優(yōu)化標(biāo)準(zhǔn)決定把哪個計算設(shè)備分配給該應(yīng)用，同時根據(jù)計算和通信開銷以及用電量等在優(yōu)化器中定義的規(guī)則對應(yīng)用的執(zhí)行進(jìn)行調(diào)度。集群和節(jié)點管理層負(fù)責(zé)特定集群中特定計算設(shè)備的應(yīng)用執(zhí)行。

用戶可以在 KernelHive 應(yīng)用層中定義將要在該系統(tǒng)中運行的應(yīng)用。

定義一個應(yīng)用只需3步

將一個工作流定義為一個有向非循環(huán)圖，圖中的節(jié)點邏輯地連接著處理節(jié)點。每個節(jié)點都包含其需要執(zhí)行的代碼。整個過程可以看成一個計算流。一開始，數(shù)據(jù)來自數(shù)據(jù)服務(wù)器，然后通過一系列的節(jié)點傳遞到有向非循環(huán)圖的最后 一個節(jié)點并保存到數(shù)據(jù)服務(wù)器中。值得注意的是， KernelHive 優(yōu)化器根據(jù)給定的優(yōu)化標(biāo)準(zhǔn)在每一個將要執(zhí)行任務(wù)的工作流節(jié)點中選擇特定的計算設(shè)備

為每一個在上一步中創(chuàng)建出來的節(jié)點選擇一個模版。模版是一個通用的定義，它指出了在特定節(jié)點中應(yīng)該執(zhí)行何種計算。模版在輸入和輸出的數(shù)量上有所不同，因此，處理流可能是一個樹形結(jié)構(gòu)。

補全在上一步中選擇出來的代碼模版。這一步通過指定一個計算內(nèi)核來實施。計算內(nèi)核負(fù)責(zé)節(jié)點內(nèi)真正的數(shù)據(jù)處理

KernelHive 系統(tǒng)基于某個能讓用戶執(zhí)行多種類型計算的計算模版的概念。模版本身提供了關(guān)于計算如何執(zhí)行和用戶如何自定義相關(guān)細(xì)節(jié)的通用思路?？蚣馨殡S著基本的和更高級的模版以及將來可能的額外擴(kuò)展。

處理邏輯可以為多種多樣的 workers 定義。不同的 workers 對應(yīng)不同的 KernelHive 框架模版。模版已經(jīng)通過用 C++ 實現(xiàn)由 worker 子系統(tǒng)定義的抽象類 Worker。基本模版最根本的區(qū)分僅僅在于被 worker 處理的輸入和輸出量。具體包含一下3部分：

數(shù)據(jù)處理器 —— 一路輸入，執(zhí)行計算，一一路輸出

數(shù)據(jù)合并器 —— 多路輸入，一路輸出

數(shù)據(jù)分割器 —— 把數(shù)據(jù)分割成多個部分

接著內(nèi)核被上傳到系統(tǒng)，并在某個設(shè)備運行 worker 前被編譯。

每個基礎(chǔ)模版只需要一個用戶定義的內(nèi)核。但另一方面，更高級的模版也許需要多個內(nèi)核。例如，考慮 Master/Slave 模型。用戶要提供3個源文件 —— 一個說明輸入數(shù)據(jù)如何被分割到多個 slave 中，一個決定所有的 slave 計算說明內(nèi)容，最后一個負(fù)責(zé)最終結(jié)果的合并。

用戶可以使用上面提到的那些模版定義自己的計算流。模板庫包括

針對工作流圖節(jié)點的模版集。每個模版定義節(jié)點的特點，例如內(nèi)核的數(shù)量、名字和需要的輸入輸出數(shù)量。也可能用額外的模版來擴(kuò)展系統(tǒng)

針對處理的計算內(nèi)核集。系統(tǒng)自帶一套預(yù)定的資源文件。用戶可以對其進(jìn)行更改或添加自己的源文件。內(nèi)核模版對應(yīng)具體的工作流幾點模版的要求。

KernelHive GUI 應(yīng)用通過圖形化的方式幫助用戶精心安排復(fù)雜的執(zhí)行方案——節(jié)點代表任務(wù)，邊代表任務(wù)間的時間關(guān)系。

一個桌面應(yīng)用。用于將 KernelHive 應(yīng)用定義為一個工作流，可以用來查看計算設(shè)備的狀態(tài)和計算結(jié)果

一個 Java EE 應(yīng)用，其對運行在底層集群系統(tǒng)上的工作流進(jìn)行優(yōu)化和管理

一個 Java 守護(hù)進(jìn)程。用來提供對單個集群資源的訪問

一個 C++ 守護(hù)進(jìn)程。用來提供對單個集群節(jié)點的資源訪問。可用于控制節(jié)點中的計算設(shè)備

運行在每一個連接到系統(tǒng)的計算機(jī)器中

任務(wù)：

更新機(jī)器狀態(tài)

監(jiān)聽傳入的作業(yè)

一個 C++ 庫。用來在某個 HIVE_UNIT 設(shè)備上執(zhí)行計算

運行在操作系統(tǒng)級別

被以上子系統(tǒng)共享的 C++ 和 Java 庫

HIVE_GUI 和 HIVE_ENGINE 部署在一臺機(jī)器上或分開部署在兩臺機(jī)器或兩個集群上。

HIVE_UNIT 部署在每個節(jié)點上

一個集群中只有一個節(jié)點部署有 HIVE_CLUSTER

GUI 的作用：

1.使用可用的應(yīng)用模型創(chuàng)建一個有向非循環(huán)圖執(zhí)行方案。

2.監(jiān)視已提交的工作流執(zhí)行狀態(tài)，例如：

完成

處理中

已調(diào)度

錯誤，等

3.監(jiān)視系統(tǒng)物理節(jié)點的硬件配置

HIVE_GUI 應(yīng)用于 KernelHive 系統(tǒng)的其他組件進(jìn)行通信，尤其是 HIVE_ENGINE 和 TEMPLATES 庫。

TEMPLATES 庫 被打包為獨立的 JAR 包放在 HIVE_ENGINE 中，在應(yīng)用初始化時唄動態(tài)加載。這樣就能保證 HIVE_ENGINE 和 HIVE_GUI 應(yīng)用 使用的是相同版本的 TEMPLATES 庫。

集群和節(jié)點管理層的任務(wù)：

為了開始調(diào)度過程進(jìn)程，HIVE_ENGINE 需要收集關(guān)于可用的基礎(chǔ)設(shè)施和他們內(nèi)部狀態(tài)的信息

設(shè)法將被分配的作業(yè)發(fā)送到已經(jīng)調(diào)度好的資源處，另外，發(fā)送部分或最終的計算結(jié)果。

追蹤正在進(jìn)行的計算的狀態(tài)。每一個 worker 定期地報告它的當(dāng)前狀態(tài)和當(dāng)前計算的進(jìn)度。

因為 HIVE_UNIT 組件，可以看到更多關(guān)于每個集群中特定計算節(jié)點的詳細(xì)信息。這些信息中包括每個節(jié)點中可用的計算設(shè)備的數(shù)量，包括 CPU 和 GPU。OpenCL 框架允許這兩種計算設(shè)備透明地使用。

為了知道作業(yè)的進(jìn)度， HIVE_CLUSTER 通過監(jiān)聽 UDP 端口來接受 HIVE_WORKER 二進(jìn)制文件發(fā)來的信息。 基于 JSVC 庫實現(xiàn)的 HIVE_CLUSTER 作為系統(tǒng)守護(hù)進(jìn)程被部署。

HIVE_UNIT 通過一個 TCP 連接與 HIVE_CLUSTER 進(jìn)行交互。HIVE_UNIT 匯報 可用設(shè)備，參數(shù)和狀態(tài)。設(shè)備列表和參數(shù)通過 OpenCL 庫的 utility 方法獲得。

子系統(tǒng)監(jiān)聽 HIVE_CLUSTER 的 connection socket

HIVE_WORKER 子系統(tǒng)包括多種預(yù)編譯二進(jìn)制文件。這些二進(jìn)制文件被分配給對應(yīng)的在應(yīng)用層定義好的計算模版。二進(jìn)制文件的執(zhí)行順序如下：

下載計算內(nèi)核和輸入數(shù)據(jù)

運行內(nèi)核

報告計算進(jìn)度

上傳結(jié)果

向 HIVE_CLUSTER 子系統(tǒng)報告作業(yè)完成

每一個節(jié)點在計算上花的時間有可能是很大的，這對 CPU 來說不是問題，但 GPU 就會出現(xiàn)問題。原因是，通常，操作系統(tǒng)會給顯卡分配一個 watchdog 計時器，這個計時器聯(lián)系著每一個活動的播放任務(wù)。當(dāng)顯卡運行一個任務(wù)的時間超過了給定時間，操作系統(tǒng)會認(rèn)為任務(wù)失敗然后殺掉該應(yīng)用。一些 KernelHive 模版已經(jīng)通過被設(shè)計成在迭代批處理中執(zhí)行計算任務(wù)來克服這個不足。 worker 能以一種標(biāo)準(zhǔn)方式被編譯，就說，在一次運行中處理全部輸入數(shù)據(jù)，或者按照以下方案進(jìn)行處理：

從頭開始或從之前保存的地方開始。一直處理輸入直到算出結(jié)果或到達(dá)迭代極限

把當(dāng)前作業(yè)的偏移量存入內(nèi)存，根據(jù)當(dāng)前計算狀態(tài)設(shè)置進(jìn)度標(biāo)志

執(zhí)行宿主機(jī)器中的代碼，讀取之前保存在內(nèi)存中的進(jìn)度標(biāo)志。如果進(jìn)度已經(jīng)算出或已經(jīng)處理完所有數(shù)據(jù)，則停止處理。否則，返回第一步

KernelHive能使用多種數(shù)據(jù)服務(wù)器。

讓KernelHive支持新的數(shù)據(jù)庫或文件系統(tǒng)時，需要實現(xiàn)與所有相關(guān)子系統(tǒng)有關(guān)的相關(guān)編程接口。比如內(nèi)存數(shù)據(jù)庫和MongoDB。

因為系統(tǒng)的異構(gòu)問題，數(shù)據(jù)格式的兼容性問題格外重要。

OpenCL標(biāo)準(zhǔn)定義了一些數(shù)據(jù)類型，這些數(shù)據(jù)類型的長度與底層的系統(tǒng)架構(gòu)無關(guān)。int類型總是4字節(jié)，long類型總是8字節(jié)

字節(jié)順序問題也很重要?？梢酝ㄟ^C++模版代碼或OpenCL內(nèi)核進(jìn)行檢查，在兩種方法中，必須要能順利進(jìn)行合適的數(shù)據(jù)轉(zhuǎn)換。

KernelHive只傳送數(shù)據(jù)地址，當(dāng)相關(guān)組件需要數(shù)據(jù)時，再自行下載

HIVE_ENGINE 決定是否需要存儲數(shù)據(jù)包和是否能夠刪除數(shù)據(jù)。這使得數(shù)據(jù)直接在計算單元間傳輸，而無需HIVE_CLUSTER 或 HIVE_ENGINE 的干涉。也因此減少了網(wǎng)絡(luò)流量。

數(shù)據(jù)包存放在分布式的數(shù)據(jù)服務(wù)器中，那些數(shù)據(jù)服務(wù)器有些是本地 HIVE_UNIT 的一部分，有些是 HIVE_CLUSTER 的子系統(tǒng)。

使用 CPU 和 GPU 并行計算的機(jī)制

針對調(diào)度和選擇計算設(shè)備的可交換的插件

調(diào)度依據(jù)：性能，耗電量，可靠性

選擇最好的計算內(nèi)核配置的能力

OpenCL 中網(wǎng)格大小的選擇

block 中線程太少，資源利用不充分

block 中線程太多，降低并行性，運行時系統(tǒng)會減少 block 的線程數(shù)

任務(wù)分解和自適應(yīng)數(shù)據(jù)產(chǎn)生

要使某個節(jié)點具有分解任務(wù)的能力，用戶必須指定數(shù)據(jù)分割和合并的方式。這要求用戶必須實現(xiàn) IDataPartitioner 和 IDataMerger 接口。DataPartition 產(chǎn)生的數(shù)據(jù)塊的數(shù)量由系統(tǒng)決定使用的計算單元決定。因為不同的計算單元的計算能力不同，所以，系統(tǒng)為了均衡負(fù)載將產(chǎn)生最佳的數(shù)據(jù)塊數(shù)量。

HIVE_ENGINE 子系統(tǒng)是 KernelHive 的大腦和中心進(jìn)入點。有關(guān)可用基礎(chǔ)設(shè)施和內(nèi)部狀態(tài)的完整信息由 HIVE_ENGINE 收集，由 HIVE_CLUSTER 傳送。同時， HIVE_ENGINE 向客戶端運用暴露客戶端接口，尤其是 HIVE_GUI

組件接受客戶端準(zhǔn)備好的工作流，并把他們轉(zhuǎn)換為單個的作業(yè)，然后把它們部署在設(shè)備上。

HIVE_ENGINE 必須能夠被每一個 HIVE_CLUSTER 子系統(tǒng)實例訪問。HIVE_CLUSTER 能更新集群的基礎(chǔ)設(shè)施狀態(tài)

調(diào)度

調(diào)度進(jìn)程使用一個優(yōu)化器組件。該優(yōu)化器組件能面向性能、耗電量、用戶正當(dāng)使用資源等方面進(jìn)行擴(kuò)展，每一個優(yōu)化器都要實現(xiàn) IOptimizer 接口。接口中唯一一個方法在每次有新的工作流提交時都會被執(zhí)行。多個優(yōu)化器可以聯(lián)合起來工作。

開發(fā)的一個備選方案

在給定耗電量的情況下，選出一個能使執(zhí)行時間最小的節(jié)點配置。這就是一個背包問題，使用了貪心近似算法

為防止機(jī)器長期沒有響應(yīng)，執(zhí)行引擎使用了 EJB 計時器服務(wù)。TimerBean 類會周期性的檢查系統(tǒng)中工作流的狀態(tài)，執(zhí)行清理程序，觸發(fā)工作流的再調(diào)度進(jìn)程

標(biāo)記為可拆分的工作流任務(wù)會有以下幾種內(nèi)核類型：

分割器內(nèi)核 —— 1進(jìn)多出

處理器內(nèi)核 —— 1進(jìn)1出

合并內(nèi)核 —— 多進(jìn)1出

當(dāng)一個節(jié)點準(zhǔn)備好被執(zhí)行時，節(jié)點的拆分就會發(fā)生。

輸入數(shù)據(jù)會被分割成一些數(shù)據(jù)塊，這樣就可以在 CPU 和 GPU 上進(jìn)行負(fù)載均衡

然后，每個計算設(shè)備上的一個分割器和多個處理器，一個合并任務(wù)，會使用已經(jīng)定義的優(yōu)化器以正確的順序被創(chuàng)建和調(diào)度

這樣就使得動態(tài)并行程序能通過數(shù)據(jù)塊的動態(tài)分配順利執(zhí)行，同時實現(xiàn)資源新能差異化情況下的負(fù)載均衡

性能調(diào)優(yōu)的機(jī)制

選擇計算設(shè)備?？紤]：設(shè)備性能，通信開銷，耗電量

決定最好網(wǎng)格配置，主要是 GPU。系統(tǒng)測量不同配置下的執(zhí)行時間，選擇最好的配置

決定首選的數(shù)據(jù)分割顆粒度和系統(tǒng)配置

通過機(jī)構(gòu)內(nèi)部開發(fā)的模擬器實現(xiàn)該功能，該模擬器的具體工作如下：

將給定數(shù)量的分發(fā)到計算設(shè)備中，分發(fā)時使用輪詢調(diào)度方式并考慮通信開銷（啟動時間、帶寬）。要考慮到重疊的通信和計算，這樣可以減少通信開銷和獲得較高的增速

處理數(shù)據(jù)包

發(fā)送中間結(jié)果

真正的并行執(zhí)行

同時有 GPU 和 CPU

每個 CUDA 服務(wù)器上有3個 GPU，CPU 不直接參與運算

暴力破解 MD5 加密

用于計算的代碼使用 OpenCL 內(nèi)核實現(xiàn)，這樣就能同時在 CPU 和 GPU 上運行

具有較高計算開銷和通信開銷的應(yīng)用可用來評估系統(tǒng)的可擴(kuò)展性和用于優(yōu)化的技術(shù)

GPU 內(nèi)部

一個 GPU 包含 一定數(shù)量的 SM （流多處理器）

每個 SM 有一個允許駐留線程個數(shù)的最大值和留給 OpenCL 工作組的位置數(shù)量的最大值

每個線程一定數(shù)量的私有內(nèi)存和在 OpenCL 中定義的局部內(nèi)存

一個線程組中有多個線程，這使得每個線程組都需要一定數(shù)量的私有內(nèi)存和局部內(nèi)存

SM 會在這些并行的線程組中運行，所以總共使用的私有內(nèi)存和局部內(nèi)存不會超過 SM 規(guī)定的值

測試內(nèi)容

每個 block 中線程數(shù)量不同時的執(zhí)行時間

每個 grid 中 block 數(shù)量不同時的執(zhí)行時間

測試結(jié)論

當(dāng) block 中線程太少時，執(zhí)行時間明顯變長

當(dāng) block 中線程數(shù)量超過一個特定值時，會造成不必要的開銷

異構(gòu)環(huán)境下涉及到多種 CPU 和 GPU。每個處理器的計算能力不同，所以需要負(fù)載均衡

時間開銷如下：

調(diào)用 Web 服務(wù)的時間，從數(shù)據(jù)服務(wù)器下載數(shù)據(jù)包的時間，

處理時間

調(diào)用 Web 服務(wù)的時間，上傳數(shù)據(jù)的時間

對于該測試而言，CPU 比 GPU 慢很多，結(jié)論：

數(shù)據(jù)包太少，GPU 先完成，而 CPU 還沒完成，那么總的執(zhí)行時間會變長

數(shù)據(jù)包太多，雖然數(shù)據(jù)包會變小，但是通信開銷會變大，比如下載數(shù)據(jù)和上傳數(shù)據(jù)的時間

要權(quán)衡數(shù)據(jù)包的大小和數(shù)量

使用理論最優(yōu)值時，執(zhí)行時間直線下降。

選擇最好的數(shù)據(jù)粒度從而找出最好的乘數(shù)是很有價值的

地理空間數(shù)據(jù)的反距離加權(quán)插值計算

數(shù)據(jù)處理節(jié)點使用 OpenCL 實現(xiàn)反距離加權(quán)插值算法

master--slave 模型

master -- HIVE_ENGINE

slave -- HIVE_WORKER

中間層 -- HIVE_CLUSTER 和 HIVE_UNIT

KernelHive 框架的總開銷比面向性能的 MPI + OpenCL 的總開銷高出約11%

KernelHive 框架開銷主要包括：

通信開銷 —— web 服務(wù)

運行時開銷 —— HIVE_ENGINE 和 HIVE_CLUSTER 由 Java實現(xiàn)