ClickHouse Cloud 万丈高楼平地起的这一年

本文字数：10756；估计阅读时间：27 分钟

作者：ClickHouse中国

引言

你是否能想到：我们在不到一年的时间里，从无到有的构建出了一个无服务器技术的SaaS是一种什么样的体验？在这篇博客文章中，我们将描述如何从无到有的开始构建ClickHouse Cloud - 一个基于全球最受欢迎的在线分析处理(OLAP)数据库之一的托管服务。我们会深入的探讨我们的计划、设计和架构决策、安全和合规性考虑，以及我们如何在云中实现全球扩展性和可靠性，以及我们在此过程中学到的一些经验教训。

更新和访谈

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

视频收看网址：https://www.youtube.com/watch?v=D2znXnta8ZU

时间线和里程碑

我们的时间线和计划过程可能显得有些非传统。自2016年以来，ClickHouse一直是一个非常受欢迎的开源项目，所以当我们在2021年创立公司之初，对我们正在构建的SaaS服务而言，就已经存在着巨大的市场需求。因此，我们设定了一个雄心勃勃的目标，即在一年内通过一系列激进的冲刺来构建出这个云服务。

我们提前制定了里程碑 ：

• 5月 内部预览

• 10月 对外的测试版

• 12月 GA 一般可用性 

然后，我们问自己：在这些日期之前有哪些是实现的，以及我们需要什么资源才行。我们必须非常慎重地确定每个里程碑中的优先事项，以及并行的开展哪些类型的项目。工作事项的优先级是由我们构建云服务的集体经验、市场分析和与早期云服务的潜在客户的痛点所驱动的。

在每个里程碑中，我们不可避免地计划了做太多要做的事情，然后进行反复的优先级评估，并根据需要调整目标和范围。有时我们会惊讶地发现，我们能够取得很快的进展（例如，完整功能控制平面的MVP仅仅在短短的几周内就构建出来了），而其他时候，表面上看起来很简单的事情却需要很长时间（例如，备份巨大的数据量就是非常的棘手）。我们每次所发布的功能都有严格的前后优先级排序，并明确的标明哪些是阻止器、高期望值和可有可无的功能。当我们不得不减量发布的功能时，我们就能毫无遗憾地放弃排序在最后的那些。

我们不想闭门造车，所以我们就邀请对这个云服务感兴趣的ClickHouse用户尽早的加入到内部测试中。从5月到7月，我们开展了广泛的内部预览测试计划，我们邀请到了50多个潜在的客户和合作伙伴使用我们的服务。我们没有对这次试用收费，因为我们的目标是：从这些真实的工作负载中学习，获取产品反馈，并与我们的用户一起成长。

然而，从一开始，我们就把使用的简单性放在了首位。我们专注于使上手的过程尽可能的轻松顺畅 - 系统生成用户邀请、自助上手使用和自动化的支持工作流程。同时，我们确保为每个私人预览用户提供了一个直接的Slack频道，这样我们可以直接听到客户的声音，并有效地解决任何担忧。

ClickHouse云的架构

我们的目标是：构建一个任何开发者或工程师都可以使用的云服务，无需深度理解分析型数据库，也不需要管理和扩展基础设施。

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

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

我们选择这种架构的原因是：

• 它极大地简化了数据管理：无需提前确定集群/存储的大小，无需物理地切分数据，无需在部署扩展时重新平衡数据，也无需因“共享无”的架构中存在的固定计算/存储比例而导致计算资源闲置。

• 根据我们的基准测试，以及运行真实工作负载的经验，我们发现这种架构为我们所管理的分析工作负载提供了最具竞争力的性能价格比。

选择这条路径所带来的额外工作包括：

• 对象存储的延迟比本地磁盘高，所以我们必须在对象存储的基础之上开发出智能缓存、并行访问和预取的功能，以确保分析查询仍然快速。

