数据密集型计算-技术、概念及动向

 

Google将放弃MapReduce 新索引系统将迁移至BigTable

http://developer.51cto.com/art/201009/226451.htm

 

 

 

海量数据处理算法

http://blog.sina.com.cn/s/blog_4010e7d80100l5j8.html

 

 

海量数据面试题整理

 

http://dotnet.cnblogs.com/page/68772/

 

http://blog.csdn.net/v_july_v/article/details/6685962

 

 

数据密集型计算编程模型研究进展 不需要关心应用程序在大规模集群上运行的细节(如数据分布、调度任务和处理容错等) 编程模型对开发人员隐藏这些细节,有助于应用程序清晰地表达对数据的处理过程,代码更容易理解、重用和维护,从而最大程度地减轻了开发人员编程的负担.

 

运行时系统处理

了很多底层细节,例如负载平衡、计算的本地化、对

机器故障的容错等

数据中心的网络带宽是稀缺资源, 移动代价很小的计算而不

是移动代价昂贵的数据

 

 

计算模型上的限制.MapReduce的计算模型

可以表示为:Input→Map→Shuffle→Sort→Reduce

→Output,单输入,单输出,限制性比较强,与支持

多输入、多输出的Dryad相比,模型的灵活性差.开

发人员必须将其问题映射到键值对上才能实现数据

的并行处理,有些问题这种映射既不容易也不自然,

键值对的含义并不清晰.

对于某些问题,MapReduce的抽象层次还是

比较低.例如,要进行数据库表中的Join,Projection

和Filter等标准操作,开发人员需要自己去实现,而

且实现起来还需要一定的技巧,这导致代码难以理

解、重用和维护.

对于某些应用,需要将几个MapReduce作业

连接起来.这会带来很多的问题,由于每个MapReduce

作业都是自包含,第1个阶段的Reduce操作和第2

阶段的Map操作之间无法进行执行优化.不同阶段

的MapReduce程序之间缺乏类型支持,开发人员必

须显式地处理不同阶段数据的类型,导致代码难以

维护和重用.

从编程抽象的角度看,基于DAG的Dryad比

基于键值对的MapReduce更通用、更灵活.此外,

Dryad可以在程序运行时通过动态地修改DAG来

提高性能

 

面向特定领域的编程模型.编程模型都有其

适用领域和范围,不存在能解决所有数据密集型应

用的通用编程模型.编程模型通常先从特定的应用

领域中提炼出一种编程抽象,可以方便地表达计算,

然后开发相应的编程系统来实现这种编程抽象.