Hadoop 权威指南学习笔记（八）

                                       构建Hadoop集群

尽管建议采用 RAID(Redundant Array of Independent Disk， ) 作为 namenode 的外部存储器以避免元数据冲突，但在 datanode 中使用 RAID 作为外部存储器井不会 HDFS 带来好处。因为 HDFS 所提供的节点间复制技术己满足了数据备份需求，无需使用 RAID 的冗余机制。如果 JBOD 配置的某一磁盘出现故障， HDFS 还可以忽略该磁盘，继续工

作。相比之下， RAID 的某一盘片故障会导致整个磁盘阵列不可用。

RAID的介绍： https://blog.csdn.net/youhuakongzhi/article/details/112747781

JBOD：JBOD（Just a bunch of disk）严格上来说不是一种RAID，因为它只是简单将多个磁盘合并成一个大的逻辑盘，并没有任何的数据冗余。数据的存放机制就是从第一块磁盘开始依序向后存储数据。如果某个磁盘损毁，则该盘上的数据就会丢失。

网络拓扑

           通常， Hadoop 集群架构包含两级网络拓扑，如图 9-1 所示。一般来说，各机架装 30-40 个服务器，共享一个 1 GB 的交换机(该图中各机架只画了 3 个服务器)各

机架的交换机又通过上行链路与一个核心交换机或路由器互联。 这个架构的一突出特点是:同一机架内部节点间的总带宽要远高于不同机架间节点的带宽 。

如果集群只包含 1机架，就不需要进行配置，因为这种情况就是默认情况。但是对于多机架的集群来说，描述清楚节点，机架间的映射关系就很有必要。H adoop MapReduce 任务分配到各个节点时，会倾向于执行机架内的数据传输(拥有更多带宽) ，而非跨机架数据传输。 namenode 使用网络位置来确定在哪里放置块

的复本。 Hadoop 配置需要通过 Java 接口 DNSToSwitchMapping 来记录节点地址和网络位置之间的映射关系。 如果没有指定脚本位置，默认情况下，会将所有节点映射到单个网络位置。

 

Hadoop 控制脚本依赖 SSH 来执行针对整个集群的操作。

 

配置管理：

         Hadoop 并没有将所有配置信息放在一个单独的全局位置中。反之，集群的 Hadoop 节点都各自保存一系列配置文件，并由管理员完成这些配置文件的同步工作。Hadoop 也支持为所有的主机器和工作机器采用同一套配置文件。分别为不同机器类分别维护一套配置文件。 Hadoop 内置一些脚本来运行指令、在集群内启动和终止守护进程。为了运行这些脚本(存放在 bin 目录中)，还需要指定集群内的所有机器。有两个文件能达成这个目标，即 masters， slaves 。

 

由于集群规模差异较大，对于主节点守护进程的配置也差异很大，包括 namenode， 辅助 namenode， jobtracker.  对于大型集群来说， 则最好让这些守护进程分别运行在不同机器上。namenode 在内存中保存整个命名空间的所有文件和块元数据，它的内存需求很大。

辅助 namenode 保存一份最新的检查点，记录文件系统的元数据。将这些历史信息备份到其他节点上，有助于在数据丢失(或系统崩溃)情况 恢复 namenode 的元数据文件。

环境设置：

在一个 tasktracker 上能够同时运行的任务数取决于一台机器有多少个处理器。但经验法则是 任务数(包括 map reduce 任务)与处理器数的比值最好在 之间。

对于主节点来说， namenode 、辅助 namenode， jobtracker 守护进程在默认情况下各使用 1000 MB 内存，所以总计 3000 MB

 

由于辅助 narnenode 的内存需求量和主 narnenode 差不多， 所以更改narnenode 的内存分配之后还需对辅助 narnenode 做相同更改 (使用

HADOOP_SECONDARYNAMENODE_OPTS 变量)。在本例中，用户一般期待备用  narnenode 运行在另一台机器上。

 

JAVA

需要设置 Hadoop 系统的 Java 安装的位置。 方法一是在 hadoop-env.sh 文件中设 JAVA_HOME 项 ，方法二是在 shell 中设置 JAVA_HOME 环境变量。相比之下，方法一更好，因为只需操作一次就能够保证整个集群使用同一版本的 Java。

系统日志

默认情况下， Hadoop 生成的系统日志文件存放在 $HADOOP_INSTALL/logs 目录之中，也可以通过 hadoop-env.sh 文件中的 HADOOP_LOG_DIR 来进行修改。建议修改

默认设置，使之独立于 Hadoop 的安装目录。这样的话，即使 Hadoop 升级之后安装路径发生变化，也不会影响日志文件的位置。通常可以将日志文件存放在 /var/log/hadoop 目录中

 

SSH 设置

          借助 SSH 协议，用户在主节点上使用控制脚本就能在(远程)工作节点上运行一系列指令， StrictHostKeyChecking 也是一个很有用的 SSH 设置。设置为 no 会自动将新主机键加到已知主机文件之中。 利用 rsync 工具， Hadoop 控制脚本能够将配置文件分发到集群中的所有节点。默认情况下，该功能井未启用 为了启用功能，需要在 hadoop-env.sh 文件中定义HADOOP_MASTER 项。

