1. 简述什么是HDFS，以及HDFS作用 ？

HDFS在Hadoop中的作用是为海量的数据提供了存储，能提供高吞吐量的数据访问，HDFS有高容错性的 特点，并且设计用来部署在低廉的硬件上；而且它提供高吞吐量来访问应用程序的数据，适合那些有着 超大数据集的应用程序。
对外部客户机而言，HDFS就像一个传统的分级文件系统。可以创建、删除、移动或重命名文件，等等。 但是HDFS的架构是基于一组特定的节点构建的，这是由它自身的特点决定的。这些节点包括
NameNode（仅一个，HA两个），它在HDFS内部提供元数据服务；DataNode，它为HDFS提供存储块

2. 简述HDFS文件写入和读取流程 ？

HDFS存储机制，包括HDFS的写入数据过程和读取数据过程两部分

1）客户端通过Distributed FileSystem模块向NameNode请求上传文件，NameNode检查目标文件是否已存在，父目录是否存在。
2）NameNode返回是否可以上传。
3）客户端请求第一个 block上传到哪几个datanode服务器上。
4）NameNode返回3个datanode节点，分别为dn1、dn2、dn3。
5）客户端通过FSDataOutputStream模块请求dn1上传数据，dn1收到请求会继续调用dn2，然后dn2调用dn3，将这个通信管道建立完成。
6）dn1、dn2、dn3逐级应答客户端。
7）客户端开始往dn1上传第一个block（先从磁盘读取数据放到一个本地内存缓存），以packet为单位，
dn1收到一个packet就会传给dn2，dn2传给dn3；dn1每传一个packet会放入一个应答队列等待应答。
8）当一个block传输完成之后，客户端再次请求NameNode上传第二个block的服务器。（重复执行3-7
步）

3. 简述HDFS的存储机制 ？

HDFS（Hadoop Distributed File System）是Hadoop分布式计算中的数据存储系统，是基于流数据模式访问和处理超大文件的需求而开发的。
HDFS的基础概念

Block ：HDFS中的存储单元是每个数据块block，HDFS默认的最基本的存储单位是64M的数据块。和普通的文件 系统相同的是，HDFS中的文件也是被分成64M一块的数据块存储的。不同的是，在HDFS中，如果一个文 件大小小于一个数据块的大小，它是不需要占用整个数据块的存储空间的。

NameNode：元数据节点。该节点用来管理文件系统中的命名空间，是master。其将所有的为了见和文件夹的元数据 保存在一个文件系统树中，这些信息在硬盘上保存为了：命名空间镜像（namespace image）以及修改日志（edit log），后面还会讲到。此外，NameNode还保存了一个文件包括哪些数据块，分布在哪些数据节点上。然而，这些信息不存放在硬盘上，而是在系统启动的时候从数据节点收集而成的。

DataNode：数据节点。是HDFS真正存储数据的地方。客户端（client）和元数据节点（NameNode）可以向数据节 点请求写入或者读出数据块。此外，DataNode需要周期性的向元数据节点回报其存储的数据块信息。

Secondary NameNode ：从元数据节点。从元数据节点并不是NameNode出现问题时候的备用节点，它的主要功能是周期性的将
NameNode中的namespace image和edit log合并，以防log文件过大。此外，合并过后的namespace
image文件也会在Secondary NameNode上保存一份，以防NameNode失败的时候，可以恢复。

Edit Log：修改日志。当文件系统客户端client进行------写------操作的时候，我们就要把这条记录放在修改日志中。 在记录了修改日志后，NameNode则修改内存中的数据结构。每次写操作成功之前，edit log都会同步到文件系统中。

Fsimage：命名空间镜像。它是内存中的元数据在硬盘上的checkpoint。当NameNode失败的时候，最新的
checkpoint的元数据信息就会从fsimage加载到内存中，然后注意重新执行修改日志中的操作。而Secondary NameNode就是用来帮助元数据节点将内存中的元数据信息checkpoint到硬盘上的。

Checkpoint的过程如下
1）Secondary NameNode通知NameNode生成新的日志文件，以后的日志都写到新的日志文件中。2）Secondary NameNode用http get从NameNode获得fsimage文件及旧的日志文件。
3） Secondary NameNode将fsimage文件加载到内存中，并执行日志文件中的操作，然后生成新的
fsimage文件。
4） Secondary NameNode将新的fsimage文件用http post传回NameNode。
5） NameNode可以将旧的fsimage文件及旧的日志文件，换为新的fsimage文件和新的日志文件(第一步生 成的)，然后更新fstime文件，写入此次checkpoint的时间。
这样NameNode中的fsimage文件保存了最新的checkpoint的元数据信息，日志文件也重新开始，不会变 的很大了。

4. 简述HDFS优缺点，以及使用场景 ？

优点

1）高容错性
数据自动保存多个副本。它通过增加副本的形式，提高容错性
某一个副本丢失以后，它可以自动恢复。

2）适合处理大数据
数据规模：能够处理数据规模达到GB、TB、甚至PB级别的数据；
文件规模：能够处理百万规模以上的文件数量，数量相当之大。
3）可构建在廉价机器上，通过多副本机制，提高可靠性

缺点

