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

将 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 查询中指定的策略。每个部分的描述如下。

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'。

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

创建一个表​

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

根据硬件情况，这个插入 100 万行的数据可能需要几分钟才能完成。您可以通过 system.processes 表确认进度。可以根据需要将行数调整到 1000 万的限制，并探索一些示例查询。

处理复制​

通过使用 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 虚拟机上部署 ClickHouse 服务器节点，每个节点都有一个相应的 GCS 存储桶。复制由一组 ClickHouse Keeper 节点协调，这些节点也以虚拟机的形式部署。

高可用性的示例要求：

  • 两个 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。可以在与 chnode1 相同的区域部署 keepernode1，在与 chnode2 相同的区域部署 keepernode2，并在任一区域中以与该区域中的 ClickHouse 节点不同的可用区中部署 keepernode3。

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

创建两个存储桶​

为了实现高可用性，两个 ClickHouse 服务器将位于不同区域。每个服务器将在同一区域中拥有一个 GCS 存储桶。

在 Cloud Storage > Buckets 中选择 CREATE BUCKET。对于本教程，在 us-east1 和 us-east4 中创建了两个存储桶。存储桶是单区域的，标准存储类别，不公开。当提示时，请启用公共访问防止。如有必要，不要创建文件夹，它们将在 ClickHouse 写入存储时创建。

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

创建 GCS 存储桶和 HMAC 密钥

ch_bucket_us_east1​

在 US East 1 创建 GCS 存储桶

ch_bucket_us_east4​

在 US East 4 创建 GCS 存储桶

生成访问密钥​

创建服务帐户 HMAC 密钥和密钥​

打开 Cloud Storage > 设置 > 互操作性，选择现有的 访问密钥，或者 为服务帐户创建密钥。 本指南涵盖了为新服务帐户创建新密钥的步骤。

在 GCS 中生成服务帐户 HMAC 密钥

添加新的服务帐户​

如果这是一个没有现有服务帐户的项目，创建新帐户。

在 GCS 中添加新的服务帐户

创建服务帐户有三个步骤，在第一步为帐户提供一个有意义的名称、ID 和描述。

在 GCS 中定义新的服务帐户名称和 ID

在互操作性设置对话框中，建议选择 IAM 角色 Storage Object Admin；在第二步选择该角色。

在 GCS 中选择 IAM 角色 Storage Object Admin

第三步是可选的，本指南中未使用。您可以根据您的政策允许用户拥有这些权限。

在 GCS 中配置新服务帐户的附加设置

服务帐户 HMAC 密钥将显示。保存此信息，因为它将在 ClickHouse 配置中使用。

检索 GCS 生成的 HMAC 密钥

配置 ClickHouse Keeper​

所有 ClickHouse Keeper 节点的配置文件相同，唯一的区别是 server_id 行（下面第一行高亮）。根据 ClickHouse Keeper 服务器的主机名修改文件，并在每台服务器上将 server_id 设置为与 raft_configuration 中的相应 server 条目匹配。本例中 server_id 设置为 3，我们在 raft_configuration 中高亮显示了相应的行。

  • 编辑文件以包含您的主机名，并确保它们可以从 ClickHouse 服务器节点和 Keeper 节点解析
  • 将文件复制到对应位置 (/etc/clickhouse-keeper/keeper_config.xml 在每个 Keeper 服务器上)
  • 根据其在 raft_configuration 中的条目编号编辑每台机器上的 server_id

配置 ClickHouse 服务器​

best practice

本指南中的某些步骤会要求您将配置文件放置在 /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 配置文件中使用的名称相同。展开这些文件夹，您将看到许多文件，表示数据分区。

副本一的存储桶​

Google Cloud Storage 中副本一的存储桶

副本二的存储桶​

Google Cloud Storage 中副本二的存储桶