初学Hadoop

Hadoop：

是一个由Apache基金会所开发的分布式系统基础架构。

用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。

  Hadoop实现了一个分布式文件系统（Hadoop Distributed File System），简称HDFS。HDFS有高容错性的特点，并且设计用来部署在低廉的（low-cost）硬件上；而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。HDFS放宽了（relax）POSIX的要求，可以以流的形式访问（streaming access）文件系统中的数据。

Hadoop的框架最核心的设计就是：HDFS和MapReduce。HDFS为海量的数据提供了存储，则MapReduce为海量的数据提供了计算。

Hadoop的设计目的：

应对海量数据 2.对大数据进行分布式处理，实现google的mapreduce编程模型和框架，能够把应用程序分割成许多小的工作单元，并把这些单元放到任何集群节点上执行。

Hadoop的元素构成：

最底部是Hadoop Distributed File System（HDFS）:存储Hadoop集群中所有存储节点上的文件

HDFS的上一层引擎是MapReduce引擎：由JobTracker和TaskTracker组成

HDFS:

对外部客户机而言，HDFS就像一个传统的分级文件系统，可以创建、删除、移动或重命名文件等等。

HDFS的框架是基于一组特定的节点构建的，这是由它自身的特点决定的，这些节点包括：

NameNode（仅一个）：在HDFS中提供元数据服务；NameNode 是一个通常在 HDFS 实例中的单独机器上运行的软件。它负责管理文件系统名称空间；记录文件数据块在每个DataNode上的位置和副本信息；协调客户端对文件的访问；记录命名空间内的改动或命名空间本身属性的改动。

DataNode：为HDFS提供存储块，把HDFS数据块读写到本地的文件系统（存储实际的数据）。DataNode 也是一个通常在 HDFS实例中的单独机器上运行的软件。它负责所在物理节点上的存储管理。

客户端联系NameNode以获取文件的元数据，而真正的IO操作是直接和DataNode进行交互的。

NameNode使用事务日志（Editlog）记录HDFS，元数据变化使用映像文件存储文件系统的命名空间，包括文件的映射，文件的属性信息等。事务日志和映像文件都存储在NameNode的本地文件系统中。NameNode启动的时候，从磁盘中读取映像文件和事务日志，把事务日志的事物都应用到内存中的映像文件中，然后将新的元数据刷新到本地磁盘的新的映像文件中，这样可以截去旧的事务日志，这个过程被称为检查点。

副本的存放是HDFS可靠性和性能的关键。HDFS采用一种称之为Rack-Aware的策略来改进数据的可靠性、有效性和网络带宽的利用。

如果一个HDFS集群跨越了多个数据中心，那么也将首先尝试读本地数据中心的副本，NameNode自动会进入一个称之为SafeMode的特殊状态，处在这个状态的NameNode是不会进行数据块的复制的，NameNode从所有的DataNode接收心跳包（heartbeat）和Blockreport（块状态报告），Blockreport包括了某个DataNode所有的数据块列表，每个Block都有指定的数目的副本。当NameNode检测确认某个DataNode的数据块副本的最小数目，那么该DataNode就会被确认是安全的；如果一定百分比的数据确认是安全的，那么NameNode将退出SafeMode的状态，接下来它会确定还有哪些数据块的副本没有达到指定数目，并将这些Block复制到其他DataNode。

NameNode在内存中保存着整个文件系统的namespace（命名空间）和Blockmap的映像。

HDFS的特点：

 高度容错性的系统，并且设计用来部署在低廉的（low-cost）硬件上。

提供高吞吐量的数据访问，适合那些有着超大数据集（large data set）的应用程序。

 放宽了一部分POSIX约束，可以以流的形式访问（streaming access）文件系统中的数据。

Apache Nutch搜索引擎项目的基础架构

HDFS的缺点：

仅存在一个NameNode（单点失败）

HDFS的传输：

存储在HDFS中的文件被分成块，然后将这些块复制到多个计算机中。块的大小通常为64MB，和复制的块数量在创建时由客户机决定。Namenode可以控制所有文件操作。HDFS内部的所有通信都基于标准的TCP\IP协议

HDFS的主要目的

是支持以流的形式访问写入的大型文件，如果客户机想将文件写到HDFS上，首先需要将该文件缓存到本地的临时存储，如果缓存的大于所需的HDFS块大小，创建文件的请求将发送给NameNode，NameNode将以DataNode标志和目标块响应客户机，同时也通知将要保存文件块副本的DataNode为客户机开始将临时文件发送给第一个DataNode时，将立即通过管道方式将块内从转发给副本DataNode，客户机也负责创建保存在相同HDFS上名称空间中的校验和文件，在最后的文件块发送后NameNode将文件创建块提交到它的持久化元素、数据存储，在分布式存储和分布式计算方面，Hadoop使用主从，也就是master和slave架构，在一个配置完整的集群上有不同的角色行使各自的权利，来让Hadoop运行起来。

