Hadoop 擅长什么?

来自似乎亚裔博主Ricky ho的一篇文章:What Hadoop is Good At,大意翻译转贴如下:

多线程编程模型允许多个带有不同执行逻辑的处理单元访问共享的数据,为了维护数据的完整性,处理单元需要通过锁或Semaphores机制来协调对共享数据的访问,但是会带来"race condition竞争条件", "deadlocks死锁" 等问题,非常难于调试(banq注:这也是JavaEE的JSP/Servlet封装多线程原因,但是本质上还是多线程,所以JavaEE逃不过多线程的问题。),这使得多线程程序难于编写和难于维护,Java提供了并发包来降低这种难度。

数据驱动编程模型是将数据喂给不同的处理单元(带有相同或不同的执行逻辑). 运行是被数据的到达触发。因为处理只能访问分给它的数据, 因为数据共享天然被禁止了,就因为这样,所以没有必须进行协调数据的访问了,也就没有死锁等问题。

这不意味着一点也不需要数据访问协调,我们认为协调已经完成:定义处理单元是如何通过数据管道彼此连接的。

Map-Reduce编程模型是数据驱动编程模型的一个专门实现,,这种协调图是使用MapReduce工作job顺序完成的,在每个Map/Reduce工作中, 运行被切分成一个"map"段和一个"reduce"段phase. 在map段中, 每个被划分数据被处理,一个或多个结果产生,这些结果都带有一个key. 这个key用于路由输出结果给下第二个"reduce" 段phase, 在那里,带有同样key的数据被收集在一起,然后以一种聚合方式被处理。

注意在Map/Reduce模型中, 并行只有在一个工作job中发生,工作job之间是通过顺序方式实现的,不同的工作jobs 可以访问同样的数据, 必须了解工作job的串行执行可以消除数据之间协调访问的需要。

Hadoop 处理特点:
1. Hadoop是数据并行,处理串行. 在一个工作中job, 并行只在一个map段和一个reduce段中发生. 但是这两个段不能并行运行, reduce段直到map段完全完成后才能开始。

2.所有被map过程访问的数据都必须被冻结 (也不能有修改发生),直至整个工作job完成. 这就意味做Hadoop处理数据是在一个面向批处理batch-oriented风格的链条中实现的,, 这就注定它不适合在基于流stream-based处理的方式,在流处理中,数据流是持续的必须立即得到及时处理。

3.数据之间联系是通过一个分布式文件系统(HDFS)完成. 延迟会因为网络I/O开销发生了,这种延迟不会成为面向批处理模式的主要问题,在面向批处理模式中,吞吐量才是首要考虑的,但是这意味做Hadoop不适合实现对延迟要求很严格,甚至不允许有延迟发生的在线实时系统。

根据Hadoop以上特点,给出下来Hadoop不适合的场合:
1.需要数据低延迟性的在线数据处理,(比如股票系统,更新需要让所有人及时知道,不能有丝毫延迟。)

2.在一个大数据集中执一个小数据集的随机ad/hoc处理。

3.执行实时/基于流的处理模式,数据持续到达需要立即被处理(如视频等)。

感谢作者写了这篇通俗易懂的云计算文章:What Hadoop is Good At

[该贴被banq于2009-11-09 10:21修改过]

Hadoop适用于大数据量分析,应用场景相当有局限性,对一般的公司来说,不免是屠龙技(有网友说过),数据量达不到。

我用三台100多块的机器搭了个环境,实践了下传说中的mapreduce,感觉有些cool,时下mapreduce已经不再是神秘或传说的东西了。

希望能有机会做一些生产环境下的实践。

2009年11月09日 14:01 "chenlinping"的内容
Hadoop适用于大数据量分析,应用场景相当有局限性,对一般的公司来说,不免是屠龙技(有网友说过),数据量达不到。我用三台100多块的机器搭了个环境,实践了下传说中的mapreduce,感觉有些cool,时下mapreduce已经不再是神秘或传说的东西了。希望能有机会做一些生产环境下的实践。

现在这个一般的公司P点数据量 可是偏偏莫名其妙的“屠龙技”。真让我感到费解。

说白点就是适合真的非常大的数据量,并且数据本身是稳定的,查询的结果不要求太快。

三台100多块的机器?
你什么机器?