JMU软件大数据技术复习提纲
Posted jiangxiaoju
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了JMU软件大数据技术复习提纲相关的知识，希望对你有一定的参考价值。
原创不易，未经允许，请勿转载。
本复习提纲只适用于JMU软件工程大数据课程
第一章
1.1 大数据问题的定义和来源 P3-5
- 存储设备容量不断增加。（信息存储）
- CPU处理能力大幅提升。（信息处理）
- 网络带宽不断增加。（信息传输）
1.2 大数据问题的特点 P7-9
关于什么是大数据，大家比较认可大数据的”4V“说法。大数据的4个”V“，或者说大数据的四个特点，包括4个层面：
- 数据量大。
- 数据类型繁多。
- 处理速度快。
- 价值密度低。
1.3 大数据应用四大层面的关键技术 P15
- 数据采集与预处理：利用ETL工具将分布的、异构数据源中的数据，如关系数据、平面数据文件等，抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础;也可以利用日志采集工具(如 Flume、Kafka 等）把实时采集的数据作为流计算系统的输人,进行实时处理分析。
- 数据存储与管理：利用分布式文件系统、数据仓库、关系数据库、NoSQL 数据库、云数据库等，实现对结构化、半结构化和非结构化海量数据的存储和管理。
- 数据处理与分析：利用分布式并行编程模型和计算框架，结合机器学习和数据挖掘算法,实现对海量数据的外理和分析；对分析结果进行可视化呈现，帮助人们更好地理解数据、分析数据。
- 数据安全和隐私保护：在从大数据中挖掘潜在的巨大商业价值和学术价值的同时,构建隐私数据保护体系和数据安全体系,有效保护个人隐私和数据安全
1.4 大数据四大计算模式：除图计算外详细了解 P16
| 大数据计算模式 | 解决问题 | 代表产品 |
|---|---|---|
| 批处理计算 | 针对大规模数据的批量问题 | MapReduce、Spark等 |
| 流计算 | 针对流数据的实时计算 | Storm、S4、Flume、Streams、Puma等 |
| 图计算 | 针对大规模图结构数据的处理 | Pregel、GraphX、Giraph等 |
| 查询分析计算 | 大规模数据的存储管理和查询分析 | Hive、Dremel等 |
1.5 云计算的概念，物联网的概念，云计算与物联网之间的关系 P18-19,21-22,26
1.5.1 云计算的概念
云计算实现了通过网络提供可伸缩的、廉价的分布式计算能力，用户只需要在具备网络接入条件的地方，就可以随时随地获得所需的各种IT资源。云计算代表了以虚拟化为核心、以低成本为目标的、动态可扩展的网络应用基础设施，是近年最有代表性的网络计算计算与模式。
云计算包括3种典型的服务模式，即IaaS（基础设施即服务），PaaS（平台即服务）和SaaS（软件即服务）。IaaS酱基础设施（计算资源和存储）作为服务出租，PaaS把平台作为服务出租，SaaS把软件作为服务出租。
1.5.2 物联网的概念
物联网是物物相连的互联网，是互联网的延申，它利用局部网络或互联网等通信技术把传感器、控制器、机器、人员和物等通过新的方式连在一起，形成人与物、物与物相连，实现信息化和远程管理控制。
从技术架构上来看，物联网可分为四层：感知层、网络层、处理层和应用层。物联网各个层次的功能如下表：
| 层次 | 功能 |
|---|---|
| 感知层 | 如果把物联网系统比喻为一人体，那么感知层好比人体的神经末梢，用来感知物理世界，采集来自物理世界的各种信息。这个层包含了大量的传感器，如温度传感器、湿度传感器、应力传感器、加速度传感器、重力传感器、气体浓度传感器、土壤盐分传感器、二维码标签、RFID标签和读写器、摄像头、GPS设备等 |
| 网络层 | 相当于人体的神经中板，起到信息传输的作用。网络层包括各种类型的网络，如互联网、移动通信网络、卫星通信网络等 |
| 处理层 | 相当于人体的大脑，起到存储和处理的作用，包括数据存储、管理和分析平台 |
| 应用层 | 直接面向用户，满足各种应用需求，如智能交通、智慧农业、智慧医疗、智能工业等 |
### 1.5.3 云计算与物联网之间的关系
大数据、云计算和物联网的联系。从敷体上看、大数据、云计算和物联网这三者是相辅相成的。大数据根植于云计算，大数据分析的很多技术都来自于云计算，云计算的分布式数据存储和管理系统(包括分布式文件系统和分布式数据库系统)提供了海量数据的存储和管理能力,分布式并行处理框架 MapReduce提供了海量数据分析能力，没有这些云计算技术作为支撑，大数据分析就无从谈起。反之，大数据为云计算提供了“用武之地”,没有大数据这个“练兵场”，云计算技术再先进,也不能发挥它的应用价值。物联网的传感器源源不断产生的大量数据，构成了大数据的重要数据来源，没有物联网的飞速发展，就不会带来数据产生方式的变革,即由人工产生阶段转向自动产生阶段，大数据时代也不会这么快就到来。同时,物联网需要借助于云计算利大数据技术,实现物联网大数据的存储、分析和处理。
第三章
3.1 HDFS的本质：分布式文件系统
3.2 块的概念和优势P46
块的概念：
在传统的文件系统中，为了提高磁盘读写效率，一般以数据块为单位，而不是以字节为单位。以块为单位读写数据，可以把磁盘寻道时间分摊到大量数据中。
块的优势：
- 支持大规模文件存储。
- 简化系统设计。
- 适合数据备份。
3.3 名称节点和数据节点的定义P46-47
3.3.1 名称节点的定义
称节点（NameNode)负责管理分布式文件系统的命名空间，保存了两个核心的数据结构，即FsImage和EditLog。FsImage用于维护文件系统树以及文件树中所有的文件和文件夹的元数据，操作日志文件EditLog记录了所有针对文件的创建、重命名等操作。名称节点记录了每个文件中各个块所在的数据节点为位置信息（相当于一个数据目录），但是并不持久化存储这些信息，而是在系统每次启动时扫描所有数据节点重构得到这些信息。
3.3.2 数据节点的定义
数据节点（DataNode）是分布式文件系统HDFS的工作节点，负责数据的存储和读取，会根据客户端或者名称节点的调度来进行数据的存储和检索，并且向名称节点定期发送自己所存储的块的列表。每个数据节点种的数据会被保存在各自节点的本地Linux文件系统中。
3.4 第二名称节点的意义和工作原理P47
3.4.1 第二名称节点的意义
第二名称节点是为了解决EditLog逐渐变大带来的问题。
在名称节点运行期间，HDFS会不断发生更新操作，这些更新操作都是直接被写入到EditLog文件，因此 EditLog 文件也会逐渐变大。在名称节点运行期间，不断变大的EditLog 文件通常对于系统性能不会产生显著影响，但是当名称节点重启时，需要将FsImage加载到内存中,然后逐条执行EditLog中的记录，使得FsImage保持最新。可想而知，如果EditLog很大,就会导致整个过程变得非常缓慢,使得名称节点在启动过程中长期处于“安全模式”,无法正常对外提供写操作，影响了用户的使用。
3.4.2 工作原理
具体介绍翻书（P47-48）
3.5 冗余存储的具体实现方法和优势P50-51
3.5.1 具体实现方式
作为一个分布式文件系统，为了保证系统的容错性和可用性，HDFS采用了多副本方式对数据进行冗余存储，通常一个数据块的多个副本会被分布到不同的数据节点上。
3.5.2 优势
- 加快数据传输速度。
- 容易检查数据错误。
- 保证数据可靠性。
3.6 数据存放策略和原因P51
3.6.1 策略
为了提高数据的可靠性于系统的可用性，以及充分利用网络带宽，HDFS采用了以机架（Rack）为基础的数据存放策略。一个HDFS集群通常包含多个机架，不同机架之间的数据通信需要经过交换机或路由器，同一个机架不同机器之间的通信则不需要通过交换机和路由器，这意味着同一个机架中的不同机器之间的通信要比不同机架之间的通信带宽大。
3.6.2 原因
首先，可以获得很高的数据可靠性，即使一个机架发生故障，位于其他机架上的数据副本仍然可用的。其次，在读取数据的时候，可以在多个机架上并行的处理数据，大大提高了数据读取速度；最后，可以更容易地实现系统内部负载均衡和错误处理。
3.7 数据读取与复制P52
3.7.1 数据读取
HDFS提供了一个API可以确定一个数据节点所属地机架ID，客户端也可以调用API获取自己所属地机架ID。当客户端读取数据时，从名称节点获得数据块不同副本地存放位置列表，列表中包含了副本所在的数据节点，可以调用API来确定客户端和这些数据节点所属的机架ID。当发现某个数据块副本对应的机架ID和客户端对用的机架ID相同时，就优先选择该副本读取数据，如果没有发现，就随机选择一个副本读取数据。
3.7.2 数据复制
HDFS的数据复制采用了流水线复制的策略，大大提高了数据复制过程的效率。
3.8 HDFS中三种可能的错误和恢复方法 P52
-
名称节点出错：
第一，把名称节点上的元数据信息同步存储到其他文件系统中；第二，运行一个第二名称节点，当名称节点宕机以后，可以把第二名称节点作为一种弥补措施，利用第二名称节点的元数据信息进行系统恢复，但是从前面对第二名称节点的介绍中可以看出，这样做仍然会丢失部分数据。因此，一般会把上述两种方法结合使用，当名称节点发生宕机时，首先到远程挂载的网络文件系统中获取备份的元数据信息，放到第二名称节点上进行恢复，并把第二名称节点作为名称节点来使用。
-
数据节点出错：
每个数据节点会定期向名称节点发送“心跳”信息，向名称节点报告自己的状态。当数据节点发生故障，或者网络发生断网时，名称节点就无法收到来自一些数据节点的“心跳”信息，这时这些数据节点就会被标记为“宕机”,节点上面的所有数据都会被标记为“不可读”，名称节点不会再给它们发送任何IO请求。这时，有可能出现一种情形，即由于一些数据节点的不可用，会导致一些数据块的副本数量小于冗余因子。名称节点会定期检查这种情况，一旦发现某个数据块的副本数量小于冗余因子，就会启动数据冗余复制，为它生成新的副本。HDFS 与其他分布式文件系统的最大区别就是可以调整冗余数据的位置。
-
数据出错：
数据校验出错，客户端会请求另外一个数据节点读取改数据块，并且向名称节点报告这个文件块有错误，名称节点会定期检查并重新复制这个块。
第四章
4.1 HBASE与传统数据库的对比 P64-65
HBase与传统的关系数据库区别主要体现在以下几个方面：
- 数据类型。 关系数据库采用关系模型，具有丰富的数据类型和存储方式。HBase采用更简单的数据模型，它把数据存储为未经解释的字符串，用户可以把不同格式的结构化数据和非结构化数据都序列化成字符粗保存到HBase中，用户需要自己编写程序把字符粗解析成不同的数据类型。
- 数据操作。 关系数据库中包含了丰富的操作，如插入、删除、更新、查询等，其中会涉及到多表连接，通常是借助于多个表之间的主外键关联来实现的。HBase操作则不存在复杂的表与表之间的关系，只有简单的插入、查询、删除、清空等（，因为HBase在设计上就避免了复杂的表与表之间的关系，通常只采用单表的主键查询，所以它无法实现像关系数据库中那样的表与表之间的连接操作。
- 存储模式。关系数据库基于行模式存储，元组或行会被连续地存储在磁盘页中。HBase基于列存储，每个列族都有几个文件保存，不同列族的文件是分离的。
- 数据索引。关系数据库通常可以针对不同列构建复杂的多个索引以提高数据访问性能。HBase只有一个索引——行键。
- 数据维护。在关系数据库中，更新操作会用最新的当前值去替换记录中掉原来的值，旧值被覆盖后就不会存在。而HBase的更新操作时，并不会删除数据旧的版本，而是生产一个新的版本，旧的版本仍然保留。
- 可伸缩性。关系数据库很难实现横向扩展,纵向扩展的空间也比较有限。相反，HBase和BigTable这些分布式数据库就是为了实现灵活的水平扩展而开发的,因此能够轻易地通过在集群中增加或者减少硬件数量来实现性能的伸缩。
4.2 HBASE的数据模型概念、数据坐标P66-68
4.2.1 数据模型概念
-
表：HBase采用表来组织数据，表由行和列组成，列分为若干个列族。
-
行：HBase 表中的每行数据都由一个 RowKey 和多个 Column（列）组成，数据是按照 RowKey
的字典顺序存储的，并且查询数据时只能根据 RowKey 进行检索，所以 RowKey 的设计十分重
要。
-
列族：HBase 中的每个列都由 Column Family(列族)和 Column Qualifier（列限定符）进行限
定，例如 info：name，info：age。建表时，只需指明列族，而列限定符无需预先定义。
-
单元格：由{rowkey, column Family：column Qualifier, time Stamp} 唯一确定的单元。cell 中的数
据是没有类型的，全部是字节码形式存贮。
-
时间戳：用于标识数据的不同版本（version），每条数据写入时，如果不指定时间戳，系统会
自动为其加上该字段，其值为写入 HBase 的时间。
4.2.2 数据作标
对于我们熟悉的关系数据块而言，数据定位可以理解为采用”二维坐标“。即根据行和列就可以确定表中一个确定的值。HBase中需要根据行键、列族、列限定符和时间戳来确定一个单格，即四维坐标{行键，列族，列限定符，时间戳}
4.3 HBASE列式存储的基本模型 P70 图4-4
http://c.biancheng.net/view/3586.html
4.4 HBASE的三层结构 P73
4.5 HBASE的系统结构与客户端、Zookeeper服务器、Master服务器、Region服务器功能P74-75
-
客户端
客户端包含访问HBase的接口，同时缓存中维护着已经访问过的Region信息，用来加快后续数据访问过程。
-
Region服务器
Region Server 为 Region 的管理者，其实现类为 HRegionServer，主要作用如下:
对于数据的操作：get, put, delete；
对于 Region 的操作：splitRegion、compactRegion。
-
Master
Master 是所有 Region Server 的管理者，其实现类为 HMaster，主要作用如下：
对于表的操作：create, delete, alter
对于 RegionServer的操作：分配 regions到每个RegionServer，监控每个 RegionServer
的状态，负载均衡和故障转移。
-
Zookeeper
HBase 通过 Zookeeper 来做 Master 的高可用、RegionServer 的监控、元数据的入口以及
集群配置的维护等工作。
第五章
5.1 NoSQL数据库三大特点 P94-95
- 灵活的可拓展性
- 灵活的数据模型
- 与云计算紧密融合
5.2 关系型数据库不满足Web2.0应用的三大原因 P96
- Web2.0网站系统通常不要求严格的数据库事务
- Web2.0并不要求严格的读写实时性
- Web2.0通常不包含大量复杂的SQL查询
5.3 四大类型NOSQL数据库名称与特点P99-101
- 键值数据库
- 列族数据库
- 文档数据库
- 图数据库
5.4 NoSQL三大基石：CAP的定义，CAP三种选择两种的实现方法P102-103
- C（Consistenct）:一致性。它是指任何一个读操作总是能够读到之前完成的写操作的结果，也就是分布式环境中，多点数据是一致的。
- A（Availability) :可用性。它是指快速获取数据，可以在确定的时间内返回结果。
- P（Tolerance of Network Partition):分区容忍性。它是指当出现网络分区的情况时，分离的系统也能够正常运行。
5.4.1 CAP三种选两种
- CA：也就是强调一致性©和可用性（A)，放弃分区容忍性§,最简单的做法是把所有与事务相关的内容都放到同一台机器上。很显然，这种做法会严重影响系统的可扩展性。传统的关系数据库(mysql、SQL Server 和 PostgreSQL)都采用了这种设计原则,因此扩展性都比较差。
- CP：也就是强调一致性(C）和分区容忍性§，放弃可用性（A),当出现网络分区的情况时,受影响的服务需要等待数据一致,因此在等待期间就无法对外提供服务。Neo4J、BigTable和 HBase等NoSQL 数据库都采用了CP设计原则。
- AP：也就是强调可用性(A)和分区容忍性§，放弃一致性©,允许系统返回不一致的数据。这对于许多Web 2.0网站而言是可行的，这些网站的用户首先关注的是网站服务是否可用,当用户需要发布一条微博时，必须能够立即发布，否则，用户就会放弃使用，但是这条微博发布后什么时候能够被其他用户读取到,则不是非常重要的问题，不会影响到用户体验。因此，对于Web 2.0网站而言,可用性与分区容忍性优先级要高于数据一致性,网站一般会尽量朝着AP的方向设计。当然,在采用AP设计时,也可以不完全放弃一致性,转而采用最终一致性。Dynamo、Riak、CouchDB、Cassandra 等NoSQL 数据库就采用了AP设计原则。
5.5 NoSQL四大特性：BASE定义 P104
-
基本可用
基本可用是指一个分布式系统的一部分发生问题变得不可用时，其他部分仍然可以正常使用，也就是允许分区失败的情形出现。
-
软状态
“软状态”是与“硬状态”相对应的一种提法。数据库保存的数据是“硬状态”时，可以保证数据的一致性，即保证数据一直是正确的。“软状态”是指状态可以有一段时间不同步，具有一定的滞后性。
-
最终一致性
一致性的类型包括强一致性和弱一致性，二者的主要区别在于高并发的数据访问操作下，后续操作是否能够获取最新数据。
第七章
7.1 Map与Reduce的基本定义P133表7-1
7.2 MapReduce基本工作流程 P134
7.3 使用combiner与不使用combiner时的MapReduce执行Wordcount的基本流图 P141-142 图7-7、8、9
7. 4 使用MapReduce进行自然连接运算流程 P143
第九章
9.1 Spark相比Hadoop的核心优势，核心优势的实现方法P174
- Spark的计算模式也属于MapReduce，但不限于Map和Reduce操作，还提供了多种数据集操作类型，编程模型比MapReduce更灵活。
- Spark提供了内存计算，中间结果直接存放到内存中，带来了更高的迭代运算效率。
- Spark基于DAG的任务调度执行机制，要优于MapReduce的迭代执行机制。
9.2 RDD转换操作、行动操作、惰性调用与DAG构建 P180
9.3 常用RDD API P188表9-2 9-3
9.4 Spark面向不同功能的组件 P176
-
Spark Core
Spark Core包含了Spark基本功能,如内存计算、任务调度、部署模式、故障恢复、存储管理等,主要面对批数据处理场景。Spark建立在统一的抽象RDD之上，使其可以以基本一致的方式应对不同的大数据处理场景。
-
Spark SQL
Spark SQL允许开发人员直接处理RDD，同时也可查询Hive、HBase等外部数据源。Spark SQL的一个重要特点是其能够统一处理关系表和RDD，使得开发人员不需要自己编写Spark应用程序，开发人员可以轻松使用你SQL命令进行查询，并进行更复杂的数据分析。
-
Spark Streaming
Spark Streaming支持高吞吐量、可容错处理的实时流数据处理，其核心思路是将流数据分解成一系列短小的批处理作业，每个短小的批处理作业都可以使用Spark Core进行快速处理。Spark Streaming支持多种数据输入源，如Kafka、Flume和TCP套接字等。
-
MLlib（机器学习）
MLlib提供了常用机器学习算法的实现，包括聚类、分类、回归、协同过滤等，降低了机器学习的门槛，开发人员只需要具备一定的理论知识就能进行机器学习工作。
-
GraphX（图计算）
GraphX是Spark中用于图计算的API，可认为是Pregel在Spark上的重写优化，GraphX性能良好，拥有丰富的功能和运算符，能在海量数据上自如地运行复杂地图算法。
第十章
10.1 流数据的特点P195
- 数据快速持续到达，潜在大小也许是无穷无尽地。
- 数据来源众多，格式复杂。
- 数据量大，但是不十分关注存储，一旦流数据中的某个元素经过处理，要么被丢弃，要么被归档存储。
- 注重数据的整体价值，不过分关注个别数据。
- 数据顺序颠倒，或者不完整，系统无法控制将要处理的新到达的数据元素顺序。
10.2 静态数据分析与流数据处理的不同（批处理与流计算）P199
- 流处理系统处理的是实时的数据，而传统的数据处理系统处理的是预先存储好的静态数据。
- 用户通过流处理系统获取的是实时结果，而通过传统的数据处理系统获取的是过去某一时刻的结果。并且，流处理系统，无需用户主动发出查询，实时查询服务可以主动将实时结果推送给用户。
10.3 流计算的概念，MapReduce为什么不适用于流计算
10.3.1 流计算的概念
流计算平台实时获取来自不同数据源的海量数据，经过实时分析处理，获得有价值的信息。
10.3.2 MapReduce为什么不适用于流计算
MapReduce是专门面向静态数据的批量处理的，内部各种实现机制都是为批处理做了高度优化，不适用于处理持续到达的动态数据。
10.4 流计算的数据处理流程 P198
包含三个阶段：数据实时采集、数据实时计算、实时查询服务
10.5 Storm的基本设计思想 （Spouts Bolts Topology）P202
-
Spouts
Storm认为每个Stream都有一个源头，并把这个源头抽象为Sputs。Spouts会从外部读取流数据并持续发出Tuple。
-
Bolts
Storm将Stream的状态转换过程抽象为Bolts。Bolts既可以处理Tuple，也可以将处理后的Tuple作为新的Streams发送给其他Bolts。对Tuple的处理逻辑都被封装到Bolts中，可执行过滤、聚合、查询等操作。
-
Topology
Storm将Spouts 和 Bolts组成的网络抽像成Topology。Topology是Storm中高层次的抽象概念，它可以被提交到Storm集群执行。一个Topology就是一个流转换图，图中节点就是一个Spout活Bolt，图中的边则表示Bolt订阅了哪个Stream。当Spout或者Bolt发送元组时，它会把元组发送到每个订阅了该Stream的Bolt上进行处理。
10.6 Spark Streaming的基本设计思想 P207
拒绝白嫖从一键三连开始！
原创不易，未经允许，请勿转载。
以上是关于JMU软件大数据技术复习提纲的主要内容，如果未能解决你的问题，请参考以下文章