超全面试汇总——Hadoop（一）_hadoop面经

HDFS文件系统的特点

• 扩展性 & 容错性 & 海量数量存储
• master/slaver架构 主从架构
• 分块存储 block 128M
• 名字空间 NameSpace HDFS 支持传统的层次型文件组织结构任何对文件系统名字空间或属性的修改
• 数据通过副本存储 默认3个副本，提高了容错性
• 能够处理很多数据，对应用程序的高吞吐量访问
• 方便扩展
• 节约成本可建在廉价机器上、分布式

@@HDFS的读写流程

• 写流程
  • 用户在Client向NN节点发起命令，通过RPC与NN建立通讯，namenode检查该用户是否有上传权限，以及上传的文件是否在hdfs对应的目录下重名，
  • 将文件分块block（一般128MB一块）和设置副本参数（3个）
  • NN节点负责协调Client和DN节点的交互，从管理的DN节点中找到合适的3个节点（两个不同机架、一个同机架），把DN节点地址和路径参数给Client，并记录元数据；
  • Client通过NN的回复信息找到第一个DN节点A，数据被分割成一个个的packet数据包在pipeline上依次传输，Client 开始往 A 上传第一个 block（先从磁盘读取数据放到一个本地内存缓存），以 packet 为单位（默认64K），A 收到一个 packet （64kb）就会传给 B，B 传给 C（串形写入）。A 每传一个 packet 会放入一个应答队列等待应答，在 pipeline 反方向上， 逐个发送 ack（命令正确应答）
  • 本质上就是RPC调用，建立pipeline，A收到请求后会继续调用B，B在调用C，将整个pipeline建立完成，逐级返回client
  • Client 再次请求 NameNode 上传第二个 block ，namenode重新选择三台DataNode给client
• 读流程
  • Client向NN节点发出读请求RPC，包含文件名等信息
  • NN收到请求，检查用户权限以及是否有这个文件，NameNode会视情况返回文件的部分或者全部block列表，**对于每个block，NameNode 都会返回含有该 block 副本的 DataNode 地址（不是返回请求块的数据）；**按照DN与客户端的距离排序
  • Client根据收到的DN节点信息，选取每个块所在路径开销最小的DN节点执行读取操作。如果客户端本身就是DataNode,那么将从本地直接获取数据(短路读取特性)
  • 客户端和DN通讯，底层上本质是建立 Socket Stream，重复的调用父类 DataInputStream 的 read 方法，直到这个块上的数据读取完毕，并行的读取block信息，并会checksum验证
• HDFS在读取文件的时候,如果其中一个块突然损坏了怎么办
  • 客户端读取完DataNode上的块之后会进行checksum 验证，也就是把客户端读取到本地的块与HDFS上的原始块进行校验，如果发现校验结果不一致，客户端会通知 NameNode，然后再从下一个拥有该 block 副本的DataNode 继续读
• HDFS在上传文件的时候,如果其中一个DataNode突然挂掉了怎么办
  • 客户端上传文件时与DataNode建立pipeline管道，管道正向是客户端向DataNode发送的数据包，管道反向是DataNode向客户端发送ack确认，也就是正确接收到数据包之后发送一个已确认接收到的应答，
  • 当DataNode突然挂掉了，客户端接收不到这个DataNode发送的ack确认，客户端会通知 NameNode，NameNode检查该块的副本与规定的不符，NameNode会通知DataNode去复制副本，并将挂掉的DataNode作下线处理，不再让它参与文件上传与下载。

@客户端和NameNode、DataNode通信过程

• client和NameNode之间是通过RPC通信
• DataNode和NameNode之间是通过RPC通信
• client和DataNode之间是通过简单的Socket通信
• DataNode与DataNode之间通过RPC通信
• Remote Procedure Call （简称：RPC):远程过程调用协议。
  • 请求程序就是一个客户机，而服务提供程序就是一个服务器。
  • 首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。
  • 在服务器端，进程保持睡眠状态直到调用信息的到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。

底层文件结构 好处

