?博客主頁： https://blog.csdn.net/m0_63815035?type=blog

💗《博客內容》：大數據、Java、測試開發、Python、Android、Go、Node、Android前端小程序等相關領域知識
📢博客專欄： https://blog.csdn.net/m0_63815035/category_11954877.html
📢歡迎點贊 👍 收藏 ?留言 📝
📢本文為學習筆記資料，如有侵權，請聯系我刪除，疏漏之處還請指正🙉
📢大廈之成，非一木之材也；大海之闊，非一流之歸也?

一、在線事務處理（OLTP）和在線分析處理（OLAP）的區別【重點】

OLTP與OLAP概述

1.OLTP（在線事務處理）和OLAP（在線分析處理）是數據處理方式的兩種主要類型。

2.OLTP強調事務的ACID特性（原子性、一致性、隔離性、持久性）和實時響應。

3.OLAP側重于數據分析，不強調事務性操作，查詢速度較慢。

OLAP的特點

1.OLAP查詢通常比較慢，因為需要處理海量數據。

2.OLAP查詢結果常用于決策支持，如報表和數據分析。

3.OLAP系統通常存儲歷史數據，并對其進行規范化處理。

OLAP與OLTP的比較

1.OLAP適合進行數據分析，OLTP適合處理實時事務。

2.OLAP查詢速度較慢，OLTP查詢速度快。

3.OLAP存儲歷史數據，OLTP處理當前數據。

ETL過程

1.ETL（提取、轉換、加載）是將數據從數據源提取并轉換后加載到數據倉庫的過程。

2.ETL過程包括數據清洗、整理等操作。

3.ETL后的數據用于OLAP分析

報表與即席查詢

1.報表是數據庫中的表，用于展示統計指標結果。

2.即席查詢允許用戶通過頁面請求快速獲取數據倉庫中的信息。

3.即席查詢通常需要借助大數據組件實現快速查詢。

MOLAP與ROLAP

1.MOLAP（多維查詢）通過預計算和構建立方體來提高查詢速度。

2.ROLAP（請求時計算）采用MPP分布式架構進行查詢。

3.HOLAP（混合查詢）結合了MOLAP和ROLAP的特點。

OLTP和OLAP的對比總結

二、數倉的定義【了解】

數據倉庫的必要性

1.沒有數據倉庫的情況下，直接從業務庫中獲取數據進行分析會面臨諸多問題。

2.數據倉庫可以統一存儲、計算和展示多個異構數據源，緩解資源競爭問題。

3.數據倉庫提供歷史數據，支持環比和同比分析，同時整合多個語言系統的數據。

數據倉庫的技術組件

1.數據倉庫不是某一種技術，而是由一系列大數據軟件組件組合而成。

2.數據倉庫包括數據抽取、清洗、計算和報表展示等技術。

3.常見的組件包括Flume、DataX、Hadoop、Hive、Spark等。

數據倉庫的架構和組件

1.數據倉庫的底層架構包括Hadoop和HDFS，提供高可用的存儲和計算能力。

2.Hadoop的MapReduce和Hive的SQL分析引擎用于數據處理和分析。

3.Spark基于內存計算，提供更快的處理速度。

4.數據倉庫還包括調度、監控、數據治理和權限控制等組件。

數據倉庫的優缺點

1.數據倉庫的優點包括統一存儲、計算和展示，支持歷史數據分析和分布式計算。

2.數據倉庫的缺點包括搭建和維護的復雜性，以及需要專業的技術和團隊來支持。

三、數倉與數據庫的區別

1.數據倉庫不是大型數據庫，也不是用來替代數據庫的。

2.數據庫面向事物，數據倉庫面向主題。

3.數據庫存儲業務數據，數據倉庫存儲歷史數據。

4.數據庫設計盡量避免冗余，數據倉庫會刻意引入冗余。

5.數據庫針對某一業務應用進行設計，數據倉庫確定業務線后再確定維度。

6.數據庫是為了捕獲數據，數據倉庫是為了分析數據。

數倉發展史概述

1.數倉發展史分為三個時代：1.0時代（傳統數倉）、2.0時代（Hadoop生態）、3.0時代（云端數倉）。

傳統數倉1.0時代(傳統數倉使用關系型數據庫搭建數據倉庫。 )

