随着数据速度的增长，数据大小很容易超过机器的存储限制。一种解决方案是通过机器网络存储数据。这种文件系统称为分布式文件系统。由于数据存储在网络中，因此网络的所有复杂性都会出现。
这就是 Hadoop 的用武之地。它提供了最可靠的文件系统之一。 HDFS（Hadoop分布式文件系统）是一种独特的设计，它为具有流数据访问模式的超大文件提供存储，并在商品硬件上运行。让我们详细说明这些条款：
- 超大文件：这里我们讨论的是 PB（1000 TB）范围内的数据。
- 流式数据访问模式：HDFS 是根据一次写入和多次读取的原则设计的。写入数据后，可以处理大部分数据集。
- 商品硬件：价格低廉且易于在市场上买到的硬件。这是将 HDFS 与其他文件系统区分开来的特性之一。
节点：主从节点通常构成 HDFS 集群。
- 主节点：
- 管理所有从节点并为其分配工作。
- 它执行文件系统命名空间操作，如打开、关闭、重命名文件和目录。
- 它应该部署在具有高配置的可靠硬件上。不是在商品硬件上。
- 名称节点：
- 实际工作节点，他们执行实际工作，如读取、写入、处理等。
- 它们还根据 master 的指令执行创建、删除和复制。
- 它们可以部署在商品硬件上。
HDFS 守护进程：守护进程是在后台运行的进程。
- 名称节点：
- 在主节点上运行。
- 存储元数据（有关数据的数据），如文件路径、块数、块 ID。等等。
- 需要大量内存。
- 将元数据存储在 RAM 中以便快速检索，即减少查找时间。尽管它的永久副本保存在磁盘上。
- 数据节点：
- 在从节点上运行。
- 需要高内存，因为数据实际上存储在这里。
HDFS中的数据存储：现在让我们看看数据是如何以分布式方式存储的。
_0.jpg)
假设插入了 100TB 的文件，然后 masternode(namenode) 将首先将文件分成 10TB 的块（Hadoop 2.x 及更高版本中的默认大小为 128 MB）。然后这些块存储在不同的数据节点（从节点）上。数据节点（从节点）在它们之间复制块，并将它们包含的块的信息发送给主节点。默认复制因子为3意味着为每个块创建 3 个副本（包括它自己）。在 hdfs.site.xml 中，我们可以增加或减少复制因子，即我们可以在此处编辑其配置。
注意： MasterNode 拥有一切的记录，它知道每个数据节点的位置和信息以及它们包含的块，即没有 masternode 的许可，什么都做不了。
为什么将文件分成块？
答：假设我们不划分，现在在一台机器上存储100 TB的文件是非常困难的。即使我们存储，对整个文件的每次读写操作也将花费非常长的寻道时间。但是，如果我们有多个大小为 128MB 的块，那么与一次对整个文件执行不同的读写操作相比，它就变得容易了。因此，我们将文件划分为更快的数据访问，即减少查找时间。
为什么在存储时复制数据节点中的块？
答：假设我们不进行复制，并且数据节点 D1 上只有一个黄色块。现在，如果数据节点 D1 崩溃，我们将丢失该块，这将导致整体数据不一致和错误。所以我们复制块来实现容错。
与 HDFS 相关的术语：
- HeartBeat ：是datanode持续发送给namenode的信号。如果 namenode 没有从 datanode 接收到心跳，那么它会认为它已经死了。
- 平衡：如果数据节点崩溃，则其上的块也将消失，并且与其余块相比，这些块的复制不足。在这里，主节点（namenode）将向包含要复制的丢失块的副本的数据节点发出信号，以便平衡块的整体分布。
- 复制： ：由datanode完成。
注意：同一数据节点上不存在同一块的两个副本。
特征：
- 分布式数据存储。
- 块减少了寻道时间。
- 由于同一块存在于多个数据节点上，因此数据是高度可用的。
- 即使多个数据节点宕机，我们仍然可以完成我们的工作，从而使其高度可靠。
- 高容错性。
限制：尽管 HDFS 提供了许多功能，但在某些方面它不能很好地工作。
- 低延迟数据访问：需要对数据进行低延迟访问（即在毫秒范围内）的应用程序不适用于 HDFS，因为 HDFS 的设计牢记我们需要高吞吐量的数据，即使以延迟为代价。
- 小文件问题：有很多小文件会导致大量的查找和从一个数据节点到另一个数据节点的大量移动以检索每个小文件，整个过程是一种非常低效的数据访问模式。