初始HDFS1.0

hdfs：存储海量数据
mapreduce:针对海量数据进行处理
hdfs1.0
1、hdfs本身是一个master slave 架构
2、hdfs是一个分布式存储的系统架构，是一个集群（多个节点/服务器）
3、namenode 主 datanode 从

4、namenode是个进程，存在于某个节点上（主节点）上，本身也维护这一块内存。
内存中存储着两份重要的数据：
（1）文件名->block数据块之间的映射关系（mapping） 针对数据块简单理解为就是一个标识。
（2）block->datanode节点之间的映射关系。

HDFS系统架构：

NameNode：
1、管理者文件系统命名空间
2、存储运输局
3、保存文件，block，datanode之间的映射关系
4、元信息持久化
5、运行NameNode会占用大量内存和I/O资源
6、Hadoop更倾向存储大文件的原因

Hadoop集群不适合存储海量的小文件：
（1）针对磁盘空间产生资源浪费
（2）namenode内存资源有限，若是过多的小文件，直接导致namenode内存溢出。

hdfs1.0只有一个NameNode，当时基础设施的不完整，数据量也不是很多，zookeeperk（分布式锁服务）
NameNode - 单节点故障
hdfs1.0只有一个NameNode, 导致单节点故障
– 解决方案:

1. 将hadoop元数据写入到本地文件系统的同时再实时同
   步到一个远程挂载的网络文件系统（NFS）
   2.运行一个Secondary NameNode，它的作用是与
   NameNode进行交互定期通过编辑日志文件合并命名空间镜
   像。当NameNode发生故障时它会通过自己合并的命名空间
   镜像副本来恢复。需要注意的是Secondary NameNode
   保存的状态总是滞后于NameNode，所以这种方式难免会导
   致丢失部分数据。

DataNode作用：
（1）存储数据块，提供读写服务。
（2）心跳机制，定期报告文件块信息

Secondary NameNode（SNN）不能直接理解为NameNode的备份

即使加入SNN还会存在数据丢失情况：
editlog还没有写入SNN，SNN还没有写入新文件中。
后面hdfs2.0解决该问题。

什么时候涉及到机架感知？
hadoop集群规模很大的时候，还有为了避免跨机架，导致的带宽消耗。

副本放置规则：
第一个副本,在客户端相同的节点（如果客户端市是集群外的一台机器，就随机算节点，但是系统会避免挑选太满或者太忙的节点）。
第二个副本，放在不同机架（随机选择）的节点上。
第三个副本，放在与第二个副本同机架但是不同节点上。

数据的完整性
（1）不希望在存储和处理数据是丢失或损坏任何数据。
（2）HDFS会对写入的数据计算校验和，并在读取数据时验证校验和
（3）两种检验方法：
1)校验和：crc32(冗余校验码)，可以给每一个数据块一个唯一的id
检测损坏数据的常用方法是在第一次进行系统是计算数据的校验和，在通道传输过程中，如果新生成的校验和不完全匹配原始的校验和，那么数据就会认为被损坏的。

	2）数据块检测程序DataBlockScanner：
	在DataNode节点上开启一个后台进程，来定期验证存储在它上所有块，这个防止物理介质出现损减情况而造成的数据损坏。

可靠性保证：
（1）一个名字节点和多个数据节点
（2）数据复制（冗余机制）：
存放的位置（机架感知策略）
（3）故障检测：
数据节点
心跳包（检测是否宕机）
快报告（安全模式下检测）
数据完整性检测（校验和比较）
名字节点（日志文件，镜像文件）
（5） 空间回收机制：Trash目录

（1）副本
（2）NameNode和DataNode之间心跳关系
（3）数据完整性
（4）空间回收机制

HDFS 特点
优点

• 存储并管理PB级数据
• 处理非结构化数据
• 注重数据处理的吞吐量（延迟不敏感）
• 应用模式：write-once-read-many存取模式（无数据一致性
  问题）
  缺点
• 存储小文件（不建议）
• 大量随机读（不建议）
• 需要对文件修改（不支持）
• 多用户写入（不支持）

大量随机读解释图

13、mapreduce在1.0中主（jobtracker）, 从（tasktracker）就近原则：本地化，数据不移动，代码（任务）移动