数据价值挖掘利器!阿里云实时数仓AnalyticDB PG版新一代计算引擎Odyssey技术解析

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 Tair(兼容Redis),内存型 2GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
简介: 随着数字经济时代的到来,越来越多的应用依赖数据分析来挖掘数据的价值。作为大数据存储、在线分析的重要基础系统,分析型数据库(OLAP)为数据价值的在线化提供重要的技术平台。

本文作者:吕政、长别、知数等

目的

随着数字经济时代的到来,越来越多的应用依赖数据分析来挖掘数据的价值。作为大数据存储、在线分析的重要基础系统,分析型数据库(OLAP)为数据价值的在线化提供重要的技术平台。

阿里巴巴OLAP团队经过调研发现,现有的OLAP数据库执行引擎往往是在已有的OLTP执行引擎的基础之上,进行二次开发而来,存在性能损耗大、历史包袱重、未充分利用最新优化技术、未充分发挥新硬件优势等问题。

随着数据量的快速增长和数据分析需求的日趋强劲,OLAP系统所需要承担的计算量也呈指数级增长,现有系统的性能难以满足未来的在线数据分析的需求。经过分析,阿里巴巴OLAP团队认为,真正面向全面上云时代、面向数字经济时代的OLAP执行引擎,应当具备如下技术特点:

支持多种硬件平台。满足企业上云需求,支持多种硬件平台。除了支持传统X86平台,也应当兼容ARM平台,同时支持利用GPU、FPGA等新兴硬件进行加速。

极致性价比。充分利用硬件性能,精选最佳算法和算子实现,提升硬件执行效率。对于密集、复杂的计算,使用特殊算法特殊硬件来提升效率。

SQL 兼容性高。高度兼容现有的SQL标准、优化器标准、存储标准,减少用户的迁移难度和学习难度。用户无需改写SQL,无需重新学习优化技术,无需迁移数据,仅需要进行小版本软件升级,即可享受到最新的性能优化技术。
01.png

为了解决如上需求,阿里巴巴OLAP AnalyticDB Postgres(简称ADB PG版)研发团队历时1年多,研发了新型的计算引擎Odyssey。Odyssey计算引擎具备如下主要技术特点:

支持多种软硬件平台。除传统X86平台外,也支持ARM芯片服务器;支持采用GPU、FPGA加速部分核心算法。

性能强劲。抛弃传统数据库执行引擎的实现方式,充分利用硬件执行效率。通过算法设计,消除了火山模型、碎片化内存分配、冗余逻辑等带来的性能问题,将宝贵的CPU资源用于核心计算;采用LLVM进行动态代码生成(CodeGen),提升表达式计算性能、精简计算逻辑,实现逻辑计算完美“瘦身”;采用“超算”优化技术、对算子性能进行建模,全面分析代码热点,严格考察每一行代码的实现性能;充分利用新硬件特性,利用CPU的SIMD技术、GPU的超高带宽技术、FPGA的深度流水线,进一步提升性能。

• 兼容性强。Odyssey计算引擎内生于ADB PG版,与PostgreSQL的SQL标准、优化器、存储层多个层面实现完美兼容,用户无需任何操作,即可从原生引擎迁移到Odyssey计算引擎。

本文的如下部分,我们将从架构设计、核心技术点、性能评测三个维度,介绍新型计算引擎Odyssey的特点。

Odyssey计算引擎介绍

基本框架

下图是ADB PG版的系统框架,以及Odyssey计算引擎与ADB PG版的关系。
02.png

ADB PG是一个MPP架构、高可用、可伸缩的分布式分析型数据库系统。一个ADB PG集群由Master节点和Segment节点组成,通过网络进行互联。Master节点负责接收用户请求、对SQL进行解析/优化、下发计算任务。Segment节点负责存储数据、执行计算任务,Segment节点之间可能会有多次数据交换(shuffle)操作。网络互联速度、存储性能、Segment节点的执行性能,均对ADB PG的性能有重要影响。本次发布的Odyssey计算引擎,主要提升了Segment的执行性能。

Odyssey计算引擎的研发目标,是为ADB PG新增一个更高效的计算引擎,而保持原有各模块不变。ADB PG的Master节点在接收到用户的SQL请求之后,对SQL进行解析、优化,生成执行计划然后下发到Segment,Odyssey计算引擎对这一环节没有影响,因此用户无需修改SQL、无需重新优化SQL。