1）不适合低延时数据访问，比如毫秒级的存储数据，是做不到的
2）无法高效的对大量小文件进行存储
存储大量小文件的话，它会占用NameNode大量的内存来存储文件目录和块信息。这样是不可取的，因为NameNode的内存总是有限的；小文件存储的寻址时间会超过读取时间，它违反了HDFS的设计目标。

3）不支持并发写入、文件随机修改
一个文件只能有一个写，不允许多个线程同时写； 仅支持数据append（追加），不支持文件的随机修改

5. 简述HDFS的容错机制 ？

HDFS可以通过廉价机器搭建大规模集群，获得海量数据的分布式存储能力。对于廉价机器而言，出现网 络故障、节点失效、数据损坏现象的频率并不低，所以在故障之后如何进行数据恢复和容错处理是至关重要的，HDFS提供了完善的容错机制，使得它成为一个高度容错性和高吞吐量的海量数据存储解决方案。

【故障检测机制】
故障的类型主要有以下三种，针对这三种故障类型，HDFS提供了不同的故障检测机制：

针对 DataNode失 问题：
每个DataNode以固定的周期向NameNode 发送心跳信号，通过这种方法告诉 NameNode 它们在正常工作。如果在一定的时间内 NameNode 没有收到 DataNode 心跳，就认为该 DataNode 宕机了。

针对网络故障 而导致无法收发数据的问题：
HDFS提供了ACK的机制，在发送端发送数据后，如果没有收到ACK并且经过多次重试后仍然如此，则认为网络故障；

针对 数据损坏(脏数据) 问题：
在传输数据的时候，同时会发送总和检验码，当数据存储到硬盘时，总和检验码也会被存储。 所有的 DataNode 都会定期向 NameNode 发送数据块的存储状况。 在发送数据块报告前，会先检查总和校验码是否正确，如果数据存在错误就不发送该数据块的信息

6. HDFS的常见数据格式，列式存储格式和行存储格式异同点，列式存储优点有哪些 ？

1、Hadoop中的文件格式大致上分为面向行和面向列两类行式存储
一条数据保存为一行，读取一行中的任何值都需要把整行数据都读取出来（如：Sequence Files，Map File，Avro Data Files），这种方式在磁盘读取的开销比较大，这无法避免。
列式存储
整个文件被切割为若干列数据，每一列中数据保存在一起（如：Parquet，RC Files，ORC Files，Carbon
Data，IndexR）。这种方式会占用更多的内存空间，需要将行数据缓存起来。
2、列存储和行存储异同点从以下几个方面说明
写入：
行存储的写入是一次完成，数据的完整性因此可以确定；
列存储需要把一行记录拆分成单列保存，写入次数明显比行存储多； 行存储在写入上占有很大的优势。
数据修改：
行存储是在指定位置写入一次，列存储是将磁盘定位到多个列上分别写入； 行存储在数据修改也是占优的。
数据读取：
行存储通常将一行数据完全读出，如果只需要其中几列数据，就会存在冗余列； 列存储每次读取的数据是集合中的一段或者全部；
由于列储存的数据是同质的，这种情况使数据解析变得容易。行存储则复杂的多，因为在一行记录 中保存了多种类型的数据，数据解析需要在多种数据类型之间频繁转换，这个操作很消耗cpu；
所以列存储的解析过程中更有利于分析大数据。
3、列存储和行存储优缺点行存储
优点：行存储的写入是一次性完成的，写入效率高，消耗的时间比列存储少，并且能够保证数据的完整 性
缺点：数据读取过程中会产生冗余数据，如果只看少量数据，此影响可以忽略；数量大可能会影响数据 的处理效率
列存储
优点：在读取过程中，不会产生冗余数据，这对数据完整性要求不高的大数据处理领域尤为重要
缺点：写入效率，保证数据完整性上都不如行存储

7. HDFS如何保证数据不丢失 ？

1）数据在写入之后进行校验和的计算，DataNode周期性的进行校验和计算，将计算结果与第一次进行 对比，若相同表示无数据丢失，若不相同表示有数据丢失，丢失后将进行数据修复；
2）数据读取之前对数据进行校验，与第一次的结果进行对比，若相同表示数据没有丢失，可以读取， 若不相同表示数据有所丢失，到其他副本读取数据。

保证DataNode节点保证数据完整性的方法
1）当 DataNode 读取 Block 的时候，它会计算CheckSum；
2）如果计算后的 CheckSum，与Block 创建时值不一样，说明 Block 已经损坏；
3）Client读 取 其 他 DataNode 上 的Block；
4）常见的校验算法 crc（32），md5（128），sha1（160）；
5）DataNode 在其文件创建后周期验证CheckSum

8. 简述HDFS的默认副本数？为什么是这个数量？如果想修改副本数怎么修改 ？

hdfs的默认副本数量是3个，配置在/etc/hadoop/conf/hdfs-site.xml中（修改也是在这）

dfs.replication
3

关于HDFS的副本数为什么选择3，可看以下内容：
HDFS采用一种称为机架感知的策略来改进数据的可靠性、可用性和网络带宽的利用率。
在大多数情况下，HDFS的副本系数是3，HDFS的存放策略是一个副本存放在本地机架节点上，另一个副 本存放在不同一机架的节点上，第三个副本存放在在与第二个节点同一机架的不同节点上。这种策略减 少了机架间的数据传输，提高了写操作的效率。机架错误的概率远比节点错误的概率小，所以这种策略 不会对数据的可靠性和可用性造成影响。与此同时，因为数据只存在两个机架上，这种策略减少了读数 据时需要的网络传输带宽。
在这种策略下，副本并不是均匀地分布在机架上。这种策略在不损坏可靠性和读取性能的情况下，改善 了写的性能。

