乾貨丨時序數據庫DolphinDB做業管理概述

做業（Job）是DolphinDB中最基本的執行單位，能夠簡單理解爲一段DolphinDB腳本代碼在DolphinDB系統中的一次執行。Job根據阻塞與否可分紅同步做業和異步做業。

同步做業

同步做業也稱爲交互式做業（Interactive Job），它的主要來源有：

• Web notebook
• DolphinDB GUI
• DolphinDB命令行界面
• 經過DolphinDB提供的各個編程語言API接口

因爲這種類型的做業對實時性要求較高，DolphinDB在執行過程當中會自動給予較高的優先級，使其更快地獲得計算資源。

異步做業

異步做業是在DolphinDB後臺執行的做業，包括：

• 經過submitJob或submitJobEx函數提交的批處理做業。
• 經過scheduleJob函數提交的定時做業。
• Streaming 做業。

這類任務通常對結果的實時反饋要求較低，且須要長期執行，DolphinDB通常會給予較低的優先級。

子任務

在DolphinDB中，若數據表數據量過大，通常都須要進行分區處理。若是一個Job A裏含有分區表的查詢計算任務（如SQL查詢），將會分解成多個子任務並送到不一樣的節點上並行執行，等待子任務執行完畢以後，再合併結果，繼續Job A的執行。相似的，DolphinDB的分佈式計算也會產生子任務。所以，Job也能夠理解成一系列的子任務。

Worker與Executor

DolphinDB是一個P2P架構的系統，即每個Data Node的角色都是相同的，它們均可以執行來自用戶提交的Job，而由於一個Job可能產生子任務，每一個Data Node須要有負責Job內部執行的調度者，咱們稱它爲Worker，它負責處理用戶提交的Job，簡單計算任務的執行，並執行Job的任務分解，任務分發，並聚集最終的執行結果。Job中分解出來的子任務將會被分發到集羣中的Data Node上（也有多是本地Data Node），並由Data Node上的Worker或Executor線程負責執行。

具體Worker與executor在執行job的時候主要有如下幾種狀況：

• 當一個表沒有進行分區，對其查詢的Job將會有Worker線程執行掉。
• 當一個表被分區存放在單機上時候，對其的查詢Job可能會分解成多個子任務，並由該節點上的多個Executor線程執行，達到並行計算的效果。
• 當一個表被分區存儲在DFS時，對其查詢的Job可能會被分解成多個子任務，這些子任務會被分發給其餘Node的Worker上執行，達到分佈式計算的效果。

爲了最大化性能，DolphinDB會將子任務發送到數據所在的Data Node上執行，以減小網絡傳輸開銷。好比：

• 對於存儲在DFS中的分區表，Worker將會根據分區模式以及分區當前所在Data Node來進行任務分解與分發。
• 對於分佈式計算，Worker將會根據數據源信息，發送子任務到相應的數據源Data Node執行。

Job調度

Job優先級

在DolphinDB中，Job是按照優先級進行調度的，優先級的取值範圍爲0-9，取值越高優先級則越高。對於優先級高的Job，系統會更及時地給與計算資源。每一個Job通常默認會有一個default priority，取值爲4，而後根據Job的類型又會有所調整。

Job調度策略

基於Job的優先級，DolphinDB設計了多級反饋隊列來調度Job的執行。具體來講，系統維護了10個隊列，分別對應10個優先級，系統老是分配線程資源給高優先級的Job，對於處於相同優先級的Job，系統會以round robin的方式分配線程資源給Job；當一個優先級隊列爲空的時候，纔會處理低優先級的隊列中的Job。

Job並行度

因爲一個Job可能會分紅多個並行子任務，DolphinDB的Job還擁有一個並行度parallelism，表示在一個Data Node上，將會最多同時用多少個線程來執行Job產生的並行任務，默認取值爲2，能夠認爲是一種時間片單位。舉個例子，若一個Job的並行度爲2，Job產生了100個並行子任務，那麼Job被調度的時候系統只會分配2個線程用於子任務的計算，所以須要50輪調度才能完成整個Job的執行。

Job優先級的動態變化

爲了防止處於低優先級的Job被長時間飢餓，DolphinDB會適當下降Job的優先級。具體的作法是，當一個job的時間片被執行完畢後，若是存在比其低優先級的Job，那麼將會自動下降一級優先級。當優先級到達最低點後，又回到初始的優先級。所以低優先級的任務早晚會被調度到，解決了飢餓問題。

設置Job的優先級

DolphinDB的Job的優先級能夠經過如下方式來設置：

• 對於console、web notebook以及API提交上來的都屬於interactive job，其優先級取值爲min(4，一個可調節的用戶最高優先級)，所以能夠經過改變用戶自身的優先級值來調整。
• 對於經過submitJob提交上的batch job，系統會給與default priority，即爲4。用戶也可使用submitJobEx函數來指定優先級。
• 定時任務的優先級沒法改變，默認爲4。

計算容錯

DolphinDB database 的分佈式計算含有必定的容錯性，主要得益於分區副本冗餘存儲。當一個子任務被髮送到一個分區副本節點上以後，若節點出現故障或者分區副本發生了數據校驗錯誤(副本損壞），Job Scheduler(即某個Data Node的一個worke線程)將會發現這個故障，而且選擇該分區的另外一個副本節點，從新執行子任務。用戶能夠經過設置dfsReplicationFactor參數來調整這種冗餘度。

計算與存儲耦合以及做業之間的數據共享

DolphinDB的計算是儘可能靠近存儲的。DolphinDB之因此不採用計算存儲分離，主要有如下幾個緣由：

1. 計算與存儲分離會出現數據冗餘。考慮存儲與計算分離的Spark+Hive架構，Spark應用程序之間是不共享存儲的。若N個Spark應用程序從Hive讀取某個表T的數據，那麼首先T要加載到N個Spark應用程序的內存中，存在N份，這將形成機器內存的的浪費。在多用戶場景下，好比一份tick數據可能會被多個分析人員共享訪問，若是採起Spark那種模式，將會提升IT成本。
2. 拷貝帶來的延遲問題。雖說如今數據中心逐漸配備了RDMA，NVMe等新硬件，網絡延遲和吞吐已經大大提升。可是這主要仍是在數據中心，DolphinDB系統的部署環境可能沒有這麼好的網絡環境以及硬件設施，數據在網絡之間的傳輸會成爲嚴重的性能瓶頸。

綜上這些緣由，DolphinDB採起了計算與存儲耦合的架構。具體來講：

1. 對於內存浪費的問題，DolphinDB的解決方案是Job（對應Spark應用程序）之間共享數據。在數據通過分區存儲到DolphinDB的DFS中以後，每一個分區的副本都會有本身所屬的節點，在一個節點上的分區副本將會在內存中只存在一份。當多個Job的子任務都涉及到同一個分區副本時，該分區副本在內存中能夠被共享地讀取，減小了內存的浪費。
2. 對於拷貝帶來的延遲問題，DolphinDB的解決方案是將計算髮送到數據所在的節點上。一個Job根據DFS的分區信息會被分解成多個子任務，發送到分區所在的節點上執行。由於發送計算到數據所在的節點上至關於只是發送一段代碼，網絡開銷大大減小。