話聊

建設(shè)數(shù)倉

ETL

工具

面臨的問題

分層

分層的出發(fā)點

分層設(shè)計

模型建設(shè)

為什么要建設(shè)模型

怎么建設(shè)模型

理清工作思路

實施步驟

建模方法及實施

規(guī)范建設(shè)

臨時表管理

代碼規(guī)范

流程規(guī)范

話聊

技術(shù)升級快于我們的想象，今天的故事在明天來看就是一種常識。對于數(shù)倉而言，又何嘗不是？互聯(lián)網(wǎng)的發(fā)展，導(dǎo)致大數(shù)據(jù)的人才缺口。互聯(lián)網(wǎng)公司雨后春筍，傳統(tǒng)行業(yè)機巧轉(zhuǎn)身。短短幾年，數(shù)據(jù)行業(yè)已滄海桑田。今天談大數(shù)據(jù)已不復(fù)當(dāng)年霧里看花的景象，它像一列更高速的快車，和老前輩們一樣，向自己的終點加速。

回到主題，最近負(fù)責(zé)一個數(shù)據(jù)中臺項目的建設(shè)，從0到1的建立數(shù)倉。模型建設(shè)，參考維度模型的方式。通過維度+事實，支持業(yè)務(wù)數(shù)據(jù)需求。走了不少彎路，在這里總結(jié)總結(jié)，更希望和大家交流。

建設(shè)數(shù)倉

什么是數(shù)倉，為什么建設(shè)數(shù)倉，怎么建設(shè)數(shù)倉？(我是誰，我從哪里來，我到哪里去)

Inmon將數(shù)據(jù)倉庫定義為：在企業(yè)管理和決策中面向主題的、集成的、與時間相關(guān)的、不可修改的數(shù)據(jù)集合。數(shù)據(jù)倉庫的目標(biāo)：數(shù)據(jù)資產(chǎn)、決策信息。

系統(tǒng)層面

etl過程：打通你的任督二脈(離線+實時)，讓數(shù)據(jù)在整個環(huán)節(jié)中流通起來

數(shù)據(jù)分層：一套(低耦合、高內(nèi)聚)的層級，是十分重要的?？偛幌霕I(yè)務(wù)、數(shù)據(jù)等一變化，數(shù)倉像又投胎了一次

數(shù)據(jù)集成：多業(yè)務(wù)場景下，打破數(shù)據(jù)信息壁壘，避免數(shù)據(jù)歧義，統(tǒng)一數(shù)據(jù)服務(wù)

規(guī)范化：良好的流程化、規(guī)范化設(shè)計，會帶來易維護、高擴展

監(jiān)控與輔助：質(zhì)量監(jiān)控、調(diào)度管理、元數(shù)據(jù)管理、信息安全管理

走向服務(wù)：對外api服務(wù)/自助查詢平臺/OLAP分析平臺

實時數(shù)倉：有機會再寫

協(xié)作層面

與后端開發(fā)協(xié)同：上游依賴，需要有一個良好的通道，保證信息共享和聯(lián)動響應(yīng)

與分析/業(yè)務(wù)握手：下游服務(wù)，需求方是多個的，即可能是分析，也可能是運營/boss，先理解他們，在讓他們理解你

迭代數(shù)倉：只要業(yè)務(wù)在發(fā)展，數(shù)倉就需要不斷更新；響應(yīng)業(yè)務(wù)變化，豐富數(shù)據(jù)模型

個人角色

責(zé)任：做好數(shù)據(jù)集成，保持?jǐn)?shù)據(jù)準(zhǔn)確，樹立數(shù)倉權(quán)威

工作安排：簡單的事情復(fù)雜化，復(fù)雜的事情簡單化(簡單的事情想著系統(tǒng)化，復(fù)雜的事情想想流程化，標(biāo)準(zhǔn)化)

溝通：魯迅說過，雙贏才是真理。

掌握技能：優(yōu)化查詢、高效存儲、模型理論

ETL

因為數(shù)據(jù)應(yīng)用場景的不同，數(shù)據(jù)存儲方案也有較大差異。內(nèi)部常用的mysql/Mssql/oracle和hive/hbase/MongDB，外部數(shù)據(jù)交互的excel/csv/txt/api等。