• HDFS目前默认块大小在Hadoop2.x版本中是128M，减少寻址开销
• 目前磁盘的传输率约为100M/s,而HDFS读取文件时最佳的寻址时间为10ms，寻址时间为传输时间的百分之1时最佳，所以定义块大小为128M，1秒左右可以快速读取完毕；本质上HDFS的块大小取决于磁盘的传输速率。
• 简化存储系统的设计。因为块是固定的大小，计算磁盘的存储能力就容易多了
• 以块的形式存储 不需要全部存在一个磁盘上，可以分布在各个文件系统的磁盘上

@HDFS存储文件类型

• 面向行：同一行的数据存储在一起，即连续存储。
  • text
  • SequenceFile 用于存储键值对的二进制文件格式 支持压缩
  • MapFile 排序后的sequencefile
• 面向列：整个文件被切割为若干列数据，每一列数据一起存储，不适合流式写入，因为一旦写入失败，当前文件无法恢复
  • RC File 是一种行列存储相结合的存储方式。首先，其将数据按行分块，保证同一个 record 在一个块上，避免读一个记录需要读取多个 block。其次，块数据列式存储，有利于数据压缩和快速的列存取。RCFile 目前没有性能优势，只有存储上能省 10% 的空间。
  • ORC File ：优化的RC FIle

@HDFS的组成，重要角色

• Client：客户端
  • 切分文件。文件上传HDFS的时候，Client将文件切分成一个一个的Block，然后进行存储
  • 与NameNode交互，获取文件的位置信息
  • 与DataNode交互，读取或者写入数据
  • Client提供一些命令来管理HDFS，比如启动关闭HDFS、访问HDFS目录及内容等
• NameNode节点，负责管理文件系统的命名空间、集群配置信息(block映射信息)和存储块的复制等
  • 元数据信息包括文件名，命令空间，文件属性（文件生成的时间、文件的副本数、文件的权限）、文件数据块、文件数据块与所在 DataNode 之间的映射关系等
  • 将文件的元数据保存在一个文件目录树中
  • Editlog 日志文件,记录每次元数据的变化
  • FsImage 镜像文件,存储系统的命名空间，内存中元数据在本地磁盘的映射
• SecondaryNameNode，并不是 NameNode 的备份，在NameNode 发生故障时也不能立刻接管 NameNode 的工作，一个是备份数据镜像，另一个是定期合并日志与镜像，因此可以称其为 Hadoop 的检查点（checkpoint）,定期同步NameNode的日志(EditLog)和镜像文件(FsImage),并将日志和镜像合并成新的镜像文件fsimage.ckpt回传给NameNode
• DataNode节点，HDFS的执行者。负责文件的存储，以块为存储单位，数据分散在不同DN节点，支持一次写入多次读取等。相当于正文。
  • 一个数据块包含两个文件：一个是存储数据本身的文件，另一个是存储元数据的文件（这些元数据主要包括数据块的长度、数据块的检验和、时间戳）。
  • 每个存储数据的节点运行一个 datanode 守护进程。
• 热备份 NameNode停止工作后,热备份NameNode马上接替NameNode的工作
• 冷备份 同SecondaryNmaeNode

HDFS的几个进程

• namenode
  • 负责接收客户端读写数据请求
  • 负责数据块副本的存储策略
  • 存储元数据信息 元数据保存在内存中
  • 管理文件系统名称空间
• datenode
  • 存储实际的数据块
  • 每个存储数据的节点运行一个 datanode 守护进程。
• secondary name node
  • 与name node，通讯定期合并FSimage和Edits编辑日志,合并为最新的镜像文件
  • 保存HDFS元数据的快照
• resource manager 统一资源调度和管理器
  • 处理客户端请求
  • 监控node manger
  • 启动或者监控 appliaction master
  • 资源的分配和调度
• node manger 提供计算资源
  • 管理单个节点上的资源，YARN中每个节点上的代理
  • 与ResourceManger保持通信，监督Container的生命周期管理

@yarn 集群的架构

• ResourceManager
  • RM是一个全局的资源管理器，负责整个系统的资源管理和分配，它主要由两个部分组成：调度器（Scheduler）和应用程序管理器（Application Manager）。
  • 应用程序的提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重启它
• ApplicationMaster
  • 用户提交的一个应用程序会对应于一个ApplicationMaster
  • 与RM调度器协商以获得资源，资源以Container表示。
  • 将得到的任务进一步分配给内部的任务。
  • 与NM通信以启动/停止任务。
  • 监控所有的内部任务状态，并在任务运行失败的时候重新为任务申请资源以重启任务。
