Apache Hadoop 2.9.2 的Federation架构设计

60 阅读 0 评论 40 点赞

我是靠谱客的博主隐形跳跳糖，最近开发中收集的这篇文章主要介绍Apache Hadoop 2.9.2 的Federation架构设计，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

　　　　　　　　　　　　　Apache Hadoop 2.9.2 的Federation架构设计

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　作者：尹正杰

　　能看到这篇文件，说明你对NameNode的工作原理想必已经了如指掌了。也知道他将来会面料的一些弊端，我们知道NameNode在启动时会将镜像文件（fsimage）和编辑日志（edits）从磁盘加载到内存，生成最初的元数据信息后，从而退出安全模式。但是随着数据量越来也多，逐步形成了大数据。根据有关技术报告知道，国内有几家优秀的互联网公司，如百度，腾讯和阿里巴巴等公司数据规模如下：

2013年百度相关技术报告称，百度数据总量接近1000PB，网页的数量大是几千亿个，每年更新几十亿个，每天查询次数几十亿次。
2013年腾讯相关技术报告称，腾讯约有8亿用户，4亿移动用户，总存储数据量经压缩处理以后在100PB左右，日新增200TB到300TB，月增加10%的数据量。　
2013年阿里巴巴相关技术报告称，总体数据量为100PB，每天的活跃数据量已经超过50TB，共有4亿条产品信息和2亿多名注册用户，每天访问超过4000万人次。

　　综上所述，单台NameNode需要记录如上所属的公司数据，那定是相当吃力，而且还是6年前的数据信息，尽管你单台NameNode的内存是256G，依旧是不够用的，我们知道HA模式只是增加了集群的可用性，但是并没有负载均衡的作用，因为HA只能有一台机器可以对外提供写操作。那如何解决这个问题呢？其实官方已经想到了这个问题，相比大家也知道，就是联邦模式（Federation），本文将详细介绍如何部署联邦模式。

一.NameNode架构的局限性

1>.Namespace（名称空间）的限制

　　就像我们上面提到过的，由于NameNode在内存中存储所有的元数据（metadata），因此单个NameNode所能够存储的对象（文件+块）数据受到NameNode所在JVM的heap size的限制。

2>.隔离问题

　　由于HDFS仅有一个NameNode，无法隔离各个程序，因此HDFS上的一个实验程序就很可能影响整个HDFS上运行的程序。

3>.性能的瓶颈

　　由于是单个NameNode的HDFS架构，因此整个HDFS文件系统的吞吐量受限于单个NameNode的吞吐量。

二.HDFS Federation架构设计

　　关于HDFS的联邦模式，官方文档是这样说的：（http://hadoop.apache.org/docs/r2.9.2/hadoop-project-dist/hadoop-hdfs/Federation.html）

In order to scale the name service horizontally, federation uses multiple independent Namenodes/namespaces. The Namenodes are federated; the Namenodes are independent and do not require coordination with each other. The Datanodes are used as common storage for blocks by all the Namenodes. Each Datanode registers with all the Namenodes in the cluster. Datanodes send periodic heartbeats and block reports. They also handle commands from the Namenodes.

　　这段话并不难理解，作为运维的小伙伴应该很容易明白这其实就是负载均衡，把之前只有一个NameNode进行元数据处理的事情现在交给了多个NameNode来处理，每个NameNode的处理的数据并不重复，当然Federation和HA模式并不冲突，为了解决多个联邦模式出现单点故障，因此，建议大家把联邦模式和HA一起部署，让多个NameNode的处理的元数据都不存在单点故障！