云原生数据仓库TPC-H第一背后的Laser引擎大揭秘

简介: 作者| 魏闯先阿里云数据库资深技术专家

一、ADB PG 和Laser 计算引擎的介绍

(一)ADB PG 架构

ADB PG 是一款云原生数据仓库,在保证事务ACID 能力的前提下,主要解决云上海

量数据的实时分析问题。它的架构与传统的MPP 数据仓库非常类似,主要分成两层,第一层是master 节点;第二层是work 节点。

 

master 节点主要承担实时写入和事务的处理,执行计划的生成。与其他的传统的

MPP 数据仓库不同的是ADB PG 的master 节点支持线性扩展,可以通过多个master

提升整体的事务能力、实时写入吞吐能力。

 

work 节点主要承担两个功能,第一个功能是执行,第二个功能是存储。执行引擎采用

的是向量化执行引擎,通过向量列式Batch 处理,codegen 技术,以及Fusion Scan 加速列式计算效率,在一些分析场景性能相对于普通的火山模型有了3~5 倍的提升。

 

同时它的存储节点不仅支持传统的行表和列表,也可以通过外表方式支持一些开源的表

结构,例如Parquet、ORC 等开源数据结构。ADB PG 可以直接分析保存在类似于像

OSS/HDFS 等分布式存储上的数据,减少数据的导入,可以大幅的降低用户的使用门槛和存储成本。

image.png

(二)为什么做Laser 计算引擎

为什么不采用PG 原生的计算引擎?

第一,PG 是一个传统的事务型数据库,它主要的优化大多来自于TP 的事务优化,并没有针对海量数据的分析计算做定制化的优化。

 

第二,PG 计算引擎采用解释执行的逻辑,复杂表达式采用函数执行树的递归的调用解

释执行。如图中的例子所示,每个表达式都被翻译成一个函数并组成一个执行树。每一条的数据都通过以上的函数递归调用去完成最终的计算。它带来的问题就是在海量千万以上的数据计算场景,虚函数调用大幅影响计算的性能。

 

第三, PG 默认只支持行存存储引擎,并不支持列存,所以它的整个计算执行过程是逐行处理数据,并没有对列存做定制化的优化。

 

第四, PG 代码具有非常好的扩展性、兼容性,但是在性能上考虑不多。例如说在计算过程中会涉及到内存的多次拷贝,序列化的开销比较高。

 

最后,PG 采用的是单分区单进程执行模式,无法充分发挥现代多核CPU 的优势。

 

image.png

 

(三)主流OLAP 业界方案

在开始ADB PG 计算引擎的选型过程,我们重点调研了当前主流的OLAP 业界主流

方案。

主要分成两大类,第一类:向量化执行;第二类:编译执行。

第一:向量化执行的基本做法,非常类似于火山模型,主要差别来自于它采用的是批量计算,每一批里优先列式计算。

这种模式优势在于可以充分发挥CPU 的流水线执行和内存的顺序访问,减少cache

的miss。缺点是第一实现逻辑比较复杂。第二,它需要批量的数据,并不适合每次计算数量较小的OLTP 场景。第三,它需要缓存批量数据,缓存本身带来一定的内存开销。

 

第二:编译执行基本做法是使用Codegen 技术,将所有的算子编译成函数,通过PUSH 的模型自下而上通过数据上推完成计算。

 

优点一:由于每次计算的都是一行数据,执行过程可以将这一行数据保存在寄存器里面,寄存器计算代替内存计算。优点二,它通过Codegen 技术把复杂的算子编译成一个函数,所以它非常适合计算复杂性非常高的计算加速。

 

缺点在于,PUSH 模型控制逻辑比较复杂,同时由于采用单条计算,无法做到内存的顺序访问,所以它整体的Cache miss 率比较高。典型的代表产品有Spark 和 Peloton。

 

ADB PG 综合考虑这两类方案的优缺点,最终使用了向量化的方案,主要考虑到ADB PG 原生PG 火山模型与向量化模型架构上较为接近,改造成向量计算引擎的逻辑顺畅,改造成本较编译执行小。

image.png

(四)业界主流计算引擎对比

我们对业界主流开源计算引擎做了对比,包括ClickHouse、PG11、Spark、ADBPG。在执行模型上,ClickHouse 和ADB PG、PG11 都采用的向量执行,Spark 采用

的是编译执行。

 

在内存模型上,ClickHouse 采用的是列存、PG11 采用行存、Spark 采用行存、ADB PG 采用行列混存。行列混存主要应用在类似于join、AGG 的场景,我们可以将多列group by、hashtable 数据拼成一列数据,可以充分发挥顺序访问的效率。

 

