《阿里云：全鏈路數據治理——智能數據建模篇 （182頁）.pdf》由會員分享，可在線閱讀，更多相關《阿里云：全鏈路數據治理——智能數據建模篇 （182頁）.pdf（182頁珍藏版）》請在三個皮匠報告上搜索。

1、封面頁（此頁面將由下圖全覆蓋，此為編輯稿中的示意，將在終稿 PDF 版中做更新）卷首語 云原生一體化數倉是阿里云整合自研大數據產品 MaxCompute、DataWorks、Hologres 和實時計算 Flink 版推出的一站式大數據處理平臺，具備流批一體、實時離線一體、湖倉一體、全鏈路數據治理四大核心能力，可以滿足企業在建設大數據平臺中對時效性、準確性、性價比、非結構化數據處理的需求，基于精簡的架構，支撐全域數據分析需求和決策。全鏈路數據治理包含智能數據建模、全域數據集成、高效數據開發、主動數據治理、全面數據安全、快速分析服務六大產品能力，覆蓋數據的全生命周期。本篇全域數據集成向開發者介紹

2、通過DataWorks數據集成在多表多表、多表單表、單表單表等場景下，進行實時或離線同步的技術選型與核心能力，并以MaxCompute 與 Hologres 引擎為例，演示云上數據同步操作步驟最佳實踐。后續系列電子書更新請關注 DataWorks 官網或阿里云開發者社區。l 全域數據集成電子書（已完成）l 云原生一體化數倉新能力電子書（已完結）l 全面數據安全電子書-10 月 l 離線實時一體化電子書-10 月 l 主動數據治理電子書-11 月中 DataWorks 官網：https:/ 目錄 大白話數據建模.5 數倉建模理論與規范.24 DataWorks 智能數據建模介紹.46 客戶案例：

3、菜鳥集團數倉建模.59 客戶案例：工業 OT 域數據最佳實踐.78 客戶案例：汽車行業數據建模最佳實踐.86 客戶案例：大淘系數據模型治理最佳實踐.104 產品實操：零售電商數據建模操作實踐.121 大白話數據建模 5 大白話數據建模 作者：蘇靖鑫，DataWorks 產研團隊 一、前言 合理的數據架構關乎企業的命脈，能夠協助企業數據資產長久健康發展。數據開發、數據資產、數據治理，而這一切都是圍繞數據建模展開的。數據研發同學 JobModel 里也指出了這一點：不再局限于 ETL 開發，會更側重數據建模能力或者數據架構的能力。關于建模的資料很多，或許涉及過多專業術語的緣故，可能不夠清晰直白。因

4、此我結合自己的理解，通過一個虛擬的案例，通過大白話給大家解釋數據建模的專業術語，幫助大家快速理解。二、通過案例講數據建模 Kimball 維度建模理論是目前在數據倉庫領域中使用最為廣泛的、也最得到認可和接納的一項技術。目前集團數據團隊工作規范就是基于它來開展，接下來我們來講述維度建模理論的基礎知識。1.度量與維度當我們看到一個數字的時候，我們會想到什么？大白話數據建模 6 很顯然，單獨一個 2 無法讓我們聯想到任何事。我們加一些描述進去，再來看看？加了描述以后，我們理解清楚了，原來 2 代表的是小明同學在全家便利店購買的 1瓶農夫山泉礦泉水，價格為 2 元。講到這里，我們明白：單獨一個數字無法

5、描述任何現實，必須加上必要的上下文才能讓人理解。在維度建模理論里，將數值記錄（2 元）稱之為度量，將上下文稱之為維度，這個案例中，商品、商家和客戶均是維度，維度建模便是通過這兩個名詞作為起點展開的。2.事實表 小明同學當天還購買了其他商品，數據如下所示：大白話數據建模 7 這份記錄購買記錄的表格，由多行維度和度量構成的表格，稱為事實表。它的每一行對應現實中的一個事實，這個事實被稱為業務過程。我們看到上述數據中，每一行的區分依據，是訂單 ID 和商品 ID，稱為事實表的粒度，粒度決定了事實表里每一行的細分程度。事實表里除了記錄商品 ID，還記錄了商品名稱，稱為維度屬性。在實際數據處理中，事實表為

6、了讓其更可讀、使用更便捷，往往會冗余一些維度屬性。3.維度表 小明同學購買的商品，同時還有容量，類目等描述詞，這部分描述詞稱之為維度屬性，但是它們并不會全部出現在事實表里，而是單獨存放。由維度主鍵和維度屬性構成的表格，被稱為維度表。維度表通常有多列或者說多個屬性。實際應用中，包含幾十甚至上百屬性的維度表并不少見。維度表應該盡可能多地包括一些有意義的文字性描述，以方便下游用戶使用。4.指標規范 現在我們已經有了描述便利店的商品和客戶數據，還有了客戶交易事實表。你很幸運地得到了一份數據分析師的工作，需要你來分析這家便利店的銷售業績。大白話數據建模 8 銷售業績需要通過指標來量化，所以你組織大家開了

7、一次討論會，收集大家的需求并梳理指標。大家紛紛發言：店長：我希望看到老買家和新買家的日均支付金額，希望看到近一天的，近一周的，近一個月的。店員 1：我希望看到新品上架后的銷售情況，也希望看到近一天的，近一周的，近一個月的。店員 2：我希望看到主營類目的日均支付金額，看近一周的數據就行，還希望看到新老買家分別的數據。你將大家的需求進行分析，會發現幾個現象：需求口語化：比如店員 1 提到的銷售情況，這個是含糊的詞語，無法轉化成開發需求。需求糅合：比如店員 2 雖然只說了一句話，但是實際上包含 3 個指標，近一周的，新買家的，老買家的?？趶讲灰恢拢簳洗蠹叶继岬搅诵沦I家和老買家，但是沒有人針對新/老

8、買家給出完整的解釋，因此你還需要再去詢問一次，讓大家理解并保持一致。將這個案例放大到整個公司，為了讓指標能夠規范化描述與開發，避免不同團隊產生歧義，需要引入指標體系來解決此類問題。再回到上面這個案例，你梳理出了所有指標和口徑，如下所示：大白話數據建模 9 通過表格可以發現，不同指標存在很多重復的地方，例如最近 1 天、最近 7 天；新買家、老買家；日均支付金額、訂單數；如果針對每一個指標都需要進行完整的解釋，可想而知重復的工作量有多少。因此，聰明的你決定對指標進行拆解。你將指標拆解為原子指標、時間周期、修飾詞三大類，并將現在梳理出來的指標命名為派生指標。于是就得到了如下的公式：原子指標：原子指

9、標是不可再細分的度量，如支付金額，日均支付金額，支付訂單數。時間周期：用來明確數據統計的時間范圍或者時間點，如最近 1 天，最近 7 天。修飾詞：對指標統計業務范圍的劃定，業務活動上下文的描述，如新買家，老買家。大白話數據建模 10 通過指標分類，你發現現在指標更好復用和組合。原先你需要針對每一行指標給出描述，如今你只需要針對每一類詞分別描述，隨后自由組合?？芍^是事半功倍。5.數據域與總線矩陣 現在擺在你面前的是一堆零散的需求，你不太清楚從哪里開始著手進行分析，這個時候，分而治之的思想就派上用場。你將零散需求進行分類，后續再一一展開，這個過程被叫做數據域劃分。數據域劃分：數據域是指面向業務分析

10、，將業務過程或者維度進行抽象的集合。數據域需要抽象提煉、并且長期維護和更新的，但不輕易變動。在劃分數據域時，既能涵蓋當前所有的業務需求，又能在新業務進入時無影響地被包含進已有的數據域或者擴展新的數據域。最終，你梳理出來本次需求的數據域如下所示：大白話數據建模 11 數據域 描述 包含的業務過程 包含的維度 交易域 客戶在便利店購、退商品商品的全過程 購買商品、退換商品 訂單類型等 會員域 在店鋪注冊的會員數據 開通會員、續費會員 會員類型等 店鋪域 店鋪的基本數據 開店、關店 店鋪等級等 商品域 店鋪售賣商品的基本數據 上架、下架、補充庫存 商品、品類、品牌等 上面我們提到，事實表為了更好地進

11、行分析，往往會冗余一些維度屬性，例如交易域的“購買商品”業務過程，會冗余店鋪、商品、會員等維度信息，因此，我們還需要分析業務過程與維度的關聯關系，這個時候，就要用到總線矩陣了?？偩€矩陣：是一種在全局視角理解數據結構的一種工具，可以讓相關人員對整個數倉結構能夠有清晰了解，很容易就能看出來數據域與業務過程、維度的關系；以及業務過程與維度的關系。數據域 業務過程/維度-會員域 店鋪域 商品域 時間 會員 店鋪 商品 交易域 購買商品 退換商品 店鋪域 開店 商品域 上架 由業務過程和維度的關聯關系構成的表格，就稱之為總線矩陣，可以很清晰的看出：業務過程與維度的關系：方便我們在開發時對照需要冗余的維度

12、屬性。數據域與業務過程/維度的關系：方便開發時就做好數據資產的歸類，便于后續復用。大白話數據建模 12 6.數倉分層 在需求分析完成后，你開始幫助大家開發需求。在開發過程中你發現，為了滿足大家的需求，你需要將新/老用戶的判斷重復寫在三份 SQL 代碼里，一方面代碼冗余，另一方面計算成本也更高，后面如果口徑需要變更，還需要修改三個地方。聰明的你又開始思考可否對數據倉庫做抽象，通過中間層的建設來提高后續的開發效率。最終，你想出來的方案如下：ODS 層：數據準備區，是數據開發的預熱階段，目標是 1 比 1 完整接入數據，僅僅要求全，不用對原屬數據做變更。這一步，你將便利店的數據從源頭系統拉取過來。C

13、DM（Common Data Model）：通用數據模型層，這一層是你主要開發的部分?構建 DIM 層：目標是將維度表統一管理起來。這一步你從 ODS 層，給買家維度表開發新/老買家標記。?構建 DWD 層：目標是對事實表做一些提前計算，例如拼接維度表的字段，進行數據清洗，讓數據好用。這一步你將交易事實表進行加工，添加了剛剛開發的買家維度表里的新/老用戶的標記。?構建 DWS 層，目標是根據指標對數據適度匯總。這一步你便可以生產出最近 N 天的新買家/老買家的日均支付金額和訂單數等信息。大白話數據建模 13 構建 ADS 層：與業務直接關聯的需求在此完成。例如最近 N 天新品新買家日均支付金額

14、。根據上述劃分，你設計的表分層如下：可以想象，假如后續多招聘了一位數據開發同學，他就可以基于你構建的 CDM 層數據，來完成 ADS 層的建設?？偨Y一下，通過遵循數據倉庫建模，有以下好處：屏蔽源頭系統業務變更、系統變更對于下游用戶的影響：如果源頭系統業務發生變更，相關的變更由 DW 層來處理，對下游用戶透明，無須改動下游用戶的代碼和邏輯。屏蔽源頭業務系統的復雜性：源頭系統可能極為繁雜，而且表命名、字段命名、字段含義等可能五花八門，通過 DW 層來規范和屏蔽所有這些復雜性，保證下游數據用戶使用數據的便捷和規范。避免重復計算和存儲：通過匯總層的引入，避免了下游用戶邏輯的重復計算，節省了用戶的開發時

15、間和精力，同時也節省了計算和存儲。大白話數據建模 14 數據倉庫的可維護性：分層的設計使得某一層的問題只在該層得到解決，無須更改下一層的代碼和邏輯。7.小結 基礎知識到這里就結束了，接下來會講述圍繞著數據建模理論，數據研發團隊的研發流程是如何建立的。三、基于數據建模的研發流程 完整的數據研發流程可以參考下圖：1.需求分析階段 這一階段明確清楚用戶需求，拆解數據域，業務過程，原子指標、派生指標、時間周期和修飾詞，并和用戶溝通清楚口徑，彼此達成一致。產物：通過 Excel 等表格工具梳理出的數據域、業務過程、維度、指標。大白話數據建模 15 2.模型設計階段 根據上一步梳理產物，在建模工具內完成數

16、據倉庫設計（邏輯表設計），并與團隊同學及業務方一起 Review。產物：建模工具中完成數倉設計，主要為數據域、業務過程、維度、原子指標、派生指標、事實表與匯總表。1)基礎信息錄入 參考先前梳理的資料，可以絲滑錄入到建模工具里。數據域 業務過程/維度-會員域 店鋪域 商品域 時間 會員 店鋪 商品 交易域 購買商品 x x x x 退換商品 x x x x 店鋪域 開店 x x 商品域 上架 x x x 大白話數據建模 16 大白話數據建模 17 2)指標建立 得益于前期已經遵循數據建模的思想進行拆解，所以我們可以按部就班地將原子指標、修飾詞、時間周期、派生指標生產出來。大白話數據建模 18 大

17、白話數據建模 19 大白話數據建模 20 3)數倉建設 大白話數據建模 21 4)模型發布 大白話數據建模 22 3.數據開發 在需求分析和模型設計做的很充分的情況下，數據開發反而是最為簡單的，DataWorks 數據建模甚至可以直接生成數據開發的簡單代碼，供數據開發直接使用。所以雖然在數據建模中投入一定的工作時間，但是整體數據開發的效率是更高的。在數據開發完成后，通過相關數據工具進行回歸驗證。4.數據運維 通過 DataWorks 其他模塊，觀察數據線上產出的質量、時效；觀察數據使用情況，及時對耗時長、使用率低的數據進行治理。四、總結 以往大數據研發經歷了一段野蠻增長的時光，產生了大量不可維

18、護或者計算存儲成本高的數據，給企業造成了很大的負擔?，F在大數據產品關于建模的能力正在日益變完善，后續的大數據研發過程應該都是圍繞著建模展開了，也歡迎大家使用DataWorks 提供的數據建模工具，改善、規范你的數據研發流程。大白話數據建模 23 數倉建模理論與規范 24 數倉建模理論與規范 作者：渠振方，大數據售前專家服務團隊 摘要：本文主要介紹數據倉庫模型架構設計的目標、核心思想和核心步驟。一、模型架構設計目標 1.數據倉庫的定義 數據倉庫是一個面向主題的（Subject Oriented）、集成的（Integrated）、相對穩定的（Non-Volatile）、反映歷史變化（Time Va

19、riant）的數據集合，用于支持管理決策（Decision Making Support）。從上面的定義可用看到數據倉庫主要有四個特點：面向主題：面向分析主題，如商家全域分析、交易環節分析等。集成的：將業務系統進行集成組裝，并整合到數據倉庫中。相對穩定：不同于 OLTP 需要進行很多事務性操作（如：插入、刪除、修改，等），OLAP 是一次性載入后進行多次查詢訪問。反映歷史變化：不同于 OLTP 僅反映當下數據狀態，OLAP 可以反映數據歷史的變化情況。數倉建模理論與規范 25 2.范式建模 VS 維度建模 建模的兩大核心思想是：范式建模和維度建模。1)范式建模法（3NF）Inmon 數據倉庫建

20、模中最常用的方法，在技術上可以解決關系型數據庫的數據存儲，減少大量的數據冗余；在業務上可以使模型更加簡潔易懂，數據的出口唯一。優點：從關系型數據庫的角度出發，結合了業務系統的數據模型，能很方便的實現數據倉庫建模，同時邏輯清晰，避免了數據冗余。缺點：從底層數據向數據集市的數據進行匯總時需要進行一定變通，經常需要多表關聯才能滿足相應的需求。2)維度建模Kimball 按照事實表、維表來構建數據倉庫、數據集市。優點：事實表事先針對各個維度做了大量的預處理，比如進行預先的聚集、排序、分類等，后續基于其上的應用在訪問速度很快；維度非常直觀，緊緊圍繞著業務模型，能快捷完成維度建模。缺點：當業務發生變化，需

21、要重新進行維度的定義，往往需要重新進行維度數據的預處理，并導致大量的數據冗余，無法保證數據來源的一致性與完整性。本次分享主要介紹維度建模。3.模型架構設計目標 模型架構設計的總體目標是清晰的層次架構、合理穩定的數據分域和高效易用的數據模型。具體體現在以下四個方面：1)易使用 一致性 規范性 數倉建模理論與規范 26 完整性 2)高質量 穩定產出 口徑一致 準確性 3)低成本 計算成本 存儲成本 研發成本 4)好運維 可擴展 可回刷 易維護 二、模型架構設計核心思想 1.核心原則 模型架構設計的核心原則是高內聚、低耦合，即在域內內聚，域之間耦合，以及業務和模型的耦合，在此之上實現穩定性、擴展性、

22、建設效率、產出效率和使用效率。2.核心過程 模型架構設計的核心過程有四個步驟：數據分層、業務分類、數據分域、模型設計（包括：確定維度、確定事實、確定模型）。數倉建模理論與規范 27 三、數據分層架構設計 數據分層架構主要包含三個層次。1.貼源層：ODS（Operational Data Store）操作型數據存儲層 面向業務的原始溯源性，貼原從業務系統引入并組織數據。2.中間層：CDM（Common Data Model）公共數據模型層 面向業務通用性，易用性、復用性，組織公共通用明細數據與匯總數據。包括三種類型數據：DWD（Data Warehouse Detail）：明細類數據事實表 DW

23、S（Data Warehouse Summary）：匯總類數據事實表 DIM：維度表 3.應用層：ADS（Application Data Service）應用數據服務層 面向業務應用視角組織數據，一般是面向產品、業務場景進行公共數據組合與個性化計算。下圖右邊以淘寶為例，列舉淘寶三個核心 Project（tbads、tbcdm、tbods）數倉建模理論與規范 28 四、數據分域架構設計 數據分域分為三個步驟：收集、提煉、歸納。1.收集：業務數據需求、存量數據梳理 核心目的：對現有數據和業務訴求需要的數據進行 merge，保障數據倉庫的完整性，形成數據全集。核心對象：分析師、業務運營人員、數倉開

24、發者。核心輸出：粒度、維度、數據指標、使用場景等信息。2.提煉：業務過程、業務梳理 業務過程：指企業的業務活動行為，如點擊、瀏覽、下單等，業務過程是一個不可拆分的行為事件。核心目的：對收集的數據全集，進行業務關鍵詞（包括業務過程、業務元素）提煉，根據經驗羅列分類。核心對象：數據模型架構師。核心輸出：業務過程、業務元素列表。3.歸納：數據域 數據域：面向業務，根據業務過程進行分類，組合抽象而成的數據集合。數據域不能輕易變動，在劃分數據域時，既能覆蓋當前所有的業務場景數據，又能在新業務進入時被融入，或對整體架構無影響下的擴展新數據域。核心目的：對業務過程、業務元素的列表進行抽象，盡量避免邊界模糊不

25、清，歸納出數據域名稱。核心對象：數據模型架構師。核心輸出：數據域大圖，包括核心業務過程與元素的包含關系。下圖用實例來介紹數據分域過程中如何進行收集、提煉和歸納：數倉建模理論與規范 29 五、數據模型設計流程 數據模型設計主要分為三個階段：需求調研，規范定義，模型設計。1.名詞解釋 1)時間周期 用來明確數據統計的時間范圍或者時間點，如最近 30 天、自然周、截至當日等。2)修飾詞 指除了統計維度以外指標的業務場景限定抽象，比如有效（下單金額），PC 端（下單金額）。3)度量 對某個業務事件的衡量，通常為數字，如件數，次數。區別于原子指標，度量命名一般不帶上具體的業務動作。4)原子指標 基于某一

26、業務事件行為下的度量，具有明確業務含義，是業務定義中不可再拆分的指標。原子指標=業務過程+度量，如下單（事件）金額（度量）。數倉建模理論與規范 30 5)派生指標 可以理解為對原子指標業務統計范圍的圈定。派生指標=一個原子指標+多個修飾詞（可選）+時間周期。比如：最近 30 天 PC 端下單金額（最近 30 天為時間周期，PC 端為修飾詞，下單金額為原子指標）。6)維度 維度是對應業務的數據分析角度，維度是度量的環境，用來反映業務的屬性，某類屬性的集合構成一個維度。維度歸屬于一個數據域，如地理維度（其中包括國家、地區、省以及城市等級別的內容）、時間維度（其中包括年、季、月、周、日等級別的內容）

27、，會員維度。7)粒度 精確定義事實表的每一行所表示的業務含義，傳遞的是與事實表度量有關的細節層次，比如子訂單粒度。2.需求調研 1)業務調研 業務調研的流程分三個步驟：輸入調研模板。針對產品和運營進行調研。歸納產出：業務過程&數據域。下圖舉例說明業務調研的流程：數倉建模理論與規范 31 2)需求分析 需求分析的三個步驟：輸入調研模板，研究報表&數據體系。與分析師&運營討論收集信息。歸納產出：指標體系。3)總線矩陣 根據業務調研、需求分析，完成總線矩陣，以明確數據域與哪些業務過程相關，業務過程與哪些維度相關。數倉建模理論與規范 32 3.規范定義 1)一致性維度 維度及維度屬性 在總線矩陣下，維

28、度必須歸屬某一個數據域，維度屬性的來源一種是源系統，一種是挖掘計算，如最近一次支付時間。特殊維度 雜項維度：將事實表中的狀態、分類等字段定義為維度，比如交易訂單、物流訂單中的狀態等均可稱雜項維度。行為維度：基于歷史事實構建，如會員最近一次支付時間就是一個行為維度，可作為其父維度會員維度的維度屬性，不建議單獨創建維度。維度整合和拆分 維度整合?同一業務板塊下同維度不同屬性信息可整合，如會員維度基本屬性、星級等信息。?不同業務板塊同維度信息可整合，如天貓淘寶基本會員信息。維度拆分?同一維度不同分類的屬性，差異較大或業務關聯度不大的信息，如不同業務板塊的商品維度可拆分成不同維度表。數倉建模理論與規范

29、 33?每個商品會有主屬性（形狀、顏色、價格，等）和擴展屬性，比如有些產品的一個擴展屬性是帶電的，那么在物流業務上就會有相應的限制，因此需要根據其業務屬性拆分到不同維度表。?從產出時效、易用性考慮垂直拆分出主商品維表和商品維度擴展表。比如“跨境十日達”商品，會根據其業務屬性劃分維度屬性，并放入維度擴展表。命名規則 命名規則盡可能使用英文簡寫。若英文簡寫過長，可考慮拼音首字母簡寫，如：商品 itm，商家 slr，買家 byr。最佳實踐 以淘系常用維度來看命名規則。2)一致性度量 基本原則 度量必須歸屬某一個業務過程。度量類型：一般是數值，所以在定義數據類型時候一般為數字類型，同時需要和維度屬性做

