原文见: http://hortonworks.com/blog/moving-hadoop-beyond-batch-with-apache-yarn/
Apache Hadoop 2.0继续通过开源社区apache软件基金会下成长, 并从社会发展的角度来看越来越接近于宣布"准备就绪", 一但准备就绪, 我们在Hortonworks的团队将应用我们一惯企业的严谨提供测试和分布式集成, 包含hadoop 2.0 与其它企业关注的服务和合作伙伴的要求.
做为在Hortonworks和apache hadoop开源社区的角色, 我提出了许多关键环节的问题和hadoop 2.0背后的动机. 以下是用于满足你们好奇心的一些想法.
第一代的成功激发第二代 的焦点
在雅虎Hadoop的初期，我们有一个非常特别的目标：存储和处理非常大的数据量，以支持我们的互联网搜索工作。所以第一代的Hadoop是一个专用于大量网页数据处理目的拥抱雅虎的系统, 以及其它精通技术的早期采用者如Facebook .
由于雅虎的使用开始扩大，因此做了提供了一些方法是用户获取想要的存储在hadoop中的数据.就像任何成功的开源项目, hadoop用户通过贡献额外的功能给hadoop社区使hadoop 生态系统越来越广泛. 一些最流行的例子如基于SQL查询的Apache Hive, 基于脚本处理的Apache Pig和 NoSql数据库的HBase.
这些额外的开源项目打开一扇 建立在Hadoop之上更丰富的应用之门. 但他们并没有真正解决在Hadoop中固有的设计限制，特别是，它被设计为一个以MapReduce为核心的单一的应用系统,（即面向批数据的处理）。
我们是否需要SQL ON Hadoop 或 SQL IN Hadoop
快速前进到今天, 我们看到Hadoop的势头一直持续, 并有更多的企业（不只是大规模的网络公司）要把数据存入hadoop, 然后使其用户能通过多种不同的方式: 批处理, 交互，实时分析数据流等, 与数据交互, 而最重要的是，他们希望在做这些时, 不因单一应用或查询占用整个集群资源.
为了阐述这点, 没有什么比SQL on Hadoop更好了. 所有厂商都吵着要提供更好的SQL访问存储在Hadoop中的数据 - 所以他们应该如此, 由于了解SQL的人很多, 因为Apache Hive已经称为与存储在hadoop中数据交互的事实上的SQL接口. 我们发现大多数用户想继续利用Hive以支持这些交互式的SQL用例.
但建立在Hadoop之上的SQL访问，它只是强调Hadoop的挑战是一个单一的应用系统, 当我运行一个SQL查询的数据，它可以消耗掉所有群集资源，并使集群中运行的其他应用程序和作业产生性能问题 -至少可以说不是一个好的结果。
YARN 允许 SQL IN Hadoop 和更多的应用
当我们构建的Hadoop2.0时，我们想从根本上重新设计Hadoop能够运行多种应用程序, 对应相关的数据集。这样多种类型的应用程序运行在同一集群可以预见性的能提高运行的效率 – 这几乎是Apache YARN的原因. 这是Hadoop的2.0的基础。通过在整个集群中管理资源的请求，YARN使得Hadoop从一个单一的应用系统转向多原因系统.
回到SQL ON Hadoop, 因为YARN我们有能力在hadoop上运行SQL. 因为在Hadoop中 (基于YARN编译), 它已经成为平台的一部分, 也可以被YARN管理以确保多种不同的用例可以被处理. 为什么停在SQL？机器学习和建模呢？ 处理刚到达的事件(数据)? 通过一个系统管理所有这些是否更好?
进入 YARN
通过把Apache Hadoop 2.0变成多应用数据系统, YARN使Hadoop社区解决了一个Hadoop的新需求, YARN通过基础层面解决真正需求来回应这些企业级的挑战, 而不是成为商业组件使用户环境更复杂.
这就是Hadoop的2.0的故事：释放YARN的能量。正在向你的集群接近，2013年夏天！敬请关注！