1.   概述

本文作為我這些年實施資料倉庫的總結，如有錯誤，請各位同仁指正。

文件條理不是很清楚，而且也有很多口水話，我不想搞成一個真正的官方文件，所以很隨意，符合我的性格。很多問題我只是提出來了，解決方案沒有想好，也不知道怎麼落到文字，就先提出來備註吧。

文件原本想討論的元資料管理、資料質量和監控工具的內容，由於時間關係，沒有新增，以後有空補上吧。

1.1.閱讀方法

本文閱讀方式:

1、如果你認為本節沒有意義，請將第二節作為第一節。

2、如果你覺得第二節沒有意義，請將第三節作為第一節。

3、歸納：如果你覺得第X節沒有意義，請將X+1節作為第一節。

4、如果你覺得整個文件都沒有意義，恭喜你，你打開了一個無用的

1.2.感謝

(這段應該好好寫)

謝謝黨和國家給我這麼一個大環境，讓我可以安居，讓我可以娶妻生子，更重要的是讓我可以在三個代表的光輝下茁壯成長。

感謝那些給我無窮壓力也被我無數次暗罵的客戶們：貴州聯通、廣西聯通、雲南聯通、重慶移動、江西移動、浙江移動、吉林移動、天津電信、河北移動、山東移動。沒有他們的刻薄，我也無法作出這個東西。

感謝我的妻子，忍受我長期的出差，更重要的是對我職業選擇的包容和理解。

2.定義

2.1.定義的混淆

和客戶交流的時候開始的第一個麻煩可能就是資料倉庫的概念問題，怎麼看怎麼覺得“資料倉庫”應該是一個實體概念，但是實際資料倉庫只是一個過程，而不是一個產品。過程就是計劃如何工作的單元，而不是實際工作的單元。

資料倉庫是這麼定義的：資料倉庫是在企業管理和決策中面向主題的、整合的、與時間相關的、不可修改的資料集合。

這個定義中有一個定義比較容易含混，那就是“面向主題”。面向主題是指資料倉庫圍繞一些主題,排除對於決策無用的資料,提供特定主體的簡明檢視。近年提出的“面向專題”的分析和這個概念混淆的厲害，只能用使用者熟悉的業務才能作出解釋。

以下列出幾個概念，備查：

BI：商業智慧（Business Intelligence）,指資料倉庫相關技術與應用的通稱。指利用各種智慧技術，來提升企業的商業競爭力。

BPR:業務流程重整（Business Process Reengineering）,指利用資料倉庫技術，發現並糾正企業業務流程中的弊端的一項工作。

OLAP

定義1 ：OLAP(聯機分析處理)是針對特定問題的聯機資料訪問和分析。通過對資訊(維資料)的多種可能的觀察形式進行快速、穩定一致和互動性的存取，允許管理決策人員對資料進行深入觀察。

定義2 ：OLAP(聯機分析處理) 是使分析人員、管理人員或執行人員能夠從多種角度對從原始資料中轉化出來的、能夠真正為使用者所理解的、並真實反映企業維特性的資訊進行快速、一致、互動地存取，從而獲得對資料的更深入瞭解的一類軟體技術。(OLAP委員會的定義)

OLAP的目標是滿足決策支援或多維環境特定的查詢和報表需求，它的技術核心是“維”這個概念，因此OLAP也可以說是多維資料分析工具的集合。

ROLAP:基於關係型資料庫的OLAP稱為Relational OLAP，簡稱ROLAP。代表產品有Informix Metacube、Microsoft SQL Server

MOLAP(MuiltDimension OLAP):嚴格遵照Codd的定義，自行建立多維資料庫，來存放聯機分析系統資料,簡稱MOLAP，代表產品有Hyperion Essbase等。

HOLAP:混合OLAP。

Server OLAP:資料在伺服器端處理

Client OLAP:部分資料下載到本地，為使用者提供本地的多維分析。代表產品有Brio Designer, Business Object.

2.2.資料倉庫能給客戶帶來什麼？

