概述

最近開始接觸數(shù)據(jù)可視化項目，準(zhǔn)備做一下數(shù)據(jù)倉庫，特此總結(jié)一下數(shù)據(jù)倉庫之MPP架構(gòu)內(nèi)容。

一、數(shù)據(jù)倉庫簡介

數(shù)據(jù)倉庫，英文名稱為Data Warehouse，可簡寫為DW或DWH。數(shù)據(jù)倉庫，是為企業(yè)所有級別的決策制定過程，提供所有類型數(shù)據(jù)支持的戰(zhàn)略集合。它是單個數(shù)據(jù)存儲，出于分析性報告和決策支持目的而創(chuàng)建。

數(shù)據(jù)倉庫的目的是構(gòu)建面向分析的集成化數(shù)據(jù)環(huán)境，為企業(yè)提供決策支持（Decision Support）。其實數(shù)據(jù)倉庫本身并不“生產(chǎn)”任何數(shù)據(jù)，同時自身也不需要“消費”任何的數(shù)據(jù)，數(shù)據(jù)來源于外部，并且開放給外部應(yīng)用，這也是為什么叫“倉庫”，而不叫“工廠”的原因。因此數(shù)據(jù)倉庫的基本架構(gòu)主要包含的是數(shù)據(jù)流入流出的過程，可以分為三層——源數(shù)據(jù)、數(shù)據(jù)倉庫、數(shù)據(jù)應(yīng)用。

數(shù)據(jù)倉庫最主要的工作是從各數(shù)據(jù)源獲取數(shù)據(jù)及在數(shù)據(jù)倉庫內(nèi)的數(shù)據(jù)轉(zhuǎn)換和流動都可以認(rèn)為是 ETL（抽取Extra, 轉(zhuǎn)化 Transfer, 裝載 Load）的過程，ETL 是數(shù)據(jù)倉庫的流水線，也可以認(rèn)為是數(shù)據(jù)倉庫的血液，它維系著數(shù)據(jù)倉庫中數(shù)據(jù)的新陳代謝，而數(shù)據(jù)倉庫日常的管理和維護(hù)工作的大部分精力就是保持 ETL 的正常和穩(wěn)定。

隨著海量數(shù)據(jù)問題的出現(xiàn)，海量管理能力，多類型，變化快，高可用性，低成本，高端可擴(kuò)展性等需求給企業(yè)數(shù)據(jù)戰(zhàn)略帶來了巨大的挑戰(zhàn)。企業(yè)數(shù)據(jù)倉庫、數(shù)據(jù)中心的技術(shù)選型變得尤其重要！

二、數(shù)據(jù)倉庫特點

1、面向主題

是企業(yè)系統(tǒng)信息中的數(shù)據(jù)綜合、歸類并進(jìn)行分析的一個抽象，對應(yīng)企業(yè)中某一個宏觀分析領(lǐng)域所涉及的分析對象。

比如購物是一個主題，那么購物里面包含用戶、訂單、支付、物流等數(shù)據(jù)綜合，對這些數(shù)據(jù)要進(jìn)行歸類并分析，分析這個對象數(shù)據(jù)的一個完整性、一致性的描述，能完整、統(tǒng)一的劃分對象所設(shè)計的各項數(shù)據(jù)。

如果此時要統(tǒng)計一個用戶從瀏覽到支付完成的時間時，在購物主題中缺少了支付數(shù)據(jù)或訂單數(shù)據(jù)，那么這個對象數(shù)據(jù)的完整性和一致性就可能無法保證了。

2、數(shù)據(jù)集成

數(shù)據(jù)倉庫的數(shù)據(jù)是從原有分散的數(shù)據(jù)庫中的數(shù)據(jù)抽取而來的。

操作型數(shù)據(jù)和支持決策分析型（DSS）數(shù)據(jù)差別甚大，這里需要做大量的數(shù)據(jù)清洗與數(shù)據(jù)整理的工作。