30、區別。數倉建模理論與規范 34 度量分類：按照事實的是否可加性分為：可加性度量、半可加性度量、不可加度量。命名規則 盡可能使用英文簡寫。當英文簡寫很長可以考慮漢語拼音首字母的簡寫，但一般要保持整個數倉一致性，所以盡可能選擇一種命名縮寫規則，如：數量 cnt、金額 amt。最佳實踐 前面已經定義了業務過程，比如交易域的支付過程，接下來要規范定義交易業務過程涉及的度量，例如金額 amt、單量 cnt 等。3)指標定義 基本原則 派生指標可以選擇多個修飾詞，唯一歸屬于一個原子指標，屬于某一個數據域。派生指標一般由原子指標和時間周期、若干修飾詞構成。派生指標的命名要繼承原子指標的命名規則和名稱，可以抽

31、象為：修飾詞+原子指標+時間周期。命名規則 盡可能使用英文簡寫。若過長，考慮拼音首字母簡寫，如：?原子指標：支付單量 pay_ord_cnt?派生指標：近 1 天淘特支付單量 tt_pay_ord_cnt_1d 最佳實踐 下圖左邊是邏輯結構圖，右邊是指標舉例，最近 1 天淘特支付單量的邏輯結構圖：數倉建模理論與規范 35 下圖是以交易域的指標為例看命名規則：?電商版塊：ed?交易域：trd?支付：pay?單量：ord_cnt?訂單：ord?業務來源類型：From_group?最近一天：1d?淘寶特價版：tt?支付單量：pay_ord_cnt?訂單：ord?訂單 ID、訂單狀態：order_id

32、，order_status?最近 1 天淘特支付單量：tt_pay_ord_cnt_1d 數倉建模理論與規范 36 4.模型設計 1)設計原則 高內聚，低耦合 規范性，一致性 穩定性，可擴展 公共邏輯下沉 成本性，能平衡 支持多次回刷 2)維度表設計 設計流程 基本原則 緩慢變化維 Kimball 的三種處理方法：重寫、插入新記錄、插入維度列（僅限兩次變更）；阿里采用極限存儲的方法。維度的一致性 相同維度屬性在不同物理表種字段名稱、數據類型、內容必須一致。維度的組合和拆分?同一維度不同屬性關聯性強可以整合，如會員基礎屬性星級等。?同一維度不同屬性差異大的可拆分，如淘寶商品與航旅商品。?同一維度

33、不同屬性關聯度不強的可拆分，如會員表拆為買賣家維度表，如淘寶商品與 CBU 商品。?從產出時效、易用性、穩定性角度考慮是否需要拆分，如商品維度表和擴展表。數倉建模理論與規范 37 命名規則 dim_業務 BU/pub_數據域_維度定義_自定義命名標簽 最佳實踐 以淘系事實表、交易訂單表和其中冗余的商品、買賣家相關維度表為例來介紹。下圖是淘系商品維度表：dim_tb_itm?維度：商品?維度屬性：商品標題、商品金額、商品顏色、主圖等?冗余屬性：類目維度屬性等 下圖是淘系商品屬性擴展維度表：dim_tb_itm_extend 數倉建模理論與規范 38 擴展維度表從主維度表中拆分出來主要是有三個方面

34、考慮：穩定性、產出時效、變化頻次角度。主維度表 VS 擴展維度表：主維度表 穩定 產出時間早 熱度高 擴展維度表 變化較快 產出時間晚 熱度低 3)事實表設計 事實表主要有三種類型：事務型事實表、周期快照事實表、累積快照事實表。數倉建模理論與規范 39 事務型事實表 周期快照事實表 累積快照事實表 時期 離散事務時間點 日期維度 事務日期 粒度 每行代表實體一個事務 事實 事務事實 更新方式 插入不更新 核心點 實體的單個事件發生過程 時期 以有規律的、可預測的間隔產生快照 日期維度 快照日期 粒度 每行代表某時間周期的一個實體 事實 累積事實 更新方式 插入不更新 核心點 核心關注的是當前的

35、一個累計狀態，關注的快照的當前態 時期 時間跨度不確定、不斷變化 日期快照 相關業務過程涉及的多個日期 粒度 每行代表一個實體的生命周期 事實 相關業務過程事實和時間間隔事實 更新方式 插入與在業務過程變更時更新 核心點 核心關注的是實體的生命周期范圍內（如訂單產生到完結）的各個狀態變化 a)事務型事實表 針對業務過程構建的一類事實表，用以跟蹤定義業務過程的個體行為，是數倉最原子的明細數據，提供豐富的分析能力。按照所描述的業務過程的數量分為單事務事實表和多事務事實表。數倉建模理論與規范 40 設計流程 基本原則?完整性：盡可能包含所有與業務過程相關的事實。?高內聚低耦合：只選擇和業務過程相關的

36、事實。?粒度明確：在同一個事實表中，粒度必須唯一。?成本性能的平衡：使用退化維度提高事實表的易用性。b)單事務事實表 淘寶下單事件事務事實表：dwd_tb_trd_ord_di 基本特征?業務過程：訂單創建?事實表類型：單事務事實表?粒度：子訂單 ID?度量：訂單創建金額等 數倉建模理論與規范 41?冗余屬性：冗余商品、會員屬性?數據存儲：僅插入不更新、每個實體在整張表只有一條記錄 適用場景?單業務過程，如下單、支付等?單業務過程分析無需限定業務過程?舉例：雙 11 下單單量 Select count（order_id）from tbcdm.dwd_tb_trd_ord_di where ds

37、=20211111 冗余原則?冗余維度屬性下游常用?冗余維度屬性不影響產出時效 c)多事務事實表 淘寶多事務事實表：dwd_tb_trd_ord_ent_di 基本特征?業務過程：訂單創建支付完結?事實表類型：多事務事實表 數倉建模理論與規范 42?粒度：子訂單 ID?度量：訂單創建金額、支付金額等?冗余屬性：冗余商品、會員屬性?數據存儲：僅插入不更新，每個分區存儲每個實體的最新業務過程狀態，通常以打標方式標識其業務過程（如表中的“是否當天下單”、“是否當天支付”、“是否當天確認收貨”），每個實體因其業務過程更新情況，在整張表可能有多條記錄 適用場景?適合一次分析多個業務過程的場景?此場景下計

38、算存儲相比單事務節約、取數更便捷?舉例：查詢 20220110 當天下單當天支付的訂單 select*from tbcdm.dwd_tb_trd_ord_ent_di where ds=20220110 and is_create=Y and is_pay=Y d)累積快照事實表 訂單全流程表：dwd_tb_trd_ord_flow_di 基本特征?業務過程：訂單創建-支付-完結?事實表類型：累積快照事實表 數倉建模理論與規范 43?粒度：子訂單 ID?度量：訂單創建金額、支付金額等?冗余屬性：冗余商品、會員屬性?數據存儲：每日更新，存儲每個實體的最新狀態，每個實體在整張表中僅有一條記錄 每天

39、完成的訂單存儲在當天日期的分區，而未完成的訂單統一存儲在300001231 分區 適用場景?多個業務過程，聯合分析，如下單到支付、支付到訂單完結時長的分析?保存全量數據、常見于訂單處理?舉例：近 7 天支付訂單從下單到支付平均時長 select sum（pay_time-create_time）/count（order_id）from tbcdm.dwd_tb_trd_ord_flow_di where pay_time$bizdate-7 and（ds$bizdate-7 or ds=30001231）e)周期型快照事實表 設計流程 基本原則 數據公用性?匯總層的產出是否有多個下游使用?維度

40、的聚集是否有多個下游用于分析等?高內聚低耦合：dws 層不跨域計算存儲?可擴展性：區分統計周期，如果要拆分，需要按照原子周期去拆分到多個dws 數倉建模理論與規范 44 命名規則?dws_業務 BU 縮寫/pub_數據域縮寫_數據粒度縮寫_自定義表命名標簽縮寫_統計時間周期范圍縮寫?比如：dws_tb_itm_slr_td（商品域商家粒度匯總表）?tb：業務域?itm：數據域?slr：統計粒度?td：時間周期（截至當天為止）最佳實踐 以淘系事實表商家粒度商品匯總表和其中冗余維度店鋪維度為例來介紹：商家粒度商品匯總表：dws_tb_itm_slr_td 基本特征?粒度：商家 ID?指標：歷史截至

41、當日商品數等?業務周期：每日?物理表類型：周期快照事實表?冗余維度：店鋪 ID?數據存儲：每日更新，每個分區存儲每個?實體的最新狀態 數倉建模理論與規范 45 適用場景?時間周期跨度比較大，實體的當前狀態?不需要每次讀時從事務事實再計算?舉例：該商家歷史截至當日共上線的商品數 Select itm_cnt_std from tbcdm.dws_tb_itm_slr_td where ds=$bizdate DataWorks 智能數據建模介紹 46 DataWorks 智能數據建模介紹 作者：愛桐，DataWorks 產研團隊 一、DataWorks 智能數據建模-產品建設背景 2009 年，

42、DataWorks 就已經在阿里巴巴集團立項，支撐阿里巴巴數據中臺建設，一路見證阿里巴巴大數據建設之路。2020 年之前，DataWorks 支持的是開發視角、自底向上、小步快跑，快速滿足業務需求為首要目標的數倉構建模式，然而隨著內部數據模型越來越多，線下評審流程越來越復雜，淘寶、天貓、盒馬、菜鳥等多個數據倉團隊開始和 DataWorks 合作，構建 DataWorks 智能數據建模產品，支持業務視角自頂向下的規范化數倉建設，也可以支持傳統的開發視角、自底向上的數倉構建模式，真正做到規范化、可持續發展地構建數據倉庫。2021 年云棲大會，DataWorks 智能數據建模正式發布，在阿里巴巴集團

43、內各個業務團隊投入生產，并在阿里云上服務世界 500 強億滋中國等眾多客戶。DataWorks 智能數據建模介紹 47 二、DataWorks 智能數據建模-業務痛點 在智能數據建模產品正式發布之前的這十多年時間里，阿里巴巴的各個數倉團隊實際上并不是不需要進行數據建模，而是采用線下 excel 建模評審的方式在開展這一項工作，流程本身非常規范，模型的上線及變更有著非常嚴格的評審流程，但即使如此，線下建模還是有它的弊端存在。線下建模的弊端主要體現在三大方面：規范定義、模型設計、數據開發。從規范定義方面來講，存在的主要問題是：數倉規范與模型設計分離，符合規范的模型設計對建模師本身的要求非常高，既要

44、能把業務需求高度抽象進行模型設計，還需要牢記規范的點點滴滴。數據指標定義效率低，且指標的數據加工邏輯分離，過去傳統的單個創建指標效率相對低下，且無法保證指標的唯一性，指標的加工邏輯和指標定義本身也存在脫節的情況，最終導致指標真實口徑無法統一，進而帶來了大量的針對指標結果數據不一致的對焦工作。應用層缺少規范，大多數應用層的建設都面臨需求多變、需求開發時間緊、任務重的特點，也對應用層模型規范的管理帶來了非常高的挑戰。既要能夠滿足業務需求，又要能夠符合規范，其實很難再短時間內完成這些工作。從模型設計方面來講，存在的主要問題是：純人工的模型設計效率低下，比如要在 excel 里做模型設計，并且需求在

45、excel 里做維護。從數據開發方面來講，存在的主要問題是：模型設計和物理表開發分離，模型設計是模型設計，物理表開發是物理表開發，很有可能會造成物理表開發邏輯與模型設計理念存在或多或少的差異情況。此外，本地建模，還會存在著一些隱藏的問題，如文件管理混亂、硬件設備故障、工作交接難等問題。DataWorks 智能數據建模介紹 48 三、DataWorks 智能數據建模-業務價值 數據建模作為數倉規范，最大的受益者是企業自身，但企業的價值需要通過一線研發人員的工作得以體現。對于一線研發同學來講，智能數據建模能為大家帶來的最大的好處是提效，相比傳統的純開發或者線下建模線上開發的工作方式來說，智能數據建

46、模能為大家帶來更加更加高效的建模和研發方式。由此，幫助企業做好企業數據體系的規范化建設，讓數倉規范真正能落到實處。企業數倉規范真正做好以后，能為企業沉淀大量的體系化的核心數據資產，同時，也能順其自然地為企業節省大量的存儲和計算成本。DataWorks 智能數據建模介紹 49 四、DataWorks 智能數據建模-數據建模方法論 眾所周知，維度建模和范式建模都是目前大家所熟知的建模方法論，兩種建模方法論，各有各的優勢，也有各自的劣勢，這里不對兩種方法論進行展開介紹。阿里巴巴集團大多數數倉團隊面向的業務又多具備高速發展、變化迅速、海量數據的業務特點，故以維度建模為主。智能數據建模產品由于它是生于阿

47、里，長于阿里，所以我們也是基于維度建模方法論進行的產品建設，但也不是說智能數據建模完全不體現模型關系，DataWorks 智能數據建模產品也會提供關系設計及展示相關的產品功能。五、DataWorks 智能數據建模-數倉分層 一般來說數倉會分為三大層，ODS、CDM、ADS。其中 ODS，又稱為貼源層。ODS 主要用戶存儲業務系統同步來的業務數據。一般情況下，我們不會對 ODS 層的數據做過多的加工，以便于后續在 ADS 和 CDM 數據出錯時的溯源。換句話說，ODS 不是數倉同學設計出來的，是對業務系統數據的直接同步。數倉建設最最重要的公共層 CDM 層，CDM 層需要對業務進行高度抽象，需要

48、具備通用性、易用性、復用性，因此，公共層的建設對數倉同學的要求是非常高的，既 DataWorks 智能數據建模介紹 50 精通建模方法，同時也對業務情況了如指掌。CDM 層再進行細分，一般會分為 DIM層-維度表，DWD 層-明細數據表，DWS 層-輕度匯總層。數倉建設最難管但管好了效果非常明顯的應用層 ADS 層，ADS 層主要面向業務進行模型設計。因此，大家一定要先了解清楚模型的主要應用場景，是普通的報表分析，還是數據產品的調用等等，不同的應用場景，模型設計需要考慮的因素也不一樣。如果規范化 ADS 層，需要建設的表會減少，通過統一邏輯去查詢，會使計算和存儲成本降低。六、DataWorks

49、 智能數據建模-名詞釋義 業務分類：業務板塊是某一大類的業務的指標和維度的集合，如電商，文娛。數據域：數據域是指一個或多個業務過程或者維度的集合，如交易域，日志域。業務過程：業務過程指企業的業務活動事件，如下單，支付。數據集市：面向某個應用場景或者產品的數據組織，一般會依賴數據公共層。主題域：將數據集市按照分析視角進行切分，比如在電商行業，通常分為會員、交易、商品等。維度：維度是用于分析數據的一個角度，一方面對維度進行可控管理，另一方面指導維度表的設計，如地理維度，時間維度。維度屬性：維度屬性隸屬于一個維度，用來描述維度的屬性，如地理維度中的國家名稱，省份名稱。DataWorks 智能數據建模

50、介紹 51 時間周期：時間周期是用來明確數據統計的時間范圍或者時間點，如最近 30 天，自然周。修飾詞：修飾詞是對指標統計業務范圍的劃定，指除了統計維度外指標的業務場景的限定抽象，如 PC 端，無線端。原子指標：原子指標是一般不可再細分的度量，原子指標命名=業務過程+度量。，如支付金額，訪問人數。派生指標：派生指標直接用于匯總表的字段，派生指標由原子指標、時間周期、修飾詞（可選）組成，如最近 1 天海外買家支付金額。七、DataWorks 智能數據建模-一級產品功能 DataWorks 智能數據建模產品分為四大板塊，分別是數倉規劃、數據標準、維度建模和數據指標。其中數倉規劃、數據標準和數據指標

51、最終都為維度建模服務。八、DataWorks 智能數據建模-二級產品功能 數倉規劃是數倉的頂層設計，包含分層劃域、維度管理、建?？臻g。從產品定義來講，這些內部并不復雜。難點在于數倉怎么根據業務場景來劃分。建議先用思維導圖畫好，有了一個大概雛形之后，再錄入產品。其中一個重點功能是可視化的表名檢查器配置，檢查器用于規范目標分層中表的命名，將同一分層中表名稱的命名格式統一，便于通過表名稱，即可了解到該表所屬的業務類型、作用功能、數據粒度等信息。同時，可以幫助減少后期的運維成本。系統默認創建的數倉分層和自定義 DataWorks 智能數據建模介紹 52 新建的數倉分層均可以配置數倉分層檢查器。對于建模

52、同學來講，建模效率會提升且產出的內容符合規范。數據標準包含數據標準、標準代碼、度量單位、命名詞典。數據標準和標準代碼設置好之后，可以和模型字段做關聯，關聯之后模型字段名稱、值等都需要符合標準的設置。數據指標包含派生指標、原子指標、修飾詞、時間周期。這里重點需要說明批量創建指標，勾選構成派生指標的原子指標、修飾詞、時間周期，就可以生成一系列派生指標，用于模型設計。指標創建好后有兩個作用，一是可以把指標批量導入到模型里面，作為模型的字段存在。另一個是模型字段已經存在，需要跟指標做關聯。這樣在物化之后可以找到指標對應的是哪個模型。維度建模支持正向建模和逆向建模。逆向建模解決的是已有數倉冷啟動的問題，

53、主要用于將其他建模工具生成的模型反向建模至 DataWorks 的維度建模中。例如，當已通過其他建模工具生成模型，此時，想更換為 DataWorks 的智能建模進行后續建模工作，則可以使用逆向建模功能。該功能無需再次執行建模操作，即可快速將已有模型反向建模至 DataWorks 的維度建模中，節省了大量的時間成本。正向建模支持可視化建模、excel 導入、多語言建模?？梢暬ｎ愃凭W頁版 excel的方式，把模型字段信息統一管理。在這個過程中，可以復用已經存在的物理表表機構，提升建模效率。多語言建模支持 DDL、自研 FML 方式建模。建議先用可視化建模，如果需要修改字段，可以用 DDL 或者

54、 FML 方式做字段的修改。在建模過程中，設置里某一字段為主鍵字段，非空字段，或者關聯了數據標準里的標準代碼，DataWorks 智能數據建?？梢砸绘I自動生成質量規則。當把模型發布到引擎中比如 MaxCompute 生成環境，可以自動生成一段數據開發的簡代碼。DataWorks 智能數據建模介紹 53 九、DataWorks 智能數據建模-數倉規劃 數倉規劃的整體架構如下，首先看中間部分業務分類，比如阿里的業務分為天貓、淘寶、菜鳥等等。也可以根據各個數倉團隊面向的業務來劃分。公共層分為三層，也就是上文講到的 DWS、DWD、DIM。DMI 下需要區分數據域，維度表只需要分到數據域就可以。明細表

55、需要細化到數據域和業務過程。輕度匯總層只需要指定到數據域就可以。在應用層這一部分主要是ADS 層，在實際工作中可能不止有 ADS 層還會有 DIM 層。產品側是支持大家靈活設置，如果有需要可以自行創建。ADS 層需要指定到具體的數據集市和主題域。這是模型在分層化域時需要考慮到的一整套體系。如果數倉團隊負責多個業務，多個工作空間，需要復用同一套數倉規范，可以使用一下建?？臻g功能。建?？臻g是當需要管理多個 DataWorks 工作空間且需要復用一套數倉規劃時，面對跨多個工作空間的復雜數據體系，可以通過設計空間來共享一套數據建模工具，針對整個數據體系進行統一的數倉規劃、維度建模及指標定義等工作。Da

56、taWorks 智能數據建模介紹 54 十、DataWorks 智能數據建模-逆向建模 逆向建模如下圖所示，可以選擇表所在項目空間，表名匹配規則需要指定是模糊匹配還是精準匹配，在指定表命名規范后，會根據這些關鍵詞來檢測表，匹配規范，最終成功生成模型。DataWorks 智能數據建模介紹 55 十一、DataWorks 智能數據建模-正向建模 正向建模支持創建維度表、明細表、匯總表等?；拘畔姹局饕欠謱踊蛞约氨砻淖詣由?。字段管理部分可以從數據指標導入派生指標，從表/視圖導入，可以基于已有的物理表或視圖把表結構同步，其中字段可以自定義設置，不關注字段可以隱藏起來，本質上是一個 excel

57、 操作。當模型已保存后需要修改可點擊代碼模式進行修改。十二、DataWorks 智能數據建模-數據開發簡代碼 簡代碼支持根據建模信息自動生成 ETL 簡代碼，代碼中模型信息包含：模型分層化域基礎信息，模型字段中英文，建模依賴的物理表表名及字段名，模型的關聯表關聯表字段信息等；數據開發同學只要基于此代碼進行 casewhen，where 條件等業務信息的補充即可。DataWorks 智能數據建模介紹 56 十三、DataWorks 智能數據建模-數據指標 下圖左側為篩選原子指標、修飾詞、時間周期。右側為在批量選擇完后，會自動生成能夠生成的指標，黃色代表指標沒有生成，綠色代表指標已生成。DataW

58、orks 智能數據建模介紹 57 十四、DataWorks 智能數據建模-數據標準 數據標準會支持字段標準，會對日常用到的一些詞語，做一個標準定義。標準代碼是對字段值有要求。數據標準還有度量單位和命名詞典。當這些內部定義好之后，維度建模過程中都可以做關聯，如果是關聯了標準代碼，可以自動生成質量規則。十五、DataWorks 智能數據建模-多引擎支持 DataWorks 智能數據建模介紹 58 十六、DataWorks 智能數據建模-售賣與價格 DataWorks 智能數據建模目前已經開放售賣，最小規格（small）有首月 199 元試用活動，歡迎大家開通試用體驗。https:/dw-commo

