1、數據倉庫概述

1.1、誕生背景

（1）歷史數據積存

歷史數據使用頻率低，積壓在業務庫中，導致業務系統的性能下降;企業定期將冷數據存儲到數據倉庫中

（2）企業數據分析需要

各個部門自己建立獨立的數據抽取系統，導致數據不一致各個部門直接從業務庫抽數進行報表生成,資源浪費，權限管理風險;數據倉庫為各個部門建立了一個統一的數據視圖，各個部門的數據統一一致;

1.2、數據倉庫概念

1.2.1、數據倉庫定義

• 概念：面向主題的、繼承的、非易失的且隨時間變化的數據集合

主要用于組織積累的歷史數據，并使用分析方法(OLAP、數據分析)進行分析處理,進而輔助決策我，為管理者、企業系統提供數據支持，構建商業智能;

1.2.2、數據倉庫特點

• Ⅰ、面向主題：為數據分析提供服務，根據**主題將原始數據集合聚合在一起

范例：將業務數據庫中的一些零散的表里面的原始數據進行聚合集合成為一張用戶行為表，比如從支付流水表,商品表、用戶表，訂單表抽成一張大寬表 - 用戶行為表，然后再用戶行為表上做一系列相關分析;

• Ⅱ、集成：原始數據來源于不同數據源，要整合成最終數據，需要i經過抽取、清洗、轉換的過程

不同數據源采用不同的數據規范 Ⅰ、針對性別的編碼：系統A(男，女),系統B(1,0) Ⅱ、針對計量單位的差異：系統A(cm),系統B(英尺)

• Ⅲ、非易失：保存的是一系列歷史快照，不允許被修改，只能通過工具進行查詢、分析；

數倉保存的數據為一系列的歷史快照，每天從業務數據庫同步，故數據與業務數據庫保持一致;

• Ⅳ、數倉定期接收、集成新的數據，從而反映出數據的最新變化；

將最新的數據追加到我們系統中，然后以時間戳標記版本，修改后的數據時間戳是最新的，之前老舊的數據;

1.2.3、數據倉庫與數據庫的區別

• Ⅰ、數據庫

1、面向事務設計,屬于OLTP(在線事務處理)系統； 2、主要操作是隨機讀寫，為業務系統提供存儲服務； 3、在設計時避免冗余，常采用范式規范來設計;

• Ⅱ、數據倉庫

1、面向分析設計，屬于OLAP(在線分析處理)系統 2、主要操作是批量讀寫，存儲各個業務數據庫經過清洗后的數據; 3、采用反范式設計，有意引入冗余(避免關聯多張表，采用大寬表)，關注數據整合(count,group by等操作)，以及分析、處理性能

• 數據庫VS數據倉庫

1.3、數據倉庫技術實現

1.3.1、傳統數據倉庫

（1）由多個單機的關系型數據庫組成MMP（大規模并行處理）集群，進行數據存儲和計算

（2）數據通過提前調度分配到各個節點進行存儲，一般數據采用hash分配，每個節點存儲一部分數據；

（3）每個節點的計算/查詢任務計算出的結果也是部分結果，這些部分結果會匯總成一個準確的完整的結果進行返回；？？？

• 傳統數倉的缺點

//數據量級一旦達到某個量級，會出現以下問題：//(1)擴展性有限/*在MPP的每個節點本質上還是一個數據庫,數據庫有很精細的內存管理，在MPP架構獨立進行運算，如果需要用到數據交換，需要通過高速網絡與其他節點連接進行交換數據，高速網絡直接限制了節點上限;數據存儲的時候采用分庫分表，因為架構所限，將一張大表拆分到各個節點進行存儲，每張表存儲的數據多再將表進行拆分，但分庫分表也存在上限，粒度越細性能越差;*///(2)熱點問題/*比如：有100w行的數據，存儲的時候被拆成了10分，恰好前10w行是熱點數據，再訪問的頻率是其他數據的五倍,則這個節點是承受壓力是其他節點的五倍，這個節點容易出現宕機或超時的情況，則這個節點會成為集群的瓶頸;*//*熱點問題解決方式通過數據加鹽方式及來解決，相當于給表中的數據增加前綴，將其打亂隨機分布到各個節點中，但是數據加鹽本身就是額外操作，會帶來額外問題;*/

1.3.2、大數據數倉

• Ⅰ、大數據數倉概述

（1）分布式存儲，分布式計算，利用大數據天然擴展性，完成海量的數據存放；

