美团外卖离线数仓建设实践_架构_DataFunTalk

快手、孩子王、华为等专家分享大模型在电商运营、母婴消费、翻译等行业场景的实际应用了解详情 



 写点什么

导读：美团外卖数据仓库主要是收集各种用户终端业务、行为数据，通过统一口径加工处理，通过多种数据服务支撑主题报表、数据分析等多种方式的应用。数据组作为数据基础部门，支持用户端、商家端、销售、广告、算法等各个团队的数据需求。本文主要介绍美团外卖离线数仓的历史发展历程，在发展过程中碰到的痛点问题，以及针对痛点做的一系列优化解决方案。

01 业务介绍

首先介绍下美团外卖的业务场景，核心交易链路为：用户可以通过美团的各种用户终端（包括美团外卖的 APP 或者美团 APP、QQ/微信等）下单，然后商家接单、骑手配送，三个阶段完成一笔交易。这一系列交易过程，由包括用户端、商家端、配送平台、数据组、广告组等各个系统协同完成。

这里主要介绍外卖数据组在整个业务中角色。外卖数据组主要是：

给用户端、商家端提供业务需求，
给前端提供需要展示的数据，
给广告、算法团队提供特征等数据，提高算法效率
向城市团队提供业务开展所需数据
前端提供埋点指标、埋点规范相关数据

1. 整体架构介绍

美团外卖整体分为四层： 数据源层、数据加工层、数据服务层、数据应用层。

数据源层：包含接入的原始数据，包括客户端日志、服务端日志、业务库、集团数据、外部数据等。

数据加工层：使用 Spark、Hive 构建离线数仓、使用 Storm、 Flink 实时数仓。在数仓之上针对服务对象建设各种数据集市，比如：

面向总部使用的总部数据集市
面向行为数据的流量数据集市
面向线下城市团队的城市团队集市
面向广告的广告集市
面向算法的算法特征

数据服务层：主要包括存储介质的使用和数据服务的方式。

存储：主要使用开源组件，如 Mysql, HDFS, HBase, Kylin, Doris, Druid, ES, Tair 等
数据服务：对外数据查询、接口以及报表服务

数据应用层：主要包括主题报表、自助取数工具、增值产品、数据分析等支撑业务开展，同时依赖公司平台提供的一些工具建设整体数据应用。

2. ETL on Spark

我们离线计算从 17 年开始从 Hive 迁移到 Spark，目前大部分任务已经迁移到 Spark 上运行，任务迁移后，相比之前使用 Hive 整体资源节省超过 20%。相比之下 Spark 的主要优势是：

算子丰富，支持更复杂的业务逻辑
迭代计算，中间结果可以存内存，相比 MR 充分利用了内存，提高计算效率
资源复用，申请资源后重复利用

这里简单介绍写 Spark Sql 的任务解析流程：客户端提交任务后，通过 Sql 解析先生成语法树，然后从 Catalog 获取元数据信息，通过分析得到逻辑执行计划，进行优化器规则进行逻辑执行的优化，最后转成物理执行计划提交到 spark 集群执行。

02 数仓建设

1. 数据仓库 V1.0

2016 年之前。外卖数据组的情况是：团队不大，数据量不多，但是市场竞品较多（饿了么、百度等），竞争激烈，因此当时数据组的目标是：快速响应业务需求，同时做到灵活多变，支撑业务业务决策，基于这种业务背景和实现目标，当时数仓架构设计如图所示主要分了四层，分别是：ODS 层/明细层/聚合层/主题层/应用层（具体如图示）。

随着数据量、业务复杂度与团队规模的增长，为更好完成业务需求数据组团队按照应用做拆分，比如面向总部的总部团队、面向城市业务的城市团队，各个团队都做一份自己的明细数据、指标和主题宽表数据，指标和主题宽表很多出现重叠的情况，这时候就像是”烟囱式“开发。这在团队规模较小时，大家相互了解对方做的事情，基本不会有问题；但是在团队规模增长到比较大的时候，多团队“烟囱式”独立作战也暴露出了这种架构的问题，主要是：

