Integrar Google Cloud Storage con ClickHouse

MergeTree con respaldo en Google Cloud Storage (GCS)

Si usas ClickHouse Cloud en Google Cloud, esta página no aplica, ya que tus servicios ya usarán Google Cloud Storage. Si buscas hacer SELECT o INSERT de datos desde GCS, consulta la table function gcs.

ClickHouse reconoce que GCS es una solución de almacenamiento atractiva si buscas separar almacenamiento y cómputo. Para facilitarlo, se ofrece compatibilidad para usar GCS como almacenamiento de un motor MergeTree. Esto te permitirá aprovechar la escalabilidad y las ventajas de costo de GCS, así como el rendimiento de inserción y consulta del motor MergeTree.

​

MergeTree respaldado por GCS

​

Crear un disco

Para utilizar un bucket de GCS como disco, primero debemos declararlo en la configuración de ClickHouse, en un archivo dentro de conf.d. A continuación se muestra un ejemplo de declaración de un disco de GCS. Esta configuración incluye varias secciones para configurar el “disco” de GCS, la caché y la política que se especifica en las consultas DDL cuando se crean tablas en el disco de GCS. A continuación se describe cada una de ellas.

​

Configuración de almacenamiento > disks > gcs

Esta parte de la configuración se muestra en la sección resaltada y especifica lo siguiente:

• El tipo de disco es s3 porque se utiliza la API de S3.
• El endpoint proporcionado por GCS
• La clave HMAC y el secreto de la cuenta de servicio
• La ruta de metadatos en el disco local

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

​

Configuración de almacenamiento > disks > cache

La configuración de ejemplo destacada a continuación habilita una caché en memoria de 10 Gi para el disco gcs.

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

​

Configuración de almacenamiento > políticas > gcs_main

Las políticas de configuración de almacenamiento permiten elegir dónde se almacenan los datos. La política destacada a continuación permite almacenar datos en el disco gcs especificando la política gcs_main. Por ejemplo, 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>

Puede encontrar una lista completa de los ajustes pertinentes para esta definición de disco aquí.

​

Crear una tabla

Si ha configurado su disco para usar un bucket con acceso de escritura, debería poder crear una tabla como en el ejemplo siguiente. Para simplificar, usamos un subconjunto de las columnas de los taxis de NYC y enviamos los datos directamente a la tabla respaldada por 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;

Dependiendo del hardware, este último insert de 1m filas puede tardar unos minutos en ejecutarse. Puede confirmar el progreso en la tabla system.processes. Si quiere, puede ajustar el número de filas hasta el límite de 10m y probar algunas consultas de ejemplo.

SELECT passenger_count, avg(tip_amount) AS avg_tip, avg(total_amount) AS avg_amount FROM trips_gcs GROUP BY passenger_count;

​

Gestión de la replicación

La replicación con discos de GCS se puede lograr con el motor de tabla ReplicatedMergeTree. Consulta la guía replicación de un único segmento en dos regiones de GCP mediante GCS para obtener más información.

​

Más información

La API XML de Cloud Storage es compatible con algunas herramientas y bibliotecas que funcionan con servicios como Amazon Simple Storage Service (Amazon S3).

Para obtener más información sobre cómo ajustar los hilos, consulta Optimización del rendimiento.

​

Uso de Google Cloud Storage (GCS)

El almacenamiento de objetos se usa de forma predeterminada en ClickHouse Cloud; no es necesario seguir este procedimiento si ejecutas ClickHouse en ClickHouse Cloud.

​

Planificar la implementación

Este tutorial se ha escrito para describir una implementación replicada de ClickHouse que se ejecuta en Google Cloud y utiliza Google Cloud Storage (GCS) como “tipo” de disco de almacenamiento de ClickHouse.

En este tutorial, implementará nodos de servidor de ClickHouse en máquinas virtuales de Google Compute Engine, cada uno con un bucket de GCS asociado para el almacenamiento. La replicación la coordina un conjunto de nodos de ClickHouse Keeper, también implementados como máquinas virtuales.

Requisitos de ejemplo para alta disponibilidad:

• Dos nodos de servidor de ClickHouse, en dos regiones de GCP
• Dos buckets de GCS, implementados en las mismas regiones que los dos nodos de servidor de ClickHouse
• Tres nodos de ClickHouse Keeper; dos de ellos se implementan en las mismas regiones que los nodos de servidor de ClickHouse. El tercero puede estar en la misma región que uno de los dos primeros nodos de Keeper, pero en una zona de disponibilidad distinta.

