大数据技术原理与应用(更新至第九章)

概要介绍

        大数据期末整理,岩哥牛逼
往期文章
数据可视化思维导图

网页设计整理归纳
补充!!!!
补充!!!!
姜启源《数学模型》 司守奎《数学建模算法与应用电子书》美赛o奖论文私信 留言获取

文章目录

第一章

1. 大数据的4个v

  • volume 大量的
  • velocity 快速的
  • variety 多样的
  • value 价值化

2. 大数据的影响

在思维方式方面:大数据完全颠覆了传统的思维方式:全样而非抽样、效率而非精确、相关而非因果
在社会发展方面:大数据决策逐渐成为一种新的决策方式,大数据应用有力促进了信息技术与各行业的深度融合,大数据开发大大推动了新技术和新应用的不断涌现。
在就业市场方面:大数据的兴起使得数据科学家成为热门职业。
在人才培养方面:大数据的兴起,将在很大程度上改变中国高校信息技术相关专业的现有教学和科研体制。

3. 大数据的两大核心技术及对应关系

  • 分布式存储(GFS HDFS NOSQL NewSQL)
  • 分布式处理(MapReduce Sparlk)

在这里插入图片描述

4. 产品对应关系

:批处理计算(MapReduce Sparlk). 流计算(Storm S4 Flume Streams Puma Mario 银河流数据处理平台等) 图计算(Pregel、GraphX、Giraph、PowerGraph、Hama、GoldenOrb等)

5. 三者关系

:云计算、大数据和物联网代表了IT领域最新的技术发展趋势,三者相辅相成,既有联系又有区别
在这里插入图片描述

第二章

1. hadoop最初是创始人Doug Cutting 开发的文本搜索库,hadoop源自于2002年的Apache Nutch项目

2. hadoop分布式处理的软件框架 ,特性如下

高可靠 高效性 高可扩展性 高容错性 成本低 运行在Linux平台上,支持多种编程语言

3. Apache hadoop 版本演变 1.0-》2.0

,即增加了分布式资源调度管理框架YARN 和 HDFS HA
在这里插入图片描述

4. hadoop生态系统

在这里插入图片描述

5. hadoop项目组建功能

在这里插入图片描述

6. 配置文件 core-site.xml hdfs-site.xml 参数(属性)理解

<configuration>
    <property>
        <name>hadoop.tmp.dir</name>
        <value>file:/usr/local/hadoop/tmp</value>
        <description>Abase for other temporary directories.</description>
    </property>
    <property>
        <name>fs.defaultFS</name>
        <value>hdfs://localhost:9000</value>
    </property>
</configuration>

其中 name 标签表示配置项的名称 value 表示配置的值。
hadoop.tmp.dir表示存放临时数据的目录,即包括NameNode的数据,也包括DataNode的数据。该路径任意指定,只要实际存在该文件夹即可
name为fs.defaultFS的值,表示hdfs路径的逻辑名称

<configuration>
    <property>
        <name>dfs.replication</name>
        <value>1</value>
    </property>
    <property>
        <name>dfs.namenode.name.dir</name>
        <value>file:/usr/local/hadoop/tmp/dfs/name</value>
    </property>
    <property>
        <name>dfs.datanode.data.dir</name>
       <value>file:/usr/local/hadoop/tmp/dfs/data</value>
</property></configuration>

dfs.replication表示副本的数量,伪分布式要设置为1
dfs.namenode.name.dir表示本地磁盘目录,是存储fsimage文件的地方
dfs.datanode.data.dir表示本地磁盘目录,HDFS数据存放block的地方

第三章

1. 总而言之 HDFS实现以下目标

 - 兼容廉价的硬件设备
 - 流数据读写
 - 大数据集
 - 简单的文件模型
 - 强大的跨平台兼容性

2. HDFS特殊的设置,使得本身具有一些应用局限性

1. 不适合低延迟的数据访问

2. 无法高效存储大量小文件

3. 不支持多用户写入及任意修改文件

3.块的概念

HDFS默认一个块64MB,一个文件被分成多个块,以块作为存储单位,块的大小远远小于普通文件系统,可以最小化寻址开销

4. HDFS主要组件的功能 (名称节点 数据节点)(课本更详细)

名称节点

  • 负责管理分布式文件系统的命名空间,保存了两个核心的数据结构,即FsImage 和 EditLog
  • 记录了每个文件中各个块所在的数据节点和位置信息
  • 存储元数据
  • 元数据保存在内存中
  • 保存文件block,datanode之间的映射关系
  • 管理客户端对文件的访问

