本期與大家分享的是，小北用心整理的與資料倉庫相關的常見的面試題，希望對大家能有幫助，大家喜歡就給點鼓勵吧，歡迎各位大佬評論區指教討論！

💜🧡💛制作不易，各位大佬們給點鼓勵！
🧡💛💚點贊👍 ? 收藏? ? 關注?
💛💚💙歡迎各位大佬指教，一鍵三連走起！

1.資料倉庫為什么要分層？

作為一名資料的規劃者，我們肯定希望自己的資料能夠有秩序地流轉，資料的整個生命周期能夠清晰明確被設計者和使用者感知到，直觀來講就是如下的左圖這般層次清晰、報表依賴關系直觀，

但是，大多數情況下，我們完成的資料體系卻是依賴復雜、層級混亂的，如下的右圖，在不知不覺的情況下，我們可能會做出一套表依賴結構混亂，甚至出現回圈依賴的資料體系，

因此，我們需要一套行之有效的資料組織和管理方法來讓我們的資料體系更有序，這就是談到的資料分層，資料分層并不能解決所有的資料問題，但是，資料分層卻可以給我們帶來如下的好處：

• 清晰資料結構：每一個資料分層都有它的作用域和職責，在使用表的時候能更方便地定位和理解

• 減少重復開發：規范資料分層，開發一些通用的中間層資料，能夠減少極大的重復計算

• 統一資料口徑：通過資料分層，提供統一的資料出口，統一對外輸出的資料口徑

• 復雜問題簡單化：將一個復雜的任務分解成多個步驟來完成，每一層解決特定的問題

2. 如何對資料倉庫進行分層，每一層都做了什么

ODS（Operational Data Store）：資料運營層

? “面向主題的”資料運營層，也叫ODS層，是最接近資料源中資料的一層，資料源中的資料，經過抽取、洗凈、傳輸，也就說傳說中的 ETL 之后，裝入本層，本層的資料，總體上大多是按照源頭業務系統的分類方式而分類的，

一般來講，為了考慮后續可能需要追溯資料問題，因此對于這一層就不建議做過多的資料清洗作業，原封不動地接入原始資料即可，至于資料的去噪、去重、例外值處理等程序可以放在后面的DWD層來做，

DW（Data Warehouse）：資料倉庫層

? 資料倉庫層是我們在做資料倉庫時要核心設計的一層，在這里，從 ODS 層中獲得的資料按照主題建立各種資料模型，DW層又細分為 DWD（Data Warehouse Detail）層、DWM（Data WareHouse Middle）層和DWS（Data Warehouse Service）層，

• DWD（Data Warehouse Detail）：資料明細層

? 該層一般保持和ODS層一樣的資料粒度，并且提供一定的資料質量保證，同時，為了提高資料明細層的易用性，該層會采用一些維度退化手法，將維度退化至事實表中，減少事實表和維表的關聯，

? 另外，在該層也會做一部分的資料聚合，將相同主題的資料匯集到一張表中，提高資料的可用性，

• DWM（Data Warehouse Middle）：資料中間層

? 該層會在DWD層的資料基礎上，對資料做輕度的聚合操作，生成一系列的中間表，提升公共指標的復用性，減少重復加工，直觀來講，就是對通用的核心維度進行聚合操作，算出相應的統計指標，

• DWS（Data Warehouse Service）：資料服務層

? 又稱資料集市或寬表，按照業務劃分，如流量、訂單、用戶等，生成欄位比較多的寬表，用于提供后續的業務查詢，OLAP分析，資料分發等，

? 一般來講，該層的資料表會相對比較少，一張表會涵蓋比較多的業務內容，由于其欄位較多，因此一般也會稱該層的表為寬表，在實際計算中，如果直接從DWD或者ODS計算出寬表的統計指標，會存在計算量太大并且維度太少的問題，因此一般的做法是，在DWM層先計算出多個小的中間表，然后再拼接成一張DWS的寬表，由于寬和窄的界限不易界定，也可以去掉DWM這一層，只留DWS層，將所有的資料在放在DWS亦可，

ADS/APP/DM（Application Data Store/Application/DataMarket）：資料應用層/資料集市

