近期，我司准备引入一款 SQL 审核产品来供内部流程使用，解决目前 SQL 人工上线的流程管控问题，目标是对业内的开源产品进行调研，选型一款作为落地方案，后期如果内部有需求可能会进行二次开发。我们最终选取 SQLE^[1]、Yearning^[2]、Archery^[3] 进行了初步的使用和调研，我们内部关注产品的一些点：

1. 是否较为简单的部署和运维；
2. 规则是否能满足我们公司 SQL 规范，如果不满足至少要能二次开发；
3. 具备 SQL 上线流程，是否满足要求；
4. 产品稳定性，后期是否能得到支持。

下面是调研的过程，如果恰巧你也在调研 SQL 审核产品，希望能给你提供一些经验参考。

1、运维部署

功能对比

体验对比

由于公司内网无法访问公网，因此没有使用 Docker 部署，基本采用手工部署的形式进行，SQLE 和 Yearing 部署基本都算顺畅，但是 Archery 需要安装依赖，最终是选择在自己电脑虚拟机上装的。

• SQLE：手工部署是使用 RPM 包，不用安装操作系统依赖，一键安装和启停，使用 systemd 维护进程对运维较为友好，但是 RPM 会有操作系统限制（CentOS）；进行建库操作和修改配置文件即可跑起来；
• Yearning：手工部署使用 ZIP 包，解压后和 SQLE 类似，不用安装操作系统依赖；进行建库操作和修改配置文件，额外执行一下 Install 操作，即可跑起来；
• Archery：手工部署需要安装 Python 和依赖，操作较为复杂，搞了大半天没有成功最终放弃，采用 docker compose 部署了。

体验排名

（SQLE = Yearning）> Archery

2、审核能力

功能对比

体验对比

相比来说 SQLE 支持的规则最多，但是其他数据库类型例如 Oracle，PG，官方只提供了简单的实现，只有一条规则（等于没有）。目前我们公司都是 MySQL，倒是影响不大。

• SQLE：MySQL 部分的规则基本都覆盖到了我们公司的需求，有极少数后期可能考虑二开吧；与其他两款产品的最大区别是 SQLE 的规则粒度在数据源上，每个数据源（业务）可以设计自己的规则集这点比较灵活。规则展示列表上有规则的背景说明，对于规则的选取有点帮助。
• Yearning：规则集合偏 DDL 更多点，DML 类的较少，没有覆盖到我们内部的一些规范，比较尴尬的是，规则这边是闭源的，我们后续如果二开比较被动。
• Archery：内置支持了较多数据源类型，通过查看 goInception 文档，MySQL 部分支持的规则较多，但是在 Archery 界面上审核规则无法查看，也不能配置需要开启哪些规则，目前看不太符合我们公司需求。

体验排名

SQLE > Archery > Yearning

3、SQL 工单上线

功能对比

体验对比

目前对于 SQL 上线流程来说，三家基本功能都是具备的，都符合我们公司的需求。比较有差异的部分是，SQLE 支持 DML 事务执行，对工单内数据一致性会有帮助；Yearning 和 Archery 支持上线前备份。

• SQLE：流程配置方式最简单，基本在项目界面下就能看到。
• Yearning：流程配置方式也较简单，特点要求 DML 和 DDL 分开提交，如果你们公司有这方面的规范那么这个是个不错的功能；工单提交有个比较反人类的操作，大部分操作都是按钮的形式，但是 SQL 审核没有按钮，在右键菜单里，由于试用时不太清楚搞了很久，最终在社区群里询问才解决。还有个问题是定时上线时间无法改期。
• Archery：流程配置比较麻烦，一度没有找到功能在哪里，配置过程反复在Archery UI 和 Django 管理界面横跳，没有统一的操作体验。

功能排名

（SQLE  = Yearning）> Archery

4、产品支持

功能对比

体验对比

目前来看三款产品都是还在活跃有提交的项目，其中 SQLE 提交非常活跃，看 Release 信息基本每个月都会发布新版本。对于小公司来说其实区别没太大，基本目前使用上的问题各家文档上都能找到答案。

排名对比

SQLE  > Yearning > Archery

总结

目前我们公司正在试用 SQLE，已经接管了大概 5 套环境，还在进一步体验中。

本次只对几款开源 SQL 审核产品的 SQL 审核上线能力进行了试用，当然各家都还有很多有意思的功能，我暂时没有体验，大家可以根据自身情况进行选型。

参考资料