打怪升级之小白的大数据之旅(七十二)<flume进阶>(代码片段)

GaryLea GaryLea     2023-03-09     542

关键词:

打怪升级之小白的大数据之旅(七十二)

Flume进阶

上次回顾

上一章对Flume的基础知识点进行了分享,有了上一章的铺垫,本章就深入学习一下Flume的进阶知识点

Flume的使用很简单,主要就是写配置文件,至于具体怎么配置,大家要善用官网。我再次介绍一下Fluem说明文档http://flume.apache.org/FlumeUserGuide.html

官网文档是真的细,我的案例也是参考的官方示例

Flume事务

Flume既然是针对海量数据传输的框架,它最主要的工作自然就是数据的传输,为了确保数据的完整性,Flume内部会有一个事务机制,用于保证数据再传输过程中的完整、正确性,注意啦,事务都是存储在Channel中的

上图就是Flume包含事务的架构图,图中我们可以看到,Flume由两部分组成

  • Source端的事务 Put事务
    • doput: 将数据写入到临时缓冲区putList中
    • doCommit: 将putList中的数据提交到channel中
    • doRollback: doCommit提交失败,就会调用此方法,将提交的数据放回到putList中,并再次调用doCommit提交
    • 如果在Put数据时Flume挂掉了,Put事务就会清空putList中的数据,这样可以确保channel中的数据不重复,不丢失,当Flume重新启动就会要求输入端重新发送数据
  • Sink端的事务 Take事务
    • channel我前面说了,它就像一艘船,只是存储数据的缓冲区,所以写出数据就是Take,Take事务和Put事务方法类似,只不过它是拉取数据
    • doTake:将数据拉取到临时缓冲区takeList中
    • doCommit:将takeList中的数据写入到HDFS中,如果成功,则清空takeList中的数据
    • doRollback: 如果doCommit失败,为了防止数据丢失,如Flume宕机等情况,它会将数据放回到channel中

Flume Agent内部原理

下面我将Flume的内部原理进行分享

前面已经学习了Flume的基础架构:三大组件source channel sink,这是最基本的flume,在实际开发中,一个flume中会有多个channel、sink

source接收到数据后内部的具体工作:

  • source接收到数据后,会生成一个Event,然后放到channelProcessor中,
  • channelProcessor会做两件事情,第一件,将事件放到拦截器链Interceptor中进行处理,比如定义Event的Header,处理之后,channelProcessor就会将事件放到Channel选择器中
  • Channel选择器内部有两种选择器,一种是默认的复制ReplicatingChannelSelector,一种是多路复用MultiplexingChannelSelector(具体的等下会讲)
  • Channel选择器选择好之后,channelProcessor会就根据Channel选择器的结果将事件写入到对应的Channel中

Sink内部的工作

  • Sink拉取数据时会放到SinkProcessor,SinkProcessor默认是直接将数据拉取到Sink中,这个就是DefaultSinkProcessor
  • SinkProcessor还有另外两种方式,一种是负载均衡LoadBalancingSinkProcessor,一种是故障转移FailoverSinkProcessor(后面会讲)

Flume拓扑结构

下面就为大家详细介绍一下Channel选择器和SinkProcessor中的故障转移与负载均衡

简单串联

首先介绍一下Flume的简单串联

上图就是简单串联,就像上一章我举的运河运输货物的栗子,两个Flume就像两艘船,要想进行串联,此时就需要一个串联的介质,它就是Avro,Avro有avroSource和avroSink,通过它们就可以实现两个Flume中间的连接

复制和多路复用

Flume支持将事件流向一个或者多个目的地。这种模式可以将相同数据复制到多个channel中,或者将不同数据分发到不同的channel中,sink可以选择传送到不同的目的地

复制的意思就是说,将Event发送到所有的Channel中,每个Channel中包含的Event都是一样的

多路复用就说,一个Event可以选择性的发送,为了实现这个功能,通常情况下是配合拦截器链Interceptor进行的,通过Interceptor设置的Event Header可以很方便地选择需要将Event发送到想要发送的Channel中

复制和多路复用案例(单数据源多出口)

因为多路复用案例需要配合拦截器,所以我先写一个复制的案例

