一年内从零构建 ClickHouse Cloud

您是否曾经想过，在不到一年的时间内构建一个无服务器软件即服务 (SaaS) 产品需要什么？在这篇博文中，我们将介绍我们如何从头开始构建 ClickHouse Cloud——一个建立在世界上最流行的在线分析处理 (OLAP) 数据库之上的托管服务。我们将深入探讨我们的规划流程、设计和架构决策、安全性和合规性考虑因素、我们如何在云中实现全球可扩展性和可靠性，以及我们在此过程中学到的一些经验教训。

鉴于这篇文章的受欢迎程度，我们决定借此机会在视频中回答一些出现的问题。

我们的时间线和规划流程可能看起来有点非常规。自 2016 年以来，ClickHouse 一直是一个非常流行的 开源项目，因此当我们在 2021 年成立公司时，对于我们正在构建的产品存在巨大的潜在需求。因此，我们设定了一个激进的目标，即在一年内通过一系列积极的冲刺构建此云产品。

我们预先确定了里程碑——5 月份的私有预览版、10 月份的公开 Beta 版、12 月份的正式发布版——然后问自己，在这些日期之前可以实现什么，以及我们需要哪些资源才能实现这些目标。我们必须非常明智地决定每个里程碑的优先级，以及并行启动哪些类型的项目。我们的优先级由我们构建云产品的集体经验、市场分析以及与早期云潜在客户关于他们痛点的对话驱动。

我们总是计划在每个里程碑中做太多事情，然后迭代地重新评估我们所达到的目标，并根据需要调整目标和范围。有时，我们对能够取得进展的速度感到惊讶（例如，一个功能齐全的控制平面 MVP 在短短几周内建成），而另一些时候，纸面上看起来很简单的事情却花费了更长的时间（例如，在大数据量下的备份非常棘手）。我们对每个版本的特性都有严格的堆栈排名，并清楚地标记了阻碍因素与高度期望的和锦上添花的特性。当我们需要削减特性时，我们能够毫不遗憾地删除最底层的特性。

我们不想在孤岛中构建，因此我们邀请对我们的产品感兴趣的 ClickHouse 用户尽早加入我们，试用该平台。我们在 5 月至 7 月期间运行了一个广泛的私有预览计划，邀请了 50 多家潜在客户和合作伙伴使用我们的服务。我们没有为此使用收费，因为我们的目标是从观察真实世界的工作负载中学习，获得反馈，并与我们的用户一起成长。

然而，从一开始，我们就将易用性放在首位。我们专注于使入职流程尽可能顺畅——系统生成的邀请、自助入职和自动化支持工作流程。同时，我们确保为每位私有预览用户提供直接的 Slack 频道，以便我们可以直接听到客户的声音并高效地解决任何疑虑。

我们的目标是构建一个云产品，任何开发人员或工程师都可以开始使用，而无需深入了解分析数据库，也无需显式地调整和管理基础设施。

我们最终确定了“共享一切”架构，并采用“存储和计算分离”。本质上，这意味着存储和计算是解耦的，可以单独扩展。我们使用对象存储（例如 Amazon S3）作为分析数据的主要存储，本地磁盘仅用于缓存、元数据和临时存储。

下图代表了 ClickHouse Cloud 的逻辑“共享一切”架构。

我们选择此架构的原因是

• 它极大地简化了数据管理：无需预先调整集群/存储大小，无需物理分片数据，无需在部署向上或向下扩展时重新平衡节点之间的数据，也无需因“共享无”架构中存在的固定计算/存储比率而导致计算资源闲置。
• 我们还根据我们的基准测试和运行真实世界工作负载的经验发现，对于我们看到的分析工作负载类型，这种架构提供了最具竞争力的性价比。

采用此路径产生的额外工作包括

• 对象存储延迟比本地磁盘慢，因此我们必须在对象存储之上投入智能缓存、并行访问和预取，以确保分析查询保持快速。
• 对象存储访问（尤其是对于写入操作）价格昂贵，因此我们必须仔细研究我们写入的文件数量、频率以及如何优化该成本。事实证明，这些努力也有助于我们提高整体可靠性和性能。

ClickHouse Cloud 可以被视为两个不同的独立逻辑单元

1. 控制平面 - “面向用户”的层：UI 和 API，使用户能够在云上运行其操作，授予对其 ClickHouse 服务的访问权限，并使他们能够与数据交互。
2. 数据平面 - “面向基础设施”的部分：用于管理和编排物理 ClickHouse 集群的功能，包括资源分配、配置、更新、扩展、负载均衡、隔离不同租户的服务、备份和恢复、可观察性、计量（收集使用数据）。