MapReduce：

是一种处理海量数据的并行编程模型的计算框架，用于对大规模数据集的并行运算。

在Hadoop中，分布式文件系统很大程度上是为各种分布式计算需求所服务的。从计算的角度，MapReduce框架接受各种格式的介质对文件作为输入、读取、计算后，最终生成了自定义格式的输出文件；从分布式角度，分布式计算的文件往往规模巨大，且分布在多台机器上，单机计算完全不可支撑且效率低下。

在MapReduce框架中，每一次计算请求称之为作业。

作业：

1．将作业拆分成若干个Map任务，分配到不同的机器上进行，每个Map拿输入文件的一部分作为自己的输入，经过一些计算生成某种格式的中间文件，这种格式与最终所需的文件格式完全一致

2．系统生成若干个Reduce 任务，也是分配到不同的机器中执行，它的目标就是将若干个Map任务生成的中间文件汇总到最后的输出文件。

作业服务器

在Hadoop中被称为Job Tracker：管理运行在此框架下的所有作业

 在Google论文中被称为Master：为各个作业分配任务的核心

客户端：是一组API

RPC服务器：由RPC的代理进行调用

 

Map函数的输出是一系列的Key/Value对，这些Key/Value对是给Reduce函数使用的，Map函数的输出参数也是Key/Value，与输入的Key/Value不是同一组东西。对于一个Map函数调用，输入的是一个Key/Value对，而输出是一组Key/Value对。

用户程序中的MapReduce Library会将输入的文件切分，由cluster（集群）的机器拷贝一份master，多份workers，master会将任务分配给workers。Master连接Map函数和Reduce函数，ReduceWorker将Key/Value对从MapWorker处通过RPC（远程过程调用协议）读取，读取完成后，将这些Key/Value对按照Key进行排序。ReduceWorker迭代整个被排序后的Key/Value对数据。

Master的三个作用：

将任务分配给了Worker

维护了所有Worker的信息和所处的状态

 将Map任务结果的位置告诉给Reduce任务

Master会每隔一段时间ping一次workers，如果一定时间内没有返回，那么Master会会认为这个机器宕掉了。

宕机状态分类：

Map任务正在执行。该Map任务需要分配到其他Worker上重新执行。

 Map任务已经完成。该Map任务需要分配到其他Worker上重新执行。

Reduce任务正在执行。该任务需要重新执行。

Reduce任务已经完成。这个情况下，该任务不需要重新执行，因为Reduce任务的结果是放在一个公共的分布式文件系统中，机器挂了，对于该结果的读取不会有任何影响。

如果Master宕掉了，整个MapReduce任务会被异常终止，用户程序能够捕获到这种异常，并决定是否重新执行。

Hadoop使用架构：

Master节点部署

NameNode

Secondary  NameNode：用来监控HDFS状态的辅助后台程序。每个集群都有一个Secondary NameNode，并且部署在一台单独的服务器上。与NameNode的区别在于它不接受或记录任何的数据变化，但它会与NameNode进行通信，定期保存HDFS的元数据快照。可作为NameNode备用使用。

JobTracker：跟踪所有运行的Task，一旦某个Task失败，JobTracker会自动重启这个Task：它还负责当用户代码提交到集群以后决定哪个文件被处理，并为不同的Task分配节点。每个Hadoop集群只有一个JobTracker，一般运行在Master节点上。

注：

1) 在小集群中，Secondary NameNode可以属于某个从节点

2) 在大型集群中，NameNode和JobTracker被分别部署在两台服务器上

 

Slave节电部署

DataNode

 TaskTracker：与DataNode配合，主要职责是与JobTracker交互。每个从节点仅有唯一的一个TaskTracker，用于并行处理多个Map以及Reduce任务

Hadoop集群运行模式：

单机模式：开始的调试工作

伪分布式模式：用不同的JAVA进程模拟分布式运行中的节点

完全分布式模式：不同的系统会有不同的节点划分方式

 

在HDFS方面，节点分为NameNode（只有一个）、DataNode（有多个）；

在MapReduce方面，节点分为JobTracker（只有一个）、TaskTracker（有多个）。

Hbase：

Hbase是一个分布式的、面向列的开源数据库。

NoSQL，泛指非关系型数据库。

Hbase的设计初衷是在商业服务器集群中完成从基础建设到水平扩展阶段。

在生产环境中使用Hbase的选择：使用Cloudera的CDH3版本;自行编译Hadoop branch-0.20-append源码分支

Hbase的优缺点

优点：消除了磁盘的随机写。

缺点：将最新的数据保存在了内存表中，对内存有较大需求。

