MapReduce编程模型的要点

六月 30th, 2011 by klose | No Comments | Filed in mapreduce

背景 MapReduce现在基本已经成为分布式并行编程框架的Bible,很多分布式计算引擎的实现[Hadoop][CIEL][Twister][Transformer][MR-mpi][Phoenix][Dryad]都将MapReduce作为一个核心的编程模型。 MapReduce编程模型是什么? 很多人都认为MapReduce只有这样两个过程构成: Map过程:Map(k1,v1) → list(k2,v2) Reduce过程:Reduce(k2, list (v2)) → list(v3) 会找到一些图来辅助对于MapReduce的理解: 哪些是MapReduce过程的关键点? 1)Map阶段的数据本地性的考虑。 2)Map中间结果的归并,由多个Spill文件归并成一个大文件。 3)Reduce拷贝数据的过程 对于一个具体的问题,更多的时候,确定Map、Reduce过程的操作并不困难,关键的问题是MapReduce对于数据的组织和传输问题。 1)map是数据本地性、并行化的关键步骤。对于一个大文件,它起始位置放在哪

如何突破1个server链接数超过500,000的限制(Linux Kernel tuning for 500k)

六月 21st, 2011 by klose | No Comments | Filed in 海量数据存储与处理

Note: Concurrency, as defined in this article, is the same as it is for The C10k problem: concurrent clients (or sockets). At Urban Airship we recently published a blog post about scaling beyond 500,000 concurrent socket connections. Hitting these numbers was not a trivial exercise so we’re going to share what we’ve come across during our testing. This guide is specific to Linux and has some information related to Amazon EC2, but it is not EC2-centric. These principles should apply to just about any Linux platform. For our usage, squeezing out as many possible socket connections per server is valuable. Instead of running 100 servers with 10,000 connections each, we’d rather run 2 serv

Redis的总结

六月 19th, 2011 by klose | No Comments | Filed in 海量数据存储与处理

在转载之前: 最近在研究Key-Value Store系统在互联网体系架构的应用,在开源中国社区看到了这篇文章,很喜欢作者的研究思路和文章风格,现转载到我的blog,作为对于前一段自己看Redis的一个总结吧。(Klose) redis高可用 (来自于:http://www.iteye.com/topic/1108383) 因为redis不仅作为缓存使用,而且也是resque执行异步和定时任务的消息队列,因此对于可用性的要求就比较高,一旦挂掉,所有后台任务就会全部停止,严重影响网站的功能和体验。 但是redis原生的cluster解决方案迟迟不出,去年看redis官网的时候,说是直到今年5月份才可能会有rc放出,所以没办法,只能自己做一个山寨的高可用方案勉强支撑一段时间。 PS:今年5月份的时候我再看,却又拖到“不早于夏末”了。原来不只是XXX说话不算数的。 redis双机高可用的基础,是redis的主备复制

使用Distributed Cache缓存MapReduce中间数据的策略以及思考

六月 17th, 2011 by klose | No Comments | Filed in mapreduce

简介 memcached 是以LiveJournal 旗下Danga Interactive 公司的Brad Fitzpatric 为首开发的一款软件。目前已经被Yahoo、Facebook、Twitter、Sina、Sohu等国内外知名互联网企业使用。。memcached是高性能的分布式内存缓存服务器。一般的使用目的是,通过缓存数据库查询结果,减少数据库访问次数,以提高动态Web应用的速度、提高可扩展性。 memcached作为高速运行的分布式缓存服务器,具有以下的特点。 • 协议简单。使用简单的基于文本行的协议,实现数据快速读写。 • 基于libevent的事件处理。Libevent通过对于Linux的epoll、BSD类操作系统的kqueue等事件处理功能封装成统一的接口。即使对于服务器的连接的增加,也能发挥O(1)的性能。 • 内置内存存储方式。数据仅保存在Memcached内部的内存中,系统停机以后,数据全部丢失。Memcached不负

Hadoop如何组织中间数据的存储和传输(源码级分析)2

六月 10th, 2011 by klose | No Comments | Filed in mapreduce, 海量数据存储与处理

Hadoop如何组织中间数据的存储和传输(源码级分析)1 解读了MapTask的整体执行流程,该文档将分析MapTask从内存缓冲区刷新到本地磁盘的过程。 MapTask环境设置:io.sort.mb = 200MB, io.sort.spill.percent=0.8. 1、处理内存缓冲区位于MapTask.MapOutputBuffer类中,所有的信息都被存储在byte[] kvbuffer中,它的长度为bufferlen=200*1024*1024 对于任意一条<K,V>记录,需要记录如下: 1)META DATA,主要包括: private static final int INDEX = 0;            // index offset in acct private static final int VALSTART = 1;         // val offset in acct private static final int KEYSTART = 2;         // key offset in acct private static final int PARTITION = 3;        // partition offset

MapTask与ReduceTask深入分析与调优

六月 4th, 2011 by klose | No Comments | Filed in mapreduce

1 Map-side tunning 1.1 MapTask运行内部原理 当map task开始运算,并产生中间数据时,其产生的中间结果并非直接就简单的写入磁盘。这中间的过程比较复杂,并且利用到了内存buffer来进行已经产生的 部分结果的缓存,并在内存buffer中进行一些预排序来优化整个map的性能。如上图所示,每一个map都会对应存在一个内存 buffer(MapOutputBuffer,即上图的buffer in memory),map会将已经产生的部分结果先写入到该buffer中,这个buffer默认是100MB大小,但是这个大小是可以根据job提交时的 参数设定来调整的,该参数即为:io.sort.mb。当map的产生数据非常大时,并且把io.sort.mb调 大,那么map在整个计算过程中spill的次数就势必会降低,map task对磁盘的操作就会变少,如果map tasks的瓶颈在磁盘上,这样调整就会大大提高map的计算性能。map做sort和s