Flume采集日志数据

一、为什么选用Flume？

Flume vs Logstash vs Filebeat

当时选择数据采集工具时，我们主要参考了市面上热度比较高的Flume和Logstash还有Filebeat，据目前所知，美团和苏宁用的是Flume。

Flume当初的设计初衷就是将数据传送到HDFS中，它更加地注重数据的传输，而Logstash是ELK组件（Elastic Search、Logstash、Kibana）中的一员，侧重于数据预处理。

Flume比Logstash多了一个可靠性策略，在Flume中传输的数据会持久化在channel中，除非已确认数据被传输到了下一位置，即sink端，否则不会删除，这个过程是通过事务来控制的，这样的设计使得可靠性非常好。

Filebeat是一个轻量型日志采集工具，虽能更稳健少宕机，但它设计目的是写Logstash和ES，主要处理轻量级数据。

二、Flume缺点？

可能数据重复。

例如数据已经成功由Sink发出，但是没有接收到响应，Sink会再次发送数据，此时可能会导致数据的重复。

解决：我们可以在搭建数仓的dwd层做去重。

三、Flume各组件的选型

Sources：
① Taildir Source：断点续传、多目录
② Exec Source：监测文件中新增内容
③ Spooldir Source：监测目录下新增的文件
④ Avro Source 用于Flume的级联场景

Channels：
为什么要channel?
Channel是位于Source和Sink之间的缓冲区。因此，Channel允许Source和Sink运作在不同的速率上。Channel是线程安全的，可以同时处理几个Source的写入操作和几个Sink的读取操作。

① File Channel：将所有事件写到磁盘，数据存储在磁盘中，宕机数据可以保存。传输速率慢，适合对数据传输可靠性要求高的场景，例如：金融行业
② Memory Channel：是内存中的队列，数据存储在内存中，容易受到容量限制，无法持久化，宕机数据容易丢失。传输效率快，适合对数据传输可靠性要求不高的场景，例如：日志数据
③ Kafka Channel：减少Flume的Sink阶段，提高了传输效率

Flume的通道选择器Channel Selectors
复制和多路选择

默认是Replicating Channel Selector，将从Source过来的events发往所有Channel
Multiplexing则可以选择发往哪些Channel

在实际的开发中，一台服务器产生的日志类型可能有很多种，不同类型的日志可能需要发送到不同的分析系统。此时会用到Flume拓扑结构中的Multiplexing结构，Multiplexing的原理是，根据event中Header（kv键值对类型）的某个key的值，将不同的event发送到不同的Channel中，所以我们需要自定义一个Interceptor，为不同类型的event的Header中的key对应value值赋予不同的值。

在该案例中，我们以端口数据模拟日志，以数字（单个）和字母（单个）模拟不同类型的日志，我们需要自定义interceptor区分数字和字母，将其分别发往不同的分析系统（Channel）。

@Override
    public void initialize() {
   
   

    }
    
@Override
public Event int