下图显示了 ClickHouse Cloud 组件及其交互。

控制平面和数据平面之间的双向 API 层定义了两个平面之间唯一的集成点。我们决定采用 REST API，原因如下

• REST API 独立于使用的技术，这有助于避免控制平面和数据平面之间的任何依赖关系。我们能够在数据平面中将语言从 Python 更改为 Golang，而无需对控制平面进行任何更改或影响。
• 它们提供了很大的灵活性，将各种服务器组件解耦，这些组件可以独立发展。
• 由于请求的无状态性质，它们可以高效扩展——服务器独立于之前的请求完成每个客户端请求。

当客户端执行需要与数据平面交互的操作（例如创建新集群或获取当前集群状态）时，会从控制平面调用数据平面 API。需要从数据平面传达给控制平面的事件（例如，集群已配置、监控数据事件、系统警报）使用消息代理（例如，AWS 中的 SQS 队列和 GCP 中的 Google Pub/Sub）进行传输。

此 API 的具体实现存在于数据平面内部的不同组件中。这对消费者来说是透明的，因此我们有一个“数据平面 API 外观”。数据平面 API 完成的一些任务包括

• 启动/停止/暂停 ClickHouse 服务
• 更改 ClickHouse 服务配置
  • 公开端点（例如 HTTP、GRPC）
  • 端点配置（例如 FQDN）
  • 端点安全性（例如私有端点、IP 过滤）
• 设置主客户数据库账户并重置密码
• 获取有关 ClickHouse 服务的信息
  • 有关端点的信息（例如 FQDN、端口）
  • 有关 VPC 对等连接的信息
• 获取有关 ClickHouse 服务状态的信息
  • 配置中、就绪、运行中、已暂停、已降级
• 订阅状态更新事件
• 备份和恢复

我们的控制平面在 AWS 中运行，但目标是在所有主要云提供商（包括 Google Cloud 和 Microsoft Azure）中部署数据平面。数据平面封装并抽象了云服务提供商 (CSP) 特定的逻辑，以便控制平面无需担心这些细节。

我们最初在 AWS 上开始了我们的生产构建并正式发布，但并行启动了 Google Cloud Platform (GCP) 上的概念验证工作，以确保尽早标记主要的 CSP 特定挑战。正如预期的那样，我们需要找到 AWS 特定组件的替代方案，但总的来说，这项工作是渐进的。我们主要关注的是在 S3 之上分离计算和存储的工作量需要多少才能移植到另一个云提供商。令我们欣慰的是，在 GCP 中，我们从 Google Cloud Storage (GCS) 之上的 S3 API 兼容性中受益匪浅。我们对 S3 的对象存储支持在很大程度上“只是工作”，除了身份验证方面的一些差异。

在本节中，我们将回顾一些设计决策以及我们选择的原因。

我们早期决定选择 Kubernetes 作为计算基础设施，因为它具有内置的扩展、重新调度（例如，在崩溃的情况下）、监控（活性/就绪探针）、内置服务发现以及与负载均衡器的轻松集成等功能。Operator 模式允许为集群中发生的任何事件构建自动化。升级更容易（应用程序和节点/操作系统升级），并且 100% 云不可知。

我们使用托管 Kubernetes 服务——AWS 中的 EKS（以及其他云提供商中的类似服务），因为它消除了集群本身的管理负担。我们考虑了 kOps，这是一种流行的用于生产就绪 Kubernetes 集群的开源替代方案，但我们确定，对于一个小团队来说，完全托管的 Kubernetes 服务将帮助我们更快地进入市场。

我们使用 Cilium，因为它使用 eBPF 并提供高吞吐量、更低的延迟和更少的资源消耗，尤其是在服务数量很大时。它在所有三个主要云提供商中也运行良好，包括 Google GKE 和 Azure AKS，这是我们选择的关键因素。我们考虑了 Calico，但它基于 iptables 而不是 eBPF，并且不符合我们的性能要求。Cilium 有一篇 详细的博客文章，其中深入探讨了一些技术细节和基准测试，这些帮助我们理解了细微差别和权衡。

当我们开始 ClickHouse Cloud 时，我们使用 AWS Lambda 构建了一个数据平面 API 层，因为它提供了快速的开发时间。我们为这些组件使用了 serverless.com 框架。当我们开始为 Beta 版和 GA 版发布做准备时，很明显，迁移到在 Kubernetes 中运行的 Golang 应用程序将有助于缩短我们的代码部署时间，并使用 ArgoCD 和 Kubernetes 简化我们的部署基础设施。

