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 b098e01..217cc5f 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
@@ -290,28 +290,28 @@
 每种类型都会捕获一个特定动作类型的独特属性。
 这样的方式覆盖从页面浏览、广告展示、搜索到服务调用、应用异常的方方面面。
 
-为了进一步理解这一优势，设想一个简单的场景 —— 显示在作业（`job`）页面提交的作业信息。
-作业页面应当只包括显示作业所需的逻辑。
-然而，在足够动态站点中，这个很容易就变成作业显示无关的额外逻辑成为点缀。
+为了进一步理解这一优势，设想一个简单的场景 —— 显示在工作职位页面提交的职位信息。
+职位页面应当只包括显示职位所需的逻辑。
+然而，在足够动态站点中，这很容易就变成与职位显示无关的额外逻辑的点缀。
 例如，我们将对如下的系统进行集成：
 
 1. 发送数据到`Hadoop`和数据仓库中，以做离线数据处理
 1. 浏览计数，确保查看者不是一个内容爬虫
-1. 聚合浏览信息，在作业提交者的分析页面显示
-1. 记录浏览信息，确保合适地设置了用户的推荐作业的展示上限（不想重复地展示同样内容给用户）
-1. 推荐系统可能需要记录浏览，以正确的跟踪作业的流行程度
+1. 聚合浏览信息，在职位提交者的分析页面显示
+1. 记录浏览信息，确保合适地设置了用户的推荐职位的展示上限（不想重复地展示同样内容给用户）
+1. 推荐系统可能需要记录浏览，以正确的跟踪职位的流行程度
 1. 等等
 
-用不了多久，简单的作业显示变得相当的复杂。
-与此同时，还要增加作业显示的其它终端 —— 移动终端应用等等 ——
+用不了多久，简单的职位显示变得相当的复杂。
+与此同时，还要增加职位显示的其它终端 —— 移动终端应用等等 ——
 这样的逻辑必须继续实现，复杂程度被不断地提升。
 更糟的是，我们需要交互的系统是多方需求交织缠绕在一起的 ——
-负责显示作业的工程师需要知道多个其它系统和功能，才可以确保集成的正确。
+负责显示职位的工程师需要知道多个其它系统和功能，才可以确保集成的正确。
 这里仅是简单描述了问题，实际应用系统只会更加复杂。
 
 『事件驱动』风格提供了简化这类问题的方案。
-作业显示页面现在只负责显示作业并记录显示作业的信息，如作业相关属性、页面浏览者及其它有价值的信息。
-其它所有关心这个信息的系统诸如推荐系统、安全系统、作业提交分析系统和数据仓库，只需订阅上面的输出数据进行各自的处理。
+职位显示页面现在只负责显示职位并记录显示职位的信息，如职位相关属性、页面浏览者及其它有价值的信息。
+其它所有关心这个信息的系统诸如推荐系统、安全系统、职位提交分析系统和数据仓库，只需订阅上面的输出数据进行各自的处理。
 显示代码并不需要关注其它的系统，也不需要因为增加了数据的消费者而做改变。
 
 构建可伸缩的日志