flume数据采集_离线数据采集-flume优化

数仓ODS层主要会有两个大的来源：

业务库

离线：这里经常会使用 Sqoop 来抽取，比如我们每天定时抽取一次。

实时：可以考虑用 Canal 监听 Mysql 的Binlog，实时接入即可。

埋点日志：

离线：线上系统会打入各种日志，这些日志一般以文件的形式保存，我们可以选择用 Flume 定时抽取，

实时：日志写入到卡夫卡，用 Spark Streaming 或者 Flink 来实时接入，当然，Kafka 也会是一个关键的角色。

1 分类型拦截

1)拦截器注意事项

项目中自定义了：ETL拦截器和区分类型拦截器。

采用两个拦截器的优缺点：优点，模块化开发和可移植性；缺点，性能会低一些

2)自定义拦截器步骤

a)实现 Interceptor

b)重写四个方法

• initialize 初始化
• public Event intercept(Event event) 处理单个Event
• public List intercept(List events) 处理多个Event，在这个方法中调用Event intercept(Event event)
• close 方法

c)静态内部类，实现Interceptor.Builder

flume selecter

@Overridepublic void initialize() {}@Overridepublic Event intercept(Event event) {   // 将body里的数据根据类型，写到header   // 1 获取body数据   byte[] body = event.getBody();   String log = new String(body, Charset.forName("UTF-8"));   // 2 获取header   Map headers = event.getHeaders();   // 3 判断   if (log.contains("start")) {      headers.put("topic", "topic_start");   } else {      headers.put("topic", "topic_event");   }   return event;}@Overridepublic List intercept(List events) {   ArrayList interceptors = new ArrayList<>();   for (Event event : events) {      Event intercept = intercept(event);      interceptors.add(intercept);   }   return interceptors;}@Overridepublic void close() {}public static class Builder implements Interceptor.Builder {   @Override   public Interceptor build() {      return new LogTypeInterceptor();   }   @Override   public void configure(Context context) {   }}

2 断点续传

1)Source

(1)Taildir Source相比Exec Source、Spooling Directory Source的优势

TailDir Source：断点续传、多目录。Flume1.6以前需要自己自定义Source记录每次读取文件位置，实现断点续传。

Exec Source可以实时搜集数据，但是在Flume不运行或者Shell命令出错的情况下，数据将会丢失。

Spooling Directory Source监控目录，不支持断点续传。

(2)batchSize大小如何设置？

答：Event 1K左右时，500-1000合适(默认为100)

2)Channel

采用Kafka Channel，省去了Sink，提高了效率。

3 flume事务

1)Flume组成，Put事务，Take事务

Taildir Source：断点续传、多目录。Flume1.6以前需要自己自定义Source记录每次读取文件位置，实现断点续传。

File Channel：数据存储在磁盘，宕机数据可以保存。但是传输速率慢。适合对数据传输可靠性要求高的场景，比如，金融行业。

Memory Channel：数据存储在内存中，宕机数据丢失。传输速率快。适合对数据传输可靠性要求不高的场景，比如，普通的日志数据。

Kafka Channel：减少了Flume的Sink阶段，提高了传输效率。

Source到Channel是Put事务

Channel到Sink是Take事务

4 flume sink小文件

(1)HDFS存入大量小文件，有什么影响？

元数据层面：每个小文件都有一份元数据，其中包括文件路径，文件名，所有者，所属组，权限，创建时间等，这些信息都保存在Namenode内存中。所以小文件过多，会占用Namenode服务器大量内存，影响Namenode性能和使用寿命

计算层面：默认情况下MR会对每个小文件启用一个Map任务计算，非常影响计算性能。同时也影响磁盘寻址时间。

(2)HDFS小文件处理

官方默认的这三个参数配置写入HDFS后会产生小文件，hdfs.rollInterval、hdfs.rollSize、hdfs.rollCount

基于以上hdfs.rollInterval=3600，hdfs.rollSize=134217728，hdfs.rollCount =0，hdfs.roundValue=10，hdfs.roundUnit= second几个参数综合作用，效果如下：

(1)tmp文件在达到128M时会滚动生成正式文件

(2)tmp文件创建超10秒时会滚动生成正式文件

举例：在2018-01-01 05:23的时侯sink接收到数据，那会产生如下tmp文件：

/upload/20200101/log.201801010520.tmp

即使文件内容没有达到128M，也会在05:33时滚动生成正式文件