第一章

信息科技需要处理的三大核心问题

信息存储、信息传输、信息处理

数据产生方式的变革

运营式系统阶段

数据库的出现使数据管理的复杂度大大降低，数据往往伴随着一定的运营活动而产生并记录在数据库中，数据的产生方式是被动的

用户原创内容阶段

数据爆发产生于Web2.0时代，而Web2.0的最重要的标志就是用户原创内容
智能手机等移动设备加速内容产生
数据产生方式是主动的

感知式系统阶段

感知式系统的广泛使用
人类社会数据量第三次大的飞跃最终导致的大数据的产生

大数据4V概念（能简要概括）

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

大数据对思维方式的影响

全样而非抽样、效率而非准确、相关而非因果

大数据技术的不同层面及其功能

技术层面	功能
数据采集与预处理	采用ELT工具将分布的、异构数据源中的数据，如关系数据、平面数据文件等，抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础；也可以利用日志采集工具（如Flume、Kafka等）把实时采集的数据作为流计算系统的输入，进行实时处理分析
数据存储和管理	利用分布式文件系统、数据仓库、关系数据库、NoSQL数据库、云数据库等，实现对结构化、半结构化和非结构化海量数据的存储和管理
数据处理和分析	利用分布式并行编程模型和计算机框架，结合机器学习和数据挖掘算法，实现对海量数据的处理和分析；对分析结果进行可视化呈现，帮助人们更好地理解数据、分析数据
数据安全和隐私保护	在从大数据中挖掘潜在的巨大商业价值和学术价值的同时，构建隐私数据保护体系和数据安全体系，有效保护个人隐私和数据安全

大数据计算模式

大数据计算模式	解决问题	代表产品
批处理计算	针对大规模数据的批量处理	MapReduce、Spark等
流计算	针对流数据的实时计算	Storm、S4、Flume、Streams、Puma、DStream、SuperMario、银河数据处理平台等
图计算	针对大规模图结构数据的处理	Pregel、GraphX、Giraph、PowerGraph、Hama、GoldenOrb等
查询分析计算	大规模数据的存储管理和查询分析系	Dremel、Hive、Cassandra、Impala等

云计算关键技术

虚拟化、分布式存储、分布式计算、多租户等

物联网关键技术

识别和感知技术
网络与通信技术
数据挖掘与融合技术

第二-三章

分布式文件系统概念

分布式文件系统是一种通过网络实现文件在多台主机上进行分布式存储的文件系统

HDFS文件块

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

HDFS采用抽象的块概念可以带来以下几个明显的好处：

支持大规模文件存储
简化系统设计
适合数据备份

名称节点、数据节点的功能与工作原理（能简要概括）

名称节点功能：

在HDFS中，名称节点（NameNode）负责管理分布式文件系统的命名空间，保存了两个核心的数据结构，即FsImage和EditLog

名称节点工作原理：

在名称节点启动的时候，它会将FsImage文件中的内容加载到内存中，之后再 执行EditLog文件中的各项操作，使得内存中的元数据和实际的同步，存在内存 中的元数据支持客户端的读操作。
一旦在内存中成功建立文件系统元数据的映射，则创建一个新的FsImage文件 和一个空的EditLog文件
名称节点起来之后，HDFS中的更新操作会重新写到EditLog文件中，因为 FsImage文件一般都很大（GB级别的很常见），如果所有的更新操作都往 FsImage文件中添加，这样会导致系统运行的十分缓慢，但是，如果往EditLog 文件里面写就不会这样，因为EditLog 要小很多。每次执行写操作之后，且在 向客户端发送成功代码之前，edits文件都需要同步更新

数据节点：

​ 数据节点是分布式文件系统HDFS的工作节点，负责数据的存储和读取，会根据客户端或者是名称节点的调 度来进行数据的存储和检 索，并且向名称节点定期发送自己所存储的块的列表

​ 每个数据节点中的数据会被保存在各自节点的本地Linux文件系统中

第二名称节点的意义与功能（理解工作原理，能用自己语言说明）

