我就点个外卖，竟然经历了如此硬核的离线数仓迭代……

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

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

一、业务介绍

首先介绍下美团外卖的业务场景，核心交易链路为：用户可以通过美团的各种用户终端（包括美团外卖的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 集群执行。

二、数仓建设

1. 数据仓库V1.0

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

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

开发效率低

数据口径不统一

资源成本高

2. 数据仓库V2.0

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

简化开发流程，提高开发运维效率

明确分层，分主题标准，贯彻执行

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

① 分工标准

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

数据应用组：负责应用指标、应用维度、应用模型，这一组的数据建模特点是：自上而下、面向应用。

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

② 分层标准

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

③ 主题标准

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

1）数仓规范

① 数据仓库建模规范

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

ODS：数据源层，主要职责是接入数据源，并做多数据源的整合。

IDL：数据集成层，主要职责是：业务主题的划分、数据规范化，比如商家、交易、用户等多个主题。这一层主要起到缓冲的作用，屏蔽底层影响，尽量还原业务，统一标准。

CDL：数据组件层，主要职责是划分分析主题、建设各个主题的基础指标，比如商家交易、用户活动等多个主题。这样针对同一个分析对象统一了指标口径，同时避免重复计算。

MDL：数据集市层，主要职责是建设宽表模型、汇总表模型，比如商家宽表、商家时段汇总表等。主要作用是支撑数据分析查询以及支持应用所需数据。

ADL：数据应用层，主要职责是建设应用分析、支撑多维分析应用，比如城市经营分析等。

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

② 数据源层

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

业务库数据：主要是将各个客户端的数据同步 Hive ，主要有用户端、商家端、运营端，同步方法主要采用 binlog 同步，同步方式有全量同步、增量、快照同步三种方式。同时支持业务库分库分表、分集群等不同部署方式下的数据同步。

流量日志：特点是外卖终端多，埋点质量不一，比如单 C 端分类就超过十种。为此公司统一了终端埋点 SDK，保证不同终端埋点上报的数据规范一致，同时使用一些配置工具、测试工具、监控工具保证埋点的质量。整理建设思路是：定义埋点规范、梳理埋点流程、完善埋点工具。

集团数据：包含集团业务数据、集团公共数据，特点是数据安全要求高。目前公司建立了统一的安全仓，用于存储跨 BU 的数据，同时定义权限申请流程。这样对于需要接入的数据，直接走权限申请流程申请数据然后导入业务数仓即可。

三方数据：外部渠道数据，特点是外部渠道多、数据格式不统一，对此我们提供了通用接口对于收集或者采买的三方数据在接入数仓前进行了规范化的清洗。

③ 数据集成层

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

抽象业务过程

识别实体关系，挂靠业务主题，比如交易过程包括提单、支付等过程，把这些业务行为涉及的事实表进行关联，识别出里面的实体关系

兼容数据成本

屏蔽业务变化，比如订单状态变化

统一数据标准，敏感字段脱敏，字段名称标准化等

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

④ 数据组件层

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

建设思路：

识别分析对象，包含分析对象实体以及对象行为

圈定分析边界

丰富对象属性

建设原则：

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

分析对象包括业务实体和业务行为

分析对象的原子指标和属性的惟一封装

为下一层提供可共享和复用的组件

多维明细模型：

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

识别分析对象：首先明确分析对象为商家实体

圈定分析边界：多维明细不需要关联实体行为，只需要识别出实体之后圈定商家属性信息作为分析边界；

丰富对象属性：提取商家属性信息，比如商家的品类信息、组织结构信息等

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

轻度汇总模型：

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

识别分析对象：分析实体是商家，业务行为是交易，分析对象是商家交易

圈定分析边界：圈定提交表、商家信息表、订单状态表、会员表作为商家交易的边界

丰富对象属性：将城市、组织结构等维度信息冗余进来，丰富维度属性信息

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

⑤ 数据集市层

建设思路：

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

宽表模型：订单宽表为例，建设过程为：选定订单实体作为实体对象，然后圈定订单明细、订单状态、订单活动、订单收购等分析对现象通过订单 id 进行关联。这里的宽表模型与数据组件层的多维明细模型的区别在于多维明细模型里的实体对象粒度更细，例如订单宽表中分析对象：订单明细、订单状态、订单活动等都是多维明细模型里的一个个数据组件，这几个数据组件通过订单 id 关联拼接形成了宽表模型。