數據倉庫建模與 ETL 實踐技巧

北京邁思奇科技有限公司 戴子良

專家簡歷

戴子良，北京邁思奇科技有限公司（ www.minesage.com ）咨詢顧問，微軟 MCP ， ETL 專家，在數據倉庫，數據清洗，數據整合和多維數據庫方面有很深的造詣，負責企業級數據倉庫建模， ETL ，數據倉庫實現，調度，海量數據的優化處理以及數據分析與挖掘等。負責和參與開發的主要項目有：微軟總部 MSN 數據挖掘項目；微軟總部 Microsoft Marketing 數據分析項目等。對數據倉庫的架構和海量數據的優化有豐富的經驗和處理方法，有豐富的實際項目經驗，尤其對 ETL 過程及數據清洗整合有獨到的見解。

?

在上一期的專欄文章中，我們曾經提到：數據分析系統的總體架構分為四個部分 —— 源系統、數據倉庫、多維數據庫、客戶端（圖一： pic1.bmp ）

其中，數據倉庫（ DW ）起到了數據大集中的作用。通過數據抽取，把數據從源系統源源不斷地抽取出來，可能每天一次，或者每 3 個小時一次（當然是自動的）。這個過程，我們稱之為 ETL 過程。

那么，今天，我們就來談一談：如何搭建數據倉庫，在這個過程中都應該遵循哪些方法和原則；然后介紹一些項目實踐中的技巧。

?

一、數據倉庫的架構

數據倉庫（ 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 系統之間的橋梁，是數據從源系統流入數據倉庫的通道。在數據倉庫的項目實施中，它關系到整個項目的數據質量，所以馬虎不得，必須將其擺到重要位置，將數據倉庫這一大廈的根基筑牢！

?

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1417391