《云原生一站式数据库技术与实践》——二、云原生数据仓库AnalyticDB MySQL高性能存储引擎(1) https://developer.aliyun.com/article/1231659?groupCode=aliyundb
最上层为JDBC 协议的接入层。一个insert into 语句由JDBC 接入后向下发送，首先会转为Raft command，通过Raft层发送给存储节点。计算层的主要功能是外表的高并发读，读取到的数据会被批量写入到存储节点。
存储节点类似于分库分表的架构，任意表会被均匀地拆到下面的若干个Shard之上。每个Shard 包含两个数据副本和一个日志副本，它并不是完全标准的Raft，而是2+1 的模式。两个数据副本负责承接写入和查询，日志副本仅参与投票，保证整体高可用的同时也节省了一份数据存储的开销以及一份用户写入的开销。
Shard 内部最上层为query merger，相当于存储层的查询接入，负责接入下推到存储的计算算子。存储引擎内部的数据分为实时数据和历史数据。
实时数据面向写进行优化，具备相对良好的写入能力，它只有数据文件和粗糙索引，不具备复杂精确索引。除此之外，还有版本管理器和delete bit-set，便于修改。实时数据通过build 转化为历史数据。历史数据可以认为是经过读优化的数据，具备良好的读性能。
在历史数据中，除了数据文件以外，还有多种类型的索引，包括倒排、BKD、位图等多种类型的索引。构建过程中还进行了数据的冷热分层。
准实时数仓的写入需求一般为高吞吐（日志数据）、低延迟（业务数据），还需要兼顾写入性能以及查询性能。
前端节点为无状态，具备良好的可拓展性，可以任意横向扩展，进行高并发的写入。Raft 在相对成规模的生产集群中，通常有数千个Raft group，互相之间完全独立，相当于数千个Raft Group 可同时进行并发写入。
一条insert 语句从前端节点转成Raft command，进入Raft 状态机进行消费之后，会转发给同步层的Dispatch queue。每个Raft group对应一个shard 或分库。若用户创建了N 个表，每个分库中有N 个分表。即使Raft 的并发度足够高，用户分表数也可能更多，因此需要在Dispatch queue 中进行进一步拆分，使得写并发更高。除此之外，Dispatch queue 还负责内存管理和反压工作，写入之后会进行内存控制和反压，保证不会被写挂，防止影响线上查询。
消费到存储层之后会进行group commit 操作，在table engine 前进行攒批。Append only的写模式能够保证非常良好的写入性能。
ADB 内部实现了Snapshot 功能，每隔一段时间会打快照，使产品具备time travel查询能力的基础，但time travel 的功能并目前没未对用户放开。同时，我们会定期将snapshot 进行刷盘，落盘之后做checkpoint。checkpoint 可以与raft log 进行配合，重启之后可从某个checkpoint 位点恢复，再消费少量的增量log，做到快速恢复。Snapshot 还会作为build 只读数据源进行异步构建，构建索引和分区。
上图左侧为Replace的原子性实现
《云原生一站式数据库技术与实践》——二、云原生数据仓库AnalyticDB MySQL高性能存储引擎(3) https://developer.aliyun.com/article/1231657?groupCode=aliyundb
