大數(shù)據(jù)從業(yè)者一定知道MPP數(shù)據(jù)庫。什么？你還不知道什么是MPP！

在說清楚這個問題之前，我們來聊聊常見的DBMS架構。

數(shù)據(jù)庫的常見架構模式

DBMS的系統(tǒng)架構指定CPU可以直接訪問哪些共享資源，它影響著CPU之間的協(xié)調方式以及它們在數(shù)據(jù)庫中檢索和存儲對象的位置，常見的四種架構包括：

• Shared Everything

單節(jié)點DBMS使用的就是所謂的shared everything架構，使用本地內存和存儲。

• Shared Memory

在Shared Memory系統(tǒng)中，多個CPU可以共享內存，同時也共享存儲。

• Shared Disk

在Shared Disk架構中，所有節(jié)點都有自己的專用內存，并且都可以通過網(wǎng)絡直接讀寫共享存儲。這種架構常見于云原生數(shù)據(jù)庫，將計算層和存儲層結構，可以分別擴縮容。

• Shared Nothing

在Shared Nothing架構中，每個節(jié)點都有自己的CPU、內存和磁盤，節(jié)點間僅通過網(wǎng)絡通信。增加新節(jié)點是，DBMS必須將數(shù)據(jù)物理地移動到新節(jié)點，因此在這種架構中增加容量更加困難，靈活性較差。然而，其優(yōu)點是它可以大規(guī)模并行，并優(yōu)化本地讀從而實現(xiàn)不錯的性能。

那什么是MPP呢？

傳統(tǒng)關系型數(shù)據(jù)庫的技術架構，尤其是 OLTP 數(shù)據(jù)庫在海量數(shù)據(jù)的存儲、查閱以及分析方面出現(xiàn)了明顯的性能瓶頸。隨著分布式技術的產(chǎn)生和發(fā)展，出現(xiàn)了以 Teradata 為代表的基于專有硬件的MPP數(shù)據(jù)庫，以及 Greenplum 和 Vertica 等基于普通服務器的 MPP 數(shù)據(jù)庫。

MPP即大規(guī)模并行處理（Massively Parallel Processing），MPP數(shù)據(jù)庫是針對分析工作負載進行了優(yōu)化的數(shù)據(jù)庫，可以聚合和處理大型數(shù)據(jù)集。MPP數(shù)據(jù)庫往往是列式的，因此MPP數(shù)據(jù)庫通常將每一列存儲為一個對象，而不是將表中的每一行存儲為一個對象。這種體系結構使復雜的分析查詢可以更快，更有效地處理。

這些分析數(shù)據(jù)庫將其數(shù)據(jù)集分布在許多節(jié)點上以處理大量數(shù)據(jù)，這些節(jié)點都有獨立的磁盤存儲系統(tǒng)和內存系統(tǒng)，從而使每個節(jié)點都可以執(zhí)行查詢的一部分。業(yè)務數(shù)據(jù)根據(jù)數(shù)據(jù)庫模型和應用特點劃分到各個節(jié)點上，每臺數(shù)據(jù)節(jié)點通過專用網(wǎng)絡或者商業(yè)通用網(wǎng)絡互相連接，彼此協(xié)同計算，作為整體提供數(shù)據(jù)庫服務。結合前文來看，我們所說的MPP數(shù)據(jù)庫即采用了Shared Nothing架構。

大數(shù)據(jù)時代，MPP仍是中流砥柱？

針對于傳統(tǒng)數(shù)據(jù)庫，MPP數(shù)據(jù)庫集群有可伸縮性、高可用、高性能、優(yōu)秀的性價比、資源共享等優(yōu)勢，它的誕生解決了用戶“數(shù)據(jù)多，很難在一臺物理機器上分析數(shù)據(jù)”的難題，在21世紀的前十年，大量企業(yè)開始采用MPP驅動的新型數(shù)據(jù)庫系統(tǒng)，MPP解決了單個SQL數(shù)據(jù)庫不能存放海量數(shù)據(jù)的問題，分析MPP數(shù)據(jù)庫的激增和成本下降也為數(shù)據(jù)驅動型組織提供了巨大的機會來運營和分析比以往更大的數(shù)據(jù)集，但與此同時，數(shù)據(jù)的快速增長也為體系結構帶來了額外的復雜性，以Greenplum為例，它采用了Shared Nothing的MPP架構，盡管它允許用戶自定義數(shù)據(jù)分布方式以提高查詢性能，但它的缺點也顯而易見：

