導語

本專欄博文會整理日常作業與面試中最常用到的大資料相關組件與Java語言的架構、概念、知識點，方便大家進行查閱，
涉及到的面試題以及答案均為博主搜羅整理，并加上自己的理解撰寫而成，同時博主會在部分題目的下方添加管遇此題深入理解的博文連接，方便讀者的深入理解，
希望大家可以通過此篇博文對于大資料相關概念有一個更深入的理解
還有哪些想看的面試題，讀者可以在評論區補充，博主會在一天內進行更新！！！
最后預祝大家新的一年升職加薪，工資漲漲漲！

1、什么是資料倉庫（數倉的定義）

資料倉庫 Data Warehouse，是為企業所決策制定程序，提供所有支持型別的資料集合，用于分析性報告和決策支持，數倉是一個面向主題、集成的、相對穩定、反應歷史變化的資料集合，隨著大資料技術的發展，其作用不再局限于決策分析、還可以為業務應用、審計、追蹤溯源等多方面提供資料支撐，幫助企業完成數字化轉型，

2、資料倉庫特點

面向主題

普通的操作型資料庫主要面向事務性處理，而資料倉庫中的所有資料一般按照主題進行劃分，主題是對業務資料的抽象，是從較高層次上對資訊系統中的資料進行歸納和整理，

面向主題的資料可以劃分成兩部分

1. 根據原系統業務資料的特點進行主題的抽取，
2. 確定每個主題所包含的資料內容，例如客戶主題、產品主題、財務主題等；而客戶主題包括客戶基本資訊、客戶信用資訊、客戶資源資訊等內容，

分析資料倉庫主題的時候，一般方法是先確定幾個基本的主題，然后再將范圍擴大，最后再逐步求精

集成性

面向操作型的資料庫通常是異構的、并且相互獨立，所以無法對資訊進行概括和反映資訊的本質，
而資料倉庫中的資料是經過資料的抽取、清洗、切換、加載得到的，所以為了保證資料不存在二義性，必須對資料進行編碼統一和匯總，以保證數倉內的資料一致性，消除冗余資料，

穩定性

資料倉庫中的資料反映的都是一段歷史時期的資料內容，它的主要操作是查詢、分析而不進行一般意義上的更新（操作型資料庫主要完成資料的增加、修改、洗掉、查詢），一旦某個資料進入到資料倉庫后，一般情況下資料會被長期保留，當超過規定的期限才會被洗掉，通常資料倉庫需要做的作業就是加載、查詢和分析，一般不進行修改操作，

反映歷史變化

資料倉庫不斷從操作型資料庫或其他資料源獲取變化的資料，從而分析和預測需要的歷史資料，所以一般資料倉庫中資料表的維度與事實表中都含有時間鍵，以表明資料的歷史時期資訊，然后不斷增加新的資料內容，通過這些歷史資訊可以對企業的發展歷程和趨勢做出分析和預測，資料倉庫的建設需要大量的業務資料作為積累，并將這些寶貴的歷史資訊經過加工、整理，最后提供給決策分析人員，這是資料倉庫建設的根本目的，

3、資料庫和資料倉庫的區別

資料庫
用于OLTP，主要用于操作型處理
資料庫是面向事物處理的，資料是由日常的業務產生的，常更新；
資料庫一般用來存盤當前事務性資料，如交易資料、業務資料；
資料庫的設計一般是符合三范式的，有最大的精確度和最小的冗余度，有利于資料的插入；

資料倉庫
用于OLAP，支持管理決策，
資料倉庫是面向主題的，資料來源多樣，經過一定的規則轉換得到，用來分析，
資料倉庫一般存盤的歷史資料，
資料倉庫的設計一般不符合三范式，并且反規劃范，有利于查詢，

4、數倉構建流程

1、資料調研、劃分主題域

通過與業務部門的交流，了解建立數倉要解決的問題，確定資料分析或前端展現的主題和各個主題下的查詢分析要求，主題要體現出某一方面的各分析角度(維度)和統計數值型資料(量度)之間的關系，

2、明確統計指標

確定主題后，需要考慮分析的各種指標，它們一般為資料值型資料，量度是要統計的指標，必須事先選擇恰當，基于不同的度量可以進行復雜關鍵性指標(KPI)的設計和計算，

3、構建總線矩陣

明確業務程序和維度所屬主題域、明確維度與業務程序的關系，最后形成一個總線矩陣圖表，

4、構建明細模型

DIM公共維度層
（DIM）公共維度層由維度表構成，基于維度建模理念，建立整個企業的一致性維度，
維度是邏輯概念，是衡量和觀察業務的角度，在劃分資料域、構建總線矩陣時，需要結合對業務程序的分析定義維度，

構建明細事實表DWD，將原始資料表和各個維度表進行關聯,生成事實表，

5、構建匯總模型

根據衍生指標和派生指標構建DWS

6、ETL以及代碼實作

