作为系列文章的第二篇,本文将首先来探讨应用层中的运营数据系统,因为运营数据几乎是所有互联网创业公司开始做数据的起点,也是早期数据服务的主要对象。本文将着重回顾下我们做了哪些工作、遇到过哪些问题、如何解决并实现了相应的功能。
早期数据服务
产品上线开始推广后不久,后台研发人员便会经常收到运营同事的私信:“能不能查一下有多少用户注册了,来自哪里?……..”。几次之后,大家便觉得这样的效率太低了:研发人员需要在繁忙的开发任务中抽时间来做数据查询、统计,而运营同事则需要等很久才能拿到数据。于是,大家开始协商更好的方法,最终达成一致:由运营同事提供所需的数据模板,后台研发人员根据模板将数据导入Excel文件,运营同事可根据自身需求自己分析统计。这便是早期的数据服务了,其组成结构如下图所示。
这样的做法简单明了,后台研发人员根据数据模板写一个Python脚本,从业务数据库中将数据捞出来,做些分析、整合后,将结果输出到一个Excel文件,然后发送邮件通知运营同事接收文件。然而,随着需求的增加和细化、数据量的增加,暴露的问题越来越多,这里先罗列出来,这些问题有的会在本文提出解决方案,有的则会在后面的文章中陆续提出解决方案。
- Worker越来越多,分布在多个地方,存在很多重复的劳动和代码,某个逻辑的修改需要改很多文件。
- 由于使用ORM来访问数据库,很多代码只考虑逻辑,没考虑到查询数据的效率问题,导致有些报告需要跑十几个小时才能出结果(在循环查询数据的性能问题及优化一文有讲解)。
- 中间计算结果流失,数据没有共享,每个Worker都要跑自己的逻辑去算一遍。
- Woker依靠crontab来控制触发,没有监管,经常由于脏数据导致中断,需要等到运营同事发现后报过来才知道。
运营数据Dashboard
随着业务的发展,以数据报表的形式来提供数据服务逐渐不能满足需求了。一方面,高层期望每天一早便能看到清晰的数据,搞清楚最近的运营效果和趋势;另一方面,虽然数据报表提供了详细的数据,但是还是需要手动去过滤、统计一下才有结果,所有想看数据的人都需要做一遍才行,而业务人员处理Excel的水平层次不齐。
于是,我们开始筹划Dashboard系统,以Web的形式提供数据可视化服务。可是,Da