前言

       随着数据量的爆炸，数据来源越来越多，例如文件、数据库、Hadoop分布式文件系统, web服务接口, MQTT, RabbitMQ, Kafka, 甚至TCP、UDP端口都可以作为数据来源。

       当用户的ETL需求比较复杂时，使用可视化Dataflow处理工具能降低使用门槛，提高效率。有两个开源的Dataflow数据处理工具，可以帮助完成复杂ETL的工作：Apache NiFi和StreamSets Data Collector（SDC），两个工具都有Web界面有。 NiFi是2014年由NASA捐赠给Apache基金会，目前的开发和支持主要由Hortonworks提供。 SDC由加利福尼亚州的一家初创公司于2014年创立，作为GitHub上的开源ETL项目。 第一个版本于2015年6月发布。

       两个产品都是用Java编写的，许可证是Apache 2.0。

架构和特性

      这两个工具都适用于创建长周期执行的作业，比如流式数据或定时的批处理。虽然可以创建手动管理的作业，但设置起来会很繁琐，参数很多，这两个工具提供的可视化界面可以完全在界面中配置好作业的相关参数，自动管理作业的执行并监控运行的状态。

Apache NiFi

        在Apache NiFi官网上，是这么介绍NiFi的：“一个易用、强大、可靠的数据处理与分发系统”。

       简单来说，NiFi用于自动化管理系统之间的Dataflow。企业中，往往有不止一个系统，其中一些系统产生数据，另外一些负责消费数据，而其中往往还有专门负责存储数据的系统。如下图所示，可以看到一个完整的从数据产生到存储，再到被消费的通用Dataflow。

       Apache NiFi的架构经过了良好的实际生产环境中的验证。 从外部源获取数据后，在Apache NiFi中Dataflow中转换为FlowFile。 FlowFile基本上是附有元信息的原始数据。 无论是CSV或其他结构化的数据，还是图片，视频，音频等任何二进制数据，都可以在Apache Nifi中进行处理。

       如上图所示，是Nifi的一个Dataflow的示例。

Nifi中有几个重要的组件，如下：

Processor组件

Processor是Nifi的重要组件，每一个Processor表示对数据的一种处理，通常有3个输出：

1. 失败。 如果无法正确处理FlowFile，则原始FlowFile将路由到此输出。
2. 原始。 处理完传入的FlowFile后，原始FlowFile将路由到此输出。
3. 成功。 成功处理的FlowFiles将路由到此关系。

可以使用复选框终止输出，因此Apache NiFi将忽略已终止的输出，并且不会在发送任何FlowFiles。

Processor Group

      Processor Group是一组Processor的集合，可以被当做一个整体被使用。 当Dataflow变得复杂时，可以将Dataflow元素组合到Processor Group中，Process Group以与普通Processor相同的方式在UI中以图形方式表示，整体表现出跟Processor类似的行为，有输入和输出，通过Processor Group可以嵌套的构建非常复杂的Dataflow。

Controller Service

     Controller Sever是Dataflow之外的特性，提供Processor配置、控制的功能。 例如SSL证书，JDBC连接和连接池配置，Schema定义等等。 Controller Service是全局的服务，不是DataFlow级别的服务。

      在Apache Nifi中Processor或者Processor Group之间使用连接线表示数据的流动，但是连接线同时还代表了一个Queue队列，队列提供了back-pressure的特性，能够控制流量，防止大流量的冲击导致Nifi宕机，每一个连接线所代表的的队列都可以单独进行精细化配置。

       例如上图中，如果LogAttribute Processor由于某种原因变慢或停止，则GenerateFlowFile处理器生成的FlowFile将在连接表示的队列中排队。 一段时间后，back-pressure反压机制触发将暂停GenerateFlowFile处理器，直到队列低于配置的阈值。

Data Provenance

       数据跟踪服务，可在处理数据时记录Dataflow中的所有内容。 用来记录Dataflow的执行历史，包括FlowFiles的已保存内容。 代价是需要更多磁盘空间来保存跟踪数据。

