數據倉庫的分層及架構

數據倉庫的定義

        數據倉庫是一個面向主題的、集成的、隨時間變化的、但信息自己相對穩定的數據集合，用於對管理決策過程的支持。數據倉庫自己並不「生產」任何數據，同時自身也不須要「消費」任何的數據，數據來源於外部，而且開放給外部應用使用。

數據倉庫的特色

​         面向主題的：數據倉庫都是基於某個明確的主題，僅須要與該主題相關的數據，其餘的無關細節將會被去掉。

​         集成的：數據倉庫裏面的數據都是通過ETL（ Extract-Transform-Load 抽取-轉換-加載）操做後被集中放到同一個數據源，數據倉庫裏的數據是來自於各類不一樣的數據源。

​         隨時間變化的：關鍵數據隱式或者顯示地隨時間變化而變化。

        ​ 數據相對穩定的：數據裝入後通常只是進行查詢操做，沒有傳統數據庫的增刪改操做。

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

數據倉庫的做用

​         能夠整合公司的全部業務，創建統一的數據中心。

​         分析用戶行爲數據，經過數據挖掘來下降投入成本，提升投入效果。

​         能夠做爲各個業務的數據源，造成業務數據互相反饋的良性循環。

​         能夠提供數據報表，用於公司的決策等等。

	傳統數據庫	數據倉庫
特徵	用於操做處理，面向OLTP	用於信息處理，面向OLAP
用戶	用戶：DBA、開發。用戶規模：數百或數億	用戶：經理、主管、分析人員。用戶規模：數百
功能	平常操做	長期信息需求、決策支持
DB設計	基於ER模型，面向應用	星形/雪花模型，面向主題
數據	當前的、最新的	歷史的、跨時間維護

​         註解 數據處理大體能夠分紅兩大類：聯機事務處理OLTP（on-line transaction processing）、聯機分析處理OLAP（On-Line Analytical Processing）。OLTP是傳統的關係型數據庫的主要應用，主要是基本的、平常的事務處理，例如銀行交易。OLAP是數據倉庫系統的主要應用，支持複雜的分析操做，側重決策支持，而且提供直觀易懂的查詢結果。 OLTP 系統強調數據庫內存效率，強調內存各類指標的命令率，強調綁定變量，強調併發操做。OLAP系統則強調數據分析，強調SQL執行市場，強調磁盤I/O，強調分區等。

數據倉庫的架構

        數據採集層：數據採集層的任務就是把數據從各類數據源中採集和存儲到數據庫上，期間有可能會作一些ETL（抽取extra，轉化transfer，裝載load ）操做。數據源種類能夠有多種：

​             日誌：所佔份額最大，存儲在備份服務器上 業務數據庫：如Mysql、Oracle 來自HTTP/FTP的數據：合做夥伴提供的接口 其餘數據源：如Excel等須要手工錄入的數據 數據存儲與分析

​             HDFS是大數據環境下數據倉庫/數據平臺最完美的數據存儲解決方案。

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

​             使用Hadoop框架天然而然也提供了MapReduce接口，若是真的很樂意開發Java，或者對SQL不熟，那麼也可使用MapReduce來作分析與計算。

​             Spark性能比MapReduce好不少，同時使用SparkSQL操做Hive。

​     數據共享

​             前面使用Hive、MR、Spark、SparkSQL分析和計算的結果，仍是在HDFS上，但大多業務和應用不可能直接從HDFS上獲取數據，那麼就須要一個數據共享的地方，使得各業務和產品能方便的獲取數據。 這裏的數據共享，其實指的是前面數據分析與計算後的結果存放的地方，其實就是關係型數據庫和NOSQL數據庫。

​     數據應用

​             報表：報表所使用的數據，通常也是已經統計彙總好的，存放於數據共享層。

​             接口：接口的數據都是直接查詢數據共享層便可獲得。

​             即席查詢：即席查詢一般是現有的報表和數據共享層的數據並不能知足需求，須要從數據存儲層直接查詢。通常都是經過直接操做SQL獲得。

數據倉庫的要求

​     高效率：數據倉庫的分析數據通常分爲日、周、月、季、年等，能夠看出，以日爲週期的數據要求的效率最高，要求24小時甚至12小時內，客戶能看到昨天的數據分析。因爲有的企業每日的數據量很大，若是數據倉庫設計的很差，須要延時一到兩天才能顯示數據，這顯然是不能出現這種事情的。

