开发者学堂课程【企业运维训练营之数据库原理与实践课程 ：云数据库管理 DMS（二）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1201/detail/18286
云数据库管理 DMS
三、DMS 解决方案
我们再来看一下敏感数据的管理。敏感数据资产在现代企业是非常重要的。各大企业其实也越来越重视对数据资产的保护，特别是数据库中的敏感数据，就是我们经常能听到由于敏感数据管理不善导致的数据泄露而引发企业公关风险还是很多的。大概有调研数据说有超过50%数据泄露都是由于内部人员泄露出去的。其实跟管理不是有很大关系，所以应该怎么去管理敏感数据，这是敏感数据管理的难点。其实主要有几方面，一个是怎么去使用这些敏感数据，用户个人信息、银行卡号、身份身份证号等等。还有就是怎么去做到单独的授权、怎么去限制人员的访问，以及怎么做到审计。DMS提供了一套完善啊并且灵活的敏感数据管理体系。它首先支持了一个规则扫描的方式去识别敏感数据，DMS系统内内置了很多行业或者法案等识别规则，也支持用户自定义基元数据或者数据内容的识别规则，具体系统会去扫描目标库的元数据或者随机抽取少量的抽样数据，匹配的就会被打标成敏感数据。
少量数据一般是几百行都是很小的，也不会去其他地方存储。只适用于抽样、检查、匹配，针对这些敏感的打样数据，可以设置一些加密算法，加密算法还是很灵活的，比如有哈西、遮掩、替换、变换，这其中每一种，其实有很多种细分的，这些算法有助于实现不同场景的差异化脱敏，如果这个字段是已经识别成敏感字段，如果需要去查询这个敏感字段的数据，即使有库表权限，不申请敏感字段的权限也是看不到的，只会显示一个脱敏之后的数据。那就需要单独申请敏感字段的权限。面这张图也给了一个样例，如果没有铭文权限或者是半脱敏权限，它全部都是星号，这就是替换遮掩的算法，如果是半脱敏权限只会显示一半的数据。只有申请铭文权限才会显示完整的铭文数据，还有一个使用场景就是如果敏感数据加密了，但是有些企业里面可能要做到生产数据跟测试数据的联动，但是一定要经过脱敏或者有一些其他用途，可以通过加密字段加密之后直接查出来，直接导出就可以了，这在导入到其他的环境或者是用于其他用途都是可以的。
DMS 也提供了敏感数据的审计功能，记录了敏感数据在 DMS 中的使用情况，方便解决敏感数据异常使用或者数据泄露等溯源问题。右边是 DMS 的一个系统流程架构，大家可以简单了解一下。企业数据库管理中不同的业务场景或者系统可能会有不同的个性化需求，比如限制单次查询的返回行数或者是限制查询或者数据导出的超时时间，防止对线上业务的影响时间过长，又比如限制全表扫描的最大值，如果还有那种特殊场景，比如说双11这种公司业务在正在关键时刻的场景，需要对变更窗口进行管制，拦截一些高风险 SQL 或者是升级一下审批流程等等，这种个性化需求 DMS 也提供了相应的解决方案。
他主要是通过一组领域专专用语言 DSL 去对数据库实例，实现精细化的管控，通过这些 DSL 的安全规则对 DMS 上的操作进行管控，可以在 DMS 的平台内打造一套符合企业实际操作规范的流程和研发流程。任何不符合这些安全规范的操作的 DMS 都会进行拦截，这里目前默认 DMS 内置了很多阿里巴巴的安全规范，用户也可以自定义。
可以给大家演示一下，比如说这是 DMS 数据管理服务的 web 页面，安全规则里面可以新增一个 mySQL 引擎，然后Test1117，提交。
这里就是一个继承了内置的安全规范的一个模板，大家可以看到这里面有很多很详细的安全规范，比如说单字查询最大返回行数，也可以在这里随机的自定义的去设置，还有限制全表扫描的最大值，还有关闭社会教育影响航速等等，还有单线制单次执行 Circle 的个数也是可以编辑的，比如可以定义1000个或者是其他的，这里就是 DSL 的一个语法。它包含四种，一个是因子，一个是动作，一个是函数，一个是操作符。因子其实就是一个条件，比如 if、else 、and 这里面的一个条件。动作就是拒绝执行还是允许执行，拒绝后面可以带一个备注，弹窗提示吗不允许超过1000或者其他。函数其实就是一个条件的拼接。操作符其实就是大于、小于，这种都是可以非常定制化的去实现你的一些个性化需求。
除了这种适合窗口的变更还有很多，比如数据导出。这个就是数据库导出的审批模板，这里可以配置一下。就是需要切换哪种审批模板，这种模板也是可以定制的，比如审批流程里面可以新增审批模板，有很多角色，比如这个先Owner，然后 DBA，然后在 Admin 审批一层一层下来，如果是要应对一些公司业务特殊时刻又升级审批流程，其实可以订制一个审批流程，比如上达到某某老板、某某总监就可以了。这个安全规则里面其实还有很多种，比如权限申请的流程，还有一些表结构设计，这里 SQL 优化审计后面也会再讲一下。
数据访问最后一环其实就是操作审计，这也是很多监管政策的要求，为了方便快速定位和排查数据库问题，以及提供审计运作，DMS 是在原来操作日志的基础上推出了操作审计功能，包括 SQL 窗口产生的 SQL 语句列表、工单列表，还有登录列表操作日志等等，审计人员或者是管理员可以随时通过控制台页面或者 open API 去获取的审计日志。下面那张图其实就是一个展示的一个样例，他能非常详细的记录当时是执行了什么操作，比如说这个 dms read only，人员在这个时间执行了 Stacked 那个表的 SQL 操作，这些都是可以很详细的查得到的。
从这个方案开始其实就进入了数据变更安全规范解决方案里面了，然后这个整合通常企业都有一套自己的数据开发规范，但是无法保证所有人都能严格遵守。如果线上上线了一个非常低效或者有漏洞 SQL 可能会导致数据库的故障。传统的收购审核非常依赖于人工，这种效率太差，而且容易出错。EMS 提供了一种审核方案，它支持对上传的 SQL 语序进行审核并提出优化建议，避免无索引或者不规范的 SQL，降低 SQL 的风险，它其实也是依赖于上面提到的安全规则来实现来实现自定义的就是规则的设置，它主要提供了就是三种系统行为动作，必须改进潜在问题、建议改进等等，必须改进的话会阻塞收购的执行，直到改进并验证通过后才允许执行。
审核建议就是机构整合优化建议，大家可以看到里面其实有很多内置的安全规范，比如说表又有主见，要有备注，不能有外界，限制大小写，比如他是大写不能是小写，这里可以看到。行为动作，这里有很多，潜在问题，建议改进潜在问题的建议改进执行，只会去弹出他的优化建议，但是不会阻塞执行，但是如果改成必须执行，如果这个表的字段数量超过了128，那这个建表 SQL 是执行不下去的。这里优化建议也是可以编辑的。DMS 不只是能支持 SQL 的一个审核也支持很多类型文件的审核，比如代码框架的 XML 文件，或者 SQL 文本文件或者 Trick 数据库日志文件等等。
大家可以看一下这个样例，就是这里提到申请了一个 SQL 审核，这个有一个 SQL 不通过，这是一个 SQL 文件，是有一个 SQLSlack 新 from my study user，看一下它的详情，他的建议改进，就是说一定要有外条件，这是一个建议改进就是不会处事执行。通过这种方式 DMS 能非常灵活的去自定义或者是去做到自动化的审核。
接下来看一下表结构变更数据变更方面，DMS 能给我们带来什么样的解决方案。数据库在做 DDL 的时候虽然这个操作很常见，但是也是让 DBA 特别头疼的一件事情，特别是数据量很大的情况下，因为 DDL 会有锁阻塞，就算是业务的分期执行也会对业务带来风险，所以 MYSQL 在5.6之后提供了一些原生的 onlineddl 能力，它能覆盖很大部分的DDL 类型，比如添加或者删除列，但是仍有部分常见的 DDL 是不支持的，比如修改列类型或者长度修改字不齐等。市面上也有一些开源的工具支持更广泛的 ddl 类型的 onlineddl 工具，但是这种实现的方式是依赖于触发器去实现它的增量数据同步。这个我可以先给大家来简单解释一下就是 onlineddl 的简单的原理，就是先生成一个临时表，这个临时表的新结构就是做 DDL 之后的那个结构，然后再将数据全量同步到这个临时表中，然后通过某种方式，比如这个 PDF 其实就是通过触发器的方式去保存它的增量数据，最后再把它运用到临时表中，最后再隔夜的时候就是把表明换一下就是切换一下见右表这种原理。但是通过触发器来实现增量数据同步的话就存在很多的弊端，比如说触发器本身就有很大的性能开销，触发器实际是将两张表的操作关联到一个事物中，这样也会导致所竞争的增加。这种方式的话是不能暂停或者中断就会出现就是变更中断或者数据丢失等等，后续的处理就会变得很麻烦，同时这种方式没办法去灵活控制，所以会带来很大的准备延迟问题。
DMS 的无锁表结构变更是通过一种全新的方式，他不是依赖于触发器去实现的。而是他消费 binlog 的事件，将原表的增量变换保存下来，然后再回放到目标表中，这种方式有个很明显的优势是它将原表和目标表其实是已经结有了，目标表的增量数据并不直接来源于原表而是消费 binLog，如果消费 binlog 中断，只需要继续消费就可以了，这也带来了 DMS 无锁表结构变更的另外一个很大的优势，就是 DMS 可以根据系统的负载以及祖辈延迟的情况随时中断或者放慢 DDL 的执行速度。虽然这种方式会将 DMS 的 onlineDDS 时间长于其他的方式，比如触发器这种方式，但是这种方式影响更小，并且更健壮，他失败的话重启一下就好了，重试一下任务就好了，它的优势是明显大于劣势的。刚刚提到他的逻辑是新旧表，所以开启 onlineddl 的数据在做完这个 DDL 的时候，可能发现它的表的碎片率变小了，因为他有个切换新旧表的操作新表的碎片率是很低的。
在执行大批量数据更新的时候就一般需要咨询很久，大事物也可能会导致锁表，并且在提交的时候很有可能是将数据库打卦的，因为数量变动变化很大，如果有个 bbinlog 他可能会去写临时文件，提交的时候又会经过首尔，然后又落到 binlog 文件中，这个过程很容易将数据库打卦的，所以一般都是建议将大批量的数据更新拆分成一个个小的批量去做，但是这种拆分其实是很复杂的，而且大家可能想到使用 Linux 来去做。但是还有一个问题，就是如果这个更新操作没有索引，就是更新字段条件字段是没有索引的，效率就会变得更加差了。
这里我就举个例子。比如 PPT 中执行一个大的 Update，发现 bug 导致业务故障，然后需要紧急定这个数据，那么就需要去将 State 等于 new 的这个用户的优惠券减少50，就是一个 Update 的操作，但是 State 等于 new 是没有索引的，而且也不适合建索引，但是这种情况下，如果直接去执行绝对是一个大失误，如果分批去执行很难找到一个很快速的方式，因为时 state 的字段是没有索引的。DMS 的不锁表数据变更是是自动去查找唯一键，然后根据唯一键去拆分SQL，比如说他将ID1到1000的去做一个批量，然后1000到2000制作一个批量，其实就是拆分成单个事物，单个 SQL 也是能走上索引的，这种效率是有很大的改善的，并且不会对线上业务造成很大的影响，不会有很大的阻塞。DMS 这个部署表结构，不锁数据变更的还有一个小小细节大家可以看一下，就是它有一个动态实例的策略，其实就是他在每次批量执行后会有一定的 sleep 进行缓冲，这样能有效的缓解大事故再次带来的储备延时问题也能保证主户更加稳定。
在做数据变更的时候突然发现跑错了，一个 SQL 导致误删数据或者是错误更新了大量的生产数据。并且当时忘记了在变更前做数据备份，那么我应该怎么样快速的做数据恢复。一般的流程可能大家也能想到就是通过数据库Dump去恢复数据，比如恢复全亮，然后再追增量，增量到哪个时间点或者是云上的话也提供了按照时间点恢复库表等等，但是这种方式成本很高，而且时间比较长，因为它还是需要去先恢复一下全量数据，然后再追增量，所以说它的成本是比较高的。并且这种方式也需要本身就有一个完善的备份方案，那么就是有没有其他的更快速的方式去做恢复呢。DMS 提供了一种数据追踪的方式就是只要提供误操作的时间以及 Soho 类型，还有表信息的它就可以快速的从 binlog 中去，按需找到目标时间段内的相关更新，然后汇总完行程逆向的一个回本数据，只需要将这些回本的 SQL 语句，在数据库中重新执行就可以了，这个下面这个 DNS 数据回滚就是解释的一个流程，它其实就是通过生成一个binlog 找到更新相关的表的更新，然后反向去生成一个 roll backSQL，然后再去执行一遍就可以了，这样能保证快速的去做数据恢复。今天的 DMS 的相关的这些解决方案就介绍到这儿，其实还有很多其他的最佳实践方案，比如一些研发效能或者一些具体场景，比如业务大促一些具体场景，我就没有在这里讲，大家可以参考官方文档，比如这里有很多最佳实践的解决方案，比如数据归档，最佳实践里面也有很多比如说 DML 数据管理预案助理业务大促，还有一些 SQL 审核的最佳方案，它里面也有很多审核规则的建议，还有一些安全管理的最佳实践等等，大家可以有兴趣再去看一下。
