隐藏复杂、抽象概念，「技术无感化」 ——The Future of Database2022 | 黄东旭新番

12 月 1 日，以"去发现，去挑战"为主题的 PingCAP DevCon 2022 主论坛上，PingCAP 联合创始人兼 CTO 黄东旭，在大会上分享了“The Future of Database”的主题演讲。

2022 年底的预测，黄东旭给出的关键词是：Frictionless Developer Experience，“技术无感化”。

“过去我们其实一直在把数据库与开发者分开来看。数据库关注性能、稳定性，各种各样特别硬核的跑分，但是未来将是从开发者的角度考虑如何去使用数据库，让这个数据库帮助开发者更快、更流畅地构建应用。”他在接受媒体采访时表达。

得出这一预测的前提是：过去一年中，TiDB 的发版节奏和模型发生了变化。这也是基于去年的判断——云的意义在于加速软件的迭代速度，大半年时间 TiDB Cloud 已经进行了超过 34 次迭代，增加了上百个功能特性和改进。这个迭代速度比 TiDB 内核本身的迭代速度更快。

以下是为你梳理了黄东旭分享中的要点，以及在随后媒体群访中的观点：

1、广义上的开发者包括架构师、开发者、DBA，但数据库软件的真正用户是应用开发者。

2、2023 年，云上数据库可能会超过传统数据库，未来数据库产品中，云一定会变成数据库服务的承载平台。

3、基础设施维护（买服务器、部署服务器、运维）时间仍然占据一个程序员新开发应用过程中 40%以上的时间。真正开发应用的时间只有 10%～20%。以及数据架构组件之间的连接非常复杂，需要更多时间保证系统稳定运行。

如果用传统的思路去构建系统，你就会发现要用一大堆不同的技术栈串联在一起才能实现，并且每一个技术栈还有着自身复杂的运维成本。过去 20 年我们发明了太多的技术，太多不同的 Database，每一种 Database 都有着自己复杂的概念与运维。作为一个开发者，要想把它用好，就需要把这些东西都学习一遍。复杂的概念现在都没有被隐藏起来，反而全都透传给了开发者。公有云厂商会有好多机型推荐给你，如 i3.xlarge、i3.2xlarge、i3.4xlarge 等，这些机型代号背后到底意味着什么？这都是系统架构的复杂性。如果你在云上选错了机型或者选错了服务，就会发现最后的账单和你选了正确的机型或者服务有着天壤之别。

Vercel，是一个非常偏向于开发者开发流程和体验的平台，在它的首页有三个英文单词：Develop（开发）、Preview（预览）和 Ship（上线），这其实就是一个开发者的视角。用过的同学就会知道，在 Vercel 这个平台上，一个应用开发者只需要关注网站怎么做，只需要去写 code。其他的事情，包括发布、部署、CDN、流量全都由 Vercel 帮忙封装好了，开发者只需要将 100% 的时间都放在业务逻辑开发上就可以了。这是一个很好的方向，这意味着应用的开发门槛在降低。未来，应用开发者对数据库的关注点会从数据库变成 API，甚至在更长远的的未来只需要关注 web 前端开发

Abstraction（抽象）程度提高，架构的复杂性会变得越来越低。云不再让开发者考虑硬件、网络、磁盘、存储、数据中心的租赁，开发者的心智负担降低。

4、计算能力的抽象方面，公有云的概念出现了，把刚才那些复杂的硬件、部署、网络等数据中心的复杂性抽象掉了。你拿到就是一台机器，它到底是不是真实的机器你不用关心。这时，你要再开发一个应用，只需要在公有云上开个账号，把应用部署上去，按月给钱就行了。这比起自己去折腾数据中心来说，迭代速度又快了一步。

5、再往上看，云原生的概念出现了。云原生的核心计算单元是 Container，Container 是更高层次的抽象。在虚拟机时代，你依然要去考虑 VM 挂了怎么办，但是在 Container 世界里，Container 以及底下云的调度器都不用你管，意味着迭代速度更快。

