【大数据技术原理（期末复习）】_大数据技术期末复习

本文章主要对大数据重要章节的重要部分进行复习

---

一、大数据概论

1.1 大数据时代

1.1.1 三次信息化浪潮

1.1.3 数据产生方式

人类社会的数据产生方式大致经历了3个阶段: 运营式系统阶段、用户原创内容阶段 和 感知式系就阶段。

1.2 大数据的概念

大数据的“4V”
大数据的4个特点，包含4个层面:数据量大( Volume )、数据类型繁多( Variety )、处理速度快( Velocity) 和 价值密度低( Value )。

1.8 大数据与云计算、物联网

1.8.3 大数据与云计算、物联网的关系

这张图可以了解“大数据，云计算，物联网”的关系

---

二、大数据处理架构Hadoop

本章后半部分主要是演示Hadoop的安装，这里不做演示。

2.1 概述

2.1.1 Hadoop简介

Hadoop的核心是分布式文件系统（HDFS）和 MapReduce。

2.1.3 Hadoop的特性

• 高可靠性
• 高效性
• 高可拓展性
• 高容错性
• 成本低
• 运行在Linux操作系统上
• 支持多种编程语言

2.2 Hadoop生态系统

后面章节会主要讲述HDFS、HBase、MapReduce、YARN、
简单阐述Hive、Spark

---

三、分布式文件系统HDFS

本章主要任务是掌握 HDFS相关概念、HDFS的数据读写过程。

3.1 分布式文件系统

3.1.2 分布式文件系统的结构

分布式文件系统在物理结构上是由计算机集群中的多个节点构成的，这些节点分为两类，一类叫“主节点”( Master Node ),或者被称为“名称节点”(NameNode);另一类叫“从节点”( Slave Node),或者被称为“数据节点" (DataNode)。
名称节点负责文件和目录的创建、删除和重命名等，同时管理着数据节点和文件块的映射关系，因此客户端只有访问名称节点才能找到请求的文件块所在的位置，进而到相应位置读取所需文件块。
数据节点负责数据的存储和读取，在存储时，由名称节点分配存储位置，然后由客户端把数据直接写人相应数据节点;在读取时，客户端从名称节点获得数据节点和文件块的映射关系，然后就可以到相应位置访问文件块。数据节点也要根据名称节点的命令创建、删除和复制数据块。

3.3 HDFS的相关概念

3.3.2 名称节点和数据节点

在HDFS中，名称节点负责管理分布式文件系统的命名空间( Namespace)，保存了两个核心的数据结构，即Fslmage和Editlog。FsImage用于维护文件系统树以及文件树中所有的文件和文件夹的元数据，操作日志文件EditLog中记录了所有针对文件的创建、删除、重命名使等操作。名称节点记录了每个文件中各个块所在的数据节点的位置信息，但是并不持久化地存储送这些信息，而是在系统每次启动时扫描所有数据节点并重构，得到这些信息。

名称节点在启动时，会将Fslmage的内容加载到内存当中，然后执行EditLog文件中的各项操作，使内存中的元数据保持最新。这个操作完成以后，就会创建一个新的 FsImage文件和一个空的EditLog文件。名称节点启动成功并进人正常运行状态以后，HDFS中的更新操作都会被写人EditLog,而不是直接被写人Fslmage.这是因为对于分布式文件系统而言，FsImage 文件通常都很庞大(一般都是GB级别以上)，如果所有的更新操作都直接在Fslmage文件中进行，那么系统的运行速度会变得非常缓慢。相对而言，EditLog 通常都要远小于FsImage, 更新操作写人EditLog是非常高效的。名称节点在启动的过程中处于“安全模式”，只能对外提供读操作，无法提供写操作。启动过程结束后，系统就会退出安全模式，进人正常运行状态,对外提供读写操作。

3.3.3 第二名称节点

在名称节点运行期间，HDFS会不断产生更新操作，这些更新操作直接被写人EditLog文件，因此EditLog文件也会逐渐变大。在名称节点运行期间，不断变大的EditLog文件通常对于系统性能不会产生显著影响，但是当名称节点重启时，需要将FsImage加载到内存中，然后逐条执行EditLog中的记录，使FsImage保持最新。可想而知，如果EditLog很大，就会导致整个过程变得非常缓慢，使名称节点在启动过程中长期处于“安全模式”，无法正常对外提供写操作,影响用户的使用。

为了有效解决EditLog逐渐变大带来的问题，HDFS 在设计中采用了第二名称节点( SecondaryNameNode)。第二名称节点是HDFS架构的一个重要组成部分，具有两个方面的功能:首先，它可以完成EditLog与FsImage的合并操作，减小EditLog文件大小，缩短名称节点重启时间；其次，它可以作为名称节点的“检查点”，保存名称节点中的元数据信息。

