從RDB DB DDB DW到DC的幾篇文章學習

從RDBDBDDBDW到DC的幾篇文章學習2012-07-2910:16:50分類：IT職場從RDBDBDDBDW到DC

實時數據庫

數據庫文檔數據庫數據倉庫數據中心

--

數據倉庫的建設是一個巨大的工程，按照倉庫的理論思想和我自己實際的倉庫建設過程，我覺得數據倉庫最好分為六層的設計思想來構建和實施：

一，源數據層

源數據層的目的是為數據倉庫提供數據來源，它的數據來自于倉庫外部，如企業(yè)各應用系統(tǒng)，各部門的源數據，企業(yè)的外圍數據，如行業(yè)標準等。這些數據的特點是：

1，它們是動態(tài)的，數據可能隨時間變化。

2，它們是面向應用，面向業(yè)務的。

3，它們是明細的，數據粒度是最低的。

4，它們是固定的，在倉庫建設過程中，不允許干系人更改它們。

5，它們是形式多樣化的，可能以多種新式出現（如file,dbtable,dataset,xml,sap,xls等)。

6，它們的物理位置的多樣性，數據可能在一臺機器上，也可能在一個局域網類，也可能在internet上。

7，它們生成的多樣性，我們可能每天都到一個固定的地方獲取它們，也可能是臨時的，跟政策相關的，經協(xié)商后產生并提供給倉庫用的。

源數據層中數據的生命周期：在數據倉庫建設過程中，我們只要向它們取數就行，不用考慮其生命周期。

在數據從本層到ODS層加工的過程中，我想強調的有一下幾點：

1，etl工具的使用：

具體情況具體對待，如果源數據層的構成比較簡單，數據量也比較少，加工的時間窗口充足，則為了節(jié)省成本，可以用一些免費的工具，或者自己開發(fā)工具。如果構成比較復雜，數據量也很大，為了保證加工的時間窗口，在資金充足的情況下，建議使用datastage,informatic之類的工具，因為它們在異構數據環(huán)境下的數據搬運能力不容小覷。

2，工作內容分析：

本階段的工作是ETL的E部分，即數據的抽取。當然也包括部分為了更好的抽取而進行的必要數據清洗過程。這部分的工作量依賴于源數據層的構成，源數據層中數據的規(guī)整程度以及數據量的大小。如果源數據層構成比較復雜，再加上它數據的規(guī)整程度很低，數據量又很大，則本層的工作量是相當的大。否則，則工作量如其它各層的相當。

舉例說明，在某銀行的數據倉庫建設過程中，一個19GB的數據文件入庫時報錯，經漫長的分析后，發(fā)現是數據中的某個中文漢字的編碼中包含了作為分隔符的‘|’。再如某銀行的數據倉庫建設過程中發(fā)現，某上級單位下發(fā)的非開放式標準的xml類型的數據，需要經過單獨開發(fā)工具加工處理后才能入ODS層的庫。

二，ODS層

數據從源數據層經過簡單的清洗后，或者不經過清洗直接搬運后就到了ODS。

ODS層的功能是：

1，為S_DW層提供數據

2，為查詢分析層提供明細數據查詢

3，隔離了分析系統(tǒng)與業(yè)務系統(tǒng)，保證了業(yè)務系統(tǒng)的安全性，減輕了業(yè)務系統(tǒng)的壓力。

ODS層數據的特點是：

1，數據內容與源數據層完全一樣或基本一致。

2，數據是明細的，粒度最低的。

3，數據是面向主題存儲的。

4，數據是反映歷史變化的

5，數據是穩(wěn)定的。

ODS層數據的生命周期：一天

數據從ODS層加工到S_DW層過程中：

1，etl工具的使用：

建議用procedure,function,UDF等來完成。

1，優(yōu)點是：效率高，軟件費用低，無需額外第三方etl工具的技術支持。

2，缺點是：不便于開發(fā)，維護；調度，運行的可監(jiān)控性較差。

