Flume+Kafka整合案例实现

 

一、为什么要集成Flume和Kafka

我们很多人在在使用Flume和kafka时，都会问一句为什么要将Flume和Kafka集成？那首先就应该明白业务需求，一般使用Flume+Kafka架构都是希望完成实时流式的日志处理，后面再连接上Flink/Storm/Spark Streaming等流式实时处理技术，从而完成日志实时解析的目标。第一、如果Flume直接对接实时计算框架，当数据采集速度大于数据处理速度，很容易发生数据堆积或者数据丢失，而kafka可以当做一个消息缓存队列，从广义上理解，把它当做一个数据库，可以存放一段时间的数据。第二、Kafka属于中间件，一个明显的优势就是使各层解耦，使得出错时不会干扰其他组件。

因此数据从数据源到flume再到Kafka时，数据一方面可以同步到HDFS做离线计算，另一方面可以做实时计算，可实现数据多分发。

二、概念剖析Flume+Kafka

Flume 是一个分布式、可靠、和高可用的海量日志聚合的系统，支持在系统中定制各类数据发送方，通过监控整个文件目录或者某一个特定文件，用于收集数据；同时Flume也 提供数据写到各种数据接受方(可定制)的能力，用于转发数据。Flume 的易用性在于通过读取配置文件，可以自动收集日志文件，在大数据处理及各种复杂的情况下，flume 经常被用来作为数据处理的工具。

• Source：Flume 搜集日志的方式多种多样，比如可以检测文件夹的变化spool Source，可以监测端口信息 Netcat Source，可以监控某各文件新增的内容 Exec Source等等，通常使用检测文件夹变化的方式来实时收集信息，所以本例中我们也将使用Spool Source。
• Channel：提供了一层缓冲机制，来实现数据的事务性传输，最大限度保证数据的安全传输。常用的有MemoryChannel：所有的events 被保存在内存中，优点是高吞吐，缺点是容量有限并且Agent 死掉时会丢失内存中的数据；FileChannel：所有的Events 被保存在文件中，优点是容量较大且死掉时数据可恢复，缺点是速度较慢。因此为了保证Event 在数据流点对点传输中是可靠地，要注意Channel 的选择。目前为了提高速度，我们暂时采用MemoryChannel，之后的目标是实现一个自定义channel—doubleChannel，解决上述的两个痛点问题。
• Sink：将数据转发到目的地，或者继续将数据转发到另外一个source，实现接力传输，多层之间通过AVRO Sink来实现。本例中，我们的最终目标是实现日志实时处理ÿ