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

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

什么是數(shù)據(jù)倉庫？

數(shù)據(jù)倉庫的架構

數(shù)據(jù)倉庫多維數(shù)據(jù)模型的設計

1. 什么是數(shù)據(jù)倉庫

1.1 數(shù)據(jù)倉庫的概念

官方定義

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

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

特點

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

個人理解

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

1.2 數(shù)據(jù)倉庫的用途

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

1.3 數(shù)據(jù)庫和數(shù)據(jù)倉庫的區(qū)別

差異項數(shù)據(jù)庫數(shù)據(jù)倉庫

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

2. 數(shù)據(jù)倉庫的架構

2.1 當前架構

當前我們的數(shù)據(jù)倉庫架構很low，但是能實現(xiàn)基本功能，如下：?

數(shù)據(jù)采集

數(shù)據(jù)采集層的任務就是把數(shù)據(jù)從各種數(shù)據(jù)源中采集和存儲到數(shù)據(jù)存儲上，期間有可能會做一些ETL操作。

數(shù)據(jù)源種類可以有多種：

• 日志：所占份額最大，存儲在備份服務器上
• 業(yè)務數(shù)據(jù)庫：如Mysql、Oracle
• 來自HTTP/FTP的數(shù)據(jù)：合作伙伴提供的接口
• 其他數(shù)據(jù)源：如Excel等需要手工錄入的數(shù)據(jù)

數(shù)據(jù)存儲與分析

HDFS是大數(shù)據(jù)環(huán)境下數(shù)據(jù)倉庫/數(shù)據(jù)平臺最完美的數(shù)據(jù)存儲解決方案。

離線數(shù)據(jù)分析與計算，也就是對實時性要求不高的部分，Hive是不錯的選擇。

使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很樂意開發(fā)Java，或者對SQL不熟，那么也可以使用MapReduce來做分析與計算。

Spark性能比MapReduce好很多，同時使用SparkSQL操作Hive。

數(shù)據(jù)共享

前面使用Hive、MR、Spark、SparkSQL分析和計算的結果，還是在HDFS上，但大多業(yè)務和應用不可能直接從HDFS上獲取數(shù)據(jù)，那么就需要一個數(shù)據(jù)共享的地方，使得各業(yè)務和產(chǎn)品能方便的獲取數(shù)據(jù)。?
這里的數(shù)據(jù)共享，其實指的是前面數(shù)據(jù)分析與計算后的結果存放的地方，其實就是關系型數(shù)據(jù)庫和NOSQL數(shù)據(jù)庫。

數(shù)據(jù)應用

報表：報表所使用的數(shù)據(jù)，一般也是已經(jīng)統(tǒng)計匯總好的，存放于數(shù)據(jù)共享層。

接口：接口的數(shù)據(jù)都是直接查詢數(shù)據(jù)共享層即可得到。

即席查詢：即席查詢通常是現(xiàn)有的報表和數(shù)據(jù)共享層的數(shù)據(jù)并不能滿足需求，需要從數(shù)據(jù)存儲層直接查詢。一般都是通過直接操作SQL得到。

2.2 理想架構

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

增加了以下內(nèi)容：

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

消息系統(tǒng)：可以加入Kafka防止數(shù)據(jù)丟失

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

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

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

數(shù)據(jù)可視化：提供可視化前端頁面，方便運營等非開發(fā)人員直接查詢

3. 數(shù)據(jù)倉庫多維數(shù)據(jù)模型的設計

3.1 基本概念

主題（Subject）

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

維（Dimension）

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

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

分層（Hierarchy）

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

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

量度

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

粒度?
數(shù)據(jù)的細分層度，例如按天分按小時分。

事實表和維表

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

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

事實表和維表通過ID相關聯(lián)，如圖所示：

星形/雪花形/事實星座

這三者就是數(shù)據(jù)倉庫多維數(shù)據(jù)模型建模的模式

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

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

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

企業(yè)級數(shù)據(jù)倉庫/數(shù)據(jù)集市

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

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

3.2 數(shù)據(jù)倉庫設計步驟

1、確定主題

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

2、確定量度

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

3、確定數(shù)據(jù)粒度

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

4、確定維度

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

5、創(chuàng)建事實表

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

---

Refer

http://lxw1234.com/

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

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

總結

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。