2022 年了，MPP 还是当今数据库主流架构吗？( 二 ) _数据库

无法动态适应业务发展。
MPP存算耦合的架构，不太容易满足云时代不同场景下的不同workload需求。由于其采用无共享的Shared Nothing架构，计算存储共享一个节点，每个节点有自己独立的CPU、内存、磁盘资源，互相不共享。需求动态发展，不易做好规划。在企业需要进行数据导入类的任务时，往往需要消耗比较大的IO、网络带宽，而CPU资源的使用率较低；在进行复杂查询类任务时，对CPU的资源消耗则变得非常大。因此在选择资源规格时，需要结合不同的workload分别做不同的类型选择，MPP很难满足这些需求。随着业务不停在发展，workload也不停在变化，企业也比较难提前做好规划。

扩容易影响业务连续性。
在扩缩容的增删节点操作时，数据重分布就成为一个令人头疼的问题，它的整个操作过程会产生大量的 I/O 请求，引起正常的业务处理速度下降，影响客户的正常查询需求。随着用户数据规模增长，数据重分布过程少则需要几小时，多则需要几天，可能会对业务连续性造成一定影响。

文章插图
典型 MPP 架构图

所以，MPP数据库在集群规模上是有限制的，它所支持的应用主要还是适合小集群、低并发的场景。

企业有没有更好的选择？
【2022 年了，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）。