3.5 HDFS的存储原理

3.5.1 数据的冗余存储

作为一个分布式文件系统，为了保证系统的容错性和可用性，HDFS 采用了多副本方式对数据进行冗余存储，通常一个数据块的多个副本会被分布到不同的数据节点上。这种多副本方式具有以下3个优点。

• 加快数据传输速度
• 容易检查数据错误
• 保证数据的可靠性

3.5.2 数据存取策略

数据存取策略包括数据存放、数据读取和数据复制等方面，它在很大程度上会影响到整个分布式文件系统的读写性能，是分布式文件系统的核心内容。

3.6 HDSF的数据读写过程

3.6.1 读数据过程

在介绍HDFS的数据读写过程之前，需要简单介绍一下相关的类。FileSystem 是一个通用文件系统的抽象基类，可以被分布式文件系统继承，所有可能使用Hadoop文件系统的代码都要使用到这个类。Hadoop 为FileSystem 这个抽象类提供了多种具体的实现，DistributedFileSystem 就是FileSystem在HDFS中的实现.FileSystem的open()方法返回的是一个输人流FSDataInputStream对象，在HDFS中具体的输人流就是DFSInputStream; FileSystem 中的create()方法返回的是一个输出流FSDataOutputStream对象，在HDFS中具体的输出流就是DFSOutputStream。

• (1)客户端通过FileSystem.open()打开文件，相应地，在HDFS中DistributedFileSystem具体实现了FileSystem。因此，调用open()方法后，DistributedFileSystem 会创建输人流FSData InputSream,对于HDFS而言，具体的输人流就是DFSInputStream.

• (2)在DFSInputStream的构造函数中，输人流通过ClientProtocal.getBlockLocations()远程调用名称节点，获得文件开始部分数据块的保存位置。对于该数据块，名称节点返回保存该数据块的所有数据节点的地址，同时根据距离客户端的远近对数据节点进行排序;然后，DistributedFileSystem 会利用DFSInputStream来实例化FSDataInputStream,并返回给客户端，同时返回数据块的数据节点地址。

• (3)获得输人流FSDataInputStream后，客户端调用read()方法开始读取数据。输人流根据前面的排序结果，选择距离客户端最近的数据节点建立连接并读取数据。

• (4)当客户端读取完数据的时候，调用FSDataInputStream的close()方法，关闭输人流。需要注意的是，在读取数据的过程中，如果客户端与数据节点通信时出现错误，就会尝试连接包含此数据块的下一个数据节点。

---

四、分布式数据库HBase

HBase是针对谷歌BigTable的开源实现，是一个高可靠、高性能、面向列、可伸缩的分布式数据库，主要用来存储非结构化和半结构化的松散数据。

4.3 HBase数据模型

4.3.2 HBase数据模型的相关概念

HBase实际上就是一个稀疏、 多维、持久化存储的映射表，它采用行键(Row Key)、 列族( Column Family )、列限定符( Column Qualifer )和时间戳( Timestamp)进行索引。

4.4 HBase的实现原理

4.4.1 HBase的功能组件

HBase的实现包括3个主要的功能组件:库函数，链接到每个客户端;一个Master主服务器(也称为Master);许多个Region 服务器。Region 服务器负责存储和维护分配给自己的Region,处理来自客户端的读写请求。Master主服务器负责管理和维护HBase表的分区信息，Master会实时监测集群中的Region服务器，把特定的Region分配到可用的Region服务器上，并确保整个集群内部不同Region服务器之间的负载均衡。当某个Region服务器因出现故障而失效时，Master 会把该故障服务器上存储的Region重新分配给其他可用的Region服务器。除此以外，Master 还处理模式变化，如表和列族的创建。

客户端并不是直接从Master主服务器上读取数据，而是在获得Region的存储位置信息后，直接从Region服务器上读取数据。尤其需要指出的是，HBase 客户端并不依赖于Master而是借助于ZooKeeper来获得Region的位置信息的，所以大多数客户端从来不和Master主服务器通信，这种设计方式使Master的负载很小。

4.4.3 Region的定位

每个Region都有一个RegionID来标识它的唯一性 ，这样，一个Region标识符就可以表示成“表名+开始主键+ RegionID”。有了Region标识符，就可以唯一地标识每个Region。为了定位每个Region所在的位置，可以构建一张映射表。映射表的每个条目( 或每行)包含两项内容，一个是Region标识符，另一个是Region服务器标识。这个条目表示Region和Region服务器之间的对应关系，从而可以知道某个Region被保存在哪个Region服务器中。这个映射表包含了关于Region的元数据(即Region和Region服务器之间的对应关系)，因此也被称为“元数据表”，又名“.META.表”。当一个HBase表中的Region数量非常庞大的时候，.META.表的条目就会非常多，一个服务器保存不下，也需要分区存储到不同的服务器上，因此.META.表也会被分裂成多个Region。 这时，为了定位这些Region,就需要构建一个新的映射表， 记录所有元数据的具体位置，这个新的映射表就是“根数据表”，又名“-ROOT表”。-ROOT表是不能被分割的，永远只存在一个Region用于存放-ROOT表。因此这个用来存放-ROOT-表的唯一个Region, 它的名字是在程序中被“写死”的，Master主服务器永远知道它的位置。