2，工作內容分析：

本階段的目的是清洗，整合，加工數據。對應于ETL的T，即加工。由于ODS層的每個表數據量都相對較小，故本層中適合做加工處理，多表的關聯(lián)等。在建好模型的基礎上，本部分的開發(fā)工作量不是太大。本層的數據依賴于源數據層的數據，而且加工處理較多。故數據加工時間可能比較大。

三，S_DW層

ODS層的數據經過清洗，加工，整合后就到了S_DW層，S_DW層其實是從ODS層分解出來的，它是ODS層和DW層之間的一個中間層，它不是必須的，如果數據倉庫比較大，比較復雜，那么建議使用本層，以提高效率。本層的存在相當于用空間來交換時間。

S_DW層的功能是：它為數據從ODS層到DW層提供了一個緩沖，相當于一個臨時空間，節(jié)省了FACT表和DIM表生成的時間。

S_DW層數據的特點：

1，數據的規(guī)整程度較高。

2，數據的粒度較低。

3，數據是面向主題的。

4，數據是反映歷史變化的。

5，數據是穩(wěn)定的。

S_DW層數據的生命周期：一天

數據從S_DW層加工到DW層過程中：

1，ETL工具的使用：

同ODS層。

2，工作內容分析：

本階段的目的是把整合后的業(yè)務數據表加工成符合入倉庫規(guī)則的FACT表和DIM表。然后數據以FACT表和DIM表的形式入倉庫。對應于ETL過程的L，即入倉庫。在建好模型的基礎上，本部分的開發(fā)工作量不是太大。本層的數據依賴于ODS層的數據，加工處理，整合較少。故數據加工時間也較少。四，DW層

當FACT表，DIM表生成后，就可以利用它們按照主題來建CUBE了。CUBE建成后，數據倉庫就基本建成了。后繼所需的工作就是每天（增量或全量）刷新CUBE，或者按照需求往倉庫中新增主題，新增CUBE來充實倉庫了。

DW層的功能是：為后繼的基于倉庫的應用提供基礎。

DW層數據的特點：

1，面向主題

2，穩(wěn)定的

3，反映歷史變化的。

4，集成的。

DW層數據的生命周期：倉庫的數據規(guī)劃保留期。

數據倉庫中的cube加工注意事項：

CUBE的刷新方式：最好使用日增量方式，不然時間會特別慢。CUBE的模型也特別影響CUBE的刷新時間，當CUBE的模型發(fā)生變化時，CUBE必須要全量刷新。另外有個細節(jié)問題須強調的是，在緯度表中，要有條“未知”記錄來描述一些不太規(guī)整的事實。

五，查詢分析層

就我接觸的，知道的，基于倉庫的應用：

1，多維分析層

經營統(tǒng)計分析，風險分析，績效考核，客戶分析，產品分析等。

它們向cube取數。

2，二維報表層

提供上級部門必須的報表，如銀監(jiān)局，人行，外管局所必須的報表。

它們可以從dw層取數

3，信息查詢層

比如某些特殊的報表，需要知道最n的m條記錄的信息，例如想知道今天交易的最大的10比貸款的客戶資料。

準確的說，他們應該是從dw或s_dw,或ods層取數據。

4，數據挖掘層

我沒有具體做過挖掘，僅僅是知道他們是基于倉庫的應用而已。

六，應用層

經過前面的建設，我們就可以從信息系統(tǒng)獲取信息了。但是經過對DW中信息的分析得出了某些知識后，我們怎么樣去使用這些知識呢？這就是DW信息系統(tǒng)建設的目的和意義所在。

我參與建設的銀行信息系統(tǒng)中，較少有涉及到這一層的。下面就以我個人的理解來做表述。

1，應用層體現了基于DW的信息系統(tǒng)建設的目的。

