数据仓库介绍（DW）
第一章：了解DW
1.1什么是數據倉庫？
數據倉庫(Data Warehouse)，簡稱DW。數據倉庫顧名思義，是?個很?的數據存儲集合，出于企業的分析性報告和決策?持?的?創建，對多樣的業務數據進?篩選與整合。它能為企業提供?定的BI（商業智能：例如數據挖掘、數據分析和數據報表）能?。有了數據報表，還可以指導業務流程改進。
?由數據倉庫之父比爾·恩門（BillInmon）提出
?數據倉庫是一個面向主題的、集成的、非易失的且隨時間變化的數據集合
?主要用于組織積累的歷史數據，并使用分析方法（OLAP、數據分析）進行分析整理，進而輔助決策，為管理者、企業系統提供數據支持，構建商業智能。
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
1.2數據倉庫誕生的原因：? 歷史數據積存 ? 企業數據分析需要
歷史數據積存
? 歷史數據使用頻率低，堆積在業務庫中，導致性能下降
1.3數據倉庫誕生的背景：
-企業數據分析需要：?各個部門自己建立獨立的數據抽取系統，導致數據不一致。
1.4數據倉庫解決什么問題？
數據倉庫是應景大數據而生的，解決的問題無非就是存儲和快速提取， 另外還有跨部?應?的功能。
對于不同數據整合到了數據倉庫之后，也就是大數據有了存儲的位置；我們可以不同的部門進行不同的應用（例如數據挖掘、數據分析、報表展示和查詢等等）；而快速提取是我們對于數據倉庫的基本需求，所以數據倉庫在設計起初就要具備快速提取的功能。而技術實現呢，就是分布式。
1.5數據倉庫的主要特征
-?向主題的:傳統數據庫最大的特點就是面向應用進行組織數據，一個業務系統管理一部分企業數據，多個業務系統之間呢是相互分離的，而數據倉庫則是面向主題的。我們可以通過從上圖中的源數據那部分看到，它把多個業務的數據來整合，所以是面向主題的。
實例
-集成的:集成是指數據倉庫中數據必須是一致的，也就是我們要通過ETL進行軟碼編輯。數據倉庫的數據是從原有的、分散多個數據倉庫、數據文件、用戶日志中抽取出來的，那數據來源上可能既有內部數據，又有外部數據。
數據倉庫中的數據是為分析而服務的，而分析呢又需要多種、廣泛的不同數據源、數據，以便進行比較、鑒別。因此數據倉庫中的數據必須從多個數據源中獲取。那這些數據源就包括我們在上篇博客介紹過的內部數據、外部數據、文件系統以及網上的其他數據等。這些是通過數據集成而形成數據倉庫的數據，所以它是集成的。
-非易失：保存的數據是一系列歷史快照，不允許被修改，只允許通過工具進行查詢、分析。
-時變性：數倉會定期接收、集成新的數據，從而反映出數據的最新變化。
1.6數據倉庫 VS 數據庫
? 數據庫面向事務設計，屬于OLTP（在線事務處理）系統，主要操作是隨機讀寫；在設計時盡 量避免冗余，常采用符合范式規范來設計 。
? 數據倉庫是面向主題設計的，屬于OLAP（在線分析處理）系統，主要操作是批量讀寫；關 注數據整合，以及分析、處理性能；會有意引入冗余，采用反范式方式設計。
1.7 技術的實現
傳統數據倉庫:
? 由關系型數據庫組成MPP（大規模并行處理）集群
問題：擴展性有限，熱點問題
大數據數據倉庫：
? 利用大數據天然的擴展性，完成海量數據的存放
? 將SQL轉換為大數據計算引擎任務，完成數據分析
問題：SQL支持率，事務支持
1.8 MPP & 分布式架構
MPP架構?
? 傳統數倉中常見的技術架構，將單機數據庫節點組成集群，提升整體處理性能
? 節點間為非共享架構（Share Nothing），每個節點都有獨立的磁盤存儲系統和內存系統
? 每臺數據節點通過專用網絡或者商業通用網絡互相連接，彼此協同計算，作為整體提供服務
? 設計上優先考慮C(一致性)，其次考慮 A(可用性)，盡量做好P(分區容錯性)
架構優點
? 運算方式精細，延遲低、吞吐低
? 適合中等規模的結構化數據處理
架構缺點
? 存儲位置不透明，通過Hash確定數據所在的物理節點，查詢任務在所有節點均會執行
? 并行計算時，單節點瓶頸會成為整個系統短板，容錯性差
? 分布式事務的實現會導致擴展性降低
分布式架構
? 大數據中常見的技術架構，也稱為Hadoop架構/批處理架構
? 各節點實現場地自治（可以單獨運行局部應用），數據在集群中全局透明共享?
? 每臺節點通過局域網或廣域網相連，節點間的通信開銷較大，在運算時致力減少數據移動
? 優先考慮的是P（分區容錯性），然后是A（可用性），最后再考慮C（一致性）
架構特點
? 解決了單點故障問題，會將出錯的任務調度到其他副本節點
? 運算方式粗獷，吞吐量大
? 擴展性極強，適合處理非結構化、半結構化數據?
? 需要將中間結果進行存儲，且數據移動開銷較大
MPP + 分布式架構
? 數據存儲采用分布式架構中的公共存儲，提高分區容錯性?
? 上層架構采用MPP，減少運算延遲
第二章：數據倉庫的架構
2.1 架構圖
數據倉庫各層說明：
一、數據加載層：ETL（Extract-Transform-Load）
二、數據運營層：ODS（Operational Data Store）
三、數據倉庫層：DW（Data Warehouse）
1. 數據明細層：DWD（Data Warehouse Detail）
2. 數據中間層：DWM（Data WareHouse Middle）
3. 數據服務層：DWS（Data WareHouse Service）
四、數據應用層：APP（Application）
五、維表層：DIM（Dimension）
分層好處：
清晰數據結構：每一個數據分層都有它的作用域和職責，在使用表的時候能更方便地定位和理解
減少重復開發：規范數據分層，開發一些通用的中間層數據，能夠減少極大的重復計算
統一數據口徑：通過數據分層，提供統一的數據出口，統一對外輸出的數據口徑
復雜問題簡單化：將復雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。當數據出現問題之后，不用修復所有的數據，只需要從有問題的步驟開始修復。
屏蔽原始數據的異常：不必改一次業務就需要重新接入數據。
2.2 ETL流程
ETL -- Extract-Transform-Load
? 將數據從來源端經過抽取（extract）、交互轉換（transform）、加載（load）至目的端的過程
? 構建數據倉庫的重要一環，用戶從數據源抽取出所需的數據，經過數據清洗，最終按照預先定義好的數據倉庫模型，將數據加載到數據倉庫中去
? ETL規則的設計和實施約占整個數據倉庫搭建工作量60%～80%
數據抽取（Extraction）?
? 抽取的數據源可以分為結構化數據、非結構化數據、半結構化數據?
? 結構化數據一般采用JDBC、數據庫日志方式，非/半結構化數據會監聽文件變動
抽取方式
? 數據抽取方式有全量同步、增量同步兩種方式
? 全量同步會將全部數據進行抽取，一般用于初始化數據裝載
? 增量同步方式會檢測數據的變動，抽取發生變動的數據，一般用于數據更新
數據轉換（Transformation）
? 數據轉換要經歷數據清洗和轉換兩個階段
－數據清洗主要是對出現的重復、二義性、不完整、違反業務或邏輯規則等問題的數據進行統一的處理
－數據轉換主要是對數據進行標準化處理，進行字段、數據類型、數據定義的轉換
? 結構化數據在轉換過程中的邏輯較為簡單，非/半結構化數據的轉換會較為復雜
數據加載（Loading）
? 將最后處理完的數據導入到對應的目標源里
2.3 數據積存
操作數據層（ODS）?
? 數據與原業務數據保持一致，可以增加字段用來進行數據管理?
? 存儲的歷史數據是只讀的，提供業務系統查詢使用
? 業務系統對歷史數據完成修改后，將update_type字段更新為UPDATE，追加回ODS中
在離線數倉中，業務數據定期通過ETL流程導入到ODS中，導入方式有全量、增量兩種
－全量導入：數據第一次導入時，選擇此種方式?
－增量導入：數據非第一次導入，每次只需要導入新增、更改的數據，建議使用外連接&全覆蓋方式
2.4 數據分析
數據明細層（DWD）
? 數據明細層對ODS層的數據進行清洗、標準化、維度退化（時間、分類、地域）
? 數據仍然滿足3NF模型，為分析運算做準備
數據匯總層（DWS）
? 數據匯總層的數據對數據明細層的數據，按照分析主題進行計算匯總，存放便于分析的寬表?
? 存儲模型并非3NF，而是注重數據聚合，復雜查詢、處理性能更優的數倉模型，如維度模型
數據應用層（ADS）?
? 數據應用層也被稱為數據集市
? 存儲數據分析結果，為不同業務場景提供接口，減輕數據倉庫的負擔 －數據倉庫擅長數據分析，直接開放業務查詢接口，會加重其負擔
3.1 基本概念
OLTP系統建模方法
? OLTP（在線事務處理）系統中，主要操作是隨機讀寫?
? 為了保證數據一致性、減少冗余，常使用關系模型?
? 在關系模型中，使用三范式規則來減少冗余
OLAP（在線聯機分析）
? OLAP系統，主要操作是復雜分析查詢；關注數據整合，以及分析、處理性能?
? OLAP根據數據存儲的方式不同，又分為ROLAP、MOLAP、HOLAP
OLAP系統分類
OLAP系統分類
? ROLAP（Relation OLAP，關系型 OLAP）：使用關系模型構建，存儲系統一般為RDBMS
? MOLAP（Multidimensional OLAP，多維型 OLAP）：預先聚合計算，使用多維數組的形式保存數據結果，加快查詢分析時間
? HOLAP（Hybrid OLAP，混合架構的 OLAP）：ROLAP 和 MOLAP 兩者的集成；如低層是關系型的，高層是多維矩陣型的；查詢效率高于ROLAP，低于MOLAP
3.2 ROLAP
ROLAP系統建模方法
? 典型的數據倉庫建模方法有ER模型、維度模型、Data Value、Anchor
維度模型
? 維度模型中，表被分為維度表、事實表，維度是對事實的一種組織。
? 維度一般包含分類、時間、地域等
維度模型
? 維度模型分為星型模型、雪花模型、星座模型?
? 維度模型建立后，方便對數據進行多維分析
星型模型
? 標準的星型模型，維度只有一層，分析性能最優
雪花模型
? 雪花模型具有多層維度，比較接近三范式設計，較為靈活
星座模型
? 星座模型基于多個事實表，事實表之間會共享一些維度表?
? 是大型數據倉庫中的常態，是業務增長的結果，與模型設計無關
什么是寬表模型？
? 寬表模型是維度模型的衍生，適合join性能不佳的數據倉庫產品?
? 寬表模型將維度冗余到事實表中，形成寬表，以此減少join操作
???????????????
3.3 MOLAP
MOLAP系統建模方法
? MOLAP將數據進行預結算，并將聚合結果存儲到CUBE模型中
? CUBE模型以多維數組的形式，物化到存儲系統中，加快后續的查詢
? 生成CUBE需要大量的時間、空間，維度預處理可能會導致數據膨脹
3.4 多維分析
OLAP多維分析
? OLAP主要操作是復雜查詢，可以多表關聯，使用COUNT、SUM、AVG等聚合函數
? OLAP對復雜查詢操作做了直觀的定義，包括鉆取、切片、切塊、旋轉
? 鉆取
? 對維度不同層次的分析，通過改變維度的層次來變換分析的粒度?
? 鉆取包括上卷（Roll-up）、下鉆(Drill-down)
? 上卷（Roll-up），也稱為向上鉆取，指從低層次到高層次的切換
? 下鉆(Drill-down)，指從高層次到低層次的切換
? 切片(Slice)、切塊(Dice)
? 選擇某個維度進行分割稱為切片?
? 按照多維進行的切片稱為切塊
? 旋轉(Pivot)
? 對維度方向的互換，類似于交換坐標軸上卷（Roll-up）
4.1 表的分類
維度建模中的表類型
? 事實表
? 維度表
? 事務事實表
? 周期快照事實表
? 累積快照事實表
事實表
? 一般是指一個現實存在的業務對象，比如用戶，商品，商家，銷售員等等
維度表?
? 一般是指對應一些業務狀態，代碼的解釋表。也可以稱之為碼表?
? 通常使用維度對事實表中的數據進行統計、聚合運算
事務事實表?
? 隨著業務不斷產生的數據，一旦產生不會再變化，如交易流水、操作日志、出庫入庫記錄
周期快照事實表?
? 隨著業務周期型的推進而變化，完成間隔周期內的度量統計，如年、季度累計
? 使用周期+狀態度量的組合，如年累計訂單數，年是周期，訂單總數是量度
累積快照事實表?
? 記錄不確定周期的度量統計，完全覆蓋一個事實的生命周期，如訂單狀態表
? 通常有多個時間字段，用于記錄生命周期中的關鍵時間點
? 只有一條記錄，針對此記錄不斷更新
實現方式一
? 使用日期分區表，全量數據記錄，每天的分區存儲昨天全量數據與當天增量數據合并的結果
? 數據量大會導致全量表膨脹，存儲大量永遠不更新的冷數據，對性能影響較大
? 適用于數據量少的情況
實現方式二
? 使用日期分區表，推測數據最長生命周期，存儲周期內數據；周期外的冷數據存儲到歸檔表?
? 需要保留多天的分區數據，存儲消耗依然很大
實現方式三
? 使用日期分區表，以業務實體的結束時間分區，每天的分區存放當天結束的數據；設計一個時間非常大的分區，如9999-12-31，存放截止當前未結束的數據
? 已結束的數據存放到相應分區，存放未結束數據的分區，數據量也不會很大，ETL性能好
? 無存儲浪費，數據全局唯一
? 業務系統可能無法標識業務實體的結束時間，可以使用其它相關業務系統的結束標志作為此業務系統的結束，也可以使用最長生命周期時間或前端系統的數據歸檔時間
拉鏈表?
? 拉鏈表記錄每條信息的生命周期，用于保留數據的所有歷史（變更）狀態?
? 拉鏈表將表數據的隨機修改方式，變為順序追加
4.2 ETL策略
全量同步
? 數據初始化裝載一定使用全量同步的方式
? 因為業務、技術原因，使用全量同步的方式做周期數據更新，直接覆蓋原有數據即可
增量同步
? 傳統數據整合方案中，大多采用merge方式（update+insert）
? 主流大數據平臺不支持update操作，可采用全外連接+數據全量覆蓋方式
－如果擔心數據更新出錯，可以采用分區方式，每天保存最新的全量版本，保留較短周期
????????????????????
4.3 任務調度
為什么需要任務調度？
? 解決任務單元間的依賴關系?
? 自動化完成任務的定時執行?
常見任務類型
? Shell
? Java程序
? Mapreduce程序
? SQL腳本
常見調度工具
? Azkaban
? Oozie
第四章：大數據名詞科普
4.1數據集市
數據倉庫也稱為中央或企業數據倉庫。因此，在某些情況下，數據倉庫的來源將是多個，而數據集市是數據倉庫的一個子集。
有兩種類型的數據集市——獨立型和從屬型。獨立型數據集市直接從操作型環境獲取數據。從屬型數據集市從企業級數據倉庫獲取數據。從長遠的角度看，從屬型數據集市在體系結構上比獨立型數據集市更穩定。
4.2數據孤島
數據孤島（通常稱為信息孤島）是只有一組人可以輕松訪問的數據集。這意味著其他人很難獲得這些信息，或者更糟糕的是，他們根本無法訪問它。
4.3數據湖
數據湖（Data Lake）是一個以原始格式存儲數據的存儲庫或系統，它按原樣存儲數據，而無需事先對數據進行結構化處理。一個數據湖可以存儲結構化數據（如關系型數據庫中的表），半結構化數據（如CSV、日志、XML、JSON），非結構化數據（如電子郵件、文檔、PDF）和二進制數據（如圖形、音頻、視頻）。
數據湖是一個存儲庫，它允許存儲大量的原始數據，也就是說，沒有按照特定的模式進行準備、處理或操作的數據。
數據湖的一個關鍵特征是不會拒絕任何數據，這意味著結構化格式和非結構化數據格式都可以存儲。由于數據湖中的數據在從源獲取時不受數據結構的約束，因此在需要時應用“讀取”模式來促進數據分析。
數據湖特征:
1.?容量大 2.格式多 3.處理速度快 4.體系結構
未來的發展趨勢可能是湖倉一體。
4.4數據中臺
各種信息系統大多是獨立建設的，無法做到信息的互聯互通，導致形成了多個數據孤島。數據中臺的作用是融合新老信息，整合各個孤島上的信息，快速形成數據服務能力，為企業經營決策、精細化運營提供支持。
4.5寬表和窄表
寬表：從字面意義上講就是字段比較多的數據庫表。通常是指業務主題相關的指標、維度、屬性關聯在一起的一張數據庫表。由于把不同的內容都放在同一張表存儲，寬表已經不符合三范式的模型設計規范，隨之帶來的主要壞處就是數據的大量冗余，與之相對應的好處就是查詢性能的提高與便捷。這種寬表的設計廣泛應用于數據挖掘模型訓練前的數據準備，通過把相關字段放在同一張表中，可以大大提高數據挖掘模型訓練過程中迭代計算時的效率問題。
窄表：嚴格按照數據庫設計三范式。盡量減少數據冗余，但是缺點是修改一個數據可能需要修改多張表。
4.6數據倉庫元數據
元數據（Metadata），又稱中介數據、中繼數據，為描述數據的數據（data about data），主要是描述數據屬性（property）的信息，用來支持如指示存儲位置、歷史數據、資源查找、文件記錄等功能。
舉幾個簡單例子:
如果一本書是一個“數據"，那么它的書名、封面、出版社、作者、總頁碼就是它的“元數據”。
如果一個電影是一個“數據”，那么它的總時長、制作人、總導演、演員列表就是它的“元數據”。
如果數據庫中某個表是一個”數據”，那么它的列名、列類型、列長度、表注釋就是它的"元數據"。
4.7數據治理
數據治理（Data Governance）是組織中涉及數據使用的一整套管理行為。由企業數據治理部門發起并推行，關于如何制定和實施針對整個企業內部數據的商業應用和技術管理的一系列政策和流程。
數據的質量直接影響著數據的價值，并且直接影響著數據分析的結果以及我們以此做出的決策的質量。我們常說，用數據說話，用數據支撐決策管理，但低質量的數據、甚至存在錯誤的數據，必然會"說假話"！！！?數據治理即提高數據的質量，發揮數據資產價值。
4.8 ETL流程
ETL是英文Extract-Transform-Load 的縮寫，用來描述將數據從來源端經過抽取（extract）、轉換（transform）、加載（load）至目的端的過程。常見于數據倉庫開發中將數據由業務系統歸集到數據倉庫（DW）或者數據集市的過程。在ETL三個部分中，花費時間最長的是“T”(Transform，清洗、轉換)的部分，一般情況下這部分工作量是整個ETL的2/3。
總結
以上是生活随笔為你收集整理的数据仓库介绍（DW）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 王文京是一个例子
- 下一篇： vue中vue-touch 的使用