下一代 Hadoop YARN 简介
（1）更快地MapReduce计算
MapReduce仍是当前使用最广泛的计算框架。YARN利用异步模型对MapReduce框架的一些关键逻辑结构（如JobInprogress、TaskInProgress等）进行了重写，相比于MRv1，具有更快地计算速度。当然，YARN具有向后兼容性，用户在MRv1上运行的作业，无需任何修改即可运行在YARN之上。
（2）对多框架支持
与MRv1相比，YARN不再是一个单纯的计算框架，而是一个框架管理器，用户可以将各种各样的计算框架移植到YARN之上，由YARN进行统一管理和资源分配，由于将现有框架移植到YARN之上需要一定的工作量，当前YARN仅可运行MapReduce这种离线计算框架。
我们知道，不存在一种统一的计算框架适合所有应用场景，也就是说，如果你想设计一种计算框架，可以高效地进行离线计算、在线计算、流式计算、内存计算等，是不可能的。既然没有全能的计算框架，为什么不开发一个容纳和管理各种计算框架的框架管理平台（实际上是资源管理平台）呢，而YARN正是干这件事情的东西。
YANR本质上是一个资源统一管理系统，这一点与几年前的mesos（http://www.mesosproject.org/），更早的Torque（http://www.adaptivecomputing.com/products/open-source/torque/）基本一致。将各种框架运行在YARN之上，可以实现框架的资源统一管理和分配，使他们共享一个集群，而不是“一个框架一个集群”，这可大大降低运维成本和硬件成本。
如果你还没有意识到当前已经进入多计算框架纵横捭阖的新时代，那让我来给你细数一下当前出现的，已小有名气的计算框架吧：
1）MapReduce:这个框架人人皆知，它是一种离线计算框架，将一个算法抽象成Map和Reduce两个阶段进行处理，非常适合数据密集型计算。
2）Spark:我们知道，MapReduce计算框架不适合（不是不能做，是不适合，效率太低）迭代计算（常见于machinelearning领域，比如PageRank）和交互式计算（datamining领域，比如SQL查询），MapReduce是一种磁盘计算框架，而Spark则是一种内存计算框架，它将数据尽可能放到内存中以提高迭代应用和交互式应用的计算效率。官方首页：http://spark-project.org/
3）Storm:MapReduce也不适合进行流式计算、实时分析，比如广告点击计算等，而Storm则更擅长这种计算、它在实时性要远远好于MapReduce计算框架。官方首页：http://storm-project.net/
4）S4:Yahoo开发的流式计算框架，与Storm较为类似。官方首页：http://incubator.apache.org/s4/
5）OpenMPI:非常经典的消息处理框架，非常适合高性能计算，现在仍被广泛使用。
6）HAMA:基于BSP（bulk-synchronousparallelmodel）模型的分布式计算框架，与Google的Pregel类似，可用于大规模科学计算，如矩阵，图算法，网络算法等，官方首页：http://hama.apache.org/。
7）ClouderaImpala/ApacheDrill:基于Hadoop的更快的SQL查询引擎（比Hive快得多），GoogleDremel的模仿者。ClouderaImpala官方首页：https://github.com/cloudera/impala，ApacheDrill官方首页：http://incubator.apache.org/drill/
8）Giraph：图算法处理框架，采用BSP模型，可用于计算pagerank，sharedconnections,personalization-basedpopularity等迭代类算法。官方首页：http://giraph.apache.org/
上面很多框架正在或正准备往YARN上迁移，具体见：http://wiki.apache.org/hadoop/PoweredByYarn/
（3）框架升级更容易
在YARN中，各种计算框架不再是作为一个服务部署到集群的各个节点上（比如MapReduce框架，不再需要部署JobTracler、TaskTracker等服务），而是被封装成一个用户程序库（lib）存放在客户端，当需要对计算框架进行升级时，只需升级用户程序库即可，多么容易！
总结
YARN是在Hadoop1.0基础上衍化而来的，它具有比Hadoop1.0更为先进的理念和思想，它充分吸取了Hadoop1.0的优势，但同时增加了很多新的特性和改进点。即使你不使用YARN，研究YARN对于改进你们当前Hadoop版本仍有巨大的帮助。
需要说明的是，由于YARN是一个崭新的系统，它完全不同于Hadoop1.0。对于一般公司而言，将旧Hadoop系统往YARN上移植将是一件十分困难的事情，因为不同公司对YARN进行了或多或少的改造，这些改造或许已经不再兼容于主流的Hadoop版本。当向YARN升级时，你需要对兼容性进行充分的测试，以确保当前运行的作业仍可以正常地运行在移植后的系统上。另外，需要引起注意的是，YARN会给运维人员带来巨大的麻烦，毕竟它是一个新系统。
当然，当前YARN还不成熟，仍处于高速酝酿阶段，讨论如何在线上使用它仍为时过早。不过，开始研究和学习它，作为一名有进取心和前瞻眼光的hadoopor，仍是十分必要的。
杂谈分布式计算
在Hadoop、S4、Strom如此火的今天，不关注下分布式计算还真有点out了。分布式计算，一般来说会非常两大类：离线计算和在线实时计算。离线计算的理论基础是MapReduce模型，典型开源代表就是hadoop了。在线实时计算方面这两年开始成为关注的重点，目前相对比较成熟的有雅虎的s4和twitter的storm。
在分布式计算框架方面，目前开源中做的比较好的是facebook和twitter，其中可以重点关注下facebook的这篇文章Real-timeAnalyticsatFacebook。通过这里也可以看出一个比较好的分布式计算框架有三个部分：分布式日志采集系统、离线计算框架、在线实时计算框架。本文也从三个方面来谈。
分布式日志采集方面，目前facebook和twitter都是采用开源的scribe。对于大部分公司来说，直接基于scribe做一些优化基本上能够满足需要了。该系统的基本原理是：在日志采集源的地方部署对应的scribe客户端，然后把日志或者其他数据通过网络传输到scribe服务中转机器上，最后通过相应的agent写入到hdfs离线存储或者直接对应在线计算的输入流。
离线计算框架方面，目前基本上都是基于hadoop，然后在上游加入hive、pig做一些更加人性化或者通用化的工作，基本上能够满足所有的离线计算需求。关于hadoop，推荐入门文章《Hadoop：你不得不了解的大数据工具》。
在实时计算方面，有一些比较折中的做法，比如说facebook的ptail、puma等等。也有一些比较系统化的方案，比如twitter的storm、雅虎的s4等等。storm资料方面，推荐中文翻译的wiki库、TwitterStorm实时数据处理框架分析总结、淘宝的一些文章（据说目前淘宝已经在生产环境使用）。关于s4方面，感兴趣的可以看看Yahoo!S4分布式流处理引擎分析总结、Yahoo!s4和Twitterstorm的粗略比较
目前总体来说，最有挑战最不成熟也最有需求的还是在线实时计算方面。
http://dongxicheng.org/mapreduce-nextgen/resourcemanager-code-details/
http://dongxicheng.org/mapreduce-nextgen/rethinking-hadoop-from-problems-solved/
http://dongxicheng.org/mapreduce-nextgen/use-hadoop-yarn-to-build-a-cloud-system/
http://dongxicheng.org/mapreduce-nextgen/mesos_vs_yarn/
Impala
Impala入门笔记:http://tech.uc.cn/?p=817
Impala/Hive现状分析与前景展望:http://yanbohappy.sinaapp.com/?p=220;
大数据提速：Impala能否取代Hive:http://developer.51cto.com/art/201211/364219.htm
浅谈SQLonHadoop系统:http://www.weibo.com/cloudv8?is_ori=1
项目地址：https://github.com/cloudera/impala
hawq
左手Hive右手Impala:
http://cloud.chinabyte.com/news/99/12558599.shtml
hbase
http://www.searchtb.com/2011/01/understanding-hbase.html
hbase0.95最新官版hbase0.95最新官版
http://abloz.com/2012/05/30/hbase-0-95-chinese-version-of-the-official-document.html;
hive
http://blog.didu.me/article/518
http://wenku.baidu.com/view/28609b80bceb19e8b8f6bab8.html
http://m.oschina.net/blog/81771