ClickHouse Keeper requiere dos nodos para funcionar; de ahí la necesidad de tres nodos para alta disponibilidad.

​

Preparar máquinas virtuales

Implemente cinco VM en tres regiones:

Región	servidor de ClickHouse	Bucket	ClickHouse Keeper
1	chnode1	bucket_regionname	keepernode1
2	chnode2	bucket_regionname	keepernode2
3 *			keepernode3

* Puede ser una zona de disponibilidad distinta en la misma región que la 1 o la 2.

​

Desplegar ClickHouse

Despliegue ClickHouse en dos hosts; en las configuraciones de ejemplo, se llaman chnode1 y chnode2.

Ubique chnode1 en una región de GCP y chnode2 en otra. En esta guía se utilizan us-east1 y us-east4 para las VM de Compute Engine y también para los buckets de GCS.

No inicie clickhouse server hasta haberlo configurado. Limítese a instalarlo.

Consulte las instrucciones de instalación al realizar los pasos de despliegue en los nodos del servidor de ClickHouse.

​

Implemente ClickHouse Keeper

Implemente ClickHouse Keeper en tres hosts; en las configuraciones de ejemplo, estos se denominan keepernode1, keepernode2 y keepernode3. keepernode1 puede implementarse en la misma región que chnode1, keepernode2 junto con chnode2 y keepernode3 en cualquiera de las dos regiones, pero en una zona de disponibilidad distinta a la del nodo de ClickHouse de esa región.

Consulte las instrucciones de instalación al realizar los pasos de implementación en los nodos de ClickHouse Keeper.

​

Crear dos buckets

Los dos servidores de ClickHouse estarán ubicados en distintas regiones para garantizar alta disponibilidad. Cada uno tendrá un bucket de GCS en la misma región.

En Cloud Storage > Buckets, elija CREATE BUCKET. Para este tutorial, se crean dos buckets: uno en us-east1 y otro en us-east4. Los buckets son de región única, de clase de almacenamiento estándar y no son públicos. Cuando se le solicite, habilite la prevención de acceso público. No cree carpetas; se crearán cuando ClickHouse escriba en el almacenamiento.

Si necesita instrucciones paso a paso para crear buckets y una clave HMAC, expanda Create GCS buckets and an HMAC key y siga el procedimiento:

Crear buckets de GCS y una clave HMAC

​

ch_bucket_us_east1

​

ch_bucket_us_east4

​

Generar una clave de acceso

​

Crear una clave HMAC y un secreto para una cuenta de servicio

Abra Cloud Storage > Settings > Interoperability y elija una Access key existente o CREATE A KEY FOR A SERVICE ACCOUNT. Esta guía describe el proceso para crear una clave nueva para una cuenta de servicio nueva.

​

Agregar una nueva cuenta de servicio

Si este proyecto no tiene ninguna cuenta de servicio existente, haga clic en CREATE NEW ACCOUNT.

La creación de la cuenta de servicio consta de tres pasos; en el primero, asigne a la cuenta un nombre, un ID y una descripción significativos.

En el cuadro de diálogo de configuración de Interoperability, se recomienda el rol de IAM Storage Object Admin; selecciónelo en el segundo paso.

El tercer paso es opcional y no se utiliza en esta guía. Puede permitir que los usuarios tengan estos privilegios según sus políticas.

Se mostrará la clave HMAC de la cuenta de servicio. Guarde esta información, ya que se utilizará en la configuración de ClickHouse.

​

Configurar ClickHouse Keeper

Todos los nodos de ClickHouse Keeper tienen el mismo archivo de configuración, excepto la línea server_id (la primera línea resaltada a continuación). Modifique el archivo con los nombres de host de sus servidores de ClickHouse Keeper y, en cada uno de ellos, configure server_id para que coincida con la entrada server correspondiente en raft_configuration. Dado que en este ejemplo server_id está establecido en 3, hemos resaltado las líneas correspondientes en raft_configuration.

