大數據從業者一定知道MPP數據庫。什么？你還不知道什么是MPP！

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

數據庫的常見架構模式

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

Shared Everything

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

Shared Memory

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

Shared Disk

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

Shared Nothing

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

那什么是MPP呢？

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

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

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

大數據時代，MPP仍是中流砥柱？

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

集群規模受限。
架構存在“木桶效應”，單機故障會導致性能嚴重下降：速度變慢，或者不穩定。無論集群規模多大，批處理的整體執行速度都由Straggler決定，其他節點上的任務執行完畢后則進入空閑狀態等待Straggler，而無法分擔其工作。導致節點處理速度降低的原因多數是磁盤等硬件損壞，考慮到磁盤本身的一定故障率當集群規模達到一定程度時，故障會頻繁出現使Straggler成為一個常規問題。因此集群規模不能太大，從而使得支持數據體量有限，很難超過 PB 級別。在數據量大的時候用戶需要分庫分表，使用多個集群。
并發性能不高。
查詢系統的設計，主要目的是提供給用戶使用的，能支持的并發數越高越好。由于MPP的“完全對稱性”，即當查詢開始執行時，每個節點都在并行的執行完全相同的任務，這意味著MPP支持的并發數和集群的節點數完全無關。對單個查詢來說，調用整個系統的能力會使查詢結果的獲取比較迅速，但同時帶來較大的性能消耗，使得整個系統支持的并發數量有限，從目前企業的實際使用的經驗來說，一般只能支持到幾十到百左右的并發能力。并發受限也是用戶使用MPP需要分庫分表的一大原因。
無法動態適應業務發展。
MPP存算耦合的架構，不太容易滿足云時代不同場景下的不同workload需求。由于其采用無共享的Shared Nothing架構，計算存儲共享一個節點，每個節點有自己獨立的CPU、內存、磁盤資源，互相不共享。需求動態發展，不易做好規劃。在企業需要進行數據導入類的任務時，往往需要消耗比較大的IO、網絡帶寬，而CPU資源的使用率較低；在進行復雜查詢類任務時，對CPU的資源消耗則變得非常大。因此在選擇資源規格時，需要結合不同的workload分別做不同的類型選擇，MPP很難滿足這些需求。隨著業務不停在發展，workload也不停在變化，企業也比較難提前做好規劃。
擴容易影響業務連續性。
在擴縮容的增刪節點操作時，數據重分布就成為一個令人頭疼的問題，它的整個操作過程會產生大量的 I/O 請求，引起正常的業務處理速度下降，影響客戶的正常查詢需求。隨著用戶數據規模增長，數據重分布過程少則需要幾小時，多則需要幾天，可能會對業務連續性造成一定影響。

典型 MPP 架構圖

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

企業有沒有更好的選擇？

Hadoop + MPP ：湖倉分體模式

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

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

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

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

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

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

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

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

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

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