Merge pull request #50 from crane-yuan/master: Fix some spelling mistakes.

log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part2-data-integration.md

@@ -88,7 +88,7 @@
 日志也起到缓冲的作用，使数据的生产异步于数据的消费。有许多原因使得这一点很重要，特别是在多个订阅方消费数据的速度各不相同的时候。
 这意味着一个数据订阅系统可以宕机或是下线维护，在重新上线后再赶上来：订阅方可以按照自己的节奏来消费数据。
 批处理系统如`Hadoop`或者是一个数据仓库，或许只能每小时或者每天消费一次数据，而实时查询系统可能需要及时到秒。
-无论是起始的数据源还是日志都感知感知各种各样的目标数据系统，所以消费方系统的添加和删除无需去改变传输管道。
+无论是起始的数据源还是日志都感知各种各样的目标数据系统，所以消费方系统的添加和删除无需去改变传输管道。
 
 特别重要的是：目标系统只知道日志，而不知道来源系统的任何细节。
 无论是数据来自于一个`RDBMS`、一种新型的键值存储，还是由一个不包含任何类型实时查询的系统所生成的，消费方系统都无需关心。

log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part4-system-building.md

@@ -40,7 +40,7 @@
 
 第一种可能性是延续现状：各个分离的系统在往后很长的一段时间里基本保持不变。
 发生这种可能要么是因为建设分布式系统的困难很难克服，
-要么系统的专用化（`specialization`）能让各个系统的便得性（`convenience`）和能力（`power`）达到一个新的高度。
+要么系统的专用化（`specialization`）能让各个系统的便利性（`convenience`）和能力（`power`）达到一个新的高度。
 只要现状不变，为了能够使用数据，数据集成问题将仍会最核心事情之一。
 如果是这样，用于集成数据的外部日志将会非常的重要。
 