在即时编译上,ClickHouse 采用表达式级LLVM、PG11 采用表达式级LLVM,Spark 采用Stage Java 技术,ADB PG 采用算子级LLVM 技术。算子级LLVM 技术可以提升算子的计算性能。

 

在硬件加速上,ClickHouse 和PG11 都不支持硬件加速,Spark 支持FPGA 加速,ADB PG 采用IR 技术,可以通过将IR 翻译成对应的机器执行代码,从而支持GPU 加速。

 

image.png

二、laser 计算引擎的核心技术

Laser 计算引擎的核心技术主要包括5 大块:

1. 向量计算引擎

2. 行列式内存模型

3. JIT 加速

4. SIMD 指令加速

5. FUSION SCAN

第一,向量计算引擎,传统火山模型中算子之间数据逐条交互,向量化计算引擎之间的交互的是BATCH 数据,然后在每个算子内部,采用的列式多条数据并行计算,这种逻辑可以充分的发挥CPU 流水线的作用。

 

在内存模型上,我们采用的是行列混存内存模型。在算子之间数据传递的是一个mini batch,mini batch 内部采用的行列混存的结构。由于每列数据在内存里都是连续摆放的,所以每次计算一列都是内存的顺序访问的过程。

 

第三,针对复杂计算,采用JIT 技术加速。可以利用LLVM CodeGen 技术将复杂计算过程转换成IR 代码,然后再通过IR 代码翻译成机器码。它的好处是可以避免类型判断,减少虚函数的调用,从而提升计算性能。

 

第四,针对一些简单场景(如:聚合场景、固定场景),利用现代CPU 的SIMD 指令,实现单条指令多条数据的并行执行,大幅提升这些简单场景的效率。

 

第五,针对列存场景,可以通过FUSION SCAN 去减少无用列读取,避免无用内存的中间拷贝,从而提升列表的计算性能。

 

image.png

 

(一)向量计算引擎

下图是一个典型的火山模型下SUM 算子的计算过程。对于火山模型,如果总共有n条数据,就会调用n 次的函数调用。右边是向量化执行过程,sum 函数接收输入参数是一个数组,而不是两个变量。整个执行过程,数据按2048 条分批处理,每2048 条数据调用一次sum 函数。

 

image.png

从这个例子中明显可以看出:

第一,Sum 函数调用从原来的n 次变成n÷2048,减少了多次。

第二,在函数内部处理中,由于计算的数据是一个batch,就可以充分发挥SIMD 指令加速效果,实现单条指令多条语句的并行计算。

第三,可以针对一些算子,如AGG 和JOIN,可以将AGG 和JOIN 算子函数合并一个函数,可以进一步的减少虚函数调用,提升系统性能。

 

由于计算过程中全部采用数组计算,可以将计算过程中的数组使用内存池化技术管理。通过MemoryPool 可以实现定长数据的内存的复用,避免频繁内存分配和释放,减少整个内存的碎片。在实际的TPC-H 的测试中,使用向量化引擎后,Q1 提升了120%,Q18提升了190%。

(二)SIMD指令加速

针对简单的加速,可以利用现代CPU 的SSE、AVX 指令,一条指令可以实现512bit 数据计算。

 

我们对TPCH 测试中的Lineitem 表做性能的对比测试,在使用SIMD 以后,整体的性能从原来的1 秒多降低到了200 多毫秒,有了4 倍左右的提升。

image.jpeg

(三)Just-in-Time 编译优化

ADB PG 不仅支持表达式级的CodeGen,也支持算子级的CodeGen。每个plan的node 对应一个CodeGen 单元和一个Executor,CodeGen 单元根据plan node 生成code(IR),Executor 根据硬件平台选择不同的后端,将IR 生成对应的执行文件,并申请资源执行,最终的结果通过master 返回给客户端。

 

如图所示,对于这样一个简单的表达式,where a>10 and b<5,如果采用解释执行,总共包括三次函数调用,1、a>10;2、b<5;3、and 函数。

 

如果使用LLVM GIT 编译优化,上面的三个函数就编译成三条LLVM 指令,避免了三次函数调用的开销。

 

在TPCH 测试场景中,使用JIT 加速后整体的性能提升了20%~30%,并且在测试中发现,表达式越复杂,性能提升越明显。

 

image.png

(四)Fusion Scan 优化

Fusion Scan 主要优化是减少无用列的读取,并且尽量的减少无用数据的读取和内存的拷贝。

 

