flume数据采集的压力测试

数据采集

1. 数据量分析

   日活300W，平均每人100次点击事件，也就是300G数据，再平均到12小时 25G/h=7M/s

   而流量峰值X10。差不多在70M/s

   为了保证我们的Flume稳定服务，即使有Web服务器的负载前提,也要保证每台机器能抗住峰值的数据量。

   为了将日志用于实时分析，我们不能让日志文件落地，所以得采用HttpSource这样的能直接获取接口数据的Source。

   为了防止异常情况服务宕机，数据丢失，选用FileChannel，这样即使宕机，重启也能恢复大量数据。

2. 原装flume压力测试

   正常的FileChannel，受限与其内部线程的安全机制，传输速度大概在10-20M/s

   即使将filechannel的可用容量加大，每秒50M/s每秒的差距也能很快让channel负载，这时候因为channel满了无法接受数据，导致source端的数据丢失也是不能接受的

3. 解决思路

   一个fileChannel 扛不住，多加几个，选择合适的selector使得所有的event能均匀的分不到不同的FileChannel上。内置的有复制选择器(存复制)和复分选择器(根据header中的某个字段分流)。看上去复分选择器已经能升任我们的工作。但是存在另外的问题。如果我们要根据某个条件分流注定各个FileChannel的压力是不均匀的。因此我们不得不维护多个不同的Channel。维护成本提升了。

   • 自定义HashSelector

     public class HashSelector extends AbstractChannelSelector {
         @Override
         public List<Channel> getRequiredChannels(Event event) {
             int hashIndex = (int) (System.currentTimeMillis()%getAllChannels().size());
             Channel channel=getAllChannels().get(hashIndex);
             return Lists.newArrayList(channel);
         }
     
         @Override
         public List<Channel> getOptionalChannels(Event event) {
             return null;
         }
     
         @Override
         public void configure(Context context) {
     
         }
     }
     

     [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-S7Gmc902-1571563138644)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\1571404274442.png)]

     数据能均匀分布到不同的channel上之后,任务其实已经完成了。

     后期我们为了维护方便，自定义一个FileChannelGroups,其内封装多个FileChannel，多个channel间通过Hash分配工作，这样之前的Hash Selector就省略了。同时kafka sink也配置多个，因为单个kafka sink的速度在50M/s