9. 简述HDFS的Block ？

Block概念

磁盘有一个Block size的概念，它是磁盘读/写数据的最小单位。构建在这样的磁盘上的文件系统也是通过块来管理数据的，文件系统的块通常是磁盘块的整数倍。文件系统的块一般为几千字节(byte)，磁盘 块一般为512字节(byte)。
HDFS也有Block的概念，但它的块是一个很大的单元，默认是64MB。像硬盘中的文件系统一样，在HDFS 中的文件将会按块大小进行分解，并作为独立的单元进行存储。但和硬盘中的文件系统不一样的是，存 储在块中的硬的一个比块小的文件并不会占据一个块大小盘物理空间（HDFS中一个块只存储一个文件的 内容）。
对HDFS进行块抽象有哪些好处呢？
1、一个显而易见的好处是：一个文件的大小，可以大于网络中任意一个硬盘的大小。
文件的块并不需要存储在同一个硬盘上，一个文件的快可以分布在集群中任意一个硬盘上。事实上，虽 然实际中并没有，整个集群可以只存储一个文件，该文件的块占满整个集群的硬盘空间。
2、使用抽象块而非整个文件作为存储单元，大大简化了系统的设计。
简化设计，对于故障种类繁多的分布式系统来说尤为重要。以块为单位，一方面简化存储管理，因为块 大小是固定的，所以一个硬盘放多少个块是非常容易计算的；另一方面，也消除了元数据的顾虑，因为Block仅仅是存储的一块数据，其文件的元数据，例如权限等就不需要跟数据块一起存储，可以交由另 外的其他系统来处理。
3、块更适合于数据备份，进而提供数据容错能力和系统可用性。
为了防止数据块损坏或者磁盘或者机器故障，每一个block都可以被分到少数几天独立的机器上(默认3 台)。这样，如果一个block不能用了，就从其他的一处地方，复制过来一份

10. HDFS的块默认大小，64M和128M是在哪个版本更换的？怎么修改默认块大小？

Hadoop 2.7.2版本及之前默认64MB，Hadoop 2.7.3版本及之后默认128M
通过修改hdfs-site.xml文件中的dfs.blocksize对应的值修改block大小

dfs.blocksize
134217728

11. 简述HDFS的block为什么是128M？增大或减小有什么影响 ？

1、首先先来了解几个概念
寻址时间：HDFS中找到目标文件block块所花费的时间。

原理：文件块越大，寻址时间越短，但磁盘传输时间越长；文件块越小，寻址时间越长，但磁盘传输时 间越短。
2、为什么block不能设置过大，也不能设置过小
如果块设置过大，一方面从磁盘传输数据的时间会明显大于寻址时间，导致程序在处理这块数据时，变 得非常慢；另一方面，MapReduce中的map任务通常一次只处理一个块中的数据，如果块过大运行速度 也会很慢。
如果设置过小，一方面存放大量小文件会占用NameNode中大量内存来存储元数据，而NameNode的内 存是有限的，不可取；另一方面块过小，寻址时间增长，导致程序一直在找block的开始位置。因此，块 适当设置大一些，减少寻址时间，传输一个有多个块组成的文件的时间主要取决于磁盘的传输速度。
3、块大小多少合适
如果寻址时间约为10ms，而传输速率为100MB/s，为了使寻址时间仅占传输时间的1%，我们要将块大小 设置约为100MB。默认的块大小128MB。
块的大小：10ms x 100 x 100M/s = 100M，
如果增加文件块大小，那就需要增加磁盘的传输速率。
比如，磁盘传输速率为200MB/s时，一般设定block大小为256MB；磁盘传输速率为400MB/s时，一般设定
block大小为512MB。

12. 简述HDFS HA怎么实现？什么架构 ？