举个例子,如果要查询满足a 大于3 和b 小于6 的a,c*d 的值,传统做法是对数据库中的每条数据数据,做a 大于3 和b 小于6 的条件过滤并且计算对应列的值。

 

Fusion Scan 的做法分成两阶段:

第一阶段是对过滤列做计算。把a 列和b 列的所有数据读出来,对每条数据进行判断。如图所示,满足条件的只有第一行第三行,我们把第一行第三行号保存在一个bitset中,同时把第一行和第三行的a 列值也保存在mini batch 中;

 

第二阶段是计算project 列,由于满足这个条件只有第一行和第三行,我们只需要把c 列和d 列的第一行和第三行的值读取出来。同时为了避免中间结果的数据拷贝,我们直接去将c 列和d 列的值结果相乘,把结果保存在mini batch 的第二列中。

 

在计算过程中,我们提前将表达式编译成IR 代码,可以避免了多次表达式函数的递归调用。

 

以上过程的主要优化点在于:

第一、避免无用列表D、E、F、G 列读取;

第二、实现了按需读取,只有满足条件的c 列和d 列的里面内容才进行计算和IO,不需要读那些不满足条件的数据。同时在c 和d 计算过程中,直接进行c 和d 的读取,无需内存中间结果的拷贝。

 

在实际执行过程中,Fusion Scan 结合列存块block 索引做进一步的优化。block

索引中包含了数据块的min 和max,我们可以将min 和max 值和where 条件做交集,

只有这个交集非空的话,才会去真正读取block 的值,否则可以直接跳过这个block。

 

通过Fusion Scan 的技术,在列存的场景Scan 算子整体的性能有3 倍以上的提升。

 

image.png

 

(五)算子实现-HashJoin

HashJoin 的向量化执行引擎,算法采用Hybrid Hash Join,HashTable 采用开放链表数据结构。

 

HashJoin 的实现过程,主要包括:

1. 把左表probe 列的值取出来计算它的Hash 值。

2. Hashcode 的值去模entry 个数,获取对应的行号。

3. 对应行号里的所有的entry 对象,比较它的哈希值,如果哈希值相同,再去比较join key。

4. 如果join key 相同,则代表probe 成功,拼接左右表的对应列并生成最终的结果。

 

如何将这样的执行过程用向量化实现?

 

1. 从左表里面读取批量数据。

2. 使用CodeGen 技术批量计算hash code 值。

3. 根据hashcode 值,批量查找hash table,得到可能的结果集。

4. 批量比较左右表的join 列值,如果匹配的话,则拼接左右表的对应列并生成最终的结果。

 

与原来行式的火山模型比起来,向量化执行主要差一点在于:

1. 按列计算;

2. 批量计算。

 

image.png

(六)插件集成

计算引擎如何与ADB PG 代码融合?

 

ADB PG 同时支持PG 计算引擎和Laser 向量化计算引擎。优化器会自动根据SQL 的pattern 和扫描的数据量来决定是否使用Laser。如果扫描数据量太少,则使用原生的计算引擎。如果数据量足够多,并且这些SQL pattern 比较适合使用向量化执行引擎的,就使用laser 计算引擎。

 

Laser 引擎的所有代码采用插件模式,代码独立。好处在于代码可以和原生代码之间完全是松耦合关系,不会影响PG 的原生代码,同时可以复用里面的一些函数和数据结构。插件模式还带来一个好处,就是可以实现热升级。因为采用动态库方式,能够在不重启PGdameon 进程的情况下,替换插件,完成升级LASER 引擎。

 

唯一需要修改的是三个stub 函数—ExecutorStart、ExecutorRun、ExecutorEnd。

image.png

 

(七)TPC-H 结果

2020 年5 月20 号,我们完成了TPC-H 30TB 场景测试,拿到了世界第一的成绩。相比于第二名微软SQL Server 2019,整体性能提升了290%,且成本只有SQL

Server 的1/4。

 

通过性能指标统计,Laser 计算引擎对性能提升起了至关重要的价值,相对于PG 计算引擎,性能提升了两倍之多。细分计算引擎的各种优化,其中大半的性能提升都是来自于向量化提升。其次是是JIT 加速,主要来源于表达式的计算。第三来自于是Fusion Scan,针对列存场景下,我们通过Fusion Scan,减少了内存的拷贝,减少了无用的读取。最后还有小部分来自于SIMD 指令的提升。

image.jpeg

三、计算引擎的未来展望

整体的未来转化(以未来一年为计划):