案例需求:

  • 监控Hive实时更新的日志文件,并将更新的文件内容分别保存在HDFS和本地中

需求分析:

  • 既然是监控日志文件并且分别输出,那么我们使用三个Flume就可以很轻松解决这个需求
  • Flume-1监控日志文件的变动,并将变动的内容分别传递给Flume-2和Flume-3
  • Flume-2负责存储到HDFS
  • Flume-3负责输出到本地文件夹中

    案例实现

Flume1:配置1个接收日志文件的source和两个channel、两个sink,分别输送给flume-flume-hdfs和flume-flume-dir

# Flume1
vim /opt/module/flume/job/group1/flume-file-flume.conf
# Name the components on this agent
a1.sources = r1
a1.sinks = k1 k2
a1.channels = c1 c2
# 将数据流复制给所有channel
a1.sources.r1.selector.type = replicating

# Describe/configure the source
a1.sources.r1.type = exec
a1.sources.r1.command = tail -F /opt/module/hive/logs/hive.log
a1.sources.r1.shell = /bin/bash -c

# Describe the sink
# sink端的avro是一个数据发送者
a1.sinks.k1.type = avro
a1.sinks.k1.hostname = hadoop102 
a1.sinks.k1.port = 4141

a1.sinks.k2.type = avro
a1.sinks.k2.hostname = hadoop102
a1.sinks.k2.port = 4142

# Describe the channel
a1.channels.c1.type = memory
a1.channels.c1.capacity = 1000
a1.channels.c1.transactionCapacity = 100

a1.channels.c2.type = memory
a1.channels.c2.capacity = 1000
a1.channels.c2.transactionCapacity = 100

# Bind the source and sink to the channel
a1.sources.r1.channels = c1 c2
a1.sinks.k1.channel = c1
a1.sinks.k2.channel = c2

Flume2:将Flume1输出作为Flume2的Source,接着输出数据到HDFS中

# Flume2
vim /opt/module/flume/job/group1/flume-flume-hdfs.conf

# Name the components on this agent
a2.sources = r1
a2.sinks = k1
a2.channels = c1

# Describe/configure the source
# source端的avro是一个数据接收服务
a2.sources.r1.type = avro
a2.sources.r1.bind = hadoop102
a2.sources.r1.port = 4141

# Describe the sink
a2.sinks.k1.type = hdfs
a2.sinks.k1.hdfs.path = hdfs://hadoop102:9820/flume1/%Y%m%d/%H
#上传文件的前缀
a2.sinks.k1.hdfs.filePrefix = flume1-
#是否按照时间滚动文件夹
a2.sinks.k1.hdfs.round = true
#多少时间单位创建一个新的文件夹
a2.sinks.k1.hdfs.roundValue = 1
#重新定义时间单位
a2.sinks.k1.hdfs.roundUnit = hour
#是否使用本地时间戳
a2.sinks.k1.hdfs.useLocalTimeStamp = true
#积攒多少个Event才flush到HDFS一次
a2.sinks.k1.hdfs.batchSize = 100
#设置文件类型,可支持压缩
a2.sinks.k1.hdfs.fileType = DataStream
#多久生成一个新的文件
a2.sinks.k1.hdfs.rollInterval = 600
#设置每个文件的滚动大小大概是128M
a2.sinks.k1.hdfs.rollSize = 134217700
#文件的滚动与Event数量无关
a2.sinks.k1.hdfs.rollCount = 0

# Describe the channel
a2.channels.c1.type = memory
a2.channels.c1.capacity = 1000
a2.channels.c1.transactionCapacity = 100

# Bind the source and sink to the channel
a2.sources.r1.channels = c1
a2.sinks.k1.channel = c1

Flume3:将Flume1输出作为Flume3的Source,接着输出数据到本地文件夹中

# Name the components on this agent
a3.sources = r1
a3.sinks = k1
a3.channels = c2

# Describe/configure the source
a3.sources.r1.type = avro
a3.sources.r1.bind = hadoop102
a3.sources.r1.port = 4142

# Describe the sink
a3.sinks.k1.type = file_roll
a3.sinks.k1.sink.directory = /opt/module/flume/job/datas/flume1