在Hadoop2.X之前，NameNode是集群中可能发生单点故障的节点，每个HDFS集群只有一个
NameNode，一旦这个节点不可用，则整个HDFS集群将处于不可用状态。
HDFS高可用（HA）方案就是为了解决上述问题而产生的，在HA HDFS集群中会同时运行两个NameNode，一个作为活动的NameNode（Active），一个作为备份的NameNode（Standby）。备份的
NameNode的命名空间与活动的NameNode是实时同步的，所以当活动的NameNode发生故障而停止服务 时，备份NameNode可以立即切换为活动状态，而不影响HDFS集群服务
在一个HA集群中，会配置两个独立的Namenode。在任意时刻，只有一个节点作为活动的节点，另一个 节点则处于备份状态。活动的Namenode负责执行所有修改命名空间以及删除备份数据块的操作，而备 份的Namenode则执行同步操作，以保持与活动节点命名空间的一致性。
为了使备份节点与活动节点的状态能够同步一致，两个节点都需要同一组独立运行的节点
（JournalNodes，JNS）通信。当Active Namenode执行了修改命名空间的操作时，它会定期将执行的操作记录在editlog中，并写入JNS的多数节点中。而Standby Namenode会一直监听JNS上editlog的变化， 如果发现editlog有改动，Standby Namenode就会读取editlog并与当前的命名空间合并。当发生了错误切换时，Standby节点会保证已经从JNS上读取了所有editlog并与命名空间合并，然后才会从Standby状态切换为Active状态。通过这种机制，保证了Active Namenode与Standby Namenode之间命名空间状态的一致性，也就是第一关系链的一致性。
为了使错误切换能够很快的执行完毕，就要保证Standby节点也保存了实时的数据快的存储信息，也就 是第二关系链。这样发生错误切换时，Standby节点就不需要等待所有的数据节点进行全量数据块汇
报，而直接可以切换到Active状态。为了实现这个机制，Datanode会同时向这两个Namenode发送心跳以 及块汇报信息。这样就实现了Active Namenode 和standby Namenode 的元数据就完全一致，一旦发生故障，就可以马上切换，也就是热备。
这里需要注意的是 Standby Namenode只会更新数据块的存储信息，并不会向namenode 发送复制或者删除数据块的指令，这些指令只能由Active namenode发送。
在HA架构中有一个非常重非要的问题，就是需要保证同一时刻只有一个处于Active状态的Namenode， 否则机会出现两个Namenode同时修改命名空间的问，也就是脑裂（Split-brain）。脑裂的HDFS集群很可 能造成数据块的丢失，以及向Datanode下发错误的指令等异常情况。
为了预防脑裂的情况，HDFS提供了三个级别的隔离机制（fencing）:
共享存储隔离：同一时间只允许一个Namenode向JournalNodes写入editlog数据。 客户端隔离：同一时间只允许一个Namenode响应客户端的请求。
Datanode隔离：同一时间只允许一个Namenode向Datanode下发名字节点指令，李如删除、复制数 据块指令等等。
在HA实现中还有一个非常重要的部分就是Active Namenode和Standby Namenode之间如何共享editlog日志文件。Active Namenode会将日志文件写到共享存储上。Standby Namenode会实时的从共享存储读取
edetlog文件，然后合并到Standby Namenode的命名空间中。这样一旦Active Namenode发生错误， Standby Namenode可以立即切换到Active状态。在Hadoop2.6中，提供了QJM（Quorum Journal
Manager）方案来解决HA共享存储问题。

所有的HA实现方案都依赖于一个保存editlog的共享存储，这个存储必须是高可用的，并且能够被集群中 所有的Namenode同时访问。Quorum Journa是一个基于paxos算法的HA设计方案

Quorum Journal方案中有两个重要的组件。
JournalNoe（JN） ：运行在N台独立的物理机器上，它将editlog文件保存在JournalNode的本地磁盘上，同时JournalNode还对外提供RPC接口QJournalProtocol以执行远程读写editlog文件的功能。
QuorumJournalManager(QJM) ：运行在NmaeNode上，（目前HA集群只有两个Namenode），通过调用RPC接口QJournalProtocol中的方法向JournalNode发送写入、排斥、同步editlog。
Quorum Journal方案依赖于这样一个概念：HDFS集群中有2N+1个JN存储editlog文件，这些editlog 文件是保存在JN的本地磁盘上的。每个JN对QJM暴露QJM接口QJournalProtocol，允许Namenode读写editlog 文件。当Namenode向共享存储写入editlog文件时，它会通过ＱＪＭ向集群中所有的ＪＮ发送写editlog 文件请求，当有一半以上的ＪＮ返回写操作成功时，即认为写成功。这个原理是基于Paxos算法的。
使用Quorum Journal实现的HA方案有一下优点：
JN进程可以运行在普通的PC上，而无需配置专业的共享存储硬件。
不需要单独实现fencing机制，Quorum Journal模式中内置了fencing功能。
Quorum Journa不存在单点故障，集群中有2N+1个Journal，可以允许有Ｎ个Journal Node死亡。
JN不会因为其中一个机器的延迟而影响整体的延迟，而且也不会因为JN数量的增多而影响性能
（因为Namenode向JournalNode发送日志是并行的）

13. 简述HDFS的数据一致性靠什么保证？ ？

1、hdfs的namenode机制
hdfs只有一个namenode,一旦namenode出现问题，数据块信息无法寻找。namenode中的元数据信息在工作时，会将元数据信息缓存在内存中。namenode将这些内存中的数据备份到磁盘中fsimage，每当有数据进行存入时，元数据信息会被追加到editLog文件中，内存中实际是这两部分的集合。那么什么时候将editlog与fsimage进行合并呢？

HDFS引入了seconderynamenode这个节点，该节点主要功能就是定期或者等到editlog达到一定数量（可在hdfs_site.xml设置）之后，就会copy namenode中的editlog和fsimage文件到seconderynamenode中，在seconderynamenode合并之后再更新namenode上的fsimage文件。如果一旦namenode中的数据丢失，seconderynamenode中的数据将作为备份，确保元数据信息不会丢失。

2、心跳机制
namenode与datanode之间通过心跳（每3秒一次可以在配置文件中设置）信息来确认并更新datanode的元数据信息。若datanode发生故障，namenode就会将取消对该datanode节点的信任（之后的读写都不会在该datanode节点上），同时，namenode将该节点上的数据进行备份处理。namenode的备份节点的选择主要依据的是拓扑距离和具体node负载情况。

