阿里数仓规范化，菜鸟数据模型管理实践

导读：本文将分享菜鸟数仓规划过程中的数仓管理模型实践，主要围绕以下内容展开：- 菜鸟末端业务介绍

• 模型管理整体规划
• 数据建模平台建设
• 总结&展望
• 问答环节

分享嘉宾｜王智龙 菜鸟 末端数仓公共层模型负责人 分享嘉宾｜董晃 菜鸟 公共数据数仓研发工程师 ## 01/菜鸟末端业务介绍

1. 菜鸟末端业务简介

菜鸟驿站建设的初衷是面向社区和校园，提供最后一公里物流服务平台，为消费者提供包裹代收、包裹代寄等服务，在此基础之上基于社区生活，完善末端驿站的服务能力，为消费者提供更多生活服务，比如驿站洗衣、家电清洗等，这就是菜鸟末端业务的定位。 接下来介绍菜鸟末端整体业务的情况。 ### 2. 菜鸟末端业务大图

业务大图主要分上下两部分，下面是我们业务的核心能力，上面是菜鸟末端的垂直业务。 - 核心能力包括网络建设和硬件打造。网络主要包括网络拓点、网络运营和网络管理。为了提高驿站站点的效率，我们打造了诸多的 IOT 设备，如高拍仪、巴枪、云监控、小票打印机、小易工作台、寄件机等。

• 垂直业务包括代收、寄件、商业化、数智驿站、消费者体验&运营和绿色公益。

3. 菜鸟末端业务数仓架构整体设计

基于上面的业务大图，接下来讲讲我们的数仓架构： 最左边是菜鸟集团使用的统一大数据开发治理平台 DataWorks，DataWorks 中有很多的功能模块，包含数据建模、数据开发、任务调度、数据质量、数据地图、数据安全等等。今天我们将重点介绍的是数据建模部分。 右边是从数据生产到数据消费整个链路的数据架构：**① 数据源：数据源主要包括业务数据和日志数据，我们通过 DataX/TT (离线/准实时/实时)将数据同步到数仓。 ② 数据计算**：即为数据加工处理，数据加工主要分为 ODS、CDM、DM和 ADM 四层。 - ODS：贴源层

• CDM：数据中间层
• DM 和 ADM 层：DM 主要是在 CDM 基础上对业务实体的再次抽象，从业务视角对数据资产的沉淀，ADM 是数据应用层

③ 数据服务：通过菜鸟数据中台自有产品天工对下游产品提供 API 服务。 ④ 数据应用：在数据服务的基础之上，来构建我们的数据产品、数据专项、业务监控报表和智能算法等数据应用。 在整个数仓架构中，数仓中间层的建设起到承上启下的作用，对下兼容和链接了底层数据，对上提供通用、易用、丰富的数据，它的好坏可以说决定了数仓的成败，那么中间层建设经常碰到难题就是数仓规范性，特别是互联网公司业务变化之快、人员流动性大，数仓规范落地是一个非常头疼的问题。 接下来我们讲讲菜鸟数仓规范性的一些痛点和对痛点的解决方案。 ### 4. 数仓规范化建设遇到的常见痛点

基于以上的业务背景和数据架构，我们可以了解到业务数仓规范化核心在数据建模，这也是我们今天为什么要重点介绍规范化数据建模的原因。接下里我们总结了下的数仓规范化建设的核心痛点，具体如下： ① 数仓规范和建模实操脱离，很多规范都是在文档里面，在落地上很难。 ② 中间层不够丰富，烟囱式开发。 ③ 模型中英文映射词库不丰富命名比较痛苦。 ④ 模型字段同意不同名。 ⑤ 模型研发缺少有效的系统工具帮助我们管理好数仓模型。 ⑥ 表的ER关系不易检索，数据开发不方便。 ⑦ 资产盘点复杂。 ⑧ 模型设计问题导致任务报错多，给运维带来很大的挑战。 ⑨ 无线上体系化的指标衡量数仓。 以上是数仓建设常见的问题，接下来我们再来看看末端数仓规范性存在的问题。 ### 5. 末端数仓规范性存在的问题分析

