導讀
一條SQL語句的執行究竟經曆了哪些過程？作者作為一個剛入職的大資料研發新人對SQL任務執行整個流程進行了整理，本文就作者學習内容和體會供大家參考。
作為一個剛剛入職的大資料萌新研發，我對SQL任務執行整個流程充滿好奇，一條SQL語句的執行究竟經曆了哪些過程？在查閱了相關文檔之後，我整理得到了這篇文檔，在此分享我的學習内容和體會供大家參考。
一、整體流程
一個SQL任務從建立到得到運作結果，中間涉及到了多個系統間的互動，這裡我們先給出一張整體的流程圖，接下來就讓我們從一個簡單的小需求—統計活動中每個獎品的發放數量，開始我們的探索之旅吧。
二、任務開發上線
建立&編輯任務
首先，我們需要在IDE中建立并編寫一個SQL任務，在DataPhin研發頁面建立離線周期計算任務，編寫sql代碼。
統計每個活動獎品數量的SQL：
SELECT prize_id
,COUNT(*) AS prize_send_cnt_1d
FROM apcdm.dwd_ap_mkt_eqt_send_di
WHERE dt = '${bizdate}'
AND prize_id IN ('PZ169328936', 'PZ169298703')
GROUP BY prize_id; 配置排程資訊
在編寫完SQL任務之後，我們需要配置任務的排程資訊。這些排程資訊被視為任務的中繼資料，并通過資料庫進行維護。隻有在配置了正确的排程資訊之後，任務才能被正确地排程和執行。常見的SQL任務配置如下表所示：
| 基本資訊 | 任務節點id、任務名稱、節點類型、運維負責人 |
| 排程參數 | Dataphin任務排程時使用的參數，根據任務排程的業務日期、定時時間及參數的取值格式自動替換為具體的值，實作在任務排程時間内參數的動态替換。 業務日期：排程日期前一天 排程/定時時間：任務執行個體計劃運作的時間 |
| 排程屬性 | 執行個體生成方式：T+1次日生成、釋出後即時生成 |
| 排程類型：正常排程、暫停排程、空跑排程 | |
| 生效日期：自動排程運作的日期範圍 | |
| 重跑屬性：多次重跑是否會影響結果 | |
| 排程周期：按照規律間隔多久執行一次該任務，可分為月排程、周排程、日排程、小時排程和分鐘排程 | |
| cron表達式：對應排程周期cron表達式 | |
| 排程依賴 | 節點間的上下遊依賴關系，上遊任務節點運作完成且運作成功，下遊任務節點才會開始運作。 |
| 節點上下文參數 | 輸入參數（接收上遊節點的輸出參數值作為目前節點的輸入）、輸出參數 |
| 執行資訊 | 執行引擎、排程資源組 |
送出釋出
在完成SQL任務的編寫和排程資訊的配置後，我們可以送出任務并生成釋出包。在進行釋出之前，我們可以在開發環境中進行冒煙測試。冒煙測試會生成一個包含代碼和排程資訊的執行個體。選擇昨日之前生成的執行個體，其排程時間已經滿足，任務會立即運作。選擇昨日生成的執行個體需要等待排程時間到達才會運作。任務送出并且冒煙測試通過後，我們可以進入釋出中心中，選中待釋出的任務對象，進行釋出。
三、轉執行個體/執行個體生産
現在任務已經釋出到線上了，後面會發生什麼呢？
時間來到晚上22:00，此時Phoenix排程系統開始忙碌起來了，它根據大家釋出的任務節點定義，提前編譯生成了一批可執行的任務執行個體，并且根據任務之間的血緣依賴和時間依賴，将這一批任務執行個體組成DAG去排程執行。轉執行個體時，還會通過系統内置的解析函數解析任務配置的cron時間表達式，為對應任務執行個體設定具體的運作時間。
四、定時排程/執行個體啟動
經過上一步轉執行個體的過程，對應的任務執行個體DAG也就緒了。那麼接下來怎麼在正确的時間，将任務執行個體喚起執行呢？
早期的執行個體排程系統是使用Quartz架構實作的，通過注冊Quartz事件，并配置觸發器的cron時間表達式來指定事件的觸發時間。Quartz架構會根據時間表達式，在預定的時間點觸發相應的事件，進而啟動對應的任務執行個體。由于Quartz架構在執行個體數量達到百萬量級的時候會出現性能瓶頸，新的排程引擎采用的資料庫維護狀态+異步查詢的自研方案。具體來說，就是通過在資料庫維護所有任務執行個體的執行時間，而後排程系統的背景線程異步定時查詢滿足時間的任務執行個體，觸發啟動執行。
五、排程資源配置設定
喚起任務執行個體之後，我們需要給執行個體配置設定資源，送出給ODPS去執行，這部分邏輯是由執行引擎Alisa來完成的。
Alisa拿到任務後，基于任務資源組資源是否空閑、排程任務執行叢集資源是否空閑将任務下發到某台gateway上送出。gateway是Alisa叢集中負責送出ODPS任務和管理任務狀态的程序，由于任務要送出到計算引擎去執行，在送出任務到任務運作的過程中會一直保持一個會話連接配接，需要占用一個槽位（slot），槽位其實是指送出任務的能力。為了保障重要業務優先使用資源，以及滿足多使用者、多租戶資源使用需求，設計了gateway執行叢集和資源組模式來控制任務使用的槽位。一個叢集可以包含多台gateway機器，叢集的槽位可以配置設定給多個資源組使用。
通過将項目空間設定到某個資源組，這個項目空間送出的任務就能夠使用這個資源組的槽位，每個資源組通過設定最大槽位(max_slot)來控制并發，可通過tesla實時檢視項目空間的槽位使用情況。
Alisa執行引擎負責管理slot使用情況，并且實時的和每台gateway機器保持一個心跳連接配接，負責給任務配置設定槽位。若排程槽位打滿，那麼作業處于擁塞狀态，等待配置設定槽位。當任務配置設定到槽位後，就會在Alisa指定的gateway機器上開始送出任務，即在gateway上啟動odpscmd程序，通過odpscmd送出作業。
六、ODPS運作作業
任務通過gateway程序使用odpscmd的方式送出作業之後，正式進入的ODPS系統的執行過程。
ODPS系統可以分為控制層和計算層兩個部分，送出的作業會先進入odps的控制層，控制層包括請求處理器Worker、排程器Scheduler和作業執行管理器Executor。作業送出生成instance後，Scheduler會負責instance的排程。Scheduler首先維護一個instance清單，然後從清單中取出instance，把Instance分解成多個Task，把可運作的Task放到優先級隊列TaskPool中，進入控制叢集排隊。Scheduler的一個背景線程會對優先級隊列TaskPool定時排序，另一個背景線程會定時查詢計算叢集的資源情況。Executor主動輪詢Scheduler，Scheduler判斷如果控制叢集還有資源，就把排序第一的SQLTask發送給Executor。
Executor在拿到任務之後，會對SQL調用SQL Parse Planner詞法文法分析器，經過詞法分析、文法分析後得到抽象文法樹（AST），然後經過邏輯分析後得到優化後的邏輯執行計劃，再經過實體分析後得到優化後的實體執行計劃。
實體執行計劃中按照資料處理過程中是否需要shuffle劃分，得到實體算子DAG圖，其中一個節點對應一個Fuxi Task，根據DAG圖和instance的元資訊（每個Fuxi Task的執行個體個數、資源規格等），生成Fuxi Job的配置檔案，送出給Fuxi Master。
七、Fuxi計算層
伏羲是大資料計算平台的分布式排程執行架構，支撐着ODPS以及PAI等多種計算引擎每天上千萬分布式作業的執行，用于處理每天EB級别的大量資料。伏羲叢集由Master和Agent組成，Agent分布在每個計算節點上，負責單個計算節點的資源管理，并将節點資訊彙報給Master，Master收集每個節點的資源使用情況，統一管理和協調計算資源的配置設定。
ODPS的任務經過處理變成Fuxi Task的描述檔案被送出給Fuxi Master處理，Fuxi Master會選擇一個空閑節點啟動該任務的Application Master程序。Application Master啟動之後會根據任務的配置資訊向Fuxi Master申請計算資源，後續該任務的資源申請都由Application Master去完成。
Fuxi Master收到資源請求以後，若叢集quota被打滿，資源緊張，則會在計算叢集上排隊，等待配置設定資源。若資源有空閑，會根據Application所屬的quota組、Job的優先級、是否打開搶占等條件，找到适合的資源（可能隻能滿足資源請求的一部分）配置設定給Application Master，通知Application Master程序，并将配置設定情況告知資源所在節點的Fuxi Agent。如果請求未被完全滿足時，Fuxi Master會在有其他可配置設定空閑資源時繼續配置設定資源給該Application Master。
Application Master收到資源配置設定的消息後，會将具體的作業計劃發送給相應的Fuxi Agent，作業計劃包含要啟動具體的程序所需要的資訊，可執行檔案名，啟動參數，資源(比如cpu/mem)限制等。
Fuxi Agent在接到Application Master的作業計劃後，會啟動worker作業程序。worker啟動以後，會和Application Master通信，從分布式存儲中讀取資料并開始執行計算邏輯。随着計算任務的執行，會不斷有worker被拉起和釋放，當worker完成所有計算任務之後，會将結果寫入到對應的檔案夾下，向Application Master彙報任務已成功完成，由Application Master向Fuxi Master通信完成資源釋放。
至此，整個ODPS任務執行完成，各個元件依次更新任務狀态。這個SQL任務的執行個體被置為成功，完成了其光榮的使命，等待着排程引擎的下一次喚醒。
作者:向鹿
來源-微信公衆号:阿裡雲開發者
出處:https://mp.weixin.qq.com/s/BnG0t4icxYcnnMD8hHS8Pg