6、过去一年中，PingCAP 一直在把这个数据库技术变成一个数据库的云服务，也就是我们在做的 TiDB Cloud。技术和服务的区别是什么呢？TiDB 技术本身就像一辆车里的发动机，或者一个火箭里的引擎。但是一个发动机跟一辆车肯定不一样，尤其在云上。对于一个在云上想要使用数据库服务的用户来说，他需要数据的导入、数据的导出、备份、智能诊断、多租户各种各样周边的东西，把它们拼装在一起才是一个服务，而不是给用户一个发动机让你自己拼出一辆车。

你想要提供服务，就要从用户使用服务的全生命周期去考虑。比如他刚进来注册的环节、绑定信用卡的环节、数据导入的环节、使用、调优、备份的环节，同步到其他数据源的环节，每一个环节都要去考虑，这里面考虑的点就是用户体验，用户体验是指引这个产品做得更好用的方向。

7、“抽象”再往前一步是什么？我们给出的答案是“Serverless”。对于数据库来说 Serverless HTAP 是一个更高级别的“抽象”，它意味着更高的开发效率。Serverless 跟云有什么区别？我觉得二者当然都是 Pay-as-you-go，但是能不能以一个更细的粒度去提供 Pay-as-you-go 的能力？过去我们其实还是按照服务器、虚拟机这样的资源来去看待一个月多少钱，这个服务能不能粒度更细一些，只收业务流量的钱？尤其是对于偏分析的场景来说，有很多时候我们做大数据分析，比如每天半夜要去跑个报表，可能需要一千个虚拟机算，20 秒钟算完，然后再缩回来。每天可能就凌晨需要这么多 OLAP 的服务器，但是我不可能白天也买这么多服务器，就为了晚上算那一下，能不能更细粒度的 Pay-as-you-go，只算 20 秒的钱非常重要。对于 Serverless 数据库来说，很重要的一个课题是从用户角度看，它应该融入到每天的、现代的开发体验中。

8、TiDB Serverless Tier， 11 月 1 号上线公测，我自己写了一个小程序，在一个全新的环境下，通过代码启动一个 TiDB 的 Serverless Tier 实例。在这个过程里，我只是告诉这个程序，要启动一个集群，这个集群叫什么名字，然后把密码一输，20 秒之后可以直接拿一个 MySQL 客户端连上去了，这个时间未来会进一步缩短。其中我们有一个原则，就是怎么利用好云提供的不同的服务，比如 SpotInstances、S3、EBS、弹性的 LoadBalancer。TiDB 的 ServerlessTier 背后对于云上所有的弹性资源都进行了很好的整合，以及巧妙的调度。当 TiDB Serverless Tier 上线以后，我们发现它一上线就把整个 TiDB 在云上的 cost 降低了。拿最小集群来说，现在对比今年年初，成本降低到 1/5。而且在可见的未来，这个成本会变得更低；第二就是启动的时间，在今年 3 月份的时候，在云上启动一个新的 TiDB 集群需要 15 分钟，如果自己部署时间可能更长。现在只要 20 秒钟，不远的未来这个时间会缩短到更短。

9、在这样的 Serverless 架构下，我们其实还能解锁更多的能力、更多的可能性。举个例子，S3 是 TiDB Serverless Tier 底下重度依赖的云对象存储服务。用过 S3 的肯定都知道它便宜，可用性很高。更重要的一点是数据共享，比如大家都在用 AWS，A 用户用 S3，B 用户部分数据也在 S3 上，比如说我想把我的数据共享给另外一个用户的时候，既然都在 S3 上，那共享就变得很简单。以前在私有环境下，你还需要把数据下载出来拷给他，再上传进去，然后才能做分析。如果是在数据量比较大的情况下，这几乎是不可想象的。这种新架构的一种可能性就是真正能够做到 Data Sharing，当然这里面肯定还涉及到包括隐私计算，各种各样的安全性问题。但从技术底层来说，这种产品形态并非不可能了。

另一种场景，比如说我想做一个区块链的数据分析应用，但做这样的应用，第一步你得把数据准备好。区块链的数据其实也不小，经常是大几百 GB 或几个 TB 的数据。但如果在 S3 上有一个公共的数据集已经准备好了，那在云上 Serverless 用户只需要在启动的时候，加载这部分数据就好了。这些能力在云下是根本不可能完成的任务。

10、未来再往前一步，会发展成什么样子？

