From 7761020a3f60cb2e61cb149de25151db9fa50764 Mon Sep 17 00:00:00 2001 From: Jerry Lee Date: Mon, 3 Aug 2015 20:29:03 +0800 Subject: [PATCH] unify translation for term job #7 --- .../part2-data-integration.md | 26 +++++++++---------- ...t3-logs-and-real-time-stream-processing.md | 10 +++---- 2 files changed, 18 insertions(+), 18 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 2fb0678..51365b6 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 @@ -291,28 +291,28 @@ 每种类型都会捕获一个特定动作类型的独特属性。 这样的方式覆盖从页面浏览、广告展示、搜索到服务调用、应用异常的方方面面。 -为了进一步理解这一优势，设想一个简单的场景 —— 显示在任务页面提交的任务信息。 -任务页面应当只包括显示任务所需的逻辑。 -然而，在足够动态站点中，任务页面很容易就变成任务显示无关的额外逻辑成为点缀。 +为了进一步理解这一优势，设想一个简单的场景 —— 显示在作业（`job`）页面提交的作业信息。 +作业页面应当只包括显示作业所需的逻辑。 +然而，在足够动态站点中，这个很容易就变成作业显示无关的额外逻辑成为点缀。 例如，我们将对如下的系统进行集成： -- 发送数据到`Hadoop`和数据仓库中，做离线数据处理 -- 浏览计数，确保查看者不是一个内容爬虫 -- 聚合浏览信息，在任务提交者的分析页面显示 -- 记录浏览信息，确保给用户推荐系统输入的是有效的展示（不想展示重复同样内容给用户） -- 推荐系统可能需要记录浏览，以正确的跟踪任务的流行程度 -- 等等 +1. 发送数据到`Hadoop`和数据仓库中，以做离线数据处理 +1. 浏览计数，确保查看者不是一个内容爬虫 +1. 聚合浏览信息，在作业提交者的分析页面显示 +1. 记录浏览信息，确保合适地设置了用户的推荐作业的展示上限（不想重复地展示同样内容给用户） +1. 推荐系统可能需要记录浏览，以正确的跟踪作业的流行程度 +1. 等等 -有不了多久，简单的任务显示变得相当的复杂。 -与此同时，还要增加任务显示的其它终端 —— 移动终端应用等等 —— +有不了多久，简单的作业显示变得相当的复杂。 +与此同时，还要增加作业显示的其它终端 —— 移动终端应用等等 —— 这样的逻辑必须继续实现，复杂程度被不断地提升。 更糟的是，我们需要交互的系统是多方需求交织缠绕在一起的 —— 负责显示作业的工程师需要知道多个其它系统和功能，才可以确保集成的正确。 这里仅是简单描述了问题，实际应用系统只会更加复杂。 『事件驱动』风格提供了简化这类问题的方案。 -任务显示页面现在只负责显示作业并记录显示任务的信息，如任务相关属性、页面浏览者及其它有价值的信息。 -其它所有关心这个信息的系统诸如推荐系统、安全系统、任务提交分析系统和数据仓库，只需订阅上面输出的数据进行各自的处理。 +作业显示页面现在只负责显示作业并记录显示作业的信息，如作业相关属性、页面浏览者及其它有价值的信息。 +其它所有关心这个信息的系统诸如推荐系统、安全系统、作业提交分析系统和数据仓库，只需订阅上面输出的数据进行各自的处理。 显示代码并不需要关注其它的系统，也不需要因为增加了数据的消费者而做改变。 构建可伸缩的日志 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 c422b28..56402eb 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 @@ -88,7 +88,7 @@ 这些派生的数据输入可以按任意的复杂方式封装组合。 让我们再深入一点这个问题。 -对于我们的目标，流处理任务是指从日志读取数据和将输出写入到日志或其它系统的任何系统。 +对于我们的目标，流处理作业是指从日志读取数据和将输出写入到日志或其它系统的任何系统。 用于输入和输出的日志把这些处理系统连接成一个处理阶段的图。 事实上，以这样的风格使用中心化的日志，你可以把组织全部的数据抓取、转化和工作流仅仅看成是一系列的写入它们的日志和处理过程。 @@ -102,13 +102,13 @@ 为了更具体地说明，设想一下从数据库中更新数据流 —— 如果在处理过程中把对同一记录的两次更新重新排序，可能会产生错误的输出。 这里的有序的持久性要强于`TCP`之类所提供的有序，因为不局限于单一的点对点链接，并且在流程处理失败和重连时仍然要保持。 -第二，日志提供了处理流程的缓冲。 -这是非常基础重要的。如果处理流程是非同步的，那么上行流数据的任务生成数据可能比下行流数据任务所能消费的更快。 +其次，日志提供了处理流程的缓冲。 +这是非常基础重要的。如果处理流程是非同步的，那么生成上行流数据的作业生成数据可能比另一个下行流数据作业所能消费的更快。 这种情况下，要么使处理进程阻塞，要么引入缓冲区，要么丢弃数据。 丢弃数据似乎不是个好的选择，而阻塞处理进程，会使得整个的数据流的图被迫中止处理。 日志是一个非常非常大的缓冲，允许处理进程的重启或是失败，而不影响流处理图中的其它部分的处理速度。 -要扩展数据流到一个更庞大的组织，这种隔离性极其重要，整个处理是由组织中不同的团队提供的处理任务完成的。 -不能因为某个任务发生错误导致影响前面任务，结果整个处理流程都被卡住。 +要扩展数据流到一个更庞大的组织，这种隔离性极其重要，整个处理是由组织中不同的团队提供的处理作业完成的。 +不能因为某个作业发生错误导致影响前面作业，结果整个处理流程都被卡住。 [`Storm`](http://storm-project.net/)和[`Sama`](http://samza.apache.org/)都是按这种风格构建，能用`kafka`或其它类似的系统作为它们的日志。