數據倉庫如何建立

A. 數據倉庫與數據挖掘技術—特點及元數據

數據倉庫具有以下特點

數據倉庫中的數據是面向主題組織的

在較高層次上對分析對象的數據做一個完整的、一致的描述，能有效地刻畫出分析對象所涉及的各項數據及數據間的聯系。主題通常在一個較高層次上將數據歸類的標准，每個主題對應一個宏觀分析領域。數據倉庫中應重新組織數據，完成業務數據向主題數據的轉換。主題的抽取則應根據分析的要求進行確定，根據所需要的信息，分不同類別、不同角度等主題把數據整理之後存儲起來

數據倉庫的數據是集成的

事務處理系統中的操作型數據在進入數據倉庫之前，必須經過統一和綜合，演變為分析性數據。需要完成的工作包括：處理欄位的同名異義，異義同名，單位不統一，長度不一致等問題，然後對源數據進行綜合和計算，生成面向主題分析的高層、綜合的數據

數據倉庫的數據是穩定的

數據倉庫中存放的是供分析決策用的歷史數據，而不是聯機事務處理的當前數據。涉及的數據操作主要是數據查詢，一般不進行數據的增刪改操作

數據倉庫的數據是隨時間不斷變化的

數據倉庫系統需要不斷獲取聯機事務處理系統不同時刻的數據，經集成後追加到數據倉庫中

數據倉庫中的數據分為四個級別、早期細節級，當前細節級，輕度綜合級，高度綜合級

首先進入當前細節級，並根據具體需要進一步的綜合，從而進入輕度綜合級，乃至高度綜合級。老化的數據進入早期細節級，數據倉庫中存在著不同的綜合級別，一般稱之為粒度。粒度越大，表示細節程度越低，綜合程度越高

元數據是「關於數據的數據」，是新一輪迭代開發和數據倉庫維護的主要技術手冊。如同數據倉庫的導航器，快速高效的定位信息，實現數據檢索和挖掘

1、技術元數據

存儲關於數據倉庫系統技術細節的數據，是用於開發和管理數據倉庫使用的數據。它主要包括數據倉庫結構的描述、業務系統、數據倉庫和數據集市的體系結構及模式以及匯總用的演算法和操作環境到數據倉庫環境的映射

2、業務元數據

業務元數據從業務角度表述了數據倉庫中的數據

數據倉庫的建立過程一般有兩種方法，「自頂而下」和「自底而上」。

自頂而下：先建立一個企業級數據倉庫，然後再在其基礎上建立部門級數據集市。

自底向上：優先建立一些數據集市，最後再把它們匯集成一個企業級數據倉庫。

B. 請問數據倉庫都用什麼建立

1、首先你得搞清楚建設數倉的目的是什麼

是偏向於整合各系統數據，為數據分析決策服務，還是偏向於快速的完成分析決策需求？

如果是前者，那麼在數據倉庫建模的時候一般會選擇ER建模方法；

如果是後者，一般會選擇維度建模方法。

• ER建模：即實體關系建模，由數據倉庫之父BIll Inmon提出，核心思想是從全企業的高度去設計三範式模型，用實體關系描述企業服務。主張的是自上而下的架構，將不同的OLTP數據集中到面向主題的數據倉庫中。

• 維度建模：由Kimball提出，核心思想是從分析決策的需求出發構建模型。這種模型由事實表和維表組成，即星型模型和雪花模型。Kimball倡導自下而上的架構，可以針對獨立部門建立數據集市，再遞增的構建，匯總成數據倉庫。

2、其次你得進行深入的業務調研和數據調研

• 業務調研：深入的業務調研能使你更加明確數倉建設的目的；同時也利於後續的建模設計，隨著調研的開展，如何將實體業務抽象為數倉模型會更加明朗。
  

• 數據調研：各部門或各科室的數據現狀了解，包括數據分類、數據存儲方式、數據量、具體的數據內容等等。這對後續的主數據串聯或者維度一致性處理等等都是必須的基礎。

3、然後是數據倉庫工具選型

• 傳統型數據倉庫：一般會選擇第三方廠家的資料庫和配套ETL工具。因為有第三方支持，相對有保障；但缺點也很明顯，受約束以及成本較高。
  

• NoSQL型數據倉庫：一般是基於hadoop生態的數據倉庫。hadoop生態已經非常強大，可以找到各種開源組件去支持數據倉庫。缺點是需要招聘專門人士去摸索，並且相對會存在一些未知隱患。

4、最後是設計與實施

• 設計：包括數據架構中的數據層次劃分以及具體的模型設計；也包括程序架構中的數據質量管理、元數據管理、調度管理等；
  

• 實施：規范化的項目管理實施，但同時也需記住一點，數據倉庫不是一個項目，它是一個過程。

C. 數據倉庫的建立步驟

1)收集和分析業務需求
2)建立數據模型和數據倉庫的物理設計
3)定義數據源
4)選擇數據倉庫技術和平台
5)從操作型資料庫中抽取、凈化、和轉換數據到數據倉庫
6)選擇訪問和報表工具
7)選擇資料庫連接軟體
8)選擇數據分析和數據展示軟體
9)更新數據倉庫 1)數據轉換工具要能從各種不同的數據源中讀取數據。
2)支持平面文件、索引文件、和legacyDBMS。
3)能以不同類型數據源為輸入整合數據。
4)具有規范的數據訪問介面
5)最好具有從數據字典中讀取數據的能力
6)工具生成的代碼必須是在開發環境中可維護的
7)能只抽取滿足指定條件的數據，和源數據的指定部分
8)能在抽取中進行數據類型轉換和字元集轉換
9)能在抽取的過程中計算生成衍生欄位
10)能讓數據倉庫管理系統自動調用以定期進行數據抽取工作，或能將結果生成平面文件
11)必須對軟體供應商的生命力和產品支持能力進行仔細評估
主要數據抽取工具供應商：Prismsolutions.Carleton'sPASSPORT.InformationBuildersInc.'s
EDA/SQL.SASInstituteInc. 一般問題 (不完全是技術或文化，但很重要) 包括但不限於以下幾點:
業務用戶想要執行什麼樣的分析?
你現在收集的數據需要支持那些分析嗎?
數據在哪兒？
數據的清潔度如何？
相似的數據有多個數據源嗎？
什麼樣的結構最適合核心數據倉庫 (例如維度或關系型)？
技術問題包括但不限於以下幾點:
在你的網路中要流通多少數據？它能處理嗎?
需要多少硬碟空間?
硬碟存儲需要多快？
你會使用固態還是虛擬化的存儲？

D. 構建企業級數據倉庫的步驟是什麼

現如今，很多企業都開始重視數據倉庫的構建，其實構建數據倉庫不是一個難事，難的地方在於如何構建企業級的數據倉庫，這對於企業來說是一件十分困難又必須提上日程的事情。不過，不要灰心，雖然困難，但是我們也可以通過一些方法去構建企業數據倉庫，在這篇文章中我們就給大家介紹一下構建數據倉庫的步驟。
構建企業級的數據倉庫第一步就是要確定主題，其實確定主題就是確定數據分析或前端展現的主題。主題要體現出某一方面的各分析角度和統計數值型數據之間的關系,確定主題時要綜合考慮。這一點是非常重要的，大家一定要重視。
第二個步驟就是確定量度。當我們確定主題後，需要考慮分析的技術指標。一般來說，這些都是數據值型數據，其中有些度量值不可以匯總。有些是可以匯總起來，以便為分析者提供有用的信息。量度是要統計的指標，必須事先選擇恰當，基於不同的量度可以進行復雜關鍵性指標的設計和計算。
第三個步驟就是確定事實數據粒度。當我們確定量度之後，需要考慮該量度的匯總情況和不同維度下量度的聚合情況。如果我們按照「天」為單位來匯總數據的在ETL處理過程中，按天來匯總數據,些時數據倉庫中量度的粒度就是「天」。如果不能確認將來的分析需求中是否要精確的秒，那麼，我們要遵循」最小粒度原則」,在數據倉庫中的事實表中保留每一秒的數據，對數據提前進行匯總，保障產生分析結果的效率。
第四個步驟就是確定維度，其實維度是分析的各個角度。基於不同的維度，可以看到各個量度匯總的情況，也可以基於所有的維度進行交叉分析。
第五個步驟就是創建事實表。在確定好事實數據和維度後，將考慮載入事實表。業務系統的的一筆筆生產，交易記錄就是將要建立的事實表的原始數據。具體的做法是將原始表與維度表進行關聯，生成事實表。關聯時有為空的數據時，需要使用外連接，連接後將各維度的代理鍵取出放於事實表中，事實表除了各維度代理鍵外，還有各度量數據，不應該存在描述性信息。
在這篇文章中我們給大家介紹了構建企業級數據倉庫的相關步驟，相信大家看了這篇文章以後已經對數據倉庫有所了解了吧？大家在構建數據倉庫的時候一定要謹遵上面的步驟進行操作，這樣才能夠提高工作效率，少走彎路，更出色地完成工作任務。

