qData 数据中台专业版 v3.0：数据建模核心能力解析与系统实操原创

现在我们看到的就是QD的3.0全新设计的数据建模模块。由于首先进入的是建模概览页面，这个页面主要用于展示企业当前的数据模型建设情况，包括整体建设成果、规范化建模流程以及模型发布后的应用情况。在页面的上方可以看到当前平台数据建模的统计信息，这里汇总了数据板块、主题域、概念模型、逻辑模型、指标模型、已发布模型。的数量，同时还展示相关的变化情况。通过这些信息我们可以快速的了解企业目前已经完成了多少业务规划，建设了多少数据模型，以及有多少模型以及完成了发布。那么接下来我们重点看一下中间的建模规划主流程，整个流程主要分为五个环节，首先通过业务规划处理企业的业务对象及其关系，然后通过数仓分层建立统一的数据仓库建设规范，在此基础上开展逻辑模型的设计，进一步通过指标与标准管理统一业务。

统计口径的字段定义，最后通过模型发布将设计成果落地到数据库，那么这几个环节共同构成了一套从业务规划到模型发布的规范化建设流程，那么除了模型本身的建设，我们还需要关注这些模型建好之后能够发挥什么作用。那么在右侧可以看到数据建模的成果，可以为数据集成、数据开发、数据治理、数据资产和数据服务等模块提供支持。例如数据开发可以参考已经定义好的模型结构和字段信息开展数据加工，数据治理可以结合数据治理，可以结合模型中的标准定义进行规范管理，而模型发布之后还会自动注册为数据资产，方便后续的统一检索和管理。那么在页面的底。

还可以查看不同数仓分层的模型分布模型发布的物理表的分布情况以及最新的建模操作动态。通过这些信息，我们就能从整体上了解企业的数据模型建设情况。接下来我们按照实际的功能模块逐步看一下具体如何开展数据建模。那么我们首先看一下数仓分层。在企业建设数仓数据仓库的过程中，会涉及原始数据、业务明细、统计汇总以及应用数据等不同类型的数据，如果把这些数据全部都放在一起，不仅难以区分用途，后续的数据开发和维护也会变得越来越复杂。因此，在正式开展模型建设之前，我们需要先建立统一的数仓分层规范。

那么在QT中，我们已经预先配置好了5个常用的数仓的等级，数仓的层级分别是ODSDMDMDDWS和ADS。Dim, 那么ods是操作数据层，主要用于承接业务系统的原始数据，保留原系统的数据结构，那么D'M层是维度层，用于管理客户、商品、地区等公共维度信息，那么DWD是明细数据层，用于组织订单、交易等具体的业务过程的明细数据，DWS是汇总的数据层，主要面向业务分析，需要提供统一的统计汇总数据。

最后是ADS应用层，用于组织报表数据分析和其他业务应用所需要的一些数据。那么例如在电商订单分析场景下，原始订单数据可以放在ods层，那么客户、商品等维度的信息放在了DMDM层，订单交易明细则放在DWD层，订单量和销售额等汇总结果放在DWS层。最后通过ADS层组织面向具体的业务应用的数据，这样不同用途的数据就有了明确的归属。那么在页面的下方，我们可以看到每一个数仓分层级的基本信息，以及该层级下面已经建设好的逻辑模型的数量平台支持对逻辑模型的分层的。名称、说明、负责人以及表明的前缀等信息进行统一的管理。例如，我们可以以明细数一层，配置统一的表前缀。

后续创建属于这一层的逻辑模型时，就可以按照对应的命名规范进行管理，那么同时呢，我们还可以直接进入到某一个数仓分层的详情页，查看该层级已经建设好的一些逻辑模型。通过数仓分层，我们能够。建立统一的模型分类和管理规范，避免不同项目按照各自的习惯随意建设数据表。接下来让我们再来看一下业务规划。了解如何确定这些数据模型具体属于哪些业务，以及涉及到哪些业务对象。那么前面我们已经建立好了数仓分层。但只有分层还是不够的，因为数仓分层解决的是数据应该如何去组织。而在真正设计模型之前，我们还需要先弄清企业有哪些业务，涉及哪些业务对象，以及这些对象之间存在怎么样的关系。因此在Q带的3.0中，我们提供了完整的业务规划能力，主要包括数据板块、主题域和业务实体和概念模型。那么首先我们就先看一下数据板块。数据板块呢，主要是用于划分企业较大的业务范围，比如在电商管理系统里面，可以按照业务特点划分电商的。