59、n- 智能數據建模需要搭配 DataWorks 增值版本使用，增值版本-專業版目前也有首月 1 元活動。計費區間的對象數量不等于所有表數量，主要指各類模型表與指標的數量，具體計數詳情參考幫助文檔或者智能數據建模產品首頁?？蛻舭咐翰锁B集團數倉建模 59 客戶案例：菜鳥集團數倉建模 作者：王智龍、董晃，菜鳥集團 一、菜鳥末端業務介紹 1.菜鳥末端業務簡介 菜鳥驛站建設的初衷是面向社區和校園，提供最后一公里物流服務平臺，為消費者提供包裹代收、包裹代寄等服務，在此基礎之上基于社區生活，完善末端驛站的服務能力，為消費者提供更多生活服務，比如驛站洗衣、家電清洗等，這就是菜鳥末端業務的定位。接下來介紹菜鳥

60、末端整體業務的情況。2.菜鳥末端業務大圖 業務大圖主要分上下兩部分，下面是我們業務的核心能力，上面是菜鳥末端的垂直業務?？蛻舭咐翰锁B集團數倉建模 60 核心能力包括網絡建設和硬件打造。網絡主要包括網絡拓點、網絡運營和網絡管理。為了提高驛站站點的效率，我們打造了諸多的 iot 設備，如高拍儀、巴槍、云監控、小票打印機、小易工作臺、寄件機等。垂直業務包括代收、寄件、商業化、數智驛站、消費者體驗&運營和綠色公益。3.菜鳥末端業務數倉架構整體設計 基于上面的業務大圖，接下來講講我們的數倉架構：客戶案例：菜鳥集團數倉建模 61 最左邊是菜鳥集團使用的統一大數據開發治理平臺 DataWorks，Data

61、Works 中有很多的功能模塊，包含數據建模、數據開發、任務調度、數據質量、數據地圖、數據安全等等。今天我們將重點介紹的是數據建模部分。右邊是從數據生產到數據消費整個鏈路的數據架構：1)數據源 數據源主要包括業務數據和日志數據，我們通過 DataX/TT（離線/準實時/實時）將數據同步到數倉。2)數據計算 即為數據加工處理，數據加工主要分為 ODS、CDM、DM 和 ADM 四層：ODS：貼源層 CDM：數據中間層 DM 和 ADM 層：DM 主要是在 CDM 基礎上對業務實體的再次抽象，從業務視角對數據資產的沉淀，ADM 是數據應用層 3)數據服務 通過菜鳥數據中臺自有產品天工對下游產品提供

62、 API 服務。4)數據應用 在數據服務的基礎之上，來構建我們的數據產品、數據專項、業務監控報表和智能算法等數據應用。在整個數倉架構中，數倉中間層的建設起到承上啟下的作用，對下兼容和鏈接了底層數據，對上提供通用、易用、豐富的數據，它的好壞可以說決定了數倉的成敗，那么中間層建設經常碰到難題就是數倉規范性，特別是互聯網公司業務變化之快、人員流動性大，數倉規范落地是一個非常頭疼的問題。接下來我們講講菜鳥數倉規范性的一些痛點和對痛點的解決方案?？蛻舭咐翰锁B集團數倉建模 62 4.數倉規范化建設遇到的常見痛點 基于以上的業務背景和數據架構，我們可以了解到業務數倉規范化核心在數據建模，這也是我們今天為什

63、么要重點介紹規范化數據建模的原因。接下里我們總結了下的數倉規范化建設的核心痛點，具體如下：數倉規范和建模實操脫離，很多規范都是在文檔里面，在落地上很難 中間層不夠豐富，煙囪式開發 模型中英文映射詞庫不豐富命名比較痛苦 模型字段同意不同名 模型研發缺少有效的系統工具幫助我們管理好數倉模型 表的 ER 關系不易檢索，數據開發不方便 資產盤點復雜 模型設計問題導致任務報錯多，給運維帶來很大的挑戰 無線上體系化的指標衡量數倉 以上是數倉建設常見的問題，接下來我們再來看看末端數倉規范性存在的問題。5.末端數倉規范性存在的問題分析 從以上數據可以看出末端數倉主要問題還是在中間層覆蓋度，模型復用性、穩定性、

64、健壯性、數據成本上。這些問題背后的具體原因如下：客戶案例：菜鳥集團數倉建模 63 1)公共層覆蓋不足：數據建設過度依賴需求驅動，缺乏業務數據建設的整體規劃和思考，后續一些場景不能快速地滿足業務，導致的問題就是應用層直接先用S 層的表滿足業務的需求。2)核心模型復用性不足：前期對業務了解不深入或考慮不周，導致后續無法滿足業務需求，只能新建模型或者下游直接依賴 S 層。3)核心模型穩定性不足：模型對上游的依賴太深，有些模型依賴層次 10 層以上 跨 bu、跨團隊依賴較多，保障難度加大 混層引用較多，比如 DWD 層反向依賴 ADM 應用層的表 4)模型健壯性不足：模型設計不合理，業務不斷變化時，對

65、模型的沖擊較大需投入更多的人力。5)數據成本不斷增長：不合理的數據生命周期設置 不合理的模型設計以全量表作為主模型，還有過渡的模型設計，比如小時表。這些不好的設計對我們的成本都會有較大的影響 6)數據規范和易用性不足：表和字段的命名規范執行不足 缺乏指標的統一管理 缺乏統一的數據大圖，精品表識別推薦，下游找數難 以上問題的本質主要在數據模型、數據規范管控落地上，所以線上模型管理和規范管控是我們的重點。二、模型管理整體規劃 1.數倉規范化-菜鳥模型管理整體目標 客戶案例：菜鳥集團數倉建模 64 菜鳥數倉從穩定性、擴展性、時效性、易用性和成本幾大方面制定了模型管理的目標。1)穩定性：完善我們數據產

66、出時效和數據質量穩定性，以我們的值班起夜次數和基線破線率、數據質量工單主動發現率為目標。2)擴展性：提升模型變化的兼容性，達到底層業務變動與上層需求變動對模型沖擊最小化，以業務需求支持效率和業務模塊新建核心表數量為目標。3)時效型：提升數據模型產出時效以及需求響應速度，以值班起夜次數和業務需求及時交付率為目標。4)易用性：降低下游使用門檻，復雜邏輯前置，通過冗余維度和事實表，進行公共計算邏輯下沉，明細與匯總共存等為業務提供靈活性，以數倉豐富度為目標。5)成本：避免煙囪式的重復建設以及優化不合理任務消耗，節約計算、存儲成本，以成本執行率為目標。2.數倉規范化-菜鳥模型管理整體方案 圍繞以上 5

67、點目標，我們的模型管理方案主要包含兩部分，分別是模型線上化與模型管理&評估。模型線上化，我們需要有“數據架構委員會”這樣的組織保障團隊，即搭建架構師團隊，并將模型管理責任到數據負責人；接著我們需擬定數倉的規范制度，例如數據模型規范、數倉公共開發規范、數倉命名規范等；最后我們將規范制度和模型負責人通過產品工具 DataWorks 智能數據建模產品進行落地。完成模型線上化只是第一步，接下來模型管理&評估是我們的重點，我們要做到事前模型評審、事中模型評估打分、事后模型治理推送，實現模型管理的閉環，促進模型不斷優化和完善?？蛻舭咐翰锁B集團數倉建模 65 模型線上化主要分為正向建模和逆向建模 2 種方

68、式：正向建模：新模型通過 DataWorks 智能建模平臺完成模型線上設計、評審、發布，實現模型后續線上化管理。逆向建模：存量模型借助 DataWorks 智能建模平臺逆向導入的方式實現模型線上化管理，同時也能對我們數倉模型做一次全面的盤點。3.數倉規范化-正向建模實施流程 正向建模實施流程分為七個步驟，通過 DataWorks 的數據建模即可實現，如下圖所示：客戶案例：菜鳥集團數倉建模 66 4.數倉規范化-逆向建模實施流程 逆向建模實施流程分為五個步驟：通過逆向建模，我們對數倉的業務過程有了更全面清晰的認識和了解，同時對歷史無人維護、低價值模型，進行了下線。最終完成了存量模型 100%線上

69、化管理。我們在逆向建模過程中也發現一些問題，多年積攢下來的歷史包袱，導致數據質量存在風險；多套規范并存，導致命名混亂；相似模型和低價值模型較多。三、數據建模平臺建設 DataWorks 數據建模平臺是菜鳥、大淘系（淘寶/天貓）、盒馬、本地生活等多個部門和阿里云 DataWorks 團隊共建的基于維度建模的數據數倉建模平臺，菜鳥集團作為較早參與的部門，從 2020 年開始與 DataWorks 團隊完成了產品從需求、開發、落地、迭代的整個周期。1.智能數據建模平臺規劃 菜鳥通過對所需功能進行梳理，總結出從規范定義、便捷開發、發布評審、業務管理四個模塊來研發這個建模工具：客戶案例：菜鳥集團數倉建模

70、 67 1)規范定義 在前期，菜鳥是沒有這個數據建模平臺的，大家都是以線下的建模方式，比如對 Excel梳理后，進行數據探查之后進行模型的設計，然后再線下進行模型評審。整個模型設計和評審都在線下。最終導致大家數據建模的時候沒有形成一個規范，數據開發過程是不嚴謹的，下游有了大量的引用之后，切換的成本也非常高，模型維護的成本非常高，變得越來越差。所以我們希望將規范的定義搬到線上，上圖中列出了線上規范定義的主要內容。2)發布評審 之前我們的評審也是在線下進行，在架構師和工程師比較忙的時候，評審流程就不夠嚴謹，甚至沒有走評審的過程就直接發布了，所以我們希望將這個功能也搬到線上去。發布前我們會對表命名、

71、字段命名進行強校驗，同時支持多引擎發布，比如我們的離線數據存在 MaxCompute 或者 Hive 上面，還有一部分數據存在 MySQL 或者Oracle 上面等等。影響性檢查是模型發布之后，對于下游的引用這個模型的 ETL 腳本是不是有一些影響，比如有的時候我們新增了一個字段，下游同學使用的時候是select*的方式，而他的表沒有新增的這個字段，就會導致下游任務報錯?？蛻舭咐翰锁B集團數倉建模 68 3)便捷開發 這是核心重要的一點。我們希望將建模方式從線下搬到線上之后，不要影響大家的開發效率，所以我們設計了各種提高效率的便捷開發功能。4)業務管理 這是從使用的角度上來說的。對于研發人員來

72、說，我們有業務分類和數據域的視角，對于業務人員來說，我們提供數倉大圖和數據字典的視角。從成本治理的角度來說，比如一些歷史上的模型可以做歸并或下線。菜鳥集團將以上能力與 DataWorks 的數據建模平臺緊密結合，沉淀了數倉規劃、數據標準、數據建模、數據指標四大核心功能模塊，接下來將為大家逐一介紹菜鳥集團的使用情況。2.智能數據建模平臺核心功能 客戶案例：菜鳥集團數倉建模 69 3.核心功能規范定義 規范定義分為分層劃域和表名規范兩個部分：1)分層劃域 我們將數據分為 ODS、DWD、DWS、ADS 和 DIM 五層。我們有 12 大級的業務分類，菜鳥就是其中的一個業務分類。同時業務分類下面還有

73、一些子級的業務分類。有 13 個數據域，比如快遞、財務等等和若干的業務過程。2)表名規范 我們有 6 類的表名命名規范。因為在業務發展的過程中，之前可能業務分類只定了一級，后面發現一級業務大類并不能幫助我們在數倉建模的過程中有效地表現規范性，于是就迭代出二級業務分類。4.核心功能逆向建模 無論是維度建模和 Fast 建模，都要經過概念模型設計、邏輯模型設計和物理模型設計三個必要階段。逆向建模是物理模型設計到邏輯模型設計的過程，也就是 Hive 數據庫已經有了 N 張表，需要把它反向到邏輯模型中，這就是一個逆向的過程?？蛻舭咐翰锁B集團數倉建模 70 需要逆向建模的大部分是歷史的不規范的表，菜鳥

74、對于這些表是沒有改造要求的，這些表可以通過批量逆向和 FML 批量調整來實現逆向建模。批量逆向設計的主要目的是將幾千張表順移到數據倉庫里面，通過表名的正則表達式匹配進行一個批量的逆向。正則匹配只針對當前遵守最新規范的表，對于不是很規范的表可以通過 FML批量調整。FML（Fast Modeling Language）是 DataWorks 團隊開源的，用于維度建模領域快速構建的 DSL 語言，主要目標是提供一套 kimball 維度建模理論下，結合大數據開發場景下的一種領域特定語言。原來的 Hive 建表的時候我們不能指定業務分類、數據域和業務過程的，現在通過 FML 語言就可以調整，這樣就可

75、以對不規范的表進行批量調整。5.核心功能多表克隆 客戶案例：菜鳥集團數倉建模 71 之前在模型設計的過程中，最常用的一個建模過程就是對源表進行數據探查，再進行模型設計。我們可能需要從 N 張表中選取我們所需要的字段，對已有的表的字段進行勾選、順序調整，最終形成一個邏輯模型。以前在線下對這樣的過程可能就是從 Excel 中將多張表的字段全部拷貝出來，選取自己所需要的字段，再進行一個字段排序等等?，F在我們可以通過多表克隆功能選取我們所需要的表，這些表可能不僅僅是我們自己 ODS 層的表，也可能跨 project、跨企業引用，在多表克隆界面這些表都可以被選擇，通過勾選字段的方式來建模，并生成簡單的

76、ETL 腳本，省去自己手動寫許多 ETL 腳本的過程。6.核心功能代碼模式 代碼模式是在研發過程中比較提效的一個功能。有時候上游的產品或者研發發布了功能之后，會給數倉開發同學一個簡單的腳本來告訴數倉怎么來取數。數倉開發同學需要評估是不是要在數倉中新增一張表，數倉開發同學希望直接將腳本提交到建模平臺上去，這個腳本基于數倉開發同學選擇的字段或定義的一些簡單函數（比如sum）還有別名，將這些字段自動歸并到模型的字段中去，這就是代碼模式的主要功能。代碼模式必須定義好表命名并保存，才可使用。7.核心功能Excel 代碼模式 有些數倉開發同學，對 Excel 操作很熟練，覺得 Excel 操作很方便。所以

77、這里設計了Excel 批量導入和 Excel 交互兩個功能?？蛻舭咐翰锁B集團數倉建模 72 Excel 批量導入通過標準模板，定義表名、業務分類、字段、字段類型、字段備注等等，然后將這些模板批量導入到建模平臺。另外一個功能是 Excel 交互，該功能可與本地 Excel 無縫銜接。批量導入之后，如果想修改 Excel 里的某些東西，可以將內容拷貝到本地 Excel，修改完后再將本地 Excel 拷貝到建模平臺，Excel 交互界面右鍵集成了常用的批量操作，方便使用。8.核心功能發布評審 之前菜鳥的數倉是沒有這個環節的，現在希望將這個功能給用起來。評審按照數據域的劃分定義評審人，實現評審組功能

78、，一人通過即通過。目前只實現簡單評審流 客戶案例：菜鳥集團數倉建模 73 程，模型相似度、描述豐富度、血緣等衡量模型好壞的指標、輔助評審都在后續的規劃中。這個功能首先是用在模型評審時，其次是用在數據治理時，已經產出的模型也可以根據模型相似度、描述豐富度、血緣等衡量模型好壞的指標，輔助開發同學進行模型的優化。9.核心功能智能翻譯 智能翻譯是一個比較重量級的功能。企業的數倉中有很多的命名的詞典，將常用的中文對應的英文作為數倉的一個規范，目的是為了保證數倉模型有一個統一的辨識度，智能翻譯完成中文的翻譯與詞根的維護。10.核心功能數倉大圖 客戶案例：菜鳥集團數倉建模 74 基于業務使用視角，我們提供了

79、數據字典，通過平臺導出功能，可以生成 Excel 格式的數據字典，包括表名、分層、數據域、業務過程、字段等詳細信息，提供給業務人員使用。數倉大圖沒有在數據建模平臺實現，DataWorks 團隊正在研發一個數據資產管理平臺，將會實現一個 3D 的資產全景構建。四、總結&展望 1.菜鳥數據模型管理建設成果 菜鳥數倉團隊從 2020 年開始與 DataWorks 團隊不斷共建智能數據建模產品，從最初版簡單的錄入系統，到集成逆向建模、多表克隆、多種引擎的代碼模式、excel 交互等功能，極大提升了建模規范和研發效率，成為菜鳥落地數倉規范的統一平臺，取得的建設成果如下：規范：輔助數據體系規范化建設，將規

80、范落到實處，同時將菜鳥幾千張模型表，逆向建模到我們建模平臺上來。降本：在逆向過程中我們發現了歷史上很多不規范的表，或者需要合并的表，或者表已經沒有下游訪問了，這時候就可以將模型表刪除，物理表下線，過程中我們整體下線了 15%的模型表，對于我們降本的方面還是比較明顯的。沉淀：把建模的過程從線下轉為線上，沉淀企業級核心數據資產。提效：減少人員溝通成本，產品化支持快速建模以及開發打通，并且不會降低我們建模和研發的效率，開發效率大概提升 30%左右。多樣：面向業務視角自頂向下進行規范建模與面向開發視角自底向上構建數倉，雙管齊下，相輔相成。從 0 到 1，自頂向下是最規范的，但是開發過程中，1 個小的需

81、求，面向業務的，也可以在這個建模平臺上完成。使用人數：在產品使用方面，我們已經讓菜鳥的末端團隊與公共團隊全員使用數據建模平臺?？蛻舭咐翰锁B集團數倉建模 75 2.建設成果展示 下圖是之前提到的分層劃域等建設成果。模型管理體系是我們數據建模平臺未來計劃要集成的一個功能，主要有以下 5 個方面。研發規范健康分：包括命名規范、注釋、SQL、數據類型的規范等 數據質量健康分：是否設置了主鍵、是否有異常比如今天有 10 條數據，明天有100 條數據，是否在業務允許波動的范圍以內。計算/存儲健康分：包括簡單加工、是否有下游、模型表是否有生命周期，有些表訪問的是近 3 個月的數據，但是保存了近 10 年的

82、數據，這個時候可以調整生命周期?？蛻舭咐翰锁B集團數倉建模 76 穩定性健康分：菜鳥的數倉穩定性保證是有基線與值班機制的，我們的DataWorks 監控基線是否破線，以及數據延遲/報警導致的值班起夜率是我們重點考量的。通用健康分：復用度展現我們模型表下游的訪問度如何，完善度展現模型表信息的完整性，我們的業務人員拿到這張表后是否可以理解，以及模型的相似度、血緣的相似度等等。五、提問 Q：菜鳥的建模是基于 DataWorks 做定制化開發嗎？A：建模平臺是我們和 DataWorks 共建的，我們是建模平臺的一個使用方，也會把使用中的一些問題提給 DataWorks 來迭代優化。外部用戶也可以在阿里

83、云上開通DataWorks 來體驗這個數據建模產品，和集團內的版本沒有太多區別。Q：歷史數據有變動的情況，每一層應該怎么處理？A：對于歷史變更比較頻繁的數據，建議做一個歷史全量表。對于變更不頻繁的數據，建議做一個每日增量，比如說最近 90 天變更。這個可以根據業務數據變更的頻繁程度來做一個合適的模型設計。Q：模型是怎么打分的？怎么控制數倉 SQL 規范？A：開發人員寫 SQL 容易出現跨層依賴。首先是 SQL 規范，DataWorks 提供了很多檢查器的功能，可以監測到數據上很大一部分問題，比如 select*。其次是模型打分，主要從模型的規范和成本、穩定性和通用性來評估模型的好壞，將這幾個維

84、度綜合起來來給模型打一個分?？蛻舭咐翰锁B集團數倉建模 77 Q：正向數據模型只是建一個表結構嗎？建模后如何灌入數據？與寬表打通？A：正向數據模型不只是建一個表結構，還需要將模型物理化，物理化后再進行數據的灌入，后續還有很多 ETL 開發功能在里面?？蛻舭咐汗I OT 域數據最佳實踐 78 客戶案例：工業 OT 域數據最佳實踐 作者：張為，阿里云全球技術服務部 一、傳統維度建模的方案介紹 數倉建設中常用的方式是維度建模，其核心是將原表分為事實表和維度表。然后采用星型模型或者雪花模型進行數據建模。星型模型，是一種非常簡單常用的模型，事實表直接和多個維度表相連，維度表之間無連接。雪花模型，事實表

85、與多個維度表相連，維度表之間有連接。阿里內部在維度建模理論基礎上，對數據的分層分域、維度一致性、事實表設計、原子指標/派生指標的定義及設計等做了細化定義，同時定義了一套標準的從設計到開發的實施流程。1.維度建模工作流程 維度建模工作的實施流程如下圖所示。需求調研：分為自底向上和自頂向下兩種，自底向上是從現有的業務系統入手，從業務上分析數據域、業務過程，了解數據需求。自頂向下是和實際報表使用人員了解需求，依據報表 SQL 反向推導所需的數據源及指標信息。數據域劃分：對數倉建設涉及的數據類別進行劃分，一般可以按照行業標準或者業務系統功能模塊來劃分?？蛻舭咐汗I OT 域數據最佳實踐 79 指標設

86、計：構建總線矩陣，梳理原子指標及派生指標清單，以及原子指標的溯源、派生指標的計算邏輯等。數 據 建 模：構 建 一 致 性 維 度，構 建 一 致 性 度 量 及 指 標，分 層 設 計DWD/DWS/DIM/ADS 模型。數據開發：物理表創建，數據業務邏輯 SQL 開發。任務運維：數據開發任務運維。從工作流程可以看出，維度建模的任務鏈路是比較長的，同時其工作量和指標規?；境烧?。涉及的指標量越多，調研、設計、開發的工作成比例的增加。2.維度建模使用場景及特點 維度建模廣泛應用于 IT 域數倉建設的場景中，該類場景的特點是原始數據來源于業務系統各功能模塊，數據可以很自然的分為維度表和事實表，

87、同時掛載到類似業務板塊、業務過程這種概念上，通過統一的一套方法論即可對不同的場景、不同的數據源完成建模設計。雖然使用的建模方法論和流程是相同的，但是對于不同的指標設計是不同的，即當增加一個場景的指標時，需求調研、指標設計、模型設計、開發運維這個過程需要完整的走一遍，因此項目的實施工作量和指標數量基本成正比關系。二、工業 OT 域場景描述 在工業業務場景下，在生產產線上存在大量的 IOT 設備的測點數據，和 IT 域數據相比，這類數據量很大，但格式比較統一，核心字段包括設備 ID、時間戳、測點值、數據類型幾個，數據類型可以分為兩種，第一類為模擬量數據，例如設備的溫度、電流、電壓、喂料量等，這類數

