AnalyticDB MySQL 技术架构

文章目录

- 一、行业趋势与技术背景
- - 1、技术发展趋势
  - 2、企业面临的技术挑战
- 二、整体技术架构
- 三、计算层技术
- - 1、架构形态演进
  - [2、羲和 MPP 模式](#2、羲和 MPP 模式)
  - [3、羲和 BSP 模式](#3、羲和 BSP 模式)
  - [4、Spark 引擎](#4、Spark 引擎)
  - 5、资源组和弹性调度
- [四、Serverless 存储层](#四、Serverless 存储层)
- 五、核心组件与协作关系
- - 1、核心组件映射
  - 2、查询与写入路径
- 六、架构设计要点
- - 1、设计原则
- 七、关键术语
- - 1、术语表
- 八、官方资料

云原生数据仓库 AnalyticDB MySQL 版是一套面向 PB 级数据分析的云原生实时数据仓库。其核心技术思路是将访问、计算与存储解耦：访问层统一接入、解析和调度；计算层组合自研羲和引擎的 MPP、BSP 模式与 Spark 引擎；存储层通过共享存储、冷热分层、索引、缓存和资源隔离，同时服务高性能在线分析与低成本离线处理。

从技术演进角度看，AnalyticDB MySQL 由早期存算耦合的数仓架构，逐步发展为存算分离、计算和存储独立弹性、湖仓一体以及 Serverless 资源模式。目标是在同一平台内平衡实时写入、交互式查询、复杂批处理、ETL、机器学习和开放数据湖访问。

一、行业趋势与技术背景

1、技术发展趋势

阿里云官方文档将数据技术的发展概括为四个方向：数据规模持续增长、处理实时化、数据类型多模化、数据库与数据平台加速上云。文档引用的 IDC、Forrester 和 Gartner 数据属于其发布时的行业预测，用于说明架构演进背景，不应直接视为当前年度统计结果。

技术趋势	对数据平台的要求
数据规模增长	支持 PB 级容量、并行读写、水平扩展和高吞吐处理
处理实时化	从传统 T+1 批处理转向 T+0，缩短数据写入到可分析的时间
数据多模化	同时管理结构化、半结构化及非结构化数据，并提供统一访问方式
数据平台云化	使用托管服务、弹性资源和按需能力，减少基础设施管理负担

2、企业面临的技术挑战

企业在上述趋势下通常面临四类技术挑战：

数据散乱且口径不一致：数据分布在数据库、日志、对象存储和既有数仓中，不同格式和访问方式增加整合成本。
分析时效不足：传统批处理存在较长延迟，难以支撑实时推荐、精准营销、广告分析、物流和风控等业务。
系统组合复杂：多套大数据组件带来开发、权限、可靠性、容灾和运维负担，业务团队难以聚焦数据价值。
资源成本偏高：数据规模和业务负载存在峰谷与不确定性，需要存储和计算分别弹性调整，避免长期保有闲置资源。

AnalyticDB MySQL 的架构设计正是围绕这些问题展开：统一 SQL 与访问入口，以分布式计算处理规模和并发，以存算分离解决弹性问题，以湖仓一体覆盖多种数据类型和工作负载。

二、整体技术架构

1、架构概览

AnalyticDB MySQL 采用云原生架构，支持计算与存储分离、冷热数据分离、高吞吐实时写入和强一致性，并同时承载高并发交互查询与大吞吐批处理。硬件部署层支持 Intel、AMD 芯片和 x86 指令集。

产品于 2012 年首次在阿里巴巴集团内部上线，随后持续支撑电商、广告、物流、文娱、旅游和风控等在线分析业务，并从 2014 年开始正式对外提供服务。整体架构是在大规模核心业务验证基础上逐步演进形成的。

架构层次	核心组件或机制	主要职责
访问层	Multi-Master 协调节点	协议接入、SQL 解析和优化、实时写入分片、数据调度与查询调度
计算层	羲和 MPP、羲和 BSP、Spark	分布式查询、复杂批处理、ETL、机器学习与离线分析
存储层	共享存储、Multi-Raft、行列存储、索引与缓存	实时强一致写入、冷热分层、在线查询加速和低成本离线存储
云原生资源层	预留资源、弹性资源、Serverless 资源组	提供独立扩缩容、物理隔离和按使用量分配资源的能力

2、访问层

访问层由可线性扩展的 Multi-Master 协调节点组成。它对外承接协议连接，对内完成 SQL 解析与优化、数据写入分片、数据调度和查询调度。统一元数据、权限、开发语言和传输链路，使不同计算与存储能力通过一致入口提供服务。

3、计算层

计算层由自研羲和计算引擎与 Spark 引擎共同组成。羲和引擎面向实时分析和大规模 SQL 计算；Spark 补充复杂离线处理、数据科学和机器学习场景。计算资源可以通过资源组进行隔离，并根据业务负载独立扩缩。

4、存储层

存储层基于共享存储构建分布式、实时、强一致和高可用的数据引擎。数据通过分片和 Multi-Raft 并行写入；实时热数据位于高性能介质，全量和低频数据位于低成本存储，并通过行列存储、索引及多级缓存提升查询性能。

5、开放湖仓访问

内置数仓存储通过统一 Storage API 和 Arrow 数据访问格式向外开放，Spark、Presto 等开源计算引擎可以访问内部数据。平台同时支持 Iceberg、Hudi、Delta Lake、Paimon 等数据湖生态，减少封闭存储带来的数据锁定。

6、企业版与基础版可靠性差异

对比项	企业版	基础版
存储副本	三副本存储	单副本存储
高可用	支持服务秒级恢复、自动故障检测、故障节点摘除和副本重建	不提供高可用服务
部署能力	支持跨可用区部署	适用于无需高可用的低成本场景
备份	配合全量和增量备份提供数据保护	功能特性与企业版接近，但底层可靠性形态不同
建议用途	对可靠性有要求的开发、测试和生产环境	对数据高可用没有要求、关注低成本热数据存储的业务

7、历史数仓版架构

数仓版主要面向高性能在线分析，由接入层、计算引擎和存储引擎组成。接入层使用 Multi-Master 协调节点；计算引擎融合分布式 MPP 与 DAG 执行，并结合智能优化器处理高并发和复杂 SQL 混合负载；存储引擎基于 Raft、数据分片和 Multi-Raft 实现实时强一致及高可用，并通过冷热分层、行列存储和智能索引优化性能。

数仓版借助云原生基础设施对计算节点进行弹性调度，并通过跨可用区部署、故障检测、节点摘除、副本重建、三副本存储及全量和增量备份保障可靠性。

8、历史湖仓版架构

湖仓版是在数仓版基础上形成的在离线一体架构，围绕数据的采集、存储、计算、管理和使用进行升级。数据管道 APS 用于接入数据库、日志和大数据平台中的数据；访问层统一计费单位、元数据、权限、开发语言和传输链路；计算与存储层同时组合自研引擎和开源生态。

湖仓版的自研侧包括羲和计算引擎和玄武存储引擎，开源侧包括 Spark 计算引擎和 Hudi 存储引擎。不同引擎可以互相访问：羲和通过 MPP 和 BSP 兼顾交互式与批处理 SQL，Spark 承担复杂离线处理和机器学习；一份全量数据通过热存储、低成本存储、索引与缓存分别服务在线和离线分析。

三、计算层技术

1、架构形态演进

AnalyticDB MySQL 的计算架构从存算耦合逐步演进为存算分离与 Serverless。不同形态的核心区别在于计算、存储能否独立扩缩，扩缩时是否需要迁移数据，以及是否支持资源组隔离和按需申请资源。

架构形态	资源组织	扩缩容特点	适合负载
数仓版预留模式	Shared-Nothing，计算与存储耦合	通过调整节点数扩缩；计算和存储比例不能独立配置，扩缩可能触发数据迁移	稳定、高性能的在线分析负载
数仓版弹性模式	统一服务化存储层与独立计算层	计算和存储可分别扩缩；计算扩缩无需搬迁数据；支持资源组及分时弹性	多业务、混合负载和明显峰谷场景
湖仓版	存算分离与 Serverless 资源组	查询按需申请计算资源，结束后自动释放；支持按实际使用量计量	ETL、长时间批处理、数据湖访问和不规律负载
企业版	融合湖仓版和数仓版能力，多副本	同时提供预留性能、弹性资源、资源隔离与冷热分层	需要高可用的开发、测试和生产环境
基础版	与企业版功能接近，单副本	不提供高可用服务，侧重低成本热数据存储	对高可用没有要求的场景

2、羲和 MPP 模式

MPP 模式采用流水线式并行执行，适合低延迟交互式分析。执行过程中数据在算子间持续流动，能够快速返回结果，但不以低成本、高吞吐的长时间离线任务为主要目标。

3、羲和 BSP 模式

BSP 模式将任务组织为 DAG，分阶段、分批调度，并允许中间结果落盘。它适合有限资源下的大数据量计算、复杂 SQL 和长时间批处理。系统能够在 MPP 查询超过一定执行时间时自动切换到 BSP，避免复杂任务持续占用不合适的执行模式。

4、Spark 引擎

Spark 用于更复杂的离线处理、ETL、数据科学和机器学习任务。计算层与存储层打通，Spark 资源组可以直接处理仓内或湖上数据。它与羲和引擎形成互补：羲和侧重实时 SQL 与交互分析，Spark 侧重大规模离线和可编程计算。

5、资源组和弹性调度

计算资源可以划分为多个物理隔离的资源组，将在线查询、ETL、临时分析和不同业务域分开运行。分时弹性适合可预测的周期负载；Serverless 资源组适合突发或不规律查询，按查询需求申请资源并在任务完成后释放。

四、Serverless 存储层

1、存储架构与负载模式

Serverless 存储层建立在计算存储分离和云原生资源池化之上。存储资源可以独立扩缩，同时支持横向弹性------增加存储节点，以及纵向弹性------提升存储节点的 CPU 和内存。用户无需直接管理硬件资源。

一份数据可以同时服务在线分析和离线处理，但两类负载对介质、延迟、吞吐和隔离的要求不同：

负载模式	数据与资源路径	主要目标
在线分析	热数据位于在线 EIU 或高性能存储，使用索引与缓存加速	高频多维检索、复杂交互查询和低延迟响应
离线处理	全量数据位于低成本对象存储，弹性计算资源组高吞吐读取	大规模扫描、ETL、批处理与更强隔离性
在离线混合分析	在线查询使用 EIU，归档数据进入对象存储；离线任务按需直读对象存储	在一套系统中同时保证在线性能与离线成本

2、分层存储

实时数据位于 SSD 等热存储，提供低延迟写入和行级实时性；全量数据按微分区（Micro Partitions）组织在 OSS、PANGU 等低成本、高吞吐介质中。微分区用于降低传统数仓常见的 I/O 放大和写放大，并借助对象存储扩展容量。

3、查询加速

存储层支持列投影、谓词下推和分区裁剪，并组合两种索引路径：Skipping Index 面向高吞吐扫描过滤，Secondary Index 面向低延迟点查和过滤。系统根据查询特征自动选择访问方式。多级缓存由本地内存、本地 SSD 和远程全局分布式缓存组成，用于加速仓内与湖上数据。

4、弹性扩缩

存储与计算可以独立弹性调整。全量数据在扩缩容过程中无需整体搬迁，系统通过元数据操作完成资源变化，降低扩缩容对数据路径和运行负载的影响。

5、资源隔离

独立部署的 Build Service 承担 Compaction 等高 CPU 消耗的离线操作，使存储后台任务与在线查询隔离。在线查询与离线查询也可以使用不同计算资源组，避免大规模 ETL 挤占交互查询资源。

6、湖仓一体

存储接口和数据格式对外开放，Spark、Presto 等开源引擎可以访问内部数据；系统也能访问和管理 Parquet、Hudi 等开放格式，并支持半结构化、非结构化数据及全文检索。湖加速通过采集湖上数据统计信息改善查询计划，从而提升湖查询效率。

五、核心组件与协作关系

1、核心组件映射

组件或机制	所属层	与其他层的协作方式
Multi-Master 协调节点	访问层	接收连接和 SQL，将写入与查询分发到对应分片、计算引擎和资源组
羲和 MPP	计算层	从热存储、索引和缓存获取数据，执行低延迟并行查询
羲和 BSP	计算层	按 DAG 分批执行复杂任务，并使用落盘能力控制有限资源下的大规模计算
Spark	计算层	通过开放存储接口访问仓内及湖上数据，执行 ETL、批处理和机器学习
Multi-Raft	存储层	配合数据分片实现并行实时写入、强一致和高可用
EIU	存储与在线资源	承载热数据和在线分析所需的存算资源，保障行级实时性与交互性能
对象存储	低成本存储层	保存全量及归档数据，向弹性计算资源组提供高吞吐读取
多级缓存	存储加速层	缓解远程数据访问延迟，加速在线查询和湖仓查询
Build Service	存储后台服务	执行 Compaction 等离线维护任务，与在线查询资源隔离
资源组	计算资源管理	隔离在线、离线及不同业务负载，支持预留、分时弹性或 Serverless 模式

2、查询与写入路径

典型查询路径可以概括为：客户端连接访问层，协调节点完成 SQL 解析和优化，根据任务特征选择 MPP、BSP 或 Spark，并调度到指定资源组；计算引擎通过索引、缓存、热存储或对象存储读取数据，完成计算后向访问层返回结果。写入路径则由访问层完成数据分片，经存储引擎和 Multi-Raft 并行写入，同时维护实时数据、索引及后续分层存储。

六、架构设计要点

1、设计原则

一份数据服务多种负载：通过热存储、对象存储、索引和缓存形成不同访问路径，减少在线与离线系统之间的数据复制。
计算与存储分别弹性：业务查询增加时扩计算，数据容量增长时扩存储，降低固定比例扩容造成的浪费。
执行引擎按任务选择：MPP 面向低延迟，BSP 面向复杂批处理，Spark 面向可编程离线和机器学习。
工作负载物理隔离：资源组和 Build Service 将在线查询、离线计算及后台维护分开，降低相互干扰。
开放接口连接湖仓生态：通过 Storage API、Arrow 及开放表格式连接 Spark、Presto 和数据湖。
元数据驱动弹性：扩缩容尽量通过元数据调整完成，避免移动全量数据造成长时间停顿。

七、关键术语

1、术语表

术语	含义
MPP	大规模并行处理，通过多个计算节点并行执行查询，适合低延迟分析
BSP	批同步并行模式，以 DAG 分阶段调度任务，适合复杂和大规模批处理
Shared-Nothing	节点拥有独立计算与存储资源的分布式架构，扩缩节点通常伴随数据重新分布
存算分离	计算资源与存储资源解耦，可分别扩缩和调度
EIU	在线分析相关的存储 I/O 或存算资源单元，用于承载热数据和在线负载
Multi-Raft	在多数据分片上并行使用 Raft 的机制，用于实时写入、一致性与高可用
Micro Partitions	全量数据的微分区组织方式，用于降低 I/O 与写放大并提高扫描效率
Skipping Index	面向高吞吐扫描的跳过索引，用于快速排除无关数据区域
Secondary Index	面向低延迟过滤和点查的二级索引
Serverless 资源组	按查询需求申请并在任务结束后释放的计算资源组