HDFS Architecture 翻译和理解

HDFS官方文档链接

1. 硬件故障的容错，在软件层面cover硬件故障。
2. 流式数据读取，数据的访问是顺序的，对数据跳转访问支持不友好。
3. 数据集巨大，以TB为单位。
4. 数据一致性模型：写仅支持append和truncate，不支持update。
5. hdfs使用时，倾向于在靠近hdfs的集群创建application，原因是hdfs数据量巨大，数据的传输成本高。
6. NameNode采用master/slave机制，避免数据丢失。
7. DataNode中，同一个文件会有多个副本（可配置）。面临的问题是：副本在同机房时如果机房发生意外，数据会丢失。副本不在同一机房时，写数据会高度依赖机房间的带宽。针对3个副本的优化是，2个副本在同一个机房的不同DataNode上，1个副本在不同机房的DataNode上。
8. 数据读取优化，选择离application最近的机房读取副本数据。
9. NameNode的safemode：Namenode启动时进入safemode，对每个DataNode通过BlockReport获取其存储的数据块的信息，对所有数据块的副本数进行比较，如果副本数小于指定的百分比，那么先进行数据库的复制，直到所有数据块的副本数都满足配置的百分比，退出safemode，开始提供服务。
10. NameNode中MetaData的持久化。EditLog存储每一个客户端发送的修改，FsImage存储NameNode内存中的全量数据。重启或者达到触发条件时，NameNode会从磁盘中加载FsImage和EditLog，更新内存中的数据并生成新的FsImage和清空旧的EditLog。触发条件通常是时间间隔或累计修改记录数量。PS：对应redis的RDB+AOF。Q：触发数据合并时，如何处理新的写入请求？保留旧的FsImage和EditeLog，fork新进程来创建FsImage，对于新的写入请求，写入旧的EditLog的同时也写入新创建的EditLog，如果新的FsImage未创建完成就宕机，那么从旧的FsImage和EditLog中恢复数据。如果FsImage创建成功，删除旧的FsImage和EditLog。
11. NameNode只接受客户端和DataNode的RPC请求，不主动推送任何请求。
12. NameNode通过HeartBeat来确定DataNode是否有效，通常间隔是10min，当DataNode被判定无效时，DataNode将不会被分配读写并会、触发其上面DataBlock的复制，确保每个DataBlock的副本数达到最低限度。这也是为什么心跳间隔时间不能太短，太短容易触发大规模的副本复制。
13. 集群的负载均衡？集群中的DataNode检测到磁盘容量低于阈值时，将其上面的DataBlock拷贝到别的DataNode中。
14. DataBlock的数据一致性，client写数据同时会针对每个DataBlock计算checksum并存储到NameNode中，读数据时校验checksum，如果不同则说明数据异常。
15. MetaData数据的一致性，同时写多个FsImage和EditLog？有用吗？
16. DataBlock数据的写？一、client向NameNode发送写请求，NameNode回复可写的DataNodeList。二、client向第一个DataNode写数据并告知DataNodeList信息。三、第一个DataNode写数据并且告知下一个DataNode写数据和DataNodeList。