大数据复习总结

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接: https://blog.csdn.net/qq_39699765/article/details/90903332

大数据复习总结


复习的内容较多,然而实际上简答题只占20分,因此重在理解,实验的内容是最为重要的,实验一二三占到了40分,一定要看!!

第一章 大数据概述

a.大数据的基本概念

大数据是指其大小超出了常规数据库工具获取、储存、管理和分析能力的数据集。
大数据的特点 4V+1C
Volume(数据量大)、Velocity(处理速度快)、Variety(数据类型繁多)、Value(有价值但密度低)
Complexity(复杂性) 处理和分析的难度非常大

b.云计算、大数据、物联网之间关系

1.云计算为大数据提供了数据基础,大数据为云计算提供用武之地
2.云计算为物联网提供海量数据存储能力,物联网为云计算技术提供了广阔的应用空间
3.物联网是大数据的重要来源,大数据技术为物联网数据分析提供支撑
在这里插入图片描述

c. 大数据的几种计算模式及所能解决的问题

在这里插入图片描述

第三章 分布式文件系统HDFS

a.HDFS的相关概念

1.:HDFS以块(默认64MB)作为存储单位
①支持大规模文件存储:一个大规模文件可被分拆成若干个文件块,不同的文件块可以被分发到不同的节点上。因此,一个文件的大小不会受到单个节点的存储容量的限制。
②简化系统设计:元数据无需和文件块一起存储。
③适合数据备份:每个文件块都可冗余存储到多个节点上,大大提高了系统的容错性和可用性。
2.名称节点(NameNode):
负责管理分布式文件系统命名空间,记录每个文件中各个块所在的数据节点的位置信息。
①NameNode通过metadata管理整个文件系统,运行NameNode时,会在内存中维护整个HDFS的metadata。
②NameNode通过fsimage和edits来持久化metadata。
工作过程:
①名称节点启动时,将FsImage文件中的内容加载到内存中,再执行EditLog文件中的各项操作,使得内存中元数据与实际同步。
②一旦在内存中成功建立文件系统元数据的映射,则创建一个新的FsImage文件和一个空的EditLog文件。
③名称节点起来之后,HDFS中的更新操作会重新写到EditLog文件中,因为FsImage文件一般都很大(GB级别很常见)。
④如所有的更新操作都往FsImage文件中添加,会导致系统运行的十分缓慢。
⑤但是,如果往EditLog文件里面写就可以避免,因为EditLog要小很多。
⑥每次执行写操作之后且在向客户端发送成功代码之前,EditLog文件都需要同步更新。
3.FsImage用于维护文件系统树以及树中所有文件和文件夹的元数据。
4.EditLog中记录所有针对文件的创建、删除、重命名等的操作日志。
5.数据节点(DataNode):
①HDFS的工作节点,负责数据的存储和读取,会根据客户端或者是名称节点的调度来进行数据的存储和检索,并向名称节点定期发送自己所存储的块的列表。
②每个数据节点中的数据会被保存在各自节点本地Linux文件系统中。
6.心跳包:
①DataNode定期向NameNode汇报的信息集合,NameNode不会主动连接DataNode。
②每次由DataNode主动发起,NameNode会根据心跳包判断此DataNode当前状态。
③NameNode发命令也是通过心跳包发出相关的存取命令。
④在心跳包的最大的时间间隔内依旧接收不到某DataNode的心跳包,NameNode会认为该DataNode失效。
7.SecondaryNameNode(第二名称节点)
①SecondaryNameNode用于保存名称节点中对HDFS元数据信息的备份,并减少名称节点重启的时间。
②SecondaryNameNode一般单独运行于一台独立的机器上。

b. HDFS的体系架构

HDFS采用了主从(Master/Slave)结构模型。(理解教材P48-49页第一、二自然段及前面一题的NameNode、DataNode、心跳包相关概念进行作答)
在这里插入图片描述

c. 第二名称节点工作过程