要求

業(yè)務(wù)場景覆蓋

業(yè)務(wù)數(shù)據(jù)往往涉及多種數(shù)據(jù)源，數(shù)據(jù)存儲也常常會有多種選擇。文本數(shù)據(jù)、日志數(shù)據(jù)、RMDB、Nosql等。則要求etl工具能夠覆蓋這些業(yè)務(wù)場景。

性能

業(yè)務(wù)特性在數(shù)據(jù)上，往往常有波峰波谷。在波峰是否能夠hold住。比如常見的雙11，618等消費節(jié)日。而且伴隨業(yè)務(wù)腳步的擴展，能否面對后期的數(shù)據(jù)量增長

擴展性

從源端進行數(shù)據(jù)etl工作，當(dāng)數(shù)據(jù)結(jié)構(gòu)變化、數(shù)據(jù)刪除、數(shù)據(jù)源變更、數(shù)據(jù)類型，在這樣的情況下，就需要更好的擴展性，保持與數(shù)據(jù)質(zhì)量監(jiān)控、元數(shù)據(jù)管理的交互。

工具

datax/sqoop/kettle/informatica等等

應(yīng)該要滿足

連續(xù)性的數(shù)據(jù)，不應(yīng)該從某個時間點進行數(shù)據(jù)刪除；不應(yīng)該修改已有的數(shù)據(jù)

ETL一般為最開始的部分，凌晨之后的時間點。a：避免集中式的對某個jdbc海量同步，影響業(yè)務(wù)(部分從庫可能提供查詢服務(wù))、b：明確調(diào)度的時間，應(yīng)盡可能的在某個時間段內(nèi)完成(不能僅依靠調(diào)度，實現(xiàn)任務(wù)流的串行；為后期的大作業(yè)空間，占用等待的系統(tǒng)資源)

應(yīng)記錄數(shù)據(jù)同步過程中，涉及的元數(shù)據(jù)。包括：作業(yè)詳情、開始/結(jié)束時間、消耗資源量、過程狀態(tài)等

面臨的問題

當(dāng)源數(shù)據(jù)結(jié)構(gòu)變化(如mysql的一張表增加字段)，如果低成本的擴展，實現(xiàn)業(yè)務(wù)零感知。應(yīng)該在一開始的設(shè)計時，被考慮到?？赏ㄟ^元數(shù)據(jù)監(jiān)控，自動實現(xiàn)動態(tài)的數(shù)據(jù)擴展。

數(shù)據(jù)加載錯誤(字段類型、數(shù)據(jù)缺失、多表同步、歸檔加載、空值異常)

分層

分層的出發(fā)點

我想用身邊的房子來描述來描述分層設(shè)計。分層從直觀的角度出發(fā)，是一種層次/功能關(guān)系。數(shù)倉中體現(xiàn)為： ods/dw/dm。每一層都干著自己的事情，像房子中的廚房、衛(wèi)生間、客廳。你總不想還在睡眠中，被別人清晨的第一股清流所吵醒。

對于數(shù)倉而言，層一是解決功能界線，廚房只干著做飯炒菜的事情；二是解決問題隔離及快速定位，廚房的煙味不要跑到臥室去；如果有煙味請打開排氣扇。

分層設(shè)計

設(shè)計原則

層級清晰

功能明確

內(nèi)部無依賴

常用分層結(jié)構(gòu)

數(shù)倉-分層

Stage緩沖層

事務(wù)性數(shù)據(jù)，每日增量方式進行數(shù)據(jù)同步。需要注意數(shù)據(jù)同步時的邊界問題，避免臟數(shù)據(jù)。對于非事務(wù)性數(shù)據(jù)，一般通過快照/全量更新。不對外開放數(shù)據(jù)查詢

ODS層

一般場景下，我們認(rèn)為該層數(shù)據(jù)與線上保持一致。實際處理過程中，為了處理時間維度上的數(shù)據(jù)變化，會記錄數(shù)據(jù)的變化軌跡(緩慢變化維)。對于該部分?jǐn)?shù)據(jù)，應(yīng)該有選擇性的實施，避免業(yè)務(wù)處理過程變得復(fù)雜和問題發(fā)生后難以回溯。

