HDFS：存储模型

写的不到位的地方，欢迎评论指出不足之处

1、文件线性按字节切割成块（block），具有 offset、id

• 理解
  • 文件按每100字节，切割成一块，同时可拼成原样，每个块的第一个字节，块对应文件时（单一块对应所有块时），块的下标/偏移
• 如
  • 每5个字节，切割成一块
• 注
  • 如图只表明文件内是数字，若是其它会将内容切割坏，之后通过计算还原

一个文件
0.1.2.3.4	5.6.7.8.9	10.11.12.13.14	15.16.17.18.19	20.21.22.23.24

2、文件与文件的 block 大小可以不一样

• 如
  • 第一个文件按每5字节切割，第二个文件按每3字节切割
  • 可配置

3、一个文件除最后一个 block，其他 block大小一致（默认情况下）

• 如
  • 一个文件切割若干份，每一份的 block 大小都是一样的，最后一个由于是文件结尾部分，因此可于之前 block 大小不同

4、block 的大小依据硬件的 I/O 特性调整

• 理解
  • 每个版本对支持 I/O 都有提升或是调整，但最终还是要根据计算机实际硬件的 I/O 进行调整

5、block 被分散存放在集群的节点中，具有 location

• 如
  • 一个文件被切割 50 块，分散存放 10 个集群节点中，并具有 location（位置/地址），否则数据无法还原

6、block 具有副本( replication )，没有主从概念，副本不能出现在同一个节点

• 理解
  • 副本数可指定数量，并没有主块和备份块的概念，多个副本是同级，操作哪一个都可以，需要放在不同节点上。
• 如
  • 当一个副本所在的节点发生异常情况时，其它节点的副本仍可以正常使用

7、副本是满足可靠性和性能的关键

• 理解
  • 可靠性：当一个副本所在的节点发生异常情况时，其它节点的副本仍可以正常使用
• 性能
  • 如
    • 10个程序，有3个程序正在处理3个节点上的副本（副本正在使用中）
    • 由于没有多余或空闲副本，剩余7个程序等待，但有空闲副本时，剩有程序再拉取节点。
    • 若增加副本，10个程序同时处理10个节点上的副本，将不需要再等待拉取，从而提高性能

8、文件上传可以指定 block 大小和副本数，上传后只能修改副本数

9、一次写入多次读取，不支持修改

• 如
  • 假设修改了某一个 block 中的数据，该 block 就会变大，从而造成之后的 block 偏移情况不准。
  • 为了解决只能将该 block 为起始，对每一个 block 都进行调整，从而修整了偏移情况。
  • 但所有的 I/O、CPU 都将进行疯狂的计算，导致设备资源用在了不该用的地方，致使其它程序运行性能的降低或崩溃
  • 当大面积出现这种情况时，称为“泛洪”
  • 所以当需要修改时，需要对整个文件进行删除/上传操作

10、支持追加数据

• 理解
  • 一个文件切割若干 block ，可在最后一个 block 追加数据，因为只操作这一个 block 而不会影响其它的 block