Flume架构与实践

Flume架构与实践

Flume是一款在线数据采集的系统,典型的应用场景是作为数据的总线,在线的进行日志的采集、分发与存储,它是一个微内核,可扩展的架构设计,典型的部署图如下:

Flume与Kafka的比较

1、Kafka是pull based,Flume是Push Based, 如果你有很多下游的Data Consumer消费同一份数据,需要做限流、降级等个性化的实现,个人建议用Kafka。

2、Kafka有Replication,Flume配置起来很复杂,如果要求很高的容错性(Data High Availability),个人建议用Kafka。

3、若果需要更多的一站式Sink实现,例如HDFS,HBase Sink 等,个人建议用Flume。

4、个人推荐的架构Agent—Kafka—flume。

Flume基本概念

Event

Event是flume端到端传输的基本单元,它由数据本身和一些头域信息构成,头域信息的开销对整个数据采集来说是透明的,由K-V构成的Map信息,主要用于上下信息的传递。

Client

它主要用于产生Events,并将它们发送到一个或多个Agents,常见的有Flume log4j Appender、LoadBalancingRpcClient、FailoverRpcClient,它不是部署图中的必须部分。

Source

它是数据源,从特定渠道接受events,将它存储到Channel中,常见Source有如下分类

Agent-to-Agent的Source

Avro Source、ThriftSource

自产生Event的Source

Exec Source、SpoolingDirectory Source

与知名系统对接的Source

Kafka Source、Syslog Sources

Channel

它缓存接收到的events直到它们被Sinks节点消费完成,不同的Channel提供不同持久化层级:

Memory Channel:易失,重启丢数据。

File Channel:以WAL文件为支持,保证数据的本地持久化,重启数据不丢失。

JDBC Channel:以特定的数据库为备份。

所有的通道的存取操作都有“事务”机制的保证,对顺序性是一种弱保护的机制。可以同时对接任意个数的Sources、Sinks。它解耦了upstream与downstream的依赖关系,是整个Flow可靠性、可用性的关键所在。

Sink

它主要从特定的Channel中获取数据,将数据可靠的传输到下一个目的地,保证At least once的消费,一个Sink有且只有一个Channel;常见Sink有

Terminal sink

HDFS Sink、File RollSink、ElasticSearchSink、KafkaSink

Agent-to-Agent Sink

Avro Sink、ThriftSink

Agent

它是一个拥有Sources、Channels、Sinks、将events对象进行透明传输的容器进程。它是Flume数据流的基础组件,提供了生命周期管理、配置动态生效、数据流监控等基本功能。

Configuration

一个配置文件可以同时配置多个Agent,只有指定agent名称相关的配置才会被加载,配置错误的组件在加载的时候输出一个条告警日志,然后会被忽略,Agent支持配置的动态加载。

# Name the components on this agent

a3.sources = r3

a3.sinks = k3

a3.channels = c3

#Describe/configure the source

a3.sources.r3.type= avro

a3.sources.r3.bind=0.0.0.0

a3.sources.r3.port=28080

# Describe the sink

a3.sinks.k3.type =hdfs

a3.sinks.k3.hdfs.path= hdfs://10.0.53.81:9000/%{savePath}/%Y-%m-%d

a3.sinks.k3.hdfs.callTimeout=300000

a3.sinks.k3.hdfs.filePrefix=log

a3.sinks.k3.hdfs.rollInterval=3600

a3.sinks.k3.hdfs.rollSize=1073741824

a3.sinks.k3.hdfs.hdfs.batchSize=4000

a3.sinks.k3.hdfs.threadsPoolSize=30

a3.sinks.k3.hdfs.rollTimerPoolSize=3

a3.sinks.k3.hdfs.rollCount=0

a3.sinks.k3.hdfs.fileType= DataStream

a3.sinks.k3.hdfs.writeFormat= Text

a3.sinks.k3.serializer=text

a3.sinks.k3.serializer.appendNewline=false

a3.sinks.k3.hdfs.minBlockReplicas=1

# Use a channel which buffers events in memory

a3.channels.c3.type=file

a3.channels.c3.checkpointDir=/data/flume/channel/filechannel_3/checkpointDir

