數據倉庫的定義？
首先，用於支持決策，面向分析型數據處理；其次，對多個異構的數據源有效集成，集成後按照主題進行重組，並包含歷史數據，而且存放在數據倉庫中的數據壹般不再修改。
數據倉庫(Data Warehouse)是壹個面向主題的(subject oriented)、集成的(integrated)、相對穩定的(non-volatile)、反應歷史變化(time variant)的數據集合，用於支持管理決策(decision making support)。
數據倉庫和數據庫的區別？
從目標、用途、設計來說
數據庫是面向事物處理的，數據是由日常的業務產生的，常更新；數據倉庫是面向主題的，數據來源多樣，經過壹定的規則轉換得到，用來分析。數據庫壹般用來存儲當前事務性數據，如交易數據；數據倉庫壹般存儲的歷史數據。數據庫的設計壹般是符合三範式的，有最大的精確度和最小的冗余度，有利於數據的插入；數據倉庫的設計壹般不符合三範式，有利於查詢如何構建數據倉庫？
數倉模型的選擇是靈活的，不局限於某種模型方法。
數倉數據是靈活的，以實際需求場景為導向。
數倉設計要兼顧靈活性、可擴展性，要考慮技術可靠性和實現成本。
系統分析，確定主題。通過與業務部門的交流，了解建立數倉要解決的問題，確認各個主題下的查詢分析要求選擇滿足數據倉庫系統要求的軟件平臺。選擇合適的軟件平臺，包括數據庫、建模工具、分析工具等建立數據倉庫的邏輯模型。確定建立數據倉庫邏輯模型的基本方法，基於主題視圖，把主題視圖中的數據定義轉到邏輯數據模型中邏輯數據模型轉換為數據倉庫數據模型數據倉庫數據模型優化。隨著需求和數據量的變化進行調整數據清洗轉換和傳輸。業務系統中的數據加載到數據倉庫之前，必須進行數據的清洗和轉換，保證數據倉庫中數據的壹致性。開發數據倉庫的分析應用。滿足業務部門對數據進行分析的需求。數據倉庫的管理。包括數據庫管理和元數據管理。什麽是數據中臺？
數據中臺是指通過數據技術，對海量數據進行采集、計算、存儲、加工，同時統壹標準和口徑。數據中臺吧數據統壹之後，會形成標準數據，再進行存儲，形成大數據資產層，進而為客戶提供高效服務。
這些服務和企業的業務有較強的關聯性，是企業所獨有且能復用的，它是企業業務和數據的積澱，其不僅能降低重復建設，減少煙囪式協作的成本，也是差異化競爭的優勢所在。
數據中臺通過整合公司開發工具、打通全域數據、讓數據持續為業務賦能，實現數據平臺化、數據服務化和數據價值化。數據中臺更加側重於“復用”與“業務”。
數據中臺、數據倉庫、大數據平臺的關鍵區別是什麽？
基礎能力上的區別
數據平臺：提供的是計算和存儲能力
數據倉庫：利用數據平臺提供的計算和存儲能力，在壹套方法論指導下建設的壹整套的數據表
數據中臺：包含了數據平臺和數據倉庫的所有內容，將其打包，並且以更加整合以及更加產品化的方式對外提供服務和價值。
業務能力上的區別
數據平臺：為業務提供數據主要方式是提供數據集
數據倉庫：相對具體的功能概念是存儲和管理壹個或多個主題數據的集合，為業務提供服務的方式主要是分析報表
數據中臺：企業級的邏輯概念，提現企業數據產生價值的能力，為業務提供服務的主要方式是數據API
總的來說，數據中臺距離業務更近，數據復用能力更強，能為業務提供速度更快的服務。數據中臺是在數據倉庫和數據平臺的基礎上，將數據生產為壹個個數據API服務，以更高效的方式提供給業務。數據中臺可以建立在數據倉庫和數據平臺之上，是加速企業從數據到業務價值的過程的中間層。
大數據的壹些相關系統？
數倉設計中心：按照主題域、業務過程，分層的設計方式，以維度建模作為基本理論依據，按照維度、度量設計模型，確保模型、字段有統壹的命名規範
數據資產中心：梳理數據資產，基於數據血緣，數據的訪問熱度，做成本的治理
數據質量中心：通過豐富的稽查監控系統，對數據進行事後校驗，確保問題數據第壹時間被發現，避免下遊的無效計算，分析數據的影響範圍。
指標系統：管理指標的業務口徑、計算邏輯和數據來源，通過流程化的方式，建立從指標需求、指標開發、指標發布的全套協作流程。
數據地圖：提供元數據的快速索引，數據字典、數據血緣、數據特征信息的查詢，相當於元數據中心的門戶。
如何建設數據中臺？
數據中臺在企業落地實踐時，結合技術、產品、數據、服務、運營等方面，逐步開展相關工作。
理現狀。了解業務現狀、數據現狀、IT現狀、現有的組織架構定架構。確認業務架構、技術架構、應用架構、組織架構建資產。建立貼近數據層、統壹數倉層、標簽數據層、應用數據層用數據。對數據進行輸出、應用。數據運營。持續運營、持續叠代。中臺建設需要有全員***識，由管理層從上往下推進，由技術和業務人員去執行和落地是壹個漫長的過程，在實施數據中臺時，最困難的地方就是需要有人推動。
數據湖的理解？
數據湖是壹個存儲企業的各種各樣原始數據的大型倉庫，其中的數據可供存取、處理、分析及傳輸。
數倉最重要的是什麽？
個人認為是數據集成。
企業的數據通常是存儲在多個異構數據庫中的，要進行分析，必須先要對數據進行壹致性整合。
集成整合後才可以對數據進行分析、挖掘數據潛在的價值。
概念數據模型、邏輯數據模型、物理數據模型
概念數據模型設計與邏輯數據模型設計、物理數據模型設計是數據庫及數據倉庫模型設計的三個主要步驟。
概念數據模型CDM
概念數據模型是最終用戶對數據存儲的看法，反映了最終用戶綜合性的信息需求，以數據類的方式描述企業級的數據需求。
概念數據模型的內容包括重要的實體與實體之間的關系。在概念數據模型中不包含實體的屬性，也不包含定義實體的主鍵
概念數據模型的目標是統壹業務概念，作為業務人員和技術人員之間溝通的橋梁，確定不同實體之間的最高層次的關系
邏輯數據模型LDM
邏輯數據模型反應的是系統分析設計人員對數據存儲的觀點，是對概念數據模型的進壹步的分解和細化。邏輯數據模型是根據業務規則確定的，關於業務對象、業務對象的數據項以及業務對象之間關系的基本藍圖。
邏輯數據模型的內容包括所有的實體和關系，確定每個實體的屬性，定義每個實體的主鍵，指定實體的外鍵，需要進行範式化處理。
邏輯數據模型的目標是盡可能詳細的描述數據，但並不考慮在物理上如何實現。
物理數據模型PDM
物理數據模型是在邏輯數據模型的基礎上，考慮各種具體的技術實現因素，進行數據庫體系結構設計，真正實現數據在數據庫中的存放。
物理數據模型的內容包括確定所有的表和列，定義外鍵用於確認表之間的關系，基於用戶的需求可能要進行反範式化等內容。
SCD的常用處理方式？
slowly changing dimensions緩慢變化維度
不記錄歷史變化信息添加列來記錄歷史變化新插入數據行，並添加對應標識字段來記錄歷史數據。拉鏈表。元數據的理解？
狹義來講就是用來描述數據的數據
廣義來看，除了業務邏輯直接讀寫處理的業務數據，所有其他用來維護整個系統運轉所需要的數據，都可以較為元數據。
定義：元數據metadata是關於數據的數據。在數倉系統中，元數據可以幫助數據倉庫管理員和數據倉庫開發人員方便的找到他們所關心的數據；元數據是描述數據倉庫內部數據的結構和建立方法的數據。按照用途可分為：技術元數據、業務元數據。
技術元數據
存儲關於數據倉庫技術細節的數據，用於開發和管理數據倉庫使用的數據
數據倉庫結構的描述，包括數據模式、視圖、維、層次結構和導出數據的定義，以及數據集市的位置和內容業務系統、數據倉庫和數據集市的體系結構和模式由操作環境到數據倉庫環境的映射，包括元數據和他們的內容、數據提取、轉換規則和數據刷新規則、權限等。業務元數據
從業務角度描述了數據倉庫中的數據，他提供了介於使用者和實際系統之間的語義層，使不懂計算機技術的業務人員也能讀懂數倉中的數據。
企業概念模型：表示企業數據模型的高層信息。整個企業業務概念和相互關系。以這個企業模型為基礎，不懂sql的人也能做到心中有數多維數據模型。告訴業務分析人員在數據集市中有哪些維、維的類別、數據立方體以及數據集市中的聚合規則。業務概念模型和物理數據之間的依賴。業務視圖和實際數倉的表、字段、維的對應關系也應該在元數據知識庫中有所體現。元數據管理系統？
元數據管理往往容易被忽視，但是元數據管理是不可或缺的。壹方面元數據為數據需求方提供了完整的數倉使用文檔，幫助他們能自主快速的獲取數據；另壹方面數倉團隊可以從日常的數據解釋中解脫出來，無論是對後期的叠代更新還是維護，都有很大的好處。元數據管理可以讓數據倉庫的應用和維護更加的高效。
元數據管理功能
數據地圖：以拓撲圖的形式對數據系統的各類數據實體、數據處理過程元數據進行分層次的圖形化展示，並通過不同層次的圖形展現。元數據分析：血緣分析、影響分析、實體關聯分析、實體差異分析、指標壹致性分析。輔助應用優化：結合元數據分析功能，可以對數據系統的應用進行優化。輔助安全管理：采用合理的安全管理機制來保障系統的數據安全；對數據系統的數據訪問和功能使用進行有效監控。基於元數據的開發管理：通過元數據管理系統規範日常開發的工作流程元數據管理標準
對於相對簡單的環境，按照通用的元數據管理標準建立壹個集中式的元數據知識庫
對於比較復雜的環境，分別建立各部分的元數據管理系統，形成分布式元數據知識庫，然後通過建立標準的元數據交換格式，實現元數據的集成管理。
數倉如何確定主題域？
主題
主題是在較高層次上將數據進行綜合、歸類和分析利用的壹個抽象概念，每壹個主題基本對應壹個宏觀的分析領域。在邏輯意義上，它是對企業中某壹宏觀分析領域所涉及的分析對象。
面向主題的數據組織方式，就是在較高層次上對分析對象數據的壹個完整並且壹致的描述，能刻畫各個分析對象所涉及的企業各項數據，以及數據之間的聯系。
主題是根據分析的要求來確定的。
主題域
從數據角度看（集合論）
主題語通常是聯系較為緊密的數據主題的集合。可以根據業務的關註點，將這些數據主題劃分到不同的主題域。主題域的確定由最終用戶和數倉設計人員***同完成。
從需要建設的數倉主題看（邊界論）
主題域是對某個主題進行分析後確定的主題的邊界。
數倉建設過程中，需要對主題進行分析，確定主題所涉及到的表、字段、維度等界限。
確定主題內容
數倉主題定義好以後，數倉中的邏輯模型也就基本成形了，需要在主題的邏輯關系中列出屬性和系統相關行為。此階段需要定義好數據倉庫的存儲結構，向主題模型中添加所需要的信息和能充分代表主題的屬性組。
如何控制數據質量？
校驗機制，每天進行數據量的比對 select count(*)，早發現，早修復
數據內容的比對，抽樣比對
復盤、每月做壹次全量
如何做數據治理？
數據治理不僅需要完善的保障機制，還需要理解具體的治理內容，比如數據應該怎麽進行規範，元數據該怎麽來管理，每個過程需要那些系統或者工具來配合？
數據治理領域包括但不限於以下內容：數據標準、元數據、數據模型、數據分布、數據存儲、數據交換、數據聲明周期管理、數據質量、數據安全以及數據***享服務。
模型設計的思路？業務驅動？數據驅動？
構建數據倉庫有兩種方式：自上而下、自下而上
Bill Inmon推崇自上而下的方式，壹個企業建立唯壹的數據中心，數據是經過整合、清洗、去掉臟數據、標準的、能夠提供統壹的視圖。要從整個企業的環境入手，建立數據倉庫，要做很全面的設計。偏數據驅動
Ralph Kimball推崇自下而上的方式，認為數據倉庫應該按照實際的應用需求，架子啊需要的數據，不需要的數據不要加載到數據倉庫中。這種方式建設周期短，用戶能很快看到結果。偏業務驅動
數據質量管理
數據質量管理是對數據從計劃、獲取、存儲、***享、維護、應用、消亡生命周期的每個階段裏可能引發的數據質量問題，進行識別、度量、監控、預警等，通過改善了提高組織的管理水平使數據質量進壹步提高。
數據質量管理是壹個集方法論、技術、業務和管理為壹體的解決方案。放過有效的數據質量控制手段，進行數據的管理和控制，消除數據質量問題，從而提高企業數據變現的能力。
會遇到的數據質量問題：數據真實性、數據準確性、數據壹致性、數據完整性、數據唯壹性、數據關聯性、數據及時性
什麽是數據模型？
數據模型就是數據組織和存儲的方法，通過抽象的實體以及實體間聯系的形式來表達現實世界中事務的相互關系的壹種映射，他強調從業務、數據存取和使用角度合理的存儲數據。
為什麽需要數據倉庫建模？
數倉建模需要按照壹定的數據模型，對整個企業的數據進行采集，整理，提供跨部門、完全壹致的報表數據。
合適的數據模型，對於大數據處理來講，可以獲得得更好的性能、成本、效率和質量。良好的模型可以幫助我們快速查詢數據，減少不必要的數據冗余，提高用戶的使用效率。
數據建模進行全方面的業務梳理，改進業務流程，消滅信息孤島，更好的推進數倉系統的建設。
OLAP和OLTP的模型方法的選擇？
OLTP系統是操作事物型系統，主要數據操作是隨機讀寫，主要采用滿足3NF的實體關系模型存儲數據，在事物處理中解決數據的冗余和壹致性問題。
OLAP系統是分析型系統，主要數據操作是批量讀寫，不需要關註事務處理的壹致性，主要關註數據的整合，以及復雜大數據量的查詢和處理的性能。
3範式
每個屬性值唯壹，不具有多義性
每個非主屬性必須完全依賴於整個主鍵，而非主鍵的壹部分
每個非主屬性不能依賴於其他關系中的屬性
數據倉庫建模方法？
有四種模型：ER模型、維度模型、Data Vault模型、Anchor模型。用的較多的是維度模型和ER模型。
ER模型
ER模型用實體關系模型描述企業業務，在範式理論上滿足3NF。數倉中的3NF是站在企業角度面向主題的抽象，而不是針對某個具體業務流程的實體對象關系的抽象。
采用ER模型建設數據倉庫模型的出發點是整合數據，將各個系統中的數據按照主題進行相似性整合，並進行壹致性處理。
ER模型特點：
需要全方位了解企業業務數據
實施周期較長
對建模人員要求教高
維度建模
維度建模按照事實表和維度表來構建數倉。
維度建模從分析決策的需求出發構建模型，為分析需求服務。重點關註用戶如何快速的完成數據分析，可以直觀的反應業務模型中的業務問題，需要大量的數據預處理、數據冗余，有較好的大規模復雜查詢的響應性能。
事實表
發生在現實世界中的操作性事件，其產生的可度量數值，存儲在事實表中。從最細粒度級別來看，事實表的壹行對應壹個度量事件。事實表表示對分析主題的度量。
事實表中包含了與各個維度表相關聯的外鍵，可與維度表關聯。事實表的度量通常是數值類型，且記錄數不斷增加，表數據量迅速增長。
維度表
維度表示分析數據時所用的環境。
每個維度表都包含單獨的主鍵列。維度表行的描述環境應該與事實表行完全對應。維度表通常比較寬，是扁平型的非規範表，包含大量的低粒度的文本屬性。
註意：
事實表的設計是以能夠正確記錄歷史信息為準則
維度表的設計是以能夠以合適的角度來聚合主題內容為準則
維度建模的三種模式
星形模型：以事實表為中心，所有的維度直接連接在事實表上。由壹個事實表和壹組維度表組成。
雪花模型：是對星形模型的擴展。雪花模型的維度表可以擁有更細的維度，比星形更規範壹點。維護成本較高，且查詢是要關聯多層維表，性能較低
星座模型：基於多張事實表，多張事實表***享維度信息
維度建模步驟：
選擇業務過程
選擇粒度
選定事實表
選擇維度
事實表的類型？
事實表有：事務事實表、周期快照事實表、累積快照事實表、非事實事實表
事務事實表
事務事實表記錄的是事務層面的事實，保存的是最原子的數據，也稱“原子事實表”。事務事實表中的數據在事務事件發生後產生，數據的粒度通常是每個事務記錄壹條記錄。
周期快照事實表
以具有規律性的、可預見的時間間隔來記錄事實。它統計的是間隔周期內的度量統計，每個時間段壹條記錄，是在事務事實表之上建立的聚集表。
累積快照事實表
累積快照表記錄的不確定的周期的數據。代表的是完全覆蓋壹個事務或產品的生命周期的時間跨度，通常具有多個日期字段，用來記錄整個生命周期中的關鍵時間點。
非事實型事實表
在維度建模的數據倉庫中，有壹種事實表叫Factless Fact Table，中文壹般翻譯為“非事實型事實表”。在事實表中，通常會保存十個左右的維度外鍵和多個度量事實，度量事實是事實表的關鍵所在。在非事實型事實表中沒有這些度量事實，只有多個維度外鍵。非事實型事實表通常用來跟蹤壹些事件或者說明某些活動的範圍。下面舉例來進行說明。
第壹類非事實型事實表是用來跟蹤事件的事實表。例如：學生註冊事件，學校需要對學生按學期進行跟蹤。維度表包括學期維度、課程維度、系維度、學生維度、註冊專業維度和取得學分維度，而事實表是由這些維度的主鍵組成，事實只有註冊數，並且恒為1。這樣的事實表可以回答大量關於大學開課註冊方面的問題，主要是回答各種情況下的註冊數。
第二類非事實型事實表是用來說明某些活動範圍的事實表。例如：促銷範圍事實表。通常銷售事實表可以回答如促銷商品的銷售情況，但是對於那些沒有銷售出去的促銷商品沒法回答。這時，通過建立促銷範圍事實表，將商場需要促銷的商品單獨建立事實表保存。然後，通過這個促銷範圍事實表和銷售事實表即可得出哪些促銷商品沒有銷售出去。這樣的促銷範圍事實表只是用來說明促銷活動的範圍，其中沒有任何事實度量。
事實表中通常要保留度量事實和多個維度外鍵，度量事實是事實表的關鍵所在。
非事實表中沒有這些度量事實，只有多個維度外鍵。非事實型事實表通常用來跟蹤壹些事件或說明某些活動的範圍。
第壹類非事實型事實表是用來跟蹤事件的事實表。例如：學生註冊事件。
第二類非事實型事實表是用來說明某些活動範圍的事實表。例如：促銷範圍事實表。
數倉架構為什麽要分層?
分層可以清晰數據結構，使用時更好的定位和理解方便追蹤數據的血緣關系規範數據分層，可以開發壹些通用的中間層數據，能夠減少極大的重復計算把復雜問題簡單化屏蔽原始數據的異常。不必改壹次業務就重新接入數據數據分層思想？
理論上數據分為：操作數據層、數據倉庫層、數據服務層。可根據需要添加新的層次，滿足不同的業務需求。
操作數據層ODS
Operate Data Store操作數據存儲。數據源中的數據經過ETL後裝入ODS層。
ODS層數據的來源壹般有：業務數據庫、日誌、抓取等。
數據倉庫層DW
根據ODS層中的數據按照主題建立各種數據模型。
DW通常有：DWD、DWB、DWS
DWD: data warehouse detail細節數據層，是業務層和數據倉庫的隔離層。
DWB: data warehouse base基礎數據層，存儲的是客觀數據，壹般用作於中間層。
DWS: data warehouse service服務數據層，整合匯總分析某個主題域的服務數據。壹般是大寬表。
數據服務層/應用層ADS
該層主要提供數據產品和數據分析使用的數據，壹般會放在ES、Mysql系統中供線上系統使用
數倉架構進化
經典數倉架構：使用傳統工具來建設數倉
離線大數據架構：開始使用大數據工具來替代經典數倉中的傳統工具
Lambda架構：在離線大數據架構的基礎上，使用流處理技術直接完成實時性較高的指標計算
Kappa：實時處理變成了主要的部分，出現了以實時處理為核心的kappa架構
離線大數據架構
數據源通過離線的方式導入離線數倉中。下遊應用根據業務需求選擇獲取數據的方式
Lambda架構
在離線數倉的基礎上增加了實時計算的鏈路，並對數據源進行流式改造，實時計算去訂閱消息隊列，並推送到下遊的數據服務中去。
Lambda架構問題：同樣的需求需要開發兩套壹樣的代碼；資源占用增多
Kappa架構
kappa架構可以認為是lambda架構的簡化版，移除了lambda架構中的批處理部分。
在kappa架構中，需求修改或者歷史數據重新處理都通過上遊重放完成
kappa架構最大的問題是流式重新處理歷史數據的吞吐能力會低於批處理，但可以通過增加計算資源來彌補
總結
真實場景中，是lambda架構和kappa架構的混合。大部分實時指標通過kappa架構計算，少量關鍵指標用lambda架構批量計算
隨著數據多樣性的發展，數據庫這種提前規定schema的模式顯得力不從心。這時出現了數據湖技術，把原始數據全部緩存到某個大數據存儲上，後續分析時根據需求去解析原始數據。簡單來說，數據倉庫模式是schema on write，數據湖模式是schema on read
OLAP簡介
OLAP（On-line Analytical Processing），聯機分析處理，其主要的功能在於方便大規模數據分析及統計計算，對決策提供參考和支持。
特點：數據量大、高速響應、靈活交互、多維分析
OLAP分類
存儲類型分類
ROLAP（RelationalOLAP）
MOLAP（MultimensionalOLAP）
HOLAP（HybridOLAP）
處理類型分類
MPP架構
搜索引擎架構
預處理架構
開源OLAP解決方案
Persto、SparkSQL、Impala等MPP架構和ROLAP的引擎Druid和Kylin等預處理架構和MOLAP的引擎ES這種搜索引擎架構ClickHouse及IndexR這種列式數據庫OLAP引擎
Presto
Facebook開發的分布式大數據SQL查詢引擎，專門進行快速數據分析
特點
可以將多個數據源的數據進行合並，可以跨越整個組織進行分析直接從HDFS讀取數據，在使用前不需要大量的ETL操作查詢原理
完全基於內存的並行計算
流水線
本地化計算
動態編譯執行計劃
小心使用內存和數據結構
類BlinkDB的近似查詢
GC控制
Druid
Druid是壹個用於實時查詢和分析的分布式實時處理系統，主要用於廣告分析，互聯網廣告監控、度量和網絡監控
特點
快速的交互式查詢——Druid的低延遲數據攝取架構允許事件在它們創建後毫秒內可被查詢到。高可用性——Druid的數據在系統更新時依然可用，規模的擴大和縮小都不會造成數據丟失；可擴展——Druid已實現每天能夠處理數十億事件和TB級數據。為分析而設計——Druid是為OLAP工作流的探索性分析而構建，它支持各種過濾、聚合和查詢應用場景
需要實時查詢分析具有大量數據時，如每天數億事件的新增、每天數10T數據的增加；需要壹個高可用、高容錯、高性能數據庫時。需要交互式聚合和快速探究大量數據時Kylin
Kylin是提供與Hadoop之上的SQL查詢接口及多維分析能力以支持超大規模數據