指标平台常用数据结构设计

2025-04-10 196 阅读3分钟

指标平台技术方案文档

一、数据分类与存储设计

1. 基础属性数据

存储方式：
- 使用 Redis hash 存储基础属性数据（例如用户基本属性、设备信息等）。
过期策略：
- 为每个 hash 设置半年（6 个月）过期时间，采用支持子 key 过期的 Redis 版本。

设备信息必须拆k-v存储，不允许存储超过redis默认值的的value长度

2. 时序聚合数据

存储方式：
- 原始数据先存储于时序数据库；聚合结果以 Redis hash 的子 key 形式存储，并设置过期时间，触发方式为新数据到来或者聚合数据中最近一条明细记录过期时，通过订阅 expired 消息触发重新聚合计算。
- 为解决大 key 问题，基于聚合数据主体计算 hash 值后拼接在大 key 上，例如：key=userId_${子keyhash值}。
高并发优化：
- 高频写入数据时采用 Flink 前置小窗口预聚合一次；若瞬间过期数据量激增，则将消息先存入 Kafka 后续慢速消费处理。
归档/清理机制：
- 针对聚合数据的明细存储，每天执行一次，将半年前（或更早）的数据进行归档或者清理处理，避免历史数据无限积累。

3. 历史 Count 数据

存储方式与计算：
- 在归档清理前，将当天变化的数据值与历史值相加计算出新的总值，通过 set 操作存入 Redis。
支持计算指标：
- 提供以下聚合计算：
  - sum：所有数据累加和。
  - count：记录总数。
  - max：最大值。
  - min：最小值。
  - avg：平均值，通过存储 sum 与 count 两个值计算得到（avg = sum / count）。

4. 名单数据

存储方式：
- 采用 Redis hash 存储名单数据（如风险名单、白名单等）。
大 key 问题处理：
- 基于数据主体计算 hash 值后拼接在大 key 上，例如：key=名单编号_${内容hash数值}。

二、整体设计原则

数据写入与聚合流程
- 基础属性数据长期存储于 Redis；时序聚合数据依托时序数据库存储原始数据，通过 Redis 缓存存储聚合结果，并利用过期事件触发重新聚合。
- 高频数据采用 Flink 预聚合，Kafka 缓冲机制平滑应对数据瞬间过期量激增的情况。
历史数据归档与清理
- 针对聚合数据明细和历史 Count 数据，设置定时归档或清理任务，确保系统中仅保留业务需要的实时数据，避免历史数据无限增长。
历史 Count 数据的精度要求
- 业务上对于历史 Count 数据不需要特别精确，归档前将当天变化的数据与历史总值计算后一次性设置到 Redis，支持 sum、count、max、min、avg 指标计算，通过存储 sum 与 count 来计算 avg。
产品边界
- 不支持历史的去重计算，也不支持明细数据的长期存储。对于此类数据通过效益分析报告评估后决定是否新增产品功能，以坚守产品形态，降低系统维护复杂度。

历史去重可通过sketch结构来实现，明细数据由上游查询后传递过来，redis不适合存储明细。

三、系统运行概要

基础数据层：
存储所有基础属性，采用 Redis hash，设置半年过期，保证数据快速访问与自动清理。
时序聚合层：
基于时序数据库存储原始数据，利用 Redis 存储聚合结果，采用过期触发重新计算。大 key 问题通过 hash 拼接分散存储；同时增加每天归档或清理半年前的聚合明细数据，保证数据时效性和存储空间有效利用。
历史 Count 层：
每日归档前将当天变化数据与历史累计数据合并更新 Redis 中的各类聚合指标（sum、count、max、min、avg），满足业务统计需求，而无须过分强调写入精度。
名单层：
使用 Redis hash 存储名单数据，同样对大 key 问题进行处理，保证数据均衡分布和高效存取。

该方案在兼顾高并发、高实时性与数据归档清理机制的前提下，简化了历史计数数据操作，确保系统维护成本可控，同时满足产品形态要求。