大数据复习笔记之hadoop浅析（二）

最新推荐文章于 2022-04-29 11:10:55 发布

席八

最新推荐文章于 2022-04-29 11:10:55 发布

阅读量480

点赞数 1

分类专栏：大数据文章标签：大数据

本文链接：https://blog.csdn.net/qq_38239282/article/details/89416293

版权

大数据专栏收录该内容

3 篇文章 0 订阅

订阅专栏

Hadoop的组成

Hadoop的核心组件p21
核心组件
hadoop
分析：Hadoop的核心组件分为：HDFS（分布式文件系统）、MapRuduce（分布式运算编程框架）、YARN（运算资源调度系统）

Hadoop业务的整体开发流程：
在这里插入图片描述
下面按《Hadoop大数据实战权威指南》中顺序介绍

1.数据采集

1.1结构化数据采集工具

sqoop

p24

1 Sqoop概述
传统的应用程序管理系统，即应用程序与使用RDBMS的关系数据库的交互，是产生大数据的来源之一。由RDBMS生成的这种大数据存储在关系数据库结构中的关系数据库服务器中。

当大数据存储和Hadoop生态系统的MapReduce，Hive，HBase，Cassandra，Pig等分析器出现时，他们需要一种工具来与关系数据库服务器进行交互，以导入和导出驻留在其中的大数据。在这里，Sqoop在Hadoop生态系统中占据一席之地，以便在关系数据库服务器和Hadoop的HDFS之间提供可行的交互。

Sqoop - “SQL到Hadoop和Hadoop到SQL”

Sqoop是一个用于在Hadoop和关系数据库服务器之间传输数据的工具。它用于从关系数据库（如MySQL，Oracle）导入数据到Hadoop HDFS，并从Hadoop文件系统导出到关系数据库。。一般情况下，关系数据表存在于线上环境的备份环境，需要每天进行数据导入，根据每天的数据量而言，sqoop可以全表导入，对于每天产生的数据量不是很大的情形可以全表导入，但是sqoop也提供了增量数据导入的机制。

Sqoop如何工作？
下图描述了Sqoop的工作流程。
sqoop
sqoop1与sqoop2对比：

版本号对比

两代之间是两个完全不同的版本，不兼容
sqoop1：1.4.x

sqoop2：1.99.x

sqoop2比sqoop1的改进

(1) 引入sqoop server，集中化管理connector等
(2) 多种访问方式：CLI,Web UI，REST API
(3) 引入基于角色的安全机制

sqoop2和sqoop1的功能性对比

功能	Sqoop 1	Sqoop 2
用于所有主要 RDBMS 的连接器	支持	不支持解决办法：使用已在以下数据库上执行测试的通用 JDBC 连接器： Microsoft SQL Server 、 PostgreSQL 、 MySQL 和 Oracle 。此连接器应在任何其它符合 JDBC 要求的数据库上运行。但是，性能可能无法与 Sqoop 中的专用连接器相比
Kerberos 安全集成	支持	不支持
数据从 RDBMS 传输至 Hive 或 HBase	支持	不支持解决办法：按照此两步方法操作。将数据从 RDBMS 导入 HDFS 在 Hive 中使用相应的工具和命令（例如 LOAD DATA 语句），手动将数据载入 Hive 或 HBase
数据从 Hive 或 HBase 传输至 RDBMS	不支持解决办法：按照此两步方法操作。从 Hive 或 HBase 将数据提取至 HDFS （作为文本或 Avro 文件）使用 Sqoop 将上一步的输出导出至 RDBMS	不支持按照与 Sqoop 1 相同的解决方法操作

sqoop1和sqoop2的架构对比

(1) : sqoop1的架构图
sqoop1
版本号为1.4.x为sqoop1
在架构上：sqoop1使用sqoop客户端直接提交的方式
访问方式：CLI控制台方式进行访问
安全性：命令或脚本中指定用户数据库名及密码

(2) : sqoop2的架构图
aqoop2
版本号为1.99x为sqoop2
在架构上：sqoop2引入了sqoop server，对connector实现了集中的管理
访问方式：REST API、 JAVA API、 WEB UI以及CLI控制台方式进行访问

CLI方式访问，会通过交互过程界面，输入的密码信息丌被看到，同时Sqoop2引入基亍角色的安全机制，Sqoop2比Sqoop多了一个Server端。

sqoop1与sqoop2优缺点比较 :

