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