从以上数据可以看出末端数仓主要问题还是在中间层覆盖度，模型复用性、稳定性、健壮性、数据成本上。
这些问题背后的具体原因如下：
**① 公共层覆盖不足：
数据建设过度依赖需求驱动，缺乏业务数据建设的整体规划和思考，后续一些场景不能快速地满足业务，导致的问题就是应用层直接先用 S 层的表满足业务的需求。
② 核心模型复用性不足：
前期对业务了解不深入或考虑不周，导致后续无法满足业务需求，只能新建模型或者下游直接依赖 S 层。
③ 核心模型稳定性不足：**

• 模型对上游的依赖太深，有些模型依赖层次 10 层以上
• 跨BU、跨团队依赖较多，保障难度加大
• 混层引用较多，比如 DWD 层反向依赖 ADM 应用层的表

④ 模型健壮性不足：
模型设计不合理，业务不断变化时，对模型的冲击较大需投入更多的人力。

⑤ 数据成本不断增长：

• 不合理的数据生命周期设置
• 不合理的模型设计以全量表作为主模型，还有过渡的模型设计，比如小时表。这些不好的设计对我们的成本都会有较大的影响

⑥ 数据规范和易用性不足：
表和字段的命名规范执行不足；缺乏指标的统一管理；缺乏统一的数据大图，精品表识别推荐，下游找数难。 以上问题的本质主要在数据模型、数据规范管控落地上，所以线上模型管理和规范管控是我们的重点。 -- ju0

02模型管理整体规划

1. 数仓规范化——菜鸟模型管理整体目标

菜鸟数仓从稳定性、扩展性、时效性、易用性和成本几大方面制定了模型管理的目标。 - 稳定性：完善我们数据产出时效和数据质量稳定性，以我们的值班起夜次数和基线破线率、数据质量工单主动发现率为目标 。

• 扩展性：提升模型变化的兼容性，达到底层业务变动与上层需求变动对模型冲击最小化，以业务需求支持效率和业务模块新建核心表数量为目标。
• 时效型：提升数据模型产出时效以及需求响应速度，以值班起夜次数和业务需求及时交付率为目标。
• 易用性：降低下游使用门槛，复杂逻辑前置，通过冗余维度和事实表，进行公共计算逻辑下沉，明细与汇总共存等为业务提供灵活性，以数仓丰富度为目标。
• 成本：避免烟囱式的重复建设以及优化不合理任务消耗，节约计算、存储成本，以成本执行率为目标。

2. 数仓规范化——菜鸟模型管理整体方案

围绕以上 5 点目标，我们的模型管理方案主要包含两部分，分别是模型线上化与模型管理&评估。模型线上化，我们需要有“数据架构委员会”这样的组织保障团队，即搭建架构师团队，并将模型管理责任到数据负责人；接着我们需拟定数仓的规范制度，例如数据模型规范、数仓公共开发规范、数仓命名规范等；最后我们将规范制度和模型负责人通过产品工具 DataWorks 智能数据建模产品进行落地。完成模型线上化只是第一步，接下来模型管理&评估是我们的重点，我们要做到事前模型评审、事中模型评估打分、事后模型治理推送，实现模型管理的闭环，促进模型不断优化和完善。 模型线上化主要分为正向建模和逆向建模 2 种方式：- 正向建模：新模型通过 DataWorks 智能建模平台完成模型线上设计、评审、发布，实现模型后续线上化管理。

• 逆向建模：存量模型借助 DataWorks 智能建模平台逆向导入的方式实现模型线上化管理，同时也能对我们数仓模型做一次全面的盘点。

3. 数仓规范化——正向建模实施流程

正向建模实施流程分为七个步骤，通过 DataWorks 的数据建模即可实现，如下图所示： ### 4. 数仓规范化——逆向建模实施流程

