在线交易数据低延迟实时计算引擎设计方案咨询

一、整体架构思路 #

针对你的需求，核心要解决**低延迟实时聚合（分钟级）和大窗口高效查询（天级以上）**的矛盾，同时避免原始数据存储带来的性能和成本问题。整体分成「数据接入→实时预聚合→离线批量计算→统一查询」四个核心模块，替代你之前存全量payload再聚合的方式。

二、数据接入层：提前清洗，减少冗余 #

• 交易数据先进入Kafka做缓冲，应对峰值流量，同时保证数据不丢失。
• 在接入阶段直接完成字段提取：从payload里解析出邮箱、手机号、设备ID、交易时间戳、唯一交易ID这几个核心字段，丢弃不需要的冗余内容——只存聚合必需的数据，能大幅降低后续存储和计算的压力。

三、实时计算层：预聚合+高效存储（处理5分钟这类低延迟窗口） #

放弃查询时临时聚合原始数据的思路，改成流式预聚合，把计算压力前置：

• 用Flink做流处理（轻量场景也可以用Redis结合定时任务），定义5分钟滚动窗口，按邮箱/手机号/设备ID分组，实时计算窗口内的交易数、交易金额等指标。
• 计算结果直接写入Redis：比如针对邮箱user@example.com的5分钟窗口，key设为agg:email:user@example.com:5min，value存交易数；或者用Redis的TimeSeries类型，专门存储时序聚合数据，支持快速的时间范围查询。
• 过期策略：5分钟窗口的计算结果保留10分钟后自动删除，避免Redis内存占用过高。
• 轻量替代方案：如果不想引入流处理框架，用Redis的Sorted Set存交易ID+时间戳，比如key为trans:email:user@example.com，元素为{timestamp}:{transId}，查询近5分钟时用ZRANGEBYSCORE key (now-300 now获取数量，同时定时用ZREMRANGEBYSCORE删除超过窗口的旧数据，比遍历全量payload快数倍。

四、离线计算层：批量处理+冷热分离（处理10天这类大窗口） #

• 用Spark SQL或Hive每天批量计算前一天的各维度聚合数据，把结果写入ClickHouse（或者MySQL）——这类存储支持高效的范围查询和聚合。
• 若需要查询近10天的实时结果，采用冷热合并：用离线计算的前9天累计数，加上实时层当天的预聚合结果，合并后返回给用户，既保证查询速度，又覆盖完整窗口。
• 数据归档：超过30天的历史聚合数据可以归档到廉价存储（比如OSS），减少在线存储的成本。

五、统一查询服务：路由+缓存 #

• 封装一个查询服务，根据请求的时间窗口和维度自动路由：
  • 分钟/小时级窗口：直接查Redis
  • 天级以上窗口：查ClickHouse，或合并实时+离线数据
• 加入缓存：对频繁查询的结果（比如同一个手机号的近10天交易数）缓存到Redis，过期时间设为1小时，减少后端计算压力。

六、关键细节优化 #

• 去重处理：同一个交易可能对应多个维度（比如用户同时用邮箱和手机号下单），必须用唯一交易ID做去重，避免重复计数。
• 窗口对齐：实时窗口和离线窗口的时间边界要统一（比如都按UTC整点划分），防止合并数据时出现重叠或遗漏。
• 监控告警：实时监控流处理延迟、Redis内存使用率、离线任务完成时间，确保指标计算的时效性和准确性。

内容的提问来源于stack exchange，提问作者lowFPS