一、資料倉庫的架構

資料倉庫（Data Warehouse DW）是為了便於多維分析和多角度展現而將資料按特定的模式進行儲存所建立起來的關係型資料庫，它的資料基於OLTP源系統。資料倉庫中的資料是細節的、整合的、面向主題的，以OLAP系統的分析需求為目的。

資料倉庫的架構模型包括了星型架構（圖二：pic2.bmp）與雪花型架構（圖三：pic3.bmp）兩種模式。如圖所示，星型架構的中間為事實表，四周為維度表，類似星星；而相比較而言，雪花型架構的中間為事實表，兩邊的維度表可以再有其關聯子表，從而表達了清晰的維度層次關係。

從OLAP系統的分析需求和ETL的處理效率兩方面來考慮：星型結構聚合快，分析效率高；而雪花型結構明確，便於與OLTP系統互動。因此，在實際專案中，我們將綜合運用星型架構與雪花型架構來設計資料倉庫。

那麼，下面我們就來看一看，構建企業級資料倉庫的流程。

二、構建企業級資料倉庫五步法

（一）、確定主題

即確定資料分析或前端展現的主題。例如：我們希望分析某年某月某一地區的啤酒銷售情況，這就是一個主題。主題要體現出某一方面的各分析角度（維度）和統計數值型資料（量度）之間的關係，確定主題時要綜合考慮。

我們可以形象的將一個主題想象為一顆星星：統計數值型資料（量度）存在於星星中間的事實表；分析角度（維度）是星星的各個角；我們將通過維度的組合，來考察量度。那麼，“某年某月某一地區的啤酒銷售情況”這樣一個主題，就要求我們通過時間和地區兩個維度的組合，來考察銷售情況這個量度。從而，不同的主題來源於資料倉庫中的不同子集，我們可以稱之為資料集市。資料集市體現了資料倉庫某一方面的資訊，多個數據集市構成了資料倉庫。

（二）、確定量度

在確定了主題以後，我們將考慮要分析的技術指標，諸如年銷售額之類。它們一般為數值型資料。我們或者將該資料彙總，或者將該資料取次數、獨立次數或取最大最小值等，這樣的資料稱為量度。

量度是要統計的指標，必須事先選擇恰當，基於不同的量度可以進行復雜關鍵效能指標（KPI）等的設計和計算。

（三）、確定事實資料粒度

在確定了量度之後，我們要考慮到該量度的彙總情況和不同維度下量度的聚合情況。考慮到量度的聚合程度不同，我們將採用“最小粒度原則”，即將量度的粒度設定到最小。

例如：假設目前的資料最小記錄到秒，即資料庫中記錄了每一秒的交易額。那麼，如果我們可以確認，在將來的分析需求中，時間只需要精確到天就可以的話，我們就可以在ETL處理過程中，按天來彙總資料，此時，資料倉庫中量度的粒度就是“天”；反過來，如果我們不能確認將來的分析需求在時間上是否需要精確到秒，那麼，我們就需要遵循“最小粒度原則”，在資料倉庫的事實表中保留每一秒的資料，以便日後對“秒”進行分析。

在採用“最小粒度原則”的同時，我們不必擔心海量資料所帶來的彙總分析效率問題，因為在後續建立多維分析模型（CUBE）的時候，我們會對資料提前進行彙總，從而保障產生分析結果的效率。關於建立多維分析模型（CUBE）的相關問題，我們將在下期欄目中予以闡述。

（四）、確定維度

維度是指分析的各個角度。例如我們希望按照時間，或者按照地區，或者按照產品進行分析，那麼這裡的時間、地區、產品就是相應的維度。基於不同的維度，我們可以看到各量度的彙總情況，也可以基於所有的維度進行交叉分析。

這裡我們首先要確定維度的層次（Hierarchy）和級別（Level）（圖四：pic4.bmp）。如圖所示，我們在時間維度上，按照“年-季度-月”形成了一個層次，其中“年”、“季度”、“月”成為了這個層次的3個級別；同理，當我們建立產品維度時，我們可以將“產品大類-產品子類-產品”劃為一個層次，其中包含“產品大類”、“產品子類”、“產品”三個級別。

那麼，我們分析中所用到的這些維度，在資料倉庫中的存在形式是怎樣的呢？

