1、封面页（此页面将由下图全覆盖，此为编辑稿中的示意，将在终稿 PDF 版中做更新）卷首语 云原生一体化数仓是阿里云整合自研大数据产品 MaxCompute、DataWorks、Hologres 和实时计算 Flink 版推出的一站式大数据处理平台，具备流批一体、实时离线一体、湖仓一体、全链路数据治理四大核心能力，可以满足企业在建设大数据平台中对时效性、准确性、性价比、非结构化数据处理的需求，基于精简的架构，支撑全域数据分析需求和决策。全链路数据治理包含智能数据建模、全域数据集成、高效数据开发、主动数据治理、全面数据安全、快速分析服务六大产品能力，覆盖数据的全生命周期。本篇全域数据集成向开发者介绍

2、通过DataWorks数据集成在多表多表、多表单表、单表单表等场景下，进行实时或离线同步的技术选型与核心能力，并以MaxCompute 与 Hologres 引擎为例，演示云上数据同步操作步骤最佳实践。后续系列电子书更新请关注 DataWorks 官网或阿里云开发者社区。l 全域数据集成电子书（已完成）l 云原生一体化数仓新能力电子书（已完结）l 全面数据安全电子书-10 月 l 离线实时一体化电子书-10 月 l 主动数据治理电子书-11 月中 DataWorks 官网：https:/ 目录 大白话数据建模.5 数仓建模理论与规范.24 DataWorks 智能数据建模介绍.46 客户案例：

3、菜鸟集团数仓建模.59 客户案例：工业 OT 域数据最佳实践.78 客户案例：汽车行业数据建模最佳实践.86 客户案例：大淘系数据模型治理最佳实践.104 产品实操：零售电商数据建模操作实践.121 大白话数据建模 5 大白话数据建模 作者：苏靖鑫，DataWorks 产研团队 一、前言 合理的数据架构关乎企业的命脉，能够协助企业数据资产长久健康发展。数据开发、数据资产、数据治理，而这一切都是围绕数据建模展开的。数据研发同学 JobModel 里也指出了这一点：不再局限于 ETL 开发，会更侧重数据建模能力或者数据架构的能力。关于建模的资料很多，或许涉及过多专业术语的缘故，可能不够清晰直白。因

4、此我结合自己的理解，通过一个虚拟的案例，通过大白话给大家解释数据建模的专业术语，帮助大家快速理解。二、通过案例讲数据建模 Kimball 维度建模理论是目前在数据仓库领域中使用最为广泛的、也最得到认可和接纳的一项技术。目前集团数据团队工作规范就是基于它来开展，接下来我们来讲述维度建模理论的基础知识。1.度量与维度当我们看到一个数字的时候，我们会想到什么？大白话数据建模 6 很显然，单独一个 2 无法让我们联想到任何事。我们加一些描述进去，再来看看？加了描述以后，我们理解清楚了，原来 2 代表的是小明同学在全家便利店购买的 1瓶农夫山泉矿泉水，价格为 2 元。讲到这里，我们明白：单独一个数字无法

5、描述任何现实，必须加上必要的上下文才能让人理解。在维度建模理论里，将数值记录（2 元）称之为度量，将上下文称之为维度，这个案例中，商品、商家和客户均是维度，维度建模便是通过这两个名词作为起点展开的。2.事实表 小明同学当天还购买了其他商品，数据如下所示：大白话数据建模 7 这份记录购买记录的表格，由多行维度和度量构成的表格，称为事实表。它的每一行对应现实中的一个事实，这个事实被称为业务过程。我们看到上述数据中，每一行的区分依据，是订单 ID 和商品 ID，称为事实表的粒度，粒度决定了事实表里每一行的细分程度。事实表里除了记录商品 ID，还记录了商品名称，称为维度属性。在实际数据处理中，事实表为

6、了让其更可读、使用更便捷，往往会冗余一些维度属性。3.维度表 小明同学购买的商品，同时还有容量，类目等描述词，这部分描述词称之为维度属性，但是它们并不会全部出现在事实表里，而是单独存放。由维度主键和维度属性构成的表格，被称为维度表。维度表通常有多列或者说多个属性。实际应用中，包含几十甚至上百属性的维度表并不少见。维度表应该尽可能多地包括一些有意义的文字性描述，以方便下游用户使用。4.指标规范 现在我们已经有了描述便利店的商品和客户数据，还有了客户交易事实表。你很幸运地得到了一份数据分析师的工作，需要你来分析这家便利店的销售业绩。大白话数据建模 8 销售业绩需要通过指标来量化，所以你组织大家开了

7、一次讨论会，收集大家的需求并梳理指标。大家纷纷发言：店长：我希望看到老买家和新买家的日均支付金额，希望看到近一天的，近一周的，近一个月的。店员 1：我希望看到新品上架后的销售情况，也希望看到近一天的，近一周的，近一个月的。店员 2：我希望看到主营类目的日均支付金额，看近一周的数据就行，还希望看到新老买家分别的数据。你将大家的需求进行分析，会发现几个现象：需求口语化：比如店员 1 提到的销售情况，这个是含糊的词语，无法转化成开发需求。需求糅合：比如店员 2 虽然只说了一句话，但是实际上包含 3 个指标，近一周的，新买家的，老买家的。口径不一致：会上大家都提到了新买家和老买家，但是没有人针对新/老

8、买家给出完整的解释，因此你还需要再去询问一次，让大家理解并保持一致。将这个案例放大到整个公司，为了让指标能够规范化描述与开发，避免不同团队产生歧义，需要引入指标体系来解决此类问题。再回到上面这个案例，你梳理出了所有指标和口径，如下所示：大白话数据建模 9 通过表格可以发现，不同指标存在很多重复的地方，例如最近 1 天、最近 7 天；新买家、老买家；日均支付金额、订单数；如果针对每一个指标都需要进行完整的解释，可想而知重复的工作量有多少。因此，聪明的你决定对指标进行拆解。你将指标拆解为原子指标、时间周期、修饰词三大类，并将现在梳理出来的指标命名为派生指标。于是就得到了如下的公式：原子指标：原子指

9、标是不可再细分的度量，如支付金额，日均支付金额，支付订单数。时间周期：用来明确数据统计的时间范围或者时间点，如最近 1 天，最近 7 天。修饰词：对指标统计业务范围的划定，业务活动上下文的描述，如新买家，老买家。大白话数据建模 10 通过指标分类，你发现现在指标更好复用和组合。原先你需要针对每一行指标给出描述，如今你只需要针对每一类词分别描述，随后自由组合。可谓是事半功倍。5.数据域与总线矩阵 现在摆在你面前的是一堆零散的需求，你不太清楚从哪里开始着手进行分析，这个时候，分而治之的思想就派上用场。你将零散需求进行分类，后续再一一展开，这个过程被叫做数据域划分。数据域划分：数据域是指面向业务分析

10、，将业务过程或者维度进行抽象的集合。数据域需要抽象提炼、并且长期维护和更新的，但不轻易变动。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域或者扩展新的数据域。最终，你梳理出来本次需求的数据域如下所示：大白话数据建模 11 数据域 描述 包含的业务过程 包含的维度 交易域 客户在便利店购、退商品商品的全过程 购买商品、退换商品 订单类型等 会员域 在店铺注册的会员数据 开通会员、续费会员 会员类型等 店铺域 店铺的基本数据 开店、关店 店铺等级等 商品域 店铺售卖商品的基本数据 上架、下架、补充库存 商品、品类、品牌等 上面我们提到，事实表为了更好地进

11、行分析，往往会冗余一些维度属性，例如交易域的“购买商品”业务过程，会冗余店铺、商品、会员等维度信息，因此，我们还需要分析业务过程与维度的关联关系，这个时候，就要用到总线矩阵了。总线矩阵：是一种在全局视角理解数据结构的一种工具，可以让相关人员对整个数仓结构能够有清晰了解，很容易就能看出来数据域与业务过程、维度的关系；以及业务过程与维度的关系。数据域 业务过程/维度-会员域 店铺域 商品域 时间 会员 店铺 商品 交易域 购买商品 退换商品 店铺域 开店 商品域 上架 由业务过程和维度的关联关系构成的表格，就称之为总线矩阵，可以很清晰的看出：业务过程与维度的关系：方便我们在开发时对照需要冗余的维度

12、属性。数据域与业务过程/维度的关系：方便开发时就做好数据资产的归类，便于后续复用。大白话数据建模 12 6.数仓分层 在需求分析完成后，你开始帮助大家开发需求。在开发过程中你发现，为了满足大家的需求，你需要将新/老用户的判断重复写在三份 SQL 代码里，一方面代码冗余，另一方面计算成本也更高，后面如果口径需要变更，还需要修改三个地方。聪明的你又开始思考可否对数据仓库做抽象，通过中间层的建设来提高后续的开发效率。最终，你想出来的方案如下：ODS 层：数据准备区，是数据开发的预热阶段，目标是 1 比 1 完整接入数据，仅仅要求全，不用对原属数据做变更。这一步，你将便利店的数据从源头系统拉取过来。C

13、DM（Common Data Model）：通用数据模型层，这一层是你主要开发的部分?构建 DIM 层：目标是将维度表统一管理起来。这一步你从 ODS 层，给买家维度表开发新/老买家标记。?构建 DWD 层：目标是对事实表做一些提前计算，例如拼接维度表的字段，进行数据清洗，让数据好用。这一步你将交易事实表进行加工，添加了刚刚开发的买家维度表里的新/老用户的标记。?构建 DWS 层，目标是根据指标对数据适度汇总。这一步你便可以生产出最近 N 天的新买家/老买家的日均支付金额和订单数等信息。大白话数据建模 13 构建 ADS 层：与业务直接关联的需求在此完成。例如最近 N 天新品新买家日均支付金额

14、。根据上述划分，你设计的表分层如下：可以想象，假如后续多招聘了一位数据开发同学，他就可以基于你构建的 CDM 层数据，来完成 ADS 层的建设。总结一下，通过遵循数据仓库建模，有以下好处：屏蔽源头系统业务变更、系统变更对于下游用户的影响：如果源头系统业务发生变更，相关的变更由 DW 层来处理，对下游用户透明，无须改动下游用户的代码和逻辑。屏蔽源头业务系统的复杂性：源头系统可能极为繁杂，而且表命名、字段命名、字段含义等可能五花八门，通过 DW 层来规范和屏蔽所有这些复杂性，保证下游数据用户使用数据的便捷和规范。避免重复计算和存储：通过汇总层的引入，避免了下游用户逻辑的重复计算，节省了用户的开发时

15、间和精力，同时也节省了计算和存储。大白话数据建模 14 数据仓库的可维护性：分层的设计使得某一层的问题只在该层得到解决，无须更改下一层的代码和逻辑。7.小结 基础知识到这里就结束了，接下来会讲述围绕着数据建模理论，数据研发团队的研发流程是如何建立的。三、基于数据建模的研发流程 完整的数据研发流程可以参考下图：1.需求分析阶段 这一阶段明确清楚用户需求，拆解数据域，业务过程，原子指标、派生指标、时间周期和修饰词，并和用户沟通清楚口径，彼此达成一致。产物：通过 Excel 等表格工具梳理出的数据域、业务过程、维度、指标。大白话数据建模 15 2.模型设计阶段 根据上一步梳理产物，在建模工具内完成数

16、据仓库设计（逻辑表设计），并与团队同学及业务方一起 Review。产物：建模工具中完成数仓设计，主要为数据域、业务过程、维度、原子指标、派生指标、事实表与汇总表。1)基础信息录入 参考先前梳理的资料，可以丝滑录入到建模工具里。数据域 业务过程/维度-会员域 店铺域 商品域 时间 会员 店铺 商品 交易域 购买商品 x x x x 退换商品 x x x x 店铺域 开店 x x 商品域 上架 x x x 大白话数据建模 16 大白话数据建模 17 2)指标建立 得益于前期已经遵循数据建模的思想进行拆解，所以我们可以按部就班地将原子指标、修饰词、时间周期、派生指标生产出来。大白话数据建模 18 大

17、白话数据建模 19 大白话数据建模 20 3)数仓建设 大白话数据建模 21 4)模型发布 大白话数据建模 22 3.数据开发 在需求分析和模型设计做的很充分的情况下，数据开发反而是最为简单的，DataWorks 数据建模甚至可以直接生成数据开发的简单代码，供数据开发直接使用。所以虽然在数据建模中投入一定的工作时间，但是整体数据开发的效率是更高的。在数据开发完成后，通过相关数据工具进行回归验证。4.数据运维 通过 DataWorks 其他模块，观察数据线上产出的质量、时效；观察数据使用情况，及时对耗时长、使用率低的数据进行治理。四、总结 以往大数据研发经历了一段野蛮增长的时光，产生了大量不可维

18、护或者计算存储成本高的数据，给企业造成了很大的负担。现在大数据产品关于建模的能力正在日益变完善，后续的大数据研发过程应该都是围绕着建模展开了，也欢迎大家使用DataWorks 提供的数据建模工具，改善、规范你的数据研发流程。大白话数据建模 23 数仓建模理论与规范 24 数仓建模理论与规范 作者：渠振方，大数据售前专家服务团队 摘要：本文主要介绍数据仓库模型架构设计的目标、核心思想和核心步骤。一、模型架构设计目标 1.数据仓库的定义 数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Va

19、riant）的数据集合，用于支持管理决策（Decision Making Support）。从上面的定义可用看到数据仓库主要有四个特点：面向主题：面向分析主题，如商家全域分析、交易环节分析等。集成的：将业务系统进行集成组装，并整合到数据仓库中。相对稳定：不同于 OLTP 需要进行很多事务性操作（如：插入、删除、修改，等），OLAP 是一次性载入后进行多次查询访问。反映历史变化：不同于 OLTP 仅反映当下数据状态，OLAP 可以反映数据历史的变化情况。数仓建模理论与规范 25 2.范式建模 VS 维度建模 建模的两大核心思想是：范式建模和维度建模。1)范式建模法（3NF）Inmon 数据仓库建

20、模中最常用的方法，在技术上可以解决关系型数据库的数据存储，减少大量的数据冗余；在业务上可以使模型更加简洁易懂，数据的出口唯一。优点：从关系型数据库的角度出发，结合了业务系统的数据模型，能很方便的实现数据仓库建模，同时逻辑清晰，避免了数据冗余。缺点：从底层数据向数据集市的数据进行汇总时需要进行一定变通，经常需要多表关联才能满足相应的需求。2)维度建模Kimball 按照事实表、维表来构建数据仓库、数据集市。优点：事实表事先针对各个维度做了大量的预处理，比如进行预先的聚集、排序、分类等，后续基于其上的应用在访问速度很快；维度非常直观，紧紧围绕着业务模型，能快捷完成维度建模。缺点：当业务发生变化，需

21、要重新进行维度的定义，往往需要重新进行维度数据的预处理，并导致大量的数据冗余，无法保证数据来源的一致性与完整性。本次分享主要介绍维度建模。3.模型架构设计目标 模型架构设计的总体目标是清晰的层次架构、合理稳定的数据分域和高效易用的数据模型。具体体现在以下四个方面：1)易使用 一致性 规范性 数仓建模理论与规范 26 完整性 2)高质量 稳定产出 口径一致 准确性 3)低成本 计算成本 存储成本 研发成本 4)好运维 可扩展 可回刷 易维护 二、模型架构设计核心思想 1.核心原则 模型架构设计的核心原则是高内聚、低耦合，即在域内内聚，域之间耦合，以及业务和模型的耦合，在此之上实现稳定性、扩展性、

22、建设效率、产出效率和使用效率。2.核心过程 模型架构设计的核心过程有四个步骤：数据分层、业务分类、数据分域、模型设计（包括：确定维度、确定事实、确定模型）。数仓建模理论与规范 27 三、数据分层架构设计 数据分层架构主要包含三个层次。1.贴源层：ODS（Operational Data Store）操作型数据存储层 面向业务的原始溯源性，贴原从业务系统引入并组织数据。2.中间层：CDM（Common Data Model）公共数据模型层 面向业务通用性，易用性、复用性，组织公共通用明细数据与汇总数据。包括三种类型数据：DWD（Data Warehouse Detail）：明细类数据事实表 DW

23、S（Data Warehouse Summary）：汇总类数据事实表 DIM：维度表 3.应用层：ADS（Application Data Service）应用数据服务层 面向业务应用视角组织数据，一般是面向产品、业务场景进行公共数据组合与个性化计算。下图右边以淘宝为例，列举淘宝三个核心 Project（tbads、tbcdm、tbods）数仓建模理论与规范 28 四、数据分域架构设计 数据分域分为三个步骤：收集、提炼、归纳。1.收集：业务数据需求、存量数据梳理 核心目的：对现有数据和业务诉求需要的数据进行 merge，保障数据仓库的完整性，形成数据全集。核心对象：分析师、业务运营人员、数仓开

24、发者。核心输出：粒度、维度、数据指标、使用场景等信息。2.提炼：业务过程、业务梳理 业务过程：指企业的业务活动行为，如点击、浏览、下单等，业务过程是一个不可拆分的行为事件。核心目的：对收集的数据全集，进行业务关键词（包括业务过程、业务元素）提炼，根据经验罗列分类。核心对象：数据模型架构师。核心输出：业务过程、业务元素列表。3.归纳：数据域 数据域：面向业务，根据业务过程进行分类，组合抽象而成的数据集合。数据域不能轻易变动，在划分数据域时，既能覆盖当前所有的业务场景数据，又能在新业务进入时被融入，或对整体架构无影响下的扩展新数据域。核心目的：对业务过程、业务元素的列表进行抽象，尽量避免边界模糊不

25、清，归纳出数据域名称。核心对象：数据模型架构师。核心输出：数据域大图，包括核心业务过程与元素的包含关系。下图用实例来介绍数据分域过程中如何进行收集、提炼和归纳：数仓建模理论与规范 29 五、数据模型设计流程 数据模型设计主要分为三个阶段：需求调研，规范定义，模型设计。1.名词解释 1)时间周期 用来明确数据统计的时间范围或者时间点，如最近 30 天、自然周、截至当日等。2)修饰词 指除了统计维度以外指标的业务场景限定抽象，比如有效（下单金额），PC 端（下单金额）。3)度量 对某个业务事件的衡量，通常为数字，如件数，次数。区别于原子指标，度量命名一般不带上具体的业务动作。4)原子指标 基于某一

26、业务事件行为下的度量，具有明确业务含义，是业务定义中不可再拆分的指标。原子指标=业务过程+度量，如下单（事件）金额（度量）。数仓建模理论与规范 30 5)派生指标 可以理解为对原子指标业务统计范围的圈定。派生指标=一个原子指标+多个修饰词（可选）+时间周期。比如：最近 30 天 PC 端下单金额（最近 30 天为时间周期，PC 端为修饰词，下单金额为原子指标）。6)维度 维度是对应业务的数据分析角度，维度是度量的环境，用来反映业务的属性，某类属性的集合构成一个维度。维度归属于一个数据域，如地理维度（其中包括国家、地区、省以及城市等级别的内容）、时间维度（其中包括年、季、月、周、日等级别的内容）

27、，会员维度。7)粒度 精确定义事实表的每一行所表示的业务含义，传递的是与事实表度量有关的细节层次，比如子订单粒度。2.需求调研 1)业务调研 业务调研的流程分三个步骤：输入调研模板。针对产品和运营进行调研。归纳产出：业务过程&数据域。下图举例说明业务调研的流程：数仓建模理论与规范 31 2)需求分析 需求分析的三个步骤：输入调研模板，研究报表&数据体系。与分析师&运营讨论收集信息。归纳产出：指标体系。3)总线矩阵 根据业务调研、需求分析，完成总线矩阵，以明确数据域与哪些业务过程相关，业务过程与哪些维度相关。数仓建模理论与规范 32 3.规范定义 1)一致性维度 维度及维度属性 在总线矩阵下，维

28、度必须归属某一个数据域，维度属性的来源一种是源系统，一种是挖掘计算，如最近一次支付时间。特殊维度 杂项维度：将事实表中的状态、分类等字段定义为维度，比如交易订单、物流订单中的状态等均可称杂项维度。行为维度：基于历史事实构建，如会员最近一次支付时间就是一个行为维度，可作为其父维度会员维度的维度属性，不建议单独创建维度。维度整合和拆分 维度整合?同一业务板块下同维度不同属性信息可整合，如会员维度基本属性、星级等信息。?不同业务板块同维度信息可整合，如天猫淘宝基本会员信息。维度拆分?同一维度不同分类的属性，差异较大或业务关联度不大的信息，如不同业务板块的商品维度可拆分成不同维度表。数仓建模理论与规范

29、 33?每个商品会有主属性（形状、颜色、价格，等）和扩展属性，比如有些产品的一个扩展属性是带电的，那么在物流业务上就会有相应的限制，因此需要根据其业务属性拆分到不同维度表。?从产出时效、易用性考虑垂直拆分出主商品维表和商品维度扩展表。比如“跨境十日达”商品，会根据其业务属性划分维度属性，并放入维度扩展表。命名规则 命名规则尽可能使用英文简写。若英文简写过长，可考虑拼音首字母简写，如：商品 itm，商家 slr，买家 byr。最佳实践 以淘系常用维度来看命名规则。2)一致性度量 基本原则 度量必须归属某一个业务过程。度量类型：一般是数值，所以在定义数据类型时候一般为数字类型，同时需要和维度属性做

