1. 产品架构
AnalyticDB MySQL版采用云原生架构，计算存储分离、冷热数据分离，支持高吞吐实时写入和数据强一致，兼顾高并发查询和大吞吐批处理的混合负载。其产品架构包括接入层、计算引擎、存储引擎。
• 接入层：协议层接入、SQL解析和优化、数据和查询调度。
• 计算引擎：
ü 支持高并发和复杂SQL混合负载，采用DAG和MPP支持不同负载。
ü 弹性调度，可根据业务需求做到分钟级甚至秒级扩展，实现了资源的有效利用。
• 存储引擎：
ü 分布式实时强一致高可用存储引擎。
ü 利用分层存储实现冷热分离降低成本。
ü 通过行列存储和智能索引提升性能100%。
2. 优化器介绍
优化器包括四个部分：统计层、代价估计层、优化器层、缓存层，其功能分别如下：
• 统计信息：提供多样的统计信息；提供自动的统计信息收集；提供动态采样。
• 代价预估和代价模型。
• 基于规则的RBO框架和基于代价的CBO框架。
• 通过缓存来提供优化器的高效性，可介入、可运维。
3. 弹性计算层
弹性计算层架构图
如上图，计算引擎采用弹性计算引擎，支持资源组隔离、弹性扩容、2000多个工作站、大规模ETL、混合负载、分时弹性等。
1) 查询执行计划
语句
select count() from customer left join lineitem on customer.c nationkey=lineitem.l_partkey; |
逻辑执行计划：用户下发SQL，前端节点负责解析SQL，生成分布式执行计划，下发到计算节点和存储节点执行，执行完成后，将结果返回给前端节点。
ADB中SQL执行主要概念有如下三个：
• Stage：为了让Query能够在多台机器上并行执行，会将执行计划拆分成多个阶段（Stage），每个Stage会产生多个Task进行执行。
• Task：负责具体计算的执行，是Stage在某一个Worker或者Executor上的实例。
• Operator：对应一个相对独立的计算单位，比如过滤、投影、聚合等操作，作用于输入数据，并产生输出。
2) 查询执行模式
a) Interactive模式
• 场景：适合交互式查询，对响应时间有较高要求，查询Query不高，资源充足。
• 特点：MPP pipeline方式执行，即一个查询的所有分布式执行任务会被同时调度执行，完全基于内存进行计算，大查询消耗资源多。
b) Batch模式（E系列支持）
• 场景：适合ETL场景，作业执行时间长，对RT要求低，计算数据量大，计算逻辑复杂，但资源较为有限。
• 特点：
ü BSP方式执行，即StageByStage方式调度执行分布式任务。
ü 内存不足时自适应下盘算子状态数据。
ü Stage之间的数据传输（Exchage/Shuffle）依赖本地磁盘和对象存储。
ü 大查询/ETL离线任务资源消耗可控。
4. 存储层
存储层架构图
在存储层架构中，ADB MySQL支持实时任务的在线存储和离线任务的离线存储。在线存储通过异步更新的方式进入到离线存储，同时这两种存储会通过storage SDK的方式对外提供统一的存储接口。
1) 高吞吐写入
AnalyticDB存储层具有高吞吐写入的特点，采用玄武分析存储引擎，为用户提供高可靠、高可用、高性能、低成本的企业级数据存储能力，是AnalyticDB实现高吞吐实时写入、高性能实时查询的基础支撑。
2) 高可用
AnalyticDB在存储层使用Raft协议，在多副本之间保障数据的一致性，同时具有高可靠、高可用性，当Worker Group副本失效时，Raft协议通过多数派保证系统的正常运行。增量数据是通过异步构建的方式加载到全量数据，实现了冷热数据的分层以及数据的分级管理。
3) 行列混合存储
• 存储层是行列混合存储，玄武存储引擎支持行列混存和行存的存储格式，其中行列混存是一种以列存为基础兼顾行存的模式，类似于Hadoop中的ORC/Parquet格式。
• 不同的是，玄武的行列混存不仅兼顾分析类的列裁剪和大吞吐扫描性能，而且结合其行对齐的能力，可以实现很好的随机查找性能，这对于任意多维索引过滤的场景也拥有出色的性能优势。
4) 自适应索引
存储层采用自适应索引，加快数据的检索。
如图，在执行该sql时，条件“id=123”、“ts between and”会建立BKD索引，条件“NOT”采用Invert索引，“json_extract”采用JSON处理，“name like ‘bob%’”采用全表扫描scan模式，对于不同条件下产生的结果，通过联合或并的操作产生Row Ids的集合，最后通过Row Ids集合获取最终数据。