a3.channels.c3.dataDirs=/data/flume/channel/filechanne1_3/dataDirs

a3.channels.c3.keep-alive= 10

a3.channels.c3.transactionCapacity=10000

a3.channels.c3.capacity=104857600

# Bind the source and sink to the channel

a3.sources.r3.channels= c3 c

a3.sinks.k3.channel= c3

Flume基本原理


总体介绍

1、客户端发送events到Agents。

2、Agent拥有Source, Interceptors, Channel Selectors, Channels, Sink Processors and Sinks等组件。Source接受Events,经过Interceptor(s)过滤,根据Channel Selector将它们放置到channel(s)中,Sink Processor选择一个Sink从指定的Channel获取Events发送到配置的下一跳节点。

3、Channel的存、取操作是通过“事务的方式”去保证了单节点的消息投递的可靠性;Channel持久化保证了端到端的可靠性。

Flume-Sources


Sources的基本功能

1、从外部的Client或者内部的Sink获取events。

2、将接收到的events存到配置的channel(s),保证操作的“事务性”。

3、数据分流到不同的目的地

Sources的可用性

1、channel侧put数据的事务保证

2、可靠外部客户端的的异常重试(Avro

sink、LoadBalancingRpcClient)

Flume-Channels

Channels的基本功能

1、作为sources/sinks间的Buffer,能有效抵挡下游消费者的短暂的不可用,下游消费者的消费速度的不匹配。

2、解耦了sources、sinks。

3、多个sources/sinks可以共享同一个channel。

Channels的事务


与DB的事务不是一个概念,它的目标就是保证消息的At Least Once消费,事务是Channel强相关的,它保证了Events一旦“committed”到一个channel,它只有在下游消费者消费并返回了committed.”才会从队列中移除,基本流程如下:

1、Source 1产生的Event, “put” and “committed”到Channel 1。

2、Sink 1从Channel 1中获取并发送到Source 2。

3、Source 2 “puts” and “commits”到Channel 2。

4、Source 2发送成功到Sink 1. Sink 1发送commits确认已“take“成功,将这个event从channel1中删除。

这样就保证了“一批数据的操作的事务性“

Memory Channel

events存储在堆中,存取速度非常快,但是系统Crash、或者进程退出时,存在events丢失。

File Channel

events持久化到本地文件系统中,存取速度相对较慢,但是可靠性高,基本流程如下:


1、events以指定大小存储在log files,持久化到磁盘中

2、指向event的指针(logID+offset)存放在内存队列中

3、queue当前的状态就是events的当前存储状态

4、queue会被周期性的同步到磁盘中- checkpoint

5、channel重启时checkpoint-mmap-ed

6、从上次checkpoint发生的put/take/commit/rollback通过日志回放恢复


Flume-Sinks

它主要从特定的Channel中获取数据,将数据可靠的传输到下一个目的地,保证At least once的消费

HDFS Sink


a3.sinks.k4.type =hdfs

a3.sinks.k4.hdfs.path= hdfs://10.0.53.81:9000/%{savePath}/%Y-%m-%d/%H

a3.sinks.k4.hdfs.callTimeout=300000

a3.sinks.k4.hdfs.filePrefix=log

a3.sinks.k4.hdfs.rollInterval=600

a3.sinks.k4.hdfs.rollSize=1073741824

a3.sinks.k4.hdfs.hdfs.batchSize=4000

a3.sinks.k4.hdfs.threadsPoolSize=30

a3.sinks.k4.hdfs.rollTimerPoolSize=3

a3.sinks.k4.hdfs.rollCount=0

a3.sinks.k4.hdfs.fileType= DataStream

a3.sinks.k4.hdfs.writeFormat= Text

a3.sinks.k4.serializer=text

a3.sinks.k4.serializer.appendNewline=false

a3.sinks.k4.hdfs.minBlockReplicas=1

Contextual Routing

通过Interceptors与Channel Selectors来达到Event的路由功能,例如Terminal Sinks可以直接使用头域信息进行目标Sink节点的选择

Interceptor

