Author: 无哈
众所周知,MySQL是为了在线事务处理(OLTP)设计的开源数据库,一直以来弱于对于分析型业务场景的支持。如果有对MySQL数据库中的数据进行分析的业务场景,一般都是需要借助于第三方的ETL工具将数据导入到外部AP型数据库或者专门的数据仓库,然后将分析业务运行其上。这一处理方式对于现有业务系统引入了额外的复杂度和开销:
为了MySQL更好地支持数据分析业务,MySQL官方团队发布了新的分析执行引擎 – Heatwave,遗憾的是目前这一服务仅限于Orcale Cloud Infrastruct上使用。本文尝试结合MySQL Analytic Engine相关说明文档以及RAPID论文梳理一些MySQL分析引擎的基本信息。
HeatWave分析引擎以集群模式提供分析服务,如图1描述,集群包括常规的MySQL数据库节点和多个HeatWave分析引擎节点。应用程序只需要连接MySQL数据库节点,而无需连接到HeatWave节点。所有的查询依然是通过该节点进行分析,优化并生成执行计划。其中HeatWave插件以Secondary Engine的形式负责数据的载入和更新的同步、计算Query在HeatWave引擎执行的cost、生成HeatWave执行计划以及执行计划下发等。
图 1. HeatWave架构图
HeatWave将所有数据以列存格式存储在内存中,基本数据组织形式如图2所示。
图 2. HeatWave存储布局
现代计算设备随着更多特性的实现也导致能耗需求更大,为了满足云数据中心提高能耗比的需求,一般有两种考虑方向:
HeatWave Engine选择的是后者,其针对关系型数据处理场景的业务模式进行硬件定制和相应的数据处理软件系统设计上适配。
HeatWave Engine的硬件核心部分称作Data Processing Unit(DPU),该SoC主要包括dpCores、Data Memeory/Cache、Data Move System(DMS)等特定组件,如图3所示。
图 3. RAPID DPU
其中每个DPU包含32个dpCores,并均分为4组微服务单元以做数据并行处理。
dpCore内部采用类MIPS的64bits精简指令集架构,专门针对SELECT/JPIN等算子设计了单指令周期的BVLD(bit-vector load)、FILT(filter)、CRC32等指令。每个dpCore包含32KB的SRAM用作临时存储空间(DMEM),以及部分L1/L2 cache。dpCore实现了算数逻辑单元和Load-Store的双流水线。
RAPID SoC没有设计内存管理单元,而是采用直接寻址的访问方式。访问DMEM数据的主要方式是通过DMS子系统,其负责DRAM和dpCore之间的数据复制,利用DMS来操作DRAM和DMEM省去了通用CPU架构中的cache预取/替换等复杂逻辑。
Atomic Trasaction Engine(ATE)组件负责联通dpCores、消息传递、管理DMEM指针、中断处理以及信号同步等来完善dpCore之间的通信。
MySQL中的RAPID插件扩展了cost model,可以计算query在HeatWave节点上执行的cost以帮助优化器做决策,并且可以支持完整query和query片段下推。
RAPID插件基于pull的方式采用迭代器模型来执行算子和获取结果,RAPID Engine节点基于push的流式模型来处理RAPID插件生成并下推的执行计划。
限于篇幅,本文不逐个描述各个算子的优化以及执行流程。
HeatWave是作为插件以secondary engine的方式配合primary storage engine一起使用的,在部署好HeatWave集群后,就可以根据业务中的分析查询的特点来对Primary Engine上的表做变更已启用分析查询引擎,基本步骤包括:
RAPID使用限制包括:
本文粗略梳理Orcale Cloud Infratstructure推出的MySQL Analytic Engine服务中的HeatWave引擎的存储、RAPID引擎以及实践操作相关的信息。
对比来看,PolarDB存储引擎团队从尽可能利用计算资源的角度出发,设计了基于PolarDB的全内存列式存储,其特点: