大数据技术原理与应用笔记

第1章大数据概述

1.1大数据时代

1.2大数据概念

数据量大

数据类型繁多 -- 大数据是由结构化和非结构化数据组成的

处理速度快

价值密度低，商业价值高 -- 连续不间断监控过程中，可能有用的数据仅仅有一两秒，但是具有很高的商业价值

1.3大数据的影响

1.4大数据的应用

1.5大数据关键技术

1.6大数据计算模式

1.7大数据产业

1.8大数据与云计算、物联网的关系

云计算、大数据和物联网代表了IT领域最新的技术发展趋势，三者相辅相成，既有联系又有区别

1.8.1云计算

1.8.2物联网

第二章大数据处理架构Hadoop

2.1 概述

2.1.1 Hadoop简介

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

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

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

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

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

2.1.2 Hadoop发展简史

Hadoop是由Doug Cutting开发的文本搜索库。

2009年5月，Hadoop更是把1TB数据排序时间缩短到62秒。

2.1.3 Hadoop的特性！！！！！

Hadoop是一个能够对大量数据进行分布式处理的软件框架，并且是以一种可靠、高效、可伸缩的方式进行处理的

它具有以下几个方面的特性：

**高可靠性 **

**高效性 **

**高可扩展性 **

**高容错性 **

**成本低 **

**运行在Linux平台上 **

支持多种编程语言

2.1.3 Hadoop的应用现状

2.2 Hadoop项目结构

ps:加粗的是我们学过的

组件	功能
HDFS	分布式文件系统
MapReduce	分布式并行编程模型
YARN	资源管理和调度器
Tez	运行在YARN之上的下一代Hadoop查询处理框架
Hive	Hadoop上的数据仓库
HBase	Hadoop上的非关系型的分布式数据库
Pig	一个基于Hadoop的大规模数据分析平台，提供类似SQL的查询语言Pig Latin
Sqoop	用于在Hadoop与传统数据库之间进行数据传递
Oozie	Hadoop上的工作流管理系统
Zookeeper	提供分布式协调一致性服务
Storm	流计算框架
Flume	一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统
Ambari	Hadoop快速部署工具，支持Apache Hadoop集群的供应、管理和监控
Kafka	一种高吞吐量的分布式发布订阅消息系统，可以处理消费者规模的网站中的所有动作流数据
Spark	类似于Hadoop MapReduce的通用并行框架

2.4 Hadoop集群中的节点类型

Hadoop框架中最核心的设计是为海量数据提供存储的HDFS和对数据进行计算的MapReduce

MapReduce的作业主要包括：

（1）从磁盘或从网络读取数据，即IO密集工作；

（2）计算数据，即CPU密集工作

Hadoop集群的整体性能取决于CPU、内存、网络以及存储之间的性能平衡。因此运营团队在选择机器配置时要针对不同的工作节点选择合适硬件类型

一个基本的Hadoop集群中的节点主要有

NameNode：负责协调集群中的数据存储
DataNode：存储被拆分的数据块
JobTracker：协调数据计算任务
TaskTracker：负责执行由JobTracker指派的任务
SecondaryNameNode：帮助NameNode收集文件系统运行的状态信息

第三章分布式文件系统HDFS

3.1 分布式文件系统

3.1.1 计算机集群结构

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

3.1.2 分布式文件系统的结构

分布式文件系统在物理结构上是由计算机集群中的多个节点构成的

这些节点分为两类：

一类叫“主节点”(Master Node)或者也被称为“名称结点”(NameNode)
另一类叫“从节点”（Slave Node）或者也被称为“数据节点”(DataNode)

3.2 HDFS简介

3.2.1HDFS要实现以下目标

兼容廉价的硬件设备
流数据读写
大数据集
简单的文件模型
强大的跨平台兼容性

3.2.2HDFS的局限性

不适合低延迟数据访问
无法高效存储大量小文件
不支持多用户写入及任意修改文件

3.3 HDFS相关概念

3.3.1 块

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

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

支持大规模文件存储：文件以块为单位进行存储，一个大规模文件可以被分拆成若干个文件块，不同的文件块可以被分发到不同的节点上，因此，一个文件的大小不会受到单个节点的存储容量的限制，可以远远大于网络中任意节点的存储容量
简化系统设计：首先，大大简化了存储管理，因为文件块大小是固定的，这样就可以很容易计算出一个节点可以存储多少文件块；其次，方便了元数据的管理，元数据不需要和文件块一起存储，可以由其他系统负责管理元数据
适合数据备份：每个文件块都可以冗余存储到多个节点上，大大提高了系统的容错性和可用性

3.3.2 名称节点和数据节点

3.3.2.1名称节点的数据结构

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

FsImage用于维护文件系统树以及文件树中所有的文件和文件夹的元数据
操作日志文件EditLog中记录了所有针对文件的创建、删除、重命名等操作

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

3.3.2.2名称节点的启动

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

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

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

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

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

3.3.2.4数据节点（DataNode）

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

3.4 HDFS体系结构

3.4.1 HDFS体系结构概述

HDFS采用了主从（Master/Slave）结构模型，一个HDFS集群包括一个名称节点（NameNode）和若干个数据节点（DataNode）

3.4.2 HDFS命名空间管理

HDFS的命名空间包含目录、文件和块
在HDFS1.0体系结构中，在整个HDFS集群中只有一个命名空间，并且只有唯一一个名称节点，该节点负责对这个命名空间进行管理
HDFS使用的是传统的分级文件体系，因此，用户可以像使用普通文件系统一样，创建、删除目录和文件，在目录间转移文件，重命名文件等

3.4.3 通信协议

HDFS是一个部署在集群上的分布式文件系统，因此，很多数据需要通过网络进行传输
所有的HDFS通信协议都是构建在TCP/IP协议基础之上的
客户端通过一个可配置的端口向名称节点主动发起TCP连接，并使用客户端协议与名称节点进行交互
名称节点和数据节点之间则使用数据节点协议进行交互
客户端与数据节点的交互是通过RPC（Remote Procedure Call）来实现的。在设计上，名称节点不会主动发起RPC，而是响应来自客户端和数据节点的RPC请求

3.4.4 客户端

客户端是用户操作HDFS最常用的方式，HDFS在部署时都提供了客户端
HDFS客户端是一个库，暴露了HDFS文件系统接口，这些接口隐藏了HDFS实现中的大部分复杂性
严格来说，客户端并不算是HDFS的一部分
客户端可以支持打开、读取、写入等常见的操作，并且提供了类似Shell的命令行方式来访问HDFS中的数据
此外，HDFS也提供了Java API，作为应用程序访问文件系统的客户端编程接口

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 数据存取策略

数据存放
数据读取

3.5.3 数据错误与恢复

主要包括以下几种情形：名称节点出错、数据节点出错和数据出错。

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

3.6 HDFS数据读写过程

3.6.1 读数据的过程

3.6.2 写数据的过程

第四章分布式数据库HBase

表的结构看不懂就算了

4.1 概述

4.1.1 从BigTable说起

BigTable是一个分布式存储系统
BigTable起初用于解决典型的互联网搜索问题

建立互联网索引

1 爬虫持续不断地抓取新页面，这些页面每页一行地存储到BigTable里

2 MapReduce计算作业运行在整张表上，生成索引，为网络搜索应用做准备

搜索互联网

3 用户发起网络搜索请求

4 网络搜索应用查询建立好的索引，从BigTable得到网页

5 搜索结果提交给用户

BigTable是一个分布式存储系统

利用谷歌提出的MapReduce分布式并行计算模型来处理海量数据
使用谷歌分布式文件系统GFS作为底层数据存储
采用Chubby提供协同服务管理
可以扩展到PB级别的数据和上千台机器，具备广泛应用性、可扩展性、高性能和高可用性等特点
谷歌的许多项目都存储在BigTable中，包括搜索、地图、财经、打印、社交网站Orkut、视频共享网站YouTube和博客网站Blogger等

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.2 HBase访问接口

4.3 HBase数据模型

4.3.1 数据模型概述

