走向DevOps：云时代数据库使用 - 硅谷调研总结 （中）

作为一个数据库内核老兵，一直欠缺从应用开发和DBA/DevOps的视角，尤其是经过云时代的革命之后，在现实世界中如何使用数据库的经验？好奇心驱动笔者在过去两个月，拜访了一些在硅谷的高科技公司，今天将这个第一手的不全面的小结分享给大家。我把这些公司大概分成了如下四类: 一、老爷爷老奶奶; 二、 传统互联网; 三、 成熟互联网; 四、 初创公司

三、传统互联网公司：闯过99/2000年的第一波互联网公司

他们曾经的互联网时代的弄潮儿，dotcom泡沫的幸存者。

3.1 被调研公司的特点

• • 业务：2C的订阅型流媒体服务。

• • 用户数：6000～8000万 （约10%为日常付费客户）

• • 员工：大约2000， 大部分为技术人员包括infra, admin, dev, Data scientist...

• • 典型成熟互联网企业 （2000年成立）

• • 数据库/仓库：MySQL/PG/SingleStore/Redis/BigQuery/Hadoop...

• • 其他：在从自己维护的IDC向公有云迁移，过程缓慢

3.2 数据库使用特点

他们比较认可Database CI/CD 工具的作用，早期使用Liquibase，后来因为Java Spring的功能支持，切换到Flyway。

其应用开发团队（那些写java code的研发们）对数据库的使用负责，责任, 包括 Database Schema 设计和SQL开发。DDL (Create/Alter/Drop, etc.)通过Flyway 的change log/SQL脚本管理，DML (I/U/D/Query)在Java 应用中直接嵌入。依赖类似GIT repo统一版本管理，包括database change 和 app change，用简单 check style (https://github.com/checkstyle/checkstyle)保证所有Code(Java和SQL)的统一和标准化。

对应的DBA是一个很小的团队，主要负责infra, 资源分配，replication, backup的布丁，不负责数据库健康和SQL检查。

对于我们常常担心的Bad SQL，是完全应用开发团队负责的。手段是人工review。这点我很诧异，对方回应是每次都是small （SQL）code change, 不认为需要工具辅助。他们只是设立了最简单的规则，即应用（Java code）中不允许有DDL。规则简单直接，比较容易遵守执行。测试流程比较严谨，采用Junit。

安全和权限的管理方面，整个开发团队共享database userid，少数资深开发TL拥有 super userID （注意：还是开发负责）。在生产环境debug是采取严肃的service request 方式。同时因为完全是内部业务，所以对于开发人员没有数据脱敏的要求，这方面的权限管理也就省略了。

我特别关注他们在SQL 开发IDE/SQL Client的实际使用。发现团队对于IDE没有统一标准和限制，凭个人喜好，比如Java 用intellij idea就比较多。SQL 编辑/client方面也是每个开发员工自己决定，成熟有经验程序员用偏爱的Java IDE编辑器和数据库自带的client cmd line，年轻程序员有使用的dbvisualizer的。GUI的数据库管理工具只有在管理多个数据库时有意义。而每个应用开发团队只对自己的业务负责，对应1～3个数据库实例，就没有必要使用了。同时在允许开发人员自主选择工具的情况下，强调自动化和版本化， 强化用很少的规则，比如不允许Java应用中出现DDL，不使用复杂逻辑，如Stored Proc和Trigger。

另外，该公司还有独立的Data Scientist/数据科学家团队，对于辅助工具比较依赖，使用Zeppelin, dbvisualizer和内部开发Python包。对应的大多是数据分析，包括与hadoop交互，BigTable, BigQuery, etc。他们完全没有数据库(MySQL, SingleStore)的权限，不会影响数据库的稳定态。

3.3 观察 ｜ 思考 ｜ 结论

最关键的就是组织架构和责权分工。数据库的设计和管理权都是归属于应用开发团队的。

作为一个已经有1/4世纪历史的传统互联网团队，他们的技术栈主要在“开源”，“免费”的工具上， 加上少数付费产品（github，Jira和附带bitbucket）。团队还保持着Two-pizza teams形式(6~10人) ，所以比较容易遵循团队规则的约定俗成：借助flyway管理，针对DDL vs DML的控制，禁止Stored Proc and trigger等。Code Style是用工具维护的，SQL的质量靠人工， 以规范测试流程来保证。

以Team leader为Super User的基础上，尊重团队成员的个人偏好 (SQL Client, IDE, GUI选择)

四、 成熟互联网公司：2008次贷危机的胜出者

Facebook(2004)，Twitter/X(2006), netflix(2007)都属于本类型。这些公司或者已经在公有云上，或者有成熟的自建云IDC。

4.1 公司的特点

• • 成熟互联网公司

• • 调研覆盖了两家公司，其业务：一个是社交媒体，一个是旅游短租

• • 技术体系为公司核心竞争力之一

• • 数据中心：一家建立在（类似）AWS EC2上（数据库是自建自管的self-managed instances）；另一个是自建IDC

• • 数据库以MySQL/其他开源/Hadoop体系，完全self-managed

• • Java和Python是主要开发语言

4.2 组织架构

团队组织架构体系，由三大块组成，并且已经没有传统意义的DBA团队：

• • i. 应用开发 Application developer；

• • ii. 数据服务团队 Data Access Service Team(DA) ；

• • iii. DevOps 团队 。

应用开发 Application developer，负责开发业务， 比如java developer。该团队对数据库不感知，数据操作借助GraphQL 提出request: data model/Query request/Data operation；Java code里不会（直接）出现SQL语句，开发也不需要自己写任何SQL语句。编程过程中不需要知道数据在哪个表里，或甚至不需要了解后台使用哪个数据库（MySQL/PG/Hive/BigQuery)。这样，developer即使不具备数据库和SQL的专业知识，也不影响工作，降低了用人门槛和人力成本。

