メインコンテンツまでスキップ
メインコンテンツまでスキップ

Google Cloud StorageをClickHouseと統合する

注記

ClickHouse CloudをGoogle Cloudで使用している場合、このページは適用されません。サービスはすでにGoogle Cloud Storageを使用しているためです。GCSからデータをSELECTまたはINSERTしようとしている場合は、gcsテーブル関数を参照してください。

ClickHouseは、GCSがストレージと計算を分離したいユーザーにとって魅力的なストレージソリューションであることを認識しています。この実現を助けるため、MergeTreeエンジンのストレージとしてGCSを使用するためのサポートが提供されています。これにより、ユーザーはGCSのスケーラビリティとコスト利点、さらにMergeTreeエンジンの挿入とクエリパフォーマンスを活用できます。

GCSバックのMergeTree​

ディスクの作成​

GCSバケットをディスクとして利用するには、まずClickHouseの設定ファイル内でconf.dの下にそれを宣言する必要があります。以下に、GCSディスク宣言の例を示します。この設定には、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バックのテーブルにストリームします。

ハードウェアによっては、この1百万行の挿入には数分かかる場合があります。進捗はsystem.processesテーブルで確認できます。行数を10mの上限まで調整し、サンプルクエリを試してみてください。

レプリケーションの処理​

GCSディスクとのレプリケーションは、ReplicatedMergeTreeテーブルエンジンを使用して実現できます。GCSを使用して2つのGCPリージョンで単一のシャードをレプリケートするガイドで詳細を参照してください。

さらに学ぶ​

Cloud Storage XML APIは、Amazon Simple Storage Service (Amazon S3)などのサービスと連携するいくつかのツールやライブラリと相互運用可能です。

スレッドの調整に関する詳細情報は、パフォーマンスの最適化を参照してください。

Google Cloud Storage (GCS)の使用​

ヒント

ClickHouse Cloudではデフォルトでオブジェクトストレージが使用されるため、ClickHouse Cloudを実行している場合はこの手順に従う必要はありません。

デプロイメントの計画​

このチュートリアルは、Google Cloudで実行されるレプリケートされたClickHouseデプロイメントを説明し、ClickHouseストレージディスク「タイプ」としてGoogle Cloud Storage (GCS)を使用することを目的とします。

チュートリアルでは、ストレージ用のGCSバケットが各Google Cloud Engine VMに関連付けられたClickHouseサーバーノードをデプロイします。レプリケーションは、VMとしてデプロイされた一連のClickHouse Keeperノードによって調整されます。

高可用性のためのサンプル要件：

  • 2つのGCPリージョンに2つのClickHouseサーバーノード
  • 2つのClickHouseサーバーノードと同じリージョンにデプロイされた2つのGCSバケット
  • 3つのClickHouse Keeperノード、そのうち2つはClickHouseサーバーノードと同じリージョンにデプロイされています。3つ目は、最初の2つのKeeperノードのいずれかと同じリージョンにありますが、異なる可用性ゾーンにあります。

ClickHouse Keeperは機能するために2つのノードが必要であるため、高可用性のために3つのノードが必要です。

VMの準備​

3つのリージョンに5つのVMをデプロイします：

リージョンClickHouseサーバーバケットClickHouse Keeper
1chnode1bucket_regionnamekeepernode1
2chnode2bucket_regionnamekeepernode2
3 *keepernode3

* これは1または2と同じリージョン内の異なる可用性ゾーンであることができます。

ClickHouseのデプロイ​

2つのホストにClickHouseをデプロイします。このサンプル設定では、これらはchnode1、chnode2と名付けられています。

chnode1を1つのGCPリージョンに配置し、chnode2を別のリージョンに配置します。このガイドでは、計算エンジンVM用にus-east1とus-east4を使用し、同じくGCSバケット用にも使用します。

注記

clickhouse serverを設定が完了するまで起動しないでください。インストールするだけです。

