美团数据仓库的演进

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

史前时代

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

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

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

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

引入ETL

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

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

尝试OLAP

• 开发和使用太复杂，成本太高。
• 产品成熟度较低，很多数据需求没法支持。
• 笨重，不太适应互联网公司快速灵活的节奏。
  因为上述原因，到2012Q1， 放弃了OLAP的尝试。
  同时在这个时间点上，公司对数据需求的增长，暴露出了数据仓库的很多问题，可以说是需求走在了技术的前面，迫使我们集中力量做很多大规模的升级。

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

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

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

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

• 第一个是流程的注册，管理，查看的工具，每个流程都有了户口本和行为记录。
• 第二，写工具分析流程之间的依赖关系，画出关系图。
• 第三，开发调度系统，根据关系图调度ETL流程执行。
• 第四，抽象报表工具，屏蔽复杂的报表页面开发，将报表抽象为SQL和配置。
• 第五，建立数据字典，解释每个指标和名词的意思和计算过程。
  通过这几项主要工作，美团数据仓库发展到了一个比较成熟的阶段。也正是经历了这样一个过程，我们深刻体会到，数据仓库不仅仅是一个“数据存储的工具”， 数据仓库应该是一套完整的软件环境，它应该包括：数据抽取，计算，存储，查询，展示，以及管理这些过程的工具。

协作开放

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

还有很多挑战