本文主要討論數(shù)據(jù)倉庫的構(gòu)建方法論，包括數(shù)據(jù)倉庫的價(jià)值、選型、構(gòu)建思路。隨著數(shù)據(jù)規(guī)模膨脹和業(yè)務(wù)復(fù)雜度的提升，大型企業(yè)需要構(gòu)建企業(yè)級的數(shù)據(jù)倉庫（數(shù)據(jù)湖）來快速支撐業(yè)務(wù)的數(shù)據(jù)化需求，與傳統(tǒng)的數(shù)據(jù)庫構(gòu)建不通，數(shù)據(jù)倉庫即是OLAP場景，偏于歷史數(shù)據(jù)的存儲(chǔ)/分析，用冗余存儲(chǔ)換取數(shù)據(jù)價(jià)值。

01 數(shù)據(jù)倉庫與數(shù)據(jù)庫的區(qū)別

所有的應(yīng)用系統(tǒng)都會(huì)涉及到數(shù)據(jù)庫，針對數(shù)據(jù)庫歸納和存放，也就是數(shù)據(jù)庫的常見操作：增、刪、改、查，那么為什么想要對企業(yè)數(shù)據(jù)進(jìn)行分析，不能直接查詢數(shù)據(jù)庫，非要大費(fèi)力氣的去創(chuàng)建所謂的數(shù)據(jù)倉庫和數(shù)據(jù)湖呢？

數(shù)據(jù)倉庫主要是為了能夠支持管理決策，而數(shù)據(jù)庫是為了滿足系統(tǒng)的及時(shí)性、一致性。

好比你去銀行存錢，你希望剛把錢存進(jìn)去就能夠查詢到余額增加，你不希望第二天才能夠確認(rèn)，但是若是銀行想對你的流水和余額進(jìn)行分析，這個(gè)時(shí)候希望知道你在不同時(shí)期的銀行余額，那么從數(shù)據(jù)庫里是查不到你的歷史余額信息的，因?yàn)閿?shù)據(jù)庫在設(shè)計(jì)的時(shí)候就需要滿足一定的范式，為的就是滿足及時(shí)性和去冗余，一個(gè)客戶對應(yīng)的余額只有一個(gè)，你在存款的時(shí)候，新的余額就會(huì)覆蓋掉老的余額，所以你的歷史信息在數(shù)據(jù)庫中是沒有記錄的。

如果銀行希望查詢客戶的歷史信息，比如說你需要查詢個(gè)人客戶信息，他可能在柜臺交易系統(tǒng)中有記錄，也可以在網(wǎng)上銀行交易系統(tǒng)也有記錄，而你希望查詢客戶柜臺交易信息以及網(wǎng)銀交易信息，這個(gè)時(shí)候需要跨系統(tǒng)查詢，有可能兩個(gè)系統(tǒng)所使用的數(shù)據(jù)庫都不一樣，各自權(quán)限負(fù)責(zé)人員也不一樣，跨系統(tǒng)查詢顯得非常困難，這個(gè)時(shí)候需要一個(gè)系統(tǒng)能夠?qū)⑺�有業(yè)務(wù)系統(tǒng)的數(shù)據(jù)匯總起來并能夠跨系統(tǒng)查詢，這個(gè)時(shí)候數(shù)據(jù)倉庫定義中的集成的，反映歷史變化的正好解決了此問題，數(shù)據(jù)庫和數(shù)據(jù)倉庫的對比。

其中OLTP（On-Line Transaction Processing）指的是傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，針對實(shí)時(shí)業(yè)務(wù)處理，面對的主要操作是隨機(jī)讀寫，采用滿足三范式的實(shí)體關(guān)系模型存儲(chǔ)數(shù)據(jù)，從而在事務(wù)處理中解決數(shù)據(jù)的冗余和一致性問題。