譬如說，我們用多維分析能夠分析出什么樣的結論？這些結論能夠幫我們解決什么樣的問題？我們是否在用這些結論在解決這些問題？數據挖掘挖掘出來的知識的正確性有多大？可用程度有多大？它是否在為決策支持等提供服務？信息查詢中查詢處的信息，我們是怎樣在用它們呢？等等。總之這些信息，知識，結論是否能夠在節(jié)省成本，增加利潤，提高績效，規(guī)避或降低風險，優(yōu)化企業(yè)業(yè)務結構，組織結構，客戶構成等方面發(fā)揮作用呢？

2，應用層應為企業(yè)發(fā)展的戰(zhàn)略，戰(zhàn)術目標以及領導決策提供支持服務。

譬如說，經營統(tǒng)計分析告訴了我們企業(yè)利潤的組成及發(fā)展趨勢。產品分析告訴了我們，客戶分析告訴我們。風險分析告訴我們

通過種種分析方法，我們可以知道，企業(yè)應該通過開發(fā)什么樣屬性的產品來吸引什么樣的客戶，以以最小的風險來謀取最大的利潤。

風險分析分析結論的使用是否真正的了規(guī)避了風險?績效考核是否找到績效低下的原因，是否可以找到提高績效的方法？

3，應用層應為應用，業(yè)務系統(tǒng)提供服務。

譬如說，在銀行業(yè)務中，通過查詢分析，我們知道了某客戶是當月存款最大的客戶，那么當此客戶到銀行來辦理業(yè)務的時候，應用層程序就應該告訴客戶經理可以為該客戶提供的產品。

總結：

從上面的描述中可以看出，DW的建設是一個長期的連續(xù)的過程。它是由業(yè)務驅動的，也應該是驅動業(yè)務的，而后者在銀行中的應用體現卻不是很充分。

思考：

新應用，新業(yè)務，新產品產生后，倉庫要做哪些變化。

怎樣才能使倉庫的可擴展性強，怎樣使倉庫的架構穩(wěn)固。

怎樣使倉庫隨著應用數據量的增大，應用數的增多，而效率變化不大。

高效實現數據倉庫的七個步驟

數據倉庫和我們常見的RDBMS系統(tǒng)有些親緣關系，但它又有所不同。如果你沒有實施過數據倉庫，那么從設定目標到給出設計，從創(chuàng)建數據結構到編寫數據分析程序，再到面對挑剔的用戶的評估，整個過程都會帶給你一種與以往的項目完全不同的體驗。一句話，如果你試圖以舊有的方式創(chuàng)建數據倉庫，那你所面對的不是預算超支就是所建立的數據倉庫無法良好運作。

在處理一個數據倉庫項目時需要注意的問題很多，但同時也有很多有建設性的參考可以幫助你更順利的完成任務。開放思維，不斷嘗試新的途徑，對于找到一種可行的數據倉庫實現方法來說也是必需的。

1.配備一個全職的項目經理或你自己全面負責項目管理

在通常情況下，項目經理都會同時負責多個項目的實施。這么做完全是出于資金和IT資源方面的考慮。但是對于數據倉庫項目的管理，絕對不能出現一人身兼數個項目的情況。由于你所處的領域是你和你的團隊之前沒有進入過的領域，有關數據倉庫的一切－數據分析、設計、編程、測試、修改、維護－全都是嶄新的，因此你或者你指派的項目經理如果能全心投入，對于項目的成功會有很大幫助。

2.將項目管理職責推給別的項目經理

由于數據倉庫實現過程實在是太困難了，為了避免自虐，你可以在當前階段的項目完成后就將項目管理職責推給別的項目經理。當然，這個新的項目經理一定要復合第一條所說的具有全職性。為什么要這么做呢？首先，從項目經理的角度看，數據倉庫實施過程的任何一個階段都足以讓人身心疲憊。從物理存儲設備的開發(fā)到Extract-Transform-Load的實現，從設計開發(fā)模型到OLAP，所有階段都明顯的比以前接觸的項目更加困難。每個階段不但需要新的處理方法、新的管理方法，還需要創(chuàng)新性的觀點。所以將管理職責推給別的項目經理不但不會對項目有損害，還可以起到幫助作用。

