从零开始构建 ClickHouse 云一年

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

鉴于这篇文章的受欢迎程度，我们决定利用这个机会在视频中回答一些我们收到的问题。

我们的时间线和规划流程可能看起来有点不寻常。ClickHouse 自 2016 年以来一直是一个非常受欢迎的开源项目，因此当我们在 2021 年创立公司时，我们正在构建的产品存在着巨大的需求。因此，我们设定了一个雄心勃勃的目标，即在一年的时间内以一系列激进的冲刺构建这个云产品。

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

我们总是计划在每个里程碑中做太多的事情，然后迭代地重新评估我们所处的位置，并根据需要调整目标和范围。有时我们会对我们取得进展的速度感到惊讶（例如，一个功能齐全的控制面板 MVP 只用了几个星期就构建完成），而其他时候，在纸上看起来很简单的事情却需要更长的时间（例如，备份在巨大的数据量下很棘手）。对于每次发布，我们都有一个严格的功能优先级排序，并清楚地标记了阻断程序与高度期望的功能和锦上添花的功能。当我们不得不削减功能时，我们可以毫无遗憾地放弃那些排在末尾的功能。

我们不想在封闭的环境中构建，因此我们邀请了对我们产品感兴趣的 ClickHouse 用户尽早加入我们，试用该平台。我们从 5 月到 7 月开展了一项广泛的私有预览计划，邀请了 50 多位潜在客户和合作伙伴使用我们的服务。我们没有为此收费，因为我们的目标是通过观察真实世界的负载来学习，获取反馈，并与我们的用户共同成长。

但是，从一开始，我们就将易用性放在首位。我们专注于使入职流程尽可能地无摩擦——系统生成的邀请、自助入职和自动支持工作流程。与此同时，我们确保每个私有预览用户都有一个直接的 Slack 频道，这样我们可以直接听到客户的声音，并高效地解决任何问题。

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

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

下图展示了 ClickHouse 云的逻辑“共享一切”架构。

我们选择此架构的原因是

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

采取这条道路带来的额外工作包括

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

ClickHouse 云可以看作是两个不同的独立逻辑单元

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

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

控制面板和数据面板之间的双向 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 上发布了 GA 版本，但同时在 Google Cloud Platform (GCP) 上开始了概念验证工作，以确保尽早发现主要的 CSP 特定挑战。正如预期的那样，我们需要找到 AWS 特定组件的替代方案，但总的来说，这项工作一直在逐步进行。我们最关心的是，将计算和存储分离到 S3 之上需要花费多少工作才能移植到另一个云提供商。令我们欣慰的是，在 GCP 中，我们从 Google Cloud Storage (GCS) 之上的 S3 API 兼容性中获得了很大益处。我们的对象存储支持 S3 大致“正常工作”，除了身份验证方面的一些差异之外。

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

我们选择 Kubernetes 作为早期计算基础设施的原因是它具有内置的功能，可以实现扩展、重新调度（例如，在发生崩溃的情况下）、监控（存活/就绪探测）、内置服务发现，以及与负载均衡器的轻松集成。操作员模式允许构建对集群中发生的任何事件进行自动化的机制。升级更加容易（应用程序和节点/操作系统升级均如此），并且 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) 上，开发服务的 Pod 分布在 2 个 AZ 上，这样集群就可以从区域故障中恢复。我们还支持多个区域，这样在一个区域中发生的故障不会影响其他区域中的服务。

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

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

我们在每次重大更新时更新我们的结果，并在 benchmarks.clickhouse.com 上公开发布。下面的屏幕截图显示了 ClickHouse 云服务性能与几种不同大小的共享无状态配置的自托管设置的对比。这里最快的基线是在 AWS m5d.24xlarge 实例上运行的 ClickHouse 服务器，该服务器使用 48 个线程执行查询。如您所见，具有 48 个线程的等效云服务在基准测试中表现出色的性能，可以处理各种简单和复杂的查询。

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

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

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

