hadoop核心

1.HDFS: Hadoop Distributed File System 分布式文件系统
2.YARN: Yet Another Resource Negotiator   资源管理调度系统
3.Mapreduce：分布式运算框架
-------------------------------

HDFS的架构

1.主从结构
主节点， namenode
从节点，有很多个: datanode

2.namenode负责：
接收用户操作请求
维护文件系统的目录结构
管理文件与block之间关系，block与datanode之间关系

3.datanode负责：
存储文件
文件被分成block存储在磁盘上
为保证数据安全，文件会有多个副本

-------------------------------------------------------------------------------------------

NameNode是整个文件系统的管理节点。它维护着整个文件系统的文件目录树，

文件/目录的元信息和每个文件对应的数据块列表。

接收用户的操作请求。

文件包括：
1.fsimage:元数据镜像文件。存储某一时段NameNode内存元数据信息。
2.edits:操作日志文件。
3.fstime:保存最近一次checkpoint的时间

工作特点:

1.Namenode始终在内存中保存metedata，用于处理“读请求”
2.到有“写请求”到来时，namenode会首先写editlog到磁盘，即向edits文件中写日志，成功返回后，才会修改内存，并且向客户端返回
3.Hadoop会维护一个fsimage文件，也就是namenode中metedata的镜像，但是fsimage不会随时与namenode内存中的metedata保持一致，

而是每隔一段时间通过合并edits文件来更新内容。Secondary namenode就是用来合并fsimage和edits文件来更新NameNode的metedata的。

执行过程：从NameNode上下载元数据信息（fsimage,edits），然后把二者合并，生成新的fsimage，在本地保存，并将其推送到NameNode，替换旧的fsimage.

secondary namenode的工作流程

1.secondary通知namenode切换edits文件
2.secondary从namenode获得fsimage和edits(通过http)
3.secondary将fsimage载入内存，然后开始合并edits
4.secondary将新的fsimage发回给namenode
5.namenode用新的fsimage替换旧的fsimage

什么时候checkpiont?
1.fs.checkpoint.period 指定两次checkpoint的最大时间间隔，默认3600秒。
2.fs.checkpoint.size    规定edits文件的最大值，一旦超过这个值则强制checkpoint，不管是否到达最大时间间隔。默认大小是64M。
----------------------------------------------------------------------------------------------

DataNode提供真实文件数据的存储服务。
1.文件块（block）：最基本的存储单位。对于文件内容而言，一个文件的长度大小是size，那么从文件的０偏移开始，按照固定的大小，

顺序对文件进行划分并编号，划分好的每一个块称一个Block。HDFS默认Block大小是128MB，以一个256MB文件，共有256/128=2个Block.
dfs.block.size
2.不同于普通文件系统的是，HDFS中，如果一个文件小于一个数据块的大小，并不占用整个数据块存储空间
3.Replication。多复本。默认是三个

---------------------------------------------------------------------------------------------------

MapReduce概述是一种分布式计算模型，由Google提出，主要用于搜索领域，解决海量数据的计算问题.
MR由两个阶段组成：Map和Reduce，用户只需要实现map()和reduce()两个函数，即可实现分布式计算，非常简单。
这两个函数的形参是key、value对，表示函数的输入信息。

MapReduce执行步骤：
 1. map任务处理
1.1 读取输入文件内容，解析成key、value对。对输入文件的每一行，解析成key、value对。每一个键值对调用一次map函数。
1.2 写自己的逻辑，对输入的key、value处理，转换成新的key、value输出。

2.reduce任务处理
2.1 在reduce之前，有一个shuffle的过程对多个map任务的输出进行合并、排序。
2.2写reduce函数自己的逻辑，对输入的key、value处理，转换成新的key、value输出。
2.3 把reduce的输出保存到文件中。

MR执行流程
    (1).客户端提交一个mr的jar包给JobClient(提交方式：hadoop jar ...)
    (2).JobClient通过RPC和JobTracker进行通信，返回一个存放jar包的地址（HDFS）和jobId
    (3).client将jar包写入到HDFS当中(path = hdfs上的地址 + jobId)
    (4).开始提交任务(任务的描述信息，不是jar, 包括jobid，jar存放的位置，配置信息等等)
    (5).JobTracker进行初始化任务
    (6).读取HDFS上的要处理的文件，开始计算输入分片，每一个分片对应一个MapperTask
    (7).TaskTracker通过心跳机制领取任务（任务的描述信息）
    (8).下载所需的jar，配置文件等
    (9).TaskTracker启动一个java child子进程，用来执行具体的任务（MapperTask或ReducerTask）
    (10).将结果写入到HDFS当中