E. 帶你深入了解建立數據倉庫的八條基本准則[2]

規則三:定義目標和量化收益

在項目開始實施以前 用戶必須明確回答幾個問題 我們為什麼要建立一個數據倉庫?項目的目的同我們機構的任務一致嗎?哪些問題是我們致力於要去解決的?要考慮及時推入市場 質量和客戶滿意度等因素嗎?

在進行了目標問題的認知以後 應該認清哪些是關鍵性的影響成功的因素 以便於在解決方案的實施進程中進行跟蹤 例如 收益和運輸單位(units shipped)可能是對喪失市場份額產生作用的兩個影響因素

在確立了這些關鍵的成功影響因素以後 用戶就可以在應用中設置 自動水開標記或警報 這些警報保證對底層產生直接影響的最重要數據是清晰可見的 便於及時採取行動 定義了成功的影響因素後 在使用數據倉庫時就可以檢測到威脅成功的因素

一旦這些基本目標確立以後 下一個基本要求是對來自數據倉庫的可預期的收益進行量化 只有在做了這些工作以後 管理層才會有據可依地判斷一個數據倉庫的成功與否

量化的目標不一定非是數字或金融表達式 它們只需要明確 有意義即可

許多機構都採用金融衡量標准 比如ROI 來對收益進行量化 IDC對 家數據倉庫的實現進行研究表明 在數據倉庫項目上的總體ROI為 % 平均回報時間為 ～ 年 數據集市的ROI經檢驗為 % 其他類型的收益衡量標准還包括成本節約程度以及可獲得的能夠進行衡量的效率

規則四:取得最高管理層的支持和認可

數據倉庫中涉及到信息的共享 這必然會由於部門數據所有者的人為因素造成失控 在數據所有權和數據存放等問題上的內部紛爭 很容易給數據倉庫帶來進程上的滯延和失敗

lishixin/Article/program/SQL/201311/16252

F. 教你輕松掌握數據倉庫的規劃和構建策略

教你輕松掌握數據倉庫的規劃和構建策略