3、安全模式
HDFS在初始化阶段会进入安全模式，在安全模式下namenode不允许操作。namenode会与连接的datanode进行安全检查，只有当安全的数据块比值达到设定的阈值才会退出安全模式，

4、回滚机制
在hdfs升级或者执行数据写入时，相关的数据将会被保留备份，如果成功，则更新备份，失败，则使用备份信息。

5、安全校验
为了避免网络传输造成的数据错误问题，HDFS采用了校验和机制。各个node之间数据备份和数据读取，校验通过数据备份成功，否则备份失败，重新备份

6、回收站
当数据文件从hdfs中删除时，文件并没有消失，而是转存/trash目录下。如果误删除的话，可以在该目录下找回文件，文件的存储时间可以配置fs.trash.interval。超过该时间namenode将该文件的元数据删除， 同时datanode上的文件将会被删除。

14. 简述HDFS 使用NameNode的好处 ？

1、维护目录树，维护命名空间。
2、负责确定指定的文件块到具体的Datanode结点的映射关系。（在客户端与Datanode之间共享数据）
3、管理Datanode结点的状态报告

15. HDFS为什么文件要分块进行存储管理？

HDFS中文件都是以 block 块的方式存放在 HDFS 文件系统当中。好处有很多，引用Hadoop权威指南中的概述：

1. 一个文件有可能大于集群中任意一个磁盘，引入块机制,可以很好的解决这个问题

2. 使用块作为文件存储的逻辑单位可以简化存储子系统

3. 块非常适合用于数据备份进而提供数据容错能力和数据的可用性。

4. 简述HDFS的mapper和reducer的个数如何确定？reducer的个数依据是什么 ？

map数量
影响map个数（split个数）的主要因素有：
文件的大小。当块（dfs.block.size）为128m时，如果输入文件为128m，会被划分为1个split；当块为
256m，会被划分为2个split。
文件的个数。FileInputFormat按照文件分割split，并且只会分割大文件，即那些大小超过HDFS块的大小 的文件。如果HDFS中dfs.block.size设置为128m，而输入的目录中文件有100个，则划分后的split个数至 少为100个。
splitSize的大小。分片是按照splitszie的大小进行分割的，一个split的大小在没有设置的情况下，默认等 于hdfs block的大小。
splitSize=max{minSize,min{maxSize,blockSize}}
map数量由处理的数据分成的block数量决定default_num = total_size / split_size
reduce数量
reduce的数量job.setNumReduceTasks(x); x为reduce的数量。不设置的话默认为1

17. 简述HDSF通过什么中间组件去存储数据 ？

DataNode

18. 简述HDFS跨节点怎么进行数据迁移 ？

通过DistCp来完成数据迁移
DistCp（分布式拷贝）是用于大规模集群内部和集群之间拷贝的工具。它使用Map/Reduce实现文件分发
（DistCp原理是在Hadoop集群中使用MapReduce分布式拷贝数据），错误处理和恢复，以及报告生成。 它把文件和目录的列表作为map任务的输入，每个任务会完成源列表中部分文件的拷贝。
迁移之前需要考虑的事情
迁移总数据量有多少？
新老集群之间的带宽有多少？能否全部用完？为了减少对线上其他业务的影响最多可使用多少带 宽？
如何限制迁移过程中使用的带宽？
迁移过程中，哪些文件可能发生删除，新增数据的情况？哪些目录可能会发生新增文件的情况？ 迁移后的数据一致性校验怎么做？

迁移后的HDFS文件权限如何跟老集群保持一致？
迁移方案
1、迁移数据量评估。
通过hdfs dfs -du -h /命令查看各目录总数据量。按业务划分，统计各业务数据总量。
2、制定迁移节奏。
由于数据量大，带宽有限，HDFS中的文件每天随业务不断变化，所以在文件变化之前全部迁移完成是不 现实的。建议按业务、分目录、分批迁移。
3、迁移工具选择。
使用Hadoop自带数据迁移工具Distcp，只需要简单的命令即可完成数据迁移。 命令示意：hadoop distcp hdfs://nn1:8020/data hdfs://nn2:8020/
4、迁移时间评估。
由于老集群每天仍然在使用，为了减小对线上业务的影响，尽量选择老集群低负载运行的时间段来进行 数据迁移。
5、对新老集群之间的网络进行硬件改造。
咨询运维同学，新老集群之间的最大传输带宽是多少，如果带宽跑满的话会不会影响线上其他业务。
能否对新老集群之间的网络进行硬件改造，例如通过新老集群之间搭网线的方式来提升网络传输的带宽 并消除对其他线上业务的影响。
6、数据迁移状况评估。
在完成上面所有准备之后，先尝试进行小数据量的迁移，可以先进行100G的数据迁移、500G的数据迁 移、1T的数据迁移，以评估数据迁移速率并收集迁移过程中遇到的问题。
迁移工具Distcp
工具使用很简单，只需要执行简单的命令即可开始数据迁移，可选参数如下：
hadoop distcp 源HDFS文件路径 目标HDFS文件路径
同版本集群拷贝（或者协议兼容版本之间的拷贝）使用HDFS协议

hadoop distcp hdfs://src-name-node:3333/user/src/dir hdfs://dst-name- node:4444/user/dst/dir