客戶的第二個問題就是，資料倉庫能夠給客戶帶來什麼？或者說為什麼使用資料倉庫。還是一個比較難以回答的問題。

一般資料倉庫的入門指導的開篇都會有這麼一個論調，這個論調基本集中在資料儲存的週期、資料儲存容量、資料響應效能以及對線上事務系統(OLTP)的壓力的問題。

但是單純這一點就足以說服客戶麼？(插一句，我不管商務怎麼去談的單子，我只說怎麼面對客戶的刁難。)以上提出的論調肯定客戶也瞭解的。原因很簡單，有一點用心的客戶都會事先進行相關資料的查閱。

我對於“實用”這個詞比較敏感，我想在介紹資料倉庫的時候更多的關切到使用者的實際需求去談可能效果會更好。有一家公司的仁兄去講他的PPT的時候，前面有好十好幾張都是資料倉庫的理論知識，這個傢伙上臺開啟PPT就說“我們主要講業務，前面的都是理論，我一張張唸完就行了，大家如果有興趣自己回去翻閱”。有點門道吧？客戶面對的廠商不見得比我們面對的客戶少，老聽這些，客戶自己都能講出個123來——雖然還不知道怎麼去玩轉這個東西。

換個角度來看，客戶被灌輸的這方面理論已經不少，資料倉庫難講就在於沒有一個直觀的東西（整個快速原型？如果公司有那麼多資源或者以前實施過倒也問題不大。），很多東西都隱藏在實施中，留給客戶的就是一堆文字描述，客戶被搞得頭昏，自己也說得嘴巴乏味。

一個假設，如果客戶有一臺超級強悍的主機，已經有一個非常穩定的線上系統，而且更要命的是客戶已經在這臺主機上實現了一個快速響應的報表系統。你如何說服客戶使用資料倉庫？使用這種技術意味著客戶會為移動資料、資料準確性甚至為多了的主機操心。我只是想提醒一下，不是任何時候都需要建立一個資料倉庫的。如果在這個環境中，更多的工作可能是集中在資料倉庫的實用價值之上。

所幸的是，託硬體廠商的福。我們現在還沒有擁有這樣的主機。所以現實情況中的種種不如意還是值得說道說道。

2.3.就是一個複雜的報表系統

回到剛才的問題，資料倉庫是什麼？

有次我們做經營分析系統的操作培訓完後，酒席上一位地市分公司的負責人說了一句“你們經營分析系統搞了這麼久，不就是一個複雜的報表系統麼?”。

的確，他說的是實話，一個複雜的報表系統的確是資料倉庫應用的表徵。

如果要試著向客戶解釋那麼一套什麼持久啊時間啊儲存時限啊企業級啊之類的概念，那麼這個問題你還是會輸掉。一個複雜的報表系統（大型客戶所使用的報表系統基本都是）底層基本也是按照資料倉庫的這幾個流程走的，只是規模較小、流程不規範而已。

如果這時客戶再問，“我現在的報表系統為什麼不能稱為資料倉庫應用？”，這下應該苦笑了。

資料倉庫對於非技術人員，本身就是一個複雜的報表系統，所有後臺的操作最終目的都是為了呈現結果給客戶，所以這麼說一點也沒錯。認同這一點有點不容易，甚至有些令人洩氣。但是事實就是如此，資料倉庫除了報表還能給使用者什麼？

不要說決策支援之類虛無的東西，一個例子，上月商店銷售的鞋子是去年同期的130％，而且Nike的鞋子銷量上升最快，你覺得資料倉庫應該提出什麼樣的建議？

用現在的技術和實施過程去忽悠“決策支援”的概念顯然不是很合適，還是多說點“你能看到”、“也許你可以”這樣不鹹不淡的口水話比較安全。畢竟，我們當前幾乎所有的資料倉庫還停留在資料積累層面（說“資訊”可能比較好聽），離“知識”的範疇還是太遠。

問題在於，如何適當的向客戶描述資料倉庫報表和普通報表系統的不同。如果能夠解決這個問題，應該來說客戶關係也可以弄的不錯。