資料清洗轉換和傳輸，業務系統中的資料加載到資料倉庫之前，必須進行資料的清洗和轉換，保證資料倉庫中資料的一致性，

7、數倉應用、結果驗證

開發資料倉庫的分析應用，滿足業務部門對資料進行分析的需求，

8、數倉管理

元資料治理、資料質量監控、資料血緣管理

5、數倉分層概述

ods：operation data store原始資料層，
資料保持原貌不做處理，ODS層是資料倉庫準備區，為DWD層提供基礎原始資料，可減少對業務系統的影響

dmi：公共維度層
公共維度層由維度表構成，基于維度建模理念，建立整個企業的一致性維度，

dwd：data warehouse detail明細資料層
結構和粒度與原始表保持一致，通過維表與ods層資料進行清洗關聯得到（去除空值，臟資料）
是業務層與資料倉庫的隔離層

dws：data warehouse service資料服務層
資料輕度匯總，基于dwd上的基礎資料，整合匯總成分析某一個主題域的服務資料，一般是寬表

ads：application data store 資料應用層
為各種統計報表提供資料
該層主要是提供資料產品和資料分析使用的資料，一般會存放在ES、MySQL等系統中供線上系統使用，也可能會存在Hive或者Druid中供資料分析和資料挖掘使用，例如：我們經常說的報表資料，或者說那種大寬表，一般就放在這里，

6、數倉為什么要分層

把復雜問題簡單化

將一個復雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解，

清晰資料結構：

每一個資料分層都有它的作用域，這樣我們在使用表的時候能更方便地定位和理解，

空間換時間、減少重復開發，

通過建設多層次的資料模型供用戶使用，避免用戶直接使用操作型資料，可以更高效的訪問資料，
通過開發一些通用的中間層資料，能夠減少極大的重復計算，

資料之間解耦合：

分層后不必改一次業務就重新接入資料，

而且便于維護資料的準確性，當資料出現問題之后，可以不用修復所有的資料，只需要從有問題的步驟開始修復，

7、維度建模選擇：星型、雪花、星座

星型模型

一張事實表，根據主鍵關聯多張一級維度表

星型架構是一種非規范化的結構，多維資料集的每一個維度都直接與事實表相連接，不存在漸變維度，所以資料有一定的冗余，很多統計查詢不需要做外部的連接，通過冗余換取運行效率，

雪花模型

雪花模式是星型模式的擴展，其中某些維表被規范化，進一步分解到附加維度表中，

優點是：通過最大限度地減少資料存盤量以及聯合較小的維表來改善查詢性能，

星座模型

星座模式是星型模式延伸而來，星型模式是基于一張事實表的，而星座模式是基于多張事實表的，而且共享維度資訊，常用于資料關系更復雜的場景，也稱事實星座模型，

比較

1、雪花模型在維度表、事實表之間的連接很多，因此性能方面會比星型模型低，

2、雪花模型使用的是規范化資料，資料冗余來減少資料量，其維度層級和維度資訊都存盤在資料模型之中，
星形模型是反規范化資料，資料存在冗余，維度直接關聯事實表，維度層級清晰明了，

3、雪花模型在設計上更加復雜，由于附屬維度的限制，ETL復雜且不能并行化，
星形模型加載維度表，不需要添加附屬維度層級，ETL相對簡單，可以實作高度的并行化，

4、雪花模型使得維度分析更加容易，比如“針對特定的廣告主，有哪些客戶或者公司是在線的?”，
星形模型用來做指標分析更適合，比如“給定的一個客戶他們的收入是多少?”

8、緩慢變化維處理

常見的緩慢變化維處理方式有三種：
1）直接覆寫：不記錄歷史資料，薪資料覆寫舊資料

2）新加一行資料（縱向擴展）：使用代理主鍵+生效失效時間或者是代理主鍵+生效失效標識（保存多條記錄，直接新添一條記錄，同時保留原有記錄，并用單獨的專用欄位保存）

3）新加兩個欄位（橫向擴展）：一個是previous，一個是current，每次更新只更新這兩個值，但是這樣職能保留最近兩次的變化（添加歷史列，用不同的欄位保存變化痕跡，因為只保存兩次變化記錄，使用與變化不超過兩次的維度）

4. 通過拉鏈表

9、拉鏈表的應用

10、事實表的型別

事務型事實表

概述

事務事實表用來記錄各業務程序，它保存的是各業務程序的原子操作事件，即最細粒度的操作事件，粒度是指事實表中一行資料所表達的業務細節程度，

事務型事實表可用于分析與各業務程序相關的各項統計指標，由于其保存了最細粒度的記錄，可以提供最大限度的靈活性，可以支持無法預期的各種細節層次的統計需求，

設計流程

設計事務事實表時一般可遵循以下四個步驟：

選擇業務程序→宣告粒度→確認維度→確認事實

選擇業務程序