不同版本集群拷贝（比如1.x到2.x）使用hhp协议或者webhdfs协议，都是使用hdfs的HTTP端口
1 hadoop distcp hftp://src-name-node:80/user/src/dir hftp://dst-name- node:80/user/dst/dir
2 hadoop distcp webhdfs://src-name-node:80/user/src/dir webhdfs://dst-name- node:80/user/dst/dir

1、Distcp的原理
Distcp的本质是一个MapReduce任务，只有Map阶段，没有Reduce阶段，具备分布式执行的特性。在Map
任务中从老集群读取数据，然后写入新集群，以此来完成数据迁移。
2、迁移期间新老两个集群的资源消耗是怎样的？

Distcp是一个MapReduce任务，如果在新集群上执行就向新集群的Yarn申请资源，老集群只有数据读取和 网络传输的消耗。
3、如何提高数据迁移速度？
Distcp提供了 -m 参数来设置map任务的最大数量（默认20），以提高并发性。注意这里要结合最大网络传输速率来设置。
4、带宽如何限制？
Distcp提供了 -bandwidth 参数来控制单个Map任务的最大带宽，单位是MB。
5、迁移之后的数据一致性怎么校验？
Distcp负责进行CRC校验，可以通过-skipcrccheck参数来跳过校验来提供性能。
6、迁移之后的文件权限是怎样的？
Distcp提供了 -p 参数来在新集群里保留状态（rbugpcaxt）（复制，块大小，用户，组，权限， 校验和类型，ACL，XATTR，时间戳）。如果没有指定 -p 参数，权限是执行MapReduce任务的用户权限，迁移完成以后需要手动执行chown命令变更。
7、迁移的过程中老集群目录新增了文件，删除了文件怎么办？
把握好迁移节奏，尽量避免这些情况的出现。Distcp在任务启动的时候就会将需要copy的文件列表从源
HDFS读取出来。如果迁移期间新增了文件，新增的文件会被漏掉。删除文件会导致改文件copy失败，可 以通过 -i参数忽略失败。
8、迁移中遇到文件已存在的情况怎么办？
Distcp提供了-overwrite 参数来覆盖已存在的文件。
9、迁移了一半，任务失败了怎么办？
删除掉新集群中的脏数据，重新执行迁移命令。不加-overwrite参数，来跳过已存在的文件。
10、遇到需要对一个文件增量同步怎么办？
Distcp提供-append参数将源HDFS文件的数据新增进去而不是覆盖它。

19. 简述HDFS怎么保证数据安全 ？

1、存储在HDFS系统上的文件，会分割成128M大小的block存储在不同的节点上，block的副本数默认3
份，也可配置成更多份；
2、第一个副本一般放置在与client（客户端）所在的同一节点上（若客户端无datanode，则随机放）， 第二个副本放置到与第一个副本同一机架的不同节点，第三个副本放到不同机架的datanode节点，当取 用时遵循就近原则；
3、namonode会把其上面的数据备份到其他一个datanode节点上，保证数据的副本数量；
4、datanode会默认每小时把自己节点上的所有块状态信息报告给namenode； 5、采用safemode模式：datanode会周期性的报告block信息。Namenode会计算block的损坏率，当阀值
<0.999f时系统会进入安全模式，HDFS只读不写。 HDFS元数据采用secondaryname备份或者HA备份

20. 简述HDFS中向DataNode写数据失败了怎么办 ？

1、此时，Pipeline数据流管道会被关闭，ACK queue中的packets会被添加到data queue的前面以确保不会发生packets数据包的丢失；
2、在正常的DataNode节点上的以保存好的block的ID版本会升级——这样发生故障的DataNode节点上的
block数据会在节点恢复正常后被删除，失效节点也会被从Pipeline中删除；
3、剩下的数据会被写入到Pipeline数据流管道中的其他两个节点中

21. 简述什么是Hadoop2.x HDFS快照 ？

快照snapshots是HDFS文件系统的只读的基于某时间点的拷贝，可以针对某个目录，或者整个文件系统 做快照。快照比较常见的应用场景是数据备份，以防一些用户错误或灾难恢复。
快照的高效性实现：
快照可以即时创建，耗时仅为O(1)。–excluding the inode lookup time
只有当涉及到快照目录的修改被执行时，才会产生额外的内存消耗。而且内存消耗为O(M)，其中M 是被修改的文件或目录数。
创建快照时，block块并不会被拷贝。快照文件中只记录了block列表和文件大小，不会做任何数据 拷贝。
快照不会对正常的HDFS操作有任何影响：创建快照以后发生的修改操作，被按操作时间的倒序
（from newer to older）记录下来。所以当前的数据能被直接获取，而快照点的数据，则通过在当前的数据基础上减去执行过的操作来获取。
快照目录
我们可以在任何被设置为snapshottable的目录上执行快照，对一个目录最多可以创建65536个快照。管 理员可以把任何目录设置为snapshottable，没有限制。如果一个目录下已经存在快照，那么只有当先删 除所有快照后才能对这个目录进行删除和重命名等操作。
不允许嵌套的snapshottable目录。也就是说，如果一个目录被设置为snapshottable，那么它的父目录和 子目录都不允许被设置为snapshottable。
快照路径
快照被存放在一个被命名为.snapshot的目录中。比如/foo是一个snapshottable目录，/foo中有一个目录 为/foo/bar，对/foo创建一个快照s0。那么
/foo/.snapshot/s0/bar
就是/foo/bar目录对应的快照。可以通过".snapshot"路径直接访问和操作快照数据。例如： 列出一个目录的所有快照：
hdfs dfs -ls /foo/.snapshot
列出快照s0中的所有文件：
hdfs dfs -ls /foo/.snapshot/s0
从快照中复制文件：
hdfs dfs -cp /foo/.snapshot/s0/bar /tmp

