>记录生活, 工作的点点滴滴...

17年总结

数据BI分析系统, 数据展示向web端, 移动端转移, 应该是未来数据可视化的方向. 个人虽对此一直有深厚的兴趣, 但因其涉及知识范围较广, 对各方面技能均需有一定涉猎, 17年半为工作服务半为学习之用, 进行了一系列的实现原理探讨, 并尝试基础功能的实现.

17年搞了不少事情, 但收效甚微, 总结主要问题可能在于:
第一, 前期规划不够;
第二, 总体把控欠缺;
第三, 需求变化多端;

3-4月, 将大部分精力用在收取中台数据邮件后的分析展示操作上, 初期架构基于Excel VBA生成js格式化数据, 由网页直接加载js文件, 由此以图表等开式展示日/周报数据;
优点: 模型设定后, 可傻瓜式操作, 方便无基础人员处理.
缺点: 模型更新等引发版本控制问题; 只能本机浏览.
尝试实例: 儿童医院日报/周报

5-6月, 构建WAMP服务, 实现浏览器多端访问, 将数据存储端与展示端分离.
将数据集中整理至后台MySql数据库(最初使用SQLite, 后考虑单独配置机器作为服务器, 更为MySql)
优点: 手工更新后台数据后, 前端自动更新
缺点: 前端web页面, 数据库操作等均有一定技术门槛.
应用实例: 质检(根据医生随机抽取特定数据订单): 通过链接跳转实现基于选定订单查看订单详情

7-8月, 持续整合后台数据, 同时将部分数据结果前端化示.
中间层作为处理聚合数据与前端之间的桥梁, 数据主要通过数据库层级进行操作,
对数据层级进行构架优化, 尽量支持多维度多角度查询输出.
优点: 确定数据存储结构化, 层次化
缺点: 数据来源会越来越复杂, 后续如有更改, 迭代难度增大
尝试实例: 电话服务每日各时段接线情况 – 提供选择日期,查看历史结果

9-10月, 呼叫系统调整, 计算呼叫源数据发生变化, 重新相关设计数据库结构, 实现新旧数据融合.
并根据新数据源更多字段结构, 构建准备更多维化数据结果, 以便快速响应相应数据需求.
优点: 快速响应需求, 如已构建相应维度, 可直接给出结果
缺点: 增加维护难度
尝试实例: 电话服务每日各时段接线情况 – 增加周/月周期, 客服/医生等组别, HealthPlan/MHealth/920专线等项目维度查询

11-12月, 数据源采集->邮件发送等流程的自动化, 使用定时脚本, 实现呼叫数据定时采集, 处理, 并发送邮件.
持续优化代码, 尽量使功能模块化.

发表于:2018-01-20 11:53:28浏览(310) 评论(0) 默认分类