diff --git a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part1-what-is-a-log.md b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part1-what-is-a-log.md index 88bb381..6fb5d36 100644 --- a/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part1-what-is-a-log.md +++ b/log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part1-what-is-a-log.md @@ -28,7 +28,8 @@ 讨论到现在，你可能奇怪为什么要讨论这么简单的概念？只能追加的有序的日志记录究竟又是怎样与数据系统生产关系的？ 答案是日志有其特定的目标：它记录了什么时间发生了什么事情。而对分布式数据系统，在许多方面，这是要解决的问题的真正核心。 -不过，在我们进行更加深入的讨论之前，让我先澄清有些让人混淆的概念。每个程序员都熟悉另一种日志记录的定义 —— 应用使用`syslog`或者`log4j`写入到本地文件里的无结构的错误信息或者追踪信息。为了区分，这种情形的称为『应用日志记录』。 +不过，在我们进行更加深入的讨论之前，让我先澄清有些让人混淆的概念。每个程序员都熟悉另一种日志记录的定义 —— +应用使用`syslog`或者`log4j`写入到本地文件里的无结构的错误信息或者追踪信息。为了区分，这种情形的称为『应用日志记录』。 应用日志记录是我说的日志概念的一种退化。两者最大的区别是：文本日志意味着主要用来方便人去阅读，而构建我所说的『日志（`journal`）』或者『数据日志（`data logs`）』是用于程序的访问。 （实际上，如果你深入地思考一下，会觉得人去阅读某个机器上的日志这样的想法有些落伍过时了。 @@ -84,7 +85,8 @@ 理论上来说，我们甚至可以记录各个副本执行的机器指令序列的日志 或是 所调用的方法名和参数序列的日志。 只要两个进程用相同的方式处理这些输入，这些副本进程就会保持一致的状态。 -对日志用法不同群体有不同的说法。数据库工作者通常说成**_物理_**日志（`physical logging`）和**_逻辑_**日志（`logical logging`）。物理日志是指记录每一行被改变的内容。逻辑日志记录的不是改变的行而是那些引起行的内容改变的`SQL`语句（`insert`、`update`和`delete`语句）。 +对日志用法不同群体有不同的说法。数据库工作者通常说成**_物理_**日志（`physical logging`）和**_逻辑_**日志（`logical logging`）。 +物理日志是指记录每一行被改变的内容。逻辑日志记录的不是改变的行而是那些引起行的内容改变的`SQL`语句（`insert`、`update`和`delete`语句）。 分布式系统文献通常把处理和复制（`processing and replication`）方案宽泛地分成两种。『状态机器模型』常常被称为主-主模型（`active-active model`）， 记录输入请求的日志，各个复本处理每个请求。 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 3b66301..6039a64 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 @@ -255,10 +255,10 @@ 例如，想为组织的所有的数据集提供搜索能力。 或者想为数据流的监控的次级监控（`sub-second monitoring`）添加实时数据趋势和告警。 无论是哪个情况，传统的数据仓库的基础设施，甚至是`Hadoop`集群都将不再适合。 -更糟的是，用于支持数据加载的`ETL`处理管道可能输入不了数据到其它系统， +更糟的是，用于支持数据加载的`ETL`处理管道可能不能提供有用的数据输入给其它系统中， 和带动不了要动用数据仓库这样的大企业下的那些基础设备。 这样的做法应该是不可行的，可能可以解释为什么多数组织对他们的所有数据很难轻松具备这样的能力。 -反之，如果组织能导出标准的结构良好的数据， +反之，如果组织能导出一致的结构良好的数据， 那么任何新的系统要使用所有数据仅仅需要提供一个用于集成的管道接到中央管道上即可。 关于数据规整化和转换在哪里进行，这种架构也引出了的不同观点： 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 a4f3cdb..deac074 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 @@ -82,7 +82,7 @@ 流处理最有趣的特点是它与流处理系统的内部组织无关， 但是与之密切相关的是，流处理是怎么扩展了之前在数据集成讨论中提到的认识：输入数据（`data feed`）是什么。 -我们主要讨论了原始数据（`primary data`）的`feeds` 或说 日志 —— 各种系统执行所产生的事件和数据行。 +我们主要讨论了原始数据输入（`primarily feeds`） 或说是 原始数据（`primary data`）的日志 —— 各种系统执行所产生的事件和数据行。 但是流处理允许我们包括了由其它`feeds`计算出的`feeds`。 在消费者看来，这些派生的`feeds`和 用于生成他们的原始数据的`feeds` 看下来没什么差别。 这些派生的`feeds`可以按任意的复杂方式封装组合。 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 2128050..20a6a9f 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 @@ -135,7 +135,7 @@ 上面几点合起来使得外部日志的开销相当小。 `LinkedIn`正是使用这个模式构建了它很多的实时查询系统。 -这些系统的数据来自数据库（使用作为日志概念的数据总线，或是来自`Kafka`的真正日志），提供了在这个数据流上特定的分片、索引和查询能力。 +这些系统的数据来源依赖于数据库（使用作为日志概念的数据总线，或是来自`Kafka`的真正日志），提供了在这个数据流上特定的分片、索引和查询能力。 这也是我们实现搜索、`social graph`和`OLAP`查询系统的方式。 事实上，把单个数据源（无论来自`Hadoop`的在线数据源还是派生数据源）复制到多个在线服务系统中，这个做法很常见。 这种方式经过了验证可以大大简化系统的设计。