开发效率低
数据口径不统一
资源成本高

2. 数据仓库 V2.0

针对上述问题，数据组做了架构的升级，就是数据仓库 V2.0 版本。此次升级优化的目标主要是：

简化开发流程，提高开发运维效率
明确分层，分主题标准，贯彻执行

完成这个目标的思路如下三个方面：

① 分工标准：

之前面向不同应用建立不同团队完全纵向切分，会导致可以公用的部分明细数据重复开发。为改变这种情况将数据团队改为：数据应用组和数据建模组。各组职责如下：

数据应用组：负责应用指标、应用维度、应用模型，这一组的数据建模特点是：自上而下、面向应用。
数据建模组：负责基础事实、基础维度、原子指标的数据开发，这一组的数据建模特点是：自下而上、面向业务。

② 分层标准：

在原有分层的基础上，再次明确各层的职责，比如：明细层用来还原业务过程，轻度汇总曾用来识别分析对象；同时数据加工时考虑数据的共性、个性、时效性、稳定性四个方面的因素，基于以上原则明确数仓各层达到数据本身和应用需求的解耦的目标。具体各层细节在文章接下来的内容会展开来讲。

③ 主题标准：

根据数仓每层的特性使用不同的主题划分方式，总体原则是：主题内部高内聚、不同主题间低耦合。主要有：明细层按照业务过程划分主题，汇总层按照“实体+活动”划分不同分析主题，应用层根据应用需求划分不同应用主题。

2.1 数仓规范

① 数据仓库建模规范

根据前述三个方面的思路，将数仓分为以下几个层次：

ODS：数据源层，主要职责是接入数据源，并做多数据源的整合
IDL：数据集成层，主要职责是：业务主题的划分、数据规范化，比如商家、交易、用户等多个主题。这一层主要起到缓冲的作用，屏蔽底层影响，尽量还原业务，统一标准。
CDL：数据组件层，主要职责是划分分析主题、建设各个主题的基础指标，比如商家交易、用户活动等多个主题。这样针对同一个分析对象统一了指标口径，同时避免重复计算。
MDL：数据集市层，主要职责是建设宽表模型、汇总表模型，比如商家宽表、商家时段汇总表等。主要作用是支撑数据分析查询以及支持应用所需数据。
ADL：数据应用层，主要职责是建设应用分析、支撑多维分析应用，比如城市经营分析等。

其中 ODS/IDL/CDL，以及部分 MDL 集市由数据基建组来做，另外部分数据集市以及 ADL 应用层由数据应用组支撑，分工标准是涉及一些公共的数据集市由数据基建组来完成；数据应用组会围绕应用建设应用数据集市，如流量集市、城市经营集市。

② 数据源层

整体建设思路：从数据源落地到 Hive 表，同时与数据来源保持一致，尽量还原业务。主要由四类数据源：业务库数据、流量日志、集团数据、三方数据。

业务库数据：主要是将各个客户端的数据同步 Hive ，主要有用户端、商家端、运营端，同步方法主要采用 binlog 同步，同步方式有全量同步、增量、快照同步三种方式。同时支持业务库分库分表、分集群等不同部署方式下的数据同步。
流量日志：特点是外卖终端多，埋点质量不一，比如单 C 端分类就超过十种。为此公司统一了终端埋点 SDK，保证不同终端埋点上报的数据规范一致，同时使用一些配置工具、测试工具、监控工具保证埋点的质量。整理建设思路是：定义埋点规范、梳理埋点流程、完善埋点工具。
集团数据：包含集团业务数据、集团公共数据，特点是数据安全要求高。目前公司建立了统一的安全仓，用于存储跨 BU 的数据，同时定义权限申请流程。这样对于需要接入的数据，直接走权限申请流程申请数据然后导入业务数仓即可。
三方数据：外部渠道数据，特点是外部渠道多、数据格式不统一，对此我们提供了通用接口对于收集或者采买的三方数据在接入数仓前进行了规范化的清洗。

