个人网站电商怎么做,金凤区建设交通局网站,wordpress 图片 alt,建站教程的优点简介#xff1a;本文介绍了云原生数据仓库产品AnalyticDB PostgreSQL从Cloud-Hosted到Cloud-Native的演进探索#xff0c;探讨为了实现真正的资源池化和灵活售卖的底层设计和思考#xff0c;涵盖内容包括产品的架构设计#xff0c;关键技术#xff0c;性能结果#xff0c…简介本文介绍了云原生数据仓库产品AnalyticDB PostgreSQL从Cloud-Hosted到Cloud-Native的演进探索探讨为了实现真正的资源池化和灵活售卖的底层设计和思考涵盖内容包括产品的架构设计关键技术性能结果效果实现和后续计划几方面。 作者 | 翰明 来源 | 阿里技术公众号
一 前言
Garner预测到2022年所有数据库中有75%将部署或迁移至云平台。另外一家权威机构IDC也预测在2025年超过50%的数据库将部署在公有云上而中国则会达到惊人的70%以上。云数据库经过多年发展经历从Cloud-Hosted 云托管到 Cloud Native云原生模式的转变。
Cloud-Hosted基于市场和业界的云需求大部分厂商选择了云托管作为演进的第一步。这种模式将不再需要用户线下自建IDC而是依托于云提供商的标准化资源将数据仓库进行移植并提供高度托管从而解放了用户对底层硬件的管理成本和灵计划资源的约束。
Cloud-Native然而随着更多的业务向云上迁移底层计算和存储一体的资源绑定导致用户在使用的过程中依然需要考量不必要的资源浪费如计算资源增加会要求存储关联增加导致无效成本。用户开始期望云资源能够将数据仓库进行更为细粒度的资源拆解即对计算存储的能力进行解耦并拆分成可售卖单元以满足业务的资源编排。到这里云原生的最大化价值才被真正凸显我们不在着重于打造存算平衡的数据仓库而是面向用户业务允许存在大规模的计算或存储倾斜将业务所需要的资源进行独立部署并按照最小单位进行售卖。这一刻我们真正的进入了数据仓库云原生时代。
阿里云在2021云栖大会上预告了全新云原生架构的数据仓库【1】。本文介绍了云原生数据仓库产品AnalyticDB PostgreSQL以下简称ADB PG从Cloud-Hosted到Cloud-Native的演进探索探讨为了实现真正的资源池化和灵活售卖的底层设计和思考涵盖内容包括产品的架构设计关键技术性能结果效果实现和后续计划几方面。全文阅读时长约为10分钟
二 ADB PG云原生架构
为了让用户可以快速的适配到云数据仓库目前我们采用的是云上MPP架构的设计理念将协调节点和计算节点进行独立部署但承载于单个ECS上实现了计算节点存储计算一体的部署设计该设计由于设计架构和客户侧自建高度适配可快速并无损的将数仓业务迁移至云上对于早期的云适配非常友好且满足了资源可平行扩展的主要诉求。
随着云原生的进一步演进我们提供了全新的存算分离架构将产品进一步拆分为服务层、计算层和共享存储层架构图如下 Master协调节点保存全局的schema信息并实现了全局事务管理
行存引擎用来保存元数据信息这里的元数据信息主要指共享存储文件的可见性信息包括两个部分
一个是文件与表的关系另外一个是被删除的数据的delete bitmap
基于行存我们可以继承PG的本地事务能力在增删改查的同时与PG的事务能力完全兼容
本地缓存通过引入存储团队的DADI来实现高性能的本地缓存DADI全称是Alibaba Cloud Data Accelerator for Disaggregated Infrastructure相比开源产品性能有数量级的提升
共享存储我们借鉴了ClickHouse的一些关键设计在存储层实现了一个基于MergeTree的行列混存此外我们对共享存储基于文件接口做了一层统一访问接口同时高度适配了OSS和HDFS 两种形态的分布式文件系统
当我们在架构设计的时候和同样源自Greenplum的HAWQ对比HAWQ把元数据都保存在master在每次写的时候把修改的元数据带到master来更新读的时候先从master读取需要的元数据然后在执行计划里面把元数据都带上这样segment就能拿到对应的元数据 同时segment可以完全无状态。
但是这个设计会带来2个核心问题
元数据膨胀导致master成为瓶颈。受限于元数据的性能无法支持高并发的实时写入。
而我们不这样设计做的原因是我们希望在未来能够支持高并发的任务ADB PG大概花了2年多的时间将Greenplum的单点master架构拓展为multi-master核心是为了解决高并发实时写入的问题如果把元数据都保存在master上会带来如问题
master上面的元数据存储和访问容易形成单点瓶颈需要对ADB PG的执行层做大量的重构实现在执行计划里面把元数据都带上这会急剧的增加查询计划本身的带宽这个对于高并发的小查询非常不友好。
所以我们改进了架构将元数据分散到segment规避并实现了
master的存储和读写都不会成为瓶颈无需对执行层做重构将元数据分散减少单次查询的带宽压力。将segment上的元数据放到分布式kv上解决扩缩容的元数据搬迁问题。
共享存储使用OSS的原因在于随着单个用户业务数据不断增长需要一个可持续发展的存储方案而OSS的低存储成本高可用性和数据持久性是最好的选择。 使用OSS的另外一个好处在于按需付费用户不需要预制存储空间大小存了多少数据付多少钱数据删除后即不再收费ESSD云盘通常需要根据数据计算存储水位无法做到将存储资源真正的按需供应而且无法自动缩容这些都违背了我们云原生的设计理念。但同时OSS的劣势在于RT: 为了解决OSS的RT问题我们为计算节点配置了一定比例的本地盘用来做访问加速。此外我们设计了一个高性能的行列混存借鉴了ClickHouse mergetree存储的核心思想以有序为核心文件内绝对有序文件与文件大致相对有序通过merge的异步操作实现文件和并和排序基于有序我们在文件内设计了3层的统计信息并做了大量的IO裁剪优化。
下面我们对每个技术点做进一步介绍。
三 关键技术
1 弹性伸缩
为了实现快速的弹性伸缩我们的方式是数据在共享存储上hash bucket来组织扩缩容后通过一致性hash把计算节点和bucket做重新映射为了解决bucket与segment分配的均匀性并降低扩缩容后cache失效的影响我们对传统的一致性hash算法做了改进支持扩缩容时的动态映射。 把数据根据hash bucket分成多个分片按分片粒度在扩缩容的重新映射对象存储上的数据。如果扩容计算节点超过分片个数的时候只能重分布数据。为了解决这个问题我们支持hash bucket可以后台分裂和合并避免重新分布数据。
上述是扩缩容时“数据”的重现映射而描述数据文件可见性的元数据由于保存在行表中我们还是使用了Greenplum的数据重分布策略不同的是为了加速元数据的重分布我们做了并行化分布等优化。
我们以扩容为例进一步细化扩容的流程 结合ECS资源池化网卡并行加载和docker镜像预热等技术16节点内端到端的耗时接近1分钟。
2 分层存储
分层存储的实现如下 如上图所示我们把存储的资源分成3层包括内存、本地盘和共享存储。
内存主要负责行存访问加速并负责文件统计信息的缓存
本地盘作为行存的持久化存储并作为远端共享存储的本地加速器
远端的共享存储作为数据的持久化存储。
3 读写流程
写入流程如下
用户写入数据通过数据攒批直接写入OSS同时会在本地磁盘上记录一条元数据。这条元数据记录了文件和数据表的对应关系。元数据使用PG的行存表实现我们通过file metadata表来保存这个信息。更新或者删除的时候我们不需要直接修改OSS上面的数据我们通过标记删除来实现标记删除的信息也是保存在本地行存表中我们通过visibility bitmap来存这个信息。标记删除会导致读的性能下降我们通过后台merge来应用删除信息到文件减少删除带来的读性能影响。
我们在写入的时候是按照bucket对segment上的数据做了进一步划分这里会带来小文件的问题。为了解决小文件问题我们做了下面几点优化
Group flush一批写入的数据可以通过group flush写到同一个OSS文件我们的OSS文件采用了ORC格式不同bucket写入到对应strip流水线异步并行编码攒批排序是典型的cpu密集型任务上传到oss是典型的网络IO密集型任务我们会把这2种任务类型并行起来在上传oss的任务作为异步任务执行同时对下一批数据编码排序加快写入性能。
因为远端持久化存储提供了12个9的持久性所以只有保存元数据的行存才有WAL日志和双副本来保证可靠性数据本身写穿到共享存储无需WAL日志和多副本,由于减少了WAL日志和WAL日志的主备同步又通过异步并行和攒批在批量写入场景我们写入性能做到了基本与ECS弹性存储版本性能持平。
读取流程如下
我们通过读取file metadata表得到需要扫描的OSS文件。根据OSS文件去读取对应文件。读到的文件通过元数据表visibility bitmap过滤掉已经被删除的数据。
为了解决读OSS带来的延迟我们也引入了DADI帮忙我们实现缓存管理和封装了共享文件的访问读文件的时候首先会判断是否本地有缓存如果有则直接从本地磁盘读没有才会去 OSS读读到后会缓存在本地。写的时候会直写OSS并回写本地磁盘回写是一个异步操作。对于本地缓存数据的淘汰我们也通过DADI来管理他会根据LRU/LFU策略来自动淘汰冷数据。
由于事务是使用PG的行存实现所以与ADB PG的事务完全兼容带来的问题是我们在扩缩容的时候需要重新分布这部分数据我们重新设计了这块数据的重分布机制通过预分区并行拷贝点对点拷贝等技术极大缩短了扩缩容时间。
总结一下性能优化点
通过本地行存表实现事务ACID支持数据块级别的并发通过Batch和流水线并行化提高写入吞吐基于DADI实现内存、本地SSD多级缓存加速访问。
4 可见性表
我们在File Metadata中保存了共享存储文件相关的信息它的结构如下 Hash bucket是为了在扩缩容的时候搬迁数据的时候能够按照bucket来扫描查询的时候也是一个bucket跟着一个bucket
Level是merge tree的层次0层代表实时写入的数据这部分数据在合并的时候有更高的权重
Physical file id是文件对应的id64字节是因为它不再与segment关联不再只需要保证segment内table的唯一性需要全局唯一
Stripe id是因为一个oss文件可以包含多个bucket 的文件以stripe为单位方便在segment一次写入的多个bucket合并到一个oss文件中。避免oss小文件导致性能下降和oss小文件爆炸
Total count是文件行数这也是后台合并的一个权重越大合并的权重越低 。
Visibility bitmap记录了被删除的文件信息 Start_row对应32k对应一个delete bitmap。这个32000 4k行存使用的32k的page可以保存7条记录。
Delete count是被删除的数量。
我们无需访问oss可以直接得到需要merge的文件避免访问oss带来的延迟另外oss对于访问的吞吐也有限额避免频繁访问导致触发oss的限流。
5 行列混存 Mergetree的结构如上图左侧所示核心是通过后台merge的方式把小文件merge成有序的大文件并且在merge的时候我们可以对数据重排例如数据的有序特性做更多的优化参考后续的有序感知优化。与leveldb的不同在于
0层实时写入的会做合并不同bucket的文件会合并成大文件不同bucket会落到对应的stripeMerge会跨层把符合merge的文件做多路归并文件内严格有序但是文件间大致有序层数越高文件越大文件间的overlap越小。
每个文件我们使用了行列混存的格式右侧为行列混存的具体的存储格式我们是在ORC的基础上做了大量优化。
ORC文件一个ORC文件中可以包含多个stripe每一个stripe包含多个row group每个row group包含固定条记录这些记录按照列进行独立存储。
Postscript包括文件的描述信息PostScript、文件meta信息包括整个文件的统计信息数据字典等、所有stripe的信息和文件schema信息。
stripestripe是对行的切分组行形成一个stripe每次读取文件是以行组为单位的保存了每一列的索引和数据。它由index datarow data和stripe footer组成。
File footer保存stripe的位置、每一个列的在该stripe的统计信息以及所有的stream类型和位置。
Index data保存了row group级别的统计信息。
Data stream一个stream表示文件中一段有效的数据包括索引和数据两类。
索引stream保存每一个row group的位置和统计信息数据stream包括多种类型的数据具体需要哪几种是由该列类型和编码方式决定下面以integer和string 2种类型举例说明
对于一个Integer字段会同时使用一个比特流和整形流。比特流用于标识某个值是否为null整形流用于保存该整形字段非空记录的整数值。
String类型字段ORC writer在开始时会检查该字段值中不同的内容数占非空记录总数的百分比不超过0.8的话就使用字典编码字段值会保存在一个比特流一个字节流及两个整形流中。比特流也是用于标识null值的字节流用于存储字典值一个整形流用于存储字典中每个词条的长度另一个整形流用于记录字段值。如果不能用字典编码ORC writer会知道这个字段的重复值太少用字典编码效率不高ORC writer会使用一个字节流保存String字段的值然后用一个整形流来保存每个字段的字节长度。
在ORC文件中保存了三个层级的统计信息分别为文件级别、stripe级别和row group级别。而提升存储性能的核心是减少IO我们基于ORC的统计信息和索引实现各种下推帮助我们实现IO裁剪。例如Projection下推我们只会扫描需要物化的列。Agg下推中我们会直接把需要的minmaxsumunique从统计信息或者索引中读取即可返回避免了对data stream的解压。对于predicate我们还支持把filter下推通过统计信息直接做过滤直接跳过不符合的条件的stripe我们支持各种操作符以及in/not in以及表达式的等价转换。
此外我们针对存储格式对性能还做了下面的优化
零拷贝为了把ORC的数据类型转换成PG数据类型我们对于定长类型的做值拷贝变长类型直接转换成PG的datum做指针引用。Batch Scan面向column采用batch scan替代逐行访问而是先扫完一列再扫下一列这样对CPU cache更加友好。支持Seek read方便过滤命中情况下的跳转。
6 本地缓存
DADI帮助我们实现2个能力一个是高效的缓存管理另外一个是统一存储访问。在了解DADI之前我们可以首先看一下DADI与开源解决方案从RT与throughput 2个维度做了对比测试 从中看到DADI相比开源解决方案alluxio在内存命中的场景RT上有数量级的提升在throughput上也有明显的优势。在命中磁盘的场景也有明显的性能优势在部分分析场景下我们会频繁但是少量读取文件统计信息这些统计信息我们会缓存在本地这个优势带来整体性能的较大提升。
DADI在缓存命中场景下的性能优势可以参考下面的架构 DADI SDK通过标准读写接口访问存储通过缓存是否命中选择短路读short circuit read还是IPC进程通信访问Local DADI Service或者访问远端的DADI Service对应分布式缓存服务作为lib库嵌入ADB PG的读写进程
Cache Instance管理本地缓存缓存文件抽象成虚拟块设备来访问数据在memory和本次磁盘的冷热以block为单位管理。
这里的核心设计在于
短路读直接读共享内存避免通过IPC读缓存是否命中的数据结构也是在共享内存里面。通过reference count结合robust mutex来保证共享内存数据的多线程安全磁盘读100us 27us约等于磁盘读本身rtIPC走shm通信没有使用本地socket通信。极低的资源使用。
内存DADI Service使用的内存在100~200M原因在于基于共享内存的IPC实现hash表等数据结构避免多进程架构下内存膨胀 精简的编码方式1个内存页16k 对应 4byte的管理结构
CPULocal DADI Service在磁盘打满的时候单核CPU使用20%左右。CPU的使用在SDK这边SDK与Local DADI Service通信很少。
此外为了更好的发挥DADI在命中内存的优势我们结合行列混存做了以下优化
缓存优先级支持统计信息高优先级常驻内存索引信息常驻本地磁盘。支持维度表数据高优先级缓存在本地。细粒度缓存策略为了避免大表冷数据访问导致本地热数据被全部替换大表使用专有缓存区。文件异步预取根据查询情况把解析的数据文件预先读取到本地这个过程不影响当前文件的读写并且是异步的。
7 向量化执行 ADB PG云原生版本也同样支持向量化执行引擎核心还是通过攒批的方式提高数据在CPU cache的命中率通过codegen减少函数调用次数减少复杂计算指令跳转通过SIMD指令加速计算通过内存池管理降低算子间的内存拷贝更多信息可以参考【3】。
8 有序感知
数据的有序主要用在2个方面基于有序的IO裁剪另外一个是尽量减少计算过程中的排序IO裁剪在行列混存以及有较多的讨论这里主要讨论第二点这里我们做的主要工作有
消除多余sorting操作。如果data本身有序且满足排序要求则不需要加sort操作。最小化需要排序的列。例如希望对{c1,c2,..cn}排序如果有谓词c15则order简化成{c2,..cn}避免排序多一个字段。order下推。在初始化阶段降意向排序操作尽量下推。
我们通过下列方法来生成sort scan的算子查询SQL解析生成AST后会根据一系列启发式规则做变换生成物理执行计划
首先针对不同算子的有序性需求例如join/group by/distinct/order by,建立算子的interesting order即这个算子期望的有序输入。其次在sort scan的过程中所生成的interesting order会尽可能下推到下层算子中(sort-ahead)以尽早满足order属性要求。如果一个算子具有多个interesting order会尝试将他们合并这样一个排序就可以满足多个order属性的需求。
此外就是sort scan算子的实现存储层面只能保证文件内严格有序文件的大致有序我们通过多路归并的算法来实现。
这里的问题在于sort scan的多路归并需要一条条读取数据与向量化的batch scan与文件的批量读冲突我们通过CBO来选主最优的执行计划。
9 细粒度并行
ADB PG是MPP架构能够充分发挥节点间并行计算能力云原生版本由于对数据按bucket做了切分能帮助我们在节点内实现更细粒度的并行我们以join为例说明 左边是没有节点内并行的join的执行计划会起2个进程一个做hash join的build另外一个做probe右边是节点内做了并行我们会根据segment所分配的bucket来做并行例如上图每个bucket的数据都可以并行的去做计算由于数据是按照bucket做的划分join key是分布健的时候节点内并行也能完美命中local join的优化。
四 性能结果
1 扩缩容性能 2 读写性能
为了测试性能我们使用了4*4C规格的实例ADB PG的新版云原生与存储弹性版本做了性能对比测试。
写性能测试
测试表选用scale factor 500的TPC-H lineitem表。通过同时执行不同并发数的copy命令测得命令执行时间用总数据量除以命令执行时间得到吞吐量。 在单并发下新版本与存储弹性版本的性能差不多主要在于资源都没有满在4并发下新版本的吞吐是存储弹性的2倍原因在于使用lineitem表都定义了sort key新版本在写入数据无需写WAL日志另外攒批加上流水线并行相比弹性存储版本先写入再mergemerge的时候也需要写额外的WAL有一定优势在8并发下新版本与4并发差不多主要由于4C 4并发已经把CPU用满所以再提升并发也没有提升。
读性能测试
为了全面的测试读性能我们针对3种场景做了测试
全内存使用的是TPCH sf为10的数据集会生成10G的测试数据集。
全本地磁盘缓存使用的是TPCH sf为500的数据集会生成500GB的测试数据集。
一半缓存一半OSS使用的是TPCH sf为2000的数据集会生成2000GB的测试数据集。本地磁盘缓存960GB
测试结果如下纵轴为RT单位ms
全内存 全本地磁盘缓存 一半本地缓存一半OSS 从上述测试结果来看
云原生版本对比老的弹性存储版本均有1倍多的性能提升原因在于细粒度并行带来的加速效果对于TPCH这种计算密集型的作业即使数据一半缓存一半OSS性能也不错sf 2000数据量是sf 500的4倍rt增加到原来的2.8倍主要原因在于4*4C规格的实例没有到OSS的带宽瓶颈另外由于本身读取的预取等优化。
五 总结
AnalyticDB PostgreSQL新版云原生是充分的将物理资源进行了池化将存储和计算能力单元化进行分配实现灵活的部署。这个特性为使用者提供极致的性价比做到了算力的最优分配同时降低用户使用的门槛让用户专注于业务而无需将大量精力放在算力和存储的规划上实现体验升级。
通过存储计算分离用户可以根据业务负载模型轻松适配计算密集型或存储密集型存储并按使用计费避免存储计算一体僵化而造成的资源浪费动态的适配业务负载波峰和波谷云原生MPP架构计算侧使用了shared-nothing架构支持秒级的弹性伸缩能力而共享存储使得底层存储独立不受计算的影响。这降低了用户早期的规格选型的门槛预留了后期根据业务的动态调整灵活性在存储计算分离基础上提供了数据共享能力这真正打破了物理机的边界让云上的数据真正的流动了起来。例如数据的跨实例实时共享可支持一存多读的使用模式打破了传统数仓实例之间数据访问需要先导入再访问的孤岛简化操作提高效率降低成本。
六 后续计划
在上述存储分离的架构上我们后续主要有3个大的方向
能力补齐这块主要是补齐当前版本的一些限制例如Primary key索引物化视图补齐写入的能力性能持续优化主要优化缓存没有命中场景云原生架构持续升级这块主要是在当前存储计算分离架构下进一步提升用户体验
在云原生升级我们主要有2个重点方向
存算分离往Serverless再进一步扩缩容无感。会进一步把元数据和状态也从计算节点剥离到服务层把segment做成无状态的这样的好处在于扩缩容能做到用户无感另外一个好处在于segment无状态有利于提高系统高可用能力当前我们还是通过主备模式提供高可用当有节点故障的时候主备切换缓存失效性能会急剧下降segment无状态后我们会直接将它提出集群通过“缩容”的方式继续提高服务。应用跨实例的数据共享。此外对于分析型业务数据规模大以TB起步传统数仓采用烟囱式架构数据冗余数据同步代价高的问题我们希望提供跨实例的数据共享能力重构数仓架构。
原文链接
本文为阿里云原创内容未经允许不得转载。