DIM/DW層(模型層)

在ods層基礎(chǔ)之上，設(shè)計一個寬表層/模型層，通過維度建模的方式，實現(xiàn)維度數(shù)據(jù)與事實數(shù)據(jù)的分離(星型模型)。此外，豐富寬表以彌補星型模型的未覆蓋之處。以此高覆蓋業(yè)務(wù)場景需求

DA層(應(yīng)用層)

面向不同的應(yīng)用，聚合類的數(shù)據(jù)層。該層對于DIM/DW層的使用，是對模型層的一個檢視維度

面臨的問題

數(shù)據(jù)分層實際解決的是，不同層級之間的邊界，做到井水不犯河水(高內(nèi)聚低耦合)。實際工作中，應(yīng)結(jié)合業(yè)務(wù)處理過程，對涉及的數(shù)據(jù)加工流程，確定相應(yīng)的功能邊界，并遵守和監(jiān)控。雖如此，依然會面臨一些問題。

歷史數(shù)據(jù)重現(xiàn)： 所依賴的數(shù)據(jù)有誤，如DIM依賴的ods層數(shù)據(jù)，有問題。問題數(shù)據(jù)可能是當(dāng)日，也可能是一段時間內(nèi)。DIM歷史數(shù)據(jù)如何更新為正確數(shù)據(jù)

性能問題：對于日志數(shù)據(jù)、大型事務(wù)數(shù)據(jù)，在更新數(shù)據(jù)時存在的性能低下

分層重構(gòu)：在一開始分層設(shè)計中，將某些流程冗余到另一個層級中。前期應(yīng)怎么處理，以及后期如何進行低成本剝離

模型建設(shè)

數(shù)據(jù)倉庫，是一個工程性的建設(shè)，而非獨立的模塊開發(fā)。從大局出發(fā)，看待數(shù)倉建設(shè)，要考慮與源數(shù)據(jù)的交互，質(zhì)量的監(jiān)控，如何對外提供數(shù)據(jù)服務(wù)等。而在這些工作中，模型的建設(shè)可以說是靈魂式的存在。滿足集成性、歷史性、分主題的要求，覆蓋業(yè)務(wù)多場景需求，提供決策性企業(yè)數(shù)據(jù)。

水無定勢，兵無常法。不同的行業(yè)，有不同的需求，不同的模型解決不同的問題。

為什么要建設(shè)模型

進行全面的業(yè)務(wù)梳理，改進業(yè)務(wù)流程。在業(yè)務(wù)模型建設(shè)的階段，能夠幫助我們的企業(yè)或者是管理機關(guān)對本單位的業(yè)務(wù)進行全面的梳理。通過業(yè)務(wù)模型的建設(shè)，我們應(yīng)該能夠全面了解該單位的業(yè)務(wù)架構(gòu)圖和整個業(yè)務(wù)的運行情況，能夠?qū)I(yè)務(wù)按照特定的規(guī)律進行分門別類和程序化，同時，幫助我們進一步的改進業(yè)務(wù)的流程，提高業(yè)務(wù)效率，指導(dǎo)我們的業(yè)務(wù)部門的生產(chǎn)。

建立全方位的數(shù)據(jù)視角，消滅信息孤島和數(shù)據(jù)差異。通過數(shù)據(jù)倉庫的模型建設(shè)，能夠為企業(yè)提供一個整體的數(shù)據(jù)視角，不再是各個部門只是關(guān)注自己的數(shù)據(jù)，而且通過模型的建設(shè)，勾勒出了部門之間內(nèi)在的聯(lián)系，幫助消滅各個部門之間的信息孤島的問題，更為重要的是，通過數(shù)據(jù)模型的建設(shè)，能夠保證整個企業(yè)的數(shù)據(jù)的一致性，各個部門之間數(shù)據(jù)的差異將會得到有效解決。