• 对象存储访问（尤其是写入）的代价昂贵，所以我们必须仔细看看我们写了多少文件，多久写一次，以及如何优化这个成本。

事实证明，这些事半功倍的努力，还帮助我们提高了系统整体的可靠性和性能。

ClickHouse Cloud 的组件

ClickHouse Cloud 可以看作是由两个不同的独立逻辑单元组成的：

1. 控制面 - 是“面向用户”层：

   用户界面和 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 vs. Direct VM

我们决定早期选择 Kubernetes 作为计算基础设施，因为它内置了很多功能，用于扩展、重新调度（例如，在崩溃的情况下）、监控（存活/准备就绪探测）、内置的服务发现，以及与负载均衡器的简单集成。Operator 模式允许将构建集群中发生的任何工作的自动化。升级变得更加容易（包括应用程序和节点/操作系统的升级），并且是 100% 云不可知的。

 kOps vs. 托管 Kubernetes

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

网络隔离

我们使用 Cilium，因为它使用了 eBPF， 并提供高吞吐量、较低的延迟和较少的资源消耗，尤其是在服务数量很大时。它还在所有三大主要云服务提供商上都工作得很好，包括 Google GKE 和 Azure AKS，这是我们选择的关键因素。我们考虑过 Calico，但它是基于 iptables 而不是 eBPF，没有满足我们的性能要求。Cilium 有一个详细的博客文章，深入介绍了一些技术细节和基准测试，这帮助我们理解了这些细微差别和权衡。

数据平面 API 服务器：Lambda vs. Kubernetes

当我们开始构建 ClickHouse 云时，由于 AWS Lambda 提供了快速开发时间，我们使用它建立了数据平面 API 层。我们为这些组件使用了无服务器框架。当我们开始为 Beta 和 GA 的发布做准备时，显然将应用迁移到在 Kubernetes 中运行的 Golang 应用程序会有助于缩短代码部署的时间，并使用 ArgoCD 和 Kubernetes 简化我们的部署基础架构。

负载均衡器 - AWS NLB vs. Istio

在私有内部预览中，我们为每项服务使用了一个 AWS 网络负载均衡器（NLB）。由于每个 AWS 帐户的 NLB 数量有限，我们决定使用 Istio 和 Envoy 作为共享的入口代理。Envoy 是一个通用的 L4/L7 代理，并且可以轻松地扩展，从而为特定的协议（如 MySQL 和 Postgres）提供丰富的功能。Istio 是最受欢迎的 Envoy 控制平面实现。这两个项目已经开源超过五年。随着时间的推移，它们在行业中变得相当成熟且被广泛采用。

Istio 代理使用 SNI 来将流量路由到不同的服务。公共证书是通过 cert-manager 和 Let’s Encrypt 提供的，并使用单独的 Kubernetes 集群来运行 Proxy，确保我们可以扩展集群，从而容纳增加的流量并减少安全隐患。

异步通信的消息代理（队列）

我们使用 SQS 进行数据平面内部的通信，以及控制平面与数据平面之间的通信。尽管它不是云端无关的，但它的设置简单，配置简单且价格便宜。使用 SQS 减少了我们上市的时间，并降低了此部分架构的管理开销。迁移到另一种选择，如 Google Pub/Sub，进行替代云构建的工作量也很小。

对象存储作为主要存储

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

身份验证和凭据

我们早就做出了决定，不在控制平面或数据平面的服务中存储凭据。我们使用了 Amazon Cognito 进行客户身份和访问管理（CIAM），当您设置控制平面帐户时，凭据就会持久化在那里。当您启动一个新的 ClickHouse 服务时，我们会要求您在访问启动的服务过程中下载凭据，并且不会在该会话之后存储它。

可扩展性与可靠性

可扩展性

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

自动扩展

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