第一：每一個主題的源數(shù)據(jù)在原有分散數(shù)據(jù)庫中的有許多重復(fù)和不一致，且不同數(shù)據(jù)庫的數(shù)據(jù)是和不同的應(yīng)用邏輯捆綁的。

第二：數(shù)據(jù)倉庫中的綜合性數(shù)據(jù)不能從原有的數(shù)據(jù)庫系統(tǒng)直接得到，因此在數(shù)據(jù)進(jìn)入數(shù)據(jù)倉庫之前要進(jìn)過統(tǒng)一和綜合。（字段同名異意，異名同義，長度等）

3、不可更新

數(shù)據(jù)倉庫的數(shù)據(jù)主要是提供決策分析用，設(shè)計的數(shù)據(jù)主要是數(shù)據(jù)查詢，一般情況下不做修改，這些數(shù)據(jù)反映的是一段較長時間內(nèi)歷史數(shù)據(jù)的內(nèi)容，有一塊修改了影響的是整個歷史數(shù)據(jù)的過程數(shù)據(jù)。

數(shù)據(jù)倉庫的查詢量往往很大，所以對數(shù)據(jù)查詢提出了更高的要求，要求采用各種復(fù)雜的索引技術(shù)，并對數(shù)據(jù)查詢的界面友好性和數(shù)據(jù)凸顯性提出更高的要求。

4、隨時間不斷變化

數(shù)據(jù)倉庫中的數(shù)據(jù)不可更新是針對應(yīng)用來說，從數(shù)據(jù)的進(jìn)入到刪除的整個生命周期中，數(shù)據(jù)倉庫的數(shù)據(jù)是永遠(yuǎn)不變的。

數(shù)據(jù)倉庫的數(shù)據(jù)是隨著時間變化而不斷增加新的數(shù)據(jù)。

數(shù)據(jù)倉庫隨著時間變化不斷刪去久的數(shù)據(jù)內(nèi)容，數(shù)據(jù)倉庫的數(shù)據(jù)也有時限的，數(shù)據(jù)庫的數(shù)據(jù)時限一般是60 ~ 90天，而數(shù)據(jù)倉庫的數(shù)據(jù)一般是5年~10年。

數(shù)據(jù)倉庫中包含大量的綜合性數(shù)據(jù)，這些數(shù)據(jù)很多是跟時間有關(guān)的，這些數(shù)據(jù)特征都包含時間項，以標(biāo)明數(shù)據(jù)的歷史時期。

三、數(shù)據(jù)倉庫和數(shù)據(jù)庫的區(qū)別

數(shù)據(jù)庫的操作：一般稱為聯(lián)機(jī)事務(wù)處理OLAP（On-Line Transaction Processing），是針對具體的業(yè)務(wù)在數(shù)據(jù)庫中的聯(lián)機(jī)操作，具有數(shù)據(jù)量較少的特點，通常對少量的數(shù)據(jù)記錄進(jìn)行查詢、修改。

數(shù)據(jù)倉庫的操作：一般稱為聯(lián)機(jī)分析處理OLAP（On-Line Analytical Processing），是針對某些主題（綜合數(shù)據(jù)）的歷史數(shù)據(jù)進(jìn)行分析，支持管理決策。

四、數(shù)據(jù)倉庫--MPP架構(gòu)

1、傳統(tǒng)數(shù)據(jù)倉庫

數(shù)據(jù)倉庫有著如下幾個特性：主題導(dǎo)向、集成性、時間差異性、不變動性，而每一個特性的使用程度和趨向，將決定這個數(shù)據(jù)倉庫的能力，但是也因為業(yè)務(wù)導(dǎo)向性的存在，也常常會占主導(dǎo)作用，將數(shù)據(jù)倉庫向數(shù)據(jù)集市轉(zhuǎn)化，而使得數(shù)據(jù)倉庫本身變的臃腫，查詢效率下降，分析細(xì)顆粒度的數(shù)據(jù)變的較為困難。

