今年的期末笔记又复活回归辣！首先就是这门大数据了，这门课学下来给我一个感觉就是这个学费真没白交啊，几乎每节课都会讲一个新的技术栈，浅尝辄止但是种类特别多，复习起来归类还是很折磨的
更重要的是，刘老师不给题库不给往年题不画重点，那就只能硬着头皮上了，所以决定本学期的第一篇期末笔记就决定是你辣！
当然首先我们还是介绍下我们用的教材，是人民邮电出版社的林子雨的版本

第一章 大数据概述

1.试述信息技术发展史上的3次信息化浪潮及其具体内容。

（课本第2页）1980年前后，个人计算机开始普及；1995年前后，人类开始全面进入互联网时代；2010年前后，大数据、云计算、物联网的快速发展，拉开了第三次信息化浪潮的大幕。

2.试述数据产生方式经历的几个阶段。

（课本第4页图1-1）运营式系统阶段→用户原创内容阶段→感知式系统阶段

3.试述大数据的4个基本特征。

（课本第7页开始三级标题）数据量大、数据类型繁多、处理速度快、价值密度低

4. 人类在科学研究上经历了哪4种范式？

（课本第10页开始四级标题）实验科学、理论科学、计算科学、数据密集型科学

5.试述大数据对思维方式的重要影响。

（课本第11页开始四级标题）全样而非抽样、效率而非精确、相关而非因果

6.大数据决策与传统的基于数据仓库的决策有什么区别？

（课本第12页1.3.3.1第五行）数据仓库以关系数据库为基础，无论是在数据类型方面还是在数据量方面都存在较大的限制。大数据决策可以面向类型繁多的、非结构化的海量数据进行决策分析。

7.举例说明大数据的具体应用。

（课本第15页表1-4）利用工业大数据提升制造水平、借助大数据分析用户行为进行商品推荐和有针对性的广告投放等

8.举例说明大数据的关键技术。

（课本第17页表1-5）数据采集与预处理、数据存储与管理、数据处理与分析、数据安全和隐私保护

9.大数据产业包含哪些层次？

（课本第19页表1-7）IT基础设施层、数据源层、数据管理层、数据分析层、数据平台层、数据应用层

10.详细阐述大数据、云计算和物联网三者之间的区别与联系。

（课本第28页图1-13）

第二章 大数据处理架构Hadoop

1.试述Hadoop和谷歌的MapReduce、GFS等技术之间的关系。

（课本第31页2.1.1第三行）Hadoop的核心是HDFS和MapReduce，而HDFS是针对GFS的开源实现。

2.试述Hadoop具有的特性。

（课本第32页2.1.3）高可靠性、高效性、高可扩展性、高容错性、成本低、支持运行在Linux操作系统上、支持多种编程语言

3.试述Hadoop在各个领域的应用现状。

（课本第32页2.1.4）现在已经在各个领域得到了广泛的应用，而互联网领域是其应用的“主阵地”

4.试述Hadoop生态系统以及每个子项目的具体功能。

（课本第34页图2-2）

5.试列举单机模式和伪分布式模式的异同点。

（课本第38-39页2.3.5/6）
不同点：单机模式数据的存储采用本地文件系统而伪分布式采用分布式文件系统HDFS
相同点：都需要通过配置文件对各组件的协同工作进行设置

6.Hadoop伪分布式运行启动后所具有的进程都有哪些？

（课本第41页最上方代码块）NameNode, SecondaryNameNode, DataNode

第三章 分布式文件系统HDFS

1.试述分布式文件系统设计的需求。

（课本第50页3.1.3）透明性、并发控制、文件复制、硬件和操作系统的异构性、可伸缩性、容错、安全

2.分布式文件系统是如何实现较高水平扩展的？

通过分层架构设计、数据分片存储、节点动态管理、负载均衡机制等核心技术

3.试述HDFS中的数据块和普通文件系统中的数据块的区别。

（课本第52页3.3.1）HDFS的数据块大小明显大于普通文件系统以最小化寻址开销，并且每个数据块都可以冗余存储到多个节点上提高系统的容错性

4.试述HDFS中的名称节点和数据节点的具体功能。

（课本第52-53页3.3.2）名称节点负责管理分布式文件系统的命名空间及客户端对文件的访问，保存了两个核心的文件，即FsImage和EditLog文件；数据节点是HDFS的工作节点，负责数据的存储和读取，会根据客户端或者名称节点的调度来进行数据的存储和检索，并且向名称节点定期发送自己所存储的数据块的列表信息。

5.在分布式文件系统中，中心节点的设计至关重要，请阐述HDFS是如何减轻中心节点的负担的。

架构设计优化、功能拆分、缓存机制、负载均衡策略等

6.HDFS只设置唯一一个名称节点，在简化系统设计的同时也带来了一些明显的局限性，请阐述局限性具体表现在哪些方面。

单点风险：缺乏高可用性设计，故障恢复成本高。
内存天花板：元数据规模受限于单节点内存，无法支撑海量小文件场景。
性能瓶颈：单线程处理和资源竞争导致元数据操作成为集群性能短板。
扩展僵化：计算与存储无法独立扩展，限制集群规模上限。

7.试述HDFS的冗余数据保存策略。

（课本第57-58页3.5.2）以机架为基础的数据存放策略，读取时有HDFS提供的一个API确定一个数据节点所属的机架ID，数据复制采用了流水线复制策略

8.数据复制主要在数据写入和数据恢复的时候发生，HDFS数据复制使用流水线复制策略，试阐述该策略的细节。

（课本第58页3.5.2.3）首先，这个文件会被写入本地，并被切分成若干个数据块，每个数据块的大小由HDFS的设定值决定。每个数据块都向HDFS集群中的名称节点发起写请求，名称节点会根据系统中各个数据节点的使用情况，选择一个数据节点列表返回给客户端。然后，客户端把数据写入列表中的第1个数据节点，同时把列表传给第1个数据节点。当第1个数据节点接收到4KB数据的时候，其将数据写入本地，并且向列表中的第2个数据节点发起连接请求，把自己已经接收到的4KB数据和列表传给第2个数据节点。以此类推，列表中的多个数据节点形成一条数据复制的流水线。最后，当文件写完的时候，数据复制也完成了。

9.试述HDFS是如何检测错误发生以及如何进行自动恢复的。

（课本第59页3.5.3）如果由于一些数据节点的不可用，导致一些数据块的副本数量小于冗余复制引子，就会启动数据冗余复制，为该数据块生成新的副本；如果数据块校验出错，客户端就会请求到另外一个数据节点读取数据块，并且向名称节点报告这个数据块有错误，名称节点会定期检查并重新复制这个数据块。

10.请阐述HDFS在不发生故障的情况下读文件的过程。

（课本第60页图3-8）

第四章 分布式数据库HBase

1.试述在 Hadoop 生态系统中 HBase 与其他组件的相互关系。

（课本第70页4.1.2）HBase利用Hadoop MapReduce来处理HBase中的海量数据，实现高性能计算；利用ZooKeeper作为协同服务，实现稳定服务和失败恢复；使用HDFS作为高可靠的底层数据存储系统，利用廉价集群提供海量数据存储能力。

2.请阐述 HBase 和 BigTable 的底层技术的对应关系。

（课本第71页表4-1）

项目	文件存储系统	海量数据处理	协同服务管理
BigTable	GFS	MapReduce	Chubby
HBase	HDFS	Hadoop MapReduce	ZooKeeper

3.请阐述 HBase 和传统关系数据库的区别。

（课本第71页4.1.3）数据类型、数据操作、存储模式、数据索引、数据维护和可伸缩性

4.HBase 支持哪些类型的访问接口?

（课本第72页4.2）Native Jave API、HBase Shell、Thrift Gateway、REST Gateway、Pig和Hive

5.请以实例说明 HBase 数据模型。

（课本第74页图4-2）

6.分别解释 HBase 中行键、列族、列限定符和时间戳的概念。

（课本第73页4.3.2）

• 行键：HBase表中每行数据的唯一标识符，按字典序排列存储以定位数据。
• 列族：表的顶层组织单元，需预先定义，同一族数据物理存储在一起并共享存储配置。
• 列限定符：列族下的具体列名，无需预先定义，与列族组合标识单元格数据。
• 时间戳：数据版本标识，默认由服务器生成，用于区分同一单元格的不同版本数据。