①SecondaryNameNode会定期和NameNode通信,请求其停止使用EditLog文件,暂时将新的写操作写到一个新的文件edit.new上来,该操作是瞬间完成的。
②SecondaryNameNode通过HTTP GET方式从NameNode上获取到FsImage和EditLog文件,并下载到本地的相应目录下。
③SecondaryNameNode将下载的FsImage载入到内存,然后一条一条地执行EditLog文件中的各项更新操作,使得内存中的FsImage保持最新。这个过程就是EditLog和FsImage的文件合并。
④SecondaryNameNode执行完合并操作之后,会通过post方式将新的FsImage文件发送到NameNode节点上。
⑤NameNode将从SecondaryNameNode接收到的新的FsImage替换旧的FsImage,同时将edit.new替换EditLog文件,通过这个过程EditLog就变小了。

d. HDFS副本放置的策略

第一个副本:放置在上传文件的数据节点;如果是集群外提交,则随机挑选一台磁盘不太满、CPU不太忙的节点
第二个副本:放置在与第一个副本不同的机架节点上
第三个副本:与第一个副本相同机架的其他节点上
更多副本:随机节点

e. HDFS常用的shell命令的含义

http://hadoop.apache.org/docs/r1.0.4/cn/hdfs_shell.html#rm

第四章 分布式数据库HBase

a. Hbase的基本概念

Hbase是一个高可靠、高性能、面向列、可伸缩的分布式数据库;是BigTable的开源实现,主要用来存储非结构化和半结构化的数据。

b. HBase中Region定位的三层结构

在这里插入图片描述

c. HBase的体系架构包含哪些组成部分,每一部分分别完成的功能

(1)客户端:包含访问HBase的接口,同时在缓存中维护着已访问过的Region位置信息,以加快后续数据访问过程。
(2)** Zookeeper服务器**
①Zookeeper是一个很好的集群管理工具,被大量用于分布式计算,提供配置维护、域名服务、分布式同步、组服务等。
②Zookeeper可以帮助选举出一个Master作为集群的总管,并保证在任何时刻总有唯一一个Master在运行,这就避免了Master的“单点失效”问题。
③Master通过Zookeeper随时感知各个Region服务器的工作状态。
④每个Region服务器都需要到Zookeeper中进行注册,Zookeeper实时监控每个Region服务器的状态并通知给Master。
⑤Zookeeper保存了-ROOT-表的地址;客户端通过访问Zookeeper获得-ROOT-表的地址,通过“三级寻址”找到所需要的数据。
(3)主服务器Master主要负责表和Region的管理工作
(4)Region服务器是Hbase中最核心的模块,负责维护分配给自己的Region,并响应用户的读写请求。

d.Region服务器工作原理

①Region服务器内部管理了一系列Region对象和一个HLog文件(存储在磁盘上,记录所有的更新操作)
②每个Region对象由多个Store组成
③每个Store对应表中的一个列族的存储
④每个Store又包含一个MemStore和多个StoreFile
⑤MemStore是内存中的缓存,保存最近更新的数据
⑥StoreFile是磁盘文件,B树结构,方便快速读取
⑦StoreFile在底层的实现方式是HDFS文件系统的HFile(HFile数据块采用压缩方式存储)
1.写数据
(1)用户写入数据时,被分配到相应Region服务器去执行
(2)用户数据首先被写入到MemStore和Hlog中
(3)只有当操作写入Hlog之后,commit()调用才会将其返回给客户端
2.读数据
当用户读取数据时,Region服务器首先访问MemStore缓存,如果找不到,再去磁盘上面的StoreFile中寻找
3.刷新缓存
(1)系统周期性把MemStore缓存里的内容刷写到磁盘的StoreFile文件中。然后,清空缓存,并在Hlog里面写入一个标记;
(2)每次刷写都生成一新的StoreFile文件。因此,每个Store包含多个StoreFile文件;
(3)每个Region服务器都有一自己的HLog文件,每次启动都检查该文件,确认最近一次执行缓存刷新操作后是否发生新写入操作;
(4)如发现更新,则先写入MemStore,再刷写到StoreFile;
(5)最后删除旧的Hlog文件,并开始为用户提供服务。
在这里插入图片描述

e. Store工作原理

①Store是Region服务器的核心
②用户写入数据时,先把数据放入MemStore缓存,缓存满时,刷写到StoreFile
③随着StoreFile文件数量的增加,多个StoreFile合并成一个
④单个StoreFile过大时,又触发分裂操作,一个父Region被分裂成两个子Region
在这里插入图片描述

