关于数据库:分析型数据库MPP-数据库的概念技术架构与未来发展方向

4次阅读

共计 4696 个字符,预计需要花费 12 分钟才能阅读完成。

随着企业数据量的增多,为了配合企业的业务剖析、商业智能等利用场景,从而驱动数据化的商业决策,剖析型数据库诞生了。因为数据分析个别波及的数据量大,计算简单,剖析型数据库个别都是采纳大规模并行计算或者分布式计算来晋升它的数据处理能力。本篇文章将具体介绍 MPP 数据库的概念,解决的问题、典型的厂商以及它的技术架构和将来的倒退方向。

— MPP 数据库简介—

剖析型数据库是数据库的一个分支,次要设计指标是存储、治理和剖析数据,个别存储的数据类型多,工夫维度长,次要配合企业的业务剖析、商业智能等利用场景,驱动数据化的商业决策。因为数据分析个别波及的数据量大,计算简单,剖析型数据库个别都是采纳大规模并行计算或者分布式计算来晋升它的数据处理能力。

行业内从 1984 年开始推出基于多个关系数据库(Postgres 为主)组成的 MPP 数据库形式来晋升计算能力,代表性的产品有 Teradata、Netezza、Vertica 等。MPP 全称为 Massive Parallel Processing,是一种并行化的编程模型,其思维是通过治理来协调的,由多个处理单元并行处理一个程序中的不同局部,从而最终实现整个程序的计算模式。每个处理单元有本人独立的运行环境和资源。MPP 数据库中每个处理单元就是一个关系数据库,通过大规模并行的关系数据库的协同来晋升数据库可能解决的数据的量级和性能。基本上每个支流的关系数据库厂商都有本人的 MPP 版本,另外也有一些次要开发 MPP 的数据库厂商和开源的 MPP 数据库,国内近几年也涌现了不少的 MPP 数据库。

— 总体架构 —

MPP 数据库个别会蕴含多个管制节点和多个计算节点,管制节点负责计算工作的编译、执行打算的生成和计算结果的聚合,而计算节点负责计算划分到具体数据库实例的计算工作。为了更好的可扩展性,MPP 数据库个别采纳 Shared-nothing 架构,每个数据库节点之间没有数据共享。MPP 数据库个别能够通过减少数据库计算能力,此外因为多个实例,数据库总体的数据加载性能相比拟单实例数据库也有很高的晋升。

数据分片是可能实现并行化计算的外围,MPP 数据库有多种数据分片形式,次要包含 3 大类:

  • Hash 模式个别实用于事实表或大表,依据一条记录的某个字段或组合字段的 hash 值将数据扩散到某个节点上,hash 函数能够有多种形式。通过依据对给定字段的 hash 值来做数据分布,一个大表能够平均的扩散到 MPP 数据库的多个节点上,当对这个表查问时,MPP 数据库编译器能够依据 SQL 中相应的检索字段将查问疾速定位到某个或几个相干的数据库节点并将 SQL 下发,对应的数据库节点就能够疾速响应查问后果。Hash 模式在实在生产中应用的比拟多,不过它也有几个较显著的问题:一是 Hash 取值个别是跟数据库节点数量密切相关,如果数据库增加或者缩小节点后,那么曾经存在的数据的 Hash 散布就不再正确,因而须要做数据库的数据重散布,带来较大的运维老本;二是在实际操作中须要依据业务特点来设计或抉择 Hash 字段,否则容易呈现性能热点等影响数据库整体性能的问题。
  • 均匀分布模式个别实用于一些过程中的长期表,在对表的数据的长久化过程中依照均匀分布的形式在每个数据库节点上平均写入数据。这个模式下数据库的 IO 吞吐能够失去最大化利用,无论是读取还是写入,仅适宜表只做一次读写的场景。
  • 全复制模式个别适宜记录数比拟少的表,个别状况下在各个数据库节点都残缺的存储一份数据。这类表个别状况下用于大量的剖析类场景,事务类操作比拟少,因而尽管存储上有显著的节约,然而在剖析性场景下不再须要将这个表在多个数据库节点上传输或复制,从而晋升剖析性能。

