大数据技术基础（Hadoop、HDFS、HBase、NoSQL、MapReduce、Spark）

第 1 章-大数据概述

1.2 大数据概念

        大量化、快速化、多样化、价值化

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

1.6 大数据计算模式

第 2 章-大数据处理架构 Hadoop

2.1.1 Hadoop简介

        Hadoop是Apache软件基金会旗下的一个开源分布式计算平台，为用户提供了系统底层细节透明的分布式基础架构

        Hadoop是基于Java语言开发的，具有很好的跨平台特性，并且可以部署在廉价的计算机集群中

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

        Hadoop被公认为行业大数据标准开源软件，在分布式环境下提供了海量数据的处理能力

        几乎所有主流厂商都围绕Hadoop提供开发工具、开源软件、商业化工具和技术服务，如谷歌、雅虎、微软、思科、淘宝等，都支持Hadoop 

2.1.3 Hadoop的特性

        高可靠性    

        高效性    

        高可扩展性    

        高容错性    

        成本低    

        运行在Linux平台上    

        支持多种编程语言

2.2 Hadoop 生态系统

第 3 章-分布式文件系统 HDFS

3.1.1 计算机集群结构

        分布式文件系统把文件分布存储到多个计算机节点上，成千上万的计算机节点构成计算机集群

        与之前使用多个处理器和专用高级硬件的并行化处理装置不同的是，目前的分布式文件系统所采用的计算机集群，都是由普通硬件构成的，这就大大降低了硬件上的开销 

3.1.2    分布式文件系统的结构

        分布式文件系统在物理结构上是由计算机集群中的多个节点构成的，这些节点分为两类，一类叫“主节点”(Master Node)或者也被称为“名称结点”(NameNode)，另一类叫“从节点”（Slave Node）或者也被称为“数据节点”(DataNode)

3.2    HDFS简介

        总体而言，HDFS要实现以下目标：

        ●兼容廉价的硬件设备

        ●流数据读写

        ●大数据集

        ●简单的文件模型

        ●强大的跨平台兼容性

        HDFS特殊的设计，在实现上述优良特性的同时，也使得自身具有一些应用局限性，主要包括以下几个方面：

        ●不适合低延迟数据访问

        ●无法高效存储大量小文件

        ●不支持多用户写入及任意修改文件 

3.3 HDFS 的相关概念

3.3.1    块

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

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

        ●  支持大规模文件存储：文件以块为单位进行存储，一个大规模文件可以被分拆成若干个文件块，不同的文件块可以被分发到不同的节点上，因此，一个文件的大小不会受到单个节点的存储容量的限制，可以远远大于网络中任意节点的存储容量        

        ●    简化系统设计：首先，大大简化了存储管理，因为文件块大小是固定的，这样就可以很容易计算出一个节点可以存储多少文件块；其次，方便了元数据的管理，元数据不需要和文件块一起存储，可以由其他系统负责管理元数据        

        ●    适合数据备份：每个文件块都可以冗余存储到多个节点上，大大提高了系统的容错性和可用性

3.3.2    名称节点和数据节点

名称节点的数据结构

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

        FsImage用于维护文件系统树以及文件树中所有的文件和文件夹的元数据 操作日志文件

        EditLog中记录了所有针对文件的创建、删除、重命名等操作

        名称节点记录了每个文件中各个块所在的数据节点的位置信息

FsImage文件

        FsImage文件包含文件系统中所有目录和文件inode的序列化形式。每个inode是一个文件或目录的元数据的内部表示，并包含此类信息：文件的复制等级、修改和访问时间、访问权限、块大小以及组成文件的块。对于目录，则存储修改时间、权限和配额元数据

        FsImage文件没有记录每个块存储在哪个数据节点。而是由名称节点把这些映射信息保留在内存中，当数据节点加入HDFS集群时，数据节点会把自己所包含的块列表告知给名称节点，此后会定期执行这种告知操作，以确保名称节点的块映射是最新的。 

名称节点的启动

        在名称节点启动的时候，它会将FsImage文件中的内容加载到内存中，之后再执行EditLog文件中的各项操作，使得内存中的元数据和实际的同步，存在内存中的元数据支持客户端的读操作。

        一旦在内存中成功建立文件系统元数据的映射，则创建一个新的FsImage文件和一个空的EditLog文件

        名称节点起来之后，HDFS中的更新操作会重新写到EditLog文件中，因为FsImage文件一般都很大（GB级别的很常见），如果所有的更新操作都往FsImage文件中添加，这样会导致系统运行的十分缓慢，但是，如果往EditLog文件里面写就不会这样，因为EditLog 要小很多。每次执行写操作之后，且在向客户端发送成功代码之前，edits文件都需要同步更新