在業務系統中，挑選我們感興趣的業務程序，業務程序可以概括為一個個不可拆分的行為事件，例如電商交易中的下單，取消訂單，付款，退單等，都是業務程序，通常情況下，一個業務程序對應一張事務型事實表，

宣告粒度

業務程序確定后，需要為每個業務程序宣告粒度，即精確定義每張事務型事實表的每行資料表示什么，應該盡可能選擇最細粒度，以此來應各種細節程度的需求，
典型的粒度宣告如下：
訂單事實表中一行資料表示的是一個訂單中的一個商品項，

確定維度

確定維度具體是指，確定與每張事務型事實表相關的維度有哪些，

確定維度時應盡量多的選擇與業務程序相關的環境資訊，因為維度的豐富程度就決定了維度模型能夠支持的指標豐富程度，

確定事實

此處的“事實”一詞，指的是每個業務程序的度量值（通常是可累加的數字型別的值，例如：次數、個數、件數、金額等），

經過上述四個步驟，事務型事實表就基本設計完成了，第一步選擇業務程序可以確定有哪些事務型事實表，第二步可以確定每張事務型事實表的每行資料是什么，第三步可以確定每張事務型事實表的維度外鍵，第四步可以確定每張事務型事實表的度量值欄位，

周期快照事實表

概述

周期快照事實表以具有規律性的、可預見的時間間隔來記錄事實，主要用于分析一些存量型（例如商品庫存，賬戶余額）或者狀態型（空氣溫度，行駛速度）指標，

對于商品庫存、賬戶余額這些存量型指標，業務系統中通常就會計算并保存最新結果，所以定期同步一份全量資料到資料倉庫，構建周期型快照事實表，就能輕松應對此類統計需求，而無需再對事務型事實表中大量的歷史記錄進行聚合了，

對于空氣溫度、行駛速度這些狀態型指標，由于它們的值往往是連續的，我們無法捕獲其變動的原子事務操作，所以無法使用事務型事實表統計此類需求，而只能定期對其進行采樣，構建周期型快照事實表，

設計流程

確定粒度

周期型快照事實表的粒度可由采樣周期和維度描述，故確定采樣周期和維度后即可確定粒度，

采樣周期通常選擇每日，

維度可根據統計指標決定，例如指標為統計每個倉庫中每種商品的庫存，則可確定維度為倉庫和商品，

確定完采樣周期和維度后，即可確定該表粒度為每日-倉庫-商品，

確認事實

事實也可根據統計指標決定，例如指標為統計每個倉庫中每種商品的庫存，則事實為商品庫存，

適用場景

適用于分析存量型、狀態型指標

事實型別

此處的事實型別是指度量值的型別，而非事實表的型別，事實（度量值）共分為三類，分別是可加事實，半可加事實和不可加事實，

可加事實

可加事實是指可以按照與事實表相關的所有維度進行累加，例如事務型事實表中的事實，

半可加事實

半可加事實是指只能按照與事實表相關的一部分維度進行累加，例如周期型快照事實表中的事實，以上述各倉庫中各商品的庫存每天快照事實表為例，這張表中的庫存事實可以按照倉庫或者商品維度進行累加，但是不能按照時間維度進行累加，因為將每天的庫存累加起來是沒有任何意義的，

不可加事實

不可加事實是指完全不具備可加性，例如比率型事實，不可加事實通常需要轉化為可加事實，例如比率可轉化為分子和分母，

累計快照事實表

概述

累計快照事實表是基于一個業務流程中的多個關鍵業務程序聯合處理而構建的事實表，如交易流程中的下單、支付、發貨、確認識訓業務程序，

累積型快照事實表主要用于分析業務程序（里程碑）之間的時間間隔等需求，例如前文提到的用戶下單到支付的平均時間間隔，使用累積型快照事實表進行統計，就能避免兩個事務事實表的關聯操作，從而變得十分簡單高效，

設計流程

累積型快照事實表的設計流程同事務型事實表類似，也可采用以下四個步驟，下面重點描述與事務型事實表的不同之處，

選擇業務程序→宣告粒度→確認維度→確認事實

選擇業務程序

選擇一個業務流程中需要關聯分析的多個關鍵業務程序，多個業務程序對應一張累積型快照事實表，

宣告粒度

精確定義每行資料表示的是什么，盡量選擇最小粒度，

確認維度

選擇與各業務程序相關的維度，需要注意的是，每各業務程序均需要一個日期維度，

確認事實

選擇各業務程序的度量值，

適用場景

適用于處理多事務關聯

11、全量表,增量表,追加表，拉鏈表的區別及使用場景（同步策略）

全量表
每天的所有的最新狀態的資料， 1、全量表，有無變化，都要報 2、每次上報的資料都是所有的資料（變化的 + 沒有變化的）

增量表
新增資料，增量資料是上次匯出之后的新資料， 1、記錄每次增加的量，而不是總量； 2、增量表，只報變化量，無變化不用報 3、業務庫表中需有主鍵及創建時間，修改時間

