基于 TiDB + Flink 实现的滑动窗口实时累计指标算法

导读

当前的市场环境对产品运营提出了更高的要求，特别是对数据指标实时性的要求日益严格。为了能够实时监测数据动态和特征用户的状态，我们采用了分布式数据库 TiDB 和计算框架 Flink 的组合，提出了一种基于滑动窗口的实时累计指标算法。该算法能够在市场营销活动中发挥积极的作用，显著改善用户体验并促进收益增长。

前言

在不少的支付分析场景里，大部分累计值指标可以通过 T+n 的方式计算得到。随着行业大环境由增量市场转为存量市场，产品的运营要求更加精细化、更快速反应，这对各项数据指标的实时性要求已经越来越高。产品如果能实时把握应用的整体运行情况或特征用户的状态，就可以及时安排合理的市场营销活动，这对改善用户的体验和促进收益的增长有明显的帮助。

需求指标

有一个场景为了进一步优化营销活动内容，希望我们实时提供每个玩家在最近 1 年、2 年、5 年、10 年内的实时消费总金额。

要实时计算每个玩家最近 N 年的实时消费累计总金额，一方面要考虑到这个指标随着时间推进它可能在不断增加，另一方面会有数据过期了而不再属于这个统计周期内，要及时减去，从而维护一个动态的累计值。

这里的每一个用户的“最近 N 年”指标是不断前进的，涉及到产品上线以来的全部用户，其累计的用户量、支付数据都在亿级别以上，且明确要求实时统计历史数据。综合分析下来，解决该问题具有一定的挑战性。

在经过充分调研和分析后，基于实时计算框架 Flink 和分布式数据库 TiDB 的组合使用，我们提出了一种实时计算滑动窗口内累计指标的算法，在一个数据库里同时支持实时 OLAP 计算和 OLTP 数据服务，有效地解决了这个问题，目前已经在线上稳定服务了一段时间。下面给大家分享下我们的思考和实践。

数据特点

首先我们先从整体上评估下数据的特点，分析一下数据规模、有哪些关键问题对我们的计算有影响。

数据概况

• 基础数据量大，存在乱序、重复等问题：
  • 数据源历史数据量较大，亿级别；日增日志数据在百万级别；
  • 原始日志数据打印在不同应用机器上，没有集中统一存储，分散；
  • 由于业务有等待逻辑，业务时间字段存在乱序问题，即先产生的数据的日志打印时间可能晚于后产生的数据的打印时间，时间乱序的数据如果不及时处理可能会出现漏算的情况；
  • 由于业务有重试机制，相同的日志数据可能重复出现，数据重算会导致结果错误。
• 聚合指标要求支持高并发访问：
  • 最终的结果指标要求支持 TP 服务访问，且满足高并发场景。

线上的应用部署在不同的机器上，先后请求的数据的业务时间和日志打印时间，可能是乱序的，这会导致我们需要解决数据排序的问题。且由于业务存在请求重试逻辑，数据也有可能是重复的，需要设计好去重机制。

实现重难点

• 保证计算的实时性、准确性：
  • 需要处理数据乱序问题，使其有序，然后实时监听数据再分别进入统计周期开始边界、结束边界的变化情况，准确在累计值上执行加、减操作。
• 计算的事务性：
  • 在对同一个用户的累计指标执行加、减操作时，要严格保证每个操作的原子性和隔离性；
  • 此外，还要保证不同用户之间的操作也是事务隔离的。
• 累计指标可重入：
  • 数据经过统计窗口边界时，有且仅有一次被计算，需要处理原始数据重复问题；
  • 程序重启时数据计算结果应该保持不变，指标的值不会变多，也不会变少，即保证重入。

主要的问题在于对于统计最近一段时间内的值，这个“最近”是实时变化的，即统计区间的开始、结束时间点也是实时变化的，这个问题可能就比较复杂了，需要严格保证每个操作的原子性和隔离性，而且每笔数据不能重复算也不能漏算，否则就会出现数据错误。

可选算法

实时统计

该方案是指，当查询某个用户最近 N 年的累计值的请求发送过来时，直接到数据库统计得到结果，可以理解为是一个用户级的实时 AP 操作。这种方法在良好的表设计、索引设计下，大部分场景在秒级别可以完成查询，在并发高时数据库资源很容易出现算力瓶颈，导致服务不稳定，业务受影响。

• 优点

  • 方案简单，实现容易；
  • 能获取到准确的指标结果。

• 缺点

  • 由业务方维护计算的方法，访问和计算是同时进行的，没有做到分离；
  • 数据库要有实时高并发的 AP 能力，对数据库要求过高；
  • 计算全部依托于数据库࿰