假冒中国建设银行的网站,营销型网站重要性,自媒体时代做网站有前途吗,get写作网站随着企业数据量的增多#xff0c;为了配合企业的业务分析、商业智能等应用场景#xff0c;从而驱动数据化的商业决策#xff0c;分析型数据库诞生了。由于数据分析一般涉及的数据量大#xff0c;计算复杂#xff0c;分析型数据库一般都是采用大规模并行计算或者分布式计算…随着企业数据量的增多为了配合企业的业务分析、商业智能等应用场景从而驱动数据化的商业决策分析型数据库诞生了。由于数据分析一般涉及的数据量大计算复杂分析型数据库一般都是采用大规模并行计算或者分布式计算来提升它的数据处理能力。本篇文章将详细介绍 MPP 数据库的概念解决的问题、典型的厂商以及它的技术架构和未来的发展方向。 — MPP数据库简介—
分析型数据库是数据库的一个分支主要设计目标是存储、管理和分析数据一般存储的数据类型多时间维度长主要配合企业的业务分析、商业智能等应用场景驱动数据化的商业决策。由于数据分析一般涉及的数据量大计算复杂分析型数据库一般都是采用大规模并行计算或者分布式计算来提升它的数据处理能力。行业内从1984年开始推出基于多个关系数据库Postgres为主组成的MPP数据库方式来提升计算能力代表性的产品有Teradata、Netezza、Vertica等。MPP全称为Massive Parallel Processing是一种并行化的编程模型其思想是通过管理来协调的由多个处理单元并行处理一个程序中的不同部分从而最终完成整个程序的计算模式。每个处理单元有自己独立的运行环境和资源。MPP数据库中每个处理单元就是一个关系数据库通过大规模并行的关系数据库的协同来提升数据库能够处理的数据的量级和性能。基本上每个主流的关系数据库厂商都有自己的MPP版本另外也有一些主要开发MPP的数据库厂商和开源的MPP数据库国内近几年也涌现了不少的MPP数据库。
厂商数据库名称介绍TeradataTeradata Database1984年推出的首个MPP数据库采用列式存储加速分析性能以一体机方式交付HPVertica图灵奖得主Michael Stonebraker创立的首个真正意义上采用列式存储的MPP数据库可运行在标准硬件上PivotalGreenplum开源的MPP数据库数据库实例采用PostgreSQL可运行在标准硬件上华为GaussDB基于Postgres-XC深度自研的分析型数据库可运行在标准硬件上可扩展性较好 — 总体架构 —
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数据库的几个关键架构问题下篇我们将介绍分布式分析型数据库。