解决方案：设计compaction（压缩）操作；设计split（分割）操作

 

Hbase的RegionServer（Hbase的服务，部署在一台物理服务器上）宕机超过一定时间后，HMaster会将会将其所管理的Region（类似分区）重新分布到其他存活的RegionServer，由于数据和日志都持久的存在于HDFS中，因此不会导致数据丢失。

RegionServer的内存表memstore如何在节点间做到更高的可用，是一个较大的挑战。

Hbase使用了较新的CMS GC（算法），默认触发GC的时机是当年老代内存达到90％的时候，这个百分比由CMSlnitiatingOccupancyFraction=N这个参数设置。

Hbase的适用场合

有足够多的数据存入Hbase

要确认即便不使用传统关系型数据库提供的额外功能，系统也能顺畅工作

有足够的硬件服务器来支撑Hbase的运行

Hbase的特点

高可靠性、高性能、列存储、可伸缩、实时读写

Hbase仅支持单行事务，主要用来存储非组结构化和半结构化的松散数据

Hive：

Hive是建立在Hadoop上的数据仓库基础构架，它提供了一系列工具，可以用来进行数据提取转化加载，这是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。

Hadoop用户接口主要有三个：CLI、Client、WUI。

CLI是最常用的，它启动的时候，会同时启动一个Hive副本。

Client是Hive的客户端，用户连接至Hive Sever，在启动Client模式的时候，需要指出Hive Sever所在节点，并在该节点启动Hive Sever。

WUI是通过浏览器访问Hive

 

Hive的元数据包括表的名字、表的列。表的分区及属性、表的属性、表的数据所在目录，等。

Hive连接到数据库的模式

Single User Mode（单用户模式）：连接到In-memory（存储器）的数据库Derby，一般用于Unit Test（单元测试）。

Multi User Mode（多用户模式）：通过网络连接到数据库，最常使用的模式。

Hive的数据模型：

Table

External table

Partition

Bucket

 

Hive的服务：

  -service     指定服务

 -service help 帮助

Hive支持的服务列表：Beeline、CLI、Help、Hive Service2、Hive Service、HWI、JAR、Lineage、Metastore、Metatool。

CLI：Hive的命令行界面，可直接在命令行中使用。

Hive Service：可以让Hive以提供Thrift（软件框架）服务的服务器形式来运行，可允许多不同语言编写的客户端进行通信。

HWI ：Hive的Web接口；Hive CLI的Web替换方案。

JAR：与Hadoop JAR包等价Hive的接口，这是运行在类路径中，同时包含Hadoop和Hive表的Java应用程序的简便方式。

Metastore：和Hive服务运行在同一个进程中；可让Metastore作为单独的进程运行；可通过METASTORE_PORT指定监听的端口号。

ZooKeeper：

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

ZooKeeper中的角色：

l 领导者：负责进行投票的发起和决议；更新系统状态

l 学习者

n 跟随者：用于接收客户请求并向客户端发送结果；参与投票

n 观察者：接收客户端连接；将写请求转发给领导者；不参与投票，只同步领导者的状态。目的：扩展系统，提高读取速度

l 客户端

ZooKeeper的设计目的：

最终的一致性

可靠性

实时性

等待无关

原子性

顺序性

全局有序

 偏序

ZooKeeper的工作原理：

ZooKeeper的核心是原子广播，这个机制保证了各个Server之间的同步，实现这个协议的协议是Zab协议，这个协议有俩个模式，分别是恢复模式和广播模式。当服务启动，或者在领导者崩溃后Zab就进入了恢复模式，当领导者被选举出来且大多数的Server完成了和领导者的状态同步以后，恢复模式结束。

Server的工作状态：

LOOKING:当前的Server不知道Leader是谁，正在搜寻

LEADING:当前的Server即为选举出来的Leader

 FOLLOWING: Leader已经选举出来 ，当前Server与之同步

ZooKeeper的选举算法：

基于Basic Paxos算法实现的：

 基于Fast Paxos算法实现的（系统默认）

Zoopeeper的同步流程：

1．Laeder等待Server连接

2．Follower连接Leader，将最大的zxid发送给Leader

3．Leader根据Follower的zxid确定同步点

4．完成同步后通知Follower已经成为UpToDate状态

5．Follower收到UpTo Date消息后，又可以重新接受Client的请求进行服务

 

Leader的功能：

恢复数据

维持与Learner的心跳，接收Learner的请求并判断Learner的请求消息类型

Follower的功能

向Leader发送请求

接收Leader消息并处理

接收Client的请求，如果为写请求，发送给Leader进行投票

返回Client结果

Follower的消息处理

 PING消息

 PROPOSAL消息

COMMIT消息

UPTODATE消息

REVALIDATE消息

l SYNC消息