內容來源：2017 年 10 月 21 日，深奇智慧聯合創始人高揚在“PostgreSQL 2017中國技術大會”進行《基於Greenplum,postgreSQL的大型資料倉儲實踐》演講分享。IT 大咖說（微信id：itdakashuo）作為獨家視訊合作方，經主辦方和講者審閱授權釋出。
閱讀字數：4263 | 11分鐘閱讀
摘要
大資料時代，傳統資料倉儲技術是否已經過時？我們將進行探討，超越傳統資料倉儲，又基於傳統資料倉儲，如何設計超大型資料倉儲平臺。本專題將詳細介紹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、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，這是為了避免專案中出現太多的異構資料庫，也便於開發人員開發。