HBase是一个稀疏、多维度、排序的映射表，这张表的索引是行键、列族、列限定符和时间戳
每个值是一个未经解释的字符串，没有数据类型
用户在表中存储数据，每一行都有一个可排序的行键和任意多的列表在水平方向由一个或者多个列族组成，一个列族中可以包含任意多个列，同一个列族里面的数据存储在一起
列族支持动态扩展，可以很轻松地添加一个列族或列，无需预先定义列的数量以及类型，所有列均以字符串形式存储，用户需要自行进行数据类型转换
HBase中执行更新操作时，并不会删除数据旧的版本，而是生成一个新的版本，旧有的版本仍然保留（这是和HDFS只允许追加不允许修改的特性相关的）

4.3.2 数据模型相关概念

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

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

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

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

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

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

4.3.3 数据坐标

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

键	值
[“201505003”, “Info”, “email”, 1174184619081]	“xie@qq.com”
[“201505003”, “Info”, “email”, 1174184620720]	“you@163.com”

4.4 HBase的实现原理

4.4.1 HBase功能组件

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

库函数：链接到每个客户端
一个Master主服务器
许多个Region服务器

主服务器Master负责管理和维护HBase表的分区信息，维护Region服务器列表，分配Region，负载均衡
Region服务器负责存储和维护分配给自己的Region，处理来自客户端的读写请求
客户端并不是直接从Master主服务器上读取数据，而是在获得Region的存储位置信息后，直接从Region服务器上读取数据
客户端并不依赖Master，而是通过Zookeeper来获得Region位置信息，大多数客户端甚至从来不和Master通信，这种设计方式使得Master负载很小

4.4.2 表和Region

4.4.3 Region的定位（HBase的三层结构）

元数据表，又名.META.表，存储了Region和Region服务器的映射关系
当HBase表很大时， .META.表也会被分裂成多个Region
根数据表，又名-ROOT-表，记录所有元数据的具体位置
-ROOT-表只有唯一一个Region，名字是在程序中被写死的
Zookeeper文件记录了-ROOT-表的位置

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

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

为了加速寻址，客户端会缓存位置信息，同时，需要解决缓存失效问题
寻址过程客户端只需要询问Zookeeper服务器，不需要连接Master服务器

4.5 HBase运行机制

4.5.1 HBase系统架构

客户端

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

Zookeeper服务器

Zookeeper可以帮助选举出一个Master作为集群的总管，并保证在任何时刻总有唯一一个Master在运行，这就避免了Master的“单点失效”问题
Zookeeper是一个很好的集群管理工具，被大量用于分布式计算，提供配置维护、域名服务、分布式同步、组服务等。

Master

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

管理用户对表的增加、删除、修改、查询等操作
实现不同Region服务器之间的负载均衡
在Region分裂或合并后，负责重新调整Region的分布
对发生故障失效的Region服务器上的Region进行迁移

Region服务器

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

4.5.2 Region服务器工作原理

用户读写数据过程
缓存的刷新
StoreFile的合并

4.5.2.1 用户读写数据过程

用户写入数据时，被分配到相应Region服务器去执行
用户数据首先被写入到MemStore和Hlog中
只有当操作写入Hlog之后，commit()调用才会将其返回给客户端
当用户读取数据时，Region服务器会首先访问MemStore缓存，如果找不到，再去磁盘上面的StoreFile中寻找

4.5.2.2 缓存的刷新

系统会周期性地把MemStore缓存里的内容刷写到磁盘的StoreFile文件中，清空缓存，并在Hlog里面写入一个标记
每次刷写都生成一个新的StoreFile文件，因此，每个Store包含多个StoreFile文件
每个Region服务器都有一个自己的HLog 文件，每次启动都检查该文件，确认最近一次执行缓存刷新操作之后是否发生新的写入操作；如果发现更新，则先写入MemStore，再刷写到StoreFile，最后删除旧的Hlog文件，开始为用户提供服务

4.5.2.3 StoreFile的合并

每次刷写都生成一个新的StoreFile，数量太多，影响查找速度
调用Store.compact()把多个合并成一个
合并操作比较耗费资源，只有数量达到一个阈值才启动合并