1. 集群規(guī)模受限。
   架構存在“木桶效應”，單機故障會導致性能嚴重下降：速度變慢，或者不穩(wěn)定。無論集群規(guī)模多大，批處理的整體執(zhí)行速度都由Straggler決定，其他節(jié)點上的任務執(zhí)行完畢后則進入空閑狀態(tài)等待Straggler，而無法分擔其工作。導致節(jié)點處理速度降低的原因多數(shù)是磁盤等硬件損壞，考慮到磁盤本身的一定故障率當集群規(guī)模達到一定程度時，故障會頻繁出現(xiàn)使Straggler成為一個常規(guī)問題。因此集群規(guī)模不能太大，從而使得支持數(shù)據(jù)體量有限，很難超過 PB 級別。在數(shù)據(jù)量大的時候用戶需要分庫分表，使用多個集群。

2. 并發(fā)性能不高。
   查詢系統(tǒng)的設計，主要目的是提供給用戶使用的，能支持的并發(fā)數(shù)越高越好。由于MPP的“完全對稱性”，即當查詢開始執(zhí)行時，每個節(jié)點都在并行的執(zhí)行完全相同的任務，這意味著MPP支持的并發(fā)數(shù)和集群的節(jié)點數(shù)完全無關。對單個查詢來說，調用整個系統(tǒng)的能力會使查詢結果的獲取比較迅速，但同時帶來較大的性能消耗，使得整個系統(tǒng)支持的并發(fā)數(shù)量有限，從目前企業(yè)的實際使用的經(jīng)驗來說，一般只能支持到幾十到百左右的并發(fā)能力。并發(fā)受限也是用戶使用MPP需要分庫分表的一大原因。

3. 無法動態(tài)適應業(yè)務發(fā)展。
   MPP存算耦合的架構，不太容易滿足云時代不同場景下的不同workload需求。由于其采用無共享的Shared Nothing架構，計算存儲共享一個節(jié)點，每個節(jié)點有自己獨立的CPU、內存、磁盤資源，互相不共享。需求動態(tài)發(fā)展，不易做好規(guī)劃。在企業(yè)需要進行數(shù)據(jù)導入類的任務時，往往需要消耗比較大的IO、網(wǎng)絡帶寬，而CPU資源的使用率較低；在進行復雜查詢類任務時，對CPU的資源消耗則變得非常大。因此在選擇資源規(guī)格時，需要結合不同的workload分別做不同的類型選擇，MPP很難滿足這些需求。隨著業(yè)務不停在發(fā)展，workload也不停在變化，企業(yè)也比較難提前做好規(guī)劃。

4. 擴容易影響業(yè)務連續(xù)性。
   在擴縮容的增刪節(jié)點操作時，數(shù)據(jù)重分布就成為一個令人頭疼的問題，它的整個操作過程會產(chǎn)生大量的 I/O 請求，引起正常的業(yè)務處理速度下降，影響客戶的正常查詢需求。隨著用戶數(shù)據(jù)規(guī)模增長，數(shù)據(jù)重分布過程少則需要幾小時，多則需要幾天，可能會對業(yè)務連續(xù)性造成一定影響。

典型 MPP 架構圖

所以，MPP數(shù)據(jù)庫在集群規(guī)模上是有限制的，它所支持的應用主要還是適合小集群、低并發(fā)的場景。

企業(yè)有沒有更好的選擇？

Hadoop + MPP ：湖倉分體模式

由于新興業(yè)務的不斷產(chǎn)生，而MPP數(shù)據(jù)庫缺乏現(xiàn)代分析和數(shù)據(jù)科學所需的靈活性，這時候另一門新技術——Hadoop誕生，并快速的占領了一些市場。Spark Streaming、Flink 等實時數(shù)據(jù)處理技術也讓大數(shù)據(jù)平臺具備了實時數(shù)據(jù)處理能力。雖然 Hadoop 邏輯上實現(xiàn)了計算和存儲分離，但是其物理部署架構依然強調在每一個節(jié)點同時部署計算節(jié)點和存儲節(jié)點，通過將計算置于存儲所在的位置，利用數(shù)據(jù)本地性提升計算性能。