數據倉庫作為決策支持系統（DSS）的基礎，具有面向主題的、集成的、不可更新的、隨時間不斷變化的特性。這些特點說明了數據倉庫從數據組織到數據處理，都與原來的資料庫有很大的區別，這也就需要在數據倉庫系統設計時尋求一個適合於數據倉庫設計的方法。在一般的系統開發規劃中，首先需要確定系統的功能，這些系統的功能一般是通過對用戶的需求分析得到的。從數據倉庫的應用角度來看，DSS分析員一般是企業中的中高層管理人員，他們對決策支持的需求不能預先做出規范的說明，只能給設計人員一個抽象地描述。
這就需要設計人員在與用戶不斷的交流溝通中，將系統的需求逐步明確，並加以完善。因此數據倉庫的開發規劃過程實際上是一個用戶和設計人員對其不斷了解、熟悉和完善的過程。 數據倉庫的開發應用規劃是開發數據倉庫的首要任務。只有制定了正確的數據倉庫規劃，才能使組織主要力量有序地實現數據倉庫的開發應用。在數據倉庫規劃中一般需要經歷這樣幾個過程：選擇實現策略、確定數據倉庫的開發目標和實現范圍、選擇數據倉庫體系結構、建立商業和項目規劃預算。 當數據倉庫規劃完成後，需要編制相應的數據倉庫規劃說明書，說明數據倉庫與企業戰略的關系，以及與企業急需處理的、范圍相對有限的開發機會，重點支持的職能部門和今後數據倉庫開發工作的建議，實際使用方案和開發預算，作為數據倉庫實際開發的依據。
1、選擇數據倉庫實現策略
數據倉庫的開發策略主要有自頂向下、自底向上和這兩種策略的聯合使用。自頂向下策略在實際應用中比較困難，因為數據倉庫的功能是一種決策支持功能。這種功能在企業戰略的應用范圍中常常是很難確定的，因為數據倉庫的應用機會往往超出企業當前的實際業務范圍，而且在開發前就確定目標，會在實現預定目標後就不再追求新的應用，是數據倉庫喪失更有戰略意義的應用。由於該策略在開發前就可以給出數據倉庫的實現范圍，能夠清楚地向決策者和企業描述系統的收益情況和實現目標，因此是一種有效的數據倉庫開發策略。該方法使用時需要開發人員具有豐富的自頂向下開發系統的經驗，企業決策層和管理人員完全知道數據倉庫的預定目標並且了解數據倉庫能夠在那些決策中發揮作用。
自底向上策略一般從某個數據倉庫原型開始，選擇一些特定的為企業管理人員所熟知的管理問題作為數據倉庫開發的對象，在此基礎上進行數據倉庫的開發。因此，該策略常常用於一個數據集市、一個經理系統或一個部門的數據倉庫開發。該策略的優點在於企業能夠以較小的投入，獲得較高的數據倉庫應用收益。在開發過程中，人員投入較少，也容易獲得成效。當然，如果某個項目的開發失敗可能造成企業整個數據倉庫系統開發的延遲。該策略一般用於企業洗碗對數據倉庫的技術進行評價，以確定該技術的應用方式、地點和時間，或希望了解實現和運行數據倉庫所需要的各種費用，或在數據倉庫的應用目標並不是很明確時，數據倉庫對決策過程影響不是很明確時使用。
在自頂向下的開發策略中可以採用結構化或面向對象的方法，按照數據倉庫的規劃、需求確定、系統分析、系統設計、系統集成、系統測試和系統試運行的階段完成數據倉庫的開發。而在自底向上的開發中，則可以採用螺旋式的原型開發方法，使用戶可以根據新的需求對試運行的系統進行修改。螺旋式的原型開發方法要求在較短的時間內快速的生成可以不斷增加功能的數據倉庫系統，這種開發方法主要適合於這樣一些場合：在企業的市場動向和需求無法預測，市場的時機是實現產品的重要組成部分，不斷地改進對與企業的市場調節是必需的；持久的競爭優勢來自連續不斷地改進，系統地改進是基於用戶在使用中的不斷發現。 自頂向下和自底向上策略的聯合使用具有兩種策略的優點，既能快速的完成數據倉庫的開發與應用，還可建立具有長遠價值的數據倉庫方案。但在實踐中往往難以操作，通常需要能夠建立、應用和維護企業模型、數據模型和技術結構的、具有豐富經驗的開發人員，能夠熟練的從具體（如業務系統中的元數據）轉移到抽象（只基於業務性質而不是基於實現系統技術的邏輯模型）；企業需要擁有由最終用戶和信息系統人員組成的有經驗的開發小組，能夠清楚地指出數據倉庫在企業戰略決策支持中的應用。
2、確定數據倉庫的開發目標和實現范圍
為確定數據倉庫的開發目標和實現范圍，首先需要對企業管理者等數據倉庫用戶解釋數據倉庫在企業管理中的應用和發展趨勢，說明企業組織和使用數據來支持跨功能系統的重要性，對企業經營戰略的支持，以確定開發目標。在該階段確認與使用數據倉庫有關的業務要求，這些要求應該只支持最主要的業務職能部門，將使用精力集中在收益明顯的業務上，使數據倉庫的應用立即產生效果，不應該消耗太多的精力在各個業務上同時鋪開數據倉庫的應用。
在確定開發目標和范圍以後，應該編制需求文檔，作為今後開發數據倉庫的依據。 數據倉庫開發的首要目標是確定所需要信息的范圍，確定用戶提供決策幫助時，在主題和指標域需要哪些數據源。這就需要定義：用戶需要什麼數據？面向主題的數據倉庫需要什麼樣的支持數據？為成功地向用戶提交數據，開發人員需要哪些商業知識？哪些背景知識？這就需要定義整體需求，以文件的形式整理現存的記錄系統和系統環境，對使用數據倉庫中數據的候選應用系統進行標識、排序，構造一個傳遞模型，確定尺度、事實及時間標記演算法，以便從系統中抽取信息且將他們放入數據倉庫。通過信息范圍確定可為開發人員提供一個良好的分析平台，和用戶一起分析哪些信息是數據倉庫需要的，進行商業活動需要什麼數據。開發人員可以和用戶進一步定義需要，例如數據分級層次、聚合的層次、載入的頻率以及需要保持的時間表等。 數據倉庫開發的另一個重要目標是確定利用哪些方法和工具訪問和導航數據？雖然用戶都需要存取並且檢索數據倉庫的內容，但是所存取的粒度有所不同，有的可能是詳細的記錄，有的可能是比較概括的記錄或十分概括的記錄。用戶要求的數據概括程度不同，將導致數據倉庫的聚集和概括工具的需求不同。
數據倉庫還有具有一定功能來訪問和檢索圖表、預定義的報表、多維數據、概括性數據和詳細記錄。用戶從數據倉庫中獲得信息，應該有電子表格、統計分析器和支持多維分析的分析處理器等工具的支持，以解釋和分析數據倉庫中的內容，產生並且驗證不同的市場假設、建議和決策方案。為將決策建議和各種決策方案向用戶清楚地表達出來，需要利用報表、圖表和圖像等強有力的信息表達工具。 數據倉庫開發的其他目標，是確定數據倉庫內部數據的規模。在數據倉庫中不僅包含當前數據，而且包含多年的歷史數據。數據的概括程度決定了這些數據壓縮和概括的最大限度。如果要讓數據倉庫提供對歷史記錄進行決策查詢的功能，就必須支持對大量數據的管理。數據的規模不僅直接影響決策查詢的時間，而且還將直接影響企業決策的質量。
在數據倉庫的開發目標中，還有：根據用戶對數據倉庫的基本需求，確定數據倉庫中數據的含義；確定數據倉庫內容的質量，以確定使用、分析和建議的可信級別；哪種類型的數據倉庫可以滿足最終用戶的需求，這些數據倉庫應該具有怎樣的功能；需要哪些元數據，如何使用數據源中的數據等。 數據倉庫的開發目標多種多樣，十分復雜，需要開發人員和用戶在開發與使用的過程中不斷交互完善。因此，在規劃中需要確定數據倉庫的開發范圍。使開發人員能夠根據需求和目標的重要性逐步進行，並且在開發中吸取經驗教訓，為數據倉庫在企業中的全部實現提供技術准備。因此，在為數據倉庫確定總體開發方向和目標以後，就必須確定一個有限的能夠很快體現數據倉庫效益的使用范圍。在考慮數據倉庫苦的應用范圍時，主要從使用部門的數量和類型、數據源的數量、企業模型的子集、預算分配以及開發項目所需的時間等角度分析。
在分析這些因素時，可從用戶的角度和技術的角度兩方面進行。 從用戶的角度應該分析哪些部門最先使用數據倉庫？是哪些人員為了什麼目的使用數據倉庫？以及數據倉庫首先要滿足哪些決策查詢？因為這些決策查詢往往確定了關於數據維數、報表的種類，這些因素都將確定數據倉庫定義時所需要的數量關系。查詢的格式越具體，越容易提供數據倉庫的維數、聚集和概括的規劃說明。 從技術角度分析，應該確定數據倉庫中元資料庫的規模，數據倉庫的元資料庫是存儲數據倉庫中數據定義的模型。數據定義存儲在倉庫管理器的目錄中，可以作為所有查詢和報表工具構造和查詢數據倉庫的依據。元資料庫的規模直接表示了數據倉庫中必須管理的數據規模。通過對元資料庫規模的管理，實際上就確定了數據倉庫中所需要管理的數據規模。
3、數據倉庫的結構選擇
數據倉庫的結構可以進行靈活的選擇，可將組織所使用的各種平台進行恰當的分割，把數據源、數據倉庫和最終用戶使用的工作站分割開來進行恰當的設計。
（1）數據倉庫的應用結構
基於業務處理系統的數據倉庫 在這種結構中，將運作的數據用於無需修改數據的只讀應用程序中。具有這種結構的數據倉庫元資料庫是一種虛庫，而不是數據倉庫自身的元數據。在數據倉庫元資料庫的直接指導下，對數據倉庫的查詢就是簡單的從資料庫中抽取數據。
單純數據倉庫
利用在數據倉庫中的數據源凈化、集成、概括和集成等操作，將數據源從業務處理系統中傳輸進集中的數據倉庫，各部門的數據倉庫應用只在數據倉庫中進行。這種結構經常發生在多部門、少用戶使用數據倉庫的情況下。這里的集中僅僅是邏輯上的，物理上可能是分散的。
單純數據集市
數據集市是指在部門中使用的數據倉庫，因為企業中的各個職能部門都有自己的特殊需要，而統一的數據倉庫可能不能滿足這些部門的特殊要求。這種體系結構經常發生在個別部門對數據倉庫的應用感興趣，而組織中其他部門卻對數據倉庫的應用十分冷漠之時，由熱心的部門單獨開發式所採用。
數據倉庫和數據集市
企業各部門擁有滿足自己需要的數據集市，其數據從企業數據倉庫中獲取，而數據倉庫從企業各種數據源中收集和分配。這種體系結構是一種較為完善的數據倉庫體系結構，往往發生在組織整體對數據倉庫應用感興趣之時所採用的體系結構。
（2）數據倉庫的技術平台結構 單層結構
單層結構主要是在數據源和數據倉庫之間共享平台，或者讓數據源、數據倉庫、數據集市與最終用戶工作站使用同一個平台。共享一個平台可以降低數據抽取和數據轉換的復雜性，但是共享平台在應用中可能遇到性能和管理方面的問題，這種體系結構一般在數據倉庫規模較小，而組織的業務系統平台具有較大潛力之時所採用。
客戶/伺服器兩層結構
一層為客戶機，一層為伺服器，最終用戶訪問工具在客戶層上運行，而數據源、數據倉庫和數據集市位於伺服器上，該技術機構一般用於普通規模的數據倉庫。
三層客戶/伺服器結構
基於工作站的客戶層、基於伺服器的中間層和基於主機的第三層。主機層負責管理數據源和可選的源數據轉換；伺服器運行數據倉庫和數據集市軟體，並且存儲倉庫的數據；客戶工作站運行查詢和報表運用程序，且還可以存儲從數據集市或數據倉庫卸載的局部數據。在數據倉庫稍具規模，兩層數據倉庫結構已經不能滿足客戶的需求，要講數據倉庫的數據存儲管理、數據倉庫的應用處理和客戶端應用分開之時，可以採用這種結構。
多層式結構
這是在三層機構基礎上發展起來的數據倉庫結構，在該結構中從最內數據層到最外層的客戶層依次是：單獨的數據倉庫存儲層、對數據倉庫和數據集市進行管理的數據倉庫服務層、進行數據倉庫查詢處理的查詢服務層、完成數據倉庫應用處理的應用服務層和面向最終用戶的客戶層。體系層次可能多達五層，這種體系結構一般用於超規模數據倉庫系統。
4、數據倉庫使用方案和項目規劃預算
數據倉庫的實際使用方案與開發預算，是數據倉庫規劃中最後需要確定的問題。因為數據倉庫主要用於對企業管理人員的決策支持，確保其實用性是十分重要的，因此需要讓最終用戶參與數據倉庫的功能設計。這種參與是通過用戶的實際使用方案進行的，使用方案是一個非常重要的需求模型。實際使用方案必須有助於闡明最終用戶對數據倉庫的要求，這些要求有的只使用適當的數據源就可以得到基本滿足，而有的卻需要來自企業外部的數據源，這就需要通過使用方案將這些不同的要求聯系起來。 實際使用方案還可以將最終用戶的決策支持要求與數據倉庫的技術要求聯系起來。因為當用戶確定最終要求後，為元資料庫的范圍確定一個界限。還可以確定所需要的歷史信息的數量，當根據特定的用戶進行數據倉庫的規劃時，就可確定最終用戶所關心的維度（時間、方位、商業單位和生產企業），因為維度與所需要的概括操作有明顯的關系，必須選擇對最終用戶有實際意義的維度，如：「月」、「季度」、「年」等。最後，還可以確定數據集市/數據倉庫的結構需要，使設計人員確定採用單純數據倉庫結構，還是單純的數據集市結構或者是兩者相結合的結構。
在實際使用開發方案確定後，還需要對開發方案的預算進行估計，確定項目的投資數額。投資方案的確定可以依據以往的軟體開發成本，但是這種預算的評估比較粗糙。另一種方法是參照結構進行成本評估，也就是說，將數據倉庫實際使用方案所確定的構件進行分解，根據各個構件的成本進行預算估算。數據倉庫的構件包含在數據源、數據倉庫、數據集市、最終用戶存取、數據管理、元數據管理、傳輸基礎等部分中，這些構件有的在企業原有信息系統中已經具備，有的可以選擇商品化構件，有的則需要自我開發。根據這些構件的不同來源，可以確定比較准確的預算。 在完成數據倉庫規劃後，就需要編制數據倉庫開發說明書，說明系統與企業戰略目標的關系，以及系統與企業急需處理的范圍相對有限的開發機會，所設想的業務機會的說明以及目標任務概況說明、重點支持的職能部門和今後工作的建議。數據倉庫項目應有明確的業務價值計劃開始，在計劃中需要闡明期望取得的有形和無形的利益。無形利益包含利用數據倉庫使決策完成得更快更好等利益。
業務價值計劃最好由目標業務主管來完成，因為數據倉庫是用戶驅動的，應該讓用戶積極參與數據倉庫的建設，在規劃書中要確定數據倉庫開發目標的實現范圍、體系結構和使用方案及開發預算。

