Google Cloud Storage를 ClickHouse에 통합하기

ClickHouse는 스토리지와 컴퓨트를 분리하려는 경우 GCS가 매력적인 스토리지 솔루션이 될 수 있음을 인지하고 있습니다. 이를 지원하기 위해 MergeTree 엔진의 스토리지로 GCS를 사용할 수 있도록 지원합니다. 이를 통해 GCS의 확장성과 비용상 이점을 활용하는 동시에 MergeTree 엔진의 삽입 및 쿼리 성능도 활용할 수 있습니다.

GCS 기반 MergeTree

디스크 생성

GCS 버킷을 디스크로 사용하려면 먼저 conf.d 아래의 파일에 있는 ClickHouse 구성에서 이를 선언해야 합니다. 아래는 GCS 디스크 선언 예시입니다. 이 구성에는 GCS "디스크", 캐시, 그리고 GCS 디스크에 테이블(table)을 생성할 때 DDL 쿼리에서 지정할 정책을 설정하는 여러 섹션이 포함되어 있습니다. 각 섹션은 아래에서 설명합니다.

스토리지 구성 > disks > gcs

이 구성 부분은 강조 표시된 섹션에 나와 있으며, 다음을 지정합니다.

디스크 유형은 S3 API를 사용하므로 s3입니다.
GCS에서 제공하는 endpoint
서비스 계정 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>

스토리지 구성 > disks > 캐시

아래 강조 표시된 예시 구성은 디스크 gcs에 10Gi 메모리 캐시를 활성화합니다.

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

스토리지 구성 > 정책 > 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 taxi 컬럼 일부만 사용하고, 데이터를 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', NOSIGN, 'TabSeparatedWithNames') LIMIT 1000000;

하드웨어에 따라 이 마지막 100만 행 삽입 작업은 완료하는 데 몇 분 정도 걸릴 수 있습니다. 진행 상황은 system.processes 테이블(table)에서 확인할 수 있습니다. 행 수는 최대 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를 사용해 두 GCP 리전에서 단일 세그먼트를 복제하는 방법 가이드를 참조하십시오.

자세히 알아보기

Cloud Storage XML API는 Amazon Simple Storage Service(Amazon S3)와 같은 서비스에서 사용하는 일부 도구 및 라이브러리와 호환됩니다.

스레드 조정에 대한 자세한 내용은 성능 최적화를 참조하십시오.

Google Cloud Storage (GCS) 사용

배포 계획

이 튜토리얼은 Google Cloud에서 실행되고, ClickHouse 스토리지 디스크 "type"으로 Google Cloud Storage(GCS)를 사용하는 복제된 ClickHouse 배포를 설명합니다.

이 튜토리얼에서는 각 노드에 스토리지용 GCS 버킷이 연결된 Google Cloud Engine VM에 ClickHouse 서버 노드를 배포합니다. 복제는 역시 VM으로 배포된 ClickHouse Keeper 노드 집합이 조정합니다.

고가용성을 위한 예시 요구 사항:

2개의 GCP 리전에 각각 배포된 2개의 ClickHouse 서버 노드
두 ClickHouse 서버 노드와 동일한 리전에 배포된 2개의 GCS 버킷
3개의 ClickHouse Keeper 노드. 이 중 2개는 ClickHouse 서버 노드와 동일한 리전에 배포됩니다. 세 번째 노드는 첫 두 Keeper 노드 중 하나와 동일한 리전에 둘 수 있지만, 가용 영역은 달라야 합니다.

ClickHouse Keeper가 작동하려면 최소 2개의 노드가 필요하므로, 고가용성을 위해서는 3개의 노드가 필요합니다.

가상 머신 준비

3개의 리전에 VM 5대를 배포합니다:

리전	ClickHouse 서버	버킷	ClickHouse Keeper
1	`chnode1`	`bucket_regionname`	`keepernode1`
2	`chnode2`	`bucket_regionname`	`keepernode2`
3 `*`			`keepernode3`

* 이는 1 또는 2와 동일한 리전 내의 다른 가용 영역일 수 있습니다.

ClickHouse 배포

두 개의 호스트에 ClickHouse를 배포합니다. 이 샘플 구성에서는 호스트 이름을 chnode1, chnode2로 사용합니다.

chnode1은 한 GCP 리전에, chnode2는 다른 리전에 배치합니다. 이 가이드에서는 Compute Engine VM과 GCS 버킷에 us-east1 및 us-east4를 사용합니다.

ClickHouse 서버 노드에서 배포 단계를 수행할 때는 설치 지침을 참조하십시오.

ClickHouse Keeper 배포

3개의 호스트에 ClickHouse Keeper를 배포합니다. 샘플 구성에서는 이 호스트의 이름을 keepernode1, keepernode2, keepernode3로 사용합니다. keepernode1은 chnode1과 동일한 리전에, keepernode2는 chnode2와 동일한 리전에 배포할 수 있습니다. keepernode3는 두 리전 중 어느 곳에든 배포할 수 있지만, 해당 리전의 ClickHouse 노드와는 서로 다른 가용 영역에 배포해야 합니다.

ClickHouse Keeper 노드에서 배포 단계를 수행할 때는 설치 지침을 참조하십시오.

버킷 두 개 만들기

고가용성을 위해 두 ClickHouse 서버는 서로 다른 리전에 배치됩니다. 각 서버에는 동일한 리전에 GCS 버킷이 하나씩 있어야 합니다.