综上所述，HBase使用类似B+树的三层结构来保存Region 位置信息。

4.6 HBase编程实践

4.6.1HBase常用的Shell命令

五、NoSQL数据库

5.4 NoSQL的四大类型

NoSQL数据库虽然数量众多，但是归结起来，典型的NoSQL数据库通常包括键值数据库、列族数据库、文档数据库和图数据库。

5.5 NoSQl 的三大基石

5.5.1 CAP

• C( Consistency):一致性。 它是指任何一个读操作总是能够读到之前完成的写操作的结果，也就是在分布式环境中，多点的数据是一致的。
• A ( Availability):可用性。它是指快速获取数据，且在确定的时间内返回操作结果。
• P(Tolerance of Network Partition ):分区容忍性。它是指当出现网络分区的情况时(即系统中的一部分节点无法和其他节点进行通信)，分离的系统也能够正常。

CAP理论告诉我们，一个分布式系统不可能同时满足一致性、 可用性和分区容忍性这3个特性，最多只能同时满足其中2个。

5.5.2 BASE

说起BASE ( Basically availble、Sof-state 、Eventual consistency),不得不谈到ACID。一个数据库事务具有ACID四性。

• A(Atomicity): 原子性。它是指事务必须是原子工作单元，对于其数据修改，要么全都执行，要么全都不执行。

• C (Consistenecy):一致性。它是指事务在完成时，必须使所有的数据都保持一致状态。

• I ( Isolation): 隔离性。它是指由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。

• D ( Durability): 持久性。它是指事务完成之后，它对于系统的影响是永久性的，该修改即使出现致命的系统故障也将一直保持。

BASE的基本含义是基本可用( Basically Available )、软状态( Soft-state )和最终一致性( Eventual consistency )。

七、MapReduce

7.2 MapReduce的工作流程

7.2.1 工作流程概述

大规模数据集的处理包括分布式存储和分布式计算两个核心环节。Hadoop使用分布式文件系统HDFS实现分布式数据存储，用Hadoop MapReduce 实现分布式计算。MapReduce 的输人和输出都需要借助于分布式文件系统进行存储，这些文件被分布存储到集群中的多个节点上。

MapReduce的核心思想可以用“分而治之”来描述，也就是把一个大的数据集拆分成多个小数据集在多台机器上并行处理。也就是说，一个大的MapReduce作业，首先会被拆分成许多个Map任务在多台机器上并行执行，每个Map任务通常运行在数据存储的节点上。这样计算和数据就可以放在一起运行， 不需要额外的数据传输开销。当Map任务结束后，会生成Vkeyalue形式的许多中间结果。然后，这些中间结果会被分发到多个Reduce任务在多台机器上并行执行，具有相同key的Kkeyvalue会被发送到同一个Reduce任务，Reduce 任务会对中间结果进行汇总计算得到最后结果，并输出到分布式文件系统。

7.2.2 MapReduce的各个执行阶段

• (1 ) MapReduce框架使用InputFormat模块做Map前的预处理，比如验证输人的格式是否符合输入定义;然后，将输人文件切分为逻辑上的多个InputSplit。IputSplit是MapReduce对文件进行处理和运算的输人单位，只是一个逻辑概念，每个InputSplit并没有对文件进行实际切分，只是记录了要处理的数据的位置和长度。
• (2)因为InputSplit是逻辑切分而非物理切分，所以还需要通过RecordReader (RR)根据InputSplit中的信息来处理InputSplit 中的具体记录，加载数据并将其转换为适合Map任务读取的键值对，输人给Map任务。
• (3) Map任务会根据用户自定义的映射规则，输出系列的<key,value>作 为中间结果。
• (4)为了让Reduce可以并行处理Map的结果,需要对Map的输出进行一定的分区( Partition)、排序(Sort)、合并(Combine)、归并(Merge )等操作，得到<key,value-list>形 式的中间结果，再交给对应的Reduce来处理，这个过程称为Shufle从无序的<key,value>到有序的<key,value-list>,这个过程用Shfle来称呼是非常形象的。
• (5) Reduce以一系列<key,vale-list>中间结果作为输入，执行用户定义的逻辑，输出结果交给OutputFormat模块。
• (6) OutpuFomat模块会验证输出目录是否已经存在，以及输出结果类型是否符合配置文件中的配置类型，如果都满足，就输出Reduce的结果到分布式文件系统。

