创业公司做数据分析

推荐会员: dtfaner199 所属分类: 行业精选 发布时间: 2017-02-09 13:41

文 | Mr-Bruce

了解“认知心理学”的朋友应该知道:人类对事物的认知,总是由浅入深。然而,每个人思考的深度千差万别,关键在于思考的方式。通过提问三部曲:WHAT->HOW->WHY,可以帮助我们一步步地从事物的表象深入到事物的本质。比如学习一个新的技术框架,需要逐步搞清楚她是什么、如何使用、为什么这样设计,由浅入深。

“WHY+HOW+WHAT”,是笔者最钟爱的一种思维模式。其使用方法不仅限于上述认知过程中的思考方式,通过不同的顺序组合,可以使用在不同的场景。比如,在筹划一个项目时,采用“WHY->WHAT->HOW”的思考方式,先搞清楚为什么要做这个项目,然后是需要做哪些工作来完成这个项目,最后考虑怎么做、技术选型。这个思考方式也将被广泛使用在本系列的各个文章中。

大数据

在过去的一年里,笔者加入了一家移动互联网创业公司,工作之一便是负责数据业务的建设,陆陆续续完成了一些数据系统的实现,来满足公司的数据需求。在创业公司中做数据相关的事情,而且是从零做起,肯定不像很多大公司那样分工明细,所有的工作都要保证在有限的资源下来满足需求。回想起来也蛮有意思,因此想做些总结分享,结合我们的系统来谈一谈如何做数据分析。如果有写的不好的地方,还请网友指正。

作为系列文章的开篇,本文将按照“WHY->WHAT->HOW”的思考方式来阐述下面三个问题:

1. 创业公司为什么需要做数据分析?

2. 创业公司做数据分析,需要做哪些事情?

3. 如何实现这些数据上的需求?

WHY

随着移动互联网的发展和大数据思维的普及,越来越多的创业者、投资人开始重视数据的作用,而不再是随便拍脑袋。“数据驱动决策”、“精准化运营”、“产品快速迭代”这些概念被越来越多的人提出和使用,其背后都离不开精准的数据分析。对于大多数互联网创业公司来说,其背后没有强大的资源与财主支撑,如何在有限的人力、物力下快速摸索、少走弯路是至关重要的,而基于“数据驱动”来做决策、运营与产品将起到一个关键的作用。让我们来看两个例子。

【例一】

微信公众号早已成为各家运营的主战场之一,利用微信的关系链来转发H5海报页面是众多线上活动和拉新的一个重要方式。然而,不管是做某个线上推广活动,还是通过线下某个渠道引导用户分享、注册,我们都需要指标来衡量活动效果,从而摸清运营的方向。数据,便是关键!该活动带来的浏览量、分享量、新注册用户数、用户留存率都是重要的指标,而这一切都离不开有效的数据追踪与分析。如果同时有100个这样的渠道活动,如何统筹各个数据分析也将是一件无法忽视的事情。(下图呈现的是某次活动的传播网络的一部分)

大数据

【例二】

每逢节假日,国内各个旅游景点都是人山人海,尽管大家都知道外出游玩会遭遇这种情况,但是还是抱着一丝侥幸心理出行,毕竟好不容易有了假期嘛。在今年十一时,笔者就曾利用百度景区热力分布图来提前观察,从而避开了一些高峰期和人满为患的景区,大家不妨也试一试。

回到正题,对于很多创业公司,特别基于LBS提供服务的企业来说,都期望搞清楚“用户在哪里”、“哪里是用户感兴趣的地方”,从而摸清早期的投入方向,毕竟全面开花、四处征战的方式是不适于创业公司的。通过位置数据,来分析用户集中在哪些区域,主要分布在商业区还是高校,是否受到交通因素影响等等,当然,具体需要结合业务来做了。另一方面,还可以聚合出用户的常驻位置,可以对用户位置与商户位置的距离进行分析等等,从而形成推荐方案,优化产品与服务。

大数据

WHAT