最後順便說一點不中聽的，前期的銷售策略引導下的忽悠最終會忽悠到自己的技術實現層面。

2.4.客戶關心的ROI

首先我不想爭論到底是投資回報率（Return of Investment）好還是內部收益率（IRR：Internal rate of return）或者投資回報週期(PP:Payback Period) 對於專案的收益分析更加合理，畢竟我對這些概念也是一知半解。

IDC2002年釋出的訊息說，經過他們的調查，全球資料倉庫的ROI高達401％。這個數字有零有整，還衝著IDC的名頭，可信度很高。難怪這麼些年資料倉庫這麼火，大家都在簡歷上似是而非的整上一個星星。

但是到現在為止，我還沒有看過一份完整的資料倉庫的收益分析報告，所以我不明白那些東西怎麼出來的。技術人員和這些術語打交道的時間很少，但是不是絕對沒有。就拿電信行業來說，總部批准建設資料倉庫專案，所有費用撥下來了，怎麼花這些費用不是總部的政策能夠完全左右的，所以在技術交流的時候肯定會問道一些相關的問題。

分析就需要一個度量標準，這個東西學數學或者數學學的比我好的人都能搗騰一個出來，我不能。我只能從表象看問題。

開支是比較容易評估的，一個資料倉庫系統的搭建所需要的物力是物化的，報價單上左右也就那個Discount。然後是人力成本，我一直認為軟體技術人員是比較感性的，最近看了部分這方面的資料，大致能夠理解如何去把這些感性轉換為理性的資料。那麼，開支基本物化了，軟體費用加硬體費用就是開支。

收益如何去評估？我們怎麼量化下面幾個專案？

l 更快的訪問到資料

l 更加可靠的報表

l 更靈活的資料展示

如果不能收集相關的客戶方的資料，也只能忽悠了。

3.專案組成和實施

老大們這個方面都比我厲害，我就隨便扯幾句。

其實很多企業還沒有成熟到一下子就可以上到資料倉庫的層面，如果企業還是單純把資料倉庫作為資料呈現的工具，也就是所謂的報表系統，基本可以確定當前建設一套完善的報表系統就可以滿足需求。

資料倉庫的建設應該是從建設短平快的資料集市開始，各個企業內部的業務部門使用這些資料集市完成自己的需求磨合，然後才把資料集市提升到企業級別的資料倉庫。

遺憾的是，很多資料倉庫專案都是很倉促拍板，倉促施工，完成之後使用者發現自己所需要的資料不能取得或者取得的操作比較麻煩，長期積累的使用者怨氣可能導致整個專案的崩潰，還可能直接導致重建，有點應驗IBM的那句讓人很不痛快的話“系統建設的第一個模型是拿來扔掉的”。

3.1.風險

資料倉庫建設主要有幾個風險，技術風險、業務風險和專案管理風險。

不懂的技術，不知道怎麼搭建系統；懂得了技術，卻束手束腳，不知道如何伸展，這些都是技術風險的一個方面。

技術風險雖然比較嚴重，補足的手段和方法也比較容易：

3.1.1.1.       老人帶新人

經驗部分是可以傳輸和傳授的，有經驗的技術人員可以帶新的技術人員。

3.1.1.2.       使用熟悉的工具

儘量使用大家都比較熟悉的開發工具。這點多說一點，2001年我參加的一個專案，就是因為公司在大部分人知道或者熟悉Visual C++的前提下決定使用C++ Builder開發，導致工期拖延，專案中的成員也苦不堪言。

3.1.1.3.       避免使用未經證明的技術

說起來有點驕傲，我2000年參加的專案是世界上第一個使用JAVA開發的電信級的應用，那個專案施工中得到了Sun和Bea很多的資源，他們建了一個專門的實驗室來支撐這個專案，但是結果不是很令人滿意（幸好計費沒有用JAVA），這就發生了上面工具的那一幕。

3.1.1.4.       多做概念測試