拉鏈表
維護歷史狀態，以及最新狀態資料
適用情況：

1. 資料量比較大
2. 表中的部分欄位會被更新
3. 需要查看某一個時間點或者時間段的歷史快照資訊 查看某一個訂單在歷史某一個時間點的狀態 某一個用戶在過去某一段時間，下單次數
4. 更新的比例和頻率不是很大 如果表中資訊變化不是很大，每天都保留一份全量，那么每次全量中會保存很多不變的資訊，對存盤是極大的浪費

優點 1、滿足反應資料的歷史狀態 2、最大程度節省存盤

12、你們的數倉上層應用有哪些

用戶畫像，運營平臺，精準營銷，推薦系統等

13、資料質量保障

14、怎么理解元資料？

1. 業務元資料
   描述 "資料"背后的業務含義，
   主題定義：每段 ETL、表背后的歸屬業務主題，
   業務描述：每段代碼實作的具體業務邏輯，
   標準指標：類似于 BI 中的語意層、數倉中的一致性事實；將分析中的指標進行規范化，
   標準維度：同標準指標，對分析的各維度定義實作規范化、標準化，
   不斷的進行維護且與業務方進行溝通確認，
2. 技術元資料
   資料源元資料：例如：資料源的 IP、埠、資料庫型別；資料獲取的方式；資料存盤的結構；原資料各列的定義及 key 指對應的值，
3. ETL 元資料：
   根據 ETL 目的的不同，可以分為兩類：資料清洗元資料；資料處理元資料，
   資料清洗，主要目的是為了解決掉臟資料及規范資料格式；因此此處元資料主要為：各表各列的"正確"資料規則；默認資料型別的"正確"規則，
   資料處理，例如常見的表輸入表輸出；非結構化資料結構化；特殊欄位的拆分等，源資料到數倉、資料集市層的各類規則，比如內容、清理、資料重繪規則，
4. 資料倉庫元資料：
   資料倉庫結構的描述，包括倉庫模式、視圖、維、層次結構及資料集市的位置和內容；業務系統、資料倉庫和資料集市的體系結構和模式等，
5. BI 元資料：
   匯總用的演算法、包括各類度量和維度定義演算法，資料粒度、主題領域、聚集、匯總、預定義的查詢與報告，
6. 管理元資料
   管理領域相關，包括管理流程、人員組織、角色職責等，

15、資料漂移如何解決

源系統同步進入資料倉庫的第一層資料稱為ODS層，資料漂移是ODS資料的一個頑疾，通常是指ODS表的同一個業務日期資料中包含前一天或后一天凌晨附近的資料或者丟失當天的變更資料，

由于ODS需要承接面向歷史的細節資料查詢需求,這就需要物理落地到資料倉庫的ODS表按時間段來切分進行磁區存盤,通常的做法是按某些時間戳欄位來切分,而實際上往往由于時間戳欄位的準確性問題導致發生資料漂移，

通常,時間戳欄位分為四類:
1、 資料庫中資料更新時間(假設這類欄位叫modified_time)
2、 資料庫日志中的資料記錄更新時間(假設這類欄位叫log_time)
3、 業務程序發生時間(假設這類欄位叫proc_time)
4、 資料被抽取的時間(假設這類欄位叫extract_time)

理論上,這幾個時間應該是一致的,但是在實際生產中,這幾個時間往往會出現差異,可能的原因有以下幾點:
1、 由于資料抽取需要時間, extract_time往往會晚于前三個時間，
2、 前臺業務系統手工訂正資料時未更新modified_time.
3、 由于網路或者系統壓力問題, log_time或者modified_time會晚于proc_time.

通常的做法是根據其中的某一個欄位來切分ODS表,這就導致產生資料漂移，下面我們來具體看下資料漂移的幾種場景，
1、 根據extract_time來獲取資料，這種情況資料漂移的問題最明顯，
2、 根據modified_time限制，在實際生產中這種情況最常見,但是往往會發生不更新modified time而導致的資料遺漏,或者凌晨時間產生的資料記錄漂移到后一天，
3、 根據log_time限制，由于網路或者系統壓力問題, log_time會晚于 proc_time,從而導致凌晨時間產生的資料記錄漂移到后一天，例如,在淘寶“雙11”大促期間凌晨時間產生的資料量非常大,用戶支付需要呼叫多個介面,從而導致log_time晚于實際的支付時間，
4、 根據proc_time限制，僅僅根據proc_time限制,我們所獲取的ODS表只是包含一個業務程序所產生的記錄,會遺漏很多其他程序的變化記錄,這違背了ODS和業務系統保持一致的設計原則，
處理方法主要有以下兩種