2、快照操作快照管理
只有集群的管理员才有权限进行如下操作。
允许快照
把一个目录设置为snapshottable，就是设置允许对一个目录创建快照。
hdfs dfsadmin -allowSnapshot
对应的API为HdfsAdmin中的void allowSnapshot(Path path)。
禁止快照
把原本snapshottable的目录设置为禁止快照，不允许对该目录创建快照。在对一个目录设置禁止快照之 前，要先删除该目录的所有快照。
hdfs dfsadmin -disallowSnapshot
对应的API为HdfsAdmin中的void disallowSnapshot(Path path)。
用户操作
创建快照
为一个目录创建快照，只有目录的所属人权限能为这个目录创建快照。
hdfs dfs -createSnapshot []
snapshotName是要创建的快照名，如果没有定义，默认取当前时间戳作为快照名。类似”"s20130412-
151029.033“。
对应的API为FileSystem中的Path createSnapshot(Path path)和Path createSnapshot(Path path, String
snapshotName)。
删除快照
删除一个snapshottable目录的一个快照。删除操作也需要目录的所属人权限。
hdfs dfs -deleteSnapshot
对应的API为FileSystem中的void deleteSnapshot(Path path, String snapshotName)。
重命名快照
重命名一个快照。也需要该目录的所属人权限。
hdfs dfs -renameSnapshot
对应的API为FileSystem中的void renameSnapshot(Path path, String oldName, String newName)。
列出所有允许快照目录
列出所有当前用户有权限获取的，允许快照的目录。
hdfs lsSnapshottableDir

对应的API为DistributeFileSystem中的snapshottableDirectoryStatus[] getSnapshottableDirectoryListing()。
对比快照
对比两个快照。这个操作需要用户对两个快照目录同时具有读权限。
hdfs snapshotDiff
对应API为DistributeFileSystem中的SnapshotDiuReport getSnapshotDiuReport(Path path, String fromSnapshot, String toSnapshot)。

22. 简述HDFS写数据过程，写的过程中有哪些故障，分别会怎么处理 ？

写数据过程中，可能的异常模式如下所列：
Client 在写入过程中，自己挂了
Client 在写入过程中，有 DataNode 挂了
Client 在写入过程中，NameNode 挂了
对于以上所列的异常模式，都有分别对应的恢复模式。
1、Client 在写入过程中，自己挂了
当 Client 在写入过程中，自己挂了。由于 Client 在写文件之前需要向 NameNode 申请该文件的租约
（lease），只有持有租约才允许写入，而且租约需要定期续约。所以当 Client 挂了后租约会超时，
HDFS 在超时后会释放该文件的租约并关闭该文件，避免文件一直被这个挂掉的 Client 独占导致其他人不能写入。这个过程称为 lease recovery。
在发起 lease recovery 时，若多个文件 block 副本在多个 DataNodes 上处于不一致的状态，首先需要将其恢复到一致长度的状态。这个过程称为 block recovery。 这个过程只能在 lease recovery 过程中发起。
2、Client 在写入过程中，有 DataNode 挂了
当 Client 在写入过程中，有 DataNode 挂了。写入过程不会立刻终止（如果立刻终止，易用性和可用性都太不友好），取而代之 HDFS 尝试从流水线中摘除挂了的 DataNode 并恢复写入，这个过程称为pipeline recovery。
3、Client 在写入过程中，NameNode 挂了
当 Client 在写入过程中，NameNode 挂了。这里的前提是已经开始写入了，所以 NameNode 已经完成了对 DataNode 的分配，若一开始 NameNode 就挂了，整个 HDFS 是不可用的所以也无法开始写入。流水线写入过程中，当一个 block 写完后需向 NameNode 报告其状态，这时 NameNode 挂了，状态报告失败，但不影响 DataNode 的流线工作，数据先被保存下来，但最后一步 Client 写完向 NameNode 请求关闭文件时会出错，由于 NameNode 的单点特性，所以无法自动恢复，需人工介入恢复。

23. 简述NameNode存数据吗 ？

存储元数据（文件名、创建时间、大小、权限、文件与block块映射关系）

24. 简述HDFS中DataNode怎么存储数据的 ？

1、DataNode工作机制
1）一个数据块在DataNode上以文件形式存储在磁盘上，包括两个文件，一个是数据本身，一个是元数 据包括数据块的长度，块数据的校验和，以及时间戳
2） DataNode启动后向NameNode注册，通过后，周期性（6小时）的向NameNode上报所有的块信息
3）心跳是每3秒一次，心跳返回结果带有NameNode给该DataNode的命令如复制块数据到另一台机器， 或删除某个数据块。如果超过10分钟没有收到某个DataNode的心跳，则认为该节点不可用
4）集群运行中可以安全加入和退出一些机器