# Describe the channel
a3.channels.c2.type = memory
a3.channels.c2.capacity = 1000
a3.channels.c2.transactionCapacity = 100

# Bind the source and sink to the channel
a3.sources.r1.channels = c2
a3.sinks.k1.channel = c2

运行flume:

# flume-flume-dir
flume-ng agent -c conf/ -f /opt/module/flume/job/group1/flume-flume-dir.conf -n a3

# flume-flume-hdfs
flume-ng agent -c conf/ -f /opt/module/flume/job/group1/flume-flume-hdfs.conf -n a2

# flume-file-flume
flume-ng agent -c conf/ -f /opt/module/flume/job/group1/flume-file-flume.conf -n a1

运行结果:

  • HDFS:

    本地文件夹中:

负载均衡和故障转移

Flume支持使用将多个sink逻辑上分到一个sink组,sink组配合不同的SinkProcessor可以实现负载均衡和错误恢复的功能

负载均衡意思就是,当Sink中的数据需要发送到下一个Flume时,为了避免数据倾斜导致某个Flume承载较大而其他Flume比较空闲时,可以尽量均衡的发送到Flume中

故障转移是说,Sink发送到Flume中时,某个Flume挂掉了,可以将该挂掉的Flume中的数据发送到其他Flume中

负载均衡和故障转移案例

案例需求:

  • 使用Flume1监控一个端口,其sink组中的sink分别对接Flume2和Flume3,采用FailoverSinkProcessor,实现故障转移的功能

需求分析:

  • Flume1 使用netcat Source来监控文件.并将文件内容分别发给Flume2和Flume3
  • Flume2和Flume3都使用loggerSink进行控制台输出,看看效果
  • 当其中一个Flume挂掉,继续查看Flume输出结果

    案例实现:

Flume1: 利用netcat 监控指定端口的数据,并开启故障转移功能,然后将结果发送给Flume2和Flume3

vim /opt/module/flume/job/group2/flume-netcat-flume.conf

# Name the components on this agent
a1.sources = r1
a1.channels = c1
a1.sinkgroups = g1
a1.sinks = k1 k2

# Describe/configure the source
a1.sources.r1.type = netcat
a1.sources.r1.bind = localhost
a1.sources.r1.port = 44444

a1.sinkgroups.g1.processor.type = failover
a1.sinkgroups.g1.processor.priority.k1 = 5
a1.sinkgroups.g1.processor.priority.k2 = 10
a1.sinkgroups.g1.processor.maxpenalty = 10000

# Describe the sink
a1.sinks.k1.type = avro
a1.sinks.k1.hostname = hadoop102
a1.sinks.k1.port = 4141

a1.sinks.k2.type = avro
a1.sinks.k2.hostname = hadoop102
a1.sinks.k2.port = 4142

# Describe the channel
a1.channels.c1.type = memory
a1.channels.c1.capacity = 1000
a1.channels.c1.transactionCapacity = 100

# Bind the source and sink to the channel
a1.sources.r1.channels = c1
a1.sinkgroups.g1.sinks = k1 k2
a1.sinks.k1.channel = c1
a1.sinks.k2.channel = c1

Flume2: Flume2获取Flume1数据 ,将结果输出到控制台

vim /opt/module/flume/job/group2/flume-flume-console1.conf 

# Name the components on this agent
a2.sources = r1
a2.sinks = k1
a2.channels = c1

# Describe/configure the source
a2.sources.r1.type = avro
a2.sources.r1.bind = hadoop102
a2.sources.r1.port = 4141

# Describe the sink
a2.sinks.k1.type = logger

# Describe the channel
a2.channels.c1.type = memory
a2.channels.c1.capacity = 1000
a2.channels.c1.transactionCapacity = 100

# Bind the source and sink to the channel
a2.sources.r1.channels = c1
a2.sinks.k1.channel = c1

Flume3: Flume3获取Flume1数据,将结果输出到控制台

vim /opt/module/flume/job/group2/flume-flume-console2.conf 

# Name the components on this agent
a3.sources = r1
a3.sinks = k1
a3.channels = c2

