傳統(tǒng)數(shù)據(jù)倉庫過時了嗎

[[237958]]

傳統(tǒng)數(shù)據(jù)倉庫體系結(jié)構(gòu)

傳統(tǒng)數(shù)據(jù)倉庫由源系統(tǒng)、ODS、EDW、Data Mart這幾部分組成，源系統(tǒng)就是業(yè)務(wù)系統(tǒng)、生產(chǎn)系統(tǒng)，ODS是操作數(shù)據(jù)存儲，EDW是企業(yè)級數(shù)據(jù)倉庫，Data Mart是數(shù)據(jù)集市。

源系統(tǒng)

生產(chǎn)系統(tǒng)、財務(wù)系統(tǒng)、人力資源系統(tǒng)還有12306的訂票系統(tǒng)等其實都是源系統(tǒng)，源系統(tǒng)的主要作用是產(chǎn)生數(shù)據(jù)。傳統(tǒng)行業(yè)大多是將這些數(shù)據(jù)存儲在oracle、db2上，互聯(lián)網(wǎng)行業(yè)選擇開源數(shù)據(jù)庫的居多。

ODS

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

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

• 整合異構(gòu)的數(shù)據(jù)，比如各種業(yè)務(wù)數(shù)據(jù)以及mysql或者oracle的數(shù)據(jù)都是通過中間庫進入數(shù)據(jù)倉庫
• 轉(zhuǎn)移一部分業(yè)務(wù)系統(tǒng)細節(jié)查詢的功能，如果直接對使用傳統(tǒng)關(guān)系型數(shù)據(jù)庫的業(yè)務(wù)系統(tǒng)進行查詢，對于Oracle和db2這樣的數(shù)據(jù)庫來說存在一定的局限性。
• 數(shù)據(jù)編碼標準化轉(zhuǎn)化。
• DW是靜態(tài)數(shù)據(jù)而ODS中的數(shù)據(jù)是動態(tài)的、可更新的。
• 數(shù)據(jù)內(nèi)容不同，ODS存儲當前或者近期的數(shù)據(jù)，DW存儲歷史性數(shù)據(jù)。
• ODS數(shù)據(jù)容量級別較小，DW的數(shù)據(jù)容量很大。

上文提到的是傳統(tǒng)意義上對ODS的定義，而現(xiàn)在我們所理解的ODS已不再局限于此?，F(xiàn)在ODS存儲的不單單是文本，還包括圖片和視頻。也就是說它變成了一個中間層，而涉及的技術(shù)也不僅僅是關(guān)系型數(shù)據(jù)庫，還有NoSQL或Redis這樣的類型數(shù)據(jù)庫。在前端采集數(shù)據(jù)量非常大的時候，關(guān)系型數(shù)據(jù)庫可能會頂不住壓力，但如果是Redis的話就可以將數(shù)據(jù)緩存在內(nèi)存中，然后批量刷到關(guān)系庫中。

EDW介紹

EDW也就是企業(yè)級數(shù)據(jù)倉庫，以下是它的一些特點。

• 面向主題：操作型數(shù)據(jù)庫的數(shù)據(jù)組織面向事物處理任務(wù)，各個業(yè)務(wù)系統(tǒng) 之間各自分離，而數(shù)據(jù)倉庫中的數(shù)據(jù)是按照一定的主題域進行組織的。 例如：當事人、協(xié)議、機構(gòu)、財務(wù)、事件、產(chǎn)品等主題。
• 集成的：數(shù)據(jù)倉庫中的數(shù)據(jù)是在對原有分散的數(shù)據(jù)庫數(shù)據(jù)抽取、清理的 基礎(chǔ)上經(jīng)過系統(tǒng)加工、匯總和整理得到的，必須消除源數(shù)據(jù)中的不一致 性，以保證數(shù)據(jù)倉庫內(nèi)的信息是關(guān)于整個企業(yè)的一致的全局信息。
• 相對穩(wěn)定的：數(shù)據(jù)倉庫的數(shù)據(jù)主要供企業(yè)決策分析之用，所涉及的數(shù)據(jù)操作主要是數(shù)據(jù)查詢，一旦某個數(shù)據(jù)進入數(shù)據(jù)倉庫以后，一般情況 下將被長期保留，也就是數(shù)據(jù)倉庫中一般有大量的查詢操作，但修改 和刪除操作很少，通常只需要定期的加載、刷新。
• 反映歷史變化：數(shù)據(jù)倉庫中的數(shù)據(jù)通常包含歷史信息，系統(tǒng)記錄了企 業(yè)從過去某一時點(如開始應(yīng)用數(shù)據(jù)倉庫的時點)到目前的各個階段的信 息，通過這些信息，可以對企業(yè)的發(fā)展歷程和未來趨勢做出定量分析 和預測。

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

