数据采集中间件技术对比V1.0

---

1 前言

大数据平台一般包括以下几个步骤：
数据采集 -> 数据存储 -> 数据分析 -> 数据展示(可视化、报表、监控等)
其中数据采集是一个十分重要的组成部分。大数据采集的任务也有许多特点，比如：数量大、数据源多样性、变化快、保证数据正确、避免数据重复等。
这里我们调研了几款常用的大数据采集中间件：datax、flume、sqoop、canal、maxwell、nifi和kettle。
以下，将从几个方面对比着7款中间件。以便在各种数据采集需求下能选用更加适合的工具。
另外，这里放几个大厂实践的例子作为参考。

2 数据采集中间件对比

具体的安装使用步骤这里不过多赘述，详情请查看对应的技术实践文档。

2.1 支持的数据源

数据采集中间件一个比较重要的特征就是所支持的数据源。

1. flume：flume支持的数据源一般是文件或者目录，比如单点采集时候接收单个文件；TailDIR监控目录；
2. sqoop：Sqoop支持的数据源一般是RMDB，比如mysql、oracle、hive和hdfs等；
3. datax：datax支持的也是关系型数据库
4. canal：Canal由于原理上是伪slave，所以基本只支持开启了binlog的mysql；
5. maxwell：与canal相同，只支持开启了binlog的mysql；
6. nifi：Nifi界面化操作，只要是能在processor中搜索的到数据格式都能支持。比如，mysql和kafka。
7. kettle：在Kettle实践的文档中可以看到Kettle支持的数据源是非常多样化的，比如：文本、数据表、CSV、hbase、msyql、hdfs等等。

2.2 支持的数据格式

综合2.1的分析，再看这些中间件支持的数据格式：

1. flume：支持文件格式。avro、thrift、exec、jms、spooling directory、netcat、sequence generator、syslog、http、legacy；
2. sqoop：由于RMDB和HDFS的局限，仅支持SQL表和hdfs中的结构化数据；
3. Datax：与sqoop一样也是sql或者hdfs文件
4. canal：输入的数据仅仅支持mysql的binlog，输出的文件可以定制；
5. maxwell：输入的文件格式也是binlog，但是输出的格式也有限制，是json。详见maxwell的实践文档；
6. nifi：processor界面可以搜索的到文件格式都支持，比如csv、db、文本、kafka数据等；
7. kettle：同样，trans中能搜索到的文件格式都支持，比如Habse表，mysql表、 文本、CSV等等。

2.3 支持的上下游中间件

说完数据源和文件格式，在对比一下支持的上下游插件，毕竟大数据百花齐放，中间件众多，多支持一个多一份竞争力：

1. flume：flume上下游支持的中间件常用的有hdfs和hbase；
2. sqoop：sqoop上下游支持的中间件常用的有mysql、oracle、hdfs；
3. datax：支持的上下游与sqoop相似
4. canal：canal上游只支持mysql(MariaDB)、下游支持的中间件可以定制，一般是kafka；
5. maxwell：与canal一样上游只支持mysql，但是不可定制，只支持kafka等；
6. nifi：支持的上下游中间件众多，kafka；
7. kettle：同样支持众多中间件，比如，mysql、hbase、hdfs等等。

2.4 任务监控

1. flume：Ganglia第三方插件监控；
2. sqoop：无；
3. datax：需要另外部署datax-web。官方自带
4. canal：无；
5. maxwell：无；
6. nifi：自带界面可视化监控；
7. kettle：自带界面可视化监控。

3 MYSQL的BINLOG日志工具分析：CANAL、MAXWELL

参考链接：https://mp.weixin.qq.com/s/ePI5oU0aLElOtxaB7EFUyg
这篇文章对比了canal、maxwell和其他两种binlog日志分析工具。这里只拣关注的部分看。首先是介绍了canal原理，其实maxwell原理也是一样的：

由于canal和maxwell太多一样的地方，就直接给对比的结果了：

4 有赞大数据：FLUME 数据采集服务最佳实践

参考链接：https://www.sohu.com/a/300084430_753508
该文章主要写了有赞大数据Flume采集架构的演变和性能优化：

这是第一个版本的架构，采用的NsqSource和FileChannel到hdfsSink；

在第二个版本，出于对FileChannel故障的考虑，采用了扩展出来的NsqSourceChannel，好处是：
• 每个消息的传递只需要一次事务，而非两次，性能上更佳。
• 避免引入了新的 kafka 服务，减少了资源成本的同时保持架构上更简单从而更稳定。

5 基于NIFI+SPARK STREAMING的流式采集

参考链接：https://cloud.tencent.com/developer/article/1654949
本文采用NiFi+Spark Streaming的技术方案设计了一种针对各种外部数据源的通用实时采集处理方法。

本方案采用NiFi进行采集数据，然后经过Spark Streaming流式处理引擎，将采集的数据进行指定的转换，生成新数据发送到Kafka系统，为后续业务或流程提供，如Kylin流式模型构建。

6 基于OGG和SQOOP的TBDS接入方案系列-SQOOP与腾讯大数据套件TBDS的集成示例介绍

参考链接：https://cloud.tencent.com/developer/article/1444731
此案例介绍了一个利用Sqoop将数据从Oracle离线导入到腾讯大数据套件TBDS中Hadoop和Hive组件的场景。
文章很长，基本就是一些sqoop的常用用法，导入到hdfs和hive。核心的命令就是sqoop import:

7 利用KETTLE进行SQLSERVER与ORACLE之间的数据迁移实践

参考链接：https://www.cnblogs.com/hans_gis/p/10591174.html
这个案例介绍了将SQLServer中的数据导出到Oracle中，主要是一些技术实现，任务视图如下：

分别在表输入和表输出中配置SqlServer和oracle的连接信息即可。

8 总结

这里简单总结一下这些数据采集中间件的特点。
按照他们的特征，我把这6款中间件简单分为3类：Canal和Maxwell都是作为Binglog同步工具；Kettle和Nifi都是界面可视化操作；Flume和Sqoop是命令行操作。全部放在一起对比各有特色，但是按照用途来讲的话就很好比较了：
flume：文件采集；
sqoop：RMDB到hdfs/hive/hbase的文件采集，或者反向hdfs到RMDB导出；
canal/maxwell：mysql增量数据的实时监控，有点区别就是maxwell直接输出为json到kafka；canal还得解析，但也多了一分灵活；
kettle/nifi：都是可视化界面的拖拉拽操作，但是实现的功能侧重是不一样的。Kettle强于ETL操作，Nifi的强项是数据流的采集。
说到这里，基本上各自的应用场景都很清晰了，只是flume和Nifi好像都是强于文件采集。但是侧重点又有点不一样，Flume没有可视化界面，他的操作都在flume/conf/下的配置文件中，虽然只有source/channel/sink但是采集更加灵活。而Nifi采集的配置在processor中根据选项选出来。
最后按照对比总结一下6款中间件适用的场景：

1. flume：适合复杂的文件采集；
2. sqoop：适合RMDB到大数据平台其他中间件的传输，比如hdfs/hive/hbase；
3. datax：与sqoop高度相似，又比sqoop各方面要强一点。有替代sqoop的趋势；
4. canal：适合mymql增量数据的实时同步，可以支持格式，输出的多样化；
5. maxwell：适合mysql增量数据快速实时同步到kafka；
6. Nifi：适合简单的文件流传输操作，有简单的可视化界面，学习成本低；
7. Kettle：适合复杂的ETL操作，并且有可视化界面，操作简单。