DataWorks数据建模 - 一揽子数据模型管理解决方案

作者：DataWorks产品经理 刘天鸢

在当下的商业环境中，正确的数据治理策略对于数据增值是非常重要的。据统计，企业的数据一直都在以每年50%的速度增长，因此企业数据治理与整合的难度就不断加大了。

DataWorks一直以来都致力于成为用户更方便、更快捷地进行数据开发与数据治理的好帮手。此次发布的数据建模，是对已有数据治理领域能力的补齐，为用户带来了在数据开发前，实施事前治理的能力。

一、为什么要数据建模

引用《大数据之路：阿里巴巴大数据实践》中的内容：“如果把数据看作图书馆里的书，我们希望它们在书架上分门别类地放置；如果把数据看作城市的建筑，我们希望城市规划布局合理；如果把数据看作电脑文件和文件夹，我们希望按照自己的习惯有很好的文件夹组织方式，而不是糟糕混乱的桌面，经常为找一个文件而不知所措”。

从这几句话可以得出结论，规范合理的组织是必不可少的，只有规范合理的组织才能避免事物和现象的交叉出现，最终构成错综复杂的难题，存储在计算引擎中的数据模型（即数据表）也不例外。

（一）传统模型管理常见问题

从常见的数据中台和数据治理项目规划来看，在业务与需求梳理完成之后，模型设计是避不开的流程。经验来看，中台构建和数仓构建项目中的表平均有1000-5000张，甚至存在几十万或上百万的案例。因此，给上千张表画一张设计图，或是关系网络图就十分重要了。那么该怎么画，用什么工具画呢？

（二）原始的模型管理方式

现在大多数企业都是通过Excel来画这张图，在众多项目的实施过程中，模型都是记录在Excel上的。在模型比较少的时候，这个方式确实是轻量化并且容易实施的选择，但是当企业的数据业务飞速发展，达到成百上千规模的时候，这样的管理方式效率会很低。企业的数据模型可能和业务一样，增长、变更都非常快，数据人员根本无暇顾及维护、修改Excel中的内容，即便能腾出时间和精力来做这件事情，可操作性也非常低，并且很可能出现人为性错误。一旦管理者需要从全局的视角来审视整个数据体系的全貌时，得到的将会是没有时效性，错误率极高的信息。

（三）难以落地数据标准

在大多数情况下，如果缺少强有力可操作性强的标准工具，则本该在实际数据产出前的引标落标阶段就直接被跳过了，企业落地数据标准非常难。大多数企业都秉承着先开发后治理的思路去构建自己的数据体系，直接导致了后续数据不可用的后果。

企业如果没有明确数据标准，那么开发人员之间对业务的理解就会有差异，就会构建出不同定义、不同口径的数据模型，结果就是会引起数据产出后的质量问题，导致许多预期的需求实现不了。并且数据团队需要花费更多的时间和精力来修复这些脏数据。企业数据的质量问题，大多数都是因为数据缺乏标准，或是标准落地不彻底造成的。

关于数据治理，特别是事前治理，困扰企业的主要两个点：

• 第一，缺乏统一的视图来管理模型，企业的数据模型分散在各个不同的引擎里，每个引擎里的数据模型具体长什么样，业务人员无法实时感知。
• 第二，数据项目没有办法有效落标引起数据生产的质量问题，导致很多数据需求实施不了。

二、DataWorks数据建模介绍

根据各大网站和各家著作的阐释，数据模型是数据组织和存储的方法，是数据特征的抽象，强调从业务、数据存取和使用的角度合理存取数据。如果没有数据模型，那利益相关者很难看到现有数据库的结构、理解关键的概念。

数据模型包括概念模型、逻辑模型和物理模型。

概念模型是企业梳理业务流程得出来的，用来描述重要实体间的关系。比如企业有多个部门，每个部门有很多员工，每个员工有不同的薪资，概念模型就可以通过部门、员工、薪资这三个实体来表示各个实体间的关系。