MR过程各个角色的作用
1.jobClient：提交作业
2.JobTracker：初始化作业，分配作业，

3.TaskTracker与其进行通信，协调监控整个作业
4.TaskTracker：定期与JobTracker通信，执行Map和Reduce任务
5.HDFS：保存作业的数据、配置、jar包、结果
--------------------------------------------------------------------------------------------

YARN中运行一个作业的流程

1. 作业提交
YARN中的提交作业的API和经典的MapReduce很像(第1步). 作业提交的过程和经典的MapReduce很像, 新的作业ID(应用ID)由资源管理器分配(第2步). 作业的客户端核实作业的输出, 计算输入的split, 将作业的资源(包括Jar包, 配置文件, split信息)拷贝给HDFS(第3步). 最后, 通过调用资源管理器的submitApplication()来提交作业(第4步).

2. 作业初始化
当资源管理器收到submitApplciation()的请求时, 就将该请求发给调度器(scheduler), 调度器分配第一个container, 然后资源管理器在该container内启动应用管理器进程, 由节点管理器监控(第5a和5b步).

MapReduce作业的应用管理器是一个主类为MRAppMaster的Java应用. 其通过创造一些bookkeeping对象来监控作业的进度, 得到任务的进度和完成报告(第6步). 然后其通过分布式文件系统得到由客户端计算好的输入split(第7步). 然后为每个输入split创建一个map任务, 根据mapreduce.job.reduces创建reduce任务对象.

然后应用管理器决定如何运行构成整个作业的任务. 如果作业很小, 应用管理器会选择在其自己的JVM中运行任务, 这种作业称作是被unerized, 或者是以uber task的方式运行. 在任务运行之前, 作业的setup方法被调用来创建输出路径. 与MapRuduce 1中该方法由tasktracker运行的一个任务调用不同, 在YARN中是由应用管理器调用的.

3. 任务分配
如果不是小作业, 那么应用管理器向资源管理器请求container来运行所有的map和reduce任务(第8步). （注：每个任务对应一个container，且只能在该container上运行）这些请求是通过心跳来传输的, 包括每个map任务的数据位置, 比如存放输入split的主机名和机架(rack). 调度器利用这些信息来调度任务, 尽量将任务分配给存储数据的节点, 或者退而分配给和存放输入split的节点相同机架的节点.

请求也包括了任务的内存需求, 默认情况下map和reduce任务的内存需求都是1024MB. 可以通过mapreduce.map.memory.mb和mapreduce.reduce.memory.mb来配置.

分配内存的方式和MapReduce 1中不一样, MapReduce 1中每个tasktracker有固定数量的slot, slot是在集群配置是设置的, 每个任务运行在一个slot中, 每个slot都有最大内存限制, 这也是整个集群固定的. 这种方式很不灵活.

在YARN中, 资源划分的粒度更细. 应用的内存需求可以介于最小内存和最大内存之间, 并且必须是最小内存的倍数.

4. 任务运行
当一个任务由资源管理器的调度器分配给一个container后, 应用管理器通过练习节点管理器来启动container(第9a步和9b步). 任务有一个主类为YarnChild的Java应用执行. 在运行任务之前首先本地化任务需要的资源, 比如作业配置, JAR文件, 以及分布式缓存的所有文件(第10步). 最后, 运行map或reduce任务(第11步).

YarnChild运行在一个专用的JVM中, 但是YARN不支持JVM重用.

5. 进度和状态更新
YARN中的任务将其进度和状态(包括counter)返回给应用管理器, 后者通过每3秒的脐带接口有整个作业的视图(view). 这和MapRduce 1不太一样, 后者的进度流从tasktracker到jobtracker. 下图为MapReduce 2中的进度更新流:

客户端每秒(通过mapreduce.client.progressmonitor.pollinterval设置)向应用管理器请求进度更新, 展示给用户.

在MapReduce 1中, jobtracker的UI有运行的任务列表及其对应的进度. 在YARN中, 资源管理器的UI展示了所有的应用以及各自的应用管理器的UI.

6. 作业完成
除了向应用管理器请求作业进度外, 客户端每5分钟都会通过调用waitForCompletion()来检查作业是否完成. 时间间隔可以通过mapreduce.client.completion.pollinterval来设置.