(1) sqoop1优点:架构部署简单
sqoop1的缺点:命令行方式容易出错，格式紧耦合，无法支持所有数据类型，安全机制不够完善，例如密码暴漏，
安装需要root权限，connector必须符合JDBC模型
(2) sqoop2的优点:多种交互方式，命令行，web UI，rest API，conncetor集中化管理，所有的链接安装在sqoop server上，完善权限管理机制，connector规范化，仅仅负责数据的读写。
sqoop2的缺点:架构稍复杂，配置部署更繁琐。

1.2日志文件数据采集工具

日志收集Flume

flume的基本原理p25
一.Flume架构介绍
在这里插入图片描述

本文将围绕Flume的架构、Flume的应用(日志采集)进行详细的介绍：

flume是分布式的日志收集系统，它将各个服务器中的数据收集起来并送到指定的地方去，比如说送到图中的HDFS，简单来说flume就是收集日志的。

二.Event数据流向图

flume的核心是把数据从数据源(source)收集过来，在将收集到的数据送到指定的目的地(sink)。为了保证输送的过程一定成功，在送到目的地(sink)之前，会先缓存数据(channel),待数据真正到达目的地(sink)后，flume在删除自己缓存的数据。
在整个数据的传输的过程中，流动的是event，即事务保证是在event级别进行的。那么什么是event呢？—–event将传输的数据进行封装，是flume传输数据的基本单位，如果是文本文件，通常是一行记录，event也是事务的基本单位。event从source，流向channel，再到sink，本身为一个字节数组，并可携带headers(头信息)信息。event代表着一个数据的最小完整单元，从外部数据源来，向外部的目的地去。

