超干貨 |（實戰經驗）結合公司業務分析離線數倉建設實踐-有解無憂

資料中臺

前言

技術是為業務服務的，業務是為公司創造價值的，離開業務的技術是無意義的

本文章首發于公眾號【五分鐘學大資料】，公眾號內全是大資料干貨，可以關注下

業務介紹

公司屬于金融科技ToC企業，針對不同需求的用戶開發不同的產品，所以公司內部有很多條業務線，但是對于資料部門來說，所有業務線的資料都是資料源，對資料的劃分不只是根據業務進行，而是結合資料的屬性，

早期規劃

之前開發是不同業務線對應不同的資料團隊，每個資料團隊互不干擾，這種模式比較簡單，只針對自己的業務線進行數倉建設及報表開發即可，

但是隨著業務的發展，頻繁迭代及跨部門的垂直業務單元越來越多，業務之間的出現耦合情況，這時再采用這種煙囪式開發就出現了問題：

例如權限問題，公司對資料管理比較嚴格，不同的資料開發組沒有權限共享資料，需要其他業務線的資料權限需要上報審批，比較耽誤時間；

還有重復開發問題，不同業務線會出現相同的報表需求，如果每個業務方都開發各自的報表，太浪費資源，

所以對于資料開發而言，需要對各個業務線的資料進行統一管理，所以就有了資料中臺的出現，

資料中臺

我認為資料中臺是根據每個公司具體的業務需求而搭建的，不同的業務，對中臺的理解有所不同，

公司內部開發的敏捷資料中臺，主要從資料技術和計算能力的復用，到資料資產和資料服務的復用，資料中臺以更大價值帶寬，快準精讓資料直接賦能業務，提供一個統一化的管理，打破資料孤島，追溯資料血緣，實作自助化及高復用度，

如下所示：

資料中臺

以上解釋比較抽象，我們以實際專案開發來看下資料中臺的便利性，

比如我們之前做報表開發流程，首先是要資料采集，不同的資料源通過sqoop等工具采集到大資料平臺，然后進行數倉搭建，最后產出報表資料，放到可視化系統展示，最終把整個流程寫成腳本放到調度平臺進行自動化執行，

而有了資料中臺之后就不需要那么繁瑣，直接進行數倉搭建，產生報表即可，無需將精力過多放在資料源、可視化展示及調度，并且可以直觀的查看資料血緣關系，計算表之間血緣，像下面圖中，表之間的依賴關系很明確：

資料中臺

另一點，資料中臺的異構資料系統可以非常簡單的進行關聯查詢，比如hive的表關聯mysql的表，
可透明屏蔽異構資料系統異構互動方式，輕松實作跨異構資料系統透明混算，

異構資料系統原理是資料中臺提供虛擬表到物理表之間的映射,終端用戶無需關心資料的物理存放位置和底層資料源的特性，可直接操作資料，體驗類似操作一個虛擬資料庫，

資料中臺額外集成可視化展示，提供一站式資料可視化解決方案，支持JDBC資料源和CSV檔案上傳，支持基于資料模型拖拽智能生成可視化組件，大屏展示自適應不同大小螢屏，

調度系統是公司內部自寫集成到資料中臺的，在撰寫完sql陳述句之后可以直接進行調度，

數倉建設

到這才真正到數倉建設，為什么前面我要占那么大篇幅去介紹公司業務及所使用的資料中臺系統，因為下面的數倉建設是根據公司的業務發展及現有的資料中臺進行，數倉的建設離不開公司的業務，

智能數倉規劃

數倉建設核心思想：從設計、開發、部署和使用層面，避免重復建設和指標冗余建設，從而保障資料口徑的規范和統一，最終實作資料資產全鏈路關聯、提供標準資料輸出以及建立統一的資料公共層，
有了核心思想，那怎么開始數倉建設，有句話說數倉建設者即是技術專家，也是大半個業務專家，所以采用的方式就是需求推動資料建設，并且因為資料中臺，所以各業務知識體系比較集中，各業務資料不再分散，加快了數倉建設速度，
數倉建設主要從兩個方面進行，模型和規范，所有業務進行統一化