而OLAP（On-Line Analytical Processing）系統(tǒng)面向數(shù)據(jù)批量讀寫，OLAP不關(guān)注事務(wù)處理的一致性，主要在數(shù)據(jù)的整合，以及復(fù)雜大數(shù)據(jù)查詢和處理性能，OLAP能夠支持復(fù)雜的分析操作。

綜上， 數(shù)據(jù)庫的設(shè)計(jì)是為了完成交易而設(shè)計(jì)的，不是為了而查詢和分析的便利設(shè)計(jì)的。而數(shù)據(jù)倉庫是為了大量的查詢和分析所設(shè)計(jì)的。

02 數(shù)據(jù)倉庫對于企業(yè)的價(jià)值

數(shù)據(jù)倉庫能實(shí)現(xiàn)跨業(yè)務(wù)條線、跨系統(tǒng)的數(shù)據(jù)整合，為管理分析和業(yè)務(wù)決策提供統(tǒng)一的數(shù)據(jù)支持，從根本上把運(yùn)營數(shù)據(jù)轉(zhuǎn)化成為高價(jià)值的可以獲取的信息（或知識），并且在恰當(dāng)?shù)臅r(shí)候通過恰當(dāng)?shù)姆绞桨亚‘?dāng)?shù)男畔�傳遞給恰當(dāng)?shù)娜恕?/span>

數(shù)據(jù)倉庫定義：面向主題的（Subject Oriented）、集成的（Integrate）、相對穩(wěn)定的（Non-Volatile）、反映歷史變化（Time Variant）的數(shù)據(jù)集合；

• 面向主題：是指用戶使用數(shù)據(jù)倉庫進(jìn)行決策時(shí)所關(guān)心的重點(diǎn)方面，如：收入、客戶、銷售渠道等；所謂面向主題，是指數(shù)據(jù)倉庫內(nèi)的信息是按主題進(jìn)行組織的，而不是像業(yè)務(wù)支撐系統(tǒng)那樣是按照業(yè)務(wù)功能進(jìn)行組織的。

• 集成的：是指數(shù)據(jù)倉庫中的信息不是從各個(gè)業(yè)務(wù)系統(tǒng)中簡單抽取出來的，而是經(jīng)過一系列加工、整理和匯總的過程，因此數(shù)據(jù)倉庫中的信息是關(guān)于整個(gè)企業(yè)的一致的全局信息。

• 反映歷史變化：數(shù)據(jù)倉庫內(nèi)的信息并不只是反映企業(yè)當(dāng)前的狀態(tài)，而是記錄了從過去某一時(shí)點(diǎn)到當(dāng)前各個(gè)階段的信息。通過這些信息，可以對企業(yè)的發(fā)展歷程和未來趨勢做出定量分析和預(yù)測。

數(shù)據(jù)倉庫并非是面向生產(chǎn)的數(shù)據(jù)系統(tǒng)，而是集成并加工了多個(gè)數(shù)據(jù)庫系統(tǒng)數(shù)據(jù)，并面向各個(gè)業(yè)務(wù)條線構(gòu)建的數(shù)據(jù)存儲(chǔ)體系，能夠提供快速的運(yùn)營/決策支撐能力。

• 高級管理進(jìn)行業(yè)務(wù)分析和績效考核的數(shù)據(jù)整合、分析和展現(xiàn)的工具。

• 主要用于歷史性、綜合性和深層次數(shù)據(jù)分析。

• 數(shù)據(jù)來源是ERP（例:SAP）系統(tǒng)或其他業(yè)務(wù)系統(tǒng)。

• 能夠提供靈活、直觀、簡潔和易于操作的多維查詢分析。

• 不是日常交易操作系統(tǒng)，不能直接產(chǎn)生交易數(shù)據(jù)。

03 數(shù)據(jù)倉庫的模型構(gòu)建

一、數(shù)據(jù)倉庫構(gòu)建需要考慮的問題

與數(shù)據(jù)庫的單表基于ER模型構(gòu)建思路不同，其面向特定業(yè)務(wù)分析的特性，決定了它的構(gòu)建需要整合多套數(shù)據(jù)輸入系統(tǒng)，并輸出多業(yè)務(wù)條線的、集成的數(shù)據(jù)服務(wù)能力，需要考慮更全面的因素，包括：

