黄金屋 #1 开发者的未来：基于云服务构建数据基础设施

从亚马逊云科技（AWS）发布 S3 对象存储服务转型云计算至今，已经过去了 18 个年头。今天，在云上交付数据基础设施（Data Infrastructure）已经是广为用户接受的模式。即使是私有部署环境，往往也使用 Kubernetes 调度容器，并且能够方便地找到兼容 S3 API 的对象存储服务。

应该说，未来的应用全面上云是可以遇见的。那么，作为应用数字底座的数据基础设施，包括各种形态的数据库、消息队列和中间件等，同样全面上云，以充分利用云上资源，与云上应用形态深度集成，就是不可阻挡的趋势。

这就为数据系统的创新者提出了一个新的需求：如何在云上实现高质量的数据系统？

要想回答这个问题，答案绝不是简单地把过往流行的数据系统照搬到云环境，按照原有的架构在云上寻找各个组件的替代品；相反，这是一个如何理解云服务价值，并以云服务本身为基础构建块重新设计数据基础设施的问题。

为什么简单照搬原有架构行不通？

一开始，数据基础设施都是单机系统。类似 PostgreSQL 和 Apache ActiveMQ 等软件，并没有设想需要在系统内解决多节点通信和数据分散存储的问题。

二十年前，Google 发布了三篇奠定大数据领域方向的论文：

• 2003 The Google File System^[1]

• 2004 MapReduce: Simplified Data Processing on Large Clusters^[2]

• 2006 Bigtable: A Distributed Storage System for Structured Data^[3]

其核心设计理念，是将单机存储和处理海量数据的问题，转换成单机只需存储和处理少部分数据，用多台机器组成的集群应对海量数据，集群系统额外解决协同多台机器的问题。这个理念在摩尔定律失效的背景下，用 Scaling Out (Horizontal Scaling) 方案替代了不可负担甚至不可实现的 Scaling Up (Vertical Scaling) 方案。

由此诞生的一系列大数据系统，例如 Apache Hadoop、Apache HBase、Apache Cassandra 和 Apache Kafka 等等，统治了过去十多年的数据基础设施领域。

十年前，Google 开源发布了 Kubernetes^[4] 容器应用调度系统，历经数年打赢了容器调度战争，成为该领域无可争议的事实标准。

与此同时，云原生的理念开始冲击大数据生态当中的数据系统。

起初，这些系统集成了 Kubernetes 以替换原先基于 Apache Hadoop YARN 的资源调度框架。这一阶段可以称为 Cloud Native = Kubernetes 阶段。

后来，它们开始利用云对象存储，来解决海量数据不分冷热都存储在同等规格的硬件上带来的成本问题，也就是通过将冷数据归档到 S3 上来利用云服务提供的成本优势。这一阶段可以称为 Cloud Native = Kubernetes + Tiered Storage 阶段。

现在，这些系统开始以云对象存储为 Primary Data Storage 重新设计自身的架构，以期在保留原有业务能力的基础上，逐步摆脱有状态存储节点的架构。当前阶段可以称为 Cloud Native = Kubernetes + Cloud Object Storage 阶段。

这里就点出了为什么简单照搬原有架构行不通。

因为在大数据领域原先的 Shared Nothing 架构下，每个节点都有自己独特的需要持久化的状态。为了避免单机故障导致集群不可用甚至数据丢失，这些状态需要在集群的部分节点上进行复制。随之而来的就是数据复制过程中的一致性和完整性问题。大数据时代的基础设施，主要精力基本都在解决此类问题。

如果把这样的架构 1:1 搬到云环境上，由于云服务器（EC2）不绑定持久化存储，所以系统需要额外挂载块存储服务（EBS）或文件系统服务（EFS）做数据持久化。这些服务本身是 Shared Everything 的架构，即存储一次，所有节点都可访问，且自身具备完整的容错机制。如果叠加上大数据系统的副本复制机制，那么就会有严重的过度冗余。例如，用 Raft Group 做数据复制，常见一份数据存 3 副本，叠加 EBS 自身的冗余，至少就是 9 副本。

另一方面，如果把原先节点的概念映射为容器，以利用 Kubernetes 的调度能力，那么 Kubernetes 的 Pod 默认是无状态的。而大数据系统原有架构下，每个节点都持有独特的状态，因此需要额外用 Stateful Set 来为节点暴露稳定唯一的标识来保证状态访问的一致性，这会导致一定的弹性问题。然而，如同前面提到的，如果你把状态存储完全放到云对象存储这样 Shared Everything 的基础设施上，其实每个节点并不需要持有独特的状态，而是所有节点都是对等节点，基于共享存储上一致的状态信息，协调出集群负载的应对方式。

因此，将过往流行的数据系统照搬到云环境，并不能充分利用云服务的价值，甚至相反，会导致不必要的浪费和架构复杂度。

回归单机系统架构

上一节提到，以 Google 三篇论文为开端的大数据时代，解决的是单机系统无法存储和处理海量数据的问题。然而，大数据系统所提出的解法既不优雅，也不实用。

应用开发者不喜欢分布式系统。分布式系统的开发者大多用不上自己研发的系统。

说白了，除了分布式系统本身的复杂性具有一定挑战，某些开发者天生喜欢挑战难题以外，分布式系统的出现只是单机无法应对海量数据的一个不得已而为之的妥协。对于追求敏捷的应用开发者来说，无需知道分布式系统的复杂性，无需配合分布式系统改造业务，能够只将数据系统作为一个神奇的 API 调用，按照单机环境假设开发应用，才是认知负担最小、开发效率最高的模式。

而对于分布式系统本身的开发者来说，数据库的关系约束、表模式和事务等功能实现，消息队列的发布订阅语义和消费组管理，这些数据系统层面的业务逻辑，是独立于底层架构尤其是存储架构的。如果能够不用操心数据复制、数据存储一致性和数据完整性，将时间投入到数据系统的业务逻辑开发上，那对于提升 API 质量和用户体验显然是有正向帮助的。

Shared Everything 的云存储服务提供了这样的机会。基于关系数据库服务（RDS）做元数据管理和集群协同，基于对象存储服务（OSS）做数据管理，不再需要选主，不再需要主动复制数据，每个节点都是对等节点，基于共享存储上一致的状态信息，协调出集群负载的应对方式。这将是未来基于云服务的数据系统的形态。

在这种形态下，数据系统的开发实际回到了单机系统架构之下。云存储服务是本地盘，关系数据库服务是非易失性内存，不同的节点是不同的线程。节点之间的并发同步，变成关系数据库服务里的事务。

此外，这种研发模式带来的额外馈赠是，数据系统的开发者可以基于云服务资源快速搭建起一个自己开发出的系统的集群，而不像分布式系统的开发者那样，绝大多数时候都在一个弱化的单机版本或纯内存版本里调试，甚至从来没有亲手在生产环境里部署使用过自己开发的分布式系统。

为什么是关系数据库服务（RDS）？

传统大数据系统当中，占据这个位置的是 Apache ZooKeeper 或 etcd 等分布式共识系统。站在今天的环境下，新的数据系统使用 zk 或 etcd 至少会有以下问题：