G. 數倉建模分層理論

這篇文章較為完整、清晰的講述了數倉建模分層理論，要點如下：

1、分層的意義：清晰結構體系、數據血緣跟蹤、減少重復開發、復雜問題簡單化及統一數據口徑

2、ODS：用作緩沖，可以存一周左右，跟DWD大多重復，留存的目的還在於保持跟源端一致，方便追溯

3、DWD：針對ODS做數據的清洗和整合，在DWD層會根據維度模型，設計事實表和維度表，DWD層是一個非常規范的、高質量的、可信的數據明細層

4、DWS：基於DWD層形成某一主題的輕度匯總表或分析寬表，DWS形成大量維度退化的事實表以提高易用性，DWS層應覆蓋80%的應用場景

5、TDM：標簽層，通過統一的ID-Mapping 把各個業務板塊，各個業務過程中同一對象的數據打通，形成對象的全域數據標簽體系，方便深度分析、挖掘、應用，大家注意，這個ID不僅僅指客戶或用戶ID，也包括其它的主數據ID，其是全流程分析的基礎

6、ADS：數據應用層ApplicationDataService面向業務定製的應用數據，主要提供給數據產品和數據分析使用的數據，一般會放在ES，MYSQL，Redis等前端系統供線上系統使用，也可以放在Hive中供數據分析和數據挖掘使用

7、DM：主要是提供數據產品和數據分析的數據，主要解決部門用戶報表和分析需求而建立資料庫，數據集市就代表數據倉庫的主題域。DM 是面向單個主題的，所以它不會從全局考慮進行建設。

強烈推薦閱讀！

正文開始

簡單點兒，直接ODS+DM就可以了，將所有數據同步過來，然後直接開發些應用層的報表，這是最簡單的了；當DM層的內容多了以後，想要重用，就會再拆分一個公共層出來，變成3層架構,這個過程有點類似代碼重構，就是在實踐中不斷的進行抽象、總結。

數倉的建模或者分層，其實都是為了更好的去組織、管理、維護數據,所以當你站在更高的維度去看的話，所有的劃分都是為了更好的管理。小到JVM 內存區域的劃分，JVM 中堆空間的劃分(年輕代、老年代、方法區等)，大到國家的省市區的劃分，無一例外的都是為了更好的組織管理 。

所以數倉分層是數據倉庫設計中十分重要的一個環節， 優秀的分層設計能夠讓整個數據體系更容易理解和使用 。

這一節，我們主要是從整體上出發進行分析和介紹，就和上一節數倉建模方法論一樣，進度對比分析，更多細節的東西我們後面會單獨拆分出來，用案例進行演示，例如維度建模，維度表的設計，事實表的設計、以及如何設計標簽、如何管理標簽等等。

每一個數據分層都有它的作用域，這樣在使用表的時候能更方便的定位和理解。

由於最終給業務呈現的是一個能直接使用的業務表，但是表的數據來源有很多，如果有一張來源表出問題了，我們希望能夠 快速准確的定位到問題，並清楚它的影響范圍，從而及時給到業務方反饋，從而將損失降到最低 。

將一個復雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便於維護數據的准確性，當數據出現問題之後，可以不用修復所有的數據，只需要從有問題的步驟開始修復。

過數據分層提供統一的數據出口，統一對外輸出的數據口徑，這往往就是我們說的數據應用層。

前面我們說到分層其實是為了更好更快更準的組織管理，但是這個是從宏觀上來說的，接下來我們從微觀上也來看一下分層。

越靠上的層次，對應用越友好,比如ADS層，基本是完全為應用設計,從數據聚合程度來講，越上層的聚合程度越高，當然聚合程度越高可理解程度就越低。

數倉層內部的劃分不是為了分層而分層， 分層是為了解決 ETL 任務及工作流的組織、數據的流向、讀寫許可權的控制、不同需求的滿足等各類問題 ，當然我們常說的分層也是面向行業而言的，也是我們常用分層方法，但是你需要注意的是分層僅僅是手段而已。

ODS 全稱是 OperationalDataStore， 操作數據層存儲的是面向業務系統的數據 ，也是最接近數據源中數據的一層，數據源中的數據，經過抽取、洗凈、傳輸，也就說傳說中的 ETL 之後，裝入本層。

本層的數據，總體上大多是 按照源頭業務系統的分類方式而分類的 ，前面我們說到為什麼在數倉主要用維度建模的情況下，我們依然要學習範式建模呢，因為我們的數據源是範式建模的，所以學習範式建模可以幫助我們更好的理解業務系統，理解業務數據，所以你可以認為我們的ODS 層其實就是用的實範式建模。

這里的數據處理，並不涉及業務邏輯，僅僅是針對數據完整性以及重復值和空值的處理，其實就是做的是數據規約，數據清洗，但是為了考慮後續可能追溯數據源問題，因此 對這一層不建議做過多的數據清洗工作 ，原封不動接入源數據即可，至於數據的去噪，去重，異常值處理等過程可以放在後面的DW層

表名的設計 ODS_業務系統_表名_標記 ，這樣的設計可以保持與業務表名一致，又可以有清晰的層次，還可以區分來源。標記一般指的是其他數倉特有的屬性，例如表是天級的還是小時的，是全量的還是增量的。

ods 的設計可以保證所有的數據按照統一的規范進行存儲。

DW是數據倉庫的核心，從ODS層中獲得的數據按照主題建立各種數據模型。DW又細分數據明細層DWD 和輕度匯總層DWS

這一層和維度建模會有比較深的聯系，業務數據是按照 業務流程方便操作的角度 來組織數據的，而統一數倉層是 按照業務易理解的角度或者是業務分析的角度 進行數據組織的，定義了一致的指標、維度，各業務板塊、數據域都是按照統一的規范來建設，從而形成統一規范的 標准業務數據體系 ，它們通常都是基於Kimball的維度建模理論來構建的， 並通過一致性維度和數據匯流排來保證各個子主題的維度一致性 。

公共層的維度表中相同維度屬性在不同物理表中的欄位名稱、數據類型、數據內容必須保持一致，因為這樣可以降低我們在使用過程中犯錯誤的概率，例如使用了不正確的欄位，或者因為數據類型的原因導致了一些奇怪的錯誤

將維度所描述業務相關性強的欄位在一個物理維表實現。相關性強是指經常需要一起查詢或進行報表展現、兩個維度屬性間是否存在天然的關系等。例如，商品基本屬性和所屬品牌。

公告明細數據層，可以說是我們數倉建設的核心了。

DWD層要做的就是將 數據清理、整合、規范化、臟數據、垃圾數據、規范不一致的、狀態定義不一致的、命名不規范的數據都會被處理 。然後加工成面向數倉的基礎明細表，這個時候可以加工一些面向分析的大寬表。

