浅谈Hadoop的小发展

浅谈Hadoop的小发展

遥想十多年前国内IT圈还不知道什么是Hadoop，现如今，几乎所有的互联网企业都拥有了自己的Hadoop集群，人们提起大数据，就会想起Hadoop，Hadoop俨然成为了大数据时代的代名词。楼主就不再赘述Hadoop啦，今天楼主尽量用大白话带着大家了解它的不足之处以及大佬们是如何改进的。

不足之处

随着计算机硬件的发展，存储介质不再是掣肘大数据发展的因素，大数据越来越火的今天人们对分布式计算的要求也越来越高，很显然Hadoop这项十多年前就起源的技术必须跟着时代潮流向前发展了。那么Hadoop到底有什么不足之处呢？
大家都知道，分布式计算之所以能够引领一个时代是因为它将复杂计算划分开来，在很多台机器上同时处理，故而它处理速度快。但是在新时代人们对事务处理的效率又有了新的需求，Hadoop要等待计算全部结束才能获取结果，那如果中间结果就能够满足用户对精度的要求，Hadoop还是要等全部节点计算结束才能够返回结果，如此这般，不仅响应速度慢，也造成一定的资源浪费。有需求就有进步，大牛们开始想办法了，能不能在一部分计算结束后，先返回一个中间结果给用户呢？

产生中间结果

楼主看来应用最广泛的是2010年Tyson Condie等人提出的HOP（hadoop online prototype）方法。该改进方法的大致思路是利用“snapshot”将Map的结果用管道传输给Reduce，Reduce接收到部分数据并来产生中间结果。这需要用户提交任务后JobTracher就分配好相应的map任务和reduce任务，并将每个map任务的位置发送给reduce。管道的使用方便了map产生的数据发送给reduce，增加了并行机会，提高了利用率，减少了响应时间。在这种情况下，map一旦产生数据，reduce就开始处理，它们可以在执行过程中生成并改善最终结果的近似值。管道这种思路还拓宽了分布式计算可被应用的领域，HOP可以被用于连续查询。HOP解决了产生中间结果的问题，但它也不是完美的，HOP产生的中间结果跟最终结果之间无联系，也就是说算了耗费资源半天的中间结果只是为了看一眼，那么这种浪费是否值得呢？

考虑资源消耗

HOP在中间结果的计算上颇为浪费资源，楼主再介绍一种新的改进方法—2011年N. Pansare等人在PVLDB上发表的文章。这篇文章提出了一个适用于大规模分布式计算的OLA系统模型，它花费更少的代价，并且中间结果可以参与到最终结果计算中去，它的改进主要在两方面。首先它将所有数据结构化成数据块，再随机分配数据块到map中。强调随机两个字，因为计算只涉及到一部分数据块，如果数据不随机，那么中间结果和最终结果的偏差将会很大。Reduce阶段的主要革新是一种叫estimator（评估器）的方法。评估器是该方法种比较重要的一部分，它根据从部分map上传回来的数据计算得到一个中间结果，并估计该结果的可信度。在实际生活中，我们并不能保证数据是随机的，所以这种方法有一定局限性。

后面零零星星出现了很多在产生中间结果上的改进，在这里不一一介绍啦，以上纯属楼主自己的理解，如有错误欢迎大家指正，期待和更多道友一起进步！