# Describe/configure the source
a3.sources.r1.type = avro
a3.sources.r1.bind = hadoop102
a3.sources.r1.port = 4142

# Describe the sink
a3.sinks.k1.type = logger

# Describe the channel
a3.channels.c2.type = memory
a3.channels.c2.capacity = 1000
a3.channels.c2.transactionCapacity = 100

# Bind the source and sink to the channel
a3.sources.r1.channels = c2
a3.sinks.k1.channel = c2

运行Flume

# Flume3
flume-ng agent -c conf/ -f flume-flume-console2.conf  -n a3
# Flume2
flume-ng agent -c conf/ -f flume-flume-console1.conf  -n a2
# Flume1
flume-ng agent -c conf/ -f flume-netcat-flume.conf  -n a1
# 再开启一个shell窗口,使用netcat 模拟数据源
nc localhost 44444
hello
world
hadoop

输出结果:

  • 只有Flume2的控制台输出了结果,Flume没有输出

    关闭Flume2再次向端口中发送数据,此时Flume1接收到了数据,这个就是故障转移,负载均衡的话,因为需要海量数据来支撑,我博客里无法具体实现,负载均衡的实现就和故障转移实现方式一样,只是需要改变一下参数

聚合

这种模式是我们最常见的,也非常实用,日常web应用通常分布在上百个服务器,大者甚至上千个、上万个服务器。产生的日志,处理起来也非常麻烦。用flume的这种组合方式能很好的解决这一问题,每台服务器部署一个flume采集日志,传送到一个集中收集日志的flume,再由此flume上传到hdfs、hive、hbase等,进行日志分析


聚合的思想很好理解,想想前面讲过的MR,MR也是这样。分合

聚合案例

案例需求:

  • hadoop102上的Flume-1监控文件/opt/module/group.log,
  • hadoop103上的Flume-2监控某一个端口的数据流
  • Flume-1与Flume-2将数据发送给hadoop104上的Flume-3,Flume-3将最终数据打印到控制台

需求分析:

  • Flume1 监控模拟的Log日志文件group.log,将数据发送给Flume3
  • Flume2监控指定端口的数据,将数据发送给Flume3
  • Flume3将数据汇总合并,然后打印到控制台中


案例实现:为了案例更加贴合实际场景,我就不在一个节点中了,我在集群中实现,首先分别在hadoop102,hadoop103,hadoop103节点中创建我们的案例文件夹

mkdir /opt/module/flume/job/group3

Flume1: 配置Source用于监控自定义.log文件,配置Sink输出数据到Flume3

vim /opt/module/flume/job/group3/flume1-logger-flume.conf
# Name the components on this agent
a1.sources = r1
a1.sinks = k1
a1.channels = c1

# Describe/configure the source
a1.sources.r1.type = exec
a1.sources.r1.command = tail -F /opt/module/my.log
a1.sources.r1.shell = /bin/bash -c

# Describe the sink
a1.sinks.k1.type = avro
a1.sinks.k1.hostname = hadoop104
a1.sinks.k1.port = 4141

# Describe the channel
a1.channels.c1.type = memory
a1.channels.c1.capacity = 1000
a1.channels.c1.transactionCapacity = 100

# Bind the source and sink to the channel
a1.sources.r1.channels = c1
a1.sinks.k1.channel = c1

Flume2: 配置Source监控端口44444数据流,配置Sink数据到Flume3

vim /opt/module/flume/job/group3/flume2-netcat-flume.conf
# Name the components on this agent
a2.sources = r1
a2.sinks = k1
a2.channels = c1

# Describe/configure the source
a2.sources.r1.type = netcat
a2.sources.r1.bind = hadoop103
a2.sources.r1.port = 44444

# Describe the sink
a2.sinks.k1.type = avro
a2.sinks.k1.hostname = hadoop104
a2.sinks.k1.port = 4141

# Use a channel which buffers events in memory
a2.channels.c1.type = memory
a2.channels.c1.capacity = 1000
a2.channels.c1.transactionCapacity = 100

# Bind the source and sink to the channel
a2.sources.r1.channels = c1
a2.sinks.k1.channel = c1

Flume3