88、據為一個連續值，第二類數據為開關量數據，當設備開機時上報 1 信號，設備關機時上報 0 信號。對于這些原始 IOT 數據，存在大量指標計算的需求，相比于傳統的維度建模，這類指標計算模式相對比較固定，指標大致可以分為單點位測點值的聚合計算和多點位測點值的公式計算兩種，對于聚合計算就是統計一段周期內的最大、最小、平均值之類的指標。公式計算帶具體的業務含義，例如電流*電壓*運行時長等于電量消耗，喂料量*產量系數/運行時長等于臺時產量?？蛻舭咐汗I OT 域數據最佳實踐 80 1.工業 OT 域場景特點 從前面的描述可以看出，在工業 OT 數據域的特點是指標的量很大，但是計算方式相對比較簡單，且可以

89、枚舉或者歸納。工業 OT 數據域下，一個車間往往就有上萬個設備點位，每個點位的數據都需要做聚合計算，且存在大量的通過類似電流電壓運行時長等于電量消耗這種公式計算的指標，因此做成千上萬個指標計算是常態。參考維度建模中的指標分類，可以把原始的測點值定義為原子指標，將周期的聚合計算結果定義為派生指標，帶有具體業務含義的公式計算得到的指標定義為衍生指標。分析可以發現，這里的原子指標雖然量很大，但是其格式是固定的。派生指標的計算可枚舉，都是最大、最小、平均值之類的周期聚合計算。而衍生指標，雖然計算公式不可枚舉，但是其計算形式都是一樣的，基本都是通過一個四則運算的公式進行計算。2.工業 OT 域指標計算現

90、狀 對于工業 OT 域的指標分類和計算，目前行業內有一些各自的實現。例如某公司的ETL 過程將指標計算明確分為兩步，第一步為單點位的聚合計算，將原始點位數據的周期內最大、最小、平均值、差值等聚合指標定義為一次指標，第二步為多點位的公式融合計算，將基于一次指標進行公式計算后的結果定義為二次參數。阿里的工業數據應用平臺將指標定義為數據轉換和數據統計兩類，數據轉換可以對原始的點位數據進行各種清洗轉換操作，數據統計可以設置統計周期，計算統計周期內的數據統計量（包括聚合計算和公式計算）?？梢钥闯鰧τ?OT 域的指標計算需求是比較清晰的，各自的實現也有相似之處，但相比于標準的維度建模，現在并沒有一個很統一

91、定義，以及實現方案。例如上面的某公司雖然將指標比較清晰的分成了兩類，但在最后計算完成后所有的指標都存放在同一張表中，并沒有模型分層的概念，同時整個過程基本不涉及數據治理的動作；阿里目前的工業數據應用平臺能力比較強，能實現各種數據轉換和計算，且把計算動作分成了轉換和統計，但同樣的并沒有做指標的分層定義，從建模的角度來看是稍顯混亂的?？蛻舭咐汗I OT 域數據最佳實踐 81 三、指標工廠實現思路 由于在 OT 數據域下，指標的特點是數量特別大，但是其計算方式可枚舉或者可歸納，因此可以在現有方案的基礎上，參考維度建模定義標準的建模分層，同時設計批量指標定義和計算的實現方案，實現批量的指標的定義及加

92、工計算。1.指標工廠實現思路 指標工廠建設思路是，OT 域建模分層和傳統 IT 域維度建模一致，但是設計開發過程有比較大的差異，不需要對單個指標做復雜的設計，可以通過工廠化配置的方式批量定義和計算。1)對原始采集定位的數據定義清洗轉換規則，得到基礎的原子指標。2)定義原子指標計算方式（聚合函數），計算方式可枚舉，通過周期聚合計算得到派生指標。3)自定義衍生指標計算公式，計算公式只涉及派生指標之間的公式計算，不涉及其他約束條件。通過這種設計方式，通過幾個計算任務即可完成原子指標、派生指標、衍生指標的批量計算，當業務場景需要增加指標時，只需要增加對應的指標計算公式即可。2.指標工廠與維度建模的關系

93、 通過指標工廠的思路，可以在 OT 數據域下快速的定義及生成指標，和傳統的維度建模概念類似，分為原子指標、派生指標、衍生指標等。區別在于傳統 IT 數據域下，數據源的形式（數據源來自不同業務表）及指標計算方式（包括統計周期、修飾詞、維度、計算公式等）比較難統一，因此基本上需要對 客戶案例：工業 OT 域數據最佳實踐 82 每一個指標做建模設計。而 OT 數據域雖然數據源量特別大，例如一個車間可能就有上萬個點位的數據，但是其數據格式是一樣的，可以放在一個表中用 ID 區分不同點位數據，指標計算的方式也是比較統一的。維度建模設計示例（總線矩陣）維度建模示例 如上圖所示，維度建模需要對每一個指標做比

94、較詳細的設計，且不同的指標計算大多是需要在不同的任務中去計算。而 OT 域下基于指標工廠的指標設計和計算會簡化很多，通過批量定義原子指標的統計類型，以及派生指標的計算公式，用幾個任務即可完成所有指標的計算。IT 域建模與 OT 域建模差異 客戶案例：工業 OT 域數據最佳實踐 83 四、基于 DataWorks 實現指標工廠 DataWorks 數據建模支持數倉規劃設計、制定并沉淀企業數據標準、維度建模、數據指標定義，通過使用 DataWorks 數據建模，可以將建模設計產出的分層模型表物化到計算引擎中并進一步應用?；?DataWorks 數據建模功能，可以快速實現指標工廠概念中的原子指標和

95、派生指標，以及表模型的定義和創建。1.數倉分層設計 OT 域指標建模和 IT 域一樣，可以把數倉分為貼源層、公共層、應用層等。2.原子指標定義 這里實際上是定義在計算派生指標時原子指標的聚合方式，由于聚合方式是可枚舉的，可以在這里把原子指標全部枚舉定義出來?？蛻舭咐汗I OT 域數據最佳實踐 84 3.派生指標批量定義 通過批量選擇原子指標、時間周期即可實現派生指標的批量定義，完成不同周期，不同聚合方式的派生指標定義?？蛻舭咐汗I OT 域數據最佳實踐 85 4.模型表定義 通過快速導入的方式，可以實現將上一步定義的不同統計周期的派生指標批量的導入至模型表中。通過派生指標做公式計算得到衍生

96、指標，在建模過程中沒有標準的定義，在具體實施的時候可以通過一個前端來做公式的配置，公式存儲在配置表中，在指標計算的時候讀取配置表中的公式信息，然后關聯獲取依賴的派生指標值，再做批量的計算即可得到衍生指標結果值。五、項目實踐 基于指標工廠的思路進行 OT 域指標設計和開發已經在多個項目中進行落地實施，以某水泥項目為例，阿里云全球交付技術服務部基于指標工廠建設思路完成上萬個測點派生指標的計算以及數百個衍生指標的設計和計算。例如水泥產量等指標信息，通過統計類型配置及公式配置即可完成計算輸出，并支撐前端的大屏展示?？蛻舭咐浩囆袠I數據建模最佳實踐 86 客戶案例：汽車行業數據建模最佳實踐 作者：蘇冬

97、妮，阿里云全球技術服務部 一、企業需求與現狀介紹 本篇文章將圍繞某汽車企業項目上的智能建模實踐展開，為您介紹汽車生產業務的建模工作細節。該項目總規模涵蓋了生產車間 IOT 平臺，生產系統平臺，數據中臺以及其他智能化數字應用幾大模塊。數據鏈路也是自下而上依次生長。數據建模工作內容是在建設數據中臺時的一個重要環節，需要我們為客戶從零到一搭建汽車生產業務的數據分析指標體系。數據架構 工業企業的數字指標建設，一切都是圍繞快速，實用為導向來開展工作，存在著以下特點：客戶案例：汽車行業數據建模最佳實踐 87 缺少成熟的數字研發人員陣型，對汽車生產領域的指標需求不明確。注重研發規范、業務標準。自帶工業基因，

98、對工作進度體感要求較高。因此，在開展建模的工作的時候，我們主線圍繞著 One Data 方法論，同時也有選擇地結合了客戶實際業務情況，幫助其打造整個數據中臺模型體系。二、數據建模工作實施步驟 在該車企展開的建模工作主要分為如下幾個步驟：業務調研、指標需求確認、規范定制、建模設計。建模步驟 三、業務調研 業務調研需要從三個維度入手：業務模塊調研、需求調研、數據調研。1.業務模塊調研 1)工廠物理結構以及業務調研 理清客戶的內部業務邏輯。對于汽車生產，我們了解到客戶的生產車間有 5 個，分別是沖壓車間、焊裝車間、總裝車間、涂裝車間、電池車間，是一個很典型的整車廠的陣型。每個車間分別由不同的線體組成

99、、每條線體分別由不同的工位組成。每 客戶案例：汽車行業數據建模最佳實踐 88 個車間、線體、工位之間功能各不相同，裝配步驟也各不相同。車體在生產過程中，會依次通過車位進行裝配。一個車體的生產需要經歷：下訂單-生產計劃下發-生產計劃接收-生產流程-Andon 告警(非必需)-車輛檢查-質量返修（非必需）-車輛下線這幾個步驟。每個步驟又可分化出不同的動作流程。生產流程總線矩陣 2)需求調研 需求調研主要在于了解清楚客戶的業務通點、需要我們解決的事情是什么。有些客戶可能內部已經有數據分析場景，會比較清晰地知道自己想要落地的指標是什么，有些客戶則可能對一些業務模塊能產出的指標沒有概念，不知道自己要做什

100、么，能做什么。本次我們的客戶需求較為明確：進行生產域的分析體系建設。故交付工作也圍繞著生產模塊來開展，其他業務板塊暫不涉及。3)數據調研 上層系統圍繞著車間生產活動進行建設，IOT 平臺設備會采集車間的硬件設備信息，包括不限于工位過點信息、設備告警信息、物理信息比如溫度等。這些數據會路由到車間生產系統，并進行二次生產使用加工，幫助工廠工作人員管理和掌控車間的生產狀態。因此，除了少量的離線非結構化數據外，我們的數據來源也基本為這兩個線上系統。除了數據來源，我們還需要調研數據結構，更新方式，質量等特性?？蛻舭咐浩囆袠I數據建模最佳實踐 89 數據調研關注內容 四、指標需求確認 參考業務流程調研結

101、果和總線矩陣，確定出可以產出的指標以及指標衍生維度。比如，對于汽車生產流程下的各個動作步驟可以產生的一些指標如下：業務動作下產生的指標示例 客戶案例：汽車行業數據建模最佳實踐 90 1.規范制定 1)命名規范 在進行模型設計之前，需要約定好數倉各個層級表的命名規范。一方面統一的規范命名可以幫助我們提高開發效率，見名知義；一方面可以避免重復開發，減少資源浪費。常見的一個表的命名要結合所在數倉層級、涉及到的業務模塊、業務動作過程、以及更新方式和時間周期組合生成。在此項目中我們用到的命名規則如下：表命名規范 2)更新規范 更新分為全量更新和增量更新。一般來說，在離線計算采用每天新增一個分區，將當天新

102、更新的數據寫入該分區中?？紤]到此客戶的資源較建行和數據量較大，我們決定采用增量更新寫入，再在下游用全量合并成當天全量表的方式來存儲，這樣可以節省存儲資源，縮短數據同步時間。3)度量標準 為指標制定統一的度量，避免因為度量體系不一致導致后期數據質量問題，為使用者帶來困擾。此項目中涉及到的實體與度量的關系如下：客戶案例：汽車行業數據建模最佳實踐 91 實體與度量關系 4)詞典 詞典與命名規范和度量息息相關，在描述統一實體時統一規范我們的措辭，可以幫助我們提升溝通效率。詞典 客戶案例：汽車行業數據建模最佳實踐 92 2.模型設計 層級設計：共分為 ODS 層、DWD 層、DWS 層、ADS 層。其中

103、 DIM 層、DWD 層與DWS 層也可被統一稱為 CDM 層。每一層的定位和用途各不相同。1)數據引入層 ODS（Operation Data Store）存放未經過處理的原始數據至數據倉庫系統，結構上與源系統保持一致，是數據倉庫的數據準備區。主要完成基礎數據引入到 MaxCompute 的職責，同時記錄基礎數據的歷史變化。我們的 ODS 層本次共接入了上千張表。分別來源于 IOT 系統和生產系統，有少量來源于離線的文件。同時，我們在傳統的 ODS 分層內，劃分了兩層，最底層為初始化全量，每天增量更新的貼源層，在它的下一層，我們做了全量清洗合并，存儲每天的全量數據。2)數據公共層 CDM（C

104、ommon Data Model，又稱通用數據模型層）包括 DIM 維度表、DWD 和 DWS，由 ODS 層數據加工而成。主要完成數據加工與整合，建立一致性的維度，構建可復用的面向分析和統計的明細事實表，以及匯總公共粒度的指標。3)公共維度層（DIM）基于維度建模理念思想，建立整個企業的一致性維度。降低數據計算口徑和算法不統一風險。公共維度層的表通常也被稱為邏輯維度表，維度和維度邏輯表通常一一對應。在此項目中，我們共沉淀了 10 張以上的維度表，按照不同的車間做區分，分別是工人值班信息，車間空間信息（包含車間、線體與工位的對應關系），車體信息，能耗信息，質檢缺陷信息，Andon 告警信息等。

105、由于電池車間內的線體較為特殊，線體之間各自獨立，具有不同的生產功能，維度表在使用和設計時和其他車間有所區別?？蛻舭咐浩囆袠I數據建模最佳實踐 93 維度字段 4)明細粒度事實層（DWD）以業務過程作為建模驅動，基于每個具體的業務過程特點，構建最細粒度的明細層事實表。DWD 層在某些情況下會被用來存放原子指標，本次項目中，我們將最細粒度的明細記錄數據存放在本層。比如，涉及到車輛產量的指標，均依賴于車體在經過線體上各個工位的過點信息計算得來。因此，我們設計了一張車輛過點信息明細表，記錄每個車間各個車體通過工位點位的明細記錄。車體過點記錄表主要明細 客戶案例：汽車行業數據建模最佳實踐 94 5)公

106、共匯總粒度事實層（DWS）以分析的主題對象作為建模驅動，基于上層的應用和產品的指標需求，構建公共粒度的匯總指標事實表，以寬表化手段物理化模型。此次我們并沒有在 DWS 層進行大量寬表設計，而是將原子指標以及復合指標存放在 DWS 層，從 DWD 層引用明細數據進行計算得出結果，為下游的應用層寬表提供公共指標。某汽車生產管理匯總表 6)數據應用層 ADS（Application Data Service）也叫集市層，存放數據產品個性化的統計指標數據。根據 CDM 與 ODS 層加工生成。我們將不同業務方使用的主題寬表存放在這里，由 DWS 層的公共指標關聯得來。同時，由于使用人員各自涉及的業務表

107、不同，我們還對不同的業務模塊人員進行了不同的寬表權限的隔離?？蛻舭咐浩囆袠I數據建模最佳實踐 95 某汽車生產管理主體寬表 五、數據模型落地 基于以上設計，阿里云全球技術服務團隊與 DataWorks 產品團隊合作，通過智能數據建模產品將以上規范在客戶生產環境落地。DataWorks 智能建模產品分為四個模塊：數據指標、數據標準、數倉規劃、維度建模。1.數據指標 分別包含派生指標、原子指標、修飾詞、時間周期四個模塊。1)原子指標 原子指標用于明確業務的統計口徑和計算邏輯，是基于用戶的業務活動（即業務過程）創建的，用于統計業務活動中某一業務狀況的數值。比如，車的產量是根據車體過點記錄中通過車間

108、下線工位為準，故以車體過點記錄明細表加上下線業務動作約束，可以得到車的產量?？蛻舭咐浩囆袠I數據建模最佳實踐 96 實際產成品數量原子指標 2)派生指標 派生指標通常由原子指標+時間周期+一個或多個修飾詞組成。因此，派生指標關注的點為原子指標、時間周期、修飾詞以及所屬的業務過程。并且，由于公共層和應用層的定位均可存放派生指標，故也要指定好其所屬層級。比如，我們要計算近 1天的 XX 車型實際產量，需要通過“車體實際產量+1d+XX 車型”得到。某派生指標 客戶案例：汽車行業數據建模最佳實踐 97 3)修飾詞 修飾詞是一種業務修飾，用來圈定或者聚焦統計數據的業務范圍和限定。在此產品中，修飾詞被

109、分為普通業務修飾詞和維度枚舉修飾詞。車型信息可以作為一種修飾詞，去結合其他的原子指標，衍生出車型維度下的各個派生指標。某修飾詞 4)時間周期 時間周期是用來明確數據統計的時間范圍或者時間窗口，例如近 1 天，近 1 自然周。用于在統計派生指標時，限定業務統計的時間范圍。本次項目中用到的時間周期有，近 1 天，近一周，近一個月，近一個季度，近一年，每日，每月，每季度，每年。時間周期示例 客戶案例：汽車行業數據建模最佳實踐 98 2.數據標準 DataWorks 的數據標準包含字段標準、標準代碼、度量單位、命名詞典。1)字段標準 字段標準又稱為數據字典，可理解為全局字段管理?？蓪⒍鄠€表中含義相同但

110、字段名不同的內容進行關聯，并對該字段制定相關的取值范圍、度量單位、標準代碼等內容。如圖：對實際產成品數量的精度做了定義。字段標準 2)標準代碼 標準代碼是數據標準的取值范圍，在標準代碼中可設置某一數據標準可選擇的數據的內容以及范圍。某標準代碼 3)度量單位 字段參數的數量單位（如個、厘米等）。如圖，為常見時間單位?？蛻舭咐浩囆袠I數據建模最佳實踐 99 度量單位示例 4)命名詞典 某命名詞典 3.數倉規劃 數倉規劃包含了數據分層、業務分類、數據域和業務過程。1)數據分層 DataWorks 默認有五層數倉分層：數據引入層 ODS，明細數據層 DWD，匯總數據層 DWS，應用數據層 ADS，公

111、共維度層 DIM?？蛻舭咐浩囆袠I數據建模最佳實踐 100 數倉分層示例 2)業務分類 本次項目共劃分了六個業務模塊：汽車生產業務模塊示例 客戶案例：汽車行業數據建模最佳實踐 101 3)數據域 數據域是一個較高層次的數據歸類標準，是對企業業務過程進行抽象、提煉、組合的集合。某數據域 4.維度建模 DataWorks 的智能建模遵循 Kimball 維度建模理論。在此模塊中，我們需要分別定義出維度表，明細表，匯總表的結構。某維度表 客戶案例：汽車行業數據建模最佳實踐 102 某明細表 某匯總表 六、總結 在建設的過程中，我們通過和車間負責人調研的方式了解各車間的生產業務和系統使用特點，最終圈

112、定了生產、質量、設備和成本四個業務域來建設指標模型?？蛻舭咐浩囆袠I數據建模最佳實踐 103 最終，我們在該企業共沉淀了 100+個指標，按照車間、線體、工位、設備、車輛、班次、能耗類型、缺陷類型、告警類型等 10+種不同維度延伸。幫助支撐了 5 個以上應用及報表系統。同時 DataWorks 智能建模產品在項目中的使用，使我們在梳理建模工作步驟時更加規范化、體系化，對接工作不再是依賴于散亂的文檔，而是把每一步的產出都沉淀到工作臺上?？梢钥吹轿覀兘５拿恳粋€步驟都在平臺上做了落實，對初次參與建模工作的人來說，是非常友好的：有時面對復雜的建模流程，經驗不那么豐富的工作人員可能會感到無從下手，靠

113、著產品的引導可以很大程度幫助解決這個問題。后續我們也會將各個行業中的經驗沉淀成行業數據模型模板，加速行業數據規范化建設?？蛻舭咐捍筇韵禂祿Ｐ椭卫碜罴褜嵺` 104 客戶案例：大淘系數據模型治理最佳實踐 作者：郭進士，大淘系數倉團隊 導讀 本次分享題目為淘系數據模型治理，主要介紹過去一年淘系數據治理工作的一些總結。具體將圍繞以下 4 部分展開：模型背景&問題 問題分析 治理方案 未來規劃 一、模型背景&問題 1.整體情況 首先介紹一下淘系的整體數據背景?？蛻舭咐捍筇韵禂祿Ｐ椭卫碜罴褜嵺` 105 淘系的數據中臺成立至今已有 7 年左右，一直未作數據治理，整體數據生成構成比為：人工創建（22%

114、）+機器生成 78%。其中活躍數據占比：9%，不規范數據占比：21%。數據活躍以倒三角形狀分布，整體分布比例為 ads:dws:dwd:dim=8:2:1:1，分布還算合理。上圖中下半部分是模型的生命周期，增長和留存情況。淘系的業務還屬于快速變化中，模型變化比較快。模型生命周期為 25 個月，模型年增長比例 30%，模型留存44%。2.公共層 公共層兩大核心問題為：首先，公共層表復用性不高。在 2014 年的時候公共層還比較規范，但可持續性不強。隨著時間流逝，業務增長和變化，復用性就逐年降低。因為大部分的數據是應用層做的，他們會開發自己的公共層，復用性降低，大部分都是無效表。另外，公共數據表在

115、各個團隊分布不合理。這是由于數據團隊多，為了滿足業務開發效率，每個團隊都有自己的公共表，容易出現公共表復用占比低，重復建設的場景。其中淘寶數據團隊負責最多的公共數據表?？蛻舭咐捍筇韵禂祿Ｐ椭卫碜罴褜嵺` 106 3.應用層分析 應用層的主要問題包括：第一，公共層建設不足或公共層透出不足。隨著時間增長，公共層的指標不能滿足 ads 層的業務需要，ads 復用指標邏輯沒有下層，引用 cdm 層的 ads 表占比逐年降低，引用 ads 的 ads 表占比逐年增高。第二，較多的 ads 表共性邏輯未下沉，統計顯示超過 17.63%ads 表被下游 ads復用。第三，跨集市依賴嚴重，統計顯示，整體跨集

116、市依賴占比為 30%，特別是大進口和淘寶數據跨集市依賴達到了 40%，影響模型的穩定性，影響了模型的下線、修改。二、問題分析 1.問題匯總 以下這副圖是簡化后的數據模型，我們可以發現存在很多不規范問題影響了模型的穩定性。業務在快速發展的情況下，為了快速響應業務需求，產生模型問題是必然的。日常工作中，數據研發流程大致如下，接到業務需求，直接引用 ODS 層表開發ADS 數據，待數據需要復用的時候就把邏輯沉淀到公共層，同理指標也會有類似情況?？蛻舭咐捍筇韵禂祿Ｐ椭卫碜罴褜嵺` 107 主要問題可以歸納為七點：系統臨時表多，只增不刪，對于消費側影響較大，因為表量巨大，有效比例低，很難檢索到。命名不

