improve format

log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part1-what-is-a-log.md

@@ -17,7 +17,9 @@
 把次序直接看成是时间概念，刚开始你会觉得有点怪异，但是这样的做法有个便利的性质：解耦了 时间 和 任一特定的物理时钟（`physical clock`）。
 引入分布式系统后，这会成为一个必不可少的性质。
 
-**_【译注】_** 分布式系统的 时间、次序、时钟是个最基础根本的问题，详见被引用最多的_Leslie Lamport_的论文**_Time Clocks and the Ordering of Events in a Distributed System_**（[中文翻译](http://duanple.blog.163.com/blog/static/709717672012920101343237/)），现在先 **_不要_** 去看，除非读完本文后你还是有很兴趣要探个明白！
+> **_【译注】_** 分布式系统的 时间、次序、时钟的概念是个最基础根本的问题，详见被引用最多的_Leslie Lamport_的论文**_Time Clocks and the Ordering of Events in a Distributed System_**（[中文翻译](http://duanple.blog.163.com/blog/static/709717672012920101343237/)）。
+>
+> 现在先 **_不要_** 去看，除非读完本文后你还是有很兴趣要探个明白！
 
 日志记录的内容和格式是什么对于本文讨论并不重要。另外，不可能一直给日志添加记录，因为总会耗尽存储空间。稍后我们会再回来讨论这个问题。
 

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`推广至覆盖实时系统和处理流程。
 
 <img src="images/cabling.jpg" width="270" hspace="10px" align="right" >

log-what-every-software-engineer-should-know-about-real-time-datas-unifying/part3-logs-and-real-time-stream-processing.md

@@ -50,7 +50,7 @@
 
 由此看来，对于流处理我很容易得出不同观点：
 它处理的是包含时间概念的底层数据并且不需要静态的数据快照，
-所以可以以用户可控频率生产输出而不是等待数据集的『都』到达后再生产输出（译注：数据是会持续的，所以实际上不会有『都』达到的时间点）。
+所以可以以用户可控频率生产输出而不是等待数据集的『都』到达后再生产输出（**_【译注】_**：数据是会持续的，所以实际上不会有『都』达到的时间点）。
 从这个角度上讲，流处理是广义上的批处理，随着实时数据的流行，流处理会是很重要处理方式。
 
 那么，为什么流处理的传统观点大家之前会认为更合适呢？