什么是HDFS硬盘分布式存储？

1. 什么是HDFS硬盘分布式存储？

Namenode 是一个中心服务器，单一节点（简化系统的设计和实现），负责管理文件系统的名字空间(namespace)以及客户端对文件的访问。
文件操作，NameNode 负责文件元数据的操作，DataNode负责处理文件内容的读写请求，跟文件内容相关的数据流不经过NameNode，只会询问它跟哪个DataNode联系，否则NameNode会成为系统的瓶颈。
副本存放在哪些DataNode上由 NameNode来控制，根据全局情况做出块放置决定，读取文件时NameNode尽量让用户先读取最近的副本，降低带块消耗和读取时延
Namenode 全权管理数据块的复制，它周期性地从集群中的每个Datanode接收心跳信号和块状态报告(Blockreport)。接收到心跳信号意味着该Datanode节点工作正常。块状态报告包含了一个该Datanode上所有数据块的列表。 

NameNode支持对HDFS中的目录、文件和块做类似文件系统的创建、修改、删除、列表文件和目录等基本操作。 块存储管理，在整个HDFS集群中有且只有唯一一个处于active状态NameNode节点，该节点负责对这个命名空间（HDFS）进行管理。


1、Name启动的时候首先将fsimage（镜像）载入内存，并执行（replay）编辑日志editlog的的各项操作；
2、一旦在内存中建立文件系统元数据映射，则创建一个新的fsimage文件（这个过程不需SecondaryNameNode） 和一个空的editlog；
3、在安全模式下，各个datanode会向namenode发送块列表的最新情况；
4、此刻namenode运行在安全模式。即NameNode的文件系统对于客服端来说是只读的。(显示目录，显示文件内容等。写、删除、重命名都会失败)；
5、NameNode开始监听RPC和HTTP请求
解释RPC:RPC（Remote Procedure Call Protocol）——远程过程通过协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议；
6、系统中数据块的位置并不是由namenode维护的，而是以块列表形式存储在datanode中；
7、在系统的正常操作期间，namenode会在内存中保留所有块信息的映射信息。
存储文件，文件被分成block存储在磁盘上，为保证数据安全，文件会有多个副本 namenode和client的指令进行存储或者检索block，并且周期性的向namenode节点报告它存了哪些文件的blo
文件切分成块（默认大小128M），以块为单位，每个块有多个副本存储在不同的机器上，副本数可在文件生成时指定（默认3）
NameNode 是主节点，存储文件的元数据如文件名，文件目录结构，文件属性（生成时间,副本数,文件权限），以及每个文件的块列表以及块所在的DataNode等等
DataNode 在本地文件系统存储文件块数据，以及块数据的校验和。
可以创建、删除、移动或重命名文件，当文件创建、写入和关闭之后不能修改文件内容。


NameNode启动流程
1、Name启动的时候首先将fsimage（镜像）载入内存，并执行（replay）编辑日志editlog的的各项操作；
2、一旦在内存中建立文件系统元数据映射，则创建一个新的fsimage文件（这个过程不需SecondaryNameNode） 和一个空的editlog；
3、在安全模式下，各个datanode会向namenode发送块列表的最新情况；
4、此刻namenode运行在安全模式。即NameNode的文件系统对于客服端来说是只读的。(显示目录，显示文件内容等。写、删除、重命名都会失败)；
5、NameNode开始监听RPC和HTTP请求
解释RPC:RPC（Remote Procedure Call Protocol）——远程过程通过协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议；
6、系统中数据块的位置并不是由namenode维护的，而是以块列表形式存储在datanode中；
7、在系统的正常操作期间，namenode会在内存中保留所有块信息的映射信息。
HDFS的特点

优点：
1）处理超大文件
　　这里的超大文件通常是指百MB、数百TB大小的文件。目前在实际应用中，HDFS已经能用来存储管理PB级的数据了。

2）流式的访问数据
HDFS的设计建立在更多地响应"一次写入、多次读取"任务的基础上。这意味着一个数据集一旦由数据源生成，就会被复制分发到不同的存储节点中，然后响应各种各样的数据分析任务请求。在多数情况下，分析任务都会涉及数据集中的大部分数据，也就是说，对HDFS来说，请求读取整个数据集要比读取一条记录更加高效。