（2）將SQL轉換為大數據計算引擎任務，完成數據分析；

（3）將SQL轉換為大數據計算任務引擎，完成數據分析；

• Ⅱ、數據處理方面 - 移動計算（而不是移動數據）

1、使用了移動計算，而非移動數據的架構，為了避免海量數據移動造成IO和網絡的開銷； 2、數據在哪存儲的，就將計算任務分發到那個節點上進行計算；一份數據被拆分為并存放到多個節點上，所以每個節點接收到這個計算任務是并發進行的，得到的結果是部分結果，對結果進行匯總得到最終結果

• Ⅲ、大數據數倉特點

1、分布式文件系統：將數據庫中的結構化數據看作文件進行存儲； 2、將數據文件自動拆分，拆分完之后分發到各個節點進行存儲； 3、上層數據處理的時候，采用元數據將文件還原為表結構；解決了數據熱點問題 - 可選降低 4、數據文件被存儲到分布式文件系統時，默認備份三分，數據為一致的； 5、計算任務再分發的時候可選，相同的數據被存在三個節點，則可以選擇最空閑的數據節點，將任務分發過去;

• Ⅳ、大數據數倉的缺點
  • 大數據的數據倉庫在數據少的時候計算速度比較慢，因為是完全分布式的；
  • 任務計算時，會對任務進行拆分，然后調度到各個節點，最后對結果進行合并；
  • 在數據量沒有達到一定程度時，只是人物的轉換、分發、調度、匯總整個過程就會花費大量時間；

1.4、MPP架構

1.4.1、MPP架構概述

（1）傳統數倉中常見的技術架構，將單機數據庫節點組成集群，提升整體處理性能；

（2）節點間為非共享架構（每個節點獨立存在，不關心集群整體狀態，不關心其他節點的存儲信息），每個節點都有獨立的磁盤存儲系統和內存系統；

（3）每臺數據節點通過專用網絡或商業通用網絡互相連接，彼此協同計算，為整體提供服務；

• 計算任務中，如需要使用其他節點的數據，則通過高速網絡點對點傳輸；

（4）設計上優先考慮C（一致性），其次考慮A（可用性），盡量做好P（分區容錯性）；

1.4.2、MPP架構優點

（1）運算方式精細，延遲低，吞吐低；

（2）適合中等規模的結構化數據處理；

（3）MPP致力于實現分布式事務

（4）MPP架構沒辦法單獨運行局部應用，只能作為整體進行對外服務；

1.4.3、MPP架構缺點

（1）存儲位置不透明，通過hash確定數據所在的物理節點，查詢任務在所有節點執行；

• 非共享架構導致數據存儲位置不透明，導致執行查詢任務時在所有節點執行；

（2）并行計算時，**單個節點會成為整個系統短板，**容錯性差；

• 解決方式：當這個節點運行緩慢時，將緩慢數據節點的數據通過高速網絡分發到其他節點進行處理，但是集群規模越大，單個節點發生故障的幾率越大；

（3）分布式事務的實現會導致擴展性降低

• 集群規模越大，單個節點發生故障的幾率越大；

1.5、分布式架構

（1）大數據中常見的技術架構，也成為Hadoop架構/批處理架構；

（2）各個節點實現場地自治（可單獨運行局部應用），數據在集群中全局透明共享；

• 將每個節點存儲資源拿出來共同組成一個分布式存儲文件系統，各個節點被拿走存儲資源后，剩下就是計算資源；
• 當每個任務分發到單個節點上，節點進行計算時，可訪問公共的存儲系統，找到數據在那個位置進行計算，所以可以單獨進行局部應用

（3）每臺節點通過局域網或廣域網相連，節點間的通信開銷較大，在運算時致力于減少數據移動；

（4）優先考慮的是P（分區容錯性），然后是A（可用性），最后是C（一致性）。

• 對中間結果進行存儲，且數據移動開銷會比較大

1.6、MPP+分布式架構

• 數據存儲采用分布式架構中的公共存儲，提高分區容錯性；

相當于把數據透明化

• 上層架構采用MPP，減少運算延遲

1.7、常見數據倉庫產品

//1、傳統數據倉庫 Oracle DB2 Teradata Greenplum//2、大數據數據倉庫 Hive Spark SQL HBase impala HAWQ TIDB

2、數據倉庫架構

2.1、數據倉庫架構設計

2.1.0、OLTP與大數據倉庫的關系