名称节点运行期间EditLog不断变大的问题

        在名称节点运行期间，HDFS的所有更新操作都是直接写到EditLog中，久而久之， EditLog文件将会变得很大

        虽然这对名称节点运行时候是没有什么明显影响的，但是，当名称节点重启的时候，名称节点需要先将FsImage里面的所有内容映像到内存中，然后再一条一条地执行EditLog中的记录，当EditLog文件非常大的时候，会导致名称节点启动操作非常慢，而在这段时间内HDFS系统处于安全模式，一直无法对外提供写操作，影响了用户的使用

        如何解决？答案是：SecondaryNameNode第二名称节点

        第二名称节点是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就变小了

数据节点（DataNode）

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

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

3.4.5    HDFS体系结构的局限性

        HDFS只设置唯一一个名称节点，这样做虽然大大简化了系统设计，但也带来了一些明显的局限性，具体如下：    

        （1）命名空间的限制：名称节点是保存在内存中的，因此，名称节点能够容纳的对象（文件、块）的个数会受到内存空间大小的限制。    

        （2）性能的瓶颈：整个分布式文件系统的吞吐量，受限于单个名称节点的吞吐量。    

        （3）隔离问题：由于集群中只有一个名称节点，只有一个命名空间，因此，无法对不同应用程序进行隔离。    

        （4）集群的可用性：一旦这个唯一的名称节点发生故障，会导致整个集群变得不可用。

3.5    HDFS存储原理

3.5.1    冗余数据保存

        作为一个分布式文件系统，为了保证系统的容错性和可用性，HDFS采用了多副本方式对数据进行冗余存储，通常一个数据块的多个副本会被分布到不同的数据节点上，如图3-5所示，数据块1被分别存放到数据节点A和C上，数据块2被存放在数据节点A和B上。这种多副本方式具有以下几个优点：    

        （1）加快数据传输速度    

        （2）容易检查数据错误    

        （3）保证数据可靠性

3.5.2    数据存取策略

1.数据存放

        （1）如果是在集群内发起写操作请求，则把第1个副本放置在发起写操作请求的数据节点上，实现就近写入数据。如果是在集群外发起写操作请求，则从集群内部挑选一台磁盘空间较为充足、CPU不太忙的数据节点，作为第1个副本的存放地。

        （2）第2个副本会被放置在与第1个副本不同的机架的数据节点上。

        （3）第3个副本会被放置在与第2个副本相同的机架的其他节点上。

        （4）如果还有更多的副本，则继续从集群中随机选择数据节点进行存放，限制每个节点不超过一个副本，同时保持每个机架的副本数量低于上限（(副本数量－1)/机架数量 + 2）。

2. 数据读取

        HDFS提供了一个API可以确定一个数据节点所属的机架ID，客户端也可以调用API获取自己所属的机架ID

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

3.5.3    数据错误与恢复

        HDFS具有较高的容错性，可以兼容廉价的硬件，它把硬件出错看作一种常态，而不是异常，并设计了相应的机制检测数据错误和进行自动恢复，主要包括以下几种情形：名称节点出错、数据节点出错和数据出错。

1. 名称节点出错        

        名称节点保存了所有的元数据信息，其中，最核心的两大数据结构是FsImage和Editlog，如果这两个文件发生损坏，那么整个HDFS实例将失效。因此，HDFS设置了备份机制，把这些核心文件同步复制到备份服务器SecondaryNameNode上。当名称节点出错时，就可以根据备份服务器SecondaryNameNode中的FsImage和Editlog数据进行恢复。

2. 数据节点出错

        每个数据节点会定期向名称节点发送“心跳”信息，向名称节点报告自己的状态

        当数据节点发生故障，或者网络发生断网时，名称节点就无法收到来自一些数据节点的心跳信息，这时，这些数据节点就会被标记为“宕机”，节点上面的所有数据都会被标记为“不可读”，名称节点不会再给它们发送任何I/O请求

        这时，有可能出现一种情形，即由于一些数据节点的不可用，会导致一些数据块的副本数量小于冗余因子

        名称节点会定期检查这种情况，一旦发现某个数据块的副本数量小于冗余因子，就会启动数据冗余复制，为它生成新的副本

        HDFS和其它分布式文件系统的最大区别就是可以调整冗余数据的位置

