Streaming System 翻译中文版-Chapter 1. Streaming 101（3）
如上图所示；有两个明显的timeskew，主要是一横一竖两个线，每一个在不同的时间区域中，（下面主要解释这个一横一竖代表的含义）
处理时间lag（processing-time lag）：
那一条竖着的线，这代表processtime和eventtime之间延迟的距离有多大，也代表一个时间从产生到真正处理的时间差，这个线比较直观，
事件时间偏移（event-time skew），
那一条水平的线，代表距离理想的状态，当前pipeline的的延迟与多大。
在实际情况下，processing-time lag和event-time skew应该是相等的，只是对于同一件事情，不同的方式。对于processing-time lag或event-time skew需要重视的一点是，由于processing-time和event-time之间的差距是动态变化的，所以如果你很关心event-time你很难在上下文中得到有利的信息（解释一下，这一段有点绕，我觉得作者想说的是，如果你想知道当天eventtime后面是否还有对应的数据，比如比他早或者晚的数据，你很难通过你已经读取的数据判断，比如你现在看到了一条eventtime 8点的数据，后面来的都是8点01的了，那是不是说明8点之前的数据没有了，这并不代表，应该有可能有一些7点59的数据卡在了某些地方，多以很难用已知信息进行预测。如果event-time skew固定的就能预测了）
但是，很多系统为了更好的处理流式数据，都会提供窗口计算，稍后会对窗口计算做更加深入的介绍，本质上窗口计算就是在时间的维度上把数据切割成若干片段。 如果你关心正确性，并且想用eventtime来做窗口计算，显然processtime是不适用的。但是在实际实现的系统当中很多时候都是用processtime来做的窗口计算本来打算用eventtime做窗口的。从而导致结果不准确。（解释一下，一句话，现在好多系统要么没区分eventtime，processtime，要么不支持processtime和eventtime，所以要是你想要精确地基于eventtime的结果，现在做不到）
对于数据完整性现在的很多系统是与要求的，但是对于processtime和eventtime之间的timeskew，目前的系统又不能预测，所以这是一个问题。
下面将给出一个解决方案，与其追求讲无限的数据流变成有限的数据流，不如换个思路，来设计一个工具，应对复杂场景：新数据到达，旧数据被更新或者抛弃。（这一段直接翻译有点绕，解释一下，其实思路是这样的，现在面临的问题是，永远不知道是否还有某个eventtime之前的数据再过来，那能不能这样，把结果变成变化的，而不是不变的，一旦有新的数据过来，直接更新原来旧的结果）
在详细介绍更多的细节之前，先介绍一下其他有用的概念
閱讀更多 北京IT民工 的文章