零售、供应链管理、财务管理等不同的数据板块，那么这样后续在建设数据模型的时候，就可以按照业务规范。进行统一的组织和管理。那么在QT中每一个数据板块可以去设置它的板块的名称、英文名称、图标、板块的架构师、联系人等这些基本信息，那么板块的架构师、业务负责人以及数据负责人等信息明确了数据建设的管理职责。那么除此之外，我们的数据板块还有一个比较重要的功能就是逻辑表命名规范。那么在这里我们可以统一配置不同数仓分层的逻辑表命名规范，比如ods层DMD wdd ws ADS对应的表进行前缀，还可以根据按照天、小时、分钟等不同的时间力度配置表明后缀，那这样后续在这个数据板块下面所创建的逻辑模型的时候，就可以根据提前设置好的规范规则生成推荐的表明，不需要每一个开发人员自行。

制定命名方式。那么我们完成数据板块划分之后，就需要进一步的梳理每一个板块下面的业务主题，那么这里就需要用到我们的主题域，例如我们在电商的零售这一个板块下，可以按照业务特点划分。

履约域、交易域、商品域、客户域等不同的主题域。其中对于交易域主要管理订单、支付、退款等相关的业务，那么在K中我们的主题域最多支持5层主题域，可以根据业务需要继续细分。如果在交易域下进一步的划分订单管理、支付管理等子主题域，每一个主题都可以设置它的。主题域的名称、主题域编码、英文缩写、负责人等相关的信息。那么主题域的编码会参与后续逻辑表的命名规则，通过这种分级的管理方式，后续创建的业务实体和逻辑模型就能够关联到具体的业务主题，方便统一的分类和查找。那么有了数据板块和主题域之后，接下来我们就要进一步梳理每一个主题下面具体有哪些业务对象，以及发生了哪些业务活动。那么在Q中，我们将业务实体分为了两大类，分别是业务对象和业务活动。

那么其中业务对象呢？主要描述企业需要管理的人、事、物，如客户、商品、门店，另一层是业务活动，主要描述企业在业务过程中发生的行为和事件，可以分为业务事件和业务流程。例如下单、支付和退款都属于具体的业务事件，而订单交易、订一履约则属于由多个事件组成的业务流程，那么在这里面呢？我们以这一个客户为对客户的业务对象为例。那么在定义。

业务实体的时候，我们不仅可以管理实体的名称和业务归属，还可以进一步定义它的业务属性和相关信息，为后续的逻辑模型设计提供依据。而且两类业务实体并不是只用于业务分类，他们还可以直接关联到后续的。逻辑建模。例如客户、商品等业务对象可以用于创建维度逻辑表，而下单、支付等业务活动则可以用于创建事实逻辑表，这也是本次重构的一个重点。我们希望将前面的业务规划和后面的模型设计真正的关联在一起，而不是形成两道独立的信息。那么业务定义完成之后，还需要进一步的梳理他们之间的关系，例如一个订单属于哪个客户，一个订单交易流程包含哪些业务事件以及。

以及不同业务流程之间有什么先后关系。在Q中，我们可以通过概念模型将这些业务实体及其关系以可视化的图谱的形式展示出来。当前概念模型主要支持5种关系类型，分别是继承关系、关联关系，包含关系前续、后续和流转关系。那么，比如订单与客户之间可以建立关联关系，注册会员与普通会员之间可以建立继承关系，订单交易流程与下单支付事件之间可以建立包含关系，订单交易和订单履约两个流程之间可以建立前续、后续关系。而在同一个订单履约流程内部，还可以通过流转关系描述发货、运输、签收等事件的执行顺序，这些关系会根据业务实际的不同类型进行配置。通过图谱，我们可以直观的了解一个业务对象关联了哪些对象，参与了哪些业务活动，以及业务流程是如何衔接的。

参与。相比单纯通过表格和文档描述，这种可视化的。方式能够让业务人员和数据开发人员更加容易的理解企业的业务结构，那么到这里我们就完成了整个业务规划的过程，从数据板块明确业务规范，到主题域去规去划分业务主题，再到我们的业务实体和概念模型梳理里面具体的一些业务。接下来我们就进入整个数据建模最核心的部分，逻辑模型的设计。那么前面已经完成了业务规划，明确了企业有哪些业务对象和业务活动，也建立了统一的收仓分层规范，接下来就可以根据实际的业务需求设计对应的数据模型。那么在K带的3.0中，我们提供了五类逻辑模型，分别是天元逻辑表、维度逻辑表、事实逻辑表、汇总逻辑表和ADS应用表。这五类模型对应着从原系统数据接入、公共维度管理、业务明细建设到统计汇总和业务应用的不同环节。首先我们看一下天元逻辑表，那么天元逻辑表主要用于统一管理原系统的数据结构，属于ods操作数据层。企业通常有多个业务系统，比如ERPCRM、订单系统等，不同的系统可能会有多个业务系统。