3. 数据出错

        网络传输和磁盘错误等因素，都会造成数据错误

        客户端在读取到数据后，会采用md5和sha1对数据块进行校验，以确定读取到正确的数据

        在文件被创建时，客户端就会对每一个文件块进行信息摘录，并把这些信息写入到同一个路径的隐藏文件里面

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

3.6    HDFS数据读写过程

读取文件

写入文件

        FileSystem是一个通用文件系统的抽象基类，可以被分布式文件系统继承，所有可能使用Hadoop文件系统的代码，都要使用这个类

        Hadoop为FileSystem这个抽象类提供了多种具体实现

        DistributedFileSystem就是FileSystem在HDFS文件系统中的具体实现

        FileSystem的open()方法返回的是一个输入流FSDataInputStream对象，在HDFS文件系统中，具体的输入流就是DFSInputStream；FileSystem中的create()方法返回的是一个输出流FSDataOutputStream对象，在HDFS文件系统中，具体的输出流就是DFSOutputStream。

3.6.1    读数据的过程

3.6.2    写数据的过程 

3.7.1    HDFS常用命令

        HDFS有很多shell命令，其中，fs命令可以说是HDFS最常用的命令 利用该命令可以查看HDFS文件系统的目录结构、上传和下载数据、 创建文件等。该命令的用法为：

        hadoop fs [genericOptions] [commandOptions]

        备注：Hadoop中有三种Shell命令方式：

        hadoop fs适用于任何不同的文件系统，比如本地文件系统和HDFS文件系统

        hadoop dfs只能适用于HDFS文件系统

        hdfs dfs跟hadoop dfs的命令作用一样，也只能适用于HDFS文件系统

        hadoop fs -ls <path>。显示<path>指定的文件的详细信息。

        hadoop fs -ls -R <path>。ls命令的递归版本。

        hadoop fs -cat <path>。将<path>指定的文件的内容输出到标准输出（stdout）。

        hadoop fs -mkdir [-p] <paths>。创建<paths>指定的一个或多个文件夹，-p选项用于递归创建子文件夹。  

        hadoop fs -copyFromLocal <localsrc>  <dst>。将本地源文件<localsrc>复制到路径<dst>指定的文件或文件夹中。  

        hadoop fs -copyToLocal [-ignorecrc] [-crc] <target>  <localdst>。将目标文件<target>复制到本地文件或文件夹<localdst>中，可用-ignorecrc选项复制CRC校验失败的文件，使用-crc选项复制文件以及CRC信息。  

        hadoop fs -cp <src>  <dst>。将文件从源路径<src>复制到目标路径<dst>。

        hadoop fs -get [-ignorecrc] [-crc] <src>  <localdst>。复制<src>指定的文件到本地文件系统<localdst>指定的文件或文件夹，可用-ignorecrc选项复制CRC校验失败的文件，使用-crc选项复制文件以及CRC信息。

        hadoop fs -rm <path>。删除<path>指定的文件，只删除非空目录和文件。  

        hadoop fs -rm -r <path>。删除<path>指定的文件夹及其下的所有文件，-r选项表示递归删除子目录。

第 4 章-分布式数据库 HBase

4.1.2 HBase 简介

        HBase是一个高可靠、高性能、面向列、可伸缩的分布式数据库，是谷歌BigTable的开源实现，主要用来存储非结构化和半结构化的松散数据。HBase的目标是处理非常庞大的表，可以通过水平扩展的方式，利用廉价计算机集群处理由超过10亿行数据和数百万列元素组成的数据表

        关系数据库已经流行很多年，并且Hadoop已经有了HDFS和MapReduce，为什么需要HBase?

        Hadoop可以很好地解决大规模数据的离线批量处理问题，但是，受限于Hadoop MapReduce编程框架的高延迟数据处理机制，使得Hadoop无法满足大规模数据实时处理应用的需求

        HDFS面向批量访问模式，不是随机访问模式

        传统的通用关系型数据库无法应对在数据规模剧增时导致的系统扩展性和性能问题（分库分表也不能很好解决）

        传统关系数据库在数据结构变化时一般需要停机维护；空列浪费存储空间

        因此，业界出现了一类面向半结构化数据存储和处理的高可扩展、低写入/查询延迟的系统，例如，键值数据库、文档数据库和列族数据库（如BigTable和HBase等）

        HBase已经成功应用于互联网服务领域和传统行业的众多在线式数据分析处理系统中

