跳到主要内容
信息
· 文章中可能会出现一些错误，希望大佬们可以在评论区指出;

大数据技术复习

JMU21级软工大数据技术期末复习提纲，自用，内容可能有差错

第一章 大数据​

大数据问题的定义和来源（P2-6）​

  • 信息爆炸

    大数据、云计算、物联网的到来拉开了第三次信息化浪潮的大幕

  • 三大技术支撑

    1. 信息存储：存储设备容量不断增加
    2. 信息处理：CPU 处理能力大幅提升
    3. 信息传输：网络带宽不断增加

  • 数据产生方式变革

大数据问题的特点（P8-10）​

大数据的概念/特点可用“4V”来概括：

  • 数据量大
  • 数据类型繁多
  • 处理速度快
  • 价值密度低

大数据应用四大层面的关键技术（P16）​

大数据四大计算模式（P17）​

云计算的概念（P19-20）​

云计算实现了通过网络提供可伸缩的、廉价的分布式计算能力，用户只需要在具备网络接入条件的地方，就可以随时随地获得所需的各种 IT 资源。云计算代表了以虚拟化技术为核心、以低 成本为目标的、动态可扩展的网络应用基础设施，是近年来最有代表性的网络计算技术与模式。

三种典型服务模式和三种云：

物联网的概念（P23-24）​

物联网是物物相连的互联网，是互联网的延伸，它利用局部网络或互联网等通信技术把传感 器、控制器、计算机、人员和物等通过新的方式连在一起，形成人与物、物与物相连，实现信息 化和远程管理控制。

从技术架构上来看，物联网可分为四层：

云计算与物联网之间的关系（P27）​

第三章 HDFS​

HDFS的本质：分布式文件系统（P46）​

分布式文件系统（Distributed File System，DFS）是一种通过网络实现文件在多台主机上进行分布式存储的文件系统。

HDFS块存储的概念和好处（P50）​

概念：

在 HDFS 中的文件会被拆分成多个块，每个块作为独立的单元进行存储。默认块大小为64MB，这样做是为了最小化寻址开销，提高读写效率。

好处：

  • 支持大规模文件存储：大规模文件不会受到单个节点存储容量限制，因为可被拆分成若干块。
  • 简化系统设计：简化存储管理，方便元数据管理。
  • 适合数据备份：块可被冗余存储，提高系统容错性和可用性。

名称节点和数据节点的功能（P50-51）​

名称节点（NameNode）：

负责管理HDFS的命名空间，并保存两个核心数据结构：维护文件系统元数据的FsImage，记录操作日志的EditLog。名称节点记录了每个文件中各个块所在的数据节点的位置信息，但是并不持久化地存储这些信息，而是在系统每次启动时扫描所有数据节点并重构，得到这些信息。

数据节点（DataNode）：

负责数据的存储和读取，会根据客户端或者名称节点的调度来进行数据的存储和检索，并且向名称节点定期发送自己所存储的块的列表信息。

第二名称节点的意义和工作原理（P51-52）​

意义：

为了有效解决 EditLog 逐渐变大带来的问题而诞生，并不能完全替代名称节点，因为它只起到了“检查点”作用，而没有起到“热备份作用”，因此名称节点发生故障时还是会丢失部分元数据。

工作原理：

如图：

  1. 每隔一段时间，其与名称节点通信，对它的FsImage和EditLog进行合并与替换。
  2. 合并的过程会产生“检查点”文件FsImage.ckpt，周期性备份名称节点中的元数据信息。

冗余存储的三大优点（P54-55）​

什么是冗余存储：

HDFS 采用了多副本方式对数据进行冗余存储，通常一个数据块的多个副本会被分布到不同的数据节点上。

三大优点：

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

冗余复制因子为3时的数据存放策略（P55）​