逻辑模型是对概念模型的进一步细化，确定每个实体的属性和描述。比如员工模型中包含了姓名、身份证号、性别和生日等多个属性。

物理模型是面向引擎的模型，是基于物理特性考虑各种具体技术实现因素的模型，是只能存放在引擎中的。

DataWorks数据建模同时支持关系（ER、3NF）建模和维度建模（星型，雪花）。不同类型的模型没有最好，只有更适合。

关系建模就是ER或3NF建模，是站在全企业角度而不是业务分析角度对企业内众多的实体进行抽象，设计一套符合3NF的模型，用实体加关系的形式来描述企业的业务架构。这种方法规范性很好，基本没有冗余，适合大型企业战略性规划，缺点是不利于对接BI和下钻。并且物理模型设计通常与业务所需的模型设计不匹配，后期项目实施的周期会拖得非常长，成本也非常高，同时对建模人员的能力要求也同样很高。

维度建模主要以分析决策需求为出发点来构建模型。一般有比较好的大规模复杂查询的响应性能，能够直接面向业务。典型的代表就是众所周知的星型模型和在一些特殊场景下适用的雪花模型。维度建模相对快速上手、快速交付，但难以跨业务板块进行查询，同时有大量辅助表和垃圾表，容易产生表爆炸问题，后续维护成本高。

用户应该从企业的实际场景出发选择建模方式。根据经验总结，大多数企业都会同时存在以上两种建模方式，底层模型用关系建模，力求做到数据精简，往上维度建模就更适合，靠数据冗余带来可用性、分析性和可操作性。

DataWorks数据建模是一个开放灵活的工具，用户可以自由选择建模理论来规划与设计模型。引用Linux创始人关于描述什么才是优秀程序员的话来说，差程序员关心的是代码，好程序员关心的是数据结构和他们之间的关系，同样的道理也能迁移到数据模

型的重要性来，只有依照对企业业务流程场景的理解，将数据模型有序的组织和存储起来，大数据才能得到高性能、低成本、高效率和高质量的使用。

（一）数据模型常规的生命周期

首先，不论什么项目，在项目开始之前都要进行业务调研和需求分析。业务调研是为了更好的理解公司业务。比如，各个业务领域和业务线的业务有什么共同点和不同点？公司各个业务线可以细分为哪几个业务模块？每个业务模块的具体流程是怎么样的？这些信息非常重要，会直接决定数据仓库的建设成败。

需求调研需要从实际的工作场景入手。比如分析师和运营人员每天都要看什么报表？公司正在构建中的推荐业务系统的KPI是怎么样的？这个推荐系统需要基于什么样的数据才能达到KPI？

第二，是概要设计阶段。这个阶段要从高维度对企业业务过程中的各个实体关系进行梳理和描述，也就是对维表和事实表进行图形化的描述。

第三，是确定每个维度的属性和每个事实表的度量。确定属性和维度应该怎么样填入上一步的概要模型中。

第四，编码阶段，是将物理模型转化为DDL语句的过程。

第五，是将转换完成的DDL语句下发到开发环境来验证是否符合模型的设计规范。测试通过后，就可以将模型发布上线，服务于整个企业的数据体系。

第六，运行维护阶段是长久持续进行的。在这个阶段，模型已经成为一张在引擎中实实在在的表。为了及时发现非预期的从其他渠道对引擎进行的修改，需要对模型库与引擎中的模型差异进行定期的检查和修复验证。

（二）业内数据建模工具的基本能力

为了比较好的管理数据模型的生命周期，目前市面上普遍存在的模型管理工具都提供了下面的几个能力。

首先是概念模型与物理模型的设计能力，一般会支持以可视化的方式，来创建概念模型，构建逻辑模型以及物理模型

其次是版本控制能力，支持用户管理历史版本，在必要的时候回滚模型。

第三是模型导入导出能力，支持将模型的各类文件，导入到模型工具中，同时也支持将模型工具中的模型导出为数据库脚本，进而在数据库中创建已经规划好的模型。