作业完成之后, 应用管理器和container会清理工作状态, OutputCommiter的作业清理方法也会被调用. 作业的信息会被作业历史服务器存储以备之后用户核查.

---------------------------------------------------------------------------------------------

Hadoop的RPC框架运行机制

一： RPC的基础概念

　　RPC，即Remote Procdure Call，中文名：远程过程调用；

　　（1）它允许一台计算机程序远程调用另外一台计算机的子程序，而不用去关心底层的网络通信细节，对我们来说是透明的。

因此，它经常用于分布式网络通信中。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，

RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

　　（2）Hadoop的进程间交互都是通过RPC来进行的，比如Namenode与Datanode直接，Jobtracker与Tasktracker之间等。

       因此，可以说：Hadoop的运行就是建立在RPC基础之上的。

二：RPC的显著特点

　　（1）透明性：远程调用其他机器上的程序，对用户来说就像是调用本地方法一样；

　　（2）高性能：RPC Server能够并发处理多个来自Client的请求；

　　（3）可控性：jdk中已经提供了一个RPC框架—RMI，但是该PRC框架过于重量级并且可控之处比较少，所以Hadoop RPC实现了自定义的PRC框架。



三： RPC的基本流程

         （1）RPC采用了C/S的模式；

　　（2）Client端发送一个带有参数的请求信息到Server；

　　（3）Server接收到这个请求以后，根据发送过来的参数调用相应的程序，然后把自己计算好的结果发送给Client端；

　　（4）Client端接收到结果后继续运行；

四： Hadoop中的RPC机制

　　同其他RPC框架一样，Hadoop RPC分为四个部分：

　　（1）序列化层：Client与Server端通信传递的信息采用了Hadoop里提供的序列化类或自定义的Writable类型；

　　（2）函数调用层：Hadoop RPC通过动态代理以及Java反射实现函数调用；

　　（3）网络传输层：Hadoop RPC采用了基于TCP/IP的socket机制；

　　（4）服务器端框架层：RPC Server利用Java NIO以及采用了事件驱动的I/O模型，提高RPC Server的并发处理能力；


　　Hadoop RPC在整个Hadoop中应用非常广泛，Client、DataNode、NameNode之间的通讯全靠它了。例如：我们平时操作HDFS的时候，使用的是FileSystem类，它的内部有个DFSClient对象，这个对象负责与NameNode打交道。在运行时，DFSClient在本地创建一个NameNode的代理，然后就操作这个代理，这个代理就会通过网络，远程调用到NameNode的方法，也能返回值。

五： Hadoop RPC设计技术

　　（1）动态代理

About：动态代理可以提供对另一个对象的访问，同时隐藏实际对象的具体事实，代理对象对客户隐藏了实际对象。目前Java开发包中提供了对动态代理的支持，但现在只支持对接口的实现。

　　（2）反射——动态加载类

　　（3）序列化

　　（4）非阻塞的异步IO（NIO）

----------------------------------------------------------------------------------------

Zookeeper 是 Google 的 Chubby一个开源的实现，是 Hadoop 的分布式协调服务
它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等
为什么使用Zookeeper？
大部分分布式应用需要一个主控、协调器或控制器来管理物理分布的子进程（如资源、任务分配等）
目前，大部分应用需要开发私有的协调程序，缺乏一个通用的机制
协调程序的反复编写浪费，且难以形成通用、伸缩性好的协调器
ZooKeeper：提供通用的分布式锁服务，用以协调分布式应用

Zookeeper能帮我们做什么？
Hadoop2.0,使用Zookeeper的事件处理确保整个集群只有一个活跃的NameNode,存储配置信息等.
HBase,使用Zookeeper的事件处理确保整个集群只有一个HMaster,察觉HRegionServer联机和宕机,存储访问控制列表等.

Zookeeper的角色

1.领导者（leader），负责进行投票的发起和决议，更新系统状态
2.学习者（learner），包括跟随者（follower）和观察者（observer），follower用于接受客户端请求并想客户端返回结果，在选主过程中参与投票
3.Observer可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度
4.客户端（client），请求发起方

Zookeeper的读写机制

1.Zookeeper是一个由多个server组成的集群
2.一个leader，多个follower
3.每个server保存一份数据副本
4.全局数据一致
5.分布式读写
6.更新请求转发，由leader实施

Zookeeper的保证