第一:2020 年12 月,支持窗口函数,完成全算子的向量化改造。

第二:2020 年3 月,完成网络motion 重构。

第三:2020 年6 月,完成算子并行执行优化,可以充分利用多核能力。

第四:2020 年9 月,完成优化器适配。优化器不仅适配计划数据书,同时能够根据计算引擎来做动态识别,能够感知到数据的动态变化,再去动态去调整执行计划。

原文链接

本文为阿里云原创内容,未经允许不得转载。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/513923.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

新云网、5G、Wi-Fi 6 Plus,探秘2021通信展上的锐捷网络黑科技

供稿 | 锐捷网络 出品 | CSDN云计算 2021年9月27日&#xff0c;主题为“创新点亮数字化未来”的第三十届中国国际信息通信展览会&#xff08;PT EXPO 2021&#xff09;在北京如期开幕。展会汇聚业内的科技创新技术专家和优秀企业&#xff0c;共同探讨数字化创新的新趋势、新场…

【OpenYurt 深度解析】边缘网关缓存能力的优雅实现

简介&#xff1a; 阿里云边缘容器服务上线 1 年后&#xff0c;正式开源了云原生边缘计算解决方案 OpenYurt&#xff0c;跟其他开源的容器化边缘计算方案不同的地方在于&#xff1a;OpenYurt 秉持 Extending your native Kubernetes to edge 的理念&#xff0c;对 Kubernetes 系…

python的类名一定要大写吗_python 类名

广告关闭 腾讯云11.11云上盛惠 &#xff0c;精选热门产品助力上云&#xff0c;云服务器首年88元起&#xff0c;买的越多返的越多&#xff0c;最高返5000元&#xff01; 如果我从中执行此操作的函数是实例的类派生的基类&#xff0c;我如何找到在python中创建对象实例的类的名称…

Elasticsearch生态技术峰会 | 阿里云Elasticsearch云原生内核

简介&#xff1a; 开源最大的特征就是开放性&#xff0c;云生态则让开源技术更具开放性与创造性&#xff0c;Elastic 与阿里云的合作正是开源与云生态共生共荣的典范。值此合作三周年之际&#xff0c;我们邀请业界资深人士相聚云端&#xff0c;共话云上Elasticsearch生态与技术…

剑指云原生数据库 2.0,阿里云发布全新一站式敏捷数据仓库解决方案

作为基础软件“三驾马车”之一的数据库&#xff0c;其发展历程可追溯到60年前&#xff1a;从上世纪50年代的层次数据库、网状数据库&#xff0c;70年代的关系型数据库&#xff0c;再到90年代的关系型数据库、数据仓库、PC单机数据库和 2000 年的开源数据库&#xff0c;Oracle等…

深度 | 面向云原生数据湖的元数据管理技术解析

简介&#xff1a; 作者&#xff1a;沐远、明惠 背景 数据湖当前在国内外是比较热的方案&#xff0c;MarketsandMarkets市场调研显示预计数据湖市场规模在2024年会从2019年的79亿美金增长到201亿美金。一些企业已经构建了自己的云原生数据湖方案&#xff0c;有效解决了业务痛点…

sql中“delete from 表名”表示_SQL查询语句知识点总结

为什么要学习SQL?数据分析岗位的基础技能&#xff1a;SQL语句和会使用SQL语句操纵数据库软件&#xff1b;数据量增大的工具需求&#xff1a;excel处理十万以内的数据&#xff1b;数据量增大&#xff0c;需要使用更快速便捷的工具分析数据。SQL知识点总结1数据库基础知识什么是…

Serverless 可观测性的过去、现在与未来

简介&#xff1a; 函数计算可观测性经历了 1.0 -> 2.0 的发展&#xff0c;从闭门造车的可观测发展成开源的可观测&#xff0c;从平台的可观测发展为开发者的可观测&#xff0c;从FaaS Only 的可观测演进成了云原生的可观测。 作者&#xff1a;夏莞 背景 Serverless 将成为…

Gartner:全行业投入人工智能,计算机视觉占比最高

编辑 | 宋慧 供稿 | Gartner Gartner最近一项新调研发现&#xff0c;三分之一拥有人工智能&#xff08;AI&#xff09;技术计划的技术和服务提供商企业机构表示&#xff0c;他们在未来两年对人工智能技术的投资将达到100万美元以上。绝大多数将人工智能技术作为主要投资领域的…

爱奇艺大数据生态的实时化建设

