數倉學習2

時間 2019-12-01

標籤學習简体版

原文原文鏈接

在spark 任務時，必須注意cache的中間的的複用job，後續unpersist掉算法

1、數據倉庫建模理論sql

1.在數據倉庫領域有兩個派系：Bill Inmon建模方法論和Ralph Kimball建模方法論數據庫

•Bill Inmon被稱爲「數據倉庫之父」編程

•Ralph Kimball被稱爲「商業智能之父緩存

•兩種觀點誕生以來，圍繞「哪一種架構最佳」的爭論一直存在，但一直無法造成統一的結論安全

•供用戶不一樣的場合、針對不一樣的應用場景選擇某方法或者採用混合二者的方法服務器

2.Kimball對數據倉庫的理論與維度設計和建模有關。維度建模將客觀世界分爲：
–度量：主要由業務過程和支持業務的源系統產生的數據，常以數值形式（訂單金額、庫存數量）存在，稱爲事實
–上下文：圍繞着事實的大量文本形式存在的上下文，這些上下文一般被直觀地分割成多個獨立的邏輯塊，維度建模稱之爲維 。維描述了度量的5個W（When、Where、What、Who和Why）信息，好比：什麼時間下單、何種方式下單、買的是什麼、客戶是誰。網絡

3.維度建模的Kimball數據倉庫一般以星形架構來呈現
•因爲星形緊貼業務過程，很是直觀和符合業務人員的視角，所以被普遍和大量使用架構

4,.Kimball對數據倉庫建模理論的第二大貢獻是基於維度的「總線體系架構」。
•總線體系架構和一致性維度一起保證了多個主題的事實表和維度表可以最終集成在一起，提供一致和惟一的口徑給業務人員。
•Kimball維度建模的主題主要以星形架構爲主，主題與主題之間則用一致性維度和企業總線體系架構保證數據倉庫的一致性app

5.離線數據倉庫一般基於維度建模理論來構建，可是除此以外，離線數據倉庫一般還會從邏輯上進行分層，這也是業界最佳實踐。分層主要基於如下考慮：
–隔離性：
•數據是精心準備、規範、乾淨，方便理解和使用
•上游業務系統的變更給下游使用的用戶最小化影響
–性能和可維護性：
•數據加工和處理都在數據團隊，相同的業務邏輯不用重複執行，減小存儲和計算的開銷
•分層能夠將處理邏輯解耦，方便定位問題和修復
–規範性：對於公司和團隊，須要有統一的口徑

6.數據倉庫分層

ODS層：數據倉庫源頭系統的數據表一般會原封不動地存儲一份，這稱爲ODS（OperationDataStore）層，存儲着歷史增量和全量數據。

•DW層（DWD和DWS層）：數據倉庫明細層DWD和數據倉庫彙總層DWS是數據平臺的主要內容。
它們是經過ODS層通過ETL清洗、轉換、加載生成的，基於維度建模理論來構建，經過一致性維度和數據總線來保證各個子主題的維度一致性。
•應用層（ADS）：應用層主要是各個業務方或者部門基於DWD和DWS創建的數據集市（DM），數據集市是相對於數據倉庫來講的。

一般應用層的數據是來源於DW層，原則上是不能訪問ODS層的。對比於DW層，應用層只包含部門或業務方本身關心的明細層和彙總層的數據。

數據倉庫 O u t L i n e 大數據平臺簡介

維度建模技術

數據倉庫構建

數據倉庫大數據平臺 - 簡介一般說的大數據平臺主要包括三部分：

•數據相關的工具、產品和技術： –批量數據採集傳輸sqoop，spark –離線數據處理Hadoop，Hive，Spark –實時流處理Storm，Spark Streaming，Flink

•數據資產： –公司業務自己產生和沉澱的數據 –公司運做產生的數據（如財務、行政） –第三方數據：外界購買、交換或者爬蟲而來的數據

•數據管理：有了工具和數據，須要進行管理才能讓數據價值最大和風險最小 –相關數據管理技術和概念：數據倉庫、數據建模、數據質量、數據規範、數據安全和元數據管理

數據倉庫

離線平臺數據化運營

管理人員和業務人員當前和過去一個季度或者一個月的銷售趨勢如何？哪些商品熱銷？哪些商品銷售很差？哪些客戶購買能力比較強？指標數據獲取能統計對應指標的數據

數據倉庫離線平臺

