[color=red]之前研究hadoop但是笔记和记录都比较散，以后定期的整理到这技术博客中，希望可以帮到大家[/color]：
[b]HDFS数据存储[/b]
[i]NameNode:[/i]
接收客户端的读写服务，
NameNode保存metadata信息包括：
文件owership和permission，
文件包含那些块，block
保存在那个DataNode上。【datanode启动时上报到nameNode】
[b]NameNode[/b]的metadata信息在启动后会加载到内存，
Metadata存储到磁盘的文件名为”fsimage”
Block的位置信息不回保存到fsimage
edits记录对metaImage的操作日志。
文件被切分成固定的大小，默认是64M可以修改，若文件不到64M单独作为一个block
一个文件的存储方式：按照文件的大小切分成若干block，存储到不同的节点上，
默认情况会有每个block会有3个副本
Block大小和副本是通过上传客户端上传文件设置的，文件上传成功后副本数变更，block size不能修改。
比如一个50G的文件将会产生好多个block块，每个block块默认会在3个不同的server上存一份。如果一个server挂了，检测副本数小于指定的副本时候会复制一份block放到别的好的server上
[b]SecondNameNode[/b]:不是NN的备份，但是可以做部分的备份
主要工作是帮助NN合并editslog，减少NN启动时间。
SNN执行合并时间：
根据配置文件的时间间隔[i]fs.checkpoint.period[/i] 默认是3600秒
根据配置文件设置的edits log大小[i]fs.checkpoint.size[/i]规定edits文件最大默认值是64M
合并时候将edits文件和fsimage一同会转到secondNameNode的server合并同时在合并时候会产生新的edits文件，原来的文件用于合并，最后合并成一个新的fsimage替换原来的fsimage文件
[b]DateNode：[/b]
存储block数据
启动时候DN线程会向NN汇报block信息，
通过向NN发送心跳保持与其联系（3秒一次），如果10分钟没有收到心跳，则认为已
经丢失，并copy其上边的block到其他的DN
副本放置策略：第一个副本放置在上传文件的DN上，如果是集群外提交，则随便挑选一台磁盘不满，cpu不大忙的节点。
第二个副本：放置在第一个副本不同的机架的节点上，
第三个副本：与第二个副本相同的节点上。
更多副本：随机节点。
[b]HDFS读流程：[/b]
1.客户端发送请求，DistributeFileSystem open 获得block的位置信息NameNode。
2.收到位置信息开始read ，通过FSDateInputstream并发读取dataNode
3.关闭读取流
[b]HDFS写流程：[/b]
1. 通过DistributeFileSystem API调用一个create方法创建一个文件，传递文件名文件大小，传递给NN，NN收到信息会计算出需要多少个Block和存储的信息。
2.写入文件到一份DN，DN会创建线程往别的DN上复制副本，复制完成后会返回一个反馈上传成功的信息。
3.上传完成会客户端收到反馈会给NN一个 成功的消息。汇报给NN。
[b]
MapReduce分布式计算框架：[/b]
离线计算框架，分布式计算框架。
移动计算不移动数据。
分4个阶段：InputHDFS->（split -> mapping-> shuffing-> reducing）-> OutputHDFS->HDFSreplication
1.InputHDFS处理成一个个的split,
2.每一个split由一个mapTask线程执行
3.shuffing执行合并和排序，【将相同的单次进行合并】
3.Reduce执行之后计算出相应的数据。【reduce可以是一个】
4.OutputHDFS—》HDFSreplication
[b]Hadoop计算框架Shuffler：[/b]
在mapper和reduce中间的一个步骤，
可以把mapper的输出按照某种key值重新切分和组成n份，把key值符合某种范围的输出送到指定的reducer哪里去.（通过partiong后的数据分过来需要的数据）
MapTask执行后马上执行partion到缓存中，Map缓存在计算时候会出现溢写过程，溢写过程线程启动后，会执行sort和combiner到磁盘。
将disc中的文件在通过fetch的时候会通过parting的规则获得需要的parting数据，
可以简化reduce的过程。
每个mapTask都有一个缓存区，默认是100M存着map的输出结果。
当缓存区快满的时候需要将临时数据以一个临时文件的方式放入磁盘。
溢写（spill）是由单独的线程来完成的，不会影响往缓存区写map结果的线程，（spill.percent默认值是0.8）
当溢写线程启动后，需要对空间内的key做排序。
-假设client设置了conbiner,那么现在就是使用combiner的时候了，将具有相同key的key/value对value加起来，减少溢写到磁盘的数据量。
-当整个mapTask过程结束后对磁盘中mapTask所缠身的所有临时文件merge，对word就像是这样{“word”,[2,5,6,…]},假如有combiner,{word [13]},最终产生一个文件。
-reduce 从tasktracker copy数据。
-copy过来的数据先会放入缓存区中。这里的缓存区大小要比map端的更加灵活，它是基于JVM的head size设置的。
-merge有三种形式：1》内存到内存，2》内存到disk，3》disk到disk。 Merge从不同的tasktracker上拿到数据,{word [13,15,17]}
参考博客：http://langyu.iteye.com/blog/992916
[b]MapReduce的架构：[/b]
-主从架构
-[b]JobTracker[/b]
负责调度分配每一个子任务task运行于TaskTracker上，如果发现有失败的task就会重新分配任务到其他节点，每一个hadoop集群中只有一个JobTracker一般他运行在Master节点上。（2.0之后已经没有了）
-从[b]TaskTracker[/b]
TaskTracker主动与JobTracker通信，接收作业，并负责直接执行每一个任务。为了减少网络带宽Tasktracker最好运行在HDFS的DataNode上。
[b]Hadoop2产生的背景。[/b]
Hadoop1中的HDFS和Mapreduce在高可用，扩展性方面存在问题，
HDFS存在的问题：
NameNode单点故障，难以应用在线场景
NamoNode压力过大，且内存受限，影响系统的扩展。
Mapreduce存在的问题：
JobTracker访问压力大，影响系统的扩展性
难以支持Mapreduce[离线计算框架]之外的框架，如strom[流式计算框架]，Spark[内存计算框架]等
[b]Hadoop2.x由HDFS，Mapreduce和YARN三个分支完成[/b]
HDFS：NNFederation,HA。
1.解决HDFS1.0单点故障问和内存受限问题：
通过主备NN解决单点故障，如果主的NN发生故障，则切换到备的NN上。
所有的DN同时向两个NN汇报数据块信息。
具有两种切换选择
手动切换：通过命令实现主备之间的切换，可以在HDFS升级等场合，
自动切换：基于Zookeeper实现协调，基于zookeeper自动切换方案
ZookeeperFailoverContoller监控NN的健康状况
向zookeeper注册NN
NN挂掉后，ZKFC为NN的竞争锁，获得ZKFC锁的NN变为active
Zookeeper必须是奇数个的，内部是一种投票机制。
2.解决内存受限问题：Federation
HDFSFederation：将元数据分成多分，分散到多个节点中。使得NN可以通过增加机制来进行水平扩展，
能把单个NN负载分散到多个节点中，在HDFS数据规模较大的时候不会降低HDFS的性能。通过多个Namespace来隔离不同类型的应用，把不同类型应用的HDFS元数据的存储和管理分配到不同的NN中。
水平扩展，支持多个NN。
每个NN分管一部分目录。
所有的NN共享所有的DN存储资源。
2.0的框架变了使用方式上不变。
对HDFS使用者透明。
HDFS1.x中的命令和API都能使用。
搭建集群取数据是使用的多个集群。
[b]
YRAN：yet another resource negotiator[/b]
Hadoop2.0新引入的资源管理器，直接从MRv1演化而来的，
核心思想：将MRv1中的JobTracker的资源管理和任务调度两个功能分开，分别由ResourceManager和ApplicationMaster进程实现，
ResourceManager：负责整个集群的管理和调度，
ApplicationMaster：负责应用程序相关的事务，比如任务调度，任务监控和容错等。
YARN的引入，使得多个计算框架可运行在一个集群上中。
每个应用程序对应一个ApplicationMaster
[b]目前多个计算机框架可以运行在YARN上，比如MapReduce，Spark，Storm等。[/b]
[b]MapReduce：运行在YARN上的MR[/b]
YRAN：资源管理系统，有了这个可以有别的计算框架。2.0的优势
将MapReduce作业直接运行在YARN上，而不是由JobTracker和TaskTracker构建的MRv1系统中。
基本的功能模块
YARN:负责资源管理和调度
MRAppMaster：负责任务的切分，任务调度，任务监控和容错等；
MapTask/ReduceTask：任务驱动引擎，于MRv1一致；
每个MapReduce作业对应一个MapAppMaster
MRAppMaster任务调度，
YARN将资源分配给MRAppMaster
MapAppMaster进一步将资源分配给内部的任务。
MRAppMaster容错
失败后，由YARN重新启动，
任务失败后，MRAppMaster重新申请资源。
JN是共享的NN服务器，在linux下使用JN集群，
FailOverController：心跳检查使用Zookepper，
Zookeeper: 协调服务
针对HA使用Test版本的查询对照表请看下章安装配置：
