去哪儿网玩乐事业部-数据模式演进

简介

一转眼在去哪儿网玩乐事业部工作快4年了,经历了数据团队的组建和发展,回顾一下整体过程,经历了很多坎坷,普通而不简单。下面是大事记

  • 2014年(系统搭建):开发报表平台、接入HADOOP、搭建调度系统
  • 2015年(数据集市):搭建数据集市、开发数据同步工具
  • 2016年(数据应用):系统定价、多维分析
  • 2017年(数据重构):重构底层、数据分级、元数据、数据质量
  • 2018年(数据化运营):实时系统、用户画像、模型搭建

2014年(系统搭建)

2014年组建数据团队,整体结构如下:

当时迅速的理解了业务,区分出来了核心主题,主要工作是数据(数据报表)支持。 2014年大数据还是比较新鲜的,部门非常重视,配置了NB的产品和技术,老大在很多重要场合宣称部门要转向数据化运营,产品和运营的KPI由数据产考核,并且为此搭建了CRM系统。每次想到这里都感慨BOSS的眼光,我当时就是想不明白,出个数据有啥作用。N年后的现在,没有数据,怎么精细化产品和运营...

按理说数据团队应该策马奔腾迈向小康社会了。但是蜜月期很短,几个月后就逐步出现了问题。最主要的表现是BOSS、产品、运营看见的数据不一致、不及时,有时甚至不准确....

2015年(数据集市)

蜜月期过了之后,BOSS经常在重要场合表达对数据团队的失望,我记得非常清楚的话是:“你们知道我为了TMD数据团队背后做了多少努力吗?我咨询了XXX个公司,XXX说咱们的数据,TMD1个月就能搭起来”。或者是:“你们到底要做什么,难道就是一个提数的吗?好,你们就做一个提数的工具吧!”。当时的情况:http://www.cnblogs.com/liqiu/p/4869748.html

重新审视了数据的问题之后,决心从底层做起,搭建数据集市(数据宽表)。效果确实很好,缓解了数据一致性、数据及时性、数据准确性的问题。大家对数据团队的期望基本稳定了,系统也随之稳定了下来。

2016年(数据应用)

数据稳定之后,希望做一些有意思的东西出来,首先就是解决数据同步的问题,业界有sqoop、dataX,但是对于PG支持的不好,特别是PG的扩展属性,比如hstore支持的有限,所以决定自己开发。

1 数据同步

项目名称是synchronous,它的设计借鉴了DATAX的插件设计理念,DATAX的文档:https://github.com/alibaba/DataX。synchronous和DATAX的技术上区别是:代码小巧,精炼,易懂易读,有兴趣的同学可以快速深入,读懂了synchronous有助于快速理解DATAX。

下面简单介绍下synchronous:

  1. 选择同步的双方:插件的好处就是扩展性强,可随时增加数据源
  2. CHECK元数据:至少两边的数据字段要一致
  3. 选择数据分片:数据量可能很大,需要分片处理
  4. 同步数据:采用多线程的生产者消费者模型

 

详细设计过程可见:http://www.cnblogs.com/liqiu/p/4882821.html ; 代码在:https://github.com/autumn-star/synchronous

2 系统定价

去哪儿以前是taobao的模式,只提供平台和流量。后来有了自营产品,随着业务的发展,自营产品越来越多,定价就是问题了。按照一般的策略是保证利润率的情况下,比竞对低一点。

3 自动化接口

经常需要给外部提供数据,如果每个都写dao、dto、service和controller,开发和维护成本特别高,所以研发了一个系统,配置SQL直接吐出数据接口数据,比如一个接口需要统计一段时间每个产品的订单量和份数,那么数据表里面保存这样一个记录,主键id是1:

SELECT
  product_id, --产品id
  SUM(quantity) as quantity, --份数
  COUNT(1) as order_num --订单量
FROM table1
WHERE stat_date between @{start_date} and @{end_date}
GROUP BY product_id

访问的时候,带着参数就可以,比如:url?id=1&start_date=2017-01-01&end_date=2017-10-01。这样就吐出了时间在2017-01-01~2017-10-01之间的数据。

4 多维

为了将开发从无休止的SQL需求中解救出来,搭建了多维系统,就是数据立方体。当时用的是saiku+kylin,可是saiku需要持久的前端投入,kylin对少量维度支持的还好,维度达到几十个之后就出现问题了,所以这个项目就暂定了。但是底层数据还在,我们转而推出一个页面转成SQL的简易方案(不支持上卷、下钻、跨天和图形对比),虽然交互性差,但由于成本极低,一直支持长尾的数据需求。

2017年(数据重构)

年初遇到了一些问题,技术方面:1、部分数据产出延迟;2、维护成本高,人员流动性高;3、宽表不能完全满足需求,随之关联了几十上百张数据表;业务方面没有明确的收益预期;

调研了携程、阿里的数据体系之后,决定先重新搭建数据仓库,解决提升数据质量和降低人力成本,然后再发展个性化应用。步骤如下:

1. 协调资源

所谓资源,就是要人和时间。向BOSS说明兄弟部门投入多少多少人力和时间达到了什么效果,反观咱们只有那么点点...当然由于众志成城、团结一心,可以只用XX成本就能达到那个效果...历经N次电话会议,终于理解了数据仓库的搭建方案和应用细节

2. 搭建仓库

首先选型,kimball还是inmon,区别就不多说了。选择的是Kimball,为了让运营和产品用的更方便,也产出了宽表,这样宽表可以覆盖90%的需求,宽表+维度表可以覆盖剩下的需求。 

2017的数据仓库结构图如下:

 

3. 维护

数据仓库要准确、及时的产出数据,由于数据分散人力有限,不可能保证所有数据都百分百符合预期,所以要对数据进行分级。首先BOSS关心的报表,以及依赖的数据表是一级重要,要实时的严格校验,这里叫强一致性校验,如果发现问题需要在任何时候电话+qt+邮件预警。财务和运营的KPI数据次之,白天qt+邮件预警即可,最后是其他的数据。

数据仓库的迭代周期也很关键,业务主要使用的是宽表,我们总结了以往的经验后,发现业务经常遇到新需求就希望在宽表增加字段,避免关联的烦恼,随着字段的增加,又不控制必然会重新陷入到到自然演化体系的困局。所以采用的办法是建立一个原则:准确+常用。如果符合这个原则的属性,是以月为单位排期加入到宽表里面,这样宽表就有了生命力

2018年(数据化运营)

这是正在进行的,仅介绍一下愿景,随着精细化运营的来临,必然对数据提出更细致更及时的要求,那么以离线为主T-1的瓶颈更加凸显出来,所以要搭建实时的数据仓库。另外随着分析经验的积累,不能像以前那样粗狂的看报表,而要细分用户群,采用不同的策略,所以需要高质量的用户画像,那么今年会从实时+用户画像两个方面展开...

posted @ 2018-02-01 18:39  李秋  阅读(1921)  评论(1编辑  收藏  举报