4.5.3 Store工作原理

Store是Region服务器的核心
多个StoreFile合并成一个
单个StoreFile过大时，又触发分裂操作，1个父Region被分裂成两个子Region

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文件中，完成数据恢复

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

4.6 HBase性能监视

Master-status(自带)
Ganglia
OpenTSDB
Ambari

4.7 性能优化

行键（Row Key）
InMemory
Max Version
Time To Live

第七章 MapReduce

7.1 概述

分布式程序运行在大规模计算机集群上，可以并行执行大规模数据处理任务，从而获得海量的计算能力
谷歌公司最先提出了分布式并行编程模型MapReduce，Hadoop MapReduce是它的开源实现，后者比前者使用门槛低很多

7.1.1 分布式并行编程

问题：在MapReduce出现之前，已经有像MPI这样非常成熟的并行计算框架了，那么为什么Google还需要MapReduce？MapReduce相较于传统的并行计算框架有什么优势？

	传统并行计算框架	MapReduce
集群架构/容错性	共享式(共享内存/共享存储)，容错性差	非共享式，容错性好
硬件/价格/扩展性	刀片服务器、高速网、SAN，价格贵，扩展性差	普通PC机，便宜，扩展性好
编程/学习难度	what-how，难	what，简单
适用场景	实时、细粒度计算、计算密集型	批处理、非实时、数据密集型

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.2 MapReduce适用场景

适合用MapReduce模型来处理的数据集需要满足一个前提条件：

待处理的数据集可以分解成许多小的数据集，而且每一个小数据集都可以完全并行地进行处理。

7.1.3 Map和Reduce函数

函数	输入	输出	说明
Map	<k1,v1>如：<行号,”a b c”>	List(<k2,v2>)如：<“a”,1><“b”,1><“c”,1>	1.将小数据集进一步解析成一批<key,value>对，输入Map函数中进行处理2.每一个输入的<k1,v1>会输出一批<k2,v2>。<k2,v2>是计算的中间结果
Reduce	<k2,List(v2)>如：<“a”,<1,1,1>>	<k3,v3><“a”,3>	输入的中间结果<k2,List(v2)>中的List(v2)表示是一批属于同一个k2的value

7.2 MapReduce的体系结构

MapReduce体系结构主要由四个部分组成，分别是：Client、JobTracker、TaskTracker以及Task

1）Client

用户编写的MapReduce程序通过Client提交到JobTracker端
用户可通过Client提供的一些接口查看作业运行状态

2）JobTracker

JobTracker负责资源监控和作业调度
JobTracker 监控所有TaskTracker与Job的健康状况，一旦发现失败，就将相应的任务转移到其他节点
JobTracker 会跟踪任务的执行进度、资源使用量等信息，并将这些信息告诉任务调度器（TaskScheduler），而调度器会在资源出现空闲时，选择合适的任务去使用这些资源

3）TaskTracker

TaskTracker 会周期性地通过“心跳”将本节点上资源的使用情况和任务的运行进度汇报给JobTracker，同时接收JobTracker 发送过来的命令并执行相应的操作（如启动新任务、杀死任务等）
TaskTracker 使用“slot(槽)”等量划分本节点上的资源量（CPU、内存等）。一个Task 获取到一个slot 后才有机会运行，而Hadoop调度器的作用就是将各个TaskTracker上的空闲slot分配给Task使用。slot 分为Map slot 和Reduce slot 两种，分别供MapTask 和Reduce Task 使用

4）Task

Task 分为Map Task 和Reduce Task 两种，均由TaskTracker 启动

7.3 MapReduce工作流程

7.3.1 工作流程概述

不同的Map任务之间不会进行通信
不同的Reduce任务之间也不会发生任何信息交换
用户不能显式地从一台机器向另一台机器发送消息
所有的数据交换都是通过MapReduce框架自身去实现的

7.3.2 MapReduce各个执行阶段

关于Split（分片）

HDFS 以固定大小的block 为基本单位存储数据，而对于MapReduce 而言，其处理单位是split。split 是一个逻辑概念，它只包含一些元数据信息，比如数据起始位置、数据长度、数据所在节点等。它的划分方法完全由用户自己决定。

