跳到主要内容
跳到主要内容

将 Google Cloud Storage 与 ClickHouse 集成

备注

如果您在 Google Cloud 上使用 ClickHouse Cloud，则此页面不适用，因为您的服务将已经在使用 Google Cloud Storage。如果您希望从 GCS 中 SELECT 或 INSERT 数据，请参见 gcs 表函数。

ClickHouse 认识到 GCS 代表了一个吸引人的存储解决方案，适合希望分离存储与计算的用户。为了帮助实现这一目标，提供了将 GCS 用作 MergeTree 引擎存储的支持。这将使用户能够利用 GCS 的可扩展性和成本优势，以及 MergeTree 引擎的插入和查询性能。

GCS 支持的 MergeTree​

创建磁盘​

要将 GCS 存储桶作为磁盘使用，我们必须首先在 ClickHouse 配置中的 conf.d 下的文件中声明它。下面显示了 GCS 磁盘声明的示例。该配置包含多个部分，用于配置 GCS “磁盘”、缓存和在 DDL 查询中指定的在 GCS 磁盘上创建表时的策略。以下是对这些部分的描述。

storage_configuration > disks > gcs​

该配置的这一部分在高亮区域中显示，指定：

  • 不执行批量删除。GCS 目前不支持批量删除，因此禁用自动检测以抑制错误信息。
  • 磁盘类型为 s3，因为正在使用 S3 API。
  • GCS 提供的端点
  • 服务账户 HMAC 密钥和秘密
  • 本地磁盘上的元数据路径

storage_configuration > disks > cache​

下面高亮的示例配置为磁盘 gcs 启用了 10Gi 的内存缓存。

storage_configuration > policies > gcs_main​

存储配置策略允许选择数据存储位置。下面高亮的策略允许通过指定策略 gcs_main 将数据存储在磁盘 gcs 上。例如，CREATE TABLE ... SETTINGS storage_policy='gcs_main'。

有关此磁盘声明的相关设置的完整列表，可以在 这里 找到。

创建表​

假设您已配置好磁盘以使用具有写入访问权限的存储桶，您应该能够创建一个如下示例的表。为了简洁起见，我们使用纽约出租车列的子集，并将数据直接流式传输到以 GCS 为后端的表：

根据硬件情况，最后插入的 1 万行可能需要几分钟才能执行。您可以通过 system.processes 表确认进度。请随意将行数调整到 10 万的上限，并探索一些示例查询。

处理复制​

可以通过使用 ReplicatedMergeTree 表引擎与 GCS 磁盘实现复制。有关详细信息，请参阅 使用 GCS 在两个 GCP 区域复制单个分片 的指南。

了解更多​

Cloud Storage XML API 与一些与 Amazon Simple Storage Service（Amazon S3）等服务协作的工具和库进行互操作。

有关优化线程的更多信息，请参阅 优化性能。

使用 Google Cloud Storage (GCS)​

提示

默认情况下，ClickHouse Cloud 使用对象存储，如果您在 ClickHouse Cloud 中运行，则无需遵循此过程。

计划部署​

本教程旨在描述在 Google Cloud 中运行的复制 ClickHouse 部署，并使用 Google Cloud Storage（GCS）作为 ClickHouse 存储磁盘“类型”。

在本教程中，您将在 Google Cloud Engine VM 中部署 ClickHouse 服务器节点，每个节点都有一个关联的 GCS 存储桶。复制由一组 ClickHouse Keeper 节点协调，这些节点也作为 VM 部署。

高可用性的示例要求：

  • 两个 ClickHouse 服务器节点，位于两个 GCP 区域
  • 两个 GCS 存储桶，部署在与两个 ClickHouse 服务器节点相同的区域
  • 三个 ClickHouse Keeper 节点，两个部署在与 ClickHouse 服务器节点相同的区域。第三个可以与前两个 Keeper 节点中的一个在同一区域，但在不同的可用区中。

ClickHouse Keeper 需要两个节点才能正常工作，因此高可用性需要三个节点。

准备虚拟机​

在三个区域中部署五个虚拟机：

区域ClickHouse 服务器存储桶ClickHouse Keeper
1chnode1bucket_regionnamekeepernode1
2chnode2bucket_regionnamekeepernode2
3 *keepernode3

* 这可以是与 1 或 2 在同一区域的不同可用区。

部署 ClickHouse​

在两个主机上部署 ClickHouse，在示例配置中，这些主机分别命名为 chnode1、chnode2。

将 chnode1 安装在一个 GCP 区域，将 chnode2 安装在第二个区域。在本指南中，us-east1 和 us-east4 用于计算引擎虚拟机，以及 GCS 存储桶。

备注

在配置完成之前，请勿启动 clickhouse server。只需安装它。

在执行 ClickHouse 服务器节点的部署步骤时，请参考 安装说明。

部署 ClickHouse Keeper​

在三个主机上部署 ClickHouse Keeper，在示例配置中，这些主机分别称为 keepernode1、keepernode2 和 keepernode3。keepernode1 可以部署在与 chnode1 相同的区域，keepernode2 与 chnode2 相同，keepernode3 可以在任一区域，但必须与该区域的 ClickHouse 节点处于不同的可用区。

在执行 ClickHouse Keeper 节点的部署步骤时，请参考 安装说明。

创建两个存储桶​

这两个 ClickHouse 服务器将位于不同区域以实现高可用性。每个服务器将在同一区域内有一个 GCS 存储桶。