3.與用戶進行溝通

這里所講的內容遠比一篇文章本身要重要的多。你必須明白，在數據倉庫的設計階段，那些潛在用戶自己也不清楚他們到底需要數據倉庫為他們做什么。他們在不斷的探索和發(fā)現自己的需求，而你的開發(fā)團隊也在和客戶的接觸中做著同樣的事情。更加頻繁的與客戶接觸，多做記錄，并讓你的團隊更關注于項目需求討論的結果而不是討論的過程本身。

既然你和客戶的交流是為了了解存儲的數據是何種類型以及如何有效存儲數據，你也許需要（和你的用戶一起）采用一種新的方法觀察數據，而不是直接處理數據。你可以嘗試從中找出隱藏的信息，比如在一段時期內的數字漲落等。不要試圖追尋項目需求的答案，而是要讓答案找上門來。

4.以技術/信息庫作為領導

由于數據倉庫實施的各個階段都有很大不同，因此你需要有人能起到維持整個項目的連續(xù)進行的作用，不過這個職責并不需要那種全職性。項目實施有三個重要方面：架構、技術和業(yè)務。將架構作為重點可以保證在整個項目中，數據倉庫的架構從物理層往上，都會受到良好的維護。而我們應該將技術作為重點，因為開發(fā)團隊和關鍵用戶都在使用他們以前從未用過的工具，必須有人監(jiān)督開發(fā)過程以及工具使用的一致性。

最后，在數據倉庫的應用過程中浮現出來的業(yè)務需求必須被詳細分析和記錄，以促機開發(fā)過程持續(xù)下去。如果用戶不能很好的開發(fā)人員以及其它用戶溝通，那么數據分析和度量方面的開發(fā)進程就會延期，所以必須有人關注業(yè)務方面的開發(fā)，推動開發(fā)進入更高級別。

5.跳出反復修改程序的陷阱

第一次實現的數據倉庫肯定不會是最終交付的版本。為什么呢？實際上在真正見到產品前，你無法確定的知道自己的目標是什么?；蛘哒f，最終用戶只有在使用數據倉庫產品一段時間后，才能明確告訴你這個產品是不是他所希望的。與你以往處理的項目不同，業(yè)務智能還處于發(fā)展的初期，每個公司對業(yè)務智能都有不同的解釋，因此你的項目決不會一次成功。

為了以正確的格式獲得數據，你需要在不斷變化的狀況中摸索前進。BI具有很強的個性，不同的環(huán)境、不同的市場以及不同的企業(yè)都有不同的BI。這又代表什么呢？這表示你需要把數據庫管理員放在一個消息相對封閉的環(huán)境中，不要讓他知道數據倉庫的數據結構以及ETL程序在不斷的改變。對此沒有別的辦法。這樣可以減輕你和DBA所承受的壓力。

6.對大量的前端資源進行數據源分析

在數據倉庫實現過程中，你不得不在舊有的數據中艱難跋涉，這些數據來自老的數據庫、老的磁帶機以及遠程的數據。它們中的大部分都凌亂不堪，并且難以獲取。你要對這些數據進行大量處理，并且還要設計ETL程序來尋找其中的有用信息。如果你希望整個項目做起來比較順利，并且找到一種方法能夠一次成功，那就需要你的開發(fā)人員必須花費足夠的時間來充分研究這些舊有數據，將凌亂的數據規(guī)則化，并盡力設計和實現強壯的數據采集和轉換過程。數據倉庫的ETL部分會占用整個項目資源的百分之八十，所以一定要確定你的資源都用在刀刃上了。

將人際關系處理放在首位

