数据采集
-
数据量分析
日活300W,平均每人100次点击事件,也就是300G数据,再平均到12小时 25G/h=7M/s
而流量峰值X10。差不多在70M/s
为了保证我们的Flume稳定服务,即使有Web服务器的负载前提,也要保证每台机器能抗住峰值的数据量。
为了将日志用于实时分析,我们不能让日志文件落地,所以得采用HttpSource这样的能直接获取接口数据的Source。
为了防止异常情况服务宕机,数据丢失,选用FileChannel,这样即使宕机,重启也能恢复大量数据。
-
原装flume压力测试
正常的FileChannel,受限与其内部线程的安全机制,传输速度大概在10-20M/s
即使将filechannel的可用容量加大,每秒50M/s每秒的差距也能很快让channel负载,这时候因为channel满了无法接受数据,导致source端的数据丢失也是不能接受的
-
解决思路
一个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
-