第二名称节点是HDFS架构中的一个组成部分，它是用来保存名称节点中对HDFS 元数据信息的备份，并减少名称节点重启的时间。SecondaryNameNode一般是 单独运行在一台机器上

SecondaryNameNode的工作情况：

（1）SecondaryNameNode会定期和 NameNode通信，请求其停止使用EditLog 文件，暂时将新的写操作写到一个新的文件 edit.new上来，这个操作是瞬间完成，上层 写日志的函数完全感觉不到差别；

（2）SecondaryNameNode通过HTTP GET方式从NameNode上获取到FsImage和 EditLog文件，并下载到本地的相应目录下 ；

（3）SecondaryNameNode将下载下 来的FsImage载入到内存，然后一条一条地 执行EditLog文件中的各项更新操作，使得 内存中的FsImage保持最新；这个过程就是 EditLog和FsImage文件合并；

（4）SecondaryNameNode执行完（3 ）操作之后，会通过post方式将新的 FsImage文件发送到NameNode节点上

（5）NameNode将从 SecondaryNameNode接收到的新的 FsImage替换旧的FsImage文件，同时将 edit.new替换EditLog文件，通过这个过程 EditLog就变小了

HDFS冗余存储的定义与意义

定义：

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

意义：

​ （1）加快数据传输速度

​ （2）容易检查数据错误

​ （3）保证数据可靠性

HDFS数据存放策略，读取策略P52 （理解工作原理，用自己的话说明）

数据存放：

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

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

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

更多副本：随机节点

数据读取：

​ HDFS提供了一个API可以确定一个数据节点所属的机架ID，客户端也 可以调用API获取自己所属的机架ID。当客户端读取数据时，从名称节点获得数据块不同副本的存放位置列表， 列表中包含了副本所在的数据节点，可以调用API来确定客户端和这些 数据节点所属的机架ID，当发现某个数据块副本对应的机架ID和客户端 对应的机架ID相同时，就优先选择该副本读取数据，如果没有发现，就随机选择一个副本读取数据

HDFS三种数据错误及其恢复方法（理解工作原理，用自己的话说明）

名称节点出错

恢复方法：HDFS设置了备份机制，把这些核心文件 同步复制到备份服务器SecondaryNameNode上。当名称节点出错时， 就可以根据备份服务器SecondaryNameNode中的FsImage和Editlog 数据进行恢复。

数据节点出错

恢复方法：每个数据节点会定期向名称节点发送“心跳”信息，向名称节点报告自 己的状态。当数据节点发生故障，或者网络发生断网时，名称节点就无法收到来自 一些数据节点的心跳信息，这时，这些数据节点就会被标记为“宕机”， 节点上面的所有数据都会被标记为“不可读”，名称节点不会再给它们 发送任何I/O请求。这时，有可能出现一种情形，即由于一些数据节点的不可用，会导致一 些数据块的副本数量小于冗余因子。名称节点会定期检查这种情况，一旦发现某个数据块的副本数量小于冗 余因子，就会启动数据冗余复制，为它生成新的副本

数据出错

恢复方法：当客户端读取文件的时候，会先读取该信息文件，然后，利用该信息文件对 每个读取的数据块进行校验，如果校验出错，客户端就会请求到另外一个数 据节点读取该文件块，并且向名称节点报告这个文件块有错误，名称节点会 定期检查并且重新复制这个块

第四章

HBASE生态系统

HBASE的数据模型相关概念，理解掌握其中各个概念

表：HBase采用表来组织数据，表由行和列组成，列划分为若干个列族
行：每个HBase表都由若干行组成，每个行由行键（row key）来标识。
列族：一个HBase表被分组成许多“列族”（Column Family）的集合，它是基本的访问控制单元
列限定符：列族里的数据通过列限定符（或列）来定位
单元格：在HBase表中，通过行、列族和列限定符确定一个“单元格”（cell），单元格中存储的数据没有数据类型，总被视为字节数组byte[]
时间戳：每个单元格都保存着同一份数据的多个版本，这些版本采用时间戳进行索引

