微信扫描登录
或者
请输入您的邮件地址来登录或者创建帐号
提 交取 消
GITBOOK.CN需要您的浏览器打开cookies设置以支持登录功能

美团大数据平台的设计与实践

本篇文章整理自郑刚4月23日在『1024大数据技术峰会』上的分享实录:美团大数据平台的设计与实践。

enter image description here

大家好,我叫郑刚,来自美团网,准确说我们公司的名字是新美大。我的演讲内容分为三部分。

第一,讲述美团数据平台的演进过程。
第二,讲述数据平台中一个关键系统-调度系统的设计。
第三,介绍调度系统中的一个技术难点-SQL解析的实践。

enter image description here

美团是一家O2O行业公司,我在2011年加入美团,当年全年的交易额是十多亿,经过几年的发展2015年公司交易额一千多亿,上涨了一百多倍。

美团是一家数据驱动的公司,我们的Hadoop集群超过2000台机器,每天新增20T日志,每天运行22121个在线ETL,支持10个事业群及一级部门上千个PM和分析师的数据需求,在线报表有两千多个。

enter image description here

整个美团大数据体系架构:

底层是计算存储平台,包括HBase、Spark、HDFS,binlog同步,日志平台,实时计算等;

中间层是开发管理平台,包括调度系统、ETL开发平台,确定ETL开发、测试、审计、上线的流程规范;

最上层是应用开放平台,包括自助查询平台、指标提取工具、流量矩阵等;

右侧是元数据管理平台,包括血缘分析、权限管理、自动化建模、数据质量监控等。

enter image description here

更细看一下美团大数据的体系:

左边是业务系统,业务日志通过Flume收集,业务DB数据通过binlog收集,写入kafka;

中间是DW数据仓库,有最基础的维度、事实表,还有经过聚合后的衍生表和主题表,然后是数据集市,有各个事业群的应用表。

下层是系统工具,包括数据开放平台、日志管理、实时计算的管理等,其中的调度系统待会会重点介绍,还有ETL开发引擎。

右侧是面向PM和分析师的BI产品,比如:自助查询平台、指标提取工具,还有一些数据挖掘应用,比如:基础数据挖掘、用户画像,风控反作弊,搜索推荐等。

enter image description here

美团数据平台的演进过程大致是:

2011年Q2之前,叫史前时代,基本没有数据平台和数据仓库;
2011年Q2引入ETL;
2012年Q1开发了调度系统;
2012年Q3开放自助查询;
2012年Q4开放ETL平台供业务RD使用;
2013年Q1数据仓库引擎迁移到Hadoop;
2013年Q2~Q3开发日志平台和实时计算;
2013年Q4迁移到Hadoop2.0;
2014年到2015年做了Hadoop跨机房部署,数据可视化等。

enter image description here

先看一下史前时代,美团网于2010年3月4日成立,在这一年里提数是这样做的:原始数据在DB和日志,通过Python、PHP、Shell脚本做提取和计算,结果存入DB,最后手写报表。

这种方式有几个问题:

第一,有很多重复的代码; 第二,中间的数据缺失,我们不能很好复用中间的结果; 第三,大家使用语言五花八门不好管理; 第四,清洗和转化没有统一方法; 第五,不同的数据源不好综合使用。

enter image description here

2011年Q2引入了ETL的概念,E是Extract提取数据,T是Transform清洗和转换,L 是Load到某个目标库。

ETL的好处: 第一,是可以屏蔽数据库连接的细节,比如可以用标志符,不用写Host和密码; 第二,用数据抽取和转化统一使用SQL表示,如果逻辑比较复杂,SQL搞不定,可以嵌入脚本做转换。

这一阶段有了数据仓库的初步概念,数据被分为维度、事实、衍生数据、聚合数据等。

enter image description here

2012年Q1开发了调度系统。当时的状态是几百个ETL注册在crontab中,依赖关系不清晰,需要手工配置上下游依赖把时间错开。

另外,一些重要数据早上不能按时完成,老大们开晨会时看不到数。因此开发了ETL调度系统,能看到ETL的运行状态,很好的解决了数据运行无序的问题。

enter image description here

再接下来2012年Q3开放了自助查询平台,这一时期数据需求快速增加,数据RD大部分时间都在提数,为了改变被动局面,通过开放自助查询平台,业务方和PM自己写SQL提数,自动生成报表和图。做完这个事情RD生产力得到了解放,有更多时间和资源做一些偏技术和平台的事情。

enter image description here

2012年Q4开放了 ETL开发平台,在此之前ETL是SQL脚本,用GIT管理。