Map任务的数量

Hadoop为每个split创建一个Map任务，split 的多少决定了Map任务的数目。大多数情况下，理想的分片大小是一个HDFS块

Reduce任务的数量

最优的Reduce任务个数取决于集群中可用的reduce任务槽(slot)的数目
通常设置比reduce任务槽数目稍微小一些的Reduce任务个数（这样可以预留一些系统资源处理可能发生的错误）

7.3.3 Shuffle过程详解

Shuffle过程简介

Map端的Shuffle过程

合并（Combine）和归并（Merge）的区别：

两个键值对<“a”,1>和<“a”,1>，如果合并，会得到<“a”,2>，如果归并，会得到<“a”,<1,1>>

Reduce端的Shuffle过程

Reduce任务通过RPC向JobTracker询问Map任务是否已经完成，若完成，则领取数据
Reduce领取数据先放入缓存，来自不同Map机器，先归并，再合并，写入磁盘
多个溢写文件归并成一个或多个大文件，文件中的键值对是排序的
当数据很少时，不需要溢写到磁盘，直接在缓存中归并，然后输出给Reduce

7.4 一个WordCount执行过程的实例

图7-7 Map过程示意图

图7-8 用户没有定义Combiner时的Reduce过程示意图

图7-9 用户有定义Combiner时的Reduce过程示意图

7.5MapReduce的具体应用

MapReduce可以很好地应用于各种计算问题

关系代数运算（选择、投影、并、交、差、连接）
分组与聚合运算
矩阵-向量乘法
矩阵乘法

第十四章基于Hadoop的数据仓库Hive

14.1 概述

14.1.1 数据仓库概念

数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策。

14.1.2 传统数据仓库面临的挑战

（1）无法满足快速增长的海量数据存储需求

（2）无法有效处理不同类型的数据

（3）计算和处理能力不足

14.1.3 Hive简介

Hive是一个构建于Hadoop顶层的数据仓库工具
支持大规模数据存储、分析，具有良好的可扩展性
某种程度上可以看作是用户编程接口，本身不存储和处理数据
依赖分布式文件系统HDFS存储数据
依赖分布式并行计算模型MapReduce处理数据
定义了简单的类似SQL 的查询语言——HiveQL
用户可以通过编写的HiveQL语句运行MapReduce任务
可以很容易把原来构建在关系数据库上的数据仓库应用程序移植到Hadoop平台上
是一个可以提供有效、合理、直观组织和使用数据的分析工具

Hive具有的特点非常适用于数据仓库

采用批处理方式处理海量数据

Hive需要把HiveQL语句转换成MapReduce任务进行运行
数据仓库存储的是静态数据，对静态数据的分析适合采用批处理方式，不需要快速响应给出结果，而且数据本身也不会频繁变化

提供适合数据仓库操作的工具

Hive本身提供了一系列对数据进行提取、转换、加载（ETL）的工具，可以存储、查询和分析存储在Hadoop中的大规模数据
这些工具能够很好地满足数据仓库各种应用场景

14.1.4 Hive与Hadoop生态系统中其他组件的关系

Hive依赖于HDFS 存储数据
Hive依赖于MapReduce 处理数据
在某些场景下Pig可以作为Hive的替代工具
HBase 提供数据的实时访问

14.1.5 Hive与传统数据库的对比分析

Hive在很多方面和传统的关系数据库类似，但是它的底层依赖的是HDFS和MapReduce，所以在很多方面又有别于传统数据库

对比项目	Hive	传统数据库
数据插入	支持批量导入	支持单条和批量导入
数据更新	不支持	支持
索引	支持	支持
分区	支持	支持
执行延迟	高	低
扩展性	好	有限

14.1.6 Hive在企业中的部署和应用

Hive在企业大数据分析平台中的应用

14.2 Hive系统架构

