2. hadoop 的笔记

一，集群的初步使用

 

1.Hadoop 集群启动

DFS 集群启动：sbin/start-dfs.sh

DFS 集群关闭：sbin/stop-dfs.sh

YARN 集群启动：sbin/start-yarn.sh

YARN 集群启动：sbin/stop-yarn.sh

 

2.HDFS 初步使用

查看集群文件：hadoop fs -ls /

上传文件：hadoop fs -put filepath destpath

下载文件：hadoop fs -get destpath

创建文件夹：hadoop fs -mkdir /hadoopdata

查看文件内容：hadoop fs -cat /hadoopdata/mysecret.txt

 

3.mapreduce 初步

演示 hadoop 自带的例子程序并观察执行过程：

1、求 PI

hadoop jar hadoop-mapreduce-examples-2.6.5.jar pi 5 5   （该 jar 位于：/home/hadoop/apps/hadoop-2.6.5/share/hadoop/mapreduce/）

执行结果：

Job Finished in 70.913 seconds

Estimated value of Pi is 3.20000000000000000000

2、单词计数

hadoop jar hadoop-mapreduce-examples-2.6.5.jar wordcount /hadoopdata/mysecret.txt

 

二，为什么会有 hadoop HA

 

HA：High Available，高可用

在Hadoop 2.0之前,在HDFS 集群中NameNode 存在单点故障 (SPOF：A Single Point of Failure)。对于只有一个 NameNode 的集群，如果 NameNode 机器出现故障(比如宕机或是软件、硬件升级)，那么整个集群将无法使用，直到 NameNode 重新启动

 

那如何解决呢

HDFS 的 HA 功能通过配置 Active/Standby 两个 NameNodes 实现在集群中对 NameNode 的热备来解决上述问题。如果出现故障，如机器崩溃或机器需要升级维护，这时可通过此种方式将 NameNode 很快的切换到另外一台机器。

在一个典型的 HDFS(HA) 集群中，使用两台单独的机器配置为 NameNodes 。在任何时间点，确保 NameNodes 中只有一个处于 Active 状态，其他的处在 Standby 状态。其中ActiveNameNode 负责集群中的所有客户端操作，StandbyNameNode 仅仅充当备机，保证一旦 ActiveNameNode 出现问题能够快速切换。

为了能够实时同步 Active 和 Standby 两个 NameNode 的元数据信息（实际上 editlog），需提供一个共享存储系统，可以是 NFS、QJM（Quorum Journal Manager）或者 Zookeeper，Active Namenode 将数据写入共享存储系统，而 Standby 监听该系统，一旦发现有新数据写入，则读取这些数据，并加载到自己内存中，以保证自己内存状态与 Active NameNode 保持基本一致，如此这般，在紧急情况下 standby 便可快速切为 active namenode。为了实现快速切换，Standby 节点获取集群的最新文件块信息也是很有必要的。为了实现这一目标，DataNode 需要配置 NameNodes 的位置，并同时给他们发送文件块信息以及心跳检测

 

三，Hadoop 配置机架感知

1.背景

      Hadoop在设计时考虑到数据的安全与高效，数据文件默认在HDFS上存放三份，存储策略为本地一份，同机架内其它某一节点上一份，不同机架的某一节点上一份。这样如果本地数据损坏，节点可以从同一机架内的相邻节点拿到数据，速度肯定比从跨机架节点上拿数据要快；同时，如果整个机架的网络出现异常，也能保证在其它机架的节点上找到数据。为了降低整体的带宽消耗和读取延时，HDFS会尽量让读取程序读取离它最近的副本。如果在读取程序的同一个机架上有一个副本，那么就读取该副本。如果一个HDFS集群跨越多个数据中心，那么客户端也将首先读本地数据中心的副本。那么Hadoop是如何确定任意两个节点是位于同一机架，还是跨机架的呢？答案就是机架感知。

     默认情况下，hadoop的机架感知是没有被启用的。所以，在通常情况下，hadoop集群的HDFS在选机器的时候，是随机选择的，也就是说，很有可能在写数据时，hadoop将第一块数据block1写到了rack1上，然后随机的选择下将block2写入到了rack2下，此时两个rack之间产生了数据传输的流量，再接下来，在随机的情况下，又将block3重新又写回了rack1，此时，两个rack之间又产生了一次数据流量。在job处理的数据量非常的大，或者往hadoop推送的数据量非常大的时候，这种情况会造成rack之间的网络流量成倍的上升，成为性能的瓶颈，进而影响作业的性能以至于整个集群的服务

 

自己总结以上的话就是：备份的话，先同一个机架 ，然后离得近的机架，不能都在一个机架，方式整个机架有问题 ， 之所有要选近的 ， 因为中间的大量数据网络传输的流量会有瓶颈

 

