一、阿里巴巴數據需求流轉介紹

數據倉庫建設過程中通常會有以下幾類角色參與：

• 數據需求方：包括運營同學、BI、業務產品經理等業務角色，這類角色對數據概念了解甚少，可能也不知道模型、表、派 生指標等專業數據名詞，但這類角色往往都是業務專家，對業務情況非常了解。
• 數據產品經理：阿里內部大部分 BU 都會有數據產品經理這個角色，他們負責把業務需求轉化為能實際進行數據開發的數據需求。這也就意味著數據產品經理本身的要求是既需要對所負責的業務策略要非常地了解，也需要數據開發工作非常了解。
• 數據開發工程師：數據研發工程師主要負責數據模型、數據指標的設計以及相應的數據研發工作。

二、阿里巴巴數倉建模最佳實踐

• 業務分類：阿里巴巴大多數數倉團隊都是基于 Kimball 理論做維度建模，其更注重公共層和應用層的建設。由于涉及到的業務體系較為龐大，為了能夠更好的各模型所屬業務團隊，我們在維度建模理論的基礎上，我們增設了“業務分類”，它從更高的視角把不同業務團隊的數據倉庫區分開來。
• 數據域：是公共層里非常重要的一個概念。在設置數據域時，我們往往會先劃分好業務流程，通過將業務流程進行聚合形成一部分數據域，然后我們再將整個業務中重要的參與對象或系統梳理出來形成另外一部分數據與，從而形成完整的數據域。
• 數據集市：是應用層里非常重要的一個概念。應用層是否建模，實際上要應業務自身發展情況而定，可以選擇應用層建模、部分建模或者不建模。數據集市又可以分為業務集市、數據產品集市和公共集市。

除了剛才講到的數倉頂層設計外，數據規范的制定與執行，也是整個數倉建設過程中最難的點。數據規范，如表名規范到底應該怎么去建，我們也有已經將其以內容呈現的方式，內置在我們的零售行業模型模版中。諸如字段命名規范、存儲策略的規范命名等，我們也都以內容內置、輸入檢測、提交卡點等形式體現在產品中，在最大程度上保證規范的落地。

在維度建模理論中，維度是一個非常重要的概念，維度是我們觀察業務狀況的視角，建立整體統一的維度，有助于后續各種業務分析工作的開展。例如交易域的維度包含訂單、訂單類型、訂單支付類型等。

由于數據建模的使用具備一定的理論門檻，DataWorks 智能數據建模工作提供開箱即用的零售行業數據倉庫模型內容，涵蓋大部分分層劃域，涉及訂單、會員、商品等維度及大部分的模型和指標。模型導入后，在當前頁面可以完整地看到這些模型及指標。

三、阿里巴巴數倉建模實操演示

接下來我會帶大家一起做一個數據倉庫模型設計的實操演示。數據建模主要有四方面的工作：數倉規劃、數據標準、數據指標和維度建模。在日常的建模工作中，架構師先定義好數倉規劃、數據標準、原子指標修飾詞，再由模型設計師和數據研發同學把模型和指標創建好。和建模分工一致，DataWorks 智能數據建模在產品設計上，數倉規劃、數據標準和數據指標也最終都是服務于維度建模。 

現在我們一起看一下，整個數倉建模實踐過程中，大家可能都會遇到的一些問題。

• 建模冷啟動難的問題：對于大部分想要做好模型設計工作的數據倉庫團隊來說，在模型設計初期，可能會面臨很多的歷史包袱。
• 規范落地難的問題：規范制定非常難，制定好之后落地也很難。我們之前經常會發現沒有按照規范去做研發，導致了很多額外的溝通。
• 建模效率低的問題：從不建模到建模，日常建模方式一定會有效率的降低。
• 模型設計和數據研發脫節的問題：阿里內部數據研發的模型設計更多是用線下的 Excel，這種方式對數據研發階段來講，能獲取的幫助不是特別多，銜接的體驗就會較差。

下面來具體展開介紹每一個問題的解決方法。

問題1：如何解決已有數倉建模冷啟動難的問題？

由于歷史原因，很多模型沒法維護，還存在很多相似的模型或低價值的模型，很多模型沒有在用了，但存儲還在。我們希望大家能夠做一次歷史模型的線下梳理，梳理出來后（我們稱為全面分析盤點），下線歷史上沒有用的或者相似的模型。