Serverless 其实是云上 Database Service 更进一步产品形态的体现。现在我可能还需要去关注买多少个数据库节点，买多少个集群，但是在未来，真正从开发者的角度来说，他所关心的应该只有数据操作的 API ，这一层才是离业务更近的东西。

同时，附上记者采访过程中的 QA 摘要：

Q：什么是“技术无感化”？

黄东旭：云原生的下一步是 Serverless，这背后的一个核心的逻辑在于阻碍数字化转型进一步深入的很重要的原因是开发效率，所以我们提出了一个概念，叫技术无感化。

技术无感化对于技术软件来说，核心的就是如何能够去通过更高层次的抽象，去把数据库本身这种软件的复杂性一步一步地降低，使得未来的开发者对具体的技术几乎都不需要感知，然后就能够去把这个东西用起来。

在用户体验上，越来越简单。

一方面不特别强调数据库的硬核性能、跑分，这些极端场景一般用不到。另一方面，云提供的基础能力可以让很多东西变成可能，云原生架构枷锁了更多能力（Data Sharing）。

Q：Serverless 如何改变 TiDB 的使用场景？

黄东旭：Serverless 它是一个产品的形态，但是它并不改变数据库本身的 feature。

第一，首先 TiDB 本身还是一个 HTAP 的 database。HTAP 意味着什么呢？

你是一个电商，你做个电商的网站，肯定要有库存、有订单、有支付是吧，就这些系统其实都是对在线交易要求很高，数据不能丢，数据不能错，7x24 小时不能停机。这种叫 OLTP 的 scale 的场景不会因为它是或者不是 Serverless 就有什么区别。

另外一种场景可能是 HTAP。假设我是这个电商公司的老板。我就想看今天到现在为止我这一天卖了多少钱。你知道就这么简单的一个需求，在过去你可能要搭无数的系统，才能完成这个东西，而且一旦你的这个老板想看的报表是实时的，这个报表实时有些什么变化，HTAP 场景其实就是说，你不需要推倒再来，你直接可以在一个系统继续做在线的支付交易，同时能够让你直接在上面去做实时的分析。电商只是个例子，其他各行各业吧，都有类似的这种场景，比如说像区块链的数据分析。

叠加在这两种场景之上，如果有了 Serverless， 你完全不用关心底下基础设施。双 11 的峰值来了，自动就帮你把他系统扩上去，让你支撑这个业务。然后双 11 过了，它自动就缩回来。它只收你双 11 那天的钱。

关于实时分析，比如说你一天就分析三秒钟，Serverless 不会改变本身数据库的应用场景，而是去改变数据库在价值交付里面的粒度。同时降低使用门槛。

Q：Serverless 的技术难点究竟是在哪里？

黄东旭：很多数据库在走向 Serverless 或者走向云原生这一步犯了第一个，或者说最致命的错误，云上的数据库不能够直接把云下的架构搬到云上，这是完全错的，这样你没有办法去利用云上面提供的一些很好的能力。

所以这里面第一个难点就是你怎么能够充分地去利用云给你提供的 service。比如说你在云上你不应该去自己做存储引擎。

核心的一个理念就是你多充分的去利用云给你提供的服务。

第二个难点就是在云下的时候，原来我们是一个数据库的提供商，我们只要关心技术，数据库软件做好了就好了，但现在云上第二个难点就是，我们既是数据库服务的开发者同时又是运营者。这两块的技术的要求其实很不一样的。你做出来不难，但是你怎么把它运营好？

第三个难点是云上的账单如何设计好。

归根结底我觉得核心的难挑战就在于你要基于云作为最底层的基础，假设去开发个全新的东西。你过去学习到的所有的云下去开发数据库的几乎所有经验技巧全都要扔掉，你在云上其实在做一个新的东西。

Q：关于私有云、公有云和 Serverless 的关系。

黄东旭：不管公有云还是私有云的环境下，Serverless 解决的是能够多细的粒度去利用硬件的基础设施的这个问题，如果你就只有三台机器，那什么云原生不原生就无所谓。但当你有 3000 台机器的时候，升至 300 台机器的时候。你会看到提升个 10%的利用率，对于企业来说都是很大的一个进步，这个跟公有云私有云无关。

