一、數據倉庫定義
簡單理解：數據倉庫就是整合多個數據源的歷史數據進行細粒度的、多維的分析，幫助高層管理者或者業務分析人員做出商業戰略決策或商業報表。
官方定義：數據倉庫是一個面向主題的（主題明確）、集成的（從不同的數據源采集到同一個數據源）、隨時間變化的（關鍵數據是可變的可更新的）、但信息本身相對穩定（一般只進行查詢的操作）的數據集合，用於對管理決策過程的支持。
二、數據倉庫應用
| 差異項 | 數據庫 | 數據倉庫 |
|---|---|---|
| 特征 | 操作處理 | 信息處理 |
| 面向 | 事務 | 分析 |
| 用戶 | DBA、開發 | 經理、主管、分析人員 |
| 功能 | 日常操作 | 長期信息需求、決策支持 |
| DB設計 | 基於ER模型，面向應用 | 星形/雪花模型，面向主題 |
| 數據 | 當前的、最新的 | 歷史的、跨時間維護 |
| 匯總 | 原始的、高度詳細 | 匯總的、統一的 |
| 視圖 | 詳細、一般關系 | 匯總的、多維的 |
| 工作單元 | 短的、簡單事務 | 復雜查詢 |
| 訪問 | 讀/寫 | 大多為讀 |
| 關注 | 數據進入 | 信息輸出 |
| 操作 | 主鍵索引操作 | 大量的磁盤掃描 |
| 用戶數 | 數百到數億 | 數百 |
| DB規模 | GB到TB | >=TB |
| 優先 | 高性能、高可用性 | 高靈活性 |
| 度量 | 事務吞吐量 | 查詢吞吐量、響應時間 |
三、數據倉庫架構
(一)簡單架構
數據采集
數據采集層的任務就是把數據從各種數據源中采集和存儲到數據存儲上，期間有可能會做一些ETL操作。
數據源種類可以有多種：
- 日志：所占份額最大，存儲在備份服務器上
- 業務數據庫：如Mysql、Oracle
- 來自HTTP/FTP的數據：合作伙伴提供的接口
- 其他數據源：如Excel等需要手工錄入的數據
數據存儲與分析
HDFS是大數據環境下數據倉庫/數據平台最完美的數據存儲解決方案。
離線數據分析與計算，也就是對實時性要求不高的部分，Hive是不錯的選擇。
使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很樂意開發Java，或者對SQL不熟，那么也可以使用MapReduce來做分析與計算。
Spark性能比MapReduce好很多，同時使用SparkSQL操作Hive。
數據共享
前面使用Hive、MR、Spark、SparkSQL分析和計算的結果，還是在HDFS上，但大多業務和應用不可能直接從HDFS上獲取數據，那么就需要一個數據共享的地方，使得各業務和產品能方便的獲取數據。
這里的數據共享，其實指的是前面數據分析與計算后的結果存放的地方，其實就是關系型數據庫和NOSQL數據庫。
數據應用
報表：報表所使用的數據，一般也是已經統計匯總好的，存放於數據共享層。
接口：接口的數據都是直接查詢數據共享層即可得到。
即席查詢：即席查詢通常是現有的報表和數據共享層的數據並不能滿足需求，需要從數據存儲層直接查詢。一般都是通過直接操作SQL得到。
即席查詢：（Ad Hoc）是用戶根據自己的需求，靈活的選擇查詢條件，系統能夠根據用戶的選擇生成相應的統計報表。即席查詢與普通應用查詢最大的不同是普通的應用查詢是定制開發的，而即席查詢是由用戶自定義查詢條件的。
通常的方式是，將數據倉庫中的維度表和事實表映射到語義層，用戶可以通過語義層選擇表，建立表間的關聯，最終生成SQL語句。
(二)主流架構
數據采集：采用Flume收集日志，采用Sqoop將RDBMS以及NoSQL中的數據同步到HDFS上
消息系統：可以加入Kafka防止數據丟失
實時計算：實時計算使用Spark Streaming消費Kafka中收集的日志數據，實時計算結果大多保存在Redis中
機器學習：使用了Spark MLlib提供的機器學習算法
多維分析OLAP：使用Kylin作為OLAP引擎
數據可視化：提供可視化前端頁面，方便運營等非開發人員直接查詢
四、什么是ETL
ETL是數據抽取（Extract）、轉換（Transform）、加載（Load ）的簡寫：
它是將OLTP系統中的數據經過抽取，並將不同數據源的數據進行轉換、整合，得出一致性的數據，然后加載到數據倉庫中。簡而言之ETL是完成從OLTP系統到OLAP系統的過程。
1 數據處理大致可以分成兩大類：聯機事務處理OLTP（on-line transaction processing）、聯機分析處理OLAP（On-Line Analytical Processing）。
OLTP是傳統的關系型數據庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。OLAP是數據倉庫系統的主要應用，支持復雜的分析操作，側重決策支持，並且提供直觀易懂的查詢結果。
1 聯機分析處理（OLAP,On-line Analytical Processing），數據量大，DML少。使用數據倉庫模板 2 聯機事務處理（OLTP,On-line Transaction Processing），數據量少，DML頻繁，並行事務處理多，但是一般都很短。使用一般用途或事務處理模板。 3 決策支持系統（DDS，Decision support system)，典型的操作是全表掃描，長查詢，長事務，但是一般事務的個數很少，往往是一個事務獨占系統。
五、ETL數據倉庫架構
數據倉庫（Data Warehouse\DW）是基於OLTP(聯機事務處理過程)系統的數據源，為了便於多維分析和多角度展現將其數據按特定的模式進行存儲而建立的關系型數據庫。
它不同於多維數據庫，數據庫中的數據是細節的，集成的，數據倉庫是面向主題的，是以OLAP(聯機分析處理)系統為分析目的。
它包括星型架構與雪花型架構，其中星型架構中間為事實表，四周為維度表，類似星星；雪花型架構中間為事實表，兩邊的維度表可以再有其關聯子表，
而在星型中只允許一張表作為維度表與事實表關聯，雪花型一維度可以有多張表，而星型不可以。考慮到效率時，星型聚合快，效率高，不過雪花型結構明確，便於與OLTP系統交互。
六、數據倉庫多維數據設計
6.1一些概念
主題（Subject）
主題就是指我們所要分析的具體方面。例如：某年某月某地區某機型某款App的安裝情況。主題有兩個元素：一是各個分析角度（維度），如時間位置；
二是要分析的具體量度，該量度一般通過數值體現，如App安裝量。
維（Dimension）
維是用於從不同角度描述事物特征的，一般維都會有多層（Level：級別），每個Level都會包含一些共有的或特有的屬性（Attribute），可以用下圖來展示下維的結構和組成：
以時間維為例，時間維一般會包含年、季、月、日這幾個Level，每個Level一般都會有ID、NAME、
DESCRIPTION這幾個公共屬性，這幾個公共屬性不僅適用於時間維，也同樣表現在其它各種不同類型的維。
分層（Hierarchy）
OLAP需要基於有層級的自上而下的鑽取，或者自下而上地聚合。所以我們一般會在維的基礎上再次進行分層，維、分層、層級的關系如下圖：
每一級之間可能是附屬關系（如市屬於省、省屬於國家），也可能是順序關系（如天周年）
量度
量度就是我們要分析的具體的技術指標，諸如年銷售額之類。它們一般為數值型數據。我們或者將該數據匯總，或者將該數據取次數、獨立次數或取最大最小值等，這樣的數據稱為量度。
粒度
數據的細分層度，例如按天分按小時分。
事實表和維表
事實表是用來記錄分析的內容的全量信息的，包含了每個事件的具體要素，以及具體發生的事情。事實表中存儲數字型ID以及度量信息。
維表則是對事實表中事件的要素的描述信息，就是你觀察該事務的角度，是從哪個角度去觀察這個內容的。
事實表和維表通過ID相關聯，如圖所示：
星型：
雪花型：
雪花形就是在維度下面又細分出維度，這樣切分是為了使表結構更加規范化。雪花模式可以減少冗余，
但是減少的那點空間和事實表的容量相比實在是微不足道，而且多個表聯結操作會降低性能，所以一般不用雪花模式設計數據倉庫。
事實星座模式就是星形模式的集合，包含星形模式，也就包含多個事實表。
企業級數據倉庫/數據集市
企業級數據倉庫：突出大而全，不論是細致數據和聚合數據它全都有，設計時使用事實星座模式
數據集市：可以看做是企業級數據倉庫的一個子集，它是針對某一方面的數據設計的數據倉庫，例如為公司的支付業務設計一個單獨的數據集市。
由於數據集市沒有進行企業級的設計和規划，所以長期來看，它本身的集成將會極其復雜。其數據來源有兩種，一種是直接從原生數據源得到，
另一種是從企業數據倉庫得到，設計時使用星形模型
七、數據倉庫設計步驟
1、確定主題
主題與業務密切相關，所以設計數倉之前應當充分了解業務有哪些方面的需求，據此確定主題
2、確定量度
在確定了主題以后，我們將考慮要分析的技術指標，諸如年銷售額之類。量度是要統計的指標，必須事先選
擇恰當，基於不同的量度將直接產生不同的決策結果。
3、確定數據粒度
考慮到量度的聚合程度不同，我們將采用“最小粒度原則”，即將量度的粒度設置到最小。例如如果知道某些數據細分到天就好了，那么設置其粒度到天；
但是如果不確定的話，就將粒度設置為最小，即毫秒級別的。
4、確定維度
設計各個維度的主鍵、層次、層級，盡量減少冗余。
5、創建事實表
事實表中將存在維度代理鍵和各量度，而不應該存在描述性信息，即符合“瘦高原則”，即要求事實表數據條數盡量多(粒度最小)，而描述性信息盡量少。