HDFS 默认的冗余复制因子是 3，每一个文件块会被同时保存到 3 个地方，其中，有两个副本放在同一个机架的不同机器上面，第 3 个副本放在不同机架的机器上面，这样既可以保证机架发生异常时的数据恢复，也可以提高数据读写性能。

数据的读取和复制策略（P55-56）​

数据读取：

读取数据时，从名称节点获得数据块副本所在的数据节点，当发现某个数据块副本对应的机架 ID 和客户端对应的机架 ID 相同时，就优先选择该副本读取数据，如果没有发现，就随机选择一个副本读取数据。

数据复制：

采用 流水线复制 策略，大大提高数据复制过程效率。如下图，客户端把数据写入第一个数据节点后，第一个数据节点会将数据写入第二个数据节点，依此类推...

HDFS中三种可能的错误和恢复方法（P56-57）​

  • 名称节点出错：

    当名称节点发生死机时，首先到远程挂载的网络文件系统中获取备份的元数据信息，放到第二名称节点上进行恢复，并把第二名称节点作为名称节点来使用。

  • 数据节点出错：

    当一定数量的数据节点死机（不再定期向名称节点发送心跳），导致数据块的副本数量小于冗余因子后，就会启动数据冗余复制，为它生成新的副本。

  • 数据出错：

    读文件时先进行数据校验，如果校验出错，客户端会向名称节点报告这个文件块有错误，并且到另一个数据节点读取该文件块。名称节点会定期检查并且重新复制错误的块。

第四章 HBase​

HBase与传统数据库的不同（P68-69）​

  • 数据类型：关系数据库采用关系模型，有多种数据类型和存储方式。HBase则将数据序列化存储为字符串，需要用户自行解析。
  • 数据操作：关系数据库操作丰富，表间关系复杂。HBase只有简单CRUD操作，不存在复杂的表间关系。
  • 存储模式：关系数据库基于行模式存储，会浪费许多磁盘空间和内存带宽。HBase则基于列存储，每个列组由几个文件保存，不同列组文件分离，降低了I/O开销且支持高并发查询。
  • 数据索引：关系数据库可构建多个复杂索引。HBase则 只有一个索引——行键。
  • 数据维护：关系数据库更新数据后，旧数据便不再存在。HBase则 生成新版本数据，保留旧版本数据。
  • 可伸缩性：关系数据库很难横/纵向扩展。HBase 横向扩展灵活，能轻易通过在集群中增减硬件来实现性能的伸缩。

HBase的数据模型概念、数据坐标（P70-72）​

数据模型概念​

  • 表：表由行和列组成，列划分为若干个列族。
  • 行键：表的每行由行键（RowKey）来标识。
  • 列族和列限定符：每个列由列族（Column Family）和列限定符（Column Qualifier）进行限定，列族需要在定义表的时候定义，而列限定符不需要。例如要想访问下图的name列，就是info.name。
  • 单元格：通过行键，列族和列限定符可以确认一个单元格。每个单元格中可以保存一个数据的多个版本。
  • 时间戳：使用时间戳来索引单元格中数据的版本。

数据坐标​

对于关系数据库，它的数据坐标是二维的：[行, 列]。

而对于HBase，数据坐标是四维的：[行键, 列族, 列限定符, 时间戳]。在这种视图下，HBase也可被视为一个键值数据库：

概念视图与物理视图的不同（P72-73）​

概念视图​

一个表可以视为一个稀疏、多维的映射关系。在概念视图中，可以通过行键、行键+时间戳、行键+列就能定位数据：

物理视图​

物理存储层面，采用基于列的存储方式：

HBase列式存储的实例（P73-75）​

HBase采用列存储模型，它会对关系进行垂直分解，并为每个属性分配一个子关系：

HBase的三层结构下客户端如何访问到数据（P76-78）​

Region：

Region 包含了某键值区间内的所有行数据，是负载均衡和数据分发的基本单位。当一个 Region中包含的行数量达到一个阈值时，就会被自动等分成两个新的 Region。