（三）基于DataWorks数据建模（DataBlau DDM）的建模流程

首先，对线下已经存在模型的企业，可以通过模型文件（比如PD、ERWin文件）直接导入到客户端，或通过反向工程能力将大数据引擎里的模型直接导入到客户端里。

其次，在设计阶段，用户可以通过客户端或网页版客户端工具对模型进行进一步的规划与设计，通过标准引用的方式来完成模型的建设。

第三，开发测试阶段，模型设计完成后，可以将模型提交至开发环境进行测试，同时用户也能对历史版本进行分支管理，以便随时回滚到历史版本。

最后，模型测试完毕，再次经过相关人员的评审就可以发布到线上生产环境，并开始服务企业数据业务了。

案例

百花电影在线（Baihua）是一个虚构的在线电影网站，目前在MaxCompute 数据库中维护其销售数据。

该公司最近决定在整个企业中实施数据中台战略，以提高商业智能并获得更可靠的业务决策助力。数据团队有按需开发的宽表集市的经验，IT 团队和技术专家警告他们执行和维护整个数据中台所需的专业人才和资金，业界也已经广为流传数据中台翻车传闻。为了建立快速而可以有效复用，高质量的中台模型， 百花决定使用 Datablau Data

Modeler 来设计、开发、部署和维护他们的数据中台模型。让我们来看看我们为他们构建数据模型所遵循的过程。

1. 规划：模型分层

百花的现状是，严格来说是没有数仓概念的：没有分层，没有主题域，也没有规范。数据团队人数不多，面对数据需求，数据分析人员开始需求分析、指标拆解、字典选取、宽表建立、报表开发等一条龙作业，最终形成了宽表各种版本混乱，临时表和结果表不清，维度混乱等后续问题，同时由于团队成员感觉成为了取数机器和SQL Boy，学习不到新东西，逐渐出现人员流失，代码逐渐难以维护，数据质量问题频出，。。。总之，出现了难以为继的苗头。

吸取教训，本次中台的规划做了调研工作，大数据平台选用MaxCompute，数据标准，指标，维度，数据规范，命名规范，数据质量等都做了规划，虽然尚无太多内容，但随后项目过程中来不断丰富和遵循。

为了避免“宽表一时爽”的问题，规划方案对数据模型做了分层，使用DDM

Mapping对映射逻辑做了管理，提高系统的可维护性和质量。

ODS（原始数据层）：ODS层是数据仓库准备区，为DWD层提供基础原始数据。命名方面，不管是表命名还是字段命名尽量和业务系统保持一致，但是需要通过额外的标识来区分增量和全量表，”_delta”来标识该表为增量表。

DW（数据仓库），对于部分表进行冗余加工：

• DWD（明细数据层）：和ODS粒度一致的明细数据，对数据进行去重，脏数据过滤，空处理，保证数据质量。
• DWS（服务数据层）：轻度汇总数据及建宽表(按主题)存放数据。
• DIM（公共维度层）：轻度汇总数据及建宽表(按主题)存放数据。
• TMP（临时数据层）：轻度汇总数据及建宽表(按主题)存放数据。
• DM（应用集市层）：存放应用类的宽表数据和给报表分析类的指标结果集。

层间表名的命名规则：

数据 分层	系统 名称	系统 简写	Schema database	表角色	名称
ODS	办公系统	oa	dam	拉链增量inc	o_oa_dam_表名_inc
DWD	参与人	ip			wd_ip_表名_db
DWS	参与人	ip			ws_ip_表名_db
DWDIM	参与人	ip			wdim_ip_表名_db
DWTMP	项目名称	ip			wt_ip_表名_db
DM	项目名称	rp			dm_rp_表名_db

2. 业务需求：统计年度区域客户数

客户运营部门需要统计以往年度哪些区域的客户注册数和年龄分布情况，以便在广告投放方面进行倾斜。

分析需求主要是需要年度的订单数据，统计区域维度的用户数；并按照客户的年龄分布作为维度，进行二次统计。

