云时代数据库DevOps：硅谷调研（下）- Code is everything ，技术架构与企业文化和组织架构一致

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

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

五、新兴公司：大约5～7年的后疫情时代的初创企业

这类公司比较小，生命力有限（95%在五年内消失）。虽然创始人和团队可能拥有多年经验，但还是摆脱不了早期的粗旷发展模式。本期封面中列举的币圈的coinbase和送餐的 DOORDASH，其实不够准确，毕竟这类公司多还不为大家熟悉。

5.1 公司特点

这个是一个经过几次自我转型，已经成活了五年的初创公司。其业务在全球的9个regions有部署。最早是做VR视频直播，后引入cyber currency混币圈，最近一次转型是提供Web3 Blockchain Infra。本次调研关注其早期开发的情况，当时团队只有大约10个人。团队很小，分工模糊，职责界线松散。

5.2 数据库和业务特点

业务架构简单，事务数据库采用AWS上的Managed PostgreSQL，用来存储用户信息包括重要的币值/余额。用户在系统中的操作，属于海量低价值数据，通过BigQuery来批量分析。业务开发主要用Java和JavaScript。

• • 数据库：Managed PG @ AWS。业务对ACID是强需求，而且数据敏感，包括上千万的用户信息和数字货币digital currency（介于QQ币和bitcoin之间）。数据库的安全依靠AWS上自带的PG的Backup和高可用部署。

• • 数据仓库：BigQuery @ GCP。对应用户的operational信息， 即支持注册用户也包括Guest的操作。日常情况下有上万的用户同时在线，每天大约会产生两千万到一亿的日志信息，大约几TB的数据。这些数据通过BigQuery做自循环ETL，加工分析后的高价值用户信息在存回BigQuery。

5.3 日常操作和工具使用

ETL是常规操作，主要是两类。第一类是从TP（PG） -> AP（BigQuery)的单向服务。对实时性要求不高，一般保持小时级到一天，加上PG上是高价值的用户基本数据，更新量很小。该公司开发人员自己写脚本完成，并且对于跨云造成的延迟完全不担心。第二类是Bigquery 内部数据的清洗过滤和提取。每周搞一次，从BQ提取出来，用脚本/code在一个高端云计算资源（比如EC2: 64core， 512GB memory, cost: $100/day）处理，正常情况下：4～5小时完成，立刻释放EC2资源。笔者在调研的时候，提出异议：上述两种方式都不是最有效最合理的架构。对方也承认。但是既然可以正常完成工作，成本也不过是每个月几百刀，为什么去优化吗？

关于程序员是否使用专门的SQL IDE开发工具或SQL client。回答是非常清楚的：NO. 因为现在的通用编辑器基本满足SQL语法正确的要求。开发过程中采用API是Java DAO Layer，也包括prepareStmt 类 SQL String， https://dzone.com/articles/building-simple-data-access-layer-using-jdbc）。关于Database SQL client：被调研者是直接ssh用数据库自身的client，因为他是非常资深的开发和系统专家。虽然非数据库内核专家，知识和经验足够完成大项目的设计师。

他的日常就是bash cmd: ssh + vi 可以在所有环境使用，对他来说不是技术和能力门槛。不过，对方抱着开放的态度，不排斥GUI SQL Client工具（虽然他自己用的不多）, 比如MongoDB 附带的的 GUI帮助展示JSON效果，评价PGAdmin也不错 ，并且在AP端需要利用GCP平台上的BigQuery + Looker集合，通过Looker可视化直观的看到业务数据的曲线和分布。

内部职责管理是2～3个 SuperUser分担DevOps/DBA。在公司初期，也兼顾负责数据库设计：Create/Alter 之类，正式运转后，改动都很小了，维护的量不大。内部有比较松散的dev/staging/production deployment流程和测试，借助Confluence完成。虽然superusers有权限，但很少直接connect 到生产环境，他的记忆中只有一次ssh进去拉起系统。

5.4 观察 ｜ 思考 ｜ 结论

关于权限 ，应用开发有自己的ID，根据ID做权限控制。DevOps(其实就是资深founders) 有最高级权限。关于国内常常提到的“删库跑路”，他完全不担心有意为之的情形，关心的重点是如何避免低质量SQL和针对误操作的保护。因为本身是初创公司，只有一些初级的规则。非常认可在团队增长后，需要用工具检测避免。

总之，对方是初创公司的老炮儿。系统的各个方面都有经验，虽然不是数据库的专项专家，其系统架构的经验和动手能力完全可以掌控全局。在同意数据库架构和开发流程方面均有优化空间，且认可的优化方式的同时，不认为是高优先级的task。

六、写在最后

业界在Database DevOps的努力已经有十多年的历史。海外比如Liqubase和Flyway，阿里云上的DMS， 国内初创企业有ByteBase和NineData。这些商业公司的共同目标客户是达到一定规模的互联网公司，也就是我们上面讨论的第二类（传统互联网公司）和第三类（成熟互联网公司），同时期望能够啃下第一类大金主。而第四类归为今天的“用户”，潜在的未来的“客户”。

理念上是将业界已经认可的DevOps, 推进入数据库。希望达到 Agile的小步快跑，通过version control 版本维护 保护Stateful 的Database，同时提高Collaboration 协作开发效率和多数据库实例维护的稳定性和一致性。注重自动验证和测试，QA shift left(问题早期发现）和数据库开发过程自动化，保证和提高数据库开发质量。

实现过程中崇尚Everything is Code（SQL, Yaml, XML, JSON，脚本 etc.）和Programable可编程性，以达到可执行、可分享、可积累、可品控。又因为这个工具的主观性特点，要努力讨好开发者。使开发流程可迁移，尊重用户（开发者）偏好，提供本地 Unit Test的方案。要求对应可观察性的： 可查询性和Debugable。

DevOps 成功取代 DBA的标志是build once, deploy often。当然，这个工作还有一些关键的甚至是矛盾的设计问题需要解决：

• • ROI of Automation 自动化的回报。一个高质量的自动化框架意味高额的开发成本，尤其在引入:数据库Code代码验证与反馈后，框架的复杂度显著提高。

• • App Dev vs. DBA: 天生的矛盾。我们在调研过程中也专注了大企业内部团队的职权范围。软件系统架构需要与组织架构的配合。

• • 陷阱：Don't be just another SQL Client。用户在接受数据库DevOps之前，肯定已经有了自己的IDE工具和主观习惯的开发环境，如何“讨好”开发者，而不是强迫他们适应新的环境？

• • 减少对人类的依赖。切记在流程复杂化，添加更多层的人工review和approval手续，只会适得其反。

讨论了很多技术实现的细节后，发现企业文化和组织架构才是关键。数据库DevOps，相应的流程及工具必须与客户已经形成的企业（管理） 文化一致，与组织架构配套。没有任何一个客户会“削足適履”配合工具。

最后一句，海外的工具类DevOps产品是建立在用户和客户高度重叠的基础上：开发程序员既是用户，也是有决策权的客户，所以工具第一要满足程序员的习惯和要求，“讨好”工程师。

---

来杭州多次，更喜欢西溪湿地：

相关阅读：