話聊

建設數倉

ETL

工具

面臨的問題

分層

分層的出發點

分層設計

模型建設

為什么要建設模型

怎么建設模型

理清工作思路

實施步驟

建模方法及實施

規范建設

臨時表管理

代碼規范

流程規范

話聊

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

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

建設數倉

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

Inmon將數據倉庫定義為：在企業管理和決策中面向主題的、集成的、與時間相關的、不可修改的數據集合。數據倉庫的目標：數據資產、決策信息。

系統層面

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

數據分層：一套(低耦合、高內聚)的層級，是十分重要的。總不想業務、數據等一變化，數倉像又投胎了一次

數據集成：多業務場景下，打破數據信息壁壘，避免數據歧義，統一數據服務

規范化：良好的流程化、規范化設計，會帶來易維護、高擴展

監控與輔助：質量監控、調度管理、元數據管理、信息安全管理

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

實時數倉：有機會再寫

協作層面

與后端開發協同：上游依賴，需要有一個良好的通道，保證信息共享和聯動響應

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

迭代數倉：只要業務在發展，數倉就需要不斷更新；響應業務變化，豐富數據模型

個人角色

責任：做好數據集成，保持數據準確，樹立數倉權威

工作安排：簡單的事情復雜化，復雜的事情簡單化(簡單的事情想著系統化，復雜的事情想想流程化，標準化)

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

掌握技能：優化查詢、高效存儲、模型理論

ETL

因為數據應用場景的不同，數據存儲方案也有較大差異。內部常用的mysql/Mssql/oracle和hive/hbase/MongDB，外部數據交互的excel/csv/txt/api等。

要求

業務場景覆蓋

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

性能

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

擴展性

從源端進行數據etl工作，當數據結構變化、數據刪除、數據源變更、數據類型，在這樣的情況下，就需要更好的擴展性，保持與數據質量監控、元數據管理的交互。

工具

datax/sqoop/kettle/informatica等等

應該要滿足

連續性的數據，不應該從某個時間點進行數據刪除；不應該修改已有的數據

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

應記錄數據同步過程中，涉及的元數據。包括：作業詳情、開始/結束時間、消耗資源量、過程狀態等

面臨的問題

當源數據結構變化(如mysql的一張表增加字段)，如果低成本的擴展，實現業務零感知。應該在一開始的設計時，被考慮到。可通過元數據監控，自動實現動態的數據擴展。

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

分層

分層的出發點

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

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

分層設計

設計原則

層級清晰

功能明確

內部無依賴

常用分層結構

數倉-分層

Stage緩沖層

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

ODS層

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

DIM/DW層(模型層)

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

DA層(應用層)

面向不同的應用，聚合類的數據層。該層對于DIM/DW層的使用，是對模型層的一個檢視維度

面臨的問題

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

歷史數據重現： 所依賴的數據有誤，如DIM依賴的ods層數據，有問題。問題數據可能是當日，也可能是一段時間內。DIM歷史數據如何更新為正確數據

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

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

模型建設

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

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

為什么要建設模型

進行全面的業務梳理，改進業務流程。在業務模型建設的階段，能夠幫助我們的企業或者是管理機關對本單位的業務進行全面的梳理。通過業務模型的建設，我們應該能夠全面了解該單位的業務架構圖和整個業務的運行情況，能夠將業務按照特定的規律進行分門別類和程序化，同時，幫助我們進一步的改進業務的流程，提高業務效率，指導我們的業務部門的生產。

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

解決業務的變動和數據倉庫的靈活性。通過數據模型的建設，能夠很好的分離出底層技術的實現和上層業務的展現。當上層業務發生變化時，通過數據模型，底層的技術實現可以非常輕松的完成業務的變動，從而達到整個數據倉庫系統的靈活性。

幫助數據倉庫系統本身的建設。通過數據倉庫的模型建設，開發人員和業務人員能夠很容易的達成系統建設范圍的界定，以及長期目標的規劃，從而能夠使整個項目組明確當前的任務，加快整個系統建設的速度

怎么建設模型

怎么建設，可能是大家最關心的一點。讓我們從另一個角度想想，誰應該建設模型？或者誰應該參與到模型的建設中？

理清工作思路

誰應參與模型建設

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

模型建設人員要做什么

數倉人員的工作界定，到底在那里？他們負責哪些某塊？是指導業務梳理，還是業務提出模型需求。企業的規模、組織架構都會影響到這個選擇。但最終的模型落地，應由模型人員確定，并給出對應的設計。

哪些支持

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

實施步驟

業務模型 --> 領域模型 --> 邏輯模型 --> 物理模型

業務建模 生成業務模型，主要解決業務層面的分解和程序化

| 劃分整個單位的業務，一般按照業務部門的劃分，進行各個部分之間業務工作的界定，理清各業務部門之間的關系

| 深入了解各個業務部門的內具體業務流程并將其程序化

| 提出修改和改進業務部門工作流程的方法并程序化

| 數據建模的范圍界定，整個數據倉庫項目的目標和階段劃分

領域建模 生成領域模型，主要是對業務模型進行抽象處理

| 抽取關鍵業務概念，并將之抽象化

| 將業務概念分組，按照業務主線聚合類似的分組概念

| 細化分組概念，理清分組概念內的業務流程并抽象化

| 理清分組概念之間的關聯，形成完整的領域概念模型

邏輯建模 生成邏輯模型，主要是將領域模型的概念實體以及實體之間的關系進行數據庫層次的邏輯化

| 業務概念實體化，并考慮其具體的屬性

| 事件實體化，并考慮其屬性內容

| 說明實體化，并考慮其屬性內容

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

| 針對特定物理化平臺，做出相應的技術調整

| 針對模型的性能考慮，對特定平臺作出相應的調整

| 針對管理的需要，結合特定的平臺，做出相應的調整

| 生成最后的執行腳本，并完善

建模方法及實施

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

選擇業務過程

在確定業務過程前，應該了解企業經營范圍，對各個業務線有較為清楚的了解。面對不同的業務過程，應該業務專家確定業務所涉及的過程，如電商，涉及下單、付款、發貨、退貨等。有一個業務主線架構。

基于主線結構，選擇一個簡單且重要的業務過程。明確核心指標(事實)和模型考評標準，為后期檢視定下基調。

確定粒度

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

確定維度

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

確定事實

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

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

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

規范建設

臨時表管理

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

約定一套統一的臨時表命名方式

如創建統一的臨時庫(如TEMP)。要求該庫中的數據表全部刪除并不影響業務。命名規則根據數據處理過程而定，不同的命名指定的含義不同。

表生命周期

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

代碼規范

腳本格式規范

腳本頭部注釋編寫規范、注釋規范、sql規范google規范參考

文件/表命名規范

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

字段命名規范

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

流程規范

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。