vim /opt/module/flume/job/group3/flume3-flume-logger.conf
# Name the components on this agent
a3.sources = r1
a3.sinks = k1
a3.channels = c1

# Describe/configure the source
a3.sources.r1.type = avro
a3.sources.r1.bind = hadoop104
a3.sources.r1.port = 4141

# Describe the sink
# Describe the sink
a3.sinks.k1.type = logger

# Describe the channel
a3.channels.c1.type = memory
a3.channels.c1.capacity = 1000
a3.channels.c1.transactionCapacity = 100

# Bind the source and sink to the channel
a3.sources.r1.channels = c1
a3.sinks.k1.channel = c1

运行Flume

Flume3
flume-ng agent --conf conf/ --name a3 --conf-file flume3-flume-logger.conf -Dflume.root.logger=INFO,console

Flume2
flume-ng agent -c /conf -f flume2-netcat-flume.conf -n a2 -Dflume.root.logger=INFO,console

Flume1
flume-ng agent -c conf/ -f flume1-logger-flume.conf -n a1 -Dflume.root.logger=INFO,console

测试数据:

# hadoop102 中模拟日志文件写入
echo hello >> /opt/module/my.log 
# hadoop103 连接natcat 
nc hadoop103 4444 
world

在最终结果服务器上查看结果: hadoop104

总结

本章节主要对Flume的内部原理进行了分享,并针对内部原理举了几个案例,大家根据案例就可以体会到Flume内部原理的妙用,下一章,是FLume的最后一章,扩展知识点

打怪升级之小白的大数据之旅(七十三)<flume高级>(代码片段)

打怪升级之小白的大数据之旅(七十三)Flume高级上次回顾上一章介绍了Flume的内部原理,本章就Flume的扩展知识进行讲解,本章的重点就是了解并学会使用Flume的自定义组件自定义组件在上一章介绍了内部原理,所以下... 查看详情

打怪升级之小白的大数据之旅(七十四)<初识kafka>(代码片段)

打怪升级之小白的大数据之旅(七十四)初识Kafka引言学完Flume之后,接下来将为大家带来Kafka相关的知识点,在工作中,Kafka和Flume经常会搭配使用,那么Kafka究竟是什么呢?让我们开始今天的内容吧Kafka地图惯例&... 查看详情

打怪升级之小白的大数据之旅(七十一)<hadoop生态:初识flume>(代码片段)

打怪升级之小白的大数据之旅(七十一)Hadoop生态:初识Flume上次回顾上一章,我们学习完了hive的内容,本章开始是Hadoop中经常使用的另外一个框架Flume初识Flume下面这个是flume的标志flume的中文是水槽,但我觉得将它... 查看详情

打怪升级之小白的大数据之旅(七十三)<flume高级>(代码片段)

打怪升级之小白的大数据之旅(七十三)Flume高级上次回顾上一章介绍了Flume的内部原理,本章就Flume的扩展知识进行讲解,本章的重点就是了解并学会使用Flume的自定义组件自定义组件在上一章介绍了内部原理,所以下... 查看详情

打怪升级之小白的大数据之旅(六十二)<hive旅程第三站:hive数据类型>(代码片段)

打怪升级之小白的大数据之旅(六十二)Hive旅程第三站:Hive数据类型上次回顾上一章,我们对Hive的安装进行了学习,本章正式学习Hive的相关操作,按照惯例,学习一个新的语言就要了解它的数据类型数据类型Hive的... 查看详情

打怪升级之小白的大数据之旅(七十四)<初识kafka>(代码片段)

打怪升级之小白的大数据之旅(七十四)初识Kafka引言学完Flume之后,接下来将为大家带来Kafka相关的知识点,在工作中,Kafka和Flume经常会搭配使用,那么Kafka究竟是什么呢?让我们开始今天的内容吧Kafka地图惯例&... 查看详情

打怪升级之小白的大数据之旅(七十)<hive旅程终点站:hive的综合案例>(代码片段)

打怪升级之小白的大数据之旅(七十)Hive旅程终点站:Hive的综合案例本章内容本章是Hive的最后一章,主要是通过一个案例来对我们前面所学的知识点进行一个实操总结,大家根据案例查漏补缺,哪里知识点不会就补一下... 查看详情

