Hadoop入门(二)

最新推荐文章于 2024-04-22 23:16:36 发布

QuietHRH

最新推荐文章于 2024-04-22 23:16:36 发布

阅读量193

点赞数

分类专栏： Hadoop 文章标签： hadoop big data

本文链接：https://blog.csdn.net/QuietHRH/article/details/84503967

版权

Hadoop 专栏收录该内容

18 篇文章 0 订阅

订阅专栏

Hadoop Archives

HDFS 并不擅长存储小文件，因为每个文件最少一个 block，每个 block 的元数据都会在 NameNode 占用内存，如果存在大量的小文件，它们会吃掉NameNode 节点的大量内存。

Hadoop Archives 可以有效的处理以上问题，它可以把多个文件归档成为一个文件，归档成一个文件后还可以透明的访问每一个文件。类似压缩

shell命令

创建档案

hadoop archive -archiveName test.har –p /input /outputdir

将input目录下的文件打包为test.jar到outputdir目录下

查看档案

hadoop fs -ls /outputdir/test.har
har文件包含两个索引文件多个part文件以及一个表示成功的文件
part文件是原来多个文件的集合

查看档案中原来的文件

hadoop fs -ls har:///outputdir/test.har

解压档案

hadoop fs -cp har:///outputdir/test.har hdfs:/newpath
hadoop distcp har:///outputdir/test.har hdfs:/newpath

注意事项

Hadoop archives 是特殊的档案格式。一个 Hadoop archive 对应一个文件系统目录。
创建 archives 本质是运行一个 Map/Reduce 任务
创建 archive 文件要消耗和原文件一样多的硬盘空间
archive 文件不支持压缩，尽管 archive 文件看起来像已经被压缩过
archive 文件一旦创建就无法改变，要修改的话，需要创建新的archive 文件。
当创建 archive 时，源文件不会被更改或删除
虽然 HAR 文件可以作为 MR 的输入，但是由于 InputFormat 类并不知道文件已经存档，所以即使在 HAR 文件里处理许多小文件，仍然低效

Hadoop高可用HA

HA(High Available), 高可用，是保证业务连续性的有效解决方案，一般有两个或两个以上的节点，分为活动节点（ Active ）及备用节点（ Standby）当活动节点出现问题，导致正在运行的业务（任务）不能正常运行时，备用节点此时就会侦测到，并立即接续活动节点来执行业务。

Namenode HA

在 Active NN 和 Standby NN 之间要有个共享的存储日志的地方，Active NN把 edit Log 写到这个共享的存储日志的地方，Standby NN 去读取日志然后执行，这样 Active 和 Standby NN 内存中的 HDFS 元数据保持着同步。一旦发生主从切换 Standby NN 可以尽快接管 Active NN 的工作。

Clouera 提出的 QJM/Qurom Journal Manager, 这是一个基于 Paxos 算法（分布式一致性算法）实现的 HDFS HA 方案

基本原理就是用 2N+1 台 JournalNode 存储 EditLog，每次写数据操作有>=N+1 返回成功时即认为该次写成功，数据不会丢失了。

任何修改操作在 Active NN 上执行时，JournalNode 进程同时也会记录修改 log到至少半数以上的 JN 中，这时 Standby NN 监测到 JN 里面的同步 log 发生变化了会读取 JN 里面的修改 log，然后同步到自己的目录镜像树里面

当发生故障时，Active 的 NN 挂掉后，Standby NN 会在它成为 Active NN 前，读取所有的 JN 里面的修改日志，这样就能高可靠的保证与挂掉的 NN 的目录镜像树一致，然后无缝的接替它的职责，维护来自客户端请求，从而达到一个高可用的目的

每个 NN 改变状态的时候，向 DN 发送自己的状态和一个序列号。DN 在运行过程中维护此序列号，当 failover 时，新的 NN 在返回 DN 心跳时会返回自己的 active 状态和一个更大的序列号。DN 接收到这个返回则认为该 NN 为新的 active。如果这时原来的 active NN 恢复，返回给 DN 的心跳信息包含 active 状态和原来的序列号，这时 DN 就会拒绝这个 NN 的命令。

FailoverController

HealthMonitor: 监控 NameNode 是否处于 unavailable 或 unhealthy 状态。当前通过RPC 调用 NN 相应的方法完成。
ActiveStandbyElector: 监控 NN 在 ZK 中的状态。
ZKFailoverController: 订阅 HealthMonitor 和 ActiveStandbyElector 的事件，并管理 NN 的状态,另外 zkfc 还负责解决 fencing（也就是脑裂问题）。

ZKFailoverController 主要职责：

健康监测：周期性的向它监控的 NN 发送健康探测命令，从而来确定某个 NameNode是否处于健康状态，如果机器宕机，心跳失败，那么 zkfc 就会标记它处于一个不健康的状态
会话管理：如果 NN 是健康的，zkfc 就会在 zookeeper 中保持一个打开的会话，如果 NameNode 同时还是 Active 状态的，那么 zkfc 还会在 Zookeeper 中占有一个类型为短暂类型的 znode，当这个 NN 挂掉时，这个 znode 将会被删除，然后备用的NN 将会得到这把锁，升级为主 NN，同时标记状态为 Active
当宕机的 NN 新启动时，它会再次注册 zookeper，发现已经有 znode 锁了，便会自动变为 Standby 状态，如此往复循环，保证高可靠，需要注意，目前仅仅支持最多配置 2 个 NN
master 选举：通过在 zookeeper 中维持一个短暂类型的 znode，来实现抢占式的锁机制，从而判断那个 NameNode 为 Active 状态