逆向建模实施流程分为五个步骤： 通过逆向建模，我们对数仓的业务过程有了更全面清晰的认识和了解，同时对历史无人维护、低价值模型，进行了下线。最终完成了存量模型 100% 线上化管理。 我们在逆向建模过程中也发现一些问题，多年积攒下来的历史包袱，导致数据质量存在风险；多套规范并存，导致命名混乱；相似模型和低价值模型较多。 -- ## 03/数据建模平台建设

DataWorks 数据建模平台是菜鸟、大淘系（淘宝/天猫）、盒马、本地生活等多个部门和阿里云 DataWorks 团队共建的基于维度建模的数据数仓建模平台，菜鸟集团作为较早参与的部门，从 2020 年开始与 DataWorks 团队完成了产品从需求、开发、落地、迭代的整个周期。 ### 1. 智能数据建模平台规划

菜鸟通过对所需功能进行梳理，总结出从规范定义、便捷开发、发布评审、业务管理四个模块来研发这个建模工具： ① 规范定义：在前期，菜鸟是没有这个数据建模平台的，大家都是以线下的建模方式，比如对 Excel 梳理后，进行数据探查之后进行模型的设计，然后再线下进行模型评审。整个模型设计和评审都在线下。最终导致大家数据建模的时候没有形成一个规范，数据开发的过程是不严谨的，下游有了大量的引用之后，切换的成本也非常高，模型维护的成本非常高，变得越来越差。所以我们希望将规范的定义搬到线上，上图中列出了线上规范定义的主要内容。 ② 发布评审：之前我们的评审也是在线下进行，在架构师和工程师比较忙的时候，评审流程就不够严谨，甚至没有走评审的过程就直接发布了，所以我们希望将这个功能也搬到线上去。发布前我们会对表命名、字段命名进行强校验，同时支持多引擎发布，比如我们的离线数据存在 MaxCompute 或者 Hive 上面，还有一部分数据存在 MySQL 或者 Oracle 上面等等。影响性检查是模型发布之后，对于下游的引用这个模型的 ETL 脚本是不是有一些影响，比如有的时候我们新增了一个字段，下游同学使用的时候是 Select * 的方式，而他的表没有新增的这个字段，就会导致下游任务报错。 ③ 便捷开发：这是核心重要的一点。我们希望将建模方式从线下搬到线上之后，不要影响大家的开发效率，所以我们设计了各种提高效率的便捷开发功能。 ④ 业务管理：这是从使用的角度上来说的。对于研发人员来说，我们有业务分类和数据域的视角，对于业务人员来说，我们提供数仓大图和数据字典的视角。从成本治理的角度来说，比如一些历史上的模型可以做归并或下线。 菜鸟集团将以上能力与 DataWorks 的数据建模平台紧密结合，沉淀了数仓规划、数据标准、数据建模、数据指标四大核心功能模块，接下来将为大家逐一介绍菜鸟集团的使用情况。 ### 2. 智能数据建模平台核心功能

### 3. 核心功能——规范定义

规范定义分为分层划域和表名规范两个部分： ① 分层划域：我们将数据分为 ODS、DWD、DWS、ADS 和 DIM 五层。我们有 12 大级的业务分类，菜鸟就是其中的一个业务分类。同时业务分类下面还有一些子级的业务分类。有 13 个数据域，比如快递、财务等等和若干的业务过程。 ② 表名规范：我们有 6 类的表名命名规范。因为在业务发展的过程中，之前可能业务分类只定了一级，后面发现一级业务大类并不能帮助我们在数仓建模的过程中有效地表现规范性，于是就迭代出二级业务分类。 ### 4. 核心功能——逆向建模

