1. 摘要
對於大數據而言，數據倉庫承載着整個企業的全業務的數據。早期數倉在關系型數據如Oracle，MySql上。到大數據時代，基於hadoop生態的大數據架構，數倉基本上都是基於hive的數倉。對於很多大數據開發者而言，特別是早期，很多開發者認為hive數倉就是和業務相關，隱射Hdfs數據文件的一張張表。針對於hive數倉而言，最終看到的確實是一張紙表，但這些表是如何根據業務抽象出來的、表之間的關系、表如何更好的服務應用這些問題是數倉建模、數倉技術架構的核心。一個好的數倉技術架構和數倉建模。可以減少開發的難度，提高數據服務性能，同時能夠在很大層面上對業務形成數據中心，降低存儲，計算資源的消耗等等
2.數倉架構的演變
傳統經典數倉架構->離線數倉架構->實時數倉架構->Lambda數倉架構->Kappa數倉架構->混合數倉架構
a.傳統數倉架構在大數據領域應用不多了，這類架構在早期數據量不大，對性能的要求不高，業務較單一的場景中應用比較多，這類數倉主要以oracle，mysql這種關系型數據庫的范式設計原則設計
b.離線數倉架構是在大數據領域應運而生的。主要是基於hadoop生態組件的大數據技術架構方案中以hive為主的，在設計層面遵循和借鑒傳統數倉的設計思路和規范，在計算上則以分布式計算為主提高數據的操作性能
c.實時數倉是近幾年提出的一種數倉架構，與離線數倉方案有相似之處，不同之處在於數據是實時的。這也是整個大數據從離線分布式計算邁向實時流計算過程中產生的。但個人認為實時數倉方案還有很多不成熟的地方，在業務場景中還是有很多局限性
d.對於Lambda數倉架構，Kappa數倉架構，混合數倉架構這些架構更多的是應對與特定場景，這類數倉架構方案不具備一定的通用性
3.數倉的邏輯分層
4.數倉的設計步驟與原則
4.1.數據調研
a.業務場景調研
需要明確業務場景的分類，比如行業類大概有電商場景，電信運營商場景，社交場景等等，這些場景不同帶來的是需求不同，需求不同則帶來的是模型之間的差異化
b.需求調研
不同的場景不同的需求，比如很多企業的數倉更多是服務於數據可視化BI,有的服務於應用系統，有的服務於2C端。這些業務需求在統計、用戶畫像，推薦上等等的功能都有差異化
c.模型調研
根據實際業務場景，將業務側對齊，遵循關系型數據庫建模方式，從概念模型（cdm）->邏輯模型（ldm）->物理模型（pdm）建模套路，是一個從抽象到具體的一個不斷細化完善的分析，設計和開發的過程。
4.2.數倉建模
經典抽象建模四步驟:選擇業務過程->聲明粒度->確定維度->確定事實 進行維度建模。
常用的業務實體建模方法:維度模型、范式模型、Data-Valut模型、Anchor模型
其中維度模型是大數據數倉的最常用的模型，范式模型是傳統的數倉常用的，其他兩種模型較為少見，針對特點的場景。而維度模型根據數據組織類型又划分為星型模型、雪花模型、星座模型
a.星型模型
星型模型主要是維表和事實表，以事實表為中心，所有維度直接關聯在事實表上，呈星型分布。可以初略理解為如果用星型模型設計數倉的表時。一個業務實體中多個表的關系是一對多，one(事實表)2many(維度表)。星型模型是基於hadoop生態的大數據用的最多的一種模型
什么是維度表？
維度表可以看成是用戶用來分析一個事實的窗口，它里面的數據應該是對事實的各個方面描述，比如時間維度表，它里面的數據就是一些日，周，月，季，年，日期等數據，維度表只能是事實表的一個分析角度。
什么是事實表？
事實表其實質就是通過各種維度和一些指標值得組合來確定一個事實的，比如通過時間維度，地域組織維度，指標值可以去確定在某時某地的一些指標值怎么樣的事實。事實表的每一條數據都是幾條維度表的數據和指標值交匯而得到的
示例：
b.雪花模型
雪花模型，在星型模型的基礎上，維度表上又關聯了其他維度表。這種模型使用過程中會造成大量的join，維護成本高，性能方面也較差，所以一般不建議使用。尤其是基於hadoop體系構建數倉，減少join就是減少shuffle，性能差距會很大。
c.星座模型
星座模型，是對星型模型的擴展延伸，多張事實表共享維度表。數倉模型建設后期，當一個星型模型為一個實體，又有多個是實體，實體間又共用維表(這個是很常見的)，就自然成了星座模型了。大部分維度建模都是星座模型。
4.2.數倉規范
構建企業級數據倉庫，必不可少的就是制定數倉規范。包括 命名規范，流程規范，設計規范，開發規范 等。
開發規范 示例：
4.3.基於模型的數據開發語言
開發語言，傳統數倉一般SQL/Shell為主，互聯網數倉又對Python、Java、Scala提出了新的要求。不管是傳統數倉，還是基於Hadoop生態的構建的(hive、spark、flink)數倉，SQL雖然戲碼在下降，但依然是重頭戲。
在數倉中sql的基本操作既簡單又實用，sql中比較復雜和重要的就是join，下面用一張圖清晰的解釋了各種join的邏輯
SQL開發規范：
在大數據生態，不管哪種數據處理框架，總有一天都會孵化出強大SQL的支持。如Hive SQL，Spark SQL，Blink SQL 等。但本質上還是SQL
5.數據治理
大數據時代必不可少的一個重要環節，可從元數據管理、業務實體數據，數據質量、數據安全、數據生命周期等方面開展實施。數據治理是一個企業安身立命的根本。
元數據:
業務實體數據的標識，在大數據領域，一個數倉可以有成百上千，甚至成千上萬或更多的表。這些表的含義，表的每個字段的含義只有通過元數據才能知道。
業務實體數據：
業務產生的數據的數據內容，業務實體數據以外的數據表都是為其服務的。
數據質量：
保證業務實體數據完整性、准確性、一致性、時效性。每一個操作業務實體數據的任務都應該配置數據質量監控，嚴禁任務裸奔。可建設統一數據質量告警中心從以下四個方面進行監控、預警和優化任務。
數據安全：
即數據的保密性、真實性、完整性、未授權拷貝和所寄生系統的安全性。
數據生命周期：
對於某些數據，用完可以刪除掉，以便減少存儲空間，數據生命周期數據定義了每個業務實體數據的周期，是否為熱數據或冷數據，是否需要永久保留還是完成對應功能即可刪除等
6.數倉的衍生
隨着大數據的發展及互聯網巨頭對大數據技術的深耕及奉獻，特別是阿里。在數倉的基礎上衍生了數據湖和數據集市的概念
數據湖：
是一個集中化存儲海量的、多個來源，多種類型數據，並可以對數據進行快速加工，分析的平台，本質上是一套先進的企業數據架構，關於數據湖的更多個人覺得這篇博文(http://www.raincent.com/content-10-14037-1.html)說的比較詳細
數據集市
滿足特定的部門或者用戶的需求，按照多維的方式進行存儲，包括定義維度、需要計算的指標、維度的層次等，生成面向決策分析需求的數據立方體。