一个完整的event包括：event headers、event body、event信息(即文本文件中的单行记录。

flume架构介绍
flume之所以这么神奇，是源于它自身的一个设计，这个设计就是agent，agent本身是一个java进程，运行在日志收集节点—所谓日志收集节点就是服务器节点。
agent里面包含3个核心的组件：source—->channel—–>sink,类似生产者、仓库、消费者的架构。
source：source组件是专门用来收集数据的，可以处理各种类型、各种格式的日志数据,包括avro、thrift、exec、jms、spooling directory、netcat、sequence generator、syslog、http、legacy、自定义。
channel：source组件把数据收集来以后，临时存放在channel中，即channel组件在agent中是专门用来存放临时数据的——对采集到的数据进行简单的缓存，可以存放在memory、jdbc、file等等。
sink：sink组件是用于把数据发送到目的地的组件，目的地包括hdfs、logger、avro、thrift、ipc、file、null、hbase、solr、自定义。
flume的运行机制
flume的核心就是一个agent，这个agent对外有两个进行交互的地方，一个是接受数据的输入——source，一个是数据的输出sink，sink负责将数据发送到外部指定的目的地。source接收到数据之后，将数据发送给channel，chanel作为一个数据缓冲区会临时存放这些数据，随后sink会将channel中的数据发送到指定的地方—-例如HDFS等，注意：只有在sink将channel中的数据成功发送出去之后，channel才会将临时数据进行删除，这种机制保证了数据传输的可靠性与安全性。

数据分发工具Kafka

p26
kafka是分布式发布-订阅消息系统。它最初由LinkedIn公司开发，之后成为Apache项目的一部分。Kafka是一种快速、可扩展的、设计内在就是分布式的，分区的和可复制的提交日志服务。

Kafka架构
它的架构包括以下组件：

话题（Topic）：是特定类型的消息流。消息是字节的有效负载（Payload），话题是消息的分类名或种子（Feed）名。
生产者（Producer）：是能够发布消息到话题的任何对象。
服务代理（Broker）：已发布的消息保存在一组服务器中，它们被称为代理（Broker）或Kafka集群。
消费者（Consumer）：可以订阅一个或多个话题，并从Broker拉数据，从而消费这些已发布的消息。

在这里插入图片描述

Kafka存储策略

1）kafka以topic来进行消息管理，每个topic包含多个partition，每个partition对应一个逻辑log，有多个segment组成。

2）每个segment中存储多条消息（见下图），消息id由其逻辑位置决定，即从消息id可直接定位到消息的存储位置，避免id到位置的额外映射。

3）每个part在内存中对应一个index，记录每个segment中的第一条消息偏移。

4）发布者发到某个topic的消息会被均匀的分布到多个partition上（或根据用户指定的路由规则进行分布），broker收到发布消息往对应partition的最后一个segment上添加该消息，当某个segment上的消息条数达到配置值或消息发布时间超过阈值时，segment上的消息会被flush到磁盘，只有flush到磁盘上的消息订阅者才能订阅到，segment达到一定的大小后将不会再往该segment写数据，broker会创建新的segment。
在这里插入图片描述

Kafka数据保留策略

1）N天前的删除。

2）保留最近的多少Size数据。

Kafka broker

与其它消息系统不同，Kafka broker是无状态的。这意味着消费者必须维护已消费的状态信息。这些信息由消费者自己维护，broker完全不管（有offset managerbroker管理）。

从代理删除消息变得很棘手，因为代理并不知道消费者是否已经使用了该消息。Kafka创新性地解决了这个问题，它将一个简单的基于时间的SLA应用于保留策略。当消息在代理中超过一定时间后，将会被自动删除。
这种创新设计有很大的好处，消费者可以故意倒回到老的偏移量再次消费数据。这违反了队列的常见约定，但被证明是许多消费者的基本特征。

Flume与Kafka对比
kafka和flume都是日志系统，kafka是分布式消息中间件，自带存储，提供push和pull存取数据功能。flume分为agent（数据采集器）,collector（数据简单处理和写入）,storage（存储器）三部分，每一部分都是可以定制的。比如agent采用RPC（Thrift-RPC）、text（文件）等，storage指定用hdfs做。
kafka做日志缓存应该是更为合适的，但是 flume的数据采集部分做的很好，可以定制很多数据源，减少开发量。所以比较流行flume+kafka模式，如果为了利用flume写hdfs的能力，也可以采用kafka+flume的方式。

采集层主要可以使用Flume, Kafka两种技术。

Flume：Flume 是管道流方式，提供了很多的默认实现，让用户通过参数部署，及扩展API.

Kafka：Kafka是一个可持久化的分布式的消息队列。

Kafka 是一个非常通用的系统。你可以有许多生产者和很多的消费者共享多个主题Topics。相比之下,Flume是一个专用工具被设计为旨在往HDFS,HBase发送数据。它对HDFS有特殊的优化，并且集成了Hadoop的安全特性。所以，Cloudera 建议如果数据被多个系统消费的话，使用kafka；如果数据被设计给Hadoop使用，使用Flume。

正如你们所知Flume内置很多的source和sink组件。然而，Kafka明显有一个更小的生产消费者生态系统，并且Kafka的社区支持不好。希望将来这种情况会得到改善，但是目前：使用Kafka意味着你准备好了编写你自己的生产者和消费者代码。如果已经存在的Flume Sources和Sinks满足你的需求，并且你更喜欢不需要任何开发的系统，请使用Flume。

Flume可以使用拦截器实时处理数据。这些对数据屏蔽或者过量是很有用的。Kafka需要外部的流处理系统才能做到。

Kafka和Flume都是可靠的系统,通过适当的配置能保证零数据丢失。然而，Flume不支持副本事件。于是，如果Flume代理的一个节点崩溃了，即使使用了可靠的文件管道方式，你也将丢失这些事件直到你恢复这些磁盘。如果你需要一个高可靠行的管道，那么使用Kafka是个更好的选择。

Flume和Kafka可以很好地结合起来使用。如果你的设计需要从Kafka到Hadoop的流数据，使用Flume代理并配置Kafka的Source读取数据也是可行的：你没有必要实现自己的消费者。你可以直接利用Flume与HDFS及HBase的结合的所有好处。你可以使用Cloudera Manager对消费者的监控，并且你甚至可以添加拦截器进行一些流处理。

Flume和Kafka可以结合起来使用。通常会使用Flume + Kafka的方式。其实如果为了利用Flume已有的写HDFS功能，也可以使用Kafka + Flume的方式。

2.大数据存储技术

2.1分布式文件存储系统

（1）HDFS p34 见上一篇
（2）分布式内存文件存储Tachyon p37
Tachyon是一个以内存为核心的开源分布式存储系统，也是目前发展最迅速的开源大数据项目之一。Tachyon为不同的大数据计算框架（如Apache Spark，Hadoop MapReduce, Apache Flink等）提供可靠的内存级的数据共享服务。此外，Tachyon还能够整合众多现有的存储系统（如Amazon S3, Apache HDFS, RedHat GlusterFS, OpenStack Swift等），为用户提供统一的、易用的、高效的数据访问平台。
2.2数据库与数据仓库
HBase p38
数据仓库架构Hive p41

3.分布式计算框架

3.1离线计算框架

（1）MapReduce p43
（2）YARN(MPv2) p45
（3）Spark p46
大数据Big Data处理框架
　　Spark是一个针对超大数据集合的低延迟的集群分布式计算系统，比MapReducer快40倍左右。
　　Spark是hadoop的升级版本，Hadoop作为第一代产品使用HDFS，第二代加入了Cache来保存中间计算结果，并能适时主动推Map/Reduce任务，第三代就是Spark倡导的流Streaming。
　　Spark兼容Hadoop的APi，能够读写Hadoop的HDFS HBASE 顺序文件等。
　　传统Hadoop如下图性能慢原因有：磁盘IO 复制和序列化等等，涉及图中的HDFS
spark原理
而在Spark中，使用内存替代了使用HDFS存储中间结果：

Spark架构图
在这里插入图片描述
（4）Flink p48
Flink是新的stream计算引擎，用java实现。既可以处理stream data也可以处理batch data，可以同时兼顾Spark以及Spark streaming的功能，与Spark不同的是，Flink本质上只有stream的概念，batch被认为是special stream。Flink在运行中主要有三个组件组成，JobClient，JobManager 和 TaskManager。主要工作原理如下图
在这里插入图片描述

3.2实时流计算平台

（1）Storm p51
Storm实现了一个数据流(data flow)的模型，在这个模型中数据持续不断地流经一个由很多转换实体构成的网络。一个数据流的抽象叫做流(stream)，流是无限的元组(Tuple)序列。元组就像一个可以表示标准数据类型（例如int，float和byte数组）和用户自定义类型（需要额外序列化代码的）的数据结构。每个流由一个唯一的ID来标示的，这个ID可以用来构建拓扑中各个组件的数据源。

如下图所示，其中的水龙头代表了数据流的来源，一旦水龙头打开，数据就会源源不断地流经Bolt而被处理。图中有三个流，用不同的颜色来表示，每个数据流中流动的是元组(Tuple)，它承载了具体的数据。元组通过流经不同的转换实体而被处理。

Storm对数据输入的来源和输出数据的去向没有做任何限制。像Hadoop，是需要把数据放到自己的文件系统HDFS里的。在Storm里，可以使用任意来源的数据输入和任意的数据输出，只要你实现对应的代码来获取/写入这些数据就可以。典型场景下，输入/输出数据来是基于类似Kafka或者ActiveMQ这样的消息队列，但是数据库，文件系统或者web服务也都是可以的。
在这里插入图片描述

（2）Spark Streaming p54
Spark Streaming是建立在Spark上的实时计算框架，通过它提供丰富的API、基于内存的高速执行引擎，用户可以结合流式、批处理和交互试查询应用。

Spark Streaming的基本原理是将输入数据流以时间片（秒级）为单位进行拆分，然后以类似批处理的方式处理每个时间片数据，其基本原理如下图所示。

在这里插入图片描述

图10 Spark Streaming基本原理图

首先，Spark Streaming把实时输入数据流以时间片Δt （如1秒）为单位切分成块。Spark Streaming会把每块数据作为一个RDD，并使用RDD操作处理每一小块数据。每个块都会生成一个Spark Job处理，最终结果也返回多块。

使用Spark Streaming编写的程序与编写Spark程序非常相似，在Spark程序中，主要通过操作RDD（Resilient Distributed Datasets弹性分布式数据集）提供的接口，如map、reduce、filter等，实现数据的批处理。而在Spark Streaming中，则通过操作DStream（表示数据流的RDD序列）提供的接口，这些接口和RDD提供的接口类似。
在这里插入图片描述

图11 Spark Streaming程序转换为DStream Graph

在这里插入图片描述

图12 DStream Graph转换为Spark jobs

在图12中，Spark Streaming把程序中对DStream的操作转换为DStream Graph，图4中，对于每个时间片，DStream Graph都会产生一个RDD Graph；针对每个输出操作（如print、foreach等），Spark Streaming都会创建一个Spark action；对于每个Spark action，Spark Streaming都会产生一个相应的Spark job，并交给JobManager。JobManager中维护着一个Jobs队列, Spark job存储在这个队列中，JobManager把Spark job提交给Spark Scheduler，Spark Scheduler负责调度Task到相应的Spark Executor上执行。

在这里插入图片描述

图13

Spark Streaming的另一大优势在于其容错性，RDD会记住创建自己的操作，每一批输入数据都会在内存中备份，如果由于某个结点故障导致该结点上的数据丢失，这时可以通过备份的数据在其它结点上重算得到最终的结果。

4.数据分析平台与工具

p57

结合网络资料中将大数据平台按其职能分为五个模块：
运行环境层：

运行环境层为基础设施层提供运行时环境，它由2部分构成，即操作系统和运行时环境。

(1)操作系统我们推荐安装REHL5.0以上版本(64位)。此外为了提高磁盘的IO吞吐量，避免安装RAID驱动，而是将分布式文件系统的数据目录分布在不同的磁盘分区上，以此提高磁盘的IO性能。

(2)运行时环境的具体要求如下表：

</tbody>

名称	版本	说明
JDK	1.7或以上版本	Hadoop需要Java运行时环境，必须安装JDK。
gcc/g++	3.x或以上版本	当使用Hadoop Pipes运行MapReduce任务时，需要gcc编译器，可选。
python	2.x或以上版本	当使用Hadoop Streaming运行MapReduce任务时，需要python运行时，可选。

基础设施层：

基础设施层由2部分组成：Zookeeper集群和Hadoop集群。它为基础平台层提供基础设施服务，比如命名服务、分布式文件系统、MapReduce等。

(1)ZooKeeper集群用于命名映射，做为Hadoop集群的命名服务器，基础平台层的任务调度控制台可以通过命名服务器访问Hadoop集群中的NameNode，同时具备failover的功能。

(2)Hadoop集群是大数据平台的核心，是基础平台层的基础设施。它提供了HDFS、MapReduce、JobTracker和TaskTracker等服务。目前我们采用双主节点模式，以此避免Hadoop集群的单点故障问题。

基础平台层：

基础平台层由3个部分组成：任务调度控制台、HBase和Hive。它为用户网关层提供基础服务调用接口。

(1)任务调度控制台是MapReduce任务的调度中心，分配各种任务执行的顺序和优先级。用户通过调度控制台提交作业任务，并通过用户网关层的Hadoop客户端返回其任务执行的结果。其具体执行步骤如下：

任务调度控制台接收到用户提交的作业后，匹配其调度算法；
请求ZooKeeper返回可用的Hadoop集群的JobTracker节点地址；
提交MapReduce作业任务；
轮询作业任务是否完成；
如果作业完成发送消息并调用回调函数；
继续执行下一个作业任务。

作为一个完善的Hadoop集群实现，任务调度控制台尽量自己开发实现，这样灵活性和控制力会更加的强。

(2)HBase是基于Hadoop的列数据库，为用户提供基于表的数据访问服务。

(3)Hive是在Hadoop上的一个查询服务，用户通过用户网关层的Hive客户端提交类SQL的查询请求，并通过客户端的UI查看返回的查询结果，该接口可提供数据部门准即时的数据查询统计服务。

用户网关层：

用户网关层用于为终端客户提供个性化的调用接口以及用户的身份认证，是用户唯一可见的大数据平台操作入口。终端用户只有通过用户网关层提供的接口才可以与大数据平台进行交互。目前网关层提供了3个个性化调用接口：

(1)Hadoop客户端是用户提交MapReduce作业的入口，并可从其UI界面查看返回的处理结果。

(2)Hive客户端是用户提交HQL查询服务的入口，并可从其UI界面查看查询结果。

(3)Sqoop是关系型数据库与HBase或Hive交互数据的接口。可以将关系型数据库中的数据按照要求导入到HBase或Hive中，以提供用户可通过HQL进行查询。同时HBase或Hive或HDFS也可以将数据导回到关系型数据库中，以便其他的分析系统进行进一步的数据分析。

用户网关层可以根据实际的需求无限的扩展，以满足不同用户的需求。

客户应用层：

客户应用层是各种不同的终端应用程序，可以包括：各种关系型数据库，报表，交易行为分析，对账单，清结算等。

参考资料：
https://blog.csdn.net/ancony_/article/details/80012908
https://blog.csdn.net/lilychen1983/article/details/80241368
https://blog.csdn.net/wyqwilliam/article/details/81916682
https://blog.csdn.net/gyshun/article/details/79710534
https://blog.csdn.net/sxiaobei/article/details/80861070
https://www.cnblogs.com/shenh062326/p/3996545.html
https://blog.csdn.net/qq_25948717/article/details/80302854

席八

关注

1
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
大数据复习笔记之hadoop浅析（二）

Hadoop的组成Hadoop的核心组件p21核心组件分析：Hadoop的核心组件分为：HDFS（分布式文件系统）、MapRuduce（分布式运算编程框架）、YARN（运算资源调度系统）Hadoop业务的整体开发流程：下面按《Hadoop大数据实战权威指南》中顺序介绍1.数据采集1.1结构化数据采集工具sqoopp241 Sqoop概述传统的应用程序管理系统，即应用程序与...
复制链接

扫一扫

专栏目录