​     數據質量高：數據倉庫所提供的各類信息，確定要準確的數據。數據倉庫一般要通過數據清洗，裝載，查詢，展示等多個流程而獲得的，若是複雜的架構會有更多層次，那麼因爲數據源有髒數據或者代碼不嚴謹，均可以致使數據不許確或者有錯誤，若是客戶看到錯誤的信息就可能致使分析出錯誤的決策，形成損失經濟的損失。

​     擴展性：之因此有的大型數據倉庫系統架構設計複雜，是由於考慮到了將來3-5年的擴展性，由於若是在將來須要擴展一些新的功能了，就能夠不用重建數據倉庫系統，就能很穩定運行。由於重建一個數據創庫是比較耗費人力和財力。可擴展性主要體如今數據建模的合理性。

​     爲了達到上述的要求，創建起一個高效率、高數據質量、良好的可擴展性，再加上爲了提升建倉的速度，根據在實際生產環境中的經驗的總結，因而就提出來了數據倉庫的分層概念，那麼到底什麼是數據倉庫的分層？爲何要分紅?數據倉庫的分層的好處是什麼呢？接下來將介紹關於數據倉庫分層的一些概念。

什麼是數據倉庫分層

​         分層是數據倉庫解決方案中，數據架構設計的一種數據邏輯結構 ，經過分層理念創建的數據倉庫，它的可擴展性很是好，這樣設計出來的模型架構，能夠任意地增減、替換數據倉庫中的各個組成部分。

數據倉庫分層的緣由

​         一、用空間換時間，經過數據預處理提升效率，經過大量的預處理能夠提高應用系統的用戶體驗（效率），可是數據倉庫會存在大量冗餘的數據.

​         二、加強可擴展性，方便之後業務的變動。若是不分層的話，當源業務系統的業務規則發生變化整個數據倉庫須要重建，這樣將會影響整個數據清洗過程，工做量巨大。

​         三、經過分層管理來實現分步完成工做，簡化數據清洗的過程，使每一層處理邏輯變得更簡單。由於把原來一步的工做分到了多個步驟去完成，至關於把一個複雜的工做拆成了多個簡單的工做，把一個大的黑盒變成了一個白盒，每一層的處理邏輯都相對簡單和容易理解，這樣咱們比較容易保證每個步驟的正確性，當數據發生錯誤的時候，每每咱們只須要局部調整某個步驟便可。

數據倉庫具體的分層

​         標準的數據倉庫分層：ods（臨時存儲層），pdw（數據倉庫層），mid（數據集市層），app（應用層）。

​                 ods：歷史存儲層，它和源系統數據是同構的，並且這一層數據粒度是最細的，這層的表分爲兩種，一種是存儲當前須要加載的數據，一種是用於存儲處理完後的數據。

​                 pdw：數據倉庫層，它的數據是乾淨的數據，是一致的準確的，也就是清洗後的數據，它的數據通常都遵循數據庫第三範式，數據粒度和ods的粒度相同，它會保存bi系統中全部歷史數據

​                 mid：數據集市層，它是面向主題組織數據的，一般是星狀和雪花狀數據，從數據粒度來說，它是輕度彙總級別的數據，已經不存在明細的數據了，從廣度來講，它包含了全部業務數量。從分析角度講，大概就是近幾年

​                 app：應用層，數據粒度高度彙總，倒不必定涵蓋全部業務數據，只是mid層數據的一個子集。

補充

        數據緩存層：用於存放接口方提供的原始數據的數據庫層，此層的表結構與源數據保持基本一致，數據存放時間根據數據量大小和項目狀況而定，若是數據量較大，能夠只存近期數據，將歷史數據進行備份。此層的目的在於數據的中轉和備份。

        核心數據層：此層的數據在數據緩存層的基礎上作了必定程度的整合，稱之爲數據集市，存儲上還是關係模型。此層的目的在於進行必要的數據整合爲下一步多維模型作準備。

        分析應用層：此層的數據爲根據業務分析須要構造的多維模型數據。數據能夠直接用於分析展示。

說明

        數據層次的劃分不是固定不變的，能夠根據工做當中實際項目的須要進行適當裁剪或者是添加。若是業務相對簡單和獨立，能夠將核心數據層與分析應用層進行合併。另外，分析應用的數據能夠來自多維模型的數據，也能夠來自關係模型數據甚至原始數據。