Hadoop0.23.0初探1—前因后果

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

最近Hadoop社区最火热的事情莫过于Hortonworks公布了Hadoop最新版本(0.23.0),它标志着Hadoop新时代的到来。本文作为系列文章的第一篇,将结合Hadoop-0.20.*的特点,以及Hadoop核心理念,分析Hadoop新版本的特征。 1、Hadoop 0.20.*的局限性 HDFS单NameNode的不足     1)扩展性问题。可以随着数据量进行水平扩展,而元数据服务器不能扩展。 2)随着文件数目的增长,元数据服务器的压力变大。据统计,2.5亿个文件在NameNode中Namespace占据  的大概64GB的内存空间。 3)文件操作的吞吐率受到单个元数据服务器的限制。目前,Hadoop 0.20.*版本可以达到120k readops/sec,6000 writeops/sec. 4)隔离性的问题。0.20.*版本中,一个NameNode对应着唯一的Namespace,所有文件、应用、用户公用同一的名字空间。存在访问权限控制的问题,不利于在HDFS在

Twitter-spider的实时URL Fetcher架构

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

中文不完整的翻译:http://blog.nosqlfan.com/html/3457.html 英文内容转自Twitter-Engineering: http://engineering.twitter.com/2011/11/spiderduck-twitters-real-time-url.html SpiderDuck: Twitter’s Real-time URL Fetcher Tweets often contain URLs or links to a variety of content on the web, including images, videos, news articles and blog posts. SpiderDuck is a service at Twitter that fetches all URLs shared in Tweets in real-time, parses the downloaded content to extract metadata of interest and makes that metadata available for other Twitter services to consume within seconds. Several teams at Twitter need to access the linked content, typically in real-time, to improve Twitter products.

在Hadoop上支持增量计算

十一月 9th, 2011 by klose | No Comments | Filed in mapreduce

Socc2011上有一篇文章值得Hadoop粉丝们关注,”Incoop: MapReduce for Incremental Computations“.Hadoop-MapReduce在海量数据批处理的优势得到广泛的发挥,很多应用随着数据规模的膨胀,悄然转移到Hadoop平台。然而,一个事情在发展到一定规模之后,总会涌现出新的问题或者挑战,例如HDFS单点故障、Hadoop-MapReduce与运行时环境紧耦合、Hadoop资源利用率不高、Shuffle阶段的网络瓶颈等。这些问题在从体系结构的角度上尝试对于Hadoop系统的优化。听说Hadoop2.0新时代也在内部如火如荼地进行着。在应用层面上,Pig、Hive在MapReduce之上将常用的问题抽取出来,提供给上层的用户使用,让MapReduce向SQL的道路迈进。然而,在众多应用中,有些应用需要反复地进行MapReduce处理海量数据,而当这种数据如果基于数据累加或者更新的操作时,增量计

Hadoop-MapReduce后时代

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

随着数据规模的扩展,传统的数据库朝着分布式文件系统+上层数据管理的方向发展。在这其中,Google的技术引领了整个技术的前进和发展。Google底层使用的是GFS,分布式文件系统保证了数据规模和机器规模的可扩展性,这对于一个海量数据处理系统来讲,可扩展性意味着体系架构的稳定性。 这种版本的分布式文件系统,和HDFS的设计原理非常类似,它也是由Master(元数据服务器),ChunkServer(类似于DataNode)。这种设计有如下的好处: 1)解决了大数据存储的问题。数据块的大小默认是64mb。 2)通过备份提高数据的可靠性。 但是,经过Google和Hadoop验证,这种模型能很好地支持离线作业的执行,但是对于实时性要求比较高的应用而言,显然还有很大的问题。 1)文件规模扩大之后Master的单点故障问题(单个NameNode存在性能瓶颈) 2)ChunkServer小数据量的文