30、区别。数仓建模理论与规范 34 度量分类：按照事实的是否可加性分为：可加性度量、半可加性度量、不可加度量。命名规则 尽可能使用英文简写。当英文简写很长可以考虑汉语拼音首字母的简写，但一般要保持整个数仓一致性，所以尽可能选择一种命名缩写规则，如：数量 cnt、金额 amt。最佳实践 前面已经定义了业务过程，比如交易域的支付过程，接下来要规范定义交易业务过程涉及的度量，例如金额 amt、单量 cnt 等。3)指标定义 基本原则 派生指标可以选择多个修饰词，唯一归属于一个原子指标，属于某一个数据域。派生指标一般由原子指标和时间周期、若干修饰词构成。派生指标的命名要继承原子指标的命名规则和名称，可以抽

31、象为：修饰词+原子指标+时间周期。命名规则 尽可能使用英文简写。若过长，考虑拼音首字母简写，如：?原子指标：支付单量 pay_ord_cnt?派生指标：近 1 天淘特支付单量 tt_pay_ord_cnt_1d 最佳实践 下图左边是逻辑结构图，右边是指标举例，最近 1 天淘特支付单量的逻辑结构图：数仓建模理论与规范 35 下图是以交易域的指标为例看命名规则：?电商版块：ed?交易域：trd?支付：pay?单量：ord_cnt?订单：ord?业务来源类型：From_group?最近一天：1d?淘宝特价版：tt?支付单量：pay_ord_cnt?订单：ord?订单 ID、订单状态：order_id

32、，order_status?最近 1 天淘特支付单量：tt_pay_ord_cnt_1d 数仓建模理论与规范 36 4.模型设计 1)设计原则 高内聚，低耦合 规范性，一致性 稳定性，可扩展 公共逻辑下沉 成本性，能平衡 支持多次回刷 2)维度表设计 设计流程 基本原则 缓慢变化维 Kimball 的三种处理方法：重写、插入新记录、插入维度列（仅限两次变更）；阿里采用极限存储的方法。维度的一致性 相同维度属性在不同物理表种字段名称、数据类型、内容必须一致。维度的组合和拆分?同一维度不同属性关联性强可以整合，如会员基础属性星级等。?同一维度不同属性差异大的可拆分，如淘宝商品与航旅商品。?同一维度

33、不同属性关联度不强的可拆分，如会员表拆为买卖家维度表，如淘宝商品与 CBU 商品。?从产出时效、易用性、稳定性角度考虑是否需要拆分，如商品维度表和扩展表。数仓建模理论与规范 37 命名规则 dim_业务 BU/pub_数据域_维度定义_自定义命名标签 最佳实践 以淘系事实表、交易订单表和其中冗余的商品、买卖家相关维度表为例来介绍。下图是淘系商品维度表：dim_tb_itm?维度：商品?维度属性：商品标题、商品金额、商品颜色、主图等?冗余属性：类目维度属性等 下图是淘系商品属性扩展维度表：dim_tb_itm_extend 数仓建模理论与规范 38 扩展维度表从主维度表中拆分出来主要是有三个方面

34、考虑：稳定性、产出时效、变化频次角度。主维度表 VS 扩展维度表：主维度表 稳定 产出时间早 热度高 扩展维度表 变化较快 产出时间晚 热度低 3)事实表设计 事实表主要有三种类型：事务型事实表、周期快照事实表、累积快照事实表。数仓建模理论与规范 39 事务型事实表 周期快照事实表 累积快照事实表 时期 离散事务时间点 日期维度 事务日期 粒度 每行代表实体一个事务 事实 事务事实 更新方式 插入不更新 核心点 实体的单个事件发生过程 时期 以有规律的、可预测的间隔产生快照 日期维度 快照日期 粒度 每行代表某时间周期的一个实体 事实 累积事实 更新方式 插入不更新 核心点 核心关注的是当前的

35、一个累计状态，关注的快照的当前态 时期 时间跨度不确定、不断变化 日期快照 相关业务过程涉及的多个日期 粒度 每行代表一个实体的生命周期 事实 相关业务过程事实和时间间隔事实 更新方式 插入与在业务过程变更时更新 核心点 核心关注的是实体的生命周期范围内（如订单产生到完结）的各个状态变化 a)事务型事实表 针对业务过程构建的一类事实表，用以跟踪定义业务过程的个体行为，是数仓最原子的明细数据，提供丰富的分析能力。按照所描述的业务过程的数量分为单事务事实表和多事务事实表。数仓建模理论与规范 40 设计流程 基本原则?完整性：尽可能包含所有与业务过程相关的事实。?高内聚低耦合：只选择和业务过程相关的

36、事实。?粒度明确：在同一个事实表中，粒度必须唯一。?成本性能的平衡：使用退化维度提高事实表的易用性。b)单事务事实表 淘宝下单事件事务事实表：dwd_tb_trd_ord_di 基本特征?业务过程：订单创建?事实表类型：单事务事实表?粒度：子订单 ID?度量：订单创建金额等 数仓建模理论与规范 41?冗余属性：冗余商品、会员属性?数据存储：仅插入不更新、每个实体在整张表只有一条记录 适用场景?单业务过程，如下单、支付等?单业务过程分析无需限定业务过程?举例：双 11 下单单量 Select count（order_id）from tbcdm.dwd_tb_trd_ord_di where ds

37、=20211111 冗余原则?冗余维度属性下游常用?冗余维度属性不影响产出时效 c)多事务事实表 淘宝多事务事实表：dwd_tb_trd_ord_ent_di 基本特征?业务过程：订单创建支付完结?事实表类型：多事务事实表 数仓建模理论与规范 42?粒度：子订单 ID?度量：订单创建金额、支付金额等?冗余属性：冗余商品、会员属性?数据存储：仅插入不更新，每个分区存储每个实体的最新业务过程状态，通常以打标方式标识其业务过程（如表中的“是否当天下单”、“是否当天支付”、“是否当天确认收货”），每个实体因其业务过程更新情况，在整张表可能有多条记录 适用场景?适合一次分析多个业务过程的场景?此场景下计

38、算存储相比单事务节约、取数更便捷?举例：查询 20220110 当天下单当天支付的订单 select*from tbcdm.dwd_tb_trd_ord_ent_di where ds=20220110 and is_create=Y and is_pay=Y d)累积快照事实表 订单全流程表：dwd_tb_trd_ord_flow_di 基本特征?业务过程：订单创建-支付-完结?事实表类型：累积快照事实表 数仓建模理论与规范 43?粒度：子订单 ID?度量：订单创建金额、支付金额等?冗余属性：冗余商品、会员属性?数据存储：每日更新，存储每个实体的最新状态，每个实体在整张表中仅有一条记录 每天

39、完成的订单存储在当天日期的分区，而未完成的订单统一存储在300001231 分区 适用场景?多个业务过程，联合分析，如下单到支付、支付到订单完结时长的分析?保存全量数据、常见于订单处理?举例：近 7 天支付订单从下单到支付平均时长 select sum（pay_time-create_time）/count（order_id）from tbcdm.dwd_tb_trd_ord_flow_di where pay_time$bizdate-7 and（ds$bizdate-7 or ds=30001231）e)周期型快照事实表 设计流程 基本原则 数据公用性?汇总层的产出是否有多个下游使用?维度

40、的聚集是否有多个下游用于分析等?高内聚低耦合：dws 层不跨域计算存储?可扩展性：区分统计周期，如果要拆分，需要按照原子周期去拆分到多个dws 数仓建模理论与规范 44 命名规则?dws_业务 BU 缩写/pub_数据域缩写_数据粒度缩写_自定义表命名标签缩写_统计时间周期范围缩写?比如：dws_tb_itm_slr_td（商品域商家粒度汇总表）?tb：业务域?itm：数据域?slr：统计粒度?td：时间周期（截至当天为止）最佳实践 以淘系事实表商家粒度商品汇总表和其中冗余维度店铺维度为例来介绍：商家粒度商品汇总表：dws_tb_itm_slr_td 基本特征?粒度：商家 ID?指标：历史截至

41、当日商品数等?业务周期：每日?物理表类型：周期快照事实表?冗余维度：店铺 ID?数据存储：每日更新，每个分区存储每个?实体的最新状态 数仓建模理论与规范 45 适用场景?时间周期跨度比较大，实体的当前状态?不需要每次读时从事务事实再计算?举例：该商家历史截至当日共上线的商品数 Select itm_cnt_std from tbcdm.dws_tb_itm_slr_td where ds=$bizdate DataWorks 智能数据建模介绍 46 DataWorks 智能数据建模介绍 作者：爱桐，DataWorks 产研团队 一、DataWorks 智能数据建模-产品建设背景 2009 年，

42、DataWorks 就已经在阿里巴巴集团立项，支撑阿里巴巴数据中台建设，一路见证阿里巴巴大数据建设之路。2020 年之前，DataWorks 支持的是开发视角、自底向上、小步快跑，快速满足业务需求为首要目标的数仓构建模式，然而随着内部数据模型越来越多，线下评审流程越来越复杂，淘宝、天猫、盒马、菜鸟等多个数据仓团队开始和 DataWorks 合作，构建 DataWorks 智能数据建模产品，支持业务视角自顶向下的规范化数仓建设，也可以支持传统的开发视角、自底向上的数仓构建模式，真正做到规范化、可持续发展地构建数据仓库。2021 年云栖大会，DataWorks 智能数据建模正式发布，在阿里巴巴集团

43、内各个业务团队投入生产，并在阿里云上服务世界 500 强亿滋中国等众多客户。DataWorks 智能数据建模介绍 47 二、DataWorks 智能数据建模-业务痛点 在智能数据建模产品正式发布之前的这十多年时间里，阿里巴巴的各个数仓团队实际上并不是不需要进行数据建模，而是采用线下 excel 建模评审的方式在开展这一项工作，流程本身非常规范，模型的上线及变更有着非常严格的评审流程，但即使如此，线下建模还是有它的弊端存在。线下建模的弊端主要体现在三大方面：规范定义、模型设计、数据开发。从规范定义方面来讲，存在的主要问题是：数仓规范与模型设计分离，符合规范的模型设计对建模师本身的要求非常高，既要

44、能把业务需求高度抽象进行模型设计，还需要牢记规范的点点滴滴。数据指标定义效率低，且指标的数据加工逻辑分离，过去传统的单个创建指标效率相对低下，且无法保证指标的唯一性，指标的加工逻辑和指标定义本身也存在脱节的情况，最终导致指标真实口径无法统一，进而带来了大量的针对指标结果数据不一致的对焦工作。应用层缺少规范，大多数应用层的建设都面临需求多变、需求开发时间紧、任务重的特点，也对应用层模型规范的管理带来了非常高的挑战。既要能够满足业务需求，又要能够符合规范，其实很难再短时间内完成这些工作。从模型设计方面来讲，存在的主要问题是：纯人工的模型设计效率低下，比如要在 excel 里做模型设计，并且需求在

45、excel 里做维护。从数据开发方面来讲，存在的主要问题是：模型设计和物理表开发分离，模型设计是模型设计，物理表开发是物理表开发，很有可能会造成物理表开发逻辑与模型设计理念存在或多或少的差异情况。此外，本地建模，还会存在着一些隐藏的问题，如文件管理混乱、硬件设备故障、工作交接难等问题。DataWorks 智能数据建模介绍 48 三、DataWorks 智能数据建模-业务价值 数据建模作为数仓规范，最大的受益者是企业自身，但企业的价值需要通过一线研发人员的工作得以体现。对于一线研发同学来讲，智能数据建模能为大家带来的最大的好处是提效，相比传统的纯开发或者线下建模线上开发的工作方式来说，智能数据建

46、模能为大家带来更加更加高效的建模和研发方式。由此，帮助企业做好企业数据体系的规范化建设，让数仓规范真正能落到实处。企业数仓规范真正做好以后，能为企业沉淀大量的体系化的核心数据资产，同时，也能顺其自然地为企业节省大量的存储和计算成本。DataWorks 智能数据建模介绍 49 四、DataWorks 智能数据建模-数据建模方法论 众所周知，维度建模和范式建模都是目前大家所熟知的建模方法论，两种建模方法论，各有各的优势，也有各自的劣势，这里不对两种方法论进行展开介绍。阿里巴巴集团大多数数仓团队面向的业务又多具备高速发展、变化迅速、海量数据的业务特点，故以维度建模为主。智能数据建模产品由于它是生于阿

47、里，长于阿里，所以我们也是基于维度建模方法论进行的产品建设，但也不是说智能数据建模完全不体现模型关系，DataWorks 智能数据建模产品也会提供关系设计及展示相关的产品功能。五、DataWorks 智能数据建模-数仓分层 一般来说数仓会分为三大层，ODS、CDM、ADS。其中 ODS，又称为贴源层。ODS 主要用户存储业务系统同步来的业务数据。一般情况下，我们不会对 ODS 层的数据做过多的加工，以便于后续在 ADS 和 CDM 数据出错时的溯源。换句话说，ODS 不是数仓同学设计出来的，是对业务系统数据的直接同步。数仓建设最最重要的公共层 CDM 层，CDM 层需要对业务进行高度抽象，需要

48、具备通用性、易用性、复用性，因此，公共层的建设对数仓同学的要求是非常高的，既 DataWorks 智能数据建模介绍 50 精通建模方法，同时也对业务情况了如指掌。CDM 层再进行细分，一般会分为 DIM层-维度表，DWD 层-明细数据表，DWS 层-轻度汇总层。数仓建设最难管但管好了效果非常明显的应用层 ADS 层，ADS 层主要面向业务进行模型设计。因此，大家一定要先了解清楚模型的主要应用场景，是普通的报表分析，还是数据产品的调用等等，不同的应用场景，模型设计需要考虑的因素也不一样。如果规范化 ADS 层，需要建设的表会减少，通过统一逻辑去查询，会使计算和存储成本降低。六、DataWorks

49、 智能数据建模-名词释义 业务分类：业务板块是某一大类的业务的指标和维度的集合，如电商，文娱。数据域：数据域是指一个或多个业务过程或者维度的集合，如交易域，日志域。业务过程：业务过程指企业的业务活动事件，如下单，支付。数据集市：面向某个应用场景或者产品的数据组织，一般会依赖数据公共层。主题域：将数据集市按照分析视角进行切分，比如在电商行业，通常分为会员、交易、商品等。维度：维度是用于分析数据的一个角度，一方面对维度进行可控管理，另一方面指导维度表的设计，如地理维度，时间维度。维度属性：维度属性隶属于一个维度，用来描述维度的属性，如地理维度中的国家名称，省份名称。DataWorks 智能数据建模

50、介绍 51 时间周期：时间周期是用来明确数据统计的时间范围或者时间点，如最近 30 天，自然周。修饰词：修饰词是对指标统计业务范围的划定，指除了统计维度外指标的业务场景的限定抽象，如 PC 端，无线端。原子指标：原子指标是一般不可再细分的度量，原子指标命名=业务过程+度量。，如支付金额，访问人数。派生指标：派生指标直接用于汇总表的字段，派生指标由原子指标、时间周期、修饰词（可选）组成，如最近 1 天海外买家支付金额。七、DataWorks 智能数据建模-一级产品功能 DataWorks 智能数据建模产品分为四大板块，分别是数仓规划、数据标准、维度建模和数据指标。其中数仓规划、数据标准和数据指标

51、最终都为维度建模服务。八、DataWorks 智能数据建模-二级产品功能 数仓规划是数仓的顶层设计，包含分层划域、维度管理、建模空间。从产品定义来讲，这些内部并不复杂。难点在于数仓怎么根据业务场景来划分。建议先用思维导图画好，有了一个大概雏形之后，再录入产品。其中一个重点功能是可视化的表名检查器配置，检查器用于规范目标分层中表的命名，将同一分层中表名称的命名格式统一，便于通过表名称，即可了解到该表所属的业务类型、作用功能、数据粒度等信息。同时，可以帮助减少后期的运维成本。系统默认创建的数仓分层和自定义 DataWorks 智能数据建模介绍 52 新建的数仓分层均可以配置数仓分层检查器。对于建模

52、同学来讲，建模效率会提升且产出的内容符合规范。数据标准包含数据标准、标准代码、度量单位、命名词典。数据标准和标准代码设置好之后，可以和模型字段做关联，关联之后模型字段名称、值等都需要符合标准的设置。数据指标包含派生指标、原子指标、修饰词、时间周期。这里重点需要说明批量创建指标，勾选构成派生指标的原子指标、修饰词、时间周期，就可以生成一系列派生指标，用于模型设计。指标创建好后有两个作用，一是可以把指标批量导入到模型里面，作为模型的字段存在。另一个是模型字段已经存在，需要跟指标做关联。这样在物化之后可以找到指标对应的是哪个模型。维度建模支持正向建模和逆向建模。逆向建模解决的是已有数仓冷启动的问题，

53、主要用于将其他建模工具生成的模型反向建模至 DataWorks 的维度建模中。例如，当已通过其他建模工具生成模型，此时，想更换为 DataWorks 的智能建模进行后续建模工作，则可以使用逆向建模功能。该功能无需再次执行建模操作，即可快速将已有模型反向建模至 DataWorks 的维度建模中，节省了大量的时间成本。正向建模支持可视化建模、excel 导入、多语言建模。可视化建模类似网页版 excel的方式，把模型字段信息统一管理。在这个过程中，可以复用已经存在的物理表表机构，提升建模效率。多语言建模支持 DDL、自研 FML 方式建模。建议先用可视化建模，如果需要修改字段，可以用 DDL 或者

54、 FML 方式做字段的修改。在建模过程中，设置里某一字段为主键字段，非空字段，或者关联了数据标准里的标准代码，DataWorks 智能数据建模可以一键自动生成质量规则。当把模型发布到引擎中比如 MaxCompute 生成环境，可以自动生成一段数据开发的简代码。DataWorks 智能数据建模介绍 53 九、DataWorks 智能数据建模-数仓规划 数仓规划的整体架构如下，首先看中间部分业务分类，比如阿里的业务分为天猫、淘宝、菜鸟等等。也可以根据各个数仓团队面向的业务来划分。公共层分为三层，也就是上文讲到的 DWS、DWD、DIM。DMI 下需要区分数据域，维度表只需要分到数据域就可以。明细表

55、需要细化到数据域和业务过程。轻度汇总层只需要指定到数据域就可以。在应用层这一部分主要是ADS 层，在实际工作中可能不止有 ADS 层还会有 DIM 层。产品侧是支持大家灵活设置，如果有需要可以自行创建。ADS 层需要指定到具体的数据集市和主题域。这是模型在分层化域时需要考虑到的一整套体系。如果数仓团队负责多个业务，多个工作空间，需要复用同一套数仓规范，可以使用一下建模空间功能。建模空间是当需要管理多个 DataWorks 工作空间且需要复用一套数仓规划时，面对跨多个工作空间的复杂数据体系，可以通过设计空间来共享一套数据建模工具，针对整个数据体系进行统一的数仓规划、维度建模及指标定义等工作。Da

56、taWorks 智能数据建模介绍 54 十、DataWorks 智能数据建模-逆向建模 逆向建模如下图所示，可以选择表所在项目空间，表名匹配规则需要指定是模糊匹配还是精准匹配，在指定表命名规范后，会根据这些关键词来检测表，匹配规范，最终成功生成模型。DataWorks 智能数据建模介绍 55 十一、DataWorks 智能数据建模-正向建模 正向建模支持创建维度表、明细表、汇总表等。基本信息版本主要是分层化域以及表名的自动生成。字段管理部分可以从数据指标导入派生指标，从表/视图导入，可以基于已有的物理表或视图把表结构同步，其中字段可以自定义设置，不关注字段可以隐藏起来，本质上是一个 excel

57、 操作。当模型已保存后需要修改可点击代码模式进行修改。十二、DataWorks 智能数据建模-数据开发简代码 简代码支持根据建模信息自动生成 ETL 简代码，代码中模型信息包含：模型分层化域基础信息，模型字段中英文，建模依赖的物理表表名及字段名，模型的关联表关联表字段信息等；数据开发同学只要基于此代码进行 casewhen，where 条件等业务信息的补充即可。DataWorks 智能数据建模介绍 56 十三、DataWorks 智能数据建模-数据指标 下图左侧为筛选原子指标、修饰词、时间周期。右侧为在批量选择完后，会自动生成能够生成的指标，黄色代表指标没有生成，绿色代表指标已生成。DataW

58、orks 智能数据建模介绍 57 十四、DataWorks 智能数据建模-数据标准 数据标准会支持字段标准，会对日常用到的一些词语，做一个标准定义。标准代码是对字段值有要求。数据标准还有度量单位和命名词典。当这些内部定义好之后，维度建模过程中都可以做关联，如果是关联了标准代码，可以自动生成质量规则。十五、DataWorks 智能数据建模-多引擎支持 DataWorks 智能数据建模介绍 58 十六、DataWorks 智能数据建模-售卖与价格 DataWorks 智能数据建模目前已经开放售卖，最小规格（small）有首月 199 元试用活动，欢迎大家开通试用体验。https:/dw-commo

