腾讯内容千亿级实时计算和规则引擎实践优化之路( 三 )


我们针对大窗口(如1天)、超大窗口(如30天等) , 结合计算复杂度和精度要求 , 采用了不同的计算方案 , 保障小成本高精准计算多种窗口指标 。
大窗口计算
对实时流数据根据数据自身的事件时间是否连续分为如下不同的几种情况:
情况一:分钟级别滑动 , 每分钟窗口连续有流量的情况
当数据自身的事件时间连续的时候 , 我们需要拿到上次大窗口的计算结果值 , 在上次计算结果的基础上 , 对窗口的头部和尾部进行加减操作就可以得到新的大窗口的值 。
腾讯内容千亿级实时计算和规则引擎实践优化之路
文章图片
图3-4分钟级滑动每分钟连续的大窗口
其中 , T(6,4)代表的是6min时候近4min的累计值大小 , 其中6代表的是当前最新时间 , 4代表的是需要统计的窗口大小 , 是人为规定的 。 M(5)代表的是第5min的值 。
情况二:分钟级别滑动 , 每分钟窗口流量不连续情况
当间隔的时间小于窗口大小的情况下 , 计算当前窗口的值需要得到上一个窗口的值进行加减操作 , 由于数据自身的事件时间中断 , 所以要对最后一次窗口的值进行校准 。
腾讯内容千亿级实时计算和规则引擎实践优化之路
文章图片
图3-5分钟级滑动每分钟不连续大窗口
其中 , T(5,4)代表的是5min时候近4min的累计值大小 , 其中5代表的是当前最新时间 , 4代表的是需要统计的窗口大小 , 是人为规定的 , M(5)代表的是第5min的值 。
情况三:分钟级别滑动 , 每分钟窗口流量不连续并且当间隔的时间大于窗口的情况
当间隔的时间大于窗口大小的情况下 , 由于窗口时间内没有出现流量 , 可以直接认为大窗口的计算值为当前分钟流量值 。
腾讯内容千亿级实时计算和规则引擎实践优化之路
文章图片
图3-6分钟级滑动每分钟不连续大窗口
其中 , T(6,4)代表的是6min时候近4min的累计值大小 , 其中6代表的是当前最新时间 , 4代表的是需要统计的窗口大小 , 是人为规定的 , M(5)代表的是第5min的值 。
超大窗口(如30天)
针对30天等超大滑动窗口计算 , 资源开销会成数十倍的膨胀 , 成本难以承受 。 我们构建了一套解决方案 , 成本降低到千分之一 , 精度只损失了百分之一 , 在成本和精度间达到了高效平衡 。
腾讯内容千亿级实时计算和规则引擎实践优化之路
文章图片
图3-7超大滑动窗口指标计算
如上图所示 , 计算单个内容ID的超大滑动窗口指标过程如下 。 状态更新:读取消费流水 , 更新该ID的状态值 。 计算超大窗口指标:基于应用内状态进行计算 。 如果内容产生时间在N天内:取累计流量 。 如果内容产生时间在N天前:基于输入流量的时间取不同范围的数据 , 整体半天精度 , 如30天超大窗口的误差约1.6% 。 00:00—12:00:取过去N天+当天流量值 。 12:00—23:59:取过去N-1天+当天流量值 。
3.2.2延迟流数据滚动大窗口计算
在内容生态场景中 , 由于历史原因和服务器时钟问题导致会出现超自然时间的数据 , 以及网络原因造成的延迟的数据 。 传统通过设置窗口水印的方式存在一定问题 , 对于超自然数据 , 会导致窗口立刻关闭;对于延迟数据 , 窗口关闭后 , 延迟到来的数据未能被统计到窗口指标中 。
为了解决上述问题 , 我们设计了一种可以同时处理超自然数据和延迟数据的方案 , 优点如下:对于大窗口的计算有绝对的优势 , 普通的方式大窗口计算时候由于窗口太大 , 窗口不能及时关闭 , 当内存中存在大量的窗口时性能会急速下降 。 此技术通过聚合Key设计 , 极大的提高了大窗口情况下计算的稳定性、时效性、准确性 。 提供了及时的内存清理机制 , 保证聚合Key在过期时候能够被及时的清理 , 保证程序不会随着时间的推移而出现性能的损耗 。