数据统计服务技术架构数据统计设计方案

转载

killads 2023-09-06 21:59:42

文章标签 数据统计服务技术架构数据数据统计 redis 文章分类 架构后端开发

前言初期
中期
非实时数据统计
实时数据
后期

TOC

前言

如果想做好一款产品，数据统计一定是必不可少的功能，它为产品经理验证功能可行性提供数据支撑，为后期数据分析提供高纬度业务数据，同时产品经理会经常根据不同的业务场景，提出不同的统计需求。

不过大多数情况下，我们仅通过缓存、数据库，配合一些统计查询语句，就可以应付绝大多数的统计场景。这里结合我自身的经验，根据产品的不同阶段，分享一下数据统计的简单实现思路。

数据统计服务技术架构数据统计设计方案_redis

初期

产品初期的时候，我们的主要精力放在业务功能的实现上，所以不会花太大精力到很细化的数据统计部分，这种情况下，当然是优先考虑使用第三方的免费统计平台。

下面就推荐几个三方统计平台，我们只要根据相关文档做简单的接入，就可以快速实现数据统计功能了。

说到CNZZ大家肯定不陌生，最早在做一些门户网站的时候，一般都会接入CNZZ，最主要它是免费的，直到2016年友盟、缔元信.网络数据、CNZZ三家公司宣布合并，联手打造新公司，更名为“友盟+”，为我们提供了APP、网站、小程序的统计。

数据统计服务技术架构数据统计设计方案_数据_02

类似的平台还有：
百度统计：https://tongji.baidu.com
腾讯移动分析：https://mta.qq.com

可以看到的是，三方统计的数据通过用户信息获取到的，所以统计的内容也都是基于用户信息，对于前期仅验证AAARR模型，和那些不需要统计“内部”数据的情况，基本完全够用了。

中期

数据统计服务技术架构数据统计设计方案_redis_03

产品中期的时候，也积累了一定的“内部”数据，比如历史订单数据，实时下单数据，设备使用数据等等，这些数据原则上是也不会公开给三方平台，并且第三方平台也不提供接口让我们接入自己的后台，所以这个时候就需要我们在自己的平台实现数据统计模块了。

当然，用户基础数据统计这一块如果不是必须自行统计的话，我们还是可以依旧直接用第三方，把精力放到业务数据统计中去，只不过这个时候产品运营需要打开两个统计后台查看。

非实时数据统计

这个比较好办，因为数据部分我们都有记录了，一般存在mysql中，那么每天晚上凌晨（业务低峰期）直接执行脚本通过mysql的聚合查询语句查询即可，然后写入汇总表。
汇总表需要根据业务统计需求划分好纬度字段，一般只统计到最细化的那一部分。

例如对于订单表，从交易纬度按日汇总统计，包括日下单数、日支付数、日退款数等。

如果是统计范围是全平台，那么每天就汇总一条记录，后面如果需要统计平台的周汇总数据，月汇总数据，直接从日汇总表进行一次聚合查询即可，就不需要再创建周汇总表、月汇总表了。
如果是统计范围是按商户，那么每天需要汇总商户数条记录，这种情况下如果商户（用户）很多，在做按月汇总时，可能还需要再提取出高一层的按月汇总表。

总之尽可能的空间换时间。

实时数据

在需要统计今日数据的时候，直接用mysql就比较吃力了，这时候就考虑用缓存，redis又派上用场了。

对于类似PV（浏览量，用户每点一次记录一次），给每个页面配置一个独立的redis 计数器，把这个计数器的 key 后缀加上当天的日期。这样每来一个请求，就执行 INCRBY 指令一次，最终就可以统计出当天不同页面的 PV 数据了。
又以事实下单数为例：

如果需要按商户区分，那么给每个商户设置一个独立的redis计数器，key设置成这样 “dayOrederCount:date:merchantId”，其中merchantId为商户id，date为当天日期。
如果需要统计全平台的下单数，那么给平台设置一个独立的redis计数器，key设置成这样 “dayOrederCount:date”，下单成功之后累加即可。
如果能确保实时数据的准确，那么晚上执行统计脚本的时候可以直接将缓存数据写入，避免多一次的聚合查询。

对于判断用户是否已经执行（使用）过某些方法。

如果数据量比较小，可以考虑基于redis使用hashmap、set、bitmap，每次通过缓存判断是否存在即可。
如果数据量比较大，可以将数据冷热分离，冷历史操作记录依旧需要写入mysql，按需读取当前用户的记录到reids中，设置一个过期时间，再通过方法判断是否存在，这样可以避免频繁查询mysql，同时又减少了redis的存储大小。
如果数据量比较大，但又不需要精准判断，可以基于使用布隆过滤器(Bloom Filter)

布隆过滤器（Bloom Filter）实际上是一个很长的二进制向量和一系列随机映射函数 (hash)，你也可以把它简单理解为一个不怎么精确的 set 结构，当你使用它的 contains 方法判断某个对象是否存在时，它可能会误判。但是布隆过滤器也不是特别不精确，只要参数设置的合理，它的精确度可以控制的相对足够精确，只会有小小的误判概率。
当布隆过滤器说某个值存在时，这个值可能不存在；当它说不存在时，那么一定不存在。

对于不要求精准数据，只需要统计独立总数，并且访问数据量很大的情况，如UV，同一个用户一天之内的多次访问请求只能计数一次（基数统计）

可以考虑使用redis的HyperLogLog，主要用到了pfadd 和 pfcount 方法。