Pull模式下流计算频率与周期相关性的分析

本文讨论的话题有一些特定的背景，这里的“流计算”具体指的是以Spark Streaming为代表的Micro Batch一类的流式计算框架，因此会涉及到Batch Duration、Window以及Slide等概念。在架构层面上，数据流的走向是：数据采集组件以Pull的模式采集数据后推送给消息队列，流式处理组件以Pull的模式从消息队列中获取数据，处理之后写入NoSQL数据库，最后，前端的数据展示组件同样以Pull模式从NoSQL数据库查询数据并展示(尽管Pull模式的时效性要差一些，但是受源头数据源约束，很多数据源只能以Pull的模式进行数据采集，因此本文讨论的话题依然有很大的适用性)。因此，在数据采集组件上会有一个数据采集频率Collecting
Frequency, 在前端查询的组件上会有一个刷新频率和以及每次查询最近多长时间的参数设置，我们把UI上的这两个参数叫作Time Shift和Refresh
Frequency。 以下是对些相关参数的一些分析：

1. Batch Duration是全局唯一的: 这并不是必须的，只是在Spark Streaming的背景下，Batch Duration是绑定在一个StreamingContext上的，虽然一个应用可以启动多个StreamingContext，但我们依然认为单一的StreamingContext在资源管理与调配上有很大的优势，所以我们应该尽量地保持一个单一的StreamingContext，这也决定了整个应用层面上只有一个Batch Duration。因此Batch Duration的取值应该综合各个流的业务需求取一个平衡的值，大多数情况下这个Batch Duration的值是各个流相互妥协平衡之后取得的最小值。

2. Batch Duration == Minimum Delay: 这很容易理解，在Micro Bacth的流式系统里，Batch Duration就是理论上的整个系统的最小延迟，但考虑到数据写入和前端的查询频率，实际的延迟时间还要更大一些。

3. Batch Duration == Refresh Frequency: 把UI上的Refresh Frequency设置为与Batch Duration一样大小是比较常规的做法。但是Refresh Frequency确实可以设置的更小，这样可以让前端及时地得到刚刚写入数据库的数据。

4. Collecting Frequency == Window Size == Time Shift: 这三个参数都不是全局的，而是针对每个流独立配置的，但它们的取值最终是由Collecting Frequency来确定的， 任何小于Collecting Frequency的Window Size和Time Shift设置没有意义，任何大于Collecting Frequency的Window Size和Time Shift设置在分析结果的“解析度”上会有所降低，但如果是特殊原因，例如数据采集端鼓励以“小步快跑”的方式采集数据，而业务端不需要很细时间粒度的分析，就可以这样设置。本文原文出处: 本文原文链接: http://blog.csdn.net/bluishglc/article/details/78456213 转载请注明出处。