从 到 搭建技术中台之 SQL 审核平台.docxVIP

从 0 到 1 搭建技术大陆与台湾之 SQL 审核平台 随着伴鱼业务的快速进展，公司各产品线的业务不断丰富，日常的 SQL 上线也在不断添加。SQL 审核与执行，作为 DBA 每天工作中相当重要的一环，如何保证 SQL 语句的质量，对于系统的高效运转和长期稳定有着很大的影响。 本文在对开源 SQL 审核平台 (例如 Yearning、See 和 Archery 等) 进行调研，并结合 DBA 在 SQL 上线实践阅历的基础上，设计了伴鱼 SQL 审核平台。相比其它 SQL 审核平台，新系统次要包括以下核心功能： 基于 TiDB Parse 做 SQL 语法解析，践行 SQL 规范 基于公司组织架构做权限管理和流程审核 基于审核规章列表的动态开关 支持 SQL 执行数据备份和回滚 支持任务定时调度执行 下面从全体架构、流程设计等方面具体引见下伴鱼 SQL 审核平台以及设计背后的一些思考。 全体架构 SQL 审核架构，如下图所示，次要包括 web 前端、 SQL 审核后端和数据存储 TiDB。 流程设计 SQL 语句的质量对于系统的稳定高效运转有很大影响，因而 SQL 审核平台必需加强语句质量的审核。其次， SQL 审核平台在确保数据库平稳运转的同时，尽量提高上线的效率。 规章设计 通过系统约束是践行数据库规范最有效的手段。SQL 审核规章除了加入业界认可的规章外，我们还依据日常 SQL 上线暴露的一些风险场景，加入我们设计的一些规章。SQL 审核部分规章列表，如下图所示。 数据的删改关系到数据平安和 SQL 功能，其中 SQL 功能关系到线上服务的稳定性。这里简约引见下“删改数据规章”，次要包括以下三条规章： 删改数据索引不完全婚配 删改数据影响行数超过 100 影响行数超过 3000 下面对这 3 条规章进行解释： 日常数据修改，大多数场景只涉及少部分数据修改，所以只需完全走索引，功能基本没问题。假如系统检测到语句条件与线上索引不完全婚配，检测结果就会不通过。 在某些特殊场景下，索引完全婚配，但数据影响的实际行数可能较多 (大于配置影响行数 100)，这样检测结果也是不通过。 当然在表数据量不大 (万级别以内) 和索引没法掩盖等极少数场景下，可以通过关闭 1、2 两条规章，同时满足 3 这条规章的前提下，检测通过。 规章这样配置，一方面系统依据语句条件备份时，保证了快速高效；其次，数据执行权限已经下放给业务担任人，系统尽可能保证 SQL 的执行功能。 任务设计 业务 app 大版本上线，涉及 SQL 上线条数众多，在任务设计上次要做了如下几点考虑： 通常业务大版本上线，涉及多个业务线，所以 SQL 任务必需支持多库多表 SQL 任务通常包括建表、改表和增删改数据三品种型，每种任务需要区分对待，比如建表不会锁表，但需要关注表的索引；改表需要关注数据大小，任务最好不要在业务高峰期执行；增删改数据需要在执行前对数据进行备份，保证数据平安。 基于以上两点要求和任务提交的易用性，我们设计了任务检测页面，如下图所示。 其中，对于建表选项，我们要求每个输入框只输入一条建表语句，并备注每个表的查询和更新，这样设计的缘由是符合 DBA 审核习惯，便利 DBA 审核索引好坏。 任务检测 研发提交 SQL 任务检测后，后台基于 SQL 审核规章，对语句进行语法和规章进行检查，并将检测结果反馈给研发。在任务检测结果页，从易用性角度做了如下几点考虑： 提交检测的 SQL 众多，假如其中某些 SQL 不满足要求，需要支持在检测结果页直接修改并马上检测，不需要重新编辑全部任务再次提交 改表 (除加索引操作外) 只修改元数据，不需要拷贝数据，影响行数为 0，笼统的“代表”执行速度很快 删改数据，我们需要将数据真正影响的行数呈现给研发，让他们看到实际操作的数据条数，笼统的“告知”数据操作能否符合目标 检测结果页，如下图所示。 其中： 修改数据条件与索引不婚配，检测形态为失败； 添加索引，需要拷贝全表数据，影响行数为表总条数； 添加字段和数据类型加大，只涉及修改元数据，影响行数为 0； 第 4 条更新语句，满足删改规章，检测形态通过； 整个任务单，有条语句未通过，只需要修改该条语句满足审核规章，整个任务单才才可以提交审核，进入下一步流程。 任务审核 任务审核角色有 2 个，一级审核为业务担任人，担任审核任务提交同学的 SQL 质量，二级审核为 DBA ，进一步审核和提高 SQL 质量。审核流程，如下图所示。 目前，任务审核流程如下： 对于增删改数据操作，审核规章已经保证 SQL 功能和数据备份，审核和执行权限下放给一级审核人 对于建表， DBA 关注表的索引好坏问题，审核和执行权限由 DBA 担任 对于改表，涉及添加索引操作，需要关注语句的功能，审核和执行权限由