•離線平臺 Ø對分析需求最擅長，也是最成熟的，使用最普遍的。 Ø開源的解決方案和商業性的解決方案不少 Ø是構建公司和企業數據平臺的根本和基礎 Ø也是目前數據平臺的主戰場

數據倉庫離線數據平臺架構

數據倉庫 H i v e 體系架構

•在大數據出現以前，離線數據平臺就是數據倉庫，數據部門也就是數據倉庫部門

•hadoop出現以前，數據倉庫的主要技術是商業化數據，好比微軟的SQL Server、甲骨文 Oracle、IBM的DB2等 •隨着數據量的爆炸性增加，Hadoop的MapReduce，Spark，Hive等大數據技術被應用到數據倉庫中。

•離線數據平臺另一關鍵技術是數據的建模：維度表事實表 •離線數據內容建設會對精心加工後的數據進行分層： Ø ODS原始數據層 Ø DWD明細數據層 Ø DWS彙總層 Ø ADS集市數據層

數據倉庫數據倉庫技術 - O L T P & O L A P

•OLTP：(online transaction Processing)：

•OLTP數據庫，如商業性的Oracle、MS SQL Server和開源的MySQL等關係數據庫 •主要用於事務處理：增刪改查

•OLTP核心需求：單條記錄的高效快速處理，索引技術、分庫分表

•OLAP：

•OLAP數據庫，專門的分析型數據庫，是爲了知足分析人員的統計分析需求而發展起來的

•OLAP一般只須要處理數據查詢請求，數據都是批量導入的，所以經過列存儲、列壓縮和位圖索引等技術能夠大大加快響應請求速度

數據倉庫 O L T P & O L A P 對比

•需求上不一樣：

•OLTP側重單條數據的處理效率

•OLAP側重數據分析，須要訪問大量的數據，單條數據分析沒有意義 •資源和性能上：

•分析上須要頻繁的統計和查詢，統計須要全表掃描，會大量佔用數據庫的資源，嚴重影響線上的OLTP的性能，因此須要單獨爲分析創建OLAP的分析型的數據庫。

•OLTP的分佈式爲了解決海量單條數據請求壓力，將全部用戶請求均勻分佈到每一個節點上

•OLAP的分佈式爲了將用戶單次對大數據集的請求任務分配到各個節點上獨立計算而後再進行彙總返回（map reduce原理）

數據倉庫 O L T P & O L A P 對比 OLTP和OLAP數據庫簡單對比對比項 OLTP OLAP 用戶操做人員、一線管理人員分析決策人員、高級管理人員功能平常操做分析決策讀寫一般讀寫數條記錄一次讀取大量記錄用戶數面向外部的用戶數上億均可能、面向內部系統用戶數一般有限一般面向內部，幾十個抑或上千個，取決於公司規模大小 DB大小一般不存儲歷史數據，MB、GB 包含歷史數據，GB、TB、PB級別響應時間毫秒級秒、分鐘甚至小時 DB設計面向應用面向主題事務支持必須支持不必，不支持數據 ——八當前應用的，最新的數據歷史的、彙集的、多維、集成、統一的數據 —— 數據倉庫分析型數據庫 •專門分析型數據庫出現標誌着數據倉庫由學術（概念階段）工業階段 •商業性的MPP（分佈式的分析型數據庫）和類MPP架構應運而生： –Orcale Exadata、天睿公司的Teradata、IBM收購的Netezza、EMC公司的Greenplum、惠普的HP Vertica等 –經過一站式解決方案和產品「一體機」運營：數據倉庫軟件+配套硬件設施（服務器、存儲設備、高速網絡交換設備），實現開箱即用。 •OLAP用戶單次請求大量數據的統計分析，OLTP全部用戶單條數據請求： –OLAP須要列式存儲：列存儲的類型是固定的，能夠很容易採用高壓縮比的算法進行壓縮和解壓縮，磁盤I/O會大大減小，列存儲只須要讀取對應的列，不需用讀取整個表的全部字段進行處理 –OLTP行式存儲：把全部字段都存儲在一起

數據倉庫 H a d o o p 數據倉庫 •Hadoop內在技術決定：容易擴展、成本低廉，這兩點是決定流行的關鍵，若是大公司使用MPP，會有想當大的開銷。 •基於Hadoop的數據倉庫的解決方案（Hive）面臨最大的挑戰是數據查詢的延遲