對于此，著重分析一下它的幾個特性，尋求新的變革。

1）主題導(dǎo)向（Subject-Oriented）

將數(shù)據(jù)倉庫有別于一般 OLTP 系統(tǒng)，數(shù)據(jù)倉庫的資料模型設(shè)計，著重將資料按其意義歸類至相同的主題區(qū)（subject area），因此稱為主題導(dǎo)向。舉例如 Party、Arrangement、Event、Product 等。

2）集成性（Integrated）

資料來自企業(yè)各 OLTP 系統(tǒng)，在數(shù)據(jù)倉庫中是集成過且一致的。

3）時間差異性（Time-Variant）

資料的變動，在數(shù)據(jù)倉庫中是能夠被紀(jì)錄以及追蹤變化的，有助于能反映出能隨著時間變化的資料軌跡。

4）不變動性（Nonvolatile）

資料一旦確認(rèn)寫入后是不會被替換或刪除的，即使資料是錯誤的亦同。由此可以看出，數(shù)據(jù)倉庫本身是一個不斷收集數(shù)據(jù)，按相應(yīng)的規(guī)則進(jìn)行組合匯聚的過程，如圖 所示。

圖：數(shù)據(jù)倉庫聚合數(shù)據(jù)面板

觀察上圖可以知道，這個過程所損耗的，也只是倉庫本身的性能和 ETL 性能，而倉庫本身的性能取決于通信、I/O 能力和硬件性能，ETL 的性能也基于此。因此，在硬件性能如此強(qiáng)勁的今天，如何提高這三項指標(biāo)，決定了倉庫本身性能的優(yōu)劣，那么一個合適的架構(gòu)去操作，將顯得尤為重要，特別是在數(shù)據(jù)量不斷膨脹的今天，架構(gòu)將決定企業(yè)數(shù)據(jù)倉庫的支撐能力。

2、MPP架構(gòu)數(shù)據(jù)倉庫

在大數(shù)據(jù)普及的今天，各種架構(gòu)的數(shù)據(jù)庫不斷出現(xiàn)，下圖即是當(dāng)前使用的各種結(jié)構(gòu)的一個對比圖，從易用性到擴(kuò)展能力的對比。

圖 ：大數(shù)據(jù)技術(shù)棧對比

對于兼顧易用性和擴(kuò)展能力而言，MPP 架構(gòu)的數(shù)據(jù)庫占據(jù)著比較大的優(yōu)勢。結(jié)合上圖的結(jié)果，能處理高數(shù)據(jù)量的 MPP 架構(gòu)數(shù)據(jù)庫，是現(xiàn)在的最佳選擇，那么 MPP 到底是什么呢？

MPP 即大規(guī)模并行處理（Massively Parallel Processor），在 MPP 系統(tǒng)中，每個SMP 節(jié)點也可以運行自己的操作系統(tǒng)、數(shù)據(jù)庫等。換言之，每個節(jié)點內(nèi)的 CPU 不能訪問另一個節(jié)點的內(nèi)存。節(jié)點之間的信息交互是通過節(jié)點互聯(lián)網(wǎng)絡(luò)實現(xiàn)的，這個過程一般稱為數(shù)據(jù)重分配(Data Redistribution)。

