Oozie調研
在作業設計器中，實用哪種作業工作流的引擎是最主要的，現在對Oozie進行調研。
一．Oozie介紹
Oozie是一種工作流引擎，用於運行MR，Spark Job（有待測試），Pig等任務工作流。它是以Web呈現給用戶，運行在Tomcat中。
工作流以多個Action作爲組成部分，Action以有向無環圖DAG的模式部署運行，工作流通過HDPL（一種類似於XML的自定義處理語言）來構造。
Oozie工作流中的Action在運程系統運行如(Hadoop,Pig服務器上).一旦Action完成,遠程服務器將回調Oozie的接口並通知Action已經完成,這時Oozie又會以同樣的方式執行工作流中的下一個Action,直到工作流中所有Action都完成(完成包括失敗)。
在工作流中主要分爲兩類工作流點：
|
節點名 |
解析 |
|
可控點（Control flow node） |
這個爲Oozie的語法，定義了流開始，結束，失敗以及選擇（decision），並行（fork），join（合併）的節點。 |
|
Action節點 |
各種不同任務類型的節點如：java，Pig，MR等 |
二．Oozie的搭建
Oozie作爲一個Server對外提供Web頁面，效果圖如下：
上面記錄了歷史的作業。以及作業的狀態。如果運行失敗，則節點會報錯，不會像Azkaban一樣只要執行結束就可返回成功。
Oozie提供了Client用於提交和管理作業，每個作業包含結構如下：
其中:
|
job.properties |
任務的一些配置文件，例如運行的HDFS以及JobTracker (ResourceManager)等 |
|
Lib |
存放執行的JAR包 |
|
Workflow.xml |
工作流的依賴 |
|
****.jar |
執行任務的jar包（自定義的文件） |
這些數據需要上傳到HDFS中才可執行。每次執行的任務記錄均保存在Mysql數據庫中。線下的數據庫有其自定義的表來存儲用戶的操作。
三．任務執行流程：
由於Oozie支持MR等java任務的job，現在測試自定義的spark任務job是否可以提交執行。
3.1 自定義spark任務
使用spark wordcount做爲測試代碼，定義的job.properties包含：
Namenode節點，設置nameNode和JobTracker以及隊列的相關類型。
Workflow.xml：
參數解析：
|
Prepare |
指定了任務在開始之前刪除和創建的路徑list |
|
Job.xml |
SparkJob的配置 |
|
Configuration |
SparkJob中間運行的配置 |
|
Master |
Spark Master url |
|
Mode |
Client or Cluster，spark運行的driver |
|
Name |
任務名 |
|
Class |
Application的Main Class() |
|
Jar |
依賴的jar或者py文件 |
|
Spark-opts |
傳遞給spark的其他配置 |
|
Args |
Application的參數 |
配置好當前任務jar，job.properties和workflow.xml之後，將依賴的lib放置在當前文件夾下的lib文件夾下。將此文件夾上傳到HDFS中。
3.2 執行任務
在ooize的client端執行：
Oozie job --oozie http://ip:11000/oozie -config ${job.properties} -run
執行之後，可以在web頁面查詢執行的結果。
可以查看每個job的執行結果以及job的相關信息。在HDFS中也會產生這個job的最終生成文件。
PS.出現錯誤是因爲集羣日誌問題。
以上的任務執行信息以及任務本身信息都會存儲與Mysql Oozie的數據庫中，這個數據庫在搭建Oozie服務器時創建。
四．代碼執行過程：
從oozie的腳本中可以得出其提交的源碼入口在：org.apache.oozie.cli.OozieCLI。
當時會生成一個OozieClient，然後使用JobCommand，提交運行的信息到V1JosServlet的doPost接口，在這個接口中會調用submitJob()方法。此時會生成一個DAG對象，然後DAG.submitJon(JobConf,startJob)。
在執行提交的任務時，Oozie會使用Instrumentation進行監控，使用org.apache.oozie.command.wf.SignalXCommand中的execute()方法對WorkFlowJobBean進行提交，MR作業的提交是通過JobClient進行發送同理Spark。（Sqoop的好像是通過Shell有待驗證）。
在Oozie爲了方便將用戶定義的Action以及Workflow進行管理，底層使用Jpa將這些數據存儲於數據庫中。
五．Oozie和Azkaban的區別：
兩者在功能方面大致相同，只是Oozie底層在提交Hadoop Spark作業是通過org.apache.hadoop的封裝好的接口進行提交，而Azkaban可以直接操作shell語句。在安全性上可能Oozie會比較好。
工作流定義：Oozie是通過xml定義的而Azkaban爲properties來定義。
部署過程：Oozie的部署太虐心了。有點難。同時它是從Yarn上拉任務日誌。
Azkaban中如果有任務出現失敗，只要進程有效執行，那麼任務就算執行成功，這是BUG，但是Oozie能有效的檢測任務的成功與失敗。
操作工作流：Azkaban使用Web操作。Oozie支持Web，RestApi，Java API操作。
權限控制：Oozie基本無權限控制，Azkaban有較完善的權限控制，入用戶對工作流讀寫執行操作。
Oozie的action主要運行在hadoop中而Azkaban的actions運行在Azkaban的服務器中。
記錄workflow的狀態：Azkaban將正在執行的workflow狀態保存在內存中，Oozie將其保存在Mysql中。
出現失敗的情況：Azkaban會丟失所有的工作流，但是Oozie可以在繼續失敗的工作流運行。
經過調研，Azkaban類似於Oozie，提供了一套有效的Ajax Api，可用於HttpClient進行通信。兩類流程引擎，在功能方面大致相似，均可支持spark Job以及Hadoop MR交叉運行，只是Azkaban的操作運行於服務器上而Oozie的操作運行於HDFS中。
但是Azkaban的操作流程比較簡易，並且部署過程不像Oozie那樣折磨人。比較偏向使用Azkaban作爲底層的流程引擎。