資料倉庫的定義？
首先，用于支援決策，面向分析型資料處理；其次，對多個異構的資料源有效內建，內建後按照主題進行重組，并包含曆史資料，而且存放在資料倉庫中的資料一般不再修改。
資料倉庫(Data Warehouse)是一個面向主題的(subject oriented)、內建的(integrated)、相對穩定的(non-volatile)、反應曆史變化(time variant)的資料集合，用于支援管理決策(decision making support)。
資料倉庫和資料庫的差別？
從目标、用途、設計來說
- 資料庫是面向事物處理的，資料是由日常的業務産生的，常更新；資料倉庫是面向主題的，資料來源多樣，經過一定的規則轉換得到，用來分析。
- 資料庫一般用來存儲目前事務性資料，如交易資料；資料倉庫一般存儲的曆史資料。
- 資料庫的設計一般是符合三範式的，有最大的精确度和最小的備援度，有利于資料的插入；資料倉庫的設計一般不符合三範式，有利于查詢
如何建構資料倉庫？
數倉模型的選擇是靈活的，不局限于某種模型方法。
數倉資料是靈活的，以實際需求場景為導向。
數倉設計要兼顧靈活性、可擴充性，要考慮技術可靠性和實作成本。
https://www.zhihu.com/question/19703294
- 系統分析，确定主題。通過與業務部門的交流，了解建立數倉要解決的問題，确認各個主題下的查詢分析要求
- 選擇滿足資料倉庫系統要求的軟體平台。選擇合适的軟體平台，包括資料庫、模組化工具、分析工具等
- 建立資料倉庫的邏輯模型。确定建立資料倉庫邏輯模型的基本方法，基于主題視圖，把主題視圖中的資料定義轉到邏輯資料模型中
- 邏輯資料模型轉換為資料倉庫資料模型
- 資料倉庫資料模型優化。随着需求和資料量的變化進行調整
- 資料清洗轉換和傳輸。業務系統中的資料加載到資料倉庫之前，必須進行資料的清洗和轉換，保證資料倉庫中資料的一緻性。
- 開發資料倉庫的分析應用。滿足業務部門對資料進行分析的需求。
- 資料倉庫的管理。包括資料庫管理和中繼資料管理。
什麼是資料中台？
資料中台是指通過資料技術，對海量資料進行采集、計算、存儲、加工，同時統一标準和口徑。資料中台吧資料統一之後，會形成标準資料，再進行存儲，形成大資料資産層，進而為客戶提供高效服務。
這些服務和企業的業務有較強的關聯性，是企業所獨有且能複用的，它是企業業務和資料的積澱，其不僅能降低重複建設，減少煙囪式協作的成本，也是差異化競争的優勢所在。
資料中台通過整合公司開發工具、打通全域資料、讓資料持續為業務賦能，實作資料平台化、資料服務化和資料價值化。資料中台更加側重于“複用”與“業務”。
資料中台、資料倉庫、大資料平台的關鍵差別是什麼？
基礎能力上的差別
資料平台：提供的是計算和存儲能力
資料倉庫：利用資料平台提供的計算和存儲能力，在一套方法論指導下建設的一整套的資料表
資料中台：包含了資料平台和資料倉庫的所有内容，将其打包，并且以更加整合以及更加産品化的方式對外提供服務和價值。
業務能力上的差別
資料平台：為業務提供資料主要方式是提供資料集
資料倉庫：相對具體的功能概念是存儲和管理一個或多個主題資料的集合，為業務提供服務的方式主要是分析報表
資料中台：企業級的邏輯概念，提現企業資料産生價值的能力，為業務提供服務的主要方式是資料API
總的來說，資料中台距離業務更近，資料複用能力更強，能為業務提供速度更快的服務。資料中台是在資料倉庫和資料平台的基礎上，将資料生産為一個個資料API服務，以更高效的方式提供給業務。資料中台可以建立在資料倉庫和資料平台之上，是加速企業從資料到業務價值的過程的中間層。
大資料的一些相關系統？
數倉設計中心：按照主題域、業務過程，分層的設計方式，以次元模組化作為基本理論依據，按照次元、度量設計模型，確定模型、字段有統一的命名規範
資料資産中心：梳理資料資産，基于資料血緣，資料的通路熱度，做成本的治理
資料品質中心：通過豐富的稽查監控系統，對資料進行事後校驗，確定問題資料第一時間被發現，避免下遊的無效計算，分析資料的影響範圍。
名額系統：管理名額的業務口徑、計算邏輯和資料來源，通過流程化的方式，建立從名額需求、名額開發、名額釋出的全套協作流程。
資料地圖：提供中繼資料的快速索引，資料字典、資料血緣、資料特征資訊的查詢，相當于中繼資料中心的門戶。
如何建設資料中台？
資料中台在企業落地實踐時，結合技術、産品、資料、服務、營運等方面，逐漸開展相關工作。
- 理現狀。了解業務現狀、資料現狀、IT現狀、現有的組織架構
- 定架構。确認業務架構、技術架構、應用架構、組織架構
- 建資産。建立貼近資料層、統一數倉層、标簽資料層、應用資料層
- 用資料。對資料進行輸出、應用。
- 資料營運。持續營運、持續疊代。
中台建設需要有全員共識，由管理層從上往下推進，由技術和業務人員去執行和落地是一個漫長的過程，在實施資料中台時，最困難的地方就是需要有人推動。
資料湖的了解？
資料湖是一個存儲企業的各種各樣原始資料的大型倉庫，其中的資料可供存取、處理、分析及傳輸。
數倉最重要的是什麼？
個人認為是資料內建。
企業的資料通常是存儲在多個異構資料庫中的，要進行分析，必須先要對資料進行一緻性整合。
內建整合後才可以對資料進行分析、挖掘資料潛在的價值。
概念資料模型、邏輯資料模型、實體資料模型
概念資料模型設計與邏輯資料模型設計、實體資料模型設計是資料庫及資料倉庫模型設計的三個主要步驟。
概念資料模型CDM
conceptual data model
概念資料模型是最終使用者對資料存儲的看法，反映了最終使用者綜合性的資訊需求，以資料類的方式描述企業級的資料需求。
概念資料模型的内容包括重要的實體與實體之間的關系。在概念資料模型中不包含實體的屬性，也不包含定義實體的主鍵
概念資料模型的目标是統一業務概念，作為業務人員和技術人員之間溝通的橋梁，确定不同實體之間的最高層次的關系
邏輯資料模型LDM
logical data model
邏輯資料模型反應的是系統分析設計人員對資料存儲的觀點，是對概念資料模型的進一步的分解和細化。邏輯資料模型是根據業務規則确定的，關于業務對象、業務對象的資料項以及業務對象之間關系的基本藍圖。
邏輯資料模型的内容包括所有的實體和關系，确定每個實體的屬性，定義每個實體的主鍵，指定實體的外鍵，需要進行範式化處理。
邏輯資料模型的目标是盡可能詳細的描述資料，但并不考慮在實體上如何實作。
實體資料模型PDM
physical data model
實體資料模型是在邏輯資料模型的基礎上，考慮各種具體的技術實作因素，進行資料庫體系結構設計，真正實作資料在資料庫中的存放。
實體資料模型的内容包括确定所有的表和列，定義外鍵用于确認表之間的關系，基于使用者的需求可能要進行反範式化等内容。
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查詢接口及多元分析能力以支援超大規模資料
特點
- 使用者為百億以上資料集定義資料模型并建構立方體
- 亞秒級的查詢速度，同時支援高并發
- 為Hadoop提供标準SQL支援大部分查詢功能
- 提供與BI工具，如Tableau的整合能力
- 友好的web界面以管理，監控和使用立方體
- 項目及立方體級别的通路控制安全