數據倉庫數據倉庫建模技術 •三種搭建數據倉庫的方式： –傳統OLTP數據庫中搭建 –商業性數據倉庫產品中搭建（MPP架構的Teradata） –基於Hadoop來搭建 •無論哪一種方式都會面臨如下問題： –怎麼組織數據倉庫中的數據？ –怎麼組織才能使得數據使用最爲方便和便捷？ –怎麼組織才能使得數據倉庫具備良好的可擴展性和可維護性？

數據倉庫兩種數據倉庫的架構 •在數據倉庫領域有兩個派系：Bill Inmon建模方法論和Ralph Kimball建模方法論 •Bill Inmon被稱爲「數據倉庫之父」 •Ralph Kimball被稱爲「商業智能之父」 •兩種觀點誕生以來，圍繞「哪一種架構最佳」的爭論一直存在，但一直無法造成統一的結論 •供用戶不一樣的場合、針對不一樣的應用場景選擇某方法或者採用混合二者的方法

數據倉庫 R a l p h a K i m b a l l 建模方法論 •Kimball對數據倉庫的理論與維度設計和建模有關。維度建模將客觀世界分爲： –度量：主要由業務過程和支持業務的源系統產生的數據，常以數值形式（訂單金額、庫存數量）存在，稱爲事實 –上下文：圍繞着事實的大量文本形式存在的上下文，這些上下文一般被直觀地分割成多個獨立的邏輯塊，維度建模稱之爲維。維描述了度量的5個W（When、Where、What、Who和Why）信息，好比：什麼時間下單、何種方式下單、買的是什麼、客戶是誰。

數據倉庫星形架構 •維度建模的Kimball數據倉庫一般以星形架構來呈現 •因爲星形緊貼業務過程，非常直觀和符合業務人員的視角，所以被普遍和大量使用

數據倉庫基於維度的「總線體系架構」 •Kimball對數據倉庫建模理論的第二大貢獻是基於維度的「總線體系架構」。 •總線體系架構和一致性維度一起保證了多個主題的事實表和維度表可以最終集成在一起，提供一致和惟一的口徑給業務人員。 •Kimball維度建模的主題主要以星形架構爲主，主題與主題之間則用一致性維度和企業總線體系架構保證數據倉庫的一致性。

數據倉庫倉庫體系架構

數據倉庫 B i l l I n m o n 建模方法論 •Bill Inmon是第一個提出來OLAP和數據倉庫概念的人，因此被稱之爲「數據倉庫之父」 •他認爲：數據倉庫是「在企業管理和決策中面向主題的、集成的、與時間相關的、不可修改的數據集合」 •數據倉庫更像是一種過程，對分佈在企業內部各處的業務數據的整合、加工和分析的過程，而不是一種能夠夠買的產品。稱之爲「企業信息化工廠」

數據倉庫企業級數據倉庫體系架構

數據倉庫企業數據倉庫 •Inmon的企業信息化工程包括源頭系統、準備區、ETL、企業數據倉庫、數據集市等，而企業數據倉庫是企業化信息工廠的樞紐。 •數據集市，所謂「集市」，就是部門級的數據倉庫，Inmon主張從企業數據倉庫中提取所須要的數據，從而保證數據的一致性。 •不一樣點： –不一樣於Kimball，Inmon認爲企業數據倉庫應爲原子數據的集成倉庫，應該用第三範式和ER理論而非維度建模的事實表和維度表來建模。 –Inmon認爲先有企業數據倉庫纔可能開始創建部門級的數據集市。 •Inmon也認爲應該用Kimball的維度建模理論來構建數據集市。

數據倉庫數據倉庫建模實踐 •Inmon的方法是一種由上而下（top-down）的數據倉庫建模方法，主張首先要對企業數據倉庫進行整體規劃，並將不一樣的OLTP數據集中到面向對象主題、集成的、不易失的和時間變化的企業數據倉庫中。數據集市應該是數據倉庫的子集，每一個數據集市都是爲獨立部門專門設計的。 •Kimball方法相反，是一種自下向上的（down-top）。Kimball認爲數據倉庫是一系列數據集市的集合，企業能夠經過一致性的維度表和「企業總線架構」來遞增式集成各個數據集市，從而構建整個企業的數據倉庫。 •對比： –Inmon的方法部署和開發週期較長，可是容易維護並且高度集成。因爲互聯網業務變化快，系統一直變，數據一直變，致使可能永遠設計不出一個企業數據倉庫，因此能夠先創建數據集市，然後根據業務進展再沉澱出企業數據倉庫。 –Kimball的方法能夠迅速響應業務需求，快速構建一個數據倉庫，成效要求快，投資回報快，可是後期集成和維護較爲麻煩。