在2012年Q4开发了web系统来管理ETL,为什么要做web系统?

早期美团技术部只有一个数据组,支持整个全公司的数据分析是不太够的,比如酒店和电影有自己的业务RD,他们对自己的业务数据更熟悉,我们希望业务RD能自己做业务领域内的数据分析,因此开放了ETL开发平台。

这个系统包括ETL开发,编写SQL和Python脚本;然后是测试,运行结果是否正常;最后是审计Review和部署上线。做完这个事情数据RD的生产力进一步得到解放。

enter image description here

在2013年Q1将数据仓库迁移到Hadoop1.0。

之前数据仓库的计算在MySQL完成,左边是原始图,将业务DB同步到数据仓库,再生成维度表和事实表放在Data Warehouse,最终的汇总结果存在MySQL。考虑到扩展性和可维护性,我们将数据仓库的整个计算和存储迁移到Hadoop,上面提到的ETL也逐步迁移到Hive。

enter image description here

在2013年的Q2到Q3做了两个比较大的事,一个是日志平台,还有一个是实时计算。

整个框架中一部分是日志数据流,通过flume去收集,另一部分是业务DB数据流通过canal收集,canal是阿里开源的binlog收集系统,这两部分数据统一写入kafka,然后是基于storm的实时计算开发管理平台,提供对topology开发、测试、部署、监控的支持,应用方可以自行开发topology,实时计算用于风控、反作弊、搜索推荐等场景。

enter image description here

2014年Q1把Hadoop从1.0上升到2.0,具体包括:升级到YARN,解决jobtracker单点问题以及提供可扩展的计算框架。

提供交互式查询引擎Presto,由facebook开源,比Hive查询更快。另外做了一些数据安全工作,引入了kerberos认证,对HDFS和Hive表做了权限隔离和队列资源管理。

还有一块是HBase,比如存储用户画像,有一些用户的基本属性,手机号、姓名之类的,还有统计属性如RFM,还有挖掘属性如人群分类:白领,兴趣偏好等,用HBase存储比较方便。

最后尝试Spark,美团自己实现了一些基于Spark的机器学习算法,用于模型的迭代和训练。

enter image description here

在2014年Q3做了一些数据产品相关的工作,早期美团业务跑得非常快,数据发展的也比较粗放,元数据管理做得不好,因此开发了指标提取工具,用户在界面上筛选维度,比如:天、周、月或者再加其他维度,可以选指标,GMV或者订单数,查询方式比写SQL更友好。

2015年之后的项目不展开讲。

enter image description here

接下来重点讲述数据平台调度系统的设计。

这个系统目前支持了2万多个ETL的计算,保证数据仓库稳定运行。

enter image description here

系统架构包括任务定义模块,生成每天要执行的任务;

中间是调度器,一种是定时触发,比如每小时收集上个小时的日志,还有基于依赖关系的调度,源头从业务DB同步数据,再生成维度表,聚合表,ETL之间是有依赖关系的,这里还有优先级的概念。

另外系统支持ETL重导,失败重试,优雅重启,可以配合Hadoop集群和日志平台运维随停随启。

enter image description here

整个系统包括四个关键组件:调度管理、业务运维、智能调度、监控告警分析。

enter image description here

首先是调度管理,最重要的是ETL依赖关系的管理,通过Hive SQL解析提取SQL中用到的表,进而推导出ETL和数据表的依赖管理,最后生成ETL之间的依赖关系,整个流程完全自动化,无需人工配置。通过依赖关系图能清晰看到整个数据的流向,从最原始的log到清洗后的log到dim表等。

enter image description here

二是业务运维,可以方便的查看任务的运行状态,状态可以细分为新建、运行中、正常结束、运行出错等。还可以提交临时任务,如:ETL重导。

enter image description here

三是智能调度,刚才讲到优先级的概念,2015年Q3集群资源非常紧张,在资源有限情况下优先级就很重要,保证核心流程优先执行。下面是一个ETL关系图,可以为每一个任务节点定一个优先级。

比如:酒店产品日报的优先级定为3(3最高,2是其次高, 1最低),优先级从下游节点向上游传播,上游的dim表集成两个下游,取下游优先级中的较大值,也是3,定义好优先级后从上到下能保证核心的流程优先执行。

另外支持失败重试,当任务执行失败时会分配其他宿主机重新执行。

enter image description here

四是关键路径分析,上面提到ETL可能早上还没就绪,可以通过关键路径分析为什么运行的比较晚。

比如图中的ETL有四个上游任务,但是最右边的ETL结束最晚,它是关键路径中的一个节点,继续向源头找结束最晚的父节点,整条路径是制约ETL就绪的瓶颈,需要优化。