7.请列举实例来阐明 HBase 的概念视图和物理视图的区别。

（课本第75页4.3.5）从概念视图层面，HBase中的每个表是由许多行组成的，但是在物理层面，它采用基于列的存储方式，而不是像传统关系数据库那样采用基于行的存储方式。

8.试述 HBase 各功能组件及其作用。

（课本第78页4.4.1第一段）

• 库函数：链接到每个客户端
• 一个Master服务器：负责管理和维护HBase表的分区信息
• 许多个Region服务器：负责存储和维护分配给自己的Region

9.请阐述 HBase 的数据分区机制。

HBase以Region为单位分区，按行键字典序划分，数据量超阈值自动拆分，通过Master均衡Region分布，优化存储与访问效率。

10.HBase 中的分区是如何定位的?

（课本第81页4.4.3.2）

1. 客户端先通过ZooKeeper查询哪台Region服务器上有hbase:meta表
2. 客户端连接含有hbase:meta表的Region服务器
3. 获取这些信息后，客户端就可以直连其中一台拥有要存取的行键的Region服务器，并直接对其操作

11.试述 HBase的三层结构中各层次的名称和作用。

（课本第80页表4-7）

层次	名称	作用
第一层	ZooKeeper文件	记录了-ROOT-表的位置信息
第二层	-ROOT-表	记录了.META.表的Region位置信息，-ROOT-表只能有一个Region。通过-ROOT-表就可以访问.META.表中的数据
第三层	.META.表	记录了用户数据表的Region位置信息，.META.表可以有多个Region，保存了HBase中所有用户数据表的Region位置信息

12.请述在 HBase 两层结构下，客户端是如何访问到数据的。

HBase两层结构指Client-Master-RegionServer架构。客户端访问数据时：

1. 先从ZooKeeper获取hbase:meta表所在RegionServer地址，查询目标数据所属Region的行键范围和对应RegionServer。
2. 直接连接目标RegionServer，通过行键定位到具体Region，访问其MemStore或HFile读取数据。

（注：缓存Meta表信息减少交互开销）

13.试述HBase系统基本架构及其每个组成部分的作用。

（课本第81-82页4.5.1）

1. 客户端内含访问HBase的借口，同时在缓存中维护已经访问过的Region位置信息，以加快后续数据访问过程。
2. ZooKeeper服务器能够很容易地实现集群管理的功能，如果有多台服务器组成一个服务器集群，那么必须有一个“总管”知道当前集群中每台机器的服务状态。
3. Master服务器主要负责表盒Region的管理工作。
4. Region服务器是HBase中最核心的模块，负责维护分配给自己的Region，并响应用户的读写请求。

14.请闸述 Region 服务器向 HDFS 中读写数据的基本原理。

（课本第83页4.5.2.1）
写入：用户数据首先被写入MemStore和HLog文件中，当更新操作写入HLog文件之后，commit()调用才会将其返回给客户端。
读取：Region服务器会首先访问MemStore缓存，如果数据不在MemStore缓存中，Region服务器才会到磁盘上面的StoreFile中去寻找。

15.试述 Store 的工作原理。

（课本第84页4.5.3）当用户写入数据时，系统首先把数据放入MemStore缓存，当MemStore缓存满时，其内容就会被刷新并写入磁盘中的一个StoreFile文件中。当StoreFile文件数量不算增加，达到事先设定的数量时，就会触发文件合并操作，多个StoreFile文件会被合并成一个大的StoreFile文件。多个StoreFile文件合并会逐步形成越来越大的StoreFile文件，当单个StoreFile文件大小超过一定阈值时，就会触发文件分裂操作。同时，当前的一个父Region会被分裂成两个子Region。

16.试述 HLOg 文件的工作原理。

（课本第85页4.5.4）HBase系统为每个Region服务器配置了一个HLog文件，它是一种预写式日志，也就是说，用户更新数据必须先被记入日志才能写入MemStore缓存，并且直到MemStore缓存内容对应的日志已经被写入磁盘之后，该MemStore缓存里的内容才会被刷新并写入磁盘。

17.在 HBase 中，每个 Region 服务器只需要维护一个 HLog 文件，而不是每个 Region 都单独维护一个 HLog 文件。请说明这种做法的优点和缺点。

（课本第85页4.5.4）优点：减少磁盘寻址次数，提高对表的写操作性能。缺点：如果一个Region服务器发生故障，为了恢复其上的Region对象，需要将Region服务器上的HLog文件按照其所属的Region对象进行拆分，然后分发到其他Region服务器上执行恢复操作。

18.当一台 Region 服务器意外终止时,Master服务器如何发现这种意外终止情况?为了恢复这台发生意外的 Region 服务器上的 Region,Master 服务器会做出哪些处理(包括如何使用 HLog文件进行恢复)?

Master通过ZooKeeper会话超时（默认90秒）发现RegionServer终止。恢复时，先收集其Region列表并重新分配，再从HDFS获取该节点HLog，按Region拆分后回放日志到新节点，更新元数据后恢复服务。

19.请列举几个 HBase 常用的命令，并说明其使用方法。

create创建表，describe查看表的基本信息，list查看已经创建了哪些表，put添加数据，get用于查看表的某一个单元格数据，scan用于查看某个表的全部数据，delete用于删除一个单元格数据，deleteall用于删除一行数据，disable用于让表不可用，然后可以用drop删除表

第五章 NoSQL数据库

1.如何准确理解 NoSQL 数据库的含义?

（课本第102页5.1）NoSQL数据库是非关系数据库的统称，采用了一种不同于关系数据库的数据库管理系统设计方式，他所采用的数据模型并非传统关系数据库的关系数据模型，而是类似键值、列族、文档等非关系数据模型。

2.试述关系数据库在哪些方面无法满足 Web2.0应用的需求。

（课本第103页5.2.1）无法满足海量数据的管理需求，无法满足数据高并发的需求，无法满足高可扩展性和高可用性的需求

3.为什么说关系数据库的一些关键特性在 Web 2.0时代成为“鸡肋”?

（课本第104页5.2.2）Web 2.0网站通常不要求严格的数据库事务，Web 2.0并不要求严格的读写实时性，Web 2.0通常不包含大量复杂的SQL查询

4.请比较 NoSOL 数据库和关系数据库的优缺点。

（课本第105页5.3）关系型数据库的突出优势在于，以完备的关系代数理论作为基础，有严格的标准，严格遵守事务ACID四性，借助索引机制可以实现高效的查询，技术成熟，有大型厂商的技术支持；其劣势在于，可扩展性一般，无法较好地支持海量数据存储。NoSQL数据库的明显优势在于，可以支持超大规模数据存储，其灵活的数据模型可以很好地支持Web 2.0应用，具有强大的横向扩展能力等；其劣势在于，没有统一的数学理论基础，复杂查询性能不高，一般不能实现事务强一致性，很难实现数据完整性，技术尚不成熟，缺乏有力的技术支持，难以维护等。

5.试述 NoSOL 数据库的四大类型。

（课本第107页-108页5.4大标题）键值数据库，列族数据库，文档数据库，图数据库

6.试述键值数据库、列族数据库、文档数据库和图数据库的适用场合和优缺点。

（课本第107页-109页表5-2到5-5）

项目	键值数据库	列族数据库	文档数据库	图数据库
优点	可扩展性好、灵活性高、大量写操作时性能高	查找速度快、可扩展性强、容易进行分布式扩展、复杂性低	性能好、灵活性高、复杂性低、数据结构灵活	灵活性高、支持复杂的图算法、可用于构建复杂的关系图谱
缺点	无法存储结构化信息、条件查询效率较低	功能较少、大都不支持强事务一致性	缺乏统一的查询语法	复杂性高、只能支持一定的数据规模
适用场合	内容缓存，如会话、配置文件等	分布式数据存储与管理	存储、索引并管理面向文档的数据或者类似的半结构化数据	应用于大量复杂、互连接、低结构化的图结构场合，如社交网络、推荐系统等

7.试述 CAP 理论的具体含义。

（课本第110页5.5.1）

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