DWD層應該是覆蓋所有系統的、完整的、干凈的、具有一致性的數據層。在DWD層會根據維度模型，設計事實表和維度表，也就是說DWD層是一個非常規范的、高質量的、可信的數據明細層。

DWS層為 公共匯總層 ，這一層會進行輕度匯總，粒度比明細數據稍粗， 基於DWD層上的基礎數據，整合匯總成分析某一個主題域的服務數據 ，一般是也是面向分析寬表或者是面向某個注意的匯總表。DWS層應覆蓋80%的應用場景，這樣我們才能快速響應數據需求，否則的話，如果很多需求都要從ods開始做的話，那說明我們的數倉建設是不完善的。

例如按照業務劃分，例如流量，訂單，用戶等，生成欄位比較多的寬表，用於後續的業務查詢，OLAP分析，數據分析等。

一般採用維度模型方法作為理論基礎，更多的採用一些維度退化手法，將維度退化至事實表中，減少維度表與事實表的關聯，提高明細數據表的易用性；同時在匯總數據層要加強指標的維度退化，採用更多的寬表化手段構建公共指標數據層，提升公共指標的復用性，減少重復加工 。

維表層，所以其實維度層就是大量維表構成的，為了統一管理這些維度表，所以我們就建設維度層，維度表本身也有很多類型，例如穩定維度維表，漸變維度維表。

維度指的是觀察事物的角度，提供某一業務過程事件涉及用什麼過濾和分類的描述屬性 ，"誰、什麼時候、什麼地點、為什麼、如何"幹了什麼，維度表示維度建模的基礎和靈魂。

所以可以看出，維度表包含了業務過程記錄的業務過程度量的上下文和環境。維度表都包含單一的主鍵列， 維度表設計的核心是確定維度欄位，維度欄位是查詢約束條件(where)、分組條件(group)、排序(order)，與報表標簽的基本來源 。

維度表一般為 單一主鍵 ，在ER模型中，實體為客觀存在的事務，會帶有自己的描述性屬性，屬性一般為文本性、描述性的，這些描述被稱為維度。維度建模的核心是 數據可以抽象為事實和維度 ，維度即觀察事物的角度，事實某一粒度下的度量詞， 維度一定是針對實體而言的 。

每個維度表都 包含單一的主鍵列 。維度表的主鍵可以作為與之關聯的任何事實表的外鍵，當然，維度錶行的描述環境應與事實錶行完全對應。維度表通常比較寬，是扁平型非規范表，包含大量的低粒度的文本屬性。例如customer（客戶表）、goods(商品表)、d_time(時間表)這些都屬於維度表，這些表都有一個唯一的主鍵，然後在表中存放了詳細的數據信息。

維度表通常比較寬 ，包含多個屬性、是扁平的規范表 ，實際應用中包含幾十個或者上百個屬性的維度並不少見，所以 維度表應該包括一些有意義的描述，方便下游使用 。

維度表的維度屬性，應該盡可能的豐富，所以維度表中，經常出現一些反範式的設計，把其他維度屬性並到主維度屬性中， 達到易用少關聯的效果。

維度表的設計包括維度選擇，主維表的確定，梳理關聯維度，定義維度屬性的過程。

維度的選擇一般從報表需求和從業務人員的交談中發現，主要用於過濾、分組、排序，主維度表一般從業務庫直接同步，比如用戶表，但是數倉的本身也會有自己的維度，這是因為數倉是面向分析的，所以會有很多從分析的角度出發的維度。

關聯維度主要是不同業務系統或者同一業務系統的表之間存在關聯性(範式建模)，根據對業務表的梳理，確定哪些表和主維度表之間存在關聯關系，並選擇其中的某些表用於生成維度屬性。

隨著互聯網的普及，獲客成本越來越高，這也使得公司對用戶運營提出了更高的要求，不僅需要精細化更需要個性化。解決這一問題的辦法之一就是建立相對完備的標簽系統，而數倉的標簽層對於標簽系統而言就像數據倉庫對於數據系統一樣，有著舉足輕重的地位，這樣的標簽系統需要與業務進行緊密結合， 從業務中獲取養分—用戶標簽，同時也要服務於業務—給用戶提供更加精準和個性的服務 。

底層的標簽系統就像一個索引，層層展示大千世界，而用戶就從這大千世界中不斷選擇一些東西表明自己的身份和喜好，也不斷反哺，使得這個大千世界更加豐富多彩。 其實到最後用戶就是一些標簽的集合。

對跨業務板塊、跨數據域的特定對象進行數據整合，通過統一的ID-Mapping 把各個業務板塊，各個業務過程中 同一對象的數據打通 ，形成對象的全域數據標簽體系，方便深度分析、挖掘、應用。ID-Mapping 可以認為是通過對象的標識對不同數據體系下相同對象進行關聯和識別。對象的標識可以標識一個對象，一般是對象的ID,比如手機號，身份證，登錄賬號

完成對象的ID 打通需要給對象設置一個超級ID,需要根據對象當前業務體系的ID和獲取得到或者計算得到超級ID,進而完成所有業務標識的ID打通一般來說ID打通是建設標簽體系的前提，如果沒有ID打通就無法收集到一個對象的全面信息，也就無法對這個對象進行全面的標簽刻畫。

傳統的計算方法要有 ID-ID之間的兩兩關系，例如郵箱和手機號可以打通，手機號和身份證號可以打通，那麼郵箱就和身份證號可以打通，但是當數據量非常大，且業務板塊非常多的時候，例如有上一個對象，每個對象有數十種ID,這個時候打通就需要非常漫長的計算

那麼什麼是標簽呢，利用原始數據，通過一定的邏輯加工產出直接能被業務所直接使用的、可閱讀的，有價值的數據。標簽類目，是標簽的分類組織方式，是標簽信息的一種結構化描述，目的是管理、查找，一般採用多級類目，一般當一個對象的標簽個數超過50個的時候，業務人員查找標簽就會變得非常麻煩，這個時候我們往往會通過標簽類目進行組織管理

標簽按照產生和計算方式的不同可分為屬性標簽，統計標簽，演算法標簽，關聯標簽。

對象本身的性質就是屬性標簽，例如用戶畫像的時候打到用戶身上的標簽。

對象在業務過程中產生的原子指標，通過不同的計算方法可以生成統計標簽。

對象在多個業務過程中的特徵規律通過一定的演算法產出的標簽。

對象在特定的業務過程會和其他對象關聯，關聯對象的標簽也可以打在主對象上。

我們的標簽一定是針對用戶的，而不是一些虛假、高大上、無用的標簽，一定要真實反映用戶行為喜好的，所以我們不能只依賴人工智慧演算法的分析，來完成對一個用戶標簽的建立與定期維護，我們需要走出去和用戶交互，引導用戶使用，要抓住用戶痛點，及時獲取用戶反饋，形成閉環。

如何引導使用呢？這個方式有很多我們就不再這里介紹了，後面我們會專門介紹這一層的建設細節。

數據應用層ApplicationDataService面向業務定製的應用數據，主要提供給數據產品和數據分析使用的數據，一般會放在ES，MYSQL，Redis等系統供線上系統使用，也可以放在Hive中供數據分析和數據挖掘使用，或者使用一下其他的大數據工具進行存儲和使用。

數倉層，DIM 層，TDM 層是相對穩定的，所以無法滿足靈活多變業務需求 ，所以這和數倉層的規范和劃分相矛盾，所以我們在此基礎上建立了另外一個層，這就是ADS 層，解決了規劃穩定和靈活多變之間的矛盾。其實到這里你也就慢慢的看明白了，分層和分類其實沒多大差別，其實就是相似的放在一起，有點代碼重構的意味啊。

數據應用層，按照業務的需要，然後從統一數倉層和DIM進行取數，並面向業務的特殊需求對數據進行加工,以滿足業務和性能的需求。ADS 層因為面向的實眾多的需求，所以這一層沒有太多的規范，只需要按照命名規范來進行就可以了。

前面也說了，ADS 層因為面向的實眾多的需求，所以這一層沒有太多的規范，但是ADS 層的建設是強業務推動的，業務部門需要參與到ADS 的建設中來，至少我們得了解用戶的痛點才能對症施葯啊。