Segment接受到Master节点下发的执行计划后,若Odyssey打开,将不再调用原生执行引擎,而是调用Odyssey计算引擎。在存储层面,Odyssey计算引擎与ADB PG原生的Heap表、AOCS表、AORO表均完全兼容,复用原生存储结构和存储访问接口,Odyssey专注于执行层。理论上说,Odyssey原生引擎与ADB PG的优化器优化、存储优化等不同层次的优化是正交的,可以无缝衔接。

03.png

Odyssey计算引擎执行流程如上图所示。Odyssey通过hook接入ADB PG,成为对用户透明的新引擎。ADB PG在SQL执行开始时,通过选择不同的Hook函数,来选择不同的执行引擎。对于用户来说,既可以选择原生执行引擎,也可以通过设置GUC参数选择Odyssey执行引擎。下一个版本将通过代价模型和规则来自动的选择计算引擎,更能发挥各自的优势。
为了保证系统的稳定性和功能的完整性,Odyssey计算引擎支持执行引擎的回退,当功能不支持或者执行失败,可以自动回退到原生的执行引擎。由于执行引擎本身是无状态的,用户可以根据需求,以任意粒度(库级别、session级别、SQL级别)进行执行引擎切换。

设计思想

基于上述架构,Odyssey计算引擎充分利用ADB PG自身的优势,复用其存储、优化器和事务控制,Odyssey专注于计算性能的提升,与原生ADB PG强大、丰富的功能形成互补。为了提升计算性能,通过对原生执行引擎进行分析、横向对比多种执行引擎,我们设计了新的计算引擎。Odyssey计算引擎重新设计了plan node、codegen和executor,三者之间一一对应,如下图所示,每个plan的node对应一个codegen单元和一个Executor,codegen单元根据plan node生成code(IR),Executor根据硬件平台选择不同的后端,将IR生成对应的执行文件,并申请资源执行,最终的结果通过master返回给客户端。

04.png

执行模型优化。Odyssey计算引擎放弃了传统的火山模型,改用批量化(batch)的火山模型,批量化执行减少函数调用的开销,也方便使用向量化计算提升数据处理效率,同时也使得开发更为灵活、优化空间更大。

即时编译技术。Odyssey计算引擎采用了Just-in-Time(JIT)技术,采用LLVM动态生成代码。在一些核心操作上采用JIT技术,解决了高级语言抽象程度过高带来的性能开销,可以对表达式计算、复杂逻辑操作进行汇编级优化,最大化压缩指令的规模。

内存管理优化。ADB GP原生执行引擎存在碎片化内存分配、碎片化内存拷贝等性能问题。Odyssey计算引擎在算法层进行了重新设计,采用模块化内存分配、最大化重复利用已分配内存,大大减少了内存分配的次数。

超算软件优化。Odyssey计算引擎的开发,大量采用了“超级计算机”软件开发中的优化技术。在超算软件优化中,建立理论性能模型、进行详细性能剖析(Profiling)、严格审核代码性能,能够有效帮助软件性能的提升。Odyssey计算引擎全面采用了相关技术,做到每个算子、每段代码,都进行了深度优化。

多平台兼容。除传统X86平台,Odyssey计算引擎兼容其他X86平台和ARM平台,同时支持不同版本的Linux操作系统,为用户提供了更多的选择和优化空间。

硬件加速优化。Odyssey计算引擎能够利用GPU的超大吞吐能力和FPGA的高密度计算能力。对于部分计算量大、吞吐要求高的算子,采用GPU进行加速;对于部分计算逻辑相对固定、逻辑复杂的算子,采用FPGA进行加速。

核心技术点

执行模型优化

05.png

上图展示了TPCH-Q3的执行计划。在ADB PG中,一条SQL会被转化成一个树形执行计划。数据库传统的传统火山模型,是父节点驱动子节点执行,子节点按行返回数据给父节点,然后父节点再继续执行。火山模型有三个核心性能问题:
(1) 函数调用过多,每行数据的传递需要至少一次函数调用,CPU开销大;
(2) 优化困难,一些逻辑运算横跨多个函数,无法进行优化;
(3) CPU利用率低,CPU完成某个算子的一个操作后,马上返回到上层节点去做另一个操作,逻辑跳转多,不利于提升CPU执行效率。
Odyssey计算引擎对火山模型进行了完全重写,在复用原有的树形架构基础上,采用批量化(batch)执行提升执行性能。

