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

简介

一转眼在去哪儿网玩乐事业部工做快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. 协调资源

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

2. 搭建仓库

首先选型，kimball仍是inmon，区别就很少说了。选择的是Kimball，为了让运营和产品用的更方便，也产出了宽表，这样宽表能够覆盖90%的需求，宽表+维度表能够覆盖剩下的需求。 

2017的数据仓库结构图以下：

 

3. 维护

数据仓库要准确、及时的产出数据，因为数据分散人力有限，不可能保证全部数据都百分百符合预期，因此要对数据进行分级。首先BOSS关心的报表，以及依赖的数据表是一级重要，要实时的严格校验，这里叫强一致性校验，若是发现问题须要在任什么时候候电话+qt+邮件预警。财务和运营的KPI数据次之，白天qt+邮件预警便可，最后是其余的数据。

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

2018年（数据化运营）

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