傳統數據倉庫過時了嗎

[[237958]]

傳統數據倉庫體系結構

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