基於Greenplum,postgreSQL的大型數據倉庫實踐

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

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

嘉賓演講視頻回放及PPT： t.cn/RgcE3V6

摘要

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

傳統數據倉庫過期了嗎

傳統數據倉庫體系結構

傳統數據倉庫由源系統、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、DB二、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，這是爲了不項目中出現太多的異構數據庫，也便於開發人員開發。