1.概念階段（1978-1988年）：麻省理工學院研究員意識到業務系統與分析型系統的區別，提出采用完全不同的架構和設計。 2.萌芽階段（20世紀80年代中后期）：EDC公司定義了TI2規范，包括數據獲取、訪問目錄和用戶服務。 3.集成階段（1988年）：IBM公司在TI2規范基礎上定義了新的規范，提出了信息倉庫的概念，并定義了85種組件。 4.確立階段（1991年）：比爾恩門撰寫《構建數據倉庫》一書，提出了數據倉庫的指導性意見，包括面向主題、集成歷史、包含歷史、穩定和面向決策等概念。 5.數據集市階段（1996年）：金伯爾提出數據集市的概念，自下而上地構建數據倉庫，采用維度建模。 6.合并階段（1998年）：比爾恩門提出CRF企業信息工廠，將數據集市包含進來，握手言和。 7.傳統數倉階段（2003年以前）：傳統數倉主要使用關系型數據庫，特別是支持OLAP的大規模數據庫

數倉2.0時代(時代引入Hadoop，解決了大數據分析的需求。)

1.Hadoop的誕生（2006年）：道格卡廷基于谷歌的分布式存儲和計算技術，開發了Hadoop并開源。 2.Hadoop的普及（2008年以后）：Hadoop解決了大數據分析的需求，但計算速度較慢。 3.SQL on Hadoop（2012年以后）：Facebook開發了Hive，允許在Hadoop上編寫SQL，降低了使用門檻。 4.MPP時代（2014年以后）：基于內存的OLAP分析時代到來，滿足了快速分析大數據的需求。

數倉3.0時代(時代通過上云，減少了環境搭建和運維維護的人力。)

1.云端數倉（2016年以后）：通過上云，減少了環境搭建和運維維護的人力，提高了開發效率。 2.阿里云、百度云、華為云和亞馬遜云等提供了完整的云端數倉平臺，包括監控、告警、原數據管理和權限管理等功能。

四、數據模型建設【了解】

數據模型建設是數據倉庫理論的一部分，主要介紹數據模型建設的基本概念和流程。

數據建模的定義和重要性

1.數據建模是數據組織和存儲的方式，強調從業務數據存取和使用的角度合理存儲數據。

2.數據模型需要體現業務，用于存儲和獲取數據，并且要合理設計，避免資源浪費。

3.數據模型是數據分析中的重要概念，用于抽象和描述數據，幫助理解數據中的規律和關系。

模型的定義和特征

1.模型是現實世界中某個對象的特征模擬。

2.例子包括地圖、建筑設計沙盤和航模飛機，它們都模擬了現實世界的某些特征。

3.數據模型也是對現實世界中某些對象的特征進行抽象，方便后續操作。

數據模型的重要性

1.數據模型是數據庫系統的核心和基礎，反映現實世界中的對象和概念。

2.數據模型的真實性、可理解性和實現性是其三要素。

3.真實性要求模型完全模擬現實世界；可理解性要求模型構建細致且具體，方便溝通和理解；實現性要求模型具有具體的可執行落地方案。

數據模型的作用（為什么需要數據模型？）

1.數據模型可以更好地組織存儲數據，在性能、成本、效率和數據質量之間找到平衡點。

2.數據模型解決業務梳理、改進業務流程、建立全方位數據視角、消滅信息孤島等問題。

3.數據模型幫助解決業務的變動和數據倉庫的靈活性問題，加快數據倉庫系統的建設速度

數據模型建設流程

1.通用數據模型建設包括概念數據模型、邏輯數據模型和物理數據模型三個層次。

2.概念數據模型類似于建筑規劃圖，確定實體和關系；邏輯數據模型類似于建筑設計圖，豐富實體屬性和關系；物理數據模型類似于施工方案，轉換具體類型字段和約束。

3.數據倉庫模型建設包括業務概念、邏輯物理四個步驟。業務建模確定業務主線和主題；領域建模確定實體；邏輯建模完善實體屬性和關系；物理建模落地執行具體方案。

數據模型方法論

1.數據模型方法論包括ER建模和維度建模，重點介紹這兩種方法論。

2.ER建模在OLTP領域使用較多，強調實體關系；維度建模在數據倉庫構建中應用廣泛，強調事實表和維度表。

五、關系數據模型（E-R模型建模）【重點】

ER建模概述

1.ER建模用于OLTP事務性屬性，由比爾·恩文提出，但因專業性要求高導致大面積失敗。

2.維度建模由King BO推出，強調適當的冗余，解決數據膨脹和查詢慢的問題。

ER模型的基本概念

1.ER模型由美籍華裔計算機科學家陳平山提出，強調實體、屬性和關系。