那么为了方便后续的数据建设，我们可以通过天元逻辑表将这些原系统里面的结构纳入到统一的管理中，那么我们在创建天源逻辑表的时候，我们可以选择来源系统。

数据连接以及对应的原物理表。平台会根据原表的字段结构建立对应的天元逻辑表，并按照ods的命名规则生成推荐表明。同时天然逻辑表还会保留表级和字段级之间的关系。那么如果来源系统的表结构发生了变化，那么我们可以通过结构同步的功能更新模型定义。这里需要说明一下，信源逻辑表的主要作用是保留和规范原数据结构，并不负责业务数据的主重新加工，所以它不需要绑定前面规划的数据板块、主题域和业务实体。那么接下来我们看一下维度逻辑表。维度逻辑表主要用于统一管理客户、商品、地区等业务对象，属于DIM维度层。例如在实际业务中，客户的基本信息、会员等级和所在地区可能分别。

存储在不同的业务系统中，如果每次做数据分析都重新整理这些信息，不仅开发工作重复，也容易出现数据定义不一致的问题，因此，我们可以通过维度逻辑表统一设计客户和数据结构，供后续不同分析场景使用。那么，在创建。维度逻辑表的时候，首先我们需要写选择前序的。业务对象。我们已经规划好的业务对象，这里面直接可以看到我们之前规划好的普通对象和层级对象。选择业务对象之后呢？平台会根据关联业务对象关联相关对应的业务归属的信息，并结合预先配置好的命名规范，自动生成推荐表明。完成基本信息配置之后呢，就可以进到下一步。

的字段设计，那么在字段字段设计中，我们可以手动添加，也可以通过从逻辑表引入，还可以通过SQL解析，同时可以配置我们的组件、关联维度以及对应的数据标准等信息。那么对于业务对象中已经定义的组件和关联实体平台还能够自动的生成相应的字段，减少重复的配置。通过这样的方式，我们就把前面的业务规划中定义的业务对象真正转化为了具体的数据模型。那么前面我们介绍维度逻辑表主要回答的是客户、商品等业务对象是什么，而事实逻辑表要解决的则是业务过程中具体发生了什么。比如在订单业务中会发生下单、支付、退款等业务活动，这些活动都会产生订单编号、发生时间、交易金额等相关数据。

我们可以通过事实逻辑表对这些业务数据进行统一的建设和管理。事实逻辑表属于DWD明细数据层，在建设过程中需要关联前面的业务规划中已经定义好的业务活动。包括业务事件和业务流程。例如我们可以选择这个客户下单这张表，那么选择关联完成后，平台可以根据业务活动生成相对应的组组件。关联对象的ID以及业务时间，如果选择的是业务流程，还可以记录流程开始时间、结束时间以及包含的业务时间、发生时间，那么在事实逻辑表中，字段呢，主要分为。

主件属性度量和事件时间，那么第一类是主件的字段，例如订单标号，用来标唯一的标识一条业务记录。第二是。属性字段，那么比如客户编号、商品编号，用于前面关联建设的维度逻辑表。那么第三个是度量字段，比如订单金额、购买数量和优惠金额，用于记录具体的业务数值，第四一个是时间字段，比如下单时间和支付时间，用于记录业务活动发生的时间。我们还可以为字段配置关联维度。和数据标准等信息。通过事实逻辑表，企业就能够按照统一的业务定义来。设计明细数据结构，也为后续的指标计算和数据汇总提供基础。那么有了维度逻辑表和事实逻辑表之后，接下来就可以进一步组织统计汇总数据。那么例如订单事实表记录的就是每一笔订单的明细信息，但在实际的业务分析中，我们可能更关注每个有多少订单，每个地区的销售金额是多少。如果每个报表都重新基于明细数据进行统计，就容易出现重复开发和统计口径不一致的问题。因此Q代的提供了汇总逻辑表，基于DWS汇总数据层，那么在创建汇总逻辑表的时候，可以根据业务分析的需要设计统计时效。

