摘要：本文主要描述了資料倉庫的演進過程，介紹主動資料倉庫、實時資料倉庫、以及ODS等概念。

1、主動資料倉庫

1.1、問題的提出

客戶撥打呼叫中心，對某個產品或服務表現出關心，你的客戶代表能否主動的和客戶溝通，提高客戶保持率？
如果你的網站能夠及時的給客戶返回資訊，並且客戶每訪問3次後就給10％的折扣，將能增加多少的客戶忠誠度？
如果供應商能夠預測到假期每個商品會增加多少的銷售量，並及時補充商品，將會增加多少的銷售額？
今天，成功的商業關係，無論是客戶、合作伙伴或者供應商，都越來越依靠集成了企業所有資料的資料倉庫，分析出有價值的資訊，並把資訊分發給每天做決策的人員。主動資料倉庫轉變傳統資料倉庫解決方法的策略，使企業在維繫客戶上變得更加主動和有效。
 

1.2、變革經濟環境下的全新解決方案

新經濟環境下，有著新的客戶期望值、新的客戶關係和新的商業機會，企業需要具有主動的決策支援能力。今天，資料倉庫的資料正在發生演變，資料倉庫負擔著客戶關係管理、一對一營銷和及時制定決策等效用，進而成為具有控制和影響市場能力的工具。
資料倉庫的初始階段，是面向查詢批處理的決策支援應用。資料倉庫的初始目的是收集、清理和整合組織內的資料，這些資料用來產生報表和查詢，以支援決策的制定。
隨著資料倉庫技術的成熟和應用普及，越來越多的企業利用資料倉庫技術的特性，以支援預測分析以驅動商業決策。資料倉庫技術在更大範圍內得到應用，從分析市場將要發生什麼變化，到分析市場正在發生什麼變化，到基於事件觸發、控制市場朝著自己想要的方向去發展。
 
 

1.3、主動資料倉庫的優勢

主動資料倉庫在市場快速變化和實時企業管理決策要求下出現的，是資料倉庫技術的新的分支。利用主動資料倉庫建立應用，企業可以改進與客戶的及時溝通能力，使分支機構或者呼叫中心更好的與客戶進行聯絡。下面的這些應用在傳統資料倉庫中是難以實現的，但主動資料倉庫提供了可能：

1. 利用呼叫中心，進行自動的、直接的客戶營銷；
2. 在信用卡業務處理過程中，及時進行欺詐檢測；
3. 飛機滿座率低時，可以在飛機起飛前，讓更多的乘客坐上飛機；
4. 基於當前的客戶貢獻度和價值度，給客戶靈活的綜合定價和折扣；
5. 及時決定執行中卡車的最優線路，降低貨物運送時延，並實現對不同客戶的不同服務承諾；
6. 基於客戶近期的信用卡交易情況、結合他們長期的購買行為，優化即將要送給客戶的交叉銷售購物券；

傳統資料倉庫解決方案	主動資料倉庫解決方案
只能支援戰略決策	支援戰略決策和戰術決策
返回很難測量的指標	返回日常運營指標
以天、周或月為週期獲取資料，並做預先聚合計算	只包含明細資料，可能以分鐘為週期獲取新資料
中等規模使用者數	多使用者數併發訪問（如1000使用者以上）
只能得到高度限制的報表，使用預處理的聚合表或資料集市	靈活的即席查詢，資料探勘
適用於高階使用者，分析員，內部使用者	適用於操作僱員，呼叫中心，外部使用者

表1：傳統資料倉庫與主動資料倉庫的能力比較
 
顯然，主動資料倉庫擴充套件了傳統資料倉庫的能力：

1. 外部人員可以訪問資料倉庫，如合作伙伴、供應商和客戶。
2. 企業的所有成員都可以直接的訪問資料倉庫，包括普通的僱員、呼叫中心的客戶代表等等。
3. 整合、多主題，交叉渠道的執行可以幫助企業更快更有效的行動，拓展商業機會。

 
主動資料倉庫支援戰略和戰術的市場決策。意味著企業的戰略分析結果可以轉化為具體、詳細的條件約束和操作事務下的行動。這樣，發揮了日常戰術決策的效用，提高了資料倉庫資訊的效率。最終，對於企業來說，一致性的資料使職員和合作夥伴更好做出符合事實的、精確的和有見地的決策。
建立主動資料倉庫幫助你更接近你的客戶、優化供應鏈、提高製造質量和精準地跟蹤商品流動，計劃和管理成功的商業活動，達成銷售自動化，使得企業具備新競爭環境下的及時商業分析能力。
主動資料倉庫需要一個可擴充套件的、高效能的資料倉庫解決方案，需要實時資料倉庫的支援。
 

2、實時資料倉庫和ODS

很多資料倉庫設計者認為不可能把現有的24小時執行週期的ETL改為15分鐘的週期。因為即使將資料清理的步驟並行處理，最大的事實表和維表的增量載入也不一定能在這麼短的時間內完成。
 

2.1、ODS的引入