自动扩展是由两个组件构建的：idler（空闲器）和scaler（扩展器）。idler的职责是挂起当前未提供查询服务的服务Pod。scaler负责确保服务有足够的资源（在限制范围内）以高效地响应当前的查询操作和速率。

ClickHouse的idling设计是一个自定义实现，紧密遵循Knative的激活器模式。由于我们的流量代理（Envoy）与我们的Kubernetes Operator 紧密集成，我们能够省略Knative所需的一些组件。

idler监视各种服务参数，以确定Pod的大致启动时间。根据这些参数，它计算出一个空闲期，并在服务在此计算期间未接受请求时，取消分配给服务的计算Pod。

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

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

可靠性

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

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

性能基准测试

在构建我们的云服务时，核心团队开源了我们内部使用的分析基准测试。我们采纳此基准测试用于在不同云环境和版本间，进行的关键性能测试之一，以更好地了解数据库在各种配置、云提供商环境和跨版本中的性能表现。预估与裸机和本地SSD相比，访问对象存储会更慢，但我们仍然期望有互动性的性能，并通过并行化、预取和其他优化进行性能调整（请参见我们的meetup讲座中如何使用ClickHouse从对象存储中快速读取100倍的方法）。

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

安全性和合规性

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

内建安全

我们利用了GDPR、SOC 2和ISO 27001等合规框架，以及CIS等安全配置标准，来构建我们产品的每一个层级。面向互联网的服务受到网络应用防火墙的保护。我们不仅为控制平面和数据库设置了强大的认证机制，而且对我们的所有内部服务和系统都设置了这种机制。当新服务被创建时，它使用基础设施即代码的方式部署，确保配置标准得到一致应用。这包括从AWS身份与访问管理（IAM）角色、流量路由规则、虚拟私人网络（VPN）配置，到传输中和休眠中的加密等其他安全配置。我们的内部安全专家会审查每个组件，确保服务在高效、有效的同时，也是安全和合规的。

持续监控

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

随时间改进

我们根据行业趋势或客户要求不断增加新的安全功能。ClickHouse数据库已经内建了许多先进的安全功能，包括强大的认证和加密、灵活的用户管理RBAC策略、以及设置配额和资源使用限制的能力。我们发布的私有预览版云服务具有对控制平面的强大认证功能，为默认数据库账户自动生成强密码，并加密传输和休眠数据。在面向公共的Beta版本服务中，我们增加了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调用Simple Token Service（STS）  

4. STS为pod提供与IAM角色关联的临时安全凭证  

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

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

定价与计费

我们用了大约六个月的时间来确定定价模型，并随后实施我们的计量和计费流程，在Beta和GA阶段根据客户反馈进行了迭代。

基于用量的定价模型

我们知道：用户希望有一个基于使用量的定价模型，以匹配他们如何使用无服务器(offering)的方式。我们考虑了许多模型，并最终选择了一个简单的基于消耗存储和计算的资源定价模型。

我们考虑了其他维度的定价，但每种模型都有其弊端，不适合我们的用户。例如，基于读/写操作的定价容易理解，但对于分析系统来说并不实用，因为一个查询可以非常简单（对一个列进行简单聚合）或非常复杂（多级选择、多个聚合和连接）。基于扫描数据量的定价更为合适，但我们从其他分析系统的用户那里了解到，这种定价方式非常严格，使他们不愿意使用该系统——这与我们的目标恰恰相反！最后，我们还考虑了基于不透明的“工作负载单位”进行定价，但最终认为这种方法过于难以理解和信任，所以放弃了。

计量和计费引擎

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

ClickHouse 已经在系统表内部公开了使用度量标准。这些数据定期从每个客户的 ClickHouse 服务中查询，并发布到一个内部的中心 ClickHouse 度量标准集群中。这个集群负责存储所有客户服务的详细使用数据，这些数据为客户在他们的服务使用页面上看到的图表提供动力，并供给计费系统。

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

以下是账单生产的流程：