这个需求并不复杂，我们分析数据源头主要需要销售数据库Baihua_Sale的数据，同时需要区域和客户年龄段的画像数据。

3. 步骤 1：创建源数据模型（ODS）

使用 Datablau Data Modeler 构建数据中台模型的第一步是识别和建模源数据。我们需要创建一个数据模型项目，使用数据模型工具栏上的【逆向数据库】图标对

Baihua_Sale的销售数据库进行【逆向工程】。

这是我们对 Baihua_Sale 的数据源进行逆向工程后的样子：

注意：此模型中的实体框都对应来自 Baihua_Sale数据源的表。

通过检查模型，我们发现模型中实体的字典缺失比较严重（这也是企业数据治理工作缺位的表象之一），数据之间的关系当然也是缺失的，如何在这些分散的数据表中，找到我们分析索要的数据呢？

当然我们的方法是对源系统数据进行建模，构建业务系统的数据模型，这可以让我们快速的了解业务，准确的分析业务需求。

第一步，我们进行数据字典的补全，这是治愈的第一步，虽然这个库的物理命名还算标准，我猜你遇到的情况比我还要差。通过访问源系统开发团队，收集到缺失的数据字典，我们整理为DDM的Excel数据字典格式，进行导入，运气非常好，我们补全了

90%的数据。对于缺失的10%，我们给原系统开发团队发送了求助邮件，他们都非常好，很快给我进行了反馈，同时告知了此系统的业务模块，完成数据字典补全。

第二步，对此模型进行了业务主题建模，建设了三个主题：

产品数据(Product)，整理了产品相关的主数据和参考数据以及数据之间的业务关系。

客户数据(Customer)，整理了客户相关的主数据和参考数据，以及数据之间的业务关系。

购买交易(Business)，整理了相关客户在线订购和租赁的交易数据，这是本项目的交易事实表来源。

（主题域逻辑模型）

我们已成功创建、验证和部署 Baihua_Sale的源数据模型。

4. 步骤 2：构建通用维度模型（DWD）

该过程的下一步是设计一个维度模型，该模型将用作 Baihua_Sale 数据中台模型的通用公共模型。您可以使用数据模型工具箱中提供的Entity实体界面从头开始设计模型。

根据需求，我们将订单表和支付表合并为订单事实表；将客户和电影表进行了适度的冗余，地址表也进行了冗余，最终设计出这个星形维度模型。

通过右键单击实体，将鼠标悬停在上下文菜单中的实体类型上，然后从给定选项中选择适当的类型，您可以方便地将类型更改为事实或维度。

根据分析需求，在订单表中，根据订单日期衍生了字段“年”，客户表根据客户身份证，衍生了星座，这个标签用户分析星座对订单的影响。

4.1 建立映射表

打开数据映射管理器。

Step1. 新建数据映射。

Step2：模型库中选择目标表，这里默认是进入的时候的Film表。

Step3：源端模型，在模型库中选择ODS侧的模型，选择与Film相关的关联表。

Step4：工具跟进模型实体之间的关系，构建的连接实体和关联字段；也可以手工进行调整；

Step5：目标字段映射，工具根据名称自动进行映射，不能映射的空余项，需要在编辑器手工进行映射。

Step6：生成SQL语句和映射对应关系图。

可以预览和导出SQL语句。

依据上述步骤，对其他四个DWD的表建立映射关系。

5. 步骤 3：客户偏好分析（ADS）

该过程的下一步是设计一个分析维度模型，该模型将用作客户偏好分析的目标模型。

根据需求，我们将城市，星座，年度三个属性作为维度字段，将客户数和金额数作为度量指标。构建了这个区域客户分析的宽表。

通过右键单击实体，将鼠标悬停在上下文菜单中的字段类型上，然后从给定选项中选择适当的类型，您可以方便地将类型更改为度量或维度。

5.1 建立映射表

按照4.1方法，建立映射关系，如下图所示：

