基于Flume的美团日志收集系统(二)改进和优化

问题导读：

1.Flume的存在些什么问题？

2.基于开源的Flume美团增长了哪些功能？

3.Flume系统如何调优？

在《 基于Flume的美团日志收集系统(一)架构和设计》中，咱们详述了基于Flume的美团日志收集系统的架构设计，以及为何作这样的设计。在本节中，咱们将会讲述在实际部署和使用过程当中遇到的问题，对Flume的功能改进和对系统作的优化。

1 Flume的问题总结

在Flume的使用过程当中，遇到的主要问题以下：

a. Channel“水土不服”：使用固定大小的MemoryChannel在日志高峰时常报队列大小不够的异常；使用FileChannel又致使IO繁忙的问题；

b. HdfsSink的性能问题：使用HdfsSink向Hdfs写日志，在高峰时间速度较慢；

c. 系统的管理问题：配置升级，模块重启等；

2 Flume的功能改进和优化点

从上面的问题中能够看到，有一些需求是原生Flume没法知足的，所以，基于开源的Flume咱们增长了许多功能，修改了一些Bug，而且进行一些调优。下面将对一些主要的方面作一些说明。

2.1 增长Zabbix monitor服务

一方面，Flume自己提供了http, ganglia的监控服务，而咱们目前主要使用zabbix作监控。所以，咱们为Flume添加了zabbix监控模块，和sa的监控服务无缝融合。

另外一方面，净化Flume的metrics。只将咱们须要的metrics发送给zabbix，避免 zabbix server形成压力。目前咱们最为关心的是Flume可否及时把应用端发送过来的日志写到Hdfs上， 对应关注的metrics为：

• Source : 接收的event数和处理的event数
• Channel : Channel中拥堵的event数
• Sink : 已经处理的event数
  

2.2 为HdfsSink增长自动建立index功能

首先，咱们的HdfsSink写到hadoop的文件采用lzo压缩存储。 HdfsSink能够读取hadoop配置文件中提供的编码类列表，而后经过配置的方式获取使用何种压缩编码，咱们目前使用lzo压缩数据。采用lzo压缩而非bz2压缩，是基于如下测试数据：

event大小(Byte)	sink.batch-size	hdfs.batchSize	压缩格式	总数据大小(G)	耗时(s)	平均events/s	压缩后大小(G)
544	300	10000	bz2	9.1	2448	6833	1.36
544	300	10000	lzo	9.1	612	27333	3.49

其次，咱们的HdfsSink增长了建立lzo文件后自动建立index功能。Hadoop提供了对lzo建立索引，使得压缩文件是可切分的，这样 Hadoop Job能够并行处理数据文件。HdfsSink自己lzo压缩，但写完lzo文件并不会建索引，咱们在close文件以后添加了建索引功能。

1. /**
   
2.    * Rename bucketPath file from .tmp to permanent location.
   
3.    */
   
4.   private void renameBucket() throws IOException, InterruptedException {
   
5.       if(bucketPath.equals(targetPath)) {
   
6.               return;
   
7.         }
   
8. 
   
9.         final Path srcPath = new Path(bucketPath);
   
10.         final Path dstPath = new Path(targetPath);
    
11. 
    
12.         callWithTimeout(new CallRunner<Object>() {
    
13.               @Override
    
14.               public Object call() throws Exception {
    
15.                 if(fileSystem.exists(srcPath)) { // could block
    
16.                       LOG.info("Renaming " + srcPath + " to " + dstPath);
    
17.                      fileSystem.rename(srcPath, dstPath); // could block
    
18. 
    
19.                       //index the dstPath lzo file
    
20.                       if (codeC != null && ".lzo".equals(codeC.getDefaultExtension()) ) {
    
21.                               LzoIndexer lzoIndexer = new LzoIndexer(new Configuration());
    
22.                               lzoIndexer.index(dstPath);
    
23.                       }
    
24.                 }
    
25.                 return null;
    
26.               }
    
27.     });
    
28. }

复制代码

2.3 增长HdfsSink的开关

