From 134b01a9fb290dd7103f79d5a7eb455e68836591 Mon Sep 17 00:00:00 2001 From: Jerry Lee Date: Mon, 5 Oct 2015 14:26:59 +0800 Subject: [PATCH] add info for Anna Karenina principle --- .../part2-data-integration.md | 16 +++++++++++----- ...part3-logs-and-real-time-stream-processing.md | 2 +- 2 files changed, 12 insertions(+), 6 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 c2a67fa..f482ca9 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 @@ -15,7 +15,7 @@ **数据集成 是指 使一个组织的所有数据 对 这个组织的所有的服务和系统 可用。** 『数据集成』还不是一个常见的用语，但是我找不到一个更好的。大家更熟知的术语[`ETL`](http://en.wikipedia.org/wiki/Extract,_transform,_load) -（**_【译注】_**：`ETL`是`Extraction-Transformation-Loading`的缩写，即数据提取、转换和加载） +（**_【译注】_** `ETL`是`Extraction-Transformation-Loading`的缩写，即数据提取、转换和加载） 通常只是覆盖了数据集成的一个有限子集 —— 主要在关系型数据仓库的场景。但我描述的东西很大程度上可以理解为，将`ETL`推广至覆盖实时系统和处理流程。 @@ -95,9 +95,15 @@ 这似乎是一个小问题，但实际上却是至关重要的。 > - -> [『每个工作的数据管道要设计得像是一个日志；每个损坏的数据管道都以其自己的方式损坏。』 -> —— _Count Leo Tolstoy_ （由作者翻译）](http://en.wikipedia.org/wiki/Anna_Karenina_principle) + +> +> [『Each working data pipeline is designed like a log; each broken data pipeline is broken in its own way.』 +『工作的数据管道都是设计得像日志；而损坏的数据管道各有各的损坏。』 +> —— 列夫 · 尼古拉耶维奇 · 托尔斯泰 （由笔者改写）](http://en.wikipedia.org/wiki/Anna_Karenina_principle) +> +> **_【译注】_** [_托尔斯泰_](https://zh.wikipedia.org/zh-cn/%E5%88%97%E5%A4%AB%C2%B7%E6%89%98%E7%88%BE%E6%96%AF%E6%B3%B0) 的『[_安娜·卡列尼娜_](https://zh.wikipedia.org/zh-cn/%E5%AE%89%E5%A8%9C%C2%B7%E5%8D%A1%E5%88%97%E5%B0%BC%E5%A8%9C) 原理』的原文： +> Happy families are all alike; every unhappy family is unhappy in its own way. +> 幸福的家庭都是相似的，不幸的家庭各有各的不幸。 这里我使用术语『日志』取代了『消息系统』或者『发布-订阅』，因为在语义上明确得多，并且准确得多地描述了在实际实现中支持数据复制时你所要做的事。 我发现『发布订阅』只是表达出了消息的间接寻址（`indirect addressing of messages`） —— @@ -240,7 +246,7 @@ 这意味着作为系统设计和实现一部分的生产者，在交付到中心通道时， 必须考虑其输出和输入的数据要有良好结构形式的问题。 新的存储系统的加入对于数据仓库团队是无关紧要的，因为他们现在只有一个中心结点去集成。 -（**_译注_**：原来要集成的是其它各个相关的系统，工作是被简化了的） +（**_【译注】_** 原来要集成的是其它各个相关的系统，工作是被简化了的） 数据仓库团队需只处理更简单的问题，从中心日志中加载结构化的输入数据、完成特定于他们系统的数据转换。 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 603f4e2..a4f3cdb 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 @@ -50,7 +50,7 @@ 由此看来，对于流处理我很容易得出不同观点： 它处理的是包含时间概念的底层数据并且不需要静态的数据快照， -所以可以以用户可控频率生产输出而不是等待数据集的『都』到达后再生产输出（**_【译注】_**：数据是会持续的，所以实际上不会有『都』达到的时间点）。 +所以可以以用户可控频率生产输出而不是等待数据集的『都』到达后再生产输出（**_【译注】_** 数据是会持续的，所以实际上不会有『都』达到的时间点）。 从这个角度上讲，流处理是广义上的批处理，随着实时数据的流行，流处理会是很重要处理方式。 那么，为什么流处理的传统观点大家之前会认为更合适呢？