网站开发项目发展现状,代理小企业网站建设,wordpress新写文章会卡死,吴江网站优化简介#xff1a;在3月2日的阿里云开源 PolarDB 企业级架构发布会上#xff0c;阿里云 PolarDB 内核技术专家严华带来了主题为《PolarDB HTAP详解》的精彩演讲。在PolarDB存储计算分离架构的基础上#xff0c;我们研发了基于共享存储的MPP分布式执行引擎#xff0c;解决了单…简介在3月2日的阿里云开源 PolarDB 企业级架构发布会上阿里云 PolarDB 内核技术专家严华带来了主题为《PolarDB HTAP详解》的精彩演讲。在PolarDB存储计算分离架构的基础上我们研发了基于共享存储的MPP分布式执行引擎解决了单条SQL执行时无法利用其它节点计算资源、无法发挥共享存储池的IO大带宽的问题同时提供了弹性计算弹性扩展的保障使得PolarDB初步具备了 HTAP 的能力。本议题主要介绍PolarDB HTAP的功能特性和关键技术。 在3月2日的阿里云开源 PolarDB 企业级架构发布会上阿里云 PolarDB 内核技术专家严华带来了主题为《PolarDB HTAP详解》的精彩演讲。在PolarDB存储计算分离架构的基础上我们研发了基于共享存储的MPP分布式执行引擎解决了单条SQL执行时无法利用其它节点计算资源、无法发挥共享存储池的IO大带宽的问题同时提供了弹性计算弹性扩展的保障使得PolarDB初步具备了 HTAP 的能力。本议题主要介绍PolarDB HTAP的功能特性和关键技术。 直播回顾视频开源PolarDB企业级架构重磅发布-阿里云 PDF下载 文件下载-阿里云开发者社区 以下根据发布会演讲视频内容整理 一、背景 很多PolarDB 的用户都有 TP 和 AP 共用的需求他们白天使用 PolarDB处理高并发的 TP 请求晚上 TP 流量下降、机器空闲后继续使用 PolarDB 进行 AP 的报表分析。但是即使这样依然没有最大化利用空闲机器资源。 因为原生的 PolarDB PG 系统在处理复杂的 AP 查询时会遇到两大挑战首先单个 SQL 在原生 PG 执行引擎下只能在单个节点上执行无论是单机串行还是单机并行都无法利用其他节点的 CPU memory 等计算资源只能纵向 Scale Up不能横向 Scale Out 其次PolarDB 底层是存储池理论上 IO 吞吐是无限大的。而单个 SQL 在原生 PG 执行引擎下只能在单个节点上执行受限于单个节点的 CPU 和 memory 的瓶颈无法充分发挥存储侧大 IO 带宽的优势。 为了解决用户实际使用中的痛点PolarDB 决定做 HTAP。 当前业界HTAP的解决方案主要有以下三种 ① TP 和 AP 在存储计算上都分离能够实现TP和AP完全隔离互不影响。但实际使用中会存在一些问题。首先TP的数据需要导入到AP系统中会存在一定的延迟导致时效性不高其次需要增加冗余的 AP 系统总成本也会增加第三增加了一套 AP 系统后运维难度也会增加。 ② TP 和 AP 在存储计算上都共享这样可以做到成本最小化资源利用最大化但仍然存在两点问题。首先由于计算共享 AP 查询和 TP 查询同时运行时或多或少会存在相互影响其次当 AP 查询比重增大时系统需要扩计算节点存储因此需要重分布导致无法快速弹性Scale Out。 ③ TP 和 AP 在存储上共享在计算上分离。PolarDB 是存储计算分离架构因此天然支持此方案。 二、原理 基于 PolarDB 存储计算分离的架构。我们研发了分布式 MPP 执行引擎提供了跨机并行执行、弹性计算弹性扩展的保证使得 PolarDB 初步具备了 HTAP 的能力。 上图右是 PolarDB HTAP 的架构图。底层是池化了的共享存储TP 和 AP 共享一套存储数据在降低成本的同时能提供毫秒级的数据新鲜度还提供了快速扩容计算节点的能力这也是 PolarDB HTAP 第一个特性。 上层是读写分离的计算节点。PolarDB 具备两套执行引擎来处理 HTAP 查询其中单机执行引擎在读写节点上进行处理高并发的 TP 查询分布式 MPP 执行引擎在只读节点上处理复杂的 AP 查询TP和 AP 的查询天然进行了物理隔离解耦了 TP 和 AP 的计算环境杜绝了 CPU 和 memory 的相互影响这是 PolarDB HTAP 的第二大特性TP/AP物理隔离 。 PolarDB HTAP 的第三大特性是 Serverless 弹性扩展消除了传统 MPP 数据库 coordinate 的单点限制可以在任何一个只读节点上发起 MPP可以弹性调整 MPP 节点范围以及单机并行度同时支持 Scale Out、Scale Up 。此处的弹性调整是及时生效的并不需要进行数据重分布。 消除倾斜是 PolarDB HTAP 的第四大特性。PolarDB HTAP 在充分考虑 PG BufferPool 亲和性的基础上能够消除数据倾斜和计算倾斜实现能者多劳的调度。 PolarDB HTAP 原理的核心是分布式 MPP 执行引擎它是典型的火山引擎。 AB 两张表先做 join 再做聚合输出这也是 PG 单机执行引擎的执行流程。 在传统的 MPP 执行引擎中数据被打散到不同的节点上不同节点上的数据可能具有不同的分布属性比如哈希分布、随机分布、复制表分布等。传统的 MPP 执行引擎会针对不同表的数据分布特点在计划中插入算子来保证上层算子对数据的分布特征无感知。 PolarDB 是共享存储架构底层共享的数据可以被各个计算节点全量访问。如果使用传统的 MPP 执行引擎每个 Worker 都会扫描全量数据会产生重复的数据同时也没有起到扫描时分治加速的效果并不算真正意义上的 MPP 引擎。 因此在在 PolarDB 分布式 MPP 执行引擎中我们借鉴了火山模型论文的思想对所有扫描算子进行并发处理引入了PxScan算子来屏蔽共享存储。PxScan算子将 share-storage 的数据映射为 share-nothing 的数据通过 Worker之间的协调将目标表划分为多个虚拟分区数据块每个 Worker 扫描各自虚拟分区数据块从而实现了跨机分布式并行scan。 PxScan算子扫描出来的数据会通过 shuffle 算子来重分布再在每个 Worker 上如同执行单机一样按照火山模型来执行。 以上就是PolarDB 分布式 MPP 执行引擎的核心shuffle 算子屏蔽数据分布PxScan 算子屏蔽共享存储。 传统 MPP 只能在指定节点发起 MPP 查询因此每个节点上都只能有单个 Worker 扫描一张表。为了支持云原生下 serverless弹性扩展的需求我们引入了分布式事务一致性保证。 首先任意选择一个节点作为 coordinator节点它的 ReadLSN 会作为约定的 LSN从所有 MPP 节点的快照版本号中选择最小的版本号作为全局约定的快照版本号。通过 LSN 的等待回放和 Global Snaphot 同步机制确保在任何一个节点发起 MPP 查询时数据和快照均能达到一致可用的状态。 为了达到 serverless 的弹性扩展我们还基于共享存储的特点将 coordinator节点全链路上各个模块需要的外部依赖都放至共享存储上。各个 Worker 节点运行时需要的参数也会通过控制链路从 coordinator 节点同步过来从而使 coordinator 节点和 Worker 节点全链路无状态化。 基于以上两点设计PolarDB的弹性扩展具备了以下几大优势 ① 任何节点都可以成为coordinator 节点解决了传统 MPP 数据库 coordinator 的节点单点问题。 ② PolarDB 可以横向 Scale Out 算力弹性扩展也可以纵向 Scale Up 单机并行度弹性扩展并且弹性扩展是及时生效的不需要重分布数据。 ③ 允许业务有更多的弹性调度策略不同的业务阈可以运行在不同的节点集合上。如上图右侧所示业务域 SQL 1 可以选择 RO1 和 RO2 节点来执行 AP 查询业务域 SQL 2 可以选择使用RO3 和 RO4 节点来执行 AP 查询。两个业务域使用的计算节点可以实现弹性调度。 倾斜是传统 MPP 固有的问题其原因主要是数据分布倾斜和数据计算倾斜。数据分布倾斜通常由数据打散不均衡导致在 PG 中还会由于大对象 toast 表存储引入一些不可避免的数据分布不均衡问题计算倾斜通常由于不同节点上并发的事务、 buffer 、网络、 IO 抖动导致。倾斜会导致传统 MPP 在执行时的木桶效应。 PolarDB 设计实现了自适应扫描机制。如上图右所示采用coordinator节点来协调Worker节点询问的工作模式。在扫描数据时coordinator节点会在内存中创建一个任务管理器根据扫描任务对 Worker 节点进行调度。coordinator节点内部分为两个线程data线程主要负责服务数据链路、收集汇总元组control线程负责服务控制链路、控制每一个扫描算子的扫描进度。 扫描块的 Worker 能够扫描多个数据块实现能者多劳。比如上图中 RO1 与RO3 的 Worker 都各自扫描了4个数据块 ROI2由于计算倾斜可以扫描更多数据块因此它最终扫描了 6 个数据块。 PolarDB 自适应扫描机制还考虑了 PG BufferPool 的亲和性保证每个 Worker 尽量扫描固定的数据块从而最大化命中BufferPool中的缓存降低 IO 开销。 三、功能特性 经过持续迭代的研发目前 PolarDB HTAP 在支持 Parallel Query 上支持的功能特性主要有五大部分 ① 基础算子全支持。不仅包括 scan 类算子、Join类、聚合类还包括 SubqueryScan、HashJoin 等。 ② 共享存储算子优化。包括 shuffle 算子共享、ShareSeqScan 共享、 ShareIndexScan等。其中ShareSeqScan 共享、 ShareIndexScan共享是指在大表 join 小表时小表采用类似于复制表的机制来减少广播开销进而提升性能。 ③ 分区表支持。不仅包括对Hash/Range/List三种分区方式的完整支持还包括对多级分区静态裁剪、分区动态裁剪的支持。除此之外PolarDB 分布式 MPP 执行引擎还支持分区表的Partition Wise Join。 ④ 并行度弹性控制。包括全局级别、表级别、会话级别、查询级别的并行度控制。 ⑤ Serverless 弹性扩展。不仅包括任意节点发起 MPP、MPP 节点范围内的任意组合还包括集群拓扑信息的自动维护以及支持共享存储模式、主备库模式、三节点模式。 既然是 HTAP 则必然不能缺少对 DML 的 MPP 支持。基于 PolarDB读写分离架构和 HTAP serverless 弹性扩展的设计 PolarDB parallel DML支持一写多读、多写多读两种特性。一写多读是指在 RO节点上有多个读 Worker 但在 RW节点上只有一个写 Worker 多写多读是指在 RO 节点上有多个读 Worker 在 RW节点上也有多个写 Worker 。多写多读场景下读的并发度和写的并发度是完全解耦的。不同的特性适用不同的场景用户可以根据自己的业务特点来选择不同的PDML功能特性。 PolarDB 分布式 MPP执行引擎不仅可以用于 query 和 DML 还可以用于索引构建加速。ALTP业务中有大量的索引而索引创建过程大约有 80% 的时间消耗在排序和构建索引页上20%消耗在写索引页上。如右上图 PolarDB 利用 RO 节点进行数据分布式 MPP 加速排序采用流程化的技术来构建索引页采用批量写入技术来提高索引页的写入速度。 目前构建索引加速这一特性中PolarDB 已经对常用 B 树索引的普通创建以及 B 树索引的在线创建两种功能进行了支持。 通过上图与PolarDB原生的单机并行进行对比可以看出分布式MPP的优势所在。我们使用线上 PolarDB 16g 和 256g 内存的 16 个 RO 实例搭建了 1 TB 的 TPCH 环境进行测试对比。相比单机并行分布式 MPP 并行充分利用了所有 RO 节点的计算资源和底层共享存储 RO 带宽从根本上解决了前文提到的 HTAP 挑战。在 TPCH 22 条 SQL 中有 3 条 SQL 加速了 60 多倍19条 SQL 加速了 10 多倍平均加速 23 倍。此外我们也测试了弹性扩大给计算资源带来的变化。通过增加 CPU 总核数从 16 核增加到 128 核 TPCH 的总运营时间线性提升每一个 SQL 也呈线性提升这也验证了 PolarDB HTAP serverless 弹性扩展的特性。 测试中发现,当 CPU 的总核数增加到 256 核时性能提升并不大。原因是此时 PolarDB 共享存储的 IO 带宽已经打满成为了瓶颈。这也从侧面说明了 PolarDB 分布式 MPP 执行引擎的计算能力是非常强的。 此外我们将 PolarDB 的分布式 MPP 与传统数据库的 MPP 进行了对比同样使用 16g 和 256g 内存的 16 个节点。 1 TB 的 TPCH 数据在保持与传统 MPP 数据库相同的单机并行度为 1 的情况下PolarDB的性能是传统 MPP 数据库的90%。其中最本质的原因是传统 MPP 数据库的分布默认是哈希分布当两张表的joinkey 是各自的分布键时可以不用 shuffle 直接进行 Local Wise Join 。而 PolarDB 底层是共享存储池 PxScan 并行扫描出来的数据等价于随机分布必须 shuffle 重分布后才能像传统 MPP 数据库一样进行后续的处理。因此, TPCH 涉及到表join时 PolarDB 相比传统 MPP 数据库多了一次网络 shuffle 的开销。 PolarDB分布式 MPP 能够进行弹性扩展数据不需要重分布。因此在这有限的 16 台机器上执行 MPP 时PolarDB 还可以继续扩展单机并行度充分利用机器的资源当 PolarDB的单机并行度为 8 时它的性能是传统 MPP 数据库的 5-6 倍当 PolarDB单机并行度呈线性增加时PolarDB总的性能也呈线性增加只需要修改配置参数即可及时生效。 针对PolarDB HTAP 对构建索引加速特性的支持我们也进行了性能测试。在 500 GB 的数据量下当索引的字段有1、2、4个时分布式 MPP 并行相比单机并行构建索引性能提升了5倍左右当构建索引的字段增加到8个时性能提升了4倍左右。 原文链接 本文为阿里云原创内容未经允许不得转载。