简介&#xff1a; 实时化是大数据未来最重要的方向之一。 作者&#xff5c;爱奇艺大数据团队 数据作为互联网时代的基础生产资料&#xff0c;在各大公司企业拥有举足轻重的地位。数据的价值在互联网公司的体现&#xff0c;大致而言可以分成三类&#xff1a; 发掘数据中的信息…

python机械臂仿真_基于Python的3R机器人运动仿真

一、问题描述 如右图所示的三自由度机械臂&#xff0c;关节1和关节2相互垂直&#xff0c;关节2和关节3相互平行。如图所示&#xff0c;所有关节均处于初始状态。 要求: (1) 定义并标注出各关节的正方向&#xff1b; (2) 定义机器人基坐标系&#xff5b;0&#xff5d;及连杆坐标…

AI 事件驱动场景 Serverless 实践

简介&#xff1a; 事件驱动是指事件在持续事务管理过程中&#xff0c;进行决策的一种策略。可以通过调动可用资源执行相关任务&#xff0c;从而解决不断出现的问题。通俗地说是当用户触发使用行为时对用户行为的响应。在 Serverless 场景下&#xff0c;事件驱动完美符合其设计初…

运维质变育新机,华为云能否引领政企运维破局?

头图 | 付费下载于视觉中国 提到IT运维&#xff0c;我们马上想到的&#xff0c;就是“7*24小时待命”、“救火”。作为IT安全运行的保障&#xff0c;长久以来&#xff0c;运维一直都是“不出事看不到价值&#xff0c;一出事全是锅”的角色。例如某企业自动化运维失效导致宕机…

封神-运维大脑 | 日志检测工具

简介&#xff1a; 封神-运维大脑 | 日志检测工具1. 背景目标 阿里云应用业务有问题&#xff0c;云平台监控可以发现问题&#xff0c;但并不能定位到问题根本原因&#xff0c;运维大脑监控底层日志&#xff0c;可快速定位问题原因&#xff0c;帮助现场运维同学解决问题。 运维大…

hive sql练习_经典的SparkSQL/Hive-SQL/MySQL面试-练习题

经典的SparkSQL/Hive-SQL/MySQL面试-练习题​mp.weixin.qq.com第一题需求&#xff1a;已知一个表order&#xff0c;有如下字段:date_time&#xff0c;order_id&#xff0c;user_id&#xff0c;amount。 数据样例:2020-10-10,1003003981,00000001,1000&#xff0c;请用sql进行统…

世纪联华的 Serverless 之路

简介&#xff1a; 2019 年 双11 过后&#xff0c;世纪联华快速上云&#xff0c;将线上核心业务改造为全 Serverless 架构的中台模式&#xff0c;采用“函数计算API 网关OTS”作为计算网络存储核心&#xff0c;弹性支撑日常和大促峰谷所需资源&#xff0c;轻松支撑 618 / 双11 /…

“5G+AI”到底有啥用?这篇漫画告诉你答案…

作者|小枣君来源|鲜枣课堂根据工信部最新的数据&#xff0c;截至8月份&#xff0c;我国5G基站数量已超过百万&#xff0c;达到103.7万个。面对这张全球规模最大的5G网络&#xff0c;我们不禁会思考——它究竟会发挥怎样的作用&#xff1f;它的价值到底体现在哪&#xff1f;它会…

Kubernetes 稳定性保障手册 -- 可观测性专题

简介&#xff1a; 伴随大家对稳定性重视程度的不断提升、社区可观测性项目的火热&#xff0c;可观测性成为了一个很热门的话题&#xff0c;站在不同的角度会产生不同的理解。 我们从软件开发的生命周期出发&#xff0c;尝试形成对可观测性的一个宏观理解&#xff0c;并从 SRE 和…

读懂 Redis 源码,我总结了这7点心得

作者|Magic Kaito来源|水滴与银弹阅读本文大约需要 8 分钟。你好&#xff0c;我是 Kaito。用了这么久的 Redis&#xff0c;也翻了很多次源码&#xff0c;经常有人问我到底怎么读 Redis 源码。一提到读源码&#xff0c;很多人都会比较畏惧&#xff0c;认为读源码是高手才会做的事…

linux c url下载文件,OpenCV教程之使用cmake生成MakeFile时下载文件

在编译OpenCV以及其附加模块时&#xff0c;有时会需要一些第三方的库&#xff0c;如果本地没有&#xff0c;会自动下载&#xff0c;下载地址一般为GitHub&#xff0c;结果当然就是卡死在那里&#xff0c;根本无法下载&#xff0c;下面教大家如何解决这种问题。问题重现比如我在…