数据坐标的含义

HBase中需要根据行键、列族、列限定符和时间戳来确定一个单元格，因此，可以视为一个“四维坐标”，即[行键, 列族, 列限定符, 时间戳]

概念视图与物理视图的实际含义

概念视图：在Hbase的概念视图中，一个表可以视为一个稀疏、多维的映射关系

物理视图：在概念视图层面，HBase中的每个表是由许多行组成的，但是在物理存储层面，它是采用了基于列的存储方式

HBASE三层结构

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

第五章

NoSQL数据库的含义与特点

含义：

​ NoSQL是一种不同于关系数据库的数据库管理系统设计方式，是对非关系型数据库的统称，它所采用的数据模型并非传统关系数据库的关系模型，而是类似键/值、列族、文档等菲关系模型。

特点：

​ （1）灵活的可扩展性

​ （2）灵活的数据模型

​ （3）与云计算紧密融合

关系数据库在WEB 2.0时代的局限 与WEB 2.0不适用关系型数据库的原因

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

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

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

四大类型NoSQL数据库的定义,特点,代表性产品（理解并能用自己语言说明）

1.key-value

Redis
键值对存储，特点：查询数据块
内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等等。

键值数据库适用于那些频繁读写，拥有简单数据模型的应用。键值数据库中存储的值可以是简单的标量值，如整数或布尔值，也可以是结构化数据类型，比如列表和JSON结构。

2.Colunmn列式存储
HBase
将同一列的数据放在一起，查询非常快

列族数据库被设计应用于大量数据的情况，它保证了读取和写入的性能和高可用性。谷歌推出Bigtable来应对其服务需求。Facebook开发Cassandra 来支持其收件箱搜索服务。

3.document文档存储

MongoDB
经典用于web项目中，与KeyValue类似，比如MongoDB主要应用在爬虫

文档型数据库按照灵活性的标准设计。如果一个应用程序需要存储不同的属性以及大量的数据，那么文档数据库将会是一个很好的选择。例如，要在关系数据库中表示产品，建模者可以使用通用的属性和额外的表来为每个产品子类型存储属性。文档数据库却可以更为简单的处理这种情况。

4.Graph图结构存储

neo4j
用于社交网络

图形数据库非常适合表示网络实体连接等问题。评估图形数据库有效性的一种方法是确定实例和实例间是否存在关系。

分类	相关产品	数据模型	典型应用	优点	缺点
键值数据库（Key-Value Database)	Redis、Riak、SimplDB、Chordless、Scalaris、Memcached	键/值对	内容缓存，如会话、配置文件、参数、购物车等	扩展性好、灵活性好、大量写操作时性能高	无法存储结构化信息、条件查询效率较低
列族数据库	BigTable、Hbase、Cassandra、HadoopDB、GreenPlum、PNUTS	列族	分布式数据存储与管理	查找速度快、可扩展性强、容易进行分布式扩展、复杂性低	功能较少，大都不支持强事物一致性
文档数据库	CouchDB、MongoDB、Terrastore、ThruDB、RavenDB、SisoDB、RaptorDB、CloudKit、Perservere、Jackrabbit	版本化的文档	存储、索引并管理面向文档的数据或者类似的半结构化数据	性能好、灵活性高、复杂性低、数据结构灵活	缺乏统一的查询语法
图数据库	Neo4J、OrientDB、InfoGrid、Infinite Graph、GraphDB	图结构	应用于大量复杂、互连接、低结构化的图结构场合，如社交网络、推荐系统等	灵活性高、支持复杂的图算法、可用于构建复杂的关系图谱	复杂性高、只能支持一定的数据规模

NOSQL的三大基石, 理解三大要点的准确意义和内容，要求全部掌握，并能用自己语言说明

CAP

所谓的CAP指的是：

C（Consistency）：一致性，是指任何一个读操作总是能够读到之前完成的写操作的结果，也就是在分布式环境中，多点的数据是一致的， 或者说，所有节点在同一时间具有相同的数据