1、數據倉庫數據來源業務數據:來自OLTP集群，通過Sqoop落HDFS上日志數據:來自服務的日志文件 ,通過kafka落HDFS上

2.1.1、ETL - 數據抽取、清洗、轉換、加載

結構化數據：sqoop，Kettle結構化數據：直接將原系統數據抽取、加載到ODS層 非結構、半結構化數據(日志、文件)：Flume

2.1.2、ODS層 - 數據貼源層

目的：與原始數據保持一致存儲業務數據庫的數據，不進行數據修改

2.1.3、DW層 - 公共維度模型層

• Ⅰ、DWD層：數據明細層 – 滿足三范式形式
  • 明細層：存的是各種零散表，零散表與業務系統相差不多的，只不過是清洗后的業務系統的表；

DWD層：接受ODS層數據，ODS層拿的業務系統的數據將ODS層數據進行清洗、標準化，將異常數據剔除掉，做統一的編碼，字段描述，將數據統一規范后存儲到數據明細層;

• Ⅱ 、DWS層：數據匯總層 – 脫離三范式，維度建模，以寬表形式存在
  • 對DWD層的明細表進行匯總，比如將用戶行為相關的數據存進一張大表，形成用戶行為寬表；

DWS層:將DWD層進行維度建模,建立寬表形式存在

2.1.4、ADS層 - 數據應用層(數據集市層)

ADS層:保存數據分析的結果數據,使用傳統數據庫搭建

2.2、ETL流程

2.2.1、ETL概述

（1）將數據從來源端經過抽取、交互轉換、加載至目的端的過程；

構建數據倉庫的重要一環，用戶型數據源抽取所需的數據，經過數據清洗,最終按照預算定義好的數據倉庫模型,將數據加載到數據倉庫中;

（2）ETL規則的設計和實時約占整個數據倉庫搭建工作量的60%-80%；

2.2.2、數據抽取(E-JOB)

（1）數據源

• 抽取的數據源可以分為結構化數據、非結構化數據、半結構化數據;
• 結構化數據一把采用JDBC、數據庫日志方式,非/半結構化數據會監聽文件變動

抽取關系型數據庫： JDBC直連：消耗數據庫的IO，影響數據庫的運轉，一般抽取在凌晨業務量較少的；對于業務數據庫壓力很大 直接抽取數據庫的日志：直接采集預寫日志文件，需要將日志文件解析后獲取數據;對于業務數據庫壓力很小

（2）抽取方式

• 數據抽取方式有全量同步、增量同步兩種方式

全量同步:會將全部數據進行抽取,一般用于初始化裝載; 增量同步:檢測數據的變動,抽取發生變動的數據,一般用于數據更新;

2.2.3、數據清洗

• 數據清洗要經歷數據清洗和轉換兩個階段
  • 結構化數據抽取與源系統保持一致,數據清洗任務量很小,基本只要去重即可;
  • 數據清洗和轉換主要集中在非結構化、半結構化數據;

①數據清洗:主要是對出現的重復、二義性、不完整、違反業務或邏輯規則等問題進行統一處理數據清洗在結構化數據很少,否則業務數據庫就會產生極大的風險;數據清洗主要是對非結構化,半結構化數據進行清洗; ②數據轉換:主要是對數據進行標準化處理,進行字段、數據類型、數據定義的轉換

2.2.4、數據加載

• 將最后處理完的數據導入到對應的目標源中;

2.2.5、ETL工具

// 1、結構化數據ETL工具 Sqoop通過JDBC連接結構化數據庫進行數據抽取,使用并發處理方式,批量導入大數據的數據倉庫里面;生產中使用1.x版本,2.0版本功能完善導致性能下降; Kettle Datastage Information Kafkakafka是一個消息隊列,提供ETL功能,支持ETL操作,將數據抽取出來之后存在消息隊列里面,等待下游的數據倉庫的抽取;// 2、非/半結構化數據 Flume支持對日志文件進行數據監控,一旦有變動將數據抽取出來; Logstash

2.3、數據積存(ODS層)

（1）數據與源業務數據保持一致，可以增加審計字段用來進行數據管理

（2）存儲的歷史數據是只讀的，提供業務系統查詢使用

• 業務系統會將定期將導入數據倉庫的業務數據庫中的數據刪除掉

（3）修改只可追加：業務系統對歷史數據完成修改后，將update_type字段更新為UPDATE，追加回ODS層

（4）在離線數倉中業務數據定期通過ETL流程放到如ODS中，導入方式有兩種

