美团数据仓库,在过去的两年中,与我们的业务一起高速发展。在这一演进过程中,有很多值得总结和沉淀的内容。这篇文档回顾下美团数据仓库这两年发展过程中遇到的各种问题,为什么选择了现在的技术方案,每一个功能和模块是在什么情况下产生的,解决的是什么问题,中间有过哪些弯路。既可以作为大家熟悉美团数据仓库构建过程的一篇文档,也可以作为初次建立数据仓库的参考。

史前时代

在正式建设美团数据仓库之前,数据组也为各部门提供数据支持,不过那个时候的数据需求还比较少,而且也相对简单。

通常的做法是:

  • 工程师写一段PHP或者Shell脚本,从命令行输入参数。
  • 自己连接数据库,通常是一个业务数据库的从库,将需要的原始数据提取出来。
  • 在内存中计算数据。
  • 然后将结果写入一个专门存放统计结果的DB。
  • 再写一个PHP页面作为报表提供给需求方。

这是简单明了的流程,但是随着需求的增加和精细化,有一些问题变得很棘手,并严重影响的开发效率:

  • 有很多重复劳动和代码,比如连接数据库的代码,每个人都要写,各种写法不同,分布在很多地方,如果哪个DB的连接方法变更了,需要更改很多地方。
  • 中间数据缺失,中间计算结果不能共享。比如每个Deal每天的销量,不同的人写报表,每人都可能要重算一次。
  • 很难管理和维护,程序语言五花八门,同一指标可以写多种统计方法,各种语言各种执行方式,缺少文档,其他人很难接手维护。
  • 数据的清洗和转换没有统一方法,比如,哪天是每月第一天或每周第几天这种需求,靠手工调用各种时间函数来计算,非常容易出错。
  • 不同数据源的数据很难综合使用, 比如一个数 据需要使用主站的数据和合同系统的数据, 要把这些数据组织在一起就很麻烦
  • 为了解决这些问题,在2011年Q2初,数据组开始搭建美团的数据仓库。

引入ETL

数据仓库的学术定义有很多版本和特点,其中有几个词能概括这一段工作的特点,规范和集成。

首先需要建立一个DB用于保存从各个数据源提取出来的数据。

  • 第一,解决不同数据源的数据联合使用的问题。
  • 第二,因为是独立的DB,可以进行复杂的计算而不用考虑会影响线上个系统的DB。
  • 第三,可以保留大量需要重复使用的中间数据。
  • 第四,数据在首次进入数据仓库时,就可以进行清洗整理,去掉无效数据和脏数据,添加常用字段比如 datekey。

这一时间的一个重要工作是,引入了一个工具——ETL。ETL是Extract(抽取),Transform(转换),Load(载入)的首字母组合。顾名思义,ETL工具的功能就是抽取数据,经过加工后,再载入到新的位置。

ETL的优点是:

  • 封装了到各个数据库的连接,使得工程师只需要关注数据的抽取和转换逻辑,而不必处理各种数据库的连接细节。
  • 将数据抽取和转换统一使用SQL来表示,形式化的统一使得理解处理过程变的简单,便于不同的人协作开发,同时,用SQL表示逻辑将各种复杂的统计交给关系数据库来处理,也降低了出错的可能性。数据抽取的过程中同时完成各种清洗和转换,替换空值,规范时间表示等。

这一时间也同时确定了很多规范:

用数据表示逻辑,典型例子是,不再使用各种时间函数来计算时间,而是建立一个日期表,把某一天的各种信息属性全部算出来存在一张表里,需要的时候只要连表就可以得到。大大降低了时间逻辑出错的可能性并简化了开发。

将数据分为维度数据,事实数据,衍生数据,聚合数据等类型, 以及第一版的命名规范。 为后续数据的组织和管理奠定了基础。

数据仓库的基础数据建设,一直是数据组的一个主要工作,直到2011年Q4,随着各种数据需求的增加,在如何使用数据上,有了一些新想法。

尝试OLAP

要做数据仓库,而不是数据坟墓,数据如果不被使用,就毫无用处。怎么能供各部门更好的使用这些数据呢?我们要做平台,可供人去探索数据的平台。

2011年下半年,随着美团业务的高速发展,用数据支撑运营变得越来越重要,各种数据需求出现了一个井喷期,开发人手比较少,一时间有些捉襟见肘。

有没有方法能让需求方自助的获取数据,而不依赖RD呢,想到了一个非常流行的概念是OLAP——联机分析处理(相对于OLTP——联机事务处理),目标是做成一个自助探索工具的平台。