1、 多獲取后一天的資料
在ODS每個時間磁區中向前、向后多冗余一些資料,保障資料只會多不會少,而具體的資料切分讓下游根據自身不同的業務場景用不同的業務時間proc_time來限制，
但是這種方式會有一些資料誤差，
2、 通過多個時間截欄位限制時間來獲取相對準確的資料
(1) 首先根據log_time分別冗余前一天最后15分鐘的資料和后一天凌晨開始15分鐘的資料,并用modified_time過濾非當天資料,確保資料不會因為系統問題而遺漏，
(2) 然后根據log_time獲取后一天15分鐘的資料;針對此資料,按照主鍵根據log_time做升序排列去重，因為我們需要獲取的是最接近當天記錄變化的資料(資料庫日志將保留所有變化的資料,但是落地到ODS表的是根據主鍵去重獲取最后狀態變化的資料)，
(3) 最后將前兩步的結果資料做全外連接,通過限制業務時間proc_time來獲取我們所需要的資料，

下面來看處理淘寶交易訂單的資料漂移的實際案例，我們在處理“雙11”交易訂單時發現,有一大批在11月11日 23:59:59左右支付的交易訂單漂移到了12日，主要原因是用戶下單支付后系統需要呼叫支付寶的介面而有所延遲,從而導致這些訂單最終生成的時間跨天了，即modified_time和log_time都晚于proc_time.
如果訂單只有一個支付業務程序,則可以用支付時間來限制就能獲取到正確的資料，但是往往實際訂單有多個業務程序:下單、支付、成功,每個業務程序都有相應的時間戳欄位,并不只有支付資料會漂移，
如果直接通過多獲取后一天的資料,然后限制這些時間,則可以獲取到相關資料,但是后一天的資料可能已經更新多次,我們直接獲取到的那條記錄已經是更新多次后的狀態,資料的準確性存在一定的問題，
因此,我們可以根據實際情況獲取后一天15分鐘的資料,并限制多個業務程序的時間戳欄位(下單、支付、成功)都是“雙11"當天的,然后對這些資料按照訂單的modified time做升序排列,獲取每個訂單首次資料變更的那條記錄，
此外,我們可以根據log_time分別冗余前一天最后15分鐘的資料和后一天凌晨開始15分鐘的資料,并用modifie_time過濾非當天資料,針對每個訂單按照log_time進行降序排列,取每個訂單當天最后一次資料變更的那條記錄，最后將兩份資料根據訂單做全外連接,將漂移資料回補到當天資料中，

16、資料治理內容

技術層面-李奇峰總結

1. 資料分類：首先是針對各資料進行歸類，根據業務需求劃分成不同的類別，然后將資料表依次歸類，
2. 時間欄位治理：在所有資料中添加統一名稱的時間欄位，依次記錄資料發生時間、最后更新時間、插入時間等，
3. 資料過濾：在入庫時如果碰到無法決議的錯誤資料，或者關鍵欄位缺失的資料，則直接丟棄，
4. 資料去重：如果在入庫時發現庫中存在相同的資料，則會將新資料直接覆寫舊資料，
5. 資料抽取與合并：將各個類別的資料的指定欄位抽取到一個正式庫中，統一格式，去除多樣欄位，標注來源資訊，同時在抽取程序中，將屬于同一事件的多個日志進行合并，保存至合并庫中，
6. 資料關聯：資料入庫后，各個資料之間關聯性較弱，在開發程序中需要重復呼叫資料介面進行資料獲取，于是在資料入庫時或入庫后，根據主外鍵ID、相同含義欄位進行關聯，將關聯欄位更新至源資料中，

業務層面-蘇奕嘉總結

我覺得從框架而言，我個人認為需要幾部分：

1. 欄位規則治理：主要是和業務方對齊原子指標的含義，如有多條線，需要一起對齊口徑，只有業務方都承認和了解接受了原子指標口徑，數倉才好進一步處理，舉例：凈收益到底是【營銷額-成本（包含各種費用）】還是【營銷額-成本（只包含成品本身的成本）】，不同的業務線可能有不同的定義，如供應鏈和營銷鏈注重的就不一樣
2. 資料源治理：資料源即上游資料，上游資料多而繁雜，可細分為不同資料型別進行劃域治理，類似主題建模和資料域的概念，比如訂單、客戶、供應鏈、財務等等，不同的域有不同的強規則體系，這個體系可形成一套完備的探查系統，比如資料源探查體系：訂單{null值:是否有null值,長度:訂單號是否滿足規則,金額:是否有營銷額無凈銷額……}，客戶{OneID:是否標識,手機號:是否為空,識訓地址:是否滿足規則……}，不同的資料域有著不同的欄位定義標準和探查規則標準，如果沒有探查階段，那么資料治理就是睜眼瞎
3. 資料質量反饋體系：很多時候，上游資料有了問題，下游溝通其實是一個很難的事情，比如上游為了滿足自己業務需求，私自改了數值/欄位名/表名等等，下游會發生依賴錯誤/資料值錯誤等情況，如果要求上游怎樣做，其實很不靠譜，別人不太會聽你的，那么就需要從更高一個維度解決，一是成立PMO組織，由更高級別的Leader組織，內部有資料部門，業務部門和測驗部門，資料部門發現問題，交由測驗部門進行總結反饋，定期給出質量報告，由測驗部門監督業務部門完成整改，可用作計入績效考核等方式進行管控，沒有裁判的賽道是虛假的、不完整的，
4. 資料災備規則和系統：沒有人管控的了別人的做法和想法，那么就要做好資料部門本身的災備規則和系統，比如從小處講，ODS接入后在DW清洗時要注意NULL值處理，不管這個欄位以前有沒有NULL值，從大處講，就是完善資料部門自己的代碼書寫規范，每次發版需要嚴格CodeReview，如果從系統角度出發，比如第三方，就做一個第三方統一接入系統，從源頭規范化資料格式，比如業務線，就采取業務中臺模式，資料所有資料統一處理統一管理，當然，這些扯開都是很大的話題，以后再講