2.實體用長方形表示，屬性用橢圓形表示，關系用菱形表示。

3.關系可以具有自己的屬性，用于連接實體

ER模型的設計步驟

1.抽象出實體，找出實體之間的關系。

2.完善實體的屬性。

3.根據ER圖轉化成數據庫表。

三范式及其應用

1.三范式包括第一范式、第二范式和第三范式，是數據庫表設計的重要規范。 2.第一范式：列不可再分。

3.第二范式：建立在第一范式基礎上，要求有主鍵，非主鍵屬性依賴主鍵。

4.第三范式：建立在第二范式基礎上，要求屬性不依賴主鍵外的其他屬性。

5.三范式解決了數據冗余和查詢性能問題。

第零范式及其應用

1.第零范式允許表中某列存儲集合或對象，減少數據冗余。

2.適用于大數據領域，需要數據庫支持存儲對象或集合。

逆規范化及其應用

1.逆規范化通過增加冗余數據減少關聯查詢，提高查詢性能。

2.適用于大數據和數倉領域，通過適當的冗余提升查詢速度。

六、維度數據建模（維度建模）【重點】

維度建模概述

1.維度建模是數據倉庫構建過程中采用的一種重要方法，由kimball大師提出。

2.維度建模認為在數據倉庫構建中不應使用ER模型，以避免不必要的冗余并提升查詢速度。

數據集市與數據倉庫

1.數據集市是數據倉庫的組成部分，通過逐步構建數據集市來逐步完善數據倉庫。

2.維度建模中包含事實表和維度表，事實表用于存儲度量值，維度表用于描述觀察數據的角度。

事實表與維度表

1.事實表用于存儲度量值，通常包含大量數字數據，并與其他維度表通過外鍵關聯。 2.維度表用于描述觀察數據的角度，如時間、客戶、產品等，包含主鍵和外鍵。

度量的概念

1.度量值是事實表中的可度量值，通常為數字，但也可能為其他類型。

2.度量值用于計算如數量和金額等，是事實表的核心內容。

指標的概念

原子指標：

派生指標：

衍生指標

七、維度表【重點】

基本概念

1.維度表是維度建模的基礎和靈魂，用于描述事實表中各個維度屬性的信息。

2.維度表包含維度的主鍵和維度的屬性，用于快速準確地過濾和統計事實表中的數據。

3.維度表可以幫助用戶進行鉆取、過濾和統計事實表中的數據，方便深入分析理解數據。

維度表的來源和設計方法

1.維度表的設計包括背景調查、需求分析、數據域劃分、業務系統表結構分析等步驟。

2.通過與業務人員的交流和業務系統的表結構分析，可以發現維度并進行落地建表。

3.維度表的主鍵設計有自然鍵和代理鍵兩種方式，選擇主鍵需考慮維表的修改需求和歷史數據保留策略。

維度表的屬性和作用

1.維度表的屬性是查詢約束條件、分組和報表標簽生成的基本來源，是數據應用性的關鍵。

2.維度表的屬性用于查詢約束、分類匯總、排序等操作。

3.維度表的設計應豐富維度屬性，以便于后期查詢約束、匯總和排序。

維度表的主鍵設計

1.維度表的主鍵有自然鍵和代理鍵兩種方式。

2.自然鍵使用維度的自然唯一標識，如身份證號，優點是有上下文關系，缺點是占用空間大。

3.代理鍵是系統生成的主鍵，優點是簡單節省空間，缺點是沒有上下文關系。 4.選擇主鍵需考慮維表的修改需求和歷史數據保留策略。

維度表的設計總結

1.根據具體情況選擇自然鍵或代理鍵作為維度表的主鍵。

2.豐富維度表的屬性，便于查詢約束、分類匯總和排序。

八、維度設計方法概述

1.維度設計方法主要分為四大步，參考自阿里巴巴和美團的實踐。

2.這些定義來自權威的大廠實踐，具有較高的參考價值。

維度設計過程

1.維度設計過程就是確定維度屬性的過程。

2.選擇維度或新建維度，確定維度表，并選擇合適的主維表。

3.完善維度的屬性，通過業務系統確定主維表和相關維表。

選擇維度或新建維度

1.選擇維度或新建維度是一個抽象的概念，涉及確定范圍較大的維度。

2.在企業級數據倉庫中，必須保證維度的唯一性。

3.以淘寶商品維度為例，商品維度表下有類目屬性。

確定主維表

