HDFS设计（Architecture）
1. 简介
- HDFS具有高容错性，设计用于低成本的硬件设备
- 迅速发现错误，自动恢复是hdfs的核心设计目标
- 擅长批处理数据而不是数据的低延时获取
- 一次写入，多次读取；一个文件在创建后只能进行追加和截断操作而不能被更改；这一理念非常适用于MapReduce程序和网络爬虫
2.NameNode and DataNodes
2.1 NameNode
- 一个集群仅有一个，管理文件系统名称空间以及用户对文件的权限
- 决定了块与datanode的映射关系
- 通常情况下，一个集群中专门有一个节点来运行NameNode，而不再运行其他服务
- 储存所有hdfs的元数据（数据的相关信息）
2.2 DataNode：
- 通常集群中的每个节点（服务器）拥有一个，管理本节点上的数据
- 一个文件通常被切成多个块（block），存储在一系列DataNode中
- 负责响应用户对文件的读写请求
- 根据NameNode指示，完成块的创建、删除和备份
- 不储存任何HDFS文件的信息，只在本地存储数据真实信息
3. Data Replication
- 每个文件单独配置块大小和备份数量
- 一个文件的所有块（除去最后一个块）是相同大小
- NameNode周期性的接受来自集群中所有DataNodes的心跳（HeartBeat）和一个块报告（Blockreport）；心跳表示DataNode正在正常工作，而块报告包含一个DataNode中的所有块
4. Replica Placement（副本放置）
- 大型HDFS实例运行在一个集群中的多个机架上，而在不同机架的两个节点沟通需要通过交换机（not good)
- 采用心跳感知机制
4.1 机架感知机制
原因：为了平衡数据的可靠性和写操作的花费
方法：默认副本数为3；
- 第一个副本在Client所处的节点上，若客户端在集群外，随机选一个；
- 第二个副本在另一个机架的随机一个节点
- 第三个副本在第二个副本所在机架的随机节点
注：NameNode不允许DataNode有两个相同的块，所以最大副本数量可根据DataNode数量决定。
5. 文件系统元数据的持久性
5.1 EditLog
存储对一每一个文件系统元数据做出的改变
5.2 FsImage
整个文件系统名称空间，包括块与文件的映射，文件系统属性
5.3 Checkpoint
背景：若每对文件做一次更改就写入到磁盘的FsImage中，会占用大量资源
解决方法：
启动时，从EditLog和FsImage中将名称空间与块映射读取到内存，将来自EditLog的所有事务写入到FsImage在内存中的代表，然后一起写入到磁盘上新的FsImage中，然后就可以截断老的EditLog。这个过程就称为检查点。
检查点在指定时间间隔或指定数量事务后触发。
6. 网络协议
- 所有HDFS协议建立在TCP/IP协议之上
- 客户通过配置好的tcp端口同NameNode通信
- Client通过ClientProtocol协议与NameNode通信，DataNode通过DataNode协议与NameNode通信
- RPC抽象包装了Client协议和DataNode协议
- NameNode从不初始化RPC，只接受来自DataNode和client的RPC请求
7. 健壮性
7.1 DataNode挂了
心跳机制告诉了namenode，namenode跟踪哪些块需要被再拷贝然后开始行动。
7.2 硬件挂了（来自DataNode的数据不完整）
客户端程序实现了checksum机制，当创建Hdfs文件时，会计算checksum，并存储在相同的Hdfs名称空间（就是Hdfs的同一个文件夹下），据此获得完整数据
7.3 硬件挂了（元数据没了）
高可用性（HA) ，启用多个NameNode
面试重点，我还没学到