审校Part 3

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

@@ -34,19 +34,42 @@
 处理批量转储的唯一方法就是批量的处理。
 但是随着这些批处理被持续的数据输入所取代，人们自然而然的开始向持续处理转变，以平滑地使用所需的处理资源并且减少延迟。
 
-例如LinkedIn几乎没有批量数据收集。大部分的数据或者是活动数据或者是数据库变更，这两者都是不间断发生的。事实上，你可以想到的任何商业，正如：Jack Bauer告诉我们的，低层的机制都是实时发生的不间断的流程事件。数据是成批收集的，它总是会依赖于一些人为的步骤，或者缺少数字化或者是一些自动化的非数字化流程处理的遗留信息。当传送和处理这些数据的机制是邮件或者人工的处理时，这一过程是非常缓慢的。首轮自动化总是保持着最初的处理形式，它常常会持续相当长的时间。
+例如在`LinkedIn`几乎完全没有批量数据收集。我们大部分的数据要么是活动数据或者要么是数据库变更，两者都是不间断地发生的。
+事实上，你想到的任何商业业务，底层的机制几乎都是不间断的处理，正如*Jack Bauer*所说的，事件的发生是实时的。
+当数据以成批的方式收集，几乎总是由这些原因所致：有一些人为的步骤；缺少数字化；或是非数字化流程的历史古董不能自动化。
+当使用邮件或者人工方式，传输和处理数据是非常缓慢的。刚开始转成自动化时，总是保持着原来流程的形式，所以这样的情况会持续相当长的时间。
 
-每天运行的批量处理作业常常是模拟了一种一天的窗口大小的不间断计算。当然，低层的数据也经常变化。在LinkedIn,这些是司空见贯的，并且使得它们在Hadoop运转的机制是有技巧的，所以我们实施了一整套管理增量的Hadoop工作流的架构。
+每天运行的『批量』处理作业常常在模拟一种窗口大小是一天的持续计算。
+当然，底层的数据其实总是在变化着的。
+在`LinkedIn`，这样的做法如此之常见（并且在`Hadoop`做到这些的实现机制如此之复杂），
+以至于我们实现了一整套[框架](http://engineering.linkedin.com/datafu/datafus-hourglass-incremental-data-processing-hadoop)来管理增量的`Hadoop`工作流。
 
-由此看来，对于流处理可以有不同的观点。流处理包括了在底层数据处理的时间概念，它不需要数据的静态快照，它可以产生用户可控频率的输出，而不用等待数据集的全部到达。从这个角度上讲，流处理就是广义上的批处理，随着实时数据的流行，会儿更加普遍。
+由此看来，对于流处理我很容易得出不同观点：
+流处理包含底层处理的数据时间概念并且不需要静态的数据快照，
+所以生产输出以用户可控频率而不是等待数据集的『全部』到达可以。
+从这个角度上讲，流处理是广义上的批处理，随着实时数据的流行，流处理会是很重要处理方式。
 
-这就是为什么从传统的视角看来流处理是利基应用。我个人认为最大的原因是缺少实时数据收集使得不间断的处理成为了学术性的概念。
+那么，为什么流处理的传统观点大家之前认为更合适呢？
+我个人认为最大的原因是缺少实时数据收集，使得持续处理之前是学术性的概念。
 
-我想缺少实时数据收集就像是商用流处理系统注定的命运。他们的客户仍然需要处理面向文件的、每日批量处理ETL和数据集成。公司建设流处理系统关注的是提供附着在实时数据流的处理引擎，但是最终当时极少数人真正使用了实时数据流。事实上，在我在LinkedIn工作的初期，有一家公司试图把一个非常棒的流处理系统销售给我们，但是因为当时我们的全部数据都按小时收集在的文件里，当时我们提出的最好的应用就是在每小时的最后把这些文件输入到流处理系统中。他们注意到这是一个普遍性的问题。这些异常证明了如下规则：流处理系统要满足的重要商业目标之一是：财务， 它是实时数据流已具备的基准，并且流处理已经成为了瓶颈。
+我觉得，是否缺少实时数据的收集决定了商用流处理系统的命运。
+当他们的客户还是用面向文件的每日批量处理完成`ETL`和数据集成时，
+建设流处理系统的公司专注于连接实时数据流的处理引擎，结果就会是当时几乎没有人真地有实时数据流。
+其实我在`LinkedIn`工作的初期，有一家公司想把一个非常棒的流处理系统卖给我们，
+但是因为当时我们的全部数据都按小时收集在的文件里，
+所以用上这个系统我们能做到的最好效果就是在每小时的最后把这些文件输入到流处理系统中。
+他们意识到这是个普遍问题。
+下面这个异常案例实际上是证明上面规律：
+流处理获得一些成功的一个领域 —— 金融领域，这个领域在过去，实时数据流就已经标准化，并且流处理已经成为了瓶颈。
 
-甚至于在一个健康的批处理系统中，流处理作为一种基础架构的实际应用能力是相当广泛的。它跨越了实时数据请求-应答服务和离线批量处理之间的鸿沟。现在的互联网公司，大约25%的代码可以划分到这个类型中。
+甚至于在一个健康的批处理的生态中，我认为作为一种基础设施风格，流处理的实际应用能力是相当广阔的。
+我认为它填补了实时数据请求/响应服务和离线批量处理之间的缺口。现代的互联网公司，我觉得大约25%的代码可以划分到这个情况。
 
-最终这些日志解决了流处理中绝大部分关键的技术问题。在我看来，它所解决的最大的问题是它使得多订阅者可以获得实时数据。对这些技术细节感兴趣的朋友，我们可以用开源的[Samza](http://samza.incubator.apache.org/),它是基于这些理念建设的一个流处理系统。这些应用的更多技术细节我们在[此文档](http://samza.incubator.apache.org/learn/documentation/0.7.0)中有详细的描述。
+最终结果是日志解决了一些流处理中最关键的技术问题，后面我会进一步讲述，
+但解决的最大的问题是日志使得多订阅者可以获得实时的数据输入。
+对这些技术细节感兴趣的朋友，我们可以用开源的[`Samza`](http://samza.incubator.apache.org/)，
+它正是基于这些理念建设的一个流处理系统。
+很多这方面的应用的更多技术细节我们在[此文档](http://samza.incubator.apache.org/learn/documentation/0.7.0)中有详细的描述。
 
 数据流图
 ------------------