8.请举例说明不同产品在设计时是如何运用CAP理论的。

9.试述数据库的事务 ACID 四性的含义。

（数据库期末笔记）

10.试述 BASE的具体含义。

（课本第112页5.5.2）BASE的基本含义是基本可用、软状态和最终一致性。

11.请解释软状态、硬状态的具体含义。

（课本第112页5.5.2.2）“软状态”是指状态可以有一段时间不同步，具有一定的滞后性；“硬状态”是可以保证数据的一致性，即保证数据一直是正确的。

12.什么是最终一致性?

（课本第113页5.5.3）只要经过一段时间后能够访问到更新后的数据即可。

13.试述不一致性窗口的含义。

不一致性窗口指数据更新操作从发起至完成，系统中不同副本或节点间可能存在数据不一致的时间范围。

14.最终一致性根据更新数据后各进程访问到数据的时间和方式的不同，可以分为哪些不同类型的一致性?

（课本第113页5.5.3）因果一致性、“读己之所写”一致性、会话一致性、单调读一致性、单调写一致性

15.什么是 NewSQL 数据库?

（课本第113页5.6）NewSQL数据库是各种新的可扩展、高性能数据库的统称。

16.试述 NewSQL 数据库与传统关系数据库和 NoSQL 数据库的区别。

传统关系数据库（如MySQL、Oracle）：基于ACID特性，支持强事务一致性和复杂SQL查询，但扩展性较差，难以应对海量数据和高并发场景。
NoSQL数据库（如MongoDB、Cassandra）：强调高扩展性和高性能，支持分布式架构，但多数放弃强一致性（仅保证最终一致性），缺乏对复杂事务和SQL的支持。
NewSQL数据库（如TiDB、CockroachDB）：融合两者优势，既支持ACID事务和标准SQL（类似传统数据库），又具备水平扩展能力和高可用性（类似NoSQL），通过分布式架构实现数据分片、副本同步和故障容错，适用于兼具事务性和扩展性需求的场景（如互联网核心业务、实时分析等）。

第六章 云数据库

1.试述云数据库的概念。

（课本第120页6.1.2）云数据库是部署在云计算环境中的虚拟化数据库。

2.与传统的软件使用方式相比，云计算方式具有哪些明显的优势?

（课本第120页表6-1）

项目	传统的软件使用方式	云计算方式
获得软件的方式	自己投资建设机房，搭建硬件平台，购买软件并在本地安装	直接购买云计算厂商的软件服务
使用方式	本地安装，本地使用	软件运行在云计算厂商服务器上，用户在任何有网络接入的地方都可以通过网络使用软件服务
付费方式	需要一次性支付较大的初期投入成本，包括建设机房、配置硬件、购买各种软件（操作系统、杀毒软件、业务软件等）	零成本投入就可以立即获得所需的IT资源，只需要为所使用的资源付费，多用多付，少用少付
维护成本	需要自己花钱聘请专业技术人员维护	零成本，所有维护工作由云计算厂商负责
获得IT资源的速度	需要耗费较长时间建设机房、安装调试设备和系统	随时可用，购买服务后立即可用
共享方式	自己建设，自给自足	云计算厂商建设好云计算服务平台后，同时为众多用户提供服务
维修速度	出现病毒、系统崩溃等问题时，需要自己聘请IT人员维护，很多小企业的IT人员技术能力有限，碰到一些问题甚至需要寻找外援，通常不能立即解决	出现任何系统问题时，云计算厂商都会依靠其专业化团队给出及时的响应，确保云服务的正常使用
资源利用率	资源利用率较低，投入大量资金建设的IT系统，往往只供企业自己使用，当企业不需要那么多IT资源时，就会产生资源浪费	资源利用率较高，每天都可以为大量用户提供服务；当存在闲置资源时，云计算管理系统会自动关闭和撤出多余资源；当需要增加资源时，云计算管理系统又会自动启动和加入相关资源
企业搬迁时的成本	当企业搬迁时，原来的机房设施要作废，需要在新地方重新投入较大成本建设机房	企业无论搬迁到哪里，都可以通过网络重新零成本立即获得云计算服务，因为资源在云端，不在客户端，企业搬迁不会影响IT资源的分布
资源可扩展性	企业自己建设的IT基础设施的服务能力通常是有限的，当企业业务量突然增加时，现有的IT基础设施无法立即满足需求，就需要花费时间和金钱购买和安装新设备；当业务高峰过去时，多余的设备就会闲置，造成资源浪费	云计算厂商可以为企业提供近乎无限的IT资源（存储和计算等资源），企业想用多少都可以立即获得；当企业不使用时，只需退订多余资源，几乎不存在资源浪费问题

3.云数据库有哪些特性?

（课本第121页6.1.3大标题）动态可扩展性、高可用性、较低的使用代价、易用、高性能、免维护、安全

4.试述云数据库的影响。

• 对企业的影响：降低企业IT建设成本，快速获取资源，灵活应对业务变化，专注核心业务；
• 对行业的影响：推动数据驱动创新，加速各行业数字化转型，催生新应用模式；
• 对技术生态的影响：促进数据库技术发展，带动云计算、大数据等关联技术融合，重塑技术生态格局 。

5.举例说明主流云数据库厂商及其代表性产品。

（课本第124页表6-3）

厂商	产品
亚马逊	DynamoDB、SimpleDB、RDS
谷歌	Cloud SQL
微软	Microsoft SQL Azure
Oracle	Oracle Cloud
雅虎	PNUTS
Vertica	Analytic Database for the Cloud
EnterpriseDB	Postgres Plus in the Cloud
阿里	阿里云 RDS
百度	百度云数据库
腾讯	腾讯云数据库
华为	华为云数据库

6.试述 Microsoft SQLAzure 的体系架构。

（课本第126页图6-2）

7.试述 UMP 系统的功能。

（课本第130页6.3.3大标题）容灾、读写分离、分库分表、资源管理、资源调度、资源隔离、数据安全

8.试述 UMP 系统的组件及其具体作用。

1. UMP Proxy：作为接入层组件，负责接收客户端请求，实现分库分表、读写分离及请求路由。
2. UMP Manager：承担资源与实例管理，负责数据库实例创建、配置管理及多租户资源分配。
3. UMP Monitor：监控组件，实时采集数据库性能指标（如QPS、延迟等），支持故障预警。
4. UMP Backup：备份恢复组件，定期对数据库数据和日志进行备份，保障数据可靠性与可恢复性。
5. MySQL Instances：底层数据存储组件，提供实际数据库服务，支持高并发数据读写与存储。
6. Router：路由组件，配合Proxy实现数据分片规则管理，确保请求准确转发至目标数据库实例。

9.试述 UMP 系统实现主从备份的方法

（课本第130页6.3.3.1）主库和从库的状态是由ZooKeeper负责维护的，ZooKeeper可以实时监听各个MySQL实例的状态，一旦主库死机，ZooKeeper可以立即感知到，并通知Controller服务器。Controller服务器会启动主从切换操作，在路由表中修改用户名与后端MySQL实例地址的映射关系，并把主库标记为不可用，同时，借助消息中间件RabbitMQ通知所有Proxy服务器修改用户名与后端MySQL实例地址的映射关系。通过这一系列操作后，主从切换完成。

10.试述 UMP 系统读写分离的实现方法

（课本第130页6.3.3.2）当整个功能被开启时，负责向用户提供访问MySQL数据库服务的Proxy服务器，就会对用户发起的SQL语句进行解析。如果该SQL语句属于写操作，就直接发送到主库；如果该SQL语句属于读操作，就会被均衡地发送到主库和从库上执行。

11.UMP 系统采用哪两种方式实现资源隔离?

（课本第131页6.3.3.4）UMP系统在每台服务器内部采用Cgroup将资源进一步细分，从而限制每个进程组使用资源的上限，同时保证进程组之间相互隔离。

12.试述 UMP 系统中的3种类型的用户。

（课本第131页6.3.3.5）数据量和流量比较小的小规模用户、中等规模用户、需要分库分表的用户

13.UMP 系统如何保障数据安全?

（课本第132页6.3.3.7）SSL数据库连接、数据访问IP地址白名单、记录用户操作日志、SQL拦截

第七章 MapReduce

