5000字長文分享!數據倉庫的建設與框架終於有人給講明白了

數據倉庫,這個幾乎是所有大數據開發面試必問的話題。比如數據倉庫的分層架構?爲什麼需要數據倉庫建模?數據倉庫建模的原則是什麼?結合業務舉例說明數據倉庫建模的步驟,以及注意事項?什麼是緩慢變化維?維度該如何選擇建設,原則是什麼,主鍵如何設計等等?

一衆問題搞得小夥伴們死去活來,甚至工作好幾年的小夥伴都沒搞清楚過,尤其是大廠特別愛問這些問題。有些小夥伴甚至覺得這些都是形而上學,不懂這些我不一樣搞了很多年開發?即使感興趣的買了一本厚厚的數據倉庫工具書也看不懂!那麼實際數據倉庫建模到底是什麼,開發人員該掌握哪些?

記住:技術是服務於業務,發展於業務的。大數據的本質就解決兩個問題:海量數據的存儲和海量數據的計算。大數據之所以有很多技術框架的發展,迭代,就是爲了滿足不同的新的業務需求。故技術選型要結合業務,業務的發展也是技術的發展。

一、什麼是數據倉庫,其前世今生?

來一起看個官方定義:數據倉庫,英文名稱爲DataWarehouse,可簡寫爲DW或DWH。數據倉庫,是爲企業所有級別的決策制定過程,提供所有類型數據支持的戰略集合。它出於分析性報告和決策支持目的而創建。爲需要業務智能的企業,提供指導業務流程改進、監視時間、成本、質量以及控制。

5000字長文分享!數據倉庫的建設與框架終於有人給講明白了

 

簡單點來說,現實情況是一個企業有很多數據源,比如有的業務數據存放在Mysql,PG庫,有的存放在Oracle,有的日誌存放在Ftp,Nginx服務器上等,有的是外部採集的爬蟲數據等等。那麼對於企業來說沉澱了這麼多數據,如何將這些數據放到一起進行數據融合,數據分析,給企業挖掘數據價值呢?這些不同數據源,不同數據存儲格式,不同的數據更新週期,如果讓你把企業這些數據融合分析,你怎麼辦?

首先,你是不是要把這些不同數據按照統一的格式,一定的規範存儲到一起,然後在通過特定的工具做數據計算分析?那麼對於企業來說,把企業各種數據源的數據放到一起存儲和計算的地方就叫數據倉庫(約定俗稱的叫法),所以本質上數據倉庫上融合各個數據源,存儲加工數據的地方,早期大數據沒有發展起來的時候,企業數據倉庫的載體一般是Oracle,那時候主要給企業做BI報表(Business Intelligence商業智能)。

後來隨着企業數字化,互聯網的發展,企業收集到數據越來越多,發現原有的技術框架已經滿足不了業務存儲和分析的需求了。於是乎就有了現在Hadoop生態爲主的數倉倉庫。

5000字長文分享!數據倉庫的建設與框架終於有人給講明白了

 

二、數據倉庫發展歷程與內容

1.數據倉庫的發展大致經歷了這樣的三個過程:

簡單報表階段:這個階段,系統的主要目標是解決一些日常的工作中業務人員需要的報表,以及生成一些簡單的能夠幫助領導進行決策所需要的彙總數據。這個階段的大部分表現形式爲數據庫和前端報表工具。

數據集市階段:這個階段,主要是根據某個業務部門的需要,進行一定的數據的採集,整理,按照業務人員的需要,進行多維報表的展現,能夠提供對特定業務指導的數據,並且能夠提供特定的領導決策數據。

數據倉庫階段:這個階段,主要是按照一定的數據模型,對整個企業的數據進行採集,整理,並且能夠按照各個業務部門的需要,提供跨部門的,完全一致的業務報表數據,能夠通過數據倉庫生成對對業務具有指導性的數據,同時,爲領導決策提供全面的數據支持。

通過數據倉庫建設的發展階段,我們能夠看出,數據倉庫的建設和數據集市的建設的重要區別就在於數據模型的支持。因此,數據模型的建設,對於我們數據倉庫的建設,有着決定性的意義。

2.數據倉庫組成

多種多樣的數據源

數據抽取、轉換、導入(ETL)

操作型的數據和分析型的數據

主題模型

數據集市

報表、查詢、EIS工具(主管信息系統---服務於組織的高層經理的一類特殊的信息系統能夠迅速、方便、直觀(用圖形)地提供綜合信息)

OLAP工具

數據挖掘工具

元數據

數據質量管理

數據標準化

信息發佈

三、數據倉庫的特點和建設的原則

數倉倉庫的既然本質是給企業存儲計算各種數據源數據融合分析的。首先如果企業數據規模小,數據源單一,則無所謂,數倉倉庫怎麼搞都行。但是如果企業數據源及其多而複雜,數據體量及其龐大,如PB規模的數據,同時數據倉庫的使用人員成千上萬,那麼如何管理這些海量的數據,如何設計數據的存儲,如何管理這些人員的使用等等,都是一個難題。

