Streaming-大数据的未来
分享一篇关于实时流式计算的经典文章，这篇文章名为streaming 101: the world beyond batch
那么流计算如何超越批处理呢？
从这几个方面说明：实时流计算系统，数据处理模式，还有大数据的未来。
一、实时流式计算系统
实时流式计算的意义：
1、企业渴望获得更及时的数据，实时计算系统延迟更低。
2、数据量越来越大，而实时计算系统理论上是处理*数据的。
3、在数据到达时处理数据，可以更好的分担负载，对于资源的消耗更容易预测。
什么是streaming？
有很多的定义，比如*数据处理，近实时结果等，并不能说明streaming的真正含义。streaming应该是包含 *数据 近实时 一致性 可重复结果 等等特征的。 所以这里给出streaming的定义是：a type of data processing engine that is designed with infinite data sets in mind 一种考虑了无线数据集的数据处理引擎。
（这个定义包含了现在流行的真正的流式和微批）
streaming常见的用法：
1、无限数据：一种不断增长的，基本上无限的数据集。这些通常被称为“流式数据”。无限的流式数据集可以称为*数据，相对而言有限的批量数据就是有界数据。
2、*数据处理：一种持续的数据处理模式，应用于上面的*数据。批量处理数据（离线计算）也可以重复运行来处理数据，但是会有性能的瓶颈。
3、低延迟，近实时的结果：相对于离线计算而言，离线计算并没有考虑延迟的问题。
streaming的局限性：
streaming长期以来一直和离线系统同时存在，也就是lambda架构。
两者都执行基本相同的计算，streaming系统为您提供低延迟，不准确的结果，并且一段时间后批处理系统为您提供正确的输出。（由twitter的nathan marz（storm的创造者）提出），这样我们就需要维护两个版本数据，最后再合并结果。
所以kappa架构这种基于kafka的可重复获取消息的架构出现了，streaming应该是超越批量计算，并且能包含批量计算。flink正是接受了这个观点。
那么怎么做到这样呢？只需要两件事：
1、正确性：有了这个，就和批量计算等价了。
streaming需要能随着时间的推移依然能计算一定时间窗口的数据。spark streaming通过微批的思想解决了这个问题，实时与离线系统进行了一致性的存储，这一点在未来的实时计算系统中都应该满足。
2、推理时间的工具：这可以让我们超越批量计算。
好的时间推理工具对于处理不同事件的*无序数据至关重要。
这里有两种时间：事件时间和处理时间。
事件时间：事件实际发生的时间。
处理时间：系统中处理事件的时间。
当然，并不是所有的业务都会关心时间的问题。理想中事件时间和处理时间总是相等的，事件在发生时立即处理。然而，现实并非如此，事件时间和处理时间之间的偏差不仅不是零，而且受硬件（特别是网络），软件，数据本身影响，会有很大的偏差。
图一 时域映射 x轴为事件时间 y轴为处理时间 斜率为1的黑色虚线表示理想值，其中处理时间和事件时间完全相等; 红线代表现实。理想线和红线之间的水平距离是处理时间和事件时间之间的偏差。这种偏差本质上是处理流水线引入的延迟。
这个映射不是静态的，所以只关心事件时间，就很难在时间窗口分析数据，而如果将事件时间窗口化，完整性会出问题。
所以必须用新的方案解决这个问题，我们先来看一下现有的数据处理模式。
二、数据处理模式
这里我们将流式与微批处理放在一起，他们的差异在这里并不重要。
1、有界数据
图二，左侧的数据集充满了熵，我们通过mapreduce等批处理引擎，在右端使用具有更大内在价值的新结构化数据集。
当然，作为该方案的一部分，您可以实际计算的内容存在无限变化，但整体模型非常简单。
2、无限数据-批量
批处理引擎虽然没有明确考虑到无限数据，但是自从批量系统出现以来，它已被用于处理*数据集。主要是将*数据切割成适合批处理的有界数据集的集合。
固定窗口：
图三 使用批处理引擎重复运行来处理*数据集的最常用方法是将输入数据窗口化为固定大小的窗口，然后将每个窗口作为单独的有界数据源处理。
会话：
图四 增加批量，更复杂了
3、无限数据-streaming
这种数据可能是 时间无序的 事件处理时间有偏差
在处理这种数据时有几种情况：
不关心时间，近似算法，处理时间窗口化，事件时间窗口化。
不关心时间
这种是完全不关心时间的情况，我们只需要完成对数据的处理就可以，有以下几种情况：
过滤
比如web流量日志，过滤掉某一个域名的流量。丢弃不需要的就可以了。
图五 过滤*数据
内连接
还有就是连接两个*数据源的时候，没有时间逻辑。
图六 *数据内连接
近似算法
比图top-n k-means等算法，值得注意的是：这些算法在设计中通常会有一些时间元素，并且由于它们在到达时处理
，因此该时间元素通常基于处理时间。这可能会影响计算的误差，如果这些误差范围是以按顺序到达的数据为基础的
，那么这种数据并不可信。
图七 *数据近似值
处理时间窗口化
先介绍一下窗口，有三种窗口模式
图八 三种窗口
固定窗口：固定窗口将时间切割成具有固定大小时间长度的段。
滑动窗口：固定窗口的升级，滑动窗口由固定长度和固定周期定义。周期小于长度，则窗口重叠。如果周期等于长度，有固 定的窗口。如果周期大于长度，则会有一个的采样窗口，它只会随着时间的推移查看数据的子集。
会话：动态的窗口，会话由一系列事件组成，这些事件会超时而终止。会话通常用于通过将一系列与时间相关的事件组合在一起来分析用户随时间的行为。长度并不固定。
下面先来讨论处理时间窗口化：
当按处理时间窗口化时，系统基本上将输入数据缓冲到一个窗口中，直到经过一定量的处理时间后再做处理。例如，在五分钟固定窗口的情况下，系统会将数据缓冲五分钟的处理时间，之后它会将这五分钟内观察到的所有数据视为一个窗口并将它们发送到下游进行处理。
图九 处理时间窗口
处理时间窗口的优点：
简单：不用担心去改变数据。
窗口完整性：由于系统完全了解是否已经看到窗口的所有输入，因此可以完美的判断窗口完整。
处理时推断源的信息：比如监控系统。
但是处理时间窗口有一个非常大的缺点：如果数据有和他们关联的事件时间，弱国处理时间窗口要反映实际上这些事件的实际情况，那么这些数据必须顺序到达，但事实上大部分并不有序。
所以我们需要的是一种对时间到达顺序更稳的方式，也就是事件时间窗口。
事件时间窗口化
将*数据化为固定窗口。
图10 将事件时间固定到固定窗口
图中的实线白线表示两个特别感兴趣的数据。这两个数据都到达处理时间窗口，这些时间窗口与它们所属的事件时间窗口不匹配。因此，如果这些数据已被窗口化为处理关注事件时间的处理时间窗口，则计算结果将是不正确的。所以事件时间窗口才是正确性的体现。
图11 也可以创建动态的窗口
事件时间窗口有两个明显的缺点，因为窗口必须更长。
缓冲：由于延长了窗口的生命周期，因此需要更多的数据缓冲。这个问题可以通过持久储存和增量解决。
完整性：这个需要系统本身根据情况做出估计。
三、未来
我们定义了流的概念。正确性和推理时间的工具是关键。
通过分析事件时间和处理时间的差异，以及*数据和有界数据，*数据大致分为：不关心时间，近似算法，处理时间窗口化，事件时间窗口化。
目前来看，时间问题可能是我们需要重点解决的问题，在102中介绍了一种实时流式处理模型，这也是未来实时计算领域的基石。
让实时处理尽快融入到无限数据的系统中，为用户提供高延迟，高效率间的灵活选择，才是我们未来努力的方向。
更多实时计算，kafka等相关技术博文，欢迎关注实时流式计算