enter image description here

最后是优雅重启,比如Hadoop集群运维需要在凌晨重启调度系统,很多任务还没跑完,重启后运行状态如何恢复?

一类是依赖关系调度任务的状态恢复,图中上游三个任务运行完,中间有一个正在运行,下面的任务还没有开始,重启后在内存中恢复整个运行状态图,已经结束的不用再运行,正在运行的需要需要等待运行结束,可以还原重启前的运行状态。

另外是基于crontab的调度,通过quartz重跑missing job,保证运行状态是一样的。

enter image description here

调度系统中的一个技术难点是如何自动解析ETL依赖关系,其中的关键技术是SQL解析。

不少公司也有自己的调度系统,但依赖关系需要手动配置,这种方式的问题是如果ETL内容发生变化,比如之前依赖A上游,现在不再依赖,需要手动去改依赖关系,不是很自动化,容易产生不一致的问题,而我们是自动解析ETL依赖关系。

enter image description here

ETL主体逻辑是Hive SQL。Hive的编译过程如下:首先对输入的HiveSQL进行语法分析生成抽象语法树,然后是语义分析生成QB(QueryBlock),接下来是逻辑分析生成逻辑执行计划,物理计划生成,到最后的Map Reduce Task。提取Hive SQL依赖的表和字段,集中在语法分析和语义分析这一块。

enter image description here

Hive跟其它语言类似,也有自己的文法文件,比如Hive文法文件的词法分析,标志符的定义是以字母或者数字开头,跟着零个或多个字母、数字或下划线。还有语法分析,比如select statement包括select、from、where等短语。

enter image description here

语法分析会生成抽象语法树AST(Abstract Semantic Tree),比如:Select id From a。TOK_TABREF的子节点是a,遍历AST到TOK_TABREF的子节点时能确定是表名,TOK_TABLE_OR_COL的子节点是id,同理可以获取SQL中用到的字段。

enter image description here

可以看一个更复杂的实例,将Select的结果insert overwrite到另一个表,首先SELECT子句对应到TOK_QUERY的子树,外层是TOK_FROM树,通过遍历抽象语法树能提取SQL用到表和字段,并且把字段依赖关系解析出来。

enter image description here

SQL解析应用场景,大概有四大类:

第一,依赖关系管理。
第二,权限管理。
第三,业务数据监控。
第四,SQL性能检查。

enter image description here

表级别依赖关系可以服务于调度系统,除此之外还能生成字段级别依赖关系,对表中的某个字段可以看到上游依赖哪些字段,以及下游影响了哪些字段,字段依赖关系有什么用?

可以做重导剪枝,有时候ETL不是整体出错,只有一个字段计算逻辑出错,没有必要把整个下游ETL重导一遍,只需要重导部分下游,做剪枝。

enter image description here

权限管理。自助查询平台主要面向PM和分析师使用,需要对SQL做权限控制,当用户编写完SQL执行时,首先会调用SQL解析服务分析SQL调用了哪些表和字段,再调用权限系统鉴权,判断用户是否有访问表和字段的权限。

enter image description here

业务数据监控。图中的邮件报表可以看每天的市场份额还有财务部、客户部的数据,其中财务部的数据标红,数据未就绪,这个报表涉及到很多部门,在生成数据时也会调用SQL解析服务,分析SQL中用到哪些表,再调用调度系统查询这些表是否跑完了,如果未完成运行或运行出错,都可以检测出来再进行标红。

enter image description here

SQL性能检查。比如:Join没有on条件,join条件没有主键,SQL语句有问题导致运行效率低下,也能通过SQL解析服务检测出来。以上是SQL解析的应用。

enter image description here

未来的挑战:

第一,海量数据计算。我们现在有2000台机器,美团业务发展非常快,仍然需要探索新的计算框架和存储格式,比如Hive优化,尝试Spark等。

第二,OLAP,自助查询平台更多是AdHoc 查询,我们在做OLAP的尝试,比如:Kylin。

第三,元数据管理。这一块持续在做,正在做一个数据地图的功能,可以方便数据浏览。

第四,可视化查询。自助查询平台的使用成本还是稍微有点高,希望能提供简洁易用的数据可视化工具。

第五,数据质量、安全。数据质量监控,监控这个表是否按时完成,以及监控表中的内容,比如说环比和同比,这些是一些基于规则的配置,也会基于一些数据挖掘的方法做动态的数据监控,比如基于LR学习动态阈值范围。

数据安全方面也是有一些挑战,我们现在数据泄密比较严重,对字段、表、报表的分级和控制会做得更为严格。