在 Cloud Storage > Buckets 中选择 CREATE BUCKET。在本教程中创建了两个存储桶，一个在 us-east1，一个在 us-east4。这些存储桶是单区域的，标准存储类，并且不是公共的。当提示启用公共访问防止时，请进行设置。不要创建文件夹，它们将在 ClickHouse 写入存储时自动创建。

如果您需要逐步说明来创建存储桶和 HMAC 密钥，请展开 创建 GCS 存储桶和 HMAC 密钥，并按照说明进行操作：

GCSバケットとHMACキーの作成

ch_bucket_us_east1​

ch_bucket_us_east4​

アクセスキーの生成​

サービスアカウントのHMACキーと秘密キーを作成する​

Cloud Storage > 設定 > 相互運用性 を開き、既存の アクセスキー を選択するか、サービスアカウント用のキーを作成 を選択します。このガイドでは、新しいサービスアカウント用の新しいキーを作成する手順を説明します。

新しいサービスアカウントを追加する​

既存のサービスアカウントがないプロジェクトの場合は、新しいアカウントを作成 を選択します。

サービスアカウントを作成するには、3つのステップがあります。最初のステップでは、アカウントに意味のある名前、ID、説明を付けます。

相互運用性設定ダイアログでは、IAMロールとして Storage Object Admin が推奨されます。ステップ2でそのロールを選択します。

ステップ3はオプションであり、このガイドでは使用されません。ポリシーに基づいてユーザーにこれらの権限を与えることができます。

サービスアカウントのHMACキーが表示されます。この情報はClickHouseの設定で使用されるため、保存してください。

配置 ClickHouse Keeper​

所有 ClickHouse Keeper 节点都有相同的配置文件，除了 server_id 行（下面第一个高亮行）。修改文件以包含 ClickHouse Keeper 服务器的主机名，并在每个服务器上将 server_id 设置为匹配 raft_configuration 中适当的 server 条目。由于本示例中 server_id 设置为 3，我们在 raft_configuration 中高亮显示了匹配的行。

  • 使用您的主机名编辑文件，并确保它们能够从 ClickHouse 服务器节点和 Keeper 节点解析
  • 将文件复制到指定位置（每个 Keeper 服务器上的 /etc/clickhouse-keeper/keeper_config.xml）
  • 根据在 raft_configuration 中的条目编号，在每台机器上编辑 server_id

配置 ClickHouse 服务器​

最佳实践

本指南中的某些步骤将要求您将配置文件放在 /etc/clickhouse-server/config.d/ 中。这是 Linux 系统上用于配置覆盖文件的默认位置。当您将这些文件放入该目录时，ClickHouse 将与默认配置合并内容。通过将这些文件放在 config.d 目录中，您可以避免在升级期间丢失配置。

网络​

默认情况下，ClickHouse 在回环接口上监听，在复制设置中，不同机器之间需要网络连接。请在所有接口上监听：

远程 ClickHouse Keeper 服务器​

复制由 ClickHouse Keeper 协调。该配置文件通过主机名和端口号标识 ClickHouse Keeper 节点。

  • 编辑主机名以匹配您的 Keeper 主机

远程 ClickHouse 服务器​

此文件配置集群中每个 ClickHouse 服务器的主机名和端口。默认配置文件包含示例集群定义，为了只显示完全配置的集群，向 remote_servers 条目添加了标记 replace="true"，以便在此配置与默认配置合并时替换 remote_servers 部分，而不是添加到其中。

  • 编辑文件以包含您的主机名，并确保它们能够从 ClickHouse 服务器节点解析

副本标识​

此文件配置与 ClickHouse Keeper 路径相关的设置，特别是用于识别数据属于哪个副本的宏。在一台服务器上应指定副本为 replica_1，在另一台服务器上指定为 replica_2。可以根据我们的示例更改名称，比如一个副本存储在南卡罗来纳州，另一个存储在弗吉尼亚州，相关值可以是 carolina 和 virginia；只需确保它们在每台机器上不同。

在 GCS 中存储​

ClickHouse 存储配置包括 disks 和 policies。下面配置的磁盘名为 gcs，类型为 s3。类型为 s3 是因为 ClickHouse 将 GCS 存储桶视为 AWS S3 存储桶。需要此配置的两个副本，一个用于每个 ClickHouse 服务器节点。

在下面的配置中应进行以下替换。

在两个 ClickHouse 服务器节点之间的替换如下：

  • REPLICA 1 BUCKET 应设置为存储桶名，与服务器位于同一区域
  • REPLICA 1 FOLDER 应在一台服务器上更改为 replica_1，在另一台服务器上则为 replica_2

在两个节点共享的替换如下：

  • access_key_id 应设置为之前生成的 HMAC 密钥
  • secret_access_key 应设置为之前生成的 HMAC 私密

启动 ClickHouse Keeper​

使用适合您操作系统的命令，例如：

检查 ClickHouse Keeper 状态​

使用 netcat 向 ClickHouse Keeper 发送命令。例如，mntr 返回 ClickHouse Keeper 集群的状态。如果您在每个 Keeper 节点上运行该命令，您将看到一个是领导者，另两个是跟随者：

启动 ClickHouse 服务器​

在 chnode1 和 chnode2 上运行：

验证​

验证磁盘配置​

system.disks 应包含每个磁盘的记录：

  • default
  • gcs
  • cache

验证集群上创建的表是否在两个节点上创建​

验证数据是否可以插入​

验证表使用了存储策略 gcs_main。​

在 Google Cloud 控制台中验证​

查看存储桶，您将看到每个存储桶中创建了一个文件夹，其名称与 storage.xml 配置文件中使用的名称相同。展开这些文件夹，您将看到许多文件，代表数据分区。

副本一的存储桶​

副本二的存储桶​