一个Region标识符可以表示成：“表名+开始主键+RegionID”。

三层结构：

客户端如何访问数据：

  1. 访问ZooKeeper，获取-ROOT-表的位置信息。
  2. 访问-ROOT-表，获得.META.表的信息。
  3. 访问.META.表，找到所需的Region具体位于哪个Region服务器，然后到那个服务器读取数据。

这种方法使得客户端无需连接Master主服务器就能读取数据，减轻了Master主服务器的压力。同时也不需要重复进行三级寻址，首次寻址后的结果会存储于高级缓存中。

Region服务器工作原理（P80-81）​

  1. 读写数据

    写数据：数据首先被写入MemStore和HLog中，当操作写入 HLog 之后写入操作才会完成。

    读数据：首先访问 MemStore 缓存，如果数据不在缓存中，才会到磁盘上面的 StoreFile 中去寻找。

    MemStore：在内存中的缓存，保存最近更新的数据。

    HLog：磁盘上面的记录文件，它记录着所有的更新操作。

    StoreFile：磁盘中的文件，是B树结构的，方便快速读取。

  2. 缓存刷新

    系统会周期性把MemStore缓存内容写到 一个新的StoreFile 中，清空缓存，并在HLog中写入一个标记。

    Region服务器在启动时会检查HLog，确认最近一次缓存刷新后有没有新的写入操作：

    • 没有，说明所有数据已经保存到磁盘的StoreFile中
    • 有，把更新写入MemStore，然后进行缓存刷新操作

    之后删除旧的HLog文件，开始为用户提供服务。

  3. StoreFile合并

    每次缓存刷新后都会生成一个新的StoreFile文件，当它的数量达到一个阈值时，会进行StoreFIle合并的操作，以减少查找时间。

第五章 NoSQL​

NoSQL数据库三大特点（P98-99）​

  1. 灵活的可拓展性

    关系数据库很难横向扩展，而NoSQL具备良好的横向扩展能力。

  2. 灵活的数据模型

    关系数据模型需要满足各种严格的规范条件，而NoSQL数据库使用非关系数据模型，很灵活。

  3. 与云计算紧密融合

    NoSQL数据库和云计算都拥有良好的水平拓展能力，两者可以紧密融合，构建基于NoSQL的云数据库服务。

关系型数据库不满足Web2.0应用的三大原因（P99-100）​

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

    对于关系数据库来说，在海量数据表中进行SQL查询效率很低。

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

    关系数据库难以承受高并发读写请求。

  3. 无法满足高可扩展性和高可用性的需求

    关系数据库难以横向拓展，不容易扩展性能和负载能力。

关系型数据库的特性为何不适用于Web2.0（P100）​

  1. Web 2.0 网站系统通常不要求严格的数据库事务

    对于包含大量频繁实时读写请求的 Web 2.0 网站而言，实现事务的代价是难以承受的。

  2. Web 2.0 并不要求严格的读写实时性

    对于 Web 2.0 而言，没有实时读写的需求。

  3. Web 2.0 通常不包含大量复杂的 SQL 查询

    Web 2.0 通常只采用单表的主键查询，关系数据库的查询优化机制在 Web 2.0 中难以有所作为。

NoSQL数据库与关系型数据库优劣（P101）​

NoSQL​

优势：可以支持超大规模数据存储，其灵活的数据模型可以很好地支持 Web 2.0 应用，具有强大的横向扩展能力等。

劣势：缺乏数学理论基础，复杂查询性能不高，一般都不能实现事务强一致性，很难实现数据完整性，技术尚不成熟，缺乏专业团队的技术支持，维护较困难等。

关系型​

优势：以完善的关系代数理论作为基础，有严格的标准，支持事务 ACID 四性，借助索引机制可以实现高效的查询，技术成熟，有专业公司的技术支持