• 業(yè)務(wù)需求：從了解業(yè)務(wù)需求著手分析業(yè)務(wù)特點(diǎn)和業(yè)務(wù)期望。

• 系統(tǒng)架構(gòu)：從系統(tǒng)架構(gòu)和數(shù)據(jù)分布、數(shù)據(jù)特性等角度，分析系統(tǒng)架構(gòu)設(shè)計(jì)上是否有問題。

• 邏輯設(shè)計(jì)：從數(shù)據(jù)模型邏輯設(shè)計(jì)出發(fā)是否設(shè)計(jì)合理，是否符合數(shù)據(jù)庫開發(fā)和設(shè)計(jì)規(guī)范等。

• 物理設(shè)計(jì)：從庫表類型、庫表分區(qū)、索引、主鍵設(shè)計(jì)等維度，主要針對性能，可擴(kuò)展性進(jìn)行物理模型設(shè)計(jì)審查。

二、什么是數(shù)倉的數(shù)據(jù)模型

數(shù)據(jù)倉庫模型構(gòu)建的宗旨能夠直觀地表達(dá)業(yè)務(wù)邏輯，能夠使用實(shí)體、屬性及其關(guān)系對企業(yè)運(yùn)營和邏輯規(guī)則進(jìn)行統(tǒng)一的定義、編碼和命名，是業(yè)務(wù)人員和開發(fā)人員之間溝通的一套語言，數(shù)據(jù)倉庫數(shù)據(jù)模型的作用：

• 統(tǒng)一企業(yè)的數(shù)據(jù)視圖。

• 定義業(yè)務(wù)部門對于數(shù)據(jù)信息的需求。

• 構(gòu)建數(shù)據(jù)倉庫原子層的基礎(chǔ)。

• 支持?jǐn)?shù)據(jù)倉庫的發(fā)展規(guī)劃。

• 初始化業(yè)務(wù)數(shù)據(jù)的歸屬。

常用數(shù)據(jù)模型的是關(guān)系模型和維度模型，關(guān)系模型從全企業(yè)的高度設(shè)計(jì)一個(gè)3NF模型的方法，用實(shí)體加關(guān)系描述的數(shù)據(jù)模型描述企業(yè)業(yè)務(wù)架構(gòu)，在范式理論上符合3NF，其站在企業(yè)角度進(jìn)行面向主題的抽象，而不是針對某個(gè)具體業(yè)務(wù)流程的，它更多是面向數(shù)據(jù)的整合和一致性治理。

維度建模以分析決策的需求為出發(fā)點(diǎn)構(gòu)建模型，直接面向業(yè)務(wù)，典型的代表是我們比較熟知的星形模型，以及在一些特殊場景下適用的雪花模型，大多數(shù)據(jù)倉庫均會(huì)采用維度模型建模。

維度建模中的事實(shí)表客觀反應(yīng)整個(gè)業(yè)務(wù)的流程，比如一次購買行為我們就可以理解為是一個(gè)事實(shí)，訂單表就是一個(gè)事實(shí)表，你可以理解他就是在現(xiàn)實(shí)中發(fā)生的一次操作型事件，我們每完成一個(gè)訂單，就會(huì)在訂單中增加一條記錄，訂單表存放一些維度表中的主鍵集合，這些ID分別能對應(yīng)到維度表中的一條記錄，用戶表、商家表、時(shí)間表這些都屬于維度表，這些表都有一個(gè)唯一的主鍵，然后在表中存放了詳細(xì)的數(shù)據(jù)信息。

如果是采用ER模型，需要設(shè)計(jì)出一個(gè)大寬表，將訂單-商家-地址-時(shí)間等信息囊括在內(nèi)，比較直觀、細(xì)粒度，但也存在設(shè)計(jì)冗余，如果數(shù)據(jù)量很大，對于查詢和檢索將是一個(gè)災(zāi)難。

