阿里-数据中台建设流程

https://help.aliyun.com/document_detail/317789.html

本案例以某公司的零售事业群为例，为您介绍在构建数据中台时，如何规划业务模型中的业务板块、项目、数据域和指标等，帮助您更好的理解Dataphin的核心概念。

案例场景简介

某公司是一家横跨多个行业领域的大型企业，以零售商超起家，逐步发展到理财金融、地产等领域。其组织架构如下图，有三个独立的事业群，每个事业群都是经营责任制，财务上独立核算。该集团近来积极推进业务数字化，准备使用Dataphin来构建数据中台，选择零售事业群作为项目一期。

零售事业群的业务流程

零售事业群的业务流程，如下图所示。
零售事业群的业务行态分两大块，线上自营电商和线下商超，所涉及的主要业务流程有：

1. 供货商的采购、运输、仓储。
2. 消费者的下单、支付购买商品。
3. 线上销售与门店销售中的大件货物需要履约配送。
4. 线上与门店的营销活动，例如线上大促、 线下打折等活动。
5. 售后服务，例如退换货、投诉等。

   零售事业群的架构

   零售事业群的现有零售架构如下图。

• 业务中台系统覆盖整个零售体系的会员（人）与商品/库存（货），并且集中处理订单与营销内容。
• 电商系统与门店系统分别对应线上零售与线下零售。
• ERP系统主要是用于供应链管理。

  规划数仓

1. 规划业务板块。

   某公司实行的是事业部制，各事业部之间业务独立，关联极少，主要体现在以下几方面：因此，基于以上因素及业务板块的划分原则，某公司可以建立三个独立的业务板块：

   • 事业部之间不共享资源，人员独立、办公场地独立等。即从Dataphin的实施角度来看，事业部之间不存在共同的业务对象（业务参与人或物）。
   • 事业部之间不存在业务流程的流转。零售事业群的某个作业流程（如采购、销售）与金融事业部完全无关。
   • 零售板块
   • 金融板块
   • 地产板块
2. 规划项目。零售事业群可以作为一个项目，也可以分为多个项目归属到一个业务板块。为了管理维护方便（计算与存储资源分配）， 本案例中规划了三对项目（每对项目包括开发项目和生产项目）：
   • ODS层项目（dummy_retail_ods_dev和dummy_retail_ods），用于存放从各个业务系统每天同步过来的原始数据.
   • CDM层项目（dummy_retail_cdm_dev和dummy_retail_cdm）, 用于存放企业内通用，且经常被很多业务场景使用的数据。
   • ADS层项目（dummy_retail_ads_dev和dummy_retail_ads），面向业务场景。

3. 划分数据域。基于数据域的划分原则，零售事业群的数据域划分详情如下：

   数据域即主题域，用于存放同一业务板块内不同意义的指标。一个业务板块会划分出多个数据域，一个数据域只能归属于一个业务。 划分数据域的规则如下：

   • 一个数据域代表一种业务含义。例如，商品域、交易域。
   • 针对某个业务场景或业务职能的数据放到同一个数据域。例如，零售行业中采购、仓储、配送、都是属于供应链物流范畴，应该划分在同一个数据域。
   • 通常根据业务应用系统来划分。 例如，零售行业内业务系统的订单处理是一个独立系统，有独立的产研团队；客户管理系统是另一个独立系统，也有独立产研团队，那么就可以分别设置订单数据域和客户数据域。

   例如，零售业务板块下，您可以划分出商品域、交易域和会员域三个数据域，用于存放不同意义的指标。

   • 会员（消费者）域
   • 商品域
   • 门店域
   • 交易域
   • 供应链域
   • 履约域
   • 营销域
   • 服务域
   • 流量域
   • 公共域

