新一代云数仓 Databend Cloud 在亚马逊云上的架构实践

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

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

设计目标

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

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

上述设计思路互为彼此。

• 为了最小化用户的资源开销，我们会通过 Serverless 架构，及时地释放未使用的资源，不再产生任何费用。
• 借助 EKS 和 IaC，我们实现了标准化的基础设施，充分利用标准化的安全机制。
• 外部数据系统可以便捷地与 Databend Cloud 互通，而无需关心基础设施的细节。

整体架构

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

架构总览

描述

• 对象存储作为主要存储
  Databend 将对象存储作为主要的存储，从第一天起就是存储与计算完全分离的架构。这一点大大简化了 Cloud 产品的开发难度——只需要管理、调度无状态的计算节点即可，不需要实现复杂的节点状态迁移、主从切换等机制。
  为了实现这个目标，我们的查询引擎做了大量优化，主要包含:
• 大规模地并行扫描对象文件，跑满 IO 带宽。
• 动态的流水线调度框架，能够适应不同延时的请求。
• 增加本地数据缓存和查询结果缓存以加速查询处理。

• 基于 EKS 管理计算层
• 计算层采用 EKS（AWS 托管的 Kubernetes 服务）来进行管理。通过 EKS 来协调计算资源的伸缩。
• 充分发挥 EKS 的最大优势——它的控制面是高可用和免运维的，为我们解决了大量运维上的考量和精力。

• 数仓业务逻辑的标准化封装：Operator 和 CRD
• Operator 是控制面的核心我们充分利用了 Operator 开发模式，可以灵活扩展控制逻辑。我们使用 Operator 协调完成计算资源的调度、用量统计和自动伸缩等操作。
• 定义了两种关键的 CRD：Tenant 和 Warehouse，分别管理租户和 Warehouse 的生命周期。在 Databend Cloud 上创建的 Warehouse，均会对应一个 Warehouse CRD。
• Operator 会为 Warehouse 创建一个 StatefulSet 以启动 Databend 集群。这里需要解释下，虽然 Databend Query 本身是无状态的，那么为什么选择 StatefulSet 而非 Deployment呢？首先 StatefulSet 中的 Pod 能够拥有一个固定编号，我们会选择 0 号 Pod 作为协调者，使请求固定地访问同一个协调者进行 Plan 与协调执行。其次，我们也为 Databend 集群绑定了了一个 SSD Cache，用于加速访问。
• 使用了 Karpenter 作为 AutoScaler，可以在集群的物理资源不足时，动态申请更多计算资源，并会在负载较低时自动释放计算资源，这使集群弹性十足，能够随时应对资源需求的变化。

• 多租户的元信息中心
  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 请求转发给 EKS 中的 Databend 实例执行计算，并最终将结果返还给使用方。
  我们选择 HTTP 协议作为 Query 协议的通讯传输层。
• 在云原生环境中，包括 Query Gateway 在内的一切组件都随时可能重启，原因多种多样，可能是版本发布，也可能是机器维护。
• 相比于四层的 MySQL、Postgres 等协议，无状态的 HTTP 协议会有很大的优势，如不需要对连接进行保活，只要满足 Kubernetes 对应用程序的退出信号做到正确的平滑退出，就能够在版本发布与机器维护期间不中断任何用户的请求。
  
  目前，我们将自有的 Query 协议与大数据生态进行集成，并成功融入流行的现代数据工作流中。
• 提供 Go、Java、Python、Rust 四种语言的 SDK
• 提供 Metabase、Grafana、Quick BI、Deepnote、Airbyte、Kafka、DataX、Flink CDC 等数据系统的对接
• 推进 Flight SQL 协议的集成

• 自动休眠与自动唤醒
  为了减少计算资源的开销，我们会定期采集活跃 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 访问权限。
• 除了控制面流量，额外的一条通信来自用量信息的同步。每个区域内的 Operator 会在收集到 Warehouse 的用量、存储用量的信息后，异步地将用量信息推送给 Cloud Console。Cloud Console 会将用量信息收集集中存储于自己的数据库中，经聚合后生成用量统计数据，并在每月生成账单。

• 数据安全
  数据安全是 Cloud Warehouse 平台的重中之重，在建设 Databend Cloud 期间：
• 我们希望应用 State of Art 的安全实践，最大限度地保障用户的数据安全。
• 我们希望租户间有严格的数据访问隔离性，同时，我们也希望尽可能少地使用长生命周期的 AccessKey/SecretKey 来访问云上资源，因为长生命周期的 Key 一旦泄露，就会产生极大的安全隐患。
• 我们充分利用了AWS提供的基于IAM的 STS 服务，并于 EKS当中的Service Account Token 的身份认证机制无缝整合，来实现精细的访问控制。
  
• Databend Cloud 平台会在 配置Tenant 时为租户赋予单独的 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 基准测试报告

作为数仓产品，其性能是被关注的焦点，下面是 Databend 在业内分析类数据库管理系统中的基准测试表现。

导入性能，三个机型中均排第一

特别是在 c6a.metal 机型上，我们的导入性能仅需要 70 秒。与其他数据库的性能表现相比，可以看到 Databend 的导入性能有巨大的优势。这主要得益于 Databend 在向量化并行导入下的极致优化，以及 pipeline 在计算和 io 之间的优秀调度能力。

此外，我们的底层 Storage Access 模块都基于 OpenDAL[2]，它具有简洁的 API 设计，同时不失原生 API 的性能，覆盖了 s3、fs、memory、ftp、azblob、ipfs 等十多种后端存储。许多优秀的 Rust 项目，如 RisingWave、Greptime、Sccache 等，都采用了 OpenDAL 作为底层 IO 模块。目前，OpenDAL 已经进入 Apache 孵化器孵化，旨在打造云原生应用的统一存储底座。

查询性能，三个机型下各居一二三

在 Hot Run 查询下，Databend 在 c6a.4xlarge 上表现出色，排名第一；在 c5.4xlarge 微弱劣势居第二，c6a.metal 居第三。

最后

如何更高效、更安全、更低成本地利用云上资源，逐渐成为云数仓行业的一项共同关注。

本文介绍了 Databend Cloud 如何打造更廉价、更高效、更安全且更易用的云上数仓。希望本文能够帮助您更好地了解现代云数仓的架构设计与优势，以及各个组件的工作机制。期待您与 Databend Cloud 和亚马逊一道，共同探索大规模数据分析的现代解决方案。

本篇作者