劣势：可扩展性较差，无法较好地支持海量数据存储，数据模型过于死板，无法较好地支持 Web 2.0 应用，事务机制影响了系统的整体性能等

四大类型NoSQL数据库名称，数据模型特点，适用场合，优缺点（P102-105）​

键值数据库​

键值对：用哈希表实现，Key可以定位Value，Value对数据库而言是不可见的，因此只能用Key进行查询。

列族数据库​

列族：列族数据库由多个行构成，每行包含多个列族，不同的行可以具有不同数量的列族。每行数据可以通过行键进行定位。

文档数据库​

文档：文档数据库的最小单位。一个文档可以包含非常复杂的数据结构，并且不需要采用特定的设计模式。每个文档可能具有完全不同的结构。

图数据库​

使用图作为数据模型来存储数据，完全不同于上面三种数据模型，可以高效存储不同顶点之间的关系。

CAP的定义（P105-106）​

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

CAP三种选择两种时的实现方法，及其代表产品（P106-107）​

一个分布式系统不可能同时满足CAP，最多只能同时满足其中2个：

  • CA：最简单的做法是把所有与事务相关的内容都放到同一台机器上，会严重影响系统可扩展性。例如传统的关系数据库（MySQL、SQL Server 和 PostgreSQL）。
  • CP：当出现网络分区的情况时**，受影响的服务需要等待数据一致**，因此在等待期间就无法对外提供服务。例如Neo4J、BigTable和 HBase 等 NoSQL 数据库。
  • AP：允许系统返回不一致的数据，例如Web2.0。也可以不完全放弃一致性，转而采用最终一致性，例如DynamoDB、Riak、CouchDB、Cassandra 等 NoSQL 数据库。

BASE的具体含义（P108）​

  • 基本可用（Basically Available）：

    一个分布式系统的一部分发生问题变得不可用时，其他部分仍然可以正常使用，也就是允许分区失败的情形出现。

  • 软状态（Soft-state）：

    “软状态”是指数据状态可以有一段时间不同步，具有一定的滞后性。

    数据库保存的数据是“硬状态”时，可以保证数据一致性，即保证数据一直是正确的。

  • 最终一致性（Eventual consistency）：

    最终一致性是弱一致性的一种特例，允许后续的访问操作可以暂时读不到更新后的数据，但是经过一段时间之后，用户必须读到更新后的数据。

    弱一致性：当执行完一次更新操作后，不能保证后续访问读到的都是更新后的最新数据。

第七章 MapReduce​

MapReduce与Hadoop的关系（P131-132）​

MapReduce是谷歌提出的分布式并行编程模型，而Hadoop MapReduce是一种具体实现。Hadoop 使用分布式文件系统 HDFS 实现分布式数据存储，用 Hadoop MapReduce 实现分布式计算。

Map与Reduce函数的输入、输出与处理过程（P132）​

Map函数的输入来自HDFS的文件块，它将输入元素转换成<Key, Value>形式的键值对。

Reduce函数将输入的一系列具有相同键的键值对以某种方式组合起来，输出处理后的键值对，输出结果会合并成一个文件。

MapReduce基本工作流程（P133-135）​

总述​

HDFS中的数据会经过预处理后给多个 Map 任务并行执行，当 Map 任务结束后，会生成以<key,value>形式的许多中间结果。然后，经过Shuffle操作的中间结果会被分发到多个 Reduce 任务并行执行，具有相同 key 的<key,value>会被发送到同一个 Reduce 任务，Reduce 任务会对中间结果进行汇总计算得到最后结果，并输出到HDFS。

Map阶段​

读取经过预处理的数据后，Map 任务会根据用户自定义的映射规则，输出一系列的<key,value>作为中间结果。

Shuffle阶段​

Shuffle 是指对 Map 任务输出结果（无序的<Key, Value>）进行分区、排序、合并、归并等处理（有序的<Key, Value-List>）并交给 Reduce 的过程。