5000字長文分享!數據倉庫的建設與框架終於有人給講明白了

 

就像一個小公司一樣,幾十人,上百人時可以通過人情事故管理,靈活高效氛圍好。但是一個幾萬人,幾十萬人的公司再去靠人情管理就不太現實了,這個時候怎麼辦?就要靠規章制度去約束規範大家,靠KPI考覈大家了。同樣,數據倉庫的管理也是這樣,海量數據存儲計算的數據倉庫建設,也有一些原則和規範給大家參考。

1.數據倉庫的數據是面向主題的

什麼是主題呢?首先,主題是一個抽象的概念,是較高層次上企業信息系統中的數據綜合、歸類並進行分析利用的抽象。在邏輯意義上,它是對應企業中某一宏觀分析領域所涉及的分析對象。面向主題的數據組織方式,就是在較高層次上對分析對象的數據的一個完整、一致的描述,能完整、統一地刻劃各個分析對象所涉及的企業的各項數據,以及數據之間的聯繫。所謂較高層次是相對面嚮應用的數據組織方式而言的,是指按照主題進行數據組織的方式具有更高的數據抽象級別。

說人話,就是企業數據倉庫中數據是分主題域的,比如以電商上行業爲例,數據倉庫建設的主題分爲:會員信息主題域(會員信息相關所有數據),訂單主題域,商家主題域,商品主題域等等。這些牽涉到數據建模的選型,爲啥要這樣建設成主題,這是很多企業歷年經驗總結的,具體好處原因後面數倉建模模塊時詳細分析。

2.數據倉庫的數據是集成的

數據倉庫的數據是從原有的分散的數據庫數據抽取來的。操作型數據與DSS分析型數據之間差別甚大。

第一,數據倉庫的每一個主題所對應的源數據在原有的各分散數據庫中有許多重複和不一致的地方,且來源於不同的聯機系統的數據都和不同的應用邏輯捆綁在一起;

第二,數據倉庫中的綜合數據不能從原有的數據庫系統直接得到。因此在數據進入數據倉庫之前,必然要經過統一與綜合,這一步是數據倉庫建設中最關鍵、最複雜的一步,所要完成的工作有:(1)要統一源數據中所有矛盾之處,如字段的同名異義、異名同義、單位不統一、字長不一致,等等。 (2)進行數據綜合和計算。數據倉庫中的數據綜合工作可以在從原有數據庫抽取數據時生成,但許多是在數據倉庫內部生成的,即進入數據倉庫以後進行綜合生成的。

簡單點來說:就是數據倉庫中數據是很多數據源數據融合後加工的,跟原來業務系統的數據差別會很大,比如數據根據各中國源數據彙總統計的,或者通過特定算法ETL加工處理後得來的。所以叫集成的。

3. 數據倉庫的數據是不可更新的(相對穩定的)

數據倉庫的數據主要供企業決策分析之用,所涉及的數據操作主要是數據查詢,一般情況下並不進行修改操作。

數據倉庫的數據反映的是一段相當長的時間內歷史數據的內容,是不同時點的數據庫快照的集合,以及基於這些快照進行統計、綜合和重組的導出數據,而不是聯機處理的數據。數據庫中進行聯機處理的數據經過集成輸入到數據倉庫中,一旦數據倉庫存放的數據已經超過數據倉庫的數據存儲期限,這些數據將從當前的數據倉庫中刪去。因爲數據倉庫只進行數據查詢操作,所以數據倉庫管理系統相比數據庫管理系統而言要簡單得多。

數據庫管理系統中許多技術難點,如完整性保護、併發控制等等,在數據倉庫的管理中幾乎可以省去。但是由於數據倉庫的查詢數據量往往很大,所以就對數據查詢提出了更高的要求,它要求採用各種複雜的索引技術;同時由於數據倉庫面向的是商業企業的高層管理者,他們會對數據查詢的界面友好性和數據表示提出更高的要求。

簡單總結一下就是:數據倉庫中保存的數據是一系列企業數據的歷史快照,不建議被修改(實際分析會有數據回補的情況)。用戶只能通過分析工具進行查詢和分析。

4.數據倉庫的數據是隨時間不斷變化的(時變性)

數據倉庫中的數據不可更新是針對應用來說的,也就是說,數據倉庫的用戶進行分析處理時是不進行數據更新操作的。但並不是說,在從數據集成輸入數據倉庫開始到最終被刪除的整個數據生存週期中,所有的數據倉庫數據都是永遠不變的。

數據倉庫的數據是隨時間的變化而不斷變化的,這是數據倉庫數據的第四個特徵。這一特徵表現在以下3方面:

(1)數據倉庫隨時間變化不斷增加新的數據內容。數據倉庫系統必須不斷捕捉OLTP數據庫中變化的數據,追加到數據倉庫中去,也就是要不斷地生成OLTP數據庫的快照,經統一集成後增加到數據倉庫中去;但對於確實不再變化的數據庫快照,如果捕捉到新的變化數據,則只生成一個新的數據庫快照增加進去,而不會對原有的數據庫快照進行修改。

(2)數據倉庫隨時間變化不斷刪去舊的數據內容。數據倉庫的數據也有存儲期限,一旦超過了這一期限,過期數據就要被刪除。只是數據倉庫內的數據時限要遠遠長於操作型環境中的數據時限。在操作型環境中一般只保存有60~90天的數據,而在數據倉庫中則需要保存較長時限的數據(如5~10年),以適應DSS進行趨勢分析的要求。

(3)數據倉庫中包含有大量的綜合數據,這些綜合數據中很多跟時間有關,如數據經常按照時間段進行綜合,或隔一定的時間片進行抽樣等等。這些數據要隨着時間的變化不斷地進行重新綜合。因此,數據倉庫的數據特徵都包含時間項,以標明數據的歷史時期。

四、數據倉庫的分層架構原因與分層原則

1.數據倉庫要不要分層?

數據倉庫既然是數據存儲計算的地方,那麼爲什麼需要分層呢?同樣也是數據規模,業務場景決定。可以說很多公司數據倉庫建設剛起步時,大部分的數據都是經過粗暴的數據接入,進行ETL後就直接對接業務,生成報表或者導入業務系統直接使用。

後來隨着公司業務的發展,數據的沉澱,數據倉庫發展到一定階段,發現數據的使用雜亂無章,各種業務都是從原始數據直接計算而得。造成各種重複計算(可能兩張表只差了幾個字段,但每個人都跑了一次),嚴重浪費了計算資源和存儲資源,企業負擔成本極大。這個時候大家就要想着如何規範化存儲和計算了,如何最大化降低企業成本。尤其數據規模越大的公司,需求越強烈。

當然你公司數據規模小,非不分層可不可以,當然可以。也沒必要搞那麼規範,規範的不好之處就是要付出很大的人力成本去實施規範,監督規範的實施。最終的選擇要結合你們企業的成本去考量,一切都要結合實際。

2.數倉分層的好處有哪些?

歷史血的教訓,各大廠總結了下數倉分層的好處:

清晰數據結構:每一個數據分層都有它的作用域,這樣我們在使用表的時候能更方便地定位和理解。

數據血緣追蹤:簡單來講可以這樣理解,我們最終給業務誠信的是一能直接使用的張業務表,但是它的來源有很多,如果有一張來源表出問題了,我們希望能夠快速準確地定位到問題,並清楚它的危害範圍。

減少重複開發:規範數據分層,開發一些通用的中間層數據,能夠減少極大的重複計算。

把複雜問題簡單化。講一個複雜的任務分解成多個步驟來完成,每一層只處理單一的步驟,比較簡單和容易理解。而且便於維護數據的準確性,當數據出現問題之後,可以不用修復所有的數據,只需要從有問題的步驟開始修復。

屏蔽原始數據的異常。不必改一次業務就需要重新接入數據,或者業務改了數據,也不一定對現在有影響

屏蔽業務的影響,不必改一次業務就需要重新接入數據。

3.數據倉庫該如何分層及如何設計分層?

數倉的分層好處有那麼多?那麼該如何分層?一切其實還是結合企業的實際情況,業務場景,數據規模,可以粗放型,也可以豐富更多的細節。

具體數倉的分層設計,如何結合業務對企業數據倉庫分層?主流大廠的數倉分層架構情況,設計原則等,分層如何命名?這些內容太多了,後面詳細一章節結合案例分析。也可以先參考:數據倉庫的四個層次設計

五、數據倉庫建模的選型與建模原則

前面聊過數據倉庫發展到規範化建設需要分層架構。那麼每一層的數據建模的原則應該是什麼樣的呢?以及爲什麼需要數據建模?數據建模有哪些選型?

1.爲什麼需要數據建模?

2.數據建模有哪些方法?這些模型的特點是什麼?

3.數據建模的原則是什麼?

4.企業數倉建設如何選擇建模,各種模型的對比?

六、數據倉庫維度建模的實施與注意事項

1.維度建模有哪些步驟及其作用?

2.結合企業案例演示完整維度建模使用?

3.維度建模的注意事項?

七、數倉的數據治理與安全

1.數倉的數據治理的必要性?

2.從哪些維度數據治理?

3.數據治理與管理體系建設?

總結

總結:前面7個章節涵蓋了數倉的前世今生,發展迭代,以及當前在企業中的應用,簡單介紹了整個數倉體系與框架。學習的過程是要先見森林,再見樹木,最後再見森林的過程。

 

原文來源:滌生手記

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章