理清需求，了解業務方對數據內容、使用方式(怎麼交互的，報表、介面、即席查詢、在線查詢、指標查詢、搜索)、性能的要求。

盤點現有的數倉表是否可以支持，看以前有沒有類似的需求，有沒有可以復用的介面、報表什麼的。

代碼實現，選擇合適的存儲引擎和查詢引擎，配置線上監控然後交付。

主要是提供數據產品和數據分析的數據，一般會存放在ES、Mysql、也可能直接存儲在hive中或者druid供數據分析和數據挖掘使用。主要 解決部門用戶報表和分析需求 而建立資料庫，數據集市就代表數據倉庫的主題域。

DM 是面向單個主題的，所以它不會從全局考慮進行建設，只專注於自己的數據、往往是某個業務線，例如流量主題、社交主題、電商主題等等。

H. 萬字詳解ETL和數倉建模

ETL是數據抽取（Extract）、轉換（Transform）、載入（Load ）的簡寫，它是將OLTP系統中的數據經過抽取，並將不同數據源的數據進行轉換、整合，得出一致性的數據，然後載入到數據倉庫中。簡而言之ETL是完成從 OLTP系統到OLAP系統的過程

數據倉庫（Data Warehouse DW）是基於OLTP系統的數據源，為了便於多維分析和 多角度展現將其數據按特定的模式進行存儲而建立的關系型資料庫，它不同於多維資料庫，數據倉庫中的數據是細節的，集成的，數據倉庫是面向主題的，是以 OLAP系統為分析目的。它包括星型架構與雪花型架構，其中星型架構中間為事實表，四周為維度表， 類似星星；雪花型架構中間為事實表，兩邊的維度表可以再有其關聯子表，而在星型中只允許一張表作為維度表與事實表關聯，雪花型一維度可以有多張表，而星型 不可以。考慮到效率時，星型聚合快，效率高，不過雪花型結構明確，便於與OLTP系統交互。在實際項目中，我們將綜合運用星型架構與雪花型架構。

即 確定數據分析或前端展現的某一方面的分析主題，例如我們分析某年某月某一地區的啤酒銷售情況，就是一個主題。主題要體現某一方面的各分析角度（維度）和統 計數值型數據（量度），確定主題時要綜合考慮，一個主題在數據倉庫中即為一個數據集市，數據集市體現了某一方面的信息，多個數據集市構成了數據倉庫。

在 確定了主題以後，我們將考慮要分析的技術指標，諸如年銷售額此類，一般為數值型數據，或者將該數據匯總，或者將該數據取次數，獨立次數或取最大最小值 等，這樣的數據稱之為量度。量度是要統計的指標，必須事先選擇恰當，基於不同的量度可以進行復雜關鍵性能指標（KPI）等的計算。

在 確定了量度之後我們要考慮到該量度的匯總情況和不同維度下量度的聚合情況，考慮到量度的聚合程度不同，我們將採用「最小粒度原則」，即將量度的粒度設置 到最小，例如我們將按照時間對銷售額進行匯總，目前的數據最小記錄到天，即資料庫中記錄了每天的交易額，那麼我們不能在ETL時將數據進行按月或年匯總， 需要保持到天，以便於後續對天進行分析。而且我們不必擔心數據量和數據沒有提前匯總帶來的問題，因為在後續的建立CUBE時已經將數據提前匯總了。

維 度是要分析的各個角度，例如我們希望按照時間，或者按照地區，或者按照產品進行分析，那麼這里的時間、地區、產品就是相應的維度，基於不同的維度我們可 以看到各量度的匯總情況，我們可以基於所有的維度進行交叉分析。這里我們首先要確定維度的層次（Hierarchy）和級別（Level）（圖 四：pic4.jpg），維度的層次是指該維度的所有級別，包括各級別的屬性；維度的級別是指該維度下的成員，例如當建立地區維度時我們將地區維度作為一 個級別，層次為省、市、縣三層，考慮到維度表要包含盡量多的信息，所以建立維度時要符合「矮胖原則」，即維度表要盡量寬，盡量包含所有的描述性信息，而不 是統計性的數據信息。

還有一種常見的情況，就是父子型維度，該維度一般用於非葉子節點含有成員等情況，例如公司員工 的維度，在統計員工的工資時，部 門主管的工資不能等於下屬成員工資的簡單相加，必須對該主管的工資單獨統計，然後該主管部門的工資等於下屬員工工資加部門主管的工資，那麼在建立員工維度 時，我們需要將員工維度建立成父子型維度，這樣在統計時，主管的工資會自動加上，避免了都是葉子節點才有數據的情況。

另外，在建立維度表時要充 分使用代理鍵，代理鍵是數值型的ID號碼，好處是代理鍵唯一標識了每一維度成員信息，便於區分，更重要的是在聚合時由於數值型匹 配，JOIN效率高，便於聚合，而且代理鍵對緩慢變化維度有更重要的意義，它起到了標識 歷史 數據與新數據的作用，在原數據主鍵相同的情況下，代理鍵起到了 對新數據與 歷史 數據非常重要的標識作用。

有時我們也會遇到維度緩慢變化的情況，比如增加了新的產品，或者產品的ID號碼修改了，或者產品增加了一個新的屬性，此時某一維度的成員會隨著新的數據的加入而增加新的維度成員，這樣我們要考慮到緩慢變化維度的處理，對於緩慢變化維度，有三種情況：

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

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

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

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

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

在構建數據倉庫時，如果數據源位於一伺服器上，數據倉庫在另一 伺服器端，考慮到數據源Server端訪問頻繁，並且數據量大，需要不斷更新，所以可以建立准備區資料庫（圖七：pic7.jpg）。先將數據抽取到准備 區中，然後基於准備區中的數據進行處理，這樣處理的好處是防止了在原OLTP系統中中頻繁訪問，進行數據運算或排序等操作。例如我們可以按照天將數據抽取 到准備區中，基於數據准備區，我們將進行數據的轉換，整合，將不同數據源的數據進行一致性處理。數據准備區中將存在原始抽取表，一些轉換中間表和臨時表以 及ETL日誌表等。

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

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

在對數據倉庫進行 增量更新時必須使用調度（圖八：pic8.jpg），即對事實數據表進行增量更新處理，在使用調度前要考慮到事實數據量，需要多長時間更 新一次，比如希望按天進行查看，那麼我們最好按天進行抽取，如果數據量不大，可以按照月或半年對數據進行更新，如果有緩慢變化維度情況，調度時需要考慮到 維度表更新情況，在更新事實數據表之前要先更新維度表。

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

ETL構建數據倉庫需要簡單的五步，掌握了這五步的方法我們將構建一個強大的數據倉庫，不過每一步都有很深的需要研究與挖掘，尤其在實際項目中，我們要綜合考慮，例如如果數據源的臟數據很多，在搭建數據倉庫之前我們首先要進行數據清洗，以剔除掉不需要的信息和臟數據。

總之，ETL是數據倉庫的核心，掌握了ETL構建數據倉庫的五步法，就掌握了搭建數據倉庫的根本方法。不過，我們不能教條，基於不同的項目，我們還將要進行 具體分析，如父子型維度和緩慢變化維度的運用等。在數據倉庫構建中，ETL關繫到整個項目的數據質量，所以馬虎不得，必須將其擺到重要位置，將ETL這一 大廈根基築牢。

如果ETL和SQL來說，肯定是SQL效率高的多。但是雙方各有優勢，先說ETL，ETL主要面向的是建立數據倉庫來使用的。ETL更偏向數據清洗，多數據源數據整合，獲取增量，轉換載入到數據倉庫所使用的工具。比如我有兩個數據源，一個是資料庫的表，另外一個是excel數據，而我需要合並這兩個數據，通常這種東西在SQL語句中比較難實現。但是ETL卻有很多現成的組件和驅動，幾個組件就搞定了。還有比如跨伺服器，並且伺服器之間不能建立連接的數據源，比如我們公司系統分為一期和二期，存放的資料庫是不同的，數據結構也不相同，資料庫之間也不能建立連接，這種情況下，ETL就顯得尤為重要和突出。通過固定的抽取，轉換，載入到數據倉庫中，即可很容易實現。

