离线计算七 辅助系统(flume、sqoop、oozie)

本文介绍了大数据辅助系统中的Flume、Oozie和Sqoop。Flume是一个分布式日志采集系统,通过配置source、sink和channel实现数据传输。Oozie是工作流调度器,用于组织复杂任务执行计划。Sqoop则用于数据导入导出,支持从RDBMS到HDFS的数据迁移。文章提供了详细的配置示例和使用方法,帮助读者理解和掌握这三个工具的使用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

课程大纲(辅助系统)

离线辅助系统 数据接入 Flume介绍
Flume组件
Flume实战案例
任务调度 调度器基础
市面上调度工具
Oozie的使用
Oozie的流程定义详解
数据导出 sqoop基础知识
sqoop实战及原理
Sqoop数据导入实战
Sqoop数据导出实战
Sqoop作业操作
Sqoop的原理

学习目标:
1、理解flume、sqoop、oozie的应用场景
2、理解flume、sqoop、oozie的基本原理
3、掌握flume、sqoop、oozie的使用方法

前言
在一个完整的大数据处理系统中,除了hdfs+mapreduce+hive组成分析系统的核心之外,还需要数据采集、结果数据导出、任务调度等不可或缺的辅助系统,而这些辅助工具在hadoop生态体系中都有便捷的开源框架,如图所示:

  1. 日志采集框架Flume
    1.1 Flume介绍
    1.1.1 概述
    Flume是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的系统。
    Flume可以采集文件,socket数据包等各种形式源数据,又可以将采集到的数据输出到HDFS、hbase、hive、kafka等众多外部存储系统中
    一般的采集需求,通过对flume的简单配置即可实现
    Flume针对特殊场景也具备良好的自定义扩展能力,因此,flume可以适用于大部分的日常数据采集场景

1.1.2 运行机制
Flume分布式系统中最核心的角色是agent,flume采集系统就是由一个个agent所连接起来形成
每一个agent相当于一个数据传递员,内部有三个组件:
Source:采集源,用于跟数据源对接,以获取数据
Sink:下沉地,采集数据的传送目的,用于往下一级agent传递数据或者往最终存储系统传递数据
Channel:angent内部的数据传输通道,用于从source将数据传递到sink

1.1.4 Flume采集系统结构图

  1. 简单结构
    单个agent采集数据

  2. 复杂结构
    多级agent之间串联

1.2 Flume实战案例
1.2.1 Flume的安装部署
Flume的安装非常简单,只需要解压即可,当然,前提是已有hadoop环境
上传安装包到数据源所在节点上
然后解压 tar -zxvf apache-flume-1.6.0-bin.tar.gz
然后进入flume的目录,修改conf下的flume-env.sh,在里面配置JAVA_HOME

2、根据数据采集的需求配置采集方案,描述在配置文件中(文件名可任意自定义)
3、指定采集方案配置文件,在相应的节点上启动flume agent

先用一个最简单的例子来测试一下程序环境是否正常
先在flume的conf目录下新建一个文件
vi netcat-logger.conf

定义这个agent中各组件的名字a1.sources = r1a1.sinks = k1a1.channels = c1# 描述和配置source组件:r1a1.sources.r1.type = netcata1.sources.r1.bind = localhosta1.sources.r1.port = 44444# 描述和配置sink组件:k1a1.sinks.k1.type = logger# 描述和配置channel组件,此处使用是内存缓存的方式a1.channels.c1.type = memorya1.channels.c1.capacity = 1000a1.channels.c1.transactionCapacity = 100# 描述和配置source channel sink之间的连接关系a1.sources.r1.channels = c1a1.sinks.k1.channel = c1

启动agent去采集数据
bin/flume-ng agent -c conf -f conf/netcat-logger.conf -n a1 -Dflume.root.logger=INFO,console
-c conf 指定flume自身的配置文件所在目录
-f conf/netcat-logger.con 指定我们所描述的采集方案
-n a1 指定我们这个agent的名字
测试
先要往agent采集监听的端口上发送数据,让agent有数据可采
随便在一个能跟agent节点联网的机器上
telnet anget-hostname port (telnet localhost 44444)