117、規范。公共層過度設計。ADS 重復建設。ADS 跨集市依賴。ADS 共性未下沉。ADS 穿透依賴 ODS。2.原因分析 從問題分類上看，主要有三大類問題：規范性問題，公共層復用性問題和應用層復用性問題。從問題原因上看，主要有四大類原因：架構規范，流程機制，產品工具，以及研發能力?？蛻舭咐捍筇韵禂祿Ｐ椭卫碜罴褜嵺` 108 3.模型治理的問題 模型治理的挑戰：業務價值不明顯，治理帶來的是長期價值，短期對業務影響不大。治理協作復雜，治理需要 ODS、CDM、ADS 層多人多團隊協作。問題治理難根治，容易出現新模型依賴有問題模型。模型平均生命周期不長（25 個月）。綜上所述，模型治理的 ROI 比

118、較低，我們的問題就是如何模型治理才最高效？客戶案例：大淘系數據模型治理最佳實踐 109 三、治理方案 1.整體方案 基于以上的問題原因分析，我們制定了如下治理方案。核心策略為以下三點：1)盤點存量，掌握數據的整體情況。2)規范增量，避免新增模型走老路，重復出現相同問題，考慮到數據的生命周期，歷史數據可以先不管。3)日常治理保健康，以數據化驅動長期治理。2.機制規范 1)架構分層標準 客戶案例：大淘系數據模型治理最佳實踐 110 往年我們關注的是數據視角，今年關注的是業務視角，業務視角核心訴求主要有四點，交付效率、產出時效、質量可靠、成本可控。過去 OneData 定義了每一層的作用，但每個層次

119、的分工定位不清晰，針對這些問題重新做了清晰的定義。應用層核心是專注支持業務，需要考慮研發效率、交付數據口徑一致性和穩定性。通過集市規范來控制復雜度，通過輕度聚合的中間層確?？趶浇y一，通過扁平化設計確保穩定。公共層的核心是抽象復用來提升效率，需要考慮易用性和穩定性。通過規范和冗余寬表提升復用性，通過解耦來確保穩定性。ODS 層的核心是合規高效，需要考慮接入效率和性能穩定。通過工具化提升效率、優化治理確保性能的穩定。特別是在數據達到一定量之后要考慮采用 merge 的方式接入數據。2)集市劃分規范 數據集市，是用來滿足特定部門或者用戶的需求，按照多維的方式進行存儲。通過對相似數據業務場景內聚進行抽

120、象分類，以降低 ADS 層重復建設和數據管理復雜度，讓應用研發更聚焦更高效?？蛻舭咐捍筇韵禂祿Ｐ椭卫碜罴褜嵺` 111 集市劃分的原則有以下兩點：原則一：以業務場景或者服務對象作為劃分原則，對相似數據業務場景內聚抽象進行分類。原則二：集市劃分需要統一標準，盡量符合 MECE 原則。3)公共層共建機制 在建設公共層的建設過程中，我們通常會遇到以下兩個痛點：客戶案例：大淘系數據模型治理最佳實踐 112 應用研發的痛點：公共層相應效率低。公共層研發的痛點：如果統一承接開發工作，涉及的業務很廣泛，研發資源不足。為了解決以上兩個痛點，我們通過以下核心原則來解決：原則一：公共層開放共建，事后審計治理 應

121、用開發整理需求，把需要下沉的公共維度提給公共層研發，公共開發需求評估。原則二：以應用需求驅動，設計開發共建 以需求為驅動，拆分出核心模型和非核心。模型，核心模型公共研發負責，非核心模型由業務開發進行，共同開發以提高效率。原則三：公共層研發統一運維保障 非核心模型上線并完成相關測試（準確性、確定性、治理）后轉交給公共層研發，由公共層統一運維。3.智能建模 在數據治理中有數據規范與共建機制依然是不夠的，還需要結合自動化工具來提升效率、保障規范。我們是從以下 4 個方面入手的（詳情可以體驗 DataWorks 的產品）：數據體系目錄結構化 模型設計線上化 打通研發流程（自動化生成簡代碼）對接地圖數據

122、專輯 1)數據目錄體系結構化 形成數據體系目錄有利于了解掌握數據，分門別類的方式降低了大家的使用成本。首先要對表命名做一些管控，我們做了可視化的表命名檢測器，來確保規范性。另外，淘系不是一個單空間的數據體系，因此要解決跨多個空間的復雜數據體系的統一建模問題?？蛻舭咐捍筇韵禂祿Ｐ椭卫碜罴褜嵺` 113 客戶案例：大淘系數據模型治理最佳實踐 114 2)模型設計線上化 改變模型設計方式，由線下設計遷移到線上，通過一些自動化工具，提升效率，保證規范?？蛻舭咐捍筇韵禂祿Ｐ椭卫碜罴褜嵺` 115 3)打通研發流程（自動化生成簡代碼）模型遷移到線上后，打通研發流程自動生成簡代碼，生成代碼框架，建表語句

123、，顯著提高了研發效率?？蛻舭咐捍筇韵禂祿Ｐ椭卫碜罴褜嵺` 116 4)對接地圖數據專輯 形成相應的地圖數據專輯，方便其他用戶使用數據。4.模型治理 1)打分模型 客戶案例：大淘系數據模型治理最佳實踐 117 模型治理需要量化，如果沒有量化全靠專家經驗效率是非常低的，我們通過模型的指標形成到表級別的模型分。通過多維度對模型進行打分。2)打分機制 精細化的打分機制，針對團隊、數據域、核心進行打分，形成相應的標簽?？蛻舭咐捍筇韵禂祿Ｐ椭卫碜罴褜嵺` 118 3)整體流程 以數據驅動，上圖左邊，以模型評估數據為出發點，通過各個維度對模型進行評估，得到各個域、各個團隊的評分，形成相應的問題標簽。以產

124、品驅動，上圖右邊，通過專家經驗判斷新上線模型升級搜索權限、下線模型降權限，讓業務迅速感知數據變化，引導業務。四、未來規劃 1.應用層效率 在整個數據體系中，應用層的數據體量是最大的，投入了大量的人力。OneData 缺少對應用層的數據建設指導，集市高度耦合，給運維效率帶來了不少問題，如跨集市依賴、依賴深度的問題。過去都是以業務為主導，為了保障研發效率放棄了部分研發規范，以后要完善應用層的研發規范，同時通過工具做好研發效率與規范的平衡。2.架構規范管控 基于分層標準落地，對研發過程規范完善，包括對設計、開發、運維、變更、治理等規范進行細化?？蛻舭咐捍筇韵禂祿Ｐ椭卫碜罴褜嵺` 119 目前核心是

125、表命名規范，對依賴規范、代碼規范、運維規范等管控能力尚不足。3.產品工具提效 將繼續與 Dataworks 共建。應用層智能建模能力還不能滿足研發效率要求，因此會繼續功能提效。數據測試功能集成。數據運維功能升級。事中數據治理能力構建（開發助手）。事后治理能力提效（批量刪除、主動推送優化等)。數據地圖，找數用數提效。五、提問 Q：核心公共層的建設是自頂向下還是自底向上？A：采用的是兩者相結合的方式。以需求為驅動，沒有需求就會導致過渡設計，在應用層有復用之后再下沉到公共層，這是自頂向下的。在公共層設計階段是面向業務過程的，這時是自底向上的。Q：多 BU 公共層是否需要統一規范？怎么去做？怎么量化價

126、值？A：需要做統一的規范，規范利于數據流通，才能體現數據價值。但是具體怎么規范需要具體去看，如電商、本地生活，業務和目標不一樣，很難做到統一的規范。Q：怎么判斷指標需要下沉到公共層？A：公共層的開發是需要成本的，是否需要下沉到公共層核心是看是否需要復用，可以從兩個方面入手。專家經驗判斷：如電商交易環節數據，這類數據是核心數據，是要建設到公共層的。事后判斷：如玩法之類的業務穩定性不強，那一開始不需要下沉到公共層，避免過度設計，事后再去判斷是否需要下沉?？蛻舭咐捍筇韵禂祿Ｐ椭卫碜罴褜嵺` 120 Q：關于表、字段的命名規范，是否需要先定義好詞根再開發？A：需要分開看。對于公共層設計到的業務過程是

127、有限的，對于公共部分要先定義好再開發。對于應用層，維度采用的是總建架構所以還需要先定義，對于指標特別是派生指標是多的，不建議先定義在開發。Q：如何解決口徑一致命名不一致，或者口徑不一致或者命名一致的場景。A：模型是演變的。對于應用層，80%都是自定義的，第一次出現的時候都是不標準的，這部分如果采用先定義后開發的方式，效率是很低的，只有在下沉到公共層的時候才能夠管控。對于公共層，能做的是保障核心指標 90%的規范與定義統一，剩下的那部分也無法保證。Q：跨集市依賴下沉到公共層的必要性？A：短期來看，是沒影響的，新增效率高。長期來會給數據的運維、治理帶來很多影響，在數據下線、變更、治理過程中不得不考

128、慮到下游依賴，會影響全流程的開發效率。產品實操：零售電商數據建模操作實踐 121 產品實操：零售電商數據建模操作實踐 作者：李佳慧，DataWorks 產研團隊 實驗目標 以零售電商模擬數據為基礎，了解數倉建模整體流程。通過 DataWorks 智能數據建模，進行數倉分層、數據建模、數據標準、數據指標等產品實操。業務背景 根據零售電商行業的會員、商品、交易、物流、評價等業務數據計算出 GMV（商品交易總額）、用戶畫像等數據供業務決策。注 本次實驗數據為人工 mock 虛擬數據，非任何業務真實數據，僅供體驗使用。流程簡介 使用 DataWorks 智能建模模塊，完成對業務數據倉庫的模型規范制定及

129、數據分層、數據域、業務過程等信息的設定，完成邏輯模型的設計，并將邏輯模型發布生成物理表。實驗步驟 一、環境準備 1.購買并開通 DataWorks 與 MaxCompute 產品實操：零售電商數據建模操作實踐 122 https:/dw-common- DataWorks 專業版：首月 1 元 DataWorks 智能數據建模：首月 199 元 MaxCompute 按量付費 2.創建項目 登錄 DataWorks 管理控制臺，在上海地域創建一個新的工作空間。1)基本配置 工作空間名稱：retail_e_commerce_2（由于 MaxCompute project name 需要全局唯一，

130、名稱被占用請更換）顯示名：零售電子商務 2 模式：標準模式（開放和生產隔離），標準模式和簡單模式的區別請參見官方文檔 描述：零售電子商務項目 注 開發環境 MaxCompute 項目名稱：retail_e_commerce_2_dev 生產環境 MaxCompute 項目名稱：retail_e_commerce_2 產品實操：零售電商數據建模操作實踐 123 2)選擇引擎 選擇按量付費的 MaxCompute 引擎。這里非必選，可以選擇先創建空間，后續在工作空間配置中再綁定。3)引擎詳情 實例顯示名稱：retail_e_commerce_2 其余都使用默認配置。4)進入工作空間 創建完成后可從

131、當前頁面“DataWorks 管理控制臺-工作空間列表”入口進入DataWorks 數據開發界面。（當前語句有效，由于就在上一步操作完成的當前界面，所以沒有提供截圖。）進入工作空間后，從左上角-全部產品入口可以進入數據建模、數據集成、數據開發、運維中心等各個模塊。產品實操：零售電商數據建模操作實踐 124 3.綁定引擎 綁定 MaxCompute、Hologres（可選）、E-MapReduce（可選）引擎，綁定相關引擎后，可以創建對應的引擎節點。綁定引擎詳情請參見官方文檔配置工作空間。MaxCompute 引擎，由于之前我們創建的時候已選擇該引擎，所以這里不需要再綁定。注意一下此處的幾個配置

132、信息，一個標準模式的 DataWorks 工作空間對應兩個MaxCompute 項目，一個生產環境和一個開發環境分別如下：產品實操：零售電商數據建模操作實踐 125 生產環境 開發環境 參數 說明 參數 說明 MaxCompute項 目 名 稱：retail_e_commerce_2 在未指定項目名的情況下，生產運維中心默認訪問生產項目。MaxCompute項 目 名 稱：retail_e_commerce_2_dev 在未指定項目名的情況下，DataStudio 和開發運維中心默認訪問開發項目。MaxCompute 訪問者身份：阿里云主賬號 生產運維中心默認使用該身份訪問。默認值為阿里云主賬

133、號，支持修改為阿里云子賬號或阿里云 RAM 角色。MaxCompute 訪問者身份：任務執行者 DataStudio 和數據分析 SQL查詢默認使用該身份訪問。不可修改。Hologres 引擎 綁定 Hologres 引擎幫助文檔。E-MapReduce 引擎 綁定 E-MapReduce 引擎幫助文檔。產品實操：零售電商數據建模操作實踐 126 4.權限規劃（可選）本實驗中使用主賬號操作，相當于是最大權限。在實際生產中，對權限的管控需求可以參考如下：DataWorks：用戶、角色與權限概述官方文檔。MaxCompute：權限概述官方文檔。二、維度建模 維度建模儲備知識介紹。1.基本概念 智能

134、建模強依賴于 Kimball 維度建模理論，在實操前務必閱讀一下數倉分層和維度建模中的基本概念。維度建模：詳情請參見維度建模。業務分類：當企業業務比較復雜，不同類型業務彼此間需要共享數據域，但是又希望能在模型設計和應用過程中快速定位本業務的數據，可結合真實業務情況，規劃不同的業務分類，在后續模型設計過程中，可將模型歸屬到對應的業務分類，提升 產品實操：零售電商數據建模操作實踐 127 后續模型使用的便捷性。例如零售電子商務就是一個一級業務分類，如需進一步細分，可分為門店零售，電子商務等。數據域：是對企業業務過程進行抽象、提煉、組合的集合，是企業業務人員在使用數據時第一個分組入口，可以幫助企業業

135、務人員快速的從海量的數據中快速圈定到自己的業務數據。例如在電商領域，可以劃分會員域、商品域、交易域等。業務過程：業務過程指企業的業務活動事件，如下單，支付。數據集市：是基于業務分類，面向特定應用場景或者產品的數據組織。通常位于數據應用層，依賴于公共層的整合數據。例如電商集市、生意參謀集市等。主題域：用于將數據集市按照分析視角進行劃分，通常是聯系較為緊密的數據主題的集合。例如在電商集市下，可以創建電商 360、活動等主題域。維度：維度是用于分析數據的一個角度，一方面對維度進行可控管理，另一方面指導維度表的設計，如地理維度，時間維度。維度屬性：維度屬性隸屬于一個維度，用來描述維度的屬性，如地理維度

136、中的國家名稱，省份名稱。時間周期：時間周期是用來明確數據統計的時間范圍或者時間點，如最近 30 天，自然周。修飾詞：修飾詞是對指標統計業務范圍的劃定，指除了統計維度外指標的業務場景的限定抽象，如 PC 端，無線端。原子指標：用于明確業務的統計口徑和計算邏輯，是基于用戶的業務活動（即業務過程）創建的，用于統計業務活動中某一業務狀況的數值。例如，存量會員數。派生指標：由原子指標、時間周期、修飾詞構成，用于反映企業某一業務活動在指定時間周期及目標范圍中的業務狀況。例如，歷史截至當日（時間周期）_異常會員（修飾詞）_存量會員數（原子指標）。產品實操：零售電商數據建模操作實踐 128 數倉分層：詳情請參

137、見數倉分層 數據引入層 ODS（Operation Data Store）數據公共層 CDM（Common Data Model，又稱通用數據模型層）?公共維度層（DIM）?公共匯總粒度事實層（DWS）?明細粒度事實層（DWD）數據應用層 ADS（Application Data Service）2.模型設計理論 以下簡單介紹了維度建模模型設計方法論，舉例說明了如何劃分數據域等，更多關于維度建模方法論、事實表維度表模型設計內容，感興趣的可以參考 Star Schema完全參考手冊1重點看第 2 章第 6 章節和第 11 章節、數據倉庫工具箱（第 3版）2。產品實操：零售電商數據建模操作實踐 1

138、29 舉例：如何劃分數據域 注：以下為數據域劃分案例，和本實驗的數據域劃分有一點出入。上面示意圖引用自大數據之路：阿里巴巴大數據實踐 3.預期結果 預期的分層劃域，下圖中從下到上數倉分層，從左到右劃分數據域。這里僅需了解一下概貌，后面會一步一步配置，藍色字體為本實驗中需要使用到的表，需將模型發布至引擎生成物理表。產品實操：零售電商數據建模操作實踐 130 注：“電商 360”指的電商商品交易總額、KPI360 度概覽。4.維度建模工具實踐過程 注 維度建模中部分標注了可選，表示不操作不影響后續實驗。建議是都操作一下，以便結合業務從整體角度了解一下維度建模。1)數倉規劃 a)業務分類 新建一個業

139、務分類 業務名稱：電商業務；英文縮寫：ec 產品實操：零售電商數據建模操作實踐 131 b)數倉分層 系統內置了常規的數據分層，用戶可以針對每個數據分層設置表名檢查器。本實驗使用默認分層結構，并且為了規范模型的命名，將同一分層中表名稱的命名格式統一，我們為每個數倉分層配置對應的表名“檢查器”，開啟并設置默認檢查器，在進行模型設計時，表名會按照檢查器設置自動填充，設計師僅需補充自定義內容即可。貼源層：數據引入層 ODS 公共層：維度層 DIM、明細數據層 DWD、匯總數據層 DWS 應用層：應用數據層 ADS 表名檢查器示例：弱規則：新建對象時，根據規則定義內容，推薦填寫規則名稱 強規則：新建對

140、象時，根據規則定義內容，推薦填寫并強制校驗規則名稱 產品實操：零售電商數據建模操作實踐 132 分層 規則定義 規則示例 維度層 DIM dim_業務大類英文縮寫_數據域英文縮寫_自定義 e.g：dim_ec_mbr_user_info 會員基礎信息維度表 維度表_電商業務_會員域_xxxx 明細數據層 DWD dwd_業務大類英文縮寫_數據域英文縮寫_業務過程英文縮寫_自定義_存儲策略縮寫 e.g：dwd_ec_trd_create_ord_di 交易下單明細事實表 明細表_電商業務_交易域_下單業務過程_xxxx_每日增量 匯總數據層 DWS dws_業務大類英文縮寫_數據域英文縮寫_自定

141、義_統計周期 e.g dws_ec_mbr_cnt_std 歷史截至當日_存量會員數_cube統計表 匯總表_電商業務_會員域_xxx_歷史截止當日 應用數據層 ADS ads_業務大類英文縮寫_主題域英文縮寫_自定義 真實場景中建議使用“ads_業務大類英文縮寫_數據集市英文縮寫_主題域英文縮寫_自定義”e.g:ads_ec_ec360_gmv_kpi_overview 電 商360KPI 概覽 應用表_電商業務_電商 360_xxx 數據引入層 ODS（一般 ODS 層不需要做數據建模，所以這里略）c)公共層 數據域 新建 6 個數據域，分別如下。嘗試手動創建完一個數據域后，也可以下載 E

142、xcel 文件，使用通用工具-導入 Excel 英文縮寫*英文名*中文名*備注 mbr mbr 會員域 網站服務的注冊會員及潛在會員（leads）的各種基礎信息 trd trd 交易域 交易從加入購物車到下單、支付、發貨、退款及成果交易的各個過程，同時還包括拍賣、機票、彩票等各種類型的交易 itm itm 商品域 網站可供用戶交易的商品數據，包括類目、品牌、SPU、SKU 等相關商品基礎信息 lgt lgt 物流域（可選）log log 日志域（可選）各種類型的網站日志數據 risk risk 信用&風控域（可選）企業或者個人信用及風險相關的數據，包括審核、風控監控事件、評價、投訴、舉報、申訴

143、、處罰等相關數據 產品實操：零售電商數據建模操作實踐 133 業務過程 新建會員域下的業務過程。嘗試手動建完一個業務過程后也可以下載 Excel 文件，使用通用工具-導入 Excel 英文縮寫*中文名*英文名*數據域*備注 login 登錄 login 會員域 register 注冊 register 會員域 mbf_default（系統）會員域_默認（系統）mbr_default 會員域 數據域下默認的業務過程。新建交易域下的業務過程 英文縮寫*中文名*英文名*數據域*備注 cart 加購 cart 交易域 加入購物車 create 下單 create 交易域 創建訂單 pay 支付 pay

144、 交易域 產品實操：零售電商數據建模操作實踐 134 refund 退款 refund 交易域 trd_default（系統）交易域_默認 trd_default 交易域 數據域下的默認業務過程。新建商品域下的業務過程 英文縮寫*中文名*英文名*數據域*備注 on_off 商品上下架 on_off 商品域 publish 商品發布 publish 商品域 itm_default（系統）商品域_默認 itm_default 商品域 數據域下的默認業務過程。新建物流域下的業務過程（可選）英文縮寫*中文名*英文名*數據域*備注 take_over 攬件 take_over 物流域 lg_order_

145、crt 接單 lg_order_crt 物流域 ship 發貨 ship 物流域 delivery 派送 delivery 物流域 sign 簽收 sign 物流域 lgt_default（系統）物流域_默認 lgt_default（系統）物流域 數據域下的默認的業務過程。新建日志域下的業務過程（可選）英文縮寫*中文名*英文名*數據域*備注 exp 曝光 exposure 日志域 se 搜索 search 日志域 clk 點擊 click 日志域 pv 瀏覽 pv 日志域 log_default（系統）日志域_默認 log_default 日志域 數據域下的默認業務過程。新建信用&風控域下的業

