這邊我想特別寫出這一篇的原因是當初我在學習與操作 NiFi 的過程中，我曾感到一些疑惑，會覺得感覺有些場景流程可以用像是 Apache Airflow 等工具就可以做到了，為何需要再去學 Apache NiFi 這套工具。因為我自身的經驗先前都是拿 Apache Airflow 來做一些 Pipeline 的設計，畢竟在台灣 Airflow 的普及率我覺得比 NiFi 來得高，所以才會有這樣的疑問，也認為相關類似經驗的開發人員也會有類似的疑問。所以我後來經過一些了解與研究之後，其實他們的設計理念與原理仍有很大的不同，所以才特別提出這篇來做一個分享。
Apache Airflow 我們都知道他是一個 workflow 的工具，他同樣有 schedule 的機制，可以讓我們輕鬆地去做工作的排程任務，再者他也支援像是 AWS, GCP 等服務的 Operators。下面我簡單畫了一下他的運作原理：
從塗上我們可以看到 Airflow 是由 Operator 來組成，舉例來說像是 EmrCreateJobFlowOperator, S3ToGoogleCloudStorageTransferOperator, MLEngineStartTrainingJobOperator 等，每一個 Operator 通常都會有各自獨立的 job，所以通常較少需要用到上游所產生的資料，因為他就是一個以 Job-Oriented 的工具，也就是 A 任務做完接著做 B 任務，依此類推。
正因為 Airflow 是偏向 Job-Oriented，所以會發現他提供的 operator 不單單僅有 DB 或 Data Storage 等類型，像是其他的應用服務也都有提供, ex. EMR, ML engine 等，因為它希望以 工作任務導向 的去做排程，他的 Flow 設計也不需要一定要去哪裡拿資料或是去存放資料才能運作，所以 Airflow 也被稱作為 Workflow Tool。
接著 Airflow 也沒有像是 NiFi 有所謂的 Connection 的概念，他必須透過像是 PythonBranchOperator 來判斷前一個 Operator 來決定下游 Operator 怎麼走，而 NiFi 的 Processor 則通常會有 Success 和 Failed 等 Connection 來做分流與判斷。
我們都知道 Apache NiFi 是一種 Data Pipeline Tool，所以從下圖來看：
我們可以知道在 NiFi 的 Flow 當中，他是必須要從某個地方讀取Data 或存取 Data，可能是來自 File、Storage、DB 等，所以他是 Data-Oriented 的服務，來大家也都已經知道了 Apache Nifi 的特性，像是可處理多個資料來源、Streaming 資料處理與轉換、資料變化的動態追總等。那更詳細地重要比較，我直接整理下表給大家來做更清楚地比較。
| Apache Airflow | Apache NiFi | |
|---|---|---|
| 底層語言 | Python | Java |
| 任務導向 | Job oriented | Data oriented |
| 核心處理單元 | Operators，除了 DB 類型之外，其他像是工作類型的服務也有支援 | Procesors，只支援 DB, Message Queue等與資料相關的服務。 |
| 能否取得上游資訊 | 不行，除非特別 push xcom，否則下游無法取得上游 opertor 的資訊 | FlowFiles 本身就會帶著上游 Processor 產生的資訊到下游，所以後續的 Processor 都可以應用到上游的 metadata |
| Schedule | 較偏向於 Batch 的操作 | 較適用於 Streaming 的操作 |
所以簡單來說，只要你的服務當中的 task 不太需要上游的資料且相互獨立時，或許 Airflow 會是一個較好的選擇; 反之，如果都需要從每一個地方讀取資料做處理，接著處理完再存回到另一個地方時，則 NiFi 就會是一個更適合的選擇。
以上是我對 NiFi 和 Airflow 簡單的比較分享，當然兩個在企業的案例上都有機會被拿來作為 ETL 的使用工具，所以這當中取決於原先的架構設計與理念，像是 Batch 或 Streaming，當中所牽扯到的任務與服務、系統複雜性、成本考量與需求等，最後再來選擇出適合的服務才會是最好的。
除了這兩個服務較常被用來作 ETL 之外，另外還有像是 Apache StreamSets、AWS DataPipeline、AWS Glue 等都可做到類似的事情，當然當中會有細節上的差異，所以這邊也提供一些選擇給讀者們來做個參考。
iThome鐵人賽
看影片追技術