如图，Shuffle 过程分为 Map 端的操作和 Reduce 端的操作：

  1. 在 Map 端的 Shuffle 过程：

    Map的输出结果首先被写入缓存，缓存满时，就启动溢写操作（将缓存数据进行分区、排序及合并操作），把缓存数据写入 一个新的磁盘文件 并清空缓存。在所有Map任务结束前，这些文件会被归并成一个大的磁盘文件待用。

  2. 在 Reduce 端的 Shuffle 过程：

    从各个Map端的磁盘文件中获取属于自己处理的那部分数据，然后对数据进行归并后交给Reduce处理。

Reduce阶段​

以一系列<key,value-list>中间结果作为输入，执行用户定义的逻辑，满足条件的输出结果会存储到HDFS中。

什么是“计算向数据靠拢”？为什么采用这一思想？（P132）​

计算向数据靠拢：将计算节点和数据存储节点放在一起运行，从而减少节点间的数据移动开销。

为什么采用：移动数据需要大量的网络传输开销，尤其是在大规模数据环境下，这种开销尤为惊人，所以，移动计算要比移动数据更加经济。

Combiner的作用？使用combiner与不使用combiner时的MapReduce执行Wordcount的区别（P136, P141）​

作用：定义归并数据的合并操作，以减小Map节点和Reduce节点间数据传输的数据量，提高网络IO性能。

区别：如果没有Combiner，那么Map输出的{<key1,value1>，<key1,value2>}经过Shuffle就是{<key1,<value1，value2>>}；有Combiner的话，经过Shuffle就是{<key1,value1 + value2>}，这里的’+‘表示合并，WordsCount统计单词出现频率就可以理解为数学上的加号。

MapReduce的关系自然连接运算(P142-143)​

例子：

在Map中，将两表的外键作为key，表名和值作为Value。然后在Reduce中进行自然连接操作，根据Key将两表内容连接到一块，输出最终连接结果。

第九章 Spark​

Hadoop的缺陷与Spark的优点，Spark优点的实现方式（P193-194）​

Spark 并不能完全替代 Hadoop，其主要用于替代Hadoop 中的 MapReduce 计算模型。

Hadoop MapReduce的缺陷：

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

Spark的优点和实现方式：

  1. Spark 的计算模式也属于 MapReduce，但不局限于 Map 和 Reduce 操作，还提供了多种数据集操作类型，编程模型比 MapReduce 更灵活。
  2. Spark 提供了内存计算，中间结果直接放到内存中，带来了更高的迭代运算效率。
  3. Spark 基于 DAG 的任务调度执行机制，要优于 MapReduce 的迭代执行机制。

Spark生态系统的组件与其功能（P195-197）​

Spark生态系统架构如图：

详细组件如下：

  • Spark Core：包含Spark的基本功能，主要面向批量数据处理。
  • Spark SQL：能够统一处理关系表和RDD，让开发者轻松使用SQL命令查询，并进行更复杂的数据分析。
  • Spark Streaming：支持高吞吐量、可容错处理的实时流数据处理。
  • Structure Streaming：是一种基于 Spark SQL 引擎构建的、可扩展且容错的流处理引擎。
  • MLlib（机器学习）： 提供了常用机器学习算法的实现。
  • GraphX（图计算）： 是 Spark 中用于图计算的 API，性能良好，拥有丰富的功能和运算符，能在海量数据上自如地运行复杂的图算法。

RDD与DAG的基本概念（P197）​

[补充] Spark基本运行流程（P198-199）​

  1. 当一个Spark应用被提交后，任务控制节点会创建一个SparkContext，向资源管理器注册并申请运行Executor的资源。
  2. 资源管理器为Executor分配资源，并启动它。
  3. SparkContext根据RDD的依赖关系构建DAG，并将DAG提交给DAG调度器进行解析，分成多个阶段（即多个任务集），任务调度器将任务分配给Executor执行。
  4. Executor执行完毕后，结果反馈给任务调度器和DAG调度器，然后写入数据并释放资源。

