|
MapReduce在处理数据方面的优点有:
第一, 这个模型非常方便使用,即使是对于完全没有分布式程序的程序员也是如此。它隐藏了并行计算的细节,错误容灾,本地优化以及负载均衡。MapReduce运行开发人员使用自己熟悉的语言进行开发,如Java,C#,Python,C++等等。
第二, 对于大型的计算需求使用MapReduce可以非常轻松的完成。
比如说, Google使用MapReduce来提供网页搜索服务,排序,数据挖掘,机器学习,以及其他系统。
第三, 通过MapReduce,应用程序可以在超过1000个节点的大型集群上运行,并且提供经过优化的错误容灾。
不足地方:
1. 不适合事务/单一请求处理
MapReduce绝对是一个离线批处理系统,对于批处理数据应用得很好:MapReduce(不论是Google的还是Hadoop的)是用于处理不适合传统数据库的海量数据的理想技术。但它又不适合事务/单一请求处理。(HBase使用了来自Hadoop核心的HDFS,在其常用操作中并没有使用MapReduce。)
2. 不能随即读取
3. 以蛮力代替索引
在索引是更好的存取机制时,MapReduce将劣势尽显。
4. low-level语言和操作
“直接开始你想要的 -- 而不是展示一个算法,解释如何工作的。” (关系型数据库的观点) -- High level(DBMS)
“展示数据存取的算法。” (Codasyl 的观点) -- Low level(MapReduce)
5. 性能问题
想想N个map实例产生M个输出文件-每个最后由不同的reduce 实例处理, 这些文件写到运行map实例机器的本地硬盘. 如果N是1,000, M是500, map阶段产生500,000个本地文件. 当reduce阶段开始, 500个reduce实例每个需要读入1,000文件,并用类似FTP协议把它要的输入文件从map实例运行的节点上pull取过来. 假如同时有数量级为100的reduce实例运行, 那么2个或2个以上的reduce实例同时访问同一个map节点来获取输入文件是不可避免的-导致大量的硬盘查找, 有效的硬盘运转速度至少降低20%. 这就是为什么并行数据库系统不实现split文件, 采用push(推到socket套接字)而不是pull. 由于MapReduce的出色容错依赖于如何实现split文件, MapReduce框架是否成功地转向使用push范式, 不是很清楚.
6. 仅提供了现代DBMS功能的一小部分
作为用于分布式处理的算法技术,MapReduce不是数据库,不支持索引、数据更新、事务及完整性约束等,且与多数DBMS工具不兼容。
7. 不适合一般web应用
大部分web应用,只是对数据进行简单的访问,每次请求处理所耗费的资源其实非常小,它的问题是高并发,所以要采用负载均衡技术来分担负载。只有当特殊情况下,比如建索引,进行数据分析等,才可能用MR。
本书提到了hadoop的几个方面:海量存储;支持快速数据访问的分布式处理;可靠性,失效转移和可扩展性,我觉得它适合部分场景,不会过时,只是会随着大量使用,不断完善,加入一些更优化的技术。
|
|