3）运行于廉价的商用机器集群上
Hadoop设计对硬件需求比较低，只须运行在低廉的商用硬件集群上，而无需昂贵的高可用性机器上。廉价的商用机也就意味着大型集群中出现节点故障情况的概率非常高。这就要求设计HDFS时要充分考虑数据的可靠性，安全性及高可用性。
 
缺点：
1）不适合低延迟数据访问
如果要处理一些用户要求时间比较短的低延迟应用请求，则HDFS不适合。HDFS是为了处理大型数据集分析任务的，主要是为达到高的数据吞吐量而设计的，这就可能要求以高延迟作为代价。
 
2）无法高效存储大量小文件
　　因为Namenode把文件系统的元数据放置在内存中，所以文件系统所能容纳的文件数目是由Namenode的内存大小来决定。一般来说，每一个文件、文件夹和Block需要占据150字节左右的空间，所以，如果你有100万个文件，每一个占据一个Block，你就至少需要300MB内存。当前来说，数百万的文件还是可行的，当扩展到数十亿时，对于当前的硬件水平来说就没法实现了。还有一个问题就是，因为Map task的数量是由splits来决定的，所以用MR处理大量的小文件时，就会产生过多的Maptask，线程管理开销将会增加作业时间。举个例子，处理10000M的文件，若每个split为1M，那就会有10000个Maptasks，会有很大的线程开销；若每个split为100M，则只有100个Maptasks，每个Maptask将会有更多的事情做，而线程的管理开销也将减小很多。
 
1280M 1个文件  10block*150字节 = 1500 字节 =1.5KB
1280M 12.8M 100个 100个block*150字节 = 15000字节 = 15KB
 
3）不支持多用户写入及任意修改文件
　　在HDFS的一个文件中只有一个写入者，而且写操作只能在文件末尾完成，即只能执行追加操作。目前HDFS还不支持多个用户对同一文件的写操作，以及在文件任意位置进行修改。

四、HDFS文件 读写流程
4.1 读文件流程

（1） 打开分布式文件
调用 分布式文件 DistributedFileSystem.open()方法。
（2） 从 NameNode 获得 DataNode 地址
DistributedFileSystem 使用 RPC 调用 NameNode， NameNode返回存有该副本的 DataNode 地址， DistributedFileSystem 返回一个输入流 FSDataInputStream对象， 该对象封存了输入流DFSInputStream。
（3） 连接到DataNode
调用 输入流 FSDataInputStream 的 read() 方法， 从而输入流DFSInputStream 连接 DataNodes。
（4） 读取DataNode
反复调用 read()方法， 从而将数据从 DataNode 传输到客户端。
（5） 读取另外的DataNode直到完成
到达块的末端时候， 输入流 DFSInputStream 关闭与DataNode 连接，寻找下一个 DataNode。
（6） 完成读取， 关闭连接
即调用输入流 FSDataInputStream.close() 。

4.2 写文件流程

（1） 发送创建文件请求： 调用分布式文件系统DistributedFileSystem.create()方法；
（2） NameNode中创建文件记录： 分布式文件系统DistributedFileSystem 发送 RPC 请求给namenode， namenode 检查权限后创建一条记录， 返回输出流 FSDataOutputStream， 封装了输出流 DFSOutputDtream；
（3） 客户端写入数据： 输出流 DFSOutputDtream 将数据分成一个个的数据包， 并写入内部队列。 DataStreamer 根据 DataNode 列表来要求 namenode 分配适合的新块来存储数据备份。一组DataNode 构成管线(管线的 DataNode 之间使用 Socket 流式通信)
（4） 使用管线传输数据： DataStreamer 将数据包流式传输到管线第一个DataNode， 第一个DataNode 再传到第二个DataNode ,直到完成。
（5） 确认队列： DataNode 收到数据后发送确认， 管线的DataNode所有的确认组成一个确认队列。 所有DataNode 都确认， 管线数据包删除。
（6） 关闭： 客户端对数据量调用close（） 方法。 将剩余所有数据写入DataNode管线， 并联系NameNode且发送文件写入完成信息之前等待确认。
（7） NameNode确认
（8） 故障处理： 若过程中发生故障， 则先关闭管线， 把队列中所有数据包添加回去队列， 确保数据包不漏。 为另一个正常DataNode的当前数据块指定一个新的标识， 并将该标识传送给NameNode, 一遍故障DataNode在恢复后删除上面的不完整数据块. 从管线中删除故障DataNode 并把余下的数据块写入余下正常的DataNode。 NameNode发现复本两不足时， 会在另一个节点创建一个新的复本

