MapR设计分析

一、简介

    MapR 的设计初衷是提供99.999%高可用性的Hadoop解决方案，其中包括支持滚动升级，自我修复和自动故障转移。

    MapR 无 NameNode的HA架构避免了系统内部的单点故障，并且确保集群可以没有瓶颈的扩展。JobTracker的HA功能使得JobTracker故障不 必等待JobTracker的重启才能执行MapReduce任务，而且还能保证正在运行的Job继续执行，而不需要重新提交Job。

     目前社区版本中的Hadoop都存在单点故障，虽然社区有各种各样的解决方案，比如主从架构、Federation架构等，都难以避免类似的问题。

MapR将元数据分散存储于众多节点，同时元数据也是冗余存储于多个不同的节点，那么即使节点失效，也不会导致集群的不可用，数据和元数据都能快速的恢复到配置的备份数量，数据丢失的风险也是微乎其微。

1、NameNode HA

在整体架构上MapR与社区Hadoop的对比：

上图中Active-Standby模式是当下主流的HA方案，并不能完全解决Hadoop的单点问题，Standby节点替换Active的时间间隔可能较长，即使控制在分钟以内，对于处理在线业务也可能是不能容忍的。

MapR 的设计图中很明显的看出，MetaData是分散存储于所有节点，比如A所存储的元数据，分散存储在第一列的三个节点上，这个是将冗余份数设置为3份的情 况。分散存储的好处在于当有节点不可服务的时候，比如某个节点的宕机，存储了元数据备份的另外两个节点可以继续提供服务。元数据以及块的恢复由调度节点控 制。

2、JobTracker HA

MapR的 JobTracker HA改善了JT的恢复时间，并且提供了有自我修复功能的JobTracker集群。在JobTracker失败时，MapR会在其他的节点自动启动一个 JobTracker，TaskTracker自动暂停，然后重现连接到新的JobTracker节点，当前所有正在运行的作业或者任务继续运行而不会失 败或者丢失。

在整体架构上MapR与社区Hadoop的对比：

Hadoop开源发行版，JobTracker只运行在 一个单独的节点（暂不考虑Yarn的解决方案），JobTracker单点故障影响整个集群，如果JobTracker失败，所有正在运行的作业都会失 败，并且是不可恢复的，只能重新提交作业，而且JobTracker失败以后，管理员必须去检测到JobTracker失败了，然后去重新启动 JobTracker。

MapR中JobTracker失败，自动启动一个新的JobTracker，TaskTracker重新连接到新的JobTracker，所有任务和作业继续执行。

二、MapR与Federation对比

1、Federation机制：

为 了水平扩展命名服务的规模，federation 使用多个Namenode和命名空间代替过去的单个Namenode的模式。多个Namenode被联合在一起提供服务，但是每个Namenode又是独 立的，且每个Namenode不需要与其他Namenode协调工作。而Datenode的存储方式还是和过去一样使用块来存储，但每个Datenode 需要注册到集群中所有的Namenode上。Datanode周期性的发布心跳、块操作的报告和从Namenode发送来的操作命令的响应。

2、分布式Namenode：

当前支持分布式NameNode机制的有MapR Hadoop，可动态扩展NameNode数量，支持上万DataNode节点，1万亿文件数量等。

	Federation  NameNode	Distributed  NameNode
NameNode 扩展性