耗时n年，38页《数据仓库知识体系.pdf》（数据岗位必备）
文末下載PDF
文章很長，前言一定要看
擁有本篇文章，意味著你擁有一本完善的書籍，本篇文章整理了數據倉庫領域，幾乎所有的知識點，文章內容主要來源于以下幾個方面：
本篇文章尤其適合初級程序員準備面試，以及作為工作中的指導手冊，對資深程序員來說也可夯實基礎。
當然，技術學習僅僅依靠一篇文章還是不夠的，可加入公眾號和技術交流群（聯系方式見文末），群里有很多數據倉庫領域資深大佬，大家經常在群里討論技術熱點問題、互相解決工作難題、安排內推、甚至有部門leader直接發出崗位邀請。「西紅柿🍅」也會持續更新優質文章，也歡迎熱愛學習總結的小伙伴有償投稿，共同推動中國信息技術行業發展，讓我們一起加油吧！
目錄
一、數據倉庫的8個發展階段
1、概念階段（1978-1988）
2、萌芽階段
3、集成階段
4、確立階段（1991）
5、數據集市（1994－1996）
6、爭吵與混亂（1996-1997）
7、合并（1998－2001）
8、未來
二、四種常見數據模型
1、為什么要進行數據倉庫建模
2、四種常見模型
2.1 維度模型
2.2 范式模型
2.3 Data Vault模型
2.4 Anchor模型
3、數據模型的評價標準
三、三種事實表
1、三種事實表概述
1.1 事務事實表
1.2 周期快照事實表
1.3 累積快照事實
2、三種事實表對比
3、事實表設計 8 大原則
4、事實表設計方法
第一步：選擇業務過程及確定事實表類型
第二步：聲明粒度
第三步：確定維度
第四步：確定事實
四、多維體系結構
1、總線架構
2、一致性維度?
3、一致性事實
五、數據倉庫規范設計
1、為什么要進行規范設計
2、設計規范 - 指標
3、命名規范 - 表命名
3.1 常規表
3.2 中間表
3.3 臨時表
3.4 維度表
4、開發規范
5、流程規范
六、元數據管理
1、業務元數據
2、技術元數據
數據源元數據
ETL?元數據
數據倉庫元數據
BI?元數據
3、管理元數據
4、小編有話
七、維度表
1、什么是維度表
2、維度表設計原則
緩慢變化維
3、維度表設計方法
八、三范式與反范式
1、第一范式
2、第二范式
3、第三范式
4、反范式化
5、范式化設計和反范式化設計的優缺點
5.1 范式化 （時間換空間）
5.2 反范式化（空間換時間）
6、OLAP和OLTP中范式設計
九、數據倉庫架構-Lambda和Kappa
1、Lambda架構原理
2、Lambda架構的缺點
3、Kappa架構原理
4、Lambda架構和Kappa架構優缺點對比
5、數據架構評價標準
6、小編有話
十、數據治理（目的、方法、流程）
1、什么是數據治理
2、數據治理的目的
3、數據治理的方法
4、數據質量8個衡量標準
5、數據治理流程
十一、ETL
1、什么是ETL
2、ETL &?ELT
3、常用的ETL工具
3.1 sqoop
3.2 DataX
3.3?Kettle
3.4?canal
3.5 StreamSets
4、ETL加載策略
4.1 增量
4.2 全量
4.3 流式
5、小編有話
十二、數據應用-OLAP
1、olap和oltp的區別
2、OLAP分類
3、OLAP基本操作
4、OLAP選型
4.1 druid
4.2?kylin
十三、數據傾斜
1、數據傾斜表現
2、數據傾斜產生原因
3、解決數據傾斜思路
?
一、數據倉庫的8個發展階段
1、概念階段（1978-1988）
數據倉庫最早的概念可以追溯到20世紀70年代MIT的一項研究，該研究致力于開發一種優化的技術架構并提出這些架構的指導性意見。
第一次，MIT的研究員將業務系統和分析系統分開，將業務處理和分析處理分成不同的層次，并采用單獨的數據存儲和完全不同的設計準則。同時，MIT的研究成果與80年代提出的信息中心（InformationCenter）相吻合：即把那些新出現的、不可以預測的、但是大量存在的分析型的負載從業務處理系統中剝離出來。
但是限于當時的信息處理和數據存儲能力，該研究只是確立了一個論點：這兩種信息處理的方式差別如此之大，以至于它們只能采用完全不同的架構和設計方法。
2、萌芽階段
在80年代中后期,作為當時技術最先進的公司,DEC已經開始采用分布式網絡架構來支持其業務應用，并且DEC公司首先將業務系統移植到其自身的RDBMS產品：RdB。并且，DEC公司從工程部、銷售部、財務部以及信息技術部抽調了不同的人員組建了新的小組，不僅研究新的分析系統架構，并要求將其應用到其全球的財務系統中。該小組結合MIT的研究結論，建立了TA2（TechnicalArchitecture2）規范，該規范定義了分析系統的四個組成部分：
- 數據獲取
- 數據訪問
- 目錄
- 用戶服務
其中的數據獲取和數據訪問目前大家都很清楚，而目錄服務是用于幫助用戶在網絡中找到他們想要的信息，類似于業務元數據管理；用戶服務用以支持對數據的直接交互，包含了其他服務的所有人機交互界面，這是系統架構的一個非常大的轉變，第一次將交互界面作為單獨的組件提出來。
3、集成階段
全企業集成（EnterpriseIntergration，1988）同時，IBM也在處理信息管理不同方面的問題，其最煩人的問題是不斷增加的信息孤島，IBM的很多客戶要面對很多分立系統的數據集成問題，而這些系統有不同的編碼方式和數據格式。
1988年，為解決全企業集成問題，IBM愛爾蘭公司的BarryDevlin和PaulMurphy第一次提出了“信息倉庫（InformationWarehouse）”的概念，將其定義為：“一個結構化的環境，能支持最終用戶管理其全部的業務，并支持信息技術部門保證數據質量”，并在1991年在DECTA2的基礎上把信息倉庫的概念包含進去，并稱之為VITAL規范，將PC、圖形化界面、面向對象的組件以及局域網都包含在VITAL里，并定義了85種信息倉庫的組件，包括數據抽取、轉換、有效性驗證、加載、Cube開發和圖形化查詢工具等。但是IBM只是將這種領先的概念用于市場宣傳，而沒有付諸實際的架構設計。這是IBM有一個領域上創新后停止不前導致喪失其領先地位。因此，在90年代初期，數據倉庫的基本原理、框架架構，以及分析系統的主要原則都已經確定，主要的技術，包括關系型數據存取、網絡、C/S架構和圖形化界面均已具備，只欠東風了。
同時，在1988年－1991年，一些前沿的公司已經開始建立數據倉庫。
4、確立階段（1991）
企業級數據倉庫（EDW，1991）1991年，BillInmon出版了其有關數據倉庫的第一本書，這本書不僅僅說明為什么要建數據倉庫、數據倉庫能給你帶來什么，更重要的是，Inmon第一次提供了如何建設數據倉庫的指導性意見，該書定義了數據倉庫非常具體的原則，包括：數據倉庫是面向主題的（Subject-Oriented）、集成的（Integrated）、包含歷史的（Time-variant）、相對穩定的（Nonvolatile）、面向決策支持的（DecisionSupport）面向全企業的（EnterpriseScope）最明細的數據存（AtomicDetail）數據快照式的數據獲取（SnapShotCapture）這些原則到現在仍然是指導數據倉庫建設的最基本原則，雖然中間的一些原則引發一些爭論，并導致一些分歧和數據倉庫變體的產生。
BillInmon憑借其這本書奠定了其在數據倉庫建設的位置，被稱之為“數據倉庫之父”。
5、數據集市（1994－1996）
數據倉庫發展的第一明顯分歧是數據集市概念的產生。由于企業級數據倉庫的設計、實施很困難，使得最早吃數據倉庫螃蟹的公司遭到大面積的失敗，因此數據倉庫的建設者和分析師開始考慮只建設企業級數據倉庫的一部分，然后再逐步添加，但是這有背于BillInmon的原則：各個實施部分的數據抽取、清洗、轉換和加載是獨立，導致了數據的混亂與不一致性。而且部分實施的項目也有很多失敗，除了常見的業務需求定義不清、項目執行不力之外，很重要的原因是因為其數據模型設計，在企業級數據倉庫中，Inmon推薦采用3范式進行數據建模，但是不排除其他的方法，但是Inmon的追隨者固守OLTP系統的3范式設計，從而無法支持DSS系統的性能和數據易訪問性的要求。
這時，Ralph Kimball出現了，他的第一本書“TheDataWarehouseToolkit”掀起了數據集市的狂潮，這本書提供了如何為分析進行數據模型優化詳細指導意見，從DimensionalModeling大行其道，也為傳統的關系型數據模型和多維OLAP之間建立了很好的橋梁。從此，數據集市在很多地方冒了出來，并獲得很大成功，而企業級數據倉庫已逐漸被人所淡忘。
6、爭吵與混亂（1996-1997）
企業級數據倉庫還是部門級數據集市？關系型還是多維？BillInmon和RalphKimball一開始就爭論不休，其各自的追隨者也唇舌相向，形成相對立的兩派：Inmon派和Kimball派（有點象少林和武當，呵呵）。
在初期，數據集市的快速實施和較高的成功率讓Kimball派占了上風，但是很快，他們也發現自己陷入了某種困境：企業中存在6－7個不同的數據集市，分別有不同的ETL，相互之間的數據也不完全一致。同時，各個項目實施中也任意侵犯了Inmon開始定下的準則：把數據集市當成眾多OLTP系統之后的有一個系統，而不是一個基礎性的集成性的東西，為保證數據的準確性和實時性，有的甚至可以由OLTP系統直接修改數據集市里面的數據，為了保證系統的性能，有的數據集市刪除了歷史數據。等等，不一而足。
當然，這導致了一些新的應用的出現，例如ODS，但是人們對DataWarehouse、DataMart、ODS的概念非常的模糊，經常混為一談。有人說OLAP就是數據倉庫，也有人說我要ODS和DataMart，不要Datawarehouse，也有人說，我DataMart建多了，自然就有DataWarehouse了。但是BillInmon一直很旗幟鮮明：“你可以打到幾萬噸的小魚小蝦，但是這些小魚小蝦加起來不是大鯨魚”。
7、合并（1998－2001）
經過多翻爭吵，證明one-size-fits-all是不可能的，你需要不同的BI架構來滿足不同的業務需求。BillInmon也推出了新的BI架構CIF（Corporationinformationfactory），把Kimball的數據集市也包容進來了，第一次，Kimball承認了Inmon，但是仍然還有很多人在爭論是自頂向下，還是自底向上。
8、未來
未來幾個方向：時效性方向的實時數倉；數據質量方向的數據治理；數據中臺、數據湖（歡迎留言討論！）
推薦閱讀：
數據庫、數據倉庫、數據平臺、數據中臺、數據湖到底是什么？
二、四種常見數據模型
大數據時代，維度建模已成為各大廠的主流方式。
維度建模從分析決策的需求出發構建模型，為分析需求服務。重點關注用戶如何快速的完成數據分析，可以直觀的反應業務模型中的業務問題，需要大量的數據預處理、數據冗余，有較好的大規模復雜查詢的響應性能。
1、為什么要進行數據倉庫建模
- 性能：良好的模型能幫我們快速查詢需要的數據，減少數據的IO吞吐
- 成本：減少數據冗余、計算結果復用、從而降低存儲和計算成本
- 效率：改善用戶使用數據的體驗，提高使用數據的效率
- 改善統計口徑的不一致性，減少數據計算錯誤的可能性
2、四種常見模型
2.1 維度模型
維度建模按數據組織類型劃分可分為星型模型、雪花模型、星座模型。Kimball老爺爺維度建模四部曲：
選擇業務處理過程 > 定義粒度 > 選擇維度 > 確定事實
2.1.1 星型模型
星型模型主要是維表和事實表，以事實表為中心，所有維度直接關聯在事實表上，呈星型分布。
2.1.2 雪花模型
雪花模型，在星型模型的基礎上，維度表上又關聯了其他維度表。這種模型維護成本高，性能方面也較差，所以一般不建議使用。尤其是基于hadoop體系構建數倉，減少join就是減少shuffle，性能差距會很大。
星型模型可以理解為，一個事實表關聯多個維度表，雪花模型可以理解為一個事實表關聯多個維度表，維度表再關聯維度表。
2.1.3?星座模型
星座模型，是對星型模型的擴展延伸，多張事實表共享維度表。
星座模型是很多數據倉庫的常態，因為很多數據倉庫都是多個事實表的。所以星座模型只反映是否有多個事實表，他們之間是否共享一些維度表。
2.2 范式模型
即實體關系（ER）模型，數據倉庫之父Immon提出的，從全企業的高度設計一個3NF模型，用實體加關系描述的數據模型描述企業業務架構，在范式理論上符合3NF。此建模方法，對建模人員的能力要求非常高。
特點：設計思路自上而下，適合上游基礎數據存儲，同一份數據只存儲一份，沒有數據冗余，方便解耦，易維護，缺點是開發周期一般比較長，維護成本高。
詳見后文：三范式與反范式
2.3 Data Vault模型
DataVault由Hub（關鍵核心業務實體）、Link（關系）、Satellite（實體屬性） 三部分組成 ，是Dan Linstedt發起創建的一種模型方法論，它是在ER關系模型上的衍生，同時設計的出發點也是為了實現數據的整合，并非為數據決策分析直接使用。
2.4 Anchor模型
高度可擴展的模型，所有的擴展只是添加而不是修改，因此它將模型規范到6NF，基本變成了K-V結構模型。企業很少使用。
信息技術智庫關注領取技術資料、面試真題、簡歷模板和PPT模板；一起交流工作難題、面試套路、職場經驗、內推直通車公眾號
3、數據模型的評價標準
數據模型建設的怎么樣，極度依賴規范設計，如果代碼風格是“千人千面”，那么恐怕半年下來，業務系統就沒法看了。沒有什么比“數據系統”更看重“法制”了，規范體系不僅能保障數據建設的一致性，也能夠應對業務交接的情況，更能夠為自動化奠定基礎。
小編有話
- 在傳統企業數倉中，業務相對穩定，以范式建模為主。如電信、金融行業等
- 在互聯網公司，業務變化快，需求來來回回的改，計算和存儲也不是問題，我們更關心快速便捷的滿足業務需求，所以以維度建模為主。
?
三、三種事實表
事實表作為數據倉庫維度建模的核心，緊緊圍繞著業務過程來設 計，通過獲取描述業務過程的度量來表達業務過程，包含了引用的維度 和與業務過程有關的度量。
1、三種事實表概述
事實表有三種類型 :?事務事實表、周期快照事實表和累積快照事實表。
-
1.1 事務事實表
也稱原子事實表，描述業務過程，跟蹤控件或時間上某點的度量事件，保存的是最原子的數據；
個人理解：類似于mysql binlog日志，每一次相關的 change 都記錄下來，生成一行新的數據
-
1.2 周期快照事實表
以一個周期為時間間隔，來記錄事實，一般周期可以是每天、每周、每月、每年等；
個人理解：只看某個業務過程，比如訂單收貨，數據按訂單收貨時間來切分，周期可以為每天、每月等。
-
1.3 累積快照事實
用來描述過程開始和結束之間的關鍵步驟事件，覆蓋過程的整個生命周期，通常具有多個日期字段來記錄關鍵時間點；當過程隨著生命周期不斷變化時，記錄也會隨著過程的變化而被修改；
個人理解：要看整個生命周期的多個業務過程，比如：創建訂單 → 買家付款 → 賣家發貨 → 買家確認收貨。粒度是一個訂單一行數據，創建訂單時間，付款時間，發貨時間，收貨時間，分別作為一個字段，便于計算不同業務過程的時間間隔。
2、三種事實表對比
| 事務事實表? | 周期快照事實表? | 累積快照事實表? | |
| 時期/時間? | 離散事務時間點? | 以有規律的、可預測的? | 用于時間跨度不確定的不斷變化的工作流? |
| 日期維度? | 事務日期? | 快照日期? | 相關業務過程涉及的多個日期? |
| 粒度 | 每行代表實體的一個事務? | 每行代表某時間周期的一個實體? | 每行代表一個實體的生命周期? |
| 事實? | 事務事實 | 累積事實 | 相關業務過程事實和時間間隔事實? |
| 事實表加載? | 插入? | 插入? | 插入與更新? |
| 事實表更新? | 不更新? | 不更新? | 業務過程變更時更新? |
3、事實表設計 8 大原則
- 原則 1：盡可能包含所有與業務過程相關的事實
- 分析哪些事實與業務過程相關，是設計過程中非常重要的關注點；
- 在事實表中，盡量包含所有與業務過程相關的事實，即使存在冗余，由于事實通常是數字型，存儲開銷不會太大；
- 原則 2：只選擇與業務過程相關的事實
- 如，訂單的下單這個業務過程，事實表中不應該存在支付金額這個表示支付業務過程的事實；
- 原則 3：分解不可加性事實為可加的組件
- 如，訂單的優惠率，應分解為訂單原價金額與訂單優惠金額兩個事實存儲在事實表中；
- 原則 4：在選擇維度和事實之前必須先聲明粒度
- 因為原子粒度提供了最大限度的靈活性，可以支持無法預期的各種細節層次的用戶需求；
- 粒度用于確定事實表中一行所表示業務的細節層次，決定了維度模型的擴展性；
- 每個維度和事實必須與所定義的粒度保持一致；
- 設計事實表時，粒度定義越細越好，一般從最低級別的原子粒度開始；
- 原則 5：在同一個事實表中不能有多種不同粒度的事實
- 粒度為票一級；（實際業務中，一個訂單可以同時支付多張票）
- 票支付金額和票折扣金額，兩個事實的粒度為 “票級”，與定義的粒度一致；
- 訂單支付金額和訂單票數，兩個事實的粒度為 “訂單級”，屬于上一層訂單級數據，與 “票級” 事實表的粒度不一致，且不能進行匯總；
- 如果，以訂單金額和訂單票數這兩個維度匯總總金額和總票數，會造成大量的重復計算；
- 疑問：怎么判斷不同事實的粒度是否相同？
- 原則 6：事實的單位要保持一致
- 如，訂單金額、訂單優惠金額、訂單運費這 3 個事實，應該采用統一的計量單位，統一為元或者分，以方便使用；
- 原則 7：對事實的 null 值要處理
- 原因：在數據庫中，null 值對常用數字型字段的 SQL 過濾條件都不生效；如，大于、小于、等于、大于或等于、小于或等于；
- 處理：用 0 代替 null ；
- 原則 8：使用退化維度提高事實表的易用性
- 易用性：對事實表，更較少關聯操作、過濾查詢、控制聚合層次、排序數據、定義主從關系等；
- 在 Kimball 的維度建模中，通常按照星形模型的方式設計，通過事實表的外鍵關聯專門的維表，這種方式來獲取維度，謹慎使用退化維表；這與大數據領域的事實表設計不一樣；
- 思路：通過增加冗余存儲，減少計算開銷，提高使用效率；
4、事實表設計方法
Kimball 的維度模型設計 4 步法：選擇業務過程、聲明粒度、確定維度、確定事實；
當前的互聯網大數據環境，維度模型的設計，是基于 Kimball 的四步維度建模方法進行了更進一步的改進：
-
第一步：選擇業務過程及確定事實表類型
- 如淘寶的一個交易訂單，選擇 “買家付款” 這個業務過程，則事實表類型應為只包含買家付款這一個業務過程的 “單事務事實表”；
- 如選擇了所有 4 個業務過程，并且需要分享各業務過程的時間間隔，則事實表類型應為包含了所有 4 個業務過程的 “累積快照事實表”；
- 如是選擇 “買家付款” 這個業務過程，還是選擇 “創建訂單” 和 “買家付款” 這兩個業務過程，具體根據業務情況來定；
- 思路：詳細分析需求，對業務的整個生命周期進行分析，明確關鍵的業務步驟，從而選擇與需求有關的業務過程；
- 以實例說明：如何選擇業務過程？如何確定事實表類型？
-
第二步：聲明粒度
- 粒度的作用：
- 粒度的選擇：盡量選擇最細級別的原子粒度，以確保事實表的應用具有最大的靈活性；
-
第三步：確定維度
- 如，淘寶訂單 “付款事務事實表” 中，粒度為 “子訂單”，相關的維度有買家、賣家、商品、收貨人信息、業務類型、訂單時間等；
- 完成了粒度聲明，就意味著確定了主鍵，對應的維度組合以及相關的維度字段也可以確定了；
- 選擇維度的原則：應該選擇能夠描述清楚業務過程所處的環境的維度信息；
-
第四步：確定事實
- 確定原則：選擇與業務過程有關的所有事實，且事實的粒度要與所聲明的事實表的粒度一致；
- 思路：可以通過回答 “過程的度量是什么” 來確定；
- 注意：將不可加性事實分解為可加的組件；（分解的原則：可以通過分解后的可加的屬性值，計算得到不可加性事實）
四、多維體系結構
在Kimball的維度建模的數據倉庫中，關于多維體系結構（MD）有三個關鍵性概念：總線架構（Bus Architecture），一致性維度（Conformed Dimension）和一致性事實（Conformed Fact）。?
1、總線架構
多維體系結構(總線架構) 數據倉庫領域里，有一種構建數據倉庫的架構，叫Multidimensional Architecture（MD），中文一般翻譯為“多維體系結構”，也稱為“總線架構”（Bus Architecture）。
多維體系結構的創始人是數據倉庫領域中最有實踐經驗的Kimball博士。多維體系結構主要包括后臺（Back Room）和前臺（Front Room）兩部分。后臺也稱為數據準備區（Staging Area），是MD架構的最為核心的部件。在后臺，是一致性維度的產生、保存和分發的場所。同時，代理鍵也在后臺產生。前臺是MD架構對外的接口，包括兩種主要的數據集市，一種是原子數據集市，另一種是聚集數據集市。
原子數據集市保存著最低粒度的細節數據，數據以星型結構來進行數據存儲。聚集數據集市的粒度通常比原子數據集市要高，和原子數據集市一樣，聚集數據集市也是以星型結構來進行數據存儲。前臺還包括像查詢管理、活動監控等為了提供數據倉庫的性能和質量的服務。在多維體系結構中，所有的這些基于星型機構來建立的數據集市可以在物理上存在于一個數據庫實例中，也可以分散在不同的機器上，而所有這些數據集市的集合組成的分布式的數據倉庫。
2、一致性維度?
在多維體系結構中，沒有物理上的數據倉庫，由物理上的數據集市組合成邏輯上的數據倉庫。而且數據集市的建立是可以逐步完成的，最終組合在一起，成為一個數據倉庫。如果分步建立數據集市的過程出現了問題，數據集市就會變成孤立的集市，不能組合成數據倉庫，而一致性維度的提出正式為了解決這個問題。
一致性維度的范圍是總線架構中的維度，即可能會在多個數據集市中都存在的維度，這個范圍的選取需要架構師來決定。一致性維度的內容和普通維度并沒有本質上區別，都是經過數據清洗和整合后的結果。?一致性維度建立的地點是多維體系結構的后臺（Back Room），即數據準備區。
在多維體系結構的數據倉庫項目組內需要有專門的維度設計師，他的職責就是建立維度和維護維度的一致性。在后臺建立好的維度同步復制到各個數據集市。這樣所有數據集市的這部分維度都是完全相同的。建立新的數據集市時，需要在后臺進行一致性維度處理，根據情況來決定是否新增和修改一致性維度，然后同步復制到各個數據集市。這是不同數據集市維度保持一致的要點。
在同一個集市內，一致性維度的意思是兩個維度如果有關系，要么就是完全一樣的，要么就是一個維度在數學意義上是另一個維度的子集。
例如，如果建立月維度話，月維度的各種描述必須與日期維度中的完全一致，最常用的做法就是在日期維度上建立視圖生成月維度。這樣月維度就可以是日期維度的子集，在后續鉆取等操作時可以保持一致。如果維度表中的數據量較大，出于效率的考慮，應該建立物化視圖或者實際的物理表。這樣，維度保持一致后，事實就可以保存在各個數據集市中。雖然在物理上是獨立的，但在邏輯上由一致性維度使所有的數據集市是聯系在一起，隨時可以進行交叉探察等操作，也就組成了數據倉庫。
3、一致性事實
在建立多個數據集市時，完成一致性維度的工作就已經完成了一致性的80%－90%的工作量。余下的工作就是建立一致性事實。一致性事實和一致性維度有些不同，一致性維度是由專人維護在后臺（Back Room），發生修改時同步復制到每個數據集市，而事實表一般不會在多個數據集市間復制。需要查詢多個數據集市中的事實時，一般通過交叉探查（drill across）來實現。
為了能在多個數據集市間進行交叉探查，一致性事實主要需要保證兩點：第一個是KPI的定義及計算方法要一致，第二個是事實的單位要一致性。如果業務要求或事實上就不能保持一致的話，建議不同單位的事實分開建立字段保存。
?
? ? ? 這樣，一致性維度將多個數據集市結合在一起，一致性事實保證不同數據集市間的事實數據可以交叉探查，一個分布式的數據倉庫就建成了。
小遍有話
- 總線矩陣：業務過程和維度的交點；
- 一致性維度：同一集市的維度表，內容相同或包含；
- 一致性事實：不同集市的同一事實，需保證口徑一致，單位統一。
追求一致性必然會增加開發工作量，但長期來說，使用方便、運維簡單；一致性和性能之間，需要平衡。
?
五、數據倉庫規范設計
1、為什么要進行規范設計
無規矩、不方圓。規范設計是在具體開發工作之前制定的，過程中不斷進行完善。目的在于約束?N 個人對齊認知，按照一個標準或流程進行開發，以保證數據一致性，流程清晰且穩定。
一個良好的規范設計，應當起到以下作用：提高開發效率，提升質量，降低溝通對齊成本，降低運維成本等。
下面西紅柿🍅將帶領大家盤一盤數據倉庫有哪些規范，從中挑選幾個重點細說：
- 設計規范
? ? ? ? ? ? 邏輯架構、技術架構、分層設計、主題劃分、方法論
- ?命名規范
? ? ? ? ? ? 各層級命名、任務命名、表命名、字段命名、指標命名等?
- 模型規范
? ? ? ? ? ? 建模方法、建模工具、血緣關系、維度退化、一致性維度、元數據管理
- 開發規范
? ? ? ? ? ? 腳本注釋、字段別名、編碼規范、腳本格式、數據類型、縮寫規范?
- 流程規范
? ? ? ? ? ? 需求流程、工程流程、上線流程、調度流、調度和表生命周期管理
2、設計規范 - 指標
- Step1：面向主題域管理
為了提高指標管理的效率，你需要按照業務線、主題域和業務過程三級目錄方式管理指標。
?
- Step2：劃分原子指標和派生指標
原子指標 +?原子指標? =?派生指標
?
- Step3：進行指標命名規范
需要遵循兩個原則：易懂與統一
對于原子指標，標名稱適合用“動作 + 度量”的命名方式（比如注冊用戶數、購買用戶數）
對于派生指標，應該嚴格遵循“時間周期 + 統計粒度 + 修飾詞 + 原子指標”的命名方式。（比如30天內黑卡會員購買用戶數）
- Step4：分級管理
指標確實是多，如果一視同仁去管理其實很難，所以可以按照下面的原則進行等級劃分：
3、命名規范 - 表命名
3.1 常規表
常規表是我們需要固化的表，是正式使用的表，是目前一段時間內需要去維護去完善的表。
規范：分層前綴[dwd|dws|ads|bi]_業務域_主題域_XXX_更新頻率|全量/增量。?
業務域、主題域我們都可以用詞根的方式枚舉清楚，不斷完善，粒度也是同樣的，主要的是時間粒度、日、月、年、周等，使用詞根定義好簡稱。
建議格式：?dwd_xxx_xxx_da
- di ：每日增量
- da：每日全量
- mi：每月增量
- ma：每月全量
3.2 中間表
中間表一般出現在Job中，是Job中臨時存儲的中間數據的表，中間表的作用域只限于當前Job執行過程中，Job一旦執行完成，該中間表的使命就完成了，是可以刪除的（按照自己公司的場景自由選擇，以前公司會保留幾天的中間表數據，用來排查問題）。
建議格式：mid_table_name_[0~9]
table_name是我們任務中目標表的名字，通常來說一個任務只有一個目標表。這里加上表名，是為了防止自由發揮的時候表名沖突，而末尾大家可以選擇自由發揮，起一些有意義的名字，或者簡單粗暴，使用數字代替，各有優劣吧，謹慎選擇。
3.3 臨時表
臨時表是臨時測試的表，是臨時使用一次的表，就是暫時保存下數據看看，后續一般不再使用的表，是可以隨時刪除的表。
建議格式：tmp_xxx
只要加上tmp開頭即可，其他名字隨意，注意tmp開頭的表不要用來實際使用，只是測試驗證而已。
3.4 維度表
維度表是基于底層數據，抽象出來的描述類的表。維度表可以自動從底層表抽象出來，也可以手工來維護。
建議格式：dim_xxx
維度表，統一以dim開頭，后面加上，對該指標的描述，可以自由發揮。
4、開發規范
| 1 | 表和列的注釋釋是否有缺失，復雜計算邏輯是否有注釋釋 |
| 2 | 任務是否支持多次重跑而輸出不變，不能有insert into語句 |
| 3 | 分區表是否使用分區鍵過濾并且有有效裁剪 |
| 4 | 外連接的過逑條件是否使用正確，例如在左連接的where語句存在右表的過濾條件 |
| 5 | 關聯小表，是否使用/*+ map join * / hint |
| 6 | 不允許引用別的計算任務臨時表 |
| 7 | 原則上不允許存在一個任務更新多個目標表 |
| 8 | 是否存在笞、迪卡爾積 |
| 9 | 禁止在代碼里面使用drop 111ble、creat它111ble、renaiue 111ble、chan零column等ddl語句 |
| 10 | 使用動態分區時，有沒有檢查分區鍵值為NULL的情況 |
| 11 | DQC質量監控規則是否配置，嚴禁棵奔 |
| 12 | 代碼中有沒有進行適當的規避數據傾斜語句 |
| 13 | Where條件中is null語句有沒有進行空字符串處理 |
5、流程規范
根據阿里流程規范，本文將數據倉庫研發流程抽象為如下幾點：
六、元數據管理
1、業務元數據
2、技術元數據
-
數據源元數據
- 例如：數據源的 IP、端口、數據庫類型；數據獲取的方式；數據存儲的結構；原數據各列的定義及 key 指對應的值。
-
ETL?元數據
- 根據 ETL 目的的不同，可以分為兩類：數據清洗元數據；數據處理元數據。
- 數據清洗，主要目的是為了解決掉臟數據及規范數據格式；因此此處元數據主要為：各表各列的"正確"數據規則；默認數據類型的"正確"規則。
- 數據處理，例如常見的表輸入表輸出；非結構化數據結構化；特殊字段的拆分等。源數據到數倉、數據集市層的各類規則。比如內容、清理、數據刷新規則。
-
數據倉庫元數據
- 數據倉庫結構的描述，包括倉庫模式、視圖、維、層次結構及數據集市的位置和內容；業務系統、數據倉庫和數據集市的體系結構和模式等。
-
BI?元數據
- 匯總用的算法、包括各類度量和維度定義算法。數據粒度、主題領域、聚集、匯總、預定義的查詢與報告。
3、管理元數據
管理領域相關，包括管理流程、人員組織、角色職責等。
4、小編有話
在日常工作中，元數據的管理主要體現在元數據的采集、存儲、查詢、應用幾個方面。原則上應從規范化，到腳本化，到工具化的方向進行建設。
- 采集：元數據采集時盡可能詳細，真實，可通過工具生成或者勾選，避免手動錄入帶來不規范等問題
- 存儲：存儲元數據要做到不失真，元數據變更時及時同步
- 查詢：通過網頁或庫表等方式，方便快捷的看到元數據，輔助進行開發
- 應用：數據血緣、優化調度依賴、數據治理等
?
七、維度表
1、什么是維度表
?維度是維度建模的基礎和靈魂。在維度建模中，將度量稱為“事實” ， 將環境描述為“維度”。
維度表包含了事實表中指定屬性的相關詳細信息，最常用的維度表有日期維度、城市維度等。
日期維表：
| num | 字段名 | 字段中文名 | 描述 | 數據類型 |
| 1 | date | 日期 | 日期 yyyMMdd格式 | bigint |
| 2 | week | 星期，數字型 | 星期，數字型 0-6 | bigint |
| 3 | week_cn | 星期中文名 | 星期中文名 星期一…… | string |
| 4 | year_weeks | 一年中的第幾周 | 一年中的第幾周 1 2 3…… | bigint |
| 5 | mon_dt | 本周周一日期 | 本周周一日期 | bigint |
| 6 | sun_dt | 本周周日日期 | 本周周日日期 | bigint |
| 7 | month | 年月 | 年月，yyyyMM格式 | bigint |
| 8 | month_short | 月份簡寫 | 月份簡寫，MM格式1~12 | bigint |
| 9 | month_cn | 月份中文名 | 月份中文名 一月…… | string |
| 10 | quarter | 季度 | 季度，yyyyQ1\2\3\4 | string |
| 11 | quarter_short | 季度 數字型 | 季度 數字型 1-4 | bigint |
| 12 | quarter_cn | 季度中文名 | 季度中文名 第一季度…… | string |
| 13 | year | 年份 | 年份，yyyy格式 | bigint |
2、維度表設計原則
維度的作用一般是查詢約束、分類匯總以及排序等，我們在進行維度表設計時，應當提前考慮：
?
（1）維度屬性盡量豐富，為數據使用打下基礎
比如淘寶商品維度有近百個維度屬性，為下游的數據統計、分析、探查提供了良好的基礎。
（2）給出詳實的、富有意義的文字描述
屬性不應該是編碼，而應該是真正的文字。在間里巴巴維度建模中， 一般是編碼和文字同時存在，比如商品維度中的商品 ID 和商品標題、 類目 ID 和 類目名稱等。ID 一 般用于不同表之間的關聯，而名稱一般用 于報表標簽
（3）區分數值型屬性和事實
數值型宇段是作為事實還是維度屬性，可以參考字段的一般用途。如果通常用于查詢約束條件或分組統計，則是作為維度屬性;如果通常 用于參與度量的計算， 則是作為事實。比如商品價格，可以用于查詢約 束條件或統計價格區間 的商品數量，此時是作為維度屬性使用的;也可 以用于統計某類目 下商品的平均價格，此時是作為事實使用的。另外， 如果數值型字段是離散值，則作為維度屬性存在的可能性較大;如果數 值型宇段是連續值 ，則作為度量存在的可能性較大，但并不絕對，需要 同時參考宇段的具體用途。
（4）沉淀出通用的維度屬性，為建立一致性維度做好鋪墊
有些維度屬性獲取需要進行比較復雜的邏輯處理，有些需要通過多表關聯得到，或者通過單表 的不同宇段混合處理得到，或者通過對單表 的某個字段進行解析得到。此時，需要將盡可能多的通用的維度屬性進 行沉淀。一方 面，可以提高下游使用的方便性，減少復雜度;另一方面，可以避免下游使用解析時由于各自邏輯不同而導致口徑不 一致。
（5）退化維度（Degenerate Dimension）
在維度類型中，有一種重要的維度稱作為退化維度。這種維度指的是直接把一些簡單的維度放在事實表中。退化維度是維度建模領域中的一個非常重要的概念，它對理解維度建模有著非常重要的作用，退化維度一般在分析中可以用來做分組使用。
（6）緩慢變化維（Slowly Changing Dimensions）
維度的屬性并不是始終不變的，它會隨著時間的流逝發生緩慢的變化，這種隨時間發生變化的維度我們一般稱之為緩慢變化維（SCD），緩慢變化維一般使用代理健作為維度表的主健。
?
推薦閱讀：緩慢變化維度的10種處理方式
?
緩慢變化維
①?TYPE1?直接覆蓋原值
適用于：不看歷史數據，簡單粗暴
②?TYPE2?拉鏈表
需要在維度行再增加三列：有效日期、截止日期、行標識（可選）。
在舊的一行數據增加關鏈時間（end_date），新的一行數據增加開鏈時間和關鏈時間，多條數據加起來是一個完整的時間周期。
③?TYPE3?增加屬性列
3、維度表設計方法
- 第一步：選擇維度或新建維度。作為維度建模的核心，在企業級數 據倉庫中必須保證維度的唯一性。以淘寶商品維度為例，有且只允許有 一個維度定義。
- 第二步：確定主維表。此處的主維表一般是 ODS 表，直接與業務 系統同步。以淘寶商品維度為例， s_auction_auctions 是與前臺商品中心 系統同步的商品表，此表即是主維表。
- 第三步：確定相關維表。數據倉庫是業務源系統的數據整合，不同業務系統或者同 一業務系統中的表之間存在 關聯性。根據對業務的梳 理，確定哪些表和主維表存在關聯關系，并選擇其中的某些表用于生成維度屬性。
- 第四步 ：確定維度屬性?。本步驟主要 包括兩個階段，其中第 一 個階 段是從主維表 中選擇維度屬性或生成新的維度屬性;第 二個階段是從相 關維表中選擇維度屬性或生成新 的維度屬性。以淘寶商品維度為例，從 主維表 (s_auction_auctions)和類目、 SPU、賣家、店鋪等相關維表中 選擇維度屬性或生成新 的維度屬性。
?
八、三范式與反范式
范式是符合某一種級別的關系模式的集合。構造數據庫必須遵循一定的規則。在關系數據庫中，這種規則就是范式。
? ? ? ?關系數據庫中的關系必須滿足一定的要求，即滿足不同的范式。大數據生態中，各類強大的查詢引擎層出不窮，相對廉價的磁盤和分布式技術，也讓數據冗余變得可接受甚至更加方便。
? ? ? ?在創建一個數據庫的過程中，范化是將其轉化為一些表的過程，這種方法可以使從數據庫得到的結果更加明確。這樣可能使數據庫產生重復數據，從而導致創建多余的表。范化是在識別數據庫中的數據元素、關系以及定義所需的表和各表中的項目等這些初始工作之后的一個細化的過程。
1、第一范式
1NF要求屬性具有原子性，即列不可再分解；
表：字段1、 字段2(字段2.1、字段2.2)、字段3 ......
如學生（學號，姓名，性別，出生年月日）
有些鋼筋可能要問西紅柿了，姓名可以拆成姓、名兩列，?“出生年月日” 也可以拆成年、月、日三個字段。所以就不滿足第一范式了！！！這里再強調一下原子性，原子性是根據使用方便來自定義的最小單位。中國人一般姓名一起用，美國就習慣姓名分別存兩字段。
2、第二范式
2NF要求記錄有惟一標識，即不存在部分依賴；
簡單來說就是拆表，以人為粒度做一張明細表，以課程號為粒度做一張維度表，兩表關聯使用，消除了數據冗余
表：學號、課程號、姓名、學分;
這個表明顯說明了兩個事務:學生信息, 課程信息;由于非主鍵字段必須依賴主鍵，這里學分依賴課程號，姓名依賴與學號，所以不符合二范式。
可能會存在問題：
- 數據冗余：每條記錄都含有相同信息；
- 刪除異常：刪除所有學生成績，就把課程信息全刪除了；
- 插入異常：學生未選課，無法記錄進數據庫；
- 更新異常：調整課程學分，所有行都調整。
正確做法:?
學生：Student(學號, 姓名)；?
課程：Course(課程號, 學分)；?
選課關系：StudentCourse(學號, 課程號, 成績)。
3、第三范式
3NF是對字段的冗余性，要求任何字段不能由其他字段派生出來，它要求字段沒有冗余，即不存在傳遞依賴；
表: 學號, 姓名, 年齡, 學院名稱, 學院電話
因為存在依賴傳遞: (學號) → (學生)→(所在學院) → (學院電話) 。
可能會存在問題：
- 數據冗余:有重復值；
- 更新異常：有重復的冗余信息，修改時需要同時修改多條記錄，否則會出現數據不一致的情況?。
正確做法：
學生：(學號, 姓名, 年齡, 所在學院)；
學院：(學院, 電話)。
4、反范式化
一般說來，數據庫只需滿足第三范式（3NF）就行了。
? ? 沒有冗余的數據庫設計可以做到。但是，沒有冗余的數據庫未必是最好的數據庫，有時為了提高運行效率，就必須降低范式標準，適當保留冗余數據。具體做法是：在概念數據模型設計時遵守第三范式，降低范式標準的工作放到物理數據模型設計時考慮。降低范式就是增加字段，允許冗余，達到以空間換時間的目的。
? 〖例〗：有一張存放商品的基本表，如表1所示。“金額”這個字段的存在，表明該表的設計不滿足第三范式，因為“金額”可以由“單價”乘以“數量”得到，說明“金額”是冗余字段。但是，增加“金額”這個冗余字段，可以提高查詢統計的速度，這就是以空間換時間的作法。
? ? 在Rose 2002中，規定列有兩種類型：數據列和計算列。“金額”這樣的列被稱為“計算列”，而“單價”和“數量”這樣的列被稱為“數據列”。
5、范式化設計和反范式化設計的優缺點
5.1 范式化 （時間換空間）
優點：
- 范式化的表減少了數據冗余，數據表更新操作快、占用存儲空間少。
缺點：
- 查詢時需要對多個表進行關聯，查詢性能降低。?
- 更難進行索引優化
5.2 反范式化（空間換時間）
反范式的過程就是通過冗余數據來提高查詢性能，但冗余數據會犧牲數據一致性
優點：
- 可以減少表關聯
- 可以更好進行索引優化
缺點：
- 存在大量冗余數據
- 數據維護成本更高（刪除異常，插入異常，更新異常）
6、OLAP和OLTP中范式設計
OLAP 一般冗余比較多，以查詢分析為主，這種一般都是采用反范式設計，以提高查詢效率。更新一般是定時大批量數據插入。
?
OLTP 則是盡可能消除冗余，以提高變更的效率。因為這種應用無時無刻不在頻繁變化。
?
九、數據倉庫架構-Lambda和Kappa
隨著數據量的暴增和數據實時性要求越來越高，以及大數據技術的發展驅動企業不斷升級迭代，數據倉庫架構方面也在不斷演進，分別經歷了以下過程：早期經典數倉架構 > 離線大數據架構 > Lambda > Kappa > 混合架構。
| 架構 | 組成 | 特點 |
| 經典數倉架構 | 關系型數據庫（mysql、oracle）為主 | 數據量小，實時性要求低 |
| 離線大數據架構 | hive，spark為主 | 數據量大，實時性要求低 |
| Lambda | hive，spark負責存量，strom/Flink負責實時計算 | 數據量大，實時性要求高 |
| Kappa | kafka、strom、Flink | 多業務，多數據源，事件型數據源 |
| 混合架構 |
ps.西紅柿的舉例若有不當，歡迎指正
1、Lambda架構原理
Lambda架構的核心思想是把大數據系統拆分成三層：Batch Layer，Speed Layer和Serving Layer。其中，Batch Layer負責數據集存儲以及全量數據集的預查詢。
?
Speed Layer主要負責對增量數據進行計算，生成Realtime Views。Serving Layer用于響應用戶的查詢請求，它將Batch Views和Realtime Views的結果進行合并，得到最后的結果，返回給用戶，如下圖：
?
2、Lambda架構的缺點
Lambda架構解決了大數據量下實時計算的問題，但架構本身也存在一定缺點。
- 實時與批量計算結果不一致引起的數據口徑問題：因為批量和實時計算走的是兩個計算框架和計算程序，算出的結果往往不同，經常看到一個數字當天看是一個數據，第二天看昨天的數據反而發生了變化。
- 批量計算在計算窗口內無法完成：在IOT時代，數據量級越來越大，經常發現夜間只有4、5個小時的時間窗口，已經無法完成白天20多個小時累計的數據，保證早上上班前準時出數據已成為每個大數據團隊頭疼的問題。
- 開發和維護的復雜性問題：Lambda 架構需要在兩個不同的 API（application programming interface，應用程序編程接口）中對同樣的業務邏輯進行兩次編程：一次為批量計算的ETL系統，一次為流式計算的Streaming系統。針對同一個業務問題產生了兩個代碼庫，各有不同的漏洞。這種系統實際上非常難維護
- 服務器存儲大：數據倉庫的典型設計，會產生大量的中間結果表，造成數據急速膨脹，加大服務器存儲壓力。
3、Kappa架構原理
Kappa架構的核心思想包括以下三點：
- 用Kafka或者類似的分布式隊列系統保存數據，你需要幾天的數據量就保存幾天。
- 當需要全量重新計算時，重新起一個流計算實例，從頭開始讀取數據進行處理，并輸出到一個新的結果存儲中。
- 當新的實例做完后，停止老的流計算實例，并把老的一些結果刪除。
- 在Kappa架構下，只有在有必要的時候才會對歷史數據進行重復計算，并且實時計算和批處理過程使用的是同一份代碼。
4、Lambda架構和Kappa架構優缺點對比
| 項目 | Lambda | Kappa |
| 數據處理能力 | 可以處理超大規模的歷史數據 | 歷史數據處理的能力有限 |
| 機器開銷 | 批處理和實時計算需一直運行，機器開銷大 | 必要時進行全量計算，機器開銷相對較小 |
| 存儲開銷 | 只需要保存一份查詢結果，存儲開銷較小 | 需要存儲新老實例結果，存儲開銷相對較大 |
| 開發、測試難度 | 實現兩套代碼，開發、測試難度較大 | 只需面對一個框架，開發、測試難度相對較小 |
| 運維成本 | 維護兩套系統，運維成本大 | 只需維護一個框架，運維成本小 |
5、數據架構評價標準
- 響應速度：數據架構的主要場景包括：業務開發、數據產品、運營分析三大類，不論是那種場景，數據架構均應該在盡可能短的時間內響應需求；
- 可復用性：只有復用能力上來了，響應速度才能提上來，體現在下游依賴、調用次數、核心字段覆蓋率等指標上；
- 穩定性：除了日常任務不出問題以外，一旦發現了問題，能在多短的時間內定位和恢復問題，就非常重要；
- 健壯性：除了電商等已經耕耘多年的領域外，絕大多數業務模型，都會快速的變化，如何適應這種變化，就非常考驗架構功底。
6、小編有話
- Lambda 將全量歷史數據和實時增量數據合并輸出。
- Kappa 兩個流協作輸出，queries每次使用最新一個流處理結果
目前很多準實時增量批處理方案也能滿足實時性需求，從穩定性和運維成本上也表現更佳。
比如kudu（存儲）+impala（計算）準實時方案，可以實現千萬級數據的增量更新和olap查詢，性能優異。
?
十、數據治理（目的、方法、流程）
1、什么是數據治理
數據治理（Data Governance）是組織中涉及數據使用的一整套管理行為。由企業數據治理部門發起并推行，關于如何制定和實施針對整個企業內部數據的商業應用和技術管理的一系列政策和流程。
數據的質量直接影響著數據的價值，并且直接影響著數據分析的結果以及我們以此做出的決策的質量。
我們常說，用數據說話，用數據支撐決策管理，但低質量的數據、甚至存在錯誤的數據，必然會"說假話"！！！數據治理即提高數據的質量，發揮數據資產價值。
2、數據治理的目的
- 降低風險
- 建立數據使用內部規則
- 實施合規要求
- 改善內部和外部溝通
- 增加數據價值
- 方便數據管理
- 降低成本
- 通過風險管理和優化來幫助確保公司的持續生存
3、數據治理的方法
從技術實施角度看，數據治理包含“理”“采”“存”“管”“用”這五個步驟，即業務和數據資源梳理、數據采集清洗、數據庫設計和存儲、數據管理、數據使用。?
數據資源梳理：數據治理的第一個步驟是從業務的視角厘清組織的數據資源環境和數據資源清單，包含組織機構、業務事項、信息系統，以及以數據庫、網頁、文件和 API 接口形式存在的數據項資源，本步驟的輸出物為分門別類的數據資源清單。
數據采集清洗：通過可視化的 ETL 工具（例如阿里的 DataX，Pentaho Data Integration）將數據從來源端經過抽取 (extract)、轉換 (transform)、加載 (load) 至目的端的過程，目的是將散落和零亂的數據集中存儲起來。
基礎庫主題庫建設：一般情況下，可以將數據分為基礎數據、業務主題數據和分析數據。基礎數據一般指的是核心實體數據，或稱主數據，例如智慧城市中的人口、法人、地理信息、信用、電子證照等數據。主題數據一般指的是某個業務主題數據，例如市場監督管理局的食品監管、質量監督檢查、企業綜合監管等數據。而分析數據指的是基于業務主題數據綜合分析而得的分析結果數據，例如市場監督管理局的企業綜合評價、產業區域分布、高危企業分布等。那么基礎庫和主題庫的建設就是在對業務理解的基礎上，基于易存儲、易管理、易使用的原則抽像數據存儲結構，說白了，就是基于一定的原則設計數據庫表結構，然后再根據數據資源清單設計數據采集清洗流程，將整潔干凈的數據存儲到數據庫或數據倉庫中。
元數據管理：元數據管理是對基礎庫和主題庫中的數據項屬性的管理，同時，將數據項的業務含義與數據項進行了關聯，便于業務人員也能夠理解數據庫中的數據字段含義，并且，元數據是后面提到的自動化數據共享、數據交換和商業智能（BI）的基礎。需要注意的是，元數據管理一般是對基礎庫和主題庫中（即核心數據資產）的數據項屬性的管理，而數據資源清單是對各類數據來源的數據項的管理。
血緣追蹤：數據被業務場景使用時，發現數據錯誤，數據治理團隊需要快速定位數據來源，修復數據錯誤。那么數據治理團隊需要知道業務團隊的數據來自于哪個核心庫，核心庫的數據又來自于哪個數據源頭。我們的實踐是在元數據和數據資源清單之間建立關聯關系，且業務團隊使用的數據項由元數據組合配置而來，這樣，就建立了數據使用場景與數據源頭之間的血緣關系。數據資源目錄：數據資源目錄一般應用于數據共享的場景，例如政府部門之間的數據共享，數據資源目錄是基于業務場景和行業規范而創建，同時依托于元數據和基礎庫主題而實現自動化的數據申請和使用。
質量管理：數據價值的成功發掘必須依托于高質量的數據，唯有準確、完整、一致的數據才有使用價值。因此，需要從多維度來分析數據的質量，例如：偏移量、非空檢查、值域檢查、規范性檢查、重復性檢查、關聯關系檢查、離群值檢查、波動檢查等等。需要注意的是，優秀的數據質量模型的設計必須依賴于對業務的深刻理解，在技術上也推薦使用大數據相關技術來保障檢測性能和降低對業務系統的性能影響，例如 Hadoop，MapReduce，HBase 等。
商業智能（BI）：數據治理的目的是使用，對于一個大型的數據倉庫來說，數據使用的場景和需求是多變的，那么可以使用 BI 類的產品快速獲取需要的數據，并分析形成報表，比較知名的產品有 Microsoft Power BI，QlikView，Tableau，帆軟等。
數據共享交換：數據共享包括組織內部和組織之間的數據共享，共享方式也分為庫表、文件和 API 接口三種共享方式，庫表共享比較直接粗暴，文件共享方式通過 ETL 工具做一個反向的數據交換也就可以實現。我們比較推薦的是 API 接口共享方式，在這種方式下，能夠讓中心數據倉庫保留數據所有權，把數據使用權通過 API 接口的形式進行了轉移。API 接口共享可以使用 API 網關實現，常見的功能是自動化的接口生成、申請審核、限流、限并發、多用戶隔離、調用統計、調用審計、黑白名單、調用監控、質量監控等等。
4、數據質量8個衡量標準
- 數據的準確性
數據采集值或者觀測值和真實值之間的接近程度，也叫做誤差值，誤差越大，準確度越低。
- 數據的精確性
指對同一對象的觀測數據在重復測量時所得到不同數據間的接近程度。
- 數據的真實性
- 數據的及時性
數據能否在需要的時候得到保證，比如月初的財務對賬，能不能在月初就完成
- 數據的即時性
指數據采集時間節點和數據傳輸的時間節點，一個數據在數據源頭采集后立即存儲，并立即加工呈現，就是即時數據，而經過一段時間之后再傳輸到信息系統中，則數據即時性就稍差。
- 數據的完整性
應采集和實際采集到數據之間的比例。
- 數據的全面性
完整性衡量的是應采集和實際采集的差異。而全面性指的是數據采集點的遺漏情況。
- 數據的關聯性
指各個數據集之間的關聯關系。比如員工工資數據和員工績效考核數據是通過員工這個資源關聯在一起來的。
信息技術智庫關注領取技術資料、面試真題、簡歷模板和PPT模板；一起交流工作難題、面試套路、職場經驗、內推直通車公眾號
5、數據治理流程
基本流程：發現數據質量問題 > 定義數據質量規則 > 質量控制 > 質量評估 > 質量優化
?
十一、ETL
1、什么是ETL
ETL，是英文Extract-Transform-Load的縮寫，用來描述將數據從來源端經過抽取（extract）、轉換（transform）、加載（load）至目的端的過程，是數據倉庫的生命線。
? ? ? ?抽取（Extract）主要是針對各個業務系統及不同服務器的分散數據，充分理解數據定義后，規劃需要的數據源及數據定義，制定可操作的數據源，制定增量抽取和緩慢漸變的規則。
? ? ? ?轉換（transform）主要是針對數據倉庫建立的模型，通過一系列的轉換來實現將數據從業務模型到分析模型，通過ETL工具可視化拖拽操作可以直接使用標準的內置代碼片段功能、自定義腳本、函數、存儲過程以及其他的擴展方式，實現了各種復雜的轉換，并且支持自動分析日志，清楚的監控數據轉換的狀態并優化分析模型。
裝載（Load）主要是將經過轉換的數據裝載到數據倉庫里面，可以通過直連數據庫的方式來進行數據裝載，可以充分體現高效性。在應用的時候可以隨時調整數據抽取工作的運行方式，可以靈活的集成到其他管理系統中。
2、ETL &?ELT
伴隨著數據倉庫的發展（傳送門：數據倉庫的八個發展階段），數據量從小到大，數據實時性從T+1到準實時、實時，ETL也在不斷演進。
?
- 在傳統數倉中，數據量小，計算邏輯相對簡單，我們可以直接用ETL工具實現數據轉換（T），轉換之后再加載到目標庫，即（Extract-Transform-Load）。
- 但在大數據場景下，數據量越大越大，計算邏輯愈發復雜，數據清洗需放在運算能力更強的分布式計算引擎中完成，ETL也就變成了ELT（Extract-Load-Transform）。
即：Extract-Transform-Load ?>>? Extract-Load-Transform
通常我們所說的ETL，已經泛指數據同步、數據清洗全過程，而不僅限于數據的抽取-轉換-加載。
3、常用的ETL工具
下面小編將介紹幾類ETL工具（sqoop，DataX，Kettle，canal，StreamSets）。
3.1 sqoop
- 是Apache開源的一款在Hadoop和關系數據庫服務器之間傳輸數據的工具。
- 可以將一個關系型數據庫（MySQL ,Oracle等）中的數據導入到Hadoop的HDFS中，也可以將HDFS的數據導出到關系型數據庫中。
- sqoop命令的本質是轉化為MapReduce程序。
- sqoop分為導入（import）和導出（export），
- 策略分為table和query
- 模式分為增量和全量。
3.2 DataX
- DataX 是阿里巴巴集團內被廣泛使用的離線數據同步工具/平臺
- 實現包括 MySQL、Oracle、SqlServer、Postgre、HDFS、Hive、ADS、HBase、TableStore(OTS)、MaxCompute(ODPS)、DRDS 等各種異構數據源之間高效的數據同步功能。
3.3?Kettle
- 一款國外免費開源的、可視化的、功能強大的ETL工具，純java編寫，可以在Windows、Linux、Unix上運行，數據抽取高效穩定。
3.4?canal
- canal是阿里巴巴旗下的一款開源項目，純Java開發。基于數據庫增量日志解析，提供增量數據實時訂閱和消費，目前主要支持了MySQL，也支持mariaDB。
3.5 StreamSets
- 是大數據實時采集ETL工具，可以實現不寫一行代碼完成數據的采集和流轉。通過拖拽式的可視化界面，實現數據管道(Pipelines)的設計和定時任務調度。
- 創建一個Pipelines管道需要配置數據源(Origins)、操作(Processors)、目的地(Destinations)三部分。
4、ETL加載策略
4.1 增量
- 有些表巨大，我們需要選擇增量策略，新增delta數據需要和存量數據merge合并。
只有新增(full join。能拿更新表就拿更新表)
- 新增+刪除
- history-table Left join delet-table where delect-table.value is null == 表a
- 表a full join update-table (能拿update就拿update)
4.2 全量
每天一個全量表，也可一個hive天分區一個全量。
4.3 流式
使用kafka，消費mysql binlog日志到目標庫，源表和目標庫是1：1的鏡像。
5、小編有話
無論是全量還是增量的方式，都會浪費多余的存儲或通過計算去重，得到最新的全量數據。為解決這一問題，西紅柿墻裂建議kafka的數據同步方案，源表變化一條，目標表消費一條，目標表數據始終是一份最新全量數據，且為實時同步的。?
?
ps.極端情況下可能會丟數，需要寫幾個監控腳本（詳見上文數據質量部分）和補數腳本即可~
?
十二、數據應用-OLAP
1、olap和oltp的區別
| OLTP | OLAP | |
| 對象 | 業務開發人員 | 分析決策人員 |
| 功能 | 日常事務處理 | 面向分析決策 |
| 模型 | 關系模型 | 多維模型 |
| 數據量 | 幾條或幾十條記錄 | ＞百萬于萬條記錄 |
| 操作類型 | 增、刪、查、改(CRUD) | 查詢為主 |
| 總體概括 | 聯機事務處理 | 在線分析處理 |
2、OLAP分類
- MOLAP，基于多維數組的存儲模型，也是OLAP最初的形態，特點是對數據進行預計算，以空間換效率，明細和聚合數據都保存在cube中。但生成cube需要大量時間和空間。
- ROLAP，基于關系模型進行存儲數據，不需要預計算，按需即時查詢。明細和匯總數據都保存在關系型數據庫事實表中。其特點是與事務實體對應，關系清晰；但一般需要較為復雜的數據準備。在響應前端需求時，一般較快，但取決于計算引擎能力。
- HOLAP，混合模型，細節數據以ROLAP存放，聚合數據以MOLAP存放。這種方式相對靈活，且更加高效。可按企業業務場景和數據粒度進行取舍，沒有最好，只有最適合。
3、OLAP基本操作
- ★鉆取：維的層次變化，從粗粒度到細粒度，匯總數據下鉆到明細數據。如通過季度銷售數據鉆取每個月的銷售數據。
- ★上卷：鉆取的逆，向上鉆取。從細粒度到粗粒度，細粒度數據到不同維層級的匯總。eg. 通過每個月的銷售數據匯總季度、年銷售數據。
- ★切片：特定維數據（剩余維兩個）。eg. 只選電子產品銷售數據。
- ★切塊：維區間數據（剩余維三個）。eg. 第一季度到第二季度銷售數據。
- ★旋轉：維位置互換（數據行列互換），通過旋轉可以得到不同視角的數據。
4、OLAP選型
4.1 druid
- 實時查詢和分析的高容錯、高性能開源分布式系統，用于解決如何在大規模數據集下進行快速的、交互式的查詢和分析。
- 實時的數據消費，真正做到數據攝入實時、查詢結果實時。
- 擴展性強，支持 PB 級數據
- 極高的高可用保障，支持滾動升級。
- druid屬于時間存儲，刪除操作比較繁瑣，且不支持查詢條件刪除數據，只能根據時間范圍刪除數據。Druid能接受的數據的格式相對簡單，比如不能處理嵌套結構的數據。
4.2?kylin
- 可擴展超快olap引擎，Hadoop/Spark上百億數據規模
- 提供 Hadoop ANSI SQL 接口
- 交互式查詢能力，用戶可以與Hadoop數據進行亞秒級交互
- 百億以上數據集構建多維立方體（MOLAP CUBE）
- 與BI工具無縫整合，如Tableau，PowerBI/Excel，MSTR，QlikSense，Hue和SuperSet
?
十三、數據傾斜
1、數據傾斜表現
1.1 hadoop中的數據傾斜表現
- 有一個多幾個Reduce卡住，卡在99.99%，一直不能結束。
- 各種container報錯OOM
- 異常的Reducer讀寫的數據量極大，至少遠遠超過其它正常的Reducer
- 伴隨著數據傾斜，會出現任務被kill等各種詭異的表現。
?
1.2 hive中數據傾斜
一般都發生在Sql中group by和join on上，而且和數據邏輯綁定比較深。
?
1.3 Spark中的數據傾斜
Spark中的數據傾斜，包括Spark Streaming和Spark Sql，表現主要有下面幾種：
- Executor lost，OOM，Shuffle過程出錯；
- Driver OOM；
- 單個Executor執行時間特別久，整體任務卡在某個階段不能結束；
- 正常運行的任務突然失敗；
2、數據傾斜產生原因
我們以Spark和Hive的使用場景為例。
在做數據運算的時候會涉及到，count distinct、group by、join on等操作，這些都會觸發Shuffle動作。一旦觸發Shuffle，所有相同key的值就會被拉到一個或幾個Reducer節點上，容易發生單點計算問題，導致數據傾斜。
?
一般來說，數據傾斜原因有以下幾方面：
1）key分布不均勻；
2）建表時考慮不周
舉一個例子，就說數據默認值的設計吧，假設我們有兩張表：
????user（用戶信息表）：userid，register_ip
????ip（IP表）：ip，register_user_cnt
這可能是兩個不同的人開發的數據表。如果我們的數據規范不太完善的話，會出現一種情況：
user表中的register_ip字段，如果獲取不到這個信息，我們默認為null；
但是在ip表中，我們在統計這個值的時候，為了方便，我們把獲取不到ip的用戶，統一認為他們的ip為0。
?
兩邊其實都沒有錯的，但是一旦我們做關聯了，這個任務會在做關聯的階段，也就是sql的on的階段卡死。
?
3）業務數據激增
比如訂單場景，我們在某一天在北京和上海兩個城市多了強力的推廣，結果可能是這兩個城市的訂單量增長了10000%，其余城市的數據量不變。
?
然后我們要統計不同城市的訂單情況，這樣，一做group操作，可能直接就數據傾斜了。
?
3、解決數據傾斜思路
很多數據傾斜的問題，都可以用和平臺無關的方式解決，比如更好的數據預處理，異常值的過濾等。因此，解決數據傾斜的重點在于對數據設計和業務的理解，這兩個搞清楚了，數據傾斜就解決了大部分了。
1）業務邏輯
我們從業務邏輯的層面上來優化數據傾斜，比如上面的兩個城市做推廣活動導致那兩個城市數據量激增的例子，我們可以單獨對這兩個城市來做count，單獨做時可用兩次MR，第一次打散計算，第二次再最終聚合計算。完成后和其它城市做整合。
2）程序層面
比如說在Hive中，經常遇到count(distinct)操作，這樣會導致最終只有一個Reduce任務。
我們可以先group by，再在外面包一層count，就可以了。比如計算按用戶名去重后的總用戶量：
?
（1）優化前?
只有一個reduce，先去重再count負擔比較大：
select name,count(distinct name)from user;
（2）優化后
// 設置該任務的每個job的reducer個數為3個。Hive默認-1，自動推斷。
set mapred.reduce.tasks=3;
// 啟動兩個job，一個負責子查詢(可以有多個reduce)，另一個負責count(1)：
select count(1) from (select name from user group by name) tmp;
?
3）調參方面
Hadoop和Spark都自帶了很多的參數和機制來調節數據傾斜，合理利用它們就能解決大部分問題。
?
4）從業務和數據上解決數據傾斜
很多數據傾斜都是在數據的使用上造成的。我們舉幾個場景，并分別給出它們的解決方案。
?
一個原則：盡早過濾每個階段的數據量。
添加公眾號「信息技術智庫」：
🍅 硬核資料：20G，8大類資料，關注即可領取（PPT模板、簡歷模板、技術資料）
🍅 技術互助：技術群大佬指點迷津，你的問題可能不是問題，求資源在群里喊一聲。
🍅 面試題庫：由各個技術群小伙伴們共同投稿，熱乎的大廠面試真題，持續更新中。
🍅 知識體系：含編程語言、算法、大數據生態圈組件（Mysql、Hive、Spark、Flink）、數據倉庫、前端等。
👇👇送書抽獎丨技術互助丨粉絲福利👇👇
總結
以上是生活随笔為你收集整理的耗时n年，38页《数据仓库知识体系.pdf》（数据岗位必备）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 国家信息安全公布：向日葵爆出执行漏洞，还
- 下一篇： PCA对特征点描述子降维