作者：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