创业公司做数据分析（二）运营数据系统

  作为系列文章的第二篇，本文将首先来探讨应用层中的运营数据系统，因为运营数据几乎是所有互联网创业公司开始做数据的起点，也是早期数据服务的主要对象。本文将着重回顾下我们做了哪些工作、遇到过哪些问题、如何解决并实现了相应的功能。

早期数据服务

  产品上线开始推广后不久，后台研发人员便会经常收到运营同事的私信：“能不能查一下有多少用户注册了，来自哪里？……..”。几次之后，大家便觉得这样的效率太低了：研发人员需要在繁忙的开发任务中抽时间来做数据查询、统计，而运营同事则需要等很久才能拿到数据。于是，大家开始协商更好的方法，最终达成一致：由运营同事提供所需的数据模板，后台研发人员根据模板将数据导入Excel文件，运营同事可根据自身需求自己分析统计。这便是早期的数据服务了，其组成结构如下图所示。

  这样的做法简单明了，后台研发人员根据数据模板写一个Python脚本，从业务数据库中将数据捞出来，做些分析、整合后，将结果输出到一个Excel文件，然后发送邮件通知运营同事接收文件。然而，随着需求的增加和细化、数据量的增加，暴露的问题越来越多，这里先罗列出来，这些问题有的会在本文提出解决方案，有的则会在后面的文章中陆续提出解决方案。

• Worker越来越多，分布在多个地方，存在很多重复的劳动和代码，某个逻辑的修改需要改很多文件。
• 由于使用ORM来访问数据库，很多代码只考虑逻辑，没考虑到查询数据的效率问题，导致有些报告需要跑十几个小时才能出结果（在循环查询数据的性能问题及优化一文有讲解）。
• 中间计算结果流失，数据没有共享，每个Worker都要跑自己的逻辑去算一遍。
• Woker依靠crontab来控制触发，没有监管，经常由于脏数据导致中断，需要等到运营同事发现后报过来才知道。

运营数据Dashboard

  随着业务的发展，以数据报表的形式来提供数据服务逐渐不能满足需求了。一方面，高层期望每天一早便能看到清晰的数据，搞清楚最近的运营效果和趋势；另一方面，虽然数据报表提供了详细的数据，但是还是需要手动去过滤、统计一下才有结果，所有想看数据的人都需要做一遍才行，而业务人员处理Excel的水平层次不齐。
  于是，我们开始筹划Dashboard系统，以Web的形式提供数据可视化服务。可是，Da