③ 数据集成层

数据集成层主要是明细数据，与上一层数据源层是有对应关系的。数据集成表的整体建设思路为：

抽象业务过程
识别实体关系，挂靠业务主题，比如交易过程包括提单、支付等过程，把这些业务行为涉及的事实表进行关联，识别出里面的实体关系
兼容数据成本
屏蔽业务变化，比如订单状态变化
统一数据标准，敏感字段脱敏，字段名称标准化等

如图中示例为提单表建设过程。

④ 数据组件层

数据组件层，主要建设多维明细模型、轻度汇总模型。总体建设思路与建设原则为：

建设思路：

识别分析对象，包含分析对象实体以及对象行为
圈定分析边界
丰富对象属性

建设原则：

数据组件层生成的指标主要是原子指标，原子指标形成数据组件，方便下游的集市层以及应用层拼接数据表。

分析对象包括业务实体和业务行为
分析对象的原子指标和属性的惟一封装
为下一层提供可共享和复用的组件

多维明细模型：

以商家信息表建设过程为例：

识别分析对象：首先明确分析对象为商家实体，
圈定分析边界：多维明细不需要关联实体行为，只需要识别出实体之后圈定商家属性信息作为分析边界；
丰富对象属性：提取商家属性信息，比如商家的品类信息、组织结构信息等

以上信息就形成了一个由商家主键和商家多维信息组成的商家实体的多维明细模型。

轻度汇总模型：

以商家交易表假设过程为例：

识别分析对象：分析实体是商家，业务行为是交易，分析对象是商家交易
圈定分析边界：圈定提交表、商家信息表、订单状态表、会员表作为商家交易的边界
丰富对象属性：将城市、组织结构等维度信息冗余进来，丰富维度属性信息

汇总商家粒度、交易额等原子指标最终建立商家交易表。

⑤ 数据集市层

建设思路：

建立宽表模型和汇总模型。两者区别为宽表模型是唯一主键，基于主键拼接各种信息；汇总模型的主键类型为联合主键，根据公共维度关联生成派生指标，丰富信息。

宽表模型：订单宽表为例，建设过程为：选定订单实体作为实体对象，然后圈定订单明细、订单状态、订单活动、订单收购等分析对现象通过订单 id 进行关联。这里的宽表模型与数据组件层的多维明细模型的区别在于多维明细模型里的实体对象粒度更细，例如订单宽表中分析对象：订单明细、订单状态、订单活动等都是多维明细模型里的一个个数据组件，这几个数据组件通过订单 id 关联拼接形成了宽表模型。
汇总模型：商家时段汇总表为例，建设过程为：选定商家、时段维度作为维度组合，圈定商家和时段维度相关的表，通过公共维度进行关联、维度冗余，支持派生指标、计算指标的建设。这里区别于组件层的轻度汇总模型，在数据组件层建设的是原子指标，而数据集市层建设的是派生指标。

⑥ 数据应用层

建设思路：根据应用场景选择合适的查询引擎

选型考虑因素： OLAP 引擎选型考虑以下 8 个方面的因素：

数据规模是否适合
SQL 语法的支持程度如何
查询速度怎么样
是否支持明细数据
是否支持高并发
是否支持数据检索
是否支持精确去重
是否方便使用，开发效率如何

技术选型：早期主要使用 Kylin ，近期部分应用开始迁移 Doris。

模型：根据不同 OLAP 引擎使用不同数据模型来支持数据应用。基于 Kylin 引擎会使用星型模型的方式构建数据模型，在 Doris 支持聚合模型，唯一主键以及冗余模型。

2.2 数仓 V2.0 的缺点