146、務過程（可選）產品實操：零售電商數據建模操作實踐 135 英文縮寫*中文名*英文名*數據域*備注 remark 評價 remark 信用&風控域 risk_default（系統）信用&風控域_默認 risk_default 信用&風控域 數據域下的默認業務過程 d)應用層 數據集市 新建兩個一級數據集市 集市名稱 英文縮寫 所屬業務分類 電商集市 ec 電商業務 供應鏈數據集市 gyl 電商業務 英文縮寫：ec 集市名稱：電商集市 所屬業務分類：電商業務 主題域 新建一級主題域，分別如下：注：后續實驗中實際使用到 ec360 這個主題域。產品實操：零售電商數據建模操作實踐 136 英文縮寫 主

147、題域名稱 所屬數據集市 備注 ec360 電商 360 電商集市 open_red 開門紅 電商集市 rfd 退款 電商集市 lgt 物流 電商集市 flow 流量通道 電商集市 act 活動 電商集市 byr 買家 電商集市 brand 品牌 電商集市 cate 品類 電商集市 slr 商家 電商集市 itm 商品 電商集市 e)建?？臻g 當您所需要管理多個 DataWorks 工作空間且需要復用一套數倉規劃時，面對跨多個工作空間的復雜數據體系，可以通過設計空間來共享一套數據建模工具，針對整個數據體系進行統一地數倉規劃、維度建模及指標定義等工作。當配置了數據研發工作空間后，在后續模型發布時可

148、以選擇對應的工作空間，更多詳情請參見建?？臻g官方文檔。注：當前步驟僅為核心功能展示，不操作不影響后續實驗。產品實操：零售電商數據建模操作實踐 137 2)數據標準 a)新建字段標準 新建根目錄，名稱：線上業務 新建子目錄，名稱：會員 新建 5 個標準，分別如下表；也可以下載 Excel 文件，使用 Excel 導入。標準編碼 英文縮寫 英文名稱 中文名稱 數據類型 birthday birthday birthday 生日 DATETIME user_name user_name user_name 用戶名稱 STRING nick nick nick 昵稱 STRING gender gen

149、der gender 性別 STRING user_id user_id user_id 用戶 id BIGINT 產品實操：零售電商數據建模操作實踐 138 b)新建標準代碼 新建目錄 目錄 1 名稱：基礎代碼 目錄 2 名稱：風控 新建 2 個標準代碼，并執行發布到 MaxCompute 引擎 代碼標準 1 代碼編號：is_del 代碼名稱：是否刪除 英文名稱：is_del 編碼取值 編碼名稱 英文名稱 編碼含義 1 true true 是 0 false false 否 代碼標準 2 代碼編號：risks_level 代碼名稱：風險等級 英文名稱：risks_level 產品實操：零售電

150、商數據建模操作實踐 139 編碼取值 編碼名稱 英文名稱 編碼含義 1 高級 high 高級 2 中級 middle 中級 c)新建度量單位 新建一個度量單位 英文縮寫：people_cnt 英文名稱：people_cnt 中文名稱：人數 分類：對象量詞 產品實操：零售電商數據建模操作實踐 140 3)維度建模（公共層維度表模型和明細表模型）a)公共層-維度表模型 創建 4 張維度表模型，分別如下。維度表 1：dim_ec_itm_item_info 商品基礎信息維度表 基本信息：數倉分層*數據域*業務分類 存儲策略 表名*表中文名*生命周期 描述 公共層：維度層 商品域（itm）電商業務 d

151、im_ec_itm_item_info 注：表名是在選完業務分類、數據域后根據數倉分層中配置的檢查器自動填充dim_ec_itm部分內容，再手動填寫自定義_item_info部分。商品基礎信息維度表 365 天 商 品 基 礎信 息 維 度表 字段管理和分區字段管理：支持手動錄入、快捷模式或代碼模式的方式配置字段管理和分區字段管理，建議新建模型時使用快捷模式查找已有表/視圖的方式來快速導入，修改模型時使用代碼模式，兩種方式結合使用。產品實操：零售電商數據建模操作實踐 141 本實驗各個層級其中一張表會使用快捷模式來配置，其余表由于創建方法大體一致，為減少重復操作使用代碼模式創建，代碼模式支持

152、FML、MaxCompute DDL、Hive DDL、MySQL DDL 等多種語言，本實驗中會貼出 FML（適用于維度建模領域的類 SQL語言，FML 語句格式文檔）、MaxCompute DDL 兩種的 DDL 語句，您可以根據情況選擇任意一種。當前表使用快捷模式配置?？旖菽Ｊ脚渲茫簊tep1：進 入 編 輯 狀 態，使 用 快 捷 模 式，搜 索 已 有 表“odps.retail_e_commerce_2.ods_item_info”，選擇“導入全部字段”，導入后還能溯源到“來源表”和“來源字段”。注 快捷模式使用到了“查找已有表/視圖”，由于當前空間全新，沒有已有表，請先執行一下文

153、末附件的 ODS 層 DDL 語句。實際應用過程中，可以直接使用已存在的表或視圖。產品實操：零售電商數據建模操作實踐 142 step2：選中“id”字段，右鍵刪除，也支持批量刪除。step3：修改模型字段類型：將“gmt_create、gmt_modified”字 段 類 型 批 量 修 改 為“string”；將“reserve_price、secure_trade_ordinary_post_fee、secure_trade_fast_post_fee、secure_trade_ems_post_fee”字段類型修改為“double”；修改模型字段顯示名：將“gmt_modified”字

154、 段 顯 示 名 稱 修 改 為“商 品 最 后 修 改 日 期”；將“gmt_create”字段顯示名稱修改為“商品創建時間”，保存；修改模型字段順序：再點一次編輯，使用代碼模式調整一下字段順序，將“gmt_modified”字段調整到“gmt_create”字段前面，保存。產品實操：零售電商數據建模操作實踐 143 代碼模式配置：-不支持修改表名 CREATE DIM TABLE dim_ec_itm_item_info ALIAS 商品基礎信息維度表 (gmt_modified ALIAS 商品最后修改日期 STRING COMMENT 商品最后修改日期,gmt_create ALIAS

155、 商品創建時間 STRING COMMENT 商品創建時間,item_id ALIAS 商品數字 ID BIGINT COMMENT 商品數字 ID,title ALIAS 商品標題 STRING COMMENT 商品標題,sub_title ALIAS 商品子標題 STRING COMMENT 商品子標題,pict_url ALIAS 主圖 URL STRING COMMENT 主圖 URL,desc_path ALIAS 商品描述的路徑 STRING COMMENT 商品描述的路徑,item_status ALIAS 商品狀態 1：確認通過 0：未確認通過 BIGINT COMMENT 商

156、品狀態 1：確認通過 0：未確認通過,last_online_time ALIAS 最近一次開始銷售時間，商品上架時間 DATETIME COMMENT 最近一次開始銷售時間，商品上架時間,last_offline_time ALIAS 銷售結束時間，表示一個銷售周期的結束，僅作用于拍賣商品 DATETIME COMMENT 銷售結束時間，表示一個銷售周期的結束，僅作用于拍賣商品,duration ALIAS 有效期，銷售周期，只有兩個值，7 天或 14 天 BIGINT COMMENT 有效期，銷售周期，只有兩個值，7 天或 14 天,reserve_price ALIAS 當前價格 DOU

157、BLE COMMENT 當前價格,secure_trade_ordinary_post_fee ALIAS 平郵費用 DOUBLE COMMENT 平郵費用,secure_trade_fast_post_fee ALIAS 快遞費用 DOUBLE COMMENT 快遞費用,secure_trade_ems_post_fee ALIAS EMS 郵費 DOUBLE COMMENT EMS 郵費,last_online_quantity ALIAS 商品最近一次上架時的庫存數量 BIGINT COMMENT 商品最近一次上架時的庫存數量,features ALIAS 商品特征 STRING COM

158、MENT 商品特征,cate_id ALIAS 商品葉子類目 ID BIGINT COMMENT 商品葉子類目ID,cate_name ALIAS 商品葉子類目名稱 STRING COMMENT 商品葉子類目名稱,commodity_id ALIAS 品類 ID BIGINT COMMENT 品類 ID,commodity_name ALIAS 品類名稱 STRING COMMENT 品類名稱,is_virtual ALIAS 是否虛擬商品 STRING COMMENT 是否虛擬商品,shop_id ALIAS 商家 ID BIGINT COMMENT 商家 ID,shop_nick ALIA

159、S 商家 NICK STRING COMMENT 商家 NICK,is_deleted ALIAS 類目是否刪除 BIGINT COMMENT 類目是否刪除)COMMENT 商品基礎信息維度表 PARTITIONED BY(ds ALIAS 業務日期,yyyymmdd STRING COMMENT 業務日期,yyyymmdd)產品實操：零售電商數據建模操作實踐 144 WITH(life_cycle=365);-不支持修改表名 CREATE TABLE dim_ec_itm_item_info(gmt_modified STRING COMMENT 商品最后修改日期,gmt_create ST

160、RING COMMENT 商品創建時間,item_id BIGINT COMMENT 商品數字 ID,title STRING COMMENT 商品標題,sub_title STRING COMMENT 商品子標題,pict_url STRING COMMENT 主圖 URL,desc_path STRING COMMENT 商品描述的路徑,item_status BIGINT COMMENT 商品狀態 1：確認通過 0：未確認通過,last_online_time DATETIME COMMENT 最近一次開始銷售時間，商品上架時間,last_offline_time DATETIME CO

161、MMENT 銷售結束時間，表示一個銷售周期的結束，僅作用于拍賣商品,duration BIGINT COMMENT 有效期，銷售周期，只有兩個值，7 天或 14天,reserve_price DOUBLE COMMENT 當前價格,secure_trade_ordinary_post_fee DOUBLE COMMENT 平郵費用,secure_trade_fast_post_fee DOUBLE COMMENT 快遞費用,secure_trade_ems_post_fee DOUBLE COMMENT EMS 郵費,last_online_quantity BIGINT COMMENT 商品

162、最近一次上架時的庫存數量,features STRING COMMENT 商品特征,cate_id BIGINT COMMENT 商品葉子類目 ID,cate_name STRING COMMENT 商品葉子類目名稱,commodity_id BIGINT COMMENT 品類 ID,commodity_name STRING COMMENT 品類名稱,is_virtual STRING COMMENT 是否虛擬商品,shop_id BIGINT COMMENT 商家 ID,shop_nick STRING COMMENT 商家 NICK,is_deleted BIGINT COMMENT 類

163、目是否刪除)COMMENT 商品基礎信息維度表 PARTITIONED BY(ds STRING COMMENT 業務日期,yyyymmdd)LIFECYCLE 365;配置完成后保存并發布當前模型，生成物理表。產品實操：零售電商數據建模操作實踐 145 使用“模型開發”功能聯動數據開發模塊（這步僅作為核心功能演示，實操后可以不保存節點，在后續實驗步驟中可以使用該功能來開發）。如果使用快捷模式中的查找表、冗余字段查找表構建模型，系統會自動構建完整度較高的 etl，開發者只需要補充業務邏輯即可。不使用快捷模式查找表創建模型，如手動錄入、ddl 導入，構建的 etl 代碼需要補充的信息相對就會多，

164、且需要查看元數據來確認字段含義。產品實操：零售電商數據建模操作實踐 146 維度表 2：dim_ec_mbr_user_info 會員基礎信息維度表 基本信息：數倉分層*數據域*業務分類 存儲策略 表名*表中文名*生命周期 描述 表類型*公共層：維度層 會員域（mbr）電商業務 每日全量（df）dim_ec_mbr_user_info 會員基礎信息維度表 365 天 普通維度表 字段管理和分區字段管理：當前表使用代碼模式配置，選用 FML 語言。（使用代碼模式時，在配置完基本信息后請先保存，再點編輯，繼續配置字段部分）使用代碼模式配置：將 user_id 字段設置為業務“主鍵”和“非空”；對n

165、ick字段關聯字段標準昵稱；對is_delete字段關聯標準代碼是否刪除。將模型發布至 MaxCompute 引擎會生成對應的數據質量 DQC 校驗規則來檢查 user_id 字段的值唯一和非空。產品實操：零售電商數據建模操作實踐 147 -不支持修改表名 CREATE DIM TABLE dim_ec_mbr_user_info ALIAS 會員基礎信息維度表 (user_id ALIAS 會員數字 ID BIGINT NOT NULL COMMENT 會員數字 ID,nick ALIAS 昵稱 STRING COMMENT 會員 NICK。會員昵稱 WITH(dict=nick),gmt_

166、create ALIAS 創建時間 STRING COMMENT 創建時間,gmt_modified ALIAS 修改時間 STRING COMMENT 修改時間,reg_fullname ALIAS 個人認證表示真實姓名，企業認證表示企業名稱 STRING COMMENT 個人認證表示真實姓名，企業認證表示企業名稱,reg_mobile_phone ALIAS 注冊時綁定手機號碼 STRING COMMENT 注冊時綁定手機號碼,reg_email ALIAS 注冊填寫 EMAIL（用戶可以修改）STRING COMMENT 注冊填寫EMAIL（用戶可以修改）,reg_gender ALIA

167、S 注冊填寫性別（F 女，M 男，不是這兩個就是未知的，說明性別保密）STRING COMMENT 注冊填寫性別（F 女，M 男，不是這兩個就是未知的，說明性別保密）,reg_gender_name ALIAS 注冊填寫性別（F 女，M 男，不是這兩個就是未知的，說明性別保密）STRING COMMENT 注冊填寫性別（F 女，M 男，不是這兩個就是未知的，說明性別保密）,reg_birthdate ALIAS 注冊填寫生日（用戶可以修改）STRING COMMENT 注冊填寫生日（用戶可以修改）,reg_address ALIAS 注冊填寫地址（用戶可以修改）STRING COMMENT 注

168、冊填寫地址（用戶可以修改）,產品實操：零售電商數據建模操作實踐 148 reg_nation_id ALIAS 注冊填寫國家 ID（暫時為空）STRING COMMENT 注冊填寫國家ID（暫時為空）,reg_nation_id_name ALIAS 注冊填寫國家 ID（暫時為空）STRING COMMENT 注冊填寫國家 ID（暫時為空）,reg_prov_id ALIAS 注冊填寫省 ID STRING COMMENT 注冊填寫省 ID,reg_prov_name ALIAS 名稱 STRING COMMENT 名稱,reg_city_id ALIAS 注冊填寫城市 ID STRING C

169、OMMENT 注冊填寫城市 ID,reg_city_name ALIAS 名稱 STRING COMMENT 名稱,user_regip ALIAS 注冊 IP STRING COMMENT 注冊 IP,id_card_type ALIAS 會員認證證件類型 0：未知 1：身份證 2：企業營業執照號 BIGINT COMMENT 會員認證證件類型 0：未知 1：身份證 2：企業營業執照號,id_card_name ALIAS 會員認證證件類型 0：未知 1：身份證 2：企業營業執照號 STRING COMMENT 會員認證證件類型 0：未知 1：身份證 2：企業營業執照號,id_card_nu

170、mber ALIAS 個人認證表示身份證號，企業認證表示企業的營業執照號，沒有認證不保證準確性 STRING COMMENT 個人認證表示身份證號，企業認證表示企業的營業執照號，沒有認證不保證準確性,id_gender ALIAS 身份證解析性別（F 女，M 男，unkown 表示身份證為空或格式不對）STRING COMMENT 身份證解析性別（F 女，M 男，unkown 表示身份證為空或格式不對）,id_bday ALIAS 身份證解析生日（身份證為空或格式不對則為-1）STRING COMMENT 身份證解析生日（身份證為空或格式不對則為-1）,id_age ALIAS 身份證解析年齡

171、（身份證為空或格式不對則為-1）STRING COMMENT 身份證解析年齡（身份證為空或格式不對則為-1）,user_regdate ALIAS 注冊時間 STRING COMMENT 注冊時間,user_active_type ALIAS 用戶激活方式，1 郵件;2 手機;STRING COMMENT 用戶激活方式，1 郵件;2 手機;,user_active_name ALIAS 用戶激活激活方式名稱 STRING COMMENT 用戶激活激活方式名稱,user_active_time ALIAS 激活時間 STRING COMMENT 激活時間,vip_level ALIAS VIP

172、等級 BIGINT COMMENT VIP 等級,vip_level_name ALIAS VIP 等級名稱。v1，v2，v3 等 STRING COMMENT VIP 等級名稱。v1，v2，v3 等,is_delete ALIAS 是否刪除 STRING COMMENT 是否刪除 WITH(code_table=is_del),CONSTRAINT PK PRIMARY KEY(user_id)COMMENT 會員基礎信息維度表 PARTITIONED BY(ds ALIAS 業務日期,yyyymmdd STRING COMMENT 業務日期,yyyymmdd)產品實操：零售電商數據建模操作

173、實踐 149 WITH(life_cycle=365);-不支持修改表名 CREATE TABLE dim_ec_mbr_user_info(user_id BIGINT COMMENT 會員數字 ID,nick STRING COMMENT 會員 NICK。會員昵稱,gmt_create STRING COMMENT 創建時間,gmt_modified STRING COMMENT 修改時間,reg_fullname STRING COMMENT 個人認證表示真實姓名，企業認證表示企業名稱,reg_mobile_phone STRING COMMENT 注冊時綁定手機號碼,reg_email

174、 STRING COMMENT 注冊填寫 EMAIL（用戶可以修改）,reg_gender STRING COMMENT 注冊填寫性別（F 女，M 男，不是這兩個就是未知的，說明性別保密）,reg_gender_name STRING COMMENT 注冊填寫性別（F 女，M 男，不是這兩個就是未知的，說明性別保密）,reg_birthdate STRING COMMENT 注冊填寫生日（用戶可以修改）,reg_address STRING COMMENT 注冊填寫地址（用戶可以修改）,reg_nation_id STRING COMMENT 注冊填寫國家 ID（暫時為空）,reg_natio

175、n_id_name STRING COMMENT 注冊填寫國家 ID（暫時為空）,reg_prov_id STRING COMMENT 注冊填寫省 ID,reg_prov_name STRING COMMENT 名稱,reg_city_id STRING COMMENT 注冊填寫城市 ID,reg_city_name STRING COMMENT 名稱,user_regip STRING COMMENT 注冊 IP,id_card_type BIGINT COMMENT 會員認證證件類型 0：未知 1：身份證 2：企業營業執照號,id_card_name STRING COMMENT 會員認證

176、證件類型 0：未知 1：身份證 2：企業營業執照號,id_card_number STRING COMMENT 個人認證表示身份證號，企業認證表示企業的營業執照號，沒有認證不保證準確性,id_gender STRING COMMENT 身份證解析性別（F 女，M 男，unkown 表示身份證為空或格式不對）,id_bday STRING COMMENT 身份證解析生日（身份證為空或格式不對則為-1）,id_age STRING COMMENT 身份證解析年齡（身份證為空或格式不對則為-1）,user_regdate STRING COMMENT 注冊時間,user_active_type ST

177、RING COMMENT 用戶激活方式，1 郵件;2 手機;,user_active_name STRING COMMENT 用戶激活激活方式名稱,user_active_time STRING COMMENT 激活時間,產品實操：零售電商數據建模操作實踐 150 vip_level BIGINT COMMENT VIP 等級,vip_level_name STRING COMMENT VIP 等級名稱。v1，v2，v3 等,is_delete STRING COMMENT 是否刪除)COMMENT 會員基礎信息維度表 PARTITIONED BY(ds STRING COMMENT 業務日期

178、,yyyymmdd)LIFECYCLE 365;設置主鍵、非空、關聯字段標準和關聯標準代碼圖示。維度表 3：dim_ec_trd_biz_type 交易類型（可選）基本信息：數倉分層*數據域*業務分類 存儲策略 表名*表中文名*生命周期 描述 表類型*公共層：維度層 交易域（trd）電商業務 dim_ec_trd_biz_type 交易類型 交 易類型 普通維度表 字段管理和分區字段管理：使用代碼模式配置 -不支持修改表名 產品實操：零售電商數據建模操作實踐 151 CREATE DIM TABLE dim_ec_trd_biz_type ALIAS 交易類型 (code ALIAS code

179、 STRING,value ALIAS value STRING,description ALIAS description STRING)COMMENT 交易類型;-不支持修改表名 CREATE TABLE dim_ec_trd_biz_type(code STRING,value STRING,description STRING)COMMENT 交易類型;維度表 4：dim_ec_itm_cat 商品類目維度表（可選）基本信息：數倉分層*數據域*業務分類 存儲策略 表名*表中文名*生命周期 描述 表類型*公共層：維度層 商 品 域（itm）電商業務 每 日 全 量（df）dim_ec_i

180、tm_cat 商品類目維度表 商品類目維度表 普通維度表 字段管理和分區字段管理：-不支持修改表名 CREATE DIM TABLE dim_ec_itm_cat ALIAS 商品類目維度表 (cate_id ALIAS cate_id BIGINT NOT NULL,cate_name ALIAS cate_name STRING,CONSTRAINT PK PRIMARY KEY(cate_id)COMMENT 商品類目維度表 PARTITIONED BY(ds ALIAS 業務日期,yyyymmdd STRING COMMENT 業務日期,yyyymmdd);-不支持修改表名 產品實操：

181、零售電商數據建模操作實踐 152 CREATE TABLE dim_ec_itm_cat(cate_id BIGINT,cate_name STRING)COMMENT 商品類目維度表 PARTITIONED BY(ds STRING COMMENT 業務日期,yyyymmdd);關聯關系 維度模型間如果有業務上的“外鍵”概念，可以使用關聯關系來建立兩個維度表模型直間的聯系。比如 dim_ec_itm_item_info 的 cate_id 與 dim_ec_itm_cat 的業務主鍵 cate_id 通過畫板拉線的方式建立關聯關系。b)公共層-明細表模型 創建 3 張明細表模型，分別如下。明

182、細表 1：dwd_ec_mbr_register_event_di 會員注冊事件明細事實表（可選）基本信息：產品實操：零售電商數據建模操作實踐 153 數倉分層*數倉分層*業務分類業務分類 業務過程*業務過程*存儲策略存儲策略 表名*表名*表中文名*表中文名*生命周期生命周期 描述描述 表類型*表類型*公共層：明細數據層 電商業務 會員域/注冊 每 日 增 量（di）dwd_ec_mbr_register_event_di 會員注冊事件明細事實表 365 天 事實事務表 字段管理和分區字段管理：注 由于明細表字段配置這里沒有涉及到新的功能點，所以全部使用代碼模式配置。使用代碼模式配置：-不支持

183、修改表名 CREATE FACT TABLE dwd_ec_mbr_register_event_di ALIAS 會員注冊事件明細事實表 (event_time ALIAS 日志輸出時間 DATETIME COMMENT 日志輸出時間,session_id ALIAS 注冊臨時會話 id STRING COMMENT 注冊臨時會話 id,application ALIAS 應用名稱 STRING COMMENT 應用名稱,process ALIAS 注冊流程 STRING COMMENT 注冊流程,action ALIAS 流程中的步驟 STRING COMMENT 流程中的步驟,ip AL

184、IAS ip STRING COMMENT ip,mobile_area ALIAS 手機對應國家區號 STRING COMMENT 手機對應國家區號,mobile ALIAS 注冊或激活手機號碼 STRING COMMENT 注冊或激活手機號碼,email ALIAS 注冊或激活郵箱 STRING COMMENT 注冊或激活郵箱,nick ALIAS 注冊或激活 nick STRING COMMENT 注冊或激活 nick,reg_from ALIAS 注冊來源 STRING COMMENT 注冊來源,產品實操：零售電商數據建模操作實踐 154 local_host_name ALIAS 日

185、志記錄服務器 STRING COMMENT 日志記錄服務器,verify_type ALIAS 驗證方式 STRING COMMENT 驗證方式,action_result ALIAS 當前 action 結果信息 STRING COMMENT 當前 action 結果信息,is_success ALIAS 當前 action 結果信息 STRING COMMENT 當前 action 結果信息,target_url ALIAS 注冊傳入目標跳轉地址 STRING COMMENT 注冊傳入目標跳轉地址,os_type ALIAS 操作系統類型 STRING COMMENT 操作系統類型,app

186、_version ALIAS app 版本 STRING COMMENT app 版本)PARTITIONED BY(ds ALIAS 業務日期,yyyymmdd STRING COMMENT 業務日期,yyyymmdd)WITH(life_cycle=365);-不支持修改表名 CREATE TABLE dwd_ec_mbr_register_event_di(event_time DATETIME COMMENT 日志輸出時間,session_id STRING COMMENT 注冊臨時會話 id,application STRING COMMENT 應用名稱,process STRING

187、 COMMENT 注冊流程,action STRING COMMENT 流程中的步驟,ip STRING COMMENT ip,mobile_area STRING COMMENT 手機對應國家區號,mobile STRING COMMENT 注冊或激活手機號碼,email STRING COMMENT 注冊或激活郵箱,nick STRING COMMENT 注冊或激活 nick,reg_from STRING COMMENT 注冊來源,local_host_name STRING COMMENT 日志記錄服務器,verify_type STRING COMMENT 驗證方式,action_r

188、esult STRING COMMENT 當前 action 結果信息,is_success STRING COMMENT 當前 action 結果信息,target_url STRING COMMENT 注冊傳入目標跳轉地址,os_type STRING COMMENT 操作系統類型,app_version STRING COMMENT app 版本)COMMENT 會員注冊事件明細事實表 PARTITIONED BY(ds STRING COMMENT 業務日期,yyyymmdd)LIFECYCLE 365;產品實操：零售電商數據建模操作實踐 155 明細表 2：dwd_ec_trd_cr

189、eate_ord_di 交易下單明細事實表 基本信息：數倉分層*業務分類 業務過程*存儲策略 表名*表中文名*生命周期 描述 表類型*公共層：明細數據層 電商業務 交易域/下單 每日增量（di）dwd_ec_trd_create_ord_di 交易下單明細事實表 356 天 交易下單明細事實表 事 實 事務表 字段管理和分區字段管理：使用代碼模式配置：-不支持修改表名 CREATE FACT TABLE dwd_ec_trd_create_ord_di ALIAS 交易下單明細事實表 (id ALIAS 主鍵 BIGINT COMMENT 主鍵,gmt_create ALIAS 訂單創建時間

190、DATETIME COMMENT 創建時間,gmt_modified ALIAS 訂單修改時間 DATETIME COMMENT 修改時間,sub_order_id ALIAS 子訂單 ID BIGINT NOT NULL COMMENT 子訂單 ID,parent_order_id ALIAS 父訂單 ID BIGINT COMMENT 父訂單 ID,buyer_id ALIAS 買家數字 id BIGINT COMMENT 買家數字 id,buyer_nick ALIAS 買家昵稱 STRING COMMENT 買家昵稱,item_id ALIAS 商品數字 id BIGINT COMME

191、NT 商品數字 id,item_price ALIAS 商品價格 單位分 DECIMAL(38,18)COMMENT 商品價格 單位分,buy_amount ALIAS 購買數量 BIGINT COMMENT 購買數量,biz_type ALIAS 交易類型 BIGINT COMMENT 交易類型,memo ALIAS 備注 STRING COMMENT 備注,pay_status ALIAS 支付狀態 BIGINT COMMENT 支付狀態,logistics_status ALIAS 物流狀態 BIGINT COMMENT 物流狀態,status ALIAS 狀態 BIGINT COMME

192、NT 狀態,seller_memo ALIAS 賣家的給交易的備注 STRING COMMENT 賣家的給交易的備注,buyer_memo ALIAS 買家給交易的備注 STRING COMMENT 買家給交易的備注,ip ALIAS 買家 IP STRING COMMENT 買家 IP,end_time ALIAS 交易結束時間 DATETIME COMMENT 交易結束時間,pay_time ALIAS 付款的時間 DATETIME COMMENT 付款的時間,產品實操：零售電商數據建模操作實踐 156 is_sub ALIAS 是否是子訂單 1 表示子訂單 BIGINT COMMENT

193、是否是子訂單 1 表示子訂單,is_parent ALIAS 是否是父訂單 1 表示父訂單 BIGINT COMMENT 是否是父訂單 1 表示父訂單,shop_id ALIAS 商家 id BIGINT COMMENT 商家 id,total_fee ALIAS 去除折扣和調整后的子訂單費用 DECIMAL(38,18)COMMENT 去除折扣和調整后的子訂單費用,PRIMARY KEY(sub_order_id)COMMENT 交易下單明細事實表 PARTITIONED BY(ds ALIAS 業務日期,yyyymmdd STRING COMMENT 業務日期,yyyymmdd)WITH(

194、life_cycle=365);-不支持修改表名 CREATE TABLE dwd_ec_trd_create_ord_di(id BIGINT COMMENT 主鍵,gmt_create DATETIME COMMENT 創建時間,gmt_modified DATETIME COMMENT 修改時間,sub_order_id BIGINT COMMENT 子訂單 ID,parent_order_id BIGINT COMMENT 父訂單 ID,buyer_id BIGINT COMMENT 買家數字 id,buyer_nick STRING COMMENT 買家昵稱,item_id BIGI

195、NT COMMENT 商品數字 id,item_price DECIMAL(38,18)COMMENT 商品價格 單位分,buy_amount BIGINT COMMENT 購買數量,biz_type BIGINT COMMENT 交易類型,memo STRING COMMENT 備注,pay_status BIGINT COMMENT 支付狀態,logistics_status BIGINT COMMENT 物流狀態,status BIGINT COMMENT 狀態,seller_memo STRING COMMENT 賣家的給交易的備注,buyer_memo STRING COMMENT

196、買家給交易的備注,ip STRING COMMENT 買家 IP,end_time DATETIME COMMENT 交易結束時間,pay_time DATETIME COMMENT 付款的時間,is_sub BIGINT COMMENT 是否是子訂單 1 表示子訂單,is_parent BIGINT COMMENT 是否是父訂單 1 表示父訂單,shop_id BIGINT COMMENT 商家 id,產品實操：零售電商數據建模操作實踐 157 total_fee DECIMAL(38,18)COMMENT 去除折扣和調整后的子訂單費用)COMMENT 交易下單明細事實表 PARTITION

197、ED BY(ds STRING COMMENT 業務日期,yyyymmdd);明細表 3：dwd_ec_itm_publish_event_detail_di 商品發布事件詳情事實表（可選）基本信息：數倉分層*業務分類 業務過程*存儲策略 表名*表中文名*生命周期 描述 表類型*公共層：明細數據層 電商業務 商品域/商品發布 每 日 增 量（di）dwd_ec_itm_publish_event_detail_di 商品發布事件詳情事實表 365 天 商品發布事件詳情事實表 事 實 事務表 字段管理和分區字段管理：-不支持修改表名 CREATE FACT TABLE dwd_ec_itm_pu

198、blish_event_detail_di ALIAS 商品發布事件詳情事實表 (operation_type ALIAS 操作類型 BIGINT COMMENT 操作類型,source_from ALIAS 商品發布源頭 STRING COMMENT 商品發布源頭,item_id ALIAS 商品數字 ID STRING COMMENT 商品數字 ID,user_id ALIAS 用戶 id STRING COMMENT 用戶 id,is_success ALIAS 是否發布成功 STRING COMMENT 是否發布成功,cate_id ALIAS 商品葉子類目 ID BIGINT COM

199、MENT 商品葉子類目 ID,cate_name ALIAS 商品葉子類目名稱 STRING COMMENT 商品葉子類目名稱)COMMENT 商品發布事件詳情事實表 PARTITIONED BY(ds ALIAS 業務日期,yyyymmdd STRING COMMENT 業務日期,yyyymmdd)WITH(life_cycle=365);產品實操：零售電商數據建模操作實踐 158-不支持修改表名 CREATE TABLE dwd_ec_itm_publish_event_detail_di(operation_type BIGINT COMMENT 操作類型,source_from STR

200、ING COMMENT 商品發布源頭,item_id STRING COMMENT 商品數字 ID,user_id STRING COMMENT 用戶 id,is_success STRING COMMENT 是否發布成功,cate_id BIGINT COMMENT 商品葉子類目 ID,cate_name STRING COMMENT 商品葉子類目名稱)COMMENT 商品發布事件詳情事實表 PARTITIONED BY(ds STRING COMMENT 業務日期,yyyymmdd)LIFECYCLE 365;4)數據指標 a)概覽 原子指標和派生指標可以被匯總層或應用層表模型關聯。在后續

