开发者学堂课程【智能数据建模训课程 ：客户案例：数仓规范化-菜鸟数据模型管理实践（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1223/detail/18312
客户案例：数仓规范化-菜鸟数据模型管理实践
内容介绍
一、 菜鸟末端业务介绍
二、 模型管理整体规划
三、 数据建模平台建设
四、 总结&展望
一、 菜鸟末端业务介绍
1. 菜鸟末端业务简介
与菜鸟末端业务相关的是菜鸟驿站，菜鸟驿站建立初衷是面向社区和校园的物流服务平台，为用户提供包裹代收、代寄等服务，在此基础上再基于社区的生活服务，来构建驿站的商业能力，为消费者提供更多的基础设施服务，如驿站洗衣、驿站团购，致力于为消费者提供多元化的最后一公里服务。以下是菜鸟末端业务的定位：
接下来是介绍菜鸟末端业务总体的业务情况：其实分为两部分，第一部分是业务的核心能力，如下是业务的核心能力：包括网络的建设、硬件的打造。网络方面包括网络的拓点、运营、管理，硬件方面为了提高末端站点的效率，会打造一些 IOT 设备，如高拍仪、巴枪、寄件机等。在此之上是垂直业务，如代收、寄件、商业化、公益以及消费者运营等业务。如下是整个菜鸟末端业务大图：
2. 菜鸟末端业务数仓架构整体设计
基于业务大图，来介绍菜鸟末端数仓架构整体设计，如下图：
图中最左边是分为两部分，最左边是大数据，其实即之前提到的 DataWorks, 实际上 DataWorks 中有很多功能模块，此处重点讲述数据建模，另外右边的是从数据生产到数据消费整个数据链的一个架构。最下面的是来自于各个数据源、包括业务系统、日志数据以及与设备相关的东西，在此基础上，通过 datax/tt 同步进入数仓，数仓目前分为三层，一为贴远程，ODS 层以及 CDM 层，中间是数据中间层，再次就是 DM 和 ADM 层，DM 层主要是在中间层的基础之上做了一些如资产，数据主题。接下来是应用层，最上面是服务层，服务层采用了 OneService API 以及菜鸟自主打造的天工服务 API，提高了服务能力。在服务的基础之上再构建数据应用，打造数据产品、数据专题以及业务的监控，算法的应用。
3. 业务数仓建设痛点
基于上述提到的业务以及数据架构，接下来讲述业务数仓建设的痛点，在梳理完成之后主要从九点总结：
业务快速迭代和发展的情况下，缺少融合建模规范、建模实操、数仓大图、数据质量、衡量指标等为一体的线上建模工具。
建模规范和问题方面：
1) 数仓规范和建模实操的脱离（很多规范都是在文档中，对传承影响很大）
2) 中间层不够丰富，烟囱式开发
3) 模型中英文映射词库不丰富
4) 模型字段同意不同名
5) 模型研发缺少有效的系统工具来管理系统模型
模型日常运维和数仓整个体系衡量方面：
6) 在模型建设中，表的 ER 关系不易检索
7) 资产盘点复杂
8) 模型问题导致任务报错多，给运维带来很大挑战
9) 无线上体系化的指标衡量数仓
二、 模型管理整体规划
基于上述痛点，接下来要做模型管理整体规划
1. 业务数据规范化建设问题
如上是内部数据的趋势图，从图中可以看到当前的模型数仓是受到很大的挑战，对整个业务来说是有一些影响的。图中最上面是 S 表在各个层的引用情况，从图中来看，大部分层还是使用 S 表居多，第二个问题是中间层核心表的数量从最近三年来看是递增的趋势，特别是在2020-2021年间，核心表的数量大概增长了50%的比例。第三个方面是在数仓中基线的保障方面，在每周的周均起夜天数是在3.5天以上，这样对于值班者来说是非常辛苦的，最后是成本，数据成本的年增长比例是50%，从图中可总结出数仓建设的一些问题。
问题总结：
1) 公共层覆盖度不足，应用层访问 S 层表比例太高
2) 由于学校业务的变更，核心模型在前期的复用性上存在不足，中间层表总数年增长率50%以上
3) 核心模型稳定性不足，基线保障起夜次数，数据产出延迟较多
4) 模型健壮性不足，业务变化对模型冲击大，导致业务支持效率有较大挑战
5) 数据成本逐年保存较高增长比例
2. 问题分析
基于上述问题，如下是问题背后的原因
1) 公共层覆盖不足
整个数据建设过度依赖需求驱动，缺乏业务数据建设的整体规划和思考，后续的一些场景不能快速支撑业务，导致应用层会先用 S 表去满足业务的需求。
2) 核心模型复用性不足
前期对业务的深入了解或考虑不周，导致业务在变化过程中对整个模型有较大的冲击，后续无法满足业务需求，只能新建模型或者下游自接依赖S层。
3) 核心模型稳定性不足
模型对上游的依赖太深，有的模型甚至依赖层次在十层以上，另外跨bu,跨团队依赖较多，保障难度加大，混层引用较多，虽然层次之前已经讲述，但仍会出现 DM 层依赖于应用层的一些数据，这种混层依赖关系也会对数据模型产生较大的影响。
4) 模型健壮性不足
模型设计不合理，业务不断变化时，对模型的冲击较大需投入更多的人力
5) 模型成本不断增长
这主要体现在两个方面，第一是不合理的数据周期生命设置，第二是不合理的模型设计，前期在数据量小时以全量表作为主模型，导致在业务的体量上升之后影响成本，另外采用小时表模型这种过度的模型设计也会对成本有较大的影响。
6) 数据规范和易用性不足
表和字段的命名规范执行不足；缺乏指标的统一管理；缺乏统一的数据大图；精品表识别推荐下游找数难。
以上问题的本质主要在数据模型、数据规范管控落地上，所以线上模型管理和规范管控是我们的重点。
3. 数仓规范化-模型整体管理目标
在数据模型管理的背景下，整个做数据模型管理要达到的目标其实也是从数仓的五个维度来看：
末端模型线上化管理，总体建设目标
1) 稳定性：完善数据产出时效和数据质量稳定性，当前以值班起夜
次数和基线破线率、数据质量工单主动发现率作为考核目标。
2) 扩展性：提升模型变化的兼容性，让底层业务变动与上层需求变
动对模型冲击最小化，以业务需求支持效率和降低核心模型表数量为目标。
3) 时效性：与之前有所重叠，以提升数据模型产出时效以及需求响
应速度为主，以值班起夜次数和业务需求及时交付率为目标。
4) 易用性：降低下游使用门槛，复杂逻辑前置；主要是在模型设计
上通过冗余维度和事实表，公共计算逻辑下沉，明细与汇总共存等为业务提供灵活性，以数仓丰富度为目标。
5) 成本：在降本大背景下成本对我们挑战影响很大，避免烟囱式的
重复建设以及优化不合理任务消耗，节约计算，存储成本，最终是在数仓的模型管控上以成本执行率为考核目标。
4. 数仓规范化-模型管理整体方案
如上图，整个方案分为两部分，左边的是模型线上化，右边的是对模型管理的评估。模型的线上化管理分为三部分，第一部分是需要组织保障，需要搭建架构师组织，将模型责任到人；第二部分是要制度流程，把数仓中的模型规范、开发规范以及各个层次的分层规范，再加上模型的审批流程，基于前面的组织和规范流程，再加上之前的 DateWorks 智能数据建模产品，用 DateWorks 智能数据建模产品将人和流程、规范通过产品的方式去推动，使模型做到线上化管理。把模型做到线上化管理之后，要对模型分三个阶段去做后续的治理体系，首先是发布完成之后做一个模型评审（事前），事中要对模型进行评估和打分，事后基于模型评估打分之后对不合理的模型和有问题的模型做推送治理，通过此方式可形成一个闭环来推动整个模型的管理。
通过组织保障，制度流程体系的建设结合产品工具来实现数据模型线上化，同时构建模型评估体系和推送治理机制，促进模型不断优化和完善，达到模型线上管理目的。
其实模型管理包含了两个方面：正向建模和逆向建模，正向建模即新模型通过 DateWorks 智能建模平台完成模型线上设计、评审、发布，实现模型后续线上化管理。逆向建模即存量模型借助 DateWorks 智能建模平台逆向导入的方式实现模型线上化管理，同时也能对我们数仓模型做一次全面的盘点。
5. 数仓规范化-正向建模实施流程
如图知正向建模实施流程大概分七个步骤，开始由架构师对数仓做前期的规划，然后再定义业务域，第三步是梳理所有的业务域及定义业务过程，在此基础上使所有的数据标准都能在此平台上做一些定义，第五步是建模（以维度建模为主），建模之后对指标进行很好的管控，定义原子指标和派生指标，最后是模型评审和发布。
6. 数仓规范化-逆向建模实施流程
逆向建模实施流程大致分为五个步骤，如下图：
首先要梳理历史模型、存量模型，通过分析历史模型、存量模型形成数据模型总线矩阵，在此基础之上，由于若干历史发生变更，因此要在 DateWorks 智能建模平台上兼容历史规范，最后将所有的模型导入智能建模平台上。通过逆向建模也有收获，如下：
逆向建模效果：
1) 存量模型做了全面分析盘点。
2) 下线若干历史、无能维护，低价值模型。
3) 在逆向建模过程中，可从业务全视角去梳理定义最全业务过程，
带给同学更清晰全面的认识。
4) 当前菜鸟模型完成存量模型100%线上化管理，通过正向建模和逆
向建模已经将模型全部在 DateWorks 智能建模平台上做了管控。
逆向建模问题汇总：
1) 多年积攒下来的历史包袱，较多模型无管控、无维修，仍有大量
人在使用，对数据质量的风险较大。
2) 多套数仓规范并存，前期在业务变化过程中模型规范也有一些变
化，导致混乱的命名。
3) 相似模型和低价模型较多，低价模型即模型被下游使用较少的情
况。
