《云原生一站式数据库技术与实践》——二、云原生数据仓库AnalyticDB MySQL高性能存储引擎(3) https://developer.aliyun.com/article/1231657?groupCode=aliyundb
对于单机存储引擎，build 除了构建索引、分区、排序等建模之外，需要兼顾实时数仓的查询和写入性能，因此，我们实现了以下三个能力：
第一，基于多版本控制的细粒度锁构建过程。实时数据负责承接写入，实时数据和历史数据共同承接查询。单存储引擎收到build 命令后会进行split，将实时数据和历史数据切分为ReadonlySnapshot，还构建了新的实时数据和delete manager。ROSnapshot 作为数据源进行异步构建，新的实时引擎和delete manager 用于承接写入。切出的ROSnapshot、实时数据以及delete manager 共同承接查询。ROSnapshot 异步构建的过程对查询和写入完全没有受到任何影响。
Delete manager 是对ROSnapshot 的删除标记，即对新的历史数据的删除标记。但因为此时还在构建过程中，新的历史数据还未产生，因此先用delete manager记录删除。异步构建执行完成之后，会将新的历史数据替换掉ROSnapshot。替换之前会对delete操作进行进行replay。替换完成之后，也意味着新的历史数据包括其数据建已经完成。
另外，我们对构建过程的查询和写入也进行了拆解。如果需要对历史数据进行修改，一定会在历史数据里对ROSnapshot 标记为删除。一个delete会记录两份，一份是Bitset，方便查询后做归并，纯内存，因此查询性能较高；另一份为PK Entry，是log的格式方便顺序读写。
实时数据不牵扯到对历史数据的修改，因此直接进行追加写即可。
ADB 整体是一个分库分表、多副本的架构。因此一个表的build 任务会有非常多的子任务（分库数*副本数）。考虑到可拓展性和可运维性，目前我们选择使用FN 做全局任务管理，leader 节点生成全局plan，方便运维。
同时，我们也在做另一种调度方式，每个Raft leader 进行独立管理。其优点在于拆得足够散，调配更加灵活。而且Raft leader 在存储节点可以获取到更全面、更实时的信息，包括行数、worker 的负载等。当然，这也带来了一定的运维复杂度。
除此之外，还以Raft作为控制链路，因为控制链路必然需要高可靠的保证。我们需要副本间协同工作，如果没有高可靠保证，则副本间很可能不一致，导致现场处理非常复杂。相当于直接复用了Raft 的数据链路作为控制链路。以保证任务控制的command 一定能收到，且副本间一致。
Split 之后，只有leader会进入真正的merge 状态，进行扫描、构建索引、构建分区，然后将扫描结果上传到DFS。上传结束之后，再看follower，leader在merge时follow 会进入waiting 状态，直到被告知leader 已经结束任务，将构建完成的热数据下载到本地。如果是冷数据，会直接应用层面的link。全部完成之后，leader和follower同时切换上线。
一个ECS 往往分布着多个Raft成员，因此只要保证shard 的leader足够均匀，即可保证每个机器的负载基本相同。
《云原生一站式数据库技术与实践》——二、云原生数据仓库AnalyticDB MySQL高性能存储引擎(5) https://developer.aliyun.com/article/1231653?groupCode=aliyundb