基于数据分片的形式实现了数据无共享架构,因而能够通过减少数据库实例的形式来晋升数据库的性能,因而与晚期的 SMP 共享架构数据库(典型代表 Oracle RAC)相比,MPP 数据库的剖析性能要远远超出。此外数据库的整体并发响应,以及数据库的读写吞吐量,MPP 数据库都可能通过无效的业务优化达到一个很高的程度。

在 MPP 数据库的可扩展性方面,从中国信通院的相干测试来看,开源的 MPP 数据库可能反对一百节点左右的集群规模,而一些商业 MPP 数据库通过更好的软硬件联合曾经能够实现单集群达到五百个节点。— 开源 MPP 数据库 Greenplum —Greenplum 是以 PostgreSQL 为单实例的 MPP 数据库,于 2003 年诞生,在 2012 年之后演进成为 Pivotal Greenplum Database。Greenplum 用于存储、解决海量的数据,次要用于 OLAP 业务。Greenplum 采纳 MPP 架构,底层的逻辑数据库采纳 PostgreSQL,客户端反对 psql 和 ODBC。

Greenplum 集群中有三种角色组件,Master、Segment、Interconnect。数据的分片形式以及 SQL 计算的合成 / 聚合和通用的 MPP 数据库原理基本一致,在此不做赘述。

Master 是 Greenplum 数据库系统的入口,承受客户端连贯及提交的 SQL 语句,将工作负载分发给其它数据库实例(segment 实例),由它们存储和解决数据。Master 也负责长久化和查问零碎级元数据,负责认证用户连贯,接管来自客户端的 SQL 解决申请,最终汇总 Segments 的后果并返回客户端。Master Server 自身采纳主备形式来保障高可用。

Segment 是独立的 PostgreSQL 数据库,负责数据存储和剖析的具体执行,集群中的数据分布在各个 Segment 上,用户不间接与 Segment 通信,而是通过 Master 交互。每个 Segment 的数据冗余寄存在另一个 Segment 上,数据实时同步,当 Primary Segment 生效时,Mirror Segment 将主动提供服务。

Interconnect 负责不同 PostgreSQL 实例之间的通信,它默认应用 UDP 协定以提供更好的网络性能,并通过对数据包的测验来保障可靠性。

从 2019 年中国信通院组织的剖析数据库基准测试后果来看,一共有 14 个产品通过测试,其中 6 个产品是基于 Greenplum 来二次开发的,这阐明了 Greenplum 是开源 MPP 数据库的最受欢迎我的项目。除了自身开源以外,Greenplum 在以下几方面也比拟独特:

  • SQL 兼容度:因为 Greenplum 基于 PostgreSQL 内核,因而其自身放弃了关系数据库的个性以及 SQL 的兼容性,以及与 PostgreSQL 类似的平安和权限模型。此外,Greenplum 反对残缺的分布式事务操作和 MVCC,因而在事务相干操作上也兼容规范 SQL 语义。
  • 剖析性能:在 SQL 优化方面,GPORCA 优化器是基于代价的优化器的一个杰出的开源我的项目,为各种简单的剖析 SQL 有个极佳的执行打算。
  • 并行数据加载:Greenplum 提供了并行加载的技术,其自带的 gpfdist 工具可能间接和每个 Segment 交互做并行导入。
  • 开放式的架构:因为 PostgreSQL 可能反对插件化的形式来自定义数据类型、函数、存储过程等能力,Greenplum 也天然继承了这一特点,因而社区的开发者先后奉献了包含天文时空数据处理、机器学习、图剖析、文本剖析等在内的多个扩大模块,以及反对了 JSON、XML 等半结构化数据类型。

因为 Greenplum 数据库依然是基于典型的 MPP 架构,因而 MPP 数据库的规模问题(单个集群规模在 200 节点以内)、多租户资源隔离问题、落后者问题等依然存在,因而在撑持大型企业的多个业务场景时存在较大的技术挑战。因为其比拟良好的 SQL 兼容、分布式事务、优良的优化器等能力,Greenplum 能够比拟好的反对一些中小型企业的结构化数据分析工作。Greenplum 本身也在致力和云计算联合来解决多租户资源隔离问题,其曾经和多个私有云厂商单干推出云上的数据库服务。另外,Greenplum 也在更加严密的与 PostgreSQL 社区单干,踊跃的跟进其最新的性能。

