数据模型
AnalyticDB 采用标准的关系数据模型，支持标准的 SQL 访问（兼容 MySQL 协议）。为了实现系统扩展，AnalyticDB 支持量两级分区能力。如下图所示，数据根据 id 列分到50个 partition，称为 primary partition；在 primary partition 内部可以根据，再根据 dob 列来再进行分区（subpartition），并设置保留12个分区。subpartition 通用采用时间列进行分区，用于高效的支持时间范围查询以及数据生命周期管理（TTL)。
架构总览
AnalyticDB 主要包含 Coordinator、Write Node、Read Node 三种类型的节点。Coordinator 通过 JDBC/ODBC 连接的方式接受客户端的读写访问请求，根据请求类型分派到 Write Node、Read Node。Write Node 主要负责处理写请求，包括 INSERT、DELETE、UPDATE、FLUSH（强制数据持久化）；Read Node 则主要负责 SELECT 查询请求。
AnalyticDB 内置通用的流式执行引擎，数据以 Column Blocks 的形式在执行引擎中流转，所有的数据处理均在内存中完成，不同的处理阶段管道化执行，保证系统的高吞吐与低延时。
读写分离
AnalyticDB 读写节点物理隔离，大化读写处理能力，且尽量相互不影响。
高写入吞吐
Write Node 中一个主节点会被选为 Master（通过 Zookeeper ），集群的写入协调分配由 Master 负责。Write Node 接受到写入的 SQL 语句后，将其缓存在内存 Buffer，并周期性的以 Log 形式存储到 Pangu 分布式共享存储；当盘古上的 Log 文件达到一定数量时，AnalyticDB 会发起 MapReduce 任务将其转为数据文件，并构建全量索引。
实时读
每个 Read Node 负责部分 Partition 的读，由 Coordinator 来协调分配，通过副本机制保证读取的高并发和可靠性。Read Node 根据分配的 Partition 进行初始化，并周期性从 Write Node 拉取新的数据更新，Write Node 相当于同时作为读缓存节点。
由于新的写入需要从 Write Node 远程获取，AnalyticDB 提供 realtime和 staleness两种读模式；前者保证能读到新的写入，而后者则有一定范围的延迟但性能更高，AnalyticDB 默认采用 staleness策略。
