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扩展性

通过增加在集群中的namenode数量来扩展namespace有利于大量的调度任务或者调度大量的小文件，namenode可以水平扩展

增加集群中的namenode水平扩展集群，同样有利于大量的调度任务或者调度大量的小文件

性能

为集群增加namenode增加了文件系统的读写操作的吞吐量。Namenode支持的并发及吞吐量理论上随着namenode数量的增加呈线性增长。

为集群增加namenode增加了文件系统的读写操作的吞吐量。Namenode支持的并发及吞吐量理论上随着namenode数量的增加呈线性增长。

Namespace

独立。Federation  namenode采用多namespace的结构，每个namenode（或者每一组active-standby）是独立的命名空间，每个namespace对应一个块池，共享DataNode

非独立。采用统一命名空间

隔离性

由于Federation namenode中每一个namespace是独立的，那么可以很好的做到不同namespace之间的数据隔离。不同用户，甚至不同应用可以完全数据隔离

采用统一命名空间，无法通过namespace做到数据隔离

NameNode故障在namenode集群中的影响

单个Namespace下的namenode发生故障不会对其他namespace的服务产生影响

Namenode故障不会对整个集群造成影响

单个Namespace下NameNode单点问题

对于单个Namespace 中namenode故障会影响此Namespace的对外服务，即使使用NameNode  HA技术也无法保证完全高可用。如果应用仅使用单个Namespace服务， NameNode单点问题导致其管理的文件不可访问，同样会导致应用中断。

可以做到完全高可用

负载均衡

在负载均衡上，Federation更多的需要人工介入去控制多个Namespace之间的均衡

自动均衡

扩展对Client造成的影响

对于Client使用多Namespace的应用，在NameNode进行扩展的时候，相应的应用也必须跟随NameNode的扩展而发生改动，在使用上比较繁琐，至于会不会中断应用，需要看应用本身部署方案是不是高可用的

扩展NameNode数量从理论上来讲不会对Client端的应用造成影响，只需底层扩展，不需要修改Client应用

业界方案

已在当前开源版本中提供Federation NameNode扩展功能

MapR  Hadoop，未开源

使用

FaceBook、雅虎等（Federation由雅虎提供）

MapR  公司，商用，宣称支持1万亿级文件量

适用场景

更多的适用于不同应用数据隔离，不同用户的数据隔离等场景，单应用使用须由客户端控制写入的Namespace，根据services名区分。单namespace（32G）大概支持1.2亿文件量，非确定数据。

不做数据隔离，适合于海量文件存储等。

 

三、MapR设计实现

 

MapR整体结构中除去客户端、Zookeepr集群以外，主要有两种角色，分别是cldb和fileserver，其中的进程分别为CLDB进程和WardenMain进程。

   2、MapR中各组件介绍：

Container：MapR 中Container相当于HDFS中的NameNode，是元数据的最小分块，它维护集群中的一部分元数据，与NameNode不同之处在 于，Container不仅维护File MetaData，还维护Block映射。其中不同类型的Container的作用也是不相同的。一个FileServer可能有许许多多的 Container。

CLDB：Container Location DataBase。CLDB进程保存了由FileServer汇报上来的Container到节点node地址的映射，以及每个Container的 Summary信息，比如该Container所维护的文件数量、文件总大小等信息。CLDB的高可用是主从实现的，CLDB并非是完全高可用，失效时需 要由Slave       CLDB代替Master CLDB继续工作，由于客户端缓存的问题，在客户端已初始化完成的情况，CLDB的短暂切换不会影响到整个集群的可用性，当然此时新创建客户端是会失败 的。MapR中引入了Volume的概念，RootDir（“/”）为默认的Volume，可以在RootDir甚至是RootDir下面不同层级的目录 下创建Volume，每一个Container必然是属于其中的一个Volume。CLDB中还维护了Volume到Container的映射信 息，Volume到Container的映射信息不是Volume到这个Volume下所有Container的信息，而是存在一个Volume到 Root Container（Container类型为S）的映射信息。

