2019阿里云峰会·上海开发者大会于7月24日盛大开幕，本次峰会与未来世界的开发者们分享开源大数据、IT基础设施云化、数据库、云原生、物联网等领域的技术干货，共同探讨前沿科技趋势。本文整理自数据库专场中阿里云智能技术专家王天振 (为知)的精彩演讲，传统数据库研发模式不仅困难重重，并且效率低下，而基于DMS的企业级数据库新型研发模式却能够做到研发高效，变更稳定和数据安全，本文就为大家介绍阿里巴巴根据自身经验沉淀下来的企业级数据库新型研发模式。
数据库专场PPT下载
本文内容整理自演讲视频以及PPT。
本次分享的内容是企业级数据库新型研发模式，这种研发模式在阿里巴巴集团内部已经应用了将近十年的时间。阿里巴巴内部有大约数十万的研发人员，而这数十万研发人员每天都会产生很多数据库变更、查询以及数据导出的需求。而在阿里内部，仅通过两位数的DBA就能够满足数十万研发人员全部的数据库操作需求，这背后所依靠的正是企业级数据库新型研发模式。
本次分享将主要围绕以下三个方面：
一、云时代数据库的研发挑战
二、新型研发模式概述
三、数据管理DMS最佳实践
数据库研发的全生命周期
数据库研发的全生命周期如下图所示。这里的数据库研发指的是一款产品在其创作与迭代过程中，研发人员所需要参与的涉及到数据库的相关工作，这些工作就叫做数据库研发。数据库研发的全生命周期主要划分成了7个部分，分别是实例管理、权限管控、表结构设计、数据阶段、SQL查询、SQL审核以及性能诊断&优化，这些都需要研发人员、DBA、运维人员以及项目的负责人参与进来。
传统数据库研发面临的挑战
传统数据库研发方式需要面对三个主要的挑战，即研发效低、数据安全无保障、变更风险大。
研发效率低：传统数据库研发模式下，研发人员、运维人员甚至测试人员等产品中涉及到的所有相关人员可能都需要接触数据库，在这个过程中需要与DBA进行沟通，比如研发人员告知DBA今晚8点想要发布一个表结构。然而，在晚上8点的时候可能突然出现了业务高峰，就需要取消表结构的发布，这样的过程需要研发人员与DBA以及项目Leader反复沟通，使得沟通成本变得非常高。此外，这种方式也使得研发规范难以落实，研发规范往往是根据DBA的经验总结而成的，可能推荐了主键的使用方式以及索引和列的类型等。但是，由于研发人员的能力参差不齐，想要让整个研发团队的全体成员都能够遵守研发规范，往往很难落实。如果通过文本或者培训来落实，不仅成本比较高，而且难度也比较大。而且多环境研发也是一个难题。对于产品研发而言，可能有测试环境、开发环境，如果处在金融领域，可能有更加复杂的环境。针对不同的环境，研发方式也各有不同，如果还是需要和人进行沟通，就会使得沟通成本、研发时间以及功能上线时间都无法控制，进而造成研发效率的低下。
数据安全无保障：传统数据库研发模式下，DBA会给研发人员一个数据库账号，或者团队共用一个账号。这些账号可以实时地获取数据库信息，如果数据库中存储了业务敏感信息，还有可能在不知情的情况下发生信息泄露。而传统数据库研发模式下，往往没有审计或者审计比较弱，研发人员到底查了多少条数据，返回了哪些数据，DBA可能也不清楚。此外，当有人员离职或者转岗的时候，对于数据库账号的处理问题，都是数据安全需要考虑的范围。
变更风险大：首先，表结构变更锁表会影响业务，比如在传统数据库研发中做了一个DDL，直接把线上的IOPS打上去了或者直接锁表，使得业务无法读取数据。这种情况下，如果比较严重就会造成故障，如果不严重可能使得业务出现抖动。其次，变更误操作无法实现快速恢复，本来只需要更新10条数据，但是遗漏了WHERE条件就将全部的数据都修改了，这样该怎么办？最后，业务高峰期的变更更加难以防范，研发人员提出在8点进行变更，而DBA可能因为负责多条业务线不清楚每条业务线的高峰期，而在8点做变更时遇到业务高峰期，产生了故障。因此，如何从研发层面拦截高峰期的变更也都是传统数据库研发模式所需要面对的挑战。
阿里巴巴拥有数十万的研发人员，如果不去解决在数据库研发生命周期中的这三个问题，就会使得业务受到严重受影响。因此，阿里巴巴在使用DMS的过程中，提出了一种新型的数据库研发模式。阿里巴巴所提出的新型数据库研发模式需要多种角色参与进来，技术负责人需要把控所有数据库，可能由CTO或者数据库团队的Leader承担；还有就是DBA或者运维人员；再有安全管理人员，最后还有产品研发团队的成员。
数据库新型研发模式主要分为两个阶段。第一阶段从技术负责人开始，会先把DBA、业务Leader以及研发等的角色划分出来，并且制定安全规则，比如每个人能查多少数据，每天可以查多少次，以及变更时间范围等，还需要进行资源采购，这些就是技术负责人需要做的事情。DBA和运维人员需要制定一些规范，比如每个表里面不能超过几个索引，必须有什么样的主键和UK，表名或者列名必须要加有什么样的业务属性等。此外，还需要设置一定的变更规范，比如几点可以变更，同时可以变更几张表，以及表的大小限制等，这些规范都需要由DBA来落实。下一个步骤就到研发、测试和运营人员了，此时资源、规范以及业务线都已经准备好了，所需要做的就是申请数据库的权限，进而执行数据查询、导出以及对于表结构的变更和性能的查询等，这些研发人员常用的需求在研发流程中都可以实现全自助。
在第二阶段，研发人员发起一个申请工单提交上去，DMS会将DBA的经验和建议提供给研发人员，帮助研发人员优化自身的SQL。如果因为某些原因或者需求必须要违背一定的规范，就需要上升到另外一级进行审批把控。在这个部分，DMS会将风险收集起来提供给审批人，而整个审批过程可以实现自定义，也就是说企业可以根据自身的业务属性决定谁来审批。审批把控通过之后，则直接由发起人进行SQL的落地执行。最后一点就是全局风险掌控，技术负责人可以在产品里面查看今天业务被查询了多少次，有几个张表发生了变更，业务增长情况如何，哪些人员查询了哪些库，返回了多少数据，并且可以看到一些数据库风险报告和数据安全报告，包括安全管理人员提供的数据审计报告，这大致就是整个新型数据库研发流程。
数据管理DMS简介
下图基本上展示了DMS的整个能力范围，其下层支持了二十多种的数据源接入，并且能够进行统一的管理。DMS上层提供了非常丰富的功能供研发使用，基本上不需要DBA参与中间过程，而只需要做把控就好了。在风险把控之外需要进行审批的，才会上升到上一级，而不需要风险上升的只需要进行审计即可。DMS通过研发规范、权限控制、操作拦截以及数据脱敏、变更回滚等功能，保证了数据安全，并且提升研发效率。
安全与效率:权限管控
接下来从几个场景来介绍数据管理DMS最佳实践。第一个场景就是权限管控。简单而言，创建一个新的业务，这个业务涉及到新的数据库，这种情况下，运营、开发、测试、审计以及实习生等都需要拥有查询数据库的权限。因此就需要给与他们一个账号，传统数据库研发模式中，都是找DBA进行沟通或者为团队提供一个通用账号。如果和DBA进行沟通，DBA还需要根据具体的需求在邮件里面写清楚为研发人员申请了什么账号，并且需要去数据库实例上为用户赋予相应的权限，整个流程很复杂，沟通成本也很高。
如上图所示，传统的数据库研发模式有几个缺点。首先，DBA进行账号授权，仅仅是数据库层面的操作，而无法打通企业的组织架构，DBA并不清楚账号的真实使用者是谁，只能认为记录下来是谁就是谁。其次，还有多库多账号问题。DBA手中可能管理了10个实例和200个数据库，这些实例和库甚至到表级别都需要细分下来进行整理，这个过程中授权数量非常庞大，实例数和机器的数量也很多。第三点，沟通效率低，并且运维成本高。第四点就是SQL查询和执行记录的审计比较困难，数据库本身的审计能力基本为零，可能DBA只能看到SQL执行了，但是并不能看到SQL影响了多少行数据以及具体造成了什么影响，也无法知道具体是谁执行的。此外，在传统的数据库研发模式下，可能因为上述与DBA沟通的方式过于繁琐和困难，因此一些企业或者团队干脆使用通用账号，这就会带来安全上的问题等。以上这些是现有的场景，也是所需要面对的挑战。
而在企业DMS中，则为数据库和人员构建了新的授权管理体系，即DMS统一授权管理体系。此时，数据库只需要将权限授予DMS，而DMS可以再将权限进一步授权给研发、运维等人员。相关的人员只需要在DMS中输入所需要申请哪个库的哪种类型的权限（可以细化为查询、导出以及变更三种类型），申请时间为多久等信息即可。并且不同于数据库权限仅能限制到表级别，DMS授予的权限可以细化到列级别。对于敏感列的数据而言，可能查询出来就直接是脱敏之后的数据了。当相关人员输入完上述信息，提交申请，如果所申请的是非核心数据库的权限，直接到研发Leader或者DBA审批完成就可以获得了，如果出现人员离职或者过期等情况，数据库权限都可以实现自动回收。这样不仅能够解决传统授权方式所带来的一些问题，还能够使得效率大大提升，并且需要参与的人员也更少。
常规的数据查询需求有风险吗?
这里有一个问题，就是常规的数据查询需求有风险吗？比如研发人员说他要排查线上的问题，运维人员说他要查过去一年的业务数据，如果处在金融场景的话，大部分企业可能都不会给这些人员真正的数据库账号，因此面对这样的需求就会落到两种解决方案上。
第一种方案是集中式管控，对于这种方案而言，责任就落到了DBA身上，让DBA帮研发和运维人员查询业务数据。另外一种方案就是松散式管控，也就是让研发人员直接到数据库上进行查询。但是这两种方案都会带来一些问题，如果使用集中式管控，作为DBA而言，可能各个业务团队都有各种各样的需求，而自身的工作能力是有限的，每天所能做的也就只是几十次查询，并且面对这些需求，对于DBA自身而言，也不会得到任何成长。而且这些需求也都是机械化的，并且还存在DBA的单点瓶颈，往来邮件的沟通成本非常高。而如果使用松散式管控，研发人员拿着一个账号到数据库上随便查，这就可能因为任意的查询导致数据泄露，也可能因为输入了烂SQL将数据库打挂或者将业务搞垮，也有可能因为误操作将数据弄错了，这些风险可能会导致业务产品的迭代速度不可控。而无论对于研发Leader还是DBA而言，都需要尽量避免这些风险。
安全与效率:数据查询
那么，在DMS中是如何避免上述风险的呢？DMS提供了可控的SQL查询操作，其包含了全局权限管控、风险识别、数据脱敏、操作审计以及安全规则引擎等。对于前面所提到的场景而言，研发、测试、运营发起一条SQL查询之后，过程中会有三个拦截点，第一个拦截点是权限检查，其会判断是所执行的SQL语句否有相应数据库和数据表的权限，进一步细化地判断所查询的机器是否是可授权的。DMS还会提供一些智能提示，并且能够提供历史SQL的保存、模板SQL以及格式化等功能。通过了第一个检查点说明用户本人的权限以及查询SQL的权限没有问题。
第二个检查点会执行风险预警，也就是判断用户所发起的这条SQL是否存在风险，是否需要针对该条SQL实现主备分离，进而到备库上去执行查询。这部分还会生成执行计划，来判断该条SQL造成的影响是否会远大于预期。如果预期的影响会远大于预期，那么执行计划就会被拦截掉。
第三个检查点会对于高风险语句进行拦截，比如在DBA设置的规范里面不允许用户直接执行没有WHERE条件的SQL语句，可以直接拦截掉存在较高风险的SQL语句。在第三个检查点还可以进行执行人限流，比如某人在一天之内已经查询了两万条数据，如果他还需要继续查询就可能存在安全问题，因此也会对其请求进行拦截。
当风控引擎执行完成之后，DMS就认为这条SQL可以丢到数据库里面执行，但这条SQL不一定就是安全的。为了保证数据库的安全和稳定，也需要一定的策略。比如设置超时机制，比如一条SQL只能执行60秒，超时自动中断，这样可以避免单条SQL执行超过60秒，进而产生不可控的影响。第二个策略就是使用全局连接池，可以避免DMS创建过多的连接。第三个策略就是限制结果行数，用户一条SQL执行查询，可能会返回几万条数据，但是这样的数据量可能并不是他所预期的，用户可能只想看一下这张表里面有没有数据，因此可以限制查询结果的行数。此外，DMS还可以做实例性能实时探测，能够实时地显示在某条SQL在执行的过程中数据库实例的性能表现。实例性能降低可能是因为SQL影响，也可能是因为正处于业务高峰期，而通过实例探测来发现异常，就可以实时中断掉SQL的执行。
当结果查询返回之后，还会存在一个拦截点，就是对结果风险的预警。数据返回之后需要进行数据安全上的检查，分析返回的数据里面是否存在敏感数据，如果存在，还需要对于敏感数据进行脱敏。此外，DMS还会分析某条SQL语句执行完成之后，影响了多少行数据，查出了多少行数据以及哪些列，并对于这些数据进行真实的审计。除了数据审计之外，DMS还会进行业务审计以及操作审计，也就是用户发起的SQL是什么，造成的影响如何都会审计下来。
DMS还拥有一个全局的安全规则引擎，整个过程中要不要做主备分流，执行语句的检查粒度如何，比如执行计划所需要拦截的阈值、高风险语句等都是在安全规则管控引擎里面设置的。安全管控引擎进行拦截所依赖的经验来自于DBA和实际的业务，不同的企业或者不同的团队都可以在安全管控引擎上自己定义相应的经验。经过了上述的各个步骤，数据查询的整个过程就完成了，并将最终结果展示给了用户，并且提前避掉了之前传统数据库研发模式所面临的风险。
表结构变更要很小心!
在进行表结构变更时需要很小心。以一个具体的场景作为例子，一个核心业务表负责的是24小时在线业务，这个表非常大并且没有业务低峰期。在这种场景之下，研发同学要执行一个DDL，根据经验来说，这样一定会造成很高的IOPS，还会造成业务抖动。那么，如何避免这样的问题呢？此外，可能还会有其他的问题，比如业务同学说表的主键是int类型，而因为数据量急速增长，马上就要超出int类型所能表示的范围了，再跑就查不到数据了，业务就会出现故障，此时该怎么办？对于这样数据量又大，流量又高的数据表，在DMS中如何避免因为表结构变更而造成的问题呢？
之所以造成上述问题，主要存在两个原因，一者是这张表的主键使用了int类型，以为一般而言应该使用bigint类型，二者需要考虑如何对于这样的表做DDL而不影响业务。
安全与效率:表结构设计
那么DMS是如何实现高效研发流程中的表结构设计的呢？首先，研发人员需要提交一个对于某张表进行变更的工单，而在表的设计阶段则存在一些约束，比如索引、列以及命名的规范等，像上述场景中使用int作为主键的数据类型在这个阶段就会被拦截掉，必须要使用bigint作为主键的类型。此外，在设计阶段也可能存在这样一种情况，同一个研发团队的两个人合作实现一个业务需求，每个人都需要做一个DDL，可能涉及到一张表，也可能是两张表，如果是两张表还可能存在业务交叉。这种情况下，在表结构设计中会强制他们参与到一个工单里面进行协作，也就是进行表字段级别的协作。需要他们有一致的设计副本，发布时间也要求必须一致，这样才能跟上功能迭代的速度。设计阶段完成以后，研发人员可以认为现在设计的副本已经完成了，测试环节也验证通过了，接下来可以发布到线上去。而在发布过程中不可避免地会出现业务需求的变动，或者领导认为设计不合理等情况，此时就可以实现回退撤销，并进行重新设计，这些都是在设计阶段可以做的事情。
当确认表格设计没有问题就到了发布阶段，这个阶段需要为TL或者DBA提供一些决策信息来判断发布是否合理。DMS会将一些风险数据，比如这张表有多大，有多少个索引，将会做什么操作，会对数据库造成什么影响等收集起来并汇总给审批人，由审批人决定是否可以执行。即便研发人员因为技术能力不够，或者在提交表结构设计时没有充分地考虑各种场景，在审批阶段DBA或者TL都可以拒绝掉发布请求。
发布完成以后，就到了执行阶段。在执行阶段并不能保证一定是安全的，而DMS里面有几个策略能够降低变更风险，比如保证所有变更都是不锁表的，像前面提到了主键从int变为bigint在MySQL中一定是锁表的，而在DMS里面提供了无锁表结构变更功能，其能够保证覆盖到原生DDL覆盖不到的地方，这样不仅能够保证表在变更时对业务不会产生影响，还能保证对于IOPS也不会产生影响。第二个策略就是DDL并发控制，DDL在执行过程中，可能会使得多条SQL在执行过程中会产生冲突，而在DMS里面可以设并发控制，来设置在一个库上或者一个实例上最多有几条SQL同时执行，以此避免冲突。此外，还有锁等待检测功能，比如业务上有一个大的Update， DDL发上去之后，导致业务全部停止了，就会造成故障，而DMS会提供一个锁等待来检查现在的表上是否有锁，如果几秒钟都等不到就放弃更新，以此来避免风险。此外的实例性能探测、变更中断策略也都是为了不影响业务。最终，表的变更就执行结束了。
在表结构设计方面，DMS同样也提供了一个安全规则引擎，可以设置一定的阈值，设置哪些点开启，哪些点关闭，这些都可以由DBA进行操作。
安全与效率:数据变更
数据变更的需求十分常见，比如往往需要更新、插入或者删除一些业务数据，就需要实现数据变更。在传统的数据库研发模式下，需要提交一条SQL，之后还需要经过TL、DBA的层层审批，可能几个小时甚至一两天就过去了。
传统数据库研发模式下，实现数据变更的过程耗时比较久，而且最终还是需要DBA来执行。而DBA一天大约只能处理20个工单，这种方式使得沟通成本很高，也容易引发故障。而在DMS中，所有的工单都可以由研发人员自助提交，而DMS可以根据内置的DBA经验进行风险决策，判断是否需要上升到TL甚至DBA层级来确认。如果不需要上升风险等级，大约5分钟左右就可以完成自动审批，之后研发人员直接执行SQL即可，完全不需要其他人员的参与，相比于原来的模式极大地提升了效率。
更多的功能
除了上述所分享的功能之外，DMS还提供了很多其他的功能。DMS在AnalyticDB、POLARDB、RDS for MySQL中都作为工具进行了输出。总体而言，DMS能够帮助数据库研发流程做到研发高效、变更稳定以及数据安全。在研发高效层面，DMS能够提供高效的研发流程、全局的数据库管理、便捷的数据查询、易用的数据分析以及通畅的数据库触达；在变更稳定层面，DMS能够提供智能的SQL风险审核、不锁表结构变更、不锁表数据变更、可靠的SQL执行以及精准的数据回滚；在数据安全层面，DMS能够提供统一的授权管理、可控的数据查询、智能的数据脱敏、精确的操作审计以及定制的安全规则。
DMS实践下的全生命周期
如下图所示的是DMS实践下的全生命周期。DMS能够支持数据库研发的全生命周期的各个部分，在混合云实例管理方面，可以用户通过DMS购买云实例、同步混合云实例并且
创建新数据库。在分级权限管控方面，通过DMS可以设置变更、导出、查询权限，可以针对库、表、敏感列设置权限，并且能够做到统一授权管理和个人账号绑定。在表结构设计方面，DMS能够帮助MySQL、PolarDB、DRDS、Oceanbase等数据库设计表结构，并且能够实现多套环境发布、实现不锁表的表结构变更以及变更窗口管控。在数据方案方面，DMS能够实现不锁表数据变更、历史数据清理以及对于数据的订正和导入、导出。在SQL查询方面，DMS能够实现数据脱敏、影响行数提醒、可控数据查询、跨库查询以及数据分析。在SQL审核方面，DMS实现了应用代码审核、SQL文本和规范约束检查以及索引推荐。在性能诊断&优化方面，DMS能够预测空间和性能的变化趋势，进行SQL诊断优化，并且分析会话和实时性能。