火山模型中,节点之间传递数据的单位为一行,每个节点生成一行数据之后会被上层节点层层拉取,然后进行下一阶段的计算。 而Odyssey计算引擎以batch为单位进行数据传递。一个Batch包含多行数据(通常是数千行数据),采用列优先格式进行数据存储。一个节点在生成多行数据、填满一个batch之后,才会将数据返回给上层节点,消除了火山模型的性能问题。一方面,该方案将火山模型的函数调用的次数降低了三个数量级,消除了过多函数调用带来的性能影响;另一方面,减少了跨函数的操作,有利于在算法层进行优化、为各个算子选取最佳算法;最后,减少了逻辑跳转操作,能够有效利用现代CPU的执行资源。

内存管理

Odyssey计算引擎继续沿用了ADB PG的内存管理模块。ADBPG原生的内存管理模块除了性能上有所提升,而且能够自动追踪内存的分配,从而实现自动的内存释放,提升性能的同时避免了内存泄露的问题。该模块已经经过大规模云上实践的检验,因此在工程上。Odyssey计算引擎沿用了这一模块,但是在内存的使用上进行了优化,减少了不必要的内存分配和碎片化的内存分配。

一方面,Odyssey会尽力复用已分配的内存,避免不必要的多次内存分配。在火山模型中,部分节点生成一行数据后会为这行数据分配新的内存空间,因此每行数据都可能需要一次内存分配。Odyssey抛弃了火山模型、使用batch进行数据中转。每个batch的数据被上层节点消费完一行,Odyssey会复用此batch的内存空间,无须重新进行分配。
// 原生引擎:碎片化分配,按行分配内存

for (...) {
    void* hash_entry = palloc(32);
    
    ... // copy data
}
// Odyssey引擎:整块内存分配。
void* hash_table = palloc(32*1000,000);
for () {
    ... // copy data
}

另一方面,在一些大快内存分配时,Odyssey选取了效率更高的分配方式(如上述伪代码所示)。例如在Hash Join建哈希表时,一次插入一行数据,ADB PG的原生执行引擎,会在每行数据的插入之前为这一行分配内存。因此,每一行数据都需要重新进行一次内存分配,这种方案会带来大量的碎片化内存分配。例如Hash表有1M行,每行32字节,会导致1M个32字节的碎片化内存分配。对于现代化的系统来说,碎片化的内存分配对于性能的影响是非常大的,不仅分配过程非常耗时,后续的管理、追踪、释放过程也会非常耗时。

Odyssey对ADB PG原生执行引擎的碎片化内存分配问题进行了诊断和原因分析,排查出几个导致碎片化内存分配的关键算法问题。通过算法设计,Odyssey避免了碎片化内存分配问题,从而在不降低内存使用效率的同时,提高了内存管理的性能。

Codegen

Odyssey计算引擎采用基于LLVM的Codegen(代码生成)技术,减少了虚函数的调用,提升了复杂逻辑表达式和逻辑判断的性能。有别于PostgreSQL 11中表达式的codegen,Odyssey计算引擎是对整个算子进行codegen。目前Codegen主要用于三个层面的优化,算子优化、逻辑表达式优化和Code Specialization(代码专业化)。

算子优化。采用codegen,可以将整个算子生成一个函数,减少虚函数调用和冗余代码,也可以将多个算子生成一个函数,不光有上述优势,还能减少内存的使用和内存的拷贝。例如join + group by的场景,可以融合成一个函数,将join和AGG在一个函数里实现。特别是如果hash key和group key相同时,只需要建一个hash表。

逻辑表达式优化。如下代码实例解释了是如何实现这一优化的。对于a > 10 and b < 5这样一个过滤条件, ADBPG是通过三个函数调用来实现的,第一个函数调用Int32GT(a, 10)实现 a > 10, 第二个函数调用Int32LT(b, 5)实现b < 5, 第三个函数实现And操作。该方案需要三次函数调用,对性能有明显的影响。而Odyssey计算引擎采用的方案,使用LLVM生成LLVM IR,在编译成底层的机器码,只需要三条指令即可完成这一操作。通过该方案,Odyssey计算引擎避免了大量的冗余操作,能够针对不同的表达式、不同的逻辑判断,生成最小化的底层代码。

// 实例SQL
select count(*) from table where a > 10 and b < 5;
// ADBPG表达式方案:多次函数调用
result = Int8AndOp(Int32GT(a, 10), Int32LT(b, 5));
// Odyssey方案:生成最小化底层代码
%res1 = icmp ugt i32 %a, 10;
%res2 = icmp ult i32 %b, 5; 
%res = and i8 %res1, %res2;

