大数据时代，MPP仍是中流砥柱？
大数据从业者一定知道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架构，尽管它允许用户自定义数据分布方式以提高查询性能，但它的缺点也显而易见：
-
1. 集群规模受限。
架构存在“木桶效应”，单机故障会导致性能严重下降：速度变慢，或者不稳定。无论集群规模多大，批处理的整体执行速度都由Straggler决定，其他节点上的任务执行完毕后则进入空闲状态等待Straggler，而无法分担其工作。导致节点处理速度降低的原因多数是磁盘等硬件损坏，考虑到磁盘本身的一定故障率当集群规模达到一定程度时，故障会频繁出现使Straggler成为一个常规问题。因此集群规模不能太大，从而使得支持数据体量有限，很难超过 PB 级别。在数据量大的时候用户需要分库分表，使用多个集群。 -
2. 并发性能不高。
查询系统的设计，主要目的是提供给用户使用的，能支持的并发数越高越好。由于MPP的“完全对称性”，即当查询开始执行时，每个节点都在并行的执行完全相同的任务，这意味着MPP支持的并发数和集群的节点数完全无关。对单个查询来说，调用整个系统的能力会使查询结果的获取比较迅速，但同时带来较大的性能消耗，使得整个系统支持的并发数量有限，从目前企业的实际使用的经验来说，一般只能支持到几十到百左右的并发能力。并发受限也是用户使用MPP需要分库分表的一大原因。 -
3. 无法动态适应业务发展。
MPP存算耦合的架构，不太容易满足云时代不同场景下的不同workload需求。由于其采用无共享的Shared Nothing架构，计算存储共享一个节点，每个节点有自己独立的CPU、内存、磁盘资源，互相不共享。需求动态发展，不易做好规划。在企业需要进行数据导入类的任务时，往往需要消耗比较大的IO、网络带宽，而CPU资源的使用率较低；在进行复杂查询类任务时，对CPU的资源消耗则变得非常大。因此在选择资源规格时，需要结合不同的workload分别做不同的类型选择，MPP很难满足这些需求。随着业务不停在发展，workload也不停在变化，企业也比较难提前做好规划。 -
4. 扩容易影响业务连续性。
在扩缩容的增删节点操作时，数据重分布就成为一个令人头疼的问题，它的整个操作过程会产生大量的 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年代的数据库，到数据仓库、数据湖，到现在的湖仓一体，新产品总是在性能、功能上去解决以前从业者在业务上的痛点，我们可以说湖仓一体是数据库发展到云原生时代的必然产物。通过虚拟计算集群技术在数十万节点的超大规模集群上实现高并发，保障事务支持，提供实时能力，一份数据再无数据孤岛，新一代湖仓一体架构将是未来的发展趋势，给行业带来更大的影响。