干货整理｜SQL 审核最佳实践活动回顾

BB仔 Bytebase 2022-12-19

本周二，Bytebase 举行了第二次社区活动贝斯的圆桌趴｜DBA 福音 - SQL 审核最佳实践。我们的嘉宾们：阿里云 PolarDB 开源生态负责人 - 德哥，Pigsty 作者 / PostgreSQL 布道师 - 冯若航以及 Bytebase 首席拧巴官 - 天舟·陈在 Bytebase 直播间就「SQL 审核最佳实践」进行了愉悦的三方会谈。活动时，我们也收到许多同学的提问，未能及时在现场回答的问题我们也整理在了文末，请大家查阅。😏

完整视频大家可以在 Bytebase 视频号的「直播回放」里找到！

SQL 审核 101

「德哥，阿里云 PolarDB 开源生态负责人」

先来说说 SQL 审核是什么。业务在上线发布的时候会涉及数据库的变更操作，这些变更提交给数据库执行前，需要经过 DBA 进行审核；或者在正常业务的使用过程中，DBA/开发者/测试人员也可能会发起 SQL 请求，用于去查询数据，产生报表等，这些 SQL 语句也都要经过审核。

那为什么需要进行审核？比如可能出现删库跑路，执行 `DROP DATABASE`，`DROP TABLE` 等等；或者出现误操作，比如变更的 SQL 忘记加上 WHERE 条件了；或是未经优化的 SQL 发布，业务一上线就直接导致雪崩。所以 SQL 审核主要目的就是可以提前发现风险，避免产生问题。

如何进行 SQL 审核呢？一般来说，有三种方式：

静态规则：根据 SQL 本身定义一些风险等级，但很难穷举
动态规则：结合数据库实时统计信息，估算被评估 SQL 的执行时间、影响行数
基于动态规则 + 辅助输入进行决策：通过输入新增的或取消的 SQL (业务变更后不再需要的 SQL)，返回报告并揭示风险，给出 SQL 的优化建议

对于用户而言，Bytebase, Pigsty 与 PolarDB 的开源社区合作的价值当然在于用户使用 PolarDB 的开源版本可以更加从容了:

科技是第一生产力，Bytebase 把 DBA 的经验产品化后，至少在 SQL 自动审核层面，可以做到人人都具备 DBA 的能力，大幅度降低业务上线带来的 SQL 变更风险
Pigsty 覆盖了数据库实例的生命周期管理的能力，包括规模化部署、备份、恢复、容灾、高可用、监控、优化、诊断等 DBA 常用的需求

生态建设核心的一点，就是重新唤醒大家各自发挥自己的比较优势，来激发开源共同协作的氛围，推动整个产业良性的发展。我非常希望能够看到的一种全新的合作模式，大家能够发挥出自己的比较优势，最终给产业带来的是组织上人才体系的丰富，业务降本增效，文化上共同协作的能力。