咱们在HdfsSink和DualChannel中增长开关，当开关打开的状况下，HdfsSink再也不往Hdfs上写数据，而且数据只写向DualChannel中的FileChannel。以此策略来防止Hdfs的正常停机维护。

2.4 增长DualChannel

Flume自己提供了MemoryChannel和FileChannel。MemoryChannel处理速度快，但缓存大小有限，且没有持久 化；FileChannel则恰好相反。咱们但愿利用二者的优点，在Sink处理速度够快，Channel没有缓存过多日志的时候，就使用 MemoryChannel，当Sink处理速度跟不上，又须要Channel可以缓存下应用端发送过来的日志时，就使用FileChannel，由此我 们开发了DualChannel，可以智能的在两个Channel之间切换。

其具体的逻辑以下：

1. /***
   
2. * putToMemChannel indicate put event to memChannel or fileChannel
   
3. * takeFromMemChannel indicate take event from memChannel or fileChannel
   
4. * */
   
5. private AtomicBoolean putToMemChannel = new AtomicBoolean(true);
   
6. private AtomicBoolean takeFromMemChannel = new AtomicBoolean(true);
   
7. 
   
8. void doPut(Event event) {
   
9.         if (switchon && putToMemChannel.get()) {
   
10.               //往memChannel中写数据
    
11.               memTransaction.put(event);
    
12. 
    
13.               if ( memChannel.isFull() || fileChannel.getQueueSize() > 100) {
    
14.                 putToMemChannel.set(false);
    
15.               }
    
16.         } else {
    
17.               //往fileChannel中写数据
    
18.               fileTransaction.put(event);
    
19.         }
    
20.   }
    
21. 
    
22. Event doTake() {
    
23.     Event event = null;
    
24.     if ( takeFromMemChannel.get() ) {
    
25.         //从memChannel中取数据
    
26.         event = memTransaction.take();
    
27.         if (event == null) {
    
28.             takeFromMemChannel.set(false);
    
29.         } 
    
30.     } else {
    
31.         //从fileChannel中取数据
    
32.         event = fileTransaction.take();
    
33.         if (event == null) {
    
34.             takeFromMemChannel.set(true);
    
35. 
    
36.             putToMemChannel.set(true);
    
37.         } 
    
38.     }
    
39.     return event;
    
40. }

复制代码

2.5 增长NullChannel

Flume提供了NullSink，能够把不须要的日志经过NullSink直接丢弃，不进行存储。然而，Source须要先将events存放到 Channel中，NullSink再将events取出扔掉。为了提高性能，咱们把这一步移到了Channel里面作，因此开发了 NullChannel。

2.6 增长KafkaSink

为支持向Storm提供实时数据流，咱们增长了KafkaSink用来向Kafka写实时数据流。其基本的逻辑以下：

1. public class KafkaSink extends AbstractSink implements Configurable {
   
2.         private String zkConnect;
   
3.         private Integer zkTimeout;
   
4.         private Integer batchSize;
   
5.         private Integer queueSize;
   
6.         private String serializerClass;
   
7.         private String producerType;
   
8.         private String topicPrefix;
   
9. 
   
10.         private Producer<String, String> producer;
    
11. 
    
12.         public void configure(Context context) {
    
13.             //读取配置，并检查配置
    
14.         }
    
15. 
    
16.         @Override
    
17.         public synchronized void start() {
    
18.             //初始化producer
    
19.         }
    
20. 
    
21.         @Override
    
22.         public synchronized void stop() {
    
23.             //关闭producer
    
24.         }
    
25. 
    
26.         @Override
    
27.         public Status process() throws EventDeliveryException {
    
28. 
    
29.             Status status = Status.READY;
    
30. 
    
31.             Channel channel = getChannel();
    
32.             Transaction tx = channel.getTransaction();
    
33.             try {
    
34.                     tx.begin();
    
35. 
    
36.                     //将日志按category分队列存放
    
37.                     Map<String, List<String>> topic2EventList = new HashMap<String, List<String>>();
    
38. 
    
39.                     //从channel中取batchSize大小的日志，从header中获取category，生成topic，并存放于上述的Map中；
    
40. 
    
41.                     //将Map中的数据经过producer发送给kafka 
    
42. 
    
43.                    tx.commit();
    
44.             } catch (Exception e) {
    
45.                     tx.rollback();
    
46.                     throw new EventDeliveryException(e);
    
47.             } finally {
    
48.                 tx.close();
    
49.             }
    
50.             return status;
    
51.         }
    
52. }

