Day29 NiFi 与其他工具的比较

这边我想特别写出这一篇的原因是当初我在学习与操作 NiFi 的过程中，我曾感到一些疑惑，会觉得感觉有些场景流程可以用像是 Apache Airflow 等工具就可以做到了，为何需要再去学 Apache NiFi 这套工具。因为我自身的经验先前都是拿 Apache Airflow 来做一些 Pipeline 的设计，毕竟在台湾 Airflow 的普及率我觉得比 NiFi 来得高，所以才会有这样的疑问，也认为相关类似经验的开发人员也会有类似的疑问。所以我後来经过一些了解与研究之後，其实他们的设计理念与原理仍有很大的不同，所以才特别提出这篇来做一个分享。

Apache Airflow vs. Apache NiFi

Apache Airflow

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

我们都知道 Apache NiFi 是一种 Data Pipeline Tool，所以从下图来看：

我们可以知道在 NiFi 的 Flow 当中，他是必须要从某个地方读取Data 或存取 Data，可能是来自 File、Storage、DB 等，所以他是 Data-Oriented 的服务，来大家也都已经知道了 Apache Nifi 的特性，像是可处理多个资料来源、Streaming 资料处理与转换、资料变化的动态追总等。那更详细地重要比较，我直接整理下表给大家来做更清楚地比较。

所以简单来说，只要你的服务当中的 task 不太需要上游的资料且相互独立时，或许 Airflow 会是一个较好的选择; 反之，如果都需要从每一个地方读取资料做处理，接着处理完再存回到另一个地方时，则 NiFi 就会是一个更适合的选择。

小总结

以上是我对 NiFi 和 Airflow 简单的比较分享，当然两个在企业的案例上都有机会被拿来作为 ETL 的使用工具，所以这当中取决於原先的架构设计与理念，像是 Batch 或 Streaming，当中所牵扯到的任务与服务、系统复杂性、成本考量与需求等，最後再来选择出适合的服务才会是最好的。

除了这两个服务较常被用来作 ETL 之外，另外还有像是 Apache StreamSets、AWS DataPipeline、AWS Glue 等都可做到类似的事情，当然当中会有细节上的差异，所以这边也提供一些选择给读者们来做个参考。

Reference

• Apache NiFi vs Airflow: Overview and Comparison Study