对于大多数互联网创业公司,在做数据分析时,一定要结合自己的业务,把握一个度,在投入可控的范围内达到效果即可。数据深度挖掘、机器学习、推荐算法等等,这些技术名词背后都需要投入一定的人力、物力来支撑,即使是大厂来玩,产出也相对有限,而且很多时候实际工程效果不尽人意。举个列子,很多高端的“推荐算法”在投入使用后,其效果远不如“看了又看”来的简单有效。当然,如果你的公司就是做数据这方面的业务,那是另一回事了。

要搞清楚需要做什么,不妨先结合自身业务思考一下,现阶段自己需要什么数据来驱动决策、运营与产品。具体业务方面的数据需求,各家都不一样。从笔者接触的情况来看,早期大部分的数据需求集中在两块:运营数据的统计分析、产品使用情况的统计分析。后期随着产品线的发展,一般会延伸出一些与产品相关的数据业务,比如线上推荐。

从流程上看,需要做的事情集中在三部分:数据采集、数据处理和数据可视化,伴随着数据的变迁:原始数据->分析结果->图表呈现。首先,基础数据源的建设是做好数据分析的关键,因为如果数据源本身出了问题,那么后面做的所有工作都是没有意义的,而且如果没有提前做好数据采集,后期想做分析时也没有数据可做。

其次,数据分析的最终结果是需要呈现给别人看的,可能是公司高层,也可能是市场业务人员,直接将一堆数据丢给他们显然是不现实的,通常都需要转换为图表的形式,这便是数据可视化的工作。而从原始数据源到分析结果的过程,便归纳为数据处理,其涵盖了数据提取、数据建模、数据分析等多个步骤。

大数据

HOW

现如今国内的互联网环境发展的越来越好,第三方服务提供商越来越多。所以很多情况下我们都有两个选择:接入第三方、自己做。

数据分析这块,便有很多第三方服务,笔者将其划分为传统数据统计服务与新兴的数据公司。前者以百度统计、google analysis为代表,通过嵌入其SDK在前端采集数据,在后台便可以查看相应的统计数据。这种方式的好处是简单、免费,使用非常普及,是很多初创企业的首选。

缺点也很明显,一是这样的统计只能分析一些基本的访问量、点击率、活跃用户量,满足基本需求,无法结合业务数据来做深度分析;二是需要在前端很多地方埋点上报,耦合性较强;三是数据存储在第三方的服务器中,无法直接获取到数据源。

后者以神策、GrowingIO、诸葛IO为代表,这些公司也正是看到了传统数据统计服务的缺点,从而提出相应的解决方案,各有特色。但是,需要不菲的接入费用,私有部署的费用更多,而这笔费用对于一个初创企业来说,还是蛮多的。另一方面他们更加侧重于电商领域的数据分析,因为这个领域的分析模式已经基本成型,适合做成模板来使用。

选择自己做的话,可以结合自身的业务,做的更灵活,同时也可以尽早摸索数据业务,逐步建立相应的数据系统。当然,自己做并不代表是造轮子,而是要充分利用开源框架来实现相应的功能。

鉴于各家的业务都不同,而抛开业务谈架构都是耍流氓,所以在接下来的文章中,笔者将结合自己接触的业务来探讨一些数据系统的实现。下图所示便是现阶段我们的数据系统架构,主要分为数据采集、数据处理与数据应用三层。

从下往上,数据采集层负责从前端App、H5页面、服务器日志采集数据,通过Kafka接入后存入Elasticsearch与neo4j中,同时业务数据库也是很重要的数据源;数据处理层负责数据的抽取、清洗、建模,然后存入MongoDB与MySQL中,整个过程由Airflow任务调度管理系统来进行管理与监控;产出的数据最终提供给应用层使用。

也许有人要说,连Hadoop都没用到,怎么号称自己在做数据分析呢。笔者曾经也做过考虑和尝试,最终暂时搁置了Hadoop,主要是数据增长相对缓慢并且没有很明显的需求,目前这个架构可以在较长一段时间内应对数据需求了。

