improve wording; fix link

log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part1-what-is-a-log.md

@@ -65,7 +65,7 @@
 
 听起来有点难以晦涩，让我们更加深入的探讨，弄懂它的真正含义。
 
-[确定性](http://en.wikipedia.org/wiki/Deterministic_algorithm)（`deterministic `）意味着处理过程是与时间无关的，而且不会让任何其他『带外』输入（`"out of band" input`）影响其处理结果。
+[确定性](http://en.wikipedia.org/wiki/Deterministic_algorithm)（`deterministic`）意味着处理过程是与时间无关的，而且不会让任何其他『带外』输入（`"out of band" input`）影响其处理结果。
 例如，如果一个程序的输出会受到线程执行的具体顺序影响，或者受到`getTimeOfDay`调用、或者其他一些非重复性事件的影响，那么这样的程序一般被认为是非确定性的。
 
 > 【译注】更多关于带外（`out of band`）这个概念可以看看：

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

@@ -360,7 +360,7 @@
 
 最后，`Kafka`使用简单的二进制格式维护内存日志、磁盘日志和传送网络数据。这使得我们可以使用包括『[0拷贝的数据传输](https://www.ibm.com/developerworks/library/j-zerocopy)』在内的大量的优化机制。
 
-这些优化的积累效应是往往以磁盘和网络的速度（上限）在读写数据，即使维护的数据集大大超出内存大小。
+这些优化的积累起来的效应就是通常以磁盘和网络的速度上限在读写数据，即使维护的数据集大大超出了内存的大小。
 
 这些自卖自夸的介绍不意味着是关于`Kafka`的主要内容，我就不再深入细节了。
 `LinkedIn`方案的更细节说明在[这儿](http://sites.computer.org/debull/A12june/pipeline.pdf)，`Kafka`设计的详细说明在[这儿](http://kafka.apache.org/documentation.html#design)，你可以读一下。

log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part3-logs-and-real-time-stream-processing.md

@@ -14,12 +14,13 @@
 如果你是上世纪90年代晚期或者21世纪初[数据库](http://cs.brown.edu/research/aurora/vldb03_journal.pdf) [文化](http://db.cs.berkeley.edu/papers/cidr03-tcq.pdf)或者成功了一半的[数据](http://www-03.ibm.com/software/products/us/en/infosphere-streams) [基础设施](http://en.wikipedia.org/wiki/StreamBase_Systems) [产品](http://en.wikipedia.org/wiki/Truviso)的爱好者，那么你就可能会把流处理与建创`SQL`引擎或者『箱子和箭头』（`boxes and arrows`）接口用于事件驱动的处理联系起来。
 
 如果你关注大量出现的开源数据库系统，你就可能把流处理和一些这领域的系统关联起来，
-比如[`Storm`](http://storm-project.net/)、[`Akka`](http://akka.io/)、[`S4`](http://incubator.apache.org/s4)和[`Samza`](http://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying)。
+比如[`Storm`](http://storm-project.net/)、[`Akka`](http://akka.io/)、[`S4`](http://incubator.apache.org/s4)和`Samza`。
 但是大部分人会把这些系统看为异步消息处理系统，与支持群集的远程过程调用（`RPC`）层没什么差别
 （而事实上这一领域一些系统确实是如此）。
 
 这些观点都有一些局限性。流处理既与`SQL`无关，也不局限于实时流处理。
-并没有天然原因导致不能用多种不同的语言来表达计算，（或不能）处理一天的或一个月之前的流数据。
+并没有什么不可克服的原因（`inherent reason`）导致我们不能做到：
+通过多种不同的语言来表达计算（`express the computation`），处理一天前或一个月之前的数据流。
 
 <img src="images/19202244_GPDx.jpg" width="250" hspace="10px" align="right" >
 
@@ -50,7 +51,7 @@
 
 由此看来，对于流处理我很容易得出不同观点：
 它处理的是包含时间概念的底层数据并且不需要静态的数据快照，
-所以可以以用户可控频率生产输出而不是等待数据集『都』到达后再生产输出（**_【译注】_** 数据是会持续的，所以实际上不会有『都』达到的时间点）。
+所以可以以用户可控的频率来生产输出而不是等待数据集『都』到达后再生产输出（**_【译注】_** 数据是持续的，所以实际上不会有『都』达到的时间点）。
 从这个角度上讲，流处理是广义上的批处理，随着实时数据的流行，流处理会是很重要处理方式。
 
 那么，为什么流处理的传统观点大家之前会认为更合适呢？
@@ -78,7 +79,7 @@
 数据流图（`data flow graphs`）
 ------------------
 
-<img src="images/dag.png" width="250" hspace="10px" align="right" >
+<img src="images/dag.png" hspace="10px" align="right" >
 
 流处理最有趣的特点是它与流处理系统的内部组织无关，
 但是与之密切相关的是，流处理是怎么扩展了之前在数据集成讨论中提到的认识：输入数据（`data feed`）是什么。

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

@@ -70,7 +70,7 @@
 - [`Bookeeper`](http://zookeeper.apache.org/bookkeeper/) 和[`Hedwig`](http://zookeeper.apache.org/bookkeeper/) 另外的两个开源的『把日志作为服务』的项目。它们更关注的是数据库系统内部构件而不是事件数据。
 - [`Databus`](https://github.com/linkedin/databus)是提供类似日志的数据库表的覆盖层的系统。
 - [`Akka`](http://akka.io/) 是用于`Scala`的`Actor`框架。它有一个[事件驱动](https://github.com/eligosource/eventsourced)的插件，提供持久化和记录。
-- [`Samza`](http://storm-project.net/)是我们在`LinkedIn`中用到的流处理框架，它用到了本文论述的诸多理念，同时与`Kafka`集成来作为底层的日志。
+- [`Samza`](http://samza.apache.org/)是我们在`LinkedIn`中用到的流处理框架，它用到了本文论述的诸多理念，同时与`Kafka`集成来作为底层的日志。
 - [`Storm`](http://storm-project.net/)是广泛使用的可以很好的与`Kafka`集成的流处理框架之一。
 - [`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`之上的一层，提供了便利的计算抽象。