--全量導入：數據的第一次導入，選擇此種方式； --增量導入：數據非第一次導入，每次只需倒入新增、更改的數據,建議使用外連接&全覆蓋方式

case：針對大數據平臺不能修改數據的限制

• Ⅰ、外連接

• Ⅱ、全覆蓋

2.4、數據分析(DWD/DWS/ADS)

2.4.1、DWD - 數據明細層

• 數據仍滿足3NF模型，為分析運算做準備；
• 數據明細層對ODS層的數據進行清洗，標準化、維度退化
  • 范例：將維表數據整合到事實表中；
  • 范例：各個不同城市子公司的用戶表，添加一個城市字段后union

維度退化:在大數據的數據倉庫里面,大量join操作會涉及到一個海量數據的移動,導致性能會很差

2.4.2、DWS - 數據匯總層

• 數據匯總層：對數據明細層的數據進行計算匯總，存放便于分析的大寬表；

• 存儲模型：更加注重與數據聚合，復雜查詢，處理性能更優的數倉模型；

  • 傳統數倉：以維度模型為主；
  • 大數據數倉：以寬表模型為主

DWS層：將ODS層的零散表聚集成一張面向主題的大寬表

2.4.3、ADS - 數據應用層

• 數據應用層：數據集市;
• 主要作用：存儲數據分析結果,為不同業務場景提供外部接口，減輕數據倉庫的負擔

--數據倉庫擅長數據分析，直接開放業務查詢借口，會增加其負擔①報表決策的快速查詢：kylin②前端業務的并發查詢：Hbase③前端業務的只能檢索：ElasticSearch

3、數據倉庫建模

3.1、建模基本概念

3.1.1、OLTP傳統建模方法

（1）OLTP（在線事務處理）系統中，主要操作是隨機讀寫；

用于業務數據，主要是對業務數據庫提供數據存儲和數據操作的服務;

（2）使用關系模型建模（ER模型），保證數據一致性，減少冗余；

ER模型原則盡量將表拆分，拆分的越細越好，盡量滿足3NF的規則，減少冗余

3.1.2、OLAP在線聯機分析

（1）基本概念

• OLAP系統：主要操作是復雜分析查詢，關注數據整合以及分析，處理性能

• OLAP根據存儲方式的不同：分為ROLAP、MOLAP、HOLAP;

（2）系統分類

• Ⅰ、ROLAP：關系型OLAP

使用關系模型構建，存儲系統一般為RDBMS；

• Ⅱ、MOLAP：多維型OLAP

預先聚合計算,使用多位數組的形式保存數據結果，加快查詢分析時間；

• Ⅲ、HOLAP：混合架構的OLAP

1、ROLAP和MOLAP兩者的集成； 2、底層是關系性的，高層是多維矩陣的； 3、查詢效率高于ROLAP,低于MOLAP;

3.2、ROLAP - DWS層

• 業務場景：ADS層

3.2.1 維度模型

• 分為星形模型，雪花模型，星座模型

• 方便對數據多維分析

事實表維度表

3.2.2、星型模型

• 標準的星型模型維度只有一層,分析性能最優;

查詢的時候,找到維度表對事實表直接聚合;

• 星型模型與雪花型模型的區別

星型模型和雪花模型的主要區別在于對維度表的拆分，雪花模型:維度表的設計更加規范，一般符合3NF；星型模型:一般采用降維的操作，利用冗余來避免模型過于復雜，提高易用性和分析效率。

3.2.3、雪花模型

• 雪花模型具有多層維度,比較接近三范式設計

3.2.4、星座模型

• 星座模型基于多個事實表,事實表之間會共享一些維度表;

星座模型是大型數據倉庫中的常態,是業務增長的結果,與模型設計無關;

3.2.5、寬表模型

• 大數據數倉里面,join使得大量數據移動導致性能不佳

• 寬表模型:將維度冗余到事實表中,形成寬表,以此減少join操作;

3.3、MOLAP - ADS層

• 特點：以空間換時間；靈活性較低，不存儲原始數據
• 業務場景：應用于ADS層

（1）MOLAP將數據進行預結算，并將聚合結果存儲到CUBE模型中；

（2）CUBE模型以多維數組的形式，物化到存儲系統中，加快后續的查詢；

（3）生成cube需要大量的時間，空間，維度預處理可能導致數據膨脹；

• 常見的MOLAP產品：Kylin，Druid