A:（Availability）：可用性，是指快速获取数据，可以在确定的时间 内返回操作结果，保证每个请求不管成功或者失败都有响应；

P（Tolerance of Network Partition）：分区容忍性，是指当出现网络分区的情况时（即系统中的一部分节点无法和其他节点进行通信），分离的系统也能够正常运行，也就是说，系统中任意信息的丢失或失败不会影响系统的继续运作。

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

当处理CAP的问题时，可以有几个明显的选择：

CA：也就是强调一致性（C）和可用性（A），放弃分区容忍性（P），最简单的做法是把所有与事务相关的内容都放到同一台机器上。很显然，这种 做法会严重影响系统的可扩展性。传统的关系数据库（MySQL、SQL Server 和PostgreSQL），都采用了这种设计原则，因此，扩展性都比较差
CP：也就是强调一致性（C）和分区容忍性（P），放弃可用性（A），当出现网络分区的情况时，受影响的服务需要等待数据一致，因此在等待期间 就无法对外提供服务
AP：也就是强调可用性（A）和分区容忍性（P），放弃一致性（C），允许系统返回不一致的数据

BASE

ACID	BASE
原子性(Atomicity)	基本可用(Basically Available)
一致性(Consistency)	软状态/柔性事务(Soft state)
隔离性(Isolation)	最终一致性 (Eventual consistency)
持久性 (Durable)

一个数据库事务具有ACID四性：

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

BASE的基本含义是基本可用（Basically Availble）、软状态（Softstate）和最终一致性（Eventual consistency）：

基本可用：基本可用，是指一个分布式系统的一部分发生问题变得不可用时，其 他部分仍然可以正常使用，也就是允许分区失败的情形出现
软状态： “软状态（soft-state）”是与“硬状态（hard-state）”相对应的一种提法。数据库保存的数据是“硬状态”时，可以保证数据一致性，即保证数据一直是正确的。“软状态”是指状态可以有一段时间不同 步，具有一定的滞后性

最终一致性

​ 一致性的类型包括强一致性和弱一致性，二者的主要区别在于高并发的数据访问操作下，后续操作是否能够获取最新的数据。对于强一致性而言，当执行完一次更新操作后，后续的其他读操作就可以保证读到更新后的最新数据；反之，如果不能保证后续访问读到的都是更新后的最新数据，那么就是弱一致性。而最终一致性只不过是弱一致性的一种特例，允许后续的访问操作可以暂时读不到更 新后的数据，但是经过一段时间之后，必须最终读到更新后的数据。最常见的实现最终一致性的系统是DNS（域名系统）。一个域名更新操作根据配置的形式被分发出去，并结合有过期机制的缓存；最终所有的客户端可以看到 最新的值。

最终一致性根据更新数据后各进程访问到数据的时间和方式的不同， 又可以区分为：

因果一致性：如果进程A通知进程B它已更新了一个数据项，那么进程B 的后续访问将获得A写入的最新值。而与进程A无因果关系的进程C的访问 ，仍然遵守一般的最终一致性规则
“读己之所写”一致性：可以视为因果一致性的一个特例。当进程A自己执行一个更新操作之后，它自己总是可以访问到更新过的值，绝不会看 到旧值
单调读一致性：如果进程已经看到过数据对象的某个值，那么任何后续 访问都不会返回在那个值之前的值
会话一致性：它把访问存储系统的进程放到会话（session）的上下文中，只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统保证不会延续到新的会话
单调写一致性：系统保证来自同一个进程的写操作顺序执行。系统必须 保证这种程度的一致性，否则就非常难以编程了

第六章

云数据库的概念

云数据库是部署和虚拟化在云计算环境中的数据库。云数据库是在云计算的大背景下发展起来的一种新兴的共享基础架构的方法，它极大地增强了数据库的存储能力，消除了人员、硬件、软件的重复配置，让软、硬件升级变得更加容易。

云数据库的特性

（1）动态可扩展

