ClickHouse では、ストレージとコンピュートを分離したい場合、GCS が魅力的なストレージソリューションになると考えています。これを実現できるよう、MergeTree エンジンのストレージとして GCS を使用する機能をサポートしています。これにより、GCS のスケーラビリティとコスト面での利点に加え、MergeTree エンジンの insert とクエリパフォーマンスを活用できます。
GCS bucket をディスクとして利用するには、まず conf.d 配下のファイルで ClickHouse の設定内に宣言する必要があります。GCS ディスクの宣言例を以下に示します。この設定には、GCS の「ディスク」、cache、および GCS ディスク上に table を作成する際に DDL queries で指定するポリシーを設定するための複数のセクションが含まれています。各セクションについては、以下で説明します。
構成のこの部分はハイライトされたセクションに示されており、次の項目を指定します。
S3 API を使用するため、ディスクの type は s3 です。
GCS が提供するエンドポイント
サービスアカウントの HMACキーとシークレット
ローカルディスク上のメタデータパス
< clickhouse > < storage_configuration > < disks > < gcs > < support_batch_delete > true </ support_batch_delete > < type > s3 </ type > < endpoint > https://storage.googleapis.com/BUCKET NAME/FOLDER NAME/ </ endpoint > < access_key_id > SERVICE ACCOUNT HMAC KEY </ access_key_id > < secret_access_key > SERVICE ACCOUNT HMAC SECRET </ secret_access_key > < metadata_path > /var/lib/clickhouse/disks/gcs/ </ metadata_path > </ gcs > </ disks > < policies > < gcs_main > < volumes > < main > < disk > gcs </ disk > </ main > </ volumes > </ gcs_main > </ policies > </ storage_configuration > </ clickhouse > 以下で示す設定例では、ディスク gcs に 10Gi のメモリ cache を有効化しています。
< clickhouse > < storage_configuration > < disks > < gcs > < support_batch_delete > true </ support_batch_delete > < type > s3 </ type > < endpoint > https://storage.googleapis.com/BUCKET NAME/FOLDER NAME/ </ endpoint > < access_key_id > SERVICE ACCOUNT HMAC KEY </ access_key_id > < secret_access_key > SERVICE ACCOUNT HMAC SECRET </ secret_access_key > < metadata_path > /var/lib/clickhouse/disks/gcs/ </ metadata_path > </ gcs > < gcs_cache > < type > cache </ type > < disk > gcs </ disk > < path > /var/lib/clickhouse/disks/gcs_cache/ </ path > < max_size > 10Gi </ max_size > </ gcs_cache > </ disks > < policies > < gcs_main > < volumes > < main > < disk > gcs_cache </ disk > </ main > </ volumes > </ gcs_main > </ policies > </ storage_configuration > </ clickhouse > ストレージ構成 > policies > gcs_main ストレージ構成ポリシーでは、データの保存先を選択できます。以下で示すポリシーでは、gcs_main を指定することで、データをディスク gcs に保存できます。たとえば、CREATE TABLE ... SETTINGS storage_policy='gcs_main' のように指定します。
< clickhouse > < storage_configuration > < disks > < gcs > < support_batch_delete > true </ support_batch_delete > < type > s3 </ type > < endpoint > https://storage.googleapis.com/BUCKET NAME/FOLDER NAME/ </ endpoint > < access_key_id > SERVICE ACCOUNT HMAC KEY </ access_key_id > < secret_access_key > SERVICE ACCOUNT HMAC SECRET </ secret_access_key > < metadata_path > /var/lib/clickhouse/disks/gcs/ </ metadata_path > </ gcs > </ disks > < policies > < gcs_main > < volumes > < main > < disk > gcs </ disk > </ main > </ volumes > </ gcs_main > </ policies > </ storage_configuration > </ clickhouse > このディスク宣言に関連する設定の一覧は、こちら をご覧ください。
書き込み権限のあるバケットを使用するようにディスクを設定していることを前提とすると、以下の例のようなテーブルを作成できます。簡潔にするため、ここでは NYC タクシーのカラムの一部だけを使用し、データを GCS をバックエンドとするテーブルに直接書き込みます。
CREATE TABLE trips_gcs ( `trip_id` UInt32, `pickup_date` Date , `pickup_datetime` DateTime , `dropoff_datetime` DateTime , `pickup_longitude` Float64, `pickup_latitude` Float64, `dropoff_longitude` Float64, `dropoff_latitude` Float64, `passenger_count` UInt8, `trip_distance` Float64, `tip_amount` Float32, `total_amount` Float32, `payment_type` Enum8( 'UNK' = 0 , 'CSH' = 1 , 'CRE' = 2 , 'NOC' = 3 , 'DIS' = 4 ) ) ENGINE = MergeTree PARTITION BY toYYYYMM(pickup_date) ORDER BY pickup_datetime SETTINGS storage_policy = 'gcs_main' INSERT INTO trips_gcs SELECT trip_id, pickup_date, pickup_datetime, dropoff_datetime, pickup_longitude, pickup_latitude, dropoff_longitude, dropoff_latitude, passenger_count, trip_distance, tip_amount, total_amount, payment_type FROM s3( 'https://ch-nyc-taxi.s3.eu-west-3.amazonaws.com/tsv/trips_{0..9}.tsv.gz' , 'TabSeparatedWithNames' ) LIMIT 1000000 ;
ハードウェアによっては、後者の100万行の insert の実行に数分かかる場合があります。進捗状況は system.processes テーブルで確認できます。行数は上限の1000万まで適宜調整し、いくつかのサンプルクエリを試してみてください。
SELECT passenger_count, avg (tip_amount) AS avg_tip, avg (total_amount) AS avg_amount FROM trips_gcs GROUP BY passenger_count;
GCS ディスクを使用したレプリケーションは、ReplicatedMergeTree テーブルエンジンを使用して実現できます。詳細については、GCS を使用して 2 つの GCP リージョンにまたがって単一の分片をレプリケートする ガイドを参照してください。
Cloud ストレージ XML API は、Amazon Simple Storage Service (Amazon S3) などのサービスで動作する一部のツールやライブラリとの互換性があります。スレッドの調整について詳しくは、パフォーマンスの最適化 を参照してください。
Google Cloud Storage (GCS) を使用する ClickHouse Cloud ではデフォルトでオブジェクトストレージが使用されるため、ClickHouse Cloud を使用している場合はこの手順に従う必要はありません。
このチュートリアルでは、Google Cloud 上で稼働し、ClickHouse のストレージディスクの「type」として Google Cloud Storage (GCS) を使用する、レプリケーション構成の ClickHouse デプロイメントについて説明します。
このチュートリアルでは、Google Cloud Engine VM に ClickHouse サーバー ノードをデプロイし、各ノードに対応する GCS バケットをストレージとして関連付けます。レプリケーションは、同じく VM としてデプロイされた一連の ClickHouse Keeper ノードによって調整されます。
高可用性の要件例:
2 つの GCP リージョンに 2 つの ClickHouse サーバー ノード
2 つの GCS バケット。2 つの ClickHouse サーバー ノードと同じリージョンにデプロイ
3 つの ClickHouse Keeper ノード。このうち 2 つは ClickHouse サーバー ノードと同じリージョンにデプロイします。3 つ目は最初の 2 つの Keeper ノードのいずれかと同じリージョンでもかまいませんが、可用性ゾーンは別にする必要があります。
ClickHouse Keeper が機能するには 2 ノード必要なため、高可用性を確保するには 3 ノード必要です。
3 つのリージョンに 5 台の VM をデプロイします。
Region ClickHouse Server Bucket ClickHouse Keeper 1 chnode1bucket_regionnamekeepernode12 chnode2bucket_regionnamekeepernode23 * keepernode3
* これは、1 または 2 と同じリージョン内の別のアベイラビリティゾーンにすることも可能です。2台のホストにClickHouseをデプロイします。サンプル構成では、これらのホストの名前は chnode1、chnode2 です。
chnode1 は1つ目の GCP リージョンに、chnode2 は2つ目のリージョンに配置します。このガイドでは、Compute Engine の VM と GCS バケットの両方に us-east1 と us-east4 を使用します。clickhouse server は設定が完了するまで起動しないでください。インストールだけを行ってください。
ClickHouse サーバーノードでデプロイ手順を実行する際は、インストール手順 を参照してください。
ClickHouse Keeper をデプロイする 3 台のホストに ClickHouse Keeper をデプロイします。サンプル構成では、これらのホストは keepernode1、keepernode2、keepernode3 という名前です。keepernode1 は chnode1 と同じリージョンに、keepernode2 は chnode2 と同じリージョンにデプロイできます。keepernode3 はどちらのリージョンにもデプロイできますが、そのリージョン内の ClickHouse ノードとは異なるアベイラビリティゾーンに配置する必要があります。
ClickHouse Keeper ノードでデプロイ手順を実施する際は、インストール手順 を参照してください。
高可用性のため、2 台の ClickHouseサーバーは異なるリージョンに配置します。各サーバーには、同じリージョン内に GCS バケットが 1 つ必要です。
Cloud Storage > Buckets で CREATE BUCKET を選択します。このチュートリアルでは、us-east1 と us-east4 にそれぞれ 1 つずつ、合計 2 つのバケットを作成します。バケットは単一リージョン、Standard ストレージクラス、非公開に設定します。求められたら、公開アクセス防止を有効にしてください。フォルダは作成しないでください。ClickHouse がストレージに書き込むときに作成されます。バケットと HMAC キーの作成手順を順を追って確認したい場合は、Create GCS buckets and an HMAC key を展開して、その手順に従ってください。
ch_bucket_us_east1 ch_bucket_us_east4 アクセスキーを生成する サービス アカウントの HMAC キーとシークレットを作成する Cloud Storage > Settings > Interoperability を開き、既存の Access key を選択するか、CREATE A KEY FOR A SERVICE ACCOUNT を選択します。このガイドでは、新しいサービス アカウント用に新しいキーを作成する手順を説明します。新しいサービス アカウントを追加する 既存のサービス アカウントがないプロジェクトの場合は、CREATE NEW ACCOUNT を選択します。 サービス アカウントの作成は 3 つの手順で行います。最初の手順では、アカウントにわかりやすい名前、ID、説明を設定します。 Interoperability の設定ダイアログでは、IAM role Storage Object Admin を使用することを推奨します。2 番目の手順でこのロールを選択してください。 3 番目の手順は任意であり、このガイドでは使用しません。ポリシーに応じて、ユーザーにこれらの権限を付与できます。 サービス アカウントの HMAC キーが表示されます。この情報は ClickHouse の設定で使用するため、保存しておいてください。 すべての 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 を編集してください
/etc/clickhouse-keeper/keeper_config.xml
< clickhouse > < logger > < level > trace </ level > < log > /var/log/clickhouse-keeper/clickhouse-keeper.log </ log > < errorlog > /var/log/clickhouse-keeper/clickhouse-keeper.err.log </ errorlog > < size > 1000M </ size > < count > 3 </ count > </ logger > < listen_host > 0.0.0.0 </ listen_host > < keeper_server > < tcp_port > 9181 </ tcp_port > < server_id > 3 </ server_id > < log_storage_path > /var/lib/clickhouse/coordination/log </ log_storage_path > < snapshot_storage_path > /var/lib/clickhouse/coordination/snapshots </ snapshot_storage_path > < coordination_settings > < operation_timeout_ms > 10000 </ operation_timeout_ms > < session_timeout_ms > 30000 </ session_timeout_ms > < raft_logs_level > warning </ raft_logs_level > </ coordination_settings > < raft_configuration > < server > < id > 1 </ id > < hostname > keepernode1.us-east1-b.c.clickhousegcs-374921.internal </ hostname > < port > 9234 </ port > </ server > < server > < id > 2 </ id > < hostname > keepernode2.us-east4-c.c.clickhousegcs-374921.internal </ hostname > < port > 9234 </ port > </ server > < server > < id > 3 </ id > < hostname > keepernode3.us-east5-a.c.clickhousegcs-374921.internal </ hostname > < port > 9234 </ port > </ server > </ raft_configuration > </ keeper_server > </ clickhouse > ベストプラクティス このガイドの一部の手順では、設定ファイルを /etc/clickhouse-server/config.d/ に配置する必要があります。これは、Linux システムで設定の上書きファイルを配置する既定の場所です。これらのファイルをこのディレクトリに配置すると、ClickHouse はその内容をデフォルト設定にマージします。これらのファイルを config.d ディレクトリに配置しておけば、アップグレード時に設定が失われるのを防げます。
デフォルトでは、ClickHouse はループバックインターフェイスで待ち受けます。レプリケーション構成では、マシン間のネットワーク接続が必要です。すべてのインターフェイスで待ち受けるようにします。
/etc/clickhouse-server/config.d/network.xml
< clickhouse > < listen_host > 0.0.0.0 </ listen_host > </ clickhouse >
リモート ClickHouse Keeper サーバー レプリケーションは ClickHouse Keeper によって管理されます。この設定ファイルでは、ホスト名とポート番号で ClickHouse Keeper ノードを指定します。
ホスト名を使用する Keeper ホストに合わせて編集します
/etc/clickhouse-server/config.d/use-keeper.xml
< clickhouse > < zookeeper > < node index = "1" > < host > keepernode1.us-east1-b.c.clickhousegcs-374921.internal </ host > < port > 9181 </ port > </ node > < node index = "2" > < host > keepernode2.us-east4-c.c.clickhousegcs-374921.internal </ host > < port > 9181 </ port > </ node > < node index = "3" > < host > keepernode3.us-east5-a.c.clickhousegcs-374921.internal </ host > < port > 9181 </ port > </ node > </ zookeeper > </ clickhouse >
このファイルでは、クラスター内の各 ClickHouse サーバーのホスト名とポートを設定します。デフォルトの設定ファイルにはサンプルのクラスター定義が含まれているため、完全に設定されたクラスターだけを表示するには、remote_servers エントリに replace="true" タグを追加します。これにより、この設定をデフォルト設定とマージした際、remote_servers セクションに追記するのではなく、そのセクション全体を置き換えるようになります。
ホスト名に合わせてファイルを編集し、それらが ClickHouse サーバーノードから名前解決できることを確認してください
/etc/clickhouse-server/config.d/remote-servers.xml
< clickhouse > < remote_servers replace = "true" > < cluster_1S_2R > < shard > < replica > < host > chnode1.us-east1-b.c.clickhousegcs-374921.internal </ host > < port > 9000 </ port > </ replica > < replica > < host > chnode2.us-east4-c.c.clickhousegcs-374921.internal </ host > < port > 9000 </ port > </ replica > </ shard > </ cluster_1S_2R > </ remote_servers > </ clickhouse >
このファイルでは、ClickHouse Keeper の path に関連する設定を行います。具体的には、データがどのレプリカに属しているかを識別するためのマクロを設定します。片方のサーバーではレプリカを replica_1、もう片方のサーバーでは replica_2 と指定する必要があります。名前は変更可能です。たとえば、一方のレプリカを South Carolina に、もう一方を Northern Virginia に保存する場合、値は carolina と virginia にできます。ただし、各マシンで異なる名前を指定してください。
/etc/clickhouse-server/config.d/macros.xml
< clickhouse > < distributed_ddl > < path > /clickhouse/task_queue/ddl </ path > </ distributed_ddl > < macros > < cluster > cluster_1S_2R </ cluster > < shard > 1 </ shard > < replica > replica_1 </ replica > </ macros > </ clickhouse > ClickHouse のストレージ構成には disks と policies が含まれます。以下で構成するディスクは gcs という名前で、type は s3 です。type が s3 なのは、ClickHouse が GCS バケットを AWS S3 バケットのように扱ってアクセスするためです。この構成は 2 つ必要で、それぞれの ClickHouse サーバー ノードに 1 つずつ配置します。
以下の構成では、次の置換を行ってください。
これらの置換は、2 つの ClickHouse サーバー ノードで異なります。
REPLICA 1 BUCKET は、server と同じリージョンにあるバケット名に設定してくださいREPLICA 1 FOLDER は、一方の server では replica_1 に、もう一方では replica_2 に変更してください
次の置換は 2 つのノードで共通です。
access_key_id は、先ほど生成した HMAC Key に設定してくださいsecret_access_key は、先ほど生成した HMAC Secret に設定してください
/etc/clickhouse-server/config.d/storage.xml
< clickhouse > < storage_configuration > < disks > < gcs > < support_batch_delete > true </ support_batch_delete > < type > s3 </ type > < endpoint > https://storage.googleapis.com/REPLICA 1 BUCKET/REPLICA 1 FOLDER/ </ endpoint > < access_key_id > SERVICE ACCOUNT HMAC KEY </ access_key_id > < secret_access_key > SERVICE ACCOUNT HMAC SECRET </ secret_access_key > < metadata_path > /var/lib/clickhouse/disks/gcs/ </ metadata_path > </ gcs > < cache > < type > cache </ type > < disk > gcs </ disk > < path > /var/lib/clickhouse/disks/gcs_cache/ </ path > < max_size > 10Gi </ max_size > </ cache > </ disks > < policies > < gcs_main > < volumes > < main > < disk > gcs </ disk > </ main > </ volumes > </ gcs_main > </ policies > </ storage_configuration > </ clickhouse >
ご利用のオペレーティングシステムに応じたコマンドを使用してください。たとえば次のとおりです。
sudo systemctl enable clickhouse-keeper sudo systemctl start clickhouse-keeper sudo systemctl status clickhouse-keeper
ClickHouse Keeper のステータスを確認する netcat を使って ClickHouse Keeper にコマンドを送信します。たとえば、mntr は ClickHouse Keeper クラスターの状態を返します。各 Keeper ノードでこのコマンドを実行すると、1 つが leader、残り 2 つが followers であることを確認できます。echo mntr | nc localhost 9181
zk_version v22.7.2.15-stable-f843089624e8dd3ff7927b8a125cf3a7a769c069 zk_avg_latency 0 zk_max_latency 11 zk_min_latency 0 zk_packets_received 1783 zk_packets_sent 1783 zk_num_alive_connections 2 zk_outstanding_requests 0 zk_server_state leader zk_znode_count 135 zk_watch_count 8 zk_ephemerals_count 3 zk_approximate_data_size 42533 zk_key_arena_size 28672 zk_latest_snapshot_size 0 zk_open_file_descriptor_count 182 zk_max_file_descriptor_count 18446744073709551615 zk_followers 2 zk_synced_followers 2 chnode1 と chnode で次を実行します:sudo service clickhouse-server start
sudo service clickhouse-server status
system.disks には、各ディスクのレコードが含まれているはずです。SELECT * FROM system . disks FORMAT Vertical
Row 1: ────── name: cache path: /var/lib/clickhouse/disks/gcs/ free_space: 18446744073709551615 total_space: 18446744073709551615 unreserved_space: 18446744073709551615 keep_free_space: 0 type: s3 is_encrypted: 0 is_read_only: 0 is_write_once: 0 is_remote: 1 is_broken: 0 cache_path: /var/lib/clickhouse/disks/gcs_cache/ Row 2: ────── name: default path: /var/lib/clickhouse/ free_space: 6555529216 total_space: 10331889664 unreserved_space: 6555529216 keep_free_space: 0 type: local is_encrypted: 0 is_read_only: 0 is_write_once: 0 is_remote: 0 is_broken: 0 cache_path: Row 3: ────── name: gcs path: /var/lib/clickhouse/disks/gcs/ free_space: 18446744073709551615 total_space: 18446744073709551615 unreserved_space: 18446744073709551615 keep_free_space: 0 type: s3 is_encrypted: 0 is_read_only: 0 is_write_once: 0 is_remote: 1 is_broken: 0 cache_path: 3 rows in set. Elapsed: 0.002 sec.
クラスターで作成したテーブルが両方のノードに作成されていることを確認する create table trips on cluster 'cluster_1S_2R' ( `trip_id` UInt32, `pickup_date` Date , `pickup_datetime` DateTime , `dropoff_datetime` DateTime , `pickup_longitude` Float64, `pickup_latitude` Float64, `dropoff_longitude` Float64, `dropoff_latitude` Float64, `passenger_count` UInt8, `trip_distance` Float64, `tip_amount` Float32, `total_amount` Float32, `payment_type` Enum8( 'UNK' = 0 , 'CSH' = 1 , 'CRE' = 2 , 'NOC' = 3 , 'DIS' = 4 )) ENGINE = ReplicatedMergeTree PARTITION BY toYYYYMM(pickup_date) ORDER BY pickup_datetime SETTINGS storage_policy = 'gcs_main' ┌─host───────────────────────────────────────┬─port─┬─status─┬─error─┬─num_hosts_remaining─┬─num_hosts_active─┐ │ chnode2.us-east4-c.c.gcsqa-375100.internal │ 9000 │ 0 │ │ 1 │ 1 │ └────────────────────────────────────────────┴──────┴────────┴───────┴─────────────────────┴──────────────────┘ ┌─host───────────────────────────────────────┬─port─┬─status─┬─error─┬─num_hosts_remaining─┬─num_hosts_active─┐ │ chnode1.us-east1-b.c.gcsqa-375100.internal │ 9000 │ 0 │ │ 0 │ 0 │ └────────────────────────────────────────────┴──────┴────────┴───────┴─────────────────────┴──────────────────┘ 2 rows in set. Elapsed: 0.641 sec.
INSERT INTO trips SELECT trip_id, pickup_date, pickup_datetime, dropoff_datetime, pickup_longitude, pickup_latitude, dropoff_longitude, dropoff_latitude, passenger_count, trip_distance, tip_amount, total_amount, payment_type FROM s3( 'https://ch-nyc-taxi.s3.eu-west-3.amazonaws.com/tsv/trips_{0..9}.tsv.gz' , 'TabSeparatedWithNames' ) LIMIT 1000000
テーブルでストレージポリシー gcs_main が使用されていることを確認します。 SELECT engine, data_paths, metadata_path, storage_policy, formatReadableSize(total_bytes) FROM system . tables WHERE name = 'trips' FORMAT Vertical
Row 1: ────── engine: ReplicatedMergeTree data_paths: ['/var/lib/clickhouse/disks/gcs/store/631/6315b109-d639-4214-a1e7-afbd98f39727/'] metadata_path: /var/lib/clickhouse/store/e0f/e0f3e248-7996-44d4-853e-0384e153b740/trips.sql storage_policy: gcs_main formatReadableSize(total_bytes): 36.42 MiB 1 row in set. Elapsed: 0.002 sec.
Google Cloud Console で確認する バケットを見ると、各バケットに storage.xml の設定ファイルで使用した名前のフォルダが作成されていることがわかります。フォルダを展開すると、データのパーティションを表す多数のファイルが表示されます。