1.试述 MapReduce 和 Hadoop 的关系。

Hadoop 是平台，MapReduce 是 Hadoop 里实现分布式计算的关键工具，Hadoop 用 MapReduce “干活”，MapReduce 靠 Hadoop 的存储、资源管理来运行。

2. MapReduce 是处理大数据的有力工具，但不是每个任务都可以使用 MapReduce 来进行处理的。试述适合用 MapReduce 来处理的任务或者数据集需要满足怎样的要求。

数据量大且可拆分、计算逻辑能分解为局部处理 + 全局汇总、以批处理为目标、容忍分布式系统的容错特性。

3. MapReduce 计算模型的核心是 Map 函数和 Reduce 函数，试述这两个函数各自的输入、输出以及处理过程。

（课本第135页表7-1）

函数	输入	输出	说明
Map	<k₁,v₁>	List(<k₂,v₂>)	（1）将小数据集进一步解析成一批<key,value>，输入Map函数中进行处理。 （2）对于每一个输入的<k₁,v₁>，会对应输出一个或一批<k₂,v₂>，<k₂,v₂>是计算的中间结果
Reduce	<k₂,List(v₂)>	<k₃,v₃>	输入的中间结果<k₂,List(v₂)>中的List(v₂)表示一个或一批属于同一个k₂的值

4.试述 MapReduce 的工作流程（需要包括提交任务、Map、Shuffle、Reduce 过程 ）。

1. 提交任务：客户端提交作业，JobTracker分配资源、启动JobClient 。
2. Map阶段：输入数据分片，Map任务读分片，转<k₁,v₁>为中间结果<k₂,v₂>，存本地 。
3. Shuffle阶段：Map端溢写、合并排序；Reduce端拉取、合并成<k₂,List(v₂)> 。
4. Reduce阶段：Reduce任务执行函数，聚合得<k₃,v₃>，输出到HDFS ，任务完成清理 。

5. Shuffle 过程是 MapReduce 工作流程的核心，也被称为“奇迹发生的地方”，试分析 Shuffle 过程的作用。

（课本第138页7.2.3.1）Shuffle是指对Map任务输出结果进行分区、排序、合并、归并等处理并交给Reduce的过程。

6.分别描述 Map 端和 Reduce 端的 Shuffle 过程（需要包括溢写、归并、“领取”的过程 ）。

（课本第138-141页7.2.3） 简化题目不要求描述的过程后剩这些

Map端Shuffle

1. 溢写：Map任务输出的<k₂,v₂>先入环形缓冲区，满阈值（如80%）时，按k₂排序、分区，写入本地磁盘溢写文件。
2. 归并：多个溢写文件合并为大文件，保留排序和分区，减少后续传输量，为Reduce做准备。

Reduce端Shuffle

1. 领取：Reduce任务通过HTTP，从各Map任务本地磁盘拉取对应分区的<k₂,v₂>数据。
2. 归并：拉取的多份数据合并，形成<k₂,List(v₂)> ，为Reduce函数提供输入，完成Shuffle 。

7.试说明一个 MapReduce 程序在运行期间所启动的 Map 任务数量和 Reduce 任务数量各是由什么因素决定的。

Map任务数量

由输入数据分片数决定，Hadoop按HDFS块大小（默认128MB ，可配）切分输入数据为InputSplit，分片数即Map任务数；同时受文件格式、InputFormat影响，不同格式分片逻辑有别，如文本文件用TextInputFormat按行切分。

Reduce任务数量

• 用户显式设置：开发者通过job.setNumReduceTasks(int num)指定数量。
• 分区策略：若未显式设置，默认1个；Map输出经Partitioner分区（默认HashPartitioner按hash(k₂) % Reduce任务数 ），分区数对应Reduce任务数，需与分区逻辑适配 。

8.是否所有的 MapReduce 程序都需要经过 Map 和 Reduce 这两个过程？如果不是，请举例说明。

当任务满足 “数据处理无需全局聚合，仅需对分片独立处理” 时，可跳过 Reduce

9.试分析为何采用 Combiner 可以减少数据传输量。是否所有的 MapReduce 程序都可以采用 Combiner？为什么？

（课本第140页第一段）如果磁盘中只有一两个溢写文件，执行合并操作就会“得不偿失”，因为执行合并操作本身也需要代价，所以不需要运行Combiner。

10. MapReduce 程序的输入文件、输出文件都存储在 HDFS 中，而在 Map 任务完成时得到的中间结果存储在本地磁盘中。试分析中间结果存储在本地磁盘而不是 HDFS 上的优缺点。

优点

• 性能高：本地磁盘读写快，避免网络传输延迟。
• 省资源：减少网络带宽占用和HDFS存储成本。
• 易恢复：Map任务失败时重启更快（无需远程读取）。

缺点

• 可靠性低：本地磁盘故障可能丢失数据。
• 共享性差：其他节点/任务无法直接访问中间结果。
• 管理复杂：需维护各节点本地磁盘空间。

11.试画出使用 MapReduce 对英语句子 “Whatever is worth doing is worth doing well” 进行词频统计的过程。

（参考课本第143页图7-7和第144页图7-8）

12.在基于 MapReduce 的词频统计中，MapReduce 如何保证相同的单词数据会划分到同一个 Reducer 上进行处理以保证结果的正确性？

Shuffle阶段的排序和分组

13. MapReduce 可用于对数据进行排序，有一种想法是利用 MapReduce 的自动排序功能，即在默认情况下，Reduce 任务的输出结果是有序的，如果只使用一个 Reducer 来对数据进行处理、输出，则结果就是有序的了。但这样的排序过程无法充分利用 MapReduce 的分布式优点。试设计一个基于 MapReduce 的排序算法，假设数据均位于 [1,100]，Reducer 的数量为 4，正序输出结果或逆序输出结果均可。试简要描述该算法（可使用分区、合并过程 ）。

1. 数据分区（Map 阶段）：

   • 自定义 RangePartitioner，将输入数据按值划分为 4 个区间：

     Reducer 0: [1, 25]  
     Reducer 1: [26, 50]  
     Reducer 2: [51, 75]  
     Reducer 3: [76, 100]  
     

   • Map 输出键值对为 <数据值, NullWritable>，分区函数为：
     partition = (value-1) / 25（确保每个值被分配到正确区间）。

2. 局部排序（Reduce 阶段）：

   • 每个 Reducer 接收对应区间的数据（如 Reducer 0 接收 [1,25]）。
   • 默认情况下，MapReduce 对每个 Reducer 的输入按键排序（即区间内有序）。
   • Reduce 函数直接输出键值对，无需额外处理。

3. 全局有序输出：

   • 按 Reducer 编号（0→3）依次读取输出文件，合并后即为全局有序结果。
   • 若需逆序，调整分区规则为降序区间（如 Reducer 0: [100,76]）。

14.试设计一个基于 MapReduce 的算法，求出数据集中的最大值。假设 Reducer 的数量大于 1，试简要描述该算法（可使用分区、合并过程 ）。

1. 数据分区（Map 阶段）：

   • 将输入数据随机或按范围分区，确保每个 Reducer 处理一部分数据。
   • Map 输出键值对为 <固定键, 当前值>（如 <"max", 5>），固定键确保所有值被发送到同一个 Reducer。

2. 局部最大值计算（Reduce 阶段）：

   • 每个 Reducer 接收一部分数据，计算局部最大值：

     public class MaxReducer extends Reducer<Text, IntWritable, Text, IntWritable> {
         public void reduce(Text key, Iterable<IntWritable> values, Context context) {
             int max = Integer.MIN_VALUE;
             for (IntWritable value : values) {
                 max = Math.max(max, value.get());
             }
             context.write(key, new IntWritable(max)); // 输出局部最大值
         }
     }
     

3. 全局最大值合并（二次 MapReduce）：

   • 将所有 Reducer 的输出作为新输入，再次执行 MapReduce：
     • Map：读取每个局部最大值，输出 <固定键, 局部最大值>。
     • Reduce：重复上述逻辑，计算所有局部最大值的最大值，得到全局结果。

15. 对于稀疏矩阵的乘法，试思考出与正文中矩阵乘法所采用的不同的 MapReduce 策略，写出相应的 Map 函数和 Reduce 函数。