（2）高可用性

（3）较低的使用代价

（4）易用性

（5）高性能

（6）免维护

（7）安全

第七-八章

MapReduce基本概念与“计算向数据靠拢”

基本概念：

​ MapReduce采用“分而治之”策略，一个存储在分布式文件系统中的大规模数据集，会被切分成许多独立的 分片（split），这些分片可以被多个Map任务并行处理 。

“计算向数据靠拢”：

​ MapReduce设计的一个理念就是“计算向数据靠拢”，而不是“数据向计算靠拢”，因为，移动数据需要大量的 网络传输开销

MapReduce工作流程 与各个执行阶段工作

MapReduce工作流程：

​

不同的Map任务之间不会进行通信

不同的Reduce任务之间也不会发生任何信息交换

用户不能显式地从一台机器向另一台机器发送消息

所有的数据交换都是通过MapReduce框架自身去实现的

各个执行阶段工作：

MapReduce的WORDCOUNT执行实例计算过程

（待补充）

MapReduce实现关系运算

关系代数运算（选择、投影、并、交、差、连接）

分组与聚合运算

矩阵-向量乘法

矩阵乘法

第九章

Spark与Hadoop的对比，SPARK高性能的原因

Spark的计算模式也属于MapReduce，但不局限于Map和Reduce操作，还提供了多种数据集操作类型，编程模型比Hadoop MapReduce更灵活
Spark提供了内存计算，可将中间结果放到内存中，对于迭代运算效率更高
Spark基于DAG的任务调度执行机制，要优于Hadoop MapReduce的迭代执行机制
使用Hadoop进行迭代计算非常耗资源，Spark将数据载入内存后，之后的迭代计算都可以直接使用内存中的中间结果作运算，避免了从磁盘中频繁读取数据

大数据处理的三种类型与其适用的Spark技术栈

在实际应用中，大数据处理主要包括以下三个类型：

复杂的批量数据处理：通常时间跨度在数十分钟到数小时之间
基于历史数据的交互式查询：通常时间跨度在数十秒到数分钟之间
基于实时数据流的数据处理：通常时间跨度在数百毫秒到数秒之间

应用场景	时间跨度	其他框架	Spark生态系统中的组件
复杂的批量数据处理	小时级	MapReduce、Hive	Spark Core
基于历史数据的交互式查询	分钟级、秒级	Impala、Dremel、 Drill	Spark SQL
基于实时数据流的数据处理	毫秒、秒级	Storm、S4	Spark Streaming

RDD的设计与运行原理（所有概念需要能够理解其内容与思想，并用自己语言说明）

（待补充）

第十章

流数据的特征

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

批量计算与实时计算的含义

批量计算以“静态数据”为对象，可以在很充裕的时间内对海量数据进行批量处理，计算得到有价值的信息。

实时计算最重要的一个需求是能够实时得到计算结果，一般要求响应时间为秒级。

流数据必须采用实时计算，响应时间为秒级

流计算的要求，Hadoop不适用于流计算的原因

对于一个流计算系统来说，它应达到如下需求：

高性能。处理大数据的基本要求，如每秒处理几十万条数据。
海量式。支持TB级甚至是PB级的数据规模。
实时性。必须保证一个较低的延迟时间，达到秒级别，甚至是毫秒级别。
分布式。支持大数据的基本架构，必须能够平滑扩展。
易用性。能够快速进行开发和部署。
可靠性。能可靠地处理流数据。

Hadoop不适用于流计算的原因：

切分成小的片段，虽然可以降低延迟，但是也增加了任务处理的附加开销，而且还要处理片段之间的依赖关系，因为一个片段可能需要用到前一个片段的计算结果
需要对MapReduce进行改造以支持流式处理，Reduce阶段的结果不能直接输出，而是保存在内存中。这种做法会大大增加MapReduce框架的复杂度，导致系统难以维护和扩展。
降低了用户程序的可伸缩性，因为用户必须要使用MapReduce接口来定义流式作业

流计算处理流程