Databend Cloud 平台的 Serverless 架构实践

作者：李亚舟

Databend Cloud 负责人

https://github.com/flaneur2020

Databend 是一个开源的、完全面向云架构的新式数仓，它将廉价的云存储作为主要存储，并提供快捷高效的分析性能，已帮助很多客户实现了数仓、行为日志等场景的降本增效并广受好评。

当然，Databend 也提供了云服务！Databend Cloud 能够帮助您托管 Databend 实例，并提供 Serverless 的部署模式，按计算时长而非固定的硬件资源进行计费。Serverless 部署不仅可以降低成本，还可以提高系统的弹性和可靠性。通过使用 Databend Cloud，您可以轻松构建低成本、高性能的数据仓库，并专注于分析而非基础架构的维护。

Databend Cloud 与 Databend 项目几乎在同一时间启动开发，在建设 Databend Cloud 期间，会同时产生一些对可扩展性、高可用性等基础设施需求，也正与 Databend 以云为中心的定位相契合。两者持续的打磨，使得 Databend Cloud 更加易用的同时，也使得 Databend 社区版更易于部署、管理和访问。

如何更高效、更安全、更低成本地利用云上资源，逐渐成为行业的一项共同关注。本文将介绍 Databend Cloud 架构的设计与取舍，以及各个组件的工作机制。希望本文能够帮助您更好地发挥云的优势，使云上数仓更廉价、更高效、更安全且更易用。

设计思路

如下设计思路贯穿 Databend Cloud 开发过程的始终：

• 按需付费，并最小化用户在计算、存储与流量等资源方面的开销
• Serverless 架构，基于 Kubernetes 和 IaC 自动化一切，总是最新版
• 默认安全，按 SOC2 标准设计零信任架构，租户之间强隔离，默认加密
• 融入数据生态，并为大数据生态加入更多云原生与 Rust 要素

上述设计思路互为彼此：为了最小化用户的资源开销，我们会通过 Serverless 架构，及时地释放未使用的资源不再产生任何费用；借助 Kubernetes 和 IaC，我们实现了标准化的基础设施，使标准化的安全机制内建于不同的云厂商与区域；此外，外部数据系统可以便捷地与 Databend Cloud 互通，而无需关心基础设施的细节。

接下来，我们会详细介绍 Databend Cloud 的总体架构与各组件的工作机制。

架构概览

下图为 Databend Cloud 在一个区域中的架构概览：

大体而言，Databend Cloud 在架构上，采用了控制面与数据面分离的多租户存储层 + Serverless 计算层的设计：

• 将对象存储作为主要存储，并按租户进行存储隔离
• 基于 Kubernetes 管理计算资源，将 Operator 作为控制面的中心，每个区域暴露一个内网的 Manage Grpc 服务用于跨云管理
• 通过多租户的元数据中心来存储表结构、身份认证等元信息
• 通过自研的 Query Gateway 作为数据面的入口
• 统一的跨区 Cloud Console 作为管理界面的入口，用于管理账号与组织信息、收集用量信息等

对象存储作为主要存储

Databend 将对象存储作为主要的存储，因此第一天起就是存储与计算完全分离的架构。这一点大大简化了 Cloud 产品的开发难度：只需要管理、调度无状态的计算节点即可，不需要实现复杂的节点状态迁移、主从切换等机制。

不过对象存储在带来成本优势的同时，也为我们的查询引擎带来了新的挑战：

1. 对象存储的访问时间延不稳定
2. 云厂商可能会在对象存储的访问上施加限额

因此我们在流水线调度上针对对象存储的性质做了很多优化：

1. 大规模地并行扫描对象文件，使 IO 带宽跑满
2. 动态的流水线调度框架，动态适应不同延时的请求
3. 针对云存储的限额等报错，动态地退避重试，确保查询成功
4. 增加本地 SSD Cache 以加速热数据访问

基于 Kubernetes 管理计算资源

我们将计算层放置于云厂商的 Kubernetes 中进行管理。通过 Kubernetes，我们能够抹平不同云厂商之间的差异，使用同一套 API 来协调计算资源的伸缩。Kubernetes 社区中通行的 Operator 开发模式，允许我们灵活地扩展控制逻辑。除了计算资源的调度，还有用量统计、自动伸缩等操作，也均由 Operator 来协调完成。

Operator 正是控制面的核心。它主要定义了 Tenant 和 Warehouse 两种 CRD，分别管理租户和 Warehouse 的生命周期。在 Databend Cloud 上创建的 Warehouse，均会对应一个 Warehouse CRD，随后 Operator 会为 Warehouse 创建一个 StatefulSet 以启动 Databend 集群。