2. HDFS分布式文件系统具有哪些优点

HDFS分布式文件系统具有以下优点：
支持超大文件
支持超大文件。超大文件在这里指的是几百M，几百GB，甚至几TB大小的文件。一般来说hadoop的文件系统会存储TB级别或者PB级别的数据。所以在企业的应用中，数据节点有可能有上千个。
检测和快速应对硬件故障
在集群的环境中，硬件故障是常见的问题。因为有上千台服务器连接在一起，这样会导致高故障率。因此故障检测和自动恢复是hdfs文件系统的一个设计目标。
流式数据访问
Hdfs的数据处理规模比较大，应用一次需要访问大量的数据，同时这些应用一般都是批量处理，而不是用户交互式处理。应用程序能以流的形式访问数据集。主要的是数据的吞吐量，而不是访问速度。
简化的一致性模型
大部分hdfs操作文件时，需要一次写入，多次读取。在hdfs中，一个文件一旦经过创建、写入、关闭后，一般就不需要修改了。这样简单的一致性模型，有利于提高吞吐量。
缺点
低延迟数据访问
低延迟数据。如和用户进行交互的应用，需要数据在毫秒或秒的范围内得到响应。由于hadoop针对高数据吞吐量做了优化，牺牲了获取数据的延迟，所以对于低延迟来说，不适合用hadoop来做。
大量的小文件
Hdfs支持超大的文件，是通过数据分布在数据节点，数据的元数据保存在名字节点上。名字节点的内存大小，决定了hdfs文件系统可保存的文件数量。虽然现在的系统内存都比较大，但大量的小文件还是会影响名字节点的性能。
多用户写入文件、修改文件
Hdfs的文件只能有一次写入，不支持写入，也不支持修改。只有这样数据的吞吐量才能大。
不支持超强的事务
没有像关系型数据库那样，对事务有强有力的支持。

3. HDFS分布式文件系统具有哪些优点

　　目前几个主流的分布式文件系统除GPFS外，还有PVFS、Lustre、PanFS、GoogleFS等。
　　1.PVFS(Parallel Virtual File System)项目是Clemson大学为了运行Linux集群而创建的一个开源项目,目前PVFS还存在以下不足：
　　1）单一管理节点:只有一个管理节点来管理元数据，当集群系统达到一定的规模之后，管理节点将可能出现过度繁忙的情况，这时管理节点将成为系统瓶颈;
　　2）对数据的存储缺乏容错机制:当某一I/O节点无法工作时，数据将出现不可用的情况;
　　3）静态配置:对PVFS的配置只能在启动前进行，一旦系统运行则不可再更改原先的配置。
　　2.Lustre文件系统是一个基于对象存储的分布式文件系统，此项目于1999年在Carnegie Mellon University启动，Lustre也是一个开源项目。它只有两个元数据管理节点,同PVFS类似,当系统达到一定的规模之后，管理节点会成为Lustre系统中的瓶颈。
　　3.PanFS(Panasas File System)是Panasas公司用于管理自己的集群存储系统的分布式文件系统。
　　4.GoogleFS(Google File System)是Google公司为了满足公司内部的数据处理需要而设计的一套分布式文件系统。

4. Hadoop分布式文件系统（HDFS）会不会被淘汰？