前面几小节对数仓 2.0 做了详细的介绍，在数仓 2.0 版本的建设过程中我们也遇到了一些问题。前面有提到数据集成层与组件层由数据基建组来统一运维，数据应用层是由数据应用组来运维，这样导致虽然在集成层和组件做了收敛但是在应用层和集市层却产生了膨胀，缺乏管理。

面对这个问题，我们在 2019 年对数仓进行了新的迭代，即数仓 V3.0，下面将对此做详细介绍。

3. 数据仓库 V3.0

总体愿景：数仓 3.0 优化思路主要是使用建模工具替代人工开发。

建模工具：分为基础的建模工具和应用层建模工具。

基础层建模工具：主要是在元数据中心记录维护业务过程、表的关联关系、实体对象、识别的分析对象，基于维护的信息构建数据组件以供应用层和集市层拼接
自助查询工具：根据数据组件和用户选取的需要查询的指标维度信息构建逻辑宽表，根据逻辑宽表匹配最佳模型从而生成查询语句将查询出来的数据反馈给用户。同时根据用户查询情况反过来指导建模，告诉我们需要把哪些指标和哪些维度经常会放在一起查询，根据常用的指标、维度组合建设数据组件
应用层建模工具：依赖数据组件，包括数据组件层的多维明细数据、轻度汇总数据以及集市层的宽表等构建构建数据应用。主要过程是获取所需数据组件，进行数据裁剪，与维表关联后冗余维度属性，按需进行上卷聚合、复合指标的计算，最终把获取到的多个小模型拼接起来构建数据应用

通过整套工具的使得数据组件越来越完善，应用建模越来越简单，以上就是数仓 3.0 的整体思路。

03 数据治理

1. 数据开发流程

先说下我们数据开发流程，数据开发流程主要分为四个阶段：需求分析、技术方案设计、数据开发、报表开发 &接口开发，具体内容如下：

需求分析：在需求分析阶段，产品会设计一个需求 PRD 以及列出指标维度矩阵，然后需求评审与需求相关人员进行沟通，做一些数据的探查
技术方案设计：完成需求分析之后，形成模型设计的技术方案，同时将方案落地到文档进行技术方案的评审
数据开发：完成技术方案的设计与评审就正式进入了数据开发以及测试阶段
报表开发 &接口开发：数据开发完成之后进入具体应用的开发

在整个数据开发流程中，我们遵循的整体思路是：

数据标准化
标准系统化
系统一体化

即数据符合标准规范，同时将标准规范落地到系统里，最后系统要和周边应用打通，形成一体。下面对各个思路做详细的描述。

① 数据标准化

在数据标准化这块，数据产品团队、数据开发团队、数据分析团队联合建立了数据标准化委员会。数据标准委员会制定了《指标标准规范》、《维度标准规范》以及一些新增指标、维度的流程等一系列规范标准，这样做的好处是：指标维度管理有据可依，指标维度管理有组织保障，保障各业务方指标维度口径清晰统一。

② 标准系统化

明确了数据标准各项规范，需要将这些标准化规范落地到系统，就是我们的数据治理平台，我们的数据治理平台由自建系统 + 集团数据服务构成。这里面主要有四层： 数据生产工具、集团基础平台、元数据层、数据服务层。

数据生产工具：数据生产主要依靠平台的计算能力，包括离线生产平台、实时生产平台、调度管理平台
集团基础平台：数据生产工具之上是集团基础平台，包括数据资产管理、元数据管理、数据质量管理、资源管理以及权限管理
元数据层：元数据与数据服务都是美团外卖自己业务做的一些工作，元数据层包括数据模型、表/字段、主题/层级、指标/维度、业务过程、词根/词库
数据服务层：服务层包含有数据标准化，前面提到的指标流程、维度流程、认证管理都是在这里落地；同时把业务管理起来，包括理业务大盘、业务过程、数据域管理；然后还管理我们的数据模型包括指标维度矩阵、事实逻辑模型、维度逻辑模型；同时提供元数据服务，包含业务元数据、技术元数据以及维度服务；还有刚才提到的一些在线建模工具

