对于简单的O(n)复杂度查询,是否有比Hadoop更好的解决方案?

时间:2013-10-04 10:00:09

标签: hadoop

我需要创建一个系统,需要获取数TB的数字数据并回答三个问题:1。Min,2。Max,3。总计数

一位朋友建议Hadoop使用map-reduce,其中reduce步骤总是对数据进行排序。这导致O(nlogn)的复杂性,即使对于O(n)查询,例如最小值,最大值和总计数。

我一直在网上搜索;但是,我一直无法找到答案。有人可以帮忙吗?我是这个领域的新手,所以请忍受我缺乏知识。

谢谢!

2 个答案:

答案 0 :(得分:2)

Hadoop不会改变任何东西的渐近复杂性。它只是关于减少大O忽略的常数因素。

将分布式计算的结果放在一起总会有一些开销。但是,如果遇到三个问题,使用组合器会将最终排序减少到O(1)。我不知道当只有一个键时,每个地图主机上发生的局部排序的复杂性是什么,以便为组合器分组。在这种情况下,它可能比O(n lg n)更好。

答案 1 :(得分:2)

我在实践中没有尝试过这个,但我相信你可以通过为你的工作定义一个自定义排序和分组比较器来有效地禁用排序。您希望使用排序比较器,该比较器表示所有键都相同,以便进行排序。我相信这将使所有种类至少做尽可能少的工作 - 一次通过。您希望保留默认分区程序和分组比较器,因此仍然以相同的方式分配工作,并且相同的值使用相同的键。

我不知道这是否会使它成为O(n),因为内部还有很多其他内容,比如合并。

而且,大O是速度的一个非常粗略的衡量标准。像高效的可写和合并器这样的东西会比这些问题产生更大的不同。

当然,我可能不会建议您为此类工作构建自定义MapReduce作业。这是Hive可以为您解决的问题,虽然它只是委托给MapReduce作业,并且比您在开始时考虑的简单MapReduce要慢。

像Impala这样的实时工具可以更快,更快地回答这些类型的查询。他们不使用MapReduce,而是在Hadoop上运行。如果你真的想这样做,我强烈建议你朝那个方向努力。