我們可以將3個級別設定成一張資料表中的3個欄位，比如時間維度；我們也可以使用三張表，分別儲存產品大類、產品子類、產品三部分資料，比如產品維度。（圖五：pic5.bmp）

    另外，值得一提的是，我們在建立維度表時要充分使用代理鍵。代理鍵是數值型的ID號碼（例如圖六中每張表的第一個欄位），它唯一標識了每一維度成員。更重要的是，在聚合時，數值型欄位的匹配和比較，JOIN效率高，便於聚合。同時，代理鍵對緩慢變化維度有著重要的意義，在原資料主鍵相同的情況下，它起到了對新資料與歷史資料的標識作用。

在此，我們不妨談一談維度表隨時間變化的問題，這是我們經常會遇到的情況，我們稱其為緩慢變化維度。

比如我們增加了新的產品，或者產品的ID號碼修改了，或者產品增加了一個新的屬性，此時，維度表就會被修改或者增加新的記錄行。這樣，我們在ETL的過程中，就要考慮到緩慢變化維度的處理。對於緩慢變化維度，有三種情況：

1、緩慢變化維度第一種型別：歷史資料需要修改。這種情況下，我們使用UPDATE方法來修改維度表中的資料。例如：產品的ID號碼為123，後來發現ID號碼錯了，需要改寫成456，那麼，我們就在ETL處理時，直接修改維度表中原來的ID號碼為456。

2、緩慢變化維度第二種型別：歷史資料保留，新增資料也要保留。這時，要將原資料更新，將新資料插入，我們使用UPDATE / INSERT。比如：某一員工2005年在A部門，2006年時他調到了B部門。那麼在統計2005年的資料時就應該將該員工定位到A部門；而在統計2006年資料時就應該定位到B部門，然後再有新的資料插入時，將按照新部門（B部門）進行處理，這樣我們的做法是將該維度成員列表加入標識列，將歷史的資料標識為“過期”，將目前的資料標識為“當前的”。另一種方法是將該維度打上時間戳，即將歷史資料生效的時間段作為它的一個屬性，在與原始表匹配生成事實表時將按照時間段進行關聯，這種方法的好處是該維度成員生效時間明確。

3、緩慢變化維度第三種類型：新增資料維度成員改變了屬性。例如：某一維度成員新加入了一列，該列在歷史資料中不能基於它瀏覽，而在目前資料和將來資料中可以按照它瀏覽，那麼此時我們需要改變維度表屬性，即加入新的欄位列。那麼，我們將使用儲存過程或程式生成新的維度屬性，在後續的資料中將基於新的屬性進行檢視。

（五）、建立事實表

在確定好事實資料和維度後，我們將考慮載入事實表。

在公司的大量資料堆積如山時，我們想看看裡面究竟是什麼，結果發現裡面是一筆筆生產記錄，一筆筆交易記錄… 那麼這些記錄是我們將要建立的事實表的原始資料，即關於某一主題的事實記錄表。

我們的做法是將原始表與維度表進行關聯，生成事實表（圖六：pic6.bmp）。注意在關聯時有為空的資料時（資料來源髒），需要使用外連線，連線後我們將各維度的代理鍵取出放於事實表中，事實表除了各維度代理鍵外，還有各量度資料，這將來自原始表，事實表中將存在維度代理鍵和各量度，而不應該存在描述性資訊，即符合“瘦高原則”，即要求事實表資料條數儘量多（粒度最小），而描述性資訊儘量少。

如果考慮到擴充套件，可以將事實表加一唯一標識列，以為了以後擴充套件將該事實作為雪花型維度，不過不需要時一般建議不用這樣做。

事實資料表是資料倉庫的核心，需要精心維護，在JOIN後將得到事實資料表，一般記錄條數都比較大，我們需要為其設定複合主鍵和索引，以實現資料的完整性和基於資料倉庫的查詢效能優化。事實資料表與維度表一起放於資料倉庫中，如果前端需要連線資料倉庫進行查詢，我們還需要建立一些相關的中間彙總表或物化檢視，以方便查詢。

三、什麼是ETL

在資料倉庫的構建中，ETL貫穿於專案始終，它是整個資料倉庫的生命線，包括了資料清洗、整合、轉換、載入等各個過程。如果說資料倉庫是一座大廈，那麼ETL就是大廈的根基。ETL抽取整合資料的好壞直接影響到最終的結果展現。所以ETL在整個資料倉庫專案中起著十分關鍵的作用，必須擺到十分重要的位置。