4.1.3    HBase与传统关系数据库的对比分析

        HBase与传统的关系数据库的区别主要体现在以下几个方面：

        （1）数据类型：关系数据库采用关系模型，具有丰富的数据类型和存储方式，HBase则采用了更加简单的数据模型，它把数据存储为未经解释的字符串

        （2）数据操作：关系数据库中包含了丰富的操作，其中会涉及复杂的多表连接。HBase操作则不存在复杂的表与表之间的关系，只有简单的插入、查询、删除、清空等，因为HBase在设计上就避免了复杂的表和表之间的关系

        （3）存储模式：关系数据库是基于行模式存储的。HBase是基于列存储的，每个列族都由几个文件保存，不同列族的文件是分离的

        （4）数据索引：关系数据库通常可以针对不同列构建复杂的多个索引，以提高数据访问性能。HBase只有一个索引——行键，通过巧妙的设计，HBase中的所有访问方法，或者通过行键访问，或者通过行键扫描，从而使得整个系统不会慢下来

        （5）数据维护：在关系数据库中，更新操作会用最新的当前值去替换记录中原来的旧值，旧值被覆盖后就不会存在。而在HBase中执行更新操作时，并不会删除数据旧的版本，而是生成一个新的版本，旧有的版本仍然保留

        （6）可伸缩性：关系数据库很难实现横向扩展，纵向扩展的空间也比较有限。相反，HBase和BigTable这些分布式数据库就是为了实现灵活的水平扩展而开发的，能够轻易地通过在集群中增加或者减少硬件数量来实现性能的伸缩

4.3.1    数据模型概述

        HBase是一个稀疏、多维度、排序的映射表，这张表的索引是行键、列族、列限定符和时间戳

        每个值是一个未经解释的字符串，没有数据类型

        用户在表中存储数据，每一行都有一个可排序的行键和任意多的列

        表在水平方向由一个或者多个列族组成，一个列族中可以包含任意多个列，同一个列族里面的数据存储在一起

        列族支持动态扩展，可以很轻松地添加一个列族或列，无需预先定义列的数量以及类型，所有列均以字符串形式存储，用户需要自行进行数据类型转换

        HBase中执行更新操作时，并不会删除数据旧的版本，而是生成一个新的版本，旧有的版本仍然保留（这是和HDFS只允许追加不允许修改的特性相关的）

4.3.2    数据模型相关概念

        表：HBase采用表来组织数据，表由行和列组成，列划分为若干个列族

        行：每个HBase表都由若干行组成，每个行由行键（row key）来标识。

        列族：一个HBase表被分组成许多“列族”（Column Family）的集合，它是基本的访问控制单元

        列限定符：列族里的数据通过列限定符（或列）来定位

        单元格：在HBase表中，通过行、列族和列限定符确定一个“单元格”（cell），单元格中存储的数据没有数据类型，总被视为字节数组byte[]

        时间戳：每个单元格都保存着同一份数据的多个版本，这些版本采用时间戳进行索引

4.3.3    数据坐标

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

4.4.1    HBase功能组件

        HBase的实现包括三个主要的功能组件：

        （1）库函数：链接到每个客户端

        （2）一个Master主服务器

        （3）许多个Region服务器

        主服务器Master负责管理和维护HBase表的分区信息，维护Region服务器列表，分配Region，负载均衡

        Region服务器负责存储和维护分配给自己的Region，处理来自客户端的读写请求

        客户端并不是直接从Master主服务器上读取数据，而是在获得Region的存储位置信息后，直接从Region服务器上读取数据

        客户端并不依赖Master，而是通过Zookeeper来获得Region位置信息，大多数客户端甚至从来不和Master通信，这种设计方式使得Master负载很小

4.4.3    Region的定位

