“Hadoop&BigData 技术赢门票”活动正式启动

[言行合一]

由中国计算机协会（CCF）主办，CCF大数据专家委员会协办，CSDN承办的国内大数据领域最纯粹的技术盛会——“Hadoop与大数据技术大会”（Hadoop&BigData Technology Conference 2012，HBTC 2012）将于2012年11月30日-12月1日在北京新云南皇冠假日酒店举行。

为了帮助更多开源爱好者认识Hadoop，也为了结识更多的Hadoop&大数据的实践派英雄！HBTC 2012大会召开前夕，CSDN云计算频道特别举办4期的“Hadoop&BigData技术赢门票”的小活动。每期将邀请国内大数据领域技术专家出题，感兴趣的朋友均可参与回答。用你的技术、知识和智慧赢得价值¥1750元的大会门票！问题精彩，期待回答更绝伦！论坛的朋友直接回答即可。

规则：

1.所有CSDN的粉丝及爱好开源，对云计算及大数据感兴趣的朋友都可参加，免费；

2.回答方向、内容、字数均不限；

3.参与方式三种，任君选择：微博@CSDN云计算，CSDN论坛直接回复；邮件[e-mail]，抄送[e-mail]；

4.每次活动都由出题者来确定获奖人，每期2个名额，下期活动开始会在CSDN云计算微博公布（出题者会写明获奖理由）；

5.第二期问题将在11月14日15：00点挂出,第三期、第四期问题将在11月21日15：00点挂出；

没有最好，只有更好！HBTC 2012期待你的参与！

11月7日，“Hadoop&BigData 技术赢门票”活动第一期

问题：作为批量计算的代表框架，Hadoop MapReduce被广泛使用。不过目前也有一种声音在质疑Hadoop计算延迟问题。对于那些希望获得低延迟(可能是毫秒级，秒级或分钟级)保证的用户，如何改进MapReduce框架使得其满足需求？

期待精彩回答！

CSDN云计算频道

2012年11月7日


相关链接：
第一期：“改进MapReduce降低Hadoop计算延迟”获奖公布

第二期：“Hadoop技术赢门票”：技术+开放自由选

[孟子E章]

期待精彩回答！

[zj25810]

孟老师先上一段精彩的？

[IMS123456]

答：计算 mapreduce 各个节点时延分布情况，在各个节点做出妥协办法挤得

[qqgemini5201314]

首先应该将毫秒级延迟和秒级，分钟级延迟分开，对于毫秒级的延迟主要思路是在数据产生的时候就一直保证数据在内存中，这种计算受内存大小限制,所分析的复杂度有限，主要是计数等简单的统计. 对于秒级，分钟级,要将处理的数据大小区分开来，对于ETL任务，输出大量数据，移动，转换，连接，多步骤的计算，mapreduce的延迟和吞吐能力是非常优秀的，对于交互式查询的需求，一般输出非常少，但是扫描的数据非常大，mapreduce 本身的模型不适合这种计算，mapreduce 提出的时候假定是文件系统是共享的，这个是7年前的背景，现在的数据增长已经超过共享文件系统的上限，在大量数据面前，网络和磁盘IO 是主要的瓶颈，这个mapreduce 是永远解决不了的. 对比现在的列数据库,cloudera 的impala,hadapt,drill,dremel, 都是建立在本地扫描数据. 另外还有其他的压缩方式，磁盘扫描方式，执行引擎计划等等优化都是建立在发展了多年的DBMS 基础上的，所以这个问题本身就有问题，不存在所谓的改进mapreduce 框架来减少延迟，需求都是数据大到一定程度才细粒度划分的，没有一个框架能解决所有问题.

[linfssay]

[Andy-Hadoop]

应该考虑使用与搜索引擎类似的数据处理方式来代替基于mapreduce的实时大数据的处理。

[98ki]

Hadoop采用的是动态调度算法，即：当某个tasktracker上出现空slot时，它会通过HEARBEAT（默认时间间隔为3s，当集群变大时，会适当调大）告诉jobtracker，之后jobtracker采用某种调度策略从待选task中选择一个，再通过HEARBEAT告诉tasktracker。从整个过程看，HDFS在获取下一个task之前，一直处于等待状态，这造成了资源利用率不高。此外，由于tasktracker获取新task后，其数据读取过程是完全串行化的，即：tasktracker获取task后，依次连接namenode，连接datanode并读取数据，处理数据。在此过程中，当tasktracker连接namenode和datanode时，HDFS仍在处于等待状态。 为了解决调度延迟问题，可以考虑的解决方案有：重叠I/O和CPU阶段（pipelining），task预取（taskprefetching），数据预取（data prefetching）等

[aperson111]