对于维度实体，布局生成器中的维度角色列提供了完整的选项列表。这些包括以下内容：

• 代理键和业务键。
• 缓慢变化的维度类型（SCD1、SCD2、SCD3 和 SCD6）。
• 记录标识符（生效和到期日期、当前记录指示符和版本号）以跟踪历史数据。
• 占位符维度以跟踪迟到和早到的事实和维度。

现在维度模型已准备就绪，我们将对其进行验证和部署以供进一步使用。

6. 步骤 4：部署数据模型

在这一步中，我们将通过设计 ETL 管道将相关源数据加载到每个表中来填充Baihua_Sale的数据中台模型。在 Datablau Data Modeler 中，您可以在Mapping设计器产生DML SQL语句，包括从ODS到DWD的SQL语句，从DWD到ADS的SQL语句，存储为两个文件。

将新的SQL语句导入的ETL调度工具，进行数据的分布加载和运行。

最后，通过调度工具内置的 Job Scheduler 自动执行刷新这些数据的过程。在

Scheduler选项卡中，您可以创建一个新计划，以给定调度频率自动执行调度过程。在这种情况下，我们已安排每天刷新销售数据。

7. 最后：可视化和分析

通过BI工具有效地分析他们的销售数据并从中获得有价值的业务洞察力。

（四）DataWorks智能数据建模（维度建模）

DataWorks智能数据建模模块，涵盖数仓规划、数据标准、数据建模、数据指标四个方面的能力，能够加速数仓设计与维度建模，提升数据中台的规范化和标准化，一站式完成数仓设计与开发。

数仓规划

数仓设计的基础规划包括数据分层、业务分类、数据域、业务过程。

• 数据分层：提供业界通用的五层数据分层（ODS、DIM、DWD、DWS、ADS），并支持用户自新增和修改，支持表名检查器功能。
• 业务分类：支持多级业务分类自定义能力，可根据企业业务状况进行划分。
• 数据域：业务过程的集合，可以结合企业业务划分设计，方便业务快速筛选数据。如交易域、商品域、物流域等。
• 业务过程：一个个不可拆分的行为类、存量分析类、特殊的自定义类业务过程，如加购、收藏、评价等；

数据建模

DataWorks提供了可视化维度建模工具，支持多种大数据引擎的正向和逆向辅助建模工作，不仅支持将工具中已经设计好的模型直接下发至引擎，而且可以将引擎中已经存在的模型提取到工具中进行再编辑、再下发，提供一站式的管理、建模、发布能力，告别传统工具手工导入导出的繁琐操作。在模型落标监控方面，支持对已经落到引擎中的模型进行基线检查，帮助用户轻松发现表结构与物理模型结构的不一致，以便及时修正。DataWorks在提供专业的本地客户端的同时也提供了在线轻量化网页版本客户端，方便用户在不同工作场景下进行选择。

• 管理：对模型支持从数据域视角和业务分类视角进行管理及查找，清晰易用。
• 建模：支持三建模方式，Excel、可视化建模、脚本建模，满足多种建模偏好。
• 发布：无需二次开发，支持一键发布到MaxCompute、Emr、Hologres等引擎的生产或开发环境

数据标准

数据标准是数据模型和指标标准化的基础保障，能够提供统一的规范约束，保障数据定义和使用的一致性、准确性和完整性。DataWorks数据标准模块支持对数据字典、标准代码、度量单位等进行自定义，不仅支持企业管理者定义属于自己的数据标准，同时支持数据建模人员在构建模型时引用这些标准，以解决不同建模人员对数据理解不一致而导致口径不一致的问题。

• 数据字典：定义字段的类型、取值范围、度量单位、标准代码等约束内容，可在数据建模中表的字段定义时进行引用。
• 标准代码：设置某一数据标准可选择的数据的枚举值内容。主要在数据字典中引用，定义字段的取值约束。
• 度量单位：字段参数的数量单位（如个、元、米等）。可在指标定义和数据建模中表的字段定义时进行引用。

