From 3995a7132306d2c4d0ffbc834992cd1fe2ceb388 Mon Sep 17 00:00:00 2001 From: Jerry Lee Date: Fri, 28 Aug 2015 13:42:50 +0800 Subject: [PATCH] review translation of 'partition' #9 --- .../part2-data-integration.md | 8 ++++---- .../part3-logs-and-real-time-stream-processing.md | 4 ++-- .../part4-system-building.md | 12 ++++++------ .../the-end.md | 5 ++++- 4 files changed, 16 insertions(+), 13 deletions(-) diff --git a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part2-data-integration.md b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part2-data-integration.md index 3b1d017..ac16e58 100644 --- a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part2-data-integration.md +++ b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part2-data-integration.md @@ -198,7 +198,7 @@ 在相当长的时间内，`Kafka`是独一无二的（有人会说是怪异） —— 作为一个底层设施，它既不是数据库，也不是日志文件收集系统，更不是传统的消息系统。 但是最近`Amazon`提供了非常非常类似`Kafka`的服务，称之为[`Kinesis`](http://aws.amazon.com/kinesis)。 -相似度包括了分片处理的方式，数据的持有方式，甚至包括有点特别的`Kafka API`分类（分成高端和低端消费者）。 +相似度包括了分片（`partition`）处理的方式，数据的持有方式，甚至包括有点特别的`Kafka API`分类（分成高端和低端消费者）。 我很开心看到这些，这表明了你已经创建了很好的底层设施抽象，`AWS`已经把它作为服务提供！ 他们对此的想法看起来与我所描述的完全吻合： 管道联通了所有的分布式系统，诸如`DynamoDB`,`RedShift`,`S3`等，同时作为使用`EC2`进行分布式流处理的基础。 @@ -337,11 +337,11 @@ ![](images/partitioned_log.png) -每个切片的日志是有序的，但是分片之间没有全局的次序（这个有别于在你的消息中可能包含的挂钟时间）。 -由写入者决定消息发送到特定的日志片段，大部分使用者以某种键值（如用户`id`）来进行分片。 +每个分片的日志是有序的，但是分片之间没有全局的次序（这个有别于在你的消息中可能包含的挂钟时间）。 +由写入者决定消息发送到特定的日志分片，大部分使用者以某种键值（如用户`id`）来进行分片。 追加日志时，分片方式在片段之间可以不需要协调，并且可以使系统的吞吐量与`Kafka`集群大小线性增长。 -每个分片通过可配置数字指定数据复制的复本个数，每个复本都有分片的完全一致一份拷贝。 +每个分片通过可配置数字指定数据复制的复本个数，每个复本都有一个分片日志完全一致的一份拷贝。 任何时候都有一个复本作为`leader`，如果`leader`出错了，会有一个复本接替成为`leader`。 缺少跨分片的全局顺序是个局限，但是我们没有发现它成为大问题。 diff --git a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part3-logs-and-real-time-stream-processing.md b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part3-logs-and-real-time-stream-processing.md index f3965b3..cbd5ccb 100644 --- a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part3-logs-and-real-time-stream-processing.md +++ b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part3-logs-and-real-time-stream-processing.md @@ -137,14 +137,14 @@ 甚至是些更不常见的组件，如[`Lucene`](http://lucene.apache.org/) 或[`fastbit`](https://sdm.lbl.gov/fastbit)索引。 这样一些存储的内容可以从它的输入流生成（可能做过了各种转换后的输入流）。 通过记录关于本地索引的变更日志，在发生崩溃、重启时也可以恢复它的状态。 -这是个通用的机制，用于保持 任意索引类型的协作分片（`co-partitioned`）的本地状态 与 输入流数据 一致。 +这是个通用的机制，用于保持 任意索引类型的分片之间相互协作（`co-partitioned`）的本地状态 与 输入流数据 一致。 当处理流程失败时，可以从变更日志中恢复它的索引。 每次备份时，即是日志把本地状态转化成一种增量记录。 这种状态管理方案的优雅之处在于处理器的状态也是做为日志来维护。 我们可以把这个日志看成是数据库表变更的日志。 -事实上，这些处理器本身就很像是自维护的协作分片的表。 +事实上，这些处理器本身就很像是自维护的分片之间相互协作的表。 因为这些状态本身就是日志，所以其它处理器可以订阅它。 如果处理流程的目标是更新结点的最后状态并且这个状态又是流程的一个自然的输出，那么这种方式就显得尤为重要。 diff --git a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part4-system-building.md b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part4-system-building.md index d460ba8..2128050 100644 --- a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part4-system-building.md +++ b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part4-system-building.md @@ -83,7 +83,7 @@ 这就是一个数据分布式系统所要做的主要部分，实际上，剩下的大部分内容是与 最终用户要面对的查询`API`和索引策略相关的。 -这正是不同系统间的应该变化的部分，例如：一个全文搜索查询语句可能需要查询所有的分区， +这正是不同系统间的应该变化的部分，例如：一个全文搜索查询语句可能需要查询所有分区， 而一个主键查询只需要查询负责这个主键数据的单个节点就可以了。 @@ -92,7 +92,7 @@ 系统被分为两个逻辑部分：日志和服务层。日志按顺序捕获状态变化。 服务节点存储索引提供查询服务需要的所有信息（比如键值存储的索引可能会类似`BTree`或`SSTable`，搜索系统可能用的是倒排索引（`inverted index`））。 写入操作可以直接进入日志，尽管可能经过服务层的代理。 -在写入日志的时候会生成逻辑时间戳（称为日志中的索引），如果系统是分区的，我假定是会分区， +在写入日志的时候会生成逻辑时间戳（称为日志中的索引），如果系统是分区的，我也假定是分区的， 那么日志和服务节点会包含相同分区个数，尽管两者的机器台数可能相差很多。 服务节点订阅日志，并按照日志存储的顺序尽快把日志写到它的本地索引中。 @@ -104,8 +104,8 @@ 服务节点可能会或可能不会需要感知`master`身份或是当选`leader`。 对很多简单的使用场景，服务节点集群可以完全无需`leader`，因为日志是正确真实的信息源。 -分布式系统所需要处理的一件比较复杂的事是 恢复失败节点 和 在结点之间移动分区。 -典型的做法是仅保留一个固定窗口的数据，并把这个数据和分区中存储数据的一个快照关联。 +分布式系统所需要处理的一件比较复杂的事是 恢复失败节点 和 在结点之间移动分片（`partition`）。 +典型的做法是仅保留一个固定窗口的数据，并把这个数据和分片中存储数据的一个快照关联。 另一个相同效果的做法是，让日志保留数据的完整拷贝，并[对日志做垃圾回收](https://cwiki.apache.org/confluence/display/KAFKA/Log+Compaction)。 这把大量的复杂性从特定于系统的系统服务层移到了通用的日志中。 @@ -135,12 +135,12 @@ 上面几点合起来使得外部日志的开销相当小。 `LinkedIn`正是使用这个模式构建了它很多的实时查询系统。 -这些系统的数据来自数据库（使用作为日志概念的数据总线，或是来自`Kafka`的真正日志），提供了在这个数据流上特定的分区、索引和查询能力。 +这些系统的数据来自数据库（使用作为日志概念的数据总线，或是来自`Kafka`的真正日志），提供了在这个数据流上特定的分片、索引和查询能力。 这也是我们实现搜索、`social graph`和`OLAP`查询系统的方式。 事实上，把单个数据源（无论来自`Hadoop`的在线数据源还是派生数据源）复制到多个在线服务系统中，这个做法很常见。 这种方式经过了验证可以大大简化系统的设计。 系统根本不需要给外部提供写入`API`，`Kafka`和数据库通过日志给查询系统提供记录和变更流。 -各个分区的结点在本地完成写操作。 +各个分片的结点在本地完成写操作。 这些结点只要机械地把日志中的数据转录到自己的存储中。失败的结点通过回放上游的日志就可以恢复。 系统的强度取决于日志的使用方式。一个完全可靠的系统把日志用作数据分片、结点的存储、负载均衡，以及所有和数据一致性和数据传播（`propagation`）有关的方面。 diff --git a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/the-end.md b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/the-end.md index ff07cc8..925adb6 100644 --- a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/the-end.md +++ b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/the-end.md @@ -51,7 +51,10 @@ 企业级软件存在着同样的问题，只是名称不同，或者规模较小，或者是`XML`格式的。哈哈，开个玩笑。 -- [事件驱动](http://cs.brown.edu/research/aurora/hwang.icde05.ha.pdf) —— 据我所知：它就是企业级应用的工程师们常说的『状态机的复现』。有趣的是同样的理念会用在如此迥异的场景中。事件驱动关注的是小的、内存中的使用场景。这种机制在应用开发中看起来是把发生在日志事件中的『流处理』和应用关联起来。因此变得不那么琐碎：当处理的规模大到需要数据分片时，我关注的是流处理作为独立的首要的基础设施。 +- [事件驱动](http://cs.brown.edu/research/aurora/hwang.icde05.ha.pdf) —— + 据我所知：它就是企业级应用的工程师们常说的『状态机的复现』。有趣的是同样的理念会用在如此迥异的场景中。事件驱动关注的是小的、内存中的使用场景。 + 这种机制在应用开发中看起来是把发生在日志事件中的『流处理』和应用关联起来。因此变得不那么琐碎： + 当处理的规模大到需要数据分片时，我关注的是流处理作为独立的首要的基础设施。 - [变更数据捕获](http://en.wikipedia.org/wiki/Change_data_capture) —— 在数据库之外会有些对于数据的舍入处理，这些处理绝大多数都是日志友好的数据扩展。 - [企业级应用集成](http://en.wikipedia.org/wiki/Enterprise_application_integration)，当你有一些现成的类似客户类系管理`CRM`和供应链管理`SCM`的软件时，它似乎可以解决数据集成的问题。 - [复杂事件处理（`CEP`）](http://en.wikipedia.org/wiki/Complex_event_processing)没有人知道它的确切涵义或者它与流处理有什么不同。这些差异看起来集中在无序流和事件过滤、发现或者聚合上，但是依我之见，差别并不明显。我认为每个系统都有自己的优势。