分布式系统

作者： Terence Parr

译者：Nicholas @ NirvanaStudio

译文出处：http://www.cnblogs.com/me-sa/articles/766533.html

原文出处：http://www.cs.usfca.edu/~parrt/course/652/lectures/antlr.html

另有一篇不错的文章：http://www.cppblog.com/morya/archive/2009/12/07/102681.html

介绍

自1980年以来我手工编写了很多识别程序（recognizer）和翻译程序（translator）但最终我感到很恶心并且尝试将这个过程自动化：来源于我的座右铭： "Why program by hand in five days what you can spend five years of your life automating." read more

zz from：http://blog.sina.com.cn/s/blog_406d9bb00100ui5p.html

Storm简介

Storm是一个分布式的、容错的实时计算系统，遵循Eclipse Public License 1.0,Storm可以方便地在一个计算机集群中编写与扩展复杂的实时计算，Storm之于实时处理，就好比Hadoop之于批处理。Storm保证每个消息都会得到处理，而且它很快——在一个小集群中，每秒可以处理数以百万计的消息。可以使用任意编程语言来做开发。
主要商业应用及案例：Twitter
Storm的优点
1. 简单的编程模型。类似于MapReduce降低了并行批处理复杂性，Storm降低了进行实时处理的复杂性。
2. 服务化,一个服务框架,支持热部署,即时上线或下线App.
3. 可以使用各种编程语言。你可以在Storm之上使用各种编程语言。默认支持Clojure、Java、Ruby和Python。要增加对其他语言的支持，只需实现一个简单的Storm通信协议即可。
4. 容错性。Storm会管理工作进程和节点的故障。
5. 水平扩展。计算是在多个线程、进程和服务器之间并行进行的。
6. 可靠的消息处理。Storm保证每个消息至少能得到一次完整处理。任务失败时，它会负责从消息源重试消息。
7. 快速。系统的设计保证了消息能得到快速的处理，使用ZeroMQ作为其底层消息队列。
8. 本地模式。Storm有一个“本地模式”，可以在处理过程中完全模拟Storm集群。这让你可以快速进行开发和单元测试。
Storm目前存在的问题 read more

zz from：http://blog.csdn.net/HEYUTAO007/article/details/5725379

参考： 

1 caibinbupt的源代码分析http://caibinbupt.javaeye.com

2 coderplay的avaeye 

http://coderplay.javaeye.com/blog/295097

http://coderplay.javaeye.com/blog/318602 

3 Javen-Studio 咖啡小屋 

http://www.cppblog.com/javenstudio/articles/43073.html read more

zz from：http://www.cloudera.com/blog/2010/04/cap-confusion-problems-with-partition-tolerance/

by Henry Robinson April 26, 2010 14 comments Tweet

The ‘CAP’ theorem is a hot topic in the design of distributed data storage systems. However, it’s often widely misused. In this post I hope to highlight why the common ‘consistency, availability and partition tolerance: pick two’ formulation is inadequate for distributed systems. In fact, the lesson of the theorem is that the choice is almost always between sequential consistency and high availability. read more

zz from：http://www.codinglabs.org/html/consistent-hashing.html

摘要

本文将会从实际应用场景出发，介绍一致性哈希算法（Consistent Hashing）及其在分布式系统中的应用。首先本文会描述一个在日常开发中经常会遇到的问题场景，借此介绍一致性哈希算法以及这个算法如何解决此问题；接下来会对这个算法进行相对详细的描述，并讨论一些如虚拟节点等与此算法应用相关的话题。 read more

from：http://blog.sciencenet.cn/home.php?mod=space&uid=449420&do=blog&id=483860

【原题】Above the Clouds: A Berkeley View of Cloud Computing
【译题】 云之上：伯克利对云计算的一个观点
【作者】Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy Katz,
Andy Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica, and Matei Zaharia
(Comments should be addressed to abovetheclouds@cs.berkeley.edu)
UC Berkeley Reliable Adaptive Distributed Systems Laboratory
http://radlab.cs.berkeley.edu/
February 10, 2009 read more

版权声明: 允许非商业性转载，但转载时必须标明原作者 fcicq、原始链接 http://www.fcicq.net/wp/?p=892 及本声明。

2009 年以索引技术创业的 TokuTek 发布了 TokuDB for MySQL, 看性能参数是挺不错的.当时就对它产生了极大的兴趣. 但非常不幸偶没有理解它的索引原理 (Tokutek 也不说). 再加上它不是很成熟, 没有 ACID, 多核支持也不好, 所以暂时搁置了. read more

zz from：http://www.blogjava.net/killme2008/archive/2011/11/08/363238.html?utm_source=twitterfeed&utm_medium=twitter 

Items\Projects

Yahoo! s4

Twitter Storm

协议

Apache license 2.0

Eclipse Public License 1.0

开发语言

Java

Clojure,Java,Clojure编写了核心代码 结构

去中心化的对等结构

有中心节点nimbus，但非关键 通信

可插拔的通讯层，目前是基于UDP的实现 基于twitter开源的thrift框架 事件/Stream

<K,A>序列，用户可自定义事件类 提供Tuple类，用户不可自定义事件类，

但是可以命名field和注册序列化器 处理单元 Processing Elements，内置PE处理

count,join和aggregate等常见任务 Bolt，没有内置任务，提供IBasicBolt处理

自动ack 第三方交互

提供API,Client Adapter/Driver，第三方客户端输入或者输出事件 定义Spout用于产生Stream，没有标准输出API 持久化 提供Persist API规范，可根据频率或者次数做

持久化

无特定API，用户可自行选择处理

可靠处理  无，可能会丢失事件  提供对事件处理的可靠保证（可选） 路由 EventType + Keyed attribute + value匹配

