從0建設離線數據倉庫

話聊
建設數倉

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規範參考

文件/表命名規範
一個文件中，只應該有一張表，其他只能是臨時表；表名稱應與文件名稱相同

字段命名規範
去除多詞同義，和同詞多義問題。尤爲是在模型層(通常也叫作一致性維度)

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