DM介紹

數(shù)據(jù)集市的英文名稱是Data Marts。它是一種小型的部門級的數(shù)據(jù)倉庫，主要面向部門級業(yè)務(wù)，并且只面向某個特定的主題，是為滿足特定用戶（一般是部門級別的）的需求而建立的一種分析型環(huán)境。投資規(guī)模比較小，更關(guān)注在數(shù)據(jù)中構(gòu)建復雜的業(yè)務(wù)規(guī)則來支持 功能強大的分析。

大數(shù)據(jù)的概念和數(shù)據(jù)集市的概念正好相反，數(shù)據(jù)集市是從一個超集中得出一個子集，而大數(shù)據(jù)是集合眾多業(yè)務(wù)數(shù)據(jù)，然后從其中發(fā)掘數(shù)據(jù)的關(guān)聯(lián)以及價值。所以我們認為數(shù)據(jù)集市的概念在大數(shù)據(jù)時代已經(jīng)是過時了，這也是近些年來已經(jīng)很少有人討論數(shù)據(jù)集市的原因。

上圖是我們認為的正確的體系結(jié)構(gòu)，***的DW被替換成DV（可視化數(shù)據(jù)庫/結(jié)果庫）。在EDW中計算的結(jié)果最終被存到DW中，然后由DW做展示或者可視化。

PG/GP是否已經(jīng)過時

前面提到過傳統(tǒng)型數(shù)據(jù)庫有著很多局限，接下來我們會重新梳理和設(shè)計，讓傳統(tǒng)數(shù)據(jù)倉庫也能去適應(yīng)大數(shù)據(jù)時代的變化。

源系統(tǒng)設(shè)計

上圖展示的是SCADA（數(shù)據(jù)采集與監(jiān)視控制系統(tǒng)），這樣的一套系統(tǒng)中如果存在著上萬個傳感器，那么在一瞬間所產(chǎn)生的數(shù)據(jù)量會非常龐大。過去SCADA的做法是將采集的數(shù)據(jù)存放在內(nèi)存中，但是由于數(shù)據(jù)量太大且無法發(fā)現(xiàn)數(shù)據(jù)價值，所以會進行定期清除。

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

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

中間庫（ODS）設(shè)計

中間庫通常被設(shè)計成數(shù)據(jù)庫集群而不是單機。下圖的接口數(shù)據(jù)庫其實就是一個中間庫，是由多臺機器組成的集群，每臺機器上會有多個MySQL或PG實例。這樣就可以將數(shù)據(jù)分布到不同的機器上，形成一個接口庫成為集群。這里的集群并非傳統(tǒng)意義上的集群，中間庫應(yīng)該是松散的MySQL集群、PG集群，數(shù)據(jù)量大的時候也可以選擇Redis集群。

EDW設(shè)計

既然談到數(shù)據(jù)倉庫設(shè)計，那么就要先回到傳統(tǒng)層面——基于Oracle的數(shù)據(jù)倉庫。