StreamSets Data Collector

       StreamSets中数据是有结构的，也就是说StreamSets中所有的数据都被当做record来处理。

       在Apache NiFi中，对于不同的数据格式，需要不同类型的Processor来处理，所以会导致Processor非常多，例如，一个用于CSV的版本，一个用于JSON，另一个用于Avro。 在Apache NiFi 1.5做了重大改进，其中大多数处理器都使用Avro格式，以后与Streamset一样采用有结构的数据表示形式。

       如果在运行过程中发现Processor参数配置的不合理，在Apache Nifi中可以停掉某一个具体的Processor，配置完毕，重新启动即可，在这个过程中，上游的Processor会停止发送数据，恢复之后，数据不会丢失。但是在StreamSets中，需要停掉整个作业任务，配置完毕，重启整个作业任务，这一点Nifi比较灵活。

     虽然StreamSets修改参数需要重启整个Dataflow作业，但这并不意味着Streamsets的DataFlow更难调试。 实际上更容易，StreamSets有一个精美的实时数据仪表盘，在Dataflow运行时显示每个Processor的大量统计数据。 错误在Processor图标上清晰地显示为红色数字，可以通过鼠标单击查看每个错误记录的个别错误。 甚至可以在Processor之间的连接上放置记录过滤器以检查有问题的记录。 可以在Dataflow运行时应用过滤器，用作实时调试工具。

Streamsets有4种Processor类型：

      Origin：用来从外部来源获取数据。Dataflow中可能只有一个Origin处理器。

      Processor：用来对数据做转换。

      Destination：用来将数据保存到外部系统或文件。

      Executor：用来处理由其他处Processor生成的事件。一些Streamsets Processor在处理过程中可能会产生错误、异常等事件。 在StreamSet使用称为Executors的特殊Processor来处理。 例如，Email Executor，可以在发生错误时发送电子邮件。

       相比之下Nifi的Processor、Controller Server架构设计的更简洁、更容易理解，StreamSets稍微复杂一些，但是使用起来也挺方便。

 

UI界面

Apache Nifi

Apache NiFi UI没什么好说的。 界面美观程度一般，但是设计的比较紧凑，感觉简洁，并且很容易上手。

SteamSets

StreamSets的UI界面毫无疑问要漂亮很多，但在使用过程中的时候也不是完美的。

首先，没有Controller Service，特别是JDBC的设置，导致就算是从同一个数据源读取数据，也需要手动配置每一个Processor的JDBC参数，使用起来不够友好。

其次，在启动Dataflow之前，Streamsets将检查Dataflow中的每个Processor，以确保正确配置所有处理器。这听起来像是一件好事，有时能帮助找到错误，但有时候会特别麻烦。例如在Apache NiFi中，可以使用断开连接的处理器，将它们保留用于调试目的。在Streamsets中，无法执行相同操作，因为必须连接所有处理器才能进行Dataflow验证。

最后，在界面上无法同时选中多个Processor，调整Processor的布局时候，如果量特别多操作起来稍微有些麻烦。

 

总结

上边简要介绍了Apache NiFi和Streamsets，有很多有用的功能并没有详细提及。两者也都有二次开发或者对接其他数据处理引擎的功能，即便是官方的提供的功能中没有我们想要的数据处理的逻辑，也可以通过 Python，Javascript，R甚至Apache Spark，来编写Apache NiFi或Streamsets Dataflow中的复杂数据转换逻辑。

Apache NiFi和Streamset都是成熟的开源ETL工具，各有千秋。Streamsets中的实时监控的功能非常有用，可以掩盖其他的小问题。

产品	优点	不足
Apache Nifi	清晰简洁的Dataflow概念， 可以处理二进制数据 数据来源	朴素的UI界面 没有每个记录级别的统计信息的实时监控/调试功能
StreamSets	实时监控/调试功能，每个处理器都有可视化的每条记录统计信息 美观的UI界面 非常适合基于有结构的数据和流式数据	编辑单个处理器配置，需要停止整个Dataflow 处理器没有可重用的JDBC配置