mapreduce的缺陷
(1)只能做简单的统计计算，很多复杂的算法没法表达
(2)mr的过程中做了很多无效的排序,其他的计算模型获取可以省去这些无效的计算
(3)mr启动任务需要花费时间，对于一些小当量的计算,还不如拉回数据到本地计算
(4)mr在计算过程中会产生中间结果并写入磁盘，多次IO，不能像storm那样，将数据流出去
(5)mr在计算过程中不可迭代，只能临时写磁盘
mapreduce在开发者的角度看来
需要知道计算的复杂度，多次map的考虑
不需要数据的位置，但是要指定数据源，数据的格式
mapreduce对比impala
impala在计算时，需要将表转换成分区，将分区转换成文件，将文件再转换成分区，最后再转换成split,这个粒度已经很小了
也就是说impala关心数据的位置。
mr本质上是不关心数据的位置，但是需要知道数据源，mr中的map负责为整个计算过程产生源数据，这个过程一般都是去读文件，解析文件内容，所以mr对数据源的最小粒度是文件，最后这个reducer再去合并，这个reducer的个数如果很多，并且操作同一个文件，这个就会因reducer太多而产生竞争。
mr不关心数据的位置，这个数据的位置最后是由jobtracker去找到数据的位置来完成。
mapreduce计算的过程产生的疑问
包括提交的过程，这点也是类似storm，将topology的jar提交到nimbus,mr是通过jobclient将mr的程序提交到jobtracker。
只是不知道这个jobtracker管理taskTracker来控制任务的执行，只是使用多少个taskTracker来做，怎么建立这些mapTask和reducerTask之间的通信通道？
storm也有类似的概念，像worker,Executor,Task。storm使用了disruptor和zeroMQ/netty来进行这些数据的通信，并且通过ack机制来达到对计算过程的跟踪。
阅读(1185) | 评论(0) | 转发(0) |
