[轉載] 第一篇數據倉庫概述

時間 2019-11-11

標籤轉載一篇數據倉庫概述简体版

原文原文鏈接

閱讀目錄html

回到頂部

前言

閱讀本文前，請先回答下面兩個問題：前端

1. 數據庫和數據倉庫有什麼區別？算法

2. 某大公司Hadoop Hive裏的關係表不徹底知足完整/參照性約束，也不徹底知足範式要求，甚至第一範式都不知足。這種狀況正常嗎？數據庫

若是您不能五秒內給出答案，那麼本文應該是對您有幫助的。架構

注：若是您還不清楚完整參照性約束，請參考《數據庫關係建模》：，若是您還不瞭解範式，請參考《更新異常與規範化設計》。分佈式

回到頂部

數據庫的"分家"

隨着關係數據庫理論的提出，誕生了一系列經典的RDBMS，如Oracle，MySQL，SQL Server等。這些RDBMS被成功推向市場，併爲社會信息化的發展作出的重大貢獻。然而隨着數據庫使用範圍的不斷擴大，它被逐步劃分爲兩大基本類型：工具

1. 操做型數據庫oop

主要用於業務支撐。一個公司每每會使用並維護若干個數據庫，這些數據庫保存着公司的平常操做數據，好比商品購買、酒店預訂、學生成績錄入等；性能

2. 分析型數據庫大數據

主要用於歷史數據分析。這類數據庫做爲公司的單獨數據存儲，負責利用歷史數據對公司各主題域進行統計分析；

那麼爲何要"分家"？在一塊兒不合適嗎？能不能構建一個一樣適用於操做和分析的統一數據庫？

答案是NO。一個顯然的緣由是它們會"打架"......若是操做型任務和分析型任務搶資源怎麼辦呢？再者，它們有太多不一樣，以至於早已"貌合神離"。接下來看看它們到底有哪些不一樣吧。

回到頂部

操做型數據庫 VS 分析型數據庫

由於主導功能的不一樣(面向操做/面向分析)，兩類數據庫就產生了不少細節上的差別。這就好像一樣是人，但一個和尚和一個穆斯林確定有不少行爲/觀念上的不一樣。

接下來本文將詳細分析兩類數據庫的不一樣點：

1. 數據組成差異 - 數據時間範圍差異

通常來說，操做型數據庫只會存放90天之內的數據，而分析型數據庫存放的則是數年內的數據。這點也是將操做型數據和分析型數據進行物理分離的主要緣由。

2. 數據組成差異 - 數據細節層次差異

操做型數據庫存放的主要是細節數據，而分析型數據庫中雖然既有細節數據，又有彙總數據，但對於用戶來講，重點關注的是彙總數據部分。

操做型數據庫中天然也有彙總需求，但彙總數據自己不存儲而只存儲其生成公式。這是由於操做型數據是動態變化的，所以彙總數據會在每次查詢時動態生成。

而對於分析型數據庫來講，由於彙總數據比較穩定不會發生改變，並且其計算量也比較大(由於時間跨度大)，所以它的彙總數據可考慮事先計算好，以免重複計算。

3. 數據組成差異 - 數據時間表示差異

操做型數據一般反映的是現實世界的當前狀態；而分析型數據庫既有當前狀態，還有過去各時刻的快照，分析型數據庫的使用者能夠綜合全部快照對各個歷史階段進行統計分析。

4. 技術差異 - 查詢數據總量和查詢頻度差異

操做型查詢的數據量少而頻率多，分析型查詢則反過來，數據量大而頻率少。要想同時實現這兩種狀況的配置優化是不可能的，這也是將兩類數據庫物理分隔的緣由之一。

5. 技術差異 - 數據更新差異

操做型數據庫容許用戶進行增，刪，改，查；分析型數據庫用戶則只能進行查詢。

6. 技術差異 - 數據冗餘差異

數據的意義是什麼？就是減小數據冗餘，避免更新異常。而如5所述，分析型數據庫中沒有更新操做。所以，減小數據冗餘也就沒那麼重要了。

如今回到開篇是提到的第二個問題"某大公司Hadoop Hive裏的關係表不徹底知足完整/參照性約束，也不徹底知足範式要求，甚至第一範式都不知足。這種狀況正常嗎？"，答曰是正常的。由於Hive是一種數據倉庫，而數據倉庫和分析型數據庫的關係很是緊密(後文會講到)。它只提供查詢接口，不提供更新接口，這就使得消除冗餘的諸多措施不須要被特別嚴格地執行了。

7. 功能差異 - 數據讀者差異

操做型數據庫的使用者是業務環境內的各個角色，如用戶，商家，進貨商等；分析型數據庫則只被少許用戶用來作綜合性決策。

8. 功能差異 - 數據定位差異

這裏說的定位，主要是指以何種目的組織起來。操做型數據庫是爲了支撐具體業務的，所以也被稱爲"面向應用型數據庫"；分析型數據庫則是針對各特定業務主題域的分析任務建立的，所以也被稱爲"面向主題型數據庫"。

回到頂部

數據倉庫(data warehouse)定義

