一、基础知识（里面的内容包含大部分的Hadoop的内容，耐心的看完，肯定有收获，如有不同可留言或者上某度）
1、Hadoop生态系统介绍
(1)HBase
Nosql 数据库，key-value存储
最大化利用内存
(2)HDFS
简介：Hadoop distribute file system 分布式文件系统
最大化利用磁盘
HDFS的设计原则：
文件以块（block）方式存储，默认块（64M）（如果一个文件没有64M，仍然占用一个block，但是物理内存可能没有没有64M），也可以自定义
通过副本机提高可靠度和读取吞吐量
每个区块至少分到三台DataNode上
单一master（NameNode）来协调存储元数据（metadata）单点故障？ 一般是standby nameNode 或者采用NFS服务避免单点故障
客户端对文件没有缓存机制（No data caching）
NameNode主要功能提供名称查询服务，它是一个jetty服务器
NameNode保存metadata信息包括
(I)文件owership 和Permissions
(II)文件包含哪些块
(III)Block保存在哪个DataNode（由DataNode启动时上报）
NameNode的metadata信息在启动后会加载到内存
metadata存储在磁盘文件名为"fsimage" 和Block 的位置信息不会保存到fsimage中（hdfs/namenode/current fsimage）
DataNode(DN):保存block，启动DataNode线程的时候会向NN(NameNode)汇报block信息
通过向NN发送心跳保持与其联系（3秒一次），如果NN 10分钟没有收到DN（DataNode）的心跳，则认为其已经lost，则copy其他的block 过来
Block的副本放置策略：
一般情况是保存三份：
第一份副本：放置在上传文件的DN，如果是集群外提交，则随机挑选一台磁盘不太满，CPU不太忙的节点
第二份副本：放置在于第一个副本不同的机架的节点上
第三份副本：放置在和第二份副本同一个机架的另一个节点上（ps:一个NameNode带动4000节点）
Block大小和副本数由Client端上传文件HDFS时设置，其中副本数可以变更，Block是不可以再上传后变更的
数据损坏处理（可靠性）：
当DN读取block的时候，它会计算checksum,如果计算后的checksum与block创建时值不一样，说明该block已经损坏的
Client读取其它DN上的block；NN标记该块已经损坏，然后复制block达到预期设置的文件备份数
DN在其文件创建后三周验证其checksum
SecondNameNode(SNN):(企业内很少使用，可以了解原理)（重点是fsimage和edits的机制）
将本地fsimage导入
是namenode的冷备份（无法做到自动的切换）
修改cluster所有的DN的NameNode地址
修改client端NameNode地址
or修改SNN IP为原NNIP
它的工作时帮助NN合并edits log 减少NN启动的时间
fsimage和edits(面试经常问到的问题):
当edits文件很大的时候，NameNode在启动的时候需要逐一每条的执行这些edits文件，这就严重影响到了整个HDFS的启动时间，这问题在SecondaryNameNode机制将edits文件合并到fsimage中，使其得到解决，SecondaryNameNode的工作流程（fsimage和edits log）：
1、SNN在一个checkpoint时间点和NameNode进行通信，请求NameNode停止使用edits文件记录相关操作而是暂时将新的writes操作写到新的文件edit.new来
2、SNN从NN上copy fsimage and edits ，通过HTTP Get的方式从NameNode中将fsimage和edits文件下载回来本地目录中
3、SNN中合并edits和fsimage，SNN将从NameNode中下载回来的fsimage加载到内存中，然后逐条执行edits文件中的各个操作项，使得加载到内存中的fsimage中包含edites中的操作，这个过程就是所谓的合并了。
4、在SNN中合并完fsimage和edites文件后，需要将新的fsimage回传到NameNode上，这个是通过HTTP Post方式进行的
5、NameNode将从SNN接受到的新的fsimage替换掉旧的fsimage，了，同时edites.new文件转换了通常的edites文件，这样edites文件的大小就得到了减少,SNN整个合并以及和NameNode
安全模式：
NameNode启动的时候，首先将映像文件(fsimage)载入内存，并执行编辑日志（edits）中的各项操作
一旦在内存中成功建立文件系统元数据的映射，则创建一个新的fsimage文件，这个操作不需要secondaryNameNode和一个空的编辑日志
NameNode开始监听RPC和Http请求
此刻namenode运行在安全模式，即namenode的文件系统对于客户端来说是只读的
系统中数据块位置并不是有namenode维护的，而是以块列表形式存储在datanode中
查看namenode处于哪个状态
Hadoop dfsadmin -safemode get
进入到安全模式（Hadoop）启动的时候是在安全模式
hadoop dfsadmin -safemode enter
退出安全模式;
hadoop dfsadmin -safemode leave
HDFS的读写过程（Hadoop 学习的精髓部分，编程开发必备前提知识，没有理由，必须学好^_^!）：
（1）客户端（client）用FileSystem的open()函数打开文件
（2）DisbutedFileSystem用RPC调用元数据节点，得到文件的数据块信息
（3）对于每一个数据块，元数据节点返回保存数据块的数据节点的地址
（4）DistributedFileSystem返回FSDataInputStream给客户端，用来读取数据
（5）客户端调用Stream的read()函数开始读取数据
（6）DFSInputStream 连接保存此文件第一个数据块的最近的数据节点
（7）Data从数据节点读取到客户端（client）
（8）当此数据块读取完毕时，DFSInputStream关闭和此数据节点的链接，然后连接此文件下一个数据最近的节点
（9）当客户端读取完毕数据的时候，调用FSDataInputStream的close函数
（10）在读取数据的过程中，如果客户端在于数据节点通信出现错误，则尝试连接包含此数据库的下一个数据节点
失败的数据节点将被记录，以后不再连接
写文件的过程：
（1）客户端调用creat()来创建文件
（2）DistributedFileSystem用RPC调用元数据节点，在文件系统的命名空间中创建一个新的文件
（3）元数据节点首先确定文件原来不存在，并且客户端有创建文件的权限，然后创建新文件
（4）DistributedFileSystem返回DFSOutStream，客户端用于写数据
（5）客户端开始写入数据，DFSOutStream 将数据分成块，写入data queue
（6）Data Stream 将数据块写入pipeline中的第一个数据节点，第一个数据节点将数据块发送给第二个数据节点，第二个数据节点将数据发送给第三个数据节点
（7）DFSOutStream为发出去的数据块保存了ack queue,等待pipeline中的数据节点告知数据已经写入
如果数据节点在写入的过程中失败：
关闭pipeline，将ack queue中的数据块放入data queue的开始
当前的数据块在已经写入的数据节点中被元数据节点赋予新的标示，则错误节点重启后能够察觉其数据块已经过时
，会被删除
失败的数据节点从pipeline中移除，另外的数据块则写入pipeline中的另外两个数据节点
元数据节点则被通知此数据块是复制块数不足，将来会再创建第三份备份
当客户端结束写入数据，则调用stream的close函数，此操作将所有的数据块写入pipeline中的数据节点，并等待ack queue返回成功。最后通知元数据节点写入完毕。
HDFS开发常用的命令（类shell语言）：
创建一个文件夹：
Hadoop fs -mkdir 文件夹
eg：Hadoop fs -mkdir /usr/hadoop/myfile
（文件夹）
上传一个文件：
Hadoop fs -put 文件 Hadoop的文件夹
eg:Hadoop fs -put /wordcount.jar /usr/hadoop/myfile
删除文件
Hadoop fs -rm 文件
查看一个文件夹里面有哪些内容文件？
Hadoop fs -ls 文件
查看文件的内容
Hadoop fs -text/ 文件
Hadoop管理员常用命令：
Hadoop job -list 列出正在运行的job
hadoop job -kill<job_id> kill job
Hadoop fsck 检查HDFS块状态，是否损坏
Hadoop dfsadmin -report 检查HDFS块状态，包括DN信息
Hadoop distcp hsfs:/// hdfs:// 并行拷贝
(3)MapReduce
(1)编程模型，主要用来做数据的分析
(2)最大化利用CPU