MapR浅析

1. 天上掉下个MapR

MapR成立于2009年，但是引起媒体广泛关注是缘由GIGAOM网站2011年3月的一篇报道 《MapR，Cloudera的新对手》（http://gigaom.com/cloud/meet-mapr-a-competitor-to-hadoop-leader-cloudera/），报道这么描述MapR：
“构建一个HDFS的私有替代品，这个替代品比当前的开源版本快三倍，自带快照功能，而且支持无Namenode单点故障（SPOF），并且在API上和兼容，所以可以考虑将其作为替代方案。”
这篇报道随即被InfoQ引用 （http://www.infoq.com/cn/news/2011/03/structure_big_data ），鉴于InfoQ的巨大影响力，一时间，Hadoop技术圈内，人人都在谈论MapR以及其提供的神奇功能，但是，那个时候，MapR网站的主页上对一切只字不提，只有大大的敬请期待字样。
到了5月，确切的说，是5月25号，另一个爆炸性的新闻被披露了。这天，EMC World 2011上，EMC宣布，将在自己推出的Greenplum HD企业版Hadoop中采用MapR的技术。一时间，MapR处于全球技术媒体的聚光灯下，人们不禁要问，MapR到底提供了什么，为什么会被EMC选中作为合作伙伴呢？

 

GreenPlum HD，会跳舞的大象

 

2. Hadoop的阿喀琉斯之踵
Hadoop，大数据处理的宠儿，现今IT媒体聚光灯的焦点，如同希腊神话中的勇士阿喀琉斯一样，有着传奇的出身：Hadoop的主要设计思想，来自两篇著名的Google论文：《MapReduce: SimplifiedData Processing on Large Clusters》http://labs.google.com/papers/mapreduce.html 和《TheGoogle File System》http://labs.google.com/papers/gfs.html。Map-Reduce和GFS可以说是Google搜索引擎的基石，在Google内部被广泛使用，是支撑其每天亿万次搜索的最重要的组成部分，而这两篇论文详细讨论了Map-Reduce以及GFS背后的理论依据，设计权衡以及工程实践。 总之，Hadoop的架构实际上是有Google来背书的。 另一方面，Hadoop的实现也不含糊： 互联网巨人Yahoo敏锐的发现了Hadoop项目的巨大潜力，把Doug Cutting （http://en.wikipedia.org/wiki/Doug_Cutting）吸收为自己的全职员工，并成立了的一个专门的小组来进行Hadoop的开发工作。 现今，作为一个Open Source 项目,  来自全球各地的contributor 正在不停的完善Hadoop，使其变得更加完美。

Hadoop有两个主要的子系统，Hadoop 分布式文件系统HDFS和Hadoop Map/Reduce。HDFS是Hadoop的分布式存储子系统，用户的数据文件，会被切分成64M大小的block（block的大小是可调 的，64M是Google在实践中总结出来的一个优选参数），经过Namenode协调，存放在不同的DataNode上。对于任何一个HDFS文 件，Namenode会在内存中维护两种meta data：1） HDFS文件和block的对应关系 ，2）block在data node上存放的位置。Namenode会在磁盘上保存第一种meta data （通过checkpoint 文件和write ahead log），第二种meta data则是DataNode通过block report 定时发送给NameNode。
上述构架简洁优雅，而且Google在工程实践中也证明了这个构架的可用性和可靠性。但是随着Hadoop被广泛应用，面对各种不同的需求，人们也渐渐的发现了Hadoop的阿喀琉斯之踵。总结下来，主要有以下3大方面：
1) 性能。 一系列测试（比如论文 《A Comparison ofApproaches to Large-Scale Data Analysis》 ，http://database.cs.brown.edu/projects/mapreduce-vs-dbms/ ）发现，Hadoop在性能上可以提高的空间，尤其是和硬件的理论性能比较，还很多。造成这个的原因主要有： 在当前Hadoop的设计中，所有的meta data操作都要通过集中式的Namenode来进行，Namenode有可能是性能的瓶颈；M/R 应用程序需要通过DataNode来访问HDFS, 这就涉及到格外的进程切换和网络传输开销（请参阅著名的HDFS-347，https://issues.apache.org/jira/browse/HDFS-347，题外话，通读关于这个issue的讨论绝对会让你受益匪浅）；还有在M/R 应用程序端的开销也有值得改进的地方（http://developer.yahoo.com/blogs/hadoop/posts/2009/08/the_anatomy_of_hadoop_io_pipel/）。