数据节点:

  • 数据节点是分布式文件系统HDFS的工作节点,负责数据的存储和读取,会根据客户端或者名称节点的调度来惊醒数据的存储和检索,并且向名称节点定期发送自己所存储的块的列表
  • 存储文本内容
  • 文件内容保存在磁盘
  • 维护了block id 到 datanode本地文件的映射关系
    在这里插入图片描述
    在这里插入图片描述

在这里插入图片描述

5. 名称节点的数据结构

名称节点负责管理分布式文件系统的命名空间,保存了两个核心的数据结构,即FsImage EditLog并且名称节点记录了每个文件中各个块所在的数据节点的位置信息。

  1. FsImage用于维护文件系统树以及文件树中所有的文件和文件夹的元数据

  2. 操作日志文件EditLog中记录了所有针对文件的创建、删除、重命名等操作
    在这里插入图片描述

6. 第二名称节点:

第二名称节点是HDFS架构中的一个组成部分,它是用来保存名称节点中对HDFS元数据信息的备份,并减少名称节点重启的时间。SecondaryNameNode一般是单独运行在一台机器上。
补充
(所有更新操作写入Editlog,导致过大,每次名称节点重启的时候把Fsimage里面所有内容映射到内存,再一条一条执行EditLog中的记录会非常的慢当Editlog文件非常大)(引出第二名称节点)

7. 第二名称节点的工作流程(个人概括)

  • 第二名称节点定期要求名称节点停止使用editlog文件
  • 将新的写操作写在edit.new
  • 第二名称节点通过get方式获取FsImage和Editlog
  • FsImage加载内存,Editlog执行文件中的更新操作,合并为新的FsImage
  • 新的FsImage通过post发送到名称节点替换旧的,而edit.new替换为新的Editlog

在这里插入图片描述

8. HDFS体系机构概述

修改时间:2021/1/10 第一点

  1. client 向名称节点发送文件写入请求,名称节点根据文件的大小和文件块的配置情况,返回给client它所管理的datanode的信息,client将文件划分成多个block,根据数据节点的信息,按照顺序写入到每一个数据节点块中。
  2. HDFS采用的是主从(Master/Slave)结构模型,一个HDFS集群包括一个名称节点和若干个数据节点
  3. 数据节点的数据保存在本地Linux文件系统中
  4. 数据节点会周期性向名称节点发送“心跳信息”

在这里插入图片描述

9. HDFS通信协议

概述:

  • HDFS是一个部署在集群上的分布式文件系统,因此很多数据需要通过网络进行传输
  • 所有的HDFS通信协议都是构建在TCP/IP协议基础之上的

在这里插入图片描述

10. 多副本方式冗余数据的保存

目的:为了保证系统的容错性和可用性
优点:加快数据传输速度

  • 加快数据传输速度

  • 容易检查数据错误

  • 保证数据可靠性
    什么是多副本:通常一个数据块的多个副本会被分布到不同的数据节点
    在这里插入图片描述

11. 数据存储策略(重点)

  • 第一个副本:放置在上传文件的数据节点;如果是集群外提交,则随机挑选一台磁盘不太满、CPU不太忙的节点

  • 第二个副本:放置在与第一个副本不同的机架的节点上

  • 第三个副本:与第一个副本相同机架的其他节点上

  • 更多副本:随机节点
    在这里插入图片描述

12. 数据错误与恢复(名称节点出错 数据节点出错 数据出错)(了解)

名称节点出错
    
名称节点保存了所有的元数据信息,其中,最核心的两大数据结构是FsImage和Editlog,如果这两个文件发生损坏,那么整个HDFS实例将失效。因此,HDFS设置了备份机制,把这些核心文件同步复制到备份服务器SecondaryNameNode上。当名称节点出错时,就可以根据备份服务器SecondaryNameNode中的FsImage和Editlog数据进行恢复。

数据节点出错
    

  • 每个数据节点会定期向名称节点发送“心跳”信息,向名称节点报告自己的状态
  • 当数据节点发生故障,或者网络发生断网时,名称节点就无法收到来自一些数据节点的心跳信息,这时,这些数据节点就会被标记为“宕机”,节点上面的所有数据都会被标记为“不可读”,名称节点不会再给它们发送任何I/O请求
  • 这时,有可能出现一种情形,即由于一些数据节点的不可用,会导致一些数据块的副本数量小于冗余因子
  • 名称节点会定期检查这种情况,一旦发现某个数据块的副本数量小于冗余因子,就会启动数据冗余复制,为它生成新的副本
  • HDFS和其它分布式文件系统的最大区别就是可以调整冗余数据的位置