八、Hadoop再探讨

8.2 HDFS 2.0的新特性

8.2.1 HDFS HA

由于第二名称节点无法提供“热备份”功能，即在名称节点发生故障的时候，系统无法实时切换到第二名称节点立即对外提供服务，仍然需要进行停机恢复，因此HDFS 1.0 的设计是存在单点故障问题的。为了解决单点故障问题，HDFS 2.0采用了高可用( High Availbility, HA)架构。在一个典型的HA集群中，一般设置两个名称节点，其中一个名称节点处于“活跃”( Active )状态，另一个处于“待命”( Standby )状态，处于活跃状态的名称节点负责对外处理所有客户端的请求，处于待命状态的名称节点则作为备用节点，保存足够多的系统元数据，当名称节点出现故障时提供快速恢复能力。也就是说，在HDFS HA中，处于待命状态的名称节点提供了“热备份”，一旦活跃名称节点出现故障，就可以立即切换到待命名称节点，不会影响到系统的正常对外服务。

8.3 新一代资源管理调度框架YARN

8.3.1 MapReduce 1.0的缺陷

• (1)存在单点故障。MapReduce 1.0 由JobTracker负责所有MapReduce作业的调度，而系统中只有一个JobTracker,因此会存在单点故障问题，即这个唯一的JobTracker出现故障就会导致系统不可用。

• (2) JobTracker“大包大揽”导致任务过重。JobTracker 既要负责作业的调度和失败恢复，又要负责资源管理分配。JobTracker 执行过多的任务，需要消耗大量的资源，

8.3.2 YARN设计思路

为了克服MapReduce 1.0 版本的缺陷，在Hadoop 2.0以后的版本中对其核心子项目MapReduce1.0的体系结构进行了重新设计，生成了MapReduce 2.0和YARN。其基本思路就是“放权”，即不让JobTracker这一个组件承担过多的功能，对原JobTracker三大功能(资源管理、任务调度和任务监控)进行拆分，分别交给不同的新组件去处理。重新设计后得到的YARN包括ResourceManager 、ApplicationMaster 和NodeManager, 其中，由ResourceManarger负责资源管理，由AplicationMaster负责任务调度和监控，由NodeManager负责执行原TaskTracker的任务。这种“放权”的设计，大大降低了JobTacker的负担，提升了系统运行的效率和稳定性。

九、数据仓库Hive

数据仓库的体系结构通常包含4个层次:数据源、数据存储和管理、数据服务、数据应用。

十、Spark

10.1 概述

10.1.1 Spark简介

Spark作为大数据计算平台的后起之秀，在2014年打破了Hadoop 保持的基准排序( SortBenchmark )纪录，使用206个节点在23 min的时间里完成了100 TB数据的排序，而Hadoop是使用2000个节点在72 min的时间里才完成同样数据的排序。也就是说，Spark 仅使用了约十分之-的计算资源，获得了约比Hadoop快3倍的速度。新纪录的诞生，使得Spark获得多方追捧，也表明了Spark可以作为一个更加快速、高效的大数据计算框架。

10.1.3 Spark与Hadoop的对比

Hadoop虽然已成为大数据技术的事实标准，但其本身还存在诸多缺陷，最主要的缺陷是其MapReduce计算模型延迟过高，无法胜任实时、快速计算的需求，因而只适用于离线批处理的应用场景。回顾Hadoop的工作流程，可以发现Hadoop存在以下缺点。

• (1)表达能力有限。计算都必须要转化成Map和Reduce两个操作，但这并不适合所有的情况，难以描述复杂的数据处理过程。
• (2)磁盘10开销大。每次执行时都需要从磁盘读取数据，并且在计算完成后需要将中间结果写人磁盘中，I0开销较大。
• (3)延迟高。一次计算可能需要分解成-系列按顺序执行的MapReduce任务，任务之间的衔接由于涉及IO开销，会产生较高延迟。而且，在前一个任 务执行完成之前，其他任务无法开始，因此难以胜任复杂、多阶段的计算任务。

Spark在借鉴Hadoop MapReduce 优点的同时，很好地解决了MapReduce所面临的问题。相比于MapReduce, Spark 主要具有如下优点。

• (1)Spark的计算模式也属于MapReduce,但不局限于Map和Reduce操作，还提供了多种数据集操作类型，编程模型比MapReduce更灵活。

• (2 ) Spark提供了内存计算，中间结果直接放到内存中，带来了更高的迭代运算效率。

• (3) Spark基于DAG的任务调度执行机制，要优于MapReduce的迭代执行机制。

Spark最大的特点就是将计算数据、中间结果都存储在内存中，大大减少了I0开销，因而Spark更适合于迭代运算比较多的数据挖掘与机器学习运算。