Hadoop学习-分布式文件系统HDFS的一些概念

当数据集的大小超过一台独立的物理计算机的存储能力是，就有必要对它进行分区(partition)并存储到若干台单独的计算机上。管理网络中跨多台计算机存储的文件系统称为分布式文件系统(distributed filesystem)。Hadoop 自带一个HDFS 的分布式文件系统，即 Hadoop Distributed Filesystem。

HDFS 的设计

• 超大文件 指的是具有几百MB、几百GB、几百TB及PB级大小的文件
• 流式数据访问 HDFS 构建思路：一次写入，多次读取是最高效的访问模式。数据集通常由数据源生成或从数据源复而来，接着长时间再此数据集上进行各种分析。每次分析都将涉及该数据集的大部分数据甚至全部，因此读取整个数据集的时间延迟比读取第一条记录的时间延迟更重要
• 商用硬件Hadoop 并不需要运行在昂贵且高可靠的硬件上。它是设计运行在商用硬件上（在各种零售店都能买到的普通硬件）的集群上，因此至少对于庞大的集权来说，节点故障的机率还是非常高的。HDSF遇到这些故障时，被设计成能够继续运行且不让用户察觉到明显的中断。
• 低时间延迟的数据访问要求低时间延迟数据访问的应用，例如几十毫秒范围，不适合在HDFS上运行。HDFS是为高数据吞吐量应用优化的，这可能会以提高时间延迟为代价。
• 大量的小文件 由于namenode 将文件系统的元数据存储在内存中，因此该文件系统所能存储的文件总数受限于namenode的内存容量。根据经验，每个文件、目录和数据块的存储信息大约占150字节。因此。如果有一百万个文件，且每个文件占一个数据块，那至少需要300MB的内存。尽管存储上百万个文件是可行的，但是存储数十亿个文件就超出了当前硬件的能力。
• 多用户写入,任意修改文件 HDFS中的文件写入只支持单个写入者，而且写操作总是以“只添加”方式在文件末尾写数据。它不支持多个写入者的操作，也不支持在文件的任意位置进行修改。

HDFS Architecture

HDFS Block

HDFS 同样也有块(block)的概念，但是大的多，默认为128M（1.0 版本为64M)。与单一磁盘上的文件系统相似，HDFS上的文件也被划分为块大小的多个分块（chunk)，作为独立的存储单元。与面向单一磁盘的文件系统不同的是，HDFS中小于要给块大小的文件不会占据整个块的空间，当一个1MB的文件存储在一个128MB的块中时，文件只使用1MB的磁盘空间，而不是128MB

• HDFS中的块为什么这么大？
  • 为了最小化寻址开销，HDFS的块要比磁盘的大很多，查找时间在10ms左右，数据传输几率在100MB/s,为了使查找时间是传输时间的1%，块的大小必须在100MB左右。因而，传输一个由多个块组成的大文件的时间取决于磁盘传输速率。但是这个参数也不能设置过大。MapReduce 中的map任务通常一个次只处理一个块中的数据，因此如果任务数太少（少于集群中的节点数量)，作业的运行速度就会比较慢。
• 块抽象的优点:
  • 1.一个文件的大小可以大于网络中任意一个磁盘的容量
  • 2.使用抽象块而非整个文件作为存储单元，大大简化了存储子系统的设计。由于块的大小是固定的，因此计算单个磁盘存储多个块就相对容易，
  • 3.使用块比文件更适合用于数据备份进而提供数据容错能力和提高可用性。将每个块复制到少数几个物理上相互独立的机器（默认为3个），可以确保在块、磁盘或机器发生故障后数据不丢失。

NameNode

• 管理着文件系统命名空间
  • 维护着文件系统树及树中的所有文件和目录。这些信息以两个文件形式永久保存在本地磁盘上：命名空间镜像文件和编辑日志文件。
• 存储元数据
  • NameNode保存元信息的种类：
    • 文件名目录名及它们之间的层级关系
    • 文件目录的所有者及其权限
    • 每个文件块的名及文件有哪些块组成
• 元数据保存在内存中
  • NameNode并不永久保存块的位置信息，因为这些信息会在系统启动时根据数据节点信息重建