201、建表模型時，我們可以快速勾選派生指標，構建模型，模型中的字段也可以和指標構建關聯關系。例如：原子指標mbr_cnt被匯總表模型dws_ec_mbr_cnt_std所關聯。產品實操：零售電商數據建模操作實踐 159 派生指標由原子指標、修飾詞、時間周期構成。例如，存量會員數+歷史截止當日+異常會員=歷史截至當日_異常會員_存量會員數，該派生指標可以作為模型的字段存在，也可以和模型的字段做關聯。b)原子指標 新建 13 個原子指標保存并提交，分別如下表；也可以下載 Excel 文件，使用 Excel導入，如果部分可選數據域未創建，請先將下載的 excel 文件中相關數據域刪除再執行導入。業務過程

202、英文縮寫 英文名稱 中文名稱 業務口徑 描述 指標來源 計算函數 小數位數 數據單位 是否去重 會員域/注冊 new_mbr_cnt new member count 注冊會員數 注冊會員數 計數（COUNT）0 人數 是 會員域/會員域_默認 mbr_cnt member count 存量會員數 注冊且激活的會員總量 計數（COUNT）0 人數 是 交易域/支付 pay_ord_cnt pay order count 支付子訂單數 支付子訂單數 計數（COUNT）0 人數 否 交易域/支付 pay_ord_amt GMV 訂單支付成功金額 GMV，訂單支付成功金額。訂單類型包含：等待賣家發貨

203、、等待買家確認收貨、交易成功；訂單支付狀態包含付款成功。累加（SUM）4 元（人民幣）否 交易域/支付 pay_itm_cnt pay item count 支付商品數 支付商品數 計數（COUNT）0 個 否 交易域/支付 pay_ord_pbt pay order pbt 客單價 訂單支付成功金額/支付子訂單數 求平均（AVG）4 元（人民幣）否 產品實操：零售電商數據建模操作實踐 160 交易域/支付 kpi_gmv_rate kpi_gmv_rate 成交金額完成度 成 交 金 額 目 標 值 為3000 萬；成交金額目標完成度=成交金額實際完成值/成交金額目標值；率 4 小數 否 物

204、流域/攬件 lgt_lanshou_ord_cnt lgt_lanshou_ord_cnt 物流攬收訂單數 物流攬收訂單數 計數（COUNT）0 筆 否 物流域/接單 lgt_crt_ord_cnt lgt_crt_ord_cnt 物流接單訂單數 物流接單訂單數 計數（COUNT）0 筆 否 物流域/簽收 lgt_sign_ord_cnt lgt_sign_ord_cnt 物流簽收訂單數 物流簽收訂單數 計數（COUNT）0 筆 否 物流域/物流域_默認 lgt_ord_cnt lgt_ord_cnt 物流訂單總數 物流訂單總數 累加（SUM）0 筆 否 信 用&風 控域/評價 remark_

205、ord_cnt remark order count 評價訂單數 評價訂單數 計數（COUNT）0 筆 否 信 用&風 控域/評價 remark_ord_rate remark order rate 評價訂單占比 評價訂單數/支付子訂單數 率 4 小數 否 c)修飾詞 新建 12 個修飾詞，保存并提交，分別如下表；也可以下載 Excel 文件，使用 Excel導入。修飾詞類型 英文縮寫 英文名稱 中文名稱 業務口徑 描述 數倉分層 普通業務修飾詞 00s 00s 00 后 00 后 普通業務修飾詞 90s 90s 90 后 90 后 普通業務修飾詞 80s 80s 80 后 80 后 普通業務

206、修飾詞 70s 70s 70 后 70 后 產品實操：零售電商數據建模操作實踐 161 普通業務修飾詞 men men 男性會員 男性會員 普通業務修飾詞 women women 女性會員 女性會員 普通業務修飾詞 act_tel act_tel 手機激活 手機激活 普通業務修飾詞 act_email act_email 郵箱激活 郵箱激活 普通業務修飾詞 exp exp 異常會員 異常會員 普通業務修飾詞 high high 高級會員 高級會員 普通業務修飾詞 mid mid 中級會員 中級會員 普通業務修飾詞 low low 初級會員 初級會員 d)時間周期 使用默認配置。產品實操：零售電

207、商數據建模操作實踐 162 e)派生指標 會員域下的派生指標 批量創建會員域/會員域_默認業務過程下的 13 個派生指標。原子指標：存量會員數 修飾詞：上文修飾詞列表中的所有一共 12 個，再加一個修飾詞 system_empty（空）。批量選會合并成一個，所以這里需要一個一個選后添加 時間周期：std（歷史截止當日）單個創建會員域/注冊業務過程下的 1 個派生指標 時間周期*修飾詞 原子指標*數倉分層*業務分類 業務過程*中文名稱*英文名稱 描述 Cm（自然月）new_mbr_cnt（注冊會員數）公共層：匯總數據層 電商業務 會員域/注冊 自然月_注冊會員數（點擊智能推薦）new_mbr_c

208、nt_cm（點擊智能推薦）產品實操：零售電商數據建模操作實踐 163 交易域下的派生指標 分兩次批量創建交易域/支付業務過程下的派生指標，方法同上。第一批 原子指標：成交金額完成度、客單價、支付商品數、支付子訂單數、訂單支付成功金額 修飾詞：system_empty（空）時間周期：1d（近 1 天）第二批 原子指標：成交金額完成度、訂單支付成功金額 修飾詞：system_empty（空）時間周期：fy（財年）物流域下的派生指標 單個創建物流域下的 4 個派生指標，分別如下。時間周期*修飾詞 原子指標*數倉分層*業務分類 業務過程*中文名稱*英文名稱 描述 1d（近 1天）lgt_lanshou

209、_ord_cnt（物流攬收訂單數）公共層：匯總數據層 電商業務 物流域/攬件 近 1 天_物流攬收訂單數 lgt_lanshou_ord_cnt_1d 產品實操：零售電商數據建模操作實踐 164 1d（近 1天）lgt_crt_ord_cnt（物流攬收訂單數）公共層：匯總數據層 電商業務 物流域/接單 近 1 天_物流接單訂單數 lgt_crt_ord_cnt_1d 1d（近 1天）lgt_sign_ord_cnt（物流攬收訂單數）公共層：匯總數據層 電商業務 物流域/簽收 近 1 天_物流簽收訂單數 lgt_sign_ord_cnt_1d 1d（近 1天）lgt_ord_cnt（物流攬收訂單

210、數）公共層：匯總數據層 電商業務 物流域/物流域_默認 近 1 天_物流訂單總數 lgt_ord_cnt_1d 信用&風控域下的派生指標 單個創建信用&風控域下的 3 個派生指標，分別如下。時間周期*修飾詞 原子指標*數倉分層*業務分類 業務過程*中文名稱*英文名稱 描述 1d（近 1天）remark_ord_cnt（評價訂單數）公共層：匯總數據層 電商業務 信用&風控域/評價 近 1 天_評價訂單數 remark_ord_cnt_1d 1d（近 1天）remark_ord_rate（評價訂單占比）公共層：匯總數據層 電商業務 信用&風控域/評價 近 1 天_評價訂單占比 remark_ord

211、_rate_1d 1d（近 1天）00s（00后）remark_ord_cnt（評價訂單數）公共層：匯總數據層 電商業務 信用&風控域/評價 近 1 天_00 后_評價訂單數 remark_ord_cnt_1d_00s 5)維度建模（公共層匯總表模型和應用層應用表模型）a)公共層-匯總表模型 創建 6 張匯總表模型，分別如下。匯總表 1：dws_ec_mbr_cnt_std 歷史截至當日存量會員數 cube 統計表 基本信息：產品實操：零售電商數據建模操作實踐 165 數倉分層*業務分類 數據域*時間周期*修飾詞 表名*表中文名*生命周期 描述 表類型*公共層：匯總數據層 電商業務 會 員 域

212、（mbr）Std（歷史截止當日）dws_ec_mbr_cnt_std 歷史截至當日存量會員數 cube 統計表 365 天 歷史截至當日存 量 會 員 數cube 統計表 輕 度 匯總表 字段管理和分區字段管理：當前表使用快捷模式結合代碼模式配置?？旖菽Ｊ脚渲茫簊tep1：從指標導入。注 這里僅作為核心功能演示，實際當前表不需要導入，后續的匯總表中會使用到從指標導入的功能。產品實操：零售電商數據建模操作實踐 166 step2：使用“代碼模式”，將下文中的 MaxCompute DDL 語句復制進去，點擊確定替換表內容。step3：可視化編輯關聯粒度/指標，并按下圖關聯對應的統計粒度、原子指標

213、、派生指標，點擊確定。最終得到如圖表結構，保存。產品實操：零售電商數據建模操作實踐 167 代碼模式配置：-不支持修改表名 CREATE TABLE dws_ec_mbr_cnt_std(reg_prov_id STRING COMMENT 注冊填寫省 ID,reg_prov_name STRING COMMENT 注冊填寫省名稱,reg_gender STRING COMMENT 身份證解析性別（F 女，M 男，unkown 表示身份證為空或格式不對）,reg_gender_name STRING COMMENT 身份證解析性別（F 女，M 男，unkown 表示身份證為空或格式不對）,ag

214、e_tag STRING COMMENT 出生年代,user_active_type STRING COMMENT 用戶激活方式,user_active_name STRING COMMENT 激活方式名稱,vip_level BIGINT COMMENT VIP 等級,vip_level_name STRING COMMENT VIP 等級名稱。v1，v2，v3 等,mbr_cnt BIGINT COMMENT 存量會員數)COMMENT 歷史截至當日_存量會員數_cube 統計表 PARTITIONED BY(ds STRING COMMENT 業務日期,yyyymmdd)LIFECYCL