个人认为MAP REDUCE的时间延迟主要在网络带宽和IO上，如果在计算量较大，但想要实现毫秒级或秒级的结果，需要在并行运算的节点性能和网络、IO之间找到平衡点，这需要主节点采用合理的算法进行分配；另外，如果用户确定想要得到毫秒级或秒级的响应，如果是固定的一些业务，建议hadoop在主节点和子节点上分配一块内存作为缓存，允许用户（开发者）使用这块空间来存放一些经常使用或需要快速响应的结果，这样就可以直接从内存中获取；这个缓存可以存放MAP的结果，也可以存放reduce的结果，也可以存放某一个应用的查询结果等； 对于分钟级的响应，和秒级不是一个级别吧～如果可以解决秒级的延迟问题，那么分钟级的也不会有太大问题。

[中国好小伙-_-]

首先分析m/r计算延迟相对高的原因：1、获取task等待。2、某一个单线程处理多事物。3、m/r强制性排序。4、m/r的读取数据全部采用streaming方式。所以，针对以上4个问题，我建议：1、改进mr调度算法，比如task预先读取等等。2、将线程分组，分为通信组与数据读取组。3、对于没有排序需求的用户，可将m/r排序部分去掉。4、本地文件读取采用direct.

[黑肚皮的窝]

答:实时的概念应该是根据具体标准来衡量，比如秒，毫秒，微妙级，可以增大并发处理的map reducer个数，来逐步“逼近”这个实时的需求标准。

[aa346786718]

顶............................

[HONG_DE]

[ochinchina_cn]

Hadoop MR是批量大数据处理的代表，既然是大数据，数据量是非常大的．Hadoop MR在处理大数据时，认为节点的管理，原始数据的加载，任务处理JVM的启动，中间结果的本地存储，节点之间的数据传输等的开销与整个任务处理的开销相比是比较小的。所以，Hadoop MR用于处理非常大的数据时有非常大的优势。 如果要进行实时处理，那么每批次处理的数据肯定不是很大，但是，数据是源源不断来的，而不是先将它们存起来达到一定的量后再处理，上面描述的开销在处理每批次的数据时所占的比例就会相当大，从而达不到数据的实时处理要求。 要将Hadoop MR改造为有实时性，那么我们可以采用如下的一些方法： １） 数据的输入，现在Hadoop数据的输入是从HDFS文件系统中输入的，可以增加网络数据输入，这样就避免了输入数据的磁盘IO。 ２） 现在每个任务提交的时候，Hadoop的JobTracker会根据任务配置要求TaskTacker启动JVM来处理map子任务或者reduce子任务，JVM的启动时间在秒级，任务完成后，所有的任务JVM都会释放。如果要达到毫秒级，任务JVM的启动就必须是一次启动，永久使用，除非是显示的终止。这要求更改M/R的任务JVM的管理，任务JVM的启动终止是与每个Job无关的，对每一种类型的Job而言，可以预先启动一个Task Pool，每个JVM标示为空闲。当一个Job提交的时候，JobTacker只需要找到空闲的Task JVM而不是启动一个新的JVM，然后assign一个Task跟它并将它标为忙，这样JVM的启动时间就省了。当子任务完成后，必须立即地将JVM放入空闲的Task pool中，便于JVM尽快地被重用。 ３） 中间结果的存放，当前每个map子任务完成的后，都要将结果写入本地磁盘，这也比较耗时。如果是实时的任务，中间结果应该不大，完全可以存放在内存中，当reduce子任务要求数据时，直接从内存传输过去。 ４） 最终结果的存放，当前最终结果也是写入磁盘的，可以要求将最终结果通过网络直接传递给某个应用程序。 ５） 增加pipe line机制，这个比较简单，第４）步的结果可以作为pipe line的下一步的输入，即pipe line的下一步的１）的输入。 再上面的方法中，对Hadoop进行第２）步的难度相对而言是比较大的，其他部分的改造比较简单。 上述方法能否将Hadoop改造为具有实时性，欢迎各位同学提出宝贵的意见和建议。

[comeandgo201205]

开开心心每一天。

[lixiaoya529]

hadoop现在对静态数据处理比较好，希望能支持实时数据处理。

[gqwewq]

北京啊，无缘了

[csdn1111]

[天才2012]

[sefdtrtry]

前段时间，我一好朋友借着我生日的机会送了一套【丽塔去痘茶】 我是在乐购时尚网买的，并一再叮咛一定要坚持喝。有天早上起来发现，痘痘几乎快消失了，我都不敢相信镜子里的自己。用了那么多祛痘产品，这么有效果的还是第一次遇到，真是惊喜万分，2个月下来，我的痘痘消的差不多了，强烈推荐各位长痘的人，真的可以去试一下，呵呵qq 876931865。 lcl

[cdre121]

北京啊，无缘