• NodeManager
  • NodeManager是每个节点上的资源和任务管理器，
  • 一方面，它会定期地向RM汇报本节点上的资源使用情况和各个Container的运行状态；
  • 另一方面，他接收并处理来自AM的Container启动和停止请求。
• Container
  • 是YARN中的资源抽象，封装了各种资源。一个应用程序会分配一个Container，这个应用程序只能使用这个Container中描述的资源。是一个动态资源的划分单位，更能充分利用资源。

@yarn执行流程

• Client提交作业请求
• NodeManager进程和 ResourceManager 进程通信，根据集群资源，为用户程序分配第一个Container(容器)，并将 ApplicationMaster 分发到这个容器上面
• 在启动的Container中创建ApplicationMaster
• ApplicationMaster启动后向ResourceManager注册进程,采用轮询的方式向RM申请和领取资源
• ApplicationMaster申请到资源后，向对应的NodeManager申请启动Container,将要执行的程序分发到NodeManager上
• NodeManager设置好运行环境，Container启动后，执行对应的任务
• Tast执行完毕之后，向ApplicationMaster返回结果
• ApplicationMaster向ResourceManager 请求kill

yarn 的资源调度三种模型

• FIFO Scheduler 先来先服务
• Capacity Scheduler 能力调度器 apache版本的hadoop
  • 有一个专门的队列用来运行小任务，但是为小任务专门设置一个队列会预先占用一定的集群资源
• Fair Scheduler 公平调度器 CDH版本的默认使用的
  • Fair调度器会为所有运行的job动态的调整系统资源。当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。
  • 从第二个任务提交到获得资源会有一定的延迟，因为它需要等待第一个任务释放占用的Container。小任务执行完成之后也会释放自己占用的资源，大任务又获得了全部的系统资源。

HDFS的高可靠性

• NN的高可靠性
  • 热备份：ZooKeeper就是协调机制，在HDFS中主要就是协调选举主备NameNode节点。每个NN节点都会通过 “心跳”与ZooKeeper保持联系，报告自己的状态信息虽然备NN节点不工作，但它里面的元数据信息和DN节点状态信息跟主NN节点是同步更新的，所以一旦备NN被选为主NN节点，会立刻接替主NN节点的工作。
  • 冷备份 secondary node工作原理：
    • 当有对元数据执行操作时，NN节点会生成 新的对应日志文件( Editlog.new)
    • NN节点 **内存里存放的是日志文件(Editlog)和元数据镜像文件(Fsimage)，**namenode 滚动正在写的edits日志，SecondaryNN通过NN节点定时同步checkpoint获取得到滚动前的日志和镜像文件，
    • SecondaryNN中将二者合并成新的镜像文件Fsimage.ckpt文件并上传到主节点上
    • 主节点将原来的镜像文件更新NN，此时在之前过程中新的日志文件(Editlog.new)已经变成Editlog，不在是新日志，与更新后的镜像文件重新同步到SecondaryNN上
    • 当NN故障退出需要重新恢复时，可以从SecondaryNN的工作目录中将Fsimage拷贝到NN的工作目录，以恢复NN中的元数据。
  • 默认情况下进行ckeckpoint（合并镜像及编辑日志）的触发条件是什么？
    • 2NN每隔一小时执行一次checkpoint
    • 一分钟检查一次Edits文件的操作次数，当操作次数达到1百万时，2NN执行一次checkpoint
• DN的高可靠性
  • 数据的副本机制，数据冗余
  • DN受NN节点的监控，若挂了会重新找一带DN节点，根据副本数据进行备份。同时修改元数据信息和DN节点状态信息

冷备份 secondary node工作原理：