（1）输入数据表示

将稀疏矩阵 $M(m\times n)$、$N(n\times p)$ 按 “坐标 - 值” 存储，如三元组 $⟨i,j,m_{ij}⟩$（矩阵 $M$）、$⟨j,k,n_{jk}⟩$（矩阵 $N$），其中 $m_{ij}\ne 0$、$n_{jk}\ne 0$。

（2）Map 函数：关联可乘元素

• 输入：矩阵 $M$ 的三元组 $⟨i,j,m_{ij}⟩$ 和矩阵 $N$ 的三元组 $⟨j,k,n_{jk}⟩$（通过文件区分或标记）。
• 输出：以公共维度 $j$ 为键，输出可相乘的元素对，格式为：

  Key: j  
  Value: (M, i, m_{ij}) 或 (N, k, n_{jk})  
  

  （用标记区分来自矩阵 $M$ 或 $N$ 的数据，方便 Reduce 阶段识别）

（3）Reduce 函数：计算非零乘积和

• 输入：键 $j$ 对应的所有值，包含矩阵 $M$ 的 $⟨i,m_{ij}⟩$ 和矩阵 $N$ 的 $⟨k,n_{jk}⟩$。
• 逻辑：
  1. 分离 $M$ 和 $N$ 的数据，得到列表 $M\_list=[⟨i,m_{ij}⟩]$、$N\_list=[⟨k,n_{jk}⟩]$。
  2. 遍历 $M\_list$ 和 $N\_list$，对每个 $m_{ij}\in M\_list$、$n_{jk}\in N\_list$，计算乘积 $m_{ij}\times n_{jk}$，并按结果矩阵的坐标 $⟨i,k⟩$ 累加。
• 输出：结果矩阵的非零元素，格式为 $⟨i,k,\sum (m_{ij}\times n_{jk})⟩$（仅当和大于 0 时输出，确保稀疏性）。

16. 当输入为由许多整数构成的文件、输出为最大整数时，试设计 MapReduce 算法实现该功能，并写出 Map 函数和 Reduce 函数。

Map 函数实现

public class MaxIntegerMapper extends Mapper<LongWritable, Text, Text, IntWritable> {
    private final Text KEY = new Text("max");
    private IntWritable currentMax = new IntWritable(Integer.MIN_VALUE);

    @Override
    protected void map(LongWritable key, Text value, Context context) {
        try {
            int num = Integer.parseInt(value.toString());
            if (num > currentMax.get()) {
                currentMax.set(num);
            }
        } catch (NumberFormatException | IOException | InterruptedException e) {
            // 处理异常（如非整数格式）
            e.printStackTrace();
        }
    }

    @Override
    protected void cleanup(Context context) throws IOException, InterruptedException {
        context.write(KEY, currentMax); // 输出当前块的局部最大值
    }
}

Reduce 函数实现

public class MaxIntegerReducer extends Reducer<Text, IntWritable, Text, IntWritable> {
    @Override
    protected void reduce(Text key, Iterable<IntWritable> values, Context context) {
        int globalMax = Integer.MIN_VALUE;
        for (IntWritable value : values) {
            globalMax = Math.max(globalMax, value.get());
        }
        context.write(key, new IntWritable(globalMax)); // 输出全局最大值
    }
}

17.试述实现矩阵 - 向量乘法与矩阵乘法采用不同 MapReduce 策略的原因。

矩阵-向量乘法只需按行并行计算，结果向量元素间无依赖，适合按行划分矩阵；而矩阵乘法需跨矩阵协作（行×列），同一行/列数据需被复用，需按公共维度分区。二者数据依赖模式、计算复杂度不同，故策略不同。

18.为非方阵矩阵（即行数与列数不等的矩阵 ）的乘法运算设计一般化的 MapReduce 算法，并写出 Map 函数和 Reduce 函数。

public class MatrixMultiplication {

    public static int colA = 3; // 矩阵A的列数
    public static int rowB = 3; // 矩阵B的行数

    public static class MatrixMapper extends Mapper<LongWritable, Text, Text, Text> {

        private Text outputKey = new Text();
        private Text outputValue = new Text();

        @Override
        protected void map(LongWritable key, Text value, Context context)
                throws IOException, InterruptedException {
            FileSplit fileSplit = (FileSplit) context.getInputSplit();
            String fileName = fileSplit.getPath().getName();

            String[] tokens = value.toString().trim().split(",");
            int i = Integer.parseInt(tokens[0]);
            int j = Integer.parseInt(tokens[1]);
            double val = Double.parseDouble(tokens[2]);

            if (fileName.contains("matrixA")) {
                for (int k = 0; k < rowB; k++) {
                    outputKey.set(i + "," + k);
                    outputValue.set("A," + j + "," + val);
                    context.write(outputKey, outputValue);
                }
            } else if (fileName.contains("matrixB")) {
                for (int k = 0; k < colA; k++) {
                    outputKey.set(k + "," + j);
                    outputValue.set("B," + i + "," + val);
                    context.write(outputKey, outputValue);
                }
            }
        }
    }

    public static class MatrixReducer extends Reducer<Text, Text, Text, Text> {

        private Text outputValue = new Text();

        @Override
        protected void reduce(Text key, Iterable<Text> values, Context context)
                throws IOException, InterruptedException {
            double[] matrixA = new double[colA];
            double[] matrixB = new double[rowB];

            for (Text val : values) {
                String[] parts = val.toString().split(",");
                if (parts[0].equals("A")) {
                    matrixA[Integer.parseInt(parts[1])] = Double.parseDouble(parts[2]);
                } else {
                    matrixB[Integer.parseInt(parts[1])] = Double.parseDouble(parts[2]);
                }
            }

            double sum = 0;
            for (int j = 0; j < colA; j++) {
                sum += matrixA[j] * matrixB[j];
            }

            outputValue.set(String.valueOf(sum));
            context.write(key, outputValue);
        }
    }
}    

第八章 Hadoop再探讨

1.试述在 Hadoop 推出之后其优化与发展主要体现在哪两个方面。

（课本第158页8.1.2）Hadoop框架自身的改进与提升、不断完善的Hadoop生态系统

2.试述 HDFS 1.0 中只包含一个名称节点会带来哪些问题。

（课本第159页第二三行）一旦这个唯一地名称节点发生故障，就会导致整个集群变得不可用，这就是常说的“单点故障问题”。

3.请描述组成 HDFS HA 架构的组件及其具体功能。

1. Active NameNode：处理客户端读写请求，维护元数据，将变更写入 JournalNode。
2. Standby NameNode：同步 Active 状态，在故障时接替服务，读取 JournalNode 更新自身。
3. JournalNode 集群：存储 EditLog，通过多数表决确保元数据一致性，支持多 NN 同步。
4. ZooKeeper 集群：协调 NN 选举，监控健康状态，触发故障转移。
5. ZKFC（ZooKeeper Failover Controller）：监控 NN 健康，执行故障切换与 fencing，防止脑裂。
6. DataNode：向所有 NN 发送心跳和块报告，响应 Active NN 的数据操作指令。
7. 客户端：通过逻辑名称服务透明访问集群，自动重定向至 Active NN。

4. 请分析 HDFS HA 架构中数据节点如何和名称节点保持通信。

HDFS HA架构中，DataNode 启动时获取所有 NameNode（Active 和 Standby ）地址，定期向二者发心跳与块报告 。Active 处理心跳并下发指令，Standby 仅同步状态。故障切换时，DataNode 借 ZooKeeper 感知新 Active，自动重连，同时 ZKFC 执行 fencing 防止脑裂，保障通信持续与元数据一致 。

5.请阐述为什么需要 HDFS 联邦，即它能够解决什么问题。

（课本第160页8.2.2.1）单点故障问题、可扩展性问题、系统整体性能问题、隔离性问题

6. 请描述 HDFS 联邦中“块池”的概念，并分析为什么 HDFS 联邦中的一个名称节点失效，也不会影响与它相关的数据节点继续为其他名称节点提供服务。

（课本第160页8.2.2.2）HDFS联邦拥有多个独立的命名空间，其中每一个命名空间管理属于自己的一组数据块，这些属于同一个命名空间的数据块构成一个“块池”。数据节点是一个物理概念，块池则是一个逻辑概念，一个块池是一组数据快的逻辑集合，块池中的各个数据块实际上存储在各个不同的数据节点中，因此失效不影响。