大数据

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

早期数据服务

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

大数据

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

Worker越来越多,分布在多个地方,存在很多重复的劳动和代码,某个逻辑的修改需要改很多文件。

由于使用ORM来访问数据库,很多代码只考虑逻辑,没考虑到查询数据的效率问题,导致有些报告需要跑十几个小时才能出结果(在循环查询数据的性能问题及优化一文有讲解)。

中间计算结果流失,数据没有共享,每个Worker都要跑自己的逻辑去算一遍。

Woker依靠crontab来控制触发,没有监管,经常由于脏数据导致中断,需要等到运营同事发现后报过来才知道。

运营数据Dashboard

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

于是,我们开始筹划Dashboard系统,以Web的形式提供数据可视化服务。可是,Dashboard要做成什么样子?由于产品经理和设计人员都忙于产品业务,所以只能自己考虑要做什么、怎么做。好在笔者之前用过百度统计,对那里面的一些统计服务比较清楚,结合公司的业务,形成了一些思路:

数据内容上,包含:核心指标数据和图表分析两部分。前者以曲线图为主,要能快速显示数量和趋势,比如注册日增量趋势图;后者使用各种图表来展现某个时间段内的分析结果,比如10月份的TOP10用户感兴趣品牌。

数据类型上,包含:C端核心指标、B端核心指标、核心分析和专题活动指标与分析。前两者是分别针对C端和B端的指标数据,核心分析是一些综合的分析,比如转化率分析,专题活动是针对一些特定的大型运营活动。

数据维度上,包含:时间维度、城市维度和B端品牌维度。时间是最基本最重要的维度,城市维度可以分析各个运营大区的状态,B端品牌维度主要是针对B端上的业务。

整理后便形成了下图所示的Mockup(简化版),基本涵盖了上述的思路。虽然在美观上相对欠缺,但是毕竟是内部使用嘛,重要的数据显示要能准确、快速。

大数据

搞清楚了要做什么,接下来就是要将想法落地,考虑如何实现了。

整体架构

系统的整体架构如下图所示,主要基于这么几点考虑:

前后端分离。前端只负责加载图表、请求数据并显示,不做任何数据逻辑处理;后端负责产出数据,并提供REST API与前端交互。

离线与实时计算并存。为了提高数据获取的速度,曲线指标数据采用离线计算的方式,提供历史数据供前端展示;图表分析类数据采用实时计算的方式,其速度取决于所选时间段内的数据量,必要时进行缓存。

大数据

前端实现

Dashboard系统的前端并不复杂,前面也提到我们不会做太多样式上的工作,重点是数据的显示。那么,第一件事就是要寻找一款图表库。笔者这里选择的是百度ECharts,其提供了丰富的图表类型,可视化效果很棒,对移动端的支持很友好,重要的是有详细的示例和文档。事实证明ECharts确实很强大,很好的满足了我们的各种需求。

选好了图表库,接下来的问题是如何优雅的加载几十个图表,甚至更多。这就需要找到图表显示共性的地方(行为和属性),进行抽象。通常,使用ECharts显示一个数据图表需要四步(官方文档):第一步,引入ECharts的JS文件;第二步,声明一个DIV作为图表的容器;第三步,初始化一个echart实例,将其与DIV元素绑定,并初始化配置项;第四步,加载图表的数据并显示。可以发现,行为上主要分为初始化和更新数据两个,属性上主要是初始配置项和数据。

基于此,笔者使用“Pattern+Engine”的思想来实现前端数据加载。首先,在JS中使用JSON对每个图表进行配置,即写Pattern。例如,下面的配置便对应了一个图表,elementId是DIV的id,title是图表的标题,names是图表的曲线名称,url提供了获取数据的API,loader表示要加载的图表Engine。而一个页面的图表便由一组这样的配置项组成。

大数据

 

