一、傳統(tǒng)數(shù)據(jù)倉庫技術介紹

傳統(tǒng)的數(shù)據(jù)倉庫架構一般有由源系統(tǒng)、ODS、EDW、Data Mart幾部分組成。源系統(tǒng)就是業(yè)務系統(tǒng)、管理系統(tǒng)、辦公系統(tǒng)等等；ODS是操作數(shù)據(jù)存儲；EDW是企業(yè)級數(shù)據(jù)倉庫，Data Mart是數(shù)據(jù)集市。

1、源系統(tǒng)

業(yè)務系統(tǒng)、財務系統(tǒng)、OA系統(tǒng)、ERP系統(tǒng)等其實都是源系統(tǒng)，源系統(tǒng)的主要作用是就是產生數(shù)據(jù)。傳統(tǒng)行業(yè)大多是將這些數(shù)據(jù)存儲在Oracle和SQL Server上，互聯(lián)網行業(yè)則選擇開源數(shù)據(jù)庫(MySQL、NoSQL)的居多。

2、ODS

ODS全稱是Openrational Data Store，直譯過來就是操作數(shù)據(jù)存儲。在具體項目中往往被叫做中間庫或臨時庫。數(shù)據(jù)從源系統(tǒng)進入數(shù)據(jù)倉庫前一般會有一個中間層，就是ODS。

ODS有以下幾個特點：

整合異構的數(shù)據(jù)，數(shù)據(jù)都是先到ODS再到數(shù)據(jù)倉庫

轉移一部分業(yè)務系統(tǒng)細節(jié)查詢的功能，直接跨不同的關系型數(shù)據(jù)庫進行查詢有比較大的局限性

數(shù)據(jù)編碼標準化轉化

數(shù)據(jù)是動態(tài)的、可更新的，DW是靜態(tài)數(shù)據(jù)

ODS存儲當前或者近期的數(shù)據(jù)，DW存儲歷史性數(shù)據(jù)

ODS數(shù)據(jù)容量級別較小，DW的數(shù)據(jù)容量很大

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

3、EDW介紹

EDW有如下特點：

面向主題：各個源系統(tǒng)之間在物理上往往是分離的，數(shù)據(jù)也是按照源系統(tǒng)服務的業(yè)務/流程進行組織，而數(shù)據(jù)倉庫中的數(shù)據(jù)是按照一定的主題域進行組織的。例如：用戶、組織、財務、事件、產品等主題。

集成性：數(shù)據(jù)倉庫中的數(shù)據(jù)是在對原有分散的數(shù)據(jù)庫數(shù)據(jù)進行抽取、清理的基礎上，再通過系統(tǒng)加工、匯總和整理后得到的，必須消除源數(shù)據(jù)中的不一致性，以保證數(shù)據(jù)倉庫內的信息在企業(yè)級是全局一致的。

相對穩(wěn)定：數(shù)據(jù)倉庫的數(shù)據(jù)主要供企業(yè)決策分析之用，主要用來查詢，很少涉及修改和刪除（不提供修改和刪除的功能），通常情況下數(shù)據(jù)也不會輕易的被刷新（指進入DW的數(shù)據(jù)不會經常因為源系統(tǒng)的原因需要重新被刷新，如果有這個場景，要思考是否是設計上除了問題）。

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

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

4、DM(Data Marts)介紹

數(shù)據(jù)集市一般是面向部門級業(yè)務(雖然很多時候都在說面向企業(yè)級，事實上在實施的時候往往面向的是部門級，這是傳統(tǒng)企業(yè)的一個很大的特征)，是為了滿足他們的需求而建立的一種分析型環(huán)境。投資規(guī)模比較小，更關注在數(shù)據(jù)中構建復雜的業(yè)務規(guī)則來支持功能強大的分析。

現(xiàn)在有人認為數(shù)據(jù)集市的概念在大數(shù)據(jù)時代已經是過時了，其實這里面我認為還是有一定誤區(qū)。大數(shù)據(jù)時代也需要數(shù)據(jù)集市，只是數(shù)據(jù)集市中分析結果背后的邏輯有所變化，由因果關系逐步轉向了關聯(lián)關系。

我們認為傳統(tǒng)數(shù)倉仍然有非常大的應用場景，起碼是在大多數(shù)數(shù)據(jù)分析和商業(yè)BI上完全可用。在大多數(shù)場景下，最合理的做法是將DM替換成為現(xiàn)在更為流行、體驗更好的DV（數(shù)據(jù)可視化）產品。

二、傳統(tǒng)數(shù)倉應該做如何的變化

為了適應大數(shù)據(jù)時代，傳統(tǒng)數(shù)據(jù)倉庫技術應該做如下的變化來更好的服務與企業(yè)數(shù)據(jù)分析的需求。

1、源系統(tǒng)設計

源系統(tǒng)設計本身并不屬于數(shù)據(jù)倉庫技術的一部分，但是源系統(tǒng)設計的優(yōu)劣會直接影響數(shù)據(jù)倉庫實施的成本。最明顯的就是數(shù)據(jù)結構的不統(tǒng)一問題，這對后期數(shù)據(jù)抽取、清洗會帶來極大的成本，應該盡早的實行元數(shù)據(jù)管理。另外特別重要的一點是數(shù)據(jù)庫架構的規(guī)劃，要跳出某個具體的源系統(tǒng)，站在企業(yè)的角度對數(shù)據(jù)庫進行頂層架構設計。

2、ODS設計

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

3、EDW設計

數(shù)據(jù)倉庫的選擇在PostgreSQL、Greenplum和Hadoop中展開。對于在線交易系統(tǒng)選擇的肯定是PostgreSQL，而對于真正的數(shù)據(jù)倉庫就應該選擇Greenplum。

Greenplum體系結構

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

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

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

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

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

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

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

引入Hadoop

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

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

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

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

三、總結

數(shù)據(jù)倉庫技術依然有其廣泛的應用場景，我們應該根據(jù)業(yè)務的需求變化、用戶體驗的提升等角度對設計和技術選型進行調整和適應，而不是鼓吹概念，動則大數(shù)據(jù)，事實上有幾個企業(yè)里面擁有的數(shù)據(jù)真正屬于大數(shù)據(jù)？