2.配置

  默认情况下，namenode启动时候日志是这样的：

2016-07-17 17:27:26,423 INFO org.apache.hadoop.net.NetworkTopology: Adding a new node: /default-rack/ 192.168.147.92:50010

每个IP 对应的机架ID都是 /default-rack ，说明hadoop的机架感知没有被启用。

要将hadoop机架感知的功能启用，配置非常简单，在 NameNode所在节点的/home/bigdata/apps/hadoop/etc/hadoop的core-site.xml配置文件中配置一个选项:

<property>

        <name>topology.script.file.name</name>

        <value>/home/bigdata/apps/hadoop/etc/hadoop/topology.sh</value>

</property>

      这个配置选项的value指定为一个可执行程序，通常为一个脚本，该脚本接受一个参数，输出一个值。接受的参数通常为某台datanode机器的ip地址，而输出的值通常为该ip地址对应的datanode所在的rack，例如”/rack1”。Namenode启动时，会判断该配置选项是否为空，如果非空，则表示已经启用机架感知的配置，此时namenode会根据配置寻找该脚本，并在接收到每一个datanode的heartbeat时，将该datanode的ip地址作为参数传给该脚本运行，并将得到的输出作为该datanode所属的机架ID，保存到内存的一个map中.

      至于脚本的编写，就需要将真实的网络拓朴和机架信息了解清楚后，通过该脚本能够将机器的ip地址和机器名正确的映射到相应的机架上去。一个简单的实现如下

自己的总结：namenode 判断配置的值，如果配置了，namenode 根据配置的选项会执行一个可执行的程序，接受datanode 机器的ip ,返回它所在的机架 ，保存到内存中

#!/bin/bash

HADOOP_CONF=/home/bigdata/apps/hadoop/etc/hadoop

while [ $# -gt 0 ] ; do

nodeArg=$1

exec<${HADOOP_CONF}/topology.data

result=""

while read line ; do

ar=( $line )

if [ "${ar[0]}" = "$nodeArg" ]||[ "${ar[1]}" = "$nodeArg" ]; then

result="${ar[2]}"

fi

done

shift

if [ -z "$result" ] ; then

echo -n "/default-rack"

else

echo -n "$result"

fi

done

topology.data ,格式为：节点（ip或主机名） /交换机xx/机架xx

192.168.147.91 tbe192168147091 /dc1/rack1

192.168.147.92 tbe192168147092 /dc1/rack1

192.168.147.93 tbe192168147093 /dc1/rack2

192.168.147.94 tbe192168147094 /dc1/rack3

192.168.147.95 tbe192168147095 /dc1/rack3

192.168.147.96 tbe192168147096 /dc1/rack3

需要注意的是，在Namenode上，该文件中的节点必须使用IP，使用主机名无效，而Jobtracker上，该文件中的节点必须使用主机名，使用IP无效,所以，最好ip和主机名都配上。

 

这样配置后，namenode启动时候日志是这样的：

2016-07-17 17:16:27,272 INFO org.apache.hadoop.net.NetworkTopology: Adding a new node: /dc1/rack3/ 192.168.147.94:50010

说明hadoop的机架感知已经被启用了。

 

查看HADOOP机架信息命令:

./hadoop dfsadmin -printTopology

Rack: /dc1/rack1

192.168.147.91:50010 (tbe192168147091)

192.168.147.92:50010 (tbe192168147092)

 

Rack: /dc1/rack2

192.168.147.93:50010 (tbe192168147093)

 

Rack: /dc1/rack3

192.168.147.94:50010 (tbe192168147094)

192.168.147.95:50010 (tbe192168147095)

192.168.147.96:50010 (tbe192168147096)

 

3.增加数据节点，不重启NameNode

假设Hadoop集群在192.168.147.68上部署了NameNode和DataNode,启用了机架感知，执行bin/hadoop dfsadmin -printTopology看到的结果：

Rack: /dc1/rack1

   192.168.147.68:50010 (dbj68)

现在想增加一个物理位置在rack2的数据节点192.168.147.69到集群中，不重启NameNode。

首先，修改NameNode节点的topology.data的配置，加入:192.168.147.69 dbj69 /dc1/rack2,保存。

192.168.147.68 dbj68 /dc1/rack1

192.168.147.69 dbj69 /dc1/rack2

然后，sbin/hadoop-daemons.sh start datanode启动数据节点dbj69,任意节点执行bin/hadoop dfsadmin -printTopology 看到的结果：

Rack: /dc1/rack1

192.168.147.68:50010 (dbj68)

 

Rack: /dc1/rack2

192.168.147.69:50010 (dbj69)

说明hadoop已经感知到了新加入的节点dbj69。

注意：如果不将dbj69的配置加入到topology.data中，执行sbin/hadoop-daemons.sh start datanode启动数据节点dbj69，datanode日志中会有异常发生，导致dbj69启动不成功。

2016-07-17 10:51:33,502 FATAL org.apache.hadoop.hdfs.server.datanode.DataNode: Initialization failed for block pool Block pool BP-1732631201-192.168.147.68-1385000665316 (storage id DS-878525145-192.168.147.69-50010-1385002292231) service to dbj68/192.168.147.68:9000

org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.net.NetworkTopology$InvalidTopologyException): Invalid network topology. You cannot have a rack and a non-rack node at the same level of the network topology.