對關鍵技術進行預先測試以滿足需求。現在貴州有家公司使用SQLServer2000作為資料庫支撐整個貴州聯通的業務，但是由於前期技術測試不過關，現在全省話單壓下來，系統每天需要全負荷運轉7個小時才能出最底層的彙總資料，前車之鑑啊。

3.1.1.5.       設計複查，增加專案理解

做前端開發的人員瞭解多少後臺的東西？Cube資料從什麼地方到什麼地方？這些問題在整個資料倉庫系統中多少人能夠掌握？這點有個公司做的不錯，每週整個專案的人作個設計的review，在這個會議上各個小組描述自己的工作，其他小組的可以提出自己的意見和建議，各個小組對專案的理解加深了，對自己的介面更加有信心了。

業務風險最基本的就是系統開發出來和預期不一致，甚至系統根本沒有人使用。

避免業務風險可以使用下面的方法。

3.1.2.1.       使用者參與開發設計

說實話，做到這點真的比較難，只能部分做到。如果讓客戶參與到開發和設計中對系統業務理解和業務把握是非常有益的。

如果參與的是客戶方的技術人員，需要注意的是技術人員的優點是理解系統比較容易，對於系統施工中的難度也能很快掌握，但是缺點是協調能力比較差，很少有技術人員能夠頂住上頭的壓力，這點需要在開發過程中注意

3.1.2.2.       注重推廣和應用

培訓是推廣的一個重要手段，不斷的收集使用者反饋也是一個很重要的渠道。

即使開發團隊採取了正確的技術，並正常地使用了它，但還是存在不能按時或按預算完成工程的開發和實施。可以通過如下的手段來克服這種風險：

3.1.3.1.       明晰的計劃

專案初期的計劃制定非常重要，整個計劃指導專案的施工，這點老大們比我有心得，我就不班門弄斧了。

PS：我在這裡提出這個來，但是自己做的很弱，很慚愧。

3.1.3.2.       管理方法

一個強大的方法會起到工程管理和工程團隊路標的作用，指導開發人員如何前進。（這不是我說的，我說話的風格不是這樣）。

3.1.3.3.       需求變更控制

這點不用多說了。

3.2.開發團隊構建

以下是資料倉庫團隊建設的幾個部分。

專案經理作為整個專案中的靈魂人物，專案成敗的關鍵，簡單說手中掌控專案的生死成敗。專案經理不一定是技術的專家，但必須理解和檢查專案的每個細節，並知道關鍵路徑在那裡，以及如何引導專案前進。

應該應具備的能力：

l 有效計劃和分配資源。

l 團結並激勵整個團隊並使其保持和諧。

l 善於與客戶溝通。這點比較重要，我和我的前任都被客戶說過“溝通不暢”，主要是公司政策和專案實施之間的權衡。

l 善於控制專案規模

l 進行風險管理

l 定期評定專案開發成果並評估每個人員

l 敢於承認失敗並把專案帶回正軌

與比終端使用者相比他能從更全面的角度來衡量業務，並能從某些技術的角度提供些建議。

應具備能力：

l 相關業務經驗比終端使用者還要豐富

l 瞭解行業的標準及發展趨勢

l 瞭解資料倉庫的一些技術實現

l 善於將業務轉化為技術人員所能接受的語言

應具備的能力：

l 分析並引導使用者的需求

l 對資料庫的正規化和星型結構熟練運用

l 設計系統的ER圖和資料字典如屬性、約束等

l 善於溝通，能把專案的設計架構清晰的告訴別人

l 熟悉RDBMS並有良好商業分析能力

終端使用者作為需求的提出者參與專案是因為終端使用者對相關業務比專案中任何成員都瞭解。與這些人搞好關係，因為他們往往也是專案的驗收者。

參與專案的終端使用者應具備的能力:

l 必須對原有系統和業務有深入瞭解。

l 必須明確專案的成敗和他個人關係緊密。

l 讓他明確知道和理解你的專案會為他的日常工作帶來便利，並且有責任和義務傳達這個訊息給他的同事和領導。

l 有許可權協調其他相關係統的資源配備。

