| 佔用獨立服務器，獨立部署，獨立運維 |
集成在 EMR 中，不需要部署，不需要特運維 |
| 代碼文件打包成 zip，手動上傳 |
代碼文件手動上傳到 OSS |
| 一個項目下可以都多個工作流，但是必須在一個 zip 包中，上傳後自動解析 flow。flow 之間無法直接依賴。 |
一個項目可以多個工作流，工作流之間可以互相依賴。 |
| 每個 flow 下的 job，支持 hive、shell、spark 等 |
每個 flow 下的 job，支持 hive、shell、spark 等 |
| sql 文件、作業之間的依賴關係都在 zip 包中，azkaban 自動解析 |
需要爲每個sql 創建一個job 作業，類型是 shell，引用 oss 上的 shell 命令和 sql 腳本：azkaban 上有接近 80 個作業，在 EMR 上就需要創建 80 多個 job 作業； 每個作業都要寫 shell 命令； 併爲每個作業指定執行隊列bi和執行用戶 hadoop |
| 一個工作流需要維護一個.flow結尾的配置文件，flow 下的作業的依賴關係都維護在這個文件中，可以通過依賴圖看到 job 間的依賴關係。 |
基於 EMR 上創建好的作業，可以在工作流界面通過拖拽的方式創建工作流；此次測試，按照業務 IM、CDR、DM、SMS、Tickets、UserCenter 等業務分別創建的工作流，因此沒有一個全局的依賴關係圖 |
| flow 之間無法直接依賴 |
flow 間可以配置依賴關係 |
| 一個flow 有一個可視化的依賴關係圖 |
一個 flow 有可視化圖，有依賴關係的 flow 沒有可視化依賴圖 |
| 一個 flow 下的依賴越來越多時，可視化的依賴圖會越來越龐大 |
一個flow 下的依賴越來越多時，可以拆分成小的 flow，flow 之間形成依賴，但是沒有可視化的依賴圖 |
| 正常的調度執行 |
正常的調度執行 |
| flow調度執行失敗後，作業恢復：執行單個作業；快速選擇某個作業的父節點執行；快速選擇某個作業的子節點執行；快速選擇某個作業的全部依賴作業並執行 |
flow調度執行失敗後，作業恢復：一個 flow 失敗，可以整個 flow 重新執行，或者每個作業手動去執行；flow 間的依賴導致的失敗，需要一個個flow 手動修復 |