三、如何構(gòu)建數(shù)倉的數(shù)據(jù)模型

概念模型設(shè)計(jì)（業(yè)務(wù)模型）：界定系統(tǒng)邊界；確定主要的主題域及其內(nèi)容；邏輯模型設(shè)計(jì)：維度建模方法（事實(shí)表、維度表）；以星型和雪花型來組織數(shù)據(jù)；物理模型設(shè)計(jì)：將數(shù)據(jù)倉庫的邏輯模型物理化到數(shù)據(jù)庫的過程。

1、概念模型設(shè)計(jì)

數(shù)據(jù)倉庫中數(shù)據(jù)模型設(shè)計(jì)順序如上，數(shù)據(jù)倉庫是為了輔助決策的，與業(yè)務(wù)流程（Business Process）息息相關(guān)，數(shù)據(jù)模型的首要任務(wù)便是選擇業(yè)務(wù)流程，為數(shù)據(jù)倉庫的建立提供指導(dǎo)方向，這樣才能反過來為業(yè)務(wù)提供更好的決策數(shù)據(jù)支撐，讓數(shù)據(jù)倉庫價(jià)值的最大化，對于每個(gè)業(yè)務(wù)流程，都需要進(jìn)行獨(dú)立的數(shù)據(jù)建模，將業(yè)務(wù)系統(tǒng)中的 ER 模型轉(zhuǎn)化為數(shù)據(jù)倉庫中的維度數(shù)據(jù)模型，以便更好的查詢與分析。

2、邏輯模型設(shè)計(jì)

事實(shí)表一般由兩部分組成，維度（Dimension）和度量（Measurement），事實(shí)表可以通俗的理解為「什么人在什么時(shí)間做了什么事」的事實(shí)記錄或者場景上下文，擁有最大的數(shù)據(jù)量，它是業(yè)務(wù)流程的核心體現(xiàn)，比如電商場景中的訂單表，其主鍵為一個(gè)聯(lián)合主鍵，由各個(gè)維度的外鍵組成，外鍵不能為空值，事實(shí)表一般不包含非數(shù)字類型字段，雖然數(shù)據(jù)量大，但占用的空間并不大，保證更高的查詢效率。

維度表用于對事實(shí)表的補(bǔ)充說明，描述和還原事實(shí)發(fā)生時(shí)的場景，如電商訂單中定義用戶、商品、地址、時(shí)間、促銷5個(gè)維度，通過這5個(gè)維度還原訂單發(fā)生時(shí)的場景，什么人在什么時(shí)間在什么地方購買了什么商品，以及購買該商品的促銷方式。對于每一個(gè)維度而言，都有若干個(gè)屬性來描述，比如用戶有性別、年齡、所在地等信息。這些維度的屬性就是之后數(shù)據(jù)統(tǒng)計(jì)的依據(jù)，比如我們可以統(tǒng)計(jì)不同性別，不同年齡，不同地區(qū)在訂單中的差異，從向用戶制定更精細(xì)的營銷策略。

在關(guān)系型數(shù)據(jù)庫三范式（3NF）設(shè)計(jì)極力避免數(shù)據(jù)的冗余，達(dá)到數(shù)據(jù)的高度一致性，但在數(shù)據(jù)倉庫中3NF并不是最佳實(shí)踐，反而讓系統(tǒng)復(fù)雜不已，不利于理解和維護(hù)，所以在維度建模中，維度表一般采取反范式的設(shè)計(jì)，在一張維度表中扁平化存儲(chǔ)維度的屬性，盡量避免使用外鍵。

3、物理模型設(shè)計(jì)