4. 确定维度与业务过程。您可以按照以下步骤，梳理维度和业务过程：

   1. 列举出业务活动，下表仅列举了部分业务活动。 | 数据域 | 业务活动 | | —- | —- | | 交易域 | 订单、支付 | | 供应链域 | 采购、运输、仓储（入库、上架、拣选、出库、盘点等） | | 履约域 | 接单、配送 |

   2. 拆分上述步骤中每个业务活动的参与对象和业务活动中的关键节点，下表仅列举了部分参与对象和关键节点。 | 数据域 | 业务活动 | 参与对象 | 关键节点 | | —- | —- | —- | —- | | 交易域 | 订单 | 消费者、门店、商品 | 下单、支付、关单 | | 交易域 | 支付 | 消费者 | 创建（支付单）、支付、关单 | | 供应链域 | 采购 | 供应商、商品、仓库 | 确认采购单、预付、发货、收货、付尾款、关单 | | 供应链域 | 运输、调拨 | 仓库、商品、承运商、门店 | 确认调拨单、发运、收货、关单 | | 履约域 | 配送 | 仓库、商品、消费者 | 发货、收货、关单 |

   3. 确定维度及其所在的数据域。根据上一步的拆分，将各个业务活动的参与对象集合起来，去除重复后得到的就是维度。另外，维度本身的一些属性也是重要的分析角度，也需要设置为维度。确定了维度后，按照以下原则确定维度的归属数据域：基于以上原则，确定的维度及维度归属的数据域如下表所示，下表仅列举了部分维度及归属数据域。

      • 有公共性的对象（即参与了多个数据域业务活动的对象），通常都设置了独立的数据域，如消费者域。
      • 只参与某一个数据域的业务活动的对象归属在所在数据域。
      • 维度的属性延展出来的维度，与本维度在同一个数据域。 | 数据域 | 维度 | | —- | —- | | 消费者域 | 消费者、性别、年龄层、职业等 | | 商品域 | 商品、类目 | | 门店域 | 门店 | | 供应链域 | 供应商、仓库、承运商 |

   4. 确定业务过程通常，业务分析只需要关注业务活动的关键节点，这些关键节点可以设置为业务过程（如果后面业务需要，可以将其他节点也设置为业务过程） 。 | 数据域 | 业务过程 | | —- | —- | | 交易域 | 下单、支付、关单；创建（支付单）、支付、支付关单 | | 供应链域 | 确认采购单、预付、发货、收货、付尾款、采购关单确认调拨单、发运、收货、调拨关单 | | 履约域 | 发货、收货、关单 |

5. 配置维度逻辑表给一个维度添加属性字段并设置字段的来源（对应某个ODS层物理表的字段或字段计算逻辑），设置其关联维度后就可以得到维度逻辑表。下表为消费者维度逻辑表，仅列举了部分属性字段。地址是一个公共域维度，其维度逻辑表为下表所示，仅列举了部分属性字段。 | 属性字段 | 说明 | 来源字段 | 关联维度 | | —- | —- | —- | —- | | customer_id | 客户ID | dummy_retail_ods.s_customer.id | 无 | | customer_name | 消费者名称 | dummy_retail_ods.s_customer.name | 无 | | reg_date | 注册日期 | dummy_retail_ods.s_customer.reg_date | 无 | | gender | 性别 | dummy_retail_ods.s_customer.gender | 性别 | | address_id | 消费者注册地址 | dummy_retail_ods.s_customer.address_id | 地址 |

1. 配置事实逻辑表给一个业务过程添加属性字段并设置字段的来源（对应某个ODS层物理表的字段或字段计算逻辑），设置其关联维度后就可以得到事实逻辑表。下表为下单的事实逻辑表，仅列举了部分属性字段。该事实逻辑表关联了消费者维度，消费者维度又关联了地址，地址关联了地域相关的多个维度。 | 属性字段 | 说明 | 来源字段 | 关联维度 | | —- | —- | —- | —- | | order_id | 订单ID | dummy_retail_ods.s_order.id | 无 | | order_time | 下单时间 | dummy_retail_ods.s_order.gmt_create | 无 | | customer_id | 消费者（买家）ID | dummy_retail_ods.s_order.buyer_id | 消费者 | | order_site | 订单来源平台 | dummy_retail_ods.s_order.order_source | 平台类型（枚举） | | store_id | 门店ID | dummy_retail_ods.s_order.store_id | 门店 | | amount | 订单金额 | dummy_retail_ods.s_order.amount | 无 |

注意 线下订单下单、支付、关单在POS支付那一刻就全部完成。

定义指标

下文以消费者运营团队统计最近30天内每个消费者线上下单金额为例，为您介绍如何定义其中的指标。
按照传统SQL研发方式，您可以使用以下代码，统计最近30天内每个消费者线上下单金额。

—假设今天是 2021/10/01 select customer_id ,sum(amount) as order_amt_30d from fct_crt_ord_di where ds >= ‘20210901’ and ds <= ‘20210930’ and order_site = 1 group by customer_id
根据上述代码为您介绍如何定义统计周期、统计粒度、统计时效、原子指标、业务限定和派生指标：

• 统计周期统计周期用于约束指标的来源数据的时间跨度，即该指标的统计周期为最近30天，也就是指定了该指标的来源数据是最近30天内创建的订单。
• 统计粒度统计粒度是分析维度，即Group By后需要聚合的维度，该指标的统计粒度就是消费者维度。
• 统计时效最近30天这个统计周期是以天为统计粒度的，因此该指标的统计时效是天。
• 原子指标下单金额是该指标的原子指标，其计算逻辑为sum(amount)。下单金额是最基础、且不可拆分的事件。从SQL角度来看，下单金额sum(amount)是一个简单的聚合表达式。
• 业务限定统计周期约束了来源数据的时间跨度，其他过滤条件则进一步筛选出进入统计的数据，这些过滤条件即业务限定。该指标统计的线上订单为业务限定，其计算逻辑为order_site=1。
• 派生指标最近30天每个消费者的线上下单金额，就是派生指标。