— MPP 数据库的架构问题与将来倒退方向 —

MPP 数据库通过并行计算来解决了很多的数据分析的能力问题,不过也有它的架构缺点,次要包含以下几个问题:

数据的散布对业务的性能影响极大:在抉择数据分布算法以及对应的分片字段的时候,不仅要思考数据分布的平均问题,还须要思考到业务中对这个表的应用特点。如果多个业务的应用形式有显著差别,往往很难抉择一个十分好的表分片字段,因而会导致一些因为数据或业务不均匀分布或跨节点数据 shuffle 可能引起的性能问题。
落后者问题(又称 Straggler Node Problem)是 MPP 数据库的一个重要架构问题。工作负载节点(对 GPDB 而言是 Segment 节点)是齐全对称的,数据平均的存储在这些节点,处理过程中每个节点(即该节点上的 Executor)应用本地的 CPU、内存和磁盘等资源实现本地的数据加工。当某个节点呈现问题导致速度比其余节点慢时,该节点会成为 Straggler。此时,无论集群规模多大,批处理的整体执行速度都由 Straggler 决定,其余节点上的工作执行结束后则进入闲暇状态期待 Straggler,而无奈分担其工作,如下图所示 Executor 7 即为落后者并最终拖慢了整个集群。当集群规模达到肯定水平时,故障会频繁呈现使 straggler 成为一个惯例问题。

集群规模问题:因为 MPP 的“齐全对称性”,即当查问开始执行时,每个节点都在并行执行完全相同的工作,这意味着 MPP 反对的并发数和集群的节点数齐全无关。在大数据时代,对于联机查问的并发能力要求减少十分迅速,也极大的挑战了 MPP 架构自身。此外,MPP 架构中的 Master 节点承当了肯定的工作负载,所有联机查问的数据流都要通过该节点,这样 Master 也存在肯定的性能瓶颈。因而很多 MPP 数据库在集群规模上是存在肯定限度的。

多租户资源隔离问题是 MPP 数据库一个十分难解决的一个架构问题。因为一个企业的 MPP 数据库个别撑持多个业务或多个租户,如果某个业务的局部 SQL 剖析在数据库节点 Node 1 上产生了热点并占用了该节点绝大部分的资源,从而拖慢了所有的可能应用 Node 1 的其余租户或业务,导致整体业务服务能力好转。从咱们对行业的一些大型企业客户的调研后果看,这个问题是十分致命的问题,只能通过运维的伎俩来检测并敞开相似的热点 SQL 来缓解。

更好的撑持 AI 程序处理半结构化或非结构化数据是 MPP 数据库的一个重要挑战,尤其是在人工智能相干的需要暴发后,NLP、智能辨认等技术都须要无效的半结构化或非结构化数据的存储、检索和计算需要,而这些都不是关系数据库善于的能力。

随着硬件技术的疾速倒退,尤其是 SSD 和网络性能的大幅度晋升,MPP 数据库厂商都开始基于这些新硬件技术来解决以后的软件架构问题,如采纳更高速的网络来晋升总体的可扩展性,解决集群规模存在下限的问题。另外局部 MPP 数据库从新设计其执行模式,调整其计算架构同时反对 MPP 和 DAG 模式,通过更加的执行打算和 Lazy Evaluation 形式来解决常见的“落后者”问题。此外,近几年 MPP 数据库厂商都在推动存算拆散架构,让底层能够间接依赖云存储等形式,从而实现云化服务,并以此来实现多租户隔离等治理能力。

— 小结—
本文介绍了剖析型数据库 MPP 数据库,它通过大规模并行的关系数据库的协同来晋升数据库可能解决的数据的量级和性能。那么,剖析型数据库的另外一个倒退方向是以分布式技术来代替 MPP 的并行计算,一方面比 MPP 有更好的可扩展性,另一方面能够解决 MPP 数据库的几个要害架构问题,下篇咱们将介绍分布式剖析型数据库。

正文完
 0