f. HBase中数据定位的“四维坐标”

HBase是一个稀疏、多维度、排序的映射表,这张表的索引是行键、列族、列限定符和时间戳
HBase中根据行键、列族、列限定符和时间戳来确定一个单元格,因此可以视为一个“四维坐标”,即[行键,列族,列限定符,时间戳]
行键:每个行由行键(Row Key)来标识。
列族:一表被分组成许多列族的集合,是基本的访问控制单元。
列限定符:列族里的数据通过列限定符(或列)来定位。
时间戳:每个单元格都保存同一份数据的多个版本,该版本用时间戳进行索引。

第五章 NoSQL数据库(第二重要)

a.常见的NoSql数据库有哪些

键值数据库、列族数据库、文档数据库、图形数据库

b.NoSQL数据库的三大基石包括哪些

CAP、BASE和最终一致性
p101 大概率选择判断

c.掌握Mongodb的Shell命令,给定一个Mongodb的应用程序代码,写出给定语句的完成的功能

详见实验一
https://download.csdn.net/download/qq_39699765/11228190
在这里插入图片描述

d.键值数据库与列族数据库的异同

参考课本99页或者文章https://www.cnblogs.com/quinnsun/p/NoSQL_2.html

答题理解参考文章
https://blog.csdn.net/weixin_42636552/article/details/82778567

在这里插入图片描述

e.NoSQL数据库与关系数据库的比较

教材p97内容与表格理解一下
如果考简答题可参考之前云计算的文章
https://blog.csdn.net/qq_39699765/article/details/85885639

第七章 Mapreduce

a. MapReduce中的shuffle过程

Shuffle是指对Map输出结果进行分区、排序、合并等处理并交给Reduce的过程,因此,Shuffle过程又分为Map端的操作和Reduce端的操作
(1)Map端的Shuffle过程
①输入数据可以是文档,也可以是二进制格式的。Map任务接受<key,value>输入,映射转换为<key,value>输出
(输入数据和执行Map任务)
②Map的输出结果首先被写入缓存,当缓存满时,就启动溢写操作,把缓存中的数据写入磁盘文件,并清空缓存
(写入缓存)
③当启动溢写操作时,首先需要把缓存中的数据进行分区,然后对每个分区的数据进行排序(Sort)和合并(Combine),之后再写入磁盘文件。每次溢写操作会生成一个新的磁盘文件,随着Map任务的执行,磁盘中就会生成多个溢写文件
(溢写(分区、排序和合并))
④在Map任务全部结束之前,这些溢写文件会被归并(Merge)成一个大的磁盘文件,然后通知相应的Reduce任务来领取属于自己处理的数据
(文件归并)
(2)Reduce端的Shuffle过程
Reduce任务从Map端的不同Map机器领回属于自己处理的那部分数据,然后对数据进行归并(Merge)后交给Reduce处理
①“领取”数据
②归并数据
③把数据输入给Reduce任务

b. MapReduce执行过程包括哪些

(1)MapReduce框架使用InputFormat模块做Map前的预处理,比如验证输入的格式是否符合输入定义;然后,将输入文件切分为逻辑上的多个InputSplit(逻辑概念,并没有实际切割)
(2)RecorderReader(RR)处理InputSplit中的具体记录,加载数据并转换为合适的键值对,输入给Map任务
(3)Map任务根据用户自定义映射规则,输出一系列的<key,value>作为中间结果
(4)Shuffle(洗牌),通过排序(Sort)、合并(Combine)、归并(Merge)等操作,将无序的<key,value>转换为有序的<key,value-list>
(5)Reduce以一系列<key,value-list>中间结果作为输入,执行用户定义的逻辑,输出结果给OutputFormat模块
(6)OutputFormat模块会验证输出目录是否已经存在以及输出类型结果类型是否符合配置文件中的配置类型,如果都满足,就输出Reduce的结果到分布式文件系统
在这里插入图片描述

第八章 Yarn

a.Yarn的体系架构
在这里插入图片描述

b.Yarn的工作流程

在这里插入图片描述

c.Yarn发展的目标