對相似模型處理完成后，會形成一個數據模型的總線矩陣，這個總線矩陣需要去兼容一些歷史規范問題，我們可以借此把整個總線矩陣梳理好，最后通過產品的方式把歷史存量的模型導入到產品里，也就完成了存量模型的線上化管理。最終線下模型處理好之后，存量模型開始正常在產品上做建模之前，我們會把線下建模的口子關掉，從而保障模型后續都是比較規范的。

大多數架構師會通過 DataWorks 逆向建模把已經線下治理好的存量模型一次性批量導入到 DataWorks 產品里，導入后再去正向建模或修改。這里我們建議最好是做好線下梳理之后再使用這個功能。

問題2：如何解決數倉規范落地難的問題？ 

逆向建模之后一個很重要的工作就是去關掉線下所有能夠去建模的口子，我們的做法是在系統里把建模檢查器配置好，其作用是后續所有人要去開發數倉核心表時，必須要建模，不能直接上線。

規范落地比較典型的場景是表名規范，過去大家需要記表名規則是什么，規則里的每個詞到底應該怎么寫，而現在已經完全產品化，模型設計師新建一個模型時，會調用對應分層下的模型命名規則，把表名自動生成出來，直接避免了模型命名不規范的情況出現。

問題3：如何提升模型設計的工作效率？

在指標設計方面，最重要的一個點是通過勾選原子指標、修飾詞、時間周期批量生成派生指標，生成后再做匯總層模型和應用層模型建設，效率就會高很多。

在數據模型創建時，一個經典的建模場景是從表導入再字段冗余。以明細表模型創建為例，DWD 會基于 ODS 的數據表結構，直接導入，基本上不會做改變，只是基于這個基礎做一些臟數據處理，然后再把經常需要分析的維度冗余到 DWD 這張表里來，這時就可以快速完成 DWD 的模型設計。

通過這樣的建模方式后續生成的 ETL 代碼就會非常規范。基本上只需要添加一下 where 條件以及 case when等就可以了。

對于匯總表和應用表，通常是直接從指標導入，把數據指標中創建好的派生指標直接導入到模型字段里來，指標名稱直接作為字段名稱，這樣后續應用理解上也非常方便，而且也能夠統一。

上述介紹的是新建模型的場景，如果要修改模型，建議通過代碼建模，代碼模式會支持常用的 MaxCompute DDL、Hive DDL 等。

在代碼模式中，我們也支持根據 select 語句快速生成模型，這個功能非常適用于平時喜歡先分析數據，寫好 ETL 代碼，再去做模型設計的場景。

問題4：如何解決模型設計與數據研發脫節的問題？

大家對直接創建物理表的方式可能會比較熟悉，在 DataWorks 智能數據建模中創建模型再進行物化時，無需再編寫 DDL 語句，可直接將模型發布為物理表，只要在產品上選要發布到哪里、發布到哪個環境等即可。

簡代碼打通了模型設計和數據研發，先做好模型設計后，可以通過模型的數據開發功能，自動生成模型對應的 ETL 代碼，并打通數據開發，將代碼加載到數據開發中。

數據模型設計好之后，一般都是用于給大家去使用的，我們一般會將穩定下來的模型在資產中進行上架操作，這樣模型就可以被大家找到和消費。數據建模的分層劃域可以和資產目錄做好映射，打通之后模型可以自動上架到數據資產以被找到和消費。

四、數據模型應用-數據資產介紹

DataWorks 數據資產 3D 全景圖，旨在展示企業數據資產的全貌，讓數倉同學的工作能夠顯性化體現出來并且能體現出業務價值。

資產概覽是一些比較常規的統計性的信息，資產管理員可以在這里從不同維度來觀察企業數據資產的分布情況，便于做好企業數據資產盤點工作。

資產市場更加適合于業務人員日常去找數據資產及用資產，管理員可以將希望開放給業務人員的數據資產進行上架。

最后講一下模型的應用，模型一旦物化之后，在數據資產上也可以直接去做字段的勾選以及 SQL 分析，完全是零代碼，當然只是單表建模單表分析，結束后就可以直接下載數據。

五、Q & A

問：DataWorks 是否支持拉鏈表？

答：拉鏈的自動生成，現在還沒有對外開放。

問：數據資產是怎么分享的？

答： 我們是由管理員開放所需共享的資產，放在數據資產模塊里。普通業務人員間的資產分享，現在還是通過直接發產品地址的方式。

DataWorks 智能數據建模目前已經在阿里云上商業化，當前推出個人版本，6個月僅需60元，并贈送零售電子商務模板和學習教程供各位開發者使用。

https://www.aliyun.com/product/bigdata/ide。