59、n- 智能数据建模需要搭配 DataWorks 增值版本使用，增值版本-专业版目前也有首月 1 元活动。计费区间的对象数量不等于所有表数量，主要指各类模型表与指标的数量，具体计数详情参考帮助文档或者智能数据建模产品上海品茶。客户案例：菜鸟集团数仓建模 59 客户案例：菜鸟集团数仓建模 作者：王智龙、董晃，菜鸟集团 一、菜鸟末端业务介绍 1.菜鸟末端业务简介 菜鸟驿站建设的初衷是面向社区和校园，提供最后一公里物流服务平台，为消费者提供包裹代收、包裹代寄等服务，在此基础之上基于社区生活，完善末端驿站的服务能力，为消费者提供更多生活服务，比如驿站洗衣、家电清洗等，这就是菜鸟末端业务的定位。接下来介绍菜鸟

60、末端整体业务的情况。2.菜鸟末端业务大图 业务大图主要分上下两部分，下面是我们业务的核心能力，上面是菜鸟末端的垂直业务。客户案例：菜鸟集团数仓建模 60 核心能力包括网络建设和硬件打造。网络主要包括网络拓点、网络运营和网络管理。为了提高驿站站点的效率，我们打造了诸多的 iot 设备，如高拍仪、巴枪、云监控、小票打印机、小易工作台、寄件机等。垂直业务包括代收、寄件、商业化、数智驿站、消费者体验&运营和绿色公益。3.菜鸟末端业务数仓架构整体设计 基于上面的业务大图，接下来讲讲我们的数仓架构：客户案例：菜鸟集团数仓建模 61 最左边是菜鸟集团使用的统一大数据开发治理平台 DataWorks，Data

61、Works 中有很多的功能模块，包含数据建模、数据开发、任务调度、数据质量、数据地图、数据安全等等。今天我们将重点介绍的是数据建模部分。右边是从数据生产到数据消费整个链路的数据架构：1)数据源 数据源主要包括业务数据和日志数据，我们通过 DataX/TT（离线/准实时/实时）将数据同步到数仓。2)数据计算 即为数据加工处理，数据加工主要分为 ODS、CDM、DM 和 ADM 四层：ODS：贴源层 CDM：数据中间层 DM 和 ADM 层：DM 主要是在 CDM 基础上对业务实体的再次抽象，从业务视角对数据资产的沉淀，ADM 是数据应用层 3)数据服务 通过菜鸟数据中台自有产品天工对下游产品提供

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

63、么要重点介绍规范化数据建模的原因。接下里我们总结了下的数仓规范化建设的核心痛点，具体如下：数仓规范和建模实操脱离，很多规范都是在文档里面，在落地上很难 中间层不够丰富，烟囱式开发 模型中英文映射词库不丰富命名比较痛苦 模型字段同意不同名 模型研发缺少有效的系统工具帮助我们管理好数仓模型 表的 ER 关系不易检索，数据开发不方便 资产盘点复杂 模型设计问题导致任务报错多，给运维带来很大的挑战 无线上体系化的指标衡量数仓 以上是数仓建设常见的问题，接下来我们再来看看末端数仓规范性存在的问题。5.末端数仓规范性存在的问题分析 从以上数据可以看出末端数仓主要问题还是在中间层覆盖度，模型复用性、稳定性、

64、健壮性、数据成本上。这些问题背后的具体原因如下：客户案例：菜鸟集团数仓建模 63 1)公共层覆盖不足：数据建设过度依赖需求驱动，缺乏业务数据建设的整体规划和思考，后续一些场景不能快速地满足业务，导致的问题就是应用层直接先用S 层的表满足业务的需求。2)核心模型复用性不足：前期对业务了解不深入或考虑不周，导致后续无法满足业务需求，只能新建模型或者下游直接依赖 S 层。3)核心模型稳定性不足：模型对上游的依赖太深，有些模型依赖层次 10 层以上 跨 bu、跨团队依赖较多，保障难度加大 混层引用较多，比如 DWD 层反向依赖 ADM 应用层的表 4)模型健壮性不足：模型设计不合理，业务不断变化时，对

65、模型的冲击较大需投入更多的人力。5)数据成本不断增长：不合理的数据生命周期设置 不合理的模型设计以全量表作为主模型，还有过渡的模型设计，比如小时表。这些不好的设计对我们的成本都会有较大的影响 6)数据规范和易用性不足：表和字段的命名规范执行不足 缺乏指标的统一管理 缺乏统一的数据大图，精品表识别推荐，下游找数难 以上问题的本质主要在数据模型、数据规范管控落地上，所以线上模型管理和规范管控是我们的重点。二、模型管理整体规划 1.数仓规范化-菜鸟模型管理整体目标 客户案例：菜鸟集团数仓建模 64 菜鸟数仓从稳定性、扩展性、时效性、易用性和成本几大方面制定了模型管理的目标。1)稳定性：完善我们数据产

66、出时效和数据质量稳定性，以我们的值班起夜次数和基线破线率、数据质量工单主动发现率为目标。2)扩展性：提升模型变化的兼容性，达到底层业务变动与上层需求变动对模型冲击最小化，以业务需求支持效率和业务模块新建核心表数量为目标。3)时效型：提升数据模型产出时效以及需求响应速度，以值班起夜次数和业务需求及时交付率为目标。4)易用性：降低下游使用门槛，复杂逻辑前置，通过冗余维度和事实表，进行公共计算逻辑下沉，明细与汇总共存等为业务提供灵活性，以数仓丰富度为目标。5)成本：避免烟囱式的重复建设以及优化不合理任务消耗，节约计算、存储成本，以成本执行率为目标。2.数仓规范化-菜鸟模型管理整体方案 围绕以上 5

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

68、式：正向建模：新模型通过 DataWorks 智能建模平台完成模型线上设计、评审、发布，实现模型后续线上化管理。逆向建模：存量模型借助 DataWorks 智能建模平台逆向导入的方式实现模型线上化管理，同时也能对我们数仓模型做一次全面的盘点。3.数仓规范化-正向建模实施流程 正向建模实施流程分为七个步骤，通过 DataWorks 的数据建模即可实现，如下图所示：客户案例：菜鸟集团数仓建模 66 4.数仓规范化-逆向建模实施流程 逆向建模实施流程分为五个步骤：通过逆向建模，我们对数仓的业务过程有了更全面清晰的认识和了解，同时对历史无人维护、低价值模型，进行了下线。最终完成了存量模型 100%线上

69、化管理。我们在逆向建模过程中也发现一些问题，多年积攒下来的历史包袱，导致数据质量存在风险；多套规范并存，导致命名混乱；相似模型和低价值模型较多。三、数据建模平台建设 DataWorks 数据建模平台是菜鸟、大淘系（淘宝/天猫）、盒马、本地生活等多个部门和阿里云 DataWorks 团队共建的基于维度建模的数据数仓建模平台，菜鸟集团作为较早参与的部门，从 2020 年开始与 DataWorks 团队完成了产品从需求、开发、落地、迭代的整个周期。1.智能数据建模平台规划 菜鸟通过对所需功能进行梳理，总结出从规范定义、便捷开发、发布评审、业务管理四个模块来研发这个建模工具：客户案例：菜鸟集团数仓建模

70、 67 1)规范定义 在前期，菜鸟是没有这个数据建模平台的，大家都是以线下的建模方式，比如对 Excel梳理后，进行数据探查之后进行模型的设计，然后再线下进行模型评审。整个模型设计和评审都在线下。最终导致大家数据建模的时候没有形成一个规范，数据开发过程是不严谨的，下游有了大量的引用之后，切换的成本也非常高，模型维护的成本非常高，变得越来越差。所以我们希望将规范的定义搬到线上，上图中列出了线上规范定义的主要内容。2)发布评审 之前我们的评审也是在线下进行，在架构师和工程师比较忙的时候，评审流程就不够严谨，甚至没有走评审的过程就直接发布了，所以我们希望将这个功能也搬到线上去。发布前我们会对表命名、

71、字段命名进行强校验，同时支持多引擎发布，比如我们的离线数据存在 MaxCompute 或者 Hive 上面，还有一部分数据存在 MySQL 或者Oracle 上面等等。影响性检查是模型发布之后，对于下游的引用这个模型的 ETL 脚本是不是有一些影响，比如有的时候我们新增了一个字段，下游同学使用的时候是select*的方式，而他的表没有新增的这个字段，就会导致下游任务报错。客户案例：菜鸟集团数仓建模 68 3)便捷开发 这是核心重要的一点。我们希望将建模方式从线下搬到线上之后，不要影响大家的开发效率，所以我们设计了各种提高效率的便捷开发功能。4)业务管理 这是从使用的角度上来说的。对于研发人员来

72、说，我们有业务分类和数据域的视角，对于业务人员来说，我们提供数仓大图和数据字典的视角。从成本治理的角度来说，比如一些历史上的模型可以做归并或下线。菜鸟集团将以上能力与 DataWorks 的数据建模平台紧密结合，沉淀了数仓规划、数据标准、数据建模、数据指标四大核心功能模块，接下来将为大家逐一介绍菜鸟集团的使用情况。2.智能数据建模平台核心功能 客户案例：菜鸟集团数仓建模 69 3.核心功能规范定义 规范定义分为分层划域和表名规范两个部分：1)分层划域 我们将数据分为 ODS、DWD、DWS、ADS 和 DIM 五层。我们有 12 大级的业务分类，菜鸟就是其中的一个业务分类。同时业务分类下面还有

73、一些子级的业务分类。有 13 个数据域，比如快递、财务等等和若干的业务过程。2)表名规范 我们有 6 类的表名命名规范。因为在业务发展的过程中，之前可能业务分类只定了一级，后面发现一级业务大类并不能帮助我们在数仓建模的过程中有效地表现规范性，于是就迭代出二级业务分类。4.核心功能逆向建模 无论是维度建模和 Fast 建模，都要经过概念模型设计、逻辑模型设计和物理模型设计三个必要阶段。逆向建模是物理模型设计到逻辑模型设计的过程，也就是 Hive 数据库已经有了 N 张表，需要把它反向到逻辑模型中，这就是一个逆向的过程。客户案例：菜鸟集团数仓建模 70 需要逆向建模的大部分是历史的不规范的表，菜鸟

74、对于这些表是没有改造要求的，这些表可以通过批量逆向和 FML 批量调整来实现逆向建模。批量逆向设计的主要目的是将几千张表顺移到数据仓库里面，通过表名的正则表达式匹配进行一个批量的逆向。正则匹配只针对当前遵守最新规范的表，对于不是很规范的表可以通过 FML批量调整。FML（Fast Modeling Language）是 DataWorks 团队开源的，用于维度建模领域快速构建的 DSL 语言，主要目标是提供一套 kimball 维度建模理论下，结合大数据开发场景下的一种领域特定语言。原来的 Hive 建表的时候我们不能指定业务分类、数据域和业务过程的，现在通过 FML 语言就可以调整，这样就可

75、以对不规范的表进行批量调整。5.核心功能多表克隆 客户案例：菜鸟集团数仓建模 71 之前在模型设计的过程中，最常用的一个建模过程就是对源表进行数据探查，再进行模型设计。我们可能需要从 N 张表中选取我们所需要的字段，对已有的表的字段进行勾选、顺序调整，最终形成一个逻辑模型。以前在线下对这样的过程可能就是从 Excel 中将多张表的字段全部拷贝出来，选取自己所需要的字段，再进行一个字段排序等等。现在我们可以通过多表克隆功能选取我们所需要的表，这些表可能不仅仅是我们自己 ODS 层的表，也可能跨 project、跨企业引用，在多表克隆界面这些表都可以被选择，通过勾选字段的方式来建模，并生成简单的

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

77、这里设计了Excel 批量导入和 Excel 交互两个功能。客户案例：菜鸟集团数仓建模 72 Excel 批量导入通过标准模板，定义表名、业务分类、字段、字段类型、字段备注等等，然后将这些模板批量导入到建模平台。另外一个功能是 Excel 交互，该功能可与本地 Excel 无缝衔接。批量导入之后，如果想修改 Excel 里的某些东西，可以将内容拷贝到本地 Excel，修改完后再将本地 Excel 拷贝到建模平台，Excel 交互界面右键集成了常用的批量操作，方便使用。8.核心功能发布评审 之前菜鸟的数仓是没有这个环节的，现在希望将这个功能给用起来。评审按照数据域的划分定义评审人，实现评审组功能

78、，一人通过即通过。目前只实现简单评审流 客户案例：菜鸟集团数仓建模 73 程，模型相似度、描述丰富度、血缘等衡量模型好坏的指标、辅助评审都在后续的规划中。这个功能首先是用在模型评审时，其次是用在数据治理时，已经产出的模型也可以根据模型相似度、描述丰富度、血缘等衡量模型好坏的指标，辅助开发同学进行模型的优化。9.核心功能智能翻译 智能翻译是一个比较重量级的功能。企业的数仓中有很多的命名的词典，将常用的中文对应的英文作为数仓的一个规范，目的是为了保证数仓模型有一个统一的辨识度，智能翻译完成中文的翻译与词根的维护。10.核心功能数仓大图 客户案例：菜鸟集团数仓建模 74 基于业务使用视角，我们提供了

79、数据字典，通过平台导出功能，可以生成 Excel 格式的数据字典，包括表名、分层、数据域、业务过程、字段等详细信息，提供给业务人员使用。数仓大图没有在数据建模平台实现，DataWorks 团队正在研发一个数据资产管理平台，将会实现一个 3D 的资产全景构建。四、总结&展望 1.菜鸟数据模型管理建设成果 菜鸟数仓团队从 2020 年开始与 DataWorks 团队不断共建智能数据建模产品，从最初版简单的录入系统，到集成逆向建模、多表克隆、多种引擎的代码模式、excel 交互等功能，极大提升了建模规范和研发效率，成为菜鸟落地数仓规范的统一平台，取得的建设成果如下：规范：辅助数据体系规范化建设，将规

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

81、求，面向业务的，也可以在这个建模平台上完成。使用人数：在产品使用方面，我们已经让菜鸟的末端团队与公共团队全员使用数据建模平台。客户案例：菜鸟集团数仓建模 75 2.建设成果展示 下图是之前提到的分层划域等建设成果。模型管理体系是我们数据建模平台未来计划要集成的一个功能，主要有以下 5 个方面。研发规范健康分：包括命名规范、注释、SQL、数据类型的规范等 数据质量健康分：是否设置了主键、是否有异常比如今天有 10 条数据，明天有100 条数据，是否在业务允许波动的范围以内。计算/存储健康分：包括简单加工、是否有下游、模型表是否有生命周期，有些表访问的是近 3 个月的数据，但是保存了近 10 年的

82、数据，这个时候可以调整生命周期。客户案例：菜鸟集团数仓建模 76 稳定性健康分：菜鸟的数仓稳定性保证是有基线与值班机制的，我们的DataWorks 监控基线是否破线，以及数据延迟/报警导致的值班起夜率是我们重点考量的。通用健康分：复用度展现我们模型表下游的访问度如何，完善度展现模型表信息的完整性，我们的业务人员拿到这张表后是否可以理解，以及模型的相似度、血缘的相似度等等。五、提问 Q：菜鸟的建模是基于 DataWorks 做定制化开发吗？A：建模平台是我们和 DataWorks 共建的，我们是建模平台的一个使用方，也会把使用中的一些问题提给 DataWorks 来迭代优化。外部用户也可以在阿里

83、云上开通DataWorks 来体验这个数据建模产品，和集团内的版本没有太多区别。Q：历史数据有变动的情况，每一层应该怎么处理？A：对于历史变更比较频繁的数据，建议做一个历史全量表。对于变更不频繁的数据，建议做一个每日增量，比如说最近 90 天变更。这个可以根据业务数据变更的频繁程度来做一个合适的模型设计。Q：模型是怎么打分的？怎么控制数仓 SQL 规范？A：开发人员写 SQL 容易出现跨层依赖。首先是 SQL 规范，DataWorks 提供了很多检查器的功能，可以监测到数据上很大一部分问题，比如 select*。其次是模型打分，主要从模型的规范和成本、稳定性和通用性来评估模型的好坏，将这几个维

84、度综合起来来给模型打一个分。客户案例：菜鸟集团数仓建模 77 Q：正向数据模型只是建一个表结构吗？建模后如何灌入数据？与宽表打通？A：正向数据模型不只是建一个表结构，还需要将模型物理化，物理化后再进行数据的灌入，后续还有很多 ETL 开发功能在里面。客户案例：工业 OT 域数据最佳实践 78 客户案例：工业 OT 域数据最佳实践 作者：张为，阿里云全球技术服务部 一、传统维度建模的方案介绍 数仓建设中常用的方式是维度建模，其核心是将原表分为事实表和维度表。然后采用星型模型或者雪花模型进行数据建模。星型模型，是一种非常简单常用的模型，事实表直接和多个维度表相连，维度表之间无连接。雪花模型，事实表

85、与多个维度表相连，维度表之间有连接。阿里内部在维度建模理论基础上，对数据的分层分域、维度一致性、事实表设计、原子指标/派生指标的定义及设计等做了细化定义，同时定义了一套标准的从设计到开发的实施流程。1.维度建模工作流程 维度建模工作的实施流程如下图所示。需求调研：分为自底向上和自顶向下两种，自底向上是从现有的业务系统入手，从业务上分析数据域、业务过程，了解数据需求。自顶向下是和实际报表使用人员了解需求，依据报表 SQL 反向推导所需的数据源及指标信息。数据域划分：对数仓建设涉及的数据类别进行划分，一般可以按照行业标准或者业务系统功能模块来划分。客户案例：工业 OT 域数据最佳实践 79 指标设

86、计：构建总线矩阵，梳理原子指标及派生指标清单，以及原子指标的溯源、派生指标的计算逻辑等。数 据 建 模：构 建 一 致 性 维 度，构 建 一 致 性 度 量 及 指 标，分 层 设 计DWD/DWS/DIM/ADS 模型。数据开发：物理表创建，数据业务逻辑 SQL 开发。任务运维：数据开发任务运维。从工作流程可以看出，维度建模的任务链路是比较长的，同时其工作量和指标规模基本成正比。涉及的指标量越多，调研、设计、开发的工作成比例的增加。2.维度建模使用场景及特点 维度建模广泛应用于 IT 域数仓建设的场景中，该类场景的特点是原始数据来源于业务系统各功能模块，数据可以很自然的分为维度表和事实表，

87、同时挂载到类似业务板块、业务过程这种概念上，通过统一的一套方法论即可对不同的场景、不同的数据源完成建模设计。虽然使用的建模方法论和流程是相同的，但是对于不同的指标设计是不同的，即当增加一个场景的指标时，需求调研、指标设计、模型设计、开发运维这个过程需要完整的走一遍，因此项目的实施工作量和指标数量基本成正比关系。二、工业 OT 域场景描述 在工业业务场景下，在生产产线上存在大量的 IOT 设备的测点数据，和 IT 域数据相比，这类数据量很大，但格式比较统一，核心字段包括设备 ID、时间戳、测点值、数据类型几个，数据类型可以分为两种，第一类为模拟量数据，例如设备的温度、电流、电压、喂料量等，这类数

88、据为一个连续值，第二类数据为开关量数据，当设备开机时上报 1 信号，设备关机时上报 0 信号。对于这些原始 IOT 数据，存在大量指标计算的需求，相比于传统的维度建模，这类指标计算模式相对比较固定，指标大致可以分为单点位测点值的聚合计算和多点位测点值的公式计算两种，对于聚合计算就是统计一段周期内的最大、最小、平均值之类的指标。公式计算带具体的业务含义，例如电流*电压*运行时长等于电量消耗，喂料量*产量系数/运行时长等于台时产量。客户案例：工业 OT 域数据最佳实践 80 1.工业 OT 域场景特点 从前面的描述可以看出，在工业 OT 数据域的特点是指标的量很大，但是计算方式相对比较简单，且可以

89、枚举或者归纳。工业 OT 数据域下，一个车间往往就有上万个设备点位，每个点位的数据都需要做聚合计算，且存在大量的通过类似电流电压运行时长等于电量消耗这种公式计算的指标，因此做成千上万个指标计算是常态。参考维度建模中的指标分类，可以把原始的测点值定义为原子指标，将周期的聚合计算结果定义为派生指标，带有具体业务含义的公式计算得到的指标定义为衍生指标。分析可以发现，这里的原子指标虽然量很大，但是其格式是固定的。派生指标的计算可枚举，都是最大、最小、平均值之类的周期聚合计算。而衍生指标，虽然计算公式不可枚举，但是其计算形式都是一样的，基本都是通过一个四则运算的公式进行计算。2.工业 OT 域指标计算现