1.HBase早期定位方法

        元数据表，又名.META.表，存储了Region和Region服务器的映射关系

        当HBase表很大时， .META.表也会被分裂成多个Region

        根数据表，又名-ROOT-表，记录所有元数据的具体位置

        -ROOT-表只有唯一一个Region，名字是在程序中被写死的

        Zookeeper文件记录了-ROOT-表的位置

        为了加快访问速度，.META.表的全部Region都会被保存在内存中

        假设.META.表的每行（一个映射条目）在内存中大约占用1KB，并且每个Region限制为128MB，那么，上面的三层结构可以保存的用户数据表的Region数目的计算方法是：

        （-ROOT-表能够寻址的.META.表的Region个数）×（每个.META.表的 Region可以寻址的用户数据表的Region个数）

        一个-ROOT-表最多只能有一个Region，也就是最多只能有128MB，按照每行（一个映射条目）占用1KB内存计算，128MB空间可以容纳128MB/1KB=2**17行，也就是说，一个-ROOT-表可以寻址2**17个.META.表的Region。

        同理，每个.META.表的 Region可以寻址的用户数据表的Region个数是128MB/1KB=2**17。

        最终，三层结构可以保存的Region数目是(128MB/1KB) × (128MB/1KB) = 2**34个Region

        客户端访问数据时的“三级寻址”

        为了加速寻址，客户端会缓存位置信息，同时，需要解决缓存失效问题

        寻址过程客户端只需要询问Zookeeper服务器，不需要连接Master服务器

2.HBase定位新方法

        通过三层结构虽然极大地扩展了可以容纳的Region数量，一直扩展到了 234个 Region，可是实际上并用不了这么多，虽然设计上是允许多个.META.表存在的，但是实际上在HBase的发展历史中，.META.表一直只有一个，所以，-ROOT表-中的记录一直都只有一行，-ROOT-表形同虚设。三层结构增加了代码的复杂度，容易产生BUG。因此，从0.96.0版本之后，HBase舍弃了三层结构，转而采用两层结构。-ROOT-表被去掉了，.MEAT.表被修改成hbase:meta表。

        采用两层结构以后的Region定位方法如下（如图4-9所示）：

        （1）客户端先通过ZooKeeper查询到哪台Region服务器上有hbase:meta表；

        （2）客户端连接含有hbase:meta表的Region服务器。hbase:meta表存储了所有Region的行键范围信息，通过这个表就可以查询出要存取的行键属于哪个Region的范围里面，以及这个Region又是属于哪个Region服务器。

        （3）获取这些信息后，客户端就可以直连其中一台拥有要存取的行键的Region服务器，并直接对其操作。

        （4）客户端会把定位信息缓存起来，下次操作就不需要进行以上加载hbase:meta表的步骤了。

4.5.1    HBase系统架构

        1. 客户端 客户端包含访问HBase的接口，同时在缓存中维护着已经访问过的Region位置信息，用来加快后续数据访问过程

        2. Zookeeper服务器 Zookeeper可以帮助选举出一个Master作为集群的总管，并保证在任何时刻总有唯一一个Master在运行，这就避免了Master的“单点失效”问题

        3. Master

        主服务器Master主要负责表和Region的管理工作：

        管理用户对表的增加、删除、修改、查询等操作

        实现不同Region服务器之间的负载均衡

        在Region分裂或合并后，负责重新调整Region的分布

        对发生故障失效的Region服务器上的Region进行迁移

        4. Region服务器

        Region服务器是HBase中最核心的模块，负责维护分配给自己的Region，并响应用户的读写请求

4.5.2    Region服务器工作原理

1. 用户读写数据过程

        用户写入数据时，被分配到相应Region服务器去执行

        用户数据首先被写入到MemStore和Hlog中

        只有当操作写入Hlog之后，commit()调用才会将其返回给客户端

        当用户读取数据时，Region服务器会首先访问MemStore缓存，如果找不到，再去磁盘上面的StoreFile中寻找

2. 缓存的刷新

        系统会周期性地把MemStore缓存里的内容刷写到磁盘的StoreFile文件中，清空缓存，并在Hlog里面写入一个标记

        每次刷写都生成一个新的StoreFile文件，因此，每个Store包含多个StoreFile文件

        每个Region服务器都有一个自己的HLog 文件，每次启动都检查该文件，确认最近一次执行缓存刷新操作之后是否发生新的写入操作；如果发现更新，则先写入MemStore，再刷写到StoreFile，最后删除旧的Hlog文件，开始为用户提供服务

