Flume source关注四种类型的数据源

本文针对的是flume V1.4, 介绍source, channel, sink这三个串联的功能组件
通常在实际系统中, 会把source端的Flume称为agent. 采集数据有两种方式:

  • push sources
    外部系统主动将数据推送到Flume, 如RPC, syslog, post
  • poll sources
    采用轮询的方式去获取数据.

    通过配置, 可以让应用程序直接连接已有的source(除了上边提到的, 还有Avro在Flume间的通讯, DB-需要check是否有现成模块).
    也可以继承Source, 自定义数据接入.

文本文件是常见的log接入源

它是poll方式的

1 ExecSource

如使用类似tail -f, 在flume未运行的时候会丢失数据, 而且需指定文件名.

2 SpoolSource

监测某个目录的新增文件, 这样就支持了分割的文件. 控制新增文件的频度, 可以实现为弱实时. 如log4j有TimeRolling插件. 值得注意的是:

  • spool目录中的文件不应该再写入
  • 不能再包含子目录
  • 处理完一个文件, 会修改其后缀(可配置)
  • 应该保证文件是一次性放入spool目录(如在同一磁盘使用mv, 不能是cp)
  • 在传送某个文件期间重启Flume, 文件会再次传递

    Channel

    Channel的实现方式有:
  • MemoryChannel 速度快但是无法保证数据的完整性
  • FileChannel 保证数据的完整和一致性. 这篇文章介绍了Flume-ng FileChannel原理解析
    其它还有JDBC Channel等

    Sink

    对应agent, sink端的Flume通常被称为collector. 通过配置, 可以向文件系统, 数据库, hdfs存数据.
    对数据进行正则匹配, 可以写到不同的位置, 这里的例子是Flume 正则方式收集nginx日志到Hbase hadoop
    和Source类似, 实现Sink的子类, 可将数据写往特定目标

    可靠性

    Flume传输的数据的基本单位是event, 如果文本文件的一行记录, event是事务的基本单位: 当event到达dest时, 才能从channel中删除.
    Flume同时支持memory/file两种方式保存channel, 作为备份. memory方式在进程退出后就没法恢复了(我不理解memory方式的作用是什么)
    Flume提供3种数据可靠性选项: End-to-end, Store on failure, Best effort. 其中End-to-end使用磁盘日志和接受端Ack的方式, 保证Flume接收到的数据会最终到达目的; Store on failure在目的不可用的时候, 数据会保持在本地硬盘. 和End-to-end不同的是, 如果是进程出现问题, Store on failure可能会丢失部分数据; Best effort不做任何QoS保证.

    自定义与扩展

    除了可以对source和sink自定义, 还能通过SinkDecorator, 对数据进行预处理; 配置管理多个结点可以用zookeeper.

    遇到的BUG

    1 在spooldir中放一个空文件: 序列化出错
    2 spooldir中同时存放两个空文件: readEvents exception
    3 先后放入两个同名文件. 可通过删除来work around