Code Specialization。 对于一些在执行全已知的逻辑判断,可以通过LLVM进行code specialization, 从而消除逻辑判断。例如,某些数据结构的类型SQL解析完成后、在执行引擎开始执行前是确定的,比如每个节点的输出数据类型、数据长度。如果是使用高级语言(比如C语言)进行执行,由于写代码是开发者并不知道数据的类型,需要对每个元素的类型、长度进行判断。但是LLVM是在代码生成时就确定了数据的类型,因此生成的最终代码无需进行判断、直接进行操作即可。由于执行引擎经常需要进行数据类型、长度判断,尽管每次节省的时间非常少,但是累计下来性能的提升非常明显。

向量化执行

将按行拉取数据的火山模型改为按batch拉取数据的火山模型后,结合按列存放的优势,可以更进一步挖掘处理器的性能。例如,批量化处理的模型可以利用CPU的向量指令,或者GPU的众核优势,进一步提升性能。

// 伪代码样例:利用SIMD指令加速聚合  
for (int i = 0; i < round_row; i += 8) {
    __m256 m_tmp = _mm256_load_ps(&(aligned_input_data[i]));
    __m256 ymm2 = _mm256_permute2f128_ps(m_tmp , m_tmp , 1);
    m_tmp = _mm256_add_ps(m_tmp, ymm2);
    m_tmp = _mm256_hadd_ps(m_tmp, m_tmp);
    m_tmp = _mm256_hadd_ps(m_tmp, m_tmp);
    result += m_tmp[0];
  }

例如OLAP 中常用的Aggregation操作,采用SIMD指令,计算性能能提升4倍左右,伪代码如上所示。一些更为复杂的算法可以利用GPU众核计算能力,例如并行过滤、聚合、规约等算法,计算性能最高可以提升一个数量级。

跨平台支持

云计算时代,云平台支持多种不同的硬件资源,除传统x86平台外,国产x86平台、国产ARM平台、GPU、FPGA资源均可支持,用户只需要购买相应的资源规格即可,满足了用户不同的场景需求。Odyssey计算引擎在ADB PG的基础之上,进一步扩展了支持的范围,目前Odyssey计算引擎已经完美运行在x86平台和ARM平台上。

06.png

除此之外,Odyssey计算引擎支持使用GPU和FPGA对关键算子进行加速。GPU作为一种众核架构,计算资源和带宽资源充足,适合数据密集型、高吞吐的场景。FPGA作为一种可定制化处理器,非常适合一些逻辑复杂的操作,有效提升硬件的资源利用率。目前Odyssey计算引擎支持使用GPU加速部分高密度算子,可实现超过5倍的性能提升。支持使用FPGA加速存储层的压缩和解压缩,最高性能提升超过10倍。

性能结果

测试采用的是标准的TPCH测试集,使用TPCH官方的工具生成数据和22条SQL,数据量为1TB,scale factor = 1000,集群规模都为32个segment。22条SQL从Q1到Q22单并发顺序、连续执行,每一条SQL发送出去记为开始时间,返回结果为结束时间,执行时间为两者的差值。

X86平台测试结果

x86平台测试在阿里云上进行,实例的具体规格如下:
单节点核数:4
单节点内存:32G
单节点磁盘:320G SSD
实例节点数:32
测试结果如下:
07.png

从图中可以看出,Odyssey计算引擎比原生引擎有比较明显的优势,Q1、Q4、Q9、Q11、Q17、Q20、Q21、Q22这些SQL有1倍以上的提升,其中Q17有2倍以上的性能提升。提升的比例与SQL类型有关,对于计算密集型的SQL优势更加明显。对于IO密集型的SQL,我们在IO接口上做了适配和优化,计算性能提升的同事,IO性能也有提升。

ARM平台测试结果

ARM平台的测试采用三台服务器,一台作为master,另外两台作为计算节点。计算节点上各部署16个segment,共32个segment。每台服务器的配置如下:
08.png

CPU:128 cores
内存:378G
磁盘:3.84Tx4 AliFlash
从图中可以看出,在ARM平台,Odyssey计算引擎也有比较大的优势,而且相对x86平台,Odyssey在ARM平台上优势更明显。

总结

