backup/translations
1
0
Fork 0
mirror of https://github.com/oldratlee/translations.git synced 2026-11-05 15:07:28 +08:00
Code Issues Projects Releases Wiki Activity

审校Part 3

Browse Source
This commit is contained in:
Jerry Lee
2015-07-20 16:07:36 +08:00
parent 8c09b38570
commit 7bf7cec6b4
3 changed files with 27 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
log-what-every-software-engineer-should-know-about-real-time-datas-unifying/README.md
View File

@@ -44,6 +44,6 @@
- [`ETL`与数据仓库的关系](part2-data-integration.md#etl与数据仓库的关系)
- [日志文件与事件](part2-data-integration.md#日志文件与事件)
- [构建可伸缩的日志](part2-data-integration.md#构建可伸缩的日志)
- [第三部分：日志和实时流处理](part3-logs-and-real-time-stream-processing.md)
- [第三部分：日志与实时流处理](part3-logs-and-real-time-stream-processing.md)
- [第四部分：系统建设](part4-system-building.md)
- [结束语](the-end.md)

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

@@ -104,10 +104,10 @@
我发现『发布订阅』只是表达出了消息的间接寻址（`indirect addressing of messages`） ——
如果你去比较两个发布-订阅的消息系统的话，会发现他们承诺的是完全不同的东西，而且大多数模型在这一领域没什么用。
你可以认为日志是一种有持久性保证和强有序（`strong ordering`）语义的消息系统。
在分布式系统中，这个通信模型有时有个（有些可怕的）名字叫做[原子广播](http://en.wikipedia.org/wiki/Atomic_broadcast)。
在分布式系统中，这个通信模型有时有个（有些可怕的）名字叫做[原子广播（`atomic broadcast`）](http://en.wikipedia.org/wiki/Atomic_broadcast)。
值得强调的是，日志仍然只是基础设施。并不是掌握数据流这个故事的结束：
故事的其余部分围绕着元数据（`metadata`)、`schemas`、兼容性（`compatibility`）以及处理数据结构及其演化的所有细节。
故事的其余部分围绕着元数据（`metadata`)、`schemas`、兼容性以及处理数据结构及其演化的所有细节。
除非有一种可靠的通用的方法来处理数据流的机制，否则语义的细节总是次要的。
在`LinkedIn`
@@ -357,7 +357,7 @@
这些优化的积累效应是往往以磁盘和网络的速度在读写数据，即使维护的数据集大大超出内存大小。
这些自卖自夸的介绍不意味着这些是关于`Kafka`的主要内容，我就不再深入细节了。
这些自卖自夸的介绍不意味着是关于`Kafka`的主要内容，我就不再深入细节了。
`LinkedIn`方案的更细节说明在[这儿](http://sites.computer.org/debull/A12june/pipeline.pdf)，`Kafka`设计的详细说明在[这儿](http://kafka.apache.org/documentation.html#design)，你可以读一下。
-----------------

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

@@ -1,25 +1,38 @@
第三部分：日志和实时流处理
第三部分：日志与实时流处理
=================================
到此为止，我只是描述从端到端数据复制的理想机制。但是在存储系统中搬运字节不是所要讲述内容的全部。最终我们发现日志是流的另一种说法，日志是[流处理](http://highlyscalable.wordpress.com/2013/08/20/in-stream-big-data-processing/)的核心。
到目前为止，我只讲述了系统之间拷贝数据的理想机制。但是在存储系统之间搬运字节不是所要讲述内容的全部。
最终会发现，『日志』是流的另一种说法，
并且日志是[流处理](http://highlyscalable.wordpress.com/2013/08/20/in-stream-big-data-processing/)的核心。
但是，等等，什么是流处理呢？
但是，等会儿，流处理到底是什么呢？
如果你是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引擎或者创建“箱子和箭头”接口用于事件驱动的处理等联系起来。
如果你是上世纪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`](http://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying)。
但是大部分人会把这些系统看为异步消息处理系统，与支持群集的远程过程调用（`RPC`）层没什么差别
（而事实上这一领域一些系统确实是如此）。
这些视图都有一些局限性。流处理与SQL是无关的。它也局限于实时流处理。不存在内在的原因限制你不能处理昨天的或者一个月之前的流数据，且使用多种不同的语言表达计算。
这些观点都有一些局限性。流处理即与`SQL`无关，也不局限于实时流处理。
还没有根本的原因，限制你不能使用多种不同的语言来表达计算，处理昨天的或者一个月之前的流数据。
<img src="images/19202244_GPDx.jpg" width="250" hspace="10px" align="right" >
我把流处理视为更广泛的概念：持续数据流处理的基础架构。我认为计算模型可以像MapReduce或者分布式处理架构一样普遍，但是有能力处理低时延的结果。
我把流处理视为更广泛的概念：持续数据流处理的基础架构。
我认为计算模型可以像`MapReduce`或者分布式处理架构一样通用，但是有能力生成低时延的结果。
处理模型的实时驱动是数据收集方法。成批收集的数据是分批处理的。数据是不断收集的，它也是按顺序不断处理的。
处理模型的真正驱动力是数据收集方法。成批收集数据自然是批处理。当数据是持续收集的，自然也应该持续不断地处理。
美国的统计调查就是成批收集数据的良好典范。统计调查周期性的开展，通过挨门挨户的走访，使用蛮力发现和统计美国的公民信息。1790年统计调查刚刚开始时这种方式是奏效的。那时的数据收集是批处理的，它包括了骑着马悠闲的行进，把信息写在纸上，然后把成批的记录传送到人们统计数据的中心站点。现在，在描述这个统计过程时，人们立即会想到为什么我们不保留出生和死亡的记录，这样就可以产生人口统计信息这些信息或是持续的或者是其它维度的。
美国的统计调查是一个成批收集数据的好例子。
统计调查周期性的开展，用的是蛮力调查，通过挨门挨户的走访统计美国的公民信息。
在1790年统计调查刚刚开始，这样做是很合理的。
那时的数据收集本质就是面向批处理的，包括了骑马到周边人家，用纸笔记录，然后把成批的记录运输到人们统计数据的中心站点。
现在，在描述这个统计过程时，人们立即会想到为什么我们不保留出生和死亡的记录，这样就可以算出人口统计信息，这些信息或是持续即时计算出来或者按需要时间隔计算。
这是一个极端的例子，但是大量的数据传送处理仍然依赖于周期性的转储，批量转化和集成。处理大容量转储的唯一方法就是批量的处理。但是随着这些批处理被持续的供给所取代，人们自然而然的开始不间断的处理以平滑的处理所需资源并且消除延迟。
这是一个极端的例子，但是现在大量的数据传输处理仍然依赖于周期性的转储、批量传输和集成。
处理批量转储的唯一方法就是批量的处理。
但是随着这些批处理被持续的数据输入所取代，人们自然而然的开始向持续处理转变，以平滑地使用所需的处理资源并且减少延迟。
例如LinkedIn几乎没有批量数据收集。大部分的数据或者是活动数据或者是数据库变更，这两者都是不间断发生的。事实上，你可以想到的任何商业，正如：Jack Bauer告诉我们的，低层的机制都是实时发生的不间断的流程事件。数据是成批收集的，它总是会依赖于一些人为的步骤，或者缺少数字化或者是一些自动化的非数字化流程处理的遗留信息。当传送和处理这些数据的机制是邮件或者人工的处理时，这一过程是非常缓慢的。首轮自动化总是保持着最初的处理形式，它常常会持续相当长的时间。