图片右边展示了我们的元数据模型，从下而上，我们首先维护词根组成的词库，同时词根、词库组成我们的指标和维度，其中维度分为维表和码表，指标在确保唯一性的前提下划分业务过程，同时区分原子指标、派生指标、计算指标；然后由维度和指标拼接成字段、字段组成表，表再和业务主题、业务过程相关联，识别出实体、行为，区分事实表、维度表同时确定表所在的层级，最后由一张张的表组成我们的数据模型，整个过程就是我们的元数据模型。

③ 系统一体化

有了前面的数据信息之后，我们和下游对接就比较方便。使用到数据治理平台的数据下游有：

报表系统：报表展示所需的指标维度信息、模型信息都是来自于数据治理平台，
数据超市：数据超市的自助取数里根据指标、维度、数据组件构建数据查询，这些信息都是来自数据治理平台，
海豚数据平台：海豚数据平台是我们的外卖数据门户
异常分析平台：对指标维度的波动进行监测分析
CRM 系统：面向一线城市团队的数据展示
算法平台：向算法平台提供标签、特征数据的管理
画像平台：管理画像平台的人群标签
数据 API 服务：对外提供的 API 模型以及接口的信息
到家数据检索：到家业务元数据联通，统一检索元数据信息
公司元数据平台：向公司元数据平台提供元数据信息

通过与各个下游不同形式的对接，数据治理平台完成了整个下游数据应用的联通，以及支持数据使用与生产，形成了一体化的系统。

2. 资源优化

资源优化方面，在美团会把核算单元分成若干个租户，然后把资源分配给各个租户，在同一个租户里各个项目组协调分割分配到资源，项目组由任务和数据组成。

我们把租户与对应主题进行挂靠，这样就可让租户有对应的接口人管理，比如把外卖核算单元分为：数仓租户、广告租户、算法租户以及其他的业务租户，让每个租户对应一个接口人，与接口人对接资源优化方案、规则，最后由接口人推动。

我们的优化规则主要分为三个方向：

流量：流量方面，主要是对无效 ODS 下线从而降低存储与传输成本；同时埋点数据生命周期减少成本浪费，目前用户日活几千万，上报的流量日志是有上百亿，埋点若不再使用对存储与传输成本浪费较大；另外对日志进行序列化压缩处理降低成本
存储：存储方面我们使用 ORC 进行压缩，同时对冷热数据做了生命周期管理，另外也通过模型的优化以及文件的优化把存储成本控制住
计算：计算方面对无效任务进行下线、 ETL 任务优化；同时对数据开发收敛，把业务中公共部分收敛到数据组

有了优化规则，针对规则的运营监控流程为：首先对账单分析，账单主要有离线/实时计算资源、存储资源、ODS 数据收集使用的资源、日志中心所使用的资源，分析帐单后定义运营规则并将规则落地到数据运维平台，由数据运维平台将任务推送到相关责任人，责任人收到通知后，在数据资产中心做相关处理，同时数据运维平台会做成本监控，对超出配额 &预算异常进行报警。

这样我们通过建立统一规则并将规则分发到不同租户落地执行，完成数据资源优化的目标。

3. 数据安全

数据安全方面主要是对数据脱敏，数据保密等级的设定 (C1~C4)，数据申请做权限控制，审计数据使用的方式，我们分三个阶段完成数据安全的治理：

事前：包括敏感数据脱敏、数据权限控制。针对事业部内、事业部外使用不同的权限流程控制。
事中：包括敏感 SQL 的预警与拦截，针对敏感 SQL 我们进行拦截并由数据安全人员进行审批
事后：包括敏感 SQL 审计，操作异常审计。输出敏感 SQL 审计的月报发到对应的部门负责人，审核内容主要有敏感 SQL 的查询、数据操作异常及后续审批还有全量查询日志分析。