2、数据完整性
1）当DataNode读取block的时候，它会计算checksum
2）如果计算后的checksum，与block创建时值不一样，说明block已经损坏
3） client读取其他DataNode上的block
4） datanode在其文件创建后周期验证checksum

25. 简述HDFS写流程中如果DataNode突然宕机了怎么办 ？

客户端上传文件时与 DataNode 建立 pipeline 管道，管道正向是客户端向 DataNode 发送的数据包，管道反向是 DataNode 向客户端发送 ack 确认，也就是正确接收到数据包之后发送一个已确认接收到的应答，当 DataNode 突然挂掉了，客户端接收不到这个 DataNode 发送的 ack 确认，客户端会通知NameNode，NameNode 检查该块的副本与规定的不符，NameNode 会通知 DataNode 去复制副本，并将挂掉的 DataNode 作下线处理，不再让它参与文件上传与下

26. 简述直接将数据文件上传到HDFS的表目录中，如何在表中查询到该数据 ？

在Hive中创建表并将HDFS中的数据导入Hive，然后再进行查询就行得到结果

27. 简述NameNode与SecondaryNameNode 的区别与联系 ？

区别
1）NameNode负责管理整个文件系统的元数据，以及每一个路径（文件）所对应的数据块信息。
2）SecondaryNameNode主要用于定期合并命名空间镜像和命名空间镜像的编辑日志。

联系
1）SecondaryNameNode中保存了一份和namenode一致的镜像文件（fsimage）和编辑日志（edits）。
2）在主namenode发生故障时（假设没有及时备份数据），可以从SecondaryNameNode恢复数据

28. 简述ZKFailoverController主要职责 ？

1）健康监测：周期性的向它监控的NN发送健康探测命令，从而来确定某个NameNode是否处于健康状态，如果机器宕机，心跳失败，那么zkfc就会标记它处于一个不健康的状态。

2）会话管理：如果NN是健康的，zkfc就会在zookeeper中保持一个打开的会话，如果NameNode同时还是Active状态的，那么zkfc还会在Zookeeper中占有一个类型为短暂类型的znode，当这个NN挂掉时，这个znode将会被删除，然后备用的NN，将会得到这把锁，升级为主NN，同时标记状态为Active。

3）当宕机的NN新启动时，它会再次注册zookeper，发现已经有znode锁了，便会自动变为Standby状态，如此往复循环，保证高可靠，需要注意，目前仅仅支持最多配置2个NN。

4）master选举：如上所述，通过在zookeeper中维持一个短暂类型的znode，来实现抢占式的锁机制，从而判断那个NameNode为Active状态

29. 简述Secondary NameNode 了解吗，它的工作机制是怎样的 ？

辅助NameNode将NameNode的编辑日志合并到fsimage文件中；其具体工作机制:
1.辅助NameNode询问NameNode是否需要检查点。直接带回NameNode是否检查结果；
2.辅助NameNode请求执行检查点；；
3.NameNode滚动正在写入的编辑日志；
4.在滚动到辅助NameNode之前，复制编辑日志和图像文件；；
5.次NameNode将编辑日志和图像文件加载到内存中，并将它们合并；
6.生成新的图像文件fs image . chk point；；
7.将fsimage.chkpoint复制到NameNode；
8.NameNode已重命名为fsimage。chkpoint作为fsimage
因此，如果NameNode中的元数据丢失，可以从辅助NameNode中恢复部分元数据信息，但不是全部，因为NameNode正在写入的编辑日志尚未复制到辅助NameNode，并且这部分信息无法恢复

30. Secondary NameNode 不能恢复 NameNode 的全部数据，那如何保证NameNode 数据存储安全 ？

这个问题就要说 NameNode 的高可用了，即 NameNode HA。

如果一个NameNode有一个单点故障，那么配置双NameNode。配置中有两个关键点。一个是保证两个NameNode的元数据信息必须同步，另一个是在一个NameNode挂机后立即补上。

1.元数据信息同步采用HA方案中的“共享存储”。每次写文件时，都需要将日志同步写入共享存储。只有这一步成功了，才能决定写文件成功。然后，备份节点定期同步来自共享存储的日志，以便在活动和备用之间切换。

监控 NameNode 状态采用 zookeeper，两个 NameNode 节点的状态存放在zookeeper 中，另外两个 NameNode 节点分别有一个进程监控程序，实施读取 zookeeper 中有 NameNode 的状态，来判断当前的 NameNode 是不是已经 down 机。如果 Standby 的 NameNode 节点的 ZKFC 发现主节点已经挂掉， 那么就会强制给原本的 Active NameNode 节点发送强制关闭请求，之后将备用的 NameNode 设置为 Active。

31. 简述fsimage 和 edit 的区别 ？

fsimage：filesystem image 的简写，文件镜像。

客户端修改文件时候，先更新内存中的 metadata 信息,只有当对文件操作成功的时候，才会写到 editlog。

fsimage 是文件 meta 信息的持久化的检查点。secondary namenode 会定期的将 fsimage 和

editlog 合并 dump 成新的 fsimage

32. 简述一个文件只有一行，但是这行有 100G 大小，mr 会不会切分，我们应该怎么解决 ？

重写 inputformat