作者 食指 出自《食指的诗》
当蜘蛛网无情地查封了我的炉台，
当灰烬的余烟叹息着贫困的悲哀，
我依然固执地铺平失望的灰烬，
用美丽的雪花写下：相信未来。
当我的紫葡萄化为深秋的露水，
当我的鲜花依偎在别人的情怀，
我依然固执地用凝霜的枯藤
在凄凉的大地上写下：相信未来。
我要用手指那涌向天边的排浪，
我要用手掌那托住太阳的大海，
摇曳着曙光那枝温暖漂亮的笔杆
用孩子的笔体写下：相信未来。
我之所以坚定地相信未来，
是我相信未来人们的眼睛——
她有拨开历史风尘的睫毛，
她有看透岁月篇章的瞳孔。
不管人们对于我们腐烂的皮肉，
那些迷途的惆怅、失败的苦痛，
是寄予感动的热泪、深切的同情，
还是给以轻蔑的微笑、辛辣的嘲讽。
我坚信人们对于我们的脊骨，
那无数次的探索、迷途、失败和成功，
一定会给予热情、客观、公正的评定。
是的，我焦急地等待着他们的评定。
朋友，坚定地相信未来吧，
相信不屈不挠的努力，
相信战胜死亡的年轻，
相信未来、热爱生命。
1968年 北京
“大多数科学家是因为惧怕生活而成为科学家的。在科学中有所成就是非常诱人的，因为不必与人发生冲突，不必感受人际关系的痛苦，不必在世界上艰难前进就可以成就这些东西。脱离尘世是多么地诱人——这个有几分清净的世界，你可以全力施展你的才华，而没有任何痛苦。解决问题的痛苦和生活中的痛苦比起来是微不足道的。” –约翰.巴库斯
终于将今年十一期间翻译的文章整理完了。从去年开始翻分布式方面的论文，算起来现在也已经一年多的时间了。去年中秋的假期，翻译出了面向星球的网络搜索：google集群架构，然后十一又翻完了GFS，MapReduce，BigTable。之后的文章基本都是利用周末的时间翻出来的，到现在应该也翻了30多篇了。
原文： http://ofps.oreilly.com/titles/9781449396107/architecture.html
译者：phylips@bmy 2011-10-1
出处：http://duanple.blog.163.com/blog/static/709717672011925102028874/
HBase中的每个column family可能有多个文件，文件中包含实际的cells或者是KeyValue实例。当memstore中积累的更新被flush到磁盘上时这些文件就会创建出来。负责compaction的后台线程会通过将小文件合并成更大的文件来将文件数控制在一定水平上。Major compaction最终会将所有的文件集合压缩成一个，之后随着flush的进行，小文件又会出现。
作者：Biswapesh Chattopadhyay&Weiran Liu .etc.Google Inc 2011-8
原文：http://www.vldb.org/pvldb/vol4/p1318-chattopadhyay.pdf
译者：phylips@bmy 2011-10-6
译文： http://duanple.blog.163.com/blog/static/70971767201192484915767/
摘要
Tenzing是一个建立在MapReduce之上的用于Google数据的ad hoc分析的查询引擎。Tenzing提供了一个具有如下关键特征的完整SQL实现(还具有几个扩展)：异构性，高性能，可扩展性，可靠性，元数据感知，低延时，支持列式存储和结构化数据，容易扩展。Tenzing目前已被Google内部的上千个工程师所使用，提供了每天在1.5PB压缩后数据上的10000多个查询支持。在本文中，我们描述了Tenzing的架构和实现，并给出了由一些典型分析型查询任务组成的benchmark结果。
原文： http://ofps.oreilly.com/titles/9781449396107/architecture.html
译者：phylips@bmy 2011-10-1
出处：http://duanple.blog.163.com/blog/static/709717672011923111743139/
Region servers在未收集到足够数据flush到磁盘之前，会一直把它保存在内存中，这主要是为了避免产生太多的小文件。当数据驻留在内存中的时候，它就是不稳定的，比如可能会在服务器发生供电问题时而丢失。这是一个很典型的问题，参见the section called “Seek vs. Transfer”。
作者：phylips@bmy 2011-10-15
虽然标题有些诡异，但是实际上转成英文就一目了然了：Dynamo Dremel ZooKeeper Hive。这几个系统之间本身没有太过紧密的联系，只是最近休假期间把它们四个粗略看了一遍，因此放到一块简要总结一下。就这四篇比较来看，其中Dremel和Hive相对容易理解些，Dynamo和ZooKeeper则相对深奥一些。
from：http://www.programmer.com.cn/8606/
文/杨栋
本文系统地介绍和分析比较了业界主流的Yahoo! S4、StreamBase和Borealis三种流式计算系统，希望读者能从这些系统的设计中领悟到不同场景下流式计算所要解决的关键问题。
背景
非实时计算几乎都基于MapReduce计算框架，但MapReduce并不是万能的。对于搜索应用环境中的某些现实问题，MapReduce并不能很好地解决问题。
最新版的HFile主要做了两个改进，这两个改进都主要是为了降低内存使用和启动时间，思路都是将它们切分为多个block，填满就写出去，这也降低了writer的内存占用：
1. 增加了树状结构的数据块索引(data block index)支持。原因是在数据块的索引很大时，很难全部load到内存，比如当前的一个data block会在data block indxe区域对应一个数据项，假设每个block 64KB，每个索引项64Byte，这样如果每条机器上存放了6TB数据，那么索引数据就得有6GB，因此这个占用的内存还是很高的。通过对这些索引以树状结构进行组织，只让顶层索引常驻内存，其他索引按需读取并通过LRU cache进行缓存，这样就不需要将全部索引加载到内存。
译者：phylips@bmy 2011-10-1
出处：http://duanple.blog.163.com/blog/static/70971767201191661620641/
本文翻译自：http://ofps.oreilly.com/titles/9781449396107/architecture.html
作为开源类BigTable实现。HBase目前已经应用在很多互联网公司中。
[说明：之前的那篇<<分布式系统领域经典论文翻译集>>颇显庞杂，涵盖内容五花八门，也有人提出不知道从哪开始。所以呢，就有了这一篇，主要以组成Hadoop生态系统的各组件为线索，串起了其中相对重要的那些论文，同时基本上也是按照从前往后的顺序由浅入深的，其中也包含了翻译集中所未出现的一些。这些文章中，标为(译)的那些是本人翻译的，标为(zz)的那些是其他人的译文或原创，剩余未标明的部分基本上是英文原文，可能会择其要者而译之。]
作者：phylips@bmy 2011-10-03
[序：关于MapReduce的争论，这篇<<MapReduce和并行数据库，朋友还是敌人？(zz)>>已经进行了展开。不过我通常对这方面的内容持着浓厚的兴趣，所以还是再理一下，并将涉及的论文翻译了出来。]
作者：Michael Stonebraker &Daniel Abadi et. 2010-1
原文：http://database.cs.brown.edu/papers/stonebraker-cacm2010.pdf
译者：phylips@bmy 2011-10-5
译文：http://duanple.blog.163.com/blog/static/7097176720119720494/
序
MapReduce弥补了DBMS的不足，因为数据库不是设计用于执行ETL任务，而在这方面MapReduce更擅长。
作者：Jeffrey Dean &Sanjay Ghemawat .Google Inc 2010-1
原文：http://perspectives.mvdirona.com/2010/01/02/MapReduceInCACM.aspx
译者：phylips@bmy 2011-10-5
译文：http://duanple.blog.163.com/blog/static/7097176720119711038980/
序
与并行数据库相比，MapReduce的优势包括存储系统无关以及大规模jobs的细粒度容错性。
作者：Andrew Pavlo &Erik Paulson etc. 2009-6
原文：http://db.csail.mit.edu/pubs/benchmarks-sigmod09.pdf
译者：phylips@bmy 2011-10-4
译文：http://duanple.blog.163.com/blog/static/7097176720119701941950/
摘要
使用MapReduce模型进行大规模数据分析目前已成为一个炙手可热的领域而备受关注[17]。尽管该框架的基本控制流实际上早在20多年前就出现在数据库管理系统(DBMS)中了，但是有些人还是把它称为一个全新的计算模型[8,17]。在本文中，我们分别对这两种模型进行了描述和对比。此外，我们还对比了这两种系统的性能和开发的复杂度。最后，我们定义了由多个计算任务组成的benchmark，并在一个MR的开源版本和两个并行DBMS系统上进行了测试。针对每个计算任务，我们在一个100节点的集群上进行了多个并行度上的系统性能测试。我们得到了一些有趣的结论。尽管并行DBMS的数据加载过程和执行调优所花费的时间比MR系统要长，但是这些DBMS系统所表现出的执行性能却比MR系统好很多。我们对产生这种显著的性能差异的原因进行了思考，并考虑了那些未来系统所需要从这两种架构学习的地方。
from：http://gost.isi.edu/555/fall2011/11-readinglist.html
August 26, 2010
CSci 555 / Fall 2011
Except as noted, all items on the reading list are required reading. Chapters may be found in the textbook. Chapter numbers are from the 4th edition, followed by the chapter numbers in the 3rd edition if known in square brackets. The dates following the section headings are the weeks when these papers will be discussed. You should read the papers before the lectures in the given week. Papers are linked from the number preceding the reference in this reading list. For papers retrived as scanned PDF files, the password is cs555.
zz from：http://databasecolumn.vertica.com/database-innovation/mapreduce-ii/
MapReduce: A major step backwards 的续
[Note: Although the system attributes this post to a single author, it was written by David J. DeWitt and Michael Stonebraker]
Last week’s MapReduce post attracted tens of thousands of readers and generated many comments, almost all of them attacking our critique. Just to let you know, we don’t hold a personal grudge against MapReduce. MapReduce didn’t kill our dog, steal our car, or try and date our daughters.
Monday, November 2nd, 2009 at 8:00 am by Doug Cutting, filed under data collection, general, hadoop, mapreduce.
王旭 [ gnawux(at)gmail.com , @gnawux, http://wangxu.me ]于11月2-3日译
译注：Doug Cutting 是 Hadoop 的大佬，目前在 Cloudera，Avro 基本上将成为未来 Hadoop 的数据描述和 RPC 的基础，今天看到这篇，就立刻翻译了，水平有限且译的比较草，请见谅，且欢迎纠错。