一个集群多个框架,即在一个集群上部署一个统一的资源管理框架YARN,在YARN之上可以部署其他各种计算框架,比如Mapreduce、Tez、HBase、Storm、Giraph、Spark、OpenMPI等

d.Yarn的设计思路以及所包含的各组件的功能

将原JobTracker三大功能进行了拆分,分别交给不同的新组件去处理
由ResourceManager负责资源管理,由ApplicationMaster负责任务调度和监控,由NodeManager负责执行原TaskTracker任务
通过这种“放权”的设计,大大降低了JobTracker的负担,提升了系统运行的效率和稳定性

组件 功能
ResourceManager
  • 处理客户端请求
  • 启动/监控ApplicationMaster
  • 监控NodeManager
  • 资源分配与调度
ApplicationMaster
  • 为应用程序申请资源,并分配给内部任务
  • 任务调度、监控与容错
NodeManager
  • 单个节点上的资源管理
  • 处理来自ResourceManager的命令
  • 处理来自ApplicationMaster的命令

第九章 Spark(重点)

a.Spark上课讲的全部是重点

b.最后两个编程题,要求完成一个功能,用Spark编程实现。语言不限**

参考实验二与实验三

实验二:https://download.csdn.net/download/qq_39699765/11228194
实验三:https://download.csdn.net/download/qq_39699765/11228199

c.Spark生态系统的各组件及其功能

1.Spark Core:Spark的基本功能,如内存计算、任务调度、部署模式、故障修复、存储管理等。
2.Spark SQL:允许开发人员直接处理RDD,同时也可查询Hive、HBase等外部数据源。
3.Spark Streaming支持高吞吐量、可容错处理的实时流数据处理,核心思路是将流数据分解成一系列短小的批处理作业。
4.MLlib提供了机器学习算法的实现
5.GraphX是Spark中用于图计算的API

d.Spark的运行的流程

1.首先为应用构建起基本的运行环境,即由Driver创建一个SparkContext,进行资源的申请、任务的分配和监控。
在这里插入图片描述
2.资源管理器为Executor分配资源,并启动Executor进程。
3.SparkContext根据RDD的依赖关系构建DAG图,DAG图提交给DAGScheduler解析成Stage(TaskSet),把一个个TaskSet提交给底层调度器TaskScheduler处理,Executor向SparkContext申请Task,TaskScheduler将Task发放给Executor运行,并提供应用程序代码
4.Task在Executor上运行,把执行结果反馈给TaskScheduler,然后反馈给DAGScheduler,运行完毕后写入数据并释放所有资源

e.RDD特性

RDD是Resillient Distributed Dataset(弹性分布式数据集)的简称,是分布式内存的一个抽象概念,提供了一种高度受限的共享内存模型
1.高效的容错性。RDD的设计中,数据只读,不可修改,如果需要修改数据,必须从父RDD转换到子RDD,由此在不同RDD之间建立了血缘关系,因此不需要通过数据冗余实现容错,而只需通过RDD父子依赖(血缘)关系重新计算得到丢失的分区来实现容错;RDD提供的转换操作都是一些粗粒度的操作,RDD依赖关系只需要记录这种粗粒度的转换操作,而不需要记录具体的数据和各种细粒度操作的日志
2.中间结果持久化到内存。数据在内存中的多个RDD操作之间传递,不需要“落地”到磁盘上,避免了不必要的对象序列化和反序列化开销
3.存放的数据可以是Java对象,避免了不必要的对象序列化和反序列化开销。

f.RDD依赖关系

RDD中的依赖关系分为窄依赖与宽依赖。
1.如果父RDD的一个分区只能被一个子RDD的一个分区使用就是窄依赖,否则就是宽依赖
2.从计算过程来看,窄依赖是数据以管道方式经一系列计算操作可以运行在了一个集群节点上;宽依赖则可能需要将数据通过跨节点传递后运行(如groupByKey),有点类似于MR的shuffle过程
3.从失败恢复来看,窄依赖的失败恢复起来更高效,因为它只需找到父RDD的一个对应分区即可,而且可以在不同节点上并行计算做恢复;宽依赖则牵涉到父RDD的多个分区,恢复起来相对复杂些

g.RDD操作的惰性机制