業務層面-幻楓總結：

1. 指標體系的建立，加上緯度屬性的集成，構成資料字典，
2. 資料源有公約規則約束的情況下建立明細資料的的資料監控，資料遠沒有公約規則的，按斬訓礎的資料標準和業務程序進行資料探查，然后按照資料展現情況進行資料監控，
3. 就是資料治理的組織架構，要由上層牽頭下游處理，且要有管理體系，比如約束規范更改要有特定的流程，
4. 就是數倉內部根據下游的需求，制定清晰轉換規則，要有相應的操作留檔

業務層面-A94總結：

資料治理按型別分：

1. 主資料治理：
   指企業內一致并共享的業務主體，
   特點：準確性、一致性、集成性、共享性/可重用性和高價值，
   主資料治理一般會作為單獨的專案來做，MDM系統，一般是從源端進行管控治理
   主資料的主要問題：
   關鍵資訊孤島，資料分布在多個孤島，不能跨組織傳播
   組織內不能就一個主資料源達成一致
   資料質量問題引發的業務流程和交易的失敗
   不正確或丟失資料造成合規性和績效管理的問題
   決策者做出基于錯誤資料的錯誤決定
   主資料解決方案：
   一：資料轉換映射
   二：由應用系統承擔主資料管理功能
   三：集中管控

2. 交易資料治理
   交易資料一般可以先在資料平臺先行治理，之后再在源端進行管控治理

3. 參考資料治理
   參考資料一般可以先在資料平臺先行治理，之后再在源端進行管控治理

4. 分析資料治理
   分析資料一般可以在資料平臺進行治理

5. 資料模型、資料標準的治理
   資料模型、資料標準一般可以先在資料平臺先行治理，之后再在源端進行管控治理

6. 元資料治理：是企業資料資產管理的基礎，是關于“資料的資料”，例如資料型別、資料定義、資料關系等，相當于資料表格中的表頭資訊，是一個相對客觀的概念，
   元資料一般可以先在資料中臺先行治理，之后再在源端進行管控治理

思想層面-南知總結：

資料權限（安全），元資料管理（技術or業務，資產），資料質量（上下游延遲，故障快速感知和修復）

治理是很大的概念，從我經歷過或做過的，可以下手的點就是質量、安全、資產

數倉是數倉，治理是治理，要明確的分開，凡涉及到口徑、資料源、ETL processing的，應該算數倉方法論或數倉規范或落地平臺化的方式方法

17、資料集市、資料中臺、資料倉庫

18、原子指標、衍生指標、派生指標的區別

1. 原子指標
   基于某一業務事件行為下的度量，是業務定義中不可再拆分的指標，具有明確業務含義的名稱，如呼單量、交易金額
2. 派生指標
   是1個原子指標+多個修飾詞（可選）+時間周期，是原子指標業務統計范圍的圈定，派生指標又分可以下二種型別：
   a. 事務型指標：是指對業務程序進行衡量的指標，例如，呼單量、訂單支付金額，這類指標需
   要維護原子指標以及修飾詞，在此基礎上創建派生指標，
   b.存量型指標：是指對物體物件（如司機、乘客）某些狀態的統計，例如注冊司機總數、注冊
   乘客總數，這類指標需要維護原子指標以及修飾詞，在此基礎上創建派生指標，對應的時間
   周期一般為“歷史截止當前某個時間”，
3. 衍生指標
   是在事務性指標和存量型指標的基礎上復合成的，主要有比率型、比例型、統計型均值

19、范式建模

范式建模法主要用于關系型資料庫的資料存盤，主要用于業務系統，分為物體表與關系表，可以解決資料冗余，插入，修改，洗掉例外的問題，
目前OLTP業務系統中大多采用的是三范式建模法，

• 第一范式
  1NF是所有關系型資料庫的最基本要求，屬性值不可再分，說直白點就是一列里面不能包含多個小列，就像下面這樣
  
• 第二范式
  保證一張表只描述一件事情
• 第三范式
  所有欄位只能直接依賴主鍵，不得依賴于其它欄位(非主屬性) 消除依賴傳遞，決定某欄位值的必須是主鍵，而不是其他欄位

