摘要：云原生数据库在使用存算分离技术后，可以在完全兼容MYSQL协议和语法的情况下，极大提升单实例所能承载的数据规模与吞吐能力上限。但除了对客户端兼容外，对整个数据生态（地域容灾，数据分析，备份恢复）的适配同样需要大量的设计优化工作。本次分享GaiaDB在跨地域/异构数据同步场景下，吞吐/实时性/一致性方面能力打造与实践经验。
在2023云数据库技术沙龙 “MySQL x ClickHouse” 专场上，百度数据库资深技术专家邱学达，为大家分享一下《百度云原生数据库GaiaDB的HTAP与多地多活技术实践》的一些技术内容。
邱学达，百度数据库资深技术专家，主要负责分布式架构设计与数据库内核特性设计和开发。多年数据库与分布式存储开发经验，专注于分布式高可用+高可靠架构设计与云原生化改造。在分布式性能优化、端到端可用性提升方面具有丰富经验。
大家好，今天我想和大家分享的内容是百度云原生数据库GaiaDB在数据分析场景与多地多活方面的一些实践经验。
GaiaDB是百度智能云研发的一款云原生数据库，目前已经在云上获得了广泛的应用，承载了多个高吞吐/超大容量业务，特别是帮助很多业务在0改造成本下，实现了服务多地域多活，在每个地域都可以实现接近本地的低延迟读取能力。在大数据量承载方面，多个线上百TB以上业务实践证明，GaiaDB在这种规模下依然具备良好的吞吐与弹性能力。
首先是接入层 ，接入层主要用来提供自动读写分离/流量控制/SQL防火墙/鉴权与负载均衡等功能，业务无需维护复杂的读写分离/连接池逻辑，直接使用proxy即可享受丰富的接入管理功能。对于有读写一致性要求的业务，还可以选择使用主从一致性或全局强一致等多种一致性级别，解决传统架构写后读不可见导致的多种复杂兼容问题。
再往下是计算层，计算层依然是多个计算节点互相负载均衡的架构。对于读场景已经实现了无状态的横向与纵向弹性伸缩，可以实现秒级扩缩容，方便应对线上各种活动流量与突发尖峰。对于写场景，默认仍提供基于纵向扩展的弹性伸缩能力，可以满足线上大部分业务的写吞吐需求。对于写能力的横向扩展，我们也做了大量的技术储备，写的扩展能力主要取决于请求的冲突情况；在完全无冲突的负载下，乐观事务可以提供近似线性的写扩展能力，但是大部分的交易类负载都是存在冲突的，在这种情况下乐观事务模型的使用体验就会变得不易接受；对于目前主流的悲观事务模型来讲，解决冲突主要使用锁机制实现，横向写扩展引入的跨节点锁协商会带来较高的事务延迟与吞吐瓶颈，目前在工程上还是非常具有挑战性的。当前对于写的横向扩展我们更多的是结合业务特点进行专属方案定制，实现业务上的整体最优解。
接下来是存储层的架构设计，对于分布式存储系统来讲，核心就是数据分区算法与数据引擎设计。数据分区算法的核心在于如何在尽量降低映射获取时延的同时，将内存消耗控制在可接受的范围内，同时又尽量避免数据的大规模搬运。对于实时性要求越高的系统，分区算法的设计应该层级越少、规则越简单，避免引入过多的切换消耗。而数据引擎的设计优化方向则集中在Base数据的读取优化以及增量数据（WAL）的可靠性/一致性保证上。GaiaDB的存储引擎在设计上将Base数据与增量更新分离到了两个子系统中，即存储子系统和日志子系统，避免了日志流与数据流的IO争抢导致各类性能问题，存储子系统可以向极致读性能方向优化，将读IO优先级设为最高，写则可以使用异步落盘+内存动态回放技术降低对磁盘占用；日志子系统向极致写性能方向优化，使用窗口技术+增量引擎，将写能力优化至极致水平，读使用热数据缓存技术提升性能。通过将读写数据流解耦分别优化，实现了资源的最大化利用。
在整体架构设计上，GaiaDB对于系统数据一致性与可靠性方面做了重点加强。Mysql的主从切换一直是一个比较复杂的课题，在硬件掉电/网络不可达等场景下，保证数据的严格一致较为困难。GaiaDB将原生数据可靠能力（RPO=0)固化到系统的基础设计之中，通过将一致性协议中的任期机制融入到整个数据链路中，新的写入任期开启后，任何过时写入都会被排除在数据流之外，确保即使发生了假死等情况，数据的完整性也完全不会受到影响。
接下来想和大家分享一下 GaiaDB 在配合业务的分析需求、让业务可以更高效流畅实现数据分析的一些实践经验。
很多业务在使用GaiaDB满足交易类和轻度分析类需求的同时，还会使用Doris解决分析型场景下的需求，Doris是由百度自研并捐赠至Apache软件基金会的开源MPP数据库，在行业内获得了广泛的应用，对于不同种类的数据分析读取需求，我们积累了一些成本与效率最优的解决方案，下面我来结合具体的案例进行分析。
如图是一个典型的泛互联网产品架构：最前端是网络接入层，用于承接APP/Web发来的业务请求、聚合和分发不同子系统之间流量；后面有多个业务子系统，例如商品、订单、活动、推送等。这些用户业务系统更关注的是数据的高并发+低延迟访问，对数据的一致性和事务隔离性也有较高的要求，同时由于线上活动或者节假日流量高峰，对弹性和扩展性也有迫切需求，GaiaDB可以很好满足这类业务的需求。
与用户业务系统使用同一份数据的部门往往还有另外两类，一类是后台服务，也就是对内的客服系统/运营维护系统/供应链业务系统等。这些系统的特点是：由于只有公司内部人员使用，QPS和并发不高，但负载复杂而且迭代要求高。比如运营部门经常需要进行新活动设计与配置，客服/MIS系统则需要配合线上活动情况增加各种查询功能。因此，对于后台类业务来讲，能用SQL和事务快速完成复杂可靠的功能开发是刚性需求，所以SQL的功能丰富度与兼容性显得尤为重要，同时SQL的并行能力与计算下推对于这类场景的体验优化具有重要作用。第二类则是专业的数据分析团队，数据分析团队往往承担了多维度、高复杂度的数据分析需求，所以通常使用专业的数据分析一揽子方案，这种场景下数据请求不会直接发往在线数据库，而是需要尽量实时的从在线库导入至分析库，因此快速、简单、可靠的数据导入导出能力成为首要关注点。
所以针对异构分析的需求，100%生态兼容的导入导出功能是首要+必备选项，特别是分析型解决方案的数据同步组件都是通用而非业务自研组件，上云用云过程中修改这部分基础设施难度是非常高的。因此GaiaDB在这方面做了很多增强工作，比如基于日志流的高可靠强一致能力原生实现了RPO=0级别的Binlog流支持能力，同时对于通用的DTS产品和社区导入导出工具，也是保证了完全兼容和历史经验复用，不增加额外的学习成本。
而对于轻度的离线分析需求，这部分的特点是需求多变、对成本敏感、与线上服务有隔离诉求。GaiaDB使用多入口技术支持业务在离线请求完全隔离，对于离线类请求使用单独计算资源，不会对线上造成影响，同时充分利用存储层分布式MVCC能力，不增加额外的存储成本和数据一致性维护开销，随着离线负载的变化，对应计算资源还可以动态伸缩以进一步增强成本节省能力。对于支持数据分区的业务来讲，GaiaDB同样兼容了该功能，数据分区可以有效降低资源争抢密度，提升并行读取能力，对于并行分析具备很好的提速作用。
还有一类对数据一致性要求更高的业务，如金融类产品，期望拿到精确到秒级的全局一致数据用于分析，不但从空间维度要求数据一致，从时间维度上也期望在分析的过程中数据可以保证前后一致，这种场景下GaiaDB只读镜像库的能力就得以体现，在资源空闲的低峰时段创建镜像库同时启动分析任务，有效利用低峰时段空闲算力。由于只读镜像无需处理写负载，所以写相关的日志子系统可以裁剪以节省成本，同时也解耦了对高性能介质的依赖。只需要计算节点+冷存储介质，结合查询并行化技术充分利用分布式IO吞吐能力，即可实现超低成本离线分析解决方案。同时全量镜像也确保了数据严格一致，避免了增量同步可能导致的DDL处理、数据校验等复杂问题，有效保证了数据的可用性与可靠性。
近几年随着业务精细化程度的提升和基础设施规模故障风险的存在，越来越多的业务将多活能力纳入了架构设计考虑的范畴，业务既希望可以获得高可用性，还想让成本控制在比较低的程度，同时还不希望由业务实现多份数据的同步与维护，这样就对数据库这类基础设施的多地多活能力提出了很高的要求，GaiaDB的高对称架构天然适合多地多活方式部署，所有存储副本逻辑上完全对称，每个副本都具备动态回放任意版本数据能力，这样就为数据就近访问打下了坚实的基础：业务请求可以自动路由到同机房计算节点，计算节点请求同机房存储副本即可读取实时数据，避免了主从架构副本导致的多次跨机房访问问题。同时全对称架构还可以避免故障场景下批量选主带来的服务中断与请求风暴问题，任意副本故障不会影响其他副本工作，可用性更高、延迟更平稳。对于写链路则使用并行写入技术加速，最快的多数派返回即可实现写入成功。综上，GaiaDB的同城多活架构在读写链路上都可以避免单个慢节点/机房导致的性能抖动问题，使整体性能损耗控制在很小的范围内。
此外GaiaDB也支持跨地域热活实例组，将灾备能力提升到了地域级，业务在地域间部署无需适配改造，即可实现就近读取低延迟能力和写请求自动转发能力，无需维护复杂读写入口，提供了与单地域实例一致的使用体验，帮助大量业务实现了跨地域灾备能力。
以上就是我今天想和大家分享的内容，GaiaDB在架构设计上核心关注数据的高可靠与高可用性，重点打造了数据的极致可靠保障能力、跨地域多活能力与灾备恢复能力，同时在使用体验上注重简单可靠，实现了对生态和使用经验的完全兼容，将用户上云门槛降至最低，让所有上云用云业务都可以享受到基础设施架构提升带来的效能提升，谢谢大家。
本次大会围绕“技术进化，让数据更智能”为主题，汇聚字节跳动、阿里云、玖章算术、华为云、腾讯云、百度的6位数据库领域专家，深入 MySQL x ClickHouse 的实践经验和技术趋势，结合企业级的真实场景落地案例，与广大技术爱好者一起交流分享。