美团数据仓库，在过去的两年中，与我们的业务一起高速发展。在这一演进过程中，有很多值得总结和沉淀的内容。这篇文档回顾下美团数据仓库这两年发展过程中遇到的各种问题，为什么选择了现在的技术方案，每一个功能和模块是在什么情况下产生的，解决的是什么问题，中间有过哪些弯路。既可以作为大家熟悉美团数据仓库构建过程的一篇文档，也可以作为初次建立数据仓库的参考。
史前时代
在正式建设美团数据仓库之前，数据组也为各部门提供数据支持，不过那个时候的数据需求还比较少，而且也相对简单。
通常的做法是：
工程师写一段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
- 原文链接：美团数据仓库的演进