FileServer：FileServer启动加载元数据信息，一个FileServer存有很多不 同的Container，每一个Container有全局唯一的编号，为全局自增的ID，加载元数据是分别加载每一个Container保存的元数据。 FileServer负责将所有Container Summary信息汇报给CLDB，FileServer维护了ContainerID到磁盘的映射关系，从实现上来分析，一个Container对应一 块磁盘，（而不会是一个Container对应多个磁盘），一个磁盘可以由多个Container，这样实现的好处在于，文件的真实数据随整个 Container的移动而移动，单个Container移动的时候不会影响其他磁盘，初步分析。FileServer包含的Container有两种类 型，分别是Super和Common，Super类型的Container维护该Volume下面的所有元数据信息，同时维护文件大小小于64K的块信 息，Common Container维护文件大小大于64K的文件的块信息，在设计上一个文件的多个块的元数据信息必然不会由同一个Container维护。

3、元数据和Block的组织方式

Container 是MapR中存储元数据的最小组件，分有两种类型，分别是S和C，两种类型的Container的功能不相同。S类型的Container包含了当前 Volume下所有文件元数据信息，这个元数据信息和NameNode中的元数据类似，包含目录树相关的信息和文件Block到Container的映射 信息，与NameNode不同之处在于，S类型的Container同时还保存文件大小小于64K的文件的Block详细信息，这个详细信息包含这个 Block到磁盘中数据的映射。C类型的Container保存的信息文件大小大于64K的文件的Block详细信息。

64K作为将Block详细信息保存在不同类型Container的映射中是有一定意义的，对于小于64K的文件，客户端直接与根据Volume映射找出的FileServer通信，返回文件的数据，比HDFS中通信次数少，而对于大于64K的文件，则需要多次通信。

MapR 与HDFS在元数据和Block的组织方式的区别在于，MapR将NameNode与DataNode基本上融合在了一起作为一个服务进程，减少了 DataNode向NameNode汇报Block的信息量，同时MapR将元数据Container分散于所有节点，增加Volume也可以增加类似于 NameNode的S类型Container，具备强大的横向扩展能力。

   4、客户端访问

       1、read

           读取一个文件有如下过程：

a、     从CLDB拉取到Volume和S Container的映射信息和Container到节点的映射信息；

b、     根据文件路径找到对应的Volume；

c、     根据Volume找到S Container及其对应node；

d、     根据node信息与FileServer通信，取回文件元数据或者文件内容；

Client 在第一获取到Container Location信息和Volume Map信息后，会将这些信息缓存在客户端，后续的读取操作Fetch Container不需要从CLDB获取这些信息，Client与FileServer通信后，同时也会将该文件的元数据信息缓存在客户端，Client 第二次读取该文件的时候不要重新获取元数据信息，Client与FileServer的通信也会将与该文件相同目录下的文件元数据缓存在客户 端，Client读取该目录下文件相当于对同一个文件进行二次读。

        2、write

           写入一个文件有如下过程：

a、     从CLDB拉取到Volume和S Container的映射信息和Container到节点的映射信息；

b、     根据文件路径找到对应的Volume；

c、     根据Volume找到S Container及其对应node；

d、     根据node信息与FileServer通信，请求分配Block，如果是小于64K的文件，即客户端一次发送即可完成文件写入，Block信息存 入S Container中；如果文件大小大于64K，则有FileServer分配块到C Container中，S Container保存了Block到CContainer的映射；

e、     Client将数据写入到FileServer中；

Client 在第一获取到Container Location信息和Volume Map信息后，会将这些信息缓存在客户端，后续的读取操作Fetch Container不需要从CLDB获取这些信息，Client与其中一个FileServer通信有FileServer在S Container中创建元数据并分配Block，包含这个Block存储的Container，这个Container可能是S类型的，可能是C类型 的，根据文件大小区分。

MapR的互为冗余的多个Container都是可写的，那么用户写的时候就有可能操作两个或者多个Container，这里就涉及到处理分布式事务的问题。