• 当有对元数据执行操作时，NN节点会生成 新的对应日志文件( Editlog.new)
• NN节点内存里存放的是日志文件(Editlog)和元数据镜像文件(Fsimage)，Secondary NameNode请求执行checkpoint，NameNode滚动正在写的edits日志，生成新的edits log，把新的日志写到新的edits log中
• 将滚动前的编辑日志和镜像文件拷贝到SecondaryNN ，使用的是http get方式，SecondaryNN中将二者合并成新的镜像文件Fsimage.ckpt文件并上传到主节点上
• 主节点将原来的镜像文件更新NN，此时在之前过程中新的日志文件 (Editlog.new)已经变成Editlog，NameNode将fsimage.chkpoint重新命名成fsimage，不再是新日志，与更新后的镜像文件重新同步到SecondaryNN上
• 当NN故障退出需要重新恢复时，可以从SecondaryNN的工作目录中将Fsimage拷贝到NN的工作目录，以恢复NN中的元数据。
• 从Secondary NameNode恢复一部分元数据信息的，但不是全部，因为NameNode正在写的edits日志还没有拷贝到Secondary NameNode，这部分恢复不了
• 默认情况下进行ckeckpoint（合并镜像及编辑日志）的触发条件是什么？
  • 2NN每隔一小时执行一次checkpoint
  • 一分钟检查一次Edits文件的操作次数，当操作次数达到1百万时，2NN执行一次checkpoint
  • 可以在core-site.xml 中配置

@hadoop的HA(高可用)实现和zk的作用

• 在典型的HA集群中，一般有两台不同的机器充当nn,(note1 主机 nn ，note2 备用主机nn )。在任何时间，有且只有一台机器处于active状态；另一台机器处于standby状态。 active nn 负责所有客户端的操作，standby nn 主要用于备用，它的主要目的是 active nn宕机时 ，可以提供备用并快速的故障恢复。
• 元数据信息同步在 HA 方案中采用的是“共享存储”。每次写文件时，需要将日志同步写入共享存储，这个步骤成功才能认定写文件成功。然后备份节点定期从共享存储同步日志，以便进行主备切换。
• 监控NN状态采用 zookeeper，两个NN节点的状态存放在ZK中，另外两个NN节点分别有一个进程监控程序，实施读取ZK中有NN的状态，来判断当前的NN是不是已经down机。如果standby的NN节点的ZKFC发现主节点已经挂掉，那么就会强制给原本的active NN节点发送强制关闭请求，之后将备用的NN设置为active。
• standby nn 如何保持与active nn 数据同步 (元数据保持一致)
  • 这里有一个JournalNodes守护进程，他俩都会和这个进程通信，当 active nn 执行任何有关命名空间的修改操作，它需要持久化到一半以上的 JournalNodes 上(通过 edits log 持久化存储),而 Standby NN 负责观察 edits log的变化,它能够读取从 JNs 中读取 edits 信息,并更新其内部的命名空间。一旦 Active NN出现故障,Standby NN 将会保证从 JNs 中读出了全部的 Edits,然后切换成 Active 状态。
  • QJM 共享存储的基本思想来自于 Paxos 算法，采用多个称为 JournalNode 的节点组成的 JournalNode 集群来存储 EditLog
  • 为了提供快速的故障恢复,Standby NN 也需要保存集群中各个文件块的存储位置。为了实现这个,集群中所有的 Database 将配置好 Active NN 和 Standby NN 的位置,并向它们发送块文件所在的位置及心跳

在NameNode HA中，会出现脑裂问题吗？怎么解决脑裂

假设 NameNode1 当前为 Active 状态，NameNode2 当前为 Standby 状态。如果某一时刻 NameNode1 对应的 ZKFailoverController 进程发生了“假死”现象，那么 Zookeeper 服务端会认为 NameNode1 挂掉了，根据前面的主备切换逻辑，NameNode2 会替代 NameNode1 进入 Active 状态。但是此时 NameNode1 可能仍然处于 Active 状态正常运行，这样 NameNode1 和 NameNode2 都处于 Active 状态，都可以对外提供服务。这种情况称为脑裂

• 脑裂对于NameNode 这类对数据一致性要求非常高的系统来说是灾难性的，数据会发生错乱且无法恢复。Zookeeper 社区对这种问题的解决方法叫做 fencing，中文翻译为隔离，也就是想办法把旧的 Active NameNode 隔离起来，使它不能正常对外提供服务。
• 在进行 fencing 的时候，会执行以下的操作：
  • 首先尝试调用这个旧 Active NameNode 的 HAServiceProtocol RPC 接口的 transitionToStandby 方法，看能不能把它转换为 Standby 状态。
  • 如果 transitionToStandby 方法调用失败，那么就执行 Hadoop 配置文件之中预定义的隔离措施，Hadoop 目前主要提供两种隔离措施，通常会选择 sshfence：
    • sshfence：通过 SSH 登录到目标机器上，执行命令 fuser 将对应的进程杀死
    • shellfence：执行一个用户自定义的 shell 脚本来将对应的进程隔离