ETL是資料抽取（Extract）、轉換（Transform）、載入（Load ）的簡寫，它是指：將OLTP系統中的資料抽取出來，並將不同資料來源的資料進行轉換和整合，得出一致性的資料，然後載入到資料倉庫中。例如：下圖就向我們展示了ETL的資料轉換效果。（圖七：pic7.bmp）

那麼，在這一轉換過程中，我們就完成了對資料格式的更正、對資料欄位的合併、以及新增指標的計算三項操作。類似地，我們也可以根據其他需求，完善資料倉庫中的資料。

簡而言之，通過ETL，我們可以基於源系統中的資料來生成資料倉庫。ETL為我們搭建了OLTP系統和OLAP系統之間的橋樑。

五、專案實踐技巧

（一）、準備區的運用

 在構建資料倉庫時，如果資料來源位於一臺伺服器上，資料倉庫在另一臺伺服器端，考慮到資料來源Server端訪問頻繁，並且資料量大，需要不斷更新，所以可以建立準備區資料庫（圖八：pic8.bmp）。先將資料抽取到準備區中，然後基於準備區中的資料進行處理，這樣處理的好處是防止了在原OLTP系統中頻繁訪問，進行資料運算或排序等操作。

例如我們可以按照天將資料抽取到準備區中，基於資料準備區，我們將進行資料的轉換、整合、將不同資料來源的資料進行一致性處理。資料準備區中將存在原始抽取表、轉換中間表和臨時表以及ETL日誌表等。

（二）、時間戳的運用

時間維度對於某一事實主題來說十分重要，因為不同的時間有不同的統計資料資訊，那麼按照時間記錄的資訊將發揮很重要的作用。在ETL中，時間戳有其特殊的作用，在上面提到的緩慢變化維度中，我們可以使用時間戳標識維度成員；在記錄資料庫和資料倉庫的操作時，我們也將使用時間戳標識資訊。例如：在進行資料抽取時，我們將按照時間戳對OLTP系統中的資料進行抽取，比如在午夜0：00取前一天的資料，我們將按照OLTP系統中的時間戳取GETDATE到GETDATE減一天，這樣得到前一天資料。

（三）、日誌表的運用

在對資料進行處理時，難免會發生資料處理錯誤，產生出錯資訊，那麼我們如何獲得出錯資訊並及時修正呢? 方法是我們使用一張或多張Log日誌表，將出錯資訊記錄下來，在日誌表中我們將記錄每次抽取的條數、處理成功的條數、處理失敗的條數、處理失敗的資料、處理時間等等。這樣，當資料發生錯誤時，我們很容易發現問題所在，然後對出錯的資料進行修正或重新處理。

（四）、使用排程

在對資料倉庫進行增量更新時必須使用排程（圖九：pic9.bmp），即對事實資料表進行增量更新處理。在使用排程前要考慮到事實資料量，確定需要多長時間更新一次。比如希望按天進行檢視，那麼我們最好按天進行抽取，如果資料量不大，可以按照月或半年對資料進行更新。如果有緩慢變化維度情況，排程時需要考慮到維度表更新情況，在更新事實資料表之前要先更新維度表。

排程是資料倉庫的關鍵環節，要考慮縝密。在ETL的流程搭建好後，要定期對其執行，所以排程是執行ETL流程的關鍵步驟。每一次排程除了寫入Log日誌表的資料處理資訊外，還要使用傳送Email或報警服務等，這樣也方便的技術人員對ETL流程的把握，增強了安全性和資料處理的準確性。

五、總結

構建企業級資料倉庫需要簡單的五步，掌握了這五步的方法，我們可以構建一個強大的資料倉庫。然而，每一步都有很深的內容需要研究與挖掘，尤其在實際專案中，我們要綜合考慮。例如：如果資料來源的髒資料很多，在搭建資料倉庫之前我們首先要進行資料清洗，以剔除掉不需要的資訊和髒資料。

ETL是OLTP系統和OLAP系統之間的橋樑，是資料從源系統流入資料倉庫的通道。在資料倉庫的專案實施中，它關係到整個專案的資料質量，所以馬虎不得，必須將其擺到重要位置，將資料倉庫這一大廈的根基築牢！