作者 ｜ 黄东旭
本文是 “2021 年度技术盘点” 系列文章之一，主要介绍数据库在2021年的重要进展。
“2021年终技术盘点”是掘金推出的重磅企划，涵盖Serverless、Service Mesh、大前端、数据库、人工智能、低代码、边缘计算等众多技术领域。看过去，向未来，回顾IT技术在2021年的发展情况，盘点IT技术的重大事件，展望IT技术的未来趋势。同时，我们将开启第15期技术主题征文活动，一起来聊聊你眼中的2022年技术趋势吧！
2021年是全球数据技术的黄金之年，也是中国数据库的蓬勃发展之年；2021 年的数据库行业，无论是技术、生态、还是行业场景拓展方面都有了长足的进步，越来越多的人关注到了数据库这个领域；海量、实时、可扩展的新一代数据架构已经成为了企业数字化创新的关键支撑，在架构以外，这一年中国数据库产业最大的变化是开源潮流的兴起，开源的价值也被主流的企业用户高度关注。
技术侧变化：云技术、 HTAP 迅速发展，Hadoop 逐步落幕
数据技术领域最大的变化应该是云基础设施对数据库的影响，未来几年数据技术的最大的变化就在分布式数据库和云基础设施的交叉创新上。在最近数据库行业的发展中，比起“代码写得好不好”这样的工程技术问题，有一件事情非常深刻地改变了整个数据库的行业，那就是数据库底层发生了变化。
以往大家去思考数据库软件和系统软件，都会先做一个假设：软件是跑在计算机等具体的硬件上的，即使是分布式数据库，每个节点都还是一个普通的计算机。现在这个假设改变了，等我们的下一代到了能够学编程或者写代码的年纪，不会再像我们现在这样能够看到 CPU、硬盘、网络等硬件，他们看到的可能就是 AWS 提供的一个 S3 的 API 。其实这种改变并不仅是软件载体的改变，更重要的是架构、编程的底层逻辑发生了变化。
云对基础设施和软件的影响和改变是深远的。具体到 PingCAP 身上，最大的感受就是比起做数据库内核， 现在在云上做 TiDB Cloud 的产品投入可能多得多。
技术侧的第二大变化是 HTAP 成为主流。我们经常说“数据驱动”，现在对于企业来说，最需要解决的挑战就是数据的“海量”和“割裂”：一方面，企业需要处理大量的数据，这本书就是挑战，另一方面，数据系统的割裂状态，让其中有价值的部分难以筛选。在过去，面对数据的联机交易处理和事实分析处理两大需求，数据库分为好多个细分的品类，每个数据库都有学习成本，诸侯割据，“各自为政”；造就了割裂的数据孤岛和复杂的技术栈。数据孤岛大大限制了企业对于数据的综合应用，也降低了企业实时汇聚，实时分析，实时决策的整体能力。
在数字化进程加速的背景下，这两年行业中的领先企业一直在尝试在应用场景和技术上做一些突破，打破这种割裂的数据孤岛的限制，把在线交易（OLTP）和离线分析（OLAP）技术进行融合，也就是我们所谓的 HTAP 能力。HTAP 带来的融合价值在于技术栈的简化和实时能力的增强。HTAP 使得众多企业的实时/交互式 BI 成为现实，为高成长企业和数字化创新场景提供了一栈式的数据服务底座。
我们在 2020 年发布了一篇论文：TiDB- A Raft-based HTAP Database.pdf 就描述了 HTAP 的理论基础。这种“一栈式”的架构过去大家也一直在尝试，但直到最近两年，得益于理论架构的创新和基础设施的成熟，HTAP 才真正成为了技术的主流，并在数字化的实时场景中广泛的用武之地。
第三个变化不算是技术突破，比起前两个进展更像是一个“甩掉包袱”的动作。2021 年 Apache 软件基金会（ASF）宣布将其至少 19 个开源项目撤回到 Apache Attic（用于归档的开源项目），其中有 10 个项目属于 Hadoop 生态系统。我个人觉得，随着实时数据分析、统一技术栈的需求越来越强烈，Hadoop 作为一个大数据技术栈本身基本上已经退出历史舞台了。
数据库是一种必须与业务场景结合的基础软件，我们常说：真实场景是最好的架构师，只有有场景、有用户，数据库技术才有机会进步和发展。Hadoop 的逐渐落幕，给了新兴的数据库新的机会，让分布式技术、NewSQL 数据库逐渐进入公众视野。从某种意义来说这也算是一个很大的进步。
⽣态变化：开源数据库成为主流，也成为构建生态的主导模式
从生态角度来讲，2021 年是中国开源进入企业软件主流市场的元年。
我们一直说开源是基础软件技术成功的最佳路径，2021 年初，开源第一次被写入国家“十四五”规划中，开源受到的关注度因此急剧提升，开源得到了越来越多开发者以外的圈外人的关注。在数据库领域，开源数据库的部署首次超过商业数据库， Databricks, Mongo 的估值或市值都比 2020 年提升一倍以上，全球开源软件公司 IPO 的热潮已经到来。
从创建之初开始，PingCAP 始终坚持开源战略，也因此体会颇多。从生态角度，开源的研发模式能够迅速积累用户。TiDB 1.0 版本 2017 年 11 月发布，从诞生到现在，我们知道名字的用户有 2000 多家，贡献者有 1600 多个，CNCF 开源组织的 Contribution Rank 中，PingCAP 过去两年排名全球第六。从技术角度，开源加速了产品的迭代速度。基本上每年 TiDB 的代码都在被重写，我们每年保持了 40% 左右的代码更新。这个迭代的速度就是通过开源社区来实现的，这是任何一个团队、任何一个公司、任何一个企业从头开始做一个数据库都无法达到的进化速度。
借助开源，学术届与工业届也正在进行更多的联结。今年，数据库领域具有最高学术地位的国际性的学术会议 SIGMOD 第一次落地中国，在西安召开，这意味着中国的数据库发展在国际上也有了一定的影响力；从我们自己来看，2021 年 PingCAP 承办了 VLDB Summer School，我们和 CCF 数据库专委会合作，以 TiDB 的 Talent Plan 为基础，带领学生了解分布式事务的理论和工程实现，并以此为参考进行分布式数据库的开发实践，实现了工业实践到学术研究的输出。中国拥有全世界最具挑战性的数据库应用场景，TiDB 通过用户大规模实践的检验，得到了越来越多全球用户的认可，正在定义分布式数据库事实标准的路上。我们也希望能够通过此次合作以实践赋能学术，培养更多数据库人才，持续保持技术领先。
DBaaS 的落地实践
云在重塑数据库的商业逻辑
技术的发展、生态的演进让更多的人加入到了数据库这个赛道中，尤其是在 OLAP 领域涌现出了许多优秀的创业公司。大多数人在思考价值的时候总是希望抓住核心应用场景或者数据存储，因为过去做商业数据库的盈利模式基本上就是收保护费，所以被保护的场景越重要，能收的保护费就越多，但是这个思路在开源 + 云时代会发生重大的变革：
- 开源数据库的成熟度已经基本上能够满足大多核心的业务场景需求
- 云可以将交付标准化
- 开源数据库的用户群体极大
基于这两个前提，其实你会找到除了追求占据核心场景这条路之外的一个新思路：找到用户旅程中的通用的路径，先不管核心不核心，极致优化用户（开发者）体验，然后利用云的基础设施把成本做低，最后利用流量入口 + PLG 走病毒式传播的路线。2021 年 Hashricorp Terraform 跨云部署工具的商业成功也正印证了这一点。
最近两年我也重新定义了一下 PingCAP 的使命：让全世界的开发者享受到我们的服务，Any where with Any Scale。因此我也一直在思考，一个流行的开源数据库应该通过什么方式规模化的商业化？
可规模化的前提一定是云化的 SaaS 服务，如果说两年前这个答案还会有人质疑云的可靠性和成熟度，在 2022 年的当下，已经毋庸置疑。
当然，从 DB 到 DBaaS 远不止将底层资源换成云这么简单，还用更多更重要的事需要考虑：技术上要实现降本增效、运维自动化、多租户管理，合规上要考虑数据安全，商业上计价模式、商业化策略等都是被纳入了考虑的范围。
接下来我就以 TiDB 为例，介绍数据库 DBaaS 化落地实践中的一些经验和思考。
成本节约：分离的架构设计
云原生技术最终要解决的就是成本的问题。
在过去，TiDB 计算和存储的边界是非常模糊的，很难处理不同负载率的场景。本地部署的情况下，如果需要增加存储容量，就需要增加存储节点，因为硬件的限制，除了磁盘，CPU 及网络带宽也会同步增加，这就造成了资源的浪费，这是所有 Shared-Nothing 的数据库都要面临的问题。
而到了云上，一切就截然不同。比如 AWS 的块存储设备的服务 EBS，特别是 GP3 系列 能够在不同的机器上运行，且达到同样的 IOPS 和 Cost，性能和对云原生的整合都非常好。 为了利用 GP3 的特性，我们是否可以把计算和存储的边界往下移，从原来的 TiKV 到存储，到现在 TiDB、TiKV 的大部分都可以是计算单元，更加灵活。
云带来的成本节约不止于此。云上真正值钱的东西是 CPU，瓶颈会是计算，而不是容量。集群和实例可以基于资源共享池进行优化（Spot instances & Clusters based on shared resource pools）、按需选择存储服务的类型、对不同类型的 EC2 实例在特定场景组合交付、无服务器计算、弹性的计算资源都将成为可能。
此外，根据我的判断，未来除了计算存储分离，网络、内存，甚至 CPU 缓存都会是分离的。因为对一个应用程序来说，尤其是分布式程序，它对硬件资源的要求总是不一样的。不管是做什么业务，就像做菜一样，手上只有一颗菜肯定做不出什么花来，但原材料很多，就可以按照口味去做自由组合，云带来的就是这样的机会。
安全性
除了成本，云的安全性也是重要课题。TiDB 官方支持的公有云是 AWS 和 GCP。云上网络用户使用的都是自己的 VPC，中间也会有 VPC Peering 打通的环节，我们看不到用户的数据，但用户可以很高性能地访问自己的业务，安全性要怎么保证？
云上的安全体系和我们云下的思考完全不同。举个特别简单的例子：云下只需要考虑 RBAC 数据库内部的权限，但在云上就非常复杂，需要考虑从网络到存储一整套的用户安全体系。做好云上安全的关键点是千万不要自己重复发明，因为基本都有安全漏洞。所以我们现在就是要充分利用云本身提供的一套完整的安全机制，比如密钥管理和规则等。当然，最好的地方都是这些服务都能够明码标价，只要做出计费模型就好了。
运维自动化
关于 DBaaS 的构建还有一点很重要，其实也和成本有关，就是运维自动化。云是一个规模化的生意，而现在国内数据库生意最麻烦的部分之一就是交付。在一些线下数据中心，一个大客户恨不得派二十个人驻场。我们要实现的就是可以通过 10 个人的交付团队去支持有 1000 个客户的系统，这是规模化的前提。TiDB 通过 Kubernetes 实现云上部署，通过 Gardener 进行联邦管理，管控多个 Kubernetes 集群。
Kubernetes
要把 TiDB 变成云服务总共分为几步？第一步就是人肉运维全部变成代码。TiDB 要扩容了，不要人肉扩容，系统自己能不能扩容？TiDB 故障恢复，人参与不了，机器能不能参与？我们把所有 TiDB 的运维全部变成了 Kubernetes Operator，相当于我们实现了自动运维 TiDB。Kubernetes 能够屏蔽所有云厂商的接口复杂性，每个云厂商都会提供 Kubernetes 服务。
Pulumi
刚才说过这些东西的部署、运维、调度的逻辑，如果都是靠人写脚本，一是不稳定，二是不可维护。我们的理念就是只要能够变成代码的东西就固化下来，千万不要依赖人，包括去开一个服务器，或者去买一个虚拟机，我们都会把它变成 Pulumi 编程语言的脚本。
Gardener
TiDB 通过 Gardener 的 API 来管控多个不同 Region 里的 Kubernetes 集群，每个 Kubernetes 集群再去划分不同租户的 TiDB 集群，形成一个多云、多区域、多 AZ 跨云、跨 AZ 的大的系统。这个架构有一个好处：用户可以在自己应用程序所在的云服务商和地理区域按需启用 TiDB，保持技术栈的统一。
做一个租户的跨云迁移就会变得平滑简单，有了 Gardener，跨云迁移对用户来说无非就是把一个 Kubernetes 的集群从 A 搬到 B，搬到 AWS 或者 GCP 没有任何区别。
商业 SLA
SLA 里面要考虑的东西也很多，这是 TiDB 要做的且正在做的东西。
TiDB 的海外客户特别多，海外用户对数据库的需求与国内用户有很大不同，跨数据中心是一个刚需。由于现在各国的数据安全需求，数据的传输有了诸多限制，合规的、跨数据中心的能力对数据库来说十分重要。比如面对欧洲的 GDPR 管控，如果能把一部分数据就放在欧洲，不要出来，只有不在管控范围内的东西能出来，就会省去很多麻烦。相信接下来这个能力对于中国的厂商和客户，包括做出海以及在国内做合规都会变成刚需。
这个功能在云上很容易实现，比如 AWS 本身就是多 AZ、多 Region 的架构，无需考虑底层，在另外一个数据中心开几台机器，用户只需要在界面上点一下鼠标数据就过去了，但对于无法在云端部署的数据库来说，如果要去处理全局的数据分布或者全局 Transaction 和 Local Transaction，需要考虑的东西就多得多。
现在 TiDB 就是未雨绸缪，这项功能已经马上就要发布了。
想要在云上提供服务，技术固然重要，合规是个前提。云上的生态整合有一个主线，就是跟着数据走，数据的上游、下游和管控是最重要的三个点。TiDB 的上游就是 MySQL、S3 里面的数据文件，下游只需要支持与 Kafka 或其他消息队列服务的同步即可。在数据的管控层面，在云上尤其是对海外用户来说，比起通过数据库厂商去做整体的管控，更希望和类似 DataDog、Confluent 这样的平台打通。
未来展望
我有几个特别看好的技术。第一个就是分布式、高可扩展性的 OLTP 数据库的云原生化。我认为包括 AWS Aurora、包括现在的主流的这些号称 Cloud Native 的一些数据库，还远没有到达一个最终形态，它相当于只是一个把一个单机数据库的技术云化了而已。分布式数据库如何与云原生真正结合，这现在还是一个悬而未决的问题。这个问题的本质就是分布式数据库如何从 On Cloud，走向 In Cloud。
第二是 AI for DB。比如 Lean Index 就是我非常关注的一个方向。对于一些我们经常访问的库和表，未来在云端，我们是否可以用一些机器学习的手段帮助用户更好地去建立索引、加速查询，更高效地使用数据库。
此外，就是在存储引擎这一端。我目前在做的研究就是希望实现把数据库的存储引擎变成一个高度微服务化的系统，再把每一个模块都搬到云上。我们现在主流使用的 LSM-tree 的数据结构，compaction 对 LSM-tree 性能抖动的影响非常大。但是到了云上，通过 serverless 技术、共享存储技术，就能够把 compaction 和 serving 分离开，这样资源增强对性能的影响就会非常小。在 compaction 的过程中还有更多的事情可以完成，包括刚才我说 lean index。
以上的一切都是基于数据库云原生化这个前提的。最后打个广告，TiDB 在 2021 年 11 月推出了对开发者的为期 12 个月的免费体验版，能够快速部署，默认支持 HTAP 功能，通过容器实现计算隔离，同时具有专用的块存储，大家在云上可以随意使用。我们的网址是 tidbcloud.com，未来也会支持国内的云，期待大家的体验和反馈。
作者介绍：
黄东旭，PingCAP 联合创始人兼 CTO，资深基础软件工程师，架构师，曾就职于微软亚洲研究院，网易有道及豌豆荚，擅长分布式系统以及数据库开发，在分布式存储领域有丰富的经验和独到的见解。狂热的开源爱好者以及开源软件作者，代表作品分布式 Redis 缓存方案 Codis，以及分布式关系型数据库 TiDB。2015 年创业，成立 PingCAP，在 PingCAP 的主要工作是从零开始设计并研发开源 NewSQL 数据库 TiDB，目前 GitHub 上该项目累积 star 数超过 29000+，成为本领域全球顶级的开源项目。
相关链接：
年终盘点Serverless：工业、学术、社区遍地开花，国内厂商迅速卡位