1.2.2 采集案例
1、采集目录到HDFS
采集需求:某服务器的某特定目录下,会不断产生新的文件,每当有新文件出现,就需要把文件采集到HDFS中去
根据需求,首先定义以下3大要素
采集源,即source——监控文件目录 : spooldir
下沉目标,即sink——HDFS文件系统 : hdfs sink
source和sink之间的传递通道——channel,可用file channel 也可以用内存channel

配置文件编写:
#定义三大组件的名称agent1.sources = source1agent1.sinks = sink1agent1.channels = channel1# 配置source组件agent1.sources.source1.type = spooldiragent1.sources.source1.spoolDir = /home/hadoop/logs/agent1.sources.source1.fileHeader = false#配置拦截器agent1.sources.source1.interceptors = i1agent1.sources.source1.interceptors.i1.type = hostagent1.sources.source1.interceptors.i1.hostHeader = hostname# 配置sink组件agent1.sinks.sink1.type = hdfsagent1.sinks.sink1.hdfs.path =hdfs://hdp-node-01:9000/weblog/flume-collection/%y-%m-%d/%H-%Magent1.sinks.sink1.hdfs.filePrefix = access_logagent1.sinks.sink1.hdfs.maxOpenFiles = 5000agent1.sinks.sink1.hdfs.batchSize= 100agent1.sinks.sink1.hdfs.fileType = DataStreamagent1.sinks.sink1.hdfs.writeFormat =Textagent1.sinks.sink1.hdfs.rollSize = 102400agent1.sinks.sink1.hdfs.rollCount = 1000000agent1.sinks.sink1.hdfs.rollInterval = 60#agent1.sinks.sink1.hdfs.round = true#agent1.sinks.sink1.hdfs.roundValue = 10#agent1.sinks.sink1.hdfs.roundUnit = minuteagent1.sinks.sink1.hdfs.useLocalTimeStamp = true# Use a channel which buffers events in memoryagent1.channels.channel1.type = memoryagent1.channels.channel1.keep-alive = 120agent1.channels.channel1.capacity = 500000agent1.channels.channel1.transactionCapacity = 600# Bind the source and sink to the channelagent1.sources.source1.channels = channel1agent1.sinks.sink1.channel = channel1

Channel参数解释:
capacity:默认该通道中最大的可以存储的event数量
trasactionCapacity:每次最大可以从source中拿到或者送到sink中的event数量
keep-alive:event添加到通道中或者移出的允许时间

2、采集文件到HDFS
采集需求:比如业务系统使用log4j生成的日志,日志内容不断增加,需要把追加到日志文件中的数据实时采集到hdfs

根据需求,首先定义以下3大要素
采集源,即source——监控文件内容更新 : exec ‘tail -F file’
下沉目标,即sink——HDFS文件系统 : hdfs sink
Source和sink之间的传递通道——channel,可用file channel 也可以用 内存channel

配置文件编写:
agent1.sources = source1agent1.sinks = sink1agent1.channels = channel1# Describe/configure tail -F source1agent1.sources.source1.type = execagent1.sources.source1.command = tail -F /home/hadoop/logs/access_logagent1.sources.source1.channels = channel1#configure host for sourceagent1.sources.source1.interceptors = i1agent1.sources.source1.interceptors.i1.type = hostagent1.sources.source1.interceptors.i1.hostHeader = hostname# Describe sink1agent1.sinks.sink1.type = hdfs#a1.sinks.k1.channel = c1agent1.sinks.sink1.hdfs.path =hdfs://hdp-node-01:9000/weblog/flume-collection/%y-%m-%d/%H-%Magent1.sinks.sink1.hdfs.filePrefix = access_logagent1.sinks.sink1.hdfs.maxOpenFiles = 5000agent1.sinks.sink1.hdfs.batchSize= 100agent1.sinks.sink1.hdfs.fileType = DataStreamagent1.sinks.sink1.hdfs.writeFormat =Textagent1.sinks.sink1.hdfs.rollSize = 102400agent1.sinks.sink1.hdfs.rollCount = 1000000agent1.sinks.sink1.hdfs.rollInterval = 60agent1.sinks.sink1.hdfs.round = trueagent1.sinks.sink1.hdfs.roundValue = 10agent1.sinks.sink1.hdfs.roundUnit = minuteagent1.sinks.sink1.hdfs.useLocalTimeStamp = true# Use a channel which buffers events in memoryagent1.channels.channel1.type = memoryagent1.channels.channel1.keep-alive = 120agent1.channels.channel1.capacity = 500000agent1.channels.channel1.transactionCapacity = 600# Bind the source and sink to the channelagent1.sources.source1.channels = channel1agent1.sinks.sink1.channel = channel1