3. StoreFile的合并

        每次刷写都生成一个新的StoreFile，数量太多，影响查找速度

        调用Store.compact()把多个合并成一个

        合并操作比较耗费资源，只有数量达到一个阈值才启动合并

4.5.4    HLog工作原理

        分布式环境必须要考虑系统出错。HBase采用HLog保证系统恢复

        HBase系统为每个Region服务器配置了一个HLog文件，它是一种预写式日志（Write Ahead Log）

        用户更新数据必须首先写入日志后，才能写入MemStore缓存，并且，直到MemStore缓存内容对应的日志已经写入磁盘，该缓存内容才能被刷写到磁盘

        Zookeeper会实时监测每个Region服务器的状态，当某个Region服务器发生故障时，Zookeeper会通知Master

        Master首先会处理该故障Region服务器上面遗留的HLog文件，这个遗留的HLog文件中包含了来自多个Region对象的日志记录

        系统会根据每条日志记录所属的Region对象对HLog数据进行拆分，分别放到相应Region对象的目录下，然后，再将失效的Region重新分配到可用的Region服务器中，并把与该Region对象相关的HLog日志记录也发送给相应的Region服务器

        Region服务器领取到分配给自己的Region对象以及与之相关的HLog日志记录以后，会重新做一遍日志记录中的各种操作，把日志记录中的数据写入到MemStore缓存中，然后，刷新到磁盘的StoreFile文件中，完成数据恢复

        共用日志优点：提高对表的写操作性能；缺点：恢复时需要分拆日志

第 5 章-NoSQL 数据库

5.1 NoSQL 简介

        通常，NoSQL数据库具有以下几个特点：

         （1）灵活的可扩展性

        （2）灵活的数据模型

        （3）与云计算紧密融合

        现在已经有很多公司使用了NoSQL数据库：

         Google Facebook Mozilla Adobe Foursquare LinkedIn Digg McGraw-Hill Education Vermont Public Radio 百度、腾讯、阿里、新浪、华为……

5.2  NoSQL兴起的原因

        1、关系数据库已经无法满足Web2.0的需求。

        主要表现在以下几个方面：

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

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

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

        MySQL集群是否可以完全解决问题？

        复杂性：部署、管理、配置很复杂

        数据库复制：MySQL主备之间采用复制方式，只能是异步复制，当主库压力较大时可能产生较大延迟，主备切换可能会丢失最后一部分更新事务，这时往往需要人工介入，备份和恢复不方便

        扩容问题：如果系统压力过大需要增加新的机器，这个过程涉及数据重新划分，整个过程比较复杂，且容易出错

        动态数据迁移问题：如果某个数据库组压力过大，需要将其中部分数据迁移出去，迁移过程需要总控节点整体协调，以及数据库节点的配合。这个过程很难做到自动化

2、“One size fits all”模式很难适用于截然不同的业务场景

        关系模型作为统一的数据模型既被用于数据分析，也被用于在线业务。但这两者一个强调高吞吐，一个强调低延时，已经演化出完全不同的架构。用同一套模型来抽象显然是不合适的

        Hadoop就是针对数据分析

        MongoDB、Redis等是针对在线业务，两者都抛弃了关系模型

3、关系数据库的关键特性包括完善的事务机制和高效的查询机制。但是，关系数据库引以为傲的两个关键特性，到了Web2.0时代却成了鸡肋，

        主要表现在以下几个方面：

        （1）Web2.0网站系统通常不要求严格的数据库事务

        （2）Web2.0并不要求严格的读写实时性

        （3）Web2.0通常不包含大量复杂的SQL查询（去结构化，存储空间换取更好的查询性能）

5.3  NoSQL与关系数据库的比较

总结

（1）关系数据库

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

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

（2）NoSQL数据库

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

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

关系数据库和NoSQL数据库各有优缺点，彼此无法取代

        关系数据库应用场景：电信、银行等领域的关键业务系统，需要保证强事务一致性

        NoSQL数据库应用场景：互联网企业、传统企业的非关键业务（比如数据分析）

采用混合架构

        案例：亚马逊公司就使用不同类型的数据库来支撑它的电子商务应用

        对于“购物篮”这种临时性数据，采用键值存储会更加高效

        当前的产品和订单信息则适合存放在关系数据库中

        大量的历史订单信息则适合保存在类似MongoDB的文档数据库中

