云原生一站式数据库技术与实践.pdf

封面页（此页面将由下图全覆盖，此为编辑稿中的示意，将在终稿 PDF 版中做更新）目录 一、云原生分布式数据库 PolarDB-X 技术架构.3 二、云原生数据仓库 AnalyticDB MySQL 高性能存储引擎.19 三、降本增效，阿里云一站式数据库上云最佳实践.30 一、云原生分布式数据库 PolarDB-X 技术架构 3 一、云原生分布式数据库 PolarDB-X 技术架构 作者：黄贵，阿里云 PolarDB-X 数据库研发负责人 PolarDB-X 是一款云原生分布式数据库，为存储计算分离的分布式数据库架构，由以下几个组件构成：元数据服务（GMS）。GMS 是一个高可用集群，利用 Paxos 协议实现数据的高可用，负责存储全局的元数据，包括数据的分片、数据节点计算节点的拓扑信息以及日志节点拓扑信息，还负责提供全局授时的服务，用于判断数据的全局可见性，提供外部一致性事务保证。计算节点。计算节点无状态，负责接收应用发来的 SQL，任意计算节点都可以完成 SQL 的解析、重写、优化、转化为物理执行计划并执行，支持 MPP 的执行框架，负责整个计划的调度与执行，并最终返回结果。数据节点。是数据存储的载体，同时也负责单机执行计划的执行。数据节点会组成复制组，每个组由 Paxos 一致性协议保证数据的强一致的高可用，为了横向的扩展能力会将其切分为很多分片。数据片会根据一定的规则分布在各个 DN复制组上。日志节点。提供全局一致的 Binlog 能力，兼容 MySQL 生态。日志节点输出的全局一致 Binlog 完全兼容单机 MySQL 提供的 Binlog，因此可以将整个 一、云原生分布式数据库 PolarDB-X 技术架构 4 PolarDB-X 看作单机的 MySQL 来使用，包括原来的生态、对接的下游数仓、大数据类的生态，都可以通过 CDC 消费日志。PolarDB-X 架构在阿里云平台上，包括生命周期的管理、备份、容灾、数据迁移、数据的 DevOps、SQL 的全流程诊断、DAS 等都依托于云平台提供的一整套数据库服务。PolarDB-X 作为分布式数据库，具有以下三个特点：原生 MySQL 生态。提供完全兼容 MySQL 的能力，包括语法、语义、功能、协议以及生态的兼容。原生的 MySQL JDBC 的 connector 或 Java、Go 等版本的客户端 connector 都可以直接连接 PolarDB-X，享受完全一致的体验。生态的兼容方面，利用 CDC，PolarDB-X 既可以作为 MySQL 的备机，通过 Binlog同步数据，使用 MySQL 的 replication 功能，实现主备高可用的模式，也可以作为一个大的 MySQL 数据库，通过 CDC 同步给下游的数据生态系统。一体化透明分布式。PolarDB-X 希望用户不再需要关注数据分布的细节，也无需为此做太多优化，我们希望尽可能地为用户提供与单机数据库一致性的体验，不管是建表还是应用均无需做任何改变即可享受到分布式数据库的扩展能力。降低用户的使用门槛。另外，PolarDB-X 支持手工分区模式，按实际业务需求进行调优。分布式主要体现在自动扩展、分布式事务以及 Online DDL。一、云原生分布式数据库 PolarDB-X 技术架构 5 企业级数据库的能力，包括强一致数据的高可用、支持 HTAP 以及对于数据安全的保障。分布式数据库并不是新技术，只是早期的分布式数据库更多地存在于学术界，作为研究对象。2000 年左右，互联网开始蓬勃发展，业内意识到了单机数据库以及集中式数据库的局限性，无法应对互联网业务增长带来的海量数据以及对于大规模数据的高并发、高吞吐的写入需求。为了增强数据库的扩展性，逐渐发展出了 NoSQL。而 NoSQL 数据库为了扩展性，放弃了很多关系型数据库的实用特性，包括 ACID 等，使得应用不得不编写复杂的逻辑来尽可能保证数据一致性，变得更复杂。后来，关系型数据库和分布式技术相结合发展出了 NewSQL，这也是分布式数据库从理论走向应用的发展阶段，彼时的分布式数据库更多地被大型互联网公司使用。到了云时代，分布式数据库作为云产品为用户提供通用的数据库服务，真正进入商业化发展的阶段，不仅关注扩展性，还关注易用性以及企业级的特性，因此也必然会出现兼容性、数据库运维等能力上的要求。分布式数据库面临几个较为突出的问题：兼容性：传统数据库的应用如何更便捷的迁移到分布式数据库上？使用门槛：用户有使用分布式数据库的诉求，但是又不希望投入太多学习成本。扩展能力：分布式架构能否实现真正的线性扩展？一、云原生分布式数据库 PolarDB-X 技术架构 6 运维复杂度：分布式系统天然具备复杂性，如何应对运维管理上的挑战？在分布式数据库上保证 ACID、保证数据一致性比传统数据库更具难度，比如在数据量巨大的分区表上做 DDL 或创建索引需要付出高昂的代价。PolarDB-X 全面兼容 MySQL 数据库，包括功能上的兼容和生态上的兼容。功能上并不追求百分之百的兼容。上图中圆圈为 MySQL 的能力边界，涂色的部分是PolarDB-X 目前已经覆盖的能力。部分 PolarDB-X 的能力与 MySQL 的实际能力依然存在一定差距，也有部分超出了 MySQL 的能力。判定兼容性的原则需要以用户诉求为依据，我们会优先覆盖常用功能，对于不常用的功能，会有选择性地支持，并逐步补全。目前，PolarDB-X 对 MySQL 的大部分功能基本已经实现兼容，也包括扩展性的能力，比如存储过程触发器、外键等等在分布式数据库上较难支持的功能，而高可用容灾、高并发读写等方面的能力已经远超出现有 MySQL 的能力。一、云原生分布式数据库 PolarDB-X 技术架构 7 生态的兼容主要利用全局一致的 Binlog，即 CDC。CDC 是一个高可用集群，能够提供全局一致的 Binlog 服务。PolarDB-X 作为分布式数据库，存在很多数据节点，每个数据节点都有日志流。为了保证数据一致，CDC 会对多机上的日志做归并、排序、整流，最终提供与用户事务发生顺序一致的全局 Binlog 日志流。日志流完全兼容MySQL 单机 Binlog，格式完全一致。下游生态系统消费 Binlog 时，可以将其看作单机 MySQL 来使用。一、云原生分布式数据库 PolarDB-X 技术架构 8 分布式系统作为云上的服务，希望为用户提供集中分布式一体化体验。PolarDB-X 提供了标准版和企业版两种形态，两者可以平滑迁移。标准版百分之百兼容单机MySQL，提供了高可用的能力。企业版提供了典型的分布式能力。对于很多用户而言，如果当前业务规模不大，则可以先选择标准版。业务规模扩大以后，无需任何修改即可平滑迁移至企业版。原先在单机上建的表能够自动变为分布式的表，无论是查询还是事务，使用上均没有任何区别。也可以通过 DDL 语句指定数据分区的规则，保留了按照业务特性进行数据分布的需求。集中分布式一体化有两层含义：其一，既能满足集中式的需求，也能满足分布式需求。其二，集中式到分布式可实现完全透明转化。切换到分布式形态时，如何保证集中式的体验？PolarDB-X 提供了库级 AUTO 模式，数据分布对用户完全透明，无需指定分区键，在集中数据库里建一张分布式表，数据库会自动为其做分区。同样，也可以建全局二级索引加速查询。但这必然存在代价，比如默认按主键做分区，分区不一定符合需求。其次，全局索引开销较大，导致写入开销较大，可能无法满足对业务性能的要求。一、云原生分布式数据库 PolarDB-X 技术架构 9 另外，PolarDB-X 提供了手动分区的模式，可以手动指定分区算法，采用了完全兼容 MySQL 的 partition 分区表语法，分区的算法可以兼容 Oracle 的所有的分区的算法。同时，也可以指定分区在不同条件下存放的位置，真正完全契合业务的访问模式。分布式数据库的显著优点在于能够无限扩展，然而，扩展并不是没有代价的。一旦数据进行扩展以后，集中式数据数库上的事务操作可能会变为跨分区的分布式事务操作，会导致性能急剧损失。如上图所示，即便只有 2 个 NUMA 节点，跨 NUMA Node 访问的性能也将至少下降 1 倍。而同样的事情发生在分布式架构上，性能损失会更明显。NUMA Node 之间有总线连接，而分布式架构下只有网络连接，即便是高性能网络也会产生巨大的网络延时，导致性能急剧下降。我们曾经做过实验，加一个全局二级索引，写入性能下降 30%；而加 8 个全局二级索引，写入性能将会下降一个数量级。因此，分布式系统能否做线性扩展，取决于访问模式。如果系统中跨分区的事务很少，理论上可以实现线性扩展；但如果系统中跨分区的事务比较多，则无法实现线性扩展。一、云原生分布式数据库 PolarDB-X 技术架构 10 在硬件没有实现突破时，很难提升分布式事务的性能。而我们能做的只有尽量减少分布式事务的比例。因此，我们提出了做数据亲和性绑定的概念，将业务上有关联的表，设定同样的数据分区规则，绑定为一个表组，作为调度基本单位。一个表组里的表都采用同样的分区规则、同样的分区算法以及同样的分区个数，减少了分布式事务占比，从而降低分布式事务带来的性能开销。绑定表组最优的方案是自动识别用户的访问模式，自动聚合。一、云原生分布式数据库 PolarDB-X 技术架构 11 在分布式系统里，一旦负载均衡受到了挑战，则会出现数据热点。PolarDB-X 能够进行实时的数据热点提取，可以将热点数据分片重新打散，提取到多个分区。它提供了丰富的 DDL 操作语句，能够实时有效地消除热点，达到系统的负载均衡。电商业务一般会按买卖家做分区，而大卖家会成为热点分区，此时会重新将卖家再按 order ID 做哈希分区，打散热点，这是二级分区的作用。二级分区使用灵活，支持与一级分区一样多的分区策略，是完全正交的策略。而且可以任意组合，支持模板化和非模板化的方式，能够实现精细化控制。比如二级分区可以对所有一级分区制定统一的规则，将每个一级分区都分为 5 个子分区，也可以只将某一个分区分为 5 个分区，其他一级分区不变，这样的模式可以根据业务特点进行灵活的调整，也能够避免分区数量无限膨胀。一、云原生分布式数据库 PolarDB-X 技术架构 12 分布式带来的好处在于在企业级能力上提供了一致性保证，利用 Paxos+2PC 实现了任何时候都有数据强一致的保证。Paxos 主要用于 DN 的复制组，保证数据副本之间的一致性。MVCC 加 2PC 的分布式事务的方式保证了外部的一致性。TSO 用于做 Snapshot 隔离级别、事务隔离级别的一致性保证，其优势在于，做只读事务时，无需对数据进行加速，通过快照也可以读到一致的数据视图，不会读到某个部分的事务。企业级能力这一层做了一体化，包括分布式一体化以及在线与历史归档数据一体化。一、云原生分布式数据库 PolarDB-X 技术架构 13 数据在分布式系统里的体量非常大，且很多数据均有明显的冷热区隔。为了降低成本，我们实现了自动归档的能力。归档过程全自动化，在建表时指定数据过期规则，会将过期数据自动建好分区进行归档，存储到低成本的 OSS 存储里。自动归档也会对冷数据的做压缩，大幅降低数据容量，结合 OSS 低成本的混合存储方式，相对在线数据的成本有 20 倍下降。过期的分区可以作为外表做在线查询，即对历史归档数据一样可以与在线数据做混合查询。为了解决分布式数据库的运维问题，我们做了很多工作，比如做了整体的云管平台，内核层面实现了在线数据字典变更，只需 ONE Sql，One Enter 即可实现。无论是分区表的算法变更、分区键要变还是热点数据分裂，都可以用 DDL 的方式操作，所有 DDL 都为 online，不会影响现有的数据查询和事务操作。用户无需专门找运维窗口，随时随地可做数据字典的变更以及算法的变更来提升性能。一、云原生分布式数据库 PolarDB-X 技术架构 14 同时，我们提供了完整的实时观测运维平台。我们对数据源进行了归类整理，包括 metrics、tracing、logging，会在 SQL 执行路径上做很多埋点，便于跟踪整个云管平台，进行监控告警、SQL 洞察、性能分析诊断、Profiling 以及 Tuning，也可以根据 SQL 执行模式进行索引推荐。PolarDB-X 有以下几种典型的应用场景。PolarDB-X 可以用于替换开源分库分表。一、云原生分布式数据库 PolarDB-X 技术架构 15 可以将用户自建数据库通过 DTS 同步到 PolarDB-X 集群，可以对原有的建表做结构迁移、将数据做全量迁移以及做实时的增量迁移。PolarDB-X 支持分库分表的模式，对接原有的分库分表时无需对用户应用做过多改动。PolarDB-X 还可用于单机平滑演进到分布式。单机 MySQL 的数据库可以一键迁移到线上分布式数据库，应用 0 修改，在 PolarDB-X 上直接实现建表语句即可。完成演进后，原先在单机 MySQL 上难以解决的问题，比如大表如何做拆分等问题都可以在分布式系统上得到很好的解决。分布式系统对于不同的表有不同的解决方法，比如大表可以做成分区表，按指定的方式做分区；比如针对热点表，可以将热点打散后做成分区表；一些普通的单表迁到分布式系统后依然可以作为单表使用。一、云原生分布式数据库 PolarDB-X 技术架构 16 PolarDB-X 的另一典型场景是海量数据大集中。原先的系统中使用了很多数据库，各种数据库之间存在数据孤岛问题，如何做融合的查询分析？PolarDB-X 结合 DTS 以及 ADB 提供了一整套解决方案，同时满足在线数据的处理以及在线数据分析的需要。PolarDB-X 还可与 ADB 做深度融合，中间不再需要数据传输的工具，只需进行实时的数据转换，ADB 实时分析转换好的内存的数据副本，实现完全一体化的数据处理以及数据分析的一致性体验。一、云原生分布式数据库 PolarDB-X 技术架构 17 针对金融场景的数据强一致需求，PolarDB-X 也能提供非常完备的高可用解决方案以及灾备方案，包括同城多机房、两地三中心等解决方案，能够保证跨地域的高可用、机房级别的容灾以及保证数据的一致性。未来，PolarDB-X 将持续往一体化方向演进。包括集中分布式一体化：要使分布式数据库更加接近于单机数据库的体验；负载处理一体化：能够处理 transaction 和 analytic 的负载。也包括在线和历史数据一体化，与云的基础设施更加深度的融合，利用云底下的共享存储、云的芯片做硬件结合的一体化。事务处理与分析一体化利用 CDC 做实时同步，存放到云存储上，以列式的压缩格式做存储。同时 CN 也支持行列混合的分析查询，对优化器具有较高要求，需要能够识别出处理事务与查询事务，判断将其放于行存执行还是列存上执行，计算具体的cost。未来，我们也计划通过 ADB 数仓利用大规模数据分析的计算引擎做一体化的分析工作。一、云原生分布式数据库 PolarDB-X 技术架构 18 云原生与分布式融合一体化架构也是未来发展趋势。目前所有的 DN 数据存储在本地磁盘，未来会将其存储到共享存储池，这是未来分布式数据库发展的重要方向。我们在做扩展时应尽量不动数据，而是实时或独立地扩展计算节点和存储节点。扩展了节点以后，数据要做大量搬迁工作。而如果底下是共享存储，则无须进行搬迁工作，新增节点后即可投入服务。另外，共享存储能够存储的数据量会远远超过单机的数据规模，也更有可能减少数据跨分区的可能性，从而有效减少分布式事务带来的代价。如何更好地利用云的基础设施提供更好的扩展能力以及弹性能力的分布式数据库，是未来云原生分布式数据库的重要发展方向。二、云原生数据仓库 AnalyticDB MySQL 高性能存储引擎 19 二、云原生数据仓库 AnalyticDB MySQL 高性能存储引擎 作者：张浩然，阿里云数据库高级技术专家 AnalyticDB MySQL（以下简称 ADB）是一个云原生实时数仓，采用云原生技术架构，高度兼容 MySQL 协议。关系型数据库、NoSQL、非结构化数据甚至原始的日志数据等多种数据源都可以通过 DTS、DataX 等工具同步到 ADB 中。数据导入 ADB 之后，即可拥有数据库的体验，用户可以直接写 SQL 进行相对复杂、高性能、低成本的分析。AnalyticDB 高度兼容 MySQL 协议，因此可以支持非常多的数据应用。研发人员可以自己写 SQL 进行查询分析，也支持丰富的 BI 报表工具。为了提供云上的一站式体验，ADB 还提供了数据管理，包括 DMS、DataWorks 等。二、云原生数据仓库 AnalyticDB MySQL 高性能存储引擎 20 上图为 ADB 整体架构 底层依赖了云上技术设施，包括 ECS、ECS 挂载的 ESSD 云盘以及 OSS，OSS 主要用于冷数据的存储，降低用户成本。存储层使用了分层存储，同时支持 ESSD 和 OSS。对于数据的不同业务行为用户可以进行数据冷热分层，选择高性能或低成本的存储。同时，基于 Raft 的同步层保证了数据的高可用和强一致。为了满足不同场景的查询需求，存储层实现了行列混存，支持不同的存储格式。第三层的 XIHE 为计算引擎，它具备秒级的弹性拓展能力，无状态，可任意弹出计算节点，目前单集群支持 2000+以上节点，并且规模在持续增长中。其次，它为混合负载实现，无论是 BSP 还是 MPP，都具备良好的支持。第四层为前端节点，负责协调、负载管理，还负责 JDBC 协议的支持，用户的 insert语句等需要由其进行接入，同时它还包含 API、优化器等。二、云原生数据仓库 AnalyticDB MySQL 高性能存储引擎 21 上图为存储层架构 最上层为 JDBC 协议的接入层。一个 insert into 语句由 JDBC 接入后向下发送，首先会转为 Raft command，通过 Raft 层发送给存储节点。计算层的主要功能是外表的高并发读，读取到的数据会被批量写入到存储节点。存储节点类似于分库分表的架构，任意表会被均匀地拆到下面的若干个Shard之上。每个 Shard 包含两个数据副本和一个日志副本，它并不是完全标准的 Raft，而是2+1 的模式。两个数据副本负责承接写入和查询，日志副本仅参与投票，保证整体高可用的同时也节省了一份数据存储的开销以及一份用户写入的开销。Shard 内部最上层为 query merger，相当于存储层的查询接入，负责接入下推到存储的计算算子。存储引擎内部的数据分为实时数据和历史数据。实时数据面向写进行优化，具备相对良好的写入能力，它只有数据文件和粗糙索引，不具备复杂精确索引。除此之外，还有版本管理器和 delete bit-set，便于修改。实时数据通过 build 转化为历史数据。历史数据可以认为是经过读优化的数据，具备良好的读性能。在历史数据中，除了数据文件以外，还有多种类型的索引，包括倒排、BKD、位图等多种类型的索引。构建过程中还进行了数据的冷热分层。准实时数仓的写入需求一般为高吞吐（日志数据）、低延迟（业务数据），还需要兼顾写入性能以及查询性能。二、云原生数据仓库 AnalyticDB MySQL 高性能存储引擎 22 前端节点为无状态，具备良好的可拓展性，可以任意横向扩展，进行高并发的写入。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 高性能存储引擎 23 Replace 语句被拆分为两步：先删除，再 append。数据从 Raft command 发出后，会先同步消费，再 apply 到 table engine。table engine 消费完成之后，用户 JDBC的 insert into value 会立即返回，用户得到“返回成功”。此后即可对步骤已经apply 的数据进行查询。但是，Replace 的实际流程为先删除后写入，因此需要进行一定的优化，防止用户的查询跳变。如上图左下方所示，Client（1）是写入 client，当前已经写到第 199 条，下一步可能要做 replace。Client（2）为读 client，要读第 100 条数据。当前，第 100 条数据还未被删除，因此可以查询得到。如果要执行 replace，则会先将第 100 条标记为删除，无法再得到查询结果。为了避免该种情况，此时会将第 100 条数据标记在 RowIdMap 进行删除屏蔽，在第和步之间保证查询没有问题。等 append 即完成之后，整个 replace 执行完毕，200 条数据均已经存在，查询结果将返回新数据。以上设计实现了 replace 的原子性保证。针对下推到存储的计算，我们也进行了一些优化。首先，DFP（dynamic filter pushdown）。Hash Join 有小表和大表，小表往往会被build 成 hashtable，大表用于扫描。我们对其进行了优化，优化前提为小表非常小（或过滤之后非常小）且大表有索引。将 hashtable 变成了另一种执行模式，将小表传输到大表侧，变成 in 的算子进行下推，可以直接做二级分析裁剪；其次，得益于精确的索引，单个 in 的索引开销只需在几十毫秒以内，节省了扫描大表的开销，性能也有了提高。Hash Join 的另一优化为 local index join。优化的前提条件为具有比较良好的建模，做 Join 时的两个表使用了同一级分区键进行一级分区，保证它们分布时是对齐的。比如一个用户表和订单表同时按照 user ID 进行一级分区，同时他们基于 user ID 进行 Join。基于以上前提，可以数据完全不走网络，小表在本地直接利用大表的索引进行 Index find 找到命中的行，直接实现 Local InnerJoin。二、云原生数据仓库 AnalyticDB MySQL 高性能存储引擎 24 数据文件是典型的 RC File 的实现。Column Entry 记录在 Meta file 里，包含列级统计信息，包含行数有多少个 null、最大值、最小值等元信息。Block entry 记录数据 Block 的基础元信息，包括 min、max 以及 offset。如果没有定义索引进行精确查找，则会通过 min-max 进行粗糙集过滤，进而判断是否需要读数据 block。如果需要读，则再通过 offset 找到具体的数据 block。在单条记录远超常规大小的前提下，对该字段的 Block 进行批量加载很容易导致系统 OOM。因此，这种情况下，超长字段会存储到独立的数据文件并为每条记录存在一条 toast offset。最小的 IO 单元由 block 自动退化为 value。我们支持多种索引，此外还有分区裁剪等策略来减少以计算量。在索引的选择上，支持目前列级的索引。用户仅需对每一列选择是否单独建索引，无需感知索引类型，能够根据用户的数据类型和数据特征自动化构建索引。此外为了使用户使用简单，也无需构建任何组合索引。对于任何查询，ADB 都会将存储侧复杂查询拆分为不同的查询路径。如上图以 id=123 and city in hangzhou为例，存储引擎会先对两个查询条件在索引内进行独立查询，此后将结果集进行取交；如果为 not，则取差。最终进行多路归并，取到结果集，即为最终的查询结果，无需构建组合索引。该方案存在的主要问题为某些索引命中率非常高导致索引效率比较低，因此存储引擎内部也实现了一条基于代价的执行计划选择器自适应选择是否使用索引。二、云原生数据仓库 AnalyticDB MySQL 高性能存储引擎 25 实时数据主要面向写优化，历史数据主要面向读优化，build 能够将这两种数据进行合并产生新的历史数据。合并过程会进行面向查询的建模，包括分区、排序、构建索引、收集统计信息，是 CPU 密集且 IO 密集型的操作。对于单机存储引擎，build 除了构建索引、分区、排序等建模之外，需要兼顾实时数仓的查询和写入性能，因此，我们实现了以下三个能力：二、云原生数据仓库 AnalyticDB MySQL 高性能存储引擎 26 第一，基于多版本控制的细粒度锁构建过程。实时数据负责承接写入，实时数据和历史数据共同承接查询。单存储引擎收到 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，方便运维。二、云原生数据仓库 AnalyticDB MySQL 高性能存储引擎 27 同时，我们也在做另一种调度方式，每个 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 足够均匀，即可保证每个机器的负载基本相同。数据版本管理与 build 紧密联系，基本基于 build 来实现。实时数仓的一个典型使用场景为从 TP 库同步数据到 AP 库，用户希望 TP 库的所有数据更新都能实时的在 AP 库上得到体现。现在假设一个场景：用户在 TP 库上执行 二、云原生数据仓库 AnalyticDB MySQL 高性能存储引擎 28 了一条 DDL，该 DDL 在 TP 可能耗时数十分钟。其后立即更新了大量数据并期望 AP侧能够立即对这些数据进行查询。在该场景下要求 DDL 能够在 AP 侧做到准实时或毫秒级执行。基于以上需求，我们首先进行了毫秒级的逻辑适配。逻辑适配完成之后，存储引擎可以接收新模式下的写入和查询请求，此时数据并没有得到物理上的修改。之后再通过 build 过程，对数据文件依据 DDL 进行真实的物理变更。执行时，若将全量数据进行重建会消耗大量时间以及资源，因此仅对有修改的分区进行重建。同时，为了满足客户不同的业务场景，也支持用户通过 force partition 指定重建区分区。分区管理主要包括生命周期管理以及冷热分区转化。见上图右侧在 shard1 的定义里，lifecycle=3 表示有三个分区，hot window=2 表示有两个热分区。v100 里有 7-31、7-30、7-29 三天的数据，其中 7-29 的为冷数据。8-1 的实时数据写入后，执行 build，将 7-29 的数据淘汰，产生 8-1 的新的历史数据。同时，要进行冷热转换，将 7-30 的数据从热数据转换为冷数据。转换完成之后，为了进一步保证主从副本的一致性，leader 做完裁决之后会将裁决信息作为 layout file 传到之上，从副本进行 apply，在复用了 build 的结果的同时也复用了整体分区管理的决策。冷热的转化本质是分区的存储介质变化。本地存储介质一般为 ESSD，上传后一般为OSS。数据从本地到 DFS 并不是仅进行简单的上传即可进行高效的查询。针对远程数据文件的管理，我们也做了一系列的优化。二、云原生数据仓库 AnalyticDB MySQL 高性能存储引擎 29 如上图左侧所示，上层为存储引擎，下层为 DFS。从存储引擎到 DFS，首先会经过SSD Buffer。DFS 对小文件的读写并不友好，比如常见的索引构建有很多类似于外排的操作涉及大量的随机读写。若此类操作直接打穿到 DFS 上，则导致 IOPS 非常高，对 DFS 非常不友好。因此，我们实现了 SSD Buffer，先在本地聚合，将需要预处理的数据在本地完成构建。之后，将随机的小文件读写转换成流式的、批量的、高吞吐的顺序写上传到 DFS。写的过程中，会经过 Tar FileSystem 进行打包并增加一个 cache，该 cache 为 tar文件内子文件路径到该文件在 tar 内的位置的映射。Index 置于文件尾部，一旦打开文件则会将 Index 加载到 cache 中。cache 的优势在于，在打开某个子文件时，可以少读一次元信息，同时，使得 Meta 类的操作不需要再读远程，而是可以直接在本地处理，对文件的 meta 类操作性能有显著提升。下面的 ADB FileSystem Interface 是统一的文件接口层，能够屏蔽下层存储的远程实现。存储引擎只感知通用文件接口，ADB FileSystem Interface 会进行具体转换自适应的操作远程文件存储或对象存储。读取时，经过 Tar FileSystem 和 ADB FileSystem Interface，会有 SSD Cache，做了本地文件块到远程文件的映射，能够深度感知 IO 模型，IO 模型可以分为三类：第一类，Meta 类操作，比如获取 block 位置信息等导致的随机读。第二类，Query，分为 index search（随机读）和 data cursor（高吞吐的数据扫描）。第三类，build，高吞吐的顺序读。SSD Cache 针对以上三种类型分别分配了独立的 cache，主要包括独立的磁盘空间管理、独立的淘汰队列、独立的 block size，彼此互不干扰。引擎侧向下发 query 时，会携带 hint 信息，用于判断应该使用哪种 cache。如果发生了 cache miss，会先经过 Perfetch Service，它与 IO 模型紧密相连，能够感知 query 的 plan，可以并发地进行预取，进一步加快对远程文件的读取性能。内存控制主要防止 query 过于复杂，导致查询负载较高，最终导致整体存储节点的负载过高。三、降本增效，阿里云一站式数据库上云最佳实践 30 三、降本增效，阿里云一站式数据库上云最佳实践 作者：王林平，阿里云数据库高级解决方案架构师 随着互联网的持续快速发展，云计算已经成为 IT 主流的基础设施提供方式。云计算支撑了城市大脑、冬奥会、天猫、淘宝、优酷等，与每一个人的生活息息相关。阿里集团的很多企业都已经将IT基础设施搬到云上，云计算在国内得到了蓬勃发展，为企业带来快捷的能力，实现了增效。1.上云路径 DTS 是帮助上云的有力工具。它孵化自阿里巴巴内部，最初被称为 DRC，用于做内部数据流转，包括单元化、双活、多活。2015-2016 年，集团业务要上云，面临了一系列的问题，比如数据怎么上云、混合云怎么做灾备和双活等，怎么分析上云。为了解决问题，阿里决定将 DRC 进行商业化，同时在云上为企业客户提供了丰富的能力。技术上，DTS 在某些方已经领先于国内外的友商，比如事务冲突、热点模型的合并、网络带宽的优化、数据校验、双向复制等，拥有企业客户 10 万+。三、降本增效，阿里云一站式数据库上云最佳实践 31 上图左侧是某电商客户搬站上云的路径，右侧是实时分析 该电商客户希望将业务、会员、商城、购物车、计费系统、推荐算法等系统从 IDC搬到云上。在 IDC 使用的主要为 MySQL、MongoDB、Redis，云上提供了 RDS、MySQL、MongoDB、PR 持久内存（自研的缓存），也有云 Redis，可与 Redis 完全兼容。整个上云过程可以通过 DTS 实现数据的复制。上图可见上云过程中存在两条线，绿色线是双向复制。目前从开源的 MongoDB、Redis 复制到云上的 MongoDB、Redis 依然是单向复制，而 MySQL 支持双向复制的，可以基于双向复制构建无缝的切换方案。比如某客户的核心业务系统在 MySQL 上，客户不希望 MySQL 在过程中有过多停机。我们为其构建了平滑的数据库迁移上云方案，通过全量和增量复制，将 IDC 机房的数据库连到云上的机房，得益于同城，其延迟较低。同时，在 MySQL、MongoDB和 Redis 上云的过程中提供了数据一致性的校验。同时，我们对网络提供了较好的支持。得益于双向同步，可以实现秒级、分钟级的回滚。云上业务打开之后，MySQL 依然可以回流到 IDC 继续做复制。云上业务正常后，可将 DTS 链路暂停。如果在观察期发现业务出现问题，RDS、MySQL 回流到 IDC的 M