如何确保每个工作节点的 hadoop-env.sh 文件已经设置好 HADOOP_MASTER?  对于小型集群来说很容易，编写一个脚本文件，将主节点的 hadoop-env.sh 文件拷贝到所有工作节点即可。对于大型集群来说，可以采用类似 dsh 的工具，井行拷贝文件。此外，还可以编写 hadoop-env.sh 文件，添加以上内容，并将这个文件作为自动安装脚本的一部分。

 

Hadoop守护进程的关键属性

        运行 HDFS 需要将一台机器指定为 namenode ，属性 fs default.name 描述 HDFS 文件系统的 URI ，其主机是 namenode 的主机名称或 IP 地址 ，端口号是

namenode 监听 RPC 的端口。如果没有指定端口，默认端口是 8020， 属性: fs . default. name 也指定了默认文件系统，可以解析相对路径。还需要配置 HDFS 以决定 namenode datanode 的存储目录。 属性项 dfs.name.dir 指定一系列目录来供 namenode 存储永久性的文件系统元数据。

通常情况下，配置 dfs.name.dir ，将 namenode 的元数据写到一个(或两个)本地磁盘和一个远程磁盘 (例如 NFS 挂载的目录)之中。这样的话，即使本地磁盘发生故障，甚至整个 namenode 发生故障，都可以恢复元数据文件，并且重构新的 namenode，（ 辅助 namenode 只是定期保存 namenode 的检查点，不提供 namenode 的最新备份）。

属性项 dfs.data.dir 指定 datanode 存储数据的目录。前面提到，

dfs.name.dir 描述一系列目录，其目的是支持冗余备份。 虽然 dfs.data.dir 也描述了一系列目录，但是其目的是循环地在各个目录中写数据 。因此，为了提高性能，最好分别为各个本地磁盘指定一个存储目录。 这样一来，数据块跨磁盘分布，针对不同数据块的读操作可以并发执行，从而提升读性 能。

 

Hadoop 守护进程的地址和端口

Hadoop 守护进程一般同时运行 RPC HTTP 两个服务器， RPC 服务器(表 9-5)支持守护进程间的通信， HTTP 服务器则提供与用户交互的 Web 页面

 

RPC简介

RPC的主要功能目标是构建分布式计算（应用场景）更容易，在提供强大的远程调用服务能力时。不损失本地调用的语义整洁性。

RPC由以下特点：

1. 透明性：远程调用其他机器上的程序，对用户来说就像调用本地的方法一样。

2. 高性能：RPC Server能够并发处理多个来自Client的请求。

3. 可控性：JDK中已经提供了一个RPC框架———-RMI,但是该RPC框架过于重量级并且可控制指出比较少，所以Haoop实现了自定义的RPC框架。

   实现RPC程序包括5个部分，即User、User-stub、RPCRuntime、Server-stub、Server

   这里的User就是Client端，当User想发起一个远程调用的时候，它实际时通过本地调用User-stub。User-stub负责将调用的接口、方法和参数通过约定的协议规范进行编码并通过本地的RPCRuntime实例传输到远端的实例。远端RPCRuntime实例收到请求后交给Server-stub进行解码后，发起本地端调用，调用结果再返回给User。

回到顶部

HadoopRPC简介

Hadoop中RPC的运行机制

同其他RPC框架一样，HadoopRPC分为4个部分

1. 序列化从层：Client与Server端通信传递的信息采用了Hadoop提供的序列化或自定义的Writable类型。
2. 函数调用层：HadoopRPC通过动态代理以及Java发射实现函数调用。
3. 网络传输层：Hadoop RPC采用了基于TPC/IP的Socket机制。
4. 服务端框架层：RPC Server利用Java NIO及采用了事件驱动的I/O模型，提高自己的并发处理能力。

Hadoop RPC 再整个Hadoop应用中十分 的广泛、Client、DataNode、NameNode之间的通信全靠它。例如人们平时操作HDFS的时候使用的时FileSystem类，它内部就有一个DFSClient对象，这个对象负责与 NameNode打交道。再运行时DFSClient在本地创建一个NameNode的代理。然后就操作这个代理，这个代理就会通过网络，远程调用NameNode方法，当然它也能返回值。

Hadoop RPC 默认设计时基于Java套接字通信，基于高性能网络的通信并不能达到最大的性能，也会是一个性能瓶颈，当一个调用要被发送到服务器时,RPC客户端首先分配DataOutputBuffer，它包含了一个常见的Java版本具有32字节的默认内部缓存器 。该缓冲区可以保存所有序列化的数据，然而一个很大的序列化数据不能保存在较小的内部缓存中。

Hadoop的其他属性