统计力度以及需要使用到的一些指标。例如，我们想统计每天各个地区的订单数量和销售金额，就可以选择对应的统计时效和地区维度，并关联相关的派生指标。平台可以根据统计时效和统计力度生成相对应的字段，并匹配符合条件的派生指标，形成汇总逻辑表的字段结构。这样后续不同的报表或者是分析应用需要使用相同的统计结果时，就可以复用已经设计好的汇总模型，不需要重新定义一套统计结构。那么最后我们来看一下ADS应用表。前面的介绍的维度表、事实表和汇总表主要用于组织企业的公共公共数据模型，但不同的业务应用对数据的要求可能并不相同，比如销售。

案板可能需要订单数量、销售金额和地区排名等字段，而退款分析则需要退款笔数、退款金额、商品名称等信息。因此，我们可以通过ADS应用表根据实际的业务应用需要组织对应的数据结构。

那么最后看ADS应用表，那么我们前面介绍的维度表、实时表和汇总表主要用于组织企业的公共数据模型，但不同业务应用对数据的要求可能并不相同，比如销售看板可能需要订单数量、销售金额和地区排名等字段，而退款分析则需要退款笔数、退款金额、商品名称等信息。因此我们可以通过ATS应用表根据实际的业务场景需要对组织。进行数据结构。

在创建应用表的时候，我们可以选择数据板块、主题域。具体应用的场景，并通过手动添加引用派生指标，或者是代码表引入，或者是SQL解析去获取解析设计字段，这样我们就可以在前面已经有了模型和指标的基础上，进一步的组织面向报表、大屏和数据服务等场景的数据模型。那么通过前面的演示，我们可以看到Q带的5类逻辑模型分别承担不同的职责，天元逻辑表用于管理原系统数据结构，维度逻辑表用于管理业务对象，事实逻辑表用于管理业务明细，汇总逻辑表用于组织统计、汇总数据，而ADS应用表则面向具体的业务。应用。虽然这些模型的用途不同，但都可以在平台中统一的管理模型信息，字段结构、数据类型、业务归属以及相关的标准，并查看对应的模型详情和版本信息。需要注意的是，当前完成的逻辑模型设计，也就是定义数据应该如何组织，并不代表数据已经完成了同步和加工，后续还需要通过模型发布和数据研发的能力，将这些模型设计真正的落地到数据库中。不括在发布之前，我们要先再看一下指标模型了解如何。

让这些数据模型进一步的形成统一的业务统计口径。那么在指业务，那么在企业开展数据分析的时候，经常会遇到同一个指标统计的结果不一致，比如同样是统计订单数，有的部门统计全部订单，有的部门只统计已支付的订单，还有的部门只统计APP渠道订单。虽然都叫订单数，但由于统计条件不同，最终的结果也会存在差异。那么针对这样的问题，科的提供了统一的指标建设能力。

主要包括原子指标、业务限定和派生指标。那么我们首先看一下原子指标，原则指标主要用于定义最基础的业务统计，例如订单数、支付金额、退款金额等。那么在课中，我们可以基于维度逻辑表或者是事实逻辑表创建原子指标，选择对应的计算字段，聚合方式以及统计是，嗯。以及统计时间字段，明确指标的数据来源和计算规则。例如，我们需要定义订单数这个指标，就可以选择前面建设的订单事实逻辑表，以订单编号作为计算字段选择。相对应的聚合方式统计去重后的订单数量。如果需要统计支付金额，就可以选择对应的支付实时表，对支付金额字段进行项目求和。这样订单数、支付金额等基础指标就有了统一的定义，后续可以在不同的业务场景、业务分析场景中重复使用。那么有了原子指标之后，还需要进一步明确统计范围。例如，同样是订单数，我们可能只要统计已经支付的订单，或者是只统计APP渠道的一些订单。

那么在这里，我们就可以基于维度逻辑表或者是事实逻辑表，配置具体的业务筛选条件。比如，已经支付的订单可以配置支付状态，等于。配IDAPP渠道订单可以配置订单渠道等于APP平台除了基础限定，还支持组合限定，可以将多个条件组合起来，例如形成APP渠道已支付的订单这样的一个业务的限定。通过这种方式，我们就可以将常用的业务筛选条件统一定义后续。

