大數據時代，傳統數據倉庫技術是否已經過時？

內容來源：2017 年 10 月 21 日，深奇智慧聯合創始人高揚在「PostgreSQL 2017中國技術大會」進行《基於Greenplum,postgreSQL的大型數據倉庫實踐》演講分享。IT 大咖說（微信id：itdakashuo）作為獨家視頻合作方，經主辦方和講者審閱授權發布。

閱讀字數：4263 | 11分鐘閱讀

摘要

大數據時代，傳統數據倉庫技術是否已經過時？我們將進行探討，超越傳統數據倉庫，又基於傳統數據倉庫，如何設計超大型數據倉庫平台。本專題將詳細介紹Greenplum,postgreSQL在大型數據倉庫中的地位和實踐。

嘉賓演講視頻回放及PPT，請複製鏈接：http://t.cn/RgcE3V6，粘貼至瀏覽器地址欄即可。

傳統數據倉庫過時了嗎

傳統數據倉庫體系結構

傳統數據倉庫由源系統、ODS、EDW、Data Mart這幾部分組成，源系統就是業務系統、生產系統，ODS是操作數據存儲，EDW是企業級數據倉庫，Data Mart是數據集市。

源系統

生產系統、財務系統、人力資源系統還有12306的訂票系統等其實都是源系統，源系統的主要作用是產生數據。傳統行業大多是將這些數據存儲在oracle、db2上，互聯網行業選擇開源資料庫的居多。

ODS

ODS是Openrational Data Store的簡稱，叫操作數據存儲，在項目中也被叫做中間庫或臨時庫。數據從業務系統進入真正的數據倉庫前會有一個中間層，這中間層就是ODS。

作為一個中間層ODS有著以下幾個特點。

整合異構的數據，比如各種業務數據以及mysql或者oracle的數據都是通過中間庫進入數據倉庫

轉移一部分業務系統細節查詢的功能，如果直接對使用傳統關係型資料庫的業務系統進行查詢，對於Oracle和db2這樣的資料庫來說存在一定的局限性。

數據編碼標準化轉化。

DW是靜態數據而ODS中的數據是動態的、可更新的。

數據內容不同，ODS存儲當前或者近期的數據，DW存儲歷史性數據。

ODS數據容量級別較小，DW的數據容量很大。

上文提到的是傳統意義上對ODS的定義，而現在我們所理解的ODS已不再局限於此。現在ODS存儲的不單單是文本，還包括圖片和視頻。也就是說它變成了一個中間層，而涉及的技術也不僅僅是關係型資料庫，還有NoSQL或Redis這樣的類型資料庫。在前端採集數據量非常大的時候，關係型資料庫可能會頂不住壓力，但如果是Redis的話就可以將數據緩存在內存中，然後批量刷到關係庫中。

EDW介紹

EDW也就是企業級數據倉庫，以下是它的一些特點。

面向主題：操作型資料庫的數據組織面向事物處理任務，各個業務系統 之間各自分離，而數據倉庫中的數據是按照一定的主題域進行組織的。 例如：當事人、協議、機構、財務、事件、產品等主題。

集成的：數據倉庫中的數據是在對原有分散的資料庫數據抽取、清理的 基礎上經過系統加工、匯總和整理得到的，必須消除源數據中的不一致 性，以保證數據倉庫內的信息是關於整個企業的一致的全局信息。

相對穩定的：數據倉庫的數據主要供企業決策分析之用，所涉及的數據操作主要是數據查詢，一旦某個數據進入數據倉庫以後，一般情況 下將被長期保留，也就是數據倉庫中一般有大量的查詢操作，但修改 和刪除操作很少，通常只需要定期的載入、刷新。

反映歷史變化：數據倉庫中的數據通常包含歷史信息，系統記錄了企 業從過去某一時點(如開始應用數據倉庫的時點)到目前的各個階段的信 息，通過這些信息，可以對企業的發展歷程和未來趨勢做出定量分析 和預測。

無論是傳統的的數據倉庫還是大數據時代的數據倉庫，EDW提供的功能並無太多差異。主要還是隨機查詢、固定報表以及數據挖掘，一般大數據層面更多的是偏向數據挖掘。

DM介紹

數據集市的英文名稱是Data Marts。它是一種小型的部門級的數據倉庫，主要面向部門級業務，並且只面向某個特定的主題，是為滿足特定用戶（一般是部門級別的）的需求而建立的一種分析型環境。投資規模比較小，更關注在數據中構建複雜的業務規則來支持 功能強大的分析。

大數據的概念和數據集市的概念正好相反，數據集市是從一個超集中得出一個子集，而大數據是集合眾多業務數據，然後從其中發掘數據的關聯以及價值。所以我們認為數據集市的概念在大數據時代已經是過時了，這也是近些年來已經很少有人討論數據集市的原因。

上圖是我們認為的正確的體系結構，最後的DW被替換成DV（可視化資料庫/結果庫）。在EDW中計算的結果最終被存到DW中，然後由DW做展示或者可視化。

PG/GP是否已經過時

前面提到過傳統型資料庫有著很多局限，接下來我們會重新梳理和設計，讓傳統數據倉庫也能去適應大數據時代的變化。

源系統設計

上圖展示的是SCADA（數據採集與監視控制系統），這樣的一套系統中如果存在著上萬個感測器，那麼在一瞬間所產生的數據量會非常龐大。過去SCADA的做法是將採集的數據存放在內存中，但是由於數據量太大且無法發現數據價值，所以會進行定期清除。