复制代码

2.7 修复和scribe的兼容问题

Scribed在经过ScribeSource发送数据包给Flume时，大于4096字节的包，会先发送一个Dummy包检查服务器的反应，而 Flume的ScribeSource对于logentry.size()=0的包返回TRY_LATER，此时Scribed就认为出错，断开链接。这 样循环反复尝试，没法真正发送数据。如今在ScribeSource的Thrift接口中，对size为0的状况返回OK，保证后续正常发送数据。

3. Flume系统调优经验总结3.1 基础参数调优经验

• HdfsSink中默认的serializer会每写一行在行尾添加一个换行符，咱们日志自己带有换行符，这样会致使每条日志后面多一个空行，修改配置不要自动添加换行符；
  

1. lc.sinks.sink_hdfs.serializer.appendNewline = false

复制代码

• 调大MemoryChannel的capacity，尽可能利用MemoryChannel快速的处理能力；
  

• 调大HdfsSink的batchSize，增长吞吐量，减小hdfs的flush次数；
• 适当调大HdfsSink的callTimeout，避免没必要要的超时错误；
  
  

3.2 HdfsSink获取Filename的优化

HdfsSink的path参数指明了日志被写到Hdfs的位置，该参数中能够引用格式化的参数，将日志写到一个动态的目录中。这方便了日志的管理。例如咱们能够将日志写到category分类的目录，而且按天和按小时存放：

1. lc.sinks.sink_hdfs.hdfs.path = /user/hive/work/orglog.db/%{category}/dt=%Y%m%d/hour=%H

复制代码

HdfsS ink中处理每条event时，都要根据配置获取此event应该写入的Hdfs path和filename，默认的获取方法是经过正则表达式替换配置中的变量，获取真实的path和filename。由于此过程是每条event都要 作的操做，耗时很长。经过咱们的测试，20万条日志，这个操做要耗时6-8s左右。

因为咱们目前的path和filename有固定的模式，能够经过字符串拼接得到。然后者比正则匹配快几十倍。拼接定符串的方式，20万条日志的操做只须要几百毫秒。

3.3 HdfsSink的b/m/s优化

在咱们初始的设计中，全部的日志都经过一个Channel和一个HdfsSink写到Hdfs上。咱们来看一看这样作有什么问题。

首先，咱们来看一下HdfsSink在发送数据的逻辑：

1. //从Channel中取batchSize大小的events
   
2. for (txnEventCount = 0; txnEventCount < batchSize; txnEventCount++) {
   
3.     //对每条日志根据category append到相应的bucketWriter上；
   
4.     bucketWriter.append(event);
   
5. ｝
   
6. 
   
7. for (BucketWriter bucketWriter : writers) {
   
8.     //而后对每个bucketWriter调用相应的flush方法将数据flush到Hdfs上
   
9.     bucketWriter.flush();
   
10. ｝

复制代码

假设咱们的系统中有100个category，batchSize大小设置为20万。则每20万条数据，就须要对100个文件进行append或者flush操做。

其次，对于咱们的日志来讲，基本符合80/20原则。即20%的category产生了系统80%的日志量。这样对大部分日志来讲，每20万条可能只包含几条日志，也须要往Hdfs上flush一次。

上述的状况会致使HdfsSink写Hdfs的效率极差。下图是单Channel的状况下每小时的发送量和写hdfs的时间趋势图。

 

鉴于这种实际应用场景，咱们把日志进行了大小归类，分为big, middle和small三类，这样能够有效的避免小日志跟着大日志一块儿频繁的flush，提高效果明显。下图是分队列后big队列的每小时的发送量和写hdfs的时间趋势图。