• Edite el archivo con sus nombres de host y asegúrese de que se resuelvan desde los nodos del servidor de ClickHouse y los nodos de Keeper
• Copie el archivo en la ubicación correspondiente (/etc/clickhouse-keeper/keeper_config.xml en cada uno de los servidores de Keeper
• Edite el server_id en cada máquina según el número de su entrada en raft_configuration

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

​

Configurar el servidor de ClickHouse

práctica recomendada

En algunos pasos de esta guía, se le pedirá que coloque un archivo de configuración en /etc/clickhouse-server/config.d/. Esta es la ubicación predeterminada en los sistemas Linux para los archivos de sobrescritura de configuración. Cuando coloque estos archivos en ese directorio, ClickHouse fusionará su contenido con la configuración predeterminada. Al colocarlos en el directorio config.d, evitará perder la configuración durante una actualización.

​

Redes

De forma predeterminada, ClickHouse escucha en la interfaz de bucle local; en una configuración replicada, es necesario disponer de conectividad de red entre las máquinas. Escuche en todas las interfaces:

/etc/clickhouse-server/config.d/network.xml

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

​

Servidores remotos de ClickHouse Keeper

La replicación se coordina mediante ClickHouse Keeper. Este archivo de configuración identifica los nodos de ClickHouse Keeper por nombre de host y número de puerto.

• Modifica los nombres de host para que coincidan con tus servidores 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>

​

Servidores remotos de ClickHouse

Este archivo configura el hostname y el puerto de cada servidor de ClickHouse en el clúster. El archivo de configuración predeterminado contiene definiciones de clúster de ejemplo; para mostrar solo los clústeres que estén completamente configurados, se añade el atributo replace="true" a la entrada remote_servers para que, cuando esta configuración se fusione con la predeterminada, reemplace la sección remote_servers en lugar de añadirse a ella.

• Edite el archivo con sus nombres de host y asegúrese de que se resuelvan desde los nodos del servidor de 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>

​

Identificación de la réplica

Este archivo configura ajustes relacionados con la ruta de ClickHouse Keeper. En concreto, las macros que se usan para identificar a qué réplica pertenecen los datos. En un servidor, la réplica debe especificarse como replica_1, y en el otro servidor como replica_2. Los nombres pueden cambiarse; siguiendo nuestro ejemplo de una réplica almacenada en Carolina del Sur y la otra en el norte de Virginia, los valores podrían ser carolina y virginia; solo asegúrese de que sean diferentes en cada máquina.

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

​

Almacenamiento en GCS

La configuración de almacenamiento de ClickHouse incluye disks y policies. El disco que se configura a continuación se llama gcs y es de type s3. El tipo es s3 porque ClickHouse accede al bucket de GCS como si fuera un bucket de AWS S3. Se necesitarán dos copias de esta configuración, una para cada uno de los nodos del servidor de ClickHouse.

Estas sustituciones deben realizarse en la configuración siguiente.

Estas sustituciones difieren entre los dos nodos del servidor de ClickHouse:

• REPLICA 1 BUCKET debe establecerse con el nombre del bucket en la misma región que el servidor
• REPLICA 1 FOLDER debe cambiarse a replica_1 en uno de los servidores y a replica_2 en el otro

Estas sustituciones son comunes a ambos nodos:

• access_key_id debe establecerse con la clave HMAC generada anteriormente
• secret_access_key debe establecerse con el secreto HMAC generado anteriormente

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

​

Iniciar ClickHouse Keeper

Utilice los comandos correspondientes a su sistema operativo; por ejemplo:

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

​

Comprobar el estado de ClickHouse Keeper

Envíe comandos a ClickHouse Keeper con netcat. Por ejemplo, mntr devuelve el estado del clúster de ClickHouse Keeper. Si ejecuta el comando en cada uno de los nodos de ClickHouse Keeper, verá que uno es el líder y los otros dos son seguidores:

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

​

Iniciar el servidor de ClickHouse

En chnode1 y chnode, ejecute:

sudo service clickhouse-server start

sudo service clickhouse-server status

​

Verificación

​

Verifique la configuración del disco

system.disks debe contener registros para cada disco:

• default
• gcs
• cache

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.

​

Verifique que las tablas creadas en el clúster se hayan creado en ambos nodos

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.

​

Verifique que se puedan insertar datos

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

​

Verifique que la política de almacenamiento gcs_main se utilice para la tabla.

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.

​

Verificar en la Consola de Google Cloud

Al examinar los buckets, verá que se creó una carpeta en cada bucket con el nombre usado en el archivo de configuración storage.xml. Expanda las carpetas y verá muchos archivos que representan las particiones de datos.

​

Bucket de la réplica 1

​

Bucket para la réplica dos