共计 1608 个字符,预计需要花费 5 分钟才能阅读完成。
这篇文章主要为大家展示了“Flume 整体架构是怎么样的”,内容简而易懂,条理清晰,希望能够帮助大家解决疑惑,下面让丸趣 TV 小编带领大家一起研究并学习一下“Flume 整体架构是怎么样的”这篇文章吧。
1、Flume 介绍
Flume 是 cloudera 公司开源的一款分布式、可靠地进行大量日志数据采集、聚合和并转移到存储中;通过事务机制提供了可靠的消息传输支持,自带负载均衡机制来支撑水平扩展;并且提供了一些默认组件供直接使用。
Flume 目前常见的应用场景:日志 — Flume— 实时计算(如 Kafka+Storm)、日志 — Flume— 离线计算(如 HDFS、HBase)、日志 — Flume— ElasticSearch。
2、整体架构
Flume 主要分为三个组件:Source、Channel、Sink;数据流如下图所示:
1、Source 负责日志流入,比如从文件、网络、Kafka 等数据源流入数据,数据流入的方式有两种轮训拉取和事件驱动;
2、Channel 负责数据聚合 / 暂存,比如暂存到内存、本地文件、数据库、Kafka 等,日志数据不会在管道停留很长时间,很快会被 Sink 消费掉;
3、Sink 负责数据转移到存储,比如从 Channel 拿到日志后直接存储到 HDFS、HBase、Kafka、ElasticSearch 等,然后再有如 Hadoop、Storm、ElasticSearch 之类的进行数据分析或查询。
一个 Agent 会同时存在这三个组件,Source 和 Sink 都是异步执行的,相互之间不会影响。
假设我们有采集并索引 Nginx 访问日志,我们可以按照如下方式部署:
1、Source 采集的日志会传入 ChannelProcessor 组件,其首先通过 Interceptor 进行日志过滤,如果接触过 Servlet 的话这个概念是类似的,可以参考《Servlet3.1 规范翻译——过滤器 》;过滤器可以过滤掉日志,也可以修改日志内容;
2、过滤完成后接下来会交给 ChannelSelector 进行处理,默认提供了两种选择器:复制或多路复用选择器;复制即把一个日志复制到多个 Channel;而多路复用会根据配置的选择器条件,把符合条件的路由到相应的 Channel;在写多个 Channel 时可能存在存在失败的情况,对于失败的处理有两种:稍后重试或者忽略。重试一般采用指数级时间进行重试。
我们之前说过 Source 生产日志给 Channel、Sink 从 Channel 消费日志;它俩完全是异步的,因此 Sink 只需要监听自己关系的 Channel 变化即可。
到此我们可以对 Source 日志进行过滤 / 修改,把一个消息复制 / 路由到多个 Channel,对于 Sink 的话也应该存在写失败的情况,Flume 默认提供了如下策略:
Failover 策略是给多个 Sink 定义优先级,假设其中一个失败了,则路由到下一个优先级的 Sink;Sink 只要抛出一次异常就会被认为是失败了,则从存活 Sink 中移除,然后指数级时间等待重试,默认是等待 1s 开始重试,最大等待重试时间是 30s。
Flume 也提供了负载均衡策略:
1、首先是日志采集层,该层的 Agent 和应用部署在同一台机器上,负责采集如 Nginx 访问日志;然后通过 RPC 将日志流入到收集 / 聚合层;在这一层应该快速的采集到日志然后流入到收集 / 聚合层;
2、收集 / 聚合层进行日志的收集或聚合,并且可以进行容错处理,如故障转移或负载均衡,以提升可靠性;另外可以在该层开启文件 Channel,做数据缓冲区;
3、收集 / 聚合层对数据进行过滤或修改然后进行存储或处理;比如存储到 HDFS,或者流入 Kafka 然后通过 Storm 对数据进行实时处理。
以上是“Flume 整体架构是怎么样的”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注丸趣 TV 行业资讯频道!