ClickHouseサーバーノードでのデプロイ手順については、インストール手順を参照してください。

ClickHouse Keeperのデプロイ​

3つのホストにClickHouse Keeperをデプロイします。このサンプル設定では、これらはkeepernode1、keepernode2、keepernode3と名付けられています。keepernode1はchnode1と同じリージョンにデプロイでき、keepernode2はchnode2と一緒にデプロイし、keepernode3はどちらのリージョンにもデプロイできますが、そのリージョンのClickHouseノードとは異なる可用性ゾーンに配置してください。

ClickHouse Keeperノードでのデプロイ手順については、インストール手順を参照してください。

2つのバケットを作成​

2つのClickHouseサーバーは高可用性のために異なるリージョンに配置されます。各サーバーには同じリージョン内にGCSバケットがあります。

Cloud Storage > BucketsでCREATE BUCKETを選択します。このチュートリアルでは、us-east1とus-east4のそれぞれに1つのバケットを作成します。バケットは単一リージョンの標準ストレージクラスであり、公開されません。プロンプトが表示されたら、公開アクセス防止を有効にします。フォルダーを作成しないでください。ClickHouseがストレージに書き込むときに作成されます。

バケットとHMACキーを作成するためのステップバイステップの手順が必要な場合は、Create GCS buckets and an HMAC keyを展開し、手順に従ってください：

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）。
  • 各マシンのserver_idを変更します。これはraft_configuration内のエントリ番号に基づいています。

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パスに関連する設定を構成します。データがどのレプリカの一部であるかを特定するために使用されるマクロを具体的に示します。1台のサーバーではレプリカをreplica_1として指定し、他方のサーバーではreplica_2として指定すべきです。名前は、例として、1つのレプリカがサウスカロライナにあり、もう1つがノースバージニアに保存される場合、値はcarolinaとvirginiaにすることができます。ただし、各マシンで異なることを確認してください。

GCSでのストレージ​

ClickHouseのストレージ設定にはdisksとpoliciesが含まれます。以下で設定されているディスクはgcsと名付けられ、typeはs3です。このタイプは、ClickHouseがGCSバケットにAWS S3バケットのようにアクセスするためです。この設定の2つのコピーが必要で、各ClickHouseサーバーノード用に1つずつ用意します。

設定内の以下の置換を行う必要があります。

この置換は2つのClickHouseサーバーノードで異なります：

  • REPLICA 1 BUCKETは、サーバーと同じリージョンのバケットの名前に設定されるべきです。
  • REPLICA 1 FOLDERは、1台のサーバーでreplica_1に、もう1台のサーバーでreplica_2に変更されるべきです。

これらの置換は、2つのノード間で共通です：

  • access_key_idは、前に生成されたHMACキーに設定されるべきです。
  • secret_access_keyは、前に生成されたHMACシークレットに設定されるべきです。

ClickHouse Keeperの起動​

オペレーティングシステムに応じたコマンドを使用してください。例えば：

ClickHouse Keeperのステータスを確認​

ClickHouse Keeperにコマンドをnetcatで送信します。例えば、mntrはClickHouse Keeperクラスタの状態を返します。各Keeperノードでこのコマンドを実行すると、一つはリーダーであり、他の二つはフォロワーであることがわかります。

ClickHouseサーバーの起動​

chnode1とchnode2で実行します：

検証​

ディスク設定を確認​

system.disksには、各ディスクのレコードが含まれているはずです：

  • default
  • gcs
  • cache

クラスタ上に作成されたテーブルが両方のノードに作成されていることを確認​

データが挿入できることを確認​

ストレージポリシーgcs_mainがテーブルに使用されていることを確認​

Google Cloud Consoleでの確認​

バケットを確認すると、storage.xml設定ファイルで使用された名前のフォルダーが各バケットに作成されているのがわかります。フォルダーを展開すると、データパーティションを表す多くのファイルが表示されます。

レプリカ1のバケット​

レプリカ2のバケット​