解決業(yè)務(wù)的變動和數(shù)據(jù)倉庫的靈活性。通過數(shù)據(jù)模型的建設(shè)，能夠很好的分離出底層技術(shù)的實現(xiàn)和上層業(yè)務(wù)的展現(xiàn)。當(dāng)上層業(yè)務(wù)發(fā)生變化時，通過數(shù)據(jù)模型，底層的技術(shù)實現(xiàn)可以非常輕松的完成業(yè)務(wù)的變動，從而達到整個數(shù)據(jù)倉庫系統(tǒng)的靈活性。

幫助數(shù)據(jù)倉庫系統(tǒng)本身的建設(shè)。通過數(shù)據(jù)倉庫的模型建設(shè)，開發(fā)人員和業(yè)務(wù)人員能夠很容易的達成系統(tǒng)建設(shè)范圍的界定，以及長期目標(biāo)的規(guī)劃，從而能夠使整個項目組明確當(dāng)前的任務(wù)，加快整個系統(tǒng)建設(shè)的速度

怎么建設(shè)模型

怎么建設(shè)，可能是大家最關(guān)心的一點。讓我們從另一個角度想想，誰應(yīng)該建設(shè)模型？或者誰應(yīng)該參與到模型的建設(shè)中？

理清工作思路

誰應(yīng)參與模型建設(shè)

一個模型的成功好壞可能有很多層面。但模型不能解決某個或某一些問題，顯然是失敗的。那么，業(yè)務(wù)人員應(yīng)該參與，應(yīng)該他們是需求的出發(fā)者

模型建設(shè)人員要做什么

數(shù)倉人員的工作界定，到底在那里？他們負(fù)責(zé)哪些某塊？是指導(dǎo)業(yè)務(wù)梳理，還是業(yè)務(wù)提出模型需求。企業(yè)的規(guī)模、組織架構(gòu)都會影響到這個選擇。但最終的模型落地，應(yīng)由模型人員確定，并給出對應(yīng)的設(shè)計。

哪些支持

沒有高層的重視，模型建設(shè)就像蓋煙囪

實施步驟

業(yè)務(wù)模型 --> 領(lǐng)域模型 --> 邏輯模型 --> 物理模型

業(yè)務(wù)建模 生成業(yè)務(wù)模型，主要解決業(yè)務(wù)層面的分解和程序化

| 劃分整個單位的業(yè)務(wù)，一般按照業(yè)務(wù)部門的劃分，進行各個部分之間業(yè)務(wù)工作的界定，理清各業(yè)務(wù)部門之間的關(guān)系

| 深入了解各個業(yè)務(wù)部門的內(nèi)具體業(yè)務(wù)流程并將其程序化

| 提出修改和改進業(yè)務(wù)部門工作流程的方法并程序化

| 數(shù)據(jù)建模的范圍界定，整個數(shù)據(jù)倉庫項目的目標(biāo)和階段劃分

領(lǐng)域建模 生成領(lǐng)域模型，主要是對業(yè)務(wù)模型進行抽象處理

| 抽取關(guān)鍵業(yè)務(wù)概念，并將之抽象化

| 將業(yè)務(wù)概念分組，按照業(yè)務(wù)主線聚合類似的分組概念

| 細(xì)化分組概念，理清分組概念內(nèi)的業(yè)務(wù)流程并抽象化

| 理清分組概念之間的關(guān)聯(lián)，形成完整的領(lǐng)域概念模型

邏輯建模 生成邏輯模型，主要是將領(lǐng)域模型的概念實體以及實體之間的關(guān)系進行數(shù)據(jù)庫層次的邏輯化

| 業(yè)務(wù)概念實體化，并考慮其具體的屬性

| 事件實體化，并考慮其屬性內(nèi)容

| 說明實體化，并考慮其屬性內(nèi)容

物理建模 生成物理模型，主要解決，邏輯模型針對不同關(guān)系型數(shù)據(jù)庫的物理化以及性能等一些具體的技術(shù)問題

| 針對特定物理化平臺，做出相應(yīng)的技術(shù)調(diào)整

| 針對模型的性能考慮，對特定平臺作出相應(yīng)的調(diào)整

| 針對管理的需要，結(jié)合特定的平臺，做出相應(yīng)的調(diào)整

| 生成最后的執(zhí)行腳本，并完善

建模方法及實施