l 必須明確參與專案的終端使用者中的某一位是需求的最終出口。

DBA負責資料的最終儲存、資料庫的優化以及資料庫授權。

應具備能力：

l 強的資料庫技能。

l 能夠實現邏輯模型向物理模型的轉換。

l 監視對資料的訪問和資料庫的效能並及時調整。

l 協助ETL工程師保證其資料載入成功。

l 制定整體的資料更新和維護策略或方案。

作為資料倉庫中的搬運工，這個職位最是辛苦。其工作決定了資料倉庫專案的可用性和後期維護量。

應具備的能力:

l 深入瞭解現有系統，並理解系統內資料儲存。

l 熟悉業務知識，瞭解業務邏輯。

l 熟悉介面和規範。

l 有很強的編碼和開發能力。

l 應該是一個認真仔細並很有耐心的人，髒資料對系統的影響往往能超出一的想象。

提供資料的最終展現，應該具備的能力：

n 審美能力，知道如何設計好的展現

n 使用者溝通能力，系統搭建後期資料問題完成之後就是介面的問題了。

n 瞭解使用者操作習慣。

n 還是需要有耐心，很多中國特色是折磨人。

其工作的重要性每個人都知道，如果不把使用者教會你完成的專案有什麼意義呢?

應具備能力：

l 有優秀的交流技巧和無限的耐力。

l 具備資料倉庫各技術環節和使用者業務的相關知識。

l 編寫出色的培訓教材和演示文文件。

l 積極樂觀的態度，笑容是具有傳染力的。

4.資料抽取層

資料抽取層包含ETL過程和聚合表的生成過程。做好ETL的前提條件是：

l 好的模型表述，這需要對業務系統的理解。

l 對資料模型的理解

l 對資料來源理解（包括平臺資訊，表結構，字典等等資訊）。

l 對目標系統平臺的理解（包括資料庫資訊，平臺作業系統相關資訊）

4.1.ETL？ELT？

一般的資料倉庫資料裡面說這個的時候都比較理論化，一個ETL過程怎麼著也是那麼幾張圖。ETL過程本身不是很複雜，複雜的是ETL中的資料和邏輯（業務關係）。ETL過程中的資料組織是由上層建模所決定的，上層建模涉及到的東西比較業務化，我沒法多說。

電信級的資料一般都比較大，一般採用資料檔案方式傳輸，以前我們施工的時候採用的DB Link方式也是先對資料進行dump out到檔案操作，然後再對檔案進行load操作。原因是資料的塊操作比流操作快很多。一個比較極端的例子是當前我施工的專案使用的SybaseIQ資料庫，直接使用Insert語句插入資料庫的所需要的時間比同等的load操作慢百倍以上。

以下只針對檔案載入進行討論。

檔案載入的流程是：取得檔案>生成資料庫指令碼>執行load語句或者命令。

在上面的流程中我刻意的漏掉了ETL中的那個T(清洗，轉換過程)。這個過程到底是放在Load之前還是Load之後？不用說，分析流式檔案比資料庫整表Update效能弱，而且很容易產生錯誤。所以我說檔案方式載入的流程應該是ELT而不是ETL。

一個比較特殊的例子是我參與的網管分析系統中話單的採集。因為原始檔案是使用Visual C++直接生成的，在結構體中為位元組對齊填充了一些無效的Byte，一般的載入指令碼或者語句很難正確執行，所以就採用了比較尷尬的ETL流程：取得檔案之後>分析檔案>轉換清洗>執行Load操作。

PS：也有把ETL整成四個步驟的抽取，轉換，載入和清洗。

4.2.資料分層（Stage）

理論告訴我們應該是在DW層之下有一個ODS層。這個ODS層儲存的資料應該和業務系統資料基本保持一致，我所說基本保持一致是因為ODS層的資料是經過清洗和轉換的。

按照上面一節的說法，ODS除了儲存和查詢操作資料之外，還應當承擔資料清洗和轉換工作，這樣對於這層的資料要求比較嚴格，例如使用者如果在資料庫進行清洗轉換的時候執行了一個明細資料的查詢，將會導致不可預料的結果返回，甚至可能引起表鎖。