在完成數(shù)據(jù)倉庫的概念模型和邏輯模型設(shè)計(jì)之后，物理模型設(shè)計(jì)就是落地實(shí)施環(huán)節(jié)，根據(jù)數(shù)據(jù)的粒度和對于業(yè)務(wù)支撐能力將數(shù)據(jù)進(jìn)行分層存儲(chǔ)，數(shù)據(jù)分層存儲(chǔ)簡化了數(shù)據(jù)清洗的過程，每一層的邏輯變得更加簡單和易于理解，當(dāng)發(fā)生錯(cuò)誤或規(guī)則變化時(shí)，只需要進(jìn)行局部調(diào)整。

ODS層：全稱是Operational Data Store,又叫數(shù)據(jù)準(zhǔn)備層，數(shù)據(jù)來源層，主要用于原始數(shù)據(jù)在數(shù)據(jù)倉庫的落地，這些數(shù)據(jù)邏輯關(guān)系都與原始數(shù)據(jù)保持一致，在源數(shù)據(jù)裝入這一層時(shí)，要進(jìn)行諸如業(yè)務(wù)字段提取或去掉不用字段，臟數(shù)據(jù)處理等等�？梢岳斫鉃槭顷P(guān)系層的基礎(chǔ)數(shù)據(jù)。

DIM層：Dimension層，主要存放公共的信息數(shù)據(jù)，如國家代碼和國家名，地理位置等信息就存在DIM層表中，對外開放，用于DWD，DWS和APP層的數(shù)據(jù)維度關(guān)聯(lián)。

DWD層：全稱是Data Warehouse Detail，用于源系統(tǒng)數(shù)據(jù)在數(shù)據(jù)倉庫中的永久存儲(chǔ)，用以支撐DWS層和DM層無法覆蓋的需求，該層的數(shù)據(jù)模型主要解決一些數(shù)據(jù)質(zhì)量問題和數(shù)據(jù)的完整度問題，比如商場的會(huì)員信息來與不同表，某些會(huì)員的的和數(shù)據(jù)可能不完整等等問題。

DWS層：全稱是Data Warehouse Service，主要包含兩類匯總表：一是細(xì)粒度寬表，二是粗粒度匯總表，按照商場訂單例子，包含基于訂單、會(huì)員、商品、店鋪等實(shí)體的細(xì)粒度寬表和基于維度組合(會(huì)員日進(jìn)場匯總、會(huì)員消費(fèi)匯總、商場銷售日匯總、店鋪銷售日匯總等)的粗粒度匯總表。這層是對外開放的，用以支撐絕大部分的業(yè)務(wù)需求，匯總層是為了簡化源系統(tǒng)復(fù)雜的邏輯關(guān)系以及質(zhì)量問題等，這層是的業(yè)務(wù)結(jié)構(gòu)容易理解，dws層的匯總數(shù)據(jù)目標(biāo)是能滿足80%的業(yè)務(wù)計(jì)算。

其上根據(jù)業(yè)務(wù)需求可以繼續(xù)構(gòu)建ADS層（Application Data Store）和面向指標(biāo)和報(bào)表的高度匯總層。

04 案例：招標(biāo)采購系統(tǒng)的數(shù)據(jù)倉庫構(gòu)建

按照數(shù)據(jù)倉庫的構(gòu)建思路，順序是概念模型-->邏輯模型-->物理模型，最重要和復(fù)雜度較高的是概念模型的設(shè)計(jì)，需要結(jié)合業(yè)務(wù)，并根據(jù)業(yè)務(wù)特性設(shè)計(jì)事實(shí)表、維度表、頂層數(shù)據(jù)匯總表。

一、概念模型設(shè)計(jì)

概念模型需要結(jié)合生產(chǎn)系統(tǒng)的ER關(guān)系模型，梳理業(yè)務(wù)邏輯，當(dāng)前生產(chǎn)交易系統(tǒng)使用的是ORACLE數(shù)據(jù)庫，將數(shù)據(jù)分成多個(gè)庫：業(yè)務(wù)庫（包含招標(biāo)采購項(xiàng)目流程）、主體+組織庫（招標(biāo)人、投標(biāo)人、評標(biāo)專家、代理機(jī)構(gòu)）、財(cái)務(wù)庫（標(biāo)書費(fèi)、平臺服務(wù)費(fèi)、招標(biāo)保證金、CA辦理費(fèi)用等），項(xiàng)目表即是一個(gè)招標(biāo)流程表，該表會(huì)記錄關(guān)于招標(biāo)過程中的，招標(biāo)、投標(biāo)、開標(biāo)、評標(biāo)、定標(biāo)相關(guān)的數(shù)據(jù)：