數據倉庫數據倉庫邏輯架構設計 •離線數據倉庫一般基於維度建模理論來構建，可是除此以外，離線數據倉庫一般還會從邏輯上進行分層，這也是業界最佳實踐。分層主要基於如下考慮： –隔離性： •數據是精心準備、規範、乾淨，方便理解和使用 •上游業務系統的變更給下游使用的用戶最小化影響 –性能和可維護性： •數據加工和處理都在數據團隊，相同的業務邏輯不用重複執行，減小存儲和計算的開銷 •分層能夠將處理邏輯解耦，方便定位問題和修復 –規範性：對於公司和團隊，須要有統一的口徑

數據倉庫數據倉庫分層 •ODS層：數據倉庫源頭系統的數據表一般會原封不動地存儲一份，這稱爲ODS（Operation Data Store）層，存儲着歷史增量和全量數據。 •DW層（DWD和DWS層）：數據倉庫明細層DWD和數據倉庫彙總層DWS是數據平臺的主要內容。它們是經過ODS層通過ETL清洗、轉換、加載生成的，基於維度建模理論來構建，經過一致性維度和數據總線來保證各個子主題的維度一致性。 •應用層（ADS）：應用層主要是各個業務方或者部門基於DWD和DWS創建的數據集市（DM），數據集市是相對於數據倉庫來講的。一般應用層的數據是來源於DW層，原則上是不能訪問ODS層的。對比於DW層，應用層只包含部門或業務方本身關心的明細層和彙總層的數據。

數據倉庫數據分層架構圖

數據倉庫實時數據平臺架構 •離線數據平臺產出數據的週期一般是天，也就是說，今天看到的是昨天的數據，對於大部分的分析和「看」數據場景來講，這種T+1的離線數據能夠知足業務分析需求 •實時數據： –業務場景須要立刻看到業務效果，尤爲是在業務促銷活動（雙十一大促、618大促）等 –算法需求：實時數據訓練的算法效果和離線數據訓練的算法效果有着天壤之別，由於時效性比較好，帶來的算法效果會更好

數據倉庫實時平臺架構

數據倉庫實時數據平臺 •實時數據平臺首先要保證數據來源的實時性。數據來源主要分爲兩類： •數據庫：注意業內最佳實踐並非直接訪問數據庫抽取數據，而是會直接採集數據變動日誌 •日誌文件 •數據採集工具（Flume）採集binlog事件，產生速度和頻率一般取決於源頭系統。和下游的實時數據處理工具（Storm、Spark、Flink等流計算框架和平臺）處理數據的速度一般是不匹配的。 •實時數據處理一般還會從某個歷史時間點重啓以及多個實時任務都要使用同一源頭數據的需求，所以一般還會引入消息中間件（消息隊列好比kafka）來做爲緩衝，從而達到實時數據採集和處理適配

數據倉庫實時數據存儲 •實時數據存儲根據下游數據使用的不一樣方式一般放在不一樣的數據存儲內。 •對於數據在線服務（即數據使用方傳入某業務ID，而後獲取到全部此ID的相關字段），一般放在HBase內 •對於實時數據大屏，一般放在某關係數據庫（如Mysql）內，有時爲了提升性能並減輕對底層數據庫的壓力，還會使用緩存數據庫（Redis）等

數據倉庫數據管理 •對於一個公司和組織來講，僅有數據的技術是不夠的，還必須對數據進行管理。

•數據管理的範疇很廣，可是具體主要包含如下幾個： ‒數據探查

數據倉庫數據探查 •數據探查就是對數據自己和關聯關係等進行分析，包括但不限於： –須要的數據是否有 –都有哪些字段 –字段含義是否規範明確 –字段的分析和質量如何 •數據探查經常使用的分析技術包括： –主外鍵 –字段類型 –字段長度 –null值佔比好比- ，‘’，「」其餘非約定的值都算是空值 –枚舉值分佈 –最小值 –最大值 –平均值

數據倉庫數據探查 •數據探查分爲戰略性和戰術性的。 •戰如略何性：是指使用數據以前首先對數據進行輕量級的數據分析，肯定其是否可用、數據穩定性，以決定是否能夠歸入數據平臺使用。這是構建數據平臺的首要任務，不合格的數據源頭必須儘快剔除。 •戰術性：是指用技術手段對數據進行詳盡的分析，發現儘量多的數據質量問題並反饋給業務人員或者通知源頭系統進行改進。 •數質據探查是構建數據平臺的基礎，好的數據探查工做直接爲後續的數據建模、數據集成和數據量等工做提供了指導，也能讓數據平臺團隊對數據作到心中有數。