从2011年Q4开始到2012Q1,数据组开始调研试用开源的OLAP工具套件。耗时较长,从调研和最后试用的情况看,现有的OLAP系统不适合我们。

有几个主要的问题:

  • 开发和使用太复杂,成本太高。
  • 产品成熟度较低,很多数据需求没法支持。
  • 笨重,不太适应互联网公司快速灵活的节奏。

因为上述原因,到2012Q1, 放弃了OLAP的尝试。

同时在这个时间点上,公司对数据需求的增长,暴露出了数据仓库的很多问题,可以说是需求走在了技术的前面,迫使我们集中力量做很多大规模的升级。

数据仓库是一套完整的环境

2012Q1时,数据仓库出现了很多新的棘手的问题。

  • 首先,有哪些流程在线我们不清楚,什么时间执行的,有没有按时执行不清楚。报表出了问题要查流程历史记录都很难查。
  • 其次,我们已经有了几百个ETL流程,流程之间有执行顺序的依赖关系,但是没有好的工具来管理,靠crontab里设定执行时间间隔。经常出现上游还没有算完,下游就启动了,会出现脏数据。另一方面,并行开发太多,一个人的修改,不知道会不会影响别人,经常出现冲突。
  • 第三,每次都用PHP手写报表,重复工作太多,开发上线都非常复杂。
  • 第四,数据表和指标很多,命名不规范,经常会遇到两个相近概念的比较问题,解释起来非常麻烦,需要遍历整个计算过程才能梳理清楚。

针对这些问题,分别开发了相应的工具。

  • 第一个是流程的注册,管理,查看的工具,每个流程都有了户口本和行为记录。
  • 第二,写工具分析流程之间的依赖关系,画出关系图。
  • 第三,开发调度系统,根据关系图调度ETL流程执行。
  • 第四,抽象报表工具,屏蔽复杂的报表页面开发,将报表抽象为SQL和配置。
  • 第五,建立数据字典,解释每个指标和名词的意思和计算过程。

通过这几项主要工作,美团数据仓库发展到了一个比较成熟的阶段。也正是经历了这样一个过程,我们深刻体会到,数据仓库不仅仅是一个“数据存储的工具”, 数据仓库应该是一套完整的软件环境,它应该包括:数据抽取,计算,存储,查询,展示,以及管理这些过程的工具。

协作开放

美团的数据需求发展非常快,这体现在数据规模的增长,数据分析人员的增长,数据分析复杂程度的增长。2012年下半年,快速发展的数据需求让原有的数据仓库架构达到了瓶颈。无论是DB的计算和存储能力,还是开发人员的精力,都达到了很高的负荷。而且由于开发流程和提取数据的重复劳动很多,团队士气也比较低落。这一时间的迫切工作是,如何能让需求方自助获取数据并分析,如何能让数据的计算和存储方便的扩展。

从2012年中开始,重点推进了几项工作以解决上述问题:

  • 第一,建设主题表,将各种数据按照常用的维度展开成宽达几十列上百列的表,使得查数据非常的容易。比如,将一个城市一天的几百个指标放在一行,以城市id和日期作为主键,不用任何连表,使用简单的语法就能获取关于城市的各个角度的数据。类似的主题表还有用户,订单,Deal等角度。丰富的主题表不但简化了报表开发, 也为非技术人员能够自助查询数据提供了方便。
  • 第二,开发自助查询工具,培训使用,让各个部门的人都能在数据仓库上查自己需求的数据,培训大家使用SQL,自助完成需求。
  • 第三,建立数据集市,按业务拆分,将部分数据导入到各个不同的DB,供业务部门更灵活的数据需求。
  • 第四,将数据的存储和计算,向Hadoop/Hive 分布式平台迁移,已达到线性扩展计算和存储能力的需求。
  • 第五,开放数据的存储和计算环境,让ETL流程的编写和部署Web化,让其它组有能力的RD,可以自己在数据仓库上部署计算流程,计算自己需要的数据。

这几个工作的周期都比较长,现在也在进行中,效果也十分明显,终于有和需求并肩走在一起,没有落后的压迫感了。但还没有走在需求前面。

未来的挑战

美团的成长速度非常快,数据的规模和复杂度还将十倍百倍的增长;业务多样且变化迅速。如何能够在海量数据基础上进行数据的管理、加工、分析以支持快速成长的业务,后续还面临很多挑战。

我们期待对数据敏感、对管理海量复杂数据、对建设大型互联网电商数据仓库有兴趣的朋友们,加入美团数据仓库团队!欢迎投递简历到 diaoshihan(#)meituan.com