对于私有预览版，我们每个服务使用一个 AWS 网络负载均衡器 (NLB)。由于每个 AWS 账户的 NLB 数量有限制，我们决定使用 Istio 和 Envoy 作为共享入口代理。Envoy 是一个通用的 L4/L7 代理，可以轻松扩展以提供专门协议的丰富功能，例如 MySQL 和 Postgres。Istio 是最流行的 Envoy 控制平面实现。这两个项目都已经开源超过五年。随着时间的推移，它们变得非常成熟，并在行业中得到广泛采用。

Istio 代理使用服务器名称指示 (SNI) 将流量路由到不同的服务。公共证书通过 cert-manager 和 Let’s Encrypt 进行配置，并且使用单独的 Kubernetes 集群来运行代理可确保我们可以扩展集群以适应增加的流量并减少安全问题。

我们使用 SQS 进行数据平面内部的通信以及控制平面和数据平面之间的通信。虽然它不是云不可知的，但它易于设置、易于配置且价格低廉。使用 SQS 缩短了我们的上市时间，并降低了我们架构这一部分的管理开销。迁移到另一种替代方案（如 Google Pub/Sub）以进行其他云构建的工作量很小。

如前所述，我们使用对象存储（例如 AWS 中的 S3 或 GCP 中的 GCS）作为主要数据存储，并使用本地 SSD 用于缓存和元数据。对象存储具有无限的可扩展性、持久性，并且在存储大量数据时效率更高。在组织对象存储上的数据时，我们最初为每个逻辑 ClickHouse 服务使用单独的 S3 存储桶，但很快就开始遇到 AWS 限制。因此，我们切换到共享存储桶，其中服务基于存储桶中的子路径进行分隔，并通过维护单独的角色/服务账户来保证数据安全。

我们早期就决定不在我们的服务中存储控制平面或数据库凭证。我们使用 Amazon Cognito 进行客户身份和访问管理 (CIAM)，当您设置控制平面账户时，凭证将保存在那里。当您启动新的 ClickHouse 服务时，我们会要求您在入职期间下载凭证，并且不会在会话之外存储它。

我们希望我们的产品能够无缝扩展以处理用户流量的增加，而不会影响服务的性能。Kubernetes 使我们能够轻松扩展计算资源，通过自动故障转移和自我修复确保应用程序的高可用性，实现可移植性，并提供与其他云服务（如存储和网络）的轻松集成。

支持通过自动扩展来应对不同的工作负载模式对我们来说是一个重要的目标。由于存储和计算是分离的，我们可以根据每个工作负载的利用率添加和删除 CPU 和内存资源。

自动扩展是使用两个组件构建的：空闲器和扩展器。空闲器的职责是暂停当前未服务查询的服务的 Pod。扩展器负责确保服务具有足够的资源（在界限内）以响应当前查询的组合和速率有效地工作。

ClickHouse 空闲的设计是一种自定义实现，它紧密遵循 Knative 中的激活器模式。由于我们的代理 (Envoy) 与我们的 Kubernetes 操作符紧密集成，因此我们可以省去 Knative 中所需的一些组件。

空闲器监视各种服务参数以确定 Pod 的近似启动时间。基于这些参数，它计算空闲周期，并在服务在计算出的周期内不接受请求时，取消分配分配给该服务的计算 Pod。

ClickHouse 自动扩展器在操作上与 Kubernetes 生态系统中的自动扩展组件（如垂直和水平自动扩展器）非常相似。它与这些现成的系统在两个主要维度上有所不同。首先，它与我们的云生态系统紧密集成。因此，它能够使用来自操作系统、ClickHouse 服务器的指标，以及来自查询使用情况的一些信号来确定应为服务分配多少计算资源。其次，它对中断预算有更强的控制，这是运行有状态服务所必需的。

每 30 分钟，它会根据这些信号的历史值和当前值计算应为服务分配的资源量。它使用此数据来确定是否应为服务添加或缩减资源。自动扩展器根据启动时间和使用模式等因素确定进行更改的最佳时间。我们正在继续迭代，通过结合更多输入和进行更复杂的预测，使这些建议更快更好。