數據倉庫數據集成 •數據倉庫的數據集成也叫ETL（抽取：extract、轉換：transform、加載：load ）是數據平臺構建的核心，也是數據平臺構建過程最耗時的過程。

•ETL泛指講數據從數據源抽取、通過清洗、轉換、關聯等轉換，並最終按照預先設計的數據模型將數據加載到數據倉庫的過程。

•ETL處理的結果是爲數據使用者提供一個彙總、規範、包含全部相關訂單信息的寬表。（就是select *就能拿到全部想要的數據）

•ETL過程技術上須要解耦任務，這樣會產生大量的執行job，這些須要經過專門的調度和管理，關鍵是設置checkpoint保證出錯時重跑成本低。 •ETL開源工具：Kettle、Talend，Hive，spark

數據倉庫數據質量

•數據質量問題始終是每一個數據相關人員的核心訴求，尤爲是數據分析師、數據開發工程師、業務分析接口人

•這些人常常面臨的問題：「這個數據準確麼？」

•或者被質疑： –「這個數據有問題」 –「這個數據確定是錯誤的」

數據倉庫數據質量

•數據的準與不許須要從如下4個方面進行衡量： –完整性：是指數據信息是否存在缺失情況，不完整的數據質量會大大下降 •數據記錄缺失

•數據記錄中字段值缺失 –一致性：指數據是否遵循了統一的規範，是否保持統一的格式 •數據記錄的規範：IP地址一定是有4個0~255的數據加上「.」組成

•數據是否合乎邏輯：互聯年齡主要集中在12-60，不多是負數，也不可能大於1000 –準確性：指數據記錄的信息是否存在異常或錯誤，是否符合業務的預期

•與一致性的區別：準確性不僅是規則上的不一致，更多的是業務規則的衝突，好比：業務規定某字段值只有（1,0 ），可是出現了3或者其餘字符串 –及時性：指數據的產生時間是否及時、準時，符合預期。

數據倉庫數據質量

•數據從生產到消費有不少環節，每一個環節均可能出現數據質量問題，可是對於直接使用數據的人來講，數據開發團隊被視爲數據質量問題的第一責任人，數據開發團隊有義務和責任來解決數據質量問題，推進解決問題。

•數據質量問題須要藉助系統和工具才能落地，主要監控： –數據行數波動 –主鍵重複 –字段空值比，空值率 –枚舉值檢查、枚舉值佔比 –字段最小值、最大值、均值、數值合計 •經過這些指標+業務規則監測來衡量是否有數質量問題，若是發現系統報警，須要第一時間解決和修復。

數據倉庫數據屏蔽

•數據倉庫存儲了企業全部的數據，其中有些數據是很是敏感的，好比用戶的信用卡信息、身份證、手機號等，這些信息若是泄露會給企業和公司帶來災難性的後果。但若是直接刪除，會對開發測試和分析統計帶來影響。

•數據屏蔽就是對數據進行脫敏，進行不可逆的處理，既能知足開發測試和統計分析使用

•主要方法：

–替換：用預先準備的測試數據來替換真實的敏感數據

–洗牌（shuffle）：和替換一直，只是替換的數據集是其自己

–刪除/加擾：刪除會破壞數據完整性，能夠經過「*」來替代，150****6789

–加密：經過加密算法，將原始數據變爲無心義字符，只有應用「密鑰」才能查看原始數據

數據倉庫 O u t L i n e 大數據平臺簡介維度建模技術數據倉庫構建

數據倉庫維度建模過程 •維度建模過程順序分爲四個過程：

1. 選取業務過程：針對項目業務活動，不如百度主要業務活動是搜索，維度模型是同部門捆綁在一起的，因此沒法避免數據不一致的狀況，（好比業務編碼、含義），須要從全局考慮。

2. 定義粒度：對事實表實際表明的內容和含義給出明確的說明，粒度傳遞了事實表度量值相聯繫的細節所達到的程度的信息。（好比：訂單信息orders表，更細粒度的priors表每一個訂單具體的商品信息）粒度定義須要最大程度選擇業務過程當中最爲原子性的粒度，這樣能讓後續處理更加靈活

3. 肯定維度：維度是對度量的上下文和環境的描述。（好比用戶的註冊的基本信息，商品的基本屬性信息）

