银河里的星星
from：http://www.programmer.com.cn/4014/
文/何伟平
在2010年1月的ACM上，有两篇文章非常吸引人注意。一篇文章是Google的Jeffrey Dean、Sanjay Ghemawat发表的标题为《MapReduce:一个灵活的数据库处理工具》，另一篇文章是Michael Stonebraker、Daniel Abadi、David J. DeWitt、Sam Madden、Erik Paulson、Andrew Pavlo、Alexander、Rasin等人发表的《MapReduce和并行数据库：是朋友还是敌人？》。这两篇文章让我想起去年初Michael Stonebraker等人就MapReduce发表的一些评论而导致了一次MapReduce和数据库系统的大辩论。那篇文章的标题是《MapReduce：一个巨大的倒退》。这次辩论双方则准备了丰富的实践和实验案例。看上去更加有趣也更加有说服力。 read more
作者：Konstantin Shvachko 2010-4
原文：http://www.aosabook.org/en/hdfs.html
译者：phylips@bmy 2011-9-17
译文：http://duanple.blog.163.com/blog/static/70971767201181745539637/
[
序：如果说The Hadoop Distributed File System对应了GFS，那么这篇实际上有些与Case Study GFS: Evolution on Fast-forward相似，只是更专注于可扩展性。本文除了提供了关于HDFS可扩展性的各方面的深入思考外，其中使用的估算方法，测试方法及关于可扩展性的思考方法也是非常值得的。 read more
作者：Konstantin Shvachko, Hairong Kuang etc. 2010-10
原文：http://storageconference.org/2010/Papers/MSST/Shvachko.pdf
原文：http://www.aosabook.org/en/hdfs.html
译者：phylips@bmy 2011-9-12
译文：http://duanple.blog.163.com/blog/static/70971767201181744412133/
摘要
Hadoop分布式文件系统(HDFS)设计用于为大规模数据集提供可靠性的存储，同时能够将数据集以高带宽的传输速率推送给用户应用程序。在一个大规模集群上，将会有数千台的服务器同时负责数据存储及执行用户应用级的计算任务。通过将存储和计算分布到很多个服务器上，使得存储和计算资源可以在保持低成本的情况下根据数据规模按需增长。在本文中，我们会描述下HDFS的架构，以及我们在Yahoo!使用HDFS来管理25PB的企业数据的相关经验。 read more
from：http://timyang.net/architecture/yahoo-pnuts/
在分布式领域有个CAP理论(Brewer’s CAP Theorem) ，是说Consistency(一致性), Availability(可用性), Partition tolerance(分布) 三部分在系统实现只可同时满足二点，没法三者兼顾。所以架构设计师不要把精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍，选取最适合应用需求的其中之二。比如MySQL 5.1 cluster设计前显然不知道有CAP理论这样的经验, 所以MySQL cluster表面看来尽管可提供所有分布式特性，但实际大部分场合都无法提供稳定可靠的服务。 read more
作者：Dhruba BOrthakur & Joydeep Sen Sarma etc. Facebook Inc 2011-6
原文：http://wenku.baidu.com/view/5b1f48ef0975f46527d3e18b.html
译者：phylips@bmy 2011-9-11
出处：http://duanple.blog.163.com/blog/static/7097176720118121573597/
摘要
Facebook最近部署了Facebook Messages，这是它的首个构建于Apache Hadoop平台上的user-facing应用。使用构建于Hadoop之上的类数据库层Apach HBase来对每天数十亿的消息信息进行处理支持。这篇论文描述了Facebook在众多系统中(比如Apache Cassandra，Voldemort)最终选择了Hadoop和HBase的原因，并讨论了应用程序在一致性、可用性、分区容忍性、数据模型及可扩展性上的需求。我们还会探讨一下为了让Hadoop成为一个更有效的实时性系统所做的那些改进，在配置系统过程中所做的那些权衡，以及这种基于Hadoop的解决方案与Facebook和很多其他互联网公司在很多应用程序中采用的那种分片(sharded)MySQL数据库模式相比所具有的优势。我们还会讨论各种设计选择的背后动机，我们在日常工作中面临的挑战，一些未来的还在开发中的功能和改进。我们提供的这些关于部署中的各种观点可以为那些正在考虑使用基于Hadoop的解决方案取代传统分片RDBMS部署的公司，提供一种参考性的模型。 read more
大悲咒是观世音菩萨《大悲心陀罗尼经》中的主要部分，共有八十四句。其全名为《千手千眼观世音菩萨广大圆满无碍大悲心陀罗尼经大悲神咒》。大悲咒得名的由来是：有一次佛陀告诉阿难尊者说：“如是神咒，有种种名：一名广大圆满，一名无碍大悲，一名救苦陀罗尼，一名延寿陀罗尼，一名灭恶趣陀罗尼，一名破恶业障陀罗尼，一名满愿陀罗尼，一名随心自在陀罗尼，一名速超十地陀罗尼。”观世音被称为千手千眼观世音菩萨的由来是：有一次他曾经在千光王静住如来住所时，静住如来特为他说了“广大圆满无碍大悲陀罗尼”。并且对他说：“善男子！汝当持此心咒，普为未来恶世一切众生作大利乐。”据经的记载：当时观世音菩萨听了此咒后，即由初地证至第八地——不动地。于是发出誓愿说：“设我当来之世能利乐一切众生者，令我即时身生千手千眼具足。”如此发愿后，果真顿时身生千手千眼，并且十方大地为之震动，十方诸佛亦都放出无量光明，遍照十方的无边世界。 read more
http://www.slideshare.net/hortonworks/apache-hadoop-023
HDFS Federation http://www.hortonworks.com/an-introduction-to-hdfs-federation/
Next Generation of Apache Hadoop MapReduce http://www.slideshare.net/hortonworks/nextgen-apache-hadoop-mapreduce
HDFS High Availablity https://issues.apache.org/jira/browse/HDFS-1623 read more
1930的时候，赵元任写了篇<<施氏食狮史>>。 下面这个是两年多前写的了，其实当时应该是在调侃陈臣同学，“陈臣，陈："臣，陈臣，晨，尘沉，衬尘"”，只是却想起了yaoyao同学。大概是无聊时候的游戏，只是仿佛已很久没当年那般无聊了。 read more
from：http://cloud.csdn.net/a/20110429/296900.html
本文介绍了Facebook公司数据分析系统中的RCFile存储结构，该结构集行存储和列存储的优点于一身，在 MapReduce环境下的大规模数据分析中扮演重要角色。
Facebook曾在2010 ICDE（IEEE International Conference on Data Engineering）会议上介绍了数据仓库Hive。Hive存储海量数据在Hadoop系统中，提供了一套类数据库的数据存储和处理机制。它采用类 SQL语言对数据进行自动化管理和处理，经过语句解析和转换，最终生成基于Hadoop的MapReduce任务，通过执行这些任务完成数据处理。图1显示了Hive数据仓库的系统结构。 read more
作者：Owen Omalley 2009-8-27
原文：http://developer.yahoo.com/blogs/hadoop/posts/2009/08/the_anatomy_of_hadoop_io_pipel/
译者：phylips@bmy 2011-8-28
出处：http://duanple.blog.163.com/blog/static/70971767201172902737677/
引言
在一个典型的Hadoop MapReduce job中，通常是从HDFS上读取输入文件。为减少文件大小，文件数据通常是压缩过的，因此读取之后需要进行解压，之后得到序列化字节串，在传递给用户定义的Map函数之前再将这些字节串转换为java对象。输出则刚好是一个反向的过程，输出记录会被序列化，压缩，最终传送到HDFS上。这看起来很简单，但是因为下面的一些原因，这两个过程实际上是很复杂的： read more
作者：Jeff Dean, Sanjay Ghemawat
原文：http://leveldb.googlecode.com/svn/trunk/doc/impl.html
译者：phylips@bmy 2011-8-17
译文：http://duanple.blog.163.com/blog/static/70971767201171821616246/
Files
LevelDB的实现本质上类似于Bigtable中的tablet(参见Bigtable论文5.3节)。但是，与论文中的具体的文件组织方式稍有不同，解释如下： read more
作者：Jeff Dean, Sanjay Ghemawat
原文：http://leveldb.googlecode.com/svn/trunk/doc/index.html
译者：phylips@bmy 2011-8-16
译文：http://duanple.blog.163.com/blog/static/70971767201171705113636/
LevelDB库提供了一种永久性的key value存储。Key和value都是任意的字节序列。在这个key value存储系统中，key按照用户声明的比较函数有序排列。 read more
这两句出自苏轼的《定风波》，写于因“乌台诗案”被贬黄州后的第二年。
定风波
三月七日沙湖道中遇雨。雨具先去，同行皆狼狈，余独不觉。已而遂晴，故作此。
莫听穿林打叶声，
何妨吟啸且徐行。
竹杖芒鞋轻胜马，谁怕？
一蓑烟雨任平生。
料峭春风吹酒醒，微冷，
山头斜照却相迎。
回首向来萧瑟处，归去，
也无风雨也无晴。 read more
zz from：http://www.cnblogs.com/spork/archive/2010/04/02/1703428.html
最近看到调度器这一块，发现Hadoop官方文档中有关公平调度器（Fair Scheduler Guide）和容量调度器（Capacity Scheduler Guide）部分的文档还没有汉化，Google了下也未发现有相关汉化，So，我班门弄斧，抛砖引玉一下了。这里先奉上公平调度器的中文版。由于我一直用Cloudera Hadoop 0.20.1+152的版本，所以这个汉化也是基于里面的文档来的。目前官方上的公平调度器部分已经改动了：
取消了配额文件，参数全部设置到mapred-site.xml。任务抢占特性也取消了。增删了一些参数。但是基本的原理和设置还是一样的，该文档仍适用于新版的公平调度器。 read more
早上，朋友告诉我之前翻译的系列文章，有在新浪微博上看到别人推荐。联系到最近访问量暴增，看下统计果然有些流量是从weibo上导过来的，顿感压力山大，唯恐贻笑大方。
一方面某些文章已经是一年之前翻译的了，现在回头再看也发现其中有些理解偏颇的地方。另一方面即算现在来看，感觉还有些地方未理解透彻。当初翻译这些论文的目的在于一方面加深自己的印象，另一方面也是为了记录自己对于关键内容的理解，所以这应该是一个长期的不断改进的过程。后面这项工作应该也会持续下去，对于其中已经有翻译版本的，除非必要应该不会再去翻译，虽无严格的计划，但是大概会有几个步骤：继续关注分布式基础理论方面的论文，研究下Hadoop的源代码，做一个关于锁的专题，看下Dynamo这一系列的理论基础及相关系统 read more
作者：Kirk McKusick & Sean Quinlan 2009-8
原文：http://queue.acm.org/detail.cfm?id=1594206
译者：phylips@bmy 2011-8
译文： http://duanple.blog.163.com/blog/static/7097176720117611327190/
[一个Kirk McKusick 与Sean Quinlan之间关于GFS的起源和演化的讨论] read more
英文原文：http://developer.yahoo.com/blogs/hadoop/posts/2011/02/mapreduce-nextgen/
zz from：http://blog.nosqlfan.com/html/1451.html
注：随着Hadoop的流行，其局限性也在一定程度体现，各大公司也在hadoop上做了很多修改，下面是雅虎对Hadoop下一代的重构计划。原文地址：http://sandaobusi.javaeye.com/blog/941740 read more
zz from：http://www.dbthink.com/?p=666&cpage=1#comment-596
source : The Seven Secrets of Successful Data Scientists
1.选择合适的工具,杀鸡不要随便用牛刀,打蚊子毋需高射炮.
2.对所有的数据做压缩, 原因, 我们处在一个IO密集的世界
3.拆分,拆分,还是拆分
4.对数据取样,不是每次分析都需要使用全量数据
5.拿来主义,善于从开源社区,寻找已经解决好的方案,毋需不断重建轮子
6.Data Locality, 让数据毋需移动即可进行分析
7.不要过于聪明,专注于解决你实际面临的困难,不要去解决太过于遥远的问题 read more
zz from：http://www.dbthink.com/?p=483
本文是Ebay的架构师在2008年发表给ACM的文章,是一篇解释BASE原则,或者说最终一致性的经典文章. 文中Dan讨论了BASE与ACID原则的基本差异, 以及如何设计大型网站以满足不断增长的可伸缩性需求,期间如何对业务做调整与折衷. 以及一些具体的折衷技术的介绍. read more