数据对企业至关重要，在这个时代，在基础设施服务方面，没有人可以容忍停机。我们很早就知道 ClickHouse Cloud 需要高度可用，并具有从内部组件故障中快速恢复的内置能力，并确保它们不会影响系统的整体可用性。集群拓扑配置为将 Pod 分布在 3 个可用区 (AZ) 中以用于生产服务，在 2 个 AZ 中用于开发服务，以便集群可以从区域故障中恢复。我们还支持多个区域，以便一个区域的停机不会影响其他区域的服务。

为了避免在一个云账户中遇到资源限制，我们为数据平面采用了 蜂窝架构。“单元”是独立的、自治的单元，彼此独立运行，为整体服务提供高度的容错能力和弹性。这有助于我们在需要时启动额外的数据平面单元，以满足增加的流量和需求，并在必要时隔离不同的服务。

当我们构建我们的云产品时，核心团队开源了我们内部使用的分析基准测试。我们将此基准测试作为跨云环境和版本运行的关键性能测试之一，以更好地了解数据库在各种配置、云提供商环境和跨版本中的性能。预计与裸机和本地 SSD 相比，访问对象存储会更慢，但我们仍然期望交互式性能，并通过并行化、预取和其他优化来调整性能（请参阅如何在我们的聚会演讲中使用 ClickHouse 将对象存储读取速度提高 100 倍）。

我们在每次重大更新时更新我们的结果，并在 benchmarks.clickhouse.com 上公开它们。下面的屏幕截图显示了 ClickHouse Cloud 服务的性能与共享无配置中各种大小的一些自我管理设置的比较。这里最快的基线是在 AWS m5d.24xlarge 实例上运行的 ClickHouse 服务器，该实例使用 48 个线程进行查询执行。正如您所见，对于基准测试中表示的各种简单和复杂查询，具有 48 个线程的等效云服务相比之下表现非常好。

从一开始就在产品中建立信任对我们来说非常重要。我们采用三层方法来保护委托给我们的数据。

我们利用 GDPR、SOC 2 和 ISO 27001 等合规性框架以及 CIS 等安全配置标准来构建我们产品的每一层。面向互联网的服务受到 Web 应用程序防火墙的保护。强大的身份验证不仅适用于我们的控制平面和数据库，也适用于我们所有的内部服务和系统。创建新服务时，它会使用基础设施即代码进行部署，以确保配置标准得到一致应用。这包括多个项目，从 AWS Identity & Access Management (IAM) 角色、流量路由规则和虚拟专用网络 (VPN) 配置，到传输中和静态加密以及其他安全配置。我们的内部安全专家会审查每个组件，以确保服务可以高效有效地运行，同时保持安全合规。

安全性和合规性不仅仅是一次性的实施练习。我们通过漏洞扫描、渗透测试、配置的安全日志记录和警报来持续监控我们的环境，并且我们鼓励行业研究人员通过我们的 漏洞赏金计划 报告任何潜在问题。此外，我们还进行持续的合规性监控，其中包含 200 多个单独的检查，包括我们的生产环境、公司系统和供应商，作为第二道防线，以确保我们在技术和面向流程的计划中都保持勤奋。

我们根据行业趋势或客户请求不断添加新的安全功能。ClickHouse 数据库已经内置了许多高级安全功能，包括强大的身份验证和加密、灵活的用户管理 RBAC 策略以及设置配额和资源使用限制的功能。我们发布了具有控制平面上强大身份验证的云私有预览版、默认数据库账户的自动生成强密码以及传输中和静态数据加密。在公开 Beta 版中，我们添加了 IP 访问列表、AWS Private Link 支持、通过 Google 进行的联合身份验证和控制平面活动日志记录。在 GA 版中，我们为控制平面引入了多因素身份验证。更多安全功能即将推出，以支持更专业的用例和行业。

总的来说，我们为每个云提供商使用标准的安全性最佳实践。我们对云环境中运行的所有组件都遵循最小特权原则。生产、暂存和开发环境彼此完全隔离。每个区域也与所有其他区域完全隔离。对 AWS S3、RDS、Route53 和 SQS 等云服务的访问都使用 IAM 角色和具有严格限制的 IAM 策略。

下图显示了我们如何使用 EKS IAM OIDC 身份提供商和 IAM 角色/策略来访问存储客户数据的 S3 存储桶。每个客户都有一个隔离的 Kubernetes 命名空间，其中包含映射到专用 IAM 角色的服务账户。

1. EKS 在 Pod 创建时自动挂载 ServiceAccount 凭证
2. Pod 使用 ServiceAccount 凭证针对 IAM OIDC 提供商
3. Pod 使用提供的 JWT 和 IAM 角色调用 Simple Token Service (STS)
4. STS 为 Pod 提供与 IAM 角色关联的临时安全凭证

