1、數據倉庫的架構前端
數據倉庫(Data Warehouse DW)是爲了便於多維分析和多角度展示而將數據按特定的模式進行存儲所創建起來的關係型數據庫,它的數據基於OLTP源系統。數據倉庫中的數據是細節的、集成的、面向主題的,以OLAP系統的分析需求爲目的。數據庫
數據倉庫的架構模型包括了星型架構(圖二:pic2.bmp)與雪花型架構(圖三:pic3.bmp)兩種模式。如圖所示,星型架構的中間爲事實表,四周爲維度表,相似星星;而相比較而言,雪花型架構的中間爲事實表,兩邊的維度表能夠再有其關聯子表,從而表達了清晰的維度層次關係。 安全
從OLAP系統的分析需求和ETL的處理效率兩方面來考慮:星型結構聚合快,分析效率高;而雪花型結構明確,便於與OLTP系統交互。所以,在實際項目中,咱們將綜合運用星型架構與雪花型架構來設計數據倉庫。性能優化
那麼,下面咱們就來看一看,構建企業級數據倉庫的流程。服務器
2、構建企業級數據倉庫五步法架構
(一)、肯定主題性能
即肯定數據分析或前端展示的主題。例如:咱們但願分析某年某月某一地區的啤酒銷售狀況,這就是一個主題。主題要體現出某一方面的各分析角度(維度)和統計數值型數據(量度)之間的關係,肯定主題時要綜合考慮。優化
咱們能夠形象的將一個主題想象爲一顆星星:統計數值型數據(量度)存在於星星中間的事實表;分析角度(維度)是星星的各個角;咱們將經過維度的組合,來考察量度。那麼,「某年某月某一地區的啤酒銷售狀況」這樣一個主題,就要求咱們經過時間和地區兩個維度的組合,來考察銷售狀況這個量度。從而,不一樣的主題來源於數據倉庫中的不一樣子集,咱們能夠稱之爲數據集市。數據集市體現了數據倉庫某一方面的信息,多個數據集市構成了數據倉庫。設計
(二)、肯定量度代理
在肯定了主題之後,咱們將考慮要分析的技術指標,諸如年銷售額之類。它們通常爲數值型數據。咱們或者將該數據彙總,或者將該數據取次數、獨立次數或取最大最小值等,這樣的數據稱爲量度。
量度是要統計的指標,必須事先選擇恰當,基於不一樣的量度能夠進行復雜關鍵性能指標(KPI)等的設計和計算。
(三)、肯定事實數據粒度
在肯定了量度以後,咱們要考慮到該量度的彙總狀況和不一樣維度下量度的聚合狀況。考慮到量度的聚合程度不一樣,咱們將採用「最小粒度原則」,即將量度的粒度設置到最小。
例如:假設目前的數據最小記錄到秒,即數據庫中記錄了每一秒的交易額。那麼,若是咱們能夠確認,在未來的分析需求中,時間只須要精確到天就能夠的話,咱們就能夠在ETL處理過程當中,按天來彙總數據,此時,數據倉庫中量度的粒度就是「天」;反過來,若是咱們不能確認未來的分析需求在時間上是否須要精確到秒,那麼,咱們就須要遵循「最小粒度原則」,在數據倉庫的事實表中保留每一秒的數據,以便往後對「秒」進行分析。
在採用「最小粒度原則」的同時,咱們沒必要擔憂海量數據所帶來的彙總分析效率問題,由於在後續創建多維分析模型(CUBE)的時候,咱們會對數據提早進行彙總,從而保障產生分析結果的效率。關於創建多維分析模型(CUBE)的相關問題,咱們將在下期欄目中予以闡述。
(四)、肯定維度
維度是指分析的各個角度。例如咱們但願按照時間,或者按照地區,或者按照產品進行分析,那麼這裏的時間、地區、產品就是相應的維度。基於不一樣的維度,咱們能夠看到各量度的彙總狀況,也能夠基於全部的維度進行交叉分析。
這裏咱們首先要肯定維度的層次(Hierarchy)和級別(Level)(圖四:pic4.bmp)。如圖所示,咱們在時間維度上,按照「年-季度-月」造成了一個層次,其中「年」、「季度」、「月」成爲了這個層次的3個級別;同理,當咱們創建產品維度時,咱們能夠將「產品大類-產品子類-產品」劃爲一個層次,其中包含「產品大類」、「產品子類」、「產品」三個級別。
那麼,咱們分析中所用到的這些維度,在數據倉庫中的存在形式是怎樣的呢?
咱們能夠將3個級別設置成一張數據表中的3個字段,好比時間維度;咱們也可使用三張表,分別保存產品大類、產品子類、產品三部分數據,好比產品維度。
另外,值得一提的是,咱們在創建維度表時要充分使用代理鍵。代理鍵是數值型的ID號碼(例如圖六中每張表的第一個字段),它惟一標識了每一維度成員。更重要的是,在聚合時,數值型字段的匹配和比較,JOIN效率高,便於聚合。同時,代理鍵對緩慢變化維度有着重要的意義,在原數據主鍵相同的狀況下,它起到了對新數據與歷史數據的標識做用。
在此,咱們不妨談一談維度表隨時間變化的問題,這是咱們常常會遇到的狀況,咱們稱其爲緩慢變化維度。
好比咱們增長了新的產品,或者產品的ID號碼修改了,或者產品增長了一個新的屬性,此時,維度表就會被修改或者增長新的記錄行。這樣,咱們在ETL的過程當中,就要考慮到緩慢變化維度的處理。對於緩慢變化維度,有三種狀況:
一、緩慢變化維度第一種類型:歷史數據須要修改。這種狀況下,咱們使用UPDATE方法來修改維度表中的數據。例如:產品的ID號碼爲123,後來發現ID號碼錯了,須要改寫成456,那麼,咱們就在ETL處理時,直接修改維度表中原來的ID號碼爲456。
二、緩慢變化維度第二種類型:歷史數據保留,新增數據也要保留。這時,要將原數據更新,將新數據插入,咱們使用UPDATE / INSERT。好比:某一員工2005年在A部門,2006年時他調到了B部門。那麼在統計2005年的數據時就應該將該員工定位到A部門;而在統計2006年數據時就應該定位到B部門,而後再有新的數據插入時,將按照新部門(B部門)進行處理,這樣咱們的作法是將該維度成員列表加入標識列,將歷史的數據標識爲「過時」,將目前的數據標識爲「當前的」。另外一種方法是將該維度打上時間戳,即將歷史數據生效的時間段做爲它的一個屬性,在與原始表匹配生成事實表時將按照時間段進行關聯,這種方法的好處是該維度成員生效時間明確。
三、緩慢變化維度第三種類型:新增數據維度成員改變了屬性。例如:某一維度成員新加入了一列,該列在歷史數據中不能基於它瀏覽,而在目前數據和未來數據中能夠按照它瀏覽,那麼此時咱們須要改變維度表屬性,即加入新的字段列。那麼,咱們將使用存儲過程或程序生成新的維度屬性,在後續的數據中將基於新的屬性進行查看。
(五)、建立事實表
在肯定好事實數據和維度後,咱們將考慮加載事實表。
在公司的大量數據堆積如山時,咱們想看看裏面到底是什麼,結果發現裏面是一筆筆生產記錄,一筆筆交易記錄… 那麼這些記錄是咱們將要創建的事實表的原始數據,即關於某一主題的事實記錄表。
咱們的作法是將原始表與維度表進行關聯,生成事實表(圖六:pic6.bmp)。注意在關聯時有爲空的數據時(數據源髒),須要使用外鏈接,鏈接後咱們將各維度的代理鍵取出放於事實表中,事實表除了各維度代理鍵外,還有各量度數據,這未來自原始表,事實表中將存在維度代理鍵和各量度,而不該該存在描述性信息,即符合「瘦高原則」,即要求事實表數據條數儘可能多(粒度最小),而描述性信息儘可能少。
若是考慮到擴展,能夠將事實表加一惟一標識列,覺得了之後擴展將該事實做爲雪花型維度,不過不須要時通常建議不用這樣作。
事實數據表是數據倉庫的核心,須要精心維護,在JOIN後將獲得事實數據表,通常記錄條數都比較大,咱們須要爲其設置複合主鍵和索引,以實現數據的完整性和基於數據倉庫的查詢性能優化。事實數據表與維度表一塊兒放於數據倉庫中,若是前端須要鏈接數據倉庫進行查詢,咱們還須要創建一些相關的中間彙總表或物化視圖,以方便查詢。
3、什麼是ETL
在數據倉庫的構建中,ETL貫穿於項目始終,它是整個數據倉庫的生命線,包括了數據清洗、整合、轉換、加載等各個過程。若是說數據倉庫是一座大廈,那麼ETL就是大廈的根基。ETL抽取整合數據的好壞直接影響到最終的結果展示。因此ETL在整個數據倉庫項目中起着十分關鍵的做用,必須擺到十分重要的位置。
ETL是數據抽取(Extract)、轉換(Transform)、加載(Load )的簡寫,它是指:將OLTP系統中的數據抽取出來,並將不一樣數據源的數據進行轉換和整合,得出一致性的數據,而後加載到數據倉庫中。例如:下圖就向咱們展現了ETL的數據轉換效果。(圖七:pic7.bmp)
那麼,在這一轉換過程當中,咱們就完成了對數據格式的更正、對數據字段的合併、以及新增指標的計算三項操做。相似地,咱們也能夠根據其餘需求,完善數據倉庫中的數據。
簡而言之,經過ETL,咱們能夠基於源系統中的數據來生成數據倉庫。ETL爲咱們搭建了OLTP系統和OLAP系統之間的橋樑。
5、項目實踐技巧
(一)、準備區的運用
在構建數據倉庫時,若是數據源位於一臺服務器上,數據倉庫在另外一臺服務器端,考慮到數據源Server端訪問頻繁,而且數據量大,須要不斷更新,因此能夠創建準備區數據庫(圖八:pic8.bmp)。先將數據抽取到準備區中,而後基於準備區中的數據進行處理,這樣處理的好處是防止了在原OLTP系統中頻繁訪問,進行數據運算或排序等操做。
例如咱們能夠按照天將數據抽取到準備區中,基於數據準備區,咱們將進行數據的轉換、整合、將不一樣數據源的數據進行一致性處理。數據準備區中將存在原始抽取表、轉換中間表和臨時表以及ETL日誌表等。
(二)、時間戳的運用
時間維度對於某一事實主題來講十分重要,由於不一樣的時間有不一樣的統計數據信息,那麼按照時間記錄的信息將發揮很重要的做用。在ETL中,時間戳有其特殊的做用,在上面提到的緩慢變化維度中,咱們可使用時間戳標識維度成員;在記錄數據庫和數據倉庫的操做時,咱們也將使用時間戳標識信息。例如:在進行數據抽取時,咱們將按照時間戳對OLTP系統中的數據進行抽取,好比在午夜0:00取前一天的數據,咱們將按照OLTP系統中的時間戳取GETDATE到GETDATE減一天,這樣獲得前一天數據。
(三)、日誌表的運用
在對數據進行處理時,不免會發生數據處理錯誤,產生出錯信息,那麼咱們如何得到出錯信息並及時修正呢? 方法是咱們使用一張或多張Log日誌表,將出錯信息記錄下來,在日誌表中咱們將記錄每次抽取的條數、處理成功的條數、處理失敗的條數、處理失敗的數據、處理時間等等。這樣,當數據發生錯誤時,咱們很容易發現問題所在,而後對出錯的數據進行修正或從新處理。
(四)、使用調度
在對數據倉庫進行增量更新時必須使用調度(圖九:pic9.bmp),即對事實數據表進行增量更新處理。在使用調度前要考慮到事實數據量,肯定須要多長時間更新一次。好比但願按天進行查看,那麼咱們最好按天進行抽取,若是數據量不大,能夠按照月或半年對數據進行更新。若是有緩慢變化維度狀況,調度時須要考慮到維度表更新狀況,在更新事實數據表以前要先更新維度表。
調度是數據倉庫的關鍵環節,要考慮縝密。在ETL的流程搭建好後,要按期對其運行,因此調度是執行ETL流程的關鍵步驟。每一次調度除了寫入Log日誌表的數據處理信息外,還要使用發送Email或報警服務等,這樣也方便的技術人員對ETL流程的把握,加強了安全性和數據處理的準確性。
5、總結
構建企業級數據倉庫須要簡單的五步,掌握了這五步的方法,咱們能夠構建一個強大的數據倉庫。然而,每一步都有很深的內容須要研究與挖掘,尤爲在實際項目中,咱們要綜合考慮。例如:若是數據源的髒數據不少,在搭建數據倉庫以前咱們首先要進行數據清洗,以剔除掉不須要的信息和髒數據。
ETL是OLTP系統和OLAP系統之間的橋樑,是數據從源系統流入數據倉庫的通道。在數據倉庫的項目實施中,它關係到整個項目的數據質量,因此馬虎不得,必須將其擺到重要位置,將數據倉庫這一大廈的根基築牢!