【HDFS】启蒙：世界上已有的分布式文件系统那么多了，为什么Hadoop项目中还要开发一个分布式文件系统？

HDFS的启蒙

HDFS的核心问题：世界上已有的分布式文件系统那么多了，为什么Hadoop项目中还要开发一个HDFS文件系统？

答案肯定就是：他们都无法满足分布式计算的要求，就自己设计一个更符合的。

那么就要着重关注：Hadoop项目的HDFS具备了那些特性，以更好地支持分布式计算。

从生活案例到分布式文件系统

文件系统，在生活中的案例：银行的人工存款
想想这个场景应该要有什么？
有前台的记账工作人员和她的账本，你要去存款，以及钱放的地方
过程：有很多人要存款，要在我这里排队，我要知道他要存款的各种信息，并记录到账本上，然后为他指路：告诉他要去哪里找工人帮他把钱放在格子里存好；取款呢，也是到我这里说要取款了，我仍然是告诉他去哪里找工人人员取款，……
在我这记账保证你的钱知道在哪里，工人按照我给的路径帮你存好，保证这些不丢，双方都不会发生财产的损失。

再想想会不会有这么一种情况：要存款的人会不会在中途，突然反悔了，拿走了一点，或没有放到格子里，那么我账本上的信息就不对了。
所以，就能马上把账本写好，先写到一个草稿本上，等我的工人真的存好了后，我再把账本写好，工人非常忠诚，我非常信任他，反馈给我的都是真的。

这映射分布式文件系统

我对应的是NameNode，工人对应DataNode，工人要反馈给我信息，我才会写账本
你要存文件，首先到NN哪里说“”要存文件了”，NN会告诉告诉应该去哪里找对应的工人DN帮你存，DN存好后反馈给NN说ok，那么NN就把这个信息写好

启蒙：分布式文件系统的角色及其职责

名称中的 Node - 节点，一个节点就是一台主机/服务器

• NN - NameNode ：理解为一个“大管家”，只需要干一件事，告诉你去哪里，并记录元数据

  • 元数据：类似于Windows的文件属性（包括：文件名、大小、路径、时间、所有者等信息），但不要说文件属性，专业一点。

• DN - DataNode ：理解为是：帮你存放数据文件的工人，它也是个节点/主机，那么数据就可以存在该节点上，这个位置是由NN决定的

  • DN存好后，要告诉NN，所以NN要与DN建立==“心跳”==，保证数据的一致性，集群分布式尤其要注意这点、尤为小心

• DataNode 有多台，工人越多，能干得活就越多，也干得越快

• NameNode只有一台，所有文件的元数据都在一台机上，使得管理就变得很简单了

  • 只有一台，所以对读写性能的要求就很高，那么这些“元数据”是保存在内存上的；而且NN的这台机上一般只有这一个角色，独享这台机子的所有性能

HDFS分布式文件系统的存储模型和特性

HDFS - Hadoop Distributed File System - Hadoop 分布式文件系统

牢记以下这些内容：

• 文件 线性（顺序）按字节 切割成 block块，具有 offset ，id
  • 数据都是以二进制位/字节存储表示，所有文件实际上都是一个字节数组
  • offset - 偏移量（0，blockset++，……）
  • id 不是很重要，因为是自动映射的
  • 切割：无论按什么切，一定会将完整的数据切坏，计算就会不正确；但Hadoop在计算是还能将它算对返回正确的结果，存储层先不考虑计算层的算法，先有个基本的认识
• 文件与文件 的block 大小可以不同
  • 自定义一个文件切割成块的大小
• 同一个文件 除了最后一个block，其他 block大小一致
  • 最后那个块的数据不够块的大小，仍占用完整的空间，还是显示真实块的大小
• block的大小 要依据 硬件的IO特性 调整
  • 机械硬盘 百兆/s ，所以设置块大小为 64MB，1s完全可读完一个块
• block被 分散 存放在集群的节点中，具有 location
  • location - 块地址，知道存在哪，不能丢
• Block具有 副本 replication 的概念，没有主从概念，副本不能出现在同一个节点
  • 同等地位，所以是说副本：丢到里面存，说有3个副本，那就只能看到3个（而不是4个）
• 副本是满足 可靠性和性能 的关键
  • 可靠性：不能存在同一节点是防止一挂就都没了，挂了一个还可以取其他的副本
  • 性能：数据块/副本分开在不同的节点， 可以启动不同节点的多个程序并行计算；一个文件有多少个数据块，就可以起多少个程序计算
  • 副本数调高一点，让计算向数据移动的可能性更高一些，因为不需要从别的节点去拉取副本
• 文件上传可以指定block大小和副本数，上传后只能修改副本数，而不能调整块的大小
• 一次写入可 多次读取，不支持修改，只支持追加数据

如果支持修改
场景：客户端往下滑，就读一个块，展示在屏幕上
如果你在中间改了一下，此处后面块的数据都会往下滑，导致后面的偏移量不正确了，后面的块就得调整，出现 泛洪/泛滥 操作现象（CPU/网卡/硬盘的高度使用，竟然是因为一个小小的修改；网络疯狂的传输数据，CPU各种算：数据从哪里来的，要到哪里去），一个集群花了那么多钱，难道就想实现一个可读可写的系统吗，肯定不是吧

肯定是想：在上面跑更多的程序做计算、挖掘出数据的价值啊

如果支持修改操作，就必然影响你的终结目标，就取折中的方式：可存可读可删（文件），可批计算，可跑很多程序，可让他跑得很快，但就是不能支持修改（所以虽然有那么多分布式文件系统了，但Hadoop就必须要重新设计一个新的）

追加就不是泛滥操作，只要改最后一个块的数据，把他搬到一个空闲的空间，代价是非常非常低的