Source是负责接收数据到Flume Agent的组件。Source组件可以处理各种类型、各种格式的日志数据，
包括avro、thrift、exec、jms、spooling directory、netcat、sequence generator、syslog、http、
legacy。官方提供的source类型已经很多，但是有时候并不能满足实际开发当中的需求，此时我们就需
如：实时监控MySQL，从MySQL中获取数据传输到HDFS或者其他存储框架，所以此时需要我们自己实
官方也提供了自定义source的接口：Flume 1.9.0 Developer Guide — Apache Flume
自定义MySQLSource步骤
根据官方说明自定义MySqlSource需要继承AbstractSource类并实现Configurable和PollableSource接
口。
实现相应方法：
getBackOffSleepIncrement()//暂不用
getMaxBackOffSleepInterval()//暂不用
configure(Context context)//初始化context
process()//获取数据（从MySql获取数据，业务处理比较复杂，所以我们定义一个专门的类——
SQLSourceHelper来处理跟MySql的交互），封装成Event并写入Channel，这个方法被循环调用
stop()//关闭相关的资源
Flume的组件详解
Agent结构
Flume 运行的核心是 Agent。Flume以agent为最小的独立运行单位。一个agent就是一个JVM。它
是一个完整的数据收集工具，含有三个核心组件，分别是
source、 channel、 sink。通过这些组件， Event 可以从一个地方流向另一个地方，
图示
Source
source是数据的收集端，负责将数据捕获后进行特殊的格式化，将数据封装到事件（event）
里，然后将事件推入Channel中。 Flume提供了很多内置的Source， 支持 Avro， log4j， syslog
和 http post(body为json格式)。可以让应用程序同已有的Source直接打交道，如AvroSource，
SyslogTcpSource。 如果内置的Source无法满足需要， Flume还支持自定义Source。
图示
channel
Channel是连接Source和Sink的组件，大家可以将它看做一个数据的缓冲区（数据队列），它可以
将事件暂存到内存中也可以持久化到本地磁盘上， 直到Sink处理完该事件。介绍两个较为常用的
Channel， MemoryChannel和FileChannel。
举例几个比较常用的：
Memory Channel使用内存作为数据的存储。
Type channel的类型：必须为memory
capacity：channel中的最大event数目
transactionCapacity：channel中允许事务的最大event数目
File Channel 使用文件作为数据的存储
Type channel的类型：必须为 file
checkpointDir ：检查点的数据存储目录【提前创建目录】
dataDirs ：数据的存储目录【提前创建目录】
transactionCapacity：channel中允许事务的最大event数目
Spillable Memory Channel 使用内存作为channel超过了阀值就存在文件中
Type channel的类型：必须为SPILLABLEMEMORY
memoryCapacity：内存的容量event数
overflowCapacity：数据存到文件的event阀值数
checkpointDir：检查点的数据存储目录
dataDirs：数据的存储目录
sink
（数据输出的方式，将channel整理好的一个个event，传送到指定地方）
Sink从Channel中取出事件，然后将数据发到别处，可以向文件系统、数据库、 hadoop存数据，
也可以是其他agent的Source。在日志数据较少时，可以将数据存储在文件系统中，并且设定一定
的时间间隔保存数据。
图示
举例几个比较常用的：
HDFS Sink：将数据传输到hdfs集群中。
type：sink的类型 必须是hdfs。
hdfs.path：hdfs的上传路径。
hdfs.filePrefix：hdfs文件的前缀。默认是:FlumeData
hdfs.rollInterval:间隔多久产生新文件，默认是:30（秒） 0表示不以时间间隔为准。
hdfs.rollSize：文件到达多大再产生一个新文件，默认是:1024（bytes）0表示不以文件
大小为准。
hdfs.rollCount：event达到多大再产生一个新文件，默认是:10（个）0表示不以event
数目为准。*
hdfs.batchSize：每次往hdfs里提交多少个event，默认为100
hdfs.fileType：hdfs文件的格式主要包括：SequenceFile, DataStream
,CompressedStream，如果使用了CompressedStream就要设置压缩方式。
hdfs.codeC：压缩方式：gzip, bzip2, lzo, lzop, snappy
注：%{host}可以使用header的key。以及%Y%m%d来表示时间，但关于时间的表示需
要在header里有timestamp这个key。
ogger Sink将数据作为日志处理（根据flume中的设置的日志方式来显示）
要在控制台显示在运行agent的时候加入：-Dflume.root.logger=INFO,console 。
type：sink的类型：必须是 logger。
maxBytesToLog：打印body的最长的字节数 默认为16
Avro Sink：数据被转换成Avro Event，然后发送到指定的服务端口上。
type：sink的类型：必须是 avro。
hostname：指定发送数据的主机名或者ip
port：指定发送数据的端口
File Roll Sink：数据发送到本地文件。
type：sink的类型：必须是 file_roll。
sink.directory：存储文件的目录【提前创建目录】
batchSize：一次发送多少个event。默认为100
sink.rollInterval：多久产生一个新文件，默认为30s。单位是s。0为不产生新文件。
【即使没有数据也会产生文件】
interceptor
当我们需要对数据进行过滤时，除了我们在Source、 Channel和Sink进行代码修改之外， Flume
为我们提供了拦截器，拦截器也是chain形式的。
拦截器的位置在Source和Channel之间，当我们为Source指定拦截器后，我们在拦截器中会
得到event，根据需求我们可以对event进行保留还是
抛弃，抛弃的数据不会进入Channel中。
图示
Timestamp Interceptor 时间戳拦截器 在header里加入key为timestamp，value为当前时
间。
type：拦截器的类型，必须为timestamp
preserveExisting：如果此拦截器增加的key已经存在，如果这个值设置为true则保持原
来的值，否则覆盖原来的值。默认为false
Host Interceptor 主机名或者ip拦截器，在header里加入ip或者主机名
type：拦截器的类型，必须为host
preserveExisting：如果此拦截器增加的key已经存在，如果这个值设置为true则保持原
来的值，否则覆盖原来的值。默认为false
useIP：如果设置为true则使用ip地址，否则使用主机名，默认为true
hostHeader：使用的header的key名字，默认为host
Static Interceptor 静态拦截器，是在header里加入固定的key和value。
type：avrosource的类型，必须是static。
preserveExisting:如果此拦截器增加的key已经存在，如果这个值设置为true则保持原来
的值，否则覆盖原来的值。默认为false
key:静态拦截器添加的key的名字
value:静态拦截器添加的key对应的value值
Flume执行流程
1 Source 接受数据
2 Channel Processor 处理 Event
3 Channel Processor 将 Event 传递给 interceptor链对 Event 进行过滤操作
4 过滤完之后再把 Event 发送回 Channel Prodessor
5 Channel Processor把 Event 发送给Channel selectors
6 Channel selector返回Event 属于哪个Channel
7 根据第6步返回的结果，将Event发送到指定的Channel
8 SinkProcessor从Channel中拉去数据
9 最后把数据Sink出去
图示
Flume事务
推送事务流程
doPut: 把批数据写入到临时缓冲区putList
doCommit: 检查Channel容量是否足够，如果容量足够则把putList里的数据发送到Channel
doRollBack:如果Channel容量不够，则把数据回滚到putList
拉取事务流程
doTake:把数据读取到临时缓冲区takeList
doCommit:检查数据是否发送成功，成功的话，则把event从takeList中移除
doRollBack:如何发送失败，则把takeList的数据回滚数据到Channel
图示
Ganglia
简介
Ganglia是UC Berkeley发起的一个开源集群监视项目，设计用于测量数以千计的节点。Ganglia的核心
包含gmond、gmetad以及一个Web前端。
主要是用来监控系统性能，如：cpu 、mem、硬盘利用率，I/O负载、网络流量情况等，通过曲线很容
易见到每个节点的工作状态，对合理调整、分配系统资源，提高系统整体性能起到重要作用。
工作组件
Ganglia 监控套件包括三个主要部分：gmond，gmetad，和网页接口ganglia-web
Gmond :是一个守护进程，他运行在每一个需要监测的节点上，收集监测统计，发送和接受在同
一个组播或单播通道上的统计信息 如果他是一个发送者(mute=no)他会收集基本指标，比如系统
负载（load_one）,CPU利用率。他同时也会发送用户通过添加C/Python模块来自定义的指标。 如
果他是一个接收者（deaf=no）他会聚合所有从别的主机上发来的指标，并把它们都保存在内存缓
冲区中。
Gmetad:也是一个守护进程，他定期检查gmonds，从那里拉取数据，并将他们的指标存储在RRD
存储引擎中。他可以查询多个集群并聚合指标。他也被用于生成用户界面的web前端。
Ganglia-web :顾名思义，他应该安装在有gmetad运行的机器上，以便读取RRD文件。 集群是主
机和度量数据的逻辑分组，比如数据库服务器，网页服务器，生产，测试，QA等，他们都是完全
分开的，你需要为每个集群运行单独的gmond实例。
一般来说集群中每个节点需要一个接收的gmond，每个网站需要一个gmetad。
子主题 3
Sqoop
Sqoop简介
sqoop产生背景
在工作中，我们经常会遇到下面这样的场景。
场景一：将关系型数据库中某张表的数据抽取到 Hadoop（HDFS/Hive/HBase）上；
场景二：将 Hadoop 上的数据导出到关系型数据库中。
那么如何解决这两类问题呢？通常情况下是通过开发 Map Reduce 来实现。
导入：Map Reduce 输入为 DBInput Format 类型，输出为 Text Output Format。
导出：Map Reduce 输入为 Text Input Format 类型，输出为 DBOutput Format。
使用 Map Reduce 处理以上两个场景时存在如下问题：每次都需要编写 Map Reduce 程序，非常麻烦。
在没有出现 Sqoop 之前，实际生产中有很多类似的需求，需要通过编写 Map Reduce 去实现，然后形
成一个工具，后来慢慢就将该工具代码整理出一个框架并逐步完善，最终就有了 Sqoop 的诞生。
sqoop概述
基于 Hadoop 之上的数据传输工具 Sqoop 是 Apache 的顶级项目，主要用于在 Hadoop 和关系数据
库、数据仓库、No SQL 系统间传递数据。通过 Sqoop 我们可以方便地将数据从关系数据库导入到
HDFS、HBase、Hive，或者将数据从 HDFS 导出到关系数据库。使用 Sqoop 导入导出数据的处理流程
如图 所示。
图示
Sqoop 是连接传统关系型数据库和 Hadoop 的桥梁，它不需要开发人员编写相应的 Map Reduce 代
码，只需要编写简单的配置脚本即可，大大提升了开发效率。
图示
sqoop架构
Sqoop 的架构非常简单，其整合了 Hive、HBase 等，通过 map 任务来传输数据，map 负责数据的加
载、转换，然后存储到 HDFS、HBase 或者 Hive 中。
（1）从工作模式角度看待：Sqoop 是基于客户端模式的，用户使用客户端模式，只需要在一台机器上
即可完成。
（2）从 Map Reduce 角度看待：Sqoop 只提交一个 map 作业，数据的传输和转换都是使用 Mapper
来完成的，而且该 Map Reduce 作业仅有 Mapper 并不需要 Reducer，在执行 Sqoop 时可以通过
YARN 监控页面查看到。
（3）从安全角度看待：需要在执行时将用户名或者密码显性指定，也可以在配置文件中配置，总的来
说，安全性不是很高。
图示
sqoop导入与导出的过程
由前面的 Sqoop 框架，可以知道 Sqoop 是通过 MapReduce 作业进行导入操作的。在导入过程中，
Sqoop 从表中读取数据行，将其写入 HDFS。反之就是导出过程。
导入流程图
导出流程图
DataX
DataX概览
DataX 是一个异构数据源离线同步工具，致力于实现包括关系型数据库(MySQL、Oracle等)、HDFS、
Hive、ODPS、HBase、FTP等各种异构数据源之间稳定高效的数据同步功能。
设计理念
为了解决异构数据源同步问题，DataX将复杂的网状的同步链路变成了星型数据链路，DataX作为中间传
输载体负责连接各种数据源。
当需要接入一个新的数据源的时候，只需要将此数据源对接到DataX，便能跟已有的数据源做到无缝数
据同步。
DataX3.0的六大核心优势
1. 可靠的数据质量监控
完美解决数据传输个别类型失真问题
DataX旧版对于部分数据类型(比如时间戳)传输一直存在毫秒阶段等数据失真情况，新版本
DataX3.0已经做到支持所有的强数据类型，每一种插件都有自己的数据类型转换策略，让数据可以
完整无损的传输到目的端。
提供作业全链路的流量、数据量�运行时监控
DataX3.0运行过程中可以将作业本身状态、数据流量、数据速度、执行进度等信息进行全面的展
示，让用户可以实时了解作业状态。并可在作业执行过程中智能判断源端和目的端的速度对比情
况，给予用户更多性能排查信息。
提供脏数据探测
在大量数据的传输过程中，必定会由于各种原因导致很多数据传输报错(比如类型转换错误)，这种
数据DataX认为就是脏数据。DataX目前可以实现脏数据精确过滤、识别、采集、展示，为用户提
供多种的脏数据处理模式，让用户准确把控数据质量大关！
2. 丰富的数据转换功能
DataX作为一个服务于大数据的ETL工具，除了提供数据快照搬迁功能之外，还提供了丰富数据转换的功
能，让数据在传输过程中可以轻松完成数据脱敏，补全，过滤等数据转换功能，另外还提供了自动
groovy函数，让用户自定义转换函数。详情请看DataX3的transformer详细介绍。
3. 精准的速度控制
还在为同步过程对在线存储压力影响而担心吗？新版本DataX3.0提供了包括通道(并发)、记录流、字节
流三种流控模式，可以随意控制你的作业速度，让你的作业在库可以承受的范围内达到最佳的同步速
度
4. 强劲的同步性能
DataX3.0每一种读插件都有一种或多种切分策略，都能将作业合理切分成多个Task并行执行，单机多线
程执行模型可以让DataX速度随并发成线性增长。在源端和目的端性能都足够的情况下，单个作业一定
可以打满网卡。另外，DataX团队对所有的已经接入的插件都做了极致的性能优化，并且做了完整的性
能测试。性能测试相关详情可以参照每单个数据源的详细介绍：DataX数据源指南
5. 健壮的容错机制
DataX作业是极易受外部因素的干扰，网络闪断、数据源不稳定等因素很容易让同步到一半的作业报错
停止。因此稳定性是DataX的基本要求，在DataX 3.0的设计中，重点完善了框架和插件的稳定性。目前
DataX3.0可以做到线程级别、进程级别(暂时未开放)、作业级别多层次局部/全局的重试，保证用户的作
业稳定运行。
线程内部重试
DataX的核心插件都经过团队的全盘review，不同的网络交互方式都有不同的重试策略。
线程级别重试
目前DataX已经可以实现TaskFailover，针对于中间失败的Task，DataX框架可以做到整个Task级
别的重新调度。
6. 极简的使用体验
易用
下载即可用，支持linux和windows，只需要短短几步骤就可以完成数据的传输。请点击：Quick
Start
详细
DataX在运行日志中打印了大量信息，其中包括传输速度，Reader、Writer性能，进程CPU，JVM
和GC情况等等
DataX3.0框架设计
DataX本身作为离线数据同步框架，采用Framework + plugin架构构建。将数据源读取和写入抽象成为
Reader/Writer插件，纳入到整个同步框架中。
Reader：Reader为数据采集模块，负责采集数据源的数据，将数据发送给Framework。
Writer： Writer为数据写入模块，负责不断向Framework取数据，并将数据写入到目的端。
Framework（channel）：Framework用于连接reader和writer，作为两者的数据传输通道，并处
理缓冲，流控，并发，数据转换等核心技术问题。
DataX 3.0 开源版本支持单机多线程模式完成同步作业运行，本小节按一个DataX作业生命周期的时序
图，从整体架构设计非常简要说明DataX各个模块相互关系。
图示
核心模块的介绍
1. DataX完成单个数据同步的作业，我们称之为Job，DataX接受到一个Job之后，将启动一个进程来
完成整个作业同步过程。DataX Job模块是单个作业的中枢管理节点，承担了数据清理、子任务切
分(将单一作业计算转化为多个子Task)、TaskGroup管理等功能。
2. DataXJob启动后，会根据不同的源端切分策略，将Job切分成多个小的Task(子任务)，以便于并发
执行。Task便是DataX作业的最小单元，每一个Task都会负责一部分数据的同步工作。
3. 切分多个Task之后，DataX Job会调用Scheduler模块，根据配置的并发数据量，将拆分成的Task
重新组合，组装成TaskGroup(任务组)。每一个TaskGroup负责以一定的并发运行完毕分配好的所
有Task，默认单个任务组的并发数量为5。 4. 每一个Task都由TaskGroup负责启动，Task启动后，会固定启动Reader—>Channel—>Writer的
线程来完成任务同步工作。
5. DataX作业运行起来之后， Job监控并等待多个TaskGroup模块任务完成，等待所有TaskGroup任
务完成后Job成功退出。否则，异常退出，进程退出值非0
DataX的调度流程
举例来说，用户提交了一个DataX作业，并且配置了20个并发，目的是将一个200张分表的mysql数据同
步到odps里面。 DataX的调度决策思路是：
1. DataXJob根据分库分表切分成了200个Task。 2. 根据20个并发，DataX计算共需要分配4个TaskGroup。 3. 4个TaskGroup平分切分好的200个Task，每一个TaskGroup负责以5个并发共计运行50个Task。
数据抽取策略
和sqoop一样,从结构化数据库中抽取数据,最后需要根据数据库表和数据总量,每日数据变化做抽取
策略选择. 1. 如果是实体表,如果数据量比较小,一般每天或者一周,一个月抽取一份全量的表.
如果是实体大表,一般每天抽取一份增量数据,然后按照分区表进行存储.这类数据都是先放到
ODS层.如果有需要,在DWD层每天做所有数据的滚动聚合,这时候DWD就有一份完整总数居. 2. 事实表,如订单,购物车等表.一般都是每天抽取一份增量数据,全量导入没必要,增量导入,然后每
天的数据以分区形式存储.也是存放到ODS贴源层.
如果需要做滚动合并,一般是在DWD层做每日数据滚动合并,这样DWD就会有一份完整的总数
居大表. 3. 维度表,和实体表也是一样,需要区分大表还是小表,一般10万条或者100万条以下算小表,具体
标准每个公司差异可能很大.毕竟对于大数据处理来说,百万条数据才到入门数据门槛.
小表——全量抽取
大表——增量抽取
工具对比：Sqoop、Flume、DataX
DataX
DataX介绍：
DataX 是阿里开源的一个异构数据源离线同步工具，致力于实现包括关系型数据库(MySQL、Oracle
等)、HDFS、Hive、ODPS、HBase、FTP等各种异构数据源之间稳定高效的数据同步功能。
DataX设计理念
DataX本身作为数据同步框架，将不同数据源的同步抽象为从源头数据源读取数据的Reader插件，以及
向目标端写入数据的Writer插件，理论上DataX框架可以支持任意数据源类型的数据同步工作。同时
DataX插件体系作为一套生态系统, 每接入一套新数据源该新加入的数据源即可实现和现有的数据源互
通
Flume
Sqoop
Sqoop是一个用于在Hadoop和关系型数据库之间流转数据的一个工具。可以使用Sqoop将数据从关系
型数据库系统(RDBMS)比如MySQL或者Oracle导入到hadoop分布式文件系统(HDFS)上，然后数据在
Hadoop MapReduce上转换，以及将数据导出到RDBMS中。
Sqoop自动实现了上面提到的很多过程，Sqoop使用MapReduce来导入和导出数据，这样既可以提
供并行化操作又可以提高容错能力。
总结
这些只是工具，我们的使用，只需要安装和通过命令+配置文件的形式来执行.
对于大数据技术框架来说,总共就做几件事情
1. 数据采集
2. 数据传输
3. 数据存储
4. 数据分析与计算
5. 数据结果存储和展示
1. sqoop datax等一般用于数据库和大数据文件存储框架之间的数据导入和导出.注意导入导出是从大
数据存储框架角度来说的. 2. flume等日志采集框架,用于日志文件等半结构化数据和大数据文件存储框架之间的数据导入和导出. 3. 针对HBase的数据导入导出,可以使用文件形式,直接bulkload方式,也是一样的. 4. 其他框架按照功能划分,也是一样的道理. 不过当学会使用mapreduce或者spark 程序之后,其实这类
简单的数据导入导出功能,自己开发程序实现也是一样的,不过通用性和健壮性会差一些. 5. 实际企业开发中,遇到特殊的数据导入和导出,很多时候还是需要针对性编写代码处理的
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