2) 可扩展性和可靠性的问题可能会严重。当前Hadoop单一Namenode，单一Jobtracker的设计严重制约了整个Hadoop 可扩展性和可靠性。首先，Namenode和Jobtracker是整个系统中明显的单点故障源（SPOF）。再次单一Namenode的内存容量有限，使得Hadoop集群的节点数量被限制到2000个左右，能支持的文件系统大小被限制在10-50PB, 最多能支持的文件数量大约为1.5亿 左右（注，实际数量取决于Namenode的内存大小）。 在集中式的Namenode造成DataNode的blocks report也会对Namenode的性能造成严重的影响。例如系统有1800个Datanode, 每个Datanode有3T存储，整个集群大约有1.8P有效存储（1800*3T/3，假设每个数据块有3份replica）。那么每个Datanode上有大约50000个左右的block （假设block 大小是64M，然后有的block并没有达到64M大小），假设Datanode每小时会发送一次block report， 那么Namenode每两秒会收到一次block report，每个block report包含50000条数据，处理这些数据无疑会占用相当资源。 实际上，有用户抱怨其集群的Namenode重启需要数小时，这大大降低了系统的可用性 （HDFS-273， https://issues.apache.org/jira/browse/HDFS-273）

3) 各种企业特性。随着Hadoop被广泛使用，面对各式各样的需求，人们期望Hadoop能提供更多特性，比如完全可读写的文件系统，snapshot，mirror等等。这些都是当前版本的Hadoop不支持，但是用户又有强烈需求的。

Hadoop的这些缺点也带来了巨大的机会，Cloudera的目光最为敏锐，最早看到这一点。Cloudera的商业模式和一般Open Source创业公司无异：网罗Hadoop的contributor，积极的回馈Hadoop社区，在此基础上发布自己的Hadoop发行版CDH（Cloudera'sDistribution including Apache Hadoop），提供各种增值服务。实际上，CDH版Hadoop具有相当高的知名度。

MapR则认为，Hadoop的这些缺陷来自于其架构设计本身，小修小补不能解决问题。他们选择了一条艰难得多的路： 用新架构重写HDFS，同时在API级别，和目前的Hadoop 发行版保持兼容。这家2009年成立的创业公司，在蛰伏了两年之后，终于一鸣惊人，大放异彩。回顾前面GIGAOM的报道：“构建一个HDFS的私有替代品，这个替代品比当前的开源版本快三倍，自带快照功能，而且支持无Namenode单点故障（SPOF），并且在API上和兼容，所以可以考虑将其作为替代方案。” MapR真的做到了。

 

3. MapR架构初探
2011年6月，在Hadoop 2011峰会上，MapR的创始人M.C. Srivas做了名为《Design, Scale andPerformance of MapR's Distribution for Hadoop》的演讲（http://www.mapr.com/blog/2011/07/the-design-scale-and-performance-of-maprs-distribution-for-apache-hadoop.html），比较详细的介绍了MapR设计原则，部分实现细节以及MapR的性能，外界也第一次从内部了解MapR Hadoop。演讲的录像和PPT随后被公布在Youtube和Slideshare（http://www.slideshare.net/mcsrivas/design-scale-and-performance-of-maprs-distribution-for-hadoop）, 广大无缘参加Hadoop峰会的开发人员也得以有机会来进行研究。
MapR认为，解决Hadoop的种种问题，要采用以下设计思想：
1） 集中式的meta server可扩展性不好，对应的解决方案就是使用分布式的meta server，让每个节点都变成meta server。 但是这里要解决的问题是meta server不能占用太多内存，要留出足够的内存供M/R 应用来使用。
2） 要让每个Datanode上支持的block数量增加，同时减少block-report的大小。
3） 因为内存容量总是有限的，所以要减小查找服务的内存开销。
4） 服务能够快速重启（这样可以更好的实现HA）。
通过上述方式，MapR期望这种设计能极大的提高Hadoop的扩展能力，比如支持的节点数目从当前2000个左右扩展到10000个以上，系统文件容量从10-50PB扩展到1-10EB，文件数量从1.5亿扩展到1万亿（1 trillion）左右。同时，系统还需要支持完全的随机读写以及一系列企业应用特性，比如快照，mirror等等。MapR还期望在性能上有所突破，尽可能的榨取硬件的能力，并能对新的硬件技术（固态硬盘，万兆网卡等）提供支持。
纵观其实现，整个MapR的核心是其分布式NameNode，在MapR的设计中，分布式的NameNode又被称作Container，和Hadoop原始设计中的Namenode不一样的是，Container不仅维护了用户文件的meta data，也维护数据块。每个Container的大小在16GB-32GB之间（这也就意味着一个node上会有很多个container），同一个Container在不同node间有replica。

对于用户来说，Container的概念过于底层，MapR引入了Volume的概念来降低使用用户门槛和提高系统的灵活性。 MapR Volume（http://www.mapr.com/doc/display/MapR/Volumes）的概念和传统存储概念意义上的Volume相当类似，用户不需要直接管理Container，相应的，用户通过管理volumes来管理Container：用户可以为每个Volume指定不同的大小限制，replication level等参数。此外，用户还可以对volume建立snapshot，mirror等。
Container，volume相关的meta data被维护在被称为CLDB中（container locationdatabase，http://www.mapr.com/doc/display/MapR/Glossary#Glossary-containerlocationdatabase）。CLDB是一个集中式的服务，为此，MapR为CLDB设计了 一系列的容错功能，详细参见（http://www.mapr.com/doc/display/MapR/CLDB+Failover）。