属性项 dfs.hosts 记录即将作为datanode 加入集群机器列表 属性项 map ed.hosts 记录即将作为 tasktracker 加入集群的机器列表。与之相对应的，属性项 dfs.hosts.exclude和 mapred.hosts.exclude 所指定的文件分别包含待移除的机器列表

增大缓冲区容量会显著提高性能，例如 64 KB(65 536 字节)或 128 KB(131 072 字节)更为常用。可以通过 core-site.xml 文件 中的 io. file. buffer .size 属性项来设置缓冲区大小。

默认情况下， HDFS 块大小是 64MB ，但是许多集群把块大小设为 128 MB(134 217728 字节)或 256 MB(268 435 456 字节)以降低 namenode 的内存压力，并向 mapper 传输 更多数据 。可以通过 hdfs-site.xml 文件中的 dfs.block.size 属性项设置块的大小。

默认情况下， datanode 能够使用存储目录上的所有闲置空间，这可能导致没有空间 可供其他应用程序使用。 如果计划将部分空间留给其他应用程序(非 HDFS) ，则需要设置 dfs.datanode.du.reserved 属性项来指定待保留的空间大小 (以字节为单位)。

       回收站中的文件在被永久删除之前仍会至少保留一段时间。该信息由 core-site.xml 文件中的 fs.trash.interval 属性项 (以分钟为单位)

   假设一台运行 tasktracker 的机器的可用内存耗尽，则会影响其他正在运行的进程。为了防止此类事故发生，需要：

 

YARN

yarn.nodemanager.local-dirs 指定路径来存储中间数据

任务槽：

           一个MapReduce 作业的计算工作都由TaskTracker 完成。用户向Hadoop 提交作业，Job Tracker 会将该作业拆分为多个任务， 并根据心跳信息交由空闲的TaskTracker 启动。一个Task Tracker 能够启动的任务数量是由TaskTracker 配置的任务槽（ slot ） 决定。槽是Hadoop 的计算资源的表示模型， Hadoop 将各个节点上的多维度资源（ CPU 、内存等）抽象成一维度的槽，这样就将多维度资源分配问题转换成一维度的槽分配的问题。在实际情况中，Map 任务和Reduce任务需要的计算资源不尽相同， Hadoop 又将槽分成Map 槽和Reduce 槽， 并且Map 任务只能使用Map槽， Reduce 任务只能使用Reduce槽。

内存：

    yarn模型中，节点管理器从一个内存池中分配内存，同时运行的任务数量依赖于内存需求总量，而非槽数量。

虚拟内存和物理内存：

物理内存就是你的机器本身内存了（如内存条的大小）。物理内存就是CPU的地址线可以直接进行寻址的内存空间大小。比如8086只有20根地址线，那么它的寻址空间就是1MB，我们就说8086能支持1MB的物理内存，及时我们安装了128M的内存条在板子上，我们也只能说8086拥有1MB的物理内存空间。同理我们现在大部分使用的是32位的机子，32位的386以上CPU就可以支持最大4GB的物理内存空间了。

虚拟内存技术，即拿出一部分硬盘空间来充当内存使用，当内存占用完时，电脑就会自动调用硬盘来充当内存，以缓解内存的紧张。比如说当电脑要读取一个比物理内存还要大的文件时，就要用到虚拟内存，文件被内存读取之后就会先储存到虚拟内存，等待内存把文件全部储存到虚拟内存之后，就把虚拟内里储存的文件释放到原来的目录里了。

安全性

         Hadoop 缺乏一个安全的认证机制，以确保试图在集群上执行操作的用户恰是所声称的安全用户。如果把同一集群上的数据划分不同的安全级别，在管理上会方便很多，特别是这意味着低安全级别的数据能够被广泛共享。 然而，为了迎合数据保护的常规需求，共享集群的安全认证是不可或缺的。

1. 一个方案用 Kerberos( 一个成熟的开据网络认证协议)实现用户认证， Hadoop 不直接管理用户隐私，而 Kerberos 也不关心用户的授权细节。换句话说， Kerberos 的职责在于鉴定登录帐号是否是他所声称的用 户， Hadoop 则决定这个用户到底拥有多少权限。

2. 委托令牌。

委托令牌由服务器创建(在这里是指 namenode) ，可以视为客户端和服务器之间共享的一个密文。当客户端首次通过 RPC 访问 namenode 时，客户端井没有委托令牌，因而需要利用 Kerberos 进行认证。之后，客户端从 namenode 取得一个委托令牌。在后续 RPC 调用中，客户端只需出示委托令牌， namenode 就能验证委托令牌的真伪(因为该令牌是由 namenode 使用密钥创建的) ，井因此向服务器认证客户端的身份。

 

       现实情况下，一般在集群被投入服务之前进行测试。 且用户已经在集群上周期性地调度作业，想找到集群完全空闲的时间就非常困难了(除非和其他用户协商一个 停止服务的时间段)。总而言之，基准测试程序最好在此之前就执行。 硬盘故障是新系统最常见的硬件故障。 Tes tD FSIO 能够用于测试 HDFS 的I/O  性能