DevOps是一个很小的团队，处理系统性操作（比如备份，复制，重启，升级等），类似于传统互联网公司的DBA团队。大概”DBA“已经是古老的名词，不似DevOps代表先进生产力了，笔者发现被调研者不大用DBA来描述职责。该团队有SQL使用的权限，但实际操作中使用率很小，而且不对Create/Update/Insert/Query负责。

从数据库开发角度，数据服务团队 Data Access Service Team (DA) 便是核心关键了。他们是从传统的“开发+DBA”系统，向“开发 + Data Service + DevOps”体系演进过程中，新兴的中间团队。该团队是真正拥有数据库/仓库等知识的，负责开发借助GraphQL，从数据模型到SQL的转换的逻辑。SQL DDL 和DML均是该逻辑生成的。

DA团队的出现，将“围堵”坏和慢SQL的任务，变成疏导型“正向”控制SQL语言的规则：Positve Enforcement。DA团队向上对app developer负责API接口，向下对数据库负责SQL生成。将规则融入生产SQL的逻辑里， 彻底解决了“SQL review”的效率和有效性问题。

4.3 数据库开发特点

本节主要从上面提到的DA团队的视角展开。

核心关键通过正向疏导的方法“Positive Enforcement”SQL 语法规则， 这个理论并不新鲜，然而真正实现和用好的不多，必须拥有自动化能力，强制code-gen，关注整个lifecycle。下面举几个例子：

• • 不生成Delete From table Where...，而是转换成根据主键的多并发分两步走 Select + Delete （ATTN：留个问题，为什么采用这么“笨”的方法？）

• • 不生成Select From T Where ...， 而是转换成基于cursor control的 Select column limit 100/one page

• • 不支持Create Stored Proc

• • 不支持Create Trigger

• • 高度限制Create Index

• • 保留简单直接的constraints (由Data Access Service Team的data model负责生成)

上述过程需要有经验的DA团队，而且是一个长期演进的过程。实操开发过程中，API 演进是从Hibernate，到REST一步步走来，现在选择GraphQL。采用了一个内部的类JSON/YAML的Interface API接口，才做到了稳定可靠的Code-generated SQL。这些是通过几年的开发努力才成熟的过程。

在这个框架下，系统只会生产有限的已经被审核批准的SQL，避免复杂SQL和逻辑 (trigger, stored proc, index)，通过减少复杂度保证生产的SQL的质量， 是正向管理。而不是先由开发者随意写SQL，再依靠有经验的、负责任的、有时间的TL从众多SQL中排除"bad SQL"，这是一个不可完成的使命。

具体开发/测试流程是这样的：

• • App developer非常敏捷，每天发布4次， 采用灰度梯度：1% --> 10% --> 100%；

• • DA team/Backend: 每周发布一次；

• • 测试是完全全自动化的，通过典型三级完成：dev开发 --> staging --> production 生产。

这里特别提两点：Staging的数据是从生产上去敏后得到，而去敏逻辑的开发也是由DA team 负责；另外因为不需要DA团队去review/approve 开发团队的SQL，才能实现开发团队的每天四次发布的小步快跑。

4.4 其他日常

Debug是重要的一环。开发过程中依赖程序员的Unit Test。一旦进入staging和production生产环境，就统一通过log日志分析完成。日志log存储在某个TimeSeries DB里，比如Cassadra。借助DataDog监控，管理和分析。

作为成熟的公司，所有团队都几乎不用任何SQL Client直接连接Staging或生产环境。首先，应用开发团队没有权限，也没有需要连接（参考上面的分析）；DA team和DevOps有权限，但非常罕见，特例常常是需要拉起或HA切换，不允许在线上连接数据库debug。

权限管理方面，应用开发团队根据业务共享ID, 比如负责管理客户账户的userTeam，负责管理广告的AdsTeam, 区分权限。这个权限是统一管理的，不限于数据库。

没有对于数据Mask方面的需求。因为不需要也不允许在生产环境运行SQL查询，而Test/Staging环境的数据是经过DA团队去敏的。

4.5 观察 ｜ 思考 ｜ 结论

总结一下组织分工：

• • DevOp 团队负责整个系统，包括数据库，但是不参与数据库schema设计，也不需要了解业务；

• • Data Access Team负责数据库的操作，负责开发SQL语言的生成和数据的交换(比如Query 结果转成Java data)；

• • Application Developer应用开发负责业务逻辑，对数据库技能要求比较低。通过DA团队的限制，隔离应用程序员对数据库稳定态的影响。

对于SQL和数据库使用的理念：简单就是最好。将应用开发与数据库完全脱离，应用程序员根本不需要知道是使用了什么数据库系统，解决了应用被数据库锁死的风险。业务产品的source code中没有SQL(用类YAML的形式描述数据模型），降低了对开发技术人员的技能要求，也就降低了人力成本。

”创新“的positive enforcement的，类似「大禹治水」用疏導法来保证SQL规则和质量。而这一切又归功于，新的组织架构中Data Access Service团队的出现。

敬请期待 第三篇： 《云时代数据库DevOps：硅谷调研（下）- Code is everything ，工具必须与组织架构一致》

"麦叔叔面馆"