RDS：稳定、安全、开放的新一代云数据库服务
内容介绍：
一、RDS年度产品发布与最佳实践
二、金融场景下对于关系型数据库的要求
本次分享的主题是RDS：稳定、安全、开放的新一代云数据库服务，由阿里云智能集团数据库产品事业部RDS及开源OLAP负责人彭祥和平安科技数据库团队总工程师汪洋分享。
一、RDS年度产品发布与最佳实践
本次将介绍阿里云的RDS在过去半年在产品和技术上的发布以及最佳实践，该议题主要分为两大块，第一部分重点介绍团队在过去半年在产品上的两个重磅的技术创新和产品的发布。第一个是RDS基于对象存储做全量的数据管理，第二个是更加开放的RDS产品形态。第二部分简单介绍一个比较有借鉴意义的客户案例。
1、存储演进-RDS On OSS
（1）RDS通用云盘
去年，在云栖大会瑶池数据库技术分享中，重点介绍了基于冷温热数据分层的存储理念，今年基于冷温热数据分层推出了RDS的通用云盘。通用云盘有哪些技术上的创新？有哪些产品能力上的提升？为什么要做这件事情？云数据库如果要做出自己的核心差异化的能力以及核心竞争力，一定要将数据库、云数据库跟云的基础设施、云的技术服务紧密的结合。
简单来讲，就是要将数据库跟计算、存储、网络、安全以及corporate lattice的集群式的管理、工具紧密的结合，然后来推动上层数据库的pass服务能力的提升。在数据库实际上，从它的分层的组件来看，存储是数据库非常核心的重要组成部分，所以把大量的精力投入到存储的不断创新，通过结合云的基础设施提供的不同的存储媒介做通用云盘。
该通用云盘分为三部分，第一部分是基于高速缓存盘做了一个库extension，这样能够将客户业务在负载上的，不能够容纳到，包括库里面的这份数据溢出到extension，它能够提升整个系统的性能。第二部分是将云盘的容量跟性能进行结耦，真正将数据库的存储做到serverless化。第三部分是将数据库的数据从块存储ofl到对象存储，充分利用对象存储的低成本来给数据库的用户提供一个冷温热数据分层的完美解决方案。
了解不同的存储媒介，不同的技术指标以及为什么选择这三种不同的存储媒介。第一个是高速缓存盘，更多集中在它高性能、低延时、高吞吐的性能方面；第二个是块存储，充分的利用自身弹性、性能跟容量的充分结耦；第三个是对象存储，充分利用它的成本。基于对cap theories的了解，在做产品和服务的过程中，从性能、成本、弹性的角度，如果都能够提供给数据库的用户，而这是力求达到的目标。
（2）RDS On OSS
在RDS通用云盘的基础之上，把对象存储作为冷存归档使用，现阶段市面上所见的大部分的云数据库，也是这么使用对象存储的，基于在这个理念之上，充分的做到了把数据库的全量数据从块存储ofl到对象存储，这里面存在多个技术挑战点需要产品团队去解决。
第一，对象存储跟块存储的io模型不一样。第二，当数据存储到不同属性的存储媒介上面时，备份恢复如何做。这些都是产品上面需要解决的技术难题。总体而言，它做到了把数据库的全量数据从块存储ofl到对象存储上面，并且能够提供一个非常低成本、高效率的解决方案，能够充分的给客户弹性、成本、性能这三者达到一个完美的平衡。
（3）RDS+DuckDB一体化HTAP方案
除了能够把数据库的数据从块存储ofl到对象存储以及在成本上面提供一定的优势，还有什么其他的能够带给用户的？传统的tp类的数据库，都利用块存储，在ap类的场景上面，特别是最近非常热门的无仓类的产品，基本上它的数据全量都保存在oss，也就是对象存储上。
为在复杂的业务场景服务用户，推出了基于RDS、oss之上做的rspg，通过插件化引入了DuckDB内置的一个ap类的存储引擎，通过一份数据去提供tp的产品能力，同时在ap类的场景也大大提升了RDS 的处理能力，这种一体化的这个方案能够充分的解决客户遇到的非常复杂的tp加ap类的业务场景，这是在存储上面做的一个非常核心的功能
2、开放形态-RDS Custom
（1）Paas的开放形态
关于RDS Custom的开放paas产品形态，用户在上元的过程，一步一步的将自己的这个核心业务系统从它的自建的场景或者是IDC的机房里Information慢慢的逐步的迁到云上去，去用paas类的服务。但是很多场景下出于容灾、监管的目的，很多时候它是在云上和云下同时会有两套或者是多套管控体系。如何通过产品能力的提升给客户提供一个相对来说比较统一的技术站，这是做RDS Custom的一个出发点。
（2）内核权限开放
对于RDS Custom主要在两方面做了一些技术上的改进和产品能力上的提升。第一个是内核权限的开放，不只是在数据面上更加开放的去适配客户，还包括线下IDC机房以及线上paas服务层的权限的开发。第二个体现在各种数据面的上的镜像、不能工具的适配。能够使得客户自建的这些管控体系能够在管理和维护自己线下idc机房里面的资源的同时，能够把云上的paas类包括rds的这个数据库资源同时纳贯起来，这是第一个技术上的提升，
（3）资源节点权限开放
传统的paas类的服务客户在使用数据库的时候，更多的是一个end point，它的业务负载通过跟end point交互，然后对实际级别进行一个实际生命周期的管理，包括实际的创建、销毁、编配等这些操作。实际上客户对底层的资源节点的感知几乎没有，通过资源节点的开放，能够让客户对底层的资源有一个非常明显的感知。
客户通过自己的管控体系架构去纳管它在阿里云上面的rds数据库资源的这个过程，中间能够做到非常的好用、便捷。通过内核权限的开放以及节点资源的开放能够充分让阿里云客户在云上的业务跟线下业务能够有一个非常有趣的结合。这个是RDS产品在过去一年以及过去10个月第2个比较重磅的产品的一个能力的提升。
3、最佳实践案例
（1）汇联易：RDS数据归档解决方案
汇联易是业界比较有名的sas类的提供商，它在自己业务中间主要面临两个比较大的挑战，第1个是它的成本，成本主要体现在数据的存储上面。第2个是它在业务的波峰波谷的一个应对，客户通过RDS通用云盘的适配解决了客户在业务上的波峰和彭峰的问题，同时大大降低了客户在数据存储上面的一个成本。
（2）莉莉丝:RDS在游戏行业高并发低成本解决方案
莉莉丝是业界一个比较大的游戏类的公司，它实际上在业务上面也面临成本上的一个挑战，同时在性能以及突发流量上面的一些挑战。这个客户通过RDS通用云盘以及在计算上面适配的倚天服务器的这么一个产品形态，比较好的解决了自己业务上的挑战。简单说就是在成本下降的同时，也能够非常好的去应对业务上的洪峰以及突发流量的挑战。
（3）中免日上:一站式上云解决方案
中免日上是阿里云RDS SQL server的一个客户，最初它在线下用的比较多的SQL server，然后我们RDS这个产品通过一站式的上云能力能够非常便捷的帮客户业务比较无感的从线下机房迁到了阿里云的RDS产品之上。
二、金融场景下对于关系型数据库的要求
平安科技是平安集团的一家子公司，向整个平安集团的各个专业子公司提供数据库的一些产品和服务，从用户的视角、专业公司的视角来去在金融场景中对数据库有什么要求，特别是对关系数据库有什么要求来进行一些分享。金融行业在所有的行业里面是对数据库的可用性、高可用性、可靠性和稳定性要求最高的行业，在出现问题之后，它要求在最快的速度能够恢复服务，而且要在整个运行过程中保持它的稳定可靠性，今天从业务连续性、数据安全、可运维性、降本增效方面看金融行业到底对于关系型数据库会有哪些的要求。
业务连续性和数据安全是内外同时的要求，所谓的外是来自于监管局金融监督管理总局的科技监管司对于关系型数据库的要求，现在对于业务连续性和数据安全越来越重视，不停地出台一些隐私的保护法、数据安全相关的一些法律法规。
业务连续性在出了问题之后能够尽快的恢复，甚至能够把问题的隐患提前发现和解决，所以从平安集团自身的角度，业务连续性和数据安全也是非常重要的。平安集团是一个金融的、综合的金融集团，它涵盖了金融业务的方方面面，包括了保险、基金、银行、投资、证券等等，所以有的受证监会监管，有的受人社局监管，还有的受一些金融监管局科技监管司监管。众多的监管机构都对于这两方面提出了要求，也是我们出于自身的一些考虑。
可运维性和降本增效更多的是出于内在的需求。现在很多数据库包括平安集团用了很多年的开源数据库和国产数据库，都会发现有一个问题，当出现问题的时候，它并不能够提供一个很完善的诊断信息。在运维的过程中，也会出现许多的阻碍，并不像以前的成熟的商业数据库一样，虽然现在是在国产化、在鼓励大家自主可控，但实际上这条路大家都在说怎么样能够把能用变成好用。
所以可运维性就是从能用变成好用对关系数据库提出的一些要求。还要求降本增效，这是因为现在经营形势不是很好，所以在这个过程中尽量压低自身关系型数据库的运营成本，这就能给平安科技所服务的专业子公司带来一些成本的节约，就能够把价钱降下来。
1、业务连续性
（1）高可用性
一个冗余的硬件架构，还有怎么样能够做到active active的实例。双活的实例实际上又分为两个层面，对于一些原生的分布式数据库来讲，可以进行跨可容区的部署，从可容区的角度它本身就是双活的，当一个可容区出现故障之后，它可以快速切换到另外一个可容区。但是对于集中式数据库来讲，也希望能够在数据库运行的时候实现双活，双活可以通过一些共享存储的类似于oracle rank或者polo db的这种双活实例，当一个主机已经发生问题的时候，流量可以切断换到另一个正常运行的实例上面去运行。
对于可容区的角度也是双活实例，当一个可容区出现问题的时候，对于集中数据库来讲，它可以快速切换到另外一个可容区来提供服务，实例的快速切换其实跟刚才那个双活实例一样。
（2）版本管理
版本管理在正常的数据库的运行过程中是非常重要的特性。当应用发版之后，怎么样能够完成数据库版本的绘图发布，这是在数据库领域，特别是关系型数据库领域一直存在一个难题，关系型数据库它不是一个scheme list，它有Scheme的这种概念,有erd这种er图的概念，怎么在数据库的过程中完成数据库版本的绘图发布，这是一个问题。
还有一个要求就是当应用版本发布失败的时候，怎么样能够快速的回滚到之前的状态？这需要数据库的比如说flashback的功能。当应用发版失败之后做出的ddl对于数据结构、数据类型等等的一些改变，怎么样能够快速回滚到之前？能够完成从应用系统到数据库一个联动的回退？这也是依赖于数据库的一些机制，flashback能够完成。
第2个就是数据库软件的升级机制，这么多年很多的zero down time upgrade，就是怎么样让数据库升级过程中能够尽量的完成0宕机时间，实际上这是很难的。奥尔格数据库说如果你用逻辑同步的方法，我可以做到zero down time，但从我们来看，这种所谓的zero down time也是假的。因为虽然逻辑同步可以快速切换到，但切换之前逻辑的同步有时候会出现问题，会出现一些数据的丢失以及数据上面的一些差异化，所以这就是为什么我们在进行通过逻辑的数据同步进行数据升级的时候要去进行数据的校验。
在升级过程中切换的时间，怎么要保证数据一致性？还是要做最后一次的数据校验，所以zero down time实际上是很难做的。这是逻辑的同步，如果是物理的，我们现在经常可以做到的是什么呢？是在小版本的升级上面能够做到zero down time。但是在大版本的升级上面很难做到这种升级，怎么样能够在大版本的升级上面尽量降低它的维护窗口，这也是金融行业对于数据库升级方面的一些要求。虽然金融行业不是互联网，但实际上，这么多年的数字化转型，它是越来越像互联网，像平安来讲，产检里面它要跟外部的快手、携程这样的合作基本上都是 24小时。
申请一个宕机窗口或者维护窗口越来越难，那在这个过程中做变更、做数据库的升级，怎么样能够最小化这个maintains Window，这是对于关系型数据库提出的一个要求，要一步一步的去看怎么样能够尽量的缩短。还有性能的稳定性，在一些迁移的过程中，怎么样能够保证在迁移前后的性能是稳定的？大家都不希望看到性能是波动的，经常说到可预测，也就是说宁愿是一个延迟相对来说比较高的但稳定的，也不希望延迟忽高忽低完全不可预测，另外一方面大家永远盯的是白纸上的黑点，如果你100个SQL里面99个用户性能都是提升的，但只要有一个在升级过程中它的性能是下降，肯定会说这个升级没有做好。
很多的数据库提供了一些工具像database replay、rit，可以重演负载。从低版本的数据库抓取负载，在高版本的数据库上面重演负载，或者在低版本的数据库上面抓取SQL语句，在高版本的要升级的目标版本上面数据库里面重放SQL语句，去看它的执行计划有没有变，响应时间有没有变，cpo、io消耗跟以前有什么变化。有没有什么变化能够保证现在提到的可预测是稳定的。
（3）数据保护
数据备份保存快速恢复这些都是相对来说一个基础的能力，实际上运行过程中，当需要恢复数据的时候，发现一些数据被错误的删除怎么样能够快速的恢复？使用flashback的功能。如果照不到一张表，可以快速的回滚把它先放到reSQL B里，然后同时通过flashback。如果flashback不行，比如他发现的时间很晚，flashback的时间失效，要从备份中恢复，怎么样可以不做整库的恢复、整个表空间的恢复，而只做这一张表的恢复？只做这一张表的恢复可以大大的缩短恢复的时间，缩短故障恢复的时效。这也是我们需要去考虑的数据的备份保存和快速恢复。
还有数据坏块的预防和检测，最近刚发生起一起事件就是因为在索引的配置上出现了一些逻辑上面的错误，通过物理的检测方法检测不出来。坏块分成两种，一种是physical corruption，一种是logical corruption。平安发生了一起logical corruption，它在内部的结构上面，通过physical检测不出来，只有通过内部的一些逻辑的检测才能够检测出来。怎么样在数据库的内核上面去检测出逻辑的logical corruption，这是非常重要的，如果是检测不出来，那就会出现报错，甚至于返回的数据即是错误。对于金融行业来讲，返回的数据是错误，特别在金额上，这是非常严重的一件事情。除了数据坏块的预防和检测，还有一些误操作的预防和恢复。
（4）数据容灾
删库跑路其实很多情况下并不是有意的去删库，而是因为打了rm-rf，将整个目录删除掉或者整个表错误删除掉，怎么样能够预防这种高危命令的出现？怎么样能够在这种高危命令发生的时候进行拦截？怎么样能够做到一些双因素的认证尽量减少这种误操作发生的概率？还是要进行数据容灾，一种是逻辑的，一种是物理的。跨站点的副本像跨可容区甚至于跨地域一些副本，像金融行业经常是同城双活和同城双中心，并且还要有远程的容灾站点。应用自动重联是为了在同城双活的切换或者远程的切换中，尽量降低对应用的影响，能够做到绘画保持、自动重联，做到对应用的感知是最小的。
2、数据安全
关于数据安全，国家对于数据安全是越来越重视，不停地出台一些法律法规。存储加密分成两层,一种叫tde，透明的加密是防止硬盘或者存储被别人拿走之后能够看到自己的数据，但是作为一个数据库的用户登录进去，就能看见所有的数据。存储加密还有一层是对字段通过一些算法比如国密算法进行加密，即便有权限登录进去，也只有能够看到这些敏感数据的人才能看到解密的数据，所以存储加密也分为两层。传输加密，一般通过https进行加密。然后数据脱敏也是通过授权，某些人是看不到信用卡号码、电话号码，会进行一些数据的屏蔽，通过这种方式，使别人看不到敏感数据。
另外就是一些对数据自身的保护，进行权限分离，一般在数据库里面有明确的要求，有管理员、安全员、操作员、普通用户的角色，管理员角色过往在数据库里面具有最高权限。比如root、pg、progress用户都相当于超级用户，可以看到所有的数据。但实际上细分，它作为一个数据管理员不应该能够看到业务的数据，所以就有了安全员的角色，只有安全员或者通过一些授权能够看到这些数据的用户，才能够登录数据库，即便是管理员没有这个权限也看不到，所以这是安全员的角色。还有一些操作员，管理员进行不了高位操作，它只能进行一些允许它进行一些常规操作。访问控制也是一样通过一些授权啊。
数据的审计也是非常重要的，刚才提到的是一些事前的控制，事后的控制就是通过审计：对用户进行审计，对single statement 、update、 delete、 inserts甚至于select这种curry进行审计，对数据库的对象进行审计，对表进行审计，对一些视图进行审计，看什么时间、什么人访问了什么对象、什么数据等等，这就是细粒度的审计。在很多数据库里面现在往往不太完善，虽然表面上有审计功能，有权限访问控制功能，但是它的颗粒度不够细。但现在对于颗粒度足够的权限控制，还有审计的颗粒度都要求越来越细。
3、可运维性
对于金融行业可运维性是极其重要的，前面提到的都是数据库内核自身的一些功能，但是可运维性是在数据库的内核上面所具备的一些功能。简单提一下非数据库自身的功能：活跃的社区、良好的文档、文档可以跟大模型ai相结合、完成智能问答、降低dba的维护复杂度、完成自动的问答、多样的生态伙伴、可持续的人才梯队、dba团队梯队的建设。
重点讲可观测性，现在很多国产数据库的可观测性是不够的，比如一个SQL语句它是可以去识别出来是一个慢SQL，但是这个慢SQL到底慢在哪里是不知道的，只知道它是一个慢SQL。一个复杂SQL语句不知道他慢在哪，怎么样去对它进行针对性的优化？到底是关联的方式不对，还是关联的次序不对，还有中间的结果积太大是不知道的。所以摆很多点在数据内核里，当问题发生的时候，可以快速的收集信息，知道它慢在哪，有针对性的去进行优化，并且尽快的恢复服务，这是可观测性方面的一部分。
数据库是一个承上启下组件，它对操作系统、服务器、存储的依赖性很强。很多情况下，问题解决都需要结合操作系统的一些功能和存储方面的一些性能数据才能够诊断出来，这也是可观测性的一部分。确保能够在最短的时间内收集到足够的诊断信息，有一个全面的数据去做出一个正确的决策。
可干预方面，当发现了一个SQL语句出现问题之后，现在往往是束手无策的，应用没有做限流，dba就会不停的跳，前端就会不停的涌入，就是比谁的速度快。但实际上，手工始终没有应用前端连接的速度快，所以最后就会一直打爆。所以在这种情况下应该有一个SQL的隔离室，当识别出来这条SQL语句就快速的把它扔到隔离室，甚至可以在它执行之前就把它自动拦截掉，这就是所说的可干预。
4、降本增效
硬件成本方面享受了硬件的技术提升还有价格降低带来的红利，在这个方面持续的降本。还有迁移的降本，在数据库升级有时候需要用迁移的方式，还有一些机房的持续转移。这两年平安科技进行了一些机房的裁撤迁移，在这个过程中怎么样释放人力，让重复性的劳动通过工具来实现？就要利用迁移工具兼容的特性，配合着数据校验。在迁移过程中，如果用逻辑同步怎么样能够保证数据是一致的，能够降低迁移过程中的成本，增加迁移的效率？
5、阿里云数据库助力构建普惠金融系统
金融行业对于关系型数据库分为四大类：降本增效、可运维性、数据安全、业务连续性。平安科技已经跟阿里云进行了一些合作，在香港的公有云上面已经用了阿里云的数据库，并且阿里云的产品也很全面，包括RDS、分析的数据库和know SQL。阿里云这两年的产品线越来越丰富，并且成本也在不断降低，功能也在不断的增强。平安科技在海外的公有云上面用了阿里的数据库，实现了业务的平滑迁移，包括全量的同步和增量同步。能够在同步的过程中、切换的过程中尽量减少对业务的感知，让业务无感知的进行切换。
同时还利用了一些分层存储，通过冷热存储进一步的降低成本。阿里云的数据库的能力很强，在slv、高可用的等级上面每年都有不断的提升，即它对业务的影响会逐渐的降低，而且是越来越小。它还提供了多个区域的快速部署以及机房级的容灾能力，基本上同前面讲到的业务连续性、数据安全、降低成本、增加运维效率和可观测性是吻合的。
