【原创】StreamInsight查询系列(十一)——查询模式之窗口对齐
2011-09-02 16:52
423 查看
前面部分介绍了StreamInsight的基础查询系列,从这篇文章开始,我会开始不断介绍StreamInsight中的查询模式。这篇博文作为查询模式的第1篇,主要介绍窗口对齐部分。
weatherData代表了一系列的天气信息(时间戳、温度、气象站编码以及风速)。
接下去将weatherData转变为点类型复杂事件流:
阅读过前面文章的读者应当能够很容易的写出如下查询:
在LINQPad中导出结果如下:
细心的读者也许会问,为什么这里的StartTime是2009/12/31 21:00:00,为什么不是前面常见的2010/1/1 0:00:00。原因是因为StreamInsight的起始时间默认设置为TimeSpan.MinValue,它会根据窗口中指定的长度从该点往后进行滑动。上面的例子中窗口长度为23小时,而只有在移动到2009/12/31 21:00:00时,窗口才开始包含事件(之前由于窗口内没有事件,引擎并没有将其输出)。StreamInsight默认情况下如果窗口为24小时,那么起始事件会是午夜的0:00:00时刻。
既然如此,有没有什么方法能够指定窗口的起始时间呢,答案是肯定的!
使用TumblingWindow的另一个重载方式中的对齐窗口参数可以指定如何对齐。在上面的例子中,若想要使得窗口起始时间为2010/1/1 0:00:00,只需要将窗口整体向后移动3小时即可。因此我们设置对齐窗口为3小时,即强制StreamInsight引擎从TimeSpan.MinValue + 3小时向后滑动窗口。
首先定义对齐时间段:
然后使用翻转窗口的另一种重载方式:
结果如下:
如果将alignment中的3小时变为(3 + n * 23)小时,你会发现结果是一样的,因为它们和3对23模数都是同余的,窗口本质上并没有产生新的偏移。
下一篇将介绍StreamInsight查询模式中的事件对齐部分。
测试数据准备
为了方便测试查询,我们首先准备一个静态的测试数据源:var weatherData = new[] { new { Timestamp = new DateTime(2010, 1, 1, 0, 00, 00, DateTimeKind.Utc), Temperature = -9.0, StationCode = 71395, WindSpeed = 4}, new { Timestamp = new DateTime(2010, 1, 1, 0, 30, 00, DateTimeKind.Utc), Temperature = -4.5, StationCode = 71801, WindSpeed = 41}, new { Timestamp = new DateTime(2010, 1, 1, 1, 00, 00, DateTimeKind.Utc), Temperature = -8.8, StationCode = 71395, WindSpeed = 6}, new { Timestamp = new DateTime(2010, 1, 1, 1, 30, 00, DateTimeKind.Utc), Temperature = -4.4, StationCode = 71801, WindSpeed = 39}, new { Timestamp = new DateTime(2010, 1, 1, 2, 00, 00, DateTimeKind.Utc), Temperature = -9.7, StationCode = 71395, WindSpeed = 9}, new { Timestamp = new DateTime(2010, 1, 1, 2, 30, 00, DateTimeKind.Utc), Temperature = -4.6, StationCode = 71801, WindSpeed = 59}, new { Timestamp = new DateTime(2010, 1, 1, 3, 00, 00, DateTimeKind.Utc), Temperature = -9.6, StationCode = 71395, WindSpeed = 9}, };
weatherData代表了一系列的天气信息(时间戳、温度、气象站编码以及风速)。
接下去将weatherData转变为点类型复杂事件流:
var weatherStream = weatherData.ToPointStream(Application, t => PointEvent.CreateInsert(t.Timestamp, t), AdvanceTimeSettings.IncreasingStartTime);
窗口对齐
首先我们先利用前面基础查询中学到的知识解决这么一个问题“怎样计算过去23小时内的事件数目?”阅读过前面文章的读者应当能够很容易的写出如下查询:
var countQuery = from win in weatherStream .TumblingWindow(TimeSpan.FromHours(23), HoppingWindowOutputPolicy.ClipToWindowEnd) select new { EventCount = win.Count() };
在LINQPad中导出结果如下:
细心的读者也许会问,为什么这里的StartTime是2009/12/31 21:00:00,为什么不是前面常见的2010/1/1 0:00:00。原因是因为StreamInsight的起始时间默认设置为TimeSpan.MinValue,它会根据窗口中指定的长度从该点往后进行滑动。上面的例子中窗口长度为23小时,而只有在移动到2009/12/31 21:00:00时,窗口才开始包含事件(之前由于窗口内没有事件,引擎并没有将其输出)。StreamInsight默认情况下如果窗口为24小时,那么起始事件会是午夜的0:00:00时刻。
既然如此,有没有什么方法能够指定窗口的起始时间呢,答案是肯定的!
使用TumblingWindow的另一个重载方式中的对齐窗口参数可以指定如何对齐。在上面的例子中,若想要使得窗口起始时间为2010/1/1 0:00:00,只需要将窗口整体向后移动3小时即可。因此我们设置对齐窗口为3小时,即强制StreamInsight引擎从TimeSpan.MinValue + 3小时向后滑动窗口。
首先定义对齐时间段:
var alignment = new DateTime(TimeSpan.FromHours(3).Ticks, DateTimeKind.Utc);
然后使用翻转窗口的另一种重载方式:
var alignCountQuery = from window in weatherStream.TumblingWindow( TimeSpan.FromHours(23), alignment, HoppingWindowOutputPolicy.ClipToWindowEnd) select new { NumEvents = window.Count(), };
结果如下:
如果将alignment中的3小时变为(3 + n * 23)小时,你会发现结果是一样的,因为它们和3对23模数都是同余的,窗口本质上并没有产生新的偏移。
下一篇将介绍StreamInsight查询模式中的事件对齐部分。
相关文章推荐
- 【原创】StreamInsight查询系列(十五)——查询模式之窗口比率
- 【原创】StreamInsight查询系列(十二)——查询模式之事件对齐
- 【原创】StreamInsight查询系列(十四)——查询模式之相异计数
- 【原创】StreamInsight查询系列(十八)——查询模式之趋势发现
- 【原创】StreamInsight查询系列(十六)——查询模式之左外联接
- 【原创】StreamInsight查询系列(十七)——查询模式之应对瞬变及报警泛滥
- 【原创】StreamInsight查询系列(二十二)——查询模式之持续更新
- 【原创】StreamInsight查询系列(十三)——查询模式之基本模式
- 【原创】StreamInsight查询系列(十九)——查询模式之检测异常
- 【原创】StreamInsight查询系列(二十)——查询模式之检测间隙事件
- 【原创】StreamInsight查询系列(二十四)——查询模式之模式匹配
- 【原创】StreamInsight查询系列(二十三)——查询模式之指数平滑法
- 【原创】StreamInsight查询系列(二十一)——查询模式之使用地理数据
- 【原创】StreamInsight查询系列(八)——基本查询操作之分组排序
- 【原创】StreamInsight查询系列(九)——基本查询操作之决胜排序
- 【原创】StreamInsight查询系列(十)——基本查询操作之联接
- 【原创】StreamInsight查询系列(一)——准备工作
- 【原创】StreamInsight查询系列(三)——基本查询操作之过滤
- 【原创】StreamInsight查询系列(七)——基本查询操作之基础排序
- 【原创】StreamInsight查询系列(六)——基本查询操作之分组聚合