20、數倉一致性如何保證

數倉資料不一致會導致資料重復計算，資料孤島，并對使用人員產生誤解，

資料一致性可以避免重復建設和指標冗余建設，從而保障資料口徑的規范和統一，最終實作資料資產全鏈路關聯，提供標準資料輸出以及建立統一的資料公共層，

主要通過構建一致性維度和一致性事實，
通過制定數倉規范可以保障，

21、主題域如何劃分

主題域通常是聯系較為機密的資料主題的集合，可以根據業務關注度，將這些資料主題劃分到不同的主題域（也就是說對某個主題進行分析后確定的主題的邊界），
關于主題域的劃分，可以考慮幾方面：

1. 按照業務或者業務程序劃分：比如一個靠銷售廣告位置的門戶網站主題域可能會有廣告域，客戶域等，而廣告域可能就會有廣告的庫存，銷售分析、內部投放分析等主題；
2. 根據需求方劃分：比如需求方為財務部，就可以設定對應的財務主題域，而財務主題域里面可能就會有員工工資分析，投資回報比分析等主題；
3. 按照功能或者應用劃分：：比如微信中的朋友圈資料域、群聊資料域等，而朋友圈資料域可能就會有用戶動態資訊主題、廣告主題等；
4. 按照部門劃分：比如可能會有運營域、技術域等，運營域中可能會有工資支出分析、活動宣傳效果分析等主題；

總而言之，切入的出發點邏輯不一樣，就可以存在不同的劃分邏輯，在建設程序中可采用迭代方式，不糾結于一次完成所有主題的抽象，可先從明確定義的主題開始，后續逐步總結成自身的標準模型，

22、制定了哪些數倉規范

1. 分層規范
2. 表規范：命名、注釋、磁區、存盤格式規范、字符集、空值
3. 欄位規范：命名、注釋、型別
4. 視圖、存盤程序、函式命名規范

23、如何避免業務資料庫表結構變更導致數倉任務大面積報錯，

1、表結構變動應提前溝通，確定上下游影響范圍后進行統一調整變更，
2、抽取時避免采用select * 全表抽取，抽取粒度應該精確到欄位層面，
3、對業務資料庫表進行變更監控，根據表資訊模板與現表結構進行校驗，監控到結構變動后立即通知或告警，

24、模型設計的思路？業務驅動？資料驅動？

構建資料倉庫有兩種方式：自上而下、自下而上

自上而下指的是資料源出發，一個企業建立唯一的資料中心，資料是經過整合、清洗、去掉臟資料、標準的、能夠提供統一的視圖，要從整個企業的環境入手，建立資料倉庫，要做很全面的設計，偏資料驅動

自下而上指的是從業務需求出發，認為資料倉庫應該按照實際的應用需求，加載需要的資料，不需要的資料不要加載到資料倉庫中，這種方式建設周期短，用戶能很快看到結果，偏業務驅動

25、為什么需要資料倉庫建模？

數倉建模需要按照一定的資料模型，對整個企業的資料進行采集，整理，提供跨部門、完全一致的報表資料，

合適的資料模型，對于大資料處理來講，可以獲得得更好的性能、成本、效率和質量，良好的模型可以幫助我們快速查詢資料，減少不必要的資料冗余，提高用戶的使用效率，

資料建模進行全方面的業務梳理，改進業務流程，消滅資訊孤島，更好的推進數倉系統的建設，

26、總線架構

維度建模的資料倉庫中，有一個概念叫Bus Architecture，中文一般翻譯為“總線架構”，總線架構是Kimball的多維體系結構（MD）中的三個關鍵性概念之一，另兩個是一致性維度（Conformed Dimension）和一致性事實（Conformed Fact），

在多維體系結構（MD） 的資料倉庫架構中，主導思想是分步建立資料倉庫，由資料集市組合成企業的資料倉庫，但是，在建立第一個資料集市前，架構師首先要做的就是設計出在整個企業內具有統一解釋的標準化的維度和事實，即一致性維度和一致性事實，而開發團隊必須嚴格的按照這個體系結構來進行資料集市的迭代開發，

一致性維度就好比企業范圍內的一組總線，不同資料集市的事實的就好比插在這組總線上的元件，這也是稱之為總線架構的原因，

實際設計程序中，我們通常把總線架構串列成矩陣的形式，其中列為一致性維度，行為不同的業務處理程序，即事實，在交叉點上打上標記表示該業務處理程序與該維度相關，這個矩陣也稱為總線矩陣（Bus Matrix），

總線架構和一致性維度、一致性事實共同組成了Kimball的多維體系結構的基礎，也建立了一套可以逐步建立資料倉庫的方法論，由于總線架構是多維體系結構的核心，所以我們有時就把多維體系結構直接稱為總線架構，

27、一致性維度