7.请阐述 MapReduce 1.0 的体系结构中存在的缺陷。

（课本第162页8.3.1大标题）存在单点故障问题、JobTracker“大包大揽”导致任务过重、容易出现内存溢出、资源划分不合理

8. 请描述 YARN 体系结构中各组件的功能。

1. ResourceManager (RM)：全局资源调度，分配容器，主备模式保障高可用。
2. NodeManager (NM)：管理节点资源，按 RM 指令启动/监控容器，汇报节点状态。
3. ApplicationMaster (AM)：每个应用专属，向 RM 协商资源，调度子任务至 NM。
4. Container：资源隔离单元，由 NM 管理，运行具体任务。
5. 客户端：提交应用，查询状态。

9.请描述在 YARN 框架中执行一个 MapReduce 程序时，从提交到完成需要经历的具体步骤。

提交应用程序

用户编写客户端应用程序，向 YARN 提交包含 ApplicationMaster 程序、启动 ApplicationMaster 的命令、用户程序（如 MapReduce 作业相关代码、数据等）的应用。

分配首个容器并启动 ApplicationMaster

YARN 中 ResourceManager 接收客户端请求后，其资源调度器为应用分配一个容器 ，同时 ResourceManager 的应用程序管理器与该容器所在 NodeManager 通信，在容器中启动 ApplicationMaster（如 MapReduce 作业对应的 MR App Mstr ）。

ApplicationMaster 注册

ApplicationMaster 被创建后，向 ResourceManager 注册，这样用户可通过 ResourceManager 查看应用运行状态。

申请资源

ApplicationMaster 采用轮询方式，通过 RPC 协议向 ResourceManager 申请执行 MapReduce 任务所需资源（如 CPU、内存等 ）。

分配资源并通信

ResourceManager 以“容器”形式，将资源分配给提出申请的 ApplicationMaster 。ApplicationMaster 拿到资源后，与对应容器所在的 NodeManager 通信，要求启动任务（Map 任务、Reduce 任务等 ）。

启动任务

ApplicationMaster 为任务设置运行环境（环境变量、JAR 包、二进制程序等 ），将任务启动命令写入脚本，在容器中运行脚本，启动 Map 任务、Reduce 任务等。

任务状态汇报与监控

各任务通过 RPC 协议向 ApplicationMaster 汇报自身状态和进度，ApplicationMaster 实时掌握任务运行情况，若任务失败则重启任务。

完成与注销

应用程序（MapReduce 作业）运行完成后，ApplicationMaster 向 ResourceManager 的应用程序管理器注销并关闭自己。若 ApplicationMaster 自身失败，ResourceManager 中的应用程序管理器会监测到并重启它，直至所有任务执行完毕。

10. 请对 YARN 和 MapReduce 1.0 框架进行优劣势对比分析。

（课本第166页8.3.5）大大减少了承担中心服务功能的ResourceManager的资源消耗、MapReduce 1.0既是一个计算框架，又是一个资源调度管理框架，但是它只能支持MapReduce编程模型，而YARN是一个纯粹的资源调度管理框架、YARN中的资源管理比MapReduce 1.0中的更加高效。

第九章 数据仓库Hive

1.数据仓库的4个特性是什么？

（课本第169页9.1）面向主题、集成、相对稳定、反映历史变化

2. 一个典型的数据仓库系统包含哪些组成部分以及各自的功能是什么？

（课本第170页9.1）数据源、数据存储和管理、OLAP服务器、前端工具和应用

3.试述数据湖的概念。

（课本第171页9.2）数据湖是一个以原始格式存储数据的存储库或系统，它按原样存储数据，而无须事先对数据进行结构化处理。

4.试述数据湖与数据仓库的区别。

（课本第172页表9-2）数据湖与数据仓库的区别

特性	数据仓库	数据湖
存放数据的类型	结构化数据，抽取自事务系统、运营数据库和业务应用系统	所有类型的数据，结构化、半结构化和非结构化数据
数据模式	通常在数据仓库实施之前设计，但也可以在数据分析时编写	在分析时编写
性价比	起步成本高，使用本地存储以获得最快查询结果	起步成本低，计算与存储分离
数据质量	可作为重要事实依据的数据	包含原始数据在内的任何数据
最适合使用的对象	业务分析师为主	数据科学家、数据开发人员为主
具体应用场景	批处理报告、BI、可视化分析	机器学习、探索性分析、数据发现、流处理、大数据与特征分析

5.数据湖能够解决哪些企业问题？

（课本第173页9.2.3）数据分散，存储散乱，形成数据孤岛，无法联合数据发现更多价值；存储成本问题；SQL无法满足分析需求；存储、计算可扩展性不足；业务模型不定，无法预先建模。

6.什么是湖仓一体？

（课本第174页9.3）湖藏一体是一种新型的开放式架构，它打通了数据仓库和数据湖，将数据仓库的高性能及管理能力与数据湖的灵活性融合起来，底层支持多种数据类型并存，能实现数据间的相互共享，上层可能通过统一封装的接口进行访问，可同时支持实时查询和分析，为企业进行数据治理带来了更多的便利性。

7.“湖仓一体”架构具有哪些特性？

（课本第174页9.3）事务支持；数据治理；BI支持；存算分离；开放性；支持多种数据类型

8.试述在Hadoop生态系统中Hive与其他组件之间的关系。

（课本第175页图9-6）

9.请简述Hive与传统数据库的区别。

（课本第176页表9-3）Hive与传统数据库的对比分析

对比方面	Hive	传统数据库
数据存储	HDFS	本地文件系统
索引	支持有限索引	支持复杂索引
分区	支持	支持
执行引擎	MapReduce、Tez、Spark	自身的执行引擎
执行延迟	高	低
可扩展性	好	有限
数据规模	大	有限

10.请简述Hive的几种访问方式。

1. 命令行界面（CLI）：直接输入hive启动，适合交互式查询。
2. HiveServer2 + Beeline：服务端-客户端模式，支持多用户并发与认证。
3. JDBC/ODBC：通过标准接口供Java或其他语言程序调用。
4. Web UI（HWI）：基于Web的简易界面（逐渐被弃用）。
5. Thrift API：支持跨语言远程调用。

11.请分别对Hive的几个主要组成模块进行简要介绍。

（课本第178页9.5）用户接口模块用来实现外部应用对Hive的访问；驱动模块负责把HiveQL语句转换成一系列MapReduce作业；元数据存储模块通常是与MySQL数据库连接后创建的一个MySQL实例，也可以是Hive自带的serby数据库实例。

12.请简述向Hive中输入一个查询的具体执行过程。

*（课本第181页图9-12）

13.请简述Hive HA的基本原理。

（课本第182页图9-13）

14.请简述Impalad进程的主要作用。

（课本第182页9.8.1）它提供了SQL语义，能查询存储在Hadoop的HDFS和HBase上的PB级别的海量数据。

15.请比较Hive与Impala的异同点。

（课本第184页9.8.4）
以下是整理后的Hive与Impala异同点对比表格：

对比维度	Hive	Impala
架构与执行方式	基于Hadoop，依赖MapReduce/Tez/Spark执行，批处理为主	基于HDFS，用专属执行引擎（如LLVM编译），侧重交互式查询
查询延迟	高（分钟级/小时级），适合长时批处理	低（秒级/亚秒级），适合实时交互式分析
执行计划	将任务拆分为MapReduce管道	生成完整执行计划树，分发到Impalad并行执行
内存处理	内存不足时用外存保证任务完成	内存不足时不使用外存，更适合小输出结果查询
存储依赖	共享HDFS、HBase存储，支持TXT、RCFile等格式	同Hive，依赖HDFS、HBase存储及相同文件格式
元数据	共用元数据（如MySQL存储的元数据）	与Hive共用元数据
SQL解析	通过词法分析生成执行计划	同Hive，SQL解释处理流程相似
典型场景	离线批处理、复杂ETL、大规模历史数据挖掘	实时即席查询、交互式数据分析、结果集快速探索
生态配合	常与MapReduce配合，适合先ETL再分析	与Hive配合最佳，Hive做数据转换，Impala做快速分析