RDD转换操作与行动操作的区别（P200）​

转换操作：指定RDD之间的相互依赖关系。

行动操作：用于执行计算并指定输出的形式。

**主要区别：**转换操作（如 map、filter、groupBy、join 等）接受RDD 并返回 RDD，而行动操作（如 count、collect 等）接受 RDD 但是返回非 RDD（即输出一个值或结果）。

RDD哪些操作属于转换，哪些属于行动（常用API）（P212）​

RDD惰性调用与DAG的构建（P200, P）​

RDD惰性调用​

在 RDD 的执行过程中，真正的计算发生在 RDD 的“行动”操作，对于“行动”之前的所有“转换”操作，Spark 记录下操作后的RDD之间的生成和依赖关系，并不会触发真正的计算。

DAG的构建​

当RDD F 进行“行动”操作的时候，Spark才会根据RDD的依赖关系生成DAG，并从起点开始真正的计算。这一系列处理称为一个 “血缘关系”。

Spark宽依赖与窄依赖的定义, DAG阶段的划分（P205-207）​

宽依赖与窄依赖​

窄依赖：不包含shuffle操作，即父RDD的一个分区只被一个子RDD的一个分区所使用。

宽依赖：包含Shuffle操作，即父RDD的一个分区被多个子RDD的多个分区所使用。

窄依赖的RDD工作可以并行，互不干扰；而宽依赖的RDD工作不能并行，要相互等待。

DAG阶段的划分​

具体划分方法是：在 DAG 中进行反向解析，遇到宽依赖就断开（因为宽依赖涉及 Shuffle 操作，无法以流水线方式处理），遇到窄依赖就把当前的 RDD 加入当前的阶段中（因为窄依赖不会涉及 Shuffle 操作，可以以流水线方式处理）。

这样可以大大提高计算效率。

第十章 流计算​

流数据的特点（P221）​

静态数据处理与流数据处理的不同（批处理与流计算）（P224）​

  1. 流处理系统处理的是实时的数据，而传统的数据处理系统处理的是预先存储好的静态数据。
  2. 用户通过流处理系统获取的是实时结果，而通过传统的数据处理系统获取的是过去某一时刻的结果。并且，流处理系统无须用户主动发出查询，实时查询服务可以主动将实时结果推送给用户。

MapReduce为什么不适用于流计算（P222）​

MapReduce 专门面向静态数据的批量处理，内部各种实现机制都为批处理做了高度优化，这种批量任务处理方式在时延方面是无法满足流计算的实时响应需求的，适合处理持续到达的动态数据。

流计算一般处理流程（P223-224）​

如图：

数据实时采集​

数据实时采集阶段通常采集多个数据源的海量数据，需要保证实时性、低延迟与稳定可靠。

数据实时计算​

数据实时计算阶段对采集的数据进行实时的分析和计算。

实时查询服务​

经由流计算框架得出的结果可供用户进行实时查询、展示或存储。

流计算的两大框架：Storm和Spark Streaming（P226-233）​

Storm​

设计思想

  1. Streams

    流数据是一个无限的 Tuple 序列。

  2. Spouts

    Spouts是Stream的源头，应该是Topology图里的水龙头。

  3. Bolts

  4. Topology

    Storm 将 Spouts 和 Bolts 组成的网络抽象成 Topology，Topology 是 Storm 中最高层次的抽象概念，它可以被提交到 Storm 集群执行。在 Topology 的具体实现上，Storm 中的 Topology 定义仅是一些 Thrift 结构体。

  5. Stream Groupings

    Storm 中的 Stream Groupings 用于告知 Topology 如何在两个组件间进行 Tuple 的传送。

工作流程

Spark Streaming​

设计思想

对比​

参考资料​

部分图片来源于：