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

刪除分析數據庫的歷史訂單數據

全量更新訂單數據到分析數據庫。（由于訂單核心數據不大，所以經受得起這么折騰）

將數據簡單清洗，并生成數據集市層

分析處理，產出報表。當然還有其他的數據也是這么處理的（比如產品的數據、景區的數據、票種的數據、供應商的數據等等）

還有日志類的數據，這里不是重點，就不介紹了！這么干了一年，發現有如下問題：

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

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

數據倉庫（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://wenku.baidu.com/view/c620146c7e21af45b307a86e?fr=prin

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

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

轉載于:https://www.cnblogs.com/andy6/p/7738112.html

總結

以上是生活随笔為你收集整理的数据仓库与ODS的区别的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。