16.请简述State Store的作用。

（课本第183页9.8.2.2）负责收集分布在集群中各个Impalad的资源信息，用于查询的调度。

17.请简述Impala执行一个查询的具体过程。

（课本第184页图9-16）

18.请列举Hive中的列所支持的3种集合数据类型。

（课本第185页表9-5）Hive中的列所支持的3种集合数据类型

类型	描述	示例
ARRAY	一组有序字段，字段的类型必须相同	Array(1,2)
MAP	一组无序的键值对，键的类型必须是原子的，值可以是任何数据类型，同一个映射的键和值的类型必须相同	Map(‘a’,1,‘b’,2)
STRUCT	一组命名的字段，字段的类型可以不同	Struct(‘a’,1,1.0)

19.请列举几个Hive的常用操作及其基本语法。

（课本第186页9.9.2大标题）

• create创建数据库、表、视图
• drop删除数据库、表、视图
• alter修改数据库、表、视图
• show查看数据库、表、视图
• describe描述数据库、表、视图
• load向表中装载数据
• select查询表中数据
• insert向表中插入数据

第十章 Spark

1.Spark是基于内存计算的大数据计算平台，试述Spark的主要特点。

（课本第194页10.1.1）运行速度快，容易使用，通用，运行模式多样

2.Spark的出现是为了弥补Hadoop MapReduce的不足，试列举Hadoop存在的几个缺点，并说明Spark具备哪些优点。

（课本第194页10.1.3）
Hadoop的缺点：表达能力有限；磁盘I/O开销大；延迟高
Spark的优点：编程模型比MapReduce更灵活；迭代运算效率更高；基于DAG的任务调度执行机制比MapReduce的迭代执行机制更优

3.BDAS认为目前的大数据处理可以分为哪3种模型？

批处理模型、流式处理模型、图处理模型

4.Spark已打造出结构一体化、功能多样化的大数据生态系统，试述Spark的生态系统。

（课本第197页10.2大标题）

• Spark Core包含Spark的基本功能，如内存计算、任务调度、部署模式、故障恢复、存储管理等
• Spark SQL允许开发人员直接处理RDD，同时也允许查询Hive、HBase等外部数据源
• Spark Streaming支持高吞吐量、可容错处理的实时流数据处理
• Structured Streaming是一种基于Spark SQL引擎构建的、可扩展且容错的流处理引擎
• MLlib提供了常用机器学习算法的实现，包括聚类、分类、回归、协同过滤等
• GraphX是Spark中用于图计算的API，可认为是Pregel在Spark上的重写及优化

5.从“Hadoop+Storm”架构转向Spark架构有哪些优点？

（课本第210页10.4.2）

• 实现一键式安装和配置、线程级别的任务监控和警告
• 降低硬件集群、软件维护、任务监控和应用开发的难度
• 便于集成统一的硬件、计算平台资源池

6.试述“Spark on YARN”的概念。

（课本第209页10.4.1.3）资源管理和调度依赖于YARN，分布式存储则依赖于HDFS

7.试述如下Spark的几个主要概念：RDD、DAG、阶段、分区、窄依赖、宽依赖。

• RDD：Spark 中核心数据结构，是一个容错、并行的不可变数据集合，可分区存储在集群节点上。
• DAG：由 RDD 及转换操作构成的逻辑执行图，反映了计算过程中各操作间的依赖关系和执行顺序 。
• 阶段：根据 RDD 依赖关系划分的任务执行阶段，一个 DAG 会被切分为多个阶段，以优化执行。
• 分区：RDD 在物理上被划分成的多个数据块，可并行处理，提升计算效率。
• 窄依赖：父 RDD 的每个分区最多被一个子 RDD 的分区使用，如 map、filter 操作产生的依赖关系，便于优化和恢复。
• 宽依赖：父 RDD 的一个分区会被多个子 RDD 的分区使用，如 shuffle 操作产生的依赖，通常伴随着数据重新分布。

8.Spark对RDD的操作主要分为行动和转换两种类型，两类操作的区别是什么？

（具体过程见课本第212页10.5.2）

操作类型	执行时机	返回结果类型	对数据的影响	示例操作
转换（Transformation）	延迟计算，仅记录逻辑，构建 DAG	返回新 RDD	定义数据处理流程，不实际处理数据	map、filter、union
行动（Action）	触发实际计算，提交作业执行	返回数值、集合等（如 count 返回复数，collect 返回本地集合）	触发数据计算、处理，读取/返回/存储数据	count、collect、saveAsTextFile

第十一章 流计算

1.试述流数据的概念。

（课本第225页11.1.1.2）数据以大量、快速、时变的流形式持续到达

2.试述流数据的特点。

（课本第226页11.1.1.2）

• 数据快速、持续到达，潜在数据量也许是无穷无尽的
• 数据来源众多，格式复杂
• 数据量大，但是不十分关注存储，流数据中的某个数据一旦经过处理，要么被丢弃，要么被归档存储
• 注重数据的整体价值，不过分关注个别数据
• 数据顺序颠倒，或者不完整，系统无法控制将要处理的新到达的数据元素的顺序

3.在流计算的理念中，数据的价值与时间具备怎样的关系?

（课本第226页11.1.3）数据的价值随着时间的流逝而降低

4.试述流计算的需求。

（课本第226页11.1.3）高性能，支持海量数据，实时，支持分布式，易用，高可靠

5.试述 MapReduce 框架为何不适用于处理流数据。

（课本第227页11.1.4）MapReduce这种批量任务处理方式在时延方面是无法满足流计算的实时响应需求的

6.将基于 MapReduce 的批量处理转换为小批量处理，每隔一个周期就启动一次 MapReduce作业，通过这样的方式来处理流数据是否可行?为什么?

（课本第227页11.1.4）增加了任务处理的附加开销；大大增加了MapReduce框架的复杂度，导致系统难以维护和扩展；降低了用户程序的可伸缩性

7.列举几个常见的流计算框架。

（课本第228页11.1.5）IBM InfoSphere Streams、IBM StreamBase、Twitter Storm、Yahoo! S4、DStream、银河流数据处理平台、Super Mario

8.试述流计算的一般处理流程。

（课本第229页11.2大标题）数据实时采集、数据实时计算、实时查询服务

9.试述流计算处理流程与传统的数据处理流程的主要区别。

（课本第228页11.2.1）传统数据处理流程存储的数据是旧的，用户需要主动发出查询

10.试述数据实时采集系统的一般组成部分。

• Agent：主动采集数据，并把数据推送到Collector部分。
• Collector：接收多个Agent的数据，并实现有序、可靠、高性能地转发。
• Store：存储Collector转发过来的数据。

11.试述流计算系统与传统的数据处理系统有什么不同。

对比维度	流计算系统	传统数据处理系统
数据处理方式	实时处理持续到达的数据流，数据仅被处理一次	批量处理静态数据集（如历史数据），数据可重复处理
数据时效性	要求低延迟（秒级、毫秒级甚至微秒级），注重实时性	处理延迟较高（分钟级、小时级），侧重离线分析
数据模型	基于事件流模型，数据无界（持续产生）	基于数据集模型，数据有界（固定大小）
计算逻辑	通常为持续的、无终止的流式计算逻辑	一次性的、有明确起点和终点的批量计算逻辑
存储需求	无需存储完整数据集，仅需缓存窗口内数据	需要存储完整数据集以便重复处理
典型场景	实时监控、实时推荐、日志实时分析、欺诈检测等	离线报表生成、数据挖掘、历史趋势分析等
框架示例	Apache Flink、Apache Storm、Spark Streaming	MapReduce、Hive、Spark Core

12.试列举几个流计算的应用领域。

（课本第230页11.3大标题）实时分析、实时交通

13.流计算适用于具备怎样特点的场景?

（课本第230页11.3）Web服务、机器翻译、广告投放、自然语言处理、气候模拟预测

14.试述流计算为业务分析带来了怎样的改变。

1. 实时性：从滞后分析升级为毫秒级实时洞察，如实时监控业务指标。
2. 动态性：覆盖无界数据流，适配动态场景，如设备故障预警。
3. 前瞻性：从事后追溯转为事前预警，结合多源数据关联分析，提升决策效率与风险防控能力。