? 在這里，主要是提供給資料產品和資料分析使用的資料，一般會存放在 ES、PostgreSql、Redis等系統中供線上系統使用，也可能會存在 Hive 或者 Druid 中供資料分析和資料挖掘使用，比如我們經常說的報表資料，一般就放在這里，

DIM（Dimension）:維表層

維表層主要包含兩部分資料：

• 高基數維度資料：一般是用戶資料表、商品資料表類似的資料表，資料量可能是千萬級或者上億級別，

• 低基數維度資料：一般是配置表，比如列舉值對應的中文含義，或者日期維表，資料量可能是個位數或者幾千幾萬，

3.關系建模和維度建模的區別？

• 關系模型嚴格遵循第三范式（3NF），比較松散零碎，物理表數量眾多但資料冗余程度低，由于資料分布于眾多的表中，這些資料可以更為靈活地被使用，功能性較強，主要應用于OLTP系統中，保證資料的一致性以及避免冗余，所以大部分業務系統的表都遵循第三范式，

• 維度模型主要應用于OLAP系統中，通常以某一個事實表為中心進行表的組織，主要是面向業務，特征是可能存在資料的冗余，但是能很方便的得到資料，

• 關系模型雖然冗余少，但是在大規模資料，跨表分析統計查詢程序中，會造成多表關聯，這會大大降低執行效率，所以通常采用維度模型建模，把相關各種表整理成兩種：事實表和維度表，

4.維度建模的步驟是什么

• 選擇業務程序
  • 業務程序是組織完成的操作型活動，業務程序事件建立或獲取性能度量，并轉換為事實表中的事實，程序定義了特定的設計目標以及對粒度，維度，事實的定義，每個業務程序對應企業資料倉庫總線矩陣的一行，
• 宣告粒度
  • 在選擇維度或事實前必須宣告粒度，因為每個候選維度或事實必須與定義的粒度保持一致，在所有維度設計中強制實行一致性是保證BI應用性能和易用性的關鍵，在從給定的業務程序中獲取資料時，原子粒度是最低級別的粒度，最好從原子級別粒度開始設計，因為原子粒度能夠承受無法預期的用戶查詢，針對不同的事實表粒度，要建立不同的物理表，在同一事實表中盡量不要混用多種不同的粒度，
• 確認環境的維度
  • 維度圍繞某一業務程序事件所涉及的什么人、什么事、什么地點、什么時間、為什么、如何等背景，
• 確認用于度量的事實
  • 事實設計來自業務程序事件的度量，基本上都是以數量值表示，個數、件數、金額等等，

5. 資料庫與資料倉庫的區別（OLTP與OLAP的區別）

當今的資料處理大致可以分成兩大類：聯機事務處理OLTP（on-linetransaction processing）、聯機分析處理OLAP（On-Line Analytical Processing；OLTP是傳統的關系型資料庫的主要應用，主要是基本的、日常的事務處理，OLAP是資料倉庫系統的主要應用，支持復雜的分析操作，側重決策支持，并且提供直觀易懂的查詢結果，二者的主要區別對比如下表所示，

6.什么是維度表，有什么特征 ？

• 維度表：事實表中某個方向分支，必須有主鍵，用于關聯事實表，一般資料量較小，變化緩慢，

• 維度表的特征：
  維度表的范圍很寬（具有多個屬性、列比較多）；跟事實表相比，行數較少，（通常小于10萬條）；內容相對固定，

7.什么是事實表 ，有什么特征？什么是事實？事實表可分為幾種？

• 事實表：事實表是用來存盤主題的主干內容，一些外鍵指向維度表，事實表一般是沒有主鍵的，基本都是外鍵，資料的質量完全由業務系統來把握，一般單表欄位較多，資料量比較大
• “事實”表示的是業務事件的度量值（可以統計次數、個數、金額等），例如訂單事件中的支付金額，每一個事實表的行包括：具有可加性的數值型的度量值、與維度表相連接的外鍵、通常具有兩個及以上外鍵，
• 事實表的特征：
  非常的大；內容相對的窄；經常發生變化，每天新增很多，
