> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-mintlify-fbfa8bee.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
> MergeTree con respaldo en Google Cloud Storage (GCS)
# Integrar Google Cloud Storage con ClickHouse
export const Image = ({img, alt, size}) => {
return
;
};
Si usas ClickHouse Cloud en [Google Cloud](https://cloud.google.com), esta página no aplica, ya que tus servicios ya usarán [Google Cloud Storage](https://cloud.google.com/storage). Si buscas hacer `SELECT` o `INSERT` de datos desde GCS, consulta la [table function `gcs`](/es/reference/functions/table-functions/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
```xml highlight={5-10} theme={null}
true
s3
https://storage.googleapis.com/BUCKET NAME/FOLDER NAME/
SERVICE ACCOUNT HMAC KEY
SERVICE ACCOUNT HMAC SECRET
/var/lib/clickhouse/disks/gcs/
gcs
```
#### 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`.
```xml highlight={12-17} theme={null}
true
s3
https://storage.googleapis.com/BUCKET NAME/FOLDER NAME/
SERVICE ACCOUNT HMAC KEY
SERVICE ACCOUNT HMAC SECRET
/var/lib/clickhouse/disks/gcs/
cache
gcs
/var/lib/clickhouse/disks/gcs_cache/
10Gi
gcs_cache
```
#### 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'`.
```xml highlight={14-20} theme={null}
true
s3
https://storage.googleapis.com/BUCKET NAME/FOLDER NAME/
SERVICE ACCOUNT HMAC KEY
SERVICE ACCOUNT HMAC SECRET
/var/lib/clickhouse/disks/gcs/
gcs
```
Puede encontrar una lista completa de los ajustes pertinentes para esta definición de disco [aquí](/es/reference/engines/table-engines/mergetree-family/mergetree#table_engine-mergetree-s3).
### 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:
```sql highlight={20} theme={null}
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'
```
```sql theme={null}
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.
```sql theme={null}
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](#gcs-multi-region) para obtener más información.
### Más información
La [API XML de Cloud Storage](https://cloud.google.com/storage/docs/xml-api/overview) 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](/es/integrations/connectors/data-ingestion/AWS/integrating-s3-with-clickhouse#s3-optimizing-performance).
## 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](/es/get-started/setup/install) 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](/es/get-started/setup/install) 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:
### 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`
```xml title=/etc/clickhouse-keeper/keeper_config.xml highlight={12,33-37} theme={null}
trace
/var/log/clickhouse-keeper/clickhouse-keeper.log
/var/log/clickhouse-keeper/clickhouse-keeper.err.log
1000M
3
0.0.0.0
9181
3
/var/lib/clickhouse/coordination/log
/var/lib/clickhouse/coordination/snapshots
10000
30000
warning
1
keepernode1.us-east1-b.c.clickhousegcs-374921.internal
9234
2
keepernode2.us-east4-c.c.clickhousegcs-374921.internal
9234
3
keepernode3.us-east5-a.c.clickhousegcs-374921.internal
9234
```
### 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:
```xml title=/etc/clickhouse-server/config.d/network.xml theme={null}
0.0.0.0
```
#### 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
```xml title=/etc/clickhouse-server/config.d/use-keeper.xml theme={null}
keepernode1.us-east1-b.c.clickhousegcs-374921.internal
9181
keepernode2.us-east4-c.c.clickhousegcs-374921.internal
9181
keepernode3.us-east5-a.c.clickhousegcs-374921.internal
9181
```
#### 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
```xml title=/etc/clickhouse-server/config.d/remote-servers.xml theme={null}
chnode1.us-east1-b.c.clickhousegcs-374921.internal
9000
chnode2.us-east4-c.c.clickhousegcs-374921.internal
9000
```
#### 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.
```xml title=/etc/clickhouse-server/config.d/macros.xml highlight={8} theme={null}
/clickhouse/task_queue/ddl
cluster_1S_2R
1
replica_1
```
#### 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
```xml title=/etc/clickhouse-server/config.d/storage.xml theme={null}
true
s3
https://storage.googleapis.com/REPLICA 1 BUCKET/REPLICA 1 FOLDER/
SERVICE ACCOUNT HMAC KEY
SERVICE ACCOUNT HMAC SECRET
/var/lib/clickhouse/disks/gcs/
cache
gcs
/var/lib/clickhouse/disks/gcs_cache/
10Gi
gcs
```
### Iniciar ClickHouse Keeper
Utilice los comandos correspondientes a su sistema operativo; por ejemplo:
```bash theme={null}
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:
```bash theme={null}
echo mntr | nc localhost 9181
```
```response highlight={7-9,18-19} theme={null}
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:
```bash theme={null}
sudo service clickhouse-server start
```
```bash theme={null}
sudo service clickhouse-server status
```
### Verificación
#### Verifique la configuración del disco
`system.disks` debe contener registros para cada disco:
* default
* gcs
* cache
```sql theme={null}
SELECT *
FROM system.disks
FORMAT Vertical
```
```response theme={null}
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
```sql highlight={1,18} theme={null}
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'
```
```response theme={null}
┌─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
```sql theme={null}
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.
```sql theme={null}
SELECT
engine,
data_paths,
metadata_path,
storage_policy,
formatReadableSize(total_bytes)
FROM system.tables
WHERE name = 'trips'
FORMAT Vertical
```
```response theme={null}
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