at org.apache.hadoop.net.NetworkTopology.add(NetworkTopology.java:382)

at org.apache.hadoop.hdfs.server.blockmanagement.DatanodeManager.registerDatanode(DatanodeManager.java:746)

at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.registerDatanode(FSNamesystem.java:3498)

at org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.registerDatanode(NameNodeRpcServer.java:876)

at org.apache.hadoop.hdfs.protocolPB.DatanodeProtocolServerSideTranslatorPB.registerDatanode(DatanodeProtocolServerSideTranslatorPB.java:91)

at org.apache.hadoop.hdfs.protocol.proto.DatanodeProtocolProtos$DatanodeProtocolService$2.callBlockingMethod(DatanodeProtocolProtos.java:20018)

at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:453)

at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:1002)

at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1701)

at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1697)

at java.security.AccessController.doPrivileged(Native Method)

at javax.security.auth.Subject.doAs(Subject.java:415)

at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1408)

at org.apache.hadoop.ipc.Server$Handler.run(Server.java:1695)

 

at org.apache.hadoop.ipc.Client.call(Client.java:1231)

at org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:202)

at $Proxy10.registerDatanode(Unknown Source)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:601)

at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:164)

at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:83)

at $Proxy10.registerDatanode(Unknown Source)

at org.apache.hadoop.hdfs.protocolPB.DatanodeProtocolClientSideTranslatorPB.registerDatanode(DatanodeProtocolClientSideTranslatorPB.java:149)

at org.apache.hadoop.hdfs.server.datanode.BPServiceActor.register(BPServiceActor.java:619)

at org.apache.hadoop.hdfs.server.datanode.BPServiceActor.connectToNNAndHandshake(BPServiceActor.java:221)

at org.apache.hadoop.hdfs.server.datanode.BPServiceActor.run(BPServiceActor.java:660)

at java.lang.Thread.run(Thread.java:722)

 

4.节点间距离计算

有了机架感知，NameNode就可以画出datanode网络拓扑图。D1,R1都是交换机，最底层是datanode。则H1 rackid=/D1/R1/H1，H1的parent是R1，R1的是D1。这些rackid信息可以通过topology.script.file.name配置。有了这些rackid信息就可以计算出任意两台datanode之间的距离，得到最优的存放策略，优化整个集群的网络带宽均衡以及数据最优分配。

 

distance(/D1/R1/H1,/D1/R1/H1)=0 相同的datanode

distance(/D1/R1/H1,/D1/R1/H2)=2 同一rack下的不同datanode

distance(/D1/R1/H1,/D1/R2/H4)=4 同一IDC下的不同datanode

distance(/D1/R1/H1,/D2/R3/H7)=6 不同IDC下的datanode

 

四 , Hadoop Fedaration

为什么要有 Federation 机制呢？

在 Hadoop 2.0 之前，HDFS 的单 NameNode 设计带来很多问题，包括单点故障、内存受限，制约集群扩展性和缺乏隔离机制（不同业务使用同一个 NameNode 导致业务相互影响）等。为了解决这些问题，除了用基于共享存储的 HA 解决方案，我们还可以用 HDFS 的 Federation机制来解决这个问题。

 

什么是 Federation 机制？

HDFS Federation 是指 HDFS 集群可同时存在多个 NameNode。这些 NameNode 分别管理一部分数据，且共享所有 DataNode 的存储资源。

这种设计可解决单 NameNode 存在的以下几个问题：

1、 HDFS 集群扩展性。多个 NameNode 分管一部分目录，使得一个集群可以扩展到更多节

点，不再像 1.0 中那样由于内存的限制制约文件存储数目。

2、 性能更高效。多个 NameNode 管理不同的数据，且同时对外提供服务，将为用户提供

更高的读写吞吐率。

3、 良好的隔离性。用户可根据需要将不同业务数据交由不同 NameNode 管理，这样不同

业务之间影响很小。

 

注意问题：HDFS Federation 并不能解决单点故障问题，也就是说，每个 NameNode 都存在

在单点故障问题，你需要为每个 namenode 部署一个 backup namenode 以应对 NameNode

挂掉对业务产生的影响。