@@ -61,7 +61,7 @@
 - [`Lucene`](http://lucene.apache.org/)和[`LevelDB`](https://code.google.com/p/leveldb)等嵌入式类库做为索引。
 - [`Netty`](http://netty.io/)、[`Jetty`](http://www.eclipse.org/jetty) 和 更高层封装如[`Finagle`](http://twitter.github.io/finagle)、[`rest.li`](http://rest.li/)处理远程通信。
 - [`Avro`](http://avro.apache.org/)、[`Protocol Buffers`](https://code.google.com/p/protobuf)、[`Thrift`](http://thrift.apache.org/)和[`umpteen zillion`](https://github.com/eishay/jvm-serializers/wiki)等其它类库处理序列化。
-- [`Kafka`](http://kafka.apache.org/)和[`Bookeeper`](http://zookeeper.apache.org/bookkeeper)提供后端支持的日志。
+- [`Kafka`](http://kafka.apache.org/)和[`Bookeeper`](https://bookkeeper.apache.org/)提供后端支持的日志。
 
 如果你把上面这些叠成一堆，换个角度去看，它会有点像是乐高版（`lego version`）的分布式数据系统工程。
 你可以把这些零件拼装在一起，创建大量的可能的系统。

log-what-every-software-engineer-should-know-about-real-time-datas-unifying/the-end.md

@@ -2,9 +2,9 @@
 =============================
 
 1. [学术论文、系统、讨论和博客](#学术论文系统讨论和博客)
-1. [一些相关的开源软件](#一些相关的开源软件)
+1. [值得关注的开源软件](#值得关注的开源软件)
 
-如果你从头一直做读到了这，那么我对日志的理解你大部分都知道了。
+如果你从头一直读到了这，那么我对日志的理解你大部分都知道了。
 
 这里再给一些有意思参考资料，你可以再去看看。
 
@@ -25,11 +25,11 @@
     这个链接并没有太多的信息，但 _Martin Odersky_ （`Scala`大拿）讲授的[这个课程](https://www.coursera.org/course/reactive)很精彩。
 - `Paxos`!
     1. 原论文在[这里](http://research.microsoft.com/en-us/um/people/lamport/pubs/lamport-paxos.pdf)。
-        _Leslie Lamport_ 有一个有趣的历史：在80年代算法是如何发现的，但是直到1998年才发表了，因为评审组不喜欢论文中的希腊寓言，而作者又不愿修改。
-    2. 甚至于论文发布以后，它还是不被人们理解。_Lamport_ 再次尝试，这次它包含了一些并不有趣的小细节，这些细节是关于如何使用这些新式的自动化的计算机的。
-        它仍然没有得到广泛的认可。
+        关于作者 _Leslie Lamport_ 发表的这篇论文有个有趣的[历史](http://research.microsoft.com/en-us/um/people/lamport/pubs/pubs.html#lamport-paxos)：他在80年代就发明了这个算法，但直到1998年才发表出论文，原因是评审组不喜欢论文中的希腊寓言，而他又不愿修改。
+    2. 甚至于论文发布以后，人们还是不怎么理解。_Lamport_ [再次尝试](http://research.microsoft.com/en-us/um/people/lamport/pubs/paxos-simple.pdf)，这次甚至包含了一些『无趣的细节』，关于如何在新型自动化计算机上应用算法的细节。
+        但算法仍然没有得到广泛的理解。
     3. [_Fred Schneider_](http://www.cs.cornell.edu/fbs/publications/SMSurvey.pdf)和[_Butler Lampson_](http://research.microsoft.com/en-us/um/people/blampson/58-consensus/Abstract.html)分别给出了更多细节关于在实时系统中如何应用`Paxos`。
-    4. 一些`Google`的工程师总结了他们在`Chubby`中实施`Paxos`的[经验](http://www.cs.utexas.edu/users/lorenzo/corsi/cs380d/papers/paper2-1.pdf)。
+    4. 一些`Google`的工程师总结了他们在`Chubby`中实现`Paxos`的[经验](http://www.cs.utexas.edu/users/lorenzo/corsi/cs380d/papers/paper2-1.pdf)。
     5. 我发现所有关于`Paxos`的论文理解起来很痛苦，但是值得我们费大力气弄懂。你不必忍受这样的痛苦了，因为日志结构的文件系统的大师[_John Ousterhout_](http://www.stanford.edu/~ouster/cgi-bin/papers/lfs.pdf)的[这个视频](https://www.youtube.com/watch?v=JEpsBg0AO6o) 让这一切变得相当的容易。这些一致性算法用展开的通信图表述的更好，而不是在论文中通过静态的描述来说明。颇为讽刺的是，这个视频录制的初衷是告诉人们`Paxos`很难理解。
     6. [使用`Paxos`来构造规模一致的数据存储](http://arxiv.org/pdf/1103.2408.pdf)。这是一篇很棒的介绍使用日志来构造数据存储的文章，_Jun_ 是文章的共同作者之一，他也是`Kafka`最早期的工程师之一。
 - `Paxos`有很多的竞争者。如下诸项可以更进一步的映射到日志的实施，更适合于实用性的实施。
@@ -64,7 +64,7 @@
 - [复杂事件处理（`CEP`）](http://en.wikipedia.org/wiki/Complex_event_processing)没有人知道它的确切涵义或者它与流处理有什么不同。这些差异看起来集中在无序流和事件过滤、发现或者聚合上，但是依我之见，差别并不明显。我认为每个系统都有自己的优势。
 - [企业服务总线（`ESB`）](http://en.wikipedia.org/wiki/Enterprise_service_bus) —— 我认为企业服务总线的概念类似于我所描述的数据集成。在企业级软件社区中这个理念取得了一定程度的成功，对于从事网络和分布式基础架构的工程师们这个概念还是很陌生的。
 
-### 一些相关的开源软件
+### 值得关注的开源软件
 
 - [`Kafka`](http://kafka.apache.org/)是把日志作为服务的一个项目，是后边所列各项的基础。
 - [`Bookeeper`](http://zookeeper.apache.org/bookkeeper/) 和[`Hedwig`](http://zookeeper.apache.org/bookkeeper/) 另外的两个开源的『把日志作为服务』的项目。它们更关注的是数据库系统内部构件而不是事件数据。
@@ -75,7 +75,7 @@
 - [`Spark Streaming`](http://spark.incubator.apache.org/docs/0.7.3/streaming-programming-guide.html)一个流处理框架，是[`Spark`](http://spark.incubator.apache.org/)的一部分。
 - [`Summingbird`](https://blog.twitter.com/2013/streaming-mapreduce-with-summingbird)是在`Storm`或`Hadoop`之上的一层，提供了便利的计算抽象。
 
-对于这一领域，我将持续关注，如何您知道一些我遗漏的内容，请您告知。
+对于这一领域，我将持续关注，如果您知道一些我遗漏的内容，请您告知。
 
 最后我留给你的信息是这个： :smile_cat:  
 [![The Log Song - Ren & Stimpy (Deadwood HoN)](images/log_song.png)](https://www.youtube.com/watch?v=2C7mNr5WMjA)