1. 聚合的用量指标被添加到当前账单，并使用定价模型转换成费用。

2. 任何可用于组织的Credit（试用、预付信用等）都应用于账单金额（取决于信用的开始/结束日期、剩余金额等）。

3. 账单的总额被反复计算以检测重要的变化，如Credit的耗尽和触发通知（“您的 ClickHouse 云试用信用已超过 75%”）。

4. 在计费周期结束后，我们再次重新计算，以确保我们包括了在关闭日期后发送但属于该周期的任何剩余使用度量。

5. 然后关闭账单，任何未被信用支付的金额都会被添加到 Stripe 上的新发票中，然后会被收取信用卡费用。

6. 一个新的账单被创建，开始聚合新的计费周期的用量和成本。

管理员可以为按量计费存入信用卡信息。我们使用 Stripe 的元素 UI 组件来确保敏感的卡信息安全地直接发送到 Stripe 并被标记化。

AWS 市场

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

UI 和产品分析

对于 ClickHouse 来说，为客户提供最佳的用户界面非常重要。为了实现这一目标，我们需要了解客户如何使用我们的 UI，并识别什么 UI更好，什么是令人困惑的，以及什么应该得到改进。了解客户行为的一种方法是使用事件记录系统。幸运的是，我们内部有最好的 OLAP DB！所有的 Web UI 点击和其他产品使用事件都存储在运行在 ClickHouse 云中的 ClickHouse 服务里，工程和产品团队都依赖这些详细数据来评估产品质量并分析使用和采用情况。我们将这些事件的一个小子集报告给 Segment，它帮助我们的市场营销团队观察用户旅程，并在我们所有的接触点之间转化。

我们使用 Apache Superset 作为 ClickHouse 的可视化层，以在一个地方查看所有数据。它是一个功能强大且易于使用的开源 BI 工具，非常适合我们的需求。由于此设置从其他不同的系统中聚合数据，因此它对操作 ClickHouse Cloud 至关重要。例如，我们使用此设置来跟踪我们的转化率、微调我们的自动扩展、控制我们的 AWS 基础设施成本，并在我们的每周内部会议上作为报告工具。因为它使用了由 ClickHouse 提供的服务，所以我们从不担心因“数据过多”而使系统过载！

要点

在构建 ClickHouse Cloud 的过程中，我们学到了很多经验教训。如果我们要概括一下，对我们来说最重要的要点是这些。

1. 云并非真正的弹性。

   尽管我们认为公共云是弹性的和无限的，但是，在大规模扩容时，它并非如此。设计时要考虑到规模，仔细阅读所有的限制，并确保你在进行扩容测试以识别基础设施中的瓶颈。例如，我们在公开测试版之前进行了扩容测试，就遇到了实例可用性问题和 IAM 角色限制等问题，这促使我们采用了细胞架构。

2. 可靠性和安全性也是功能。

   重要的是要在新功能的开发与QA过程中的可靠性、安全性和可用性之间找到平衡。尤其是当产品处于开发初期时，可能会不断地构建/添加新功能，但在初期做出的架构决策将在后续产生巨大影响。

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 感到好奇，我们在30天试用期间提供300美元的Credit，以帮助您开始您的使用场景。如果您对 ClickHouse 或 ClickHouse Cloud 有任何疑问，请加入我们的社区 Slack 频道或在 GitHub 上与我们的开源社区互动。我们非常希望听到您使用 ClickHouse Cloud 的经验反馈，以及我们如何为您提供更好的服务！

首届官方社区 Meetup 分享者火热招募中🔥🔥🔥 

ClickHouse 公司官方社区将于 11 月 4 日在北京举办首届 ClickHouse Beijing User Group Meetup 活动，面向社区招募本次技术沙龙活动的分享者。

联系我们

手机号：13910395701

邮箱：Tracy.Wang@clickhouse.com

满足您所有的在线分析列式数据库管理需求