1、讀取Hadoop，hive...各種數據源獲取后； 2、由Kylin加工成cube,加工時進行多種維度組合; 3、預計算結果存儲到Hbase中; 4、前端業務人員/程序員查詢kylin,kylin返回Hbase中的數據;

3.4、OLAP多維分析

• OLAP主要操作時復雜查詢,可以多表關聯,使用count、sum、avg等函數;
• OLAP對復雜查詢做了直觀的定義,包括鉆取、切片、切塊、旋轉;

3.4.1、鉆取

• 鉆取：對維度不同層次的分析，通過改變維度的層次來變換分析的粒度;

鉆取包括上卷、下鉆;上卷:向上鉆取,指從低層次到高層次的切換;下鉆:指從高層次到低層次的切換;

3.4.2、切片/切塊

• 切片：選擇某個維度進行分割；
• 切塊：按照多維進行切片；

3.4.3、旋轉

• 旋轉：對維度方向的互換，類似于坐標軸上卷

1、先查詢產品類型,之后每個產品類型按照時間進行篩選; 2、旋轉之后,先查詢時間,之后按每年的產品類型進行分類;

4、數據倉庫最佳實踐

4.1、表的分類

4.1.1、事實表

• 事實表數據：一般指一個現實存在的業務對象；比如用戶，商品，商家等；

（1）事務事實表 – 順序追加

• 隨著業務不斷產生的數據，一般產生不會再發生變化，如交易流水，操作日志，出庫入庫記錄；

（2）周期快照事實表 – 順序追加

• 隨著業務周期型的推進而變化，完成間隔周期內的度量統計，如年、季度累計；

• 使用周期+狀態度量組合，如年累計訂單數，年是周期，訂單總數是度量；

銀行/金融行業中:業務隨著業務周期的變化,數據重新計算比如年累計,月累計,天累計

（3）累計快照事實表 – 隨機修改

• 記錄不確定周期的度量統計，完全覆蓋一個事實的生命周期，如訂單狀態表；
• 通常有多個時間字段，用于記錄生命周期中的關鍵節點；
• 只有一條記錄，針對此記錄不斷更新；

兩種實現方式：1、事務事實表;2、對之前歷史數據的隨即修改 --拉鏈表

• 累計快照事實表實現方式

1、實現方式一使用日期分區表,全量數據記錄,每天的分區存儲昨天全量數據于當天增量數據的合并結果;數據量過大會導致全量表碰撞,存儲永遠不更新的冷數據,對性能影響較大;業務場景:適合于數據量少的情況;2、實現方式二使用日期分區表,存儲周期內的數據,周期外的冷數據存儲到歸檔標中;需要保留多天的分區數據,存儲消耗依然很大;3、實現方式三使用日期分區表,以業務實體的結束時間分區,每天的分區存放當太難結束的數據,設計一個時間非常大的分區如9999-12-31,存放截至當前未結束的數據;優點:已結束的數據存放到相應分區,存放未結束數據分區,數據量也不是很大,ETL性能好;無存儲浪費,數據全局唯一;

4.1.3、維度表

• 維度表數據：一般是指一些業務狀態，代碼的解釋表（即碼表）。
  • 通常使用維度對事實表中的數據進行統計、聚合運算

4.1.4、拉鏈表

• 拉鏈表：記錄每條信息的生命周期，用于保留數據的所有歷史變化狀態；
• 拉鏈表將表數據的隨機修改方式變為順序追加；

• 拉鏈表的實現策略
  • 1、拉鏈表實現方式 – 增量數據與目標表通過主鍵做全量關聯

/* 更新最新數據,以主鍵是否存在判斷是否取增量表中數據,還是T-1的全量表中數據;(1)沒有關聯上的數據:插入insert分區;(2)關聯上的數據:插入update分區;*** 每次增量數據須和DWI表做關聯,會吃很多資源 */ insert overwrite table dwi_t_9000 partition(date) select if(tmp.id is null,ods.id,temp.id) as id from temp full join dwi on temp.id = ods.id

4.2、ETL策略

• ETL策略分為兩種：全量同步&增量同步；

4.2.1、全量同步

• 業務場景：數據初始化裝載使用全量同步方式；
  • 因為業務/技術原因，比如第三方給的數據，使用全亮的方式做周期數據更新，直接覆蓋原有的數據即可；
  • 利用分區保存每天數據，可保存較短周期；

