为什么用Flume NG?#
对Flume NG不了解的朋友可以阅读一下这篇文章Flume NG入门详解 。开源的日志采集方案很多:
Scribe : 是Facebook开发的数据收集系统,项目不怎么维护。
Logstash: 是著名的开源数据栈ELK中的那个L。Logstash使用JRuby开发,运行时依赖JVM。 有比较强大的字段解析和过滤功能,但需要配置grok表达式,对实现数据传输有一定局限性,觉得不方便二次开发。
Flume NG: 是Cloudera主导开发,是新一代的数据采集传输工具,构架简单,使用灵活,是hadoop生态中的一部分,核心代码量不大,方便二次开发。
选择什么方案主要根据团队积累和习惯,能解决数据采集问题就好。本文主要讲解使用Flume NG搭建数据采集平台。
数据采集平台需求#
数据采集是大数据平台的重要一环,一边需要对接各种数据源,另一边要考虑离线数据对接和实时流式计算需求。总结一下主要需求点:
支持文件日志数据采集,保证文件记录不丢失
考虑应用升级成本,低成本实现日志数据对接
考虑流式计算需求,建立高速数据通路
能够有一定的扩展性,应对数据量的增长
具有一定容灾考虑,保证数据完整性
能够监控数据的采集,传输过程
Flume NG数据采集平台方案#
使用 Flume NG + Kafka,基本能够实现上述平台需求:
Flume 已经实现了各种source,基本能够保证灵活实现各种数据源的对接
Flume 可配置成将数据复制成两个数据流,一条直接写入HDFS,一条写入Kafka
通过Kafka对接流式计算和其它数据消费者,从而完成数据源和消费者的解耦
Flume支持loadbalance和failover,能够实现水平扩展,保证数据传输完整性
Flume 支持http方式获取内部监控指标数据
我们看看使用Flume NG构建数据采集平台的整体架构:
整个方案通过avro rpc做数据的汇集。为什么中间多了 data collection 这层?增加这层起到数据汇集的作用,datasource节点会很多,如果这些点都直接对接持久化层,那配置是比较多的,而且需要做调整时,涉及的机器和权限太多。多加一层可以使前后耦合降低,中间层机器数量不多,对数据写入,文件数量都有一定优化作用。而且需要增加新的数据持久只需修改几个节点配置。
实际使用中有几个点需要注意和优化:
channel的选择,考虑性能和稳定性,可以考虑使用SpillableMemoryChannel,兼顾memory channel和file channel的实现,代码量不大,可以验证使用。如果你保守一点就是用file channel。
file channel使用磁盘分区最好和应用数据输出分区分开,file channel,进度和数据目录也尽量分开。
配置loadbalance和failover时候,sink不能复用。
如果有能力尽量重新定制hdfs 写入过程,使用约定来减少通用代码逻辑。现有的hdfs sink,考虑到通用性使用了正则等,没有考虑你的数据特点,有一定优化的空间。
增加各个环节 channel,source,sink 的监控,了解整体数据流向和压力,适时考虑扩容等问题。
最好自己能够开发flume ng source 和sink,这样可以根据自己业务数据的特点,做适当的优化。
总结#
Flume NG 是一个很好的数据收集和传输工具,适合二次开发。后面一些实践配置继续给出。
转载于:https://blog.51cto.com/shuiniu/1890836