4. 肯定事實：經過業務過程可能要分析什麼來肯定。好比促銷活動，須要度量的是銷售量和銷售金額

數據倉庫維度表設計

•維度表示維度建模的靈魂，在維度表設計中碰到的問題直接關係到維度建模的好壞。

•主要問題：

–維度變化：維度是緩慢變化的過程 –維度層次：某個維度表中的屬性之間存在的從屬關係 –維度一致性：兩個維度若是有關係，要麼相同，要麼是子集。不一致包括表內容和屬性上的不一致。 –維度整合和拆分：同一個維度來自多個業務系統，須要整合和拆分。

–維度其餘

數據倉庫維度變化

•維度表的數據一般來自與業務系統，商品是會發生變化的，好比商品的所屬類目、商品價格、商品描述等。這些變化多是以前錯誤的修正，或者實際商品更新。這個變化稱爲「緩慢變化維」

•肯定源數據變化在維度表中如何表示很是重要，根據變化內容的不一樣，下游分析可能要求用不一樣的辦法來處理。 –商品的描述信息變化：也許業務人員不太敏感，能夠直接覆蓋 –商品所屬類目變化：涉及到這個商品的銷售活動是哪一個類目的 •是所有歸到新類目，仍是所有歸到舊類目？ •變化前歸到就類目，仍是變化後歸到新類目？

數據倉庫維度變化

•緩慢變化維的幾種處理辦法：

–從新維度值：當一個維度值屬性發生變化時，重寫維度值方法直接用新值覆蓋舊值。在不須要保留維度屬性歷史變化的狀況。

–插入新的維度行：不維護維度屬性變化，經過插入新的行來保存和記錄變化的狀況。保存了變化先後的歷史數據，可是沒有變化的數據會有冗餘現象。

–插入新的維度列：下游分析須要用到變化前和變化後的屬性值，有能用變化後的屬性值來分析變化前的全部事實，這時能夠採用插入新的維度列。這樣會致使表結構須要發生變化，或者提早預留。

數據倉庫維度層次

•維度層次指的是某個維度表中屬性之間存在的從屬關係問題。

好比商品的類目多是有層次的（一級類目、二級類目、三級類目等），那麼維度建模如何處理這些層次結構的呢？

•有兩種處理辦法：

–將全部維度層次結構去所有扁平化，冗餘存儲到一個表中，星形架構 –新建類目維度表，並在維度表中維護父子關係，雪花架構

•在維度建表中一般採用星形架構，雖然犧牲了部分的存儲，可是給用戶使用帶來了便捷，也減低了學習使用的成本。

•維度層級結構一般和鑽取練習在一起，所謂鑽取就是對信息的持續深刻挖掘。

•鑽取的實質是增長或者減小維度分爲兩種：

–向下鑽取：從彙總數據深刻到細節數據。好比年度銷售總額增加20%，增長時間維度，分析季度增加率

–向上鑽取：從細節數據歸納到彙總數據。

數據倉庫維度一致性

•維度設計理論中，數據倉庫是在對多個主題、多個業務過程的屢次迭代過程當中逐步創建的，邏輯上劃分迭代過程爲數據集市

–數據集市一般由一張和多張緊密關聯的事實表以及多個維度表組成，一般是部門或者面向某個特定的主題。

–數據倉庫則是企業級的、面向主題的、集成的數據集合

•若是分步創建數據集市的過程當中維度表不一致，那麼數據集市就會變成孤立的集市，不能從邏輯上組合成一個集成的數據倉庫，而一致性就是爲了解決這個問題。

•維度一致性：兩個維度若是有關係，要麼徹底一樣，要麼數據邏輯上是另一個的子集。 –內容不一致：某種交易上缺失了部分商品，那麼對這些缺失商品的交易分析沒法完成。 –維度不一致：好比日期格式、類目和日組合成一個數據信息、 •能夠採用共享同一個維度表或者讓其中一個維度表示另一個維度表的子集的方式保證一致性。

數據倉庫維度整合 & 拆分 •有時候出現同一個維度表來自於多個前臺業務系統的問題，此時會帶來維度整合和拆分問題。好比：移動端交易系統和PC端交易系統的系統架構和底層數據庫、表結構等的不一樣。

•同一個維度的整個須要考慮如下問題： –命名規範：要確保一致和統一 –字段類型：統一整合爲一個字段類型 –字段編碼和含義：編碼及含義要整個爲一致的。