那麼SQL呢？SQL事實上只是固定的腳本語言，但是執行效率高，速度快。不過靈活性不高，很難跨伺服器整合數據。所以SQL更適合在固定資料庫中執行大范圍的查詢和數據更改，由於腳本語言可以隨便編寫，所以在固定資料庫中能夠實現的功能就相當強大，不像ETL中功能只能受組件限制，組件有什麼功能，才能實現什麼功能。

所以具體我們在什麼時候使用ETL和SQL就很明顯了，當我們需要多數據源整合建立數據倉庫，並進行數據分析的時候，我們使用ETL。如果是固定單一資料庫的數據層次處理，我們就使用SQL。當然，ETL也是離不開SQL的。

主要有三大主流工具，分別是Ascential公司的Datastage、Informatica公司的Powercenter、NCR Teradata公司的ETL Automation.還有其他開源工具，如PDI(Kettle)等。

DW系統以事實發生數據為基礎，自產數據較少。

一個企業往往包含多個業務系統，均可能成為DW數據源。

業務系統數據質量良莠不齊，必須學會去偽存真。

業務系統數據紛繁復雜，要整合進數據模型。

源數據之間關系也紛繁復雜，源數據在加工進DW系統時，有些必須遵照一定的先後次序關系;

流水事件表：此類源表用於記錄交易等動作的發生，在源系統中會新增、大部分不會修改和刪除，少量表存在刪除情況。如定期存款登記簿;

常規狀態表：此類源表用於記錄數據信息的狀態。在源系統中會新增、修改，也存在刪除的情況。如客戶信息表;

代碼參數表：此類源表用於記錄源系統中使用到的數據代碼和參數;

數據文件大多數以1天為固定的周期從源系統載入到數據倉庫。數據文件包含增量，全量以及待刪除的增量。

增量數據文件：數據文件的內容為數據表的增量信息，包含表內新增及修改的記錄。

全量數據文件：數據文件的內容為數據表的全量信息，包含表內的所有數據。

帶刪除的增量：數據文件的內容為數據表的增量信息，包含表內新增、修改及刪除的記錄，通常刪除的記錄以欄位DEL_IND='D'標識該記錄。

可劃分為： 歷史 拉鏈演算法、追加演算法(事件表)、Upsert演算法(主表)及全刪全加演算法(參數表);

歷史 拉鏈：根據業務分析要求，對數據變化都要記錄，需要基於日期的連續 歷史 軌跡;

追加(事件表)：根據業務分析要求，對數據變化都要記錄，不需要基於日期的連續 歷史 軌跡;

Upsert(主表)：根據業務分析要求，對數據變化不需要都要記錄，當前數據對 歷史 數據有影響;

全刪全加演算法(參數表)：根據業務分析要求，對數據變化不需要都要記錄，當前數據對 歷史 數據無影響;

所謂拉鏈，就是記錄 歷史 ，記錄一個事務從開始，一直到當前狀態的所有變化信息(參數新增開始結束日期);

一般用於事件表，事件之間相對獨立，不存在對 歷史 信息進行更新;

是update和insert組合體，一般用於對 歷史 信息變化不需要進行跟蹤保留、只需其最新狀態且數據量有一定規模的表，如客戶資料表;

一般用於數據量不大的參數表，把 歷史 數據全部刪除，然後重新全量載入;

歷史 拉鏈，Upsert,Append,全刪全加;載入性能：全刪全加，Append，Upsert， 歷史 拉鏈;

APPEND演算法，常規拉鏈演算法，全量帶刪除拉鏈演算法;

APPEND演算法，MERGE演算法，常規拉鏈演算法，基於增量數據的刪除拉鏈演算法，基於全量數據的刪除拉鏈演算法，經濟型常規拉鏈演算法，經濟型基於增量數據的刪除拉鏈演算法，經濟型基於全量數據的刪除拉鏈演算法，PK_NOT_IN_APPEND演算法，源日期欄位自拉鏈演算法;

此演算法通常用於流水事件表，適合這類演算法的源表在源系統中不會更新和刪除，而只會發生一筆添加一筆，所以只需每天將交易日期為當日最新數據取過來直接附加到目標表即可，此類表在近源模型層的欄位與技術緩沖層、源系統表基本上完全一致，不會額外增加物理化處理欄位，使用時也與源系統表的查詢方式相同;

此演算法通常用於無刪除操作的常規狀態表，適合這類演算法的源表在源系統中會新增、修改，但不刪除，所以需每天獲取當日末最新數據(增量或全增量均可)，先找出真正的增量數據(新增和修改)，用它們將目標表中屬性發生修改的開鏈數據(有效數據)進行關鏈操作(即END_DT關閉到當前業務日期)，然後再將最新的增量數據作為開鏈數據插入到目標表即可。

此類表再近源模型層比技術緩沖層、源系統的相應表額外增加兩個物理化處理欄位START_DT(開始日期)和END_DT(結束日期)，使用時需要先選定視覺日期，通過START_DT和END_DT去卡視覺日期，即START_DT'視覺日期';

此演算法通常用於有刪除操作的常規狀態類表，並且要求全量的數據文件，用以對比出刪除增量;適合這類演算法的源表在源系統中會新增，修改，刪除，每天將當日末最新全量數據取過來外，分別找出真正的增量數據(新增，修改)和刪除增量數據，用它們將目標表中屬性發生修改的開鏈數據(有效數據)進行關鏈操作(即END_DT關閉到當前業務日期)，然後再將最新增量數據中真正的增量及刪除數據作為開鏈數據插入到目標表即可，注意刪除記錄的刪除標志DEL_IND會設置為『D』;

此類表在近源模型層比技術緩沖層，源系統的相應表額外增加三個物理化處理欄位START_DT(開始日期)，ENT_DT(結束日期)，DEL_IND(刪除標准)。使用方式分兩類：一時一般查詢使用，此時需要先選定視角日期，通過START_DT和END_DT去卡視角日期，即START_DT『視角日期』，同時加上條件DEL_IND 'D';另一種是下載或獲取當日增量數據，此時就是需要START_DT'視角日期' 一個條件即可，不需要加DEL_IND 'D'的條件。

此演算法通常用於流水事件表，適合這類演算法的源表在源系統中不會更新和刪除，而只會發生一筆添加一筆，所以只需每天將交易日期為當日的最新數據取過來直接附加到目標表即可;

通常建一張名為VT_NEW_編號的臨時表，用於將各組當日最新數據轉換加到VT_NEW_編號後，再一次附加到最終目標表;

此演算法通常用於無刪除操作的常規狀態表，一般是無需保留 歷史 而只保留當前最新狀態的表，適合這類演算法的源表在源系統中會新增，修改，但不刪除，所以需獲取當日末最新數據(增量或全量均可)，用於MERGE IN或UPSERT目標表;為了效率及識別真正增量的要求，通常先識別出真正的增量數據(新增及修改數據)，然後再用這些真正的增量數據向目標表進行MERGE INTO操作;

通常建兩張臨時表，一個名為VT_NEW_編號，用於將各組當日最新數據轉換加到VT_NEW_編號;另一張名為VT_INC_編號，將VT_NEW_編號與目標表中昨日的數據進行對比後找出真正的增量數據(新增和修改)放入VT_INC_編號，然後再用VT_INC_編號對最終目標表進行MERGE INTO或UPSERT。

此演算法通常用於無刪除操作的常規狀態表，適合這類演算法的源表在源系統中會新增、修改，但不刪除，所以需每天獲取當日末最新數據(增量或全增量均可)，先找出真正的增量數據(新增和修改)，用它們將目標表中屬性發生修改的開鏈數據(有效數據)進行關鏈操作(即END_DT關閉到當前業務日期)，然後再將最新增量數據作為開鏈數據插入到目標表即可;

通常建兩張臨時表，一個名為VT_NEW_編號，用於將各組當日最新數據轉換加到VT_NEW_編號;另一張名為VT_INC_編號，將VT_NEW_編號與目標表中昨日的數據進行對比後找出真正的增量數據(新增和修改)放入VT_INC_編號，然後再將最終目標表的開鏈數據中的PK出現在VT_INT_編號中進行關鏈處理，然後將VT_INC_編號中的所有數據作為開鏈數據插入最終目標表即可。

