实时指标计算发展脉络

1、实时指标计算发展脉络

指标计算本质上是对一定时间范围内的数据进行统计计算的过程，它包含了实时计算和离线计算两种计算形式。实时指标计算发展脉络如下：

1.1、基于SQL/NoSQL实时指标计算

实时指标计算引擎查询到历史所有时间，然后在内存中进行筛选，完成指标计算（如某设备在最近5分钟登陆次数）

 

• 优点：速度快（1次查询获取所需数据），节省NoSQL内存（一份数据重复使用并进行多个指标计算），同一主属性新指标上线快（无需积累数据）
• 缺点：每次实时指标计算，返回大量无关数据，对网络带宽和内存带来压力
• 其他优化方案：通过数据存储/数据压缩/数据缓存/数据截断/NoSQL数据库聚合等形式进行优化，设备最近1天登陆1000次和10000次的风险是没有区别的，因此可以存储最近1000次数据。NoSQL数据库支持Lua脚本，可以直接写Lua脚本，由NoSQL数据库完成聚合，而不是原始的明细数据。
• 总结：该计算方式针对大并发（抢红包）等业务场景可能会面临带宽、应用内存等压力。

1.2、明细数据拆分实时计算（key-字段，Value）

 

• 优点：按需存储数据，占用Nosql较大的内存和存储，是一种空间换取时间的方式
• 缺点：数据复用性较差

 

1.3、数据分片实时计算

 

• 优点：分片存储中间计算数值结果，占用较少的存储空间
• 缺点：无法做数据去重，只支持“频度-出现次数统计”指标

1.4、引入flink框架实时计算

在实际的业务场景下，消息处理、数据库读写、容错、异常处理以及监控等各种复杂业务逻辑。理想情况下，我们作为有计算需求的业务方只需要聚焦于业务指标本身，完全不用关注计算过程中的并行处理、异常处理、容错处理、数据持久化处理等。当业务事件触发到相关规则时，只根据响应的Key查询指标结果即可。

• 优点：逻辑简单，只需关注业务主属性、时间窗口、计算方法，其他交给计算框架解决
• 缺点：需要引入并熟悉实时计算框架

1.5、Lambda架构(离线+实时)

 

有些指标是需要回溯1个月或1年进行计算。对于这种时间跨度比较长的指标，可以把指标计算转换为一个“较短时间窗口的实时指标”和一个“历史数据的离线指标”的聚合结果。