用户接口模块包括CLI、HWI、JDBC、ODBC、Thrift Server、
驱动模块（Driver）包括编译器、优化器、执行器等，负责把HiveSQL语句转换成一系列MapReduce作业
元数据存储模块（Metastore）是一个独立的关系型数据库（自带derby数据库，或MySQL数据库）

Hive通过给用户提供的一系列交互接口，接收到用户的指令(SQL)，使用自己的Driver，结合元数据(MetaStore)，将这些指令翻译成MapReduce，提交到Hadoop中执行，最后，将执行返回的结果输出到用户交互接口。

用户接口：Client CLI（hive shell）、JDBC/ODBC(java访问hive)、WEBUI（浏览器访问hive）
元数据：Metastore 元数据包括：表名、表所属的数据库（默认是default）、表的拥有者、列/分区字段、表的类型（是否是外部表）、表的数据所在目录等；默认存储在自带的derby数据库中，推荐使用MySQL存储Metastore
Hadoop：使用HDFS进行存储，使用MapReduce进行计算。
驱动器：Driver

（1）解析器（SQL Parser）：将SQL字符串转换成抽象语法树AST，这一步一般都用第三方工具库完成，比如antlr；对AST进行语法分析，比如表是否存在、字段是否存在、SQL语义是否有误。

（2）编译器（Physical Plan）：将AST编译生成逻辑执行计划。

（3）优化器（Query Optimizer）：对逻辑执行计划进行优化。

（4）执行器（Execution）：把逻辑执行计划转换成可以运行的物理计划。对于Hive来说，就是MR/Spark。

14.3 Hive工作原理

14.3.1 SQL语句转换成MapReduce的基本原理

join的实现原理

group by的实现原理

14.5 Impala

Impala和Hive、HDFS、HBase等工具是统一部署在一个Hadoop平台上的
Impala主要由Impalad，State Store和CLI三部分组成
Impala是由Cloudera公司开发的新型查询系统，它提供SQL语义，能查询存储在Hadoop的HDFS和HBase上的PB级大数据，在性能上比Hive高出3~30倍
Impala的运行需要依赖于Hive的元数据
Impala是参照 Dremel系统进行设计的
Impala采用了与商用并行关系数据库类似的分布式查询引擎，可以直接与HDFS和HBase进行交互查询
Impala和Hive采用相同的SQL语法、ODBC驱动程序和用户接口

Impala主要由Impalad，State Store和CLI三部分组成

说明：Impala中的元数据直接存储在Hive中。Impala采用与Hive相同的元数据、SQL语法、ODBC驱动程序和用户接口，从而使得在一个Hadoop平台上，可以统一部署Hive和Impala等分析工具，同时支持批处理和实时查询

Hive与Impala的不同点

Hive适合于长时间的批处理查询分析，而Impala适合于实时交互式SQL查询
Hive依赖于MapReduce计算框架，Impala把执行计划表现为一棵完整的执行计划树，直接分发执行计划到各个Impalad执行查询
Hive在执行过程中，如果内存放不下所有数据，则会使用外存，以保证查询能顺序执行完成，而Impala在遇到内存放不下数据时，不会利用外存，所以Impala目前处理查询时会受到一定的限制

Hive与Impala的相同点

Hive与Impala使用相同的存储数据池，都支持把数据存储于HDFS和HBase中
Hive与Impala使用相同的元数据
Hive与Impala中对SQL的解释处理比较相似，都是通过词法分析生成执行计划

14.6 Hive编程实践

14.6.2 Hive的数据类型

表 Hive的基本数据类型

类型	描述	示例
TINYINT	1个字节（8位）有符号整数	1
SMALLINT	2个字节（16位）有符号整数	1
INT	4个字节（32位）有符号整数	1
BIGINT	8个字节（64位）有符号整数	1
FLOAT	4个字节（32位）单精度浮点数	1.0
DOUBLE	8个字节（64位）双精度浮点数	1.0
BOOLEAN	布尔类型，true/false	true
STRING	字符串，可以指定字符集	“xmu”
TIMESTAMP	整数、浮点数或者字符串	1327882394（Unix新纪元秒）
BINARY	字节数组	[0,1,0,1,0,1,0,1]

表 Hive的集合数据类型

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