90、状 对于工业 OT 域的指标分类和计算，目前行业内有一些各自的实现。例如某公司的ETL 过程将指标计算明确分为两步，第一步为单点位的聚合计算，将原始点位数据的周期内最大、最小、平均值、差值等聚合指标定义为一次指标，第二步为多点位的公式融合计算，将基于一次指标进行公式计算后的结果定义为二次参数。阿里的工业数据应用平台将指标定义为数据转换和数据统计两类，数据转换可以对原始的点位数据进行各种清洗转换操作，数据统计可以设置统计周期，计算统计周期内的数据统计量（包括聚合计算和公式计算）。可以看出对于 OT 域的指标计算需求是比较清晰的，各自的实现也有相似之处，但相比于标准的维度建模，现在并没有一个很统一

91、定义，以及实现方案。例如上面的某公司虽然将指标比较清晰的分成了两类，但在最后计算完成后所有的指标都存放在同一张表中，并没有模型分层的概念，同时整个过程基本不涉及数据治理的动作；阿里目前的工业数据应用平台能力比较强，能实现各种数据转换和计算，且把计算动作分成了转换和统计，但同样的并没有做指标的分层定义，从建模的角度来看是稍显混乱的。客户案例：工业 OT 域数据最佳实践 81 三、指标工厂实现思路 由于在 OT 数据域下，指标的特点是数量特别大，但是其计算方式可枚举或者可归纳，因此可以在现有方案的基础上，参考维度建模定义标准的建模分层，同时设计批量指标定义和计算的实现方案，实现批量的指标的定义及加

92、工计算。1.指标工厂实现思路 指标工厂建设思路是，OT 域建模分层和传统 IT 域维度建模一致，但是设计开发过程有比较大的差异，不需要对单个指标做复杂的设计，可以通过工厂化配置的方式批量定义和计算。1)对原始采集定位的数据定义清洗转换规则，得到基础的原子指标。2)定义原子指标计算方式（聚合函数），计算方式可枚举，通过周期聚合计算得到派生指标。3)自定义衍生指标计算公式，计算公式只涉及派生指标之间的公式计算，不涉及其他约束条件。通过这种设计方式，通过几个计算任务即可完成原子指标、派生指标、衍生指标的批量计算，当业务场景需要增加指标时，只需要增加对应的指标计算公式即可。2.指标工厂与维度建模的关系

93、 通过指标工厂的思路，可以在 OT 数据域下快速的定义及生成指标，和传统的维度建模概念类似，分为原子指标、派生指标、衍生指标等。区别在于传统 IT 数据域下，数据源的形式（数据源来自不同业务表）及指标计算方式（包括统计周期、修饰词、维度、计算公式等）比较难统一，因此基本上需要对 客户案例：工业 OT 域数据最佳实践 82 每一个指标做建模设计。而 OT 数据域虽然数据源量特别大，例如一个车间可能就有上万个点位的数据，但是其数据格式是一样的，可以放在一个表中用 ID 区分不同点位数据，指标计算的方式也是比较统一的。维度建模设计示例（总线矩阵）维度建模示例 如上图所示，维度建模需要对每一个指标做比

94、较详细的设计，且不同的指标计算大多是需要在不同的任务中去计算。而 OT 域下基于指标工厂的指标设计和计算会简化很多，通过批量定义原子指标的统计类型，以及派生指标的计算公式，用几个任务即可完成所有指标的计算。IT 域建模与 OT 域建模差异 客户案例：工业 OT 域数据最佳实践 83 四、基于 DataWorks 实现指标工厂 DataWorks 数据建模支持数仓规划设计、制定并沉淀企业数据标准、维度建模、数据指标定义，通过使用 DataWorks 数据建模，可以将建模设计产出的分层模型表物化到计算引擎中并进一步应用。基于 DataWorks 数据建模功能，可以快速实现指标工厂概念中的原子指标和

95、派生指标，以及表模型的定义和创建。1.数仓分层设计 OT 域指标建模和 IT 域一样，可以把数仓分为贴源层、公共层、应用层等。2.原子指标定义 这里实际上是定义在计算派生指标时原子指标的聚合方式，由于聚合方式是可枚举的，可以在这里把原子指标全部枚举定义出来。客户案例：工业 OT 域数据最佳实践 84 3.派生指标批量定义 通过批量选择原子指标、时间周期即可实现派生指标的批量定义，完成不同周期，不同聚合方式的派生指标定义。客户案例：工业 OT 域数据最佳实践 85 4.模型表定义 通过快速导入的方式，可以实现将上一步定义的不同统计周期的派生指标批量的导入至模型表中。通过派生指标做公式计算得到衍生

96、指标，在建模过程中没有标准的定义，在具体实施的时候可以通过一个前端来做公式的配置，公式存储在配置表中，在指标计算的时候读取配置表中的公式信息，然后关联获取依赖的派生指标值，再做批量的计算即可得到衍生指标结果值。五、项目实践 基于指标工厂的思路进行 OT 域指标设计和开发已经在多个项目中进行落地实施，以某水泥项目为例，阿里云全球交付技术服务部基于指标工厂建设思路完成上万个测点派生指标的计算以及数百个衍生指标的设计和计算。例如水泥产量等指标信息，通过统计类型配置及公式配置即可完成计算输出，并支撑前端的大屏展示。客户案例：汽车行业数据建模最佳实践 86 客户案例：汽车行业数据建模最佳实践 作者：苏冬

97、妮，阿里云全球技术服务部 一、企业需求与现状介绍 本篇文章将围绕某汽车企业项目上的智能建模实践展开，为您介绍汽车生产业务的建模工作细节。该项目总规模涵盖了生产车间 IOT 平台，生产系统平台，数据中台以及其他智能化数字应用几大模块。数据链路也是自下而上依次生长。数据建模工作内容是在建设数据中台时的一个重要环节，需要我们为客户从零到一搭建汽车生产业务的数据分析指标体系。数据架构 工业企业的数字指标建设，一切都是围绕快速，实用为导向来开展工作，存在着以下特点：客户案例：汽车行业数据建模最佳实践 87 缺少成熟的数字研发人员阵型，对汽车生产领域的指标需求不明确。注重研发规范、业务标准。自带工业基因，

98、对工作进度体感要求较高。因此，在开展建模的工作的时候，我们主线围绕着 One Data 方法论，同时也有选择地结合了客户实际业务情况，帮助其打造整个数据中台模型体系。二、数据建模工作实施步骤 在该车企展开的建模工作主要分为如下几个步骤：业务调研、指标需求确认、规范定制、建模设计。建模步骤 三、业务调研 业务调研需要从三个维度入手：业务模块调研、需求调研、数据调研。1.业务模块调研 1)工厂物理结构以及业务调研 理清客户的内部业务逻辑。对于汽车生产，我们了解到客户的生产车间有 5 个，分别是冲压车间、焊装车间、总装车间、涂装车间、电池车间，是一个很典型的整车厂的阵型。每个车间分别由不同的线体组成

99、、每条线体分别由不同的工位组成。每 客户案例：汽车行业数据建模最佳实践 88 个车间、线体、工位之间功能各不相同，装配步骤也各不相同。车体在生产过程中，会依次通过车位进行装配。一个车体的生产需要经历：下订单-生产计划下发-生产计划接收-生产流程-Andon 告警(非必需)-车辆检查-质量返修（非必需）-车辆下线这几个步骤。每个步骤又可分化出不同的动作流程。生产流程总线矩阵 2)需求调研 需求调研主要在于了解清楚客户的业务通点、需要我们解决的事情是什么。有些客户可能内部已经有数据分析场景，会比较清晰地知道自己想要落地的指标是什么，有些客户则可能对一些业务模块能产出的指标没有概念，不知道自己要做什

100、么，能做什么。本次我们的客户需求较为明确：进行生产域的分析体系建设。故交付工作也围绕着生产模块来开展，其他业务板块暂不涉及。3)数据调研 上层系统围绕着车间生产活动进行建设，IOT 平台设备会采集车间的硬件设备信息，包括不限于工位过点信息、设备告警信息、物理信息比如温度等。这些数据会路由到车间生产系统，并进行二次生产使用加工，帮助工厂工作人员管理和掌控车间的生产状态。因此，除了少量的离线非结构化数据外，我们的数据来源也基本为这两个线上系统。除了数据来源，我们还需要调研数据结构，更新方式，质量等特性。客户案例：汽车行业数据建模最佳实践 89 数据调研关注内容 四、指标需求确认 参考业务流程调研结

101、果和总线矩阵，确定出可以产出的指标以及指标衍生维度。比如，对于汽车生产流程下的各个动作步骤可以产生的一些指标如下：业务动作下产生的指标示例 客户案例：汽车行业数据建模最佳实践 90 1.规范制定 1)命名规范 在进行模型设计之前，需要约定好数仓各个层级表的命名规范。一方面统一的规范命名可以帮助我们提高开发效率，见名知义；一方面可以避免重复开发，减少资源浪费。常见的一个表的命名要结合所在数仓层级、涉及到的业务模块、业务动作过程、以及更新方式和时间周期组合生成。在此项目中我们用到的命名规则如下：表命名规范 2)更新规范 更新分为全量更新和增量更新。一般来说，在离线计算采用每天新增一个分区，将当天新

102、更新的数据写入该分区中。考虑到此客户的资源较建行和数据量较大，我们决定采用增量更新写入，再在下游用全量合并成当天全量表的方式来存储，这样可以节省存储资源，缩短数据同步时间。3)度量标准 为指标制定统一的度量，避免因为度量体系不一致导致后期数据质量问题，为使用者带来困扰。此项目中涉及到的实体与度量的关系如下：客户案例：汽车行业数据建模最佳实践 91 实体与度量关系 4)词典 词典与命名规范和度量息息相关，在描述统一实体时统一规范我们的措辞，可以帮助我们提升沟通效率。词典 客户案例：汽车行业数据建模最佳实践 92 2.模型设计 层级设计：共分为 ODS 层、DWD 层、DWS 层、ADS 层。其中

103、 DIM 层、DWD 层与DWS 层也可被统一称为 CDM 层。每一层的定位和用途各不相同。1)数据引入层 ODS（Operation Data Store）存放未经过处理的原始数据至数据仓库系统，结构上与源系统保持一致，是数据仓库的数据准备区。主要完成基础数据引入到 MaxCompute 的职责，同时记录基础数据的历史变化。我们的 ODS 层本次共接入了上千张表。分别来源于 IOT 系统和生产系统，有少量来源于离线的文件。同时，我们在传统的 ODS 分层内，划分了两层，最底层为初始化全量，每天增量更新的贴源层，在它的下一层，我们做了全量清洗合并，存储每天的全量数据。2)数据公共层 CDM（C

104、ommon Data Model，又称通用数据模型层）包括 DIM 维度表、DWD 和 DWS，由 ODS 层数据加工而成。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总公共粒度的指标。3)公共维度层（DIM）基于维度建模理念思想，建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。在此项目中，我们共沉淀了 10 张以上的维度表，按照不同的车间做区分，分别是工人值班信息，车间空间信息（包含车间、线体与工位的对应关系），车体信息，能耗信息，质检缺陷信息，Andon 告警信息等。

105、由于电池车间内的线体较为特殊，线体之间各自独立，具有不同的生产功能，维度表在使用和设计时和其他车间有所区别。客户案例：汽车行业数据建模最佳实践 93 维度字段 4)明细粒度事实层（DWD）以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。DWD 层在某些情况下会被用来存放原子指标，本次项目中，我们将最细粒度的明细记录数据存放在本层。比如，涉及到车辆产量的指标，均依赖于车体在经过线体上各个工位的过点信息计算得来。因此，我们设计了一张车辆过点信息明细表，记录每个车间各个车体通过工位点位的明细记录。车体过点记录表主要明细 客户案例：汽车行业数据建模最佳实践 94 5)公

106、共汇总粒度事实层（DWS）以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。此次我们并没有在 DWS 层进行大量宽表设计，而是将原子指标以及复合指标存放在 DWS 层，从 DWD 层引用明细数据进行计算得出结果，为下游的应用层宽表提供公共指标。某汽车生产管理汇总表 6)数据应用层 ADS（Application Data Service）也叫集市层，存放数据产品个性化的统计指标数据。根据 CDM 与 ODS 层加工生成。我们将不同业务方使用的主题宽表存放在这里，由 DWS 层的公共指标关联得来。同时，由于使用人员各自涉及的业务表

107、不同，我们还对不同的业务模块人员进行了不同的宽表权限的隔离。客户案例：汽车行业数据建模最佳实践 95 某汽车生产管理主体宽表 五、数据模型落地 基于以上设计，阿里云全球技术服务团队与 DataWorks 产品团队合作，通过智能数据建模产品将以上规范在客户生产环境落地。DataWorks 智能建模产品分为四个模块：数据指标、数据标准、数仓规划、维度建模。1.数据指标 分别包含派生指标、原子指标、修饰词、时间周期四个模块。1)原子指标 原子指标用于明确业务的统计口径和计算逻辑，是基于用户的业务活动（即业务过程）创建的，用于统计业务活动中某一业务状况的数值。比如，车的产量是根据车体过点记录中通过车间

108、下线工位为准，故以车体过点记录明细表加上下线业务动作约束，可以得到车的产量。客户案例：汽车行业数据建模最佳实践 96 实际产成品数量原子指标 2)派生指标 派生指标通常由原子指标+时间周期+一个或多个修饰词组成。因此，派生指标关注的点为原子指标、时间周期、修饰词以及所属的业务过程。并且，由于公共层和应用层的定位均可存放派生指标，故也要指定好其所属层级。比如，我们要计算近 1天的 XX 车型实际产量，需要通过“车体实际产量+1d+XX 车型”得到。某派生指标 客户案例：汽车行业数据建模最佳实践 97 3)修饰词 修饰词是一种业务修饰，用来圈定或者聚焦统计数据的业务范围和限定。在此产品中，修饰词被

109、分为普通业务修饰词和维度枚举修饰词。车型信息可以作为一种修饰词，去结合其他的原子指标，衍生出车型维度下的各个派生指标。某修饰词 4)时间周期 时间周期是用来明确数据统计的时间范围或者时间窗口，例如近 1 天，近 1 自然周。用于在统计派生指标时，限定业务统计的时间范围。本次项目中用到的时间周期有，近 1 天，近一周，近一个月，近一个季度，近一年，每日，每月，每季度，每年。时间周期示例 客户案例：汽车行业数据建模最佳实践 98 2.数据标准 DataWorks 的数据标准包含字段标准、标准代码、度量单位、命名词典。1)字段标准 字段标准又称为数据字典，可理解为全局字段管理。可将多个表中含义相同但

110、字段名不同的内容进行关联，并对该字段制定相关的取值范围、度量单位、标准代码等内容。如图：对实际产成品数量的精度做了定义。字段标准 2)标准代码 标准代码是数据标准的取值范围，在标准代码中可设置某一数据标准可选择的数据的内容以及范围。某标准代码 3)度量单位 字段参数的数量单位（如个、厘米等）。如图，为常见时间单位。客户案例：汽车行业数据建模最佳实践 99 度量单位示例 4)命名词典 某命名词典 3.数仓规划 数仓规划包含了数据分层、业务分类、数据域和业务过程。1)数据分层 DataWorks 默认有五层数仓分层：数据引入层 ODS，明细数据层 DWD，汇总数据层 DWS，应用数据层 ADS，公

111、共维度层 DIM。客户案例：汽车行业数据建模最佳实践 100 数仓分层示例 2)业务分类 本次项目共划分了六个业务模块：汽车生产业务模块示例 客户案例：汽车行业数据建模最佳实践 101 3)数据域 数据域是一个较高层次的数据归类标准，是对企业业务过程进行抽象、提炼、组合的集合。某数据域 4.维度建模 DataWorks 的智能建模遵循 Kimball 维度建模理论。在此模块中，我们需要分别定义出维度表，明细表，汇总表的结构。某维度表 客户案例：汽车行业数据建模最佳实践 102 某明细表 某汇总表 六、总结 在建设的过程中，我们通过和车间负责人调研的方式了解各车间的生产业务和系统使用特点，最终圈

112、定了生产、质量、设备和成本四个业务域来建设指标模型。客户案例：汽车行业数据建模最佳实践 103 最终，我们在该企业共沉淀了 100+个指标，按照车间、线体、工位、设备、车辆、班次、能耗类型、缺陷类型、告警类型等 10+种不同维度延伸。帮助支撑了 5 个以上应用及报表系统。同时 DataWorks 智能建模产品在项目中的使用，使我们在梳理建模工作步骤时更加规范化、体系化，对接工作不再是依赖于散乱的文档，而是把每一步的产出都沉淀到工作台上。可以看到我们建模的每一个步骤都在平台上做了落实，对初次参与建模工作的人来说，是非常友好的：有时面对复杂的建模流程，经验不那么丰富的工作人员可能会感到无从下手，靠

113、着产品的引导可以很大程度帮助解决这个问题。后续我们也会将各个行业中的经验沉淀成行业数据模型模板，加速行业数据规范化建设。客户案例：大淘系数据模型治理最佳实践 104 客户案例：大淘系数据模型治理最佳实践 作者：郭进士，大淘系数仓团队 导读 本次分享题目为淘系数据模型治理，主要介绍过去一年淘系数据治理工作的一些总结。具体将围绕以下 4 部分展开：模型背景&问题 问题分析 治理方案 未来规划 一、模型背景&问题 1.整体情况 首先介绍一下淘系的整体数据背景。客户案例：大淘系数据模型治理最佳实践 105 淘系的数据中台成立至今已有 7 年左右，一直未作数据治理，整体数据生成构成比为：人工创建（22%

114、）+机器生成 78%。其中活跃数据占比：9%，不规范数据占比：21%。数据活跃以倒三角形状分布，整体分布比例为 ads:dws:dwd:dim=8:2:1:1，分布还算合理。上图中下半部分是模型的生命周期，增长和留存情况。淘系的业务还属于快速变化中，模型变化比较快。模型生命周期为 25 个月，模型年增长比例 30%，模型留存44%。2.公共层 公共层两大核心问题为：首先，公共层表复用性不高。在 2014 年的时候公共层还比较规范，但可持续性不强。随着时间流逝，业务增长和变化，复用性就逐年降低。因为大部分的数据是应用层做的，他们会开发自己的公共层，复用性降低，大部分都是无效表。另外，公共数据表在

115、各个团队分布不合理。这是由于数据团队多，为了满足业务开发效率，每个团队都有自己的公共表，容易出现公共表复用占比低，重复建设的场景。其中淘宝数据团队负责最多的公共数据表。客户案例：大淘系数据模型治理最佳实践 106 3.应用层分析 应用层的主要问题包括：第一，公共层建设不足或公共层透出不足。随着时间增长，公共层的指标不能满足 ads 层的业务需要，ads 复用指标逻辑没有下层，引用 cdm 层的 ads 表占比逐年降低，引用 ads 的 ads 表占比逐年增高。第二，较多的 ads 表共性逻辑未下沉，统计显示超过 17.63%ads 表被下游 ads复用。第三，跨集市依赖严重，统计显示，整体跨集

116、市依赖占比为 30%，特别是大进口和淘宝数据跨集市依赖达到了 40%，影响模型的稳定性，影响了模型的下线、修改。二、问题分析 1.问题汇总 以下这副图是简化后的数据模型，我们可以发现存在很多不规范问题影响了模型的稳定性。业务在快速发展的情况下，为了快速响应业务需求，产生模型问题是必然的。日常工作中，数据研发流程大致如下，接到业务需求，直接引用 ODS 层表开发ADS 数据，待数据需要复用的时候就把逻辑沉淀到公共层，同理指标也会有类似情况。客户案例：大淘系数据模型治理最佳实践 107 主要问题可以归纳为七点：系统临时表多，只增不删，对于消费侧影响较大，因为表量巨大，有效比例低，很难检索到。命名不

117、规范。公共层过度设计。ADS 重复建设。ADS 跨集市依赖。ADS 共性未下沉。ADS 穿透依赖 ODS。2.原因分析 从问题分类上看，主要有三大类问题：规范性问题，公共层复用性问题和应用层复用性问题。从问题原因上看，主要有四大类原因：架构规范，流程机制，产品工具，以及研发能力。客户案例：大淘系数据模型治理最佳实践 108 3.模型治理的问题 模型治理的挑战：业务价值不明显，治理带来的是长期价值，短期对业务影响不大。治理协作复杂，治理需要 ODS、CDM、ADS 层多人多团队协作。问题治理难根治，容易出现新模型依赖有问题模型。模型平均生命周期不长（25 个月）。综上所述，模型治理的 ROI 比

118、较低，我们的问题就是如何模型治理才最高效？客户案例：大淘系数据模型治理最佳实践 109 三、治理方案 1.整体方案 基于以上的问题原因分析，我们制定了如下治理方案。核心策略为以下三点：1)盘点存量，掌握数据的整体情况。2)规范增量，避免新增模型走老路，重复出现相同问题，考虑到数据的生命周期，历史数据可以先不管。3)日常治理保健康，以数据化驱动长期治理。2.机制规范 1)架构分层标准 客户案例：大淘系数据模型治理最佳实践 110 往年我们关注的是数据视角，今年关注的是业务视角，业务视角核心诉求主要有四点，交付效率、产出时效、质量可靠、成本可控。过去 OneData 定义了每一层的作用，但每个层次