•對於業務系統的不一樣一般有兩種處理辦法： –創建一個基礎的維度表，此基礎維度表包含這些不一樣業務的共有屬性，同時簡歷各自業務的單獨維度表以包含其獨特的業務屬性。 –拆分，即不合並，即各個業務差別獨特性的業務各自創建徹底獨立的兩個維度表，各自管理各自維度表和屬性。（好比1.能夠將pc與app端的建同一張表，pc端特有信息字段app端沒有，app端特有的pc端沒有 2.或者將公共的部分建一個表，特有的信息各自建一個表，進行關聯便可）

•實際操做中，對於業務差別大的業務，耦合在一起並不能帶來很大的便利和好處，所以一般傾向於拆分（即不合並），各自管理各自的維度表。對於業務類似度比較大的業務，則能夠採用第一種辦法。

數據倉庫深入事實表

•事實表示維度建模的核心和基本表。事實表存儲了業務過程的各類度量和事實，而這些度量和事實正是下游數據使用人員關心和分析的對象。

•事實表的三種主要的類型： –事務事實表：記錄業務過程原子粒度的事件，每一個事務一條記錄。 –快照事實表：業務的狀態（當前狀態、歷史狀態），好比商品的庫存，擠壓促銷。

–累計快照事實表：適用於具備工做流或者流水線形式的業務的分析。好比：漏斗分析（瀏覽、點擊、轉化）

數據倉庫事務事實表（用戶購買了那些商品，點擊了多少次等行爲量是多，商品銷售額等）

•事務事實表記錄業務過程的事件，並且是原子粒度的事件。

•數據在事務發生後產生，數據的粒度一般是每一個事務一條記錄。

•一旦事務被提交，事實表數據被插入。 •經過事務事實表存儲單詞業務事件/行爲的細節，以及存儲與事件相關的維度細節，用戶能夠單獨聚合分析業務事件和行爲。

數據倉庫事務事實表

•結合超市零售業務以及維度建模的四個環節來講明事務事實表：

1. 選擇業務過程 •理解POS系統記錄的顧客購買狀況，何時、什麼商品、哪一個收銀臺、銷售了哪些商品等

2. 定義粒度 •用戶購買行爲體如今一張小票，事務事實選擇最原子粒度的事件，因此小票的子項目（商品）是超市零售事務事實表的粒度

3. 肯定維度 •粒度肯定後，銷售日期、銷售商品、銷售收銀臺、收銀員、銷售門店等維度就容易被肯定下來了。細節（促銷行爲）

4. 肯定事實

•肯定哪些事實和度量應該在事實表中出現。本例：商品銷售數量、銷售價格、銷售金額等數據倉庫快照事實表

•在實際業務中，除了關心單次的業務事件和行爲外，不少時候還關心業務的狀態（當前狀態、歷史狀態），好比在商品中對應的是庫存狀況。

•快照事實表，又叫週期快照事實表，指間隔一定的週期對業務的狀態進行一次拍照並記錄下來的事實表。最多見的例子：銷售庫存，帳戶餘額等 •對比事務事實表發生纔會記錄，週期快照則必須捕獲當前每一個實體的狀態。好比：某個商品當天沒有售賣，事務事實表不會有記錄，但週期快照須要對其庫存進行定時記錄。

•週期快照事實表的週期須要和業務方共同肯定，最多見的週期（day、Week、 Month）

數據倉庫快照事實表

•以超市的庫存業務啦介紹週期快照事實表的設計過程：

1. 選擇業務過程 •業務目的爲了更好理解超市庫存狀況，業務過程就是商品庫存狀況。何時、什麼商品、哪一個倉庫的庫存量

2. 定義粒度 •主要指定庫存的週期。週期爲day的記錄計算：100家連鎖店*10000個商品=100w行記錄/day

3. 肯定維度 •週期（天、周、月等）、商品、倉庫

4. 肯定事實 •庫存量、增量度量（庫存價值、庫存成本、週期銷售量、去化天數【基於週期內銷售預計須要庫存天數】）

數據倉庫累計快照事實表

•累計快照事實表很是適用於具備工做流或者流水線形式業務的分析，這些業務通常涉及多個時間點或者有主要的里程碑事件，是從全流程角度對業務狀態的拍照

•以車險舉例：

–主要事件：客戶報案、保險公司立案、客戶提交理賠材料、理賠審批經過和付款。 –目標：分析各個理賠的狀態、步驟間的耗時

1. 選擇業務過程：更好的理解保險公司的車險理賠業務，業務過程是車險理賠

2. 定義粒度：某個客戶的保險理賠申請做爲一個記錄

