解决方案：数据采集中间件技术对比V1.0

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

　　1前言

　　大数据平台通常包括以下步骤：

　　数据采集->数据存储->数据分析->数据显示（可视化，报告，监视等）

　　数据采集是非常重要的部分。大数据采集的任务还具有许多特征，例如：数量大，数据源的多样性，快速变化，确保正确的数据以及避免数据重复。

　　在这里，我们研究了几种常用的大数据采集中间件：datax，水槽，鱿鱼，运河，麦克斯韦，nifi和水壶。

　　以下将从多个方面比较7种中间件。为了根据各种数据采集的需求选择更合适的工具。

　　此外，这里有一些主要工厂的做法示例可供参考。

　　2个数据采集中间件比较

　　此处不再重复特定的安装和使用步骤。有关详细信息，请参阅相应的技术实践文档。

　　2.1受支持的数据源

　　数据采集中间件的一个更重要的功能是它支持的数据源。

　　flume：flume支持的数据源通常是文件或目录，例如用于接收单个文件的单点采集； TailDIR监视目录； sqoop：Sqoop支持的数据源通常是RMDB，例如mysql，oracle，hive和hdfs等。 datax：datax还支持关系数据库canal：Canal原则上是伪奴隶，因此它基本上仅支持启用了binlog的mysql； maxwell：与运河相同，仅支持启用了binlog的mysql； nifi：Nifi接口操作，只要可以在处理器中搜索数据格式就可以支持。例如，mysql和kafka。 Kettle：在Kettle的实践文档中，您可以看到Kettle支持的数据源非常多样化，例如：文本，数据表，CSV，hbase，msyql，hdfs等。 2.2支持的数据格式

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

　　flume：支持文件格式。 avro，thrift，exec，jms，假脱机目录，netcat，序列*敏*感*词*，syslog，http，legacy； sqoop：由于RMDB和HDFS的限制，仅支持hdfs中的SQL表和结构化数据； Datax：SQL也与sqoop或hdfs文件通道相同：输入数据仅支持mysql binlog，输出文件可以自定义； maxwell：输入文件格式也为binlog，但输出格式也受限制，即json。有关详细信息，请参阅maxwell的实践文档。 nifi：支持所有可以在处理器界面中搜索的文件格式，例如csv，db，文本，kafka数据等；水壶：还支持所有可以在trans中搜索的文件格式，例如Habse表，mysql表，文本，CSV等。2.3支持的上下游中间件

　　在讨论了数据源和文件格式之后，我们来比较一下受支持的上游和下游插件。毕竟，大数据正在蓬勃发展，并且有许多中间件。还有一个更具竞争力：

　　flume：由水槽上游和下游支持的中间件是常用的hdfs和hbase； sqoop：sqoop上游和下游支持的中间件是常用的mysql，oracle，hdfs； datax：支持的上游和下游类似于sqoop运河：上游运河仅支持mysql（MariaDB），下游中间件可以定制，一般为Kafka； maxwell：像运河上游仅支持mysql，但不能自定义，仅支持kafka等； nifi：支持许多上游和下游中间件kafka； Kettle：它还支持许多中间件，例如mysql，hbase，hdfs等。2.4任务监视通道：Ganglia第三方插件监视； oop datax：需要额外部署datax-web。官方附带运河：没有；麦克斯韦：无； nifi：带有界面的可视监视；电水壶：带有界面的可视监控。 3 MYSQL的BINLOG日志工具分析：CANAL，MAXWELL

　　参考链接：

　　此文章比较运河，麦克斯韦和其他两个binlog日志分析工具。这里只挑相关部分看。首先是介绍运河的原理，其实麦克斯韦的原理是一样的：

　　

　　由于运河和麦克斯韦之间有太多相似之处，我将直接给出比较结果：

　　

　　4个Youzan大数据：FLUME数据采集服务的最佳做法

　　参考链接：

　　文章主要写了大数据Flume 采集架构的演变和性能优化：

　　

　　这是该体系结构的第一个版本，使用NsqSource和FileChannel来hdfsSink；

　　

　　在第二个版本中，出于考虑FileChannel故障的原因，使用了扩展的NsqSourceChannel。优点是：

　　•每条消息的传递仅需要一笔交易，而不是两次，因此性能更好。

　　•避免引入新的kafka服务，减少资源成本，同时保持架构更简单，更稳定。

　　5个基于NIFI + SPARK STREAMING 采集的流媒体

　　参考链接：

　　本文使用NiFi + Spark Streaming的技术方案为各种外部数据源设计通用的实时采集处理方法。

　　

　　此解决方案使用NiFi处理采集数据，然后通过Spark Streaming流引擎，将采集数据按指定进行转换，并生成新数据并将其发送到Kafka系统以用于后续服务或流程，例如Kylin Streaming模型的构建。

　　基于OGG和SQOOP的6 TBDS访问解决方案系列-SQOOP和腾讯大数据套件TBDS集成示例的介绍

　　参考链接：

　　此案例介绍了一种场景，其中Sqoop用于将数据从Oracle脱机导入到腾讯的大数据套件TBDS中的Hadoop和Hive组件。

　　文章很长，基本上是sqoop的一些常用用法，已导入hdfs和hive中。核心命令是sqoop import：

　　

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

　　参考链接：

　　此案例主要在某些技术实现中引入了将SQL Server中的数据导出到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；运河必须解析，但是它有点灵活；

　　水壶/ nifi：两者都是可视界面的拖放操作，但是实现的功能不同。 Kettle比ETL操作更强大，Nifi的优势在于数据流采集。

　　说到这里，基本上各自的应用场景都非常清楚，但是flume和Nifi似乎都比文件采集好。但是重点有所不同。 Flume没有可视界面。其操作全部在flume / conf /下的配置文件中。尽管只有源/通道/*敏*感*词*，但采集更灵活。根据处理器中的选项选择Nifi 采集的配置。

　　最后，根据比较总结一下这6种中间件的适用场景：

　　flume：适用于复杂文件采集； sqoop：适合将RMDB传输到大数据平台的其他中间件，例如hdfs / hive / hbase； datax：与sqoop非常相似，但在各个方面都比sqoop强。有一种趋势是替换鱿鱼。渠道：适用于mymql增量数据的实时同步，可以支持格式和输出多样化； maxwell：适用于将mysql增量数据快速实时同步到kafka； Nifi：适合简单的文件流操作，是的简单的视觉界面，学习成本低；水壶：适合复杂的ETL操作，并具有可视界面，易于操作。