首先我们应该更具体的理解这样一个现象，为什么流行的技术框架会被淘汰。谈到淘汰，常见两种情况：
  
 第一：应用模式被淘汰了，例如：BB机，功能机，最终被智能机淘汰，胶卷被数码相机淘汰，即便诺基亚的功能机做得再完美，也会被淘汰。软件方面例如：终端的字处理，邮件收发等应用软件被视窗应用软件淘汰。
  
 第二：技术升级，新技术弥补了老技术的缺陷，并且引入了更多有优势的功能。例如：Springframework的横空出世，配合Hibernate，在具有同样功效的情况下，解决了EJB的部署复杂，体态臃肿，计算效率低，用灵活性，面向程序员的友好性，淘汰了曾经企业级经典的EJB。
  
 那么对于Hadoop分布式文件系统（HDFS），我们要讨论它的淘汰可能性，淘汰时间，首先我们就要看它为什么要被淘汰的因素。从模式上，分布式文件系统是大数据存储技术极为重要的一个领域，我们还看不到分布式文件系统有被淘汰的任何理由，那么我就再看技术升级是否有淘汰它的可能性。
  
 谈技术升级，首先要看HDFS的缺点，然后再看这种缺点的解决办法，是否会带来新的技术框架，然后让HDFS埋进历史的垃圾堆。
  
 HDFS为集中式协调架构，namenode若是单节点，部署并不复杂，但是namenode作为单节点无法可靠的运行在生产环境，必须对namenode实现双机HA，那么部署复杂度就变得极高，这时候需要在namenode，datanode的基础上再引入namenode active，namenode standby的概念，需要引入QJM的元数据共享存储并基于Paxos做一致性协调，另外需要引入ZKFC和ZooKeeper，解决主备选举，健康探测，主备切换等操作。
                                          
 因此HDFS的部署复杂度完全是因为namenode HA导致的。这是集中式管理的分布式架构一个原生问题，如果在这个地方进行优化的话，那么就是简化QJM，ZKFC，ZooKeeper的多组服务，用一组服务来代替，但是namenode和datanode的分布式数据块的读写，复制，恢复机制，目前看非常成熟，高效，这是核心问题，并不是缺点，不需要更具颠覆性的优化。
  
 由于namenode在内存中记录了所有数据块（block 默认128M）的信息，索引了数据块与datanode的关系，并且构建了文件系统树，因此可想而知namenode的元数据内存区是大量占用内存，这是没有上限的。对于较大型数据存储项目，例如上百个datanode节点和上千万个数据块的容量来说，元数据在namenode的内存大概能控制在32G以内，这是还没问题的，但是对于构建海量数据中心的超大型项目，这个问题就好像达摩克斯之剑，首先堆内存超过临界范围导致的内存寻址性能问题不说，一旦namenode内存超限到单机内存可承载的物理上最大承受范围，整个hdfs数据平台将面临停止服务。
  
 这个问题的本质还是Google设计GFS时候采用粗放的实用主义，先把元数据都交给主节点在内存中节制，超大问题以后再解决。目前Google的GFS2设计上，已经将元数据在内存中迁移至了BigTable上，那么问题就来了：“BigTable基于GFS，而GFS2的元数据基于BigTable”？有点鸡生蛋还是蛋生鸡的自相矛盾。是的，看似矛盾实质上是架构的嵌套复用，可以这么去解读：GFS2是基于的下一代GFS架构。用BigTable的k-v存储模型放GFS2的元数据，虽然没有内存高效，但是够用，而且可以无限存储，用BigTable专门存储元数据形成的k-v记录最终保存成GFS数据块，因此在GFS的元数据内存中只需少量的内存占用，就能支撑天量的真正应用于数据块存储的GFS2元数据。
  
 基于GFS2的设计思想，我相信下一代HDFS应该也是这样的方案去解决元数据的内存瓶颈问题，也就是基于的下一代HDFS架构。那么HDFS的元数据瓶颈问题将被彻底解决，很难看到比这更具优势的替代性技术框架了。
  
 如下图所示：
                                          
 副本数默认为3最大的问题就是占空间，这几乎是所有传统分布式文件系统（DFS）的通病。因此HDFS集群的默认空间利用率只有33.3%，这么低的利用率显然不符合一些场景，例如长期的冷数据备份，那么有没有更好的方式呢？是有的，目前比较成熟的方案就是纠删码技术，类似raid5，raid6，HDFS 3.0版本以后支持这种模式，叫做Erasure Coding(EC)方案。
  
 HDFS是怎么通过EC方案解决磁盘利用率的问题呢？我们先聊点比较硬的原理，说说EC方案之一的条形布局：
  
 首先数据文件写的时候会向N个节点的块(Block)依次写入，N个Block会被切成多组条(stripe 1... stripe n)，如果分布式环境有五个存储节点(DataNode)，那么就把stripe切成3个单元(cell)，然后再根据这3个cell计算出2个校验cell，然后这5个cell（3个data+2个parity）分别写入5个Block中。数据条就这么依次轮巡的方式，将校验块的位置轮换存储在不同Block上，直至写满，这样校验块的分布可以更均匀。
                                          
 其次再说取数据，取数据每次只从3个DataNode中各取出1个cell，如果这3个cell都是数据cell，那么就成功拿到一组数据条stripe，如果有一个cell是校验cell，那么就能通过校验cell和另外2个数据cell计算出第3个数据cell，完成数据条stripe的组合。这种情况下，即便是5个datanode节点有2个datanode宕机了，另外3个datanode也能通过校验码计算完成剩余2个节点的数据，这就是利用纠删码技术实现数据冗余的原理。
  
 通过这种方式，我们就比传统2副本50%，3副本33.3%的多副本模式要省空间，EC中2+1可以达到66.7%的磁盘利用率，例子是3+2可以达到60%的磁盘利用率
  
 但是其问题是特别消耗CPU计算，上面那种读取情况，五分之三的读取数据条时间都要进行校验码计算。因此可以利用Intel CPU推出的ISA-L底层函数库专门用于提升校纠删码算法的编解码性能。通常情况下，纠删码用于冷数据的冗余，也就是不经常访问，但又必须联机存储以备查询的数据。除了磁盘利用率，多副本方式用空间换效率的方式肯定是最好，没什么问题。