数据错误
    

  • 网络传输和磁盘错误等因素,都会造成数据错误
  • 客户端在读取到数据后,会采用md5和sha1对数据块进行校验,以确定读取到正确的数据
  • 在文件被创建时,客户端就会对每一个文件块进行信息摘录,并把这些信息写入到同一个路径的隐藏文件里面
  • 当客户端读取文件的时候,会先读取该信息文件,然后,利用该信息文件对每个读取的数据块进行校验,如果校验出错,客户端就会请求到另外一个数据节点读取该文件块,并且向名称节点报告这个文件块有错误,名称节点会定期检查并且重新复制这个块

13. HDFS数据读写操作(背)(待补充)

HDFS有很多命令,其中fs命令可以说是HDFS最常用的命令,利用fs命令可以查看HDFS文件系统的目录结构、上传和下载数据、创建文件信息等。该命令的用法如下
hadoop fs [genericOptions] [commandOptions]
hadoop fs -ls :显示指定的文件的详细信息

第四章

1. 从BigTable说起

  • BigTable是一个分布式存储系统
  • BigTable起初是用于解决典型的互联网搜索问题

2. HBase 和BigTable的底层技术对应关系

在这里插入图片描述

3. HBase与传统关系数据库的对比分析

HBase与传统的关系数据库的区别主要体现在以下几个方面:

  • 数据类型:关系数据库采用关系模型,具有丰富的数据类型和存储方式,HBase则采用了更加简单的数据模型,它把数据存储为未经解释的字符串
  • 数据操作:关系数据库中包含了丰富的操作,其中会涉及复杂的多表连接。HBase操作则不存在复杂的表与表之间的关系,只有简单的插入、查询、删除、清空等,因为HBase在设计上就避免了复杂的表和表之间的关系
  • 存储模式:关系数据库是基于行模式存储的。HBase是基于列存储的,每个列族都由几个文件保存,不同列族的文件是分离的
  • 数据索引:关系数据库通常可以针对不同列构建复杂的多个索引,以提高数据访问性能。HBase只有一个索引——行键,通过巧妙的设计,HBase中的所有访问方法,或者通过行键访问,或者通过行键扫描,从而使得整个系统不会慢下来
  • 数据维护:在关系数据库中,更新操作会用最新的当前值去替换记录中原来的旧值,旧值被覆盖后就不会存在。而在HBase中执行更新操作时,并不会删除数据旧的版本,而是生成一个新的版本,旧有的版本仍然保留
  • 可伸缩性:关系数据库很难实现横向扩展,纵向扩展的空间也比较有限。相反,HBase和BigTable这些分布式数据库就是为了实现灵活的水平扩展而开发的,能够轻易地通过在集群中增加或者减少硬件数量来实现性能的伸缩

4. HBase数据模型概述

概述:HBase是一个稀疏、多维度、排序的映射表,这张表的索引是行键、列族、列限定符和时间戳
:HBase采用表来组织数据,表由行和列组成,列划分为若干个列族
:每个HBase表都由若干行组成,每个行由行键(row key)来标识。
列族:一个HBase表被分组成许多“列族”(Column Family)的集合,它是基本的访问控制单元
列限定符:列族里的数据通过列限定符(或列)来定位
单元格:在HBase表中,通过行、列族和列限定符确定一个“单元格”(cell),单元格中存储的数据没有数据类型,总被视为字节数组byte[]
时间戳:每个单元格都保存着同一份数据的多个版本,这些版本采用时间戳进行索引
在这里插入图片描述
补充 :HBase数据的物理视图—按列族进行物理存储
在这里插入图片描述

5. HBase功能组件及各组件功能(注意区别HDFS)

  • 库函数:链接到每个客户端
  • 一个Master主服务器
  • 许多个Region服务器

Master:主服务器Master负责管理和维护HBase表的分区信息,维护Region服务器列表,分配Region,负载均衡
Region:Region服务器负责存储和维护分配给自己的Region,处理来自客户端的读写请求

6. HBase的三层结构(名称+各自作用)