一致性維度是Kimball的多維體系結構中的三個關鍵性概念之一，另兩個是總線架構（Bus Architecture）和一致性事實（Conformed Fact），

在多維體系結構中，沒有物理上的資料倉庫，資料倉庫是由物理上的資料集市組合成，是一個邏輯概念，資料集市的建立是可以逐步完成的，多個資料集市組合在一起，成為一個資料倉庫，那么如果分步建立資料集市的程序出現了問題，資料集市就會變成孤立的集市，不能組合到整個資料倉庫中，而一致性維度的提出正式為了解決這個問題，

一致性維度的范圍是總線架構中的維度，即在多個資料集市中都存在的維度，這個范圍的選取需要資料架構師來決定，一致性維度的內容和普通維度并沒有本質上區別，都是經過資料清洗和整合后的結果，

維度保持一致后，事實表就可以保存在各個資料集市中，雖然在物理上是獨立的，但在邏輯上由一致性維度使所有的資料集市是聯系在一起，隨時可以進行交叉資料探索等操作，同時也就組成了資料倉庫，

28、一致性事實

在建立多個資料集市時，完成一致性維度的作業就已經完成了一致性的80%－90%的作業量，余下的作業就是建立一致性事實， 一致性事實和一致性維度有些不同，一致性維度是由專人維護在后臺（Back Room），發生修改時同步復制到每個資料集市，而事實表一般不會在多個資料集市間復制，需要查詢多個資料集市中的事實時，一般通過交叉探查（drill across）來實作， 為了能在多個資料集市間進行交叉探查，一致性事實主要需要保證兩點：第一個是KPI的定義及計算方法要一致，第二個是事實的單位要一致性，如果業務要求或事實上就不能保持一致的話，建議不同單位的事實分開建立欄位保存，
這樣，一致性維度將多個資料集市結合在一起，一致性事實保證不同資料集市間的事實資料可以交叉探查，一個分布式的資料倉庫就建成了，

29、Kimball架構和Inmon架構的區別

Inmon理論，自上而下，資料驅動
（1）自上而下按照主題建立資料倉庫，如按照客戶、供應商、產品等建立不同的主題，開發程序中每次增加一個主題；
（2）當建立的資料集市是跨多個主題的，需要以整合好的主題資料為基礎，

Kimball理論，自下而上，業務驅動，
（1）自下而上，維度建模；
（2）先按照業務主線建立最小粒度的事實表，再建立維度表，形成資料集市，通過“一致維度”能夠共同看到不同資料集市的資訊；

30、概念模型、邏輯模型、物理模型分別介紹一下？

概念模型設計 , 邏輯模型設計 , 物理模型設計 是資料庫及資料倉庫模型設計的三個主要步驟

1. 概念模型
   概念模型就是在了解了用戶的需求 , 用戶的業務領域作業情況以后 , 經過分析和總結 , 提煉出來的用以描述用戶業務需求的一些概念的東西 ;

1. 該系統的商業目的是什么 , 要解決何種業務場景
2. 該業務場景中 , 有哪些人或組織參與 , 角色分別是什么
3. 該業務場景中 , 有哪些物件參與 , 
4. 此外需要具備相關行業經驗 , 如核心業務流程 , 組織架構 , 行業術語

2. 邏輯模型
   邏輯模型是將概念模型轉化為具體的資料模型的程序 , 即按照概念結構設計階段建立的基本 E-R 圖 , 按選定的管理系統軟體支持的資料模型 (層次/網狀/關系/面向物件) , 轉換成相應的邏輯模型 , 這種轉換要符合關系資料模型的原則 ;

1. 分多少個主題 , 每個主題包含的物體
2. 每個物體的屬性都有什么
3. 各個物體之間的關系是什么
4. 各個物體間是否有關系約束

3. 物理模型
   物理模型就是針對上述邏輯模型所說的內容 , 在具體的物理介質上實作出來 , 系統需要建立幾個資料表 : 業務員資訊表 , 客戶資訊表 , 商品資訊表 , 定單表 ; 系統要包括幾個功能 : 業務員資訊維護 , 客戶資訊維護 , 商品資訊維護 , 建立銷售定單 ; 表 , 視圖 , 欄位 , 資料型別 , 長度 , 主鍵 , 外鍵 , 索引 , 約束 , 是否可為空 , 默認值 , 該階段需完成 :

1. 型別與長度的定義
2. 欄位的其他詳細定義 , 非空 , 默認值
3. 卻準詳細的定義 , 列舉型別欄位 , 各列舉值具體含義
4. 約束的定義 , 主鍵 , 外鍵

31、你認為資料倉庫最重要的是什么

資料集成和資料質量
企業的資料通常存盤在多個異構資料庫中，要進行分析，必須對資料進行一致性整合，整合后才能對資料進行分析挖掘出潛在的價值；
資料質量必須有保障，資料質量不過關，業務方無法高效的使用資料，

32、指標體系建設流程

33、維度建模和范式建模的區別、應用場景