215、E 365;-不支持修改表名 CREATE ADVANCED DWS TABLE dws_ec_mbr_cnt_std ALIAS 歷史截至當日_存量會員數_cube 統計表 產品實操：零售電商數據建模操作實踐 168(reg_prov_id ALIAS 注冊填寫省 ID STRING COMMENT 注冊填寫省 ID REFERENCES dim_ec_mbr_user_info.reg_prov_id,reg_prov_name ALIAS 注冊填寫省名稱 STRING COMMENT 注冊填寫省名稱,reg_gender ALIAS 身份證解析性別（F 女，M 男，unkown 表示身份

216、證為空或格式不對）STRING COMMENT 身份證解析性別（F 女，M 男，unkown 表示身份證為空或格式不對）REFERENCES dim_ec_mbr_user_info.reg_gender,reg_gender_name ALIAS 身份證解析性別（F 女，M 男，unkown 表示身份證為空或格式不對）STRING COMMENT 身份證解析性別（F 女，M 男，unkown 表示身份證為空或格式不對）,age_tag ALIAS 出生年代 STRING COMMENT 出生年代 REFERENCES dim_ec_mbr_user_info.id_age,user_acti

217、ve_type ALIAS 用戶激活方式 STRING COMMENT 用戶激活方式 REFERENCES dim_ec_mbr_user_info.user_active_type,user_active_name ALIAS 激活方式名稱 STRING COMMENT 激活方式名稱,vip_level ALIAS VIP 等級 BIGINT COMMENT VIP 等級 REFERENCES dim_ec_mbr_user_info.vip_level,vip_level_name ALIAS VIP 等級名稱。v1，v2，v3 等 STRING COMMENT VIP 等級名稱。v1，v

218、2，v3 等,mbr_cnt ALIAS 存量會員數 BIGINT COMMENT 存量會員數 WITH(atomic_indicator=mbr_cnt,time_period=std)COMMENT 歷史截至當日_存量會員數_cube 統計表 PARTITIONED BY(ds ALIAS 業務日期,yyyymmdd STRING COMMENT 業務日期,yyyymmdd)WITH(life_cycle=365);匯總表 2：dws_ec_mbr_register_cm 近 1 自然月會員注冊信息統計（可選）基本信息：數倉分層*業務分類 數據域*時間周期*修飾詞 表名*表中文名*生命周期

219、 描述 表類型*公共層：匯總數據層 電商業務 會員域（mbr）Cm（自然月）dws_ec_mbr_register_cm 近 1 自然月會員注冊信息統計 720 天 近 1 自然月會員注冊信息統計 普 通 匯總表 字段管理和分區字段管理：產品實操：零售電商數據建模操作實踐 169-不支持修改表名 CREATE DWS TABLE dws_ec_mbr_register_cm ALIAS 近 1 自然月_會員_注冊信息統計 (reg_month ALIAS 注冊月份 STRING COMMENT 注冊月份,new_mbr_cnt_cm ALIAS 自然月_注冊會員數 BIGINT COMMENT

220、 自然月_注冊會員數 REFERENCES(INDDC100268E31)COMMENT 近 1 自然月_會員_注冊信息統計 PARTITIONED BY(ds ALIAS 業務日期,yyyymmdd STRING COMMENT 業務日期,yyyymmdd)WITH(life_cycle=720);-不支持修改表名 CREATE DWS TABLE dws_ec_mbr_register_cm ALIAS 近 1 自然月_會員_注冊信息統計 (reg_month ALIAS 注冊月份 STRING COMMENT 注冊月份,new_mbr_cnt_cm ALIAS 自然月_注冊會員數 BIG

221、INT COMMENT 自然月_注冊會員數 REFERENCES(new_mbr_cnt_cm)COMMENT 近 1 自然月_會員_注冊信息統計 PARTITIONED BY(ds ALIAS 業務日期,yyyymmdd STRING COMMENT 業務日期,yyyymmdd)WITH(life_cycle=720);可視化編輯或查看關聯粒度/指標信息：產品實操：零售電商數據建模操作實踐 170 匯總表 3：dws_ec_trd_cate_commodity_gmv_kpi_fy 財年 KPI 類目品類_GMV統計 基本信息：數倉分層*業務分類 數據域*時間周期*修飾詞 表名*表中文名*生

222、命周期 描述 表類型*公共層：匯總數據層 電商業務 交 易 域（trd）Fy（財年）dws_ec_trd_cate_commodity_gmv_kpi_fy 財年 KPI 類目品類_GMV 統計 365 天 財年 KPI_類 目 品 類GMV 統計 普 通 匯總表 字段管理和分區字段管理：-不支持修改表名 CREATE DWS TABLE dws_ec_trd_cate_commodity_gmv_kpi_fy ALIAS 財年 KPI_類目_品類_GMV 統計 (cate_id ALIAS 商品葉子類目 ID BIGINT COMMENT 商品葉子類目 ID,cate_name ALIAS

223、商品葉子類目名稱 STRING COMMENT 商品葉子類目名稱,commodity_id ALIAS 品類 ID BIGINT COMMENT 品類 ID,commodity_name ALIAS 品類名稱 STRING COMMENT 品類名稱,pay_ord_amt_fy ALIAS 財年_訂單支付成功金額 DECIMAL COMMENT 財年_訂單支付成功金額 REFERENCES(pay_ord_amt_fy),kpi_gmv_rate_fy ALIAS 財年_成交金額完成度 DECIMAL COMMENT 財年_成交金額完成度)COMMENT 財年 KPI_類目_品類_GMV 統計

224、 PARTITIONED BY(ds ALIAS 業務日期,yyyymmdd STRING COMMENT 業務日期,yyyymmdd)WITH(life_cycle=365);-不支持修改表名 CREATE TABLE dws_ec_trd_cate_commodity_gmv_kpi_fy(cate_id BIGINT COMMENT 商品葉子類目 ID,cate_name STRING COMMENT 商品葉子類目名稱,commodity_id BIGINT COMMENT 品類 ID,commodity_name STRING COMMENT 品類名稱,pay_ord_amt_fy D

225、ECIMAL COMMENT 財年_訂單支付成功金額,kpi_gmv_rate_fy DECIMAL COMMENT 財年_成交金額完成度 產品實操：零售電商數據建模操作實踐 171)COMMENT 財年 KPI_類目_品類_GMV 統計 PARTITIONED BY(ds STRING COMMENT 業務日期,yyyymmdd)LIFECYCLE 365;可視化查看或編輯關聯粒度/指標：匯總表 4：dws_ec_trd_pay_cate_commodity_1d 近 1 天類目品類_交易支付指標匯總（可選）基本信息：數倉分層*業務分類 數據域*時間周期*修飾詞 表名*表中文名*生命周期 描

226、述 表類型*匯總層：公共數據層 電商業務 交 易 域（trd）1d（近 1天）dws_ec_trd_pay_cate_commodity_1d 近1天類目品類_交易支付指標匯總 720 天 近1天_類目品類交易支付指標匯總 普 通 匯總表 字段管理和分區字段管理：-不支持修改表名 CREATE DWS TABLE dws_ec_trd_pay_cate_commodity_1d ALIAS 近 1 天_類目_品類_交易支付指標匯總 (stat_date ALIAS 統計日期 STRING COMMENT 統計日期,產品實操：零售電商數據建模操作實踐 172 stat_month ALIAS 統

227、計月份 STRING COMMENT 統計月份,stat_year ALIAS 統計年份 STRING COMMENT 統計年份,cate_id ALIAS 商品葉子類目 ID BIGINT COMMENT 商品葉子類目 ID REFERENCES dim_ec_itm_item_info.cate_id,cate_name ALIAS 商品葉子類目名稱 STRING COMMENT 商品葉子類目名稱,commodity_id ALIAS 品類 ID BIGINT COMMENT 品類 ID REFERENCES dim_ec_itm_item_modity_id,commodity_name

228、 ALIAS 品類名稱 STRING COMMENT 品類名稱,pay_ord_cnt_1d ALIAS 近 1 天_支付子訂單數 BIGINT COMMENT 近 1 天_支付子訂單數 REFERENCES(pay_ord_cnt_1d),pay_itm_cnt_1d ALIAS 近 1 天_支付商品數 BIGINT COMMENT 近 1 天_支付商品數 REFERENCES(pay_itm_cnt_1d),pay_ord_amt_1d ALIAS 近 1 天_訂單支付成功金額 DECIMAL COMMENT 近 1 天_訂單支付成功金額 REFERENCES(pay_ord_amt_1d

229、),pay_ord_pbt_1d ALIAS 近 1 天_客單價 DECIMAL COMMENT 近 1 天_客單價 REFERENCES(pay_ord_pbt_1d)COMMENT 近 1 天_類目_品類_交易支付指標匯總 PARTITIONED BY(ds ALIAS 業務日期,yyyymmdd STRING COMMENT 業務日期,yyyymmdd)WITH(life_cycle=720);-不支持修改表名 CREATE TABLE dws_ec_trd_pay_cate_commodity_1d(stat_date STRING COMMENT 統計日期,stat_month ST

230、RING COMMENT 統計月份,stat_year STRING COMMENT 統計年份,cate_id BIGINT COMMENT 商品葉子類目 ID,cate_name STRING COMMENT 商品葉子類目名稱,commodity_id BIGINT COMMENT 品類 ID,commodity_name STRING COMMENT 品類名稱,pay_ord_cnt_1d BIGINT COMMENT 近 1 天_支付子訂單數,pay_itm_cnt_1d BIGINT COMMENT 近 1 天_支付商品數,pay_ord_amt_1d DECIMAL COMMENT

231、近 1 天_訂單支付成功金額,pay_ord_pbt_1d DECIMAL COMMENT 近 1 天_客單價)COMMENT 近 1 天_類目_品類_交易支付指標匯總 PARTITIONED BY 產品實操：零售電商數據建模操作實踐 173(ds STRING COMMENT 業務日期,yyyymmdd)LIFECYCLE 720;可視化查看或編輯關聯粒度/指標：匯總表 5：dws_ec_lgt_ord_overview_1d 近 1 天_物流訂單概覽指標匯總（可選）基本信息：數倉分層*業務分類 數據域*時間周期*修飾詞 表名*表中文名*生命周期 描述 表類型*公共層：匯總數據層 電商業務

232、物 流 域（lgt）1d（近 1天）dws_ec_lgt_ord_overview_1d 近 1 天_物流訂單概覽指標匯總 365 天 近 1 天_物流訂單概覽指標匯總 普 通 匯總表 字段管理和分區字段管理：-不支持修改表名 CREATE DWS TABLE dws_ec_lgt_ord_overview_1d ALIAS 近 1 天_物流訂單概覽指標匯總 (stat_date ALIAS 統計日期 STRING COMMENT 統計日期,lgt_ord_cnt_1d ALIAS 近 1 天_物流訂單總數 BIGINT MEASUREMENT COMMENT 近 1 天_物流訂單總數 REF

233、ERENCES(lgt_ord_cnt_1d),產品實操：零售電商數據建模操作實踐 174 lgt_crt_ord_cnt_1d ALIAS 近 1 天_物流接單訂單數 BIGINT MEASUREMENT COMMENT 近 1 天_物流接單訂單數 REFERENCES(lgt_crt_ord_cnt_1d),lgt_lanshou_ord_cnt_1d ALIAS 近 1 天_物流攬收訂單數 BIGINT MEASUREMENT COMMENT 近 1 天_物流攬收訂單數 REFERENCES(lgt_lanshou_ord_cnt_1d),lgt_sign_ord_cnt_1d ALIA

234、S 近 1 天_物流簽收訂單數 BIGINT MEASUREMENT COMMENT 近 1 天_物流簽收訂單數 REFERENCES(lgt_sign_ord_cnt_1d)COMMENT 近 1 天_物流訂單概覽指標匯總 PARTITIONED BY(ds ALIAS 業務日期,yyyymmdd STRING COMMENT 業務日期,yyyymmdd)WITH(life_cycle=365);-不支持修改表名 CREATE TABLE dws_ec_lgt_ord_overview_1d(stat_date STRING COMMENT 統計日期,lgt_ord_cnt_1d BIGIN

235、T COMMENT 近 1 天_物流訂單總數,lgt_crt_ord_cnt_1d BIGINT COMMENT 近 1 天_物流接單訂單數,lgt_lanshou_ord_cnt_1d BIGINT COMMENT 近 1 天_物流攬收訂單數,lgt_sign_ord_cnt_1d BIGINT COMMENT 近 1 天_物流簽收訂單數)COMMENT 近 1 天_物流訂單概覽指標匯總 PARTITIONED BY(ds STRING COMMENT 業務日期,yyyymmdd)LIFECYCLE 365;可視化查看或編輯關聯粒度/指標：產品實操：零售電商數據建模操作實踐 175 匯總表

236、6：dws_ec_risk_remark_tag_1d 近 1 天_評價算法打標分類指標匯總表（可選）基本信息：數倉分層*業務分類 數據域*時間周期*修飾詞 表名*表中文名*生命周期 描述 表類型*公共層：匯總數據層 電商業務 信 用&風 控 域（risk）1d（近 1天）dws_ec_risk_remark_tag_1d 近1天_評價算法打標分類指標匯總表 365 天 近 1 天_評價算法打標分類指標匯總表 普 通 匯總表 字段管理和分區字段管理：-不支持修改表名 CREATE DWS TABLE dws_ec_risk_remark_tag_1d ALIAS 近 1 天_評價算法打標分類指

237、標匯總表 (stat_date ALIAS 統計日期 STRING COMMENT 統計日期,remark_tag ALIAS 評價打標分類 STRING COMMENT 評價打標分類,cate_id ALIAS 商品葉子類目 ID BIGINT COMMENT 商品葉子類目 ID REFERENCES dim_ec_itm_cat.cate_id,cate_name ALIAS 商品葉子類目名稱 STRING COMMENT 商品葉子類目名稱,commodity_id ALIAS 品類 ID BIGINT COMMENT 品類 ID REFERENCES dim_ec_itm_item_mo

238、dity_name,commodity_name ALIAS 品類名稱 STRING COMMENT 品類名稱,remark_ord_cnt_1d ALIAS 近 1 天_評價訂單數 BIGINT COMMENT 近 1 天_評價訂單數 REFERENCES(remark_ord_cnt_1d)COMMENT 近 1 天_評價算法打標分類指標匯總表 PARTITIONED BY(ds ALIAS 業務日期,yyyymmdd STRING COMMENT 業務日期,yyyymmdd)WITH(life_cycle=365);-不支持修改表名 CREATE TABLE dws_ec_risk_re

239、mark_tag_1d(stat_date STRING COMMENT 統計日期,remark_tag STRING COMMENT 評價打標分類,產品實操：零售電商數據建模操作實踐 176 cate_id BIGINT COMMENT 商品葉子類目 ID,cate_name STRING COMMENT 商品葉子類目名稱,commodity_id BIGINT COMMENT 品類 ID,commodity_name STRING COMMENT 品類名稱,remark_ord_cnt_1d BIGINT COMMENT 近 1 天_評價訂單數)COMMENT 近 1 天_評價算法打標分類

240、指標匯總表 PARTITIONED BY(ds STRING COMMENT 業務日期,yyyymmdd)LIFECYCLE 365;可視化查看或編輯關聯粒度/指標：b)應用層-應用表模型 創建 1 張應用表模型，如下。應用表 1：ads_ec_ec360_gmv_kpi_overview 電商 360KPI 概覽 基本信息：產品實操：零售電商數據建模操作實踐 177 數倉分層*集市/主題*時間周期*修飾詞 表名*表中文名*生命周期 描述 表類型*應用層：應用數據層 電商 360 Fy（財年）、std（歷史截止當日)ads_ec_ec360_gmv_kpi_overview 電商 360KPI

241、 概覽 電商360KPI概覽 普通應用表 字段管理和分區字段管理：-不支持修改表名 CREATE DWS TABLE ads_ec_ec360_gmv_kpi_overview ALIAS 電商 360KPI 概覽 (pay_ord_amt_fy ALIAS pay_ord_amt_fy DECIMAL REFERENCES(pay_ord_amt_fy),mbr_cnt_std ALIAS mbr_cnt_std BIGINT REFERENCES(mbr_cnt_std),kpi_gmv_rate_fy ALIAS kpi_gmv_rate_fy DECIMAL REFERENCES(kp

242、i_gmv_rate_fy)COMMENT 電商 360KPI 概覽 PARTITIONED BY(ds ALIAS 業務日期,yyyymmdd STRING COMMENT 業務日期,yyyymmdd);-不支持修改表名 CREATE TABLE ads_ec_ec360_gmv_kpi_overview(pay_ord_amt_fy DECIMAL,mbr_cnt_std BIGINT,kpi_gmv_rate_fy DECIMAL)COMMENT 電商 360KPI 概覽 PARTITIONED BY 產品實操：零售電商數據建模操作實踐 178(ds STRING COMMENT 業務日

243、期,yyyymmdd);可視化查看或編輯關聯粒度/指標：6)逆向建模 上文中主要是講解了正向建模，但是在實際生產中很多企業已經有了大量的MaxCompute 物理表，同時又希望在 DataWorks 智能數據建模產品統一管理所有模型，那么逆向建模功能就可以幫助企業快速將已創建的數據表生成規范的數倉模型。該功能無需您再次執行建模操作，即可快速將已有物理表反向建模至DataWorks 的維度建模中，節省了大量的時間成本。注：該步驟僅為核心功能展示，不操作不會影響后續實驗。具體的逆向建模操作介紹請參見逆向建模官方文檔。產品實操：零售電商數據建模操作實踐 179 7)模型發布 確 認 模 型 無 誤

244、后，將 其 中 的 維 度 表（dim_ec_itm_item_info、dim_ec_mbr_user_info）、匯總表（dws_ec_trd_cate_commodity_gmv_kpi_fy、dws_ec_mbr_cnt_std）、明 細 表（dwd_ec_trd_create_ord_di）、應 用 表（ads_ec_ec360_gmv_kpi_overview）發布至對應空間的開發環境和生產環境，后續實驗中應用到這幾張表。發布成功后可以前往數據地圖查看表結構。設置項 說明 工作空間 這里會列出建?？臻g中配置的所有數據研發工作空間。本實驗選擇當前工作空間。引擎類型 支持 MaxCom

245、pute、E-MapReduce、Hologres 等多種引擎。本實驗選擇 MaCompute 引擎實例 根據需求將表物化至引擎類型參數中相應類型的數據存儲引擎。生效環境 標準模式下，可選擇發布至開發或生產環境。發布模式 增量發布：選擇該模式，發布時僅會將目標模型此次變更的內容發布至對應引擎。刪除重建：選擇該模式，發布時會將對應引擎中之前已發布的該模型刪除，刪除后再重新創建此次發布的模型。附件 MaxCompute ODS 層 DDL 建表語句。產品實操：零售電商數據建模操作實踐 180 注 主要為維度建模時快捷模式編輯字段“使用已有表/視圖”功能使用，全部產品-數據開發-臨時查詢中創建 od

246、ps sql 節點中執行，如未執行，也可以在配置數據集成離線同步采集數據時，一鍵建表創建。CREATE TABLE IF NOT EXISTS ods_mbr_user_info(id BIGINT COMMENT 主鍵,gmt_create DATETIME COMMENT 創建時間,gmt_modified DATETIME COMMENT 修改時間,user_id BIGINT COMMENT 會員數字 ID,nick STRING COMMENT 會員 NICK。會員昵稱,reg_fullname STRING COMMENT 個人認證表示真實姓名，企業認證表示企業名稱,reg_mob

247、ile_phone STRING COMMENT 注冊時綁定手機號碼,reg_email STRING COMMENT 注冊填寫 EMAIL（用戶可以修改）,reg_gender STRING COMMENT 注冊填寫性別（F 女，M 男，不是這兩個就是未知的，說明性別保密）,reg_birthdate DATETIME COMMENT 注冊填寫生日（用戶可以修改）,reg_address STRING COMMENT 注冊填寫地址（用戶可以修改）,reg_nation_id STRING COMMENT 注冊填寫國家 ID（暫時為空）,reg_prov_id STRING COMMENT 注

248、冊填寫省 ID,reg_city_id STRING COMMENT 注冊填寫城市 ID,user_regip STRING COMMENT 注冊 IP,id_card_type BIGINT COMMENT 會員認證證件類型 0：未知 1：身份證 2：企業營業執照號,id_card_number STRING COMMENT 個人認證表示身份證號，企業認證表示企業的營業執照號，沒有認證不保證準確性,user_regdate DATETIME COMMENT 注冊時間,user_active_type STRING COMMENT 用戶激活方式，1 郵件;2 手機;,user_active_t

249、ime DATETIME COMMENT 激活時間,vip_level STRING COMMENT VIP 等級,is_delete STRING COMMENT 是否刪除)COMMENT 會員信息源表 PARTITIONED BY(ds STRING COMMENT YYYYMMDD)LIFECYCLE 10000;產品實操：零售電商數據建模操作實踐 181 CREATE TABLE IF NOT EXISTS ods_t_area(id BIGINT,pid BIGINT COMMENT 父級,name STRING COMMENT 名稱,shortname STRING COMMENT

250、 簡稱,longitude STRING COMMENT 經度,latitude STRING COMMENT 緯度,level BIGINT COMMENT 級別,sort BIGINT COMMENT 排序)COMMENT 地區源表 PARTITIONED BY(ds STRING COMMENT YYYYMMDD)LIFECYCLE 30;CREATE TABLE IF NOT EXISTS ods_item_info(id BIGINT COMMENT 主鍵,gmt_create DATETIME COMMENT 創建時間,gmt_modified DATETIME COMMENT 修

251、改時間,item_id BIGINT COMMENT 商品數字 ID,title STRING COMMENT 商品標題,sub_title STRING COMMENT 商品子標題,pict_url STRING COMMENT 主圖 URL,desc_path STRING COMMENT 商品描述的路徑,item_status BIGINT COMMENT 商品狀態 1：確認通過 0：未確認通過,last_online_time DATETIME COMMENT 最近一次開始銷售時間，商品上架時間,last_offline_time DATETIME COMMENT 銷售結束時間，表示一

252、個銷售周期的結束，僅作用于拍賣商品,duration BIGINT COMMENT 有效期，銷售周期，只有兩個值，7天或 14 天,reserve_price DECIMAL(38,18)COMMENT 當前價格,secure_trade_ordinary_post_fee DECIMAL(38,18)COMMENT 平郵費用,secure_trade_fast_post_fee DECIMAL(38,18)COMMENT 快遞費用,產品實操：零售電商數據建模操作實踐 182 secure_trade_ems_post_fee DECIMAL(38,18)COMMENT EMS 郵費,last

253、_online_quantity BIGINT COMMENT 商品最近一次上架時的庫存數量,features STRING COMMENT 商品特征,cate_id BIGINT COMMENT 商品葉子類目 ID,cate_name STRING COMMENT 商品葉子類目名稱,commodity_id BIGINT COMMENT 品類 ID,commodity_name STRING COMMENT 品類名稱,is_virtual STRING COMMENT 是否虛擬商品,shop_id BIGINT COMMENT 商家 ID,shop_nick STRING COMMENT 商

254、家 NICK,is_deleted BIGINT COMMENT 類目是否刪除)PARTITIONED BY(ds STRING COMMENT YYYYMMDD)LIFECYCLE 30;CREATE TABLE IF NOT EXISTS ods_trade_order(id BIGINT COMMENT 主鍵,gmt_create DATETIME COMMENT 創建時間,gmt_modified DATETIME COMMENT 修改時間,sub_order_id BIGINT COMMENT 子訂單 ID,parent_order_id BIGINT COMMENT 父訂單 ID,

255、buyer_id BIGINT COMMENT 買家數字 id,buyer_nick STRING COMMENT 買家昵稱,item_id BIGINT COMMENT 商品數字 id,item_price DECIMAL(38,18)COMMENT 商品價格 單位分,buy_amount BIGINT COMMENT 購買數量,biz_type BIGINT COMMENT 交易類型,memo STRING COMMENT 備注,pay_status BIGINT COMMENT 支付狀態,logistics_status BIGINT COMMENT 物流狀態,status BIGINT

256、 COMMENT 狀態,seller_memo STRING COMMENT 賣家的給交易的備注,buyer_memo STRING COMMENT 買家給交易的備注,ip STRING COMMENT 買家 IP,end_time DATETIME COMMENT 交易結束時間,pay_time DATETIME COMMENT 付款的時間,is_sub BIGINT COMMENT 是否是子訂單 1 表示子訂單,產品實操：零售電商數據建模操作實踐 183 is_parent BIGINT COMMENT 是否是父訂單 1 表示父訂單,shop_id BIGINT COMMENT 商家 id,total_fee DECIMAL(38,18)COMMENT 去除折扣和調整后的子訂單費用)PARTITIONED BY(ds STRING COMMENT YYYYMMDD)LIFECYCLE 30;1 亞當森 Star Schema 完全參考手冊，北京：清華大學出版社，2012 2 Ralph，Kimball，Margy，Ross，數據倉庫工具箱（第 3 版），北京：清華大學出版社，2015 以上實驗流程結束，如有其他使用問題，請加入 DataWorks 交流群：