打怪升级之小白的大数据之旅(六十三)<hive旅程第四站:ddl操作>(代码片段)

打怪升级之小白的大数据之旅(六十三)Hive旅程第四站:DDL操作上次回顾上一章,我们学习了Hive的数据类型以及访问方式,本章节我们对数据库与数据表的操作进行学习DDL操作数据库操作的CURD数据库的操作和mysql相同,... 查看详情

打怪升级之小白的大数据之旅(六十一)<hive旅程第二站:hive安装>(代码片段)

打怪升级之小白的大数据之旅(六十一)Hive旅程第二站:Hive安装上次回顾上一章我们学习了Hive的概念以及框架原理,本章节是对Hive的安装进行分享,因为它有些需要自己配置的点,所以我单独开了一个章节Hive安装前期... 查看详情

打怪升级之小白的大数据之旅(六十四)<hive旅程第五站:dml基本操作>(代码片段)

打怪升级之小白的大数据之旅(六十四)Hive旅程第五站:DML基本操作上次回顾上一章,我们学习了Hive的DDL操作,学会如何操作数据库、数据表后,本章我们就要开始学习如何将数据导入到表中,如何将数据从表中导... 查看详情

打怪升级之小白的大数据之旅(六十九)<hive旅程第十站:hive的优化>(代码片段)

打怪升级之小白的大数据之旅(六十九)Hive旅程第十站:Hive的优化上次回顾上一章介绍了Hive的压缩与存储格式,本章节是Hive的一起其他优化方法Fetch抓取Fetch抓取是指,Hive中对某些情况的查询可以不必使用MapReduce计算从hive... 查看详情

打怪升级之小白的大数据之旅(六十五)<hive旅程第六站:hive的查询>(代码片段)

打怪升级之小白的大数据之旅(六十五)Hive旅程第六站:Hive的查询上次回顾经过前面的学习,我们已经可以初步使用Hive对数据的一些简单操作了,本章节是Hive的一个重点内容–查询查询HQL和我们前面学习的Mysql语法是一样... 查看详情

打怪升级之小白的大数据之旅(六十八)<hive旅程第九站:hive的压缩与存储>(代码片段)

打怪升级之小白的大数据之旅(六十八)Hive旅程第九站:Hive的压缩与存储上次回顾上一章,我们学习完了hive的函数相关操作,到此,我们hive的大的知识点就全部介绍完毕了,当然了,还有一些细节我没有讲到... 查看详情

打怪升级之小白的大数据之旅(六十六)<hive旅程第七站:hive的分区表与分桶表>(代码片段)

打怪升级之小白的大数据之旅(六十六)Hive旅程第七站:Hive的分区表与分桶表上次回顾上一章,我们学习了Hive的查询相关语法,本章节我们学习一下分区表与分桶表分区表通过前面Hive的学习,我们知道,表在HDFS中... 查看详情

打怪升级之小白的大数据之旅(六十)<hive旅程中的始发站>(代码片段)

打怪升级之小白的大数据之旅(六十)Hive旅程中的始发站引言经过了前面Hadoop、MR、Java、MySQL以及Linux的洗礼,接下来我们就要进入到大数据中特别重要的一个知识点学习–Hive,Hive是我们大数据日常工作中必不可少的一个技能&#x... 查看详情

flask连接数据库打怪升级之旅

...一个学习经验,也就是我们今天分享的连接数据库部分的打怪升级之旅。希望可以为大家在学习Python的路上提供一些参考。初级阶段首先安装Mysql扩展包650)this.width=650; 查看详情

flask连接数据库打怪升级之旅

...、初级阶段 1.Mysql扩展包 2.建立数据库连接3.开启打怪升级之路 在日常开发中,连 查看详情

03注解是什么?——《android打怪升级之旅》(代码片段)

感谢大家和我一起,在Android世界打怪升级!注解非常的简单,但又大量的出现在源码中。希望通过该文章,能让大家看到注解不打怵,明白如何自定义注解,以及注解的作用,一眼就能粗略的理解该注... 查看详情