它主要用来对流入Source的Event对象进行修饰和过滤,当前内置的Interceptors支持添加时间戳、主机、静态标签等头域信息;支持用户自定义的Interceptor。

Channel Selector

它允许Source根据Event头域的标签信息,从所有的Channels中选出Event对应的Channel;目前内置的Channel Selectors有:

Replicating:将Event应用到所有对应Channel中。

Multiplexing:根据头域选择对应的Channel。

Flume可用性与可靠性


Flume可用性设计


Client可用性

LoadBalancingRpcClient、FailoverRpcClient,保证了Client侧的高可用性。

Channel可用性

Memory Channel、FileChannel、JDBC Channel的可用性递增,性能递减。

Sink Processor

它负责从指定的SinkGroup中调用一个Sink节点,由Sink Runner负责调度,类似做了一层代理;一个Sink节点只能存在于一个SinkProcessor中,如果没有配置任何SinkGroup,默认是在Default Sink Processor中。

目前内置Sink Process有 Load Balancing Sink Processor--RANDOM,ROUND_ROBIN 、Failover Sink Processor、Default Sink Processor

Flume可靠性设计


channel的事务

保证了Agent间数据交换的At least once消费 

内置的负载均衡和FailOve机制

channel的持久化

保证了Agent挂了之后的自动恢复,保证了消息的At least once消费

节点不可用

1、通过冗余的topologies来解决,Flume允许你将你数据流复制到冗余的topologies,这个对于应对磁盘损坏和单点失效有用,代价较大,topology会比较复杂。

2、如果承载channel的磁盘做了Raid,重新挂在,启动agent,也能很快的进行数据恢复,例如Kafka channel/JDBC Channel

3、允许部分数据的丢失。

4、概率较小,推荐在应用层进行回放的操作。

Flume的调优


选择正确的Channel

memory channel:低延时,高吞吐,可靠性弱。

file channel:延时相对高,吞吐相对小,可靠性较高。

disk-based channels10’s of MB/s

memory based channels100’s of MB/s

选择合适的capacity

根据你容忍的down机时间而定,capacity越大,恢复需要的时间越长,同时存在消费延时的问题。

选择合适的batch size

batch size越大吞吐量越高,异常重传的代价高,一般推荐100 or 1,000 or 10,000这个跟单个event的大小也有关

client与agent的比例配比

20:1 or 30:1的客户端agent比例比较适中

GC参数的选择

根据应用的具体情况进行调优

agent的监控

通过agent暴露的metrice服务,关注ChannelSize找到数据流中的瓶颈

http://10.0.52.28:34545/metrics

Flume应用

业界应用


我司应用


使用的是Client+Avro Source+ Replicating/ Multiplexing+TimeStampInterceptor+FileChannel/MemChannel+Failover sink Processr/Loadbalance SinkProcess+HdfsSink/ ElasticSink/FileSink/CustomSource

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 210,914评论 6 490
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 89,935评论 2 383
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 156,531评论 0 345
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,309评论 1 282
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,381评论 5 384
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,730评论 1 289
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,882评论 3 404
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,643评论 0 266
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,095评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,448评论 2 325
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,566评论 1 339
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,253评论 4 328
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,829评论 3 312
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,715评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,945评论 1 264
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,248评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,440评论 2 348

推荐阅读更多精彩内容

  • 介绍 概述 Apache Flume是为有效收集聚合和移动大量来自不同源到中心数据存储而设计的可分布,可靠的,可用...
    ximengchj阅读 3,516评论 0 13
  • 博客原文 翻译作品,水平有限,如有错误,烦请留言指正。原文请见 官网英文文档 引言 概述 Apache Flume...
    rabbitGYK阅读 11,452评论 13 34
  • 这里主要介绍几种常见的日志的source来源,包括监控文件型,监控文件内容增量,TCP和HTTP。 Spool类型...
    欢醉阅读 1,384评论 0 10
  • Flume的功能和架构特点 ** 功能 **flume 是一个分布式的,可靠的,可用的,可以非常有效率的对大数据的...
    心_的方向阅读 2,511评论 1 10
  • Flume的官网地址:http://flume.apache.org/FlumeUserGuide.html#ex...
    24格的世界阅读 901评论 0 1