1.主維表一般是ODS表，與前臺商品中心系統同步的商品表。

2.主維表的確定涉及業務系統的同步和數據倉庫的分層。

3.通過與業務人員交談或查詢業務庫，可以發現維度和維度屬性。

確定相關維表

1.確定相關維表，如類目、SPU、賣家店鋪等，與主維表相關聯的維度。

2.通過查詢分析主維表的關聯關系，確定相關維表。

確定維度屬性

1.確定維度屬性，將主維表和相關維表中的屬性抽取到一張表中。

2.考慮維度表的拆分和合并，以生成豐富的維度。

3.以淘寶商品維度為例，從主維表和類目、SPU、賣家店鋪等表中抽取屬性，生成新的商品維度表。

九、維度統一&維度拆分&維度設計原則

維度統一

1.維度統一的目的：將來源于多個系統的數據維度進行統一，確保表名字段名的一致性。

2.公共編碼的統一：如性別編碼（男：1，女：0）。

3.業務含義相同的表合并：將業務含義相同的表合并到一張表中，或采用主從表的方式。

維度拆分

1.維度拆分的目的：優化查詢性能，將不常用的維度數據分離，減少join操作。

2.水平拆分：將維度表拆分為子表，通過主鍵關聯。

3.垂直拆分：將維度表的屬性拆分為獨立的表，事實表需要關聯多個維度表。

維度設計原則

1.生成豐富的維度屬性：盡可能多的生成維度屬性，提供豐富的觀測數據角度。

2.給出富有意義的文字性描述：避免數字編碼，采用文字描述，減少數據冗余。

3.區分數值型屬性和事實：區分維度屬性和度量值，確保數據使用的準確性。

4.沉淀通用維度屬性：將通用的維度屬性抽取出來，提高下游使用的便利性。

5.退化維度：適當退化維度，減少join操作，提高查詢效率。

6.緩慢變化維：采用插入新行的方式處理維度變化，保留歷史數據。

十、事實表

事實表的定義和特性

1.事實表定義：記錄現實世界中發生的真實事件，反映業務的真實情況。

2.事實表特性：具有真實性，記錄現實中的操作和度量值。

3.度量值：未來用于分析的數據值，如訂單金額、商品數量。

4.事實表通過維度進行分析：通過不同的維度（如時間、地區、商品等）對度量值進行分組和匯總。

事實類型的分類

1.可加性事實：可以與任意維度進行匯總，結果有意義。

2.半可加性事實：只能按特定維度匯總，如庫存。

3.不可加性事實：通過計算得出，如優惠率。

事實表在ER建模中的角色

1.事實表包含與業務過程相關的維度引用和業務過程度量。

2.維度表：觀察數據的角度，不包含度量值。

3.事實表總結：包含與業務過程相關的維度引用和業務過程的度量值。

事實表的修改和歷史變化

1.事實表一般不修改，以反映歷史變化。

2.拉鏈表：一種節省空間的技術，通過兩個時間鍵反映歷史變化。

3.事實表隨著業務發展不斷產生新的數據，但一般不再修改舊數據。

事實表的設計原則

1.原子性：事實表中的數據應是最小不可分割的單位。

2.可累加性：度量值應支持累加操作。

3.時間戳：記錄數據的時間信息，以反映歷史變化。

【設計原則】※

1.盡可能包含所有與業務相關過程的事實。

2.只選擇與業務過程相關的事實。

3.分解不可加事實為可加組件。

4.在選擇維度和事實之前，先聲明力度。

5.在同一個事實表中，不能有多種不同力度的事實。

6.事實的單位要保持一致。

7.對事實的null值要處理。

8.使用退化維度提高事實表的應用性。

事實表設計方法

1.選擇業務過程，確定事實表的類型。

2.聲明力度，確定事實表的存儲方式。

3.確定維度，觀測數據的角度。

4.確定事實，選擇度量值。

5.融余，將常用維度退回到事實表中。

十一、事實表的分類

1.事實表分為事物事實表、周期快照事實表和累積快照事實表。

2.事物事實表：記錄用戶單次操作事件，力度細，稀疏。

3.周期快照事實表：按固定時間段匯總數據，稠密。

4.累積快照事實表：記錄生命周期事件，周期不固定。

事實表與維度表的數據來源

1.事實表和維度表的數據來源于公司的業務數據庫。

2.業務數據庫記錄用戶操作，如增刪查改行為。

3.數據倉庫通過ETL過程復制業務數據庫的數據。