什么是region:表示一个分区,包含了位于某个值域区间内的所有数据,它是负载均衡和数据分发的基本单位,初始时候,一个表只有一个Region,随着数据插入,持续变多

  • 元数据表,又名.META.表,存储了Region和Region服务器的映射关系
  • 当HBase表很大时, .META.表也会被分裂成多个Region
  • 根数据表,又名-ROOT-表,记录所有元数据的具体位置
  • -ROOT-表只有唯一一个Region,名字是在程序中被写死的
  • Zookeeper文件记录了-ROOT-表的位置

在这里插入图片描述

在这里插入图片描述

7. Region服务器工作原理(理解)

在这里插入图片描述

  • 用户读写数据过程:①用户写入数据时,被分配到相应Region服务器去执行②用户数据首先被写入到MemStore和Hlog中③只有当操作写入Hlog之后,commit()调用才会将其返回给客户端④当用户读取数据时,Region服务器会首先访问MemStore缓存,如果找不到,再去磁盘上面的StoreFile中寻找
  • 缓存的刷新:①系统会周期性地把MemStore缓存里的内容刷写到磁盘的StoreFile文件中,清空缓存,并在Hlog里面写入一个标记
    ②每次刷写都生成一个新的StoreFile文件,因此,每个Store包含多个StoreFile文件
    ③每个Region服务器都有一个自己的HLog 文件,每次启动都检查该文件,确认最近一次执行缓存刷新操作之后是否发生新的写入操作;如果发现更新,则先写入MemStore,再刷写到StoreFile,最后删除旧的Hlog文件,开始为用户提供服务
  • StoreFile的合并:①每次刷写都生成一个新的StoreFile,数量太多,影响查找速度
    ②调用Store.compact()把多个合并成一个
    ③合并操作比较耗费资源,只有数量达到一个阈值才启动合并

8 .HLog工作原理

  • 分布式环境必须要考虑系统出错。HBase采用HLog保证系统恢复
  • HBase系统为每个Region服务器配置了一个HLog文件,它是一种预写式日志(Write Ahead Log)
  • 用户更新数据必须首先写入日志后才能写入MemStore缓存,并且,直到MemStore缓存内容对应的日志已经写入磁盘,该缓存内容才能被刷写到磁盘
  • Zookeeper会实时监测每个Region服务器的状态,当某个Region服务器发生故障时,Zookeeper会通知Master
  • Master首先会处理该故障Region服务器上面遗留的HLog文件,这个遗留的HLog文件中包含了来自多个Region对象的日志记录
  • 系统会根据每条日志记录所属的Region对象对HLog数据进行拆分,分别放到相应Region对象的目录下,然后,再将失效的Region重新分配到可用的Region服务器中,并把与该Region对象相关的HLog日志记录也发送给相应的Region服务器
  • Region服务器领取到分配给自己的Region对象以及与之相关的HLog日志记录以后,会重新做一遍日志记录中的各种操作,把日志记录中的数据写入到MemStore缓存中,然后,刷新到磁盘的StoreFile文件中,完成数据恢复
  • 共用日志优点:提高对表的写操作性能;缺点:恢复时需要分拆日志

9 .HBase实际应用中的性能优化方法

  • 行键(Row Key):行键是按照字典序存储,因此,设计行键时,要充分利用这个排序特点,将经常一起读取的数据存储到一块,将最近可能会被访问的数据放在一块。
    举个例子:如果最近写入HBase表中的数据是最可能被访问的,可以考虑将时间戳作为行键的一部分,由于是字典序排序,所以可以使用Long.MAX_VALUE - timestamp作为行键,这样能保证新写入的数据在读取时可以被快速命中。
  • InMemory: 创建表的时候,可以通过HColumnDescriptor.setInMemory(true)将表放到Region服务器的缓存中,保证在读取的时候被cache命中。
  • Max Version: 创建表的时候,可以通过HColumnDescriptor.setMaxVersions(int maxVersions)设置表中数据的最大版本,如果只需要保存最新版本的数据,那么可以设置setMaxVersions(1)。
  • Time To Live: 创建表的时候,可以通过HColumnDescriptor.setTimeToLive(int timeToLive)设置表中数据的存储生命期,过期数据将自动被删除,例如如果只需要存储最近两天的数据,那么可以设置setTimeToLive(2 * 24 * 60 * 60)。

10 . HBase常用Shell命令

  1. 查看命令的使用描述

语法:help ‘命令名’

  1. 返回hbase版本信息

语法:version

  1. 列出hbase中存在的所有表

语法:list

  1. 创建表