Zookeeper起什么作用的

• ZooKeeper就是协调机制，在HDFS中主要就是协调选举主备NameNode节点。
• 每个NN节点都会通过**“心跳”与ZooKeeper保持联系，报告自己的状态信息**虽然备NN节点不工作，但它里面的元数据信息和DN节点状态信息跟主NN节点是同步更新的，所以一旦备NN被选为主NN节点，会立刻接替主NN节点的工作

@ZooKeeper的选举机制

• Zookeeper的工作原理 Paxos帕克索斯

• 半数机制：集群中半数以上机器存活，集群可用。所以Zookeeper适合安装奇数台服务器。

• Zookeeper虽然在配置文件中并没有指定Master和Slave。但是，Zookeeper工作时，是有一个节点为Leader，其他则为Follower，Leader是通过内部的选举机制临时产

• 选举过程，假设有五台服务器组成的Zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样的。假设这些服务器依序启动，来看看会发生什么。

  • 服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为LOOKING；
  • 服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息：此时服务器1发现服务器2的ID比自己目前投票推举的（服务器1）大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持LOOKING
  • 服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING；
  • 服务器4启动，发起一次选举。此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING；
  • 服务器5启动，同4一样当小弟。

@HDFS如何保证数据的一致性

1. 安全模式

• https://www.cnblogs.com/si-137/p/13289673.html

• HDFS的启动和关闭都是先启动NameNode，再启动DataNode，最后在启动secondarynamenode。

• NameNode启动时，会将镜像文件（Fsimage）和编辑日志（Edits）加载到内存。一旦在内存中成功建立文件系统元数据的映像，则创建一个新的Fsimage文件和一个空的编辑日志。此时，NameNode开始监听DataNode请求。这个过程期间，NameNode处于安全模式。

• 当数据块的副本数不满足（dfs.replication.min=1）最小副本数时 数量少于要求的99%，会自动补全，不会主动退出安全模式；

• 当系统处于安全模式时会检查数据块的完整性。在安全模式状态下，文件系统只接受读数据请求，而不接受删除、修改等变更请求

• hdfs  dfsadmin  -safemode  get #查看安全模式状态
  hdfs  dfsadmin  -safemode  enter #进入安全模式
  hdfs  dfsadmin  -safemode  leave #离开安全模式
  1
  2
  3

2. SecondaryNamenode：

• namenode中保存了整个文件系统的元数据，而SecondaryNameNode的作用就是周期性（周期长短也可配）保存NameNode的元数据。这些源数据中包括文件镜像数据FSImage和编辑日志EditLog。FSImage相当于HDFS的检查点，namenode启动时候会读取FSImage的内容到内存，并将其与EditLog日志中的所有修改信息合并生成新的FSImage；在namenode运行过程中，所有关于HDFS的修改都将写入EditLog。这样，如果namenode失效，可以通过SecondaryNameNode中保存的FSImage和EditLog数据恢复出namenode最近的状态，尽量减少损失。

3. 心跳机制和副本重新创建

• 为了保证namenode和各个datanode的联系，HDFS采用了心跳机制。位于整个HDFS核心的namenode，通过周期性的活动来检查datanode的活性，像跳动的心脏一样。Namenode周期性向各个datanode发送心跳包，而收到心跳包的datanode要进行回复。因为心跳包是定时发送的，所以namenode就把要执行的命令也通过心跳包发送给datanode，而datanode收到心跳包，一方面回复namenode，另一方面就开始了用户或者应用的数据传输。

• 如果侦测到datanode失效，namenode之前保存在这个datanode上的数据就变成不可用数据。如果有的副本存储在失效的datanode上，则需要重新创建这个副本，放到另外可用的地方。

4. 数据一致性：

一般来讲，datanode与应用交互的大部分情况都是通过网络进行的，而网络数据传输带来的一大问题就是数据是否原样到达。为了保证数据的一致性，HDFS采用了数据校验和(checkSum)机制。创建文件时，HDFS会为这个文件生成一个校验和，校验和文件和文件本身保存在同一空间中。传输数据时会将数据与校验数据和一同传输，应用收到数据后可以进行校验，如果两个校验的结果不同，则文件肯定出错了，这个数据块就变成无效的。如果判定无效，则需要从其他datanode上读取副本。