結構化數據:JDBC：直接連接數據庫進行數據抽取，會給數據庫帶來較大的負載和壓力，影響數據庫的穩定性；一般抽取備庫;抽取數據庫日志方式：開放CDC功能抽取日志，oracle使用OGG工具，mysql或者sqlserver使用CDC工具；

4.2.2、增量同步

• 業務場景：除了第一次全量同步完后，之后的每次的數據都是增量同步；

（1）結構化數據

• 抽取方式：
  • JDBC抽取：業務數據的時間戳抽取；
  • 日志抽取：對數據庫日志進行抽取，數據庫日志是追加的，對某個時間點之后的數據會更容易追加到；

日志抽取相比于JDBC抽取：抽取速度快，且對數據庫影響較小;

（2）非結構/半結構化數據

• 抽取工具：自帶監控功能，可以實時監控變動數據；

（3）增量數據更新方式

• Ⅰ、傳統數據整合方案：大多數采用merge方式（update+insert）
• Ⅱ、主流大數據平臺：不支持update操作，可采用全外連接+數據全量覆蓋方式

大數據平臺擔心數據出錯,可以采用分區方式,每天保存最新的全量版本,保留較短周期;

insert overwrite table dw_user_inc select --如果ODS表中有數據,以新增數據為準;如果沒有則追加; case when b.uid is not null then b.uid else a.uid end as uid, case when b.uid is not null then b.ename else a.ename end as uname ... from dw_user_inc outer join ods_user_inc b on a.uid = b.uid

4.3、任務調度

4.3.1、任務調度必要性

• 定時：自動化完成任務的定時執行;
• 制定節點：解決任務單元間的依賴關系;

4.3.2、調度任務類型

• shell：用于啟動數據倉庫的集群組件，比如ETL的采集組件；
• java：數據清洗任務；
• mapreduce：Mapreduce執行特定功能，吞吐量更高；
• SQL腳本：數據的DDL，數據處理任務等；

4.3.3、常見調度工具

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-Yx4C9AFA-1627957839829)(C:\Users\李海偉\AppData\Roaming\Typora\typora-user-images\image-20210604164125162.png)]

5、常見面試題

5.1、范式建模和維度建模的區別

范式模型:從流程上看是自上而下的，自上而下指的是數據的流向，“上”即數據的上游，“下”即數據的下游，即從分散異構的數據源 -> 數據倉庫 -> 數據集市。:以數據源頭為導向，然后一步步探索獲取盡量符合預期的數據，因為數據源往往是異構的，所以會更加強調數據的清洗工作，將數據抽取為實體-關系模型，并不強調事實表和維度表的概念。 特點 :1、能夠結合業務系統的數據模型，較方便的實現數據倉庫的模型；:2、同一份數據只存放在一個地方，沒有數據冗余，保證了數據一致性；:3、數據解耦，方便維護。缺點:表的數量多；查詢時關聯表較多使得查詢性能降低。維度模型:從流程上看是自下而上的，即從數據集市-> 數據倉庫 -> 分散異構的數據源。:Kimball 是以最終任務為導向，將數據按照目標拆分出不同的表需求，數據會抽取為事實-維度模型，數據源經ETL轉化為事實表和維度表導入數據集市，以星型模型或雪花模型等方式構建維度數據倉庫，架構體系中，數據集市與數據倉庫是緊密結合的，數據集市是數據倉庫中一個邏輯上的主題域。 特點:1、維度建模：模型結構簡單，面向分析，為了提高查詢性能可以增加數據冗余，反規范化的設計，開發周期短，能夠快速迭代。缺點:就是數據會大量冗余，預處理階段開銷大，后期維護麻煩；還有一個問題就是不能保證數據口徑一致性，原因后面有講解。范式建模:必須符合準三范式設計規范，如果使用混合建模，則源表也需要符合范式建模的限制，即源數據須為操作型或事務型系統的數據。通過ETL抽取轉換和加載到數據倉庫的ODS層，ODS層數據與源數據是保持一致的，所以ODS層數據也是符合范式設計規范的，通過ODS的數據，利用范式建模方法，建設原子數據的數據倉庫EDW，然后基于EDW，利用維度建模方法建設數據集市。

• 建模思路

結合兩種建模方式的各自規范，混合建模按照“松耦合、層次化”的基本架構原則進行實施。混合數據倉庫架構方法主要包含以下關鍵步驟：業務需求分步構建、分層次保存數據、整合原子級的數據標準、維護一致性維度等。

總結

以上是生活随笔為你收集整理的第一章 数据仓库理论专题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。