• 招標(biāo)：招標(biāo)流程是招標(biāo)人發(fā)起的，招標(biāo)人將招標(biāo)過程委托給代理機(jī)構(gòu)，代理機(jī)構(gòu)會(huì)發(fā)布招標(biāo)公告，投標(biāo)人在報(bào)名、響應(yīng)階段產(chǎn)生數(shù)據(jù)，響應(yīng)后需要付投標(biāo)保證金。

• 投標(biāo)：投標(biāo)人給代理機(jī)構(gòu)繳納標(biāo)書費(fèi)并下載招標(biāo)文件，開標(biāo)之前需要響應(yīng)，并繳納投標(biāo)保證金；發(fā)售招標(biāo)文件和投標(biāo)人購買標(biāo)書后，如果投標(biāo)人對招標(biāo)文件提出質(zhì)疑，或招標(biāo)人要修改招標(biāo)文件，此時(shí)要在規(guī)定時(shí)間內(nèi)發(fā)布一個(gè)澄清公告。

• 開標(biāo)：開標(biāo)一般是線下進(jìn)行，代理機(jī)構(gòu)把投標(biāo)人召集到開標(biāo)室，公開宣讀投標(biāo)人關(guān)于投標(biāo)人報(bào)價(jià)、工期、質(zhì)量、工程項(xiàng)目經(jīng)理等投標(biāo)人有實(shí)質(zhì)要求的內(nèi)容，此階段拆封投標(biāo)文件，解密電子的投標(biāo)文件。

• 評標(biāo)：評標(biāo)一般是線下進(jìn)行，代理機(jī)構(gòu)把監(jiān)督人、投標(biāo)人、專家召集到評標(biāo)室，專家對投標(biāo)人資質(zhì)及投標(biāo)書打分，分為技術(shù)、商務(wù)、報(bào)價(jià)分。

• 定標(biāo)：專家對投標(biāo)人綜合打分后，做一個(gè)總體排名，排名第1即為中標(biāo)候選人，評標(biāo)結(jié)束后需要發(fā)布預(yù)中標(biāo)公告，將前3名公布，公告期間接受社會(huì)監(jiān)督，期間產(chǎn)生的疑問、質(zhì)疑需要代理機(jī)構(gòu)/招標(biāo)人澄清，澄清伴隨著澄清公告，若質(zhì)疑生效則可能廢標(biāo)和流標(biāo)（評標(biāo)成本高，一般不廢標(biāo)）。

• 合同：若預(yù)中標(biāo)發(fā)布后，質(zhì)疑期間對于預(yù)中標(biāo)候選人無影響，在預(yù)中標(biāo)發(fā)布xxx天后，招標(biāo)人需要同中標(biāo)候選人簽訂合同，同時(shí)招標(biāo)人需要退還其他沒有中標(biāo)單位的保證金。

對于整個(gè)流程的梳理和業(yè)務(wù)了解后，客戶更加關(guān)注流程的監(jiān)管預(yù)警，以此為準(zhǔn)整理一些監(jiān)管維度。

二、邏輯模型設(shè)計(jì)

邏輯模型采用上一篇博文提及的維度建模模型，雪花模型，項(xiàng)目ID、投標(biāo)人ID、招標(biāo)人ID、代理機(jī)構(gòu)ID、專家ID分別是整個(gè)招、投、開、評、定標(biāo)流程的主要參與主體，數(shù)據(jù)抽取工具使用kettle：

數(shù)據(jù)表命名規(guī)范：tb_模型層次_主題域_業(yè)務(wù)域_匯總粒度