语法:create ‘表名’, ‘列族名1’, ‘列族名2’, ‘列族名N’

  1. 添加或修改的表的值(列名=列限定符 注意:)

put ‘表名’, ‘行键’, ‘列族名:列名’, ‘列值’

  1. 通过对表的扫描来获取对用的值

语法:
1 scan ‘表名’
2 扫描某个列族: scan ‘表名’, {COLUMN=>‘列族名’}
3 扫描某个列族的某个列: scan ‘表名’, {COLUMN=>‘列族名:列名’}
4 查询同一个列族的多个列: scan ‘表名’, {COLUMNS => [ ‘列族名1:列名1’, ‘列族名1:列名2’, …]}

  1. 获取行或单元(cell)的值

语法:
get ‘表名’, ‘行键’
get ‘表名’, ‘行键’, ‘列族名’

  1. 使表有效(使表无效)

语法:
enable ‘表名’ disable ‘表名’

  1. 删除表

语法:
drop的表必须是disable的
disable ‘表名’
drop ‘表名’

第五章

1 . NoSQL简介

  • 最初表示“反SQL"运动 - > 现在表示关系和非关系式数据库各有优缺点彼此都无法相互取代

在这里插入图片描述

2 NoSQL数据库具有以下几个特点:

  • 灵活的可扩展性
  • 灵活的数据模型
  • 与云计算紧密融合

3 NoSQL兴起的原因(两个大点)

(1) 关系数据库无法满足web2.0的需求

  • 无法满足海量数据的管理需求

  • 无法满足数据高并发的需求

  • 无法满足高可扩展性和高可用性的需求
    (2)关系数据库的关键特性包括完善的事务机制和高效的查询机制,但是到了Web2.0时代两个关键特性却成了鸡肋,主要表现在以下几个方面

  • Web2.0网站系统通常不要求严格的数据库事务

  • Web2.0并不要求严格的读写实时性

  • Web2.0通常不包含大量复杂的SQL查询(去结构化,存储空间换取更好的查询性能)

4 . NoSQL与关系数据库的比较(表格简单比较)

- List item
在这里插入图片描述
在这里插入图片描述

5 . NoSQL与关系数据库的比较各自优缺点

(1)关系数据库
优势:以完善的关系代数理论作为基础,有严格的标准,支持事务ACID四性,借助索引机制可以实现高效的查询,技术成熟,有专业公司的技术支持
劣势:可扩展性较差,无法较好支持海量数据存储,数据模型过于死板、无法较好支持Web2.0应用,事务机制影响了系统的整体性能等

(2)NoSQL数据库
优势:可以支持超大规模数据存储,灵活的数据模型可以很好地支持Web2.0应用,具有强大的横向扩展能力等
劣势:缺乏数学理论基础,复杂查询性能不高,大都不能实现事务强一致性,很难实现数据完整性,技术尚不成熟,缺乏专业团队的技术支持,维护较困难等

6 .NoSQL与关系数据库的应用场景

关系数据库和NoSQL数据库各有优缺点,彼此无法取代

关系数据库应用场景: 电信、银行等领域的关键业务系统,需要保证强事务一致性
NoSQL数据库应用场景:互联网企业、传统企业的非关键业务(比如数据分析)

7 .NoSQL的四大类型

  • 文档数据库(mongoDB)
  • 图数据库(Neo4j)
  • 键值数据库(redis)
  • 列族数据库(HBase)
    在这里插入图片描述

8 . 关注四类数据库的相关产品,典型应用,优点,缺点(其它了解)

键值数据库
在这里插入图片描述
列族数据库
在这里插入图片描述
文档数据库
在这里插入图片描述
图形数据库
在这里插入图片描述

9 .CAP指的是什么,说明了什么(重点)

C(Consistency):一致性,是指任何一个读操作总是能够读到之前完成的写操作的结果,也就是在分布式环境中,多点的数据是一致的,或者说,所有节点在同一时间具有相同的数据
A:(Availability):可用性,是指快速获取数据,可以在确定的时间内返回操作结果,保证每个请求不管成功或者失败都有响应;
P(Tolerance of Network Partition):分区容忍性,是指当出现网络分区的情况时(即系统中的一部分节点无法和其他节点进行通信),分离的系统也能够正常运行,也就是说,系统中任意信息的丢失或失败不会影响系统的继续运作。

CAP理论告诉我们,一个分布式系统不可能同时满足一致性、可用性和分区容忍性这三个需求,最多只能同时满足其中两个,正所谓“鱼和熊掌不可兼得”。