5.4  NoSQL的四大类型

        NoSQL数据库虽然数量众多，但是，归结起来，典型的NoSQL数据库通常包括

        键值数据库、列族数据库、文档数据库和图数据库

5.5  NoSQL的三大基石

第 7 章-MapReduce

7.1.2    MapReduce模型简介

        MapReduce将复杂的、运行于大规模集群上的并行计算过程高度地抽象到了两个函数：Map和Reduce

        编程容易，不需要掌握分布式并行编程细节，也可以很容易把自己的程序运行在分布式系统上，完成海量数据的计算

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

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

        MapReduce框架采用了Master/Slave架构，包括一个Master和若干个Slave。Master上运行JobTracker，Slave上运行TaskTracker

        Hadoop框架是用Java实现的，但是，MapReduce应用程序则不一定要用Java来写

7.1.3    Map和Reduce函数

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

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

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

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

7.3.3    Shuffle过程详解

1. Shuffle过程简介

2. Map端的Shuffle过程

3. Reduce端的Shuffle过程

        Reduce任务通过RPC向JobTracker询问Map任务是否已经完成，若完成，则领取数据         Reduce领取数据先放入缓存，来自不同Map机器，先归并，再合并，写入磁盘

        多个溢写文件归并成一个或多个大文件，文件中的键值对是排序的

        当数据很少时，不需要溢写到磁盘，直接在缓存中归并，然后输出给Reduce

7.4.3    一个WordCount执行过程的实例

第 8 章-Hadoop 架构再探讨

8.1.1Hadoop的局限与不足

        Hadoop1.0的核心组件（仅指MapReduce和HDFS，不包括Hadoop生态系统内的Pig、Hive、HBase等其他组件），主要存在以下不足：

        抽象层次低，需人工编码

        表达能力有限

        开发者自己管理作业（Job）之间的依赖关系

        难以看到程序整体逻辑

        执行迭代操作效率低

        资源浪费（Map和Reduce分两阶段执行）

        实时性差（适合批处理，不支持实时交互式）

8.2.1HDFS HA

HDFS1.0组件及其功能回顾（具体请参见第3章HDFS）

名称节点保存元数据：

（1）在磁盘上：FsImage和EditLog

（2）在内存中：映射信息，即文件包含哪些块，每个块存储在哪个数据节点

第 10 章-Spark

10.1.1 Spark简介

Spark最初由美国加州伯克利大学（UCBerkeley）的AMP实验室于2009年开发，是基于内存计算的大数据并行计算框架，可用于构建大型的、低延迟的数据分析应用程序

2013年Spark加入Apache孵化器项目后发展迅猛，如今已成为Apache软件基金会最重要的三大分布式计算系统开源项目之一（Hadoop、Spark、Storm）

Spark在2014年打破了Hadoop保持的基准排序纪录

        Spark/206个节点/23分钟/100TB数据

        Hadoop/2000个节点/72分钟/100TB数据

        Spark用十分之一的计算资源，获得了比Hadoop快3倍的速度

Spark具有如下几个主要特点：

        运行速度快：使用DAG执行引擎以支持循环数据流与内存计算

        容易使用：支持使用Scala、Java、Python和R语言进行编程，可以通过Spark Shell进行交互式编程

        通用性：Spark提供了完整而强大的技术栈，包括SQL查询、流式计算、机器学习和图算法组件

        运行模式多样：可运行于独立的集群模式中，可运行于Hadoop中，也可运行于Amazon EC2等云环境中，并且可以访问HDFS、Cassandra、HBase、Hive等多种数据源

10.1.3 Spark与Hadoop的对比

Hadoop存在如下一些缺点：

表达能力有限

磁盘IO开销大

延迟高

        任务之间的衔接涉及IO开销

        在前一个任务执行完成之前，其他任务就无法开始，难以胜任复杂、多阶段的计算任务

Spark在借鉴Hadoop MapReduce优点的同时，很好地解决了MapReduce所面临的问题

相比于Hadoop MapReduce，Spark主要具有如下优点：

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

        Spark提供了内存计算，可将中间结果放到内存中，对于迭代运算效率更高

Spark基于DAG的任务调度执行机制，要优于Hadoop MapReduce的迭代执行机制

10.2 Spark生态系统

10.3.1 基本概念

10.3.2 架构设计

10.3.4  RDD的设计与运行原理

内容太多，参考ppt

10.5.2  RDD基本操作