无论是维度建模和 Fast 建模，都要经过概念模型设计、逻辑模型设计和物理模型设计三个必要阶段。逆向建模是物理模型设计到逻辑模型设计的过程，也就是Hive数据库已经有了 N 张表，需要把它反向到逻辑模型中，这就是一个逆向的过程。需要逆向建模的大部分是历史的不规范的表，菜鸟对于这些表是没有改造要求的，这些表可以通过批量逆向和FML批量调整来实现逆向建模。批量逆向设计的主要目的是将几千张表顺移到数据仓库里面，通过表名的正则表达式匹配进行一个批量的逆向。正则匹配只针对当前遵守最新规范的表，对于不是很规范的表可以通过FML批量调整。FML（Fast Modeling Language）是 DataWorks 团队开源的，用于维度建模领域快速构建的 DSL 语言，主要目标是提供一套 Kimball 维度建模理论下，结合大数据开发场景下的一种领域特定语言。原来的 Hive 建表的时候我们不能指定业务分类、数据域和业务过程的，现在通过 FML 语言就可以调整，这样就可以对不规范的表进行批量调整。 ### 5. 核心功能——多表克隆

之前在模型设计的过程中，最常用的一个建模过程就是对源表进行数据探查，再进行模型设计。我们可能需要从 N 张表中选取我们所需要的字段，对已有的表的字段进行勾选、顺序调整，最终形成一个逻辑模型。以前在线下对这样的过程可能就是从 Excel 中将多张表的字段全部拷贝出来，选取自己所需要的字段，再进行一个字段排序等等。现在我们可以通过多表克隆功能选取我们所需要的表，这些表可能不仅仅是我们自己 ODS 层的表，也可能跨 Project、跨企业引用，在多表克隆界面这些表都可以被选择，通过勾选字段的方式来建模，并生成简单的 ETL 脚本，省去自己手动写许多ETL脚本的过程。 ### 6. 核心功能——代码模式

代码模式是在研发过程中比较提效的一个功能。有时候上游的产品或者研发发布了功能之后，会给数仓开发同学一个简单的脚本来告诉数仓怎么来取数。数仓开发同学需要评估是不是要在数仓中新增一张表，数仓开发同学希望直接将脚本提交到建模平台上去，这个脚本基于数仓开发同学选择的字段或定义的一些简单函数（比如 SUM）还有别名，将这些字段自动归并到模型的字段中去，这就是代码模式的主要功能。代码模式必须定义好表命名并保存，才可使用。 ### 7. 核心功能——Excel代码模式

有些数仓开发同学，对 Excel 操作很熟练，觉得 Excel 操作很方便。所以这里设计了 Excel 批量导入和 Excel 交互两个功能。Excel 批量导入通过标准模板，定义表名、业务分类、字段、字段类型、字段备注等等，然后将这些模板批量导入到建模平台。另外一个功能是 Excel 交互，该功能可与本地 Excel 无缝衔接。批量导入之后，如果想修改 Excel 里的某些东西，可以将内容拷贝到本地 Excel，修改完后再将本地 Excel 拷贝到建模平台，Excel 交互界面右键集成了常用的批量操作，方便使用。 ### 8. 核心功能——发布评审

之前菜鸟的数仓是没有这个环节的，现在希望将这个功能给用起来。评审按照数据域的划分定义评审人，实现评审组功能，一人通过即通过。目前只实现简单评审流程，模型相似度、描述丰富度、血缘等衡量模型好坏的指标、辅助评审都在后续的规划中。这个功能首先是用在模型评审时，其次是用在数据治理时，已经产出的模型也可以根据模型相似度、描述丰富度、血缘等衡量模型好坏的指标，辅助开发同学进行模型的优化。 ### 9. 核心功能——智能翻译

智能翻译是一个比较重量级的功能。企业的数仓中有很多的命名的词典，将常用的中文对应的英文作为数仓的一个规范，目的是为了保证数仓模型有一个统一的辨识度，智能翻译完成中文的翻译与词根的维护。 ### 10. 核心功能——数仓大图

基于业务使用视角，我们提供了数据字典，通过平台导出功能，可以生成Excel格式的数据字典，包括表名、分层、数据域、业务过程、字段等详细信息，提供给业务人员使用。数仓大图没有在数据建模平台实现，DataWorks 团队正在研发一个数据资产管理平台，将会实现一个 3D 的资产全景构建。 -- ## 04/总结&展望

