为什么用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 是一个很好的数据收集和传输工具，适合二次开发。后面一些实践配置继续给出。