聰明的讀者應該已經意識到這個問題：既然分析型數據庫中的操做都是查詢，所以也就不須要嚴格知足完整性/參照性約束以及範式設計要求，而這些卻正是關係數據庫精華所在。這樣的狀況下再將它歸爲數據庫會很容易引發你們混淆，畢竟在絕大多數人內心數據庫是能夠關係型數據庫畫上等號的。

那麼爲何不乾脆叫"面向分析的存儲系統"呢？

Bingo！~這就是關於數據倉庫最貼切的定義了。事實上數據倉庫不該讓傳統關係數據庫來實現，由於關係數據庫最少也要求知足第1範式，而數據倉庫裏的關係表能夠不知足第1範式。也就是說，一樣的記錄在一個關係表裏能夠出現N次。但因爲大多數數據倉庫內的表的統計分析仍是用SQL，所以不少人把它和關係數據庫搞混了。

知道了什麼是數據倉庫後，再來看看它有哪些特色吧。某種程度上來講，這也是分析型數據庫的特色：

1. 面向主題

面向主題特性是數據倉庫和操做型數據庫的根本區別。操做型數據庫是爲了支撐各類業務而創建，而分析型數據庫則是爲了對從各類繁雜業務中抽象出來的分析主題(如用戶、成本、商品等)進行分析而創建；

2. 集成性

集成性是指數據倉庫會將不一樣源數據庫中的數據彙總到一塊兒；

3. 企業範圍

數據倉庫內的數據是面向公司全局的。好比某個主題域爲成本，則全公司和成本有關的信息都會被聚集進來；

4. 歷史性

較之操做型數據庫，數據倉庫的時間跨度一般比較長。前者一般保存幾個月，後者可能幾年甚至幾十年；

5. 時變性

時變性是指數據倉庫包含來自其時間範圍不一樣時間段的數據快照。有了這些數據快照之後，用戶即可將其彙總，生成各歷史階段的數據分析報告；

回到頂部

數據倉庫組件

數據倉庫的核心組件有四個：各源數據庫，ETL，數據倉庫，前端應用。以下圖所示：

1. 業務系統

業務系統包含各類源數據庫，這些源數據庫既爲業務系統提供數據支撐，同時也做爲數據倉庫的數據源(注：除了業務系統，數據倉庫也可從其餘外部數據源獲取數據)；

2. ETL

ETL分別表明：提取extraction、轉換transformation、加載load。其中提取過程表示操做型數據庫蒐集指定數據，轉換過程表示將數據轉化爲指定格式並進行數據清洗保證數據質量，加載過程表示將轉換事後知足指定格式的數據加載進數據倉庫。數據倉庫會週期不斷地從源數據庫提取清洗好了的數據，所以也被稱爲"目標系統"；

3. 前端應用

和操做型數據庫同樣，數據倉庫一般提供具備直接訪問數據倉庫功能的前端應用，這些應用也被稱爲BI(商務智能)應用；

回到頂部

數據集市(data mart)

數據集市能夠理解爲是一種"小型數據倉庫"，它只包含單個主題，且關注範圍也非全局。

數據集市能夠分爲兩種，一種是獨立數據集市(independent data mart)，這類數據集市有本身的源數據庫和ETL架構；另外一種是非獨立數據集市(dependent data mart)，這種數據集市沒有本身的源系統，它的數據來自數據倉庫。當用戶或者應用程序不須要/沒必要要/不容許用到整個數據倉庫的數據時，非獨立數據集市就能夠簡單爲用戶提供一個數據倉庫的"子集"。

回到頂部

數據倉庫開發流程

在數據庫系列的第五篇中，曾詳細分析了數據庫系統的開發流程。數據倉庫的開發流程和數據庫的比較類似，所以本文僅就其中區別進行分析。

下圖爲數據倉庫的開發流程：

較之數據庫系統開發，數據倉庫開發只多出ETL工程部分。然而這一部分極有多是整個數據倉庫開發流程中最爲耗時耗資源的一個環節。由於該環節要整理各大業務系統中雜亂無章的數據並協調元數據上的差異，因此工做量很大。在不少公司都專門設有ETL工程師這樣的崗位，大的公司甚至專門聘請ETL專家。

回到頂部

小結

在大數據時代，數據倉庫的重要性更勝以往。Hadoop平臺下的Hive，Spark平臺下的Spark SQL都是各自生態圈內應用最熱門的配套工具，而它們的本質就是開源分佈式數據倉庫。

在國內最優秀的互聯網公司裏(如阿里、騰訊)，不少數據引擎是架構在數據倉庫之上的(如數據分析引擎、數據挖掘引擎、推薦引擎、可視化引擎等等)。很多員工認爲，開發成本應更多集中在數據倉庫層，不斷加大數據建設的投入。由於一旦規範、標準、高性能的數據倉庫創建好了，在之上進行數據分析、數據挖掘、跑推薦算法等都是輕鬆愜意的事情。反之若是業務數據沒梳理好，各類髒亂數據會搞得人焦頭爛額，苦不堪言。

來源：https://www.cnblogs.com/muchen/p/5305658.html