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

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

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

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

對(duì)于低級(jí)的通用 GPU 編程，最流行的是 CUDA 和 OpenCL。大致思路是

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

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

塊和塊之間獨(dú)立運(yùn)行

CUDA 在 GPU 方面只針對(duì) NVIDIA 的 GPU， OpenCL 可以在多種 GPU 和 CPU 上運(yùn)行

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

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

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

自動(dòng)調(diào)度

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

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

創(chuàng)新點(diǎn)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

處理邏輯可以為多種多樣的 workers 定義。不同的 workers 對(duì)應(yīng)不同的 KernelHive 框架模版。模版已經(jīng)通過用 C++ 實(shí)現(xiàn)由 worker 子系統(tǒng)定義的抽象類 Worker?；灸０孀罡镜膮^(qū)分僅僅在于被 worker 處理的輸入和輸出量。具體包含一下3部分：

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

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

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

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

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

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

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

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

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

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

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

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

一個(gè) C++ 守護(hù)進(jìn)程。用來提供對(duì)單個(gè)集群節(jié)點(diǎn)的資源訪問?？捎糜诳刂乒?jié)點(diǎn)中的計(jì)算設(shè)備

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

任務(wù)：

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

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

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

運(yùn)行在操作系統(tǒng)級(jí)別

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

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

HIVE_UNIT 部署在每個(gè)節(jié)點(diǎn)上

一個(gè)集群中只有一個(gè)節(jié)點(diǎn)部署有 HIVE_CLUSTER

GUI 的作用：

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

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

完成

處理中

已調(diào)度

錯(cuò)誤，等

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

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

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

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

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

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

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

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

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

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

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

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

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

運(yùn)行內(nèi)核

報(bào)告計(jì)算進(jìn)度

上傳結(jié)果

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

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

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

把當(dāng)前作業(yè)的偏移量存入內(nèi)存，根據(jù)當(dāng)前計(jì)算狀態(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ù)庫(kù)或文件系統(tǒng)時(shí)，需要實(shí)現(xiàn)與所有相關(guān)子系統(tǒng)有關(guān)的相關(guān)編程接口。比如內(nèi)存數(shù)據(jù)庫(kù)和MongoDB。

因?yàn)橄到y(tǒng)的異構(gòu)問題，數(shù)據(jù)格式的兼容性問題格外重要。

OpenCL標(biāo)準(zhǔn)定義了一些數(shù)據(jù)類型，這些數(shù)據(jù)類型的長(zhǎng)度與底層的系統(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ù)時(shí)，再自行下載

HIVE_ENGINE 決定是否需要存儲(chǔ)數(shù)據(jù)包和是否能夠刪除數(shù)據(jù)。這使得數(shù)據(jù)直接在計(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ì)算的機(jī)制

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

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

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

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

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

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

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

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

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

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

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

調(diào)度

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

真正的并行執(zhí)行

同時(shí)有 GPU 和 CPU

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

暴力破解 MD5 加密

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

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

GPU 內(nèi)部

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

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

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

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

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

測(cè)試內(nèi)容

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

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

測(cè)試結(jié)論

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

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

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

時(shí)間開銷如下：

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

處理時(shí)間

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

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

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

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

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

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

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

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

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

master--slave 模型

master -- HIVE_ENGINE

slave -- HIVE_WORKER

中間層 -- HIVE_CLUSTER 和 HIVE_UNIT

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

KernelHive 框架開銷主要包括：

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

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