1. 菜鸟数据模型管理建设成果

菜鸟数仓团队从 2020 年开始与 DataWorks 团队不断共建智能数据建模产品，从最初版简单的录入系统，到集成逆向建模、多表克隆、多种引擎的代码模式、Excel 交互等功能，极大提升了建模规范和研发效率，成为菜鸟落地数仓规范的统一平台，取得的建设成果如下： - 规范：辅助数据体系规范化建设，将规范落到实处，同时将菜鸟几千张模型表，逆向建模到我们建模平台上来。

• 降本：在逆向过程中我们发现了历史上很多不规范的表，或者需要合并的表，或者表已经没有下游访问了，这时候就可以将模型表删除，物理表下线，过程中我们整体下线了 15% 的模型表，对于我们降本的方面还是比较明显的。
• 沉淀：把建模的过程从线下转为线上，沉淀企业级核心数据资产。
• 提效：减少人员沟通成本，产品化支持快速建模以及开发打通，并且不会降低我们建模和研发的效率，开发效率大概提升 30% 左右。
• 多样：面向业务视角自顶向下进行规范建模与面向开发视角自底向上构建数仓，双管齐下，相辅相成。从 0 到 1，自顶向下是最规范的，但是开发过程中，1 个小的需求，面向业务的，也可以在这个建模平台上完成。
• 使用人数：在产品使用方面，我们已经让菜鸟的末端团队与公共团队全员使用数据建模平台。

2. 建设成果展示

下图是之前提到的分层划域等建设成果 ### 3. 菜鸟数仓管理体系未来建设计划

模型管理体系是我们数据建模平台未来计划要集成的一个功能，主要有以下 5 个方面。 - 研发规范健康分：包括命名规范、注释、SQL、数据类型的规范等。

• 数据质量健康分：是否设置了主键、是否有异常比如今天有10条数据，明天有 100 条数据，是否在业务允许波动的范围以内。
• 计算/存储健康分：包括简单加工、是否有下游、模型表是否有生命周期，有些表访问的是近 3 个月的数据，但是保存了近 10 年的数据，这个时候可以调整生命周期。
• 稳定性健康分：菜鸟的数仓稳定性保证是有基线与值班机制的，我们的 DataWorks 监控基线是否破线，以及数据延迟/报警导致的值班起夜率是我们重点考量的。
• 通用健康分：复用度展现我们模型表下游的访问度如何，完善度展现模型表信息的完整性，我们的业务人员拿到这张表后是否可以理解，以及模型的相似度、血缘的相似度等等。

-- ## 05/问答环节

Q1：菜鸟的建模是基于 DataWorks 做定制化开发吗？A1：建模平台是我们和 DataWorks 共建的，我们是建模平台的一个使用方，也会把使用中的一些问题提给 DataWorks 来迭代优化。外部用户也可以在阿里云上开通 DataWorks 来体验这个数据建模产品，和集团内的版本没有太多区别。 Q2：历史数据有变动的情况，每一层应该怎么处理？A2：对于历史变更比较频繁的数据，建议做一个历史全量表。对于变更不频繁的数据，建议做一个每日增量，比如说最近 90 天变更。这个可以根据业务数据变更的频繁程度来做一个合适的模型设计。 Q3：模型是怎么打分的？怎么控制数仓 SQL 规范？开发人员写 SQL 容易出现跨层依赖。A3：首先是 SQL 规范，DataWorks 提供了很多检查器的功能，可以监测到数据上很大一部分问题，比如 Select *。其次是模型打分，主要从模型的规范和成本、稳定性和通用性来评估模型的好坏,将这几个维度综合起来来给模型打一个分。 Q4：正向数据模型只是建一个表结构吗？建模后如何灌入数据？与宽表打通？A4：正向数据模型不只是建一个表结构，还需要将模型物理化，物理化后再进行数据的灌入，后续还有很多 ETL 开发功能在里面。