119、的分工定位不清晰，针对这些问题重新做了清晰的定义。应用层核心是专注支持业务，需要考虑研发效率、交付数据口径一致性和稳定性。通过集市规范来控制复杂度，通过轻度聚合的中间层确保口径统一，通过扁平化设计确保稳定。公共层的核心是抽象复用来提升效率，需要考虑易用性和稳定性。通过规范和冗余宽表提升复用性，通过解耦来确保稳定性。ODS 层的核心是合规高效，需要考虑接入效率和性能稳定。通过工具化提升效率、优化治理确保性能的稳定。特别是在数据达到一定量之后要考虑采用 merge 的方式接入数据。2)集市划分规范 数据集市，是用来满足特定部门或者用户的需求，按照多维的方式进行存储。通过对相似数据业务场景内聚进行抽

120、象分类，以降低 ADS 层重复建设和数据管理复杂度，让应用研发更聚焦更高效。客户案例：大淘系数据模型治理最佳实践 111 集市划分的原则有以下两点：原则一：以业务场景或者服务对象作为划分原则，对相似数据业务场景内聚抽象进行分类。原则二：集市划分需要统一标准，尽量符合 MECE 原则。3)公共层共建机制 在建设公共层的建设过程中，我们通常会遇到以下两个痛点：客户案例：大淘系数据模型治理最佳实践 112 应用研发的痛点：公共层相应效率低。公共层研发的痛点：如果统一承接开发工作，涉及的业务很广泛，研发资源不足。为了解决以上两个痛点，我们通过以下核心原则来解决：原则一：公共层开放共建，事后审计治理 应

121、用开发整理需求，把需要下沉的公共维度提给公共层研发，公共开发需求评估。原则二：以应用需求驱动，设计开发共建 以需求为驱动，拆分出核心模型和非核心。模型，核心模型公共研发负责，非核心模型由业务开发进行，共同开发以提高效率。原则三：公共层研发统一运维保障 非核心模型上线并完成相关测试（准确性、确定性、治理）后转交给公共层研发，由公共层统一运维。3.智能建模 在数据治理中有数据规范与共建机制依然是不够的，还需要结合自动化工具来提升效率、保障规范。我们是从以下 4 个方面入手的（详情可以体验 DataWorks 的产品）：数据体系目录结构化 模型设计线上化 打通研发流程（自动化生成简代码）对接地图数据

122、专辑 1)数据目录体系结构化 形成数据体系目录有利于了解掌握数据，分门别类的方式降低了大家的使用成本。首先要对表命名做一些管控，我们做了可视化的表命名检测器，来确保规范性。另外，淘系不是一个单空间的数据体系，因此要解决跨多个空间的复杂数据体系的统一建模问题。客户案例：大淘系数据模型治理最佳实践 113 客户案例：大淘系数据模型治理最佳实践 114 2)模型设计线上化 改变模型设计方式，由线下设计迁移到线上，通过一些自动化工具，提升效率，保证规范。客户案例：大淘系数据模型治理最佳实践 115 3)打通研发流程（自动化生成简代码）模型迁移到线上后，打通研发流程自动生成简代码，生成代码框架，建表语句

123、，显著提高了研发效率。客户案例：大淘系数据模型治理最佳实践 116 4)对接地图数据专辑 形成相应的地图数据专辑，方便其他用户使用数据。4.模型治理 1)打分模型 客户案例：大淘系数据模型治理最佳实践 117 模型治理需要量化，如果没有量化全靠专家经验效率是非常低的，我们通过模型的指标形成到表级别的模型分。通过多维度对模型进行打分。2)打分机制 精细化的打分机制，针对团队、数据域、核心进行打分，形成相应的标签。客户案例：大淘系数据模型治理最佳实践 118 3)整体流程 以数据驱动，上图左边，以模型评估数据为出发点，通过各个维度对模型进行评估，得到各个域、各个团队的评分，形成相应的问题标签。以产

124、品驱动，上图右边，通过专家经验判断新上线模型升级搜索权限、下线模型降权限，让业务迅速感知数据变化，引导业务。四、未来规划 1.应用层效率 在整个数据体系中，应用层的数据体量是最大的，投入了大量的人力。OneData 缺少对应用层的数据建设指导，集市高度耦合，给运维效率带来了不少问题，如跨集市依赖、依赖深度的问题。过去都是以业务为主导，为了保障研发效率放弃了部分研发规范，以后要完善应用层的研发规范，同时通过工具做好研发效率与规范的平衡。2.架构规范管控 基于分层标准落地，对研发过程规范完善，包括对设计、开发、运维、变更、治理等规范进行细化。客户案例：大淘系数据模型治理最佳实践 119 目前核心是

125、表命名规范，对依赖规范、代码规范、运维规范等管控能力尚不足。3.产品工具提效 将继续与 Dataworks 共建。应用层智能建模能力还不能满足研发效率要求，因此会继续功能提效。数据测试功能集成。数据运维功能升级。事中数据治理能力构建（开发助手）。事后治理能力提效（批量删除、主动推送优化等)。数据地图，找数用数提效。五、提问 Q：核心公共层的建设是自顶向下还是自底向上？A：采用的是两者相结合的方式。以需求为驱动，没有需求就会导致过渡设计，在应用层有复用之后再下沉到公共层，这是自顶向下的。在公共层设计阶段是面向业务过程的，这时是自底向上的。Q：多 BU 公共层是否需要统一规范？怎么去做？怎么量化价

126、值？A：需要做统一的规范，规范利于数据流通，才能体现数据价值。但是具体怎么规范需要具体去看，如电商、本地生活，业务和目标不一样，很难做到统一的规范。Q：怎么判断指标需要下沉到公共层？A：公共层的开发是需要成本的，是否需要下沉到公共层核心是看是否需要复用，可以从两个方面入手。专家经验判断：如电商交易环节数据，这类数据是核心数据，是要建设到公共层的。事后判断：如玩法之类的业务稳定性不强，那一开始不需要下沉到公共层，避免过度设计，事后再去判断是否需要下沉。客户案例：大淘系数据模型治理最佳实践 120 Q：关于表、字段的命名规范，是否需要先定义好词根再开发？A：需要分开看。对于公共层设计到的业务过程是

127、有限的，对于公共部分要先定义好再开发。对于应用层，维度采用的是总建架构所以还需要先定义，对于指标特别是派生指标是多的，不建议先定义在开发。Q：如何解决口径一致命名不一致，或者口径不一致或者命名一致的场景。A：模型是演变的。对于应用层，80%都是自定义的，第一次出现的时候都是不标准的，这部分如果采用先定义后开发的方式，效率是很低的，只有在下沉到公共层的时候才能够管控。对于公共层，能做的是保障核心指标 90%的规范与定义统一，剩下的那部分也无法保证。Q：跨集市依赖下沉到公共层的必要性？A：短期来看，是没影响的，新增效率高。长期来会给数据的运维、治理带来很多影响，在数据下线、变更、治理过程中不得不考

128、虑到下游依赖，会影响全流程的开发效率。产品实操：零售电商数据建模操作实践 121 产品实操：零售电商数据建模操作实践 作者：李佳慧，DataWorks 产研团队 实验目标 以零售电商模拟数据为基础，了解数仓建模整体流程。通过 DataWorks 智能数据建模，进行数仓分层、数据建模、数据标准、数据指标等产品实操。业务背景 根据零售电商行业的会员、商品、交易、物流、评价等业务数据计算出 GMV（商品交易总额）、用户画像等数据供业务决策。注 本次实验数据为人工 mock 虚拟数据，非任何业务真实数据，仅供体验使用。流程简介 使用 DataWorks 智能建模模块，完成对业务数据仓库的模型规范制定及

129、数据分层、数据域、业务过程等信息的设定，完成逻辑模型的设计，并将逻辑模型发布生成物理表。实验步骤 一、环境准备 1.购买并开通 DataWorks 与 MaxCompute 产品实操：零售电商数据建模操作实践 122 https:/dw-common- DataWorks 专业版：首月 1 元 DataWorks 智能数据建模：首月 199 元 MaxCompute 按量付费 2.创建项目 登录 DataWorks 管理控制台，在上海地域创建一个新的工作空间。1)基本配置 工作空间名称：retail_e_commerce_2（由于 MaxCompute project name 需要全局唯一，

130、名称被占用请更换）显示名：零售电子商务 2 模式：标准模式（开放和生产隔离），标准模式和简单模式的区别请参见官方文档 描述：零售电子商务项目 注 开发环境 MaxCompute 项目名称：retail_e_commerce_2_dev 生产环境 MaxCompute 项目名称：retail_e_commerce_2 产品实操：零售电商数据建模操作实践 123 2)选择引擎 选择按量付费的 MaxCompute 引擎。这里非必选，可以选择先创建空间，后续在工作空间配置中再绑定。3)引擎详情 实例显示名称：retail_e_commerce_2 其余都使用默认配置。4)进入工作空间 创建完成后可从

131、当前页面“DataWorks 管理控制台-工作空间列表”入口进入DataWorks 数据开发界面。（当前语句有效，由于就在上一步操作完成的当前界面，所以没有提供截图。）进入工作空间后，从左上角-全部产品入口可以进入数据建模、数据集成、数据开发、运维中心等各个模块。产品实操：零售电商数据建模操作实践 124 3.绑定引擎 绑定 MaxCompute、Hologres（可选）、E-MapReduce（可选）引擎，绑定相关引擎后，可以创建对应的引擎节点。绑定引擎详情请参见官方文档配置工作空间。MaxCompute 引擎，由于之前我们创建的时候已选择该引擎，所以这里不需要再绑定。注意一下此处的几个配置

132、信息，一个标准模式的 DataWorks 工作空间对应两个MaxCompute 项目，一个生产环境和一个开发环境分别如下：产品实操：零售电商数据建模操作实践 125 生产环境 开发环境 参数 说明 参数 说明 MaxCompute项 目 名 称：retail_e_commerce_2 在未指定项目名的情况下，生产运维中心默认访问生产项目。MaxCompute项 目 名 称：retail_e_commerce_2_dev 在未指定项目名的情况下，DataStudio 和开发运维中心默认访问开发项目。MaxCompute 访问者身份：阿里云主账号 生产运维中心默认使用该身份访问。默认值为阿里云主账

133、号，支持修改为阿里云子账号或阿里云 RAM 角色。MaxCompute 访问者身份：任务执行者 DataStudio 和数据分析 SQL查询默认使用该身份访问。不可修改。Hologres 引擎 绑定 Hologres 引擎帮助文档。E-MapReduce 引擎 绑定 E-MapReduce 引擎帮助文档。产品实操：零售电商数据建模操作实践 126 4.权限规划（可选）本实验中使用主账号操作，相当于是最大权限。在实际生产中，对权限的管控需求可以参考如下：DataWorks：用户、角色与权限概述官方文档。MaxCompute：权限概述官方文档。二、维度建模 维度建模储备知识介绍。1.基本概念 智能

134、建模强依赖于 Kimball 维度建模理论，在实操前务必阅读一下数仓分层和维度建模中的基本概念。维度建模：详情请参见维度建模。业务分类：当企业业务比较复杂，不同类型业务彼此间需要共享数据域，但是又希望能在模型设计和应用过程中快速定位本业务的数据，可结合真实业务情况，规划不同的业务分类，在后续模型设计过程中，可将模型归属到对应的业务分类，提升 产品实操：零售电商数据建模操作实践 127 后续模型使用的便捷性。例如零售电子商务就是一个一级业务分类，如需进一步细分，可分为门店零售，电子商务等。数据域：是对企业业务过程进行抽象、提炼、组合的集合，是企业业务人员在使用数据时第一个分组入口，可以帮助企业业

135、务人员快速的从海量的数据中快速圈定到自己的业务数据。例如在电商领域，可以划分会员域、商品域、交易域等。业务过程：业务过程指企业的业务活动事件，如下单，支付。数据集市：是基于业务分类，面向特定应用场景或者产品的数据组织。通常位于数据应用层，依赖于公共层的整合数据。例如电商集市、生意参谋集市等。主题域：用于将数据集市按照分析视角进行划分，通常是联系较为紧密的数据主题的集合。例如在电商集市下，可以创建电商 360、活动等主题域。维度：维度是用于分析数据的一个角度，一方面对维度进行可控管理，另一方面指导维度表的设计，如地理维度，时间维度。维度属性：维度属性隶属于一个维度，用来描述维度的属性，如地理维度

136、中的国家名称，省份名称。时间周期：时间周期是用来明确数据统计的时间范围或者时间点，如最近 30 天，自然周。修饰词：修饰词是对指标统计业务范围的划定，指除了统计维度外指标的业务场景的限定抽象，如 PC 端，无线端。原子指标：用于明确业务的统计口径和计算逻辑，是基于用户的业务活动（即业务过程）创建的，用于统计业务活动中某一业务状况的数值。例如，存量会员数。派生指标：由原子指标、时间周期、修饰词构成，用于反映企业某一业务活动在指定时间周期及目标范围中的业务状况。例如，历史截至当日（时间周期）_异常会员（修饰词）_存量会员数（原子指标）。产品实操：零售电商数据建模操作实践 128 数仓分层：详情请参

137、见数仓分层 数据引入层 ODS（Operation Data Store）数据公共层 CDM（Common Data Model，又称通用数据模型层）?公共维度层（DIM）?公共汇总粒度事实层（DWS）?明细粒度事实层（DWD）数据应用层 ADS（Application Data Service）2.模型设计理论 以下简单介绍了维度建模模型设计方法论，举例说明了如何划分数据域等，更多关于维度建模方法论、事实表维度表模型设计内容，感兴趣的可以参考 Star Schema完全参考手册1重点看第 2 章第 6 章节和第 11 章节、数据仓库工具箱（第 3版）2。产品实操：零售电商数据建模操作实践 1

138、29 举例：如何划分数据域 注：以下为数据域划分案例，和本实验的数据域划分有一点出入。上面示意图引用自大数据之路：阿里巴巴大数据实践 3.预期结果 预期的分层划域，下图中从下到上数仓分层，从左到右划分数据域。这里仅需了解一下概貌，后面会一步一步配置，蓝色字体为本实验中需要使用到的表，需将模型发布至引擎生成物理表。产品实操：零售电商数据建模操作实践 130 注：“电商 360”指的电商商品交易总额、KPI360 度概览。4.维度建模工具实践过程 注 维度建模中部分标注了可选，表示不操作不影响后续实验。建议是都操作一下，以便结合业务从整体角度了解一下维度建模。1)数仓规划 a)业务分类 新建一个业

139、务分类 业务名称：电商业务；英文缩写：ec 产品实操：零售电商数据建模操作实践 131 b)数仓分层 系统内置了常规的数据分层，用户可以针对每个数据分层设置表名检查器。本实验使用默认分层结构，并且为了规范模型的命名，将同一分层中表名称的命名格式统一，我们为每个数仓分层配置对应的表名“检查器”，开启并设置默认检查器，在进行模型设计时，表名会按照检查器设置自动填充，设计师仅需补充自定义内容即可。贴源层：数据引入层 ODS 公共层：维度层 DIM、明细数据层 DWD、汇总数据层 DWS 应用层：应用数据层 ADS 表名检查器示例：弱规则：新建对象时，根据规则定义内容，推荐填写规则名称 强规则：新建对

140、象时，根据规则定义内容，推荐填写并强制校验规则名称 产品实操：零售电商数据建模操作实践 132 分层 规则定义 规则示例 维度层 DIM dim_业务大类英文缩写_数据域英文缩写_自定义 e.g：dim_ec_mbr_user_info 会员基础信息维度表 维度表_电商业务_会员域_xxxx 明细数据层 DWD dwd_业务大类英文缩写_数据域英文缩写_业务过程英文缩写_自定义_存储策略缩写 e.g：dwd_ec_trd_create_ord_di 交易下单明细事实表 明细表_电商业务_交易域_下单业务过程_xxxx_每日增量 汇总数据层 DWS dws_业务大类英文缩写_数据域英文缩写_自定

141、义_统计周期 e.g dws_ec_mbr_cnt_std 历史截至当日_存量会员数_cube统计表 汇总表_电商业务_会员域_xxx_历史截止当日 应用数据层 ADS ads_业务大类英文缩写_主题域英文缩写_自定义 真实场景中建议使用“ads_业务大类英文缩写_数据集市英文缩写_主题域英文缩写_自定义”e.g:ads_ec_ec360_gmv_kpi_overview 电 商360KPI 概览 应用表_电商业务_电商 360_xxx 数据引入层 ODS（一般 ODS 层不需要做数据建模，所以这里略）c)公共层 数据域 新建 6 个数据域，分别如下。尝试手动创建完一个数据域后，也可以下载 E

142、xcel 文件，使用通用工具-导入 Excel 英文缩写*英文名*中文名*备注 mbr mbr 会员域 网站服务的注册会员及潜在会员（leads）的各种基础信息 trd trd 交易域 交易从加入购物车到下单、支付、发货、退款及成果交易的各个过程，同时还包括拍卖、机票、彩票等各种类型的交易 itm itm 商品域 网站可供用户交易的商品数据，包括类目、品牌、SPU、SKU 等相关商品基础信息 lgt lgt 物流域（可选）log log 日志域（可选）各种类型的网站日志数据 risk risk 信用&风控域（可选）企业或者个人信用及风险相关的数据，包括审核、风控监控事件、评价、投诉、举报、申诉

143、、处罚等相关数据 产品实操：零售电商数据建模操作实践 133 业务过程 新建会员域下的业务过程。尝试手动建完一个业务过程后也可以下载 Excel 文件，使用通用工具-导入 Excel 英文缩写*中文名*英文名*数据域*备注 login 登录 login 会员域 register 注册 register 会员域 mbf_default（系统）会员域_默认（系统）mbr_default 会员域 数据域下默认的业务过程。新建交易域下的业务过程 英文缩写*中文名*英文名*数据域*备注 cart 加购 cart 交易域 加入购物车 create 下单 create 交易域 创建订单 pay 支付 pay

144、 交易域 产品实操：零售电商数据建模操作实践 134 refund 退款 refund 交易域 trd_default（系统）交易域_默认 trd_default 交易域 数据域下的默认业务过程。新建商品域下的业务过程 英文缩写*中文名*英文名*数据域*备注 on_off 商品上下架 on_off 商品域 publish 商品发布 publish 商品域 itm_default（系统）商品域_默认 itm_default 商品域 数据域下的默认业务过程。新建物流域下的业务过程（可选）英文缩写*中文名*英文名*数据域*备注 take_over 揽件 take_over 物流域 lg_order_

145、crt 接单 lg_order_crt 物流域 ship 发货 ship 物流域 delivery 派送 delivery 物流域 sign 签收 sign 物流域 lgt_default（系统）物流域_默认 lgt_default（系统）物流域 数据域下的默认的业务过程。新建日志域下的业务过程（可选）英文缩写*中文名*英文名*数据域*备注 exp 曝光 exposure 日志域 se 搜索 search 日志域 clk 点击 click 日志域 pv 浏览 pv 日志域 log_default（系统）日志域_默认 log_default 日志域 数据域下的默认业务过程。新建信用&风控域下的业

146、务过程（可选）产品实操：零售电商数据建模操作实践 135 英文缩写*中文名*英文名*数据域*备注 remark 评价 remark 信用&风控域 risk_default（系统）信用&风控域_默认 risk_default 信用&风控域 数据域下的默认业务过程 d)应用层 数据集市 新建两个一级数据集市 集市名称 英文缩写 所属业务分类 电商集市 ec 电商业务 供应链数据集市 gyl 电商业务 英文缩写：ec 集市名称：电商集市 所属业务分类：电商业务 主题域 新建一级主题域，分别如下：注：后续实验中实际使用到 ec360 这个主题域。产品实操：零售电商数据建模操作实践 136 英文缩写 主

147、题域名称 所属数据集市 备注 ec360 电商 360 电商集市 open_red 开门红 电商集市 rfd 退款 电商集市 lgt 物流 电商集市 flow 流量通道 电商集市 act 活动 电商集市 byr 买家 电商集市 brand 品牌 电商集市 cate 品类 电商集市 slr 商家 电商集市 itm 商品 电商集市 e)建模空间 当您所需要管理多个 DataWorks 工作空间且需要复用一套数仓规划时，面对跨多个工作空间的复杂数据体系，可以通过设计空间来共享一套数据建模工具，针对整个数据体系进行统一地数仓规划、维度建模及指标定义等工作。当配置了数据研发工作空间后，在后续模型发布时可

148、以选择对应的工作空间，更多详情请参见建模空间官方文档。注：当前步骤仅为核心功能展示，不操作不影响后续实验。产品实操：零售电商数据建模操作实践 137 2)数据标准 a)新建字段标准 新建根目录，名称：线上业务 新建子目录，名称：会员 新建 5 个标准，分别如下表；也可以下载 Excel 文件，使用 Excel 导入。标准编码 英文缩写 英文名称 中文名称 数据类型 birthday birthday birthday 生日 DATETIME user_name user_name user_name 用户名称 STRING nick nick nick 昵称 STRING gender gen

