Merge pull request #46 from xuqinghan/xuqinghan-patch-1

improve wording

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

@@ -33,7 +33,7 @@
 最后，关注点会转移到更高级处理上 —— 更好的可视化、生成报表以及处理和预测算法。
 
 以我的经验，大多数组织在这个数据金字塔的底部存在巨大的漏洞 —— 缺乏可靠的完整的数据流 ——
-却想直接跳到高级数据模型技术上。这样做完全是本未倒置。
+却想直接跳到高级数据模型技术上。这样做完全是本末倒置。
 
 所以问题是，我们如何在组织中构建贯穿所有数据系统的可靠数据流？
 
@@ -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

@@ -18,8 +18,8 @@
 但是大部分人会把这些系统看为异步消息处理系统，与支持群集的远程过程调用（`RPC`）层没什么差别
 （而事实上这一领域一些系统确实是如此）。
 
-这些观点都有一些局限性。流处理即与`SQL`无关，也不局限于实时流处理。
-还没有根本的原因，限制你不能使用多种不同的语言来表达计算，处理昨天的或者一个月之前的流数据。
+这些观点都有一些局限性。流处理既与`SQL`无关，也不局限于实时流处理。
+并没有天然原因导致不能用多种不同的语言来表达计算，（或不能）处理一天的或一个月之前的流数据。
 
 <img src="images/19202244_GPDx.jpg" width="250" hspace="10px" align="right" >
 
@@ -50,7 +50,7 @@
 
 由此看来，对于流处理我很容易得出不同观点：
 它处理的是包含时间概念的底层数据并且不需要静态的数据快照，
-所以可以以用户可控频率生产输出而不是等待数据集的『都』到达后再生产输出（**_【译注】_** 数据是会持续的，所以实际上不会有『都』达到的时间点）。
+所以可以以用户可控频率生产输出而不是等待数据集『都』到达后再生产输出（**_【译注】_** 数据是会持续的，所以实际上不会有『都』达到的时间点）。
 从这个角度上讲，流处理是广义上的批处理，随着实时数据的流行，流处理会是很重要处理方式。
 
 那么，为什么流处理的传统观点大家之前会认为更合适呢？
@@ -58,9 +58,9 @@
 
 我觉得，是否缺少实时数据的收集决定了商用流处理系统的命运。
 当他们的客户还是用面向文件的每日批量处理完成`ETL`和数据集成时，
-建设流处理系统的公司专注于提供处理引擎来连接实时数据流，而结果是当时几乎没有人真地有实时数据流。
+建设流处理系统的公司专注于提供处理引擎来连接实时数据流，而结果是当时几乎没有人真的有实时数据流。
 其实我在`LinkedIn`工作的初期，有一家公司想把一个非常棒的流处理系统卖给我们，
-但是因为当时我们的所有数据都按小时收集在的文件里，
+但是因为当时我们的所有数据都在按小时收集的文件里，
 所以用上这个系统我们能做到的最好效果就是在每小时的最后把这些文件输入到流处理系统中。
 他们意识到这是个普遍问题。
 下面的这个异常案例实际上是证明上面规律：