5. hdfs和glusterFS哪个更适合做分布式存储

　　glusterfs 无元数据分布式网络存储系统， hdfs 有元数据分布式网络存储系统， 按理说这两个东西真的不应该放在一起来比较。
　　首先两者的发展思路是不同的， glusterfs支持标准的posix接口， hdfs自己私有的对外接口， 一致性hash 和 有元数据中心架构实现差距很大。
　　当然要比较必须得有一样的东西， 那就是都能做分布式网络文件存储系统。在这个大方向上一致， 那就有比较的可能啦。

6. 大数据之HDFS

 在现代的企业环境中，单机容量往往无法存储大量数据，需要跨机器存储。统一管理分布在集群上的文件系统称为 分布式文件系统 。   
                                           
    HDFS （Hadoop Distributed File System）是 Hadoop  的核心组件之一， 非常适于存储大型数据 (比如 TB 和 PB)， HDFS 使用多台计算机存储文件，并且提供统一的访问接口，像是访问一个普通文件系统一样使用分布式文件系统。
   HDFS是分布式计算中数据存储管理的基础，是基于流数据模式访问和处理超大文件的需求而开发的，可以运行于廉价的商用服务器上。它所具有的 高容错、高可靠性、高可扩展性、高获得性、高吞吐率 等特征为海量数据提供了不怕故障的存储，为超大数据集的应用处理带来了很多便利。
   HDFS 具有以下 优点 ：
   当然 HDFS 也有它的 劣势 ，并不适合以下场合：
                                           HDFS 采用Master/Slave的架构来存储数据，这种架构主要由四个部分组成，分别为HDFS Client、NameNode、DataNode和Secondary NameNode。
   Namenode是整个文件系统的管理节点，负责接收用户的操作请求。它维护着整个文件系统的目录树，文件的元数据信息以及文件到块的对应关系和块到节点的对应关系。
   Namenode保存了两个核心的数据结构：
   在NameNode启动的时候，先将fsimage中的文件系统元数据信息加载到内存，然后根据edits中的记录将内存中的元数据同步到最新状态；所以，这两个文件一旦损坏或丢失，将导致整个HDFS文件系统不可用。
   为了避免edits文件过大， SecondaryNameNode会按照时间阈值或者大小阈值，周期性的将fsimage和edits合并 ，然后将最新的fsimage推送给NameNode。
   并非 NameNode 的热备。当NameNode 挂掉的时候，它并不能马上替换 NameNode 并提供服务。其主要任务是辅助 NameNode，定期合并 fsimage和fsedits。
   Datanode是实际存储数据块的地方，负责执行数据块的读/写操作。
   一个数据块在DataNode以文件存储在磁盘上，包括两个文件，一个是数据本身，一个是元数据，包括数据块的长度，块数据的校验和，以及时间戳。
   文件划分成块，默认大小128M，以快为单位，每个块有多个副本（默认3个）存储不同的机器上。
   Hadoop2.X默认128M， 小于一个块的文件，并不会占据整个块的空间 。Block数据块大小设置较大的原因：
   文件上传 HDFS 的时候，Client 将文件切分成 一个一个的Block，然后进行存储。
   Client 还提供一些命令来管理 HDFS，比如启动或者关闭HDFS。
                                                                                   Namenode始终在内存中保存metedata，用于处理“读请求”，到有“写请求”到来时，namenode会首 先写editlog到磁盘，即向edits文件中写日志，成功返回后，才会修改内存 ，并且向客户端返回，Hadoop会维护一个fsimage文件，也就是namenode中metedata的镜像，但是fsimage不会随时与namenode内存中的metedata保持一致，而是每隔一段时间通过合并edits文件来更新内容。
                                           HDFS HA（High Availability）是为了解决单点故障问题。
   HA集群设置两个名称节点，“活跃（ Active ）”和“待命（ Standby ）”，两种名称节点的状态同步，可以借助于一个共享存储系统来实现，一旦活跃名称节点出现故障，就可以立即切换到待命名称节点。
                                           为了保证读写数据一致性，HDFS集群设计为只能有一个状态为Active的NameNode，但这种设计存在单点故障问题，官方提供了两种解决方案：
   通过增加一个Secondary NameNode节点，处于Standby的状态，与Active的NameNode同时运行。当Active的节点出现故障时，切换到Secondary节点。
   为了保证Secondary节点能够随时顶替上去，Standby节点需要定时同步Active节点的事务日志来更新本地的文件系统目录树信息，同时DataNode需要配置所有NameNode的位置，并向所有状态的NameNode发送块列表信息和心跳。
   同步事务日志来更新目录树由JournalNode的守护进程来完成，简称为QJM，一个NameNode对应一个QJM进程，当Active节点执行任何命名空间文件目录树修改时，它会将修改记录持久化到大多数QJM中，Standby节点从QJM中监听并读取编辑事务日志内容，并将编辑日志应用到自己的命名空间。发生故障转移时，Standby节点将确保在将自身提升为Active状态之前，从QJM读取所有编辑内容。
   注意，QJM只是实现了数据的备份，当Active节点发送故障时，需要手工提升Standby节点为Active节点。如果要实现NameNode故障自动转移，则需要配套ZKFC组件来实现，ZKFC也是独立运行的一个守护进程，基于zookeeper来实现选举和自动故障转移。
   虽然HDFS HA解决了“单点故障”问题，但是在系统扩展性、整体性能和隔离性方面仍然存在问题：
   HDFS HA本质上还是单名称节点。HDFS联邦可以解决以上三个方面问题。
                                           在HDFS联邦中，设计了多个相互独立的NN，使得HDFS的命名服务能够水平扩展，这些NN分别进行各自命名空间和块的管理，不需要彼此协调。每个DN要向集群中所有的NN注册，并周期性的发送心跳信息和块信息，报告自己的状态。
   HDFS联邦拥有多个独立的命名空间，其中，每一个命名空间管理属于自己的一组块，这些属于同一个命名空间的块组成一个“块池”。每个DN会为多个块池提供块的存储，块池中的各个块实际上是存储在不同DN中的。