在數據倉庫實現過程中真正的地獄不是來自技術或者開發(fā)方面，而是來自你周圍的人。你也許會遇到一個對項目并不樂觀而又沒時間聽你陳述的領導。你也許會遇到一些開發(fā)人員將進度拖延太長時間還抱怨為什么不能用老方法實施。你也許還會遇到一些抱有不切實際的幻想的用戶，他們希望輕點鼠標就能實現想象中的功能，但卻不愿在他們那邊多做些智力投資，更好的培訓他們自己的員工。而你也已經疲憊不堪，鼓勵投資，以及在開發(fā)團隊和用戶（甚至老板）中推廣新的開發(fā)技巧。

總之你要保持微笑。當一切搞定，你的煩惱也就一掃而空了，笑到最后才笑得最輕松。

數據倉庫開發(fā)過程中的七個禁忌

過去我們一直使用的OLTP技術也許隱藏著許多嚴重的缺陷。數據倉庫的實現并不是一個簡單的任務，你會發(fā)現以前積累下來的豐富經驗，并不適合處理每個數據倉庫的獨特需求。

下面列出的條款是你在實現數據倉庫過程中一定會面對的問題，其中一些看起來并沒有想象中那么嚴重，但是你還是應該盡量避免出現類似問題。數據倉庫并不是一個事務處理系統(tǒng)，它沒有一定的標準也不會實現某個特定的應用，但它本質上是非常有組織性的?？傊?，每個公司所建立的數據倉庫都是唯一的，并且每一次數據倉庫的實現方法都不是一成不變的。在實現數據倉庫時需要注意的不單是"應該如何作"，更要注意"不該如何做"。下面就是我們總結的七點"不該如何作"。

1.不要編寫自己無法快速修改的代碼

你所要編寫的程序主要用于數據分析，而不是處理事務。而你的用戶也并不真正知道他們自己真正想要一個什么樣的程序。因此你不得不反復修改代碼好幾次，才會明白用戶到底需要一個什么樣的程序。如果你編寫的程序具有良好的結構和靈活性，就算需要修改也不會太浪費力氣。反之，你會被自己累死。

2.不要使用無法修改的數據庫訪問API

在過去，你的數據庫可以為大量的客戶提供穩(wěn)定的數據查詢服務。而如今，你的程序必須能夠應付更多的數據查詢。這使得重新改寫程序以使得每個查詢請求能得到最大的數據量成為勢在必行的工作，而一般來說這種代碼修改都不會一次成功，所以只有選擇合適的可以修改的API，才能使程序盡快適應新的需求。

不要設計任何無法擴展的東西

在聯(lián)機處理過程（OLTP）應用中，數據分析并不是一個真正的應用程序。實際上，數據分析的關鍵是獲取大量舊的數據，從中提取數據模型，并以此模型推斷出新的信息。而你所編寫的訪問潛在信息的代碼應該具有可擴展性，可以附加新的數據。千萬別在支持數據分析的代碼中假定數據都是固定格式的。

不要附加不必要的功能

一個倉庫要做的是恰到好處的服務，用戶走進倉庫，從貨架上取得自己所需得信息，僅此而已。由于業(yè)務智能、分析以及規(guī)律性的問題都有各自的處理程序，因此你的客戶唯一的需要就是獲取信息。他們需要一種應用環(huán)境，可以讓他們快速的從數據倉庫中取得分析過程所需的數據，而不論這個數據是什么樣子的。也許你想幫助他們精煉一下獲得的數據，但最好不要這么做。一定要記住，不要給客戶的數據分析程序添加任何會影響數據訪問性能的功能。

5.不要簡化數據清除和數據源分析的步驟

在實現數據倉庫過程中最應該注意的地方就是為Extract-Transform-Load機制分析數據源，以及為優(yōu)化負載而清除數據。安全的做法是假設項目經理在這個階段會需要整個項目資源的一半以上。相反，如果你在這方面進行了簡化，稍后肯定會后悔。所以就算系統(tǒng)工作緩慢，也不要簡化清理舊的數據的過程。

6.不要避免顆粒度和分區(qū)問題

