https://blog.csdn.net/trigl/article/details/68944434

公司之前的數據都是直接傳到Hdfs上進行操作，沒有一個數據倉庫，趁著最近空出幾臺服務器，搭了個簡陋的數據倉庫，這里記錄一下數據倉庫的一些知識。涉及的主要內容有：

什么是數據倉庫？

數據倉庫的架構

數據倉庫多維數據模型的設計

1. 什么是數據倉庫

1.1 數據倉庫的概念

官方定義

數據倉庫是一個面向主題的、集成的、隨時間變化的、但信息本身相對穩定的數據集合，用于對管理決策過程的支持。

這個定義的確官方，但是卻指出了數據倉庫的四個特點。

特點

面向主題：數據倉庫都是基于某個明確主題，僅需要與該主題相關的數據，其他的無關細節數據將被排除掉?
集成的：從不同的數據源采集數據到同一個數據源，此過程會有一些ETL操作?
隨時間變化：關鍵數據隱式或顯式的基于時間變化?
信息本身相對穩定：數據裝入以后一般只進行查詢操作，沒有傳統數據庫的增刪改操作

個人理解

數據倉庫就是整合多個數據源的歷史數據進行細粒度的、多維的分析，幫助高層管理者或者業務分析人員做出商業戰略決策或商業報表。

1.2 數據倉庫的用途

• 整合公司所有業務數據，建立統一的數據中心
• 產生業務報表，用于作出決策
• 為網站運營提供運營上的數據支持
• 可以作為各個業務的數據源，形成業務數據互相反饋的良性循環
• 分析用戶行為數據，通過數據挖掘來降低投入成本，提高投入效果
• 開發數據產品，直接或間接地為公司盈利
• …

1.3 數據庫和數據倉庫的區別

差異項數據庫數據倉庫

特征	操作處理	信息處理
面向	事務	分析
用戶	DBA、開發	經理、主管、分析人員
功能	日常操作	長期信息需求、決策支持
DB設計	基于ER模型，面向應用	星形/雪花模型，面向主題
數據	當前的、最新的	歷史的、跨時間維護
匯總	原始的、高度詳細	匯總的、統一的
視圖	詳細、一般關系	匯總的、多維的
工作單元	短的、簡單事務	復雜查詢
訪問	讀/寫	大多為讀
關注	數據進入	信息輸出
操作	主鍵索引操作	大量的磁盤掃描
用戶數	數百到數億	數百
DB規模	GB到TB	>=TB
優先	高性能、高可用性	高靈活性
度量	事務吞吐量	查詢吞吐量、響應時間

2. 數據倉庫的架構

2.1 當前架構

當前我們的數據倉庫架構很low，但是能實現基本功能，如下：?

數據采集

數據采集層的任務就是把數據從各種數據源中采集和存儲到數據存儲上，期間有可能會做一些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得到。

2.2 理想架構

自己的架構這么低級不能誤導了讀者，所以給出主流公司會用到的一個架構圖：?

增加了以下內容：

數據采集：采用Flume收集日志，采用Sqoop將RDBMS以及NoSQL中的數據同步到HDFS上

消息系統：可以加入Kafka防止數據丟失

實時計算：實時計算使用Spark Streaming消費Kafka中收集的日志數據，實時計算結果大多保存在Redis中

機器學習：使用了Spark MLlib提供的機器學習算法

多維分析OLAP：使用Kylin作為OLAP引擎

數據可視化：提供可視化前端頁面，方便運營等非開發人員直接查詢

3. 數據倉庫多維數據模型的設計

3.1 基本概念

主題（Subject）

主題就是指我們所要分析的具體方面。例如：某年某月某地區某機型某款App的安裝情況。主題有兩個元素：一是各個分析角度（維度），如時間位置；二是要分析的具體量度，該量度一般通過數值體現，如App安裝量。

維（Dimension）

維是用于從不同角度描述事物特征的，一般維都會有多層（Level：級別），每個Level都會包含一些共有的或特有的屬性（Attribute），可以用下圖來展示下維的結構和組成：

以時間維為例，時間維一般會包含年、季、月、日這幾個Level，每個Level一般都會有ID、NAME、DESCRIPTION這幾個公共屬性，這幾個公共屬性不僅適用于時間維，也同樣表現在其它各種不同類型的維。

分層（Hierarchy）

OLAP需要基于有層級的自上而下的鉆取，或者自下而上地聚合。所以我們一般會在維的基礎上再次進行分層，維、分層、層級的關系如下圖：

每一級之間可能是附屬關系（如市屬于省、省屬于國家），也可能是順序關系（如天周年），如下圖所示：

量度

量度就是我們要分析的具體的技術指標，諸如年銷售額之類。它們一般為數值型數據。我們或者將該數據匯總，或者將該數據取次數、獨立次數或取最大最小值等，這樣的數據稱為量度。

粒度?
數據的細分層度，例如按天分按小時分。

事實表和維表

事實表是用來記錄分析的內容的全量信息的，包含了每個事件的具體要素，以及具體發生的事情。事實表中存儲數字型ID以及度量信息。

維表則是對事實表中事件的要素的描述信息，就是你觀察該事務的角度，是從哪個角度去觀察這個內容的。

事實表和維表通過ID相關聯，如圖所示：

星形/雪花形/事實星座

這三者就是數據倉庫多維數據模型建模的模式

上圖所示就是一個標準的星形模型。

雪花形就是在維度下面又細分出維度，這樣切分是為了使表結構更加規范化。雪花模式可以減少冗余，但是減少的那點空間和事實表的容量相比實在是微不足道，而且多個表聯結操作會降低性能，所以一般不用雪花模式設計數據倉庫。

事實星座模式就是星形模式的集合，包含星形模式，也就包含多個事實表。

企業級數據倉庫/數據集市

企業級數據倉庫：突出大而全，不論是細致數據和聚合數據它全都有，設計時使用事實星座模式

數據集市：可以看做是企業級數據倉庫的一個子集，它是針對某一方面的數據設計的數據倉庫，例如為公司的支付業務設計一個單獨的數據集市。由于數據集市沒有進行企業級的設計和規劃，所以長期來看，它本身的集成將會極其復雜。其數據來源有兩種，一種是直接從原生數據源得到，另一種是從企業數據倉庫得到。設計時使用星形模型

3.2 數據倉庫設計步驟

1、確定主題

主題與業務密切相關，所以設計數倉之前應當充分了解業務有哪些方面的需求，據此確定主題

2、確定量度

在確定了主題以后，我們將考慮要分析的技術指標，諸如年銷售額之類。量度是要統計的指標，必須事先選?
擇恰當，基于不同的量度將直接產生不同的決策結果。

3、確定數據粒度

考慮到量度的聚合程度不同，我們將采用“最小粒度原則”，即將量度的粒度設置到最小。例如如果知道某些數據細分到天就好了，那么設置其粒度到天；但是如果不確定的話，就將粒度設置為最小，即毫秒級別的。

4、確定維度

設計各個維度的主鍵、層次、層級，盡量減少冗余。

5、創建事實表

事實表中將存在維度代理鍵和各量度，而不應該存在描述性信息，即符合“瘦高原則”，即要求事實表數據條數盡量多(粒度最小)，而描述性信息盡量少。

---

Refer

http://lxw1234.com/

https://my.oschina.net/leejun2005/blog/188770

轉載于:https://www.cnblogs.com/davidwang456/articles/9670415.html

總結

以上是生活随笔為你收集整理的数据仓库的架构与设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。