数据指标

数据指标包括原子指标、修饰词、时间周期、派生指标、汇总表。DataWorks支持原子指标、派生指标的设计与定义，确保业务口径统一。通过汇总表收敛，自动生成指标查询代码，实现业务聚合及管理

• 原子指标：某一业务过程或活动下不可再拆分的基本度量，用于明确业务的统计口径和计算逻辑，统计业务状况的数值。
• 修饰词：表示统计的业务范围，是对统计指标的业务限定。
• 时间周期：表示统计的时间范围，是对统计指标的时间限定。
• 派生指标：由原子指标、时间周期、修饰词构成，用于反映某一业务活动在指定时间周期及目标范围中的业务状况。
• 汇总表：用于组织数据域下相同时间周期、相同维度的多个派生指标，形成业务聚合逻辑，为后续的业务查询、OLAP分析、数据分发等提供基础。

DataWorks建模能力与DataWorks开发体系完美结合，支持将模型的发布与DataWorks开发流程进行关联，可以规范化模型设计到模型发布上线的流程。

三、DataWorks开发、治理模式的演变

（一）宏观演变

在接入数据建模之前，数据会通过离线或实时的方式同步到大数据引擎里。然后开始数据的生产、开发、调度，并定时产出数据。最后，数据会回流到某些数据库或者OLAP引擎里，提供查询或直接通过数据服务API构建一个API直接服务于业务。

而DataWorks所有数据治理相关领域的功能也都是贯穿在这三个主要流程中的。包括数据上云时的源头数据写入的检查、数据生产时对数据质量和产出时效性的检测以及使用数据的权限控制。DataWorks已经为用户提供了完善的数据治理能力。这些治理能力更多是着眼于事中和事后的治理。

新发布的数据建模模块又新增了定义数据形态这个主要的使用流程，目的是为用户补全事前治理能力，同时带来一站式的模型管理解决方案。在这个步骤中，用户可以基于对企业业务流程的理解和需求调研，进行企业业务标准和规范的定义。并且在建模时基于数据标准，进行引标、落标、生成表结构，实现模型的统一管理，让事前治理落到实处。

对已经在提供服务的引擎中的模型来说，也可以通过逆向建模方式将模型加载到数据建模的模块中，做统一的修正完善后再提交回引擎。整个流程都是遵守DataWorks所定义的开发流程规范的。

（二）微观演变

从微观来看，DataWorks支持基于决策体系的授权模式，允许不同职位的人扮演不同的角色。每个人各司其职，以共同完成安全、规范的数据开发流程。

在DataWorks标准模式空间下，开发人员在开发环境会先完成代码的开发、提交和冒烟测试。测试无误后再找熟悉业务的第三方或第三人，比如说运维、部署或管理员，审核提交的代码。如果确认提交的代码不会影响业务系统的稳定性，并且符合业务预期，就可以发布到生产环境，开始周期调度运行。

在发布数据建模后，DataWorks又新增模型设计师角色。被授予该角色的人可以登陆DataWorks数据建模的模块，专门负责模型的开发。

首先由数据管理团队主管，也就是空间管理员角色先定义数据标准。其次，由数据建模人员进行模型设计，同时利用数据主管所定义的标准来引标和落标，创建表结构和表的每个字段，形成可下发到引擎的物理模型。

然后，由开发人员负责将物理模型转化为DDL语句并且提交至开发环境的引擎。最后由运维、部署或管理员角色，对下发到引擎的DDL语句审核，无误后批准发布到生产环境。

至此，一个最基本并且相对专业规范的模型已经完成设计并且落地了。当然，旧的开发流程仍然是可以复用的。不同的是，数据表的创建、修改等管理工作将会以更加严谨的方式来实施了。

最后，大家可以参考我们的数据建模公开课：https://developer.aliyun.com/article/782517

DataWorks官网：https://www.aliyun.com/product/bigdata/ide

大数据&AI体验馆：https://workbench.data.aliyun.com/experience.htm