此演算法通常用於有刪除操作的常規狀態表，並且要求刪除數據是以DEL_IND='D'刪除增量的形式提供;適合這類演算法的源表再源系統中會新增、修改、刪除，除每天獲取當日末最新數據(增量或全量均可)外，還要獲取當日刪除的數據，根據找出的真正增量數據(新增和修改)以及刪除增量數據，用它們將目標表中屬性發生修改的開鏈數據(有效數據)進行關鏈操作(即END_DT關閉到當前業務時間)，然後再將增量(不含刪除數據)作為開鏈數據插入到目標表中即可;

通常建三張臨時表，一個名為VT_NEW_編號，用於將各組當日最新數據 (不含刪除數據)轉換載入到VT_NEW_編號;第二張表名為VT_INC_編號，用VT_NEW_編號與目標表中的昨日的數據進行對比後找出真正的增量數據放入VT_INC_編號;第三張表名為VT_DEL_編號，將刪除增量數據轉換載入到VT_DEL_編號;最後再將最終目標表的開鏈數據中PK出現在VT_INC_編號或VT_DEL_編號中的進行關鏈處理，最後將VT_INC_編號中的所有數據作為開鏈數據插入最終目標表即可;

此演算法通常用於有刪除操作的常規狀態表，並且要求提供全量數據，用以對比出刪除增量;適合這類演算法的源表在源系統中會新增、修改、每天將當日末的最新全量數據取過來外，分別找出真正的增量數據(新增、修改)和刪除增量數據，用它們將目標表中屬性發生修改的開鏈數據(有效記錄)進行關鏈操作(即END_DT關閉到當前業務時間)，然後再將最新數據中真正的增量數據(不含刪除數據)作為開鏈數據插入到目標表即可;

通常建兩張臨時表，一個名為VT_NEW_編號，用於將各組當日最新全量數據轉換到VT_NEW_編號;另一張表名為VT_INC_編號,將VT_NEW_編號與目標表中昨日的數據進行對比後找出真正的增量數據(新增、修改)和刪除增量數據放入VT_INC_編號，注意將其中的刪除增量數據的END_DT置以最小日期(借用);最後再將最終目標表的開鏈數據中PK出現再VT_INC_編號或VT_DEL_編號中的進行關鏈處理，然後將VT_INC_編號中所有的END_DT不等於最小日期數據(非刪除數據)作為開鏈數據插入最終目標表即可;

此演算法基本等同與常規拉演算法，只是在最後一步只將屬性非空即非0的記錄才作為開鏈數據插入目標表;

此演算法基本等同於基於增量數據刪除拉鏈演算法，只是在最後一步只將屬性非空及非0的記錄才作為開鏈數據插入目標表;

此演算法基本等同於基於全量數據刪除拉鏈演算法，只是在最後一步只將屬性非空及非0的記錄才作為開鏈數據插入目標表;

此演算法是對每一組只將PK在當前VT_NEW_編號表中未出現的數據再插入VT_NEW_編號表，最後再將PK未出現在目標表中的數據插入目標表，以保證只進那些PK未進過的數據;

此演算法是源表中有日期欄位標識當前記錄的生效日期，本演算法通過對同主鍵記錄按這個生效日期排序後，一次首尾相連行形成一條自然拉鏈的演算法

I. 數據倉庫之數據粒度

確定數據倉庫中數據的恰當粒度是數據倉庫開發者需要面對的一個最重要的設計問題。數據粒度主要針對指標數據的計算范圍，如人口這個數據項在統計部門是以街區范圍還是一個社區為范圍統計的。人口數據細化程度越高，粒度級就越小；相反，細化程度越低，粒度級就越大。粒度是數據倉庫主要設計問題，因為它極大地影響存放在數據倉庫中的數據量的大小，同時影響數據倉庫所能回答的查詢類型。在設計數據倉庫的時候權衡數據量大小和查詢類型得出合理的粒度大小。下面我們通過規劃設計和建設兩個階段來講解數據倉庫粒度的確定。

1.規劃階段

「規劃」——對未來整體性、長期性、基本型問題的思考和考量，設計未來整套行動的方案。在規劃階段過程中首先粗略估算數據量，估算的目的是掌握數據倉庫中數據量的一個范圍。第二步預測未來數據集市中應用需要的粒度，數據倉庫存儲數據集市使用的最小粒度。

1.1. 建立良好的循環反饋機制是很重要的。

首先就要建立完善的循環反饋機制。數據倉庫是面對模糊需求開始建立的，粒度不可能一次就能規劃好，先導入少量數據，建立一部分應用提交給用戶使用，並聆聽用戶使用意見，根據用戶的使用意見調整粒度的大小。

1.2. 對存儲數據進行粗略估算對設計體系結構的人員來說非常有用。

粗略估算數據倉庫的數據量，可跟好的規劃數據倉庫架構。如果數據只有10 000行，那麼數據倉庫採用粒度級越小的數據存儲，數據倉庫中存儲所有明細數據。如果明細數據有10 000 000行，進入數據倉庫的數據就需要進行初步匯總。如果有100億行，數據倉庫不但需要有一個高粒度級，還可能將大部分數據移到溢出存儲器上去。

估算方法如下：

1.3. 預測數據集市中可能使用的數據粒度是很必要的。

為了合適地填充所有的數據集市，數據倉庫中的數據必須在一個所有數據集市所需要的最低粒度水平上。

規劃階段的成果是數據倉庫建設的重要依據內容。規劃階段對組織架構，數據量大小和後期應用的摸底，可以制定方案，並對可能的結果有預先的認知，對可能存在的問題設計上進行避免。

2. 建設階段

2.1.根據估算的空間結果，在體系架構設計上可以根據數據量大小進行存儲設備選擇。需要多少直接存取存儲設備，是否需採用雙重粒度設計。

2.2.設計溢出數據的管理。溢出數據是指數據倉庫將不經常被訪問的過時的數據轉移到存儲量更大的訪問速度慢的存儲器上的數據。管理溢出數據可以方便索引定位歷史數據並可以快速取出該數據。

跨介質存儲管理器和數據活動監控器可以對溢出數據進行有效的管理。磁碟存儲器和大容量低速存儲器之間的數據移動是通過一種稱為「跨介質存儲管理器（CMSM）」的軟體來控制的。數據活動監控器，用來確定哪些數據正在被訪問，哪些沒被訪問。數據活動監控器能提供數據存儲的位置信息。

2.3.實施數據倉庫過程中粒度的確定是一個往復循環的過程。利用規劃階段建立的反饋循環方法，不斷的從分析員獲得反饋，不斷的優化數據倉庫。

從圖可以看出成功建立數據倉庫離不開分析人員的通力協作。建設者要不斷的聆聽分析員的意見。分析人員在建立數據倉庫的時候並不知道自己需要什麼，只有在他們看到最終分析結果，才能告訴數據倉庫工作人員什麼才是他們真正有用的。為了有效的獲得反饋，以下幾點技巧可供參考：

快速建立數據倉庫很小的子集並認真聽取用戶的反饋意見；

          使用原型方法；

          參考別人的經驗；

          與有經驗的用戶協同工作；

          以企業中已有的功能需要作參考；

          定期舉行數據倉庫建設例會。

3.例舉銀行粒度小例子

3.1.銀行環境中粒度級別，下圖是銀行中的數據粒度例子。

銀行的操作層存放的是以日為單位粒度的數據。銀行的各個業務系統只存放最近60天交易活動明細內容，方便用戶查詢最近兩個月的交易信息詳情，這段時間用戶對交易數據明細最為關心。

數據倉庫層將數據匯聚成以月為單位粒度的匯總數據。銀行將過去長達十年的數據按每個賬戶每月交易信息進行匯聚，存儲在直接存儲設備，供高速查詢訪問，用戶對過去很久的交易明細並不在意，但是用戶需要快速查詢得出結果，此時提供以月為單位的匯總數據可以滿足用戶的需求。

所有的歷史數據以日為單位存放在溢出存儲區，該區域數據量極大，訪問頻率極低。一般銀行不受理長達十年的歷史明細數據查詢的請求，如果一些特殊情況需要查詢超過十年的歷史數據，查詢時間會相當緩慢。

4.小結

數據倉庫粒度的確定是一個困難的過程，要求一個合適的級別，既不能太高也不能太低。

選擇粒度級別很大程度上基於常識。建設之前作好適當的規劃，估算數據量並建立相應的反饋制度。在實施的過程中，首先建立數據倉庫的一小部分，並讓分析人員使用。然後聆聽他們的意見，根據他們的反饋對粒度級別進行適當的調整。