近些年隨著大數據的發展，這些數據的價值慢慢被體現出來，因此有了將數據存儲到後端的需求。在資料庫的選擇上很多是傾向於PG，主要原因在於SCADA是和資料庫捆綁在一起銷售，而如果捆綁的是MySQL則會存在一定風險，PG則沒有這方面的顧慮。

上面所提的這些，其實就是想說明在源系統上PG可能是更好的選擇。

中間庫（ODS）設計

中間庫通常被設計成資料庫集群而不是單機。下圖的介面資料庫其實就是一個中間庫，是由多台機器組成的集群，每台機器上會有多個MySQL或PG實例。這樣就可以將數據分布到不同的機器上，形成一個介面庫成為集群。這裡的集群並非傳統意義上的集群，中間庫應該是鬆散的MySQL集群、PG集群，數據量大的時候也可以選擇Redis集群。

EDW設計

既然談到數據倉庫設計，那麼就要先回到傳統層面——基於Oracle的數據倉庫。

傳統的數據倉庫有這樣幾個特點，一是使用分區技術加速數據訪問，Oracle中一個大表可以分為幾個區，每個區又可以放到不同物理硬碟中，這樣的設計對於性能提升其實很大，但是在大數據時代就有些捉襟見肘。二是應用集群技術，前端是多台伺服器提供運算能力，後端是共享存儲也就是IO。從架構上可以看出這其實是一個磁碟並列，一旦IO出現瓶頸，整個應用集群也會隨之出現問題，所以這樣的架構同樣不適於數據倉庫。三是Oracle的Exadata，它在交易平台使用的比較多，在數據倉庫上則很少見。另外從可視化角度來看Oracle的BIEE也很難跟上時代。

綜上所述，可以說傳統的數據倉庫技術雖然並非完全過時，但也在慢慢退出舞台。

當我們有海量數據的時候，就要面臨數據倉庫的選型問題，比如Oracle、DB2、PG生態圈或者Hadoop生態圈。基於上文所述Oracle和DB2肯定要被排除在外，在PG和Hadoop之間如果選擇的是PG生態圈，就會有兩個選擇：PostgreSQL和Greenplum。對於在線交易系統選擇的肯定是PostgreSQL，而對於真正的數據倉庫就應該選擇Greenplum。

Greenplum體系結構

Greenplum由多個控制節點（master）和多個數據節點（segment Host）構成的集群。

之所以選擇Greenplum，第一是因為它的高性能。

而高性能首先體現在大表分布上，Greenplum中會將一個大表的數據均勻的分布到多個節點，為並行執行（並行計算）打下基礎。其次是並行執行，Greenplum的並行執行可以是外部表數據載入並行、查詢並行、索引的建立和使用並行、統計信息收集並行、表關聯並行等等。第三點是列式存儲和數據壓縮，如果常用的查詢只取表中少量欄位，則列模式效率更高，如查詢需要取表中的大量欄位，行模式效率更高。

選擇Greenplum的第二個原因是產品成熟度高。前面提到過Greenplum由多個節點組成，其實它的每個節點就是一個PostgreSQL。PostgreSQLy於1986年開始研發，1987年開發出第一個版本，1988年對外展出，可以說PG經過這麼多年的發展已經是非常成熟的產品。

第三個原因是容災機制，Greenplum可以有兩個master節點，其中一個宕機的時候，另外一個會繼續接收訪問，並且這兩個節點的Catalog 和事務日誌會保持實時同步。

第四個原因是線性擴展，Greenplum採用了通用的MPP並行處理架構，在 MPP架構中增加節點就可以線性提高系統的存儲容量和處理能力。Greenplum在擴展節點時操作簡單，在很短時間內就能完成數據的重新分布。Greenplum線性擴展支持為數據分析系統將來的拓展給予了技術上的保障，用戶可根據實施需要進行容量和性能的擴展。

最後一個原因是似曾相識的開發環境，由於Greenplum是基於PostgreSQL，在語法上和PG區別並不大，所以能夠讓傳統的Java開發人員平穩的過渡到Greenplum。

引入Hadoop

基於傳統的SQL查詢Greenplum可以輕鬆應對，但是在機器學習上就明顯不足，雖然Greenplum的MADlib支持機器學習，實際案例卻並不多見。因此要在EDW中引入Hadoop生態圈來滿足機器學習的需求。

上圖就是引入的hadoop生態圈，資源管理層使用Mesos和Yarm，分散式存儲層是HDPS，處理引擎層可以在MapReduce和Spark core間選擇。所以如果要做機器學習，其實有兩個選項，一是MapReduce加Mahout，二是Spark core加MLlib。而MapReduce在性能上有所不如，因此我們一般傾向於第二個方案。

最終數據經由Greenplum進入hadoop生態圈，然後根據開發能力以及應用選擇要存儲的地方。Greenplum在這裡成為了機器學習的數據源，另外數據在進入hadoop以後，還是可以做基於SQL的查詢。

還有一點需要注意的是數據倉庫或者大數據平台的計算結果一般都會被存儲到PG中，這是由於PG對大表的處理能力要強於MySQL。

總結

最後我們反過來梳理下整個體系結構，底層的DV使用PG，EDW採用Greenplum加Hadoop，ODS這層最好也使用PG，這是為了避免項目中出現太多的異構資料庫，也便於開發人員開發。

以上為今天的全部分享內容，謝謝大家！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！