建模的方法論，當(dāng)前主流的Immon的范式建模，Kimball的維度建模，還有一個Data Vault(數(shù)據(jù)湖)。不同的建模方式，其實是從不同的角度來看待這個世界。由于實際過程中使用維度建模的方式較多，我們以維度建模來示例模型建設(shè)。

選擇業(yè)務(wù)過程

在確定業(yè)務(wù)過程前，應(yīng)該了解企業(yè)經(jīng)營范圍，對各個業(yè)務(wù)線有較為清楚的了解。面對不同的業(yè)務(wù)過程，應(yīng)該業(yè)務(wù)專家確定業(yè)務(wù)所涉及的過程，如電商，涉及下單、付款、發(fā)貨、退貨等。有一個業(yè)務(wù)主線架構(gòu)。

基于主線結(jié)構(gòu)，選擇一個簡單且重要的業(yè)務(wù)過程。明確核心指標(biāo)(事實)和模型考評標(biāo)準(zhǔn)，為后期檢視定下基調(diào)。

確定粒度

粒度，是一個不能再拆分的細(xì)分。如訂單事實，還可以拆分為訂單下的商品。最細(xì)粒度便于后期擴展，不用考慮因為統(tǒng)計口徑變化時，模型不可用或要進行大改的擔(dān)憂。

確定維度

維度，是描述事實的環(huán)境。是where、when、who、how的回答。而不同的業(yè)務(wù)過程，對于維度的考慮是不同的。訂單事實關(guān)系，如訂單量、訂單金額、商品滲透等。如果是采購過程，更關(guān)系每個商品的采購價、采購量、庫存周轉(zhuǎn)問題了。

確定事實

事實，是對發(fā)生的事務(wù)的度量。如買條褲子35元，買了5斤牛肉等

實際的模型建設(shè)過程中，更多的問題像是在一個迷宮中，不知出路是哪一條。個人的建議，和業(yè)務(wù)專家握手，了解多少業(yè)務(wù)過程，將模型的主線結(jié)構(gòu)劃分清楚。 基于主線結(jié)構(gòu)，選擇最重要的業(yè)務(wù)過程，梳理當(dāng)前業(yè)務(wù)需求中集中的問題和關(guān)切點。以此為出發(fā)點，進行需求擴展。

需求擴展時，應(yīng)從維度表開始，如常見的時間維度、商品維度、自然人維度等。將維度表確認(rèn)后對事實進行豐滿，采用維度建模方式，事實表中僅儲存維度的鍵。

規(guī)范建設(shè)

臨時表管理

數(shù)據(jù)處理過程中，不得不用到臨時表(中間表)，一般認(rèn)為臨時表是沒有儲存意義的，但是又不能立馬刪除，或結(jié)束后刪除(有時候過程有問題，你還得依靠過程表找原因呢！或是你想避免對功能庫的污染，在temp庫中進行數(shù)據(jù)備份)。如果沒有一套生命周期去約束臨時表的話，將不得不面臨臨時表的庫儲存爆炸問題。那么如何處理呢？

約定一套統(tǒng)一的臨時表命名方式

如創(chuàng)建統(tǒng)一的臨時庫(如TEMP)。要求該庫中的數(shù)據(jù)表全部刪除并不影響業(yè)務(wù)。命名規(guī)則根據(jù)數(shù)據(jù)處理過程而定，不同的命名指定的含義不同。

表生命周期

針對不同的表，周期有限。制定統(tǒng)一的表刪除策略

代碼規(guī)范

腳本格式規(guī)范

腳本頭部注釋編寫規(guī)范、注釋規(guī)范、sql規(guī)范google規(guī)范參考

文件/表命名規(guī)范

一個文件中，只應(yīng)該有一張表，其余只能是臨時表；表名稱應(yīng)與文件名稱相同

字段命名規(guī)范

去除多詞同義，和同詞多義問題。尤其是在模型層(一般也叫做一致性維度)

流程規(guī)范

最重要的就是流程了，明確各個步驟需要完成的事項，減少代碼出錯風(fēng)險。

總結(jié)

以上是生活随笔為你收集整理的数仓dw怎么建_从0建设离线数据仓库的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。