内置count,join和aggregate标准任务 Stream Groupings:

Shuffle,Fields,All,Global,None,Direct

非常灵活的路由方式 多语言支持  暂时只支持Java 多语言支持良好，本身支持Java,Clojure，

其他非JVM语言通过thrift和进程间通讯 Failover

 部分支持，数据无法failover  部分支持，数据同样无法failover Load Balance

不支持  不支持  并行处理  取决于节点数目，不可调节  可配置worker和task数目，storm会尽量将worker和task均匀分布 动态增删节点 不支持

 支持 动态部署

 不支持  支持 web管理  不支持  支持 代码成熟度  半成品  成熟 活跃度  低  活跃 编程  编程 + XML配置

  纯编程

参考文档  
http://docs.s4.io/
https://github.com/nathanmarz/storm/wiki/


http://xumingming.sinaapp.com/category/storm/ （非常好的中文翻译)
read more

非常不错的一篇文章，zz from：http://coolshell.cn/articles/5701.html 作者：陈皓

Steve Yegge， Amazon的前员工，现任Google员工，其本来想在Google+上和Google的员工讨论一些关于平台的东西，结果不小心把圈子设成了Public，结果这篇文章就公开给了全世界，引起了剧烈的反应。发布后很快他就马上把这篇文章删了，不过，互联网上早备份了下来——SteveY’s Google Platforms Rant。后来，Steve在其Google+上作了一些解释，大体是说他喝多了，而且又是在凌晨，所以大脑不清，文章中的观点很主观，极端且不完整，还有Google的PR对他很好，等等，等等 。 read more

原文： http://ofps.oreilly.com/titles/9781449396107/architecture.html

译者：phylips@bmy 2011-10-1 

出处：http://duanple.blog.163.com/blog/static/709717672011925102028874/

 
1.   Read Path

HBase中的每个column family可能有多个文件，文件中包含实际的cells或者是KeyValue实例。当memstore中积累的更新被flush到磁盘上时这些文件就会创建出来。负责compaction的后台线程会通过将小文件合并成更大的文件来将文件数控制在一定水平上。Major compaction最终会将所有的文件集合压缩成一个，之后随着flush的进行，小文件又会出现。 read more

作者：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结果。 read more

原文： http://ofps.oreilly.com/titles/9781449396107/architecture.html

译者：phylips@bmy 2011-10-1 

出处：http://duanple.blog.163.com/blog/static/709717672011923111743139/

1.   Write-Ahead Log

Region servers在未收集到足够数据flush到磁盘之前，会一直把它保存在内存中，这主要是为了避免产生太多的小文件。当数据驻留在内存中的时候，它就是不稳定的，比如可能会在服务器发生供电问题时而丢失。这是一个很典型的问题，参见the section called “Seek vs. Transfer”。 read more

  作者：phylips@bmy 2011-10-15

虽然标题有些诡异，但是实际上转成英文就一目了然了：Dynamo Dremel ZooKeeper Hive。这几个系统之间本身没有太过紧密的联系，只是最近休假期间把它们四个粗略看了一遍，因此放到一块简要总结一下。就这四篇比较来看，其中Dremel和Hive相对容易理解些，Dynamo和ZooKeeper则相对深奥一些。  read more

from：http://www.programmer.com.cn/8606/

文/杨栋

本文系统地介绍和分析比较了业界主流的Yahoo! S4、StreamBase和Borealis三种流式计算系统，希望读者能从这些系统的设计中领悟到不同场景下流式计算所要解决的关键问题。

背景

非实时计算几乎都基于MapReduce计算框架，但MapReduce并不是万能的。对于搜索应用环境中的某些现实问题，MapReduce并不能很好地解决问题。 read more

最新版的HFile主要做了两个改进，这两个改进都主要是为了降低内存使用和启动时间，思路都是将它们切分为多个block，填满就写出去，这也降低了writer的内存占用：

1.      增加了树状结构的数据块索引(data block index)支持。原因是在数据块的索引很大时，很难全部load到内存，比如当前的一个data block会在data block indxe区域对应一个数据项，假设每个block 64KB，每个索引项64Byte，这样如果每条机器上存放了6TB数据，那么索引数据就得有6GB，因此这个占用的内存还是很高的。通过对这些索引以树状结构进行组织，只让顶层索引常驻内存，其他索引按需读取并通过LRU cache进行缓存，这样就不需要将全部索引加载到内存。  read more

译者：phylips@bmy 2011-10-1

出处：http://duanple.blog.163.com/blog/static/70971767201191661620641/

 
1.   序

本文翻译自：http://ofps.oreilly.com/titles/9781449396107/architecture.html

作为开源类BigTable实现。HBase目前已经应用在很多互联网公司中。

项目主页：http://hbase.apache.org/  read more

[说明：之前的那篇<<分布式系统领域经典论文翻译集>>颇显庞杂，涵盖内容五花八门，也有人提出不知道从哪开始。所以呢，就有了这一篇，主要以组成Hadoop生态系统的各组件为线索，串起了其中相对重要的那些论文，同时基本上也是按照从前往后的顺序由浅入深的，其中也包含了翻译集中所未出现的一些。这些文章中，标为(译)的那些是本人翻译的，标为(zz)的那些是其他人的译文或原创，剩余未标明的部分基本上是英文原文，可能会择其要者而译之。] read more

作者：phylips@bmy 2011-10-03 

[序：关于MapReduce的争论，这篇<<MapReduce和并行数据库，朋友还是敌人？(zz)>>已经进行了展开。不过我通常对这方面的内容持着浓厚的兴趣，所以还是再理一下，并将涉及的论文翻译了出来。]  read more

作者：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更擅长。 read more

       作者：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的细粒度容错性。  read more