数据库的变更管理一直是产品迭代流程中的一块薄弱环节，伴随数据库类型和数据库实例的增多，集中式的数据库变更管理系统正逐步成为各企业刚需。【墨天轮数据库沙龙-数据库SQL工具专场】邀请到 Bytebase 商业化负责人王长煜，为大家带来《Bytebase——开发者友好的变更管理平台》主题分享，以下为演讲实录。
在数据领域拥有 15 年的工作经验，全面负责产品的商业推广、技术布道、解决方案相关工作。在加入 Bytebase 之前，曾任职于甲骨文、TalkingData、观远数据等公司。
Bytebase 是一款聚焦在团队协作场景下的数据库结构变更和版本管理的开源工具，主要解决研发工程师和 DBA（数据库管理员）在变更数据库结构时的协同问题。
创始人陈天舟曾在 Google 硅谷总部云数据库团队担任技术负责人，也是 Google 内部 PostgreSQL 和 MySQL 分支的主要维护者。联合创始人徐丹青曾任 Google 总部主任工程师，两次获得谷歌最高工程奖，参与并带领谷歌云的数据库和云服务基础设施的设计和研发。2021年，他俩共同创立 Bytebase 公司，确立产品开源路线，2022年正式启动了商业化工作，发布商业版，并保持两周一次的高速迭代版本的频次。
02 Bytebase 产品价值
Bytebase 产品的核心价值在于数据库的变更管理，包括访问控制等相关的能力。Bytebase 对开发者更加友好，能够提升开发者的研发效能和研发效率。
01 数据库变更过程中的挑战
面对业务需求快速变化，难免会遇到各种各样的问题，常见的例子有：
1.多个团队一起去对数据库发起变更，需要解决一些冲突的问题，例如对多个SQL脚本的执行顺序进行梳理编排。
2.ISV（Independent Software Vendors ，意为“独立软件开发商”）的用户是私有化的环境，可能对本地数据库做了额外的变更，当新版应用发布的时候，就可能出现脚本冲突，或者对象冲突等，导致脚本的发布失败。
3.再如我们的应用有多个版本，不同的版本服务于不同的用户，那就需要我们维持对应的 Schema 版本也可能要有多套，而 Schema 可能又是由一堆脚本去组成，需要去维护这些脚本的执行顺序，甚至可能高级版本发现了个 bug，还要把这个对应的脚本再 Cherry pick 回低版本，这会导致我们的整个 Schema 的版本管理变得非常的困难。
4.还有，我们可能因为各种各样的原因，导致库里面一些对象（表、索引），不知道什么原因建的，在生产库不敢轻易删除，难以维护。
02 生产力工具 Bytebase
日常研发过程中，我们需要各种生产力工具来提升效率，比如代码变更管理使用 GitLab，基础设施变更管理使用 Terraform。那面对数据库变更管理，我们可以用 Bytebase 来解决。
Bytebase 不仅仅是只面向DBA，它是一个面向研发组织设计的，面向DBA跟我们的开发团队去协作的DevOps 平台。正因为如此，Bytebase 非常注重和研发流程的整合，包括上游的代码仓库，下游的一些研发管理流程的平台等等，都做到了原生的集成。
Bytebase 提供了一整套完整的企业级的变更协同工作流，包括基于Web端的查询访问控制，一系列自动化的变更审核能力，多种灵活应对各种研发产品的发布能力，变更失败以后，可以快速回滚的能力，以及对变更Schema的版本管理和变更历史记录。
Bytebase 提供了一套完整的解决方案，目前基本上对主流的数据库都实现了支持，包括下图未列出的Redshift, MariaDB, SQL Server 也都实现了支持。
03 开发者友好的变更管理工具
对开发者友好的变更管理平台，是好用的，易用的，能够提升开发效率的，而非简单的提供一个管控平台，从而大幅度牺牲了效率。当前业务面临非常激烈的竞争，如果发布流程不够敏捷，或者说因为管控影响了我们业务研发效率，可能带来的损失也是非常大的。所以我们希望既能够保证我们的安全管控，又能够进一步提升研发的效率，这是 Bytebase 想要做到的。
那如何才能打造一个开发者友好的变更管理工具呢？Bytebase给出了解决方案。
1.基于 Web 端， Bytebase 按照DBA和研发者的一个协同作为核心去设计的，而不是简单的管控。
2.Bytebase 需要跟一些开发者常用的一些自动化部署工具去集成，比如说代码仓库GitLab GitHub，还有比如说 Terraform 等等。
3.针对研发在真实生产环境中，各种各样的场景去设计更加灵活和强大的发布方案。
4.以风险视角为中心的全局的管控操作流程。它的优点在于可以帮助我们按照风险去定义不同的安全策略，避免用一套策略应对所有的场景，导致研发效率的大幅度下降。
04 基于项目的管理体系设计
Bytebase 会把所有的库和相应的人员按照不同的项目进行划分，这个项目可能是一个产品线，一个部门，一个研发组织等等。在项目内部，研发团队可以自助在此发起一系列的变更，而我们的DBA、SRE团队在全局进行一个策略的制定和管控，然后这些策略就通过我们的产品落地。只要你不违反我的策略，那么在项目内部，所有的变更审批管理流程，可以由您的研发团队自助式的完成，而我们的DBA，它更多是作为管理者以及兜底的角色。由此，DBA可以释放出大量的时间，去做一些更高价值的工作，比如说 Schema 设计工作，好的schema设计方案，可以将很多运维问题提前解决掉。
以项目为管理边界，去进行自助化的管理，这是实现 DevOps 的一个前提。
05 基于安全协同理念设计的SQL查询客户端
Bytebase 会把所有的 SQL 访问收口，以提供更安全的SQL开发能力。在客户端中实现数据库的查询访问控制与数据脱敏。
06 GitOps 实践方案
这是我们最常用到的变更模式，由一个个变更脚本组成，按顺序执行。这种方案最大的好处就是，非常清楚的知道这次变更做了什么，过程透明可控。并且因为它是基于 SQL 的，所有的数据库都能够支持。缺点也很明显，就是可能需要维护大量的脚本的执行顺序，还要解决冲突问题，假设是多个团队甚至有跨国团队，如果说 Schema 有多个版本，应用上对应好几个版本，这时候要去维护这么多脚本的执行情况，甚至会出现顺序出错或者遗漏的情况，进而严重影响了整个发布效率。
这是 Bytebase 提供了一种新型的变更模式。您不再需要写变更脚本，只需要去编辑存在代码仓库里面的唯一一份 schema 文件，改成什么样子，那么目标库由 Bytebase 把它变成对应的样子。所以这种模式，它的优点就是不再需要写 SQL，不需要管理执行顺序，而是声明式的，当然也有些局限性，比如说不能支持 DML，不能支持 RENAME。另外需要有对应的数据库引擎能够支持，目前 Bytebase 优先实现了针对 MySQL 的这种模式的变更，后续我们支持PostgreSQL。
这种基于终态的模式，特别适合跟 GitOps 集成，只需要单一事实来源文件（SSOT）在代码仓库里面，利用代码仓库的能力，就能保证这个文件的一致性和唯一性，那么我的库就不会出现偏差或者脱离管控的对象等等情况。
在Google内部，所有的变更针对数据库的变更，全部是用利用这种模式来做的。
Bytebase 也提供了非常强大的 SQL 的审核能力，目前优先支持了 MySQL、PG、TiDB、Oracle 以及 Oceanbase。并提供了多种的审核方案，包括在UI对工单审核，可以调接口来审核。最特殊的，Bytebase 审核能力也跟代码仓库做了集成，可以在代码仓库里面实行审核，比如说在 GitLab 或者 GitHub 里面提交一个PR或者MR，那么只要这里面包含SQL脚本，或者说是大家常用的 MyBatis 里的 XML 文件，都能帮你识别到，然后就在代码仓库里面够触发对应的审核，只有通过审核了，才能够合并到指定的分支。
这种模式的优点有二：第一特别符合开发团队的工作习惯，我们知道开发团队他不想拿着一个 SQL 粘贴到多个工具，是非常繁琐的事情。第二这种模式把整个审核流程左移了，在CI阶段就触发了审核流程，而这个审核规范，是在我们的UI里面配置的，及时生效保证两边用同一套规范，比如说在上线的很早之前就能够触发审核，而不是需要到发布的那一刻再来审核了，增加了容错的时间。这是我们把审核能力融入代码仓库里面的一个非常关键的一个作用。
2）批量发布
这种一般针对SaaS公司，有大量的多租户库，分库分表，像一些工厂管理系统，还有一些 ISV，可能有多个用户的环境要部署等等。这种批量发布的库其实都是同构的，使用这种发布模式能够方便的进行发布。
3）分阶段发布
就流水性的发布模式，可以应对于多种情况，比如说可以从开发、测试、预上线、生产流水发布，您只要一个 SQL 工单，他可以逐阶段发布下去，避免了开发阶段提交的变更，可能经过测试通过了，但是往生产发的时候漏发、错发等等情况，我们通过分阶段发布去解决。再比如说，我们可能有多租户的大量的业务，这时候可能先挑一部分去做一些灰度上线，先把应用在几个客户上面先发布，没有问题了我再发布到剩余的客户去，可以把一次发布分成多个阶段来做，也是没有问题的。
4）跨环境发布
一般来说，应对于这种物理隔离的一个场景，或者说要把变更发布到用户的私有化环境中去，这时候把脚本导出来，再到那边去发布，所以我们提供了多种多样的发布能力。
5） 风险驱动的数据库变更管理流程
Bytebase 会把所有的数据库操作，按照不同的规则去定义风险等级。举个例子，当生产环境影响的行数超过1万行，操作类型是 update 或者 delete 的时候，Bytebase 认为它是一个高风险的操作。定义了高风险的操作，Bytebase会标记它的风险等级，然后根据风险等级去关联你的自定义的审批流程，然后再基于这个审批流程，触发对应的审批流与发布流程。
通过这种模式把我们所有的数据库操作去定义不同的风险，来灵活的关联不同的审批流，那么比如说研发的一些测试环境或者是预上线环境，风险等级就可以低一些，用一些比较简单的审批流；如果说是一些比较高危的操作，可以指定一个非常复杂的审批流，或者说要有一些DBA参与。再有，一些开发环境就跳过审批，自动化执行就可以了。通过这种方式就可以把我们所有的变更，进行非常灵活的管控，让整个研发的效率进一步的提升。
Bytebase 所有的变更都会跟 IM 集成，随时把控进度。目前 Bytebase 集成了主流的IM，针对自定义的也能够集成，我们可以收到所有的变更状态改变的通知。针对飞书，还实现了基于飞书端的移动端审批，如果说这个工单没有任何报错，可以直接进行审批；如果有报错，建议登到控制台做一个仔细的检查。
08 基于时间点的恢复+闪回
如果变更失败了， Bytebase 有一系列的手段去解决，目前我们这边内置了一种基于时间点的快速恢复，针对 MySQL 可以做好备份，一旦出了问题可以按照库级别实现一个时间点的恢复。另外我们还可以针对 DML 的语句级别实现一个快速闪回。包括 MySQL 和 Oracle 都支持这种模式，比如说写了一条 delete 语句，一不小心多删了很多行，那么 Bytebase 可以一键生成对应的 UNDO SQL，自动生成对应的工单，审批一下如果没有问题，就可以快速找回数据，这是 Bytebase 提供的一个变更失败的兜底保障。当然，Bytebase 内部还集成了很多这样的高级能力，比如针对 MySQL 的大表变更，提供了基于 gh-ost 的 Online DDL 能力等等，这些都帮助我们更好、更高效的完成整个变更流程。
最终变更完成以后 Bytebase 会把所有的变更记录全部记下来，包括您变更的历史，以及每一次变更前变更后完整的结构快照以及它的差异。这样的好处，一来可以快速的追溯和审计，二来可以在每一次变更版本中，直接找到当时的 Schema。比如说要还原某个版本，要做一些测试，那么不再需要去跑一堆脚本了，可以直接找到当时那个工单做完以后 Schema 快照，整个库的 Schema 就在这里了，通过这种方式我们可以管理一系列的变更版本。
图16 变更记录可追溯审计
01 场景示例：一个完整的 Database CI/CD的流程
以前我们 CI/CD 只能做到应用代码的 CI/CD，后来有些工具比如 Flyway、Liquibase ，它的做法是把数据库脚本直接打到应用镜里面一起跑，但是对我们DBA来说，一旦数据库很大，那么这个变更流程就可能出错，一旦出错，整个应用的发布就挂在那里，必须重新修改脚本，又要重新打包整个应用镜像，所以一旦数据库大一些，就不能采用那种模式了。需要将应用发布和数据库发布解耦，解耦出来的结果就是，应用自动化发布，数据库手动发布，整个过程是割裂的。如果沟通不畅，可能应用发出去，数据库变更还没有跑完，应用就各种报错了。
那 Bytebase 是怎么实现的呢，首先我们可以在代码仓库里面同时提交应用的代码和数据库的脚本，然后自动触发数据库在代码仓库内的审核，team leadr 确认没有问题后，才允许合并到指定分支，此时，应用代码就会触发应用的 CI/CD 的流程，先做build再做test，然后会有个节点，这个节点就是会读取我们这次变更的版本号，然后通过 API 去 Bytebase 的控制台 查询这个任务的状态，同时，数据库的变更脚本就会在 Bytebase 生成内部的执行工单，应用就会在等待不断查询它的状态，这时需要跑 Bytebase 数据库的审核和变更流程，如果有问题，我们在数据库这边去对应的做一些处理，直到把问题解决；如果没问题就会自动发布，一旦发布完成，应用的 CI/CD 流程的 pipeline 里面就会接收到这个信息，就可以触发应用下游的发布，全流程可以打通串联起来。同时 Bytebase 会把我们这次变更完成以后完整的 schema 再回写会代码仓库。
上述就是一个典型的 Bytebase 的 CI/CD 流程。
02 场景示例：多租户数据库的变更管理流程
关于这个示例，Bytebase 有个金融行业的 SaaS 用户，已经在生产环境中使用。当他们在业务方发起新业务，或者说新进客户的时候，会由业务同学去新建个租户，这个租户包括应用侧、业务侧，并且后台会自动创建新的数据库。这个新的数据库，会调用 Bytebase 的接口，自动创建这个库并且自动化纳管，由 Bytebase 把它的结构同步到最新，用户的账号和密码由 Vault 管理，应用代码去 Vault 获取账号密码，再把初始化数据写入进去。如此，SRE、应用开发人员可以基于 Bytebase 去管理整个变更流程。
目前 Bytebase 正处于高速发展阶段，在这个领域中，是全球唯一同时入选 CNCF 以及平台工程组织(platformengineering.org)推荐目录的产品。同时Bytebase 面向全球化运营，在海外有大量的用户，Bytebase支持英语、中文以及西班牙语。Bytebase 入选了2022年球开源初创企业增速 TOP 50。以上就是我今天分享的全部内容，谢谢大家！
图 19 Bytebase 功能架构栈