Databend Query 本身是无状态的，那么为什么选择 StatefulSet 而非 Deployment？首先 StatefulSet 中的 Pod 能够拥有一个固定编号，我们会选择 0 号 Pod 作为协调者，使请求固定地访问同一个协调者进行 Plan 与协调执行；其次，我们也为 Databend 集群绑定了了一个 SSD Cache，用于加速访问。

此外，为了提高整体的资源利用率，我们使用了 Karpenter 作为 Scaler，它能够在集群的物理资源不足时，动态向云厂商申请更多物理资源并自动加入集群，并在用量较低时自动释放物理资源，这使得 Kubernetes 集群形成了一个弹性的资源池，能够动态适应我们对物理资源需求的变化。

多租户的元信息中心

Databend 会尽可能多地缓存从 Metasrv 中得到的元信息，因此对 Metasrv 的访问压力往往并不高。因此我们选择将 Metasrv 部署为多租户的共享集群，通过 Key 前缀来区分不同租户的元数据。

在 Databend Cloud 中，Metasrv 不只用于保存表结构、用户认证信息等元数据，也为 Databend Cloud 中的表写入提供了事务性支持。对象存储往往没有提供强一致性的写入语义，我们通过基于 Raft 的 metasrv 集群补齐了这一短板：在 Databend 中表的每次写入操作均会生成新的 Snapshot 文件，在 Metasrv 中写入成功对应表的 Snapshot Key，才标志着这次写入是成功的，Metasrv 正是 Databend 实现 ACID 的基础。

Metasrv 作为 Databend Cloud 基础设施中唯一的有状态组件，其可靠性至关重要，我们为它设置了自动的备份机制，并持续地对它进行可靠性演练。从 Metasrv 中孵化的 openraft 框架是 Metasrv 保障正确性的坚实基础，它目前已是 rust 生态圈中最受好评的 Raft 框架，目前已为微软、火币等企业应用于生产。

数据面

数据面代表 Databend Cloud 中从数据导入、执行计算到展现的路径，它会按公网的 Query Gateway 作为访问入口，将来自外部的 HTTPS 请求转发给 Kubernetes 中的 Databend 实例执行计算，并最终将结果返还给使用方。

我们的 Query 协议选择了基于 HTTP 协议作为通信传输层。在云原生环境中，包括 Query Gateway 在内的一切组件都随时可能重启，原因可能是版本发布，也可能是机器维护。这时相比于四层的 MySQL、Postgres 等协议，无状态的 HTTP 协议会有很大的优势：不需要对连接进行保活，只要应用程序满足 Kubernetes 对退出信号的做到正确的平滑退出，就能够在版本发布与机器维护期间不中断任何用户的请求。

不过我们在将自有的 Query 协议与大数据生态集成时遇到了一些困难：我们需要实现不同语言的 SDK、也需要针对诸多不同的系统做一对一的对接，这对于一个新产品而言是一项不小的工作量。目前我们已提供了 Go、Java、Python、Rust 四种语言的 SDK，也提供了 Metabase、Grafana、Quick BI、Deepnote、Airbyte、Kafka、DataX、Flink CDC 等数据系统的对接。我们也开始尝试实现基于 Flight SQL 的协议，借助 Arrow 社区的 SQL 协议标准，使 Databend Cloud 更易于与其他系统集成，与更大的生态相融合。

自动休眠与自动唤醒

为了减少计算资源的开销，我们会定期采集活跃的 Warehouse 的指标，如果超过 Suspend 时间，则使 Warehouse 进入休眠状态，从而释放计算资源，不再产生费用。我们默认为 Warehouse 设置 5 分钟的自动休眠时长，你可以根据自己的需求，将休眠时长缩短到最低 1 分钟。

Operator 中的 SuspendController 会持续地检查活跃的 Warehouse 的 Pod，通过 /v1/status 接口获取 Databend 实例的运行状态，若一个 Warehouse 的所有 Pod 均没有活跃查询、且上次活跃的时间超过 Suspend 时长，则删除该 Warehouse 的 StatefulSet 释放计算资源。

当请求抵达 Query Gateway 时，如果对应的 Warehouse 未启动，它会通知 Operator 尝试唤醒该 Warehouse，在 StatefulSet 就绪后再继续发送 Query，受益于 Databend 实例快速的启动速度（1s 左右），一般只需几秒等待即可执行查询。通过这一自动唤醒机制，用户不再需要关心 Warehouse 的状态，每个 Warehouse 都是一个 Serverless 服务。

在这里我们并没有选择 knative 等 Serverless 框架，因为我们希望将该控制流程做到足够简单，通过更少的依赖与 CRD 定义完成工作，从而降低维护成本，并能够更灵活地调整 Serverless 策略。

多云与多区域支持

前面提到 Databend Cloud 的架构主要分为数据面和控制面两条链路，在多云与多区域部署上，Cloud Console 可以将每个区域视为暴露控制面入口的黑盒：