149、der gender 性别 STRING user_id user_id user_id 用户 id BIGINT 产品实操：零售电商数据建模操作实践 138 b)新建标准代码 新建目录 目录 1 名称：基础代码 目录 2 名称：风控 新建 2 个标准代码，并执行发布到 MaxCompute 引擎 代码标准 1 代码编号：is_del 代码名称：是否删除 英文名称：is_del 编码取值 编码名称 英文名称 编码含义 1 true true 是 0 false false 否 代码标准 2 代码编号：risks_level 代码名称：风险等级 英文名称：risks_level 产品实操：零售电

150、商数据建模操作实践 139 编码取值 编码名称 英文名称 编码含义 1 高级 high 高级 2 中级 middle 中级 c)新建度量单位 新建一个度量单位 英文缩写：people_cnt 英文名称：people_cnt 中文名称：人数 分类：对象量词 产品实操：零售电商数据建模操作实践 140 3)维度建模（公共层维度表模型和明细表模型）a)公共层-维度表模型 创建 4 张维度表模型，分别如下。维度表 1：dim_ec_itm_item_info 商品基础信息维度表 基本信息：数仓分层*数据域*业务分类 存储策略 表名*表中文名*生命周期 描述 公共层：维度层 商品域（itm）电商业务 d

151、im_ec_itm_item_info 注：表名是在选完业务分类、数据域后根据数仓分层中配置的检查器自动填充dim_ec_itm部分内容，再手动填写自定义_item_info部分。商品基础信息维度表 365 天 商 品 基 础信 息 维 度表 字段管理和分区字段管理：支持手动录入、快捷模式或代码模式的方式配置字段管理和分区字段管理，建议新建模型时使用快捷模式查找已有表/视图的方式来快速导入，修改模型时使用代码模式，两种方式结合使用。产品实操：零售电商数据建模操作实践 141 本实验各个层级其中一张表会使用快捷模式来配置，其余表由于创建方法大体一致，为减少重复操作使用代码模式创建，代码模式支持

152、FML、MaxCompute DDL、Hive DDL、MySQL DDL 等多种语言，本实验中会贴出 FML（适用于维度建模领域的类 SQL语言，FML 语句格式文档）、MaxCompute DDL 两种的 DDL 语句，您可以根据情况选择任意一种。当前表使用快捷模式配置。快捷模式配置：step1：进 入 编 辑 状 态，使 用 快 捷 模 式，搜 索 已 有 表“odps.retail_e_commerce_2.ods_item_info”，选择“导入全部字段”，导入后还能溯源到“来源表”和“来源字段”。注 快捷模式使用到了“查找已有表/视图”，由于当前空间全新，没有已有表，请先执行一下文

153、末附件的 ODS 层 DDL 语句。实际应用过程中，可以直接使用已存在的表或视图。产品实操：零售电商数据建模操作实践 142 step2：选中“id”字段，右键删除，也支持批量删除。step3：修改模型字段类型：将“gmt_create、gmt_modified”字 段 类 型 批 量 修 改 为“string”；将“reserve_price、secure_trade_ordinary_post_fee、secure_trade_fast_post_fee、secure_trade_ems_post_fee”字段类型修改为“double”；修改模型字段显示名：将“gmt_modified”字

154、 段 显 示 名 称 修 改 为“商 品 最 后 修 改 日 期”；将“gmt_create”字段显示名称修改为“商品创建时间”，保存；修改模型字段顺序：再点一次编辑，使用代码模式调整一下字段顺序，将“gmt_modified”字段调整到“gmt_create”字段前面，保存。产品实操：零售电商数据建模操作实践 143 代码模式配置：-不支持修改表名 CREATE DIM TABLE dim_ec_itm_item_info ALIAS 商品基础信息维度表 (gmt_modified ALIAS 商品最后修改日期 STRING COMMENT 商品最后修改日期,gmt_create ALIAS

155、 商品创建时间 STRING COMMENT 商品创建时间,item_id ALIAS 商品数字 ID BIGINT COMMENT 商品数字 ID,title ALIAS 商品标题 STRING COMMENT 商品标题,sub_title ALIAS 商品子标题 STRING COMMENT 商品子标题,pict_url ALIAS 主图 URL STRING COMMENT 主图 URL,desc_path ALIAS 商品描述的路径 STRING COMMENT 商品描述的路径,item_status ALIAS 商品状态 1：确认通过 0：未确认通过 BIGINT COMMENT 商

156、品状态 1：确认通过 0：未确认通过,last_online_time ALIAS 最近一次开始销售时间，商品上架时间 DATETIME COMMENT 最近一次开始销售时间，商品上架时间,last_offline_time ALIAS 销售结束时间，表示一个销售周期的结束，仅作用于拍卖商品 DATETIME COMMENT 销售结束时间，表示一个销售周期的结束，仅作用于拍卖商品,duration ALIAS 有效期，销售周期，只有两个值，7 天或 14 天 BIGINT COMMENT 有效期，销售周期，只有两个值，7 天或 14 天,reserve_price ALIAS 当前价格 DOU

157、BLE COMMENT 当前价格,secure_trade_ordinary_post_fee ALIAS 平邮费用 DOUBLE COMMENT 平邮费用,secure_trade_fast_post_fee ALIAS 快递费用 DOUBLE COMMENT 快递费用,secure_trade_ems_post_fee ALIAS EMS 邮费 DOUBLE COMMENT EMS 邮费,last_online_quantity ALIAS 商品最近一次上架时的库存数量 BIGINT COMMENT 商品最近一次上架时的库存数量,features ALIAS 商品特征 STRING COM

158、MENT 商品特征,cate_id ALIAS 商品叶子类目 ID BIGINT COMMENT 商品叶子类目ID,cate_name ALIAS 商品叶子类目名称 STRING COMMENT 商品叶子类目名称,commodity_id ALIAS 品类 ID BIGINT COMMENT 品类 ID,commodity_name ALIAS 品类名称 STRING COMMENT 品类名称,is_virtual ALIAS 是否虚拟商品 STRING COMMENT 是否虚拟商品,shop_id ALIAS 商家 ID BIGINT COMMENT 商家 ID,shop_nick ALIA

159、S 商家 NICK STRING COMMENT 商家 NICK,is_deleted ALIAS 类目是否删除 BIGINT COMMENT 类目是否删除)COMMENT 商品基础信息维度表 PARTITIONED BY(ds ALIAS 业务日期,yyyymmdd STRING COMMENT 业务日期,yyyymmdd)产品实操：零售电商数据建模操作实践 144 WITH(life_cycle=365);-不支持修改表名 CREATE TABLE dim_ec_itm_item_info(gmt_modified STRING COMMENT 商品最后修改日期,gmt_create ST

160、RING COMMENT 商品创建时间,item_id BIGINT COMMENT 商品数字 ID,title STRING COMMENT 商品标题,sub_title STRING COMMENT 商品子标题,pict_url STRING COMMENT 主图 URL,desc_path STRING COMMENT 商品描述的路径,item_status BIGINT COMMENT 商品状态 1：确认通过 0：未确认通过,last_online_time DATETIME COMMENT 最近一次开始销售时间，商品上架时间,last_offline_time DATETIME CO

161、MMENT 销售结束时间，表示一个销售周期的结束，仅作用于拍卖商品,duration BIGINT COMMENT 有效期，销售周期，只有两个值，7 天或 14天,reserve_price DOUBLE COMMENT 当前价格,secure_trade_ordinary_post_fee DOUBLE COMMENT 平邮费用,secure_trade_fast_post_fee DOUBLE COMMENT 快递费用,secure_trade_ems_post_fee DOUBLE COMMENT EMS 邮费,last_online_quantity BIGINT COMMENT 商品

162、最近一次上架时的库存数量,features STRING COMMENT 商品特征,cate_id BIGINT COMMENT 商品叶子类目 ID,cate_name STRING COMMENT 商品叶子类目名称,commodity_id BIGINT COMMENT 品类 ID,commodity_name STRING COMMENT 品类名称,is_virtual STRING COMMENT 是否虚拟商品,shop_id BIGINT COMMENT 商家 ID,shop_nick STRING COMMENT 商家 NICK,is_deleted BIGINT COMMENT 类

163、目是否删除)COMMENT 商品基础信息维度表 PARTITIONED BY(ds STRING COMMENT 业务日期,yyyymmdd)LIFECYCLE 365;配置完成后保存并发布当前模型，生成物理表。产品实操：零售电商数据建模操作实践 145 使用“模型开发”功能联动数据开发模块（这步仅作为核心功能演示，实操后可以不保存节点，在后续实验步骤中可以使用该功能来开发）。如果使用快捷模式中的查找表、冗余字段查找表构建模型，系统会自动构建完整度较高的 etl，开发者只需要补充业务逻辑即可。不使用快捷模式查找表创建模型，如手动录入、ddl 导入，构建的 etl 代码需要补充的信息相对就会多，

164、且需要查看元数据来确认字段含义。产品实操：零售电商数据建模操作实践 146 维度表 2：dim_ec_mbr_user_info 会员基础信息维度表 基本信息：数仓分层*数据域*业务分类 存储策略 表名*表中文名*生命周期 描述 表类型*公共层：维度层 会员域（mbr）电商业务 每日全量（df）dim_ec_mbr_user_info 会员基础信息维度表 365 天 普通维度表 字段管理和分区字段管理：当前表使用代码模式配置，选用 FML 语言。（使用代码模式时，在配置完基本信息后请先保存，再点编辑，继续配置字段部分）使用代码模式配置：将 user_id 字段设置为业务“主键”和“非空”；对n

165、ick字段关联字段标准昵称；对is_delete字段关联标准代码是否删除。将模型发布至 MaxCompute 引擎会生成对应的数据质量 DQC 校验规则来检查 user_id 字段的值唯一和非空。产品实操：零售电商数据建模操作实践 147 -不支持修改表名 CREATE DIM TABLE dim_ec_mbr_user_info ALIAS 会员基础信息维度表 (user_id ALIAS 会员数字 ID BIGINT NOT NULL COMMENT 会员数字 ID,nick ALIAS 昵称 STRING COMMENT 会员 NICK。会员昵称 WITH(dict=nick),gmt_

166、create ALIAS 创建时间 STRING COMMENT 创建时间,gmt_modified ALIAS 修改时间 STRING COMMENT 修改时间,reg_fullname ALIAS 个人认证表示真实姓名，企业认证表示企业名称 STRING COMMENT 个人认证表示真实姓名，企业认证表示企业名称,reg_mobile_phone ALIAS 注册时绑定手机号码 STRING COMMENT 注册时绑定手机号码,reg_email ALIAS 注册填写 EMAIL（用户可以修改）STRING COMMENT 注册填写EMAIL（用户可以修改）,reg_gender ALIA

167、S 注册填写性别（F 女，M 男，不是这两个就是未知的，说明性别保密）STRING COMMENT 注册填写性别（F 女，M 男，不是这两个就是未知的，说明性别保密）,reg_gender_name ALIAS 注册填写性别（F 女，M 男，不是这两个就是未知的，说明性别保密）STRING COMMENT 注册填写性别（F 女，M 男，不是这两个就是未知的，说明性别保密）,reg_birthdate ALIAS 注册填写生日（用户可以修改）STRING COMMENT 注册填写生日（用户可以修改）,reg_address ALIAS 注册填写地址（用户可以修改）STRING COMMENT 注

168、册填写地址（用户可以修改）,产品实操：零售电商数据建模操作实践 148 reg_nation_id ALIAS 注册填写国家 ID（暂时为空）STRING COMMENT 注册填写国家ID（暂时为空）,reg_nation_id_name ALIAS 注册填写国家 ID（暂时为空）STRING COMMENT 注册填写国家 ID（暂时为空）,reg_prov_id ALIAS 注册填写省 ID STRING COMMENT 注册填写省 ID,reg_prov_name ALIAS 名称 STRING COMMENT 名称,reg_city_id ALIAS 注册填写城市 ID STRING C

169、OMMENT 注册填写城市 ID,reg_city_name ALIAS 名称 STRING COMMENT 名称,user_regip ALIAS 注册 IP STRING COMMENT 注册 IP,id_card_type ALIAS 会员认证证件类型 0：未知 1：身份证 2：企业营业执照号 BIGINT COMMENT 会员认证证件类型 0：未知 1：身份证 2：企业营业执照号,id_card_name ALIAS 会员认证证件类型 0：未知 1：身份证 2：企业营业执照号 STRING COMMENT 会员认证证件类型 0：未知 1：身份证 2：企业营业执照号,id_card_nu

170、mber ALIAS 个人认证表示身份证号，企业认证表示企业的营业执照号，没有认证不保证准确性 STRING COMMENT 个人认证表示身份证号，企业认证表示企业的营业执照号，没有认证不保证准确性,id_gender ALIAS 身份证解析性别（F 女，M 男，unkown 表示身份证为空或格式不对）STRING COMMENT 身份证解析性别（F 女，M 男，unkown 表示身份证为空或格式不对）,id_bday ALIAS 身份证解析生日（身份证为空或格式不对则为-1）STRING COMMENT 身份证解析生日（身份证为空或格式不对则为-1）,id_age ALIAS 身份证解析年龄

171、（身份证为空或格式不对则为-1）STRING COMMENT 身份证解析年龄（身份证为空或格式不对则为-1）,user_regdate ALIAS 注册时间 STRING COMMENT 注册时间,user_active_type ALIAS 用户激活方式，1 邮件;2 手机;STRING COMMENT 用户激活方式，1 邮件;2 手机;,user_active_name ALIAS 用户激活激活方式名称 STRING COMMENT 用户激活激活方式名称,user_active_time ALIAS 激活时间 STRING COMMENT 激活时间,vip_level ALIAS VIP

172、等级 BIGINT COMMENT VIP 等级,vip_level_name ALIAS VIP 等级名称。v1，v2，v3 等 STRING COMMENT VIP 等级名称。v1，v2，v3 等,is_delete ALIAS 是否删除 STRING COMMENT 是否删除 WITH(code_table=is_del),CONSTRAINT PK PRIMARY KEY(user_id)COMMENT 会员基础信息维度表 PARTITIONED BY(ds ALIAS 业务日期,yyyymmdd STRING COMMENT 业务日期,yyyymmdd)产品实操：零售电商数据建模操作

173、实践 149 WITH(life_cycle=365);-不支持修改表名 CREATE TABLE dim_ec_mbr_user_info(user_id BIGINT COMMENT 会员数字 ID,nick STRING COMMENT 会员 NICK。会员昵称,gmt_create STRING COMMENT 创建时间,gmt_modified STRING COMMENT 修改时间,reg_fullname STRING COMMENT 个人认证表示真实姓名，企业认证表示企业名称,reg_mobile_phone STRING COMMENT 注册时绑定手机号码,reg_email

174、 STRING COMMENT 注册填写 EMAIL（用户可以修改）,reg_gender STRING COMMENT 注册填写性别（F 女，M 男，不是这两个就是未知的，说明性别保密）,reg_gender_name STRING COMMENT 注册填写性别（F 女，M 男，不是这两个就是未知的，说明性别保密）,reg_birthdate STRING COMMENT 注册填写生日（用户可以修改）,reg_address STRING COMMENT 注册填写地址（用户可以修改）,reg_nation_id STRING COMMENT 注册填写国家 ID（暂时为空）,reg_natio

175、n_id_name STRING COMMENT 注册填写国家 ID（暂时为空）,reg_prov_id STRING COMMENT 注册填写省 ID,reg_prov_name STRING COMMENT 名称,reg_city_id STRING COMMENT 注册填写城市 ID,reg_city_name STRING COMMENT 名称,user_regip STRING COMMENT 注册 IP,id_card_type BIGINT COMMENT 会员认证证件类型 0：未知 1：身份证 2：企业营业执照号,id_card_name STRING COMMENT 会员认证

176、证件类型 0：未知 1：身份证 2：企业营业执照号,id_card_number STRING COMMENT 个人认证表示身份证号，企业认证表示企业的营业执照号，没有认证不保证准确性,id_gender STRING COMMENT 身份证解析性别（F 女，M 男，unkown 表示身份证为空或格式不对）,id_bday STRING COMMENT 身份证解析生日（身份证为空或格式不对则为-1）,id_age STRING COMMENT 身份证解析年龄（身份证为空或格式不对则为-1）,user_regdate STRING COMMENT 注册时间,user_active_type ST

177、RING COMMENT 用户激活方式，1 邮件;2 手机;,user_active_name STRING COMMENT 用户激活激活方式名称,user_active_time STRING COMMENT 激活时间,产品实操：零售电商数据建模操作实践 150 vip_level BIGINT COMMENT VIP 等级,vip_level_name STRING COMMENT VIP 等级名称。v1，v2，v3 等,is_delete STRING COMMENT 是否删除)COMMENT 会员基础信息维度表 PARTITIONED BY(ds STRING COMMENT 业务日期

178、,yyyymmdd)LIFECYCLE 365;设置主键、非空、关联字段标准和关联标准代码图示。维度表 3：dim_ec_trd_biz_type 交易类型（可选）基本信息：数仓分层*数据域*业务分类 存储策略 表名*表中文名*生命周期 描述 表类型*公共层：维度层 交易域（trd）电商业务 dim_ec_trd_biz_type 交易类型 交 易类型 普通维度表 字段管理和分区字段管理：使用代码模式配置 -不支持修改表名 产品实操：零售电商数据建模操作实践 151 CREATE DIM TABLE dim_ec_trd_biz_type ALIAS 交易类型 (code ALIAS code

179、 STRING,value ALIAS value STRING,description ALIAS description STRING)COMMENT 交易类型;-不支持修改表名 CREATE TABLE dim_ec_trd_biz_type(code STRING,value STRING,description STRING)COMMENT 交易类型;维度表 4：dim_ec_itm_cat 商品类目维度表（可选）基本信息：数仓分层*数据域*业务分类 存储策略 表名*表中文名*生命周期 描述 表类型*公共层：维度层 商 品 域（itm）电商业务 每 日 全 量（df）dim_ec_i

180、tm_cat 商品类目维度表 商品类目维度表 普通维度表 字段管理和分区字段管理：-不支持修改表名 CREATE DIM TABLE dim_ec_itm_cat ALIAS 商品类目维度表 (cate_id ALIAS cate_id BIGINT NOT NULL,cate_name ALIAS cate_name STRING,CONSTRAINT PK PRIMARY KEY(cate_id)COMMENT 商品类目维度表 PARTITIONED BY(ds ALIAS 业务日期,yyyymmdd STRING COMMENT 业务日期,yyyymmdd);-不支持修改表名 产品实操：

181、零售电商数据建模操作实践 152 CREATE TABLE dim_ec_itm_cat(cate_id BIGINT,cate_name STRING)COMMENT 商品类目维度表 PARTITIONED BY(ds STRING COMMENT 业务日期,yyyymmdd);关联关系 维度模型间如果有业务上的“外键”概念，可以使用关联关系来建立两个维度表模型直间的联系。比如 dim_ec_itm_item_info 的 cate_id 与 dim_ec_itm_cat 的业务主键 cate_id 通过画板拉线的方式建立关联关系。b)公共层-明细表模型 创建 3 张明细表模型，分别如下。明

182、细表 1：dwd_ec_mbr_register_event_di 会员注册事件明细事实表（可选）基本信息：产品实操：零售电商数据建模操作实践 153 数仓分层*数仓分层*业务分类业务分类 业务过程*业务过程*存储策略存储策略 表名*表名*表中文名*表中文名*生命周期生命周期 描述描述 表类型*表类型*公共层：明细数据层 电商业务 会员域/注册 每 日 增 量（di）dwd_ec_mbr_register_event_di 会员注册事件明细事实表 365 天 事实事务表 字段管理和分区字段管理：注 由于明细表字段配置这里没有涉及到新的功能点，所以全部使用代码模式配置。使用代码模式配置：-不支持

183、修改表名 CREATE FACT TABLE dwd_ec_mbr_register_event_di ALIAS 会员注册事件明细事实表 (event_time ALIAS 日志输出时间 DATETIME COMMENT 日志输出时间,session_id ALIAS 注册临时会话 id STRING COMMENT 注册临时会话 id,application ALIAS 应用名称 STRING COMMENT 应用名称,process ALIAS 注册流程 STRING COMMENT 注册流程,action ALIAS 流程中的步骤 STRING COMMENT 流程中的步骤,ip AL

184、IAS ip STRING COMMENT ip,mobile_area ALIAS 手机对应国家区号 STRING COMMENT 手机对应国家区号,mobile ALIAS 注册或激活手机号码 STRING COMMENT 注册或激活手机号码,email ALIAS 注册或激活邮箱 STRING COMMENT 注册或激活邮箱,nick ALIAS 注册或激活 nick STRING COMMENT 注册或激活 nick,reg_from ALIAS 注册来源 STRING COMMENT 注册来源,产品实操：零售电商数据建模操作实践 154 local_host_name ALIAS 日

185、志记录服务器 STRING COMMENT 日志记录服务器,verify_type ALIAS 验证方式 STRING COMMENT 验证方式,action_result ALIAS 当前 action 结果信息 STRING COMMENT 当前 action 结果信息,is_success ALIAS 当前 action 结果信息 STRING COMMENT 当前 action 结果信息,target_url ALIAS 注册传入目标跳转地址 STRING COMMENT 注册传入目标跳转地址,os_type ALIAS 操作系统类型 STRING COMMENT 操作系统类型,app

186、_version ALIAS app 版本 STRING COMMENT app 版本)PARTITIONED BY(ds ALIAS 业务日期,yyyymmdd STRING COMMENT 业务日期,yyyymmdd)WITH(life_cycle=365);-不支持修改表名 CREATE TABLE dwd_ec_mbr_register_event_di(event_time DATETIME COMMENT 日志输出时间,session_id STRING COMMENT 注册临时会话 id,application STRING COMMENT 应用名称,process STRING

187、 COMMENT 注册流程,action STRING COMMENT 流程中的步骤,ip STRING COMMENT ip,mobile_area STRING COMMENT 手机对应国家区号,mobile STRING COMMENT 注册或激活手机号码,email STRING COMMENT 注册或激活邮箱,nick STRING COMMENT 注册或激活 nick,reg_from STRING COMMENT 注册来源,local_host_name STRING COMMENT 日志记录服务器,verify_type STRING COMMENT 验证方式,action_r

188、esult STRING COMMENT 当前 action 结果信息,is_success STRING COMMENT 当前 action 结果信息,target_url STRING COMMENT 注册传入目标跳转地址,os_type STRING COMMENT 操作系统类型,app_version STRING COMMENT app 版本)COMMENT 会员注册事件明细事实表 PARTITIONED BY(ds STRING COMMENT 业务日期,yyyymmdd)LIFECYCLE 365;产品实操：零售电商数据建模操作实践 155 明细表 2：dwd_ec_trd_cr

189、eate_ord_di 交易下单明细事实表 基本信息：数仓分层*业务分类 业务过程*存储策略 表名*表中文名*生命周期 描述 表类型*公共层：明细数据层 电商业务 交易域/下单 每日增量（di）dwd_ec_trd_create_ord_di 交易下单明细事实表 356 天 交易下单明细事实表 事 实 事务表 字段管理和分区字段管理：使用代码模式配置：-不支持修改表名 CREATE FACT TABLE dwd_ec_trd_create_ord_di ALIAS 交易下单明细事实表 (id ALIAS 主键 BIGINT COMMENT 主键,gmt_create ALIAS 订单创建时间

190、DATETIME COMMENT 创建时间,gmt_modified ALIAS 订单修改时间 DATETIME COMMENT 修改时间,sub_order_id ALIAS 子订单 ID BIGINT NOT NULL COMMENT 子订单 ID,parent_order_id ALIAS 父订单 ID BIGINT COMMENT 父订单 ID,buyer_id ALIAS 买家数字 id BIGINT COMMENT 买家数字 id,buyer_nick ALIAS 买家昵称 STRING COMMENT 买家昵称,item_id ALIAS 商品数字 id BIGINT COMME

191、NT 商品数字 id,item_price ALIAS 商品价格 单位分 DECIMAL(38,18)COMMENT 商品价格 单位分,buy_amount ALIAS 购买数量 BIGINT COMMENT 购买数量,biz_type ALIAS 交易类型 BIGINT COMMENT 交易类型,memo ALIAS 备注 STRING COMMENT 备注,pay_status ALIAS 支付状态 BIGINT COMMENT 支付状态,logistics_status ALIAS 物流状态 BIGINT COMMENT 物流状态,status ALIAS 状态 BIGINT COMME

192、NT 状态,seller_memo ALIAS 卖家的给交易的备注 STRING COMMENT 卖家的给交易的备注,buyer_memo ALIAS 买家给交易的备注 STRING COMMENT 买家给交易的备注,ip ALIAS 买家 IP STRING COMMENT 买家 IP,end_time ALIAS 交易结束时间 DATETIME COMMENT 交易结束时间,pay_time ALIAS 付款的时间 DATETIME COMMENT 付款的时间,产品实操：零售电商数据建模操作实践 156 is_sub ALIAS 是否是子订单 1 表示子订单 BIGINT COMMENT

193、是否是子订单 1 表示子订单,is_parent ALIAS 是否是父订单 1 表示父订单 BIGINT COMMENT 是否是父订单 1 表示父订单,shop_id ALIAS 商家 id BIGINT COMMENT 商家 id,total_fee ALIAS 去除折扣和调整后的子订单费用 DECIMAL(38,18)COMMENT 去除折扣和调整后的子订单费用,PRIMARY KEY(sub_order_id)COMMENT 交易下单明细事实表 PARTITIONED BY(ds ALIAS 业务日期,yyyymmdd STRING COMMENT 业务日期,yyyymmdd)WITH(

194、life_cycle=365);-不支持修改表名 CREATE TABLE dwd_ec_trd_create_ord_di(id BIGINT COMMENT 主键,gmt_create DATETIME COMMENT 创建时间,gmt_modified DATETIME COMMENT 修改时间,sub_order_id BIGINT COMMENT 子订单 ID,parent_order_id BIGINT COMMENT 父订单 ID,buyer_id BIGINT COMMENT 买家数字 id,buyer_nick STRING COMMENT 买家昵称,item_id BIGI

195、NT COMMENT 商品数字 id,item_price DECIMAL(38,18)COMMENT 商品价格 单位分,buy_amount BIGINT COMMENT 购买数量,biz_type BIGINT COMMENT 交易类型,memo STRING COMMENT 备注,pay_status BIGINT COMMENT 支付状态,logistics_status BIGINT COMMENT 物流状态,status BIGINT COMMENT 状态,seller_memo STRING COMMENT 卖家的给交易的备注,buyer_memo STRING COMMENT

196、买家给交易的备注,ip STRING COMMENT 买家 IP,end_time DATETIME COMMENT 交易结束时间,pay_time DATETIME COMMENT 付款的时间,is_sub BIGINT COMMENT 是否是子订单 1 表示子订单,is_parent BIGINT COMMENT 是否是父订单 1 表示父订单,shop_id BIGINT COMMENT 商家 id,产品实操：零售电商数据建模操作实践 157 total_fee DECIMAL(38,18)COMMENT 去除折扣和调整后的子订单费用)COMMENT 交易下单明细事实表 PARTITION

197、ED BY(ds STRING COMMENT 业务日期,yyyymmdd);明细表 3：dwd_ec_itm_publish_event_detail_di 商品发布事件详情事实表（可选）基本信息：数仓分层*业务分类 业务过程*存储策略 表名*表中文名*生命周期 描述 表类型*公共层：明细数据层 电商业务 商品域/商品发布 每 日 增 量（di）dwd_ec_itm_publish_event_detail_di 商品发布事件详情事实表 365 天 商品发布事件详情事实表 事 实 事务表 字段管理和分区字段管理：-不支持修改表名 CREATE FACT TABLE dwd_ec_itm_pu

198、blish_event_detail_di ALIAS 商品发布事件详情事实表 (operation_type ALIAS 操作类型 BIGINT COMMENT 操作类型,source_from ALIAS 商品发布源头 STRING COMMENT 商品发布源头,item_id ALIAS 商品数字 ID STRING COMMENT 商品数字 ID,user_id ALIAS 用户 id STRING COMMENT 用户 id,is_success ALIAS 是否发布成功 STRING COMMENT 是否发布成功,cate_id ALIAS 商品叶子类目 ID BIGINT COM

199、MENT 商品叶子类目 ID,cate_name ALIAS 商品叶子类目名称 STRING COMMENT 商品叶子类目名称)COMMENT 商品发布事件详情事实表 PARTITIONED BY(ds ALIAS 业务日期,yyyymmdd STRING COMMENT 业务日期,yyyymmdd)WITH(life_cycle=365);产品实操：零售电商数据建模操作实践 158-不支持修改表名 CREATE TABLE dwd_ec_itm_publish_event_detail_di(operation_type BIGINT COMMENT 操作类型,source_from STR

200、ING COMMENT 商品发布源头,item_id STRING COMMENT 商品数字 ID,user_id STRING COMMENT 用户 id,is_success STRING COMMENT 是否发布成功,cate_id BIGINT COMMENT 商品叶子类目 ID,cate_name STRING COMMENT 商品叶子类目名称)COMMENT 商品发布事件详情事实表 PARTITIONED BY(ds STRING COMMENT 业务日期,yyyymmdd)LIFECYCLE 365;4)数据指标 a)概览 原子指标和派生指标可以被汇总层或应用层表模型关联。在后续