• 事實表分類：
  • 1）事務型事實表：
    以每個事務或事件為單位，例如一筆支付記錄等，作為事實表里的一行資料，一旦事務被提交，事實表資料被插入，資料就不再進行更改，其更新方式為增量更新，
  • 2）周期型快照事實表：
    周期型快照事實表中不會保留所有資料，只保留固定時間間隔的資料，以具有規律性的、可預見的時間間隔記錄事實，例如每天或每月的總銷售金額，或每月的賬戶余額等，
  • 3）累積型快照事實表:
    累積快照事實表用于跟蹤業務事實的變化，覆寫程序的整個生命周期，通常具有多個日期欄位來記錄關鍵時間點，例如資料倉庫中可能需要累積或者存盤訂單從下單開始，到訂單商品被打包、運輸、簽收等各個業務階段的時間點資料，來跟蹤訂單生命周期的進展情況，當這個業務程序進行時，事實表的記錄也要不斷更新，

8.什么是寬表？拉鏈表？

• 寬表：欄位和資料量比較巨大，很多維度雜糅在一起，好處：方便查詢分析，缺點：沒有規范，
• 拉鏈表：記錄一個事物從開始，一直到當前狀態的所有變化的資訊，

9.資料倉庫建模的幾種方式 ？

范式建模，雪花模型，星型建模，事實星座模型.
鏈接：決議幾種數倉建模方式

10.數倉建設的理論（哪兩種）

Kimball和Inmon是兩種主流的資料倉庫理論，分別由 Ralph Kimbal和 Bill Inmon 提出，在實際資料倉庫建設中，業界往往會相互借鑒使用兩種開發模式，

Kimball
模式從流程上看是是自底向上的，即從資料集市到資料倉庫再到資料源(先有資料集市再有資料倉庫)的一種敏捷開發理論方法，對于Kimball模式，資料源往往是給定的若干個資料庫表，資料較為穩定但是資料之間的關聯關系比較復雜，需要從這些OLTP中產生的事務型資料結構抽取出分析型資料結構，再放入資料集市中方便下一步的BI與決策支持，通常，Kimball都是以最終任務為導向，首先，在得到資料后需要先做資料的探索，嘗試將資料按照目標先拆分出不同的表需求，其次，在明確資料依賴后將各個任務再通過ETL由Stage層轉化到DM層，這里DM層資料則由若干個事實表和維度表組成，接著，在完成DM層的事實表維度表拆分后，資料集市一方面可以直接向BI環節輸出資料了，另一方面可以先DW層輸出資料，方便后續的多維分，Kimball往往意味著快速交付、敏捷迭代，不會對資料倉庫架構做過多復雜的設計，在變換莫測的互聯網行業，這種架構方式逐漸成為一種主流范式，

Inmon
模式從流程上看是自頂向下的，即從資料源到資料倉庫再到資料集市的（先有資料倉庫再有資料市場）一種瀑布流開發方法，對于Inmon模式，資料源往往是異構的，比如從自行定義的爬蟲資料就是較為典型的一種，資料源是根據最終目標自行定制的，這里主要的資料處理作業集中在對異構資料的清洗，包括資料型別檢驗，資料值范圍檢驗以及其他一些復雜規則，在這種場景下，資料無法從stage層直接輸出到dm層，必須先通過ETL將資料的格式清洗后放入dw層，再從dw層選擇需要的資料組合輸出到dm層，在Inmon模式中，并不強調事實表和維度表的概念，因為資料源變化的可能性較大，需要更加強調資料的清洗作業，從中抽取物體-關系，通常，Inmon都是以資料源頭為導向，首先，需要探索性地去獲取盡量符合預期的資料，嘗試將資料按照預期劃分為不同的表需求，其次，明確資料的清洗規則后將各個任務通過ETL由Stage層轉化到DW層，這里DW層通常涉及到較多的UDF開發，將資料抽象為物體-關系模型，接著，在完成DW的資料治理之后，可以將資料輸出到資料集市中做基本的資料組合，最后，將資料集市中的資料輸出到BI系統中去輔助具體業務，

11.資料庫隔離等級，事務特性？

資料庫隔離等級，事務特性

12.資料庫引擎mysaim和innoDB的區別?

資料庫引擎mysaim和innoDB的區別

13.資料庫索引是什么資料結構

資料庫索引的資料結構