即在RDD的执行过程中,真正的计算发生在RDD的“行动”操作,对于“行动”之前的所有“转换”操作,Spark只是记录下“转换”操作应用的一些基础数据集以及RDD生成的轨迹,即相互之间的依赖关系,而不会触发真正的计算

h.Spark运行的架构

在这里插入图片描述
教材P177

i.Spark与MapReduce相比较而言,Spark的优势

1.利用多线程来执行具体的任务,减少任务的启动开销;
2.Executor中有一个BlockManager存储模块,会将内存和磁盘共同作为存储设备,有效减少IO开销

第十章 流计算

a.Storm中相关术语,Streams, Spouts, Bolts, Topology

Storm:
一个免费的、开源的分布式实时计算系统;
Storm可以简单、高效、可靠地处理流数据,并支持多种编程语言;
可用于许多领域,如实时分析、在线机器学习、持续计算、远程RPC、数据提取加载转换等;
Storm框架可方便地与数据库系统进行整合,从而开发出强大的实时计算系统。
Tuple(元组):
Tuple实质上是一个<key,value>形式的Map型数据结构;
在Storm中Tuple专业表述为<Fields,Values>是Storm中消息传递的基本单元。其中Fileds和Value两个字段本身可以是任意复杂的数据结构,必须满足可序列化这一基本条件。
Streams:
(1)Stream是Storm的实时处理功能的核心抽象体,是一个无限的Tuple序列,源源不断的Tuple组成了Stream。Stream有源头和处理流的水坝,Storm源和水坝分别为Spout和Bolt
(2)Spout是流的源头,通常从外部数据源读取数据并转化为Tuple。然后转发到各个Bolt中
(3)Bolt是流处理节点,处理流向本Bolt的所有Tuple,常见处理包括过滤、join、连接数据库
(4)顶点与顶点之间的数据流为Stream,数据源为Spout,流处理节点为Bolt,称由Spout、Stream、Bolt构成图为Topology
(5)Spout可以将Tuple发射到一个或者多个Bolt,同样Bolt可以订阅一个或多个Spout。
Bolt能订阅一个或多个上层的Bolt,即Topology可以有多个Spout和多层Bolt。
在这里插入图片描述
Spout:
Spout表示整个Topology的Stream来源(HDFS、Hbase、JDBC等),Storm框架会不停的调用Spout里的nextTuple()来实时读取输入源中的数据,除非手动停止Topology,否则永不停止。
在这里插入图片描述
Bolts:
(1)Storm将Streams的状态转换过程抽象为Bolt。Bolt即可以处理Tuple,也可以将处理后的Tuple作为新的Streams发送给其他Bolt;
(2)Bolt可以执行过滤、函数操作、Join、操作数据库等任何操作;
(3)Bolt是一个被动的角色,其接口中有一个execute(Tuple input)方法,在接收到消息之后会调用此函数,用户可在此方法中执行自己的处理逻辑
在这里插入图片描述
Topology:
(1)Topology由Spout、Bolt、Stream构成的DAG图。是Storm中运行的一个实际应用程序,类似于MapReduce程序,MapReduce作业有个时间期限,而一旦提交一个Topology,除非手动将其停止,否则这个Topology永远执行。
(2)Topology里面的每一个组件都是并行运行的。

b.Stream Groupings

(1)用于告知Topology如何在两个组件间(如Spout和Bolt之间,或者不同的Bolt之间)进行Tuple的传送。
(2)每一个Spout和Bolt都可有多个分布式任务,一个任务在什么时候、以什么方式发送Tuple是由Storm Groupings来决定的。

目前主要有以下六种方式:
ShuffleGrouping:随机分组
FieldsGrouping:按照字段分组
AllGrouping:广播发送
GlobalGrouping:全局分组
NonGrouping:不分组
DirectGrouping:直接分组

c.Storm的工作流程

在这里插入图片描述
详见PPT https://download.csdn.net/download/qq_39699765/11228177

d.Storm的框架(与hadoop类比去理解)

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

第十一章 图计算

a. 给一个实例,如何用Pregel计算来完成**

参考PPT,弄懂过程即可(因为题型没有计算题)
https://download.csdn.net/download/qq_39699765/11228177

猜你喜欢

转载自blog.csdn.net/qq_39699765/article/details/90903332
今日推荐