一.hadoop是什么
Hadoop被公认是一套行业大数据标准开源软件，在分布式环境下提供了海量数据的处理能力。几乎所有主流厂商都围绕Hadoop开发工具、开源软件、商业化工具和技术服务。今年大型IT公司，如EMC、Microsoft、Intel、Teradata、Cisco都明显增加了Hadoop方面的投入。
二 .hadoop能干什么
hadoop擅长日志分析，facebook就用Hive来进行日志分析，2009年时facebook就有非编程人员的30%的人使用HiveQL进行数据分析；淘宝搜索中的自定义筛选也使用的Hive；利用Pig还可以做高级的数据处理，包括Twitter、LinkedIn 上用于发现您可能认识的人，可以实现类似Amazon.com的协同过滤的推荐效果。淘宝的商品推荐也是！在Yahoo！的40%的Hadoop作业是用pig运行的，包括垃圾邮件的识别和过滤，还有用户特征建模。
三.hadoop的核心
1.HDFS: Hadoop Distributed File System 分布式文件系统
2.YARN: Yet Another Resource Negotiator 资源管理调度系统
3.Mapreduce：分布式运算框架
四.HDFS的架构
主从结构
•主节点， namenode
•从节点，有很多个: datanode
namenode负责：
•接收用户操作请求
•维护文件系统的目录结构
•管理文件与block之间关系，block与datanode之间关系
datanode负责：
•存储文件
•文件被分成block存储在磁盘上
•为保证数据安全，文件会有多个副本
Secondary NameNode负责：
合并fsimage和edits文件来更新NameNode的metedata
五.Hadoop的特点
扩容能力（Scalable）：能可靠地（reliably）存储和处理千兆字节（PB）数据。
成本低（Economical）：可以通过普通机器组成的服务器群来分发以及处理数据。这些服务器群总计可达数千个节点。
高效率（Efficient）：通过分发数据，hadoop可以在数据所在的节点上并行地（parallel）处理它们，这使得处理非常的快速。
可靠性（Reliable）：hadoop能自动地维护数据的多份副本，并且在任务失败后能自动地重新部署（redeploy）计算任务。
六.NameNode
1.简介
namenode是整个文件系统的管理节点。他维护着整个文件系统的文件目录树，文件/目录的元信息和每个文件对应的数据块列表。接收用户的操作请求。
文件包括：
fsimage:元数据镜像文件。存储某一时段NameNode内存元数据信息。
edits:操作日志文件。
fstime:保存最近一次checkpoint的时间。
2.NameNode的工作特点
NameNode始终在内存中保存metedata，用于处理“读请求”，到有“写请求”到来时，NameNode首先会写editlog到磁盘，即向edits文件中写日志，成功返回后，才会修改内存，并且向客户端返回。
Hadoop会维护一个人fsimage文件，也就是NameNode中metedata的镜像，但是fsimage不会随时与NameNode内存中的metedata保持一致，而是每隔一段时间通过合并edits文件来更新内容。Secondary NameNode就是用来合并fsimage和edits文件来更新NameNode的metedata的。
3.什么时候checkpoint
fs.checkpoint.period 指定两次checkpoint的最大时间间隔，默认3600秒(1h)。
fs.checkpoint.size 规定edits文件的最大值，一旦超过这个值则强制checkpoint，不管是否到达最大时间间隔。默认大小是64M。
七.SecondaryNameNode
1.简介
HA的一个解决方案。但不支持热备。配置即可。
执行过程：从NameNode上下载元数据信息（fsimage,edits），然后把二者合并，生成新的fsimage，在本地保存，并将其推送到NameNode，替换旧的fsimage.
默认在安装在NameNode节点上，但这样...不安全！
2.工作流程
（1）secondary通知namenode切换edits文件(怎么通知的？)；
（2）secondary从namenode获得fsimage和edits(通过http)；
（3）secondary将fsimage载入内存，然后开始合并edits；
（4）secondary将新的fsimage发回给namenode；
（5）namenode用新的fsimage替换旧的fsimage；
八.DataNode
提供真实文件数据的存储服务。
文件块（block）：最基本的存储单位。对于文件内容而言，一个文件的长度大小是size，那么从文件的０偏移开始，按照固定的大小，顺序对文件进行划分并编号，划分好的每一个块称一个Block。HDFS默认Block大小是128MB，以一个256MB文件，共有256/128=2个Block.
dfs.block.size
不同于普通文件系统的是，HDFS中，如果一个文件小于一个数据块的大小，并不占用整个数据块存储空间;
Replication:多复本。默认是三个。
九.HDFS
（1）读过程
1.初始化FileSystem，然后客户端(client)用FileSystem的open()函数打开文件
2.FileSystem用RPC调用元数据节点，得到文件的数据块信息，对于每一个数据块，元数据节点返回保存数据块的数据节点的地址。
3.FileSystem返回FSDataInputStream给客户端，用来读取数据，客户端调用stream的read()函数开始读取数据。
4.DFSInputStream连接保存此文件第一个数据块的最近的数据节点，data从数据节点读到客户端(client)
5.当此数据块读取完毕时，DFSInputStream关闭和此数据节点的连接，然后连接此文件下一个数据块的最近的数据节点。
6.当客户端读取完毕数据的时候，调用FSDataInputStream的close函数。
7.在读取数据的过程中，如果客户端在与数据节点通信出现错误，则尝试连接包含此数据块的下一个数据节点。
8.失败的数据节点将被记录，以后不再连接。
8.失败的数据节点将被记录，以后不再连接。
（2）写过程
1.初始化FileSystem，客户端调用create()来创建文件
2.FileSystem用RPC调用元数据节点，在文件系统的命名空间中创建一个新的文件，元数据节点首先确定文件原来不存在，并且客户端有创建文件的权限，然后创建新文件。
3.FileSystem返回DFSOutputStream，客户端用于写数据，客户端开始写入数据。
4.DFSOutputStream将数据分成块，写入data queue。data queue由Data Streamer读取，并通知元数据节点分配数据节点，用来存储数据块(每块默认复制3块)。分配的数据节点放在一个pipeline里。Data Streamer将数据块写入pipeline中的第一个数据节点。第一个数据节点将数据块发送给第二个数据节点。第二个数据节点将数据发送给第三个数据节点。
5.DFSOutputStream为发出去的数据块保存了ack queue，等待pipeline中的数据节点告知数据已经写入成功。
6.当客户端结束写入数据，则调用stream的close函数。此操作将所有的数据块写入pipeline中的数据节点，并等待ack queue返回成功。最后通知元数据节点写入完毕。
7.如果数据节点在写入的过程中失败，关闭pipeline，将ack queue中的数据块放入data queue的开始，当前的数据块在已经写入的数据节点中被元数据节点赋予新的标示，则错误节点重启后能够察觉其数据块是过时的，会被删除。失败的数据节点从pipeline中移除，另外的数据块则写入pipeline中的另外两个数据节点。元数据节点则被通知此数据块是复制块数不足，将来会再创建第三份备份。
所以说呢，要想学习大数据的话Hadoop是必不可少要学习的分布式系统基础架构。下面的是小编整理的Hadoop的学习路线和Hadoop（视频+PPT）共208集
Namenode元数据信息维护的流程？
转载：
目录
一、前奏
二、HDFS的NameNode架构原理
一、前奏
Hadoop是目前大数据领域最主流的一套技术体系，包含了多种技术。
包括HDFS（分布式文件系统），YARN（分布式资源调度系统），MapReduce（分布式计算系统），等等。
有些朋友可能听说过Hadoop，但是却不太清楚他到底是个什么东西，这篇文章就用大白话给各位阐述一下。
假如你现在公司里的数据都是放在MySQL里的，那么就全部放在一台数据库服务器上，我们就假设这台服务器的磁盘空间有2T吧，大家先看下面这张图。
现在问题来了，你不停的往这台服务器的MySQL里放数据，结果数据量越来越大了，超过了2T的大小了，现在咋办？
你说，我可以搞多台MySQL数据库服务器，分库分表啊！每台服务器放一部分数据不就得了。如上图所示！
好，没问题，那咱们搞3台数据库服务器，3个MySQL实例，然后每台服务器都可以2T的数据。
现在我问你一个问题，所谓的大数据是在干什么？
我们来说一下大数据最初级的一个使用场景。假设你有一个电商网站，现在要把这个电商网站里所有的用户在页面和APP上的点击、购买、浏览的行为日志都存放起来分析。
你现在把这些数据全都放在了3台MySQL服务器，数据量很大，但还是勉强可以放的下。
某天早上，你的boss来了。要看一张报表，比如要看每天网站的X指标、Y指标、Z指标，等等，二三十个数据指标。
好了，兄弟，现在你尝试去从那些点击、购买、浏览的日志里，通过写一个SQL来分析出那二三十个指标试试看？
我跟你打赌，你绝对会写出来一个几百行起步，甚至上千行的超级复杂大SQL。这个SQL，你觉得他能运行在分库分表后的3台MySQL服务器上么？
如果你觉得可以的话，那你一定是不太了解MySQL分库分表后有多坑，几百行的大SQL跨库join，各种复杂的计算，根本不现实。
所以说，大数据的存储和计算压根儿不是靠MySQL来搞的，因此，Hadoop、Spark等大数据技术体系才应运而生。
本质上，Hadoop、Spark等大数据技术，其实就是一系列的分布式系统。
比如hadoop中的HDFS，就是大数据技术体系中的核心基石，负责分布式存储数据，这是啥意思？别急，继续往下看。
HDFS全称是Hadoop Distributed File System，是Hadoop的分布式文件系统。
它由很多机器组成，每台机器上运行一个DataNode进程，负责管理一部分数据。
然后有一台机器上运行了NameNode进程，NameNode大致可以认为是负责管理整个HDFS集群的这么一个进程，他里面存储了HDFS集群的所有元数据。
然后有很多台机器，每台机器存储一部分数据！好，HDFS现在可以很好的存储和管理大量的数据了。
这时候你肯定会有疑问：MySQL服务器也不是这样的吗？你要是这样想，那就大错特错了。
这个事情不是你想的那么简单的，HDFS天然就是分布式的技术，所以你上传大量数据，存储数据，管理数据，天然就可以用HDFS来做。
如果你硬要基于MySQL分库分表这个事儿，会痛苦很多倍，因为MySQL并不是设计为分布式系统架构的，他在分布式数据存储这块缺乏很多数据保障的机制。
好，你现在用HDFS分布式存储了数据，接着不就是要分布式来计算这些数据了吗？
对于分布式计算：
- 很多公司用Hive写几百行的大SQL（底层基于MapReduce）
- 也有很多公司开始慢慢的用Spark写几百行的大SQL（底层是Spark Core引擎）。
总之就是写一个大SQL，人家会拆分为很多的计算任务，放到各个机器上去，每个计算任务就负责计算一小部分数据，这就是所谓的分布式计算。
这个，绝对比你针对分库分表的MySQL来跑几百行大SQL要靠谱的多。
对于上述所说，老规矩，同样给大家来一张图，大伙儿跟着图来仔细捋一下整个过程。
二、HDFS的NameNode架构原理
好了，前奏铺垫完之后，进入正题。本文其实主要就是讨论一下HDFS集群中的NameNode的核心架构原理。
NameNode有一个很核心的功能：管理整个HDFS集群的元数据，比如说文件目录树、权限的设置、副本数的设置，等等。
下面就用最典型的文件目录树的维护，来给大家举例说明，我们看看下面的图。现在有一个客户端系统要上传一个1TB的大文件到HDFS集群里。
此时他会先跟NameNode通信，说：大哥，我想创建一个新的文件，他的名字叫“/usr/hive/warehouse/access_20180101.log”，大小是1TB，你看行不？
然后NameNode就会在自己内存的文件目录树里，在指定的目录下搞一个新的文件对象，名字就是“access_20180101.log”。
这个文件目录树不就是HDFS非常核心的一块元数据，维护了HDFS这个分布式文件系统中，有哪些目录，有哪些文件，对不对？
但是有个问题，这个文件目录树是在NameNode的内存里的啊！
这可坑爹了，你把重要的元数据都放在内存里，万一NameNode不小心宕机了可咋整？元数据不就全部丢失了？
可你要是每次都频繁的修改磁盘文件里的元数据，性能肯定是极低的啊！毕竟这是大量的磁盘随机读写！
没关系，我们来看看HDFS优雅的解决方案。
每次内存里改完了，写一条edits log，元数据修改的操作日志到磁盘文件里，不修改磁盘文件内容，就是顺序追加，这个性能就高多了。
每次NameNode重启的时候，把edits log里的操作日志读到内存里回放一下，不就可以恢复元数据了？
大家顺着上面的文字，把整个过程，用下面这张图跟着走一遍。
但是问题又来了，那edits log如果越来越大的话，岂不是每次重启都会很慢？因为要读取大量的edits log回放恢复元数据！
所以HDFS说，我可以这样子啊，我引入一个新的磁盘文件叫做fsimage，然后呢，再引入一个JournalNodes集群，以及一个Standby NameNode（备节点）。
每次Active NameNode（主节点）修改一次元数据都会生成一条edits log，除了写入本地磁盘文件，还会写入JournalNodes集群。
然后Standby NameNode就可以从JournalNodes集群拉取edits log，应用到自己内存的文件目录树里，跟Active NameNode保持一致。
然后每隔一段时间，Standby NameNode都把自己内存里的文件目录树写一份到磁盘上的fsimage，这可不是日志，这是完整的一份元数据。这个操作就是所谓的checkpoint检查点操作。
然后把这个fsimage上传到到Active NameNode，接着清空掉Active NameNode的旧的edits log文件，这里可能都有100万行修改日志了！
然后Active NameNode继续接收修改元数据的请求，再写入edits log，写了一小会儿，这里可能就几十行修改日志而已！
如果说此时，Active NameNode重启了，bingo！没关系，只要把Standby NameNode传过来的fsimage直接读到内存里，这个fsimage直接就是元数据，不需要做任何额外操作，纯读取，效率很高！
然后把新的edits log里少量的几十行的修改日志回放到内存里就ok了！
这个过程的启动速度就快的多了！因为不需要回放大量上百万行的edits log来恢复元数据了！如下图所示。
此外，大家看看上面这张图，现在咱们有俩NameNode。
- 一个是主节点对外提供服务接收请求
- 另外一个纯就是接收和同步主节点的edits log以及执行定期checkpoint的备节点。
大家有没有发现！他们俩内存里的元数据几乎是一模一样的啊！
所以呢，如果Active NameNode挂了，是不是可以立马切换成Standby NameNode对外提供服务？
这不就是所谓的NameNode主备高可用故障转移机制么！
接下来大家再想想，HDFS客户端在NameNode内存里的文件目录树，新加了一个文件。
但是这个时候，人家要把数据上传到多台DataNode机器上去啊，这可是一个1TB的大文件！咋传呢？
很简单，把1TB的大文件拆成N个block，每个block是128MB。1TB = 1024GB = 1048576MB，一个block是128MB，那么就是对应着8192个block。
这些block会分布在不同的机器上管理着，比如说一共有100台机器组成的集群，那么每台机器上放80个左右的block就ok了。
但是问题又来了，那如果这个时候1台机器宕机了，不就导致80个block丢失了？
也就是说上传上去的1TB的大文件，会丢失一小部分数据啊。没关系！HDFS都考虑好了！
它会默认给每个block搞3个副本，一模一样的副本，分放在不同的机器上，如果一台机器宕机了，同一个block还有另外两个副本在其他机器上呢！
大伙儿看看下面这张图。每个block都在不同的机器上有3个副本，任何一台机器宕机都没事！还可以从其他的机器上拿到那个block。
这下子，你往HDFS上传一个1TB的大文件，可以高枕无忧了吧！
OK，上面就是大白话加上一系列手绘图，给大家先聊聊小白都能听懂的Hadoop的基本架构原理。
三、Namenode容错机制
没有Namenode，HDFS就不能工作。事实上，如果运行namenode的机器坏掉的话，系统中的文件将会完全丢失，因为没有其他方法能够将位于不同datanode上的文件块(blocks)重建文件。因此，namenode的容错机制非常重要，Hadoop提供了两种机制。
第一种方式是将持久化存储在本地硬盘的文件系统元数据备份。Hadoop可以通过配置来让Namenode将他的持久化状态文件写到不同的文件系统中。这种写操作是同步并且是原子化的。比较常见的配置是在将持久化状态写到本地硬盘的同时，也写入到一个远程挂载的网络文件系统。
第二种方式是运行一个辅助的Namenode(Secondary Namenode)。 事实上Secondary Namenode并不能被用作Namenode它的主要作用是定期的将Namespace镜像与操作日志文件(edit log)合并，以防止操作日志文件(edit log)变得过大。通常，Secondary Namenode 运行在一个单独的物理机上，因为合并操作需要占用大量的CPU时间以及和Namenode相当的内存。辅助Namenode保存着合并后的Namespace镜像的一个备份，万一哪天Namenode宕机了，这个备份就可以用上了。
但是辅助Namenode总是落后于主Namenode，所以在Namenode宕机时，数据丢失是不可避免的。在这种情况下，一般的，要结合第一种方式中提到的远程挂载的网络文件系统(NFS)中的Namenode的元数据文件来使用，把NFS中的Namenode元数据文件，拷贝到辅助Namenode，并把辅助Namenode作为主Namenode来运行。
四、DataNode
Datanode是文件系统的工作节点，他们根据客户端或者是namenode的调度存储和检索数据，并且定期向namenode发送他们所存储的块(block)的列表。
集群中的每个服务器都运行一个DataNode后台程序，这个后台程序负责把HDFS数据块读写到本地的文件系统。当需要通过客户端读/写某个 数据时，先由NameNode告诉客户端去哪个DataNode进行具体的读/写操作，然后，客户端直接与这个DataNode服务器上的后台程序进行通 信，并且对相关的数据块进行读/写操作。
五、Secondary NameNode介绍
Secondary NameNode是一个用来监控HDFS状态的辅助后台程序。就想NameNode一样，每个集群都有一个Secondary NameNode，并且部署在一个单独的服务器上。Secondary NameNode不同于NameNode，它不接受或者记录任何实时的数据变化，但是，它会与NameNode进行通信，以便定期地保存HDFS元数据的 快照。由于NameNode是单点的，通过Secondary NameNode的快照功能，可以将NameNode的宕机时间和数据损失降低到最小。同时，如果NameNode发生问题，Secondary NameNode可以及时地作为备用NameNode使用。
5.1NameNode的目录结构如下：
${dfs.name.dir}/current/VERSION
/edits
/fsimage
/fstime
5.2Secondary NameNode的目录结构如下：
${fs.checkpoint.dir}/current/VERSION
/edits
/fsimage
/fstime
/previous.checkpoint/VERSION
/edits
/fsimage
/fstime
如上图，Secondary NameNode主要是做Namespace image和Edit log合并的。
那么这两种文件是做什么的？当客户端执行写操作，则NameNode会在edit log记录下来，（我感觉这个文件有些像Oracle的online redo logo file）并在内存中保存一份文件系统的元数据。
Namespace image（fsimage）文件是文件系统元数据的持久化检查点，不会在写操作后马上更新，因为fsimage写非常慢（这个有比较像datafile）。
由于Edit log不断增长，在NameNode重启时，会造成长时间NameNode处于安全模式，不可用状态，是非常不符合Hadoop的设计初衷。所以要周期性合并Edit log，但是这个工作由NameNode来完成，会占用大量资源，这样就出现了Secondary NameNode，它可以进行image检查点的处理工作。步骤如下：
（1） Secondary NameNode请求NameNode进行edit log的滚动（即创建一个新的edit log），将新的编辑操作记录到新生成的edit log文件；
（2） 通过http get方式，读取NameNode上的fsimage和edits文件，到Secondary NameNode上；
（3） 读取fsimage到内存中，即加载fsimage到内存，然后执行edits中所有操作（类似OracleDG，应用redo log），并生成一个新的fsimage文件，即这个检查点被创建；
（4） 通过http post方式，将新的fsimage文件传送到NameNode；
（5） NameNode使用新的fsimage替换原来的fsimage文件，让（1）创建的edits替代原来的edits文件；并且更新fsimage文件的检查点时间。
整个处理过程完成。
Secondary NameNode的处理，是将fsimage和edites文件周期的合并，不会造成nameNode重启时造成长时间不可访问的情况。
NameNode，DataNode和Client之间的通信方式介绍：
在hadoop系统中，master/slaves/client的对应关系是：
master---namenode；
slaves---datanode；
client---dfsclient；
那究竟是通过什么样的方式进行通信的呢，在这里从大体介绍一下：
简单地讲：
client和namenode之间是通过rpc通信；
datanode和namenode之间是通过rpc通信；
client和datanode之间是通过简单的socket通信。