采用分布式Namenode的一个必然结果就是要处理大量的分布式事务： 用户有可能同时操作两个Container。 针对这种情况， MapR认为传统的两阶段提交和基于Quarum 的协议（例如Paxos）都有局限性，他们提出了新的解决方案： MapR locklesstransaction。Srivas的讲座并没有过多讨论MapR locklesstransaction的细节，从有限的几张PPT里面，我们还是可以得知一二的：
1） 每个节点都会保存一份WAL。WAL分为两种，OP log和Value log。OP log主要保存对meta data的修改和回滚信息，相应的，Value log主要保存对data block的修改和回滚信息。
2） Log有全局的ID（利用Zookeeper可以很容易的实现这一点），这就使得其可以用来实现分布式事务成为可能。
3） 利用WAL，事务可以快速的回滚（2秒以内）
4） MapRlockless transaction不需要显式的提交（即默认事务会成功执行）
5） Replica会进行监测是否存在冲突，如果有冲突，则回滚事务。如果没有，则confirm事务。
MapR声称这种实现方式有很高的吞吐率，而且事务进行过程中不需要锁， 而且因为WAL的存在，如果事务进行过程中出现程序崩溃也无所谓。实际上，MapR locklesstransaction的实现是仔细分析了MapR 分布式事务的特点以后的一种设计折中： 作为大数据分析平台，Hadoop要处理的数据集并往往是只读或者读多写少（当前版本的Hadoop HDFS实际上是只读的），分布式事务存在冲突的几率比较小，就是说，代价很大的回滚操作执行的几率很小，在这种情况下，放弃开销很大的锁机制是划算的。

除了分布式Namenode这个大亮点之外，MapR还实现了一系列高级特性，对原来Hadoop的功能进行了大幅度的增强。这其中最吸引眼球的有两点：
1） DirectAccess NFS技术。顾名思义，用户可以直接在远程通过NFS 客户端把MapR HDFS装载到其本地，像操作本地文件一样来进行操作。这个特性在Hadoop峰会上引起了广泛关注，讲座结束后相当一部分问题都集中于此。比如，支持符号链接么（答案：支持）？ 支持O_DIRECT访问么（答案：O_DIRECT是相对本地文件系统而言的，对于NFS，O_DIRECT不是太有意义）？ 同时Direct Access NFS支持文件的随机读写（原始Hadoop的文件系统可以被认为是只读的），大大的扩展了MapR Hadoop的应用范围。
2） Snapshot，Mirror等企业应用特性。Snapshot（快照），Mirror（镜像）等企业应用特性是是企业IT管理人员必 不可少的工具，是处理复杂需求的得力助手。通过支持Volume，MapR　Hadoop方便的支持了这些功能，使得Hadoop不再只是开发人员的专 宠，数据科学家，IT管理人员也能够方便的访问Hadoop这个功能强大的大数据分析平台。
以上简要介绍了MapR Hadoop的几个亮点，在如果想对其进一步了解，请访问http://www.slideshare.net/mcsrivas/design-scale-and-performance-of-maprs-distribution-for-hadoop以及http://www.mapr.com/blog/2011/07/the-design-scale-and-performance-of-maprs-distribution-for-apache-hadoop.html

 

4. 群雄逐“象"
经过数年的酝酿，大数据成为人们关注的焦点，各大IT媒体都在讨论什么是大数据，其意味着什么，有哪些应用程序可以处理大数据，如何培养数据科学家等等。在这个潜力无比的新兴市场中，Hadoop无疑已经提前卡位成功。 在Hadoop的基础上，人们纷纷推出了自己的发行版和增值服务，比如Cloudera推出了CDH；IBM则推出了InfoSphere BigInsights；Yahoo更是将原来开发Hadoop的部分独立拆分出来成立了一家新公司Hortonworks，以期望获得更大的竞争优势。

Hortonworks，三象行，必有我师焉

 

相对于舞台上的其他竞争对手，MapR独辟蹊径，利用当前的Hadoop的一些弱点获得了巨大的关注和影响力。展望未来，MapR会如何发展捏？ 我觉得MapR必须有心理准备应付Hadoop的快速发展。Hadoop暴露各种问题已经广为知晓，Hadoop 2.0也在如火如荼的规划和实现中（http://www.oscon.com/oscon2011/public/schedule/detail/19234），在不久的将来，Hadoop将会有剧烈的变化。那么，要保持和新版的Hadoop API兼容的同时还保留自己的种种优点（高性能，高可用性，各种企业特性）是非常有挑战性的工作，MapR的天才们会交出怎样的答案？我们拭目以待。