201、建表模型时，我们可以快速勾选派生指标，构建模型，模型中的字段也可以和指标构建关联关系。例如：原子指标mbr_cnt被汇总表模型dws_ec_mbr_cnt_std所关联。产品实操：零售电商数据建模操作实践 159 派生指标由原子指标、修饰词、时间周期构成。例如，存量会员数+历史截止当日+异常会员=历史截至当日_异常会员_存量会员数，该派生指标可以作为模型的字段存在，也可以和模型的字段做关联。b)原子指标 新建 13 个原子指标保存并提交，分别如下表；也可以下载 Excel 文件，使用 Excel导入，如果部分可选数据域未创建，请先将下载的 excel 文件中相关数据域删除再执行导入。业务过程

202、英文缩写 英文名称 中文名称 业务口径 描述 指标来源 计算函数 小数位数 数据单位 是否去重 会员域/注册 new_mbr_cnt new member count 注册会员数 注册会员数 计数（COUNT）0 人数 是 会员域/会员域_默认 mbr_cnt member count 存量会员数 注册且激活的会员总量 计数（COUNT）0 人数 是 交易域/支付 pay_ord_cnt pay order count 支付子订单数 支付子订单数 计数（COUNT）0 人数 否 交易域/支付 pay_ord_amt GMV 订单支付成功金额 GMV，订单支付成功金额。订单类型包含：等待卖家发货

203、、等待买家确认收货、交易成功；订单支付状态包含付款成功。累加（SUM）4 元（人民币）否 交易域/支付 pay_itm_cnt pay item count 支付商品数 支付商品数 计数（COUNT）0 个 否 交易域/支付 pay_ord_pbt pay order pbt 客单价 订单支付成功金额/支付子订单数 求平均（AVG）4 元（人民币）否 产品实操：零售电商数据建模操作实践 160 交易域/支付 kpi_gmv_rate kpi_gmv_rate 成交金额完成度 成 交 金 额 目 标 值 为3000 万；成交金额目标完成度=成交金额实际完成值/成交金额目标值；率 4 小数 否 物

204、流域/揽件 lgt_lanshou_ord_cnt lgt_lanshou_ord_cnt 物流揽收订单数 物流揽收订单数 计数（COUNT）0 笔 否 物流域/接单 lgt_crt_ord_cnt lgt_crt_ord_cnt 物流接单订单数 物流接单订单数 计数（COUNT）0 笔 否 物流域/签收 lgt_sign_ord_cnt lgt_sign_ord_cnt 物流签收订单数 物流签收订单数 计数（COUNT）0 笔 否 物流域/物流域_默认 lgt_ord_cnt lgt_ord_cnt 物流订单总数 物流订单总数 累加（SUM）0 笔 否 信 用&风 控域/评价 remark_

205、ord_cnt remark order count 评价订单数 评价订单数 计数（COUNT）0 笔 否 信 用&风 控域/评价 remark_ord_rate remark order rate 评价订单占比 评价订单数/支付子订单数 率 4 小数 否 c)修饰词 新建 12 个修饰词，保存并提交，分别如下表；也可以下载 Excel 文件，使用 Excel导入。修饰词类型 英文缩写 英文名称 中文名称 业务口径 描述 数仓分层 普通业务修饰词 00s 00s 00 后 00 后 普通业务修饰词 90s 90s 90 后 90 后 普通业务修饰词 80s 80s 80 后 80 后 普通业务

206、修饰词 70s 70s 70 后 70 后 产品实操：零售电商数据建模操作实践 161 普通业务修饰词 men men 男性会员 男性会员 普通业务修饰词 women women 女性会员 女性会员 普通业务修饰词 act_tel act_tel 手机激活 手机激活 普通业务修饰词 act_email act_email 邮箱激活 邮箱激活 普通业务修饰词 exp exp 异常会员 异常会员 普通业务修饰词 high high 高级会员 高级会员 普通业务修饰词 mid mid 中级会员 中级会员 普通业务修饰词 low low 初级会员 初级会员 d)时间周期 使用默认配置。产品实操：零售电

207、商数据建模操作实践 162 e)派生指标 会员域下的派生指标 批量创建会员域/会员域_默认业务过程下的 13 个派生指标。原子指标：存量会员数 修饰词：上文修饰词列表中的所有一共 12 个，再加一个修饰词 system_empty（空）。批量选会合并成一个，所以这里需要一个一个选后添加 时间周期：std（历史截止当日）单个创建会员域/注册业务过程下的 1 个派生指标 时间周期*修饰词 原子指标*数仓分层*业务分类 业务过程*中文名称*英文名称 描述 Cm（自然月）new_mbr_cnt（注册会员数）公共层：汇总数据层 电商业务 会员域/注册 自然月_注册会员数（点击智能推荐）new_mbr_c

208、nt_cm（点击智能推荐）产品实操：零售电商数据建模操作实践 163 交易域下的派生指标 分两次批量创建交易域/支付业务过程下的派生指标，方法同上。第一批 原子指标：成交金额完成度、客单价、支付商品数、支付子订单数、订单支付成功金额 修饰词：system_empty（空）时间周期：1d（近 1 天）第二批 原子指标：成交金额完成度、订单支付成功金额 修饰词：system_empty（空）时间周期：fy（财年）物流域下的派生指标 单个创建物流域下的 4 个派生指标，分别如下。时间周期*修饰词 原子指标*数仓分层*业务分类 业务过程*中文名称*英文名称 描述 1d（近 1天）lgt_lanshou

209、_ord_cnt（物流揽收订单数）公共层：汇总数据层 电商业务 物流域/揽件 近 1 天_物流揽收订单数 lgt_lanshou_ord_cnt_1d 产品实操：零售电商数据建模操作实践 164 1d（近 1天）lgt_crt_ord_cnt（物流揽收订单数）公共层：汇总数据层 电商业务 物流域/接单 近 1 天_物流接单订单数 lgt_crt_ord_cnt_1d 1d（近 1天）lgt_sign_ord_cnt（物流揽收订单数）公共层：汇总数据层 电商业务 物流域/签收 近 1 天_物流签收订单数 lgt_sign_ord_cnt_1d 1d（近 1天）lgt_ord_cnt（物流揽收订单

210、数）公共层：汇总数据层 电商业务 物流域/物流域_默认 近 1 天_物流订单总数 lgt_ord_cnt_1d 信用&风控域下的派生指标 单个创建信用&风控域下的 3 个派生指标，分别如下。时间周期*修饰词 原子指标*数仓分层*业务分类 业务过程*中文名称*英文名称 描述 1d（近 1天）remark_ord_cnt（评价订单数）公共层：汇总数据层 电商业务 信用&风控域/评价 近 1 天_评价订单数 remark_ord_cnt_1d 1d（近 1天）remark_ord_rate（评价订单占比）公共层：汇总数据层 电商业务 信用&风控域/评价 近 1 天_评价订单占比 remark_ord

211、_rate_1d 1d（近 1天）00s（00后）remark_ord_cnt（评价订单数）公共层：汇总数据层 电商业务 信用&风控域/评价 近 1 天_00 后_评价订单数 remark_ord_cnt_1d_00s 5)维度建模（公共层汇总表模型和应用层应用表模型）a)公共层-汇总表模型 创建 6 张汇总表模型，分别如下。汇总表 1：dws_ec_mbr_cnt_std 历史截至当日存量会员数 cube 统计表 基本信息：产品实操：零售电商数据建模操作实践 165 数仓分层*业务分类 数据域*时间周期*修饰词 表名*表中文名*生命周期 描述 表类型*公共层：汇总数据层 电商业务 会 员 域

212、（mbr）Std（历史截止当日）dws_ec_mbr_cnt_std 历史截至当日存量会员数 cube 统计表 365 天 历史截至当日存 量 会 员 数cube 统计表 轻 度 汇总表 字段管理和分区字段管理：当前表使用快捷模式结合代码模式配置。快捷模式配置：step1：从指标导入。注 这里仅作为核心功能演示，实际当前表不需要导入，后续的汇总表中会使用到从指标导入的功能。产品实操：零售电商数据建模操作实践 166 step2：使用“代码模式”，将下文中的 MaxCompute DDL 语句复制进去，点击确定替换表内容。step3：可视化编辑关联粒度/指标，并按下图关联对应的统计粒度、原子指标

213、、派生指标，点击确定。最终得到如图表结构，保存。产品实操：零售电商数据建模操作实践 167 代码模式配置：-不支持修改表名 CREATE TABLE dws_ec_mbr_cnt_std(reg_prov_id STRING COMMENT 注册填写省 ID,reg_prov_name STRING COMMENT 注册填写省名称,reg_gender STRING COMMENT 身份证解析性别（F 女，M 男，unkown 表示身份证为空或格式不对）,reg_gender_name STRING COMMENT 身份证解析性别（F 女，M 男，unkown 表示身份证为空或格式不对）,ag

214、e_tag STRING COMMENT 出生年代,user_active_type STRING COMMENT 用户激活方式,user_active_name STRING COMMENT 激活方式名称,vip_level BIGINT COMMENT VIP 等级,vip_level_name STRING COMMENT VIP 等级名称。v1，v2，v3 等,mbr_cnt BIGINT COMMENT 存量会员数)COMMENT 历史截至当日_存量会员数_cube 统计表 PARTITIONED BY(ds STRING COMMENT 业务日期,yyyymmdd)LIFECYCL