Q：目前我们已经从 11 月份开始就公测了。现在我们的客户画像大概是一个什么样的？什么样的人会用我们？

黄东旭: 我觉得这个问题很有意思，我自己也在观察。我发现现在的这个 Serverless 的这种用户，他基本上都不是数据库的专家。都是我要在上面做个应用啊，我要快速搭一个电商，其实这才是我们真正觉得未来应该去使用 Serverless 数据库的用户，而不是那些企业的 DBA 或者企业的基础架构工程师。

Q：开源与对于数据库未来趋势预测之间的关系是什么？

黄东旭: 开源其实是用户选择你的一个基础。但再往前走，如果这个用户或者说未来的这个开发者，他就是土生土长长在云上的一个用户，那开源对于他的重要性，我觉得没有一些真正的大的企业对开源这么重要。其实开源这个价值对于不同的客户群体来，有些部分是不一样的，有些是一样的，比如说刚才说的简单易用、便宜，这个是一样的，我今天的预测是选择一些更普实的产品价值去讲。

Q：DBA 群体的发展趋势可能是怎样的？

黄东旭：DBA 可能短期还不会消失吧，但是从大的方向上来说，以后编程这件事情会变得越来越简单。就是我们这代人在学习的东西，或者说我们的同行在学的东西，可能在未来，全世界也就这些人知道了，就咱们这一小波人知道了。再过十年、再过 20 年，下一代的开发者，他可能看待编程的方式跟我们现在是完全不一样的。就比如说你现在回头去看 30 年前写程序的人，他们当时为什么要要用汇编语言？要用机器码来写程序？为什么要打孔啊？所以我觉得第一点就是编程会变得越来越简单，我们怎么给未来的这些程序员去设计系统？未来的程序员不会了解数据库的，我觉得因为这个东西太复杂了，我认为的趋势是这样的。

Q：如何理解 API 会成为未来兵家必争之地？

黄东旭：我觉得数据库厂商是肯定会在上面去布局的。因为你想数据再往上一层，用户怎么去用它？现在其实都是数据库的语言，SQL 其实严格来说是数据库的语言。但是你从来没有见过一个应用开发他会直接把 SQL 直接写在它的应用的 code 里，你还是要中间经过一层这个离应用更近的建模的方式。

但是呢，第一，现在没有统一的行业或者事实标准，当然有一些 particle。比如说你现在做一个后端开发，你天天在做的是什么事情呢？我底下搞个数据库，把数据存进去，用 SQL 把这个数据捞出来，封装成个 API 给应用层，程序员天天都在干这个事情。所以这个背后的逻辑很简单，就是我怎么去把这些开发者每天的日常重复的劳动和重复的工作隐藏掉。数据库扩容缩容部署这些东西，已经被 Serverless 隐藏掉了。那下一步大家花的时间一定是在业务上。业务经常在干的一些无意义的事情会被隐藏掉，但这个隐藏掉是数据库厂商去提供呢？还是其他什么公司去提供的，这不好说，但是我觉得下一步这方面会有一些进展。

Q：如何理解您所说的“抽象”？

黄东旭:这里的抽象指的是能够把数据库底层的跟业务不相关的概念也隐藏掉。我觉得第一个抽象就是把服务器这个节点的概念抽象掉。抽象成什么呢？抽象成 QPS 、TPS 流量这些业务指标；第二层的抽象，对于用户来说，比如像账单计费在过去其实是一套很复杂的系统，包括容量规划或者计费规则。我能不能简单到就像打出租车一样？我坐多长时间就给多少钱，这也是一种层次的抽象。其实对于用户来说，这个抽象层数是最高的，但是底下供应链的细节你不应该暴露给客户吧？

所以我觉得我刚才指的这个抽象的意思就是用户在做业务的过程中不要考虑的就把它隐藏起来。换成另外一个概念，或者把更好理解的概念暴露给用户，这种叫抽象。比如说一个节点挂了，你还要告诉用户说，你要手动去把这个服务器的数据导到另外一台机器上再启动起来，这个就不叫抽象了。这个节点挂了，你无感，后面都处理完了，用户没有感知，这个叫抽象。