【IT168 专稿】新一代Hadoop之所以引发广泛关注，不仅是因为它将带动更多以其为核心、令人振奋的新型应用程序，还由于它允许创造出一些原本无法实现的数据处理方式——上一代Hadoop由于早期架构方面的限制而束缚了思维。总而言之，Hadoop 2.0的发布是件大好事。
那么长久以来是什么制约着Hadoop的实际表现?更重要的是，时至今日情况到底有没有好转呢?
针对Hadoop的大部分批评之声都指向其规模限制，但在规模方面的最大制约因素在于其工作处理能力。Hadoop中的所有工作都通过一个名为JobTracker的后台程序进行批量处理，这就导致其可扩展性与处理速度遭遇严重瓶颈。
在Hadoop 2.0当中，JobTracker机制已经成为历史。相反，Hadoop利用一种全新工作处理框架解决了问题。该框架中包含两种后台程序：ResourceManager，负责管理系统中的所有工作，以及NodeManager，运行在每一个Hadoop节点当中并向ResourceManager持续提供与节点运行有关的信息。(每一款处于运行状态下的应用程序也拥有自己的管理程序，即ApplicationMaster。)
这种设定与此前的MapReduce完全不同，Apache为它取了个全新的名称：YARN，也就是“另一种资源协调者（Yet Another Resource Negotiator）”的缩写。新的MapReduce将作为其可选组件之一加以运行。事实上，Apache宣布任何一款分布式应用程序都可以运行在YARN之上，只是需要进行一点移植工作。为此，Apache推出了一份YARN兼容应用列表，其罗列方式与社交图谱分析系统Apache Giraph(也就是Facebook所使用的方案)颇为相似。其它各方的测试结果也即将出炉。
这种方案相当激进，因此Apache明智地决定要坚决保证其向下兼容性;所以MapReduce 2仍然与前代项目采取同样的API。现有工作只要经过重新编译即可正常执行。
另一种很难用巧合来解释的情况是，YARN的出现让Hadoop具备了远超过以往的跨Apache项目兼容性，从而使大数据的跨项目传递成为现实。只要选择了某一个项目，就不必再担心与其它项目存在冲突。Hadoop这位迅猛崛起的时代宠儿很可能带动其它Apache兄弟一同腾飞。
而此次升级带来的最大意义在于，如今MapReduce本身已经成为通过Hadoop进行数据发掘的众多可能途径之一。Apache自家推出的Spark就是另一套可以通过移植与YARN兼容的方案，且很可能在处理某些任务时带来比MapReduce更出色的表现。总之，Hadoop 2.0允许在选择最适合的引擎时拥有理想的灵活性。
作为Hadoop两大厂商，Cloudera与Hortonworks双双对YARN的重要意义进行了讨论——虽然二者当初涉足Hadoop的路线完全不同。Cloudera的Impala为我们带来运行低延迟SQL查询(指向HDFS存储数据)的能力，这使其更适合处理实时分析工作;Hortonworks则选择了Apache自家的Hive技术，更适合负责数据仓库操作(例如长时间运行且需面对大量接入型操作的查询)。
将应用程序向YARN移植并不是件容易的事，而且这种付出所能换回的具体回报要看这套新框架能够看其部署情况。不过就目前来看，Cloudera与Hortonworks双方都坚定地站在Hadoop 2.0一边，而且并没有分心打造其它产品——或者继续坚守其早期迭代方案。这已经证明了Hadoop 2.0的光明未来绝非镜花水月，YARN的广泛普及也只是时间问题。