隨著 Hadoop 大數(shù)據(jù)平臺建設逐步推廣，企業(yè)嘗試將 Hadoop 用于一些非核心場景之后，發(fā)現(xiàn) Hadoop 不僅性能和并發(fā)支持有限，而且事務支持弱，交付、運維成本高，事實證明Hadoop 無法替代核心數(shù)倉，并逐漸形成了其特殊的定位——數(shù)據(jù)湖。數(shù)據(jù)湖對全量的、各種類型的數(shù)據(jù)進行存儲和挖掘，為數(shù)據(jù)科學家提供基于任意原始數(shù)據(jù)開發(fā)應用的敏捷性，而不必局限于數(shù)倉的數(shù)據(jù)，這是數(shù)據(jù)湖優(yōu)于傳統(tǒng)數(shù)倉之處。但數(shù)據(jù)湖卻始終無法滿足用戶在性能、事務等方面的要求，然后很多企業(yè)開始考慮數(shù)據(jù)湖和數(shù)據(jù)倉庫互補的方式。即在構建數(shù)據(jù)湖的同時，也使用MPP，湖倉各自獨立部署，數(shù)據(jù)通過ETL的方式打通。

這種業(yè)內常說的 Hadoop+MPP 模式，我們稱之為"湖倉分體"模式。它讓湖和倉有很好的技術特性互補，但是它也會產(chǎn)生嚴重的數(shù)據(jù)孤島問題：同一份數(shù)據(jù)在多個集群冗余存儲，分體模式下的湖和倉各自形成數(shù)據(jù)孤島；數(shù)據(jù)達到PB 級別時， Hadoop 和 MPP 集群規(guī)模受限，Hadoop和MPP本身也需要拆成多個集群；在面對高并發(fā)數(shù)據(jù)查詢時，易造成業(yè)務應用崩潰。另外，湖+倉帶來的復雜的實施和運維問題更讓從業(yè)者頭疼不已。

理解了前面的描述，關于企業(yè)大數(shù)據(jù)處理的需求也就顯而易見了：實現(xiàn)數(shù)據(jù)和查詢層面形成一體化架構，徹底解決實時性和并發(fā)度，以及集群規(guī)模受限、非結構化數(shù)據(jù)無法整合、建模路徑冗長、數(shù)據(jù)一致性弱、性能瓶頸等問題，有效降低 IT 運維成本和數(shù)據(jù)管理的技術門檻。

存算分離架構 ：湖倉一體模式

為了保證存儲和計算可以獨立的彈性擴展和伸縮，數(shù)據(jù)平臺的設計出現(xiàn)了一個嶄新的架構，即存算分離架構。顯然，傳統(tǒng) MPP 和 Hadoop 都不適應這樣的要求。MPP 數(shù)據(jù)庫存算耦合，而 Hadoop 不得不通過計算和存儲部署在同一物理集群拉近計算與數(shù)據(jù)的距離，僅在同一集群下構成邏輯存算分離。

要真正的解決業(yè)務的痛點，選擇企業(yè)適合的湖倉產(chǎn)品，我們可以按照ANCHOR 標準來選型。ANCHOR 的6個首字母分別代表六大特性，：All Data Types（支持多類型數(shù)據(jù)）、Native on Cloud（云原生）、Consistency（數(shù)據(jù)一致性）、High Concurrency（超高并發(fā)）、One Copy of Data（一份數(shù)據(jù)）、Real-Time（實時T+0）。

國外的Snowflake、Databricks 和國內的OushuDB 就是這一代產(chǎn)品的突出代表，它們突破了傳統(tǒng) MPP 和 Hadoop 的局限性，率先實現(xiàn)了存算完全分離，計算和存儲可部署在不同物理集群，并通過虛擬計算集群技術實現(xiàn)了高并發(fā)，同時保障事務支持，成為湖倉一體實現(xiàn)的關鍵技術。

以 OushuDB 為例，實現(xiàn)了存算分離的云原生架構，并通過虛擬計算集群技術在數(shù)十萬節(jié)點的超大規(guī)模集群上實現(xiàn)了高并發(fā)，保障事務支持，提供實時能力，保證一份數(shù)據(jù)再無數(shù)據(jù)孤島。同時，偶數(shù)科技通過首創(chuàng)的Omega架構（Kappa架構的下一代）保障了湖倉一體的實時性，形成了具備全實時能力的實時湖倉一體。

隨著需求的演進，從上世紀60年代的數(shù)據(jù)庫，到數(shù)據(jù)倉庫、數(shù)據(jù)湖，到現(xiàn)在的湖倉一體，新產(chǎn)品總是在性能、功能上去解決以前從業(yè)者在業(yè)務上的痛點，我們可以說湖倉一體是數(shù)據(jù)庫發(fā)展到云原生時代的必然產(chǎn)物。通過虛擬計算集群技術在數(shù)十萬節(jié)點的超大規(guī)模集群上實現(xiàn)高并發(fā)，保障事務支持，提供實時能力，一份數(shù)據(jù)再無數(shù)據(jù)孤島，新一代湖倉一體架構將是未來的發(fā)展趨勢，給行業(yè)帶來更大的影響。