Databend Cloud 中支持的所有的区域均通过 Pulumi 进行 IaC 管理。通过 IaC 来管理所有的云上基础资源，使得我们在不同区域的基础设施环境完全标准、一致，允许我们构造与生产一致的测试环境，也允许我们快速地开启新区。

每增加一个区域，Cloud Console 均通过内网的 Manage Grpc 进行连接。当新用户注册时，会通过 SetupTenant 调用来初始化租户，这时它会为当前租户初始化一个 IAM Role，并绑定对象存储的 Prefix 访问权限。对于不同的云厂商，SetupTenant 的行为会有所不同，我们在这里为不同云厂商适配了不同的初始化逻辑。

除了控制面流量，额外的一条通信来自用量信息的同步。每个区域内的 Operator 会在收集到 Warehouse 的用量、存储用量的信息后，异步地将用量信息推送给 Cloud Console。Cloud Console 会将用量信息收集集中存储于自己的数据库中，经聚合后生成用量统计数据，并在每月生成账单。

数据安全

数据安全是 Cloud Warehouse 平台的重中之重，在建设 Databend Cloud 期间，我们希望应用 State of Art 的安全实践，最大限度地保障用户的数据安全。

我们希望租户间有严格的数据访问隔离性，同时，我们也希望尽可能少地使用长生命周期的 AccessKey/SecretKey 来访问云上资源，因为长生命周期的 Key 一旦泄露，就会产生极大的安全隐患。幸运的是，云厂商大多提供了基于 Kubernetes 的 Bound Service Account Token 的身份认证机制，很好地帮助我们解决了这一问题。它可以为服务提供一个自动轮换的 Token（比如半小时自动失效），并通过云厂商的 STS 服务与 IAM Role 建立身份关联，继而通过 IAM 规则限制该服务的访问权限，实现精细的访问控制。

Databend Cloud 平台会在 SetupTenant 时为租户赋予单独的 IAM Role，并通过 IAM 规则限制每位租户只能访问特定前缀下的文件。因为没有长生命周期的 Key 存在，访问 S3 等云上资源时也变得更加安全可信。

在 Databend Cloud 上存储的所有数据均默认开启加密。除此之外，你也可以在 Databend Cloud 上通过 Assume Role 的机制，挂载自己 AWS 账号中的 S3 Bucket 允许 Databend Cloud 进行分析。

RBAC

在 Databend 中，可以为每位用户绑定多个角色，角色之间可以有依赖关系，不过同一时间中只有一个活跃的 Role。Databend Cloud 中目前内置了 AccountAdmin 和 Public 两种特殊的 Role，分别作为管理员和普通用户使用，它们的特殊之处在于，AccountAdmin 是所有 Role 的父 Role，而 Public Role 属于所有 Role 的子 Role，其层级关系大约如下：

通过为不同职责的用户分配不同的角色和权限，能够保证只有取得授权的人员才能访问敏感数据。RBAC 机制正是数据安全的一项重要保障。

更多服务

除了使 Databend 作为基础设施更加易用与安全，我们也希望通过云服务提供更多的可能性。Cloud Data Warehouse 中的高级功能往往由更多的微服务组成，微服务架构允许我们持续迭代地增强 Data Cloud 服务能力，这也正是云数仓与传统数仓的最大不同。我们会持续地在 Databend Cloud 中开发更多的微服务，为 Data Cloud 架构添砖加瓦。比如：

• 自动数据导入流水线（Pipe）：允许自动从对象存储同步数据到 Databend Cloud 的表中，能够自动发现新的文件并发起导入，也能通过 API 通知接口更实时地通知新文件，目前暂只支持 AWS，正在开发与其他云厂商的对接；
• 自动冷热分离：允许将对象存储中的数据自动降级到更廉价的 Tier 上，进一步降低存储成本。
• 自动 Compact 与自动优化：根据使用的元信息，自动地发起优化，免费提高你的查询性能；
• Data Masking：允许设定规则，针对特定 Role 去屏蔽特定的行与列，保障你的数据隐私；
• Data Market：通过 Sharing 机制，自动地订阅其他租户共享的数据，形成数据集市；

总结

到这里您已对 Databend Cloud 的设计与架构有所了解，欢迎访问 https://app.databend.cn 申请注册体验！Databend Cloud 致力于提供廉价、高效、易用且安全的 Cloud Data Warehouse 解决方案。如果您有大量数据，希望能用更低的成本满足自己的分析诉求，欢迎加入社区与我们联系！

关于 Databend

Databend 是一款开源、弹性、低成本，基于对象存储也可以做实时分析的新式数仓。期待您的关注，一起探索云原生数仓解决方案，打造新一代开源 Data Cloud。

👨‍💻‍ Databend Cloud：https://databend.cn

📖 Databend 文档：https://databend.rs/

💻 Wechat：Databend

✨ GitHub：https://github.com/datafuselabs/databend