1、hadoop运行原理
hadoop主要由三方面组成:
1、HDFS ----- GFS
2、MapReduce -------MapReduce
3、Hbase ------------BigTable
2、HDFS存储机制
HDFS（Hadoop Distributed File System ）Hadoop分布式文件系统。是根据google发表的论文翻版的。论文为GFS（Google File System）Google 文件系统
HDFS（Hadoop Distributed File System）是Hadoop项目的核心子项目，是分布式计算中数据存储管理的基础，是基于流数据模式访问和处理超大文件的需求而开发的，可以运行于廉价的商用服务器上。
它所具有的高容错、高可靠性、高可扩展性、高获得性、高吞吐率等特征为海量数据提供了不怕故障的存储，为超大数据集（Large Data Set）的应用处理带来了很多便利
3、HDFS的优缺点比较
HDFS 的优点：
1、高容错性
1)数据自动保存多个副本。它通过增加副本的形式，提高容错性
2)某一个副本丢失以后，它可以自动恢复，这是由 HDFS 内部机制实现的，我们不必关心。
2、适合批处理
1)它是通过移动计算而不是移动数据
2)它会把数据位置暴露给计算框架。
3、适合大数据处理
1)处理数据达到 GB、TB、甚至PB级别的数据。
2)能够处理百万规模以上的文件数量，数量相当之大。
3)能够处理10K节点的规模
4、流式文件访问
1)一次写入，多次读取。文件一旦写入不能修改，只能追加。
2)它能保证数据的一致性。
5、可构建在廉价机器上
1)它通过多副本机制，提高可靠性。
2)它提供了容错和恢复机制。比如某一个副本丢失，可以通过其它副本来恢复。
HDFS 缺点（不适用适用HDFS的场景）：
1、低延时数据访问
1)比如毫秒级的来存储数据，这是不行的，它做不到。
2)它适合高吞吐率的场景，就是在某一时间内写入大量的数据。但是它在低延时的情况下是不行的，比如毫秒级以内读取数据，这样它是很难做到的。
2、小文件存储
1)存储大量小文件的话，它会占用 NameNode大量的内存来存储文件、目录和块信息。这样是不可取的，因为NameNode的内存总是有限的。
2)小文件存储的寻道时间会超过读取时间，它违反了HDFS的设计目标。
3、并发写入、文件随机修改
1)一个文件只能有一个写，不允许多个线程同时写。
2)仅支持数据 append（追加），不支持文件的随机修改。
4、HDFS 如何存储数据？
hdfs架构图
HDFS 数据存储单元（block）
– 文件被切分成固定大小的数据块
• 默认数据块大小为128MB，可配置。若文件大小不到128MB，则单独存成一个block。（hadoop1.x默认64M，hadoop2.x，默认128M）
—为何数据块如此之大？
其目的是为了最小化寻址开销。
但是该参数也不会设置的过大，MapReduce中的map任务通常一次处理一个块中的数据，因此如果任务太少（少于集群中的节点数量），作业的运行速度就会变慢
- 对分布式文件系统中的块进行抽象的好处
1、一个文件的大小可以大于网络中任意一个磁盘的容量
2、使用块抽象而非整个文件作为存储单元，大大简化了存储子系统的设计。不仅如此，块非常适合用于数据备份进而提供数据容错能力和可用性。
HDFS中 fsck 命令可以显示块信息
% hadoop fsck / -files -blocks
– 一个文件存储方式
• 按大小被切分成若干个block ，存储到不同节点上
• 默认情况下每个block都有三个副本
– Block大小和副本数通过Client端上传文件时设置，文件上传成功后副本
数可以变更，Block Size不可变更
数据存储： staging
HDFS client上传数据到HDFS时，首先，在本地缓存数据，当数据达到一个block大小时，请求NameNode分配一个block。
NameNode会把block所在的DataNode的地址告诉HDFS client。
HDFS client会直接和DataNode通信，把数据写到DataNode节点一个block文件中。
5、Namenode（NN）和datanode（DN）和SecondaryNameNode（SNN）
1、Namenode
Namenode是整个文件系统的管理节点。
– NameNode主要功能：接受客户端的读写服务
– NameNode保存metadate信息包括 。它维护着整个文件系统的文件目录树，文件/目录的元信息和每个文件对应的数据块列表。
• 文件owership和permissions
• 文件包含哪些块
• Block保存在哪个DataNode（由DataNode启动时上报）
– NameNode的metadate信息在启动后会加载到内存
• metadata存储到磁盘文件名为”fsimage”
• Block的位置信息不会保存到fsimage,存在内存中，位置信息是不会持久化的
• edits记录对metadata的操作日志
文件包括：
①fsimage:元数据镜像文件。存储某一时段NameNode内存元数据信息。
②edits:操作日志文件。
③fstime:保存最近一次checkpoint的时间
以上这些文件是保存在linux的文件系统中。通过hdfs-site.xml的dfs.namenode.name.dir属性进行设置。
查看NameNode的fsimage与edits内容
这个两个文件中的内容使用普通文本编辑器是无法直接查看的，幸运的是hadoop为此准备了专门的工具用于查看文件的内容，这些工具分别为oev和oiv，可以使用hdfs调用执行。
启动服务器：bin/hdfs oiv -i 某个fsimage文件
bash$ bin/hdfs oiv -i fsimage
14/04/07 13:25:14 INFO offlineImageViewer.WebImageViewer: WebImageViewer started.
Listening on /127.0.0.1:5978. Press Ctrl+C to stop the viewer.
查看内容：bin/hdfs dfs -ls -R webhdfs://127.0.0.1:5978/
bash$ bin/hdfs dfs -ls webhdfs://127.0.0.1:5978/
Found 2 items
drwxrwx–* - root supergroup 0 2014-03-26 20:16 webhdfs://127.0.0.1:5978/tmp
drwxr-xr-x - root supergroup 0 2014-03-31 14:08 webhdfs://127.0.0.1:5978/user
导出fsimage的内容：bin/hdfs oiv -p XML -i
tmp/dfs/name/current/fsimage_0000000000000000055 -o fsimage.xml
bash$ bin/hdfs oiv -p XML -i fsimage -o fsimage.xml
0000055 -o fsimage.xml
查看edtis的内容：bin/hdfs oev -i
tmp/dfs/name/current/edits_0000000000000000057-0000000000000000186 -o edits.xml
bash$ bin/hdfs oev -i
tmp/dfs/name/current/edits_0000000000000000057-0000000000000000186 -o edits.xml
2、Datanode
提供真实文件数据的存储服务。
文件块（ block）： 最基本的存储单位。
启动DN线程的时候会向NN汇报block信息
通过向NN发送心跳保持与其联系（3秒一次），如果NN 10分钟没有收 到DN的心跳，则认为其已经lost，并copy其上的block到其它DN
对于文件内容而言，一个文件的长度大小是size，那么从文件的０偏移开始，按照固定的大小，顺序对文件进行划分并编号，划分好的每一个块称一个Block。
HDFS默认Block大小是128MB， 因此，一个256MB文件，共有256/128=2个Block.
与普通文件系统不同的是，在 HDFS中，如果一个文件小于一个数据块的大小，并不占用整个数据块存储空间。
Replication：多复本。默认是三个。通过hdfs-site.xml的dfs.replication属性进行设置。
3、SecondaryNameNode
它不是NN的备份（但可以做备份），它的主要工作是帮助NN合并edits
log，减少NN启动时间
SNN执行合并时机
• 根据配置文件设置的时间间隔fs.checkpoint.period 默认3600秒
• 根据配置文件设置edits log大小 fs.checkpoint.size 规定edits文件的最大值默
认是64MB 
SNN如何合并
Secondary NameNode主要是做Namespace image和Edit log合并的。
那么这两种文件是做什么的？当客户端执行写操作，则NameNode会在edit log记录下来，并在内存中保存一份文件系统的元数据。
Namespace image（fsimage）文件是文件系统元数据的持久化检查点，不会在写操作后马上更新，因为fsimage写非常慢
由于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重启时造成长时间不可访问的情况。
6、数据存储，读、写文件
读文件
1.首先调用FileSystem对象的open方法，其实是一个DistributedFileSystem的实例。
2.DistributedFileSystem通过rpc获得文件的第一批block的locations，同一个block按照重复数会返回多个locations，这些locations按照hadoop拓扑结构排序，距离客户端近的排在前面。
3.前两步会返回一个FSDataInputStream对象，该对象会被封装DFSInputStream对象，DFSInputStream可以方便的管理datanode和namenode数据流。客户端调用read方法，DFSInputStream最会找出离客户端最近的datanode并连接。
4.数据从datanode源源不断的流向客户端。
5.如果第一块的数据读完了，就会关闭指向第一块的datanode连接，接着读取下一块。这些操作对客户端来说是透明的，客户端的角度看来只是读一个持续不断的流。
6.如果第一批block都读完了， DFSInputStream就会去namenode拿下一批block的locations，然后继续读，如果所有的块都读完，这时就会关闭掉所有的流。
如果在读数据的时候， DFSInputStream和datanode的通讯发生异常，就会尝试正在读的block的排序第二近的datanode,并且会记录哪个datanode发生错误，剩余的blocks读的时候就会直接跳过该datanode。 DFSInputStream也会检查block数据校验和，如果发现一个坏的block,就会先报告到namenode节点，然后DFSInputStream在其他的datanode上读该block的镜像。
该设计就是客户端直接连接datanode来检索数据并且namenode来负责为每一个block提供最优的datanode， namenode仅仅处理block location的请求，这些信息都加载在namenode的内存中，hdfs通过datanode集群可以承受大量客户端的并发访问。
写文件
1.客户端通过调用DistributedFileSystem的create方法创建新文件。
2.DistributedFileSystem通过RPC调用namenode去创建一个没有blocks关联的新文件，创建前， namenode会做各种校验，比如文件是否存在，客户端有无权限去创建等。如果校验通过， namenode就会记录下新文件，否则就会抛出IO异常。
3.前两步结束后，会返回FSDataOutputStream的对象，与读文件的时候相似， FSDataOutputStream被封装成DFSOutputStream。DFSOutputStream可以协调namenode和datanode。客户端开始写数据到DFSOutputStream，DFSOutputStream会把数据切成一个个小的packet，然后排成队列data quene。
4.DataStreamer会去处理接受data quene，它先询问namenode这个新的block最适合存储的在哪几个datanode里（比如重复数是3，那么就找到3个最适合的datanode），把他们排成一个pipeline。DataStreamer把packet按队列输出到管道的第一个datanode中，第一个datanode又把packet输出到第二个datanode中，以此类推。
5.DFSOutputStream还有一个对列叫ack quene，也是由packet组成，等待datanode的收到响应，当pipeline中的所有datanode都表示已经收到的时候，这时akc quene才会把对应的packet包移除掉。
如果在写的过程中某个datanode发生错误，会采取以下几步：
1) pipeline被关闭掉；
2)为了防止防止丢包ack quene里的packet会同步到data quene里；
3)把产生错误的datanode上当前在写但未完成的block删掉；
4)block剩下的部分被写到剩下的两个正常的datanode中；
5)namenode找到另外的datanode去创建这个块的复制。当然，这些操作对客户端来说是无感知的。
6.客户端完成写数据后调用close方法关闭写入流。
7.DataStreamer把剩余得包都刷到pipeline里，然后等待ack信息，收到最后一个ack后，通知datanode把文件标视为已完成。
注意：客户端执行write操作后，写完的block才是可见的，正在写的block对客户端是不可见的，只有调用sync方法，客户端才确保该文件的写操作已经全部完成，当客户端调用close方法时，会默认调用sync方法。是否需要手动调用取决你根据程序需要在数据健壮性和吞吐率之间的权衡
HDFS文件权限
– 与Linux文件权限类似
r: read; w:write; x:execute，权限x对于文件忽略，对于文件夹表示是否允许访问其内容
– 如果Linux系统用户zhangsan使用hadoop命令创建一个文件，那么这个文件在HDFS中owner就是zhangsan。
安全模式
– namenode启动的时候，首先将映像文件(fsimage)载入内存，并执行编辑日志(edits)中的各
项操作。
– 一旦在内存中成功建立文件系统元数据的映射，则创建一个新的fsimage文件(这个操作不
需要SecondaryNameNode)和一个空的编辑日志。
– 此刻namenode运行在安全模式。 即namenode的文件系统对于客服端来说是只读的。 (显示
目录，显示文件内容等。 写、删除、重命名都会失败)。
– 在此阶段Namenode收集各个datanode的报告，当数据块达到最小副本数以上时，会被认
为是“安全”的， 在一定比例（可设置）的数据块被确定为“安全”后，再过若干时间，安
全模式结束
– 当检测到副本数不足的数据块时，该块会被复制直到达到最小副本数，系统中数据块的位
置并不是由namenode维护的，而是以块列表形式存储在datanode中。
