案例介绍

案例场景简介

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

零售事业群的业务流程

零售事业群的业务流程，如下图所示。

零售事业群的架构

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

• 业务中台系统覆盖整个零售体系的会员（人）与商品/库存（货），并且集中处理订单与营销内容。
• 电商系统与门店系统分别对应线上零售与线下零售。
• 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. 拆分上述步骤中每个业务活动的参与对象和业务活动中的关键节点，下表仅列举了部分参与对象和关键节点。

      数据域	业务活动	参与对象	关键节点
      交易域	订单	消费者、门店、商品	下单、支付、关单 注意 线下订单下单、支付、关单在POS支付那一刻就全部完成。
      交易域	支付	消费者	创建（支付单）、支付、关单
      供应链域	采购	供应商、商品、仓库	确认采购单、预付、发货、收货、付尾款、关单
      供应链域	运输、调拨	仓库、商品、承运商、门店	确认调拨单、发运、收货、关单
      履约域	配送	仓库、商品、消费者	发货、收货、关单

   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	地址

   地址是一个公共域维度，其维度逻辑表为下表所示，仅列举了部分属性字段。

   属性字段	说明	来源字段	关联维度
   address_id	内部ID	dummy_retail_ods.s_address.id	无
   region_id	区域ID	dummy_retail_ods.s_address.region_id	区域
   province_id	省份ID	dummy_retail_ods.s_address.prov_id	省
   city_id	城市ID	dummy_retail_ods.s_address.city_id	城市
   district_id	区县ID	dummy_retail_ods.s_address.district_id	区县
   street	街道	dummy_retail_ods.s_address.street	无
   address_detail	详细地址	dummy_retail_ods.s_address.addr	无

6. 配置事实逻辑表
   给一个业务过程添加属性字段并设置字段的来源（对应某个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	无

   该事实逻辑表关联了消费者维度，消费者维度又关联了地址，地址关联了地域相关的多个维度。

定义指标

下文以消费者运营团队统计最近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