区间汇总项目
背景
由于区间指标的数据量较大;取数时可能会出现mongo查询数据量过大报错,计算时间太长导致取数超时等问题,从而影响性能。需要将这些区间指标数据进行汇总处理。
现状
当前业务的实现是以python结合数据库,在单服务器上做crontable计算数据汇总。
几条主的业务:
- 更新/reload 月度汇总数据
- 更新/reload 历史最值数据
- 更新/reload 分时数据
- 更新/reload 接口每日数据
问题
性能瓶颈
- python 代码不能合理发掘机器资源
安全问题
- 单机部署,故障后比较麻烦
维护性差
- 需要代码侵入,SQL更改
扩展实现困难
- 指标新的计算方式难以扩展
解决方案
将业务重构成Java版,以Java庞大的生态资源解决上述问题。
设计流程
应用框架结构
- 基于现有应用服务还是新起?
基于现有服务可以资源共用,节省成本
- 新起服务耦合性低,维护起来更灵活
业务实现的整体流程
配置表的设计
原表
- index_name,start_date,end_date,func,filter,db_name,day_tbl_name,month_tbl_name,status,source_name,time_span
改表
- 指标名、时间?、function、汇总后存入的db_name、table_name、定时cron、区间、指标名+计算方式+汇总区间(作为job name)
- 指标流程记录表
与任务调度平台的结合
- 读配置表,组合成job,注册调度中心
任务调度job的维度
- function的维度写handler(没必要,function 可以下沉到业务逻辑的方法中)
- 按时间区间,基于原代码流程(比较保险,能发现隐藏的业务细节)
- cron+table_name+区间区分注册job
数据源的切换 mongo 到 接口
- 需确认新数据源的情况
- 调用及使用
job 具体的计算
- 业务逻辑是否需要多线程
- 如果多线程怎么实现
日常运维
- 配置表的增删改
容错的ops工具
- 指标错误数据支持重跑
异常问题排查解决
- 日志处理
- 调度平台提供调度监控
job实现
应用部署初始化的时候,读配置表注册job
配置表:
- 指标名、起止时间、计算方式、汇总区间、定时cron、汇总后存入的db_name、table_name、指标名+计算方式+汇总区间(作为job name)
注册job
- 指标名+计算方式+汇总区间(作为job name)
- 汇总区间作为handle
JobHandle实现:指标指定的时间区间从指定的数据源取数据做汇总计算后更新到指定的库
- 拿到指标名、计算方式、汇总区间。尝试逻辑中取值
- 以上边为条件查出所有配置的所有数据 。SQL服务接口
- 对时间分割
- 按时间限制条件从新数据源取要汇总的数据 从datacore取数据量大问题
- 对数据按配置func运算,对取出来的多条数据整合出一条数据
- 将这条数据按时间限制更新到指定mongo库表
- 取数计算的部分尝试使用时间区间+股票code做线程区分,多线程跑
大致排期
DATE | EVENT | REMARKS |
---|---|---|
6.11-6.22(7天,下一周结束) | 业务代码开发 | 包括数据方面 |
6.22-6.26(下下一周) | 自测加代码review | 连通调度测试 |
下一周 | 学习并开始开发页面 | 如果可以交给测试测 |
下一周 | 准备上线,并上线 |
进展集
DATE | POINT | REMARK |
---|---|---|
6.11 | 熟悉新应用,微调代码结构。将新应用作为执行器接入调度平台 | |
6.12 | mysq建表,数据操作的代码,mongo数据源接入 | |
6.15 | 串写主流程代码,应用初始化引导,接口定义及调用 | |
6.16-17 | 主业务代码,数据汇总多线程实现 | |
6.18-19 | 串联整个调度数据汇总,自测问题修复 | |
6.22-23 | 页面的CRUD代码实现 | |
6.24-26 | 页面搭建及联调接口 |
遇到的问题
流程方案的设计(Spring 生命周期调用,策略模式、线程池、重试模板设计、单例、stream流运用等等)
Mybatis mapper 引入不到
线程池(重写、参数、使用)
测试环境调试准备
调度的对象刚开始写的是对象,需要改成bean
第二个sql表插入不上,跟第一个表一样的代码(sql表设计没有自增)