我們的建議是在ODS層下面增加一層Buffer層，這層的資料儲存只是為了轉換和清洗。

資料從檔案中直接Load進入Buffer層，然後執行Buffer層的轉換和清洗完成之後再將資料轉出到ODS層中。為了節約儲存和提高效能，建議Buffer層資料不作歷史沉澱。

增加一個Buffer層還有一個好處是減小資料庫的壓力。按照資料倉庫的建設目標，資料倉庫的中各個層面主要的最終應用是提供查詢，所以DBA對資料庫進行效能調整的時候可以專注在調整Buffer層的更新和插入，其他層面可以弱化調整。

4.3.儲存策略

資料倉庫產生的歷史沉澱是比較驚人的，拿使用者計費話單為例，一個400萬在網使用者數的省分，每月產生的話單在3～4億條之間，按照一般的設計，ODS層資料儲存的時長為6個月，這麼大的資料儲存在資料庫中，必然引起資料的查詢效能降低，到底是使用分表儲存還是使用分表空間儲存，各自有定論，以下試著列出兩種儲存策略的特點：

介面方面，分表空間儲存佔有天然的優勢，客戶端程式不需要做其他特殊操作就可以了做到對非當前月的資料的查詢，如果使用分表儲存則需要客戶端程式根據引數修改表名稱。這對於大部分應用，尤其是使用儲存過程的應用來說簡直就是一場噩夢。

儲存的額外開銷方面，兩種方式相差不大，畢竟對於資料量來說段位所佔用的空間及其微小。

執行效能方面則分表的比較佔優勢，無論DBMS如何強大，對於分表空間儲存的查詢還是有個定位過程，而分表可以免除這點。全表更新的時候分表的優勢體現的比較明顯。

4.4.工具的選擇

工具的選擇應該還是以實用為本。我參與的專案中，有兩個專案使用的DataStage，一個專案使用Powermart，試著問問，這些工具中我們使用的功能集佔全部軟體提供的功能集的百分之多少，拿著軟體的Features list應該可以得到一個大致的結論。

工具選擇需要考慮的兩個因素是價值和成本。

價值也就是說這個工具到底提供了什麼樣的功能，或者我的期望到底是什麼。基礎價值非常明確：資料對映，轉換規則對映和支援當前使用的資料倉庫產品。

有幾點不得不考慮

l 工具的伸縮性如何，能否支援自定義任務或者轉換

l 是否支援工作流方式的載入

l 錯誤支援的級別如何,錯誤細化到什麼程度(如果ETL工具只告訴你話單載入失敗，你要花多少時間才能解決問題？如果ETL工具明確的告訴你是某欄位轉換錯誤呢？)

l 是否支援資訊通知/通告

l 是否支援任務重新排程

l 是否支援檔案載入的檔名動態定義

l 是否支援實時載入

可惜的是，現在市面上的產品對於以上功能總是有那麼一些不符合。最後一個功能點，我提到一個實時載入的概念，這個主要用於電信經營分析中的話單載入，由於話單數量非常大，處理時間比較長，對資料來源提供方和接受方都是一個不小的挑戰，所以我們採用實時話單採集的方式，只要話單檔案存在就直接採集到經營分析系統中。這個實時載入我所接觸的工具都不能滿足。

我所參與的一個專案中，在專案初期施工中發現數據的瓶頸就在於Datastage的資料載入，後來ETL組修改了載入的過程，使用TCL這個指令碼語言＋Crontab實現了ETL排程和載入解決了這個問題。

是不是我們就真的需要自己編寫一個ETL工具？答案比較曖昧，這個涉及到第二個選擇ETL工具需要考慮的因素，成本。

其實一個ETL工具不見得需要多麼複雜，簡單的來說，軟體是以實用為本。

ETL工具主要有以下幾個部分組成：

l 時間觸發器

l 業務單元，處理原生的載入和轉換等等任務

l 事件，通知使用者

l 由業務和事