我们对所有需要访问其他服务的组件都使用此模式。

处理客户数据的组件在网络层上彼此完全隔离。我们的云管理组件与客户工作负载完全隔离，以降低安全风险。

我们花了大约六个月的时间才确定我们的定价模型，并随后实施我们的计量和计费管道，然后在 Beta 版和 GA 版发布后根据客户反馈对其进行了迭代。

我们知道我们的用户希望采用基于用量的定价模型，以匹配他们使用无服务器产品的方式。我们考虑了许多模型，最终确定了一个简单的基于资源的定价模型，该模型基于消耗的存储和计算。

我们考虑了其他维度的定价，但每个模型都带有不适用于我们用户的注意事项。例如，基于读/写操作的定价易于理解，但不适用于分析系统，在分析系统中，单个查询可能非常简单（对一列进行简单聚合）或非常复杂（具有多个聚合和连接的多级选择）。基于扫描数据量的定价更合适，但我们从其他分析系统的用户那里了解到，这种类型的定价非常惩罚性，并且阻止他们使用该系统——这与我们想要的恰恰相反！最后，考虑了基于不透明“工作负载单元”的定价，但最终因太难理解和信任而被放弃。

我们根据他们的计算使用量（每分钟）和存储量（每 15 分钟）收费，因此我们需要跟踪这些维度的实时使用情况，以便显示实时使用指标并监控它们以确保其不超过某些限制。

ClickHouse 已经在系统表内部公开了使用指标。此数据会定期从每个客户的 ClickHouse 服务中查询，并发布到内部和中央 ClickHouse 指标集群。此集群负责存储我们所有客户服务的精细使用数据，这些数据为客户在其服务使用情况页面上看到的图表提供支持，并馈送到计费系统。

使用数据会定期从指标集群中收集和聚合，并传输到我们的计量和计费平台 m3ter，在那里将其转换为计费维度。我们使用滚动月度计费周期，该周期从组织的创建开始。m3ter 还具有内置功能，可以管理不同用例的承诺和预付款。

以下是账单的生成方式

1. 聚合的使用指标添加到当前账单中，并使用定价模型转换为成本。
2. 组织可用的任何信用额度（试用、预付信用额度等）都将应用于账单金额（取决于信用额度的开始/结束日期、剩余金额等）。
3. 账单的总额会重复计算，以检测重要更改，例如信用额度的耗尽和触发通知（“您的 ClickHouse Cloud 试用信用额度已超过 75%”）。
4. 在计费期结束后，我们再次重新计算，以确保我们包含在截止日期之后发送的但与该期间相关的任何剩余使用指标
5. 然后关闭账单，任何未被信用额度覆盖的金额都会添加到 Stripe 上的新发票中，并在那里向信用卡收费。
6. 打开新账单以开始聚合新计费期的使用量和成本。

管理员可以将信用卡存档以进行按需付费。我们使用 Stripe 的 elements UI 组件来确保敏感的卡信息安全地直接发送到 Stripe 并进行令牌化。

在 2022 年 12 月，ClickHouse 开始通过 AWS Marketplace 提供集成计费。AWS 中的定价模型与按需付费相同，但 Marketplace 用户通过其 AWS 账户支付其 ClickHouse 使用费用。为了促进与 AWS 的集成，我们使用 Tackle，它提供了一个统一的 API 层，用于与所有主要云提供商集成，从而在构建多云基础设施产品时显着减少了总体开发工作和上市时间。当新订阅者通过 AWS 注册时，Tackle 完成握手并将他们重定向到 ClickHouse Cloud。Tackle 还提供了一个 API，用于将 m3ter 的账单报告给 AWS。

对于 ClickHouse 而言，为我们的客户提供最佳的用户界面至关重要。为了实现这一目标，我们需要了解客户如何使用我们的 UI，并识别哪些功能运行良好，哪些功能令人困惑，以及哪些功能应该改进。获取更多客户端行为可观测性的一种方法是使用事件日志记录系统。幸运的是，我们拥有最好的内部 OLAP 数据库！所有 Web UI 点击和其他产品使用事件都存储在 ClickHouse Cloud 中运行的 ClickHouse 服务中，工程和产品团队都依赖这些细粒度的数据来评估产品质量并分析使用情况和采用率。我们将这些事件的一小部分报告给 Segment, 这有助于我们的营销团队观察用户旅程以及在所有接触点上的转化。