4.ETL過程包括數據抽取、轉換和加載。

數據抽取方式

1.數據抽取方式有全量和增量。

2.全量抽取：復制表中的所有信息。

3.增量抽取：只復制新增的數據。

4.抽取頻率通常為每天。

事物事實表

1.事物事實表力度細，每行記錄為用戶的一次操作事件。

2.事物事實表是稀疏的，可能沒有數據。

3.常見于需要高精度數據的情況。

事務事實表概述

1.事務事實表是數據倉庫中最常見的表類型，用于存儲業務過程中的原子操作事件。

2.事務事實表保留原始數據，反映歷史操作，主要用于數據分析。

3.事務事實表記錄業務對象相關的事務性數據，如交易流水、操作日志等。

事務事實表設計流程

1.選擇業務過程，如下單、支付、發貨、收貨。

2.確定力度，如下單為子訂單，支付為子訂單，發貨為物流單。

3.確定維度，如買家維度、賣家維度、商品類目、地區維度等。

4.確定事實，如下單金額、支付金額、折扣紅包等。

5.淘寶設計融余維度，提高查詢性能。

訂單事務事實表

1.訂單事務事實表存儲每天所有用戶在下應用里下的訂單，按天增量導入數據倉庫。 2.每條記錄表示一個細粒度的原子操作事件，記錄訂單的詳細信息。 3.為了提高查詢性能，通常設計訂單周期快照實時表。

單事務事實表和多事務事實表

1.單事務事實表：每個業務一個事實表，如下單事實表、支付事實表。

2.多事務事實表：多個業務放到一個事實表中，使用不同的事實字段或相同的字段但用不同的標簽。

3.多事務事實表的缺點是存在大量的空值。

事務事實表的不足之處

1.存量型指標計算：如余額、庫存、累計交易額，計算成本高，查詢時間長。

2.多事物關聯統計計算：如統計最近30天下單到支付的時間間隔，效率低。

3.解決方案：使用周期快照實時表和累積快照實時表。

周期快照事實表

1.周期快照事實表按固定時間段（如天、周、月）匯總數據。

2.每行記錄一個周期的數據，稠密。

3.常見于需要匯總數據的情況。

周期快照事實表概述

1.周期快照事實表定義：按照指定的周期聚集事務事實表的記錄進行插入。

2.常見用途：記錄實體的度量值，不需要聚集長期事務歷史。

3.設計建議：事務事實表與周期快照事實表成對設計。

周期快照事實表示例

1.示例：在線人數日活統計。

2.無周期快照事實表時，需每天統計事務事實表數據。

3.使用周期快照事實表，每天插入一行數據，記錄當天的日活。

周期快照事實表特點

1.記錄事實的規律性和可預見的時間間隔。

2.適用于存量性和狀態性指標。

3.存量性：如賬戶余額、商品庫存。

4.狀態性：如溫度、行駛速度。

周期快照事實表與事務事實表比較

1.事務事實表：記錄原子事務操作，數據量大。

2.周期快照事實表：按周期聚集數據，數據量較小。

3.查詢效率：周期快照事實表提高查詢速度。

周期快照事實表的聚集操作

1.聚集操作：對周期快照事實表進行再次聚集，優化數據。

2.常見聚集間隔：年、月、日。

3.注意事項：結合業務需求確定聚集間隔。

周期快照事實表的特性

1.用快照采樣狀態：按預定間隔采樣狀態度量。

2.快照力度：多維聲明，包括時間周期和度量維度。

3.密度和稀疏性：周期快照事實表稠密，事務事實表稀疏。

4.半可加性：狀態度量半可加，不能無腦匯總。

實際案例分析

1.單維和混合維：單維度表簡單，混合維度表詳細。

2.數據加工方式：從事務事實表匯總或直接從業務庫加工。

3.淘寶賣家快照表：包括自然年至今和財年至今的下單金額、買家數等。

周期快照事實表的注意事項

1.事物與快照成對設計：事務事實表和快照事實表成對設計，互相補充。

2.附加事實：通過融余設計，減少多次使用快照表。

3.周期到日期的度量：設計時考慮多種周期，如天、周、月、年等。

累積快照事實表

1.累積快照事實表記錄生命周期事件，周期不固定。

2.每行記錄一個生命周期的事件，減少空值存儲。

3.常見于需要記錄生命周期事件的情況。

今天這篇文章就到這里了，大廈之成，非一木之材也；大海之闊，非一流之歸也。感謝大家觀看本文