可配置+实时+统计中心.

1.配置项

   每日统计的sql脚本. 基于每月统计之上月统计脚本,基于月之上的年统计脚本.

   订阅哪张表的mq消息,触发grovvy的执行.返回对应的值. 但不一定能反向找到对应的实体.例如driverId,passengerId

方案:

  年统计+月统计+当月日统计+当日binlog统计.

  这样就不用为统计专门提供mq.

功能性业务:

   统计某个key的时时数据.

非功能性考虑:

   大数据定时任务很可能延迟

   mq很可能重复或者丢失.

   sql可能多条.

   sql可能会变更.

设计:

静态: 数据中心,各种源的topic,业务方.

动态: 业务入口. 时时mq, 获取key时时统计值.

表结构设计:

amount表:

  id:

  key:

  amount:

  end_date 统计到哪天为止.

date_amount表: 非功能性考虑

  id:

  key:

  date_amount: 某日统计值

  amount: 累积统计值

redis设计:

  key_date : amount : 每日时时统计值. 非功能性考虑

  key_date_统计来源id: 表示是否已统计过. 幂等性控制. 非功能性考虑

  key: amount: 性能考虑

逻辑设计,表的增删改查:

  

    Amount表:     每日定时任务,修改数据上的amount和end_date

    Date_amount表: 每日定时任务时,Amount表的end_date开始算起. 从修改数据上的amount和end_date;

    redis:  每次mq时,不仅累加单日统计,还删除累加值(或者时时累加,对性能更好).   

     getAmount()= 获取缓存值,获取不到( 历史汇总数据+ date之后的时时日数据. )

上线单日的amount是不准的. 但第二天就准了.废弃了redis时时日统计值.当日数据不给用户展现,后台先上线

可配置化:

业务方:

  配置,

     1. 使用哪个消息源的哪个topic.

     2. 使用topic里的哪个字段作为唯一性id.

     3. key的命名.

     4. 该key统计的起始日期.

每日统计sql:

     1. 配置sql,可能是几条sql. 这个配置好后,通过大数据统计计算. 也可是是基于mysql计算.

业务方统计代码(两种选择: 选择duubo调用,还是 动态代码计算):

         通过mq查询对应数据库代码. 通过autowired指定的jdbctemplate, 执行对应select操作. 也可以搞对应的integration,但陈本比较高.

         返回累加amount;

这个代码部分可以是配置的在统计中心后台页. 也可以学习任务调度中心. 调度和执行解耦.. 各业务部署各mq执行模块. 通过rpc调用返回结果.

非功能性异常case分析:

1. sql变更

   某订单的分润结果,没有复制对应的订单风控类型. 现在产品需要保存统计非风控订单的司机收入.

   原sql非常复杂,需要跨多张表格. 业务系统会在保存分润结果的时候保存订单风控结果. 这样sql执行就不需要跨库了.

主要系统:

1. 大数据统计平台.

      1.1 sql自管理和提交到大数据统计平台

      1.2 或者让大数据那边管理,统计好导入到业务系统这边.

2. 数据中心调度和统计结果存储平台.

3. 业务统计平台.

   当选择rpc dubbo调用执行时.