我们使用 Apache Superset 作为 ClickHouse 之上的可视化层，以便在一个地方查看我们所有的数据。它是一款强大且易于使用的开源 BI 工具，非常适合我们的需求。由于这种设置聚合了来自原本分散系统的数据，因此对于运营 ClickHouse Cloud 至关重要。例如，我们使用这种设置来跟踪我们的转化率、微调我们的自动扩缩容、控制我们的 AWS 基础设施成本，并作为我们每周内部会议的报告工具。由于它由 ClickHouse 提供支持，我们永远不必担心系统因“数据过多”而过载！

在构建 ClickHouse Cloud 的过程中，我们学到了很多。如果要总结一下，对我们来说最重要的要点是以下这些。

1. 云并非真正具有弹性。 即使我们认为公有云是弹性和无限的，但在高规模下，它并非如此。在设计时考虑到规模非常重要，阅读所有限制的细则，并确保您进行规模测试以找出基础设施中的瓶颈。例如，在公开测试版之前，我们在规模测试中遇到了实例可用性问题、IAM 角色限制和其他陷阱，这促使我们采用了蜂窝架构。
2. 可靠性和安全性也是功能。 在新功能开发与不损害可靠性、安全性和可用性之间找到平衡非常重要。仅仅不断构建/添加新功能是很诱人的，尤其是在产品开发的早期阶段，但在早期过程中做出的架构决策会对后续产生巨大影响。
3. 自动化一切。 测试（用户、功能、性能测试），实施 CI/CD 管道以快速安全地部署所有更改。使用 Terraform 来配置静态基础设施（如 EKS 集群），但使用 ArgoCD 来配置动态基础设施，因为它允许您在一个地方看到基础设施中正在运行的内容。
4. 设定积极的目标。我们着手在一年内构建我们的云。我们提前确定了里程碑（五月、十月、十二月），然后计划了那时可行的目标。我们不得不就每个里程碑最重要的内容做出艰难的决定，并根据需要缩小范围。由于我们对每个版本的特性都有严格的优先级排序，当我们需要削减时，我们能够毫不后悔地放弃最底层的特性。
5. 关注上市时间。 为了快速跟踪产品开发，至关重要的是要确定架构的哪些组件需要内部构建，哪些组件需要购买现有解决方案。例如，我们没有构建自己的计量和市场集成，而是利用了 m3ter 和 Tackle 来帮助我们更快地将基于使用量的定价和市场计费推向市场。如果我们不将工程工作重点放在最核心的创新上，并与其他方面合作，我们将无法在一年内构建我们的云产品。
6. 倾听用户的声音。 我们在早期就将用户作为设计合作伙伴引入我们的平台。我们的私有预览版有 50 位用户，我们邀请他们免费使用我们的服务以提供反馈。这是一个非常成功的计划，使我们能够非常快速地了解哪些方面运行良好，以及在走向公开测试版的过程中我们需要调整哪些方面。在公开测试版期间，我们再次放下笔，开始了倾听之旅。在走向 GA 的过程中，我们迅速调整了定价模型，并为开发人员推出了专用服务，以消除摩擦并满足用户的需求。
7. 跟踪和分析您的云成本。从一开始就低效地使用云基础设施并习惯每月支付巨额账单很容易。在构建和设计产品时，应将成本效率作为关键组成部分来关注，而不是事后才考虑。寻找使用云服务的最佳实践，无论是 EC2、EKS、网络还是像 S3 这样的块存储。我们发现在 S3 中有 1PB 的垃圾数据，原因是多部分上传失败，并开启了 TTL 以确保这种情况不再发生。

我们着手在一年内构建 ClickHouse Cloud，我们做到了，但这并非一帆风顺。最终，我们一如既往地感谢我们能够利用的众多开源工具，这让我们更加自豪能够成为开源社区的一份子。自我们发布以来，我们看到了用户如潮水般涌来的反响，我们感谢所有参与我们私有预览版、测试版以及自 GA 以来加入我们旅程的每个人。

如果您有兴趣试用 ClickHouse Cloud，我们提供 300 美元的信用额度，为期 30 天的试用，以帮助您开始使用您的用例。如果您对 ClickHouse 或 ClickHouse Cloud 有任何疑问，请加入我们的社区 Slack 频道或与我们在 GitHub 上的开源社区互动。我们很乐意听到您关于使用 ClickHouse Cloud 的体验的反馈，以及我们如何才能为您做得更好！