1.3 更多source和sink组件
Flume支持众多的source和sink类型,详细手册可参考官方文档
http://flume.apache.org/FlumeUserGuide.html
2. 工作流调度器azkaban
2.1 概述
2.1.1为什么需要工作流调度系统
一个完整的数据分析系统通常都是由大量任务单元组成:
shell脚本程序,java程序,mapreduce程序、hive脚本等
各任务单元之间存在时间先后及前后依赖关系
为了很好地组织起这样的复杂执行计划,需要一个工作流调度系统来调度执行;

例如,我们可能有这样一个需求,某个业务系统每天产生20G原始数据,我们每天都要对其进行处理,处理步骤如下所示:
通过Hadoop先将原始数据同步到HDFS上;
借助MapReduce计算框架对原始数据进行转换,生成的数据以分区表的形式存储到多张Hive表中;
需要对Hive中多个表的数据进行JOIN处理,得到一个明细数据Hive大表;
将明细数据进行复杂的统计分析,得到结果报表信息;
需要将统计分析得到的结果数据同步到业务系统中,供业务调用使用。

2.1.2 工作流调度实现方式
简单的任务调度:直接使用linux的crontab来定义;
复杂的任务调度:开发调度平台
或使用现成的开源调度系统,比如ooize、azkaban等

2.1.3 常见工作流调度系统
市面上目前有许多工作流调度器
在hadoop领域,常见的工作流调度器有Oozie, Azkaban,Cascading,Hamake等

2.1.4 各种调度工具特性对比
下面的表格对上述四种hadoop工作流调度器的关键特性进行了比较,尽管这些工作流调度器能够解决的需求场景基本一致,但在设计理念,目标用户,应用场景等方面还是存在显著的区别,在做技术选型的时候,可以提供参考
特性 Hamake Oozie Azkaban Cascading
工作流描述语言 XML XML (xPDL based) text file with key/value pairs Java API
依赖机制 data-driven explicit explicit explicit
是否要web容器 No Yes Yes No
进度跟踪 console/log messages web page web page Java API
Hadoop job调度支持 no yes yes yes
运行模式 command line utility daemon daemon API
Pig支持 yes yes yes yes
事件通知 no no no yes
需要安装 no yes yes no
支持的hadoop版本 0.18+ 0.20+ currently unknown 0.18+
重试支持 no workflownode evel yes yes
运行任意命令 yes yes yes yes
Amazon EMR支持 yes no currently unknown yes
2.1.5 Azkaban与Oozie对比
对市面上最流行的两种调度器,给出以下详细对比,以供技术选型参考。总体来说,ooize相比azkaban是一个重量级的任务调度系统,功能全面,但配置使用也更复杂。如果可以不在意某些功能的缺失,轻量级调度器azkaban是很不错的候选对象。
详情如下:
功能
两者均可以调度mapreduce,pig,java,脚本工作流任务
两者均可以定时执行工作流任务

工作流定义
Azkaban使用Properties文件定义工作流
Oozie使用XML文件定义工作流

工作流传参
Azkaban支持直接传参,例如 i n p u t O o z i e 支 持 参 数

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值