215、E 365;-不支持修改表名 CREATE ADVANCED DWS TABLE dws_ec_mbr_cnt_std ALIAS 历史截至当日_存量会员数_cube 统计表 产品实操：零售电商数据建模操作实践 168(reg_prov_id ALIAS 注册填写省 ID STRING COMMENT 注册填写省 ID REFERENCES dim_ec_mbr_user_info.reg_prov_id,reg_prov_name ALIAS 注册填写省名称 STRING COMMENT 注册填写省名称,reg_gender ALIAS 身份证解析性别（F 女，M 男，unkown 表示身份

216、证为空或格式不对）STRING COMMENT 身份证解析性别（F 女，M 男，unkown 表示身份证为空或格式不对）REFERENCES dim_ec_mbr_user_info.reg_gender,reg_gender_name ALIAS 身份证解析性别（F 女，M 男，unkown 表示身份证为空或格式不对）STRING COMMENT 身份证解析性别（F 女，M 男，unkown 表示身份证为空或格式不对）,age_tag ALIAS 出生年代 STRING COMMENT 出生年代 REFERENCES dim_ec_mbr_user_info.id_age,user_acti

217、ve_type ALIAS 用户激活方式 STRING COMMENT 用户激活方式 REFERENCES dim_ec_mbr_user_info.user_active_type,user_active_name ALIAS 激活方式名称 STRING COMMENT 激活方式名称,vip_level ALIAS VIP 等级 BIGINT COMMENT VIP 等级 REFERENCES dim_ec_mbr_user_info.vip_level,vip_level_name ALIAS VIP 等级名称。v1，v2，v3 等 STRING COMMENT VIP 等级名称。v1，v

218、2，v3 等,mbr_cnt ALIAS 存量会员数 BIGINT COMMENT 存量会员数 WITH(atomic_indicator=mbr_cnt,time_period=std)COMMENT 历史截至当日_存量会员数_cube 统计表 PARTITIONED BY(ds ALIAS 业务日期,yyyymmdd STRING COMMENT 业务日期,yyyymmdd)WITH(life_cycle=365);汇总表 2：dws_ec_mbr_register_cm 近 1 自然月会员注册信息统计（可选）基本信息：数仓分层*业务分类 数据域*时间周期*修饰词 表名*表中文名*生命周期

219、 描述 表类型*公共层：汇总数据层 电商业务 会员域（mbr）Cm（自然月）dws_ec_mbr_register_cm 近 1 自然月会员注册信息统计 720 天 近 1 自然月会员注册信息统计 普 通 汇总表 字段管理和分区字段管理：产品实操：零售电商数据建模操作实践 169-不支持修改表名 CREATE DWS TABLE dws_ec_mbr_register_cm ALIAS 近 1 自然月_会员_注册信息统计 (reg_month ALIAS 注册月份 STRING COMMENT 注册月份,new_mbr_cnt_cm ALIAS 自然月_注册会员数 BIGINT COMMENT

220、 自然月_注册会员数 REFERENCES(INDDC100268E31)COMMENT 近 1 自然月_会员_注册信息统计 PARTITIONED BY(ds ALIAS 业务日期,yyyymmdd STRING COMMENT 业务日期,yyyymmdd)WITH(life_cycle=720);-不支持修改表名 CREATE DWS TABLE dws_ec_mbr_register_cm ALIAS 近 1 自然月_会员_注册信息统计 (reg_month ALIAS 注册月份 STRING COMMENT 注册月份,new_mbr_cnt_cm ALIAS 自然月_注册会员数 BIG

221、INT COMMENT 自然月_注册会员数 REFERENCES(new_mbr_cnt_cm)COMMENT 近 1 自然月_会员_注册信息统计 PARTITIONED BY(ds ALIAS 业务日期,yyyymmdd STRING COMMENT 业务日期,yyyymmdd)WITH(life_cycle=720);可视化编辑或查看关联粒度/指标信息：产品实操：零售电商数据建模操作实践 170 汇总表 3：dws_ec_trd_cate_commodity_gmv_kpi_fy 财年 KPI 类目品类_GMV统计 基本信息：数仓分层*业务分类 数据域*时间周期*修饰词 表名*表中文名*生

222、命周期 描述 表类型*公共层：汇总数据层 电商业务 交 易 域（trd）Fy（财年）dws_ec_trd_cate_commodity_gmv_kpi_fy 财年 KPI 类目品类_GMV 统计 365 天 财年 KPI_类 目 品 类GMV 统计 普 通 汇总表 字段管理和分区字段管理：-不支持修改表名 CREATE DWS TABLE dws_ec_trd_cate_commodity_gmv_kpi_fy ALIAS 财年 KPI_类目_品类_GMV 统计 (cate_id ALIAS 商品叶子类目 ID BIGINT COMMENT 商品叶子类目 ID,cate_name ALIAS

223、商品叶子类目名称 STRING COMMENT 商品叶子类目名称,commodity_id ALIAS 品类 ID BIGINT COMMENT 品类 ID,commodity_name ALIAS 品类名称 STRING COMMENT 品类名称,pay_ord_amt_fy ALIAS 财年_订单支付成功金额 DECIMAL COMMENT 财年_订单支付成功金额 REFERENCES(pay_ord_amt_fy),kpi_gmv_rate_fy ALIAS 财年_成交金额完成度 DECIMAL COMMENT 财年_成交金额完成度)COMMENT 财年 KPI_类目_品类_GMV 统计

224、 PARTITIONED BY(ds ALIAS 业务日期,yyyymmdd STRING COMMENT 业务日期,yyyymmdd)WITH(life_cycle=365);-不支持修改表名 CREATE TABLE dws_ec_trd_cate_commodity_gmv_kpi_fy(cate_id BIGINT COMMENT 商品叶子类目 ID,cate_name STRING COMMENT 商品叶子类目名称,commodity_id BIGINT COMMENT 品类 ID,commodity_name STRING COMMENT 品类名称,pay_ord_amt_fy D

225、ECIMAL COMMENT 财年_订单支付成功金额,kpi_gmv_rate_fy DECIMAL COMMENT 财年_成交金额完成度 产品实操：零售电商数据建模操作实践 171)COMMENT 财年 KPI_类目_品类_GMV 统计 PARTITIONED BY(ds STRING COMMENT 业务日期,yyyymmdd)LIFECYCLE 365;可视化查看或编辑关联粒度/指标：汇总表 4：dws_ec_trd_pay_cate_commodity_1d 近 1 天类目品类_交易支付指标汇总（可选）基本信息：数仓分层*业务分类 数据域*时间周期*修饰词 表名*表中文名*生命周期 描

226、述 表类型*汇总层：公共数据层 电商业务 交 易 域（trd）1d（近 1天）dws_ec_trd_pay_cate_commodity_1d 近1天类目品类_交易支付指标汇总 720 天 近1天_类目品类交易支付指标汇总 普 通 汇总表 字段管理和分区字段管理：-不支持修改表名 CREATE DWS TABLE dws_ec_trd_pay_cate_commodity_1d ALIAS 近 1 天_类目_品类_交易支付指标汇总 (stat_date ALIAS 统计日期 STRING COMMENT 统计日期,产品实操：零售电商数据建模操作实践 172 stat_month ALIAS 统

227、计月份 STRING COMMENT 统计月份,stat_year ALIAS 统计年份 STRING COMMENT 统计年份,cate_id ALIAS 商品叶子类目 ID BIGINT COMMENT 商品叶子类目 ID REFERENCES dim_ec_itm_item_info.cate_id,cate_name ALIAS 商品叶子类目名称 STRING COMMENT 商品叶子类目名称,commodity_id ALIAS 品类 ID BIGINT COMMENT 品类 ID REFERENCES dim_ec_itm_item_modity_id,commodity_name

228、 ALIAS 品类名称 STRING COMMENT 品类名称,pay_ord_cnt_1d ALIAS 近 1 天_支付子订单数 BIGINT COMMENT 近 1 天_支付子订单数 REFERENCES(pay_ord_cnt_1d),pay_itm_cnt_1d ALIAS 近 1 天_支付商品数 BIGINT COMMENT 近 1 天_支付商品数 REFERENCES(pay_itm_cnt_1d),pay_ord_amt_1d ALIAS 近 1 天_订单支付成功金额 DECIMAL COMMENT 近 1 天_订单支付成功金额 REFERENCES(pay_ord_amt_1d

229、),pay_ord_pbt_1d ALIAS 近 1 天_客单价 DECIMAL COMMENT 近 1 天_客单价 REFERENCES(pay_ord_pbt_1d)COMMENT 近 1 天_类目_品类_交易支付指标汇总 PARTITIONED BY(ds ALIAS 业务日期,yyyymmdd STRING COMMENT 业务日期,yyyymmdd)WITH(life_cycle=720);-不支持修改表名 CREATE TABLE dws_ec_trd_pay_cate_commodity_1d(stat_date STRING COMMENT 统计日期,stat_month ST

230、RING COMMENT 统计月份,stat_year STRING COMMENT 统计年份,cate_id BIGINT COMMENT 商品叶子类目 ID,cate_name STRING COMMENT 商品叶子类目名称,commodity_id BIGINT COMMENT 品类 ID,commodity_name STRING COMMENT 品类名称,pay_ord_cnt_1d BIGINT COMMENT 近 1 天_支付子订单数,pay_itm_cnt_1d BIGINT COMMENT 近 1 天_支付商品数,pay_ord_amt_1d DECIMAL COMMENT

231、近 1 天_订单支付成功金额,pay_ord_pbt_1d DECIMAL COMMENT 近 1 天_客单价)COMMENT 近 1 天_类目_品类_交易支付指标汇总 PARTITIONED BY 产品实操：零售电商数据建模操作实践 173(ds STRING COMMENT 业务日期,yyyymmdd)LIFECYCLE 720;可视化查看或编辑关联粒度/指标：汇总表 5：dws_ec_lgt_ord_overview_1d 近 1 天_物流订单概览指标汇总（可选）基本信息：数仓分层*业务分类 数据域*时间周期*修饰词 表名*表中文名*生命周期 描述 表类型*公共层：汇总数据层 电商业务

232、物 流 域（lgt）1d（近 1天）dws_ec_lgt_ord_overview_1d 近 1 天_物流订单概览指标汇总 365 天 近 1 天_物流订单概览指标汇总 普 通 汇总表 字段管理和分区字段管理：-不支持修改表名 CREATE DWS TABLE dws_ec_lgt_ord_overview_1d ALIAS 近 1 天_物流订单概览指标汇总 (stat_date ALIAS 统计日期 STRING COMMENT 统计日期,lgt_ord_cnt_1d ALIAS 近 1 天_物流订单总数 BIGINT MEASUREMENT COMMENT 近 1 天_物流订单总数 REF

233、ERENCES(lgt_ord_cnt_1d),产品实操：零售电商数据建模操作实践 174 lgt_crt_ord_cnt_1d ALIAS 近 1 天_物流接单订单数 BIGINT MEASUREMENT COMMENT 近 1 天_物流接单订单数 REFERENCES(lgt_crt_ord_cnt_1d),lgt_lanshou_ord_cnt_1d ALIAS 近 1 天_物流揽收订单数 BIGINT MEASUREMENT COMMENT 近 1 天_物流揽收订单数 REFERENCES(lgt_lanshou_ord_cnt_1d),lgt_sign_ord_cnt_1d ALIA

234、S 近 1 天_物流签收订单数 BIGINT MEASUREMENT COMMENT 近 1 天_物流签收订单数 REFERENCES(lgt_sign_ord_cnt_1d)COMMENT 近 1 天_物流订单概览指标汇总 PARTITIONED BY(ds ALIAS 业务日期,yyyymmdd STRING COMMENT 业务日期,yyyymmdd)WITH(life_cycle=365);-不支持修改表名 CREATE TABLE dws_ec_lgt_ord_overview_1d(stat_date STRING COMMENT 统计日期,lgt_ord_cnt_1d BIGIN

235、T COMMENT 近 1 天_物流订单总数,lgt_crt_ord_cnt_1d BIGINT COMMENT 近 1 天_物流接单订单数,lgt_lanshou_ord_cnt_1d BIGINT COMMENT 近 1 天_物流揽收订单数,lgt_sign_ord_cnt_1d BIGINT COMMENT 近 1 天_物流签收订单数)COMMENT 近 1 天_物流订单概览指标汇总 PARTITIONED BY(ds STRING COMMENT 业务日期,yyyymmdd)LIFECYCLE 365;可视化查看或编辑关联粒度/指标：产品实操：零售电商数据建模操作实践 175 汇总表

236、6：dws_ec_risk_remark_tag_1d 近 1 天_评价算法打标分类指标汇总表（可选）基本信息：数仓分层*业务分类 数据域*时间周期*修饰词 表名*表中文名*生命周期 描述 表类型*公共层：汇总数据层 电商业务 信 用&风 控 域（risk）1d（近 1天）dws_ec_risk_remark_tag_1d 近1天_评价算法打标分类指标汇总表 365 天 近 1 天_评价算法打标分类指标汇总表 普 通 汇总表 字段管理和分区字段管理：-不支持修改表名 CREATE DWS TABLE dws_ec_risk_remark_tag_1d ALIAS 近 1 天_评价算法打标分类指

237、标汇总表 (stat_date ALIAS 统计日期 STRING COMMENT 统计日期,remark_tag ALIAS 评价打标分类 STRING COMMENT 评价打标分类,cate_id ALIAS 商品叶子类目 ID BIGINT COMMENT 商品叶子类目 ID REFERENCES dim_ec_itm_cat.cate_id,cate_name ALIAS 商品叶子类目名称 STRING COMMENT 商品叶子类目名称,commodity_id ALIAS 品类 ID BIGINT COMMENT 品类 ID REFERENCES dim_ec_itm_item_mo

238、dity_name,commodity_name ALIAS 品类名称 STRING COMMENT 品类名称,remark_ord_cnt_1d ALIAS 近 1 天_评价订单数 BIGINT COMMENT 近 1 天_评价订单数 REFERENCES(remark_ord_cnt_1d)COMMENT 近 1 天_评价算法打标分类指标汇总表 PARTITIONED BY(ds ALIAS 业务日期,yyyymmdd STRING COMMENT 业务日期,yyyymmdd)WITH(life_cycle=365);-不支持修改表名 CREATE TABLE dws_ec_risk_re

239、mark_tag_1d(stat_date STRING COMMENT 统计日期,remark_tag STRING COMMENT 评价打标分类,产品实操：零售电商数据建模操作实践 176 cate_id BIGINT COMMENT 商品叶子类目 ID,cate_name STRING COMMENT 商品叶子类目名称,commodity_id BIGINT COMMENT 品类 ID,commodity_name STRING COMMENT 品类名称,remark_ord_cnt_1d BIGINT COMMENT 近 1 天_评价订单数)COMMENT 近 1 天_评价算法打标分类

240、指标汇总表 PARTITIONED BY(ds STRING COMMENT 业务日期,yyyymmdd)LIFECYCLE 365;可视化查看或编辑关联粒度/指标：b)应用层-应用表模型 创建 1 张应用表模型，如下。应用表 1：ads_ec_ec360_gmv_kpi_overview 电商 360KPI 概览 基本信息：产品实操：零售电商数据建模操作实践 177 数仓分层*集市/主题*时间周期*修饰词 表名*表中文名*生命周期 描述 表类型*应用层：应用数据层 电商 360 Fy（财年）、std（历史截止当日)ads_ec_ec360_gmv_kpi_overview 电商 360KPI

241、 概览 电商360KPI概览 普通应用表 字段管理和分区字段管理：-不支持修改表名 CREATE DWS TABLE ads_ec_ec360_gmv_kpi_overview ALIAS 电商 360KPI 概览 (pay_ord_amt_fy ALIAS pay_ord_amt_fy DECIMAL REFERENCES(pay_ord_amt_fy),mbr_cnt_std ALIAS mbr_cnt_std BIGINT REFERENCES(mbr_cnt_std),kpi_gmv_rate_fy ALIAS kpi_gmv_rate_fy DECIMAL REFERENCES(kp

242、i_gmv_rate_fy)COMMENT 电商 360KPI 概览 PARTITIONED BY(ds ALIAS 业务日期,yyyymmdd STRING COMMENT 业务日期,yyyymmdd);-不支持修改表名 CREATE TABLE ads_ec_ec360_gmv_kpi_overview(pay_ord_amt_fy DECIMAL,mbr_cnt_std BIGINT,kpi_gmv_rate_fy DECIMAL)COMMENT 电商 360KPI 概览 PARTITIONED BY 产品实操：零售电商数据建模操作实践 178(ds STRING COMMENT 业务日

243、期,yyyymmdd);可视化查看或编辑关联粒度/指标：6)逆向建模 上文中主要是讲解了正向建模，但是在实际生产中很多企业已经有了大量的MaxCompute 物理表，同时又希望在 DataWorks 智能数据建模产品统一管理所有模型，那么逆向建模功能就可以帮助企业快速将已创建的数据表生成规范的数仓模型。该功能无需您再次执行建模操作，即可快速将已有物理表反向建模至DataWorks 的维度建模中，节省了大量的时间成本。注：该步骤仅为核心功能展示，不操作不会影响后续实验。具体的逆向建模操作介绍请参见逆向建模官方文档。产品实操：零售电商数据建模操作实践 179 7)模型发布 确 认 模 型 无 误

244、后，将 其 中 的 维 度 表（dim_ec_itm_item_info、dim_ec_mbr_user_info）、汇总表（dws_ec_trd_cate_commodity_gmv_kpi_fy、dws_ec_mbr_cnt_std）、明 细 表（dwd_ec_trd_create_ord_di）、应 用 表（ads_ec_ec360_gmv_kpi_overview）发布至对应空间的开发环境和生产环境，后续实验中应用到这几张表。发布成功后可以前往数据地图查看表结构。设置项 说明 工作空间 这里会列出建模空间中配置的所有数据研发工作空间。本实验选择当前工作空间。引擎类型 支持 MaxCom

245、pute、E-MapReduce、Hologres 等多种引擎。本实验选择 MaCompute 引擎实例 根据需求将表物化至引擎类型参数中相应类型的数据存储引擎。生效环境 标准模式下，可选择发布至开发或生产环境。发布模式 增量发布：选择该模式，发布时仅会将目标模型此次变更的内容发布至对应引擎。删除重建：选择该模式，发布时会将对应引擎中之前已发布的该模型删除，删除后再重新创建此次发布的模型。附件 MaxCompute ODS 层 DDL 建表语句。产品实操：零售电商数据建模操作实践 180 注 主要为维度建模时快捷模式编辑字段“使用已有表/视图”功能使用，全部产品-数据开发-临时查询中创建 od

246、ps sql 节点中执行，如未执行，也可以在配置数据集成离线同步采集数据时，一键建表创建。CREATE TABLE IF NOT EXISTS ods_mbr_user_info(id BIGINT COMMENT 主键,gmt_create DATETIME COMMENT 创建时间,gmt_modified DATETIME COMMENT 修改时间,user_id BIGINT COMMENT 会员数字 ID,nick STRING COMMENT 会员 NICK。会员昵称,reg_fullname STRING COMMENT 个人认证表示真实姓名，企业认证表示企业名称,reg_mob

247、ile_phone STRING COMMENT 注册时绑定手机号码,reg_email STRING COMMENT 注册填写 EMAIL（用户可以修改）,reg_gender STRING COMMENT 注册填写性别（F 女，M 男，不是这两个就是未知的，说明性别保密）,reg_birthdate DATETIME COMMENT 注册填写生日（用户可以修改）,reg_address STRING COMMENT 注册填写地址（用户可以修改）,reg_nation_id STRING COMMENT 注册填写国家 ID（暂时为空）,reg_prov_id STRING COMMENT 注

248、册填写省 ID,reg_city_id STRING COMMENT 注册填写城市 ID,user_regip STRING COMMENT 注册 IP,id_card_type BIGINT COMMENT 会员认证证件类型 0：未知 1：身份证 2：企业营业执照号,id_card_number STRING COMMENT 个人认证表示身份证号，企业认证表示企业的营业执照号，没有认证不保证准确性,user_regdate DATETIME COMMENT 注册时间,user_active_type STRING COMMENT 用户激活方式，1 邮件;2 手机;,user_active_t

249、ime DATETIME COMMENT 激活时间,vip_level STRING COMMENT VIP 等级,is_delete STRING COMMENT 是否删除)COMMENT 会员信息源表 PARTITIONED BY(ds STRING COMMENT YYYYMMDD)LIFECYCLE 10000;产品实操：零售电商数据建模操作实践 181 CREATE TABLE IF NOT EXISTS ods_t_area(id BIGINT,pid BIGINT COMMENT 父级,name STRING COMMENT 名称,shortname STRING COMMENT

250、 简称,longitude STRING COMMENT 经度,latitude STRING COMMENT 纬度,level BIGINT COMMENT 级别,sort BIGINT COMMENT 排序)COMMENT 地区源表 PARTITIONED BY(ds STRING COMMENT YYYYMMDD)LIFECYCLE 30;CREATE TABLE IF NOT EXISTS ods_item_info(id BIGINT COMMENT 主键,gmt_create DATETIME COMMENT 创建时间,gmt_modified DATETIME COMMENT 修

251、改时间,item_id BIGINT COMMENT 商品数字 ID,title STRING COMMENT 商品标题,sub_title STRING COMMENT 商品子标题,pict_url STRING COMMENT 主图 URL,desc_path STRING COMMENT 商品描述的路径,item_status BIGINT COMMENT 商品状态 1：确认通过 0：未确认通过,last_online_time DATETIME COMMENT 最近一次开始销售时间，商品上架时间,last_offline_time DATETIME COMMENT 销售结束时间，表示一

252、个销售周期的结束，仅作用于拍卖商品,duration BIGINT COMMENT 有效期，销售周期，只有两个值，7天或 14 天,reserve_price DECIMAL(38,18)COMMENT 当前价格,secure_trade_ordinary_post_fee DECIMAL(38,18)COMMENT 平邮费用,secure_trade_fast_post_fee DECIMAL(38,18)COMMENT 快递费用,产品实操：零售电商数据建模操作实践 182 secure_trade_ems_post_fee DECIMAL(38,18)COMMENT EMS 邮费,last

253、_online_quantity BIGINT COMMENT 商品最近一次上架时的库存数量,features STRING COMMENT 商品特征,cate_id BIGINT COMMENT 商品叶子类目 ID,cate_name STRING COMMENT 商品叶子类目名称,commodity_id BIGINT COMMENT 品类 ID,commodity_name STRING COMMENT 品类名称,is_virtual STRING COMMENT 是否虚拟商品,shop_id BIGINT COMMENT 商家 ID,shop_nick STRING COMMENT 商

254、家 NICK,is_deleted BIGINT COMMENT 类目是否删除)PARTITIONED BY(ds STRING COMMENT YYYYMMDD)LIFECYCLE 30;CREATE TABLE IF NOT EXISTS ods_trade_order(id BIGINT COMMENT 主键,gmt_create DATETIME COMMENT 创建时间,gmt_modified DATETIME COMMENT 修改时间,sub_order_id BIGINT COMMENT 子订单 ID,parent_order_id BIGINT COMMENT 父订单 ID,

255、buyer_id BIGINT COMMENT 买家数字 id,buyer_nick STRING COMMENT 买家昵称,item_id BIGINT COMMENT 商品数字 id,item_price DECIMAL(38,18)COMMENT 商品价格 单位分,buy_amount BIGINT COMMENT 购买数量,biz_type BIGINT COMMENT 交易类型,memo STRING COMMENT 备注,pay_status BIGINT COMMENT 支付状态,logistics_status BIGINT COMMENT 物流状态,status BIGINT

256、 COMMENT 状态,seller_memo STRING COMMENT 卖家的给交易的备注,buyer_memo STRING COMMENT 买家给交易的备注,ip STRING COMMENT 买家 IP,end_time DATETIME COMMENT 交易结束时间,pay_time DATETIME COMMENT 付款的时间,is_sub BIGINT COMMENT 是否是子订单 1 表示子订单,产品实操：零售电商数据建模操作实践 183 is_parent BIGINT COMMENT 是否是父订单 1 表示父订单,shop_id BIGINT COMMENT 商家 id,total_fee DECIMAL(38,18)COMMENT 去除折扣和调整后的子订单费用)PARTITIONED BY(ds STRING COMMENT YYYYMMDD)LIFECYCLE 30;1 亚当森 Star Schema 完全参考手册，北京：清华大学出版社，2012 2 Ralph，Kimball，Margy，Ross，数据仓库工具箱（第 3 版），北京：清华大学出版社，2015 以上实验流程结束，如有其他使用问题，请加入 DataWorks 交流群：