以上是ADB PG新的计算引擎Odyssey的一些技术细节,总的来说,Odyssey使用了新的技术:JIT,新的模型:批量(batch)化的火山模型,新的硬件特性:CPU的AVX指令、GPU的众核计算、FPGA的专用计算。在公有云上1TB的TPCH实测,22条语句的总时间是原引擎的50%,单条SQL性能最高提升2倍多;ARM服务器上搭载Odyssey计算引擎的ADB PG也有一倍的性能提升,并且相对X86平台,Odyssey引擎提升更明显。
接下来的Odyssey计算引擎还会在存储层适配优化,更极致的性能优化上下功夫,敬请各位关注!

相关实践学习
AnalyticDB MySQL海量数据秒级分析体验
快速上手AnalyticDB MySQL,玩转SQL开发等功能!本教程介绍如何在AnalyticDB MySQL中,一键加载内置数据集,并基于自动生成的查询脚本,运行复杂查询语句,秒级生成查询结果。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
目录
相关文章
|
3天前
|
人工智能 自然语言处理 关系型数据库
阿里云云原生数据仓库 AnalyticDB PostgreSQL 版已完成和开源LLMOps平台Dify官方集成
近日,阿里云云原生数据仓库 AnalyticDB PostgreSQL 版已完成和开源LLMOps平台Dify官方集成。
|
2天前
|
弹性计算 网络协议 Ubuntu
如何在阿里云国际版Linux云服务器中自定义配置DNS
如何在阿里云国际版Linux云服务器中自定义配置DNS
|
1月前
|
机器学习/深度学习 Java API
阿里云文档智能解析——大模型版能力最佳实践与体验评测
阿里云文档智能解析(大模型版)在处理非结构化数据方面表现优异,尤其是在性能和可扩展性上具有明显优势。虽然存在一些待完善之处,但其强大的基础能力和广泛的适用场景使其成为企业数字转型过程中的有力助手。随着技术的不断进步和完善,相信它会在更多领域展现出更大的价值。
92 5
阿里云文档智能解析——大模型版能力最佳实践与体验评测
|
21天前
|
文字识别 算法 API
阿里云文档解析(大模型版)优化
阿里云文档解析(大模型版
|
2天前
|
弹性计算 负载均衡 网络协议
内部名称解析设置阿里云私有 DNS 区域,针对于阿里云国际版经验教程
内部名称解析设置阿里云私有 DNS 区域,针对于阿里云国际版经验教程
|
1月前
|
存储 机器学习/深度学习 监控
阿里云 Hologres OLAP 解决方案评测
随着大数据时代的到来,企业面临着海量数据的挑战,如何高效地进行数据分析和决策变得尤为重要。阿里云推出的 Hologres OLAP(在线分析处理)解决方案,旨在为用户提供快速、高效的数据分析能力。本文将深入探讨 Hologres OLAP 的特点、优势以及应用场景,并针对方案的技术细节、部署指导、代码示例和数据分析需求进行评测。
96 7
|
1月前
|
运维 数据挖掘 OLAP
阿里云Hologres:一站式轻量级OLAP分析平台的全面评测
在数据驱动决策的今天,企业对高效、灵活的数据分析平台的需求日益增长。阿里云的Hologres,作为一站式实时数仓引擎,提供了强大的OLAP(在线分析处理)分析能力。本文将对Hologres进行深入评测,探讨其在多源集成、性能、易用性以及成本效益方面的表现。
57 7
|
1月前
|
弹性计算 开发框架 数据可视化
阿里云虚拟主机和云服务器有什么区别?多角度全解析对比
阿里云虚拟主机与云服务器ECS的主要区别在于权限与灵活性。虚拟主机简化了网站搭建流程,预装常用环境,适合初级用户快速建站;而云服务器提供全面控制权,支持多样化的应用场景,如APP后端、大数据处理等,更适合具备技术能力的用户。尽管虚拟主机在价格上通常更优惠,但随着云服务器价格的下降,其性价比已超越虚拟主机,成为更具吸引力的选择。
|
3月前
|
数据采集 运维 Cloud Native
Flink+Paimon在阿里云大数据云原生运维数仓的实践
构建实时云原生运维数仓以提升大数据集群的运维能力,采用 Flink+Paimon 方案,解决资源审计、拓扑及趋势分析需求。
18478 54
Flink+Paimon在阿里云大数据云原生运维数仓的实践
|
2月前
|
分布式计算 安全 OLAP
7倍性能提升|阿里云AnalyticDB Spark向量化能力解析
AnalyticDB Spark如何通过向量化引擎提升性能?

推荐镜像

更多