3. 肯定維度：快照週期、理賠申請人、受理人、審覈人、網點等 4. 肯定事實：索賠金額、審批金額、打款金額、處理時長

數據倉庫業務需求

•以零售業務爲例，涉及到全國連鎖業務形態、收銀臺購物流程、商品供應鏈、商品庫存管理等。這麼大規模的零售，運營設計到什麼？ –整個公司的總體銷售趨勢如何？ –是否應該對某些滯銷商品進行促銷？ –客戶是否流失？ –某些暢銷商品是否應該及時補貨？ –如何選擇自營商品從而利潤最大化？

•數據倉庫平臺是以上問題實現數據化運營的前提和基礎。基於數據倉庫平臺生成的各類銷售報表和庫存報表是公司管理層和各個城市運營人員決策的主要依據。

數據倉庫數據倉庫架構設計

•數據倉庫在實際設計中，一般出於可維護性、性能成本以及使用便捷性考慮，會對數據倉庫中的表進行分層

•ODS層：源頭數據原封不一樣存儲一份，是後面DW層（倉庫層）的源數據，ODS層存儲的是歷史增量或者全量數據

•DW層：

–ODS層通過ETL生成，這一層的數據一定是清洗過的，乾淨的、一致的、規範的、準確的數據。下游用戶直接使用DW層數據，而ODS層原則上不容許下游用戶直接接觸。

–明細層：保存最細粒度的事實表和維度表

orders、pruducts表

–彙總層：設計主要是出於性能以及避免重複計算考慮，如何設計須要根據業務需求以及明細層實際彙總頻率來肯定 –原則上，業務使用頻繁的維度須要對這些數據創建彙總層，彙總的指標能夠和業務需求方共同設計完成。

orders、pruducts等同一業務的多表join起來造成寬表

•應用層：

數據來源於DW層，原則上訪問不了ODS層。各個業務方或者部門能夠創建本身的數據集市（Data Mart），只包含部門或者業務方本身關心的明細層和彙總層的數據。通常由下游用戶本身維護和開發。

數據倉庫數據倉庫規範設計

•對於公司來講，使用數據的用戶成百上千，如何下降你們對於數據使用的溝通成本、如何經過規範你們的行爲來下降使用數據的風險。須要經過規範來實現。

•數據倉庫的規範包括不少方面，主要有： –命名規範 –開發規範 –流程規範 –安全規範 –質量規範

數據倉庫命名規範

•表命名規範：爲了讓數據全部相關方對於表包含的信息有一個共同的認知。好比說屬於哪一層（ODS,DW明細，DW彙總、應用層）？哪一個業務線/部門？哪一個維度（商品、賣家、買家、類目）？哪一個時間跨度（天、月、年、實時）？增量仍是全量？ •數據平臺建設者應該首先規定數據倉庫的分層、業務/部門、常見威懾時間跨度的英文縮寫，並根據這個縮寫來命名。

dw_sale_iterm_20180801

數據倉庫開發規範

•開發規範主要用於規範和約束數據開發人員和使用人員的習慣，以最大限度下降數據使用風險，並同時保證用戶準守最佳實踐。主要包括如下幾個方面： –數據任務的分類和存放（即目錄結構的劃分）：公共代碼如何存放，我的代碼如何存放，項目和產品的代碼如何分類存放，實際項目中須要統籌規劃並保證每人都遵照，方便用戶找到對應項目、產品或者各個層次的代碼（ODS、DWD、DWS、ADS） –代碼的編程規範：好比任務註釋的規範必須包含哪幾部分、代碼對其規範、代碼的開發約定等 –最佳實踐：有些最佳實踐（靈活運用時間分區、timestamp定義到毫秒仍是秒、數據類型定義規範多個）都須要開發規範來約束，以確保最佳實踐得以落地。

數據倉庫流程規範

數據倉庫數據倉庫構建示例

- - 商品維度表

•商品維度表命名dim_fr_item，設計說明：

1. 維度表設計的首要問題是維度表的拆分以及合併問題

–主要存放共有屬性

2. 對於緩慢變化維和微型維度的問題，dim_fr_item經過快照和分區字段來解決。

–dim_fr_item將天天存放一份全量數據快照，存放的生命週期由業務需求肯定

•出於屬性擴展性考慮，dim_fr_item將包含JSON和 KeyValue的大字端，但相應地會增長了使用成本。

數據倉庫銷售事實表

數據倉庫數據平臺架構

- - 數據湖