案例介紹
本案例以某公司的零售事業(yè)群為例,為您介紹在構(gòu)建數(shù)據(jù)中臺時,如何規(guī)劃業(yè)務(wù)模型中的業(yè)務(wù)板塊、項目、數(shù)據(jù)域和指標等,幫助您更好的理解Dataphin的核心概念。
案例場景簡介
某公司是一家橫跨多個行業(yè)領(lǐng)域的大型企業(yè),以零售商超起家,逐步發(fā)展到理財金融、地產(chǎn)等領(lǐng)域。其組織架構(gòu)如下圖,有三個獨立的事業(yè)群,每個事業(yè)群都是經(jīng)營責任制,財務(wù)上獨立核算。該集團近來積極推進業(yè)務(wù)數(shù)字化,準備使用Dataphin來構(gòu)建數(shù)據(jù)中臺,選擇零售事業(yè)群作為項目一期。
零售事業(yè)群的業(yè)務(wù)流程
零售事業(yè)群的業(yè)務(wù)流程,如下圖所示。
零售事業(yè)群的業(yè)務(wù)形態(tài)分兩大塊,線上自營電商和線下商超,所涉及的主要業(yè)務(wù)流程有:
供貨商的采購、運輸、倉儲。
消費者的下單、支付購買商品。
線上銷售與門店銷售中的大件貨物需要履約配送。
線上與門店的營銷活動,例如線上大促、 線下打折等活動。
售后服務(wù),例如退換貨、投訴等。
零售事業(yè)群的架構(gòu)
零售事業(yè)群的現(xiàn)有零售架構(gòu)如下圖。
業(yè)務(wù)中臺系統(tǒng)覆蓋整個零售體系的會員(人)與商品/庫存(貨),并且集中處理訂單與營銷內(nèi)容。
電商系統(tǒng)與門店系統(tǒng)分別對應(yīng)線上零售與線下零售。
ERP系統(tǒng)主要是用于供應(yīng)鏈管理。
規(guī)劃數(shù)倉
規(guī)劃業(yè)務(wù)板塊。
某公司實行的是事業(yè)部制,各事業(yè)部之間業(yè)務(wù)獨立,關(guān)聯(lián)極少,主要體現(xiàn)在以下幾方面:
事業(yè)部之間不共享資源,人員獨立、辦公場地獨立等。即從Dataphin的實施角度來看,事業(yè)部之間不存在共同的業(yè)務(wù)對象(業(yè)務(wù)參與人或物)。
事業(yè)部之間不存在業(yè)務(wù)流程的流轉(zhuǎn)。零售事業(yè)群的某個作業(yè)流程(如采購、銷售)與金融事業(yè)部完全無關(guān)。
因此,基于以上因素及數(shù)據(jù)板塊的劃分原則,某公司可以建立三個獨立的業(yè)務(wù)板塊:
零售板塊
金融板塊
地產(chǎn)板塊
規(guī)劃項目。
零售事業(yè)群可以作為一個項目,也可以分為多個項目歸屬到一個業(yè)務(wù)板塊。為了管理維護方便(計算與存儲資源分配), 本案例中規(guī)劃了三對項目(每對項目包括開發(fā)項目和生產(chǎn)項目):
ODS層項目(dummy_retail_ods_dev和dummy_retail_ods),用于存放從各個業(yè)務(wù)系統(tǒng)每天同步過來的原始數(shù)據(jù).
CDM層項目(dummy_retail_cdm_dev和dummy_retail_cdm), 用于存放企業(yè)內(nèi)通用,且經(jīng)常被很多業(yè)務(wù)場景使用的數(shù)據(jù)。
ADS層項目(dummy_retail_ads_dev和dummy_retail_ads),面向業(yè)務(wù)場景。
劃分數(shù)據(jù)域。
基于主題域的劃分原則,零售事業(yè)群的數(shù)據(jù)域劃分詳情如下:
會員(消費者)域
商品域
門店域
交易域
供應(yīng)鏈域
履約域
營銷域
服務(wù)域
流量域
公共域
確定維度與業(yè)務(wù)過程。
您可以按照以下步驟,梳理維度和業(yè)務(wù)過程:
列舉出業(yè)務(wù)活動,下表僅列舉了部分業(yè)務(wù)活動。
數(shù)據(jù)域
業(yè)務(wù)活動
交易域
訂單、支付
供應(yīng)鏈域
采購、運輸、倉儲(入庫、上架、揀選、出庫、盤點等)
履約域
接單、配送
拆分上述步驟中每個業(yè)務(wù)活動的參與對象和業(yè)務(wù)活動中的關(guān)鍵節(jié)點,下表僅列舉了部分參與對象和關(guān)鍵節(jié)點。
數(shù)據(jù)域
業(yè)務(wù)活動
參與對象
關(guān)鍵節(jié)點
交易域
訂單
消費者、門店、商品
下單、支付、關(guān)單
重要線下訂單下單、支付、關(guān)單在POS支付那一刻就全部完成。
交易域
支付
消費者
創(chuàng)建(支付單)、支付、關(guān)單
供應(yīng)鏈域
采購
供應(yīng)商、商品、倉庫
確認采購單、預(yù)付、發(fā)貨、收貨、付尾款、關(guān)單
供應(yīng)鏈域
運輸、調(diào)撥
倉庫、商品、承運商、門店
確認調(diào)撥單、發(fā)運、收貨、關(guān)單
履約域
配送
倉庫、商品、消費者
發(fā)貨、收貨、關(guān)單
確定維度及其所在的數(shù)據(jù)域。
根據(jù)上一步的拆分,將各個業(yè)務(wù)活動的參與對象集合起來,去除重復后得到的就是維度。另外,維度本身的一些屬性也是重要的分析角度,也需要設(shè)置為維度。確定了維度后,按照以下原則確定維度的歸屬數(shù)據(jù)域:
有公共性的對象(即參與了多個數(shù)據(jù)域業(yè)務(wù)活動的對象),通常都設(shè)置了獨立的數(shù)據(jù)域,如消費者域。
只參與某一個數(shù)據(jù)域的業(yè)務(wù)活動的對象歸屬在所在數(shù)據(jù)域。
維度的屬性延展出來的維度,與本維度在同一個數(shù)據(jù)域。
基于以上原則,確定的維度及維度歸屬的數(shù)據(jù)域如下表所示,下表僅列舉了部分維度及歸屬數(shù)據(jù)域。
數(shù)據(jù)域
維度
消費者域
消費者、性別、年齡層、職業(yè)等
商品域
商品、類目
門店域
門店
供應(yīng)鏈域
供應(yīng)商、倉庫、承運商
確定業(yè)務(wù)過程
通常,業(yè)務(wù)分析只需要關(guān)注業(yè)務(wù)活動的關(guān)鍵節(jié)點,這些關(guān)鍵節(jié)點可以設(shè)置為業(yè)務(wù)過程(如果后面業(yè)務(wù)需要,可以將其他節(jié)點也設(shè)置為業(yè)務(wù)過程) 。
數(shù)據(jù)域
業(yè)務(wù)過程
交易域
下單、支付、關(guān)單;創(chuàng)建(支付單)、支付、支付關(guān)單
供應(yīng)鏈域
確認采購單、預(yù)付、發(fā)貨、收貨、付尾款、采購關(guān)單確認調(diào)撥單、發(fā)運、收貨、調(diào)撥關(guān)單
履約域
發(fā)貨、收貨、關(guān)單
配置維度邏輯表
給一個維度添加屬性字段并設(shè)置字段的來源(對應(yīng)某個ODS層物理表的字段或字段計算邏輯),設(shè)置其關(guān)聯(lián)維度后就可以得到維度邏輯表。下表為消費者維度邏輯表,僅列舉了部分屬性字段。
屬性字段
說明
來源字段
關(guān)聯(lián)維度
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
地址
地址是一個公共域維度,其維度邏輯表為下表所示,僅列舉了部分屬性字段。
屬性字段
說明
來源字段
關(guān)聯(lián)維度
address_id
內(nèi)部ID
dummy_retail_ods.s_address.id
無
region_id
區(qū)域ID
dummy_retail_ods.s_address.region_id
區(qū)域
province_id
省份ID
dummy_retail_ods.s_address.prov_id
省
city_id
城市ID
dummy_retail_ods.s_address.city_id
城市
district_id
區(qū)縣ID
dummy_retail_ods.s_address.district_id
區(qū)縣
street
街道
dummy_retail_ods.s_address.street
無
address_detail
詳細地址
dummy_retail_ods.s_address.addr
無
配置事實邏輯表
給一個業(yè)務(wù)過程添加屬性字段并設(shè)置字段的來源(對應(yīng)某個ODS層物理表的字段或字段計算邏輯),設(shè)置其關(guān)聯(lián)維度后就可以得到事實邏輯表。下表為下單的事實邏輯表,僅列舉了部分屬性字段。
屬性字段
說明
來源字段
關(guān)聯(lián)維度
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
無
該事實邏輯表關(guān)聯(lián)了消費者維度,消費者維度又關(guān)聯(lián)了地址,地址關(guān)聯(lián)了地域相關(guān)的多個維度。
定義指標
下文以消費者運營團隊統(tǒng)計最近30天內(nèi)每個消費者線上下單金額為例,為您介紹如何定義其中的指標。
按照傳統(tǒng)SQL研發(fā)方式,您可以使用以下代碼,統(tǒng)計最近30天內(nèi)每個消費者線上下單金額。
--假設(shè)今天是 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
根據(jù)上述代碼為您介紹如何定義統(tǒng)計周期、統(tǒng)計粒度、統(tǒng)計時效、原子指標、業(yè)務(wù)限定和派生指標:
統(tǒng)計周期
統(tǒng)計周期用于約束指標的來源數(shù)據(jù)的時間跨度,即該指標的統(tǒng)計周期為最近30天,也就是指定了該指標的來源數(shù)據(jù)是最近30天內(nèi)創(chuàng)建的訂單。
統(tǒng)計粒度
統(tǒng)計粒度是分析維度,即Group By后需要聚合的維度,該指標的統(tǒng)計粒度就是消費者維度。
統(tǒng)計時效
最近30天這個統(tǒng)計周期是以天為統(tǒng)計粒度的,因此該指標的統(tǒng)計時效是天。
原子指標
下單金額是該指標的原子指標,其計算邏輯為
sum(amount)
。下單金額是最基礎(chǔ)、且不可拆分的事件。從SQL角度來看,下單金額sum(amount)
是一個簡單的聚合表達式。業(yè)務(wù)限定
統(tǒng)計周期約束了來源數(shù)據(jù)的時間跨度,其他過濾條件則進一步篩選出進入統(tǒng)計的數(shù)據(jù),這些過濾條件即業(yè)務(wù)限定。該指標統(tǒng)計的線上訂單為業(yè)務(wù)限定,其計算邏輯為
order_site=1
。派生指標
最近30天每個消費者的線上下單金額,就是派生指標。