我在公司的資料部門工作，每天的訂單類資料處理流程大致如下：

1. 刪除分析資料庫的歷史訂單資料
2. 全量更新訂單資料到分析資料庫。（由於訂單核心資料不大，所以經受得起這麼折騰）
3. 將資料簡單清洗，並生成資料集市層
4. 分析處理，產出報表。當然還有其他的資料也是這麼處理的（比如產品的資料、景區的資料、票種的資料、供應商的資料等等）

還有日誌類的資料，這裡不是重點，就不介紹了！這麼幹了一年，發現有如下問題：

• 業務變化很快，比如業務資料表經常變化欄位含義、增加各種邏輯資料等
• 業務資料來源越來越多，隨著品類越來越多，新部門逐步成立，資料來源也就越來越多樣化
• 需求越來越多，越來越複雜，以前只有大佬想我們要戰略資料，可是現在所有的產品和運營都向我們要各種各樣的使用者行為資料、訂單分析資料和競對優勢資料
• 資料的實時行要求越來越高，這到不是說秒級別就看見結果，而是早晨提出個新業務資料需求，晚上就要！

資料畢竟是為了市場服務的，所以需求我們要跟上它的節奏，這就對資料系統提出了很大的挑戰，導致資料質量下降、生產效率下降！該怎麼解決哪？在解決這個問題的過程中，逐步發現了一點苗頭：發現我們建立的資料倉儲與它的定義不太符合。下面是資料倉儲的定義：

資料倉儲（Data Warehouse）：是一個面向主題的（Subject Oriented）、整合的（Integrated）、相對穩定的（Non-Volatile）、反映歷史變化（Time Variant）的資料集合，用於支援管理決策(Decision Making Support)。

很明顯我們並不符合相對穩定的和反應歷史變化的兩個條件，因為類似訂單類資料，每天全量更新（原因是同一個訂單狀態隨著時間會變化，比如今天買了，明天退貨了）。這就明顯不符合想對穩定這一概念了，更別說反應歷史變化了！經過最近的思考，發現自己搭建的系統更符合ODS的定義：

ODS：是一個面向主題的、整合的、可變的、當前的細節資料集合，用於支援企業對於即時性的、操作性的、整合的全體資訊的需求。

那麼大家可能會問ods和資料倉儲的區別是什麼哪？答：ods是短期的實時的資料，供產品或者運營人員日常使用，而資料倉儲是供戰略決策使用的資料；ods是可以更新的資料，資料倉儲是基本不更新的反應歷史變化的資料，還有很多，這裡就不一一列舉了。

講到這裡問題就明晰了，如何能搭建一個體系，既能支援戰略決策使用的資料倉儲資料，又能相容業務快速的變化和運營產品人員日常需求的ODS資料哪？

資料倉儲和ODS並存方案

經過調研，發現大體上有三種解法：

1、業務資料 － ODS － 資料倉儲

優點：這樣做的好處是ODS的資料與資料倉儲的資料高度統一；開發成本低，至少開發一次並應用到ODS即可；可見ODS是發揮承上啟下的作用，調研阿里巴巴的資料部門也是這麼實現的。

缺點：資料倉儲需要的所有資料都需要走ODS，那麼ODS的靈活性必然受到影響，甚至不利於擴充套件、系統的靈活性差

2、OB － ODS

優點：結構簡單。一般的初創資料分析團隊都是類似的結構，比如我們部門就應該歸結到這一範疇

缺點：這樣所有資料都歸結到ODS，長期資料決策分析能力差，軟硬體成本高，模組劃分不清晰，通用性差

3、資料倉儲和ODS並行

可見這個模型兼顧了上面提高的各自優點，且便於擴充套件，ODS和資料倉儲各做各的，形成優勢互補！可以解決現在網際網路公司遇到的快速變化、快速開發等特點！特別是對於那些剛剛建立資料團隊，資料開發人員緊缺的公司，可以嘗試使用這個資料架構解決問題！

參考資料：

http://blog.csdn.net/hero_hegang/article/details/8691912

http://www.cnblogs.com/liqiu/p/4947801.html