傳統(tǒng)的數(shù)據(jù)倉庫有這樣幾個特點，一是使用分區(qū)技術(shù)加速數(shù)據(jù)訪問，Oracle中一個大表可以分為幾個區(qū)，每個區(qū)又可以放到不同物理硬盤中，這樣的設(shè)計對于性能提升其實很大，但是在大數(shù)據(jù)時代就有些捉襟見肘。二是應(yīng)用集群技術(shù)，前端是多臺服務(wù)器提供運算能力，后端是共享存儲也就是IO。從架構(gòu)上可以看出這其實是一個磁盤并列，一旦IO出現(xiàn)瓶頸，整個應(yīng)用集群也會隨之出現(xiàn)問題，所以這樣的架構(gòu)同樣不適于數(shù)據(jù)倉庫。三是Oracle的Exadata，它在交易平臺使用的比較多，在數(shù)據(jù)倉庫上則很少見。另外從可視化角度來看Oracle的BIEE也很難跟上時代。

綜上所述，可以說傳統(tǒng)的數(shù)據(jù)倉庫技術(shù)雖然并非完全過時，但也在慢慢退出舞臺。

當我們有海量數(shù)據(jù)的時候，就要面臨數(shù)據(jù)倉庫的選型問題，比如Oracle、DB2、PG生態(tài)圈或者Hadoop生態(tài)圈?；谏衔乃鯫racle和DB2肯定要被排除在外，在PG和Hadoop之間如果選擇的是PG生態(tài)圈，就會有兩個選擇：PostgreSQL和Greenplum。對于在線交易系統(tǒng)選擇的肯定是PostgreSQL，而對于真正的數(shù)據(jù)倉庫就應(yīng)該選擇Greenplum。

Greenplum體系結(jié)構(gòu)

Greenplum由多個控制節(jié)點（master）和多個數(shù)據(jù)節(jié)點（segment Host）構(gòu)成的集群。

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

而高性能首先體現(xiàn)在大表分布上，Greenplum中會將一個大表的數(shù)據(jù)均勻的分布到多個節(jié)點，為并行執(zhí)行（并行計算）打下基礎(chǔ)。其次是并行執(zhí)行，Greenplum的并行執(zhí)行可以是外部表數(shù)據(jù)加載并行、查詢并行、索引的建立和使用并行、統(tǒng)計信息收集并行、表關(guān)聯(lián)并行等等。第三點是列式存儲和數(shù)據(jù)壓縮，如果常用的查詢只取表中少量字段，則列模式效率更高，如查詢需要取表中的大量字段，行模式效率更高。

選擇Greenplum的第二個原因是產(chǎn)品成熟度高。前面提到過Greenplum由多個節(jié)點組成，其實它的每個節(jié)點就是一個PostgreSQL。PostgreSQLy于1986年開始研發(fā)，1987年開發(fā)出***個版本，1988年對外展出，可以說PG經(jīng)過這么多年的發(fā)展已經(jīng)是非常成熟的產(chǎn)品。

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

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

***一個原因是似曾相識的開發(fā)環(huán)境，由于Greenplum是基于PostgreSQL，在語法上和PG區(qū)別并不大，所以能夠讓傳統(tǒng)的Java開發(fā)人員平穩(wěn)的過渡到Greenplum。

引入Hadoop

基于傳統(tǒng)的SQL查詢Greenplum可以輕松應(yīng)對，但是在機器學習上就明顯不足，雖然Greenplum的MADlib支持機器學習，實際案例卻并不多見。因此要在EDW中引入Hadoop生態(tài)圈來滿足機器學習的需求。

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

最終數(shù)據(jù)經(jīng)由Greenplum進入hadoop生態(tài)圈，然后根據(jù)開發(fā)能力以及應(yīng)用選擇要存儲的地方。Greenplum在這里成為了機器學習的數(shù)據(jù)源，另外數(shù)據(jù)在進入hadoop以后，還是可以做基于SQL的查詢。

還有一點需要注意的是數(shù)據(jù)倉庫或者大數(shù)據(jù)平臺的計算結(jié)果一般都會被存儲到PG中，這是由于PG對大表的處理能力要強于MySQL。

總結(jié)

***我們反過來梳理下整個體系結(jié)構(gòu)，底層的DV使用PG，EDW采用Greenplum加Hadoop，ODS這層***也使用PG，這是為了避免項目中出現(xiàn)太多的異構(gòu)數(shù)據(jù)庫，也便于開發(fā)人員開發(fā)。