##🔝[大众点评]数据仓库技术在大众点评网的实践之路和案例分享
//
数据仓库技术在大众点评网的实践之路和案例分享
http://www.infoq.com/cn/presentations/practice-and-case-sharing-of-data-warehouse-technology-in-dianping
//概要
随着O2O概念在互联网业务中的深度应用，相关业务发展趋于细化、市场竞争趋于白热。作为在消费领域同时提供信息和交易的互联网公司，大众点评在用户流量和交易两方面的业务都趋向精细化开发和运营，这些都对大数据平台提出很高的要求，具体表现在大数据存储/计算平台、数据仓库技术和数据产品设计上的各种Trade-off，本讨论将深度分析点评数据平台在以上三个方面的业务积累和各种取舍。
//
闫剑锋, 博士，大众点评网数据中心负责人 具有15年数据相关研究和工作经历，专业领域在数据平台构建和数据建模，互联网数据产品设计，基于数据仓库和商务智能的知识发现，以及数据挖掘和并行/分布式数据管理系统开发。 曾就职于多家IT和互联网企业，参与高性能数据处理和In-Database分析的相关研发工作，并搭建典型互联网公司的用户行为数据仓库。 目前负责大众点评网数据中心，负责从大数据分布式平台到数据展示产品的技术研发工作，负责从基础数据规范到仓库建模，再到公司指标体系的构建。
//80-90年代: 数据库行业的四大金刚(IBM/DB2/Infosys/sybase): 管好,查好(建立索引), 事务(),
异构数据--整合起来,
//6分:21秒
90--2000年: SAP, Teredata最风光,Oracle,
Oracle开始向上做⏫(对底层的贡献开始没那么大了)---做buiness, 对业务的回答.
OLTP技术(80-90年代的)已经奠定了底层基础.
//8:17 2000-2010年:
mysql散布非常广泛---
facebook的kernel很多都是在mysql之中.
阿里云ADS都是以mysql为基础的
hadoop和cassandra都是解决底层的大数据的存储/计算问题, 历史惊人相似.
客户还是要回答业务问题--sql(HiveQL/SparkSQL)也不想写.
有些公司开始做---数据整合, kafka/flume等等.把数据传进来.
业务和大数据结合的公司产品现在还很少, 比如salesForce
下一个十年会是bigdata warehouse的十年
//13:20
现在互联网创业最火的是o2o(演讲时间为2015年),
互联网是一个方法,会引领各个行业,
京东/旅游/汽车等等都是一个线上和线下的过程.
对大数据处理就是一种比较通用的技术(就像现在的sql技术一样).
缺的就是对业务的理解,
缺的就是数据仓库这样一套思路和体系.
//15:40, 数据集中/一致
大众点评的整个的数据会非常集中, 会在基础平台之上以数据仓库的概念一层一层的去建设,最终释放出来一些比较一致的数据和结果.
//16:10 互联网的一些本质, 互联网方法的三个特点:
//1)水平扩展---数据一定要规范化
(规模化/商业模式可以复制) 规模化代表太多东西,对于数据领域意味着--数据一定要规范化.
规范化之后,大众点评网对于每一个商户的日志/访问情况,都是一份code就能全部看的清清楚楚, 对于一个非常小的面馆,或者大的小南国店,最终看到的东西是一样的,可以用同一套code简单的水平扩展出来, 大众点评可能有2000万家商户,单个去做定制会是非常可怕的事情. 数据领域是有一个规范化的要求.
//2)用户触达---数据可闭环
能够通过终端知道用户在干什么, 对于数据领域的要求是: 数据可闭环, 对于数据仓库的挑战性上带来了很多内容,
SAP有财务系统, CRM系统,各种系统,ERP,
SAP财务系统说你收了多少钱,花了多少钱,成本/收益是多少,
在点评网如果加上用户可触达就复杂了很多,用户花了一千块钱,那这个用户的留存怎么样?第二次来了没有,二个月以后来了没有,花完这笔钱就永远不来了
//3)马太效应---数据精细化/数据驱动
一个行业如果做透的话,只有老大没有老二,
做互联网业务是非常难的一件事,
美国十年前提过一个概念---数据驱动
//22:10
ETL(PB,得到数据,多搜集)->HQL(TB,HQL快查询,得到信息)->DM数据集市/DM->(GB, 得到知识, 回答业务问题)
去统计/学习,看看什么原因导致业务问题.
从底层的数据 变成 可以理解的知识(业务/决策层可以理解的)
//23:10
自上而下,自下而上去做的两波人.
一个人说想看看昨天团购销售额,往下去查,
另一个人说他也查了,发现对不上,开始找错,不停滴找,
最后发现有一个去退款了,有一个没去退款
两拨人的方法转换到技术上来看,需要什么?
报表分析/临时查询,很多数据获取的结果,从结果的角度出发,把他们一路演化
目前看很多都是MapReduce的job,通过HQL的方法,通过一些编程的方法,DataMining通过Spark的MLlib等等, 一直向下--传到下去,变成一些(底层的)技术问题, 在这些过程之中需要一些工具---调度,对大量的任务去做调度.
//24:40
血缘,数据的血缘
//架构
Paste_Image.png
血缘也在调度之中,权限/主数据/数据质量/数据整合等很多东西--这些都是技术上要实现的东西,
在目前的所有开源基础之上,怎么样去完善这样一个数据仓库体系,
//点评的数据平台的发展过程.
Paste_Image.png
技术部同学做了很多mysql表,实现他们的业务,
老板或者产品要什么,各种临时抓取,从mysql里抓取,只要DBA看不见就行,
会遇到很多很多问题,
2012年, 存储计算/通用展示平台, 开始基于开源产品之上构建自己的存储和计算体系和数据展示体系.
2013年,规范/数据仓库,开始定规范,(数据要规范--互联网三个方法论其中之一),在规范的基础之上做数据仓库,日志的规范(每个业务都要打日志),商务的规范(预定的业务和团购的业务都有交易数据,数据间的关联关系是什么?)
2014年, 数据产品, 我们认为差不多了,通过数据产品来约束和统一用户对于数据的使用, 内部会类似于google analitick,去做整个流量的大盘,做运营的dashboard(运营活动效果好坏的dashboard),
2015年, 流式计算,实时的价值开始越来越高, 这是平台级
//27:40
Paste_Image.png
做具体架构之前,先看看你的用户是哪些?
全是内部用户,这些用户有不同特点,
1)有些用户,是技术部门的,拿到用户的feture来做事,需要什么?--需要高可用HA(系统一定要非常稳健),需要编程接口,需要一个service,需要一个开发平台来帮他做事,
2)销售市场部门会要数据质量, 数据质量要求很高(指的是一致性--数据闭环,一定要准确),因为要销售提成,达到一定数值后---向上11%提成,向下8%提成,
3)产品经理,他们对数据产品的要求是什么❓--他们是需要一些指标/指标体系,大的产品经理看DAU/GMV,小的产品经理要看很多细节的东西,他要看这个按钮到那个按钮的click到底是怎么样的,他要看这个颜色换成蓝色和白色之间的区别是什么--A/B test这样的东西,很多细节的指标,
4)运营的人: 运营的人要的东西就更多了, 经常会根本搞不清楚他自己的,这次运营活动对什么的提升会更好,他得有一个预测, 他就去看,他发现这个东西不是我想象的, 无法和老板交代,看看别的指标是否会提升. 本来我要拉新用户的,新用户没拉上来, 那再看看对老用户留存是否有帮助?---他会不停的Ad hoc(即席查询),
//29:50 针对以上的用户群体, 我们整个平台的设计
Paste_Image.png
//1)基础架构
首先一大块,是属于基础架构,基础的运行,存储和计算的架构.核心的基础架构采用的是hadoop/hive/storm/spark. 在展示层面会用到redis/hbase等等.
在此之上我们主要自己研发去做,有很多调度/质量监控/传输/测试/OLAP引擎等等很多这样的工具在做. 有了这些东西之后,用户就可以在平台上看,在平台基础去做,
目标只有一个--快. 用户能写东西写的/实现的很快, 运行的也不错--对性能的要求可能没有那么高 ,相比之下,能拿到正确的数据比快更重要,.
//2.1)数据仓库(ETL:数据的规范/收集/整理/集中存储)
另外一大块体系是数据--即数据仓库, 对基础数据做各种清理,对这些日志做规范/做清理.
在页面要定义规范,比如说 现在的app里会有很多的H5页面,H5页面的日志收集方法和APP是不一样的,只要是页面它收集的东西一定是用js来收集,这两者之间定义什么样的规范/命名规范/调用规范,总之要把他们连接在一起,因为从用户的角度它是一个个的APP和H5是没有区别的.--我们要看用户的体验.
//2.2)数据主题(数据的主题)
在这上面, 我们从用户/商户/交易这样的角度做基础的数据主题,
在此基础上去做, 运营/基础画像/KPI等各种各样的东西,
以上是整个数据仓库的建设过程,
//3)数据产品(数据的价值)
3.1)价值: 我们要对数据的价值有一些判断,那些数据是非常重要的,全公司的KPI指标是非常重要的,某个部门的小指标可能并不重要,
3.2)安全:
3.3)组织和维度: 这些数据是归属于哪个组织的,指标是归属于谁的/哪个部门的,
维度是各种各样的东西,城市是统一的/品类是统一的,等等很多工作,
有了这些,我们就可以应对很多基础性工作,
//4) 数据产品(数据展示/收拢)
2014年,我们开始通过产品的方法收拢,收拢整个的展示,让用户能更快速的看得到, 展示数据,展示最终的结果,包括email发送/微信之类的,
还有开发,我们的客户,很多要处理自己数据,要在此之上做开发,屏蔽底下所有的东西,只在这边做一些开发上线就可以.
运营效果好坏,包括留存,回访如何,交易拉回来的GMV--拉回来的交易额有多少,还有流量,
点评整个数据平台的架构就是如上,大概有一个概念了.
//33:40 案例
//平台中的取舍
Paste_Image.png
Paste_Image.png
建设整个平台过程中,有以下几点是非常值得小心和注意的,
1)首先, 在基础平台这一块,平台中我们是有一些取舍, 最重要一点是 实时和离线的统计,
老板总是很可恨的 ,问你这个数据出出来没有, 我随时都想看到,可不可以做到, one size not fit all, 做不到怎么办--我们就做一些取舍,
1/2)实时数据: 时效性强/一致性弱, 比如算时效奖金,错10块钱都不行,某种意义上叫一致性,
2/2)离线数据: 用户画像举例,这个人的用户行为在过去很长时间积累里面,已经有了自己的特性,实时只能对它有增强效果,没有决定性效果,至少男女年龄不会改变, 离线统计部分的价值会很高
我们以这样的原则(CAP)来和需求/和我们的客户来谈,
客户说我们想看DAU数据,我们会说没问题,但是对不起,它一定会和batch的计算差5%左右,否则你会给自己挖坑,
//36:00 实时架构
Paste_Image.png
1/3) APP手机前端日志,
2/3)app server收集后端日志,
3/3)mysql收集的是业务数据,多少交易/多少单子
传输数据到-->自研系统(Blackhole/puma<binlog>)-->最后灌入到storm-->持久化(one size not fit all,通过不同系统做持久化,通过不同特点来走) --> data service向外提供服务
//data service
异构数据源,不同系统之中的数据应该怎么办,对用户来讲,希望通过一个data service来搞定--内部的事情我们自己去做(封装在服务内部去).
//37:00 建模中的取舍
Paste_Image.png
建模中,我们的取舍是最严重的,
有三个取舍,
1/3)业务变化 VS 基础稳定:
业务经常会发生变化,基础又要非常稳定,基础数据要非常稳定, 两者之间怎么办
2/3)维度多样 VS 口径一致
维度非常多样,口径要一致, 去退款的例子,
3/3) 运营精细 VS指标全面,
//1/3)业务变化 VS 基础稳定:
Paste_Image.png
自上而下或自下而上方式建模型,可能是星型模型/雪花模型,
//1)变动小: 对流量这样的体系,采用自底而上方式,
写代码/做业务的人不care日志, 我可以在日志基础上尽情做我想做的事情,定义好这样的日志,在此基础上做,
2)变动大: 比如销售的奖金计算规则(有可能一个礼拜就变一次), 运营活动里的分析,
我们只能采用自顶向下的方式来建设, 要非常清楚地知道他到底需要知道什么样的东西,
比如在销售计算里,最开始可能只是签单多少,卖了多少,到后来要看新客有多少在用,后面可能还有流量,多少人访问了你这个单子---必须要自顶向下的来走,
3)还有些线上线下串联的工作,
比如: 运营活动里,运营活动总是最后要看效果的,下单下了多少,10单还是20单,可是会有一个现象,我们在app上先点了第一个运营活动,再点了第二个运营活动,然后我们下的单, 单算的话,
0元看电影:这是一个线上线下串接的很好例子,
第一个活动有可能帮助你留住了用户也说不准,
---我们要自底向上的设计流量模型,设计流量的树状模型,每一个运营活动的页面都放好,用户都浏览过哪些页面...然后我们自上而下地去看,怎么样去分配利润,
//维度多样 VS 口径一致
核心数据一定和CFO/CEO讨论清楚,到底应该怎么定义,我们为此吃过很多很多的亏,
数据中心自身的强大来定义所谓的规则/规范,使得上面的工作非常的简洁/容易,
//运营精细化 VS 指标全面
两者之间也是有很多矛盾,
1)用户在大规模的,高级用户在指标的全面性上有很高要求,要看DAU/订单的效率/订单金额/,
2)小级别用户会有N多的需求,
//产品设计
Paste_Image.png
通过产品来约束用户,设计真正的数据产品过程之中,也会有一些坑,坑分成两大类,
//1/2) 业务闭环 VS 数据闭环
产品经理/运营/开发是个小闭环--业务闭环,
而对于转化率/点击率/CPM展示率/好评率--这些东西是由自己来负责,数据会在纵向的闭环--从最高的指标一直到一直落到最下面的日志规范,这中间起到一个闭环作用, 由我们去定义...业务自身去做一个横向的闭环.
//2/2)产品的矛盾,
每个部门,都有自己运营活动的平台,工程师会做一个平台,让运营人员在上面自己去做事--就相当于自助
但是平台只针对于电影,运营自然会提需求,去帮我把运营效果分析下...而数据部门会看公司所有的数据结果,这两者之间是有矛盾的,从产品的角度会不同,
DAU有各种各样不同的产品,那之间怎么做,
交互的方式上可以做嵌入,
//44:45
点评网对于数据仓库技术在互联网领域的应用,有这样一个未来的规划,
Paste_Image.png
分成两拨来看,一波是硬技术--平台技术/工具技术/产品技术,
另外一波是软技术,是数据仓库技术
1)基础模型,基础框架,基础报表,
2)在此基础上,做维度统一,主题定义上面做一些事情
3)第三阶段, 流式计算,性能优化, 数据模型上要在一致性和数据驱动性上做事, 目前我们刚刚爬上第三个阶段,
-- End --