規劃資料倉庫時，可以在常規的、靜態的資料倉庫之外，建立一個實時的分割槽，這個特別的分割槽在物理上和管理上獨立於傳統的資料倉庫。事實上，實時分割槽通常並不是資料庫概念上的表分割槽，而是由一些獨立的可以在其上進行更新和查詢操作的表構成。。
儲存實時分割槽的系統就是ODS（Operational Data Store）。ODS和實時分割槽是兩大資料倉庫流派的不同名詞定義而已，我們姑且將ODS理解為儲存和管理實時分割槽的系統。ODS處於業務系統和資料倉庫之間，具有實時的、常變的、當前的、臨時的等特點。引入ODS，DW的體系結構變為：源資料→ODS→DW→OLAP。增加ODS，還需要前端工具的支援，才能夠進行無縫查詢。
實時分割槽必須滿足如下的一些苛刻要求：

1. 在靜態資料倉庫更新前，承擔所有的查詢操作；
2. 在粒度和內容上與靜態資料倉庫的事實表能夠吻合連結；
3. 支援大量併發的查詢響應。

 

2.2、實事分割槽（ODS）的應用

在維度模型中，主要有三類粒度的事實表：交易粒度（Transaction Grain），週期性快照粒度（Periodic Snapshot Grain），增量快照粒度（Accumulating Snapshot Grain）。實時分割槽在3種類型的粒度上有不同的結構。

2.2.1交易

靜態資料倉庫的事實表就是交易粒度的，它包括源系統中的交易記錄。如果在某時間週期內源系統沒有新的交易，則沒有新的記錄。相反的，如果交易很多很頻繁，就會產生大量的記錄。實時分割槽具有與靜態事實表維度關聯的資料模型結構。
實時分割槽一般完全沒有索引，因為必須不斷的維護新載入的資料，並且實時分割槽只儲存當天的資料，也不必在此上建立預聚合計算。
有了實時分割槽，應用必須能夠從靜態資料倉庫表鑽取到實時分割槽。做時間上的聚合計算時（如當月的銷售量），必須向兩個表發出相同的查詢。
在一個大型零售商場，每天有1000萬筆交易，靜態資料倉庫表中將會有很多記錄。假設每個交易記錄為40位元組，每天增加的資料量大約為400MB，一年增加150GB。這樣的事實表必然有龐大的索引，並支援聚合計算。但實時分割槽不要有索引（但可以有主鍵），以支援快速插入。實時分割槽也不要有預先聚合，實時分割槽需要支援快速的資料插入，同時實現高效能的查詢。
 

2.2.2週期快照

如果靜態資料倉庫事實表在時間維度上儲存高粒度的資料（如月份），那麼實時分割槽能夠檢視當前月的明細資料。假如一家有1500萬個帳號的銀行，靜態事實表的粒度是每個帳號每月的記錄。事實表上儲存36個月的資料，這將達到5億4000萬條記錄。實時分割槽儲存當月的資料，每月進行一次更新。假如包括4個維度和4個指標，實時分割槽大約需要480MB的儲存，可以考慮把它常住記憶體。
這裡，應用從靜態事實表查詢鑽取到實時分割槽鑽取時，與交易粒度結構下的情況有些不同。雖然很多指標能夠在表之間直接鑽取，但整個當月的資料必須聚合到月份層次，以保持查詢結果的規整。
最後，在每月的最後一天，實時分割槽資料載入到靜態資料倉庫，然後把實時分割槽清空。
 

2.2.3增量快照

此類維度模型用於短週期的處理，如定單的生命週期。定單和運輸管理中，每個專案產生一條記錄。在事實表中，這些記錄需要根據活動的變化進行更新。比如，客戶下定單時，增加一條記錄；貨物開始裝載運輸時，更新該記錄；貨物到達目的地時，再次更新記錄；然後付款、訂單完成都要更新記錄。
 這個案例中，事實表將被迫不斷的更新資料。為了效能上的考慮，這些更新將在夜間完成。這裡，實時分割槽只包括今天更新的記錄。晚上，實時分割槽的資料正好可以寫到主事實表中，可能是插入新記錄到主事實表，或者，根據唯一索引覆蓋已存在的記錄。
 在很多定單和運輸的解決方案中，實時分割槽的資料量遠沒有上面的前2個案例那麼大。比如，全美專營貓狗食品的製造商每月大約有60,000個發貨單。每張發貨單平均有20條記錄。每個發貨單平均代表2個月的供貨期，這個時間段內要更新資料5次，那麼每個工作日將有7,500行資料需要更新。即使事實表上每個記錄有80個位元組，實時分割槽也只要600KB的資料量，完全可以把它常駐記憶體，且不需要在此表上加索引和進行預先的聚合。
 查詢每個定單的情況，需要讀取事實表和實時分割槽，可以在兩個表上做外聯結操作，或在兩個表上做並集，這樣就可以查詢到新加入的記錄，並體現在報表上。
  在電信等行業，客戶投訴處理過程的情形也很類似，一個投訴要經過提交、複核、派單、處理和反饋等過程，進行多次更新操作