我们根据行业趋势或客户要求不断添加新的安全功能。ClickHouse 数据库本身已经内置了许多高级安全功能，包括强大的身份验证和加密、灵活的用户管理 RBAC 策略以及设置配额和资源使用限制的能力。我们发布了我们的云私有预览版，它在控制平面上具有强大的身份验证、自动生成的默认数据库帐户的强密码以及传输和静止时的加密。在公开测试版中，我们添加了 IP 访问列表、AWS 私有链接支持、通过 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. 使用提供的 JWT 和 IAM 角色，Pod 调用简单令牌服务 (STS)
4. STS 为 Pod 提供与 IAM 角色关联的临时安全凭据

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

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

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

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

我们考虑过按其他维度定价，但每个模型都存在一些弊端，并不适合我们的用户。例如，按读/写操作定价很容易理解，但对于分析系统来说并不实用，因为单个查询可以非常简单（对一列进行简单聚合）或非常复杂（包含多个聚合和联接的多级选择）。按扫描数据量定价更合适，但我们从其他分析系统用户的经验中了解到，这种定价方式非常惩罚性，阻碍了他们使用系统——这与我们的愿望背道而驰！最后，我们考虑过基于不透明的“工作负载单位”进行定价，但最终放弃了，因为它太难理解和信任。

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

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

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

这就是账单的生成方式

1. 汇总的使用指标会被添加到当前账单中，并使用定价模型转换为成本。
2. 组织可用的任何抵扣（试用版、预付费抵扣等）都会应用于账单金额（取决于抵扣的开始/结束日期、剩余金额等）。
3. 反复计算账单总额，以检测重要的变化，例如抵扣的减少以及触发通知（“您的 ClickHouse Cloud 试用版抵扣已超过 75%”）。
4. 在计费周期结束之后，我们会再次重新计算，以确保我们包含所有在截止日期之后发送但与该周期相关的剩余使用指标
5. 然后关闭账单，任何未由抵扣覆盖的金额都会添加到 Stripe 上的新发票中，然后会从信用卡中扣除。
6. 会打开一个新的账单，以开始汇总新计费周期的使用量和成本。

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

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

对 ClickHouse 来说，为客户提供最佳的用户界面非常重要。为了实现这一点，我们需要了解客户如何使用我们的 UI，并确定哪些有效，哪些令人困惑，以及哪些需要改进。使用事件日志系统可以更直观地了解客户的行为。幸运的是，我们拥有最优秀的 OLAP 数据库！所有 Web UI 点击和其他产品使用事件都存储在 ClickHouse 云中运行的 ClickHouse 服务中，工程和产品团队都依赖这些细粒度数据来评估产品质量并分析使用情况和采用情况。我们会向 Segment报告一小部分这些事件，它可以帮助我们的营销团队观察用户旅程和跨所有接触点的转化率。

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

结论

#

在构建 ClickHouse Cloud 的过程中，我们学到了很多东西。如果让我们总结一下，我们最主要的收获是这些。

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

结论

#

我们计划在一年内构建 ClickHouse Cloud，我们做到了，但并非一帆风顺，也经历了一些挫折和弯路。最终，我们一如既往地感谢能够利用众多开源工具，这让我们更加自豪地成为开源社区的一员。自推出以来，我们收到了来自用户的压倒性响应，感谢所有参与我们私人预览版、公测版以及正式发布后一直陪伴我们一路走来的用户。

如果你想尝试 ClickHouse Cloud，我们提供 30 天试用期间 300 美元的赠金，帮助你开始使用你的用例。如果你对 ClickHouse 或 ClickHouse Cloud 有任何疑问，请加入我们的 社区 Slack 频道 或与我们 GitHub 上的开源社区 互动。我们期待听到你使用 ClickHouse Cloud 的体验，以及如何才能让它变得更好！