1.更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行
2.数据更新原子性，一次数据更新要么成功，要么失败
3.全局唯一数据视图，client无论连接到哪个server，数据视图都是一致的
4.实时性，在一定事件范围内，client能读到最新数据

Zookeeper工作原理

Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。

Zab协议有两种模式，它们分别是恢复模式和广播模式。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，

当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。

状态同步保证了leader和server具有相同的系统状态。

一旦leader已经和多数的follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。

这时候当一个server加入zookeeper服务中，它会在恢复模式下启动，发现leader，并和leader进行状态同步。

待到同步结束，它也参与消息广播。Zookeeper服务一直维持在Broadcast状态，直到leader崩溃了或者leader失去了大部分的followers支持。

广播模式需要保证proposal被按顺序处理，因此zk采用了递增的事务id号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了zxid。

实现中zxid是一个64为的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch。低32位是个递增计数。
当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的server都恢复到一个正确的状态
------------------------------------------------------------------------------------------------------------------------

hadoop集群HA架构设计

涉及到的概念和作用解释：

1.zk : zookeeper,主要的作用是保证HA（high available 高可用），当一个namenode节点故障以后，切换备用namenode为主节点

2.FailoverControllerActive:也叫做DFSZKFailoverController,主要作用是检测namenode的状态，会用心跳的方式来判断namenode节点是否正常工作，

如果没有正常工作的话，会通知zk将备用namenode切换成主namenode

3.NN ACTIVE:namenode主节点，datanode的管理节点，是hdfs的组成部分，namenode会将上传到hdfs的文件的文件名，大小，在datanode的位置，

等等信息放在内存中，相面会详细说namenode

4.NN Standby：namenode备用节点，会在主节点故障的时候替代主节点，通过 shared NN state with single writer 来保持和主节点信息的同步

5.shared NN state with single writer：启动后的线程名字是JournalNode，主要存放的是namenode的edits文件，也就是namenode保存在硬盘的备份，这个线程时用来同步主备namenode的内存数据

6.DN:是datanode的缩写，主要是存放的文件的节点，默认一个块的大小是128M,可以选择文件的备份数量

高可用架构详细说明：

1.zookeeper是用来通过心跳机制来监测主备的namenode的状态，当主namenode出现故障的时候就会切换备namenode为主节点，实现了高可用的特性；

2.FailoverControllerActive：使用rpc来实现的心跳机制来

------------------------------------------------------------------------------------------------------------------

HBase – Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，

利用HBase技术可在廉价PC ServerHadoop 上搭建起大规模结构化存储集群。HBase利用HDFS作为其文件存储系统，

利用Hadoop MapReduce来处理HBase中的海量数据，利用Zookeeper作为协调工具。
-----------------------------------------------------------------------------------

Hive

1.什么是Hive

Hive是建立在 Hadoop  上的数据仓库基础构架。它提供了一系列的工具，可以用来进行数据提取转化加载（ETL ），这是一种可以存储、查询和分析存储在 Hadoop  中的大规模数据的机制。Hive 定义了简单的类 SQL  查询语言，称为 QL ，它允许熟悉 SQL  的用户查询数据。同时，这个语言也允许熟悉 MapReduce  开发者的开发自定义的 mapper  和 reducer  来处理内建的 mapper 和 reducer  无法完成的复杂的分析工作。

Hive是SQL解析引擎，它将SQL语句转译成M/R Job然后在Hadoop执行。
Hive的表其实就是HDFS的目录/文件，按表名把文件夹分开。如果是分区表，则分区值是子文件夹，可以直接在M/R Job里使用这些数据。

2.Hive的系统架构

1.用户接口主要有三个：CLI，JDBC/ODBC和 WebUI
CLI，即Shell命令行
JDBC/ODBC 是 Hive 的Java，与使用传统数据库JDBC的方式类似
WebGUI是通过浏览器访问 Hive
2.Hive 将元数据存储在数据库中(metastore)，目前只支持 mysql、derby。Hive 中的元数据包括表的名字，表的列和分区及其属性，表的属性（是否为外部表等），表的数据所在目录等
3.解释器、编译器、优化器完成 HQL 查询语句从词法分析、语法分析、编译、优化以及查询计划（plan）的生成。生成的查询计划存储在 HDFS 中，并在随后有 MapReduce 调用执行
4.Hive 的数据存储在 HDFS 中，大部分的查询由 MapReduce 完成（包含 * 的查询，比如 select * from table 不会生成 MapRedcue 任务）

-----------------------------------------------------------------------------