Cloud Storage > Buckets에서 CREATE BUCKET을 선택하십시오. 이 튜토리얼에서는 us-east1과 us-east4에 각각 하나씩, 총 2개의 버킷을 만듭니다. 버킷은 단일 리전, Standard 스토리지 클래스, 비공개로 설정합니다. 메시지가 표시되면 public access prevention을 활성화하십시오. 폴더는 만들지 마십시오. ClickHouse가 스토리지에 쓸 때 자동으로 생성됩니다.

버킷과 HMAC 키를 만드는 단계별 안내가 필요하면 Create GCS buckets and an HMAC key를 펼쳐 따라 하십시오:

GCS 버킷 및 HMAC 키 생성

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 settings 대화상자에서는 IAM role Storage Object Admin을 권장합니다. 두 번째 단계에서 해당 role을 선택합니다.

세 번째 단계는 선택 사항이며, 이 가이드에서는 사용하지 않습니다. 정책에 따라 사용자에게 이러한 권한을 부여할 수 있습니다.

서비스 계정 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>
    <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>

ClickHouse 서버 구성

네트워킹

기본적으로 ClickHouse는 루프백 인터페이스에서만 수신 대기합니다. 복제된 구성에서는 서버 간 네트워킹이 필요합니다. 모든 인터페이스에서 수신 대기하도록 설정하십시오:

<clickhouse>
    <listen_host>0.0.0.0</listen_host>
</clickhouse>

원격 ClickHouse Keeper 서버

복제는 ClickHouse Keeper가 조정합니다. 이 설정 파일은 호스트명과 포트 번호를 사용해 ClickHouse Keeper 노드를 식별합니다.

호스트명을 Keeper 호스트에 맞게 수정하세요

<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 서버

이 파일은 클러스터에 있는 각 ClickHouse 서버의 호스트명과 포트를 설정합니다. 기본 설정 파일에는 예시 클러스터 정의가 포함되어 있으므로, 완전히 구성된 클러스터만 표시하려면 remote_servers 항목에 replace="true" 태그를 추가합니다. 이렇게 하면 이 구성이 기본 구성과 머지될 때 remote_servers 섹션에 내용을 추가하지 않고 해당 섹션을 대체합니다.

파일에서 호스트명을 알맞게 수정하고, 해당 호스트명이 ClickHouse 서버 노드에서 이름 해석되는지 확인하세요

<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 경로와 관련된 설정을 구성합니다. 구체적으로는 데이터가 어느 레플리카에 속하는지 식별하는 데 사용되는 매크로를 설정합니다. 한 server에서는 레플리카를 replica_1로 지정하고, 다른 server에서는 replica_2로 지정해야 합니다. 이름은 변경할 수 있습니다. 예를 들어 한 레플리카가 South Carolina에 저장되고 다른 레플리카가 Northern Virginia에 저장되는 경우, 값은 carolina와 virginia로 지정할 수 있습니다. 각 머신에서 서로 다른 값만 사용하도록 하십시오.

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

GCS 스토리지

ClickHouse 스토리지 구성에는 disks와 policies가 포함됩니다. 아래에서 구성하는 디스크의 이름은 gcs이고, type은 s3입니다. type이 s3인 이유는 ClickHouse가 GCS 버킷을 AWS S3 버킷처럼 액세스하기 때문입니다. 이 구성은 각 ClickHouse 서버 노드에 하나씩, 총 2개가 필요합니다.

아래 구성에서는 다음 치환값을 적용해야 합니다.

다음 치환값은 두 ClickHouse 서버 노드마다 서로 다릅니다.

REPLICA 1 BUCKET은 서버와 동일한 리전(Region)에 있는 버킷 이름으로 설정해야 합니다
REPLICA 1 FOLDER는 한 서버에서는 replica_1로, 다른 서버에서는 replica_2로 변경해야 합니다

다음 치환값은 두 노드에 공통으로 적용됩니다.

access_key_id는 앞서 생성한 HMAC Key로 설정해야 합니다
secret_access_key는 앞서 생성한 HMAC Secret으로 설정해야 합니다

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

ClickHouse Keeper 시작

예를 들어, 사용 중인 운영 체제에 맞는 다음 명령을 사용하십시오:

sudo systemctl enable clickhouse-keeper
sudo systemctl start clickhouse-keeper
sudo systemctl status clickhouse-keeper

ClickHouse Keeper 상태 확인

netcat을 사용해 ClickHouse Keeper에 명령을 전송합니다. 예를 들어 mntr 명령은 ClickHouse Keeper 클러스터의 상태를 반환합니다. 각 Keeper 노드에서 이 명령을 실행하면 하나는 리더이고 나머지 두 개는 팔로워임을 확인할 수 있습니다:

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

ClickHouse 서버 시작

chnode1 및 chnode에서 다음을 실행하세요:

sudo service clickhouse-server start

sudo service clickhouse-server status

확인

디스크 구성을 확인하세요

system.disks에는 각 디스크에 대한 레코드가 있어야 합니다.

default
gcs
cache

SELECT *
FROM system.disks
FORMAT Vertical

행 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/

행 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:

행 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', NOSIGN, '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 콘솔에서 확인

버킷을 보면 storage.xml 설정 파일에서 사용한 이름의 폴더가 각 버킷에 생성된 것을 확인할 수 있습니다. 폴더를 펼치면 데이터 파티션을 나타내는 여러 파일이 표시됩니다.

레플리카 1용 버킷

레플리카 2용 버킷

데이터 파티션이 있는 폴더 구조를 보여주는 Google Cloud Storage의 레플리카 2 버킷