配置文件
<configuration>
<property>
<name>fs.defaultFS</name>
<value>hdfs://cluster1</value>
</property>
<property>
<name>hadoop.tmp.dir</name>
<value>/export/data/hdha</value>
</property>
<property>
<name>ha.zookeeper.quorum</name>
<value>node-1:2181,node-2:2181,node-3:2181</value>
</property>
</configuration>
<configuration>
<property>
<name>dfs.nameservices</name>
<value>cluster1</value>
</property>

<property>
<name>dfs.ha.namenodes.cluster1</name>
<value>nn1,nn2</value>
</property>

<property>
<name>dfs.namenode.rpc-address.cluster1.nn1</name>
<value>node-1:9000</value>
</property>

<property>
<name>dfs.namenode.http-address.cluster1.nn1</name>
<value>node-1:50070</value>
</property>

<property>
<name>dfs.namenode.rpc-address.cluster1.nn2</name>
<value>node-2:9000</value>
</property>

<property>
<name>dfs.namenode.http-address.cluster1.nn2</name>
<value>node-2:50070</value>
</property>

<property>
<name>dfs.namenode.shared.edits.dir</name>
<value>qjournal://node-1:8485;node-2:8485;node-3:8485/cluster1</value>
</property>

<property>
<name>dfs.journalnode.edits.dir</name>
<value>/export/data/journaldata</value>
</property>

<property>
<name>dfs.ha.automatic-failover.enabled</name>
<value>true</value>
</property>

<property>
<name>dfs.client.failover.proxy.provider.cluster1</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
</property>

<property>
<name>dfs.ha.fencing.methods</name>
<value>sshfence</value>
</property>

<property>
<name>dfs.ha.fencing.ssh.private-key-files</name>
<value>/root/.ssh/id_rsa</value>
</property>

<property>
<name>dfs.ha.fencing.ssh.connect-timeout</name>
<value>30000</value>
</property>
</configuration>
Yarn HA

从 Hadoop 2.4.0版本开始，Yarn 实现了 ResourceManager HA，ResourceManager（简写为 RM）作为 Yarn 系统中的主控节点，负责整个系统的资源管理和调度，内部维护了各个应用程序的 ApplictionMaster 信息、NodeManager（简写为 NM）信息、资源使用等。由于资源使用情况和 NodeManager 信息都可以通过 NodeManager 的心跳机制重新构建出来，因此只需要对 ApplicationMaster 相关的信息进行持久化存储即可。

手动切换：在自动恢复不可用时，管理员可用手动切换状态，或是从 Active 到 Standby,或是从 Standby 到 Active。

自动切换：基于 Zookeeper，但是区别于 HDFS 的 HA，2 个节点间无需配置额外的 ZFKC守护进程来同步数据。

<property>
<name>yarn.resourcemanager.ha.enabled</name>
<value>true</value>
</property>

<property>
<name>yarn.resourcemanager.cluster-id</name>
<value>yrc</value>
</property>

<property>
<name>yarn.resourcemanager.ha.rm-ids</name>
<value>rm1,rm2</value>
</property>

<property>
<name>yarn.resourcemanager.hostname.rm1</name>
<value>node-1</value>
</property>
<property>
<name>yarn.resourcemanager.hostname.rm2</name>
<value>node-2</value>
</property>

<property>
<name>yarn.resourcemanager.zk-address</name>
<value>node-1:2181,node-2:2181,node-3:2181</value>
</property>
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>

Hadoop Federation

当集群大到一定程度后，NameNode 进程使用的内存可能会达到上百 G，NameNode 成为了性能的瓶颈。因而提出了 namenode 水平扩展方案-- Federation。

Federation 中文意思为联邦,联盟，是 NameNode 的 Federation,也就是会有多个NameNode。多个 NameNode 的情况意味着有多个 namespace(命名空间)

原理: NN-1 和 NN-K 是不同的NM, 各自管理各自的内存, 各自的文件目录树, 但是共用DN

Federation 意味着在集群中将会有多个 namenode/namespace。这些 namenode 之间是联合的，也就是说，他们之间相互独立且不需要互相协调，各自分工，管理自己的区域。分布式的 datanode 被用作通用的数据块存储存储设备。每个 datanode 要向集群中所有的namenode 注册，且周期性地向所有 namenode 发送心跳和块报告，并执行来自所有 namenode的命令。

多个 NN 共用一个集群里的存储资源，每个 NN 都可以单独对外提供服务。
每个 NN 都会定义一个存储池，有单独的 id，每个 DN 都为所有存储池提供存储。
DN 会按照存储池 id 向其对应的 NN 汇报块信息，同时，DN 会向所有 NN 汇报本地存储可用资源情况。

在这里插入图片描述