在这里插入图片描述

10 .ACID的四个性质

  • 原子性
  • 一致性
  • 隔离性
  • 持久性

一个数据库事务具有ACID四性:
A(Atomicity):原子性,是指事务必须是原子工作单元,对于其数据修改,要么全都执行,要么全都不执行
C(Consistency):一致性,是指事务在完成时,必须使所有的数据都保持一致状态
I(Isolation):隔离性,是指由并发事务所做的修改必须与任何其它并发事务所做的修改隔离
D(Durability):持久性,是指事务完成之后,它对于系统的影响是永久性的,该修改即使出现致命的系统故障也将一直保持

在这里插入图片描述

11 BASE的基本含义(不确定部分)

  • 基本可用(Basically Availble)

  • 软状态(Soft-state)

  • 最终一致性(Eventual consistency)
    一致性的类型包括强一致性和弱一致性,二者的主要区别在于高并发的数据访问操作下,后续操作是否能够获取最新的数据。对于强一致性而言,当执行完一次更新操作后,后续的其他读操作就可以保证读到更新后的最新数据;反之,如果不能保证后续访问读到的都是更新后的最新数据,那么就是弱一致性。

12 .MongoDB概念解析(注意SQL->MongoDB中的对应关系)

概述:在mongodb中基本的概念是文档、集合、数据库

在这里插入图片描述

第六章

1 . 云数据库的概念

云数据库是部署和虚拟化在云计算环境中的数据库。云数据库是在云计算的大背景下发展起来的一种新兴的共享基础架构的方法,它极大地增强了数据库的存储能力,消除了人员、硬件、软件的重复配置,让软、硬件升级变得更加容易。云数据库具有高可扩展性、高可用性、采用多租形式和支持资源有效分发等特点。

2 . 云数据库的特性

  • 动态可扩展
  • 高可用性
  • 较低的使用代价
  • 易用性
  • 高性能
  • 免维护
  • 安全

3 .云数据库厂商概述,(企业->产品)对应关系

在这里插入图片描述

第七章

1 . MapReduce和传统的并行计算框架比对及其优势(要求能写出对应位置的比对)

在这里插入图片描述

2 .MapReduce模型简介(两个特点)

  • MapReduce采用“分而治之”策略,一个存储在分布式文件系统中的大规模数据集,会被切分成许多独立的分片(split),这些分片可以被多个Map任务并行处理。
  • MapReduce设计的一个理念就是“计算向数据靠拢”,而不是“数据向计算靠拢”,因为,移动数据需要大量的网络传输开销。

3 .Map和Reduce函数的含义

在这里插入图片描述

4 .MapReduce的体系框架及其各部分功能

概述: MapReduce体系结构主要由四个部分组成,分别是:Client、JobTracker、TaskTracker以及Task

在这里插入图片描述

  • Client

    • 用户编写的MapReduce程序通过Client提交到JobTracker端
    • 用户可通过Client提供的一些接口查看作业运行状态
  • JobTracker

    • JobTracker负责资源监控和作业调度
    • JobTracker 监控所有TaskTracker与Job的健康状况,一旦发现失败,就将相应的任务转移到其他节点
    • JobTracker 会跟踪任务的执行进度、资源使用量等信息,并将这些信息告诉任务调度器,而调度器会在资源出现空闲时,选择合适的任务去使用这些资源
  • TaskTracker

    • TaskTracker 会周期性地通过“心跳”将本节点上资源的使用情况和任务的运行进度汇报给JobTracker,同时接收JobTracker 发送过来的命令并执行相应的操作(如启动新任务、杀死任务等)
    • TaskTracker 使用“slot”等量划分本节点上的资源量(CPU、内存等)。一个Task 获取到一个slot 后才有机会运行,而Hadoop调度器的作用就是将各个TaskTracker上的空闲slot分配给Task使用。slot 分为Map slot 和Reduce slot 两种,分别供MapTask 和Reduce Task 使用
  • Task

    • Task 分为Map Task 和Reduce Task 两种,均由TaskTracker 启动

5 .MapReduce各个执行阶段

在这里插入图片描述

6 .关于Split(分片)的相关概念

HDFS 以固定大小的block 为基本单位存储数据,而对于MapReduce 而言,其处理单位是split。split 是一个逻辑概念,它只包含一些元数据信息,比如数据起始位置、数据长度、数据所在节点等。它的划分方法完全由用户自己决定。

