2.HDFS
Hadoop2.0以后的版本移除了原有的JobTracker和TaskTracker，改由Yarn ResourceManager负责集群中所有资源的统一管理和分配，NodeManager管理单个计算结点
系统架构
Active NameNode（AN）
管理命名空间
管理元数据：文件的位置、所有者、权限、数据块等
管理Block副本策略：默认3个副本
处理客户端读写请求，为DataNode分配任务
Standby NameNode(SN)
Block数据块
若一个Block的大小小于设定值，不会占用整个块空间
Block和元数据分开存储：Block存储于DataNode，元数据存储于NameNode
hadoop1.x默认块大小为64M
hadoop2.x默认块大小为128M
可以在hdfs-site.xml中设置：dfs.block.size
NameNode元数据文件
edits(编辑日志文件):保存了自最新检查点(Checkpoint)之后的所有文件更新操作
fsimage(元数据检查点镜像文件):保存了文件系统中所有的目录和文件信息
Active NameNode内存中有一份最新的元数据(= fsimage + edits)
Standby NameNode在检查点定期将内存中的元数据保存到fsimage文件中
元数据的两种存储形式
? 内存元数据（NameNode）
? 文件元数据（edits + fsimage) （编辑日志文件 元数据镜像检查点文件）
非HA high available
HDFS主要由三个组件构成，分别是NameNode、SecondaryNameNode和DataNode，其中NameNode和SecondaryNameNode运行在master节点上，DataNode运行在slave节点上
SecondaryNameNode就是来帮助解决上述问题的，它的职责是合并NameNode的edit logs到fsimage文件中。
- 首先，它定时到NameNode去获取edit logs，并更新到fsimage上。[笔者注：Secondary NameNode自己的fsimage]
- 一旦它有了新的fsimage文件，它将其拷贝回NameNode中。
- NameNode在下次重启时会使用这个新的fsimage文件，从而减少重启的时间。
Secondary NameNode：它不是HA(高可用)，它只是阶段性的合并edits和fsimage，以缩短集群启动的时间。当NN失效的时候，Secondary NN并无法立刻提供服务，Secondary NN甚至无法保证数据完整性：如果NN数据丢失的话，在上一次合并后的文件系统的改动会丢失
HA方案 hadoop2.0
两个NameNode为了数据同步，会通过一组称作JournalNodes的独立进程进行相互通信。
- 当active状态的NameNode的命名空间有任何修改时，会告知大部分的JournalNodes进程。
- standby状态的NameNode定期读取JNs中的变更信息，并且一直监控edit log的变化然后把edits文件和fsimage文件合并成一个新的fsimage，合并完成之后会通知active namenode获取这个新fsimage。active namenode获得这个新的fsimage文件之后，替换原来旧的fsimage文件。
- standby可以确保在集群出错时，命名空间状态已经完全同步了。
QJM共享存储系统
DataNode
Slave工作节点(可大规模扩展)
存储Block和数据校验和
执行客户端发送的读写操作
通过心跳机制定期(默认3秒)向NameNode汇报运行状态和Block列表信息 集群启动时，DataNode向NameNode提供Block列表信息
利用QJM实现元数据高可用
主备NameNode之间通过一组JournalNode同步元数据信息，一条数据只要成功写入多数JournalNode即认为写入成功。通常配置奇数个JournalNode
active namenode和standby namenode之间是通过一组journalnode（数量是奇数，可以是3,5,7...,2n+1）来共享数据。active namenode把最近的edits文件写到2n+1个journalnode上，只要有n+1个写入成功就认为这次写入操作成功了，然后standby namenode就可以从journalnode上读取了?？梢钥吹?，QJM方式有容错的机制，可以容忍n个journalnode的失败。
QJM共享存储系统
Quorum Journal Manager
部署奇数（2N+1）个JournalNode
JournalNode负责存储edits编辑日志
写edits的时候，只要超过半数（N+1）的 JournalNode返回成功，就代表本次写入成功
最多可容忍N个JournalNode宕机
利用ZooKeeper实现Active节点选举
Decommission or Recommission（DataNode退役和服役）
删除DataNode（先退役再删除）
自动切换
优缺点
优点：
适合大文件的存储
廉价机器，容错，恢复
流式数据访问，一次写入，多次读取最高效
缺点：
不适合小文件存储
不适合并发写入
不支持文件随机修改
不支持随机读
读写操作
写操作，在client处将文件切分为块
读操作，在client处将block拼装成一个文件
HDFS读写
1.*****数据块的大小设置为多少合适为什么？*
hadoop数据块的大小一般设置为128M，如果数据块设置的太小，一般的文件也会被分割为多个数据块，在访问的时候需要查找多个数据块的地址，这样的效率很低，而且如果数据块设置太小的话，会消耗更多的NameNode的内存；而如果数据块设置过大的话，对于并行的支持不是太好，而且会涉及系统的其他问题，比如系统重启时，需要从新加载数据，数据块越大，耗费的时间越长。
数据块太小，namenode太累，块太多
太大，恢复时间，并行执行
HDFS写流程：
1.客户端向NameNode发起写数据，NameNode将信息反馈给Client
2.Client将数据分块， 分块写入DataNode节点，DataNode自动完成副本备份
3.DataNode向NameNode汇报存储完成，NameNode通知客户端
HDFS读流程：
1.客户端向NameNode发起读数据的请求
2.NameNode找出最近的DataNode节点信息返回给客户端
3.客户端从DataNode分块下载文件
hadoop常用命令
hdfs dfs -mkdir -p /user/johnson # 创建用户目录
hdfs dfs -ls / 查看目录 本地是看不见的
hdfs dfs -mkdir -p /user/johnson/input
hdfs dfs -put /usr/local/hadoop/etc/hadoop/*.xml /user/johnson/input
rm -r ./output # 先删除本地的 output 文件夹（如果存在）
hdfs dfs -get /user/johnson/output ./output # 将 HDFS 上的 output 文件夹拷贝到本机
hdfs dfs -rm -r output
copyFromLocal（从**本地系统**->**HDFS系统**）、copyToLocal（从**HDFS系统**->**本地系统**）
运行 Hadoop 程序时，为了防止覆盖结果，程序指定的输出目录（如 output）不能存在，否则会提示错误，因此运行前需要先删除输出目录。
延伸
1.如果通过hadoop存储小文件
可以采用压缩合并小文件的策略
设置文件输入类型：ComnineFileInputFormat
Hadoop分布式缓存
DistributedCache
在执行mr时，mapper之间可能会共享一些数据，如果信息量不大，可以将其从hdfs加载到缓存中
推荐算法