與傳統(tǒng)的 SMP 架構(gòu)明顯不同，通常情況下，MPP 系統(tǒng)因為要在不同處理單元之間傳送信息，所以它的效率要比 SMP 要差一點，但是這也不是絕對的，因為 MPP 系統(tǒng)不共享資源，因此對它而言，資源比 SMP 要多，當(dāng)需要處理的事務(wù)達(dá)到一定規(guī)模時，MPP 的效率要比 SMP好。這就是看通信時間占用計算時間的比例而定，如果通信時間比較多，那 MPP 系統(tǒng)不占優(yōu)勢了，相反，如果通信時間比較少，那 MPP 系統(tǒng)可以充分發(fā)揮資源的優(yōu)勢，達(dá)到高效率。當(dāng)前使用的 OTLP 程序中，用戶訪問一個中心數(shù)據(jù)庫，如果采用 SMP 系統(tǒng)結(jié)構(gòu)，它的效率要比采用 MPP 結(jié)構(gòu)要快得多。而 MPP 系統(tǒng)在決策支持和數(shù)據(jù)挖掘方面顯示了優(yōu)勢，可以這樣說，如果操作相互之間沒有什么關(guān)系，處理單元之間需要進(jìn)行的通信比較少，那采用MPP 系統(tǒng)就要好，相反就不合適了。

在數(shù)據(jù)庫非共享集群中，每個節(jié)點都有獨立的磁盤存儲系統(tǒng)和內(nèi)存系統(tǒng)，業(yè)務(wù)數(shù)據(jù)根據(jù)數(shù)據(jù)庫模型和應(yīng)用特點劃分到各個節(jié)點上，每臺數(shù)據(jù)節(jié)點通過專用網(wǎng)絡(luò)或者商業(yè)通用網(wǎng)絡(luò)互相連接，彼此協(xié)同計算，作為整體提供數(shù)據(jù)庫服務(wù)。非共享數(shù)據(jù)庫集群有完全的可伸縮性、高可用、高性能、優(yōu)秀的性價比、資源共享等優(yōu)勢。

圖：大規(guī)模并行處理(MPP)架構(gòu)

MPP 架構(gòu)數(shù)據(jù)庫采用 Shared-nothing 架構(gòu)（非共享集群），每個節(jié)點都有自己的操作系統(tǒng)、數(shù)據(jù)庫、硬件資源，節(jié)點之間通過網(wǎng)絡(luò)來通信。在擁有高帶寬網(wǎng)絡(luò)的內(nèi)部環(huán)境中，使得每個資源都能擁有最佳的運行環(huán)境，以獲得高輸出性能。

圖 ：Shared-nothing架構(gòu)

因此，相較于傳統(tǒng)型數(shù)據(jù)庫和其他架構(gòu)數(shù)據(jù)庫，MPP 架構(gòu)的數(shù)據(jù)庫有如下優(yōu)勢：

1）大數(shù)據(jù)分析需求

傳統(tǒng)數(shù)據(jù)庫無法支持大規(guī)模集群與 PB 級別數(shù)據(jù)量，且性能受限、擴(kuò)展性受限，MPP架構(gòu)數(shù)據(jù)支持大規(guī)模集群以及PB級別數(shù)據(jù)，性能根據(jù)擴(kuò)展節(jié)點性能呈線性關(guān)系

2）軟硬件一體機(jī)成本高昂、擴(kuò)展受限

高性能單機(jī)服務(wù)器的成本十分高昂，生產(chǎn)擴(kuò)容、測試、開發(fā)、容災(zāi)都需新購?fù)吞栆惑w機(jī)（機(jī)柜），并且跨代兼容性問題目前也沒有得到很好的解決。MPP架構(gòu)數(shù)據(jù)庫可根據(jù)需要無限擴(kuò)展。

3）In-memory 技術(shù)太貴而且不成熟

內(nèi)存成本過高，TB 級別以下，不適合大數(shù)據(jù)量；MPP架構(gòu)成本可控，對于TB級數(shù)據(jù)支持優(yōu)秀，很適合大數(shù)據(jù)量。

4）Hadoop 技術(shù)的先天不足

Hive 等 sql-on-hadoop 性能太慢，SQL 兼容性與支持不足，數(shù)據(jù)安全性無法保證。MPP架構(gòu)數(shù)據(jù)庫支持通用標(biāo)準(zhǔn)SQL，數(shù)據(jù)可冗余備份，具有高可用，高安全性。