kettle命名規(guī)范：kt_模型層次_主題域_業(yè)務(wù)域_匯總粒度

三、物理模型設(shè)計(jì)

構(gòu)建ODS-->DWD-->DWS-->ADS的分層模型，這里ODS只抽取oracle庫中源數(shù)據(jù)，不做任何清洗和變動(dòng)，DWD層開始做數(shù)據(jù)的清洗和數(shù)據(jù)工程，DWS作輕度匯總，ADS面向應(yīng)用查詢提供更上層的匯總；以項(xiàng)目和供應(yīng)商的匯總維度為例，項(xiàng)目流程是模型設(shè)計(jì)主體，供應(yīng)商是類似維度表的數(shù)據(jù)，兩者結(jié)合能夠得到業(yè)務(wù)需要的一些投/中標(biāo)相關(guān)的匯總維度（比如中標(biāo)率排行、某個(gè)項(xiàng)目的投標(biāo)人的注冊金額相關(guān)統(tǒng)計(jì)、某投標(biāo)人參與投標(biāo)相關(guān)統(tǒng)計(jì)等）。

在項(xiàng)目流程表中（定標(biāo)流程），將招標(biāo)人的編號設(shè)計(jì)在內(nèi)，定標(biāo)流程的統(tǒng)計(jì)項(xiàng)從該類ADS匯總維度出結(jié)果。

05 數(shù)據(jù)倉庫產(chǎn)品

前面講了數(shù)據(jù)倉庫的價(jià)值、構(gòu)建思路、實(shí)例，完成數(shù)據(jù)倉庫的概念、邏輯、物理模型設(shè)計(jì)后，數(shù)倉的產(chǎn)品選型也是需要考慮的部分，根據(jù)數(shù)據(jù)存儲(chǔ)量、查詢效率、并發(fā)能力可以選用MPP數(shù)倉和基于Hadoop的分布式數(shù)倉等。

一、MPP還是Hadoop？

這里繼續(xù)用之前用到的圖講解，數(shù)據(jù)倉庫的特性是處理溫?cái)?shù)據(jù)和冷數(shù)據(jù)，面向業(yè)務(wù)分析提供偏于離線分析能力，因此一般選用Hadoop+MPP數(shù)倉結(jié)合的解決方法，Hive能夠提供大批量歷史數(shù)據(jù)的存儲(chǔ)計(jì)算能力，Hbase能夠提供半結(jié)構(gòu)化文檔的快速檢索能力，MPP能夠提供強(qiáng)大高壓縮比基礎(chǔ)上的快速查詢能力。

二、MPP數(shù)倉特性

在MPP解決方案中目前我已接觸過的是vertica和GP，在teradata實(shí)習(xí)期間沒有用到td數(shù)倉。

數(shù)倉的特性是大批量的查詢和索引，少量的改查工作，MPP (Massively Parallel Processing)，即大規(guī)模并行處理數(shù)據(jù)庫的一般特性。

① 列式存儲(chǔ)意味著高壓縮比、高IO能力、快速查詢能力、智能索引（數(shù)據(jù)寫入時(shí)）。

② shared nothing意味著節(jié)點(diǎn)的相互獨(dú)立、數(shù)據(jù)的冗余備份。

③ 分布式存儲(chǔ)/計(jì)算、存儲(chǔ)/計(jì)算的高擴(kuò)展性、高安全。

MPP的架構(gòu)分為3種，GP是master/slave模式，具備統(tǒng)一的查詢?nèi)肟冢╩aster），vertica是無中心架構(gòu)，所有節(jié)點(diǎn)都提供查詢服務(wù)，gbase是存儲(chǔ)/管理雙中心架構(gòu)。

shared nothing 模式：x86機(jī)器構(gòu)建計(jì)算/存儲(chǔ)的高擴(kuò)展集群，數(shù)據(jù)拆分多份并備份。shared disk 模式：專用小型機(jī)，存儲(chǔ)1份數(shù)據(jù)。