《Flume日志收集与MapReduce模式》一1.1 Flume 0.9

本节书摘来自华章出版社《Flume日志收集与MapReduce模式》一书中的第1章,第1.1节,作者 [美] 史蒂夫·霍夫曼(Steve Hoffman)斯里纳特·佩雷拉(Srinath Perera),更多章节内容可以访问云栖社区“华章计算机”公众号查看

1.1 Flume 0.9

Flume是在2011年被首次引入到Cloudera的CDH3分发中的。它由一套工作守护进程(代理)构成,这些守护进程是通过Zookeeper(一个配置与协调系统)根据一个或多个集中的Master配置而成的。在Master上,你可以在Web UI中查看代理状态,也可以以集中的方式在UI或是通过命令行Shell的方式取出配置(这两种方式都是通过Zookeeper与工作代理进行通信的)。
可以通过3种模式发送数据,分别叫作Best Effort(BE)、Disk Failover(DFO)以及End-to-End(E2E)。Masters用于E2E模式,而多个Master配置尚不成熟,因此通常情况下只会使用一个Master,这使得其成为了E2E数据流失败的主要原因。Best Effort见名知意,代理会尝试并发送数据,如果无法发送,那么数据就会被丢弃。这种模式非常适合于度量等场景,一些差异是可以被接受的,因为新数据很快就会到来。DiskFailover模式会将无法发送的数据存储到本地磁盘上(有时也存储到本地数据库中),并且会不断重试,直到可以将数据发送到数据流中的下一个接受者为止。这对于计划好(或计划外)的断电场景很方便,只要有足够的本地磁盘能够缓存负载即可。
2011年6月,Cloudera将Flume项目的控制权交给了Apache基金会。2012年,Flume项目就从孵化状态变成了顶级项目。在孵化的这一年中,开发人员就已经开始基于Star Trek Themed标签对Flume进行重构,并创建了Flume-NG(Flume the Next Generation)。

    原文作者:MapReduce
    原文地址: https://yq.aliyun.com/articles/107424
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