模型

所有業務采用統一的模型體系，從而降低研發成本，增強指標復用，并且能保證資料口徑的統一

模型分層

結合公司業務，后期新增需求較多，所以分層不宜過多，并且需要清晰明確各層職責，要保證資料層的穩定又要屏蔽對下游影響，所以采用如下分層結構：

資料分層架構

資料流向

遵循模型開發時分層結構，資料從 ods -> dw -> dm ->app 這樣正向流動，可以防止因資料參考不規范而造成資料鏈路混亂及SLA時效難保障等問題，同時保證血緣關系簡潔化，能夠輕易追蹤資料流向，
在開發時應避免以下情況出現：

資料參考鏈路不正確，如 ods -> dm ->app ，出現這種情況說明明細層沒有完全覆寫資料；如 ods -> dw -> app ，說明輕度匯總層主題劃分未覆寫全，減少跨層參考，才能提高中間表的復用度，理想的數倉模型設計應當具備：資料模型可復?，完善且規范，
盡量避免一層的表生成當前層的表，如dw層表生成dw層表，這樣會影響ETL效率，
禁止出現反向依賴，如dw表依賴于dm表，

規范
表命名規范
1. 對于ods、dm、app層表名：型別_主題_表含義，如：dm_xxsh_user
2. 對于dw層表名：型別_主題_維度_表含義，如：dw_xxsh_fact_users（事實表）、dw_xxsh_dim_city（維度表）
欄位命名規范
構建詞根，詞根是維度和指標管理的基礎，劃分為普通詞根與專有詞根
1. 普通詞根：描述事物的最小單元體，如：sex-性別，
2. 專有詞根：具備行業專屬或公司內部規定的描述體，如：xxsh-公司內部對某個產品的稱呼，
腳本命名規范
腳本名稱：腳本型別.腳本功用.[庫名].腳本名稱，如 hive.hive.dm.dm_xxsh_users
腳本型別主要分為以下三類：
1. 常規Hive sql：hive
2. 自定義shell腳本：sh
3. 自定義Python腳本：python
腳本內容規范

#變數的定義要符合python的語法要求
#指定任務負責人
owner = "zhangsan@xxx.com"
#腳本存放目錄/opt/xxx
#腳本名稱 hive.hive.dm.dm_xxsh_users
#source用來標識上游依賴表，一個任務如果有多個上游表，都需要寫進去
#(xxx_name 是需要改動的，其余不需要改)
source = {
        "table_name": {
        "db": "db_name",
        "table": "table_name"
        }
}
#如source，但是每個任務target只有一張表
target = {
        "db_table": {
                "host": "hive",
                "db": "db_name",
                "table": "table_name"
        }
}
#變數串列
#$now
#$now.date 常用，格式示例：2020-12-11

 
task = '''
寫sql代碼
'''

資料層具體實作

使用四張圖說明每層的具體實作

資料源層ODS

資料源層

資料源層主要將各個業務資料匯入到大資料平臺，作為業務資料的快照存盤，

資料明細層DW

資料明細層

事實表中的每行對應一個度量，每行中的資料是一個特定級別的細節資料，稱為粒度，維度建模的核心原則之一是同一事實表中的所有度量必須具有相同的粒度，這樣能確保不會出現重復計算度量的問題，

維度表一般都是單一主鍵，少數是聯合主鍵，注意維度表不要出現重復資料，否則和事實表關聯會出現資料發散問題，

有時候往往不能確定該列資料是事實屬性還是維度屬性，記住最實用的事實就是數值型別和可加類事實，所以可以通過分析該列是否是一種包含多個值并作為計算的參與者的度量，這種情況下該列往往是事實；如果該列是對具體值的描述，是一個文本或常量，某一約束和行標識的參與者，此時該屬性往往是維度屬性，但是還是要結合業務進行最終判斷是維度還是事實，