在數據倉庫設計過程中有兩個最大的數據存儲問題，第一是如何給轉換數據定位一個恰當的顆粒度等級，第二是如何將數據絕對的分區(qū)。為什么這兩點問題如此重要呢？因為整個數據倉庫的響應能力受顆粒度影響，并且數據訪問的效率直接與數據分區(qū)性能有關。因此這是具有關鍵性的工作，不要試圖避免面對這些問題。

7.不要在沒考慮業(yè)務問題前就使用OLAP

用戶在親眼見到程序前通常都不知道自己到底想要個什么樣的程序。因此他們的觀點有不少錯誤，比如他們希望分析結果會忠實反應性能度量，或者希望程序會使他們部門或公司的業(yè)務工作有所不同。而你必須跳出自己的職責范圍，從IT管理者的角度考慮用戶部門直至整個企業(yè)的運行方式，才能在開發(fā)過程中避免這類問題。在通常的OLTP開發(fā)中，你可以比較方便的理解業(yè)務流程。而在聯(lián)機分析處理（OLAP）領域，任何事情都需要親自考察，而在你周圍工作的人也許并不會發(fā)現你對業(yè)務方面存在的誤解。因此，不要自以為已經了解了足夠的信息。不斷的詢問才能使你真正了解"業(yè)務智能"中的"業(yè)務"到底是什么樣子的

順利開發(fā)數據倉庫的七種思路

對于大多數IT顧問來說，實現一個數據倉庫的難度比以前做過的任何項目難度都要大?？紤]到不同的數據結構、用途以及應用程序開發(fā)方法，以前所積累的經驗和技巧大部分都無用武之地了。但是只要在你的前進道路上稍加修正，你就會發(fā)現實現一個數據倉庫并不是難事，就算你是第一次實現數據倉庫也沒問題。

下面列出了數據倉庫實施過程需要考慮的步驟，有一些你可能從來沒有意識到，而另一些可能已經在實施過程中使用到了，但是重新思考一番也許你會有更多的領悟。開放思維，不斷嘗試新的途徑，找到一種可行的數據倉庫實現方法。

1.再三考慮應用程序的實現方法

數據倉庫并不涉及事務處理，并且在報表方面也僅占一小部分。而數據倉庫應用程序的本質是分析，尤其是針對業(yè)務智能的分析。BI并不是通常所說的數據：它是一種從舊有數據中,模型化得到的新的數據。那么如何才能從舊有數據中挖出這些新數據呢？事實上，這個工作不是讓你來完成的，而是你的客戶所要完成的。從項目主管的角度看，應該有一個經驗豐富的數據表格設計師與你合作，進而決定如何將各類程序融合在一起。其中所遇到的最主要的挑戰(zhàn)將是如何用新的方法觀察數據，這也是你的客戶正在試圖使用的方法。

創(chuàng)建抽象的、良好部署的數據庫訪問組件

在過去你接觸過的數據庫項目和現在的數據倉庫之間，有一點絕對不同，那就是：在OnlineTransactionProcessing（OLTP）環(huán)境中，用戶數量非常大，但使用到的數據卻比較少；而在OnlineAnalyticalProcessing（OLAP）環(huán)境中情況卻正好相反，少量的用戶在使用大量的數據。而你的工作就是編寫一個應用程序來優(yōu)化這種不同。這里有一個線索：在你所有的分析程序中，都要能抓取連續(xù)的數據項，這樣在以后建立和訪問的數據結構中才能存放與原數據物理結構類似的數據。具體如何實現呢？首先不要規(guī)格化數據。第二將其放入數組中最小化讀取請求數。按照這種方法，DBA會很樂意與你合作。

3.保持松散

現在回頭看看第一步，你應該可以理解定義一個分析程序不是件簡單事了，而且一般情況下，很難在第一次就實現符合要求的最終產品。而在你將要進行分析的數據結構上同樣存在這種問題。一句話，實現過程會有很多變數，你需要不斷的改動你的程序。通常我們都希望將改動次數降到最低。在一個數據倉庫實現過程中，本質是要分析過程毫無差錯，這也需要DB