页面加载时,根据Pattern中的配置项生成相应的Loader Engine实例,用来初始化图表和更新数据。每个Loader对应一个ECharts图表类型,因为不同图表类型的初始化和加载数据的方法不同。程序类图如下所示。

大数据

后端实现

前面提到在早期的数据服务中,存在很多重复劳动和代码,因此在Dashboard系统的后端实现中,笔者开始考虑构建数据分析的公共库,这块占据了很大一部分工作量。底层公共库不针对任何特殊业务需求,主要负责三件事:第一,封装数据源连接方法;第二,封装时间序列的生成方法,产生以天、周、月为间隔的时间序列;第三,封装基础的数据查询、清洗、统计、分析方法,形成格式化的数据,这部分是最重要的。

完成了底层公共库的构建后,整个代码结构一下子就清爽了很多。在其基础上,开始构建上层的Analyzer。Analyzer用于完成具体的数据分析需求,每个Analyzer负责一个或多个数据指标的产出,每个曲线图/图表的数据由一个Analyzer来负责。离线计算与实时计算,则是分别在Schedule和Web请求的触发下,调用对应的Analyzer来完成数据产出。因此,整个后台系统分为三层来实现,如下图所示。

大数据

最后谈一谈离线数据的问题。目前离线计算是由Schedule来触发,每日零点计算前一日的数据,数据按照“每个指标在不同维度上每天一个数据点”的原则来生成,由上述的Analyzer来负责产出格式化的数据,存入MongoDB中。由于查询规则简单,只需建立一个组合索引就可以解决效率问题了。目前数据量在500W左右,暂时没有出现性能问题,后期可以考虑将部分历史数据迁移,当然这是后话。

数据报表

Dashboard上线后,我们开始考虑将早期的数据报表服务逐步停下来,减少维护的成本。而运营同事希望能继续保留部分报表,因为Dashboard虽然提供了很多数据指标和分析,但是有些工作需要更精细的数据信息来做,比如给带来微信注册的校园代理结算工资、对新注册用户电话回访等等。经过一番梳理和协商,最终保留了六个数据报表。另一方面,B端的商家期望能在后台导出自己的相关数据。综合两方面需求,笔者构建了新的数据报表系统。

大数据

新的数据报表系统,按照流程来划分为三部分:触发、执行与通知。内部数据报表依旧由Schedule触发,启动相应的Worker进程来执行;而提供给外部的报表由Web前端通过REST API来触发,将相应的任务加入Celery任务队列中执行。执行体由一组Exporter来完成,Exporter负责获取数据、生成适合写入Excel的数据格式、写Excel文件,数据获取部分依赖前面所述的底层公共库。最后,统一发送邮件通知。

考虑到早期数据服务中经常遇到异常导致生成报表失败的问题,笔者在新的数据报表系统中做了两点与异常相关的处理:

使用Airflow对Schedule触发的任务进行监控(后续文章会有详细介绍),手动触发的任务则由Celery进行监控,遇到异常便发送邮件通知到开发人员。

如果一个Excel数据文件由多个Sheet组成,当某个Sheet出现异常时,通常由两种处理方法:一是丢弃整个文件,二是保留其他Sheet信息继续生成Excel文件。这里,内部报告使用了第二种处理方法,外部报告相对严谨,使用了第一种。

以上便是笔者所在公司的运营数据系统的发展历程和现状,目前Dashboard与数据报表两个系统已经趋于稳定,基本提供了90%以上的运营数据服务。当然,随着数据量的增长、业务需求的发展,一定会面临更多新的挑战。

来自36大数据(36dsj.com):36大数据 » 创业公司做数据分析

关键词:

版权声明:本站原创和会员推荐转载文章,仅供学习交流使用,不会用于任何商业用途,转载本站文章请注明来源、原文链接和作者,否则产生的任何版权纠纷与本站无关,如果有文章侵犯到原作者的权益,请您与我们联系删除或者进行授权,联系邮箱:service@datagold.com.cn。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

This site uses Akismet to reduce spam. Learn how your comment data is processed.