👀 小编注：德哥完整的 blogpost 大家可以移步 GitHub (https://github.com/digoal/blog/blob/master/202206/20220628_01.md) 拜读 👏

SQL 现有流程 & 工具

「冯若航，Pigsty 作者/PostgreSQL 布道师」

我有三段经历，分别是在阿里、探探和 Apple 做 PostgreSQL 相关的事情：在探探管理一个 13k 的 PD 集群，220 套数据库；在苹果用了 24 套 PostgreSQL 搭的数据仓库，在 PG 领域也积累了不少经验。
之前做 SQL 审核，大体上分为几种模式。
在阿里，我们提交的 SQL 变更，DBA 统一在第二天凌晨四点审核，然后发布 DDL 变更，至于 DML，DQL，他们是不管的。后来到了探探，分成早期和后期：早期非常简单粗暴，所谓的流程就是研发发一封邮件，我们人工执行（虽然如此，门槛还是很高的，因为那时探探都是瑞典的 old-school 工程师，重度使用了存储过程）。所以做 SQL 变更和发布的时候，不仅仅是改表加减列，更多的是调整 update 存储过程。后来慢慢地切换到比较互联网派的做法，存储过程基本上以 CRUD 为主。到后期我们就基本采用 GitOps：在 GitLab 建一个仓库，存储所有的 SQL schema 定义，另外加一个工单系统，研发提了 git 变更后提到数据库的仓库，会自动生成一个工单，再到我们这儿审核和执行，这样就完成了一个闭环。但是在 Apple 又不太一样，用的是另一套东西：Flyway，其实也是 GitOps 的一种。比如要维护一个数据库的 schema，我们可能有一排 SQL 文件，然后由 Flyway 负责挨个地执行，并在数据库中附一张 migration 的表。变更逻辑大概长这样：
研发想在数据库里做一个变更，首先要 git 仓库里存储数据库的 schema 定义提交一个 PR 到 DBA 这儿，DBA 可以 reject 或 approve，之后 DBA 就人肉（生产环境）或用 Flyway 执行变更，成功后把 PR merge 到 master，表示这个 SQL 变更已经进入到仓库了；如果没有成功，就会 rollback。
我现在做 PostgreSQL 数据库发行版，可以理解为一条龙的 pg 解决方案。里面正好需要一个 SQL schema migrator，大概 2020 年年底的时候我们了解到了 Bytebase，它把 GitOps 的完整的审批和执行工作流这一套在一个软件里实现了，所以我们直接就把它集成了进来。我们做 PG 数据库的需要一个模式变更的东西，然后这个模式变更的工具 Bytebase 又正好需要一个 PG 数据库，简直太完美了。所以我们就提供了一个 Docker compose 文件，你可以一键拉起一个无状态的 Bytebase，并且使用外部发行版创建的数据库。

我觉得 Bytebase 的出现解决了作为 DBA 之前的一个很大的痛点，如果说接下来几个问题能够一起解决的话，我觉得那么基本上就是这个领域一个比较完善的工具了。比如说像加列减列这样的操作，我不知道 Bytebase 现在是一种什么样的状态，但是有很多操作锁的力度是很大的，如果 Bytebase 能把所有这样的 schema migration 的操作都做到最小化的锁粒度，那么这对于 DBA 来说是一个非常伟大的工具，我肯定会 pay for it 的 😊。

SQL 审核最佳实践

「陈天舟，Bytebase CEO 和联合创始人」

我之前是 Google 总部云数据库服务技术负责人，也在蚂蚁集团做过数据库 / 研发 / 协同平台负责人。

在 Google，整个团队用的都是 Google Spanner 数据库，然后所有的团队都用 GitOps。如果要 alter schema，我们会在内部代码平台提交 PR，审核通过它会 check 到代码库里面，但是接下来一步还是需要通过手动的。Spanner 提供了一个 CLI，然后手动完成变更。但是如果要变更一个主键，Spanner 是不允许的（至少我待的四五年里面，从来没有干过这个事情）。

对使用者来说，Spanner 有个非常强的一面，就是它的可运维性质，其实在 Google 内部是没有传统意义上的 DBA 团队，只有一个维护它的 infra 团队，他们每周会有一个小时左右的 office hour，要是有问题的话，可以这时候咨询。除非你的业务真的是出现 P0，P1 的故障了，可能是需要找 DBA，所有其他变更完全都是自助完成。

在蚂蚁，包括整个阿里内部，用的是一个叫做 iDB 的平台（对外就是阿里云上的 DMS），是一个比较经典的工单系统 (当然能力很强大)。iDB 没有类似谷歌 GitOps 的方案，它相对来说还是偏传统的：研发提交一张工单，推进到生产的时候，DBA 进行审核，然后进行变更。

Bytebase 其实就结合了这两个点：基于工单系统和 GitOps 的方案。但是我们在 Google 的方案上面做了创新：Google 有一步是人工手动审核的步骤，审批过后，他得自己用 CLI 调一下；Bytebase 通过 GitLab 的集成把这步给自动化了，提交的 SQL 语句提交到代码仓库之后，通过 webhook 触发会自动在 Bytebase 平台上形成一个工单，会直接进入 DBA 审批的流程。还有一个点在于 Bytebase 和 GitLab 的定位：Bytebase 主要还是由 DBA 来使用，因为 DBA 需要进行线上审核，但是 GitLab 主要由开发或业务团队来管理。通常来说，一个 SQL 变更会有两个阶段：业务团队先进行业务方面的审核，审核通过后，再由 DBA 从 SQL 的规范和数据库层面去审核。所以 Bytebase 其实就是对应着现在公司里面常见的组织关系设计的。

Q&A

Q: 像业界 MySQL 有比较成熟的 SQL 审核方案，PostgreSQL 还比较少，这是有什么难点吗？

A: 难点还是在解析 PostgreSQL SQL 方言的 Parser 上。MySQL 审核方案可以基于 inception 或者直接基于 pingcap/parser 做，PostgreSQL 社区目前还没有成熟的方案。不过这个情况马上将会迎来改变，因为我们内部已经开始自研 PostgreSQL parser。

Q: SQL 审核规则怎么做规则的配置化？

A: Bytebase 现在已经支持 SQL 审核规则的配置化了，DBA 可以在 Bytebase 平台为不同环境配置不同的审核策略。变更执行前，Bytebase 会根据配置的策略自动检查 SQL 语句，如有不符合规则的 SQL 语句，Bytebase 会以警告/错误信息的方式提示用户，并暂停正在执行的 schema 变更，详情请参考适用于 MySQL 的 Schema 审核策略。

Q: 现在的 SQL 语句都是在代码中， DBA 都是事后去分析这些慢查询的，很被动，Bytebase 怎么过滤这种慢查询呢？

A: 现在整个 DevOps 都在讲左移，当然是能越早发现问题越好，这块也在 Bytebase 规划和射程之内，结合代码静态分析去系统化地解决。但估计时间线会稍后一点，请大家再等等。

Q: Bytebase 能否按规则把存储过程分成脚本，达到审核存储过程的目的？

A: 存储过程虽然保存在数据库内，其实本质上是代码，而不是数据。所以管理存储过程，最好的方式其实是走 GitOps / Database-as-Code 的方式，把存储过程保存在代码仓库里。所以这个需求是完全命中 Bytebase VCS 变更流程的设计，现在就可以试一下！

Q: Bytebase 对 PostgreSQL 后续的支持计划是怎么样的？

A: 只要是支持 MySQL 的能力，PostgreSQL 这边后续都会加上。目前因为社区 PostgreSQL 的组件还不及 MySQL，所以在功能点上和 MySQL 有些差距，我们也打算先把这些坑填了，就是要多花一点时间。

Q: 基于你们的产品可以自己二次开发吗？

德哥：这个是必须可以的。PolarDB 是开源的，用的是 Apache 2.0 协议，所以拿去二次开发或者商用都是 OK 的。

冯若航：欢迎大家来奉献！Apache 2.0 协议允许商用，但是请遵循一个 notice 就是你不能说这东西就是你写的，除了这个小小的限制以外，它是非常非常友好的。实际上据我所知，Pigsty 作为运维监控数据库的一个工具是有不少厂商拿去自己用的。

天舟：Bytebase 代码是完全开源的，对于社区版的代码，我们使用的是 MIT 证书。而企业版的功能则需要购买企业版后才能使用。在遵循使用协议的情况下，二次开发是没有问题的。而且我们在设计的时候，也是专门架构成面向二次开发友好的，比如我们引入 namespace，插件化架构等。比如说如果想集成一个 Bytebase 目前还不支持的数据库类型，只要实现我们定义的 database driver 接口就行。