• 保存文件，block，datanode之间的映射关系
• Hadoop 更倾向存储大文件原因：
  • 一般来说，一条元信息记录会占用150byte内存空间。文件越小，存储同等大小文件所需要的元信息就越多，所以Hadoop更喜欢大文件
• 运行NameNode 会占用大量内存和I/O资源，一般NameNode不会存储用户数据或执行MapReduce任务
• 1.x 版本中只有NameNode，导致单点问题。两种解决方案：将hadoop元数据写入到本地文件系统的同时再实时同步到一个远程挂载的网络文件系统（NFS）；运行一个secondary NameNode，它的作用是与NameNode进行交互，定期通过编辑日志文件合并命名空间镜像，以防止编辑日志太大，当NameNode发生故障时它会通过自己合并的命名空间镜像副本来恢复。需要注意的是secondaryNameNode保存的状态总是滞后于NameNode，所以这种方式难免会导致丢失部分数据；2.x 后实现NameNode的高可用

DataNode

• 负责存储数据块，负责为系统客户端提供数据块的读写服务
• 根据NameNode的指示进行创建、删除和复制等操作
• 心跳机制，定期报告文件块列表信息
• DataNode之间进行通信，块的副本处理

块缓存

通常DataNode从磁盘中读取块，但对于访问频繁的文件，其对应的块可能被显式地缓存在datanode内存中，以堆外块缓存地形式存在，提高读操作地性能。

机架感知策略–Block副本放置策略

• 第一个副本，在客户端相同的节点（如果客户端时集群外的一台机器，就随机算节点，，但是系统会避免挑选太满或者太忙的节点）
• 第二个副本，放在不同机架（随机选择）的节点
• 第三个副本，放在与第二个副本同机架但是不同节点上

HDFS HA

Hadoop 1.x中的NameNode在整个HDFS中只有一个，存在单点故障风险，一旦NameNode挂掉，整个集群无法使用
HDFS的高可用性通过在同一个集群中运行两个NameNode（active NameNode & standby NameNode）来解决

• 在任何时间，只有一台机器处于Active状态；另一太机器是处于Standby状态
• Active NameNode负责集群中所有客户端的操作；
• Standby NameNode主要用于备用，它主要维持足够的状态，如果必要，可以提供快速的故障恢复。
• 同步问题：需要依赖Journal Nodes守护进程，完成元数据的一致性
• DataNode 需要同时向两个NameNode 发送数据块处理报告，因为数据块的映射信息存储在NameNode 的内存中，而非磁盘
• 快速的故障恢复：心跳保证，Standby NN 也需要保存集群中各个文件块的存储位置
• 避免分歧：任何情况下，NameNode只有一个Active状态，否则导致数据的丢失及其其他不正确的结果
  • 在任何时间，JNs只允许一个NN充当writer。在故障恢复期间，将要变成Active状态的NN将取得writer的角色，并阻止另外一个NN继续处于Active状态（failover controller 故障转移控制器）
• 故障切换：系统中有一个称为故障转移控制器（failover controller）的新实体，管理着将活动NameNode转移为备用NameNode的转化过程。

• 节点分配：
  • NameNode machines：运行Active NN 和Standby NN的机器需要相同的硬件配置
  • JournalNode machines：也就是运行JN的机器。JN守护进程相对来说比较轻量，所以这些守护进程可以和其他守护进程（NN,Yarn ResourceManager)运行在同一台机器上
    • 在一个集群中，最少要运行3（奇数）个JN守护进程，这将使得系统有一定的容错能力
• 在HA集群中，Standby NN也执行namespace状态的checkpoints，所以不必要运行Secondary NN、CheckpointNode;

NameNode Federation

NameNode 在内存中保存文件系统中每个文件和每个数据块的引用关系，这意味着对于一个拥有大量文件的超大集群来说，内存将成为限制系统横向扩展的瓶颈。在2.x版本系列中引入联盟，HDFS允许系统通过添加NameNode实现扩展，每个NameNode管理文件系统命名空间中的一部分 。

HDFS 的高可用和联盟框架