五、主流分布式數(shù)據(jù)庫選擇--GreenPlum

1、 基礎(chǔ)架構(gòu)

Greenplum 是基于 Hadoop 的一款分布式數(shù)據(jù)庫產(chǎn)品，在處理海量數(shù)據(jù)方面相比傳統(tǒng)數(shù)據(jù)庫有著較大的優(yōu)勢。

Greenplum 整體架構(gòu)如下圖：

圖：GreenPlum整體架構(gòu)圖

數(shù)據(jù)庫由 Master Severs 和 Segment Severs 通過 Interconnect 互聯(lián)組。

Master 主機(jī)負(fù)責(zé)：建立與客戶端的連接和管理；SQL 的解析并形成執(zhí)行計劃；執(zhí)行計劃向 Segment 的分發(fā)收集 Segment 的執(zhí)行結(jié)果；Master 不存儲業(yè)務(wù)數(shù)據(jù)，只存儲數(shù)據(jù)字典。

Segment 主機(jī)負(fù)責(zé)：業(yè)務(wù)數(shù)據(jù)的存儲和存取；用戶查詢 SQL 的執(zhí)行。

2、主要特性

Greenplum 整體有如下技術(shù)特點：

1）Shared-nothing 架構(gòu)

海量數(shù)據(jù)庫采用最易于擴(kuò)展的 Shared-nothing 架構(gòu)，每個節(jié)點都有自己的操作系統(tǒng)、數(shù)據(jù)庫、硬件資源，節(jié)點之間通過網(wǎng)絡(luò)來通信。

2）基于 gNet Software Interconnect

數(shù)據(jù)庫的內(nèi)部通信通過基于超級計算的“軟件 Switch”內(nèi)部連接層，基于通用的 gNet(GigE， 10GigE) NICs/switches 在節(jié)點間傳遞消息和數(shù)據(jù)，采用高擴(kuò)展協(xié)議，支持?jǐn)U展到 1000個以上節(jié)點。

3）并行加載技術(shù)

利用并行數(shù)據(jù)流引擎，數(shù)據(jù)加載完全并行，加載數(shù)據(jù)可達(dá)到 4.5T/小時（理想配置）。并且可以直接通過 SQL 語句對外部表進(jìn)行操作。

4）支持行、列壓縮存儲技術(shù)

海量數(shù)據(jù)庫支持 ZLIB 和 QUICKLZ 方式的壓縮，壓縮比可到 10：1。壓縮數(shù)據(jù)不一定會帶來性能的下降，壓縮表通過利用空閑的 CPU 資源，而減少 I/O 資源占用。海量數(shù)據(jù)庫除支持主流的行存儲模式外，還支持列存儲模式。如果常用的查詢只取表中少量字段，則列模式效率更高，如查詢需要取表中的大量字段，行模式效率更高。海量數(shù)據(jù)庫的多種壓縮存儲技術(shù)在提高數(shù)據(jù)存儲能力的同時，也可根據(jù)不同應(yīng)用需求提高查詢的效率。

3、主要局限

1）用戶不可靈活控制事務(wù)的提交，用戶提交的處理將被自動視作整體事務(wù)，整體提交，整體回滾。

2）數(shù)據(jù)庫需要額外的空間清理維護(hù)，給數(shù)據(jù)庫維護(hù)帶來額外的工作量。

3）用戶不能靈活分配或控制服務(wù)器資源，服務(wù)器自動分配分發(fā)。

4）對磁盤I/O有比較高的要求。

4、 GreenPlum 對比其他數(shù)據(jù)庫

相比于其他的數(shù)據(jù)庫，GreenPlum 數(shù)據(jù)庫最大的優(yōu)勢在于其開源，極大的降低了其成本費用，相較于以往動輒四五百萬以上的費用，如今只需要不到三分之一的價格即可在企業(yè)成功運用，且能夠根據(jù)自己企業(yè)的特性進(jìn)行改良。