15.除了实时分析和实时交通，请再列举一个适合采用流计算的应用场景，并描述流计算可带来怎样的改变。

应用场景：金融行业实时反欺诈系统
流计算带来的改变：
可毫秒级分析用户交易流数据，结合历史行为、设备信息等多源数据实时关联，通过规则引擎和机器学习模型动态识别异常交易（如异地高频转账、非惯常消费模式），实时拦截欺诈行为，降低资金损失风险，较传统批量分析模式响应速度提升90%以上，显著增强风控时效性与精准度。

16.试述 Storm 框架如何改变开发人员开发实时应用的方式。

（课本第231页11.4第三段）以往开发人员在开发一个实时应用的时候，除了要关注处理逻辑，还要为实时数据的获取、传输、存储大伤脑筋，但是，有了Strom以后，开发人员可以基于Storm，快速地搭建一套健壮、易用的实时流处理系统，配合Hadoop等平台，就可以低成本地做出很多以前很难想象的实时计算系统。

17.试述 Spark Streaming 的基本原理。

（课本第232页11.5）将实时输入数据流以时间片（秒级）为单位进行拆分，然后经Spark引擎以类似批处理的方式处理每个时间片数据。

18.试述 Structured Streaming 的关键思想。

（课本第233页11.6.2）将实时数据流视为一个正在不断添加数据的表

19.试述 Structured Streaming 的两种处理模型的具体实现方法。

（课本第234页11.6.3）

• 微批处理模型
  将无界数据流切分为小批次（如每5秒一批），按批处理逻辑处理。通过Trigger设定间隔，每个批次作为独立数据集，支持SQL/API操作及窗口聚合。状态自动维护，延迟秒级，适合对实时性要求稍低、需复杂逻辑的场景（如离线转实时任务迁移）。

• 连续处理模型
  基于事件时间增量处理，通过低延迟存储（如RocksDB）实时更新状态，延迟亚秒级（毫秒级）。仅支持简单聚合，处理逻辑逐事件触发，无需全量计算。适用于高实时性、轻量级场景（如实时监控指标、简单过滤转发）。

第十二章 Flink

1.请阐述传统数据处理架构的局限性。

（课本第238页12.2.1）随着企业业务量的不算增大，数据库的负载开始不断增加，传统架构最终不堪重负，而一旦数据库系统发生问题，整个业务系统就会受到严重影响。此外，采用传统架构的系统，一般拥有比较复杂的异常问题处理方法，当出现异常问题时，很难保证系统还能很好地运行。

2.请阐述大数据Lambda架构的优点和局限性。

（课本第238页12.2.2）分开处理连续的实时数据和有限批次的批量数据，可以使系统构建工作变得简单。但是，这种做法将管理两套系统的复杂性给了系统用户。由于存在太多的框架，且在一套资源管理平台中管理不同类型的计算框架是一件比较困难的事情，导致平台复杂度过高、运维成本高。

3.请阐述与传统数据处理架构和大数据Lambda架构相比，流处理架构具有什么优点。

（课本第240页第一段）不存在“数据库不堪重负”的问题；避免了Lambda架构中存在的“多个架构难管理”的问题

4.请举例说明Flink在企业中的应用场景。

（课本第241页12.3）事件驱动型应用、数据分析应用和数据流水线应用

5.请阐述Flink核心组件栈包含哪些层次以及每个层次具体包含哪些内容。

（课本第244页图12-9）

6.请阐述Flink的JobManager和TaskManager具体有哪些功能。

（课本第245页12.5）

• JobManager负责整个Flink集群任务的调度以及的资源的管理，它从客户端获取提交的应用，然后根据集群中TaskManager上Task Slot的使用情况，为提交的应用分配相应的Task Slot资源，并命令TaskManager启动从客户端获取的应用。
• TaskManager相当于整个集群的从节点，负责具体的任务执行和对应任务在每个节点上的资源申请与管理。

7.请阐述Flink编程模式的层次结构。

（课本第246页12.6）

• 有状态数据流处理：最低级抽象，通过 Process Function 集成到 DataStream API，支持自由处理事件、管理容错状态，实现复杂计算。
• DataStream API：核心 API，提供转换、连接、聚合、窗口等通用模块，集成底层处理函数，适配多数流处理开发。
• Table API：以表为中心，支持类似关系数据库操作，代码简洁，执行前经优化器优化，可与 DataStream API 混合使用，支持 UDF 扩展。
• SQL：最高级抽象，语法和表达能力与 Table API 类似，可在 Table API 定义的表上执行查询，交互紧密 。

8.请对Spark、Flink和Strom进行对比分析。

维度	Spark	Flink	Storm
架构设计	基于批处理扩展流（微批处理），Driver-Executor 架构，依赖 Hadoop 生态。	原生流处理架构，支持流批统一（One Architecture），Master-Worker 模型，轻量级资源管理。	纯流式架构，Nimbus-Supervisor 模型，专为实时计算优化，资源隔离性强。
处理模型	微批处理（Mini-Batch），将流切分为小批次处理。	支持 连续处理（流模式） 和 微批处理（批模式），流批统一语义。	纯流式处理（逐条处理），无批处理概念。
实时性	延迟秒级（微批最小间隔约 100ms），适合准实时场景。	流模式下延迟亚秒级（毫秒级），微批模式秒级，支持事件时间和水印（Watermark）。	延迟毫秒级（逐条处理），实时性最强，适合高实时场景（如高频交易）。
状态管理	支持内存/磁盘状态，需手动管理 checkpoint，状态后端较简单。	内置轻量级状态后端（RocksDB/内存），自动管理 checkpoint 和容错，支持增量 checkpoint，状态规模大。	状态需开发者手动管理（如持久化到外部存储），容错依赖 ACK 机制，状态管理灵活性低。
时间语义	支持处理时间（Processing Time），有限支持事件时间（Event Time）。	完整支持事件时间、摄入时间（Ingestion Time）和处理时间，基于水印机制处理乱序数据。	仅支持处理时间，对乱序数据处理能力较弱。
窗口机制	支持滚动窗口、滑动窗口、会话窗口，基于批处理逻辑实现。	支持更灵活的窗口类型（如全局窗口、会话窗口），窗口触发基于事件时间或处理时间，支持增量计算。	需自定义 Trident 或通过 Topology 实现窗口逻辑，复杂度较高。
生态集成	生态成熟，无缝集成 Hadoop、Hive、Kafka 等，支持 ML、图计算（Spark MLlib/GraphX）。	生态完善，支持 Kafka、RabbitMQ、Kinesis 等数据源，集成 Flink SQL/Table、CEP、ML 等高层库，流批统一生态。	生态较单一，主要集成 Kafka、Redis 等，需结合其他框架实现复杂功能（如 Storm + HBase）。
适用场景	大数据批处理、准实时分析（如日志统计、ETL）、机器学习。	高吞吐低延迟的实时流处理（如实时监控、金融风控）、流批统一的复杂场景（如实时数仓）。	纯实时流处理、高并发低延迟场景（如实时消息推送、欺诈检测），不适合批处理。
容错机制	基于分布式快照（checkpoint），需重启 Executor 恢复任务，失败恢复时间较长。	轻量级分布式快照（支持增量 checkpoint），基于 Savepoint 实现 Exactly-Once 语义，故障恢复效率高。	基于 ACK 机制和消息重放，确保消息至少处理一次（At-Least-Once），需手动实现 Exactly-Once。
编程模型	基于 RDD/Dataset/DataFrame，支持 Scala/Java/Python，API 简洁但流处理灵活性较低。	提供 DataStream/DataSet API（底层）、Table/SQL API（高层），支持 Scala/Java/Python，流处理功能丰富（如 ProcessFunction）。	基于 Topology（Spout/Bolt），支持多语言（Java/Scala/Clojure 等），编程门槛较高，需手动管理消息传递。
资源管理	依赖 YARN/Mesos/Kubernetes，资源申请周期较长，适合长时运行作业。	支持 YARN/Kubernetes，原生集成资源管理，支持动态扩缩容，资源分配更高效。	原生支持 Supervisor 管理 Worker 节点，资源隔离性好，但生态集成度较低。