5.租约：

在linux中，为了防止多个进程向同一个文件写数据的情况，采用了文件加锁的机制。而在HDFS中，同样需要一个机制来防止同一个文件被多个人写入数据。这种机制就是租约(Lease)，每当写入数据之前，一个客户端必须获得namenode发放的一个租约。Namenode保证同一个文件只发放一个允许写的租约。那么就可以有效防止多人写入的情况。

6.回滚：

HDFS安装或升级时，会将当前的版本信息保存起来，如果升级一段时间内运行正常，可以认为这次升级没有问题，重新保存版本信息，否则，根据保存的旧版本信息，将HDFS恢复至之前的版本。

@机架感知

• HDFS 为了降低整体的网络带宽消耗和数据读取延时，HDFS 集群一定会让客户端尽量去读取近的副本，那么按照以上头解释的副本存放策略的结果：

  • 如果在本机有数据，那么直接读取；
  • 如果在跟本机同机架的服务器节点中有该数据块，则直接读取；
  • 如果该 HDFS 集群跨多个数据中心，那么客户端也一定会优先读取本数据中心的数据。

• 但是 HDFS 是如何确定两个节点是否是统一节点，如何确定的不同服务器跟客户端的远近呢？答案就是机架感知。！！！！

• 在默认情况下，HDFS 集群是没有机架感知的，也就是说所有服务器节点在同一个默认机架中。那也就意味着客户端在上传数据的时候，HDFS 集群是随机挑选服务器节点来存储数据块的三个副本的

• 那么假如，datanode1 和 datanode3 在同一个机架 rack1，而 datanode2 在第二个机架 rack2，那么客户端上传一个数据块 block_001，HDFS 将第一个副本存放在 dfatanode1，第二个副本存放在 datanode2，那么数据的传输已经跨机架一次（从 rack1 到 rack2），然后 HDFS 把第三个副本存 datanode3，此时数据的传输再跨机架一次（从 rack2 到 rack1）。显然，当 HDFS 需要处理的数据量比较大的时候，那么没有配置机架感知就会造成整个集群的网络带宽的消耗非常严重。

启动集群时，我们要对namenode进行格式化操作？为什么只能格式化一次

• 因为格式化NameNode，就会产生新的集群id,导致NameNode和DataNode的集群id不一致，集群找不到已往数据（现象datanode无法正常启动）
• 重新格式化NameNode时，一定要先删除data数据和log日志，然后再格式化NameNode，后再启动集群

namenode的瓶颈，当文件非常多，存储瓶颈是？

• NameNode内存占用问题

  • NameNode是HDFS中的管理者，主要负责文件系统的命名空间、集群配置信息和数据块的复制等。NameNode在内存中保存文件系统中每个文件和每个数据块的引用关系，也就是元数据。
  • 在运行时，HDFS中每个文件、目录和数据块的元数据信息（大约150字节）必须存储在NameNode的内存中。所以我们可以计算得出如果HDFS要存储1亿个文件（每个文件对应一个数据块），则需要至少20GB的内存空间。

• NameNode占用的内存大概是300GB。那么当它重启时，则需要从本地磁盘读取每个文件的元数据。这意味着NameNode需要加载300GB大小的数据到内存中，从而不可避免的导致服务启动时间较长。

• 在HDFS中，DataNode会通过定时的心跳来上报其数据块的位置信息，NameNode会不断跟踪并检查每个数据块的存储位置。所以数据节点需要上报的数据块越多，则会消耗越多的网络带宽，进而对网络造成压力。

• 大量的小文件

  • 源数据为海量小文件；在Hadoop处理实时或者准实时计算场景中，大部分时候抽取数据的时间间隔决定了文件的大小，如果间隔较小，比如每小时抽取一次；MapReduce中reduce数量设置过多，就可能导致任务运行结果变成N多小文件
  • 减少reduce的数量（可以使用参数进行控制）；少用动态分区，用时记得按distribute by分区；
  • 可以选择在客户端上传时执行一定的策略先合并,或者是使用Hadoop的CombineFileInputFormat<K,V>实现小文件的合并