7 .Map任务的数量(取决于split)

Hadoop为每个split创建一个Map任务,split 的多少决定了Map任务的数目。大多数情况下,理想的分片大小是一个HDFS块

8 .Reduce任务的数量

  • 最优的Reduce任务个数取决于集群中可用的reduce任务槽(slot) 的数目
  • 通常设置比reduce任务槽数目稍微小一些的Reduce任务个数(这样可以预留一些系统资源处理可能发生的错误)

9 .代码(待补充) 三个方面

第八章

1 . Hadoop1.0的局限和不足

  • 抽象层次低,需人工编码
  • 表达能力有限
  • 开发者自己管理作业(Job)之间的依赖关系
  • 难以看到程序整体逻辑
  • 执行迭代操作效率低
  • 资源浪费(Map和Reduce分两阶段执行)
  • 实时性差(适合批处理,不支持实时交互式)

2 . 针对Hadoop的改进与提升,hadoop框架从1.0->2.0

在这里插入图片描述

3 .HDFS HA 相关信息(如何工作???)

  • HDFS HA(High Availability)是为了解决单点故障问题
  • HA集群设置两个名称节点,“活跃(Active)”和“待命(Standby)
  • 两种名称节点的状态同步,可以借助于一个共享存储系统来实现
  • 一旦活跃名称节点出现故障,就可以立即切换到待命名称节点 Zookeeper确保一个名称节点在对外服务
  • 名称节点维护映射信息,数据节点同时向两个名称节点汇报信息

在这里插入图片描述

4 .YARN设计思路( 具体ppt 8.3.2笔记 )

在这里插入图片描述

5 .YARN体系结构( 具体ppt 8.3.3笔记 )

ResourceManager

  • 处理客户端请求
  • 启动/监控ApplicationMaster
  • 监控NodeManager
  • 资源分配与调度

NodeManager

  • 单个节点上的资源管理
  • 处理来自ResourceManger的命令
  • 处理来自ApplicationMaster的命令

ApplicationMaster

  • 为应用程序申请资源,并分配给内部任务 任务调度、监控与容错

在这里插入图片描述

6 .YARN发展目标

YARN的目标就是实现“一个集群多个框架”

第九章

1 .spark的特点(注意支持语言)

  • 运行速度快:使用DAG执行引擎以支持循环数据流与内存计算

  • 容易使用:支持使用Scala、Java、Python和R语言进行编程,可以通过Spark Shell进行交互式编程

  • 通用性:Spark提供了完整而强大的技术栈,包括SQL查询、流式计算、机器学习和图算法组件

  • 运行模式多样:可运行于独立的集群模式中,可运行于Hadoop中,也可运行于Amazon EC2等云环境中,并且可以访问HDFS、Cassandra、HBase、Hive等多种数据源

2 .Scala的特性(了解)

  • Scala具备强大的并发性,支持函数式编程,可以更好地支持分布式系统
  • Scala语法简洁,能提供优雅的API
  • Scala兼容Java,运行速度快,且能融合到Hadoop生态圈中

3 .Hadoop 存在如下一些缺点

  • 表达能力有限
  • 磁盘IO开销大
  • 延迟高
    • 任务之间的衔接涉及IO开销
    • 在前一个任务执行完成之前,其他任务就无法开始,难以胜任
    • 复杂、多阶段的计算任务

4 .Spark与Hadoop 的对比(主要说明Spark优点)

  • Spark的计算模式也属于MapReduce,但不局限于Map和Reduce操作,还提供了多种数据集操作类型,编程模型比Hadoop MapReduce更灵活
  • Spark提供了内存计算,可将中间结果放到内存中,对于迭代运算效率更高
  • Spark基于DAG的任务调度执行机制,要优于Hadoop MapReduce的迭代执行机制

5 . spark设计理念(可再具体参考ppt)

一个软件栈满足不同应用场景,spark所提供的生态系统足矣应对同时支持批处理、交互式查询和流数据处理三种场景。

补充:数据的流处理可以理解为系统需要接收并处理一系列连续不断变化的数据

补充:数据的批处理,可以理解为一系列相关的任务按顺序或并行的,一个接一个地执行。批处理地输入是在一段时间内收集好地数据。每次批处理地输出都可以是下次批处理地输入。

6 .spark的生态系统包含的几大组件

  • Spark Core
  • Spark SQL
  • Spark Streaming
  • MLLib
  • GraphX

在这里插入图片描述

7 .spark的生态系统组件的应用场景

在这里插入图片描述

8 .基本概念(见ppt)

  • RDD:是Resillient Distributed
    Dataset(弹性分布式数据集)的简称,是分布式内存的一个抽象概念,提供了一种高度受限的共享内存模型
  • DAG:是Directed Acyclic Graph(有向无环图)的简称,反映RDD之间的依赖关系
  • Executor:是运行在工作节点(WorkerNode)的一个进程,负责运行Task
  • Application:用户编写的Spark应用程序
  • Task:运行在Executor上的工作单元
  • Job:一个Job包含多个RDD及作用于相应RDD上的各种操作
  • Stage:是Job的基本调度单位,一个Job会分为多组Task,每组Task被称为Stage,或者也被称为TaskSet,代表了一组关联的、相互之间没有Shuffle依赖关系的任务组成的任务集

9 .Spark运行基本流程

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

10 .RDD运行原理(注意黑体)

补充:
行动:执行计算并指定输出的类型
转换:指定RDD之间的相互依赖关系

  • 一个RDD就是一个分布式对象集合,本质上是一个只读的分区记录集合,每个RDD可分成多个分区,每个分区就是一个数据集片段,并且一个RDD的不同分区可以被保存到集群中不同的节点上,从而可以在集群中的不同节点上进行并行计算
  • RDD提供了一种高度受限的共享内存模型,即RDD是只读的记录分区的集合,不能直接修改,只能基于稳定的物理存储中的数据集创建RDD,或者通过在其他RDD上执行确定的转换操作(如map、join和group
    by)而创建得到新的RDD
  • RDD提供了一组丰富的操作以支持常见的数据运算,分为“动作”(Action)和“转换”(Transformation)两种类型
  • RDD提供的转换接口都非常简单,都是类似map、filter、groupBy、join等粗粒度的数据转换操作,而不是针对某个数据项的细粒度修改(不适合网页爬虫)
  • 表面上RDD的功能很受限、不够强大,实际上RDD已经被实践证明可以高效地表达许多框架的编程模型(比如MapReduce、SQL、Pregel)
  • Spark用Scala语言实现了RDD的API,程序员可以通过调用API实现对RDD的各种操作
    11 .

11 .RDD的特性(高效计算的原因)

  • 高效的容错性
    • 现有容错机制:数据复制或者记录日志
    • RDD:血缘关系、重新计算丢失分区、无需回滚系统、重算过程在不同节点之间并行、只记录粗粒度的操作
  • 中间结果持久化到内存,数据在内存中的多个RDD操作之间进行传递,避免了不必要的读写磁盘开销
  • 存放的数据可以是Java对象,避免了不必要的对象序列化和反序列化

12 .RDD的依赖关系(窄依赖 宽依赖 )

  • 窄依赖表现为一个父RDD的分区对应于一个子RDD的分区或多个父RDD的分区对应于一个子RDD的分区
  • 宽依赖则表现为存在一个父RDD的一个分区对应一个子RDD的多个分区
    在这里插入图片描述

13 .RDD在Spark运行过程

  • 创建RDD对象;
  • SparkContext负责计算RDD之间的依赖关系,构建DAG;
  • DAGScheduler负责把DAG图分解成多个Stage,每个Stage中包含了多个Task,每个Task会被TaskScheduler分发给各个WorkerNode上的Executor去执行

在这里插入图片描述

14 .Shark到sql流程(待补充)

15 . Spark SQL中的 Catalyst

Spark SQL在Hive兼容层面仅依赖HiveQL解析、Hive元数据,也就是说,从HQL被解析成抽象语法树(AST)起,就全部由Spark SQL接管了。Spark SQL执行计划生成和优化都由Catalyst(函数式关系查询优化框架)负责

16 .Spark 三种部署方式

  • Standalone(类似于MapReduce1.0,slot为资源分配单位)
  • Spark on Mesos(和Spark有血缘关系,更好支持Mesos)
  • Spark on YARN

Spark on Yarn架构

16 .Spark RDD 的基本操作(待补充)

最后更新时间2020/1/8

总结

  文章纯属期末复习整理,如有不足和错误的地方,希望评论指出或私信
最后希望给文章点个赞,整理不易!!!
最后希望给文章点个赞,整理不易!!!
最后希望给文章点个赞,整理不易!!!

猜你喜欢

转载自blog.csdn.net/weixin_44972997/article/details/112242367