创建指标就可以直接的去引用，避免重复的编写，那么接下来我们看一下派生指标。在实际业务分析中，我们通常不会只看一个基础指标，还需要结合具体的业务范围和统计周期，比如我们想统计近7天APP渠道已经支付的订单数量，那么对于这样的一个需求。我们就需要把前面定义的原子指标和业务限定都统组合起来。首先我们就需要去选择订单数这一个原子指标，在选择APP渠道已经支付的订单这一个业务限定，在设置及近期天的统计周期，形成一个具体的派生指标。那么创建过程中，平台还会校验原子指标和业务限定的来源是否一致，统计时效是否匹配，以及来源模型能否关联到所需要的统计维度。那么完成定义之后，派生指标还可以根据统计力度和数据时效与对应的DWS汇总逻辑表进行匹配。这样我们就可以通过原子指标、业务限定和统计周期的灵活组合，满足不同场景下的指标统计需求，同时保证基础设计规则的一致性。那么除了指标统计口径之外，数据。

字段本身也需要统一规范，比如相同的都是客户编号，在不同的业务系统中可能存在不同的字段的名称、数据类型和长度要求。科大的通过数据标准和标准数据源对字段名称、业务含义、数据类型等信息进行了统一的。管理后续在设计维度逻辑表、事实逻辑表等模型时，就可以引用已有的标准数据源，减少不同模型之间的字段定义之间的差异。那么到这里我们就完成了从逻辑模型到指标口径再到字段标准的统一管理。那么接下来我们看一下如何把已经设计好的逻辑模型正式发布到数据库里面。

那么前面我们已经完成了业务规划逻辑模型和指标模型的设计，但是目前这些逻辑模型仍然是设计阶段，要让这些他们真正的应用到后续的数据开发过程，还需要完成模型发布。那么在K中我们提供了这样的能力，可以将设计完成的逻辑模型发布到指定的数据库里面，生成对应的物理表。那么首先在我们的模型发布页面里面可以统一的查看不同类型的逻辑表。同时，我们可以按照模型的类型归属的。业务归属以及发布状态等信息进行查询，了解哪些模型已经发布，哪些模型还没有发布，那么我们这里选择一张已经设计好的模型表，那么我们就可以去点发布平台提供的发布模式有删除重建和增量发布，可以根据实际的场情况去进行选择，那么其中删除重建主要用于重新创建目标物理表结构，而增量发布则用于在适用的。

结构变更场景下对已经发布的物理表进行调整，那么这里需要注意发布模式的选择，应。结合目标表是否已经存在？以及表结构变化可能造成的影响进行判断。那么除此之外，平台也支持批量发布。方便对多个逻辑表进行统一的发布操作，发布成功之后呢，那么平台就会在目标数据库中生成对应的物理表，那么在逻辑模型发布完成之后，我们可以看一下。

在详情中可以看到当前这一张逻辑表的属性字段以及发布日志。发布日志里面包含模型编码、模型名称、连接类型、发布的模式、执行的状态。那么还可以看到具体的一些详细信息，那么模型发布完成之后，还有一个非常重要的动作，就是对应的物理表会自动的注册成为数据资产。接下来我们就进入资产地图，看一下模型发布之后的成果，那么我们现在进入到刚刚发布的数据资产模块下的资产地图。刚才发布成功的逻辑模型除了在目标数据库生成物理表之外，还会自动注册成为资产。那么在这里我们可以按照数据板块、主题域、数仓、分层等不同的分类方式，查找已经纳入资产体系的数据表。

打开之后可以查看对应的数据、资产信息以及关联的。数据资产信息，那么数仓分层和业务归属等信息，这样前面完成的模型设计成果就不只是保留在建模中，而是进一步沉到沉淀到了数据资产体系里面。另外，对于企业已经存在的数据库表现大的也支持通过资产注册的方式纳入统一的管理，并补充模型的类型。数仓分层。数据板块和主题域等业务信息，也就是说无论是新建设的数据模型，还是企业已经有了历史数据表，都可以逐步的纳入统一的数据资产管理体系中。那么以上就是我们Q带的数据中台3.0。

的全部的功能。通过刚才的介绍我们可以看到，整个数据建模已经形成了一套从业务规划到数仓分层模型、模型指标定义到模型发布还有资产注册的完整建设流程。通过统一业务对象模型规范结构，统一指标口径，并将建模成果与物理表和数据资产打通，帮助企业从过去分散的数据表开发逐步走向规范化、体系化的数据建模建设。这也是Q盖的3.0本次数据建模重构希望实现的核心目标。以上就是本次数据建模的功能简讲解，谢谢大家。