Skip to main content
Puede insertar datos de S3 en ClickHouse y también usar S3 como destino de exportación, lo que permite interactuar con arquitecturas de “lago de datos”. Además, S3 puede proporcionar niveles de almacenamiento “en frío” y ayudar a separar el almacenamiento del cómputo. En las secciones siguientes, usamos el conjunto de datos de taxis de la ciudad de Nueva York para mostrar el proceso de transferir datos entre S3 y ClickHouse, así como identificar parámetros clave de configuración y ofrecer sugerencias para optimizar el rendimiento.

Funciones de tabla S3

La función de tabla s3 permite leer y escribir archivos en almacenamiento compatible con S3. La sintaxis general es la siguiente:
donde:
  • path — URL del bucket con la ruta al archivo. Admite los siguientes comodines en modo de solo lectura: *, ?, {abc,def} y {N..M}, donde N y M son números, y 'abc' y 'def' son cadenas. Para más información, consulta la documentación sobre el uso de comodines en la ruta.
  • format — El formato del archivo.
  • structure — Estructura de la tabla. Formato: 'column1_name column1_type, column2_name column2_type, ...'.
  • compression — El parámetro es opcional. Valores admitidos: none, gzip/gz, brotli/br, xz/LZMA, zstd/zst. De forma predeterminada, la compresión se detecta automáticamente según la extensión del archivo.
El uso de comodines en la expresión de ruta permite hacer referencia a varios archivos y posibilita el paralelismo.

Preparación

Antes de crear la tabla en ClickHouse, quizá quieras echar un vistazo más de cerca a los datos del bucket de S3. Puedes hacerlo directamente desde ClickHouse con la sentencia DESCRIBE:
La salida de la sentencia DESCRIBE TABLE debería mostrarte cómo ClickHouse inferiría automáticamente estos datos al verlos en el bucket de S3. Observa que también reconoce y descomprime automáticamente el formato de compresión gzip:
Para interactuar con nuestro conjunto de datos basado en S3, preparamos una tabla MergeTree estándar como destino. La siguiente sentencia crea una tabla llamada trips en la base de datos predeterminada. Tenga en cuenta que hemos optado por modificar algunos de esos tipos de datos, tal como se dedujo anteriormente, en particular para no usar el modificador de tipo de dato Nullable(), ya que podría generar datos almacenados adicionales innecesarios y cierta sobrecarga de rendimiento:
Observe el uso del particionado en el campo pickup_date. Normalmente, una clave de partición se utiliza para la gestión de datos, pero más adelante usaremos esta clave para paralelizar las escrituras en S3. Cada registro de nuestro conjunto de datos de taxis contiene un trayecto en taxi. Estos datos anonimizados constan de 20 M de registros comprimidos en el bucket de S3 https://datasets-documentation.s3.eu-west-3.amazonaws.com/, dentro de la carpeta nyc-taxi. Los datos están en formato TSV, con aproximadamente 1 M de filas por archivo.

Lectura de datos desde S3

Podemos consultar datos de S3 como origen sin necesidad de persistirlos en ClickHouse. En la siguiente consulta, tomamos una muestra de 10 filas. Tenga en cuenta que aquí no se incluyen credenciales, ya que el bucket es de acceso público:
Ten en cuenta que no es necesario especificar las columnas, ya que el formato TabSeparatedWithNames codifica los nombres de las columnas en la primera fila. Otros formatos, como CSV o TSV, devolverán columnas generadas automáticamente para esta consulta, p. ej., c1, c2, c3, etc. Las consultas también admiten columnas virtuales, como _path y _file, que proporcionan información sobre la ruta del bucket y el nombre del archivo, respectivamente. Por ejemplo:
Confirme el número de filas de este conjunto de datos de muestra. Tenga en cuenta el uso de comodines para expandir archivos, de modo que se tengan en cuenta los veinte archivos. Esta consulta tardará unos 10 segundos, según el número de núcleos de la instancia de ClickHouse:
Aunque resulta útil para el muestreo de datos y para ejecutar consultas exploratorias ad hoc, leer datos directamente de S3 no es algo que convenga hacer con regularidad. Cuando llegue el momento de tomárselo en serio, importa los datos a una tabla MergeTree en ClickHouse.

Uso de clickhouse-local

El programa clickhouse-local le permite procesar archivos locales rápidamente sin implementar ni configurar el servidor ClickHouse. Cualquier consulta que use la función de tabla s3 puede ejecutarse con esta utilidad. Por ejemplo:

Inserción de datos desde S3

Para aprovechar al máximo las capacidades de ClickHouse, a continuación leeremos e insertaremos los datos en nuestra instancia. Combinamos la función s3 con una sencilla sentencia INSERT para lograrlo. Tenga en cuenta que no es necesario enumerar las columnas, porque la tabla de destino proporciona la estructura requerida. Para ello, las columnas deben aparecer en el orden especificado en la sentencia DDL de la tabla: las columnas se asignan según su posición en la cláusula SELECT. La inserción de los 10 millones de filas puede tardar unos minutos, según la instancia de ClickHouse. A continuación, insertamos 1 millón de filas para garantizar una respuesta rápida. Ajuste la cláusula LIMIT o la selección de columnas para importar subconjuntos según sea necesario:

Inserción remota con ClickHouse Local

Si las políticas de seguridad de red impiden que su clúster de ClickHouse realice conexiones salientes, es posible insertar datos de S3 mediante clickhouse-local. En el ejemplo siguiente, leemos desde un bucket de S3 e insertamos los datos en ClickHouse con la función remote:
Para ejecutar esto a través de una conexión SSL segura, utilice la función remoteSecure.

Exportación de datos

Puede escribir archivos en S3 mediante la función de tabla s3. Para ello, necesitará los permisos adecuados. Incluimos las credenciales necesarias en la solicitud, pero consulte la página Gestión de credenciales para ver más opciones. En el sencillo ejemplo siguiente, usamos la función de tabla como destino en lugar de como origen. Aquí enviamos 10,000 filas de la tabla trips a un bucket, especificando compresión lz4 y el tipo de salida CSV:
Observe aquí cómo el formato del archivo se deduce de la extensión. Tampoco es necesario especificar las columnas en la función s3; esto puede deducirse de SELECT.

Dividir archivos grandes

Es poco probable que quieras exportar tus datos a un único archivo. La mayoría de las herramientas, incluido ClickHouse, obtienen un mayor rendimiento al leer y escribir en varios archivos gracias a la posibilidad de procesarlos en paralelo. Podríamos ejecutar nuestro comando INSERT varias veces, cada una sobre un subconjunto de los datos. ClickHouse ofrece una forma de dividir archivos automáticamente mediante una clave PARTITION. En el ejemplo siguiente, creamos diez archivos usando un módulo de la función rand(). Observa cómo el ID de partición resultante se incluye en el nombre del archivo. El resultado son diez archivos con un sufijo numérico, p. ej., trips_0.csv.lz4, trips_1.csv.lz4, etc.:
Como alternativa, podemos hacer referencia a un campo en los datos. Para este conjunto de datos, payment_type proporciona una clave de particionado natural con una cardinalidad de 5.

Uso de clústeres

Las funciones anteriores están limitadas a ejecutarse en un solo nodo. Las velocidades de lectura escalarán linealmente con los núcleos de CPU hasta que se saturen otros recursos (normalmente, la red), lo que permite a los usuarios escalar verticalmente. Sin embargo, este enfoque tiene sus limitaciones. Aunque puede aliviar parte de la presión sobre los recursos insertando en una tabla distribuida al realizar una consulta INSERT INTO SELECT, esto sigue dejando a un solo nodo a cargo de leer, analizar y procesar los datos. Para abordar este desafío y poder escalar las lecturas horizontalmente, contamos con la función s3Cluster. El nodo que recibe la consulta, conocido como iniciador, crea una conexión con cada nodo del clúster. El patrón glob que determina qué archivos deben leerse se resuelve como un conjunto de archivos. El iniciador distribuye los archivos entre los nodos del clúster, que actúan como workers. Estos workers, a su vez, solicitan archivos para procesarlos a medida que completan las lecturas. Este proceso garantiza que podamos escalar las lecturas horizontalmente. La función s3Cluster tiene el mismo formato que las variantes de un solo nodo, salvo que requiere un clúster de destino para indicar los nodos worker:
  • cluster_name — Nombre de un clúster que se utiliza para construir un conjunto de direcciones y parámetros de conexión a servidores remotos y locales.
  • source — URL a un archivo o a un conjunto de archivos. Admite los siguientes comodines en modo de solo lectura: *, ?, {'abc','def'} y {N..M}, donde N, M — números; abc, def — cadenas. Para obtener más información, consulte Wildcards In Path.
  • access_key_id y secret_access_key — Claves que especifican las credenciales que se usarán con el endpoint indicado. Opcional.
  • format — El formato del archivo.
  • structure — Estructura de la tabla. Formato ‘column1_name column1_type, column2_name column2_type, …’.
Como con cualquier función s3, las credenciales son opcionales si el bucket es inseguro o si define la seguridad mediante el entorno, por ejemplo, con roles de IAM. Sin embargo, a diferencia de la función s3, la estructura debe especificarse en la solicitud a partir de la versión 22.3.1; es decir, el esquema no se infiere. Esta función se utilizará como parte de un INSERT INTO SELECT en la mayoría de los casos. En este caso, a menudo insertará en una tabla distribuida. A continuación, mostramos un ejemplo sencillo en el que trips_all es una tabla distribuida. Aunque esta tabla utiliza el clúster events, la coherencia de los nodos utilizados para lecturas y escrituras no es un requisito:
Las inserciones se realizarán en el nodo iniciador. Esto significa que, aunque las lecturas se realizarán en cada nodo, las filas resultantes se enviarán al iniciador para su distribución. En escenarios de alto volumen, esto puede convertirse en un cuello de botella. Para solucionarlo, establezca el parámetro parallel_distributed_insert_select para la función s3cluster.

Motores de tabla de S3

Aunque las funciones s3 permiten realizar consultas ad hoc sobre datos almacenados en S3, su sintaxis es verbosa. El motor de tabla S3 evita tener que especificar la URL del bucket y las credenciales una y otra vez. Para ello, ClickHouse proporciona el motor de tabla S3.
  • path — URL del bucket con la ruta del archivo. Admite los siguientes comodines en modo de solo lectura: *, ?, {abc,def} y {N..M}, donde N y M son números, y ‘abc’ y ‘def’ son cadenas. Para más información, consulte aquí.
  • format — El formato del archivo.
  • aws_access_key_id, aws_secret_access_key - Credenciales de larga duración para el usuario de la cuenta de AWS. Puede usarlas para autenticar sus solicitudes. El parámetro es opcional. Si no se especifican credenciales, se usan los valores del archivo de configuración. Para más información, consulte Gestión de credenciales.
  • compression — Tipo de compresión. Valores admitidos: none, gzip/gz, brotli/br, xz/LZMA, zstd/zst. El parámetro es opcional. De forma predeterminada, la compresión se detecta automáticamente según la extensión del archivo.

Lectura de datos

En el siguiente ejemplo, creamos una tabla llamada trips_raw con los primeros diez archivos TSV ubicados en el bucket https://datasets-documentation.s3.eu-west-3.amazonaws.com/nyc-taxi/. Cada uno de ellos contiene 1 millón de filas:
Observe el uso del patrón {0..9} para limitar la selección a los diez primeros archivos. Una vez creada, podemos consultar esta tabla como cualquier otra:

Inserción de datos

El motor de tabla S3 admite lecturas en paralelo. Las escrituras solo se admiten si la definición de la tabla no contiene patrones glob. Por tanto, la tabla anterior bloquearía las escrituras. Para ilustrar las escrituras, cree una tabla que apunte a un bucket de S3 con permisos de escritura:
Tenga en cuenta que las filas solo se pueden insertar en archivos nuevos. No hay ciclos de merge ni operaciones de división de archivos. Una vez que se escribe un archivo, los inserts posteriores fallarán. Los usuarios tienen dos opciones aquí:
  • Especifique la configuración s3_create_new_file_on_insert=1. Esto hará que se creen archivos nuevos en cada insert. Se añadirá un sufijo numérico al final de cada archivo, que aumentará de forma monótona con cada operación de insert. En el ejemplo anterior, un insert posterior provocaría la creación de un archivo trips_1.bin.
  • Especifique la configuración s3_truncate_on_insert=1. Esto hará que el archivo se trunque; es decir, una vez completado, solo contendrá las filas recién insertadas.
Ambas configuraciones tienen el valor predeterminado 0, lo que obliga al usuario a establecer una de ellas. s3_truncate_on_insert tendrá prioridad si ambas están configuradas. Algunas notas sobre el motor de tabla S3:
  • A diferencia de una tabla tradicional de la familia MergeTree, eliminar una tabla S3 no borrará los datos subyacentes.
  • La configuración completa para este tipo de tabla se puede encontrar aquí.
  • Tenga en cuenta las siguientes limitaciones al usar este motor:
    • Las consultas ALTER no son compatibles
    • Las operaciones SAMPLE no son compatibles
    • No existe el concepto de índices, es decir, primarios o de omisión.

Gestión de credenciales

En los ejemplos anteriores, hemos pasado las credenciales en la función s3 o en la definición de la tabla S3. Aunque esto puede ser aceptable para un uso ocasional, en producción se necesitan mecanismos de authentication menos explícitos. Para ello, ClickHouse ofrece varias opciones:
  • Especifique los detalles de connection en config.xml o en un configuration file equivalente dentro de conf.d. A continuación se muestra el contenido de un archivo de ejemplo, suponiendo una instalación mediante el paquete de Debian.
    Estas credenciales se usarán en cualquier solicitud en la que el endpoint anterior coincida exactamente, como prefijo, con la URL solicitada. Observe también que, en este ejemplo, se puede declarar un header de autorización como alternativa a las claves de acceso y secretas. Puede consultar una lista completa de los Settings admitidos aquí.
  • El ejemplo anterior destaca la disponibilidad del parámetro de configuration use_environment_credentials. Este parámetro de configuration también puede establecerse globalmente en el nivel s3:
    Esta configuración activa el intento de obtener credenciales de S3 desde el entorno, lo que permite el acceso mediante IAM roles. En concreto, se sigue el siguiente orden de obtención:
    • Búsqueda de las variables de entorno AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY y AWS_SESSION_TOKEN
    • Comprobación en $HOME/.aws
    • Credenciales temporales obtenidas mediante AWS Security Token Service; es decir, a través de la API AssumeRole
    • Comprobación de credenciales en las variables de entorno de ECS AWS_CONTAINER_CREDENTIALS_RELATIVE_URI o AWS_CONTAINER_CREDENTIALS_FULL_URI y AWS_ECS_CONTAINER_AUTHORIZATION_TOKEN.
    • Obtención de credenciales mediante los metadatos de instancia de Amazon EC2, siempre que AWS_EC2_METADATA_DISABLED no esté establecido en true.
    • Estos mismos Settings también pueden establecerse para un endpoint específico, utilizando la misma regla de coincidencia por prefijo.

Optimización del rendimiento

Para obtener información sobre cómo optimizar la lectura y la inserción con la función s3, consulta la guía de rendimiento específica.

Ajuste del almacenamiento en S3

Internamente, el MergeTree de ClickHouse utiliza dos formatos de almacenamiento principales: Wide y Compact. Aunque la implementación actual usa el comportamiento predeterminado de ClickHouse (controlado mediante los ajustes min_bytes_for_wide_part y min_rows_for_wide_part), esperamos que este comportamiento sea distinto para S3 en futuras versiones; por ejemplo, un valor predeterminado más alto de min_bytes_for_wide_part favorecería un formato más Compact y, por lo tanto, menos archivos. En este momento, quizá le convenga ajustar estos parámetros si utiliza exclusivamente almacenamiento en S3.

MergeTree respaldado por S3

Las funciones s3 y el motor de tabla asociado nos permiten consultar datos en S3 con la sintaxis habitual de ClickHouse. Sin embargo, en cuanto a funcionalidades de gestión de datos y rendimiento, son limitados. No admiten índices primarios ni caché, y las inserciones de archivos deben gestionarse por parte del usuario. ClickHouse reconoce que S3 es una solución de almacenamiento atractiva, especialmente cuando el rendimiento de las consultas sobre datos “más fríos” es menos crítico y los usuarios buscan separar el almacenamiento del cómputo. Para facilitarlo, se ofrece compatibilidad para usar S3 como almacenamiento de un motor MergeTree. Esto le permitirá aprovechar la escalabilidad y las ventajas de coste de S3, así como el rendimiento de inserción y consulta del motor MergeTree.

Niveles de almacenamiento

Los volúmenes de almacenamiento de ClickHouse permiten abstraer los discos físicos del motor de tabla MergeTree. Un mismo volumen puede estar compuesto por un conjunto ordenado de discos. Aunque esta abstracción permite principalmente usar varios dispositivos de bloques para almacenar datos, también admite otros tipos de almacenamiento, incluido S3. Las partes de datos de ClickHouse pueden moverse entre volúmenes según las políticas de almacenamiento y los niveles de ocupación, lo que da lugar al concepto de niveles de almacenamiento. Los niveles de almacenamiento hacen posibles las arquitecturas hot-cold, en las que los datos más recientes, que por lo general también son los más consultados, requieren solo una pequeña cantidad de espacio en almacenamiento de alto rendimiento, por ejemplo, SSD NVMe. A medida que los datos envejecen, aumentan los SLA de los tiempos de consulta, al igual que la frecuencia de las consultas. Esta larga cola de datos puede almacenarse en medios más lentos y de menor rendimiento, como HDD o almacenamiento de objetos como S3.

Creación de un disco

Para utilizar un bucket de S3 como disco, primero debemos declararlo en el archivo de configuración de ClickHouse. Puede ampliar config.xml o, preferiblemente, crear un archivo nuevo en conf.d. A continuación se muestra un ejemplo de declaración de un disco S3:
Puede encontrar una lista completa de la configuración pertinente para esta declaración de disco aquí. Tenga en cuenta que las credenciales pueden administrarse aquí mediante los mismos métodos descritos en Gestión de credenciales; es decir, use_environment_credentials puede establecerse en true en el bloque de configuración anterior para usar roles de IAM.

Creación de una política de almacenamiento

Una vez configurado, este “disco” puede utilizarse en un volumen de almacenamiento declarado dentro de una política. En el siguiente ejemplo, asumimos que S3 es nuestro único almacenamiento. Esto deja de lado arquitecturas hot-cold más complejas, en las que los datos pueden reubicarse en función de los TTL y de los niveles de ocupación.

Creación de una tabla

Si ha configurado el 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 taxis de NYC y transmitimos los datos directamente a la tabla respaldada por S3:
Dependiendo del hardware, esta última inserción de 1 millón de filas puede tardar unos minutos en ejecutarse. Puedes confirmar el progreso mediante la tabla system.processes. Puedes ajustar el recuento de filas hasta el límite de 10 millones y explorar algunas consultas de ejemplo.

Modificar una tabla

En ocasiones, puede ser necesario modificar la política de almacenamiento de una tabla concreta. Aunque esto es posible, tiene limitaciones. La nueva política de destino debe contener todos los discos y volúmenes de la política anterior; es decir, los datos no se migrarán para adaptarse a un cambio de política. Al validar estas restricciones, los volúmenes y los discos se identificarán por su nombre, y cualquier intento de infringirlas producirá un error. No obstante, si usa los ejemplos anteriores, los siguientes cambios son válidos.
Aquí reutilizamos el volumen principal en nuestra nueva política s3_tiered e introducimos un nuevo volumen hot. Este usa el disco predeterminado, que consta de un único disco configurado mediante el parámetro <path>. Ten en cuenta que los nombres de nuestros volúmenes y discos no cambian. Los nuevos datos insertados en nuestra tabla residirán en el disco predeterminado hasta que este alcance move_factor * disk_size; en ese momento, los datos se reubicarán en S3.

Gestión de la replicación

La replicación con discos S3 puede implementarse mediante el motor de tabla ReplicatedMergeTree. Consulte la guía sobre cómo replicar un único segmento entre dos regiones de AWS con almacenamiento de objetos S3 para obtener más detalles.

Lecturas y escrituras

Las siguientes notas describen la implementación de las interacciones de S3 con ClickHouse. Aunque en general son solo informativas, pueden resultar útiles al Optimizar el rendimiento:
  • De forma predeterminada, el número máximo de hilos de procesamiento de consultas que puede usar cualquier etapa del pipeline de procesamiento de consultas es igual al número de núcleos. Algunas etapas se pueden paralelizar más que otras, por lo que este valor establece un límite superior. Varias etapas de la consulta pueden ejecutarse al mismo tiempo, ya que los datos se transmiten desde el disco. Por ello, el número exacto de hilos usados para una consulta puede superar este valor. Modifíquelo mediante la configuración max_threads.
  • Las lecturas en S3 son asíncronas de forma predeterminada. Este comportamiento viene determinado por la configuración remote_filesystem_read_method, cuyo valor predeterminado es threadpool. Al atender una solicitud, ClickHouse lee los gránulos en franjas. Cada una de estas franjas puede contener muchas columnas. Un hilo leerá las columnas de sus gránulos una por una. En lugar de hacerlo de forma síncrona, se realiza una precarga de todas las columnas antes de esperar los datos. Esto ofrece mejoras significativas de rendimiento frente a esperar de forma síncrona cada columna. En la mayoría de los casos no necesitará cambiar esta configuración; consulte Optimizar el rendimiento.
  • Las escrituras se realizan en paralelo, con un máximo de 100 hilos concurrentes de escritura de archivos. max_insert_delayed_streams_for_parallel_write, que tiene un valor predeterminado de 1000, controla el número de blobs de S3 que se escriben en paralelo. Como se requiere un búfer para cada archivo que se escribe (~1MB), esto limita de forma efectiva el consumo de memoria de un INSERT. Puede ser conveniente reducir este valor en entornos con poca memoria en el servidor.

Usar el almacenamiento de objetos de S3 como disco de ClickHouse

Si necesitas instrucciones paso a paso para crear buckets y un rol de IAM, consulta “Cómo crear un usuario de IAM de AWS y un bucket de S3”

Configure ClickHouse para usar el bucket de S3 como disco

El siguiente ejemplo se basa en un paquete Deb para Linux instalado como servicio con los directorios predeterminados de ClickHouse.
  1. Crea un archivo nuevo en el directorio config.d de ClickHouse para guardar la configuración de almacenamiento.
  1. Agregue lo siguiente a la configuración de almacenamiento, sustituyendo la ruta del bucket, la clave de acceso y las claves secretas de los pasos anteriores
Las etiquetas s3_disk y s3_cache dentro de la etiqueta <disks> son arbitrarias. Se pueden cambiar, pero debe usarse la misma etiqueta en la etiqueta <disk> dentro de la etiqueta <policies> para hacer referencia al disco. La etiqueta <S3_main> también es arbitraria y corresponde al nombre de la política que se usará como identificador del destino de almacenamiento al crear recursos en ClickHouse.La configuración que se muestra arriba es para ClickHouse 22.8 o versiones posteriores; si usas una versión anterior, consulta la documentación sobre almacenamiento de datos.Para obtener más información sobre el uso de S3: Guía de Integraciones: MergeTree con respaldo en S3
  1. Actualiza el propietario del archivo al usuario y grupo clickhouse
  1. Reinicie la instancia de ClickHouse para que los cambios surtan efecto.

Prueba

  1. Inicie sesión con el cliente de ClickHouse; por ejemplo:
  1. Cree una tabla y especifique la nueva política de almacenamiento de S3
  1. Comprueba que la tabla se haya creado con la política correcta
  1. Inserte filas de prueba en la tabla
  1. Ver las filas
  1. En la consola de AWS, ve a los buckets y selecciona el bucket nuevo y la carpeta. Deberías ver algo parecido a lo siguiente:

Replicar un único segmento entre dos regiones de AWS mediante almacenamiento de objetos en S3

El almacenamiento de objetos se utiliza de forma predeterminada en ClickHouse Cloud; no es necesario seguir este procedimiento si estás usando ClickHouse Cloud.

Planifique la implementación

Este tutorial se basa en la implementación de dos nodos de servidor de ClickHouse y tres nodos de ClickHouse Keeper en AWS EC2. El almacenamiento de datos de los servidores ClickHouse se realiza en S3. Se utilizan dos regiones de AWS, con un servidor de ClickHouse y un bucket de S3 en cada región, para posibilitar la recuperación ante desastres. Las tablas de ClickHouse se replican entre los dos servidores y, por tanto, entre las dos regiones.

Instalar el software

Nodos del servidor ClickHouse

Consulta las instrucciones de instalación al llevar a cabo los pasos de implementación en los nodos del servidor ClickHouse.

Desplegar ClickHouse

Despliegue ClickHouse en dos hosts; en las configuraciones de ejemplo, estos se denominan chnode1 y chnode2. Coloque chnode1 en una región de AWS y chnode2 en una segunda región.

Desplegar ClickHouse Keeper

Despliegue ClickHouse Keeper en tres hosts; en las configuraciones de ejemplo, se denominan keepernode1, keepernode2 y keepernode3. keepernode1 puede desplegarse 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 de la del nodo de ClickHouse de esa región. Consulte las instrucciones de instalación al realizar los pasos de despliegue en los nodos de ClickHouse Keeper.

Crear buckets de S3

Cree dos buckets de S3, uno en cada una de las regiones donde ha ubicado chnode1 y chnode2. Si necesita instrucciones paso a paso para crear buckets y un rol de IAM, expanda Crear buckets de S3 y un rol de IAM y siga los pasos:
Este artículo muestra los conceptos básicos sobre cómo configurar un usuario de IAM de AWS, crear un bucket de S3 y configurar ClickHouse para utilizarlo como disco S3. Se recomienda trabajar con el equipo de seguridad para determinar los permisos adecuados, y tomar estos como punto de partida.

Crear un usuario de IAM de AWS

En los siguientes pasos crearás un usuario de cuenta de servicio (no un usuario de inicio de sesión).
  1. Inicie sesión en la Consola de administración de AWS IAM.
  2. En el menú Users, seleccione Create user
Consola de administración de AWS IAM: agregar un nuevo usuario
  1. Introduce el nombre de usuario, establece el tipo de credencial en Access key - Programmatic access y selecciona Next: Permissions
Configuración del nombre de usuario y del tipo de acceso para el usuario de IAM
  1. No añadas al usuario a ningún grupo; selecciona Next: Tags
Omitir la asignación de grupo para el usuario de IAM
  1. Salvo que necesite añadir alguna etiqueta, seleccione Next: Review
Omitiendo la asignación de etiquetas para el usuario de IAM
  1. Selecciona Create User
El mensaje de advertencia que indica que el usuario no tiene permisos puede ignorarse; en la siguiente sección se le concederán permisos sobre el bucket
Creación del IAM user sin advertencia sobre permisos
  1. El usuario ya está creado; haz clic en show y copia la clave de acceso y la clave secreta.
Guarda las claves en otro lugar; esta es la única vez que la clave de acceso secreta estará disponible.
Ver y copiar las claves de acceso del usuario de IAM
  1. Haz clic en Cerrar y luego busca al usuario en la pantalla Usuarios.
Encontrar el IAM user recién creado en la lista de usuarios
  1. Copie el ARN (Amazon Resource Name) y guárdelo para utilizarlo al configurar la política de acceso del bucket.
Copiar el ARN del usuario de IAM

Crear un bucket de S3

  1. En la sección del bucket de S3, selecciona Create bucket
Inicio del proceso de creación del bucket de S3
  1. Introduzca un nombre de bucket y deje el resto de opciones predeterminadas
El nombre del bucket debe ser único en todo AWS, no solo dentro de la organización; de lo contrario, se producirá un error.
  1. Deje Block all Public Access activado; no es necesario el acceso público.
Configuración de los ajustes del bucket de S3 con el acceso público bloqueado
  1. Selecciona Create Bucket al final de la página
Finalizando la creación del bucket de S3
  1. Seleccione el enlace, copie el ARN y guárdelo para usarlo al configurar la política de acceso del bucket.
  2. Una vez creado el bucket, busque el nuevo bucket de S3 en la lista de buckets de S3 y seleccione el enlace
Ubicar el bucket de S3 recién creado en la lista de buckets
  1. Selecciona Create folder
Creación de una carpeta nueva en el bucket de S3
  1. Introduzca un nombre para la carpeta que será el destino del disco S3 de ClickHouse y seleccione Create folder
Configuración del nombre de la carpeta para el uso del disco S3 en ClickHouse
  1. La carpeta ahora debería verse en la lista de buckets
Vista de la carpeta recién creada en el bucket de S3
  1. Seleccione la casilla de verificación de la carpeta nueva y haga clic en Copy URL. Guarde la URL copiada para usarla en la configuración de almacenamiento de ClickHouse en la siguiente sección.
Copiando la URL de la carpeta de S3 para la configuración de ClickHouse
  1. Seleccione la pestaña Permissions y haga clic en el botón Edit de la sección Bucket Policy
Acceso a la configuración de la política del bucket de S3
  1. Añade una política para el bucket; a continuación se muestra un ejemplo:
Debe colaborar con su equipo de seguridad para determinar los permisos que se utilizarán; considérelos como punto de partida. Para obtener más información sobre las políticas y la configuración, consulte la documentación de AWS: https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-policy-language-overview.html
  1. Guarde la configuración de la política.
Los archivos de configuración se colocarán en /etc/clickhouse-server/config.d/. A continuación, se muestra un archivo de configuración de ejemplo para un bucket; el otro es similar, salvo por las tres líneas resaltadas:
/etc/clickhouse-server/config.d/storage_config.xml
Muchos de los pasos de esta guía le pedirán 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 usará su contenido para sobrescribir la configuración predeterminada. Al colocar estos archivos en el directorio de sobrescritura, evitará perder su configuración durante una actualización.

Configurar ClickHouse Keeper

Cuando se ejecuta ClickHouse Keeper en modo standalone (independiente del servidor de ClickHouse), la configuración se define en un único archivo XML. En este tutorial, el archivo es /etc/clickhouse-keeper/keeper_config.xml. Los tres servidores Keeper usan la misma configuración, con una única diferencia: <server_id>. server_id indica el ID que se asignará al host donde se use el archivo de configuración. En el ejemplo siguiente, el server_id es 3, y si observa más abajo en el archivo, en la sección <raft_configuration>, verá que el servidor 3 tiene el hostname keepernode3. Así es como el proceso de ClickHouse Keeper sabe a qué otros servidores conectarse al elegir un líder y realizar todas las demás actividades.
/etc/clickhouse-keeper/keeper_config.xml
Copie el archivo de configuración de ClickHouse Keeper en la ubicación correspondiente (recuerde configurar <server_id>):

Configurar el servidor de ClickHouse

Definir un clúster

Los clústeres de ClickHouse se definen en la sección <remote_servers> de la configuración. En este ejemplo, se define un clúster, cluster_1S_2R, que consta de un único segmento con dos réplicas. Las réplicas están ubicadas en los hosts chnode1 y chnode2.
/etc/clickhouse-server/config.d/remote-servers.xml
Cuando se trabaja con clústeres, resulta útil definir macros que rellenen las consultas DDL con la configuración de clúster, segmento y réplica. Este ejemplo le permite especificar el uso de un motor de tabla replicado sin proporcionar detalles de shard y replica. Cuando cree una tabla, podrá ver cómo se usan las macros shard y replica consultando system.tables.
/etc/clickhouse-server/config.d/macros.xml
Las macros anteriores son para chnode1; en chnode2, configure replica como replica_2.

Deshabilitar la replicación zero-copy

En las versiones 22.7 y anteriores de ClickHouse, la configuración allow_remote_fs_zero_copy_replication está establecida en true de forma predeterminada para los discos S3 y HDFS. Para este escenario de recuperación ante desastres, esta configuración debe establecerse en false; a partir de la versión 22.8, ya está establecida en false de forma predeterminada. Esta configuración debe establecerse en false por dos motivos: 1) esta funcionalidad no está lista para producción; 2) en un escenario de recuperación ante desastres, tanto los datos como los metadatos deben almacenarse en varias regiones. Establezca allow_remote_fs_zero_copy_replication en false.
/etc/clickhouse-server/config.d/remote-servers.xml
ClickHouse Keeper se encarga de coordinar la replicación de datos entre los nodos de ClickHouse. Para indicar a ClickHouse cuáles son los nodos de ClickHouse Keeper, añada un archivo de configuración a cada uno de los nodos de ClickHouse.
/etc/clickhouse-server/config.d/use_keeper.xml

Configurar la red

Consulta la lista de puertos de red al configurar los ajustes de seguridad en AWS para que tus servidores puedan comunicarse entre sí y para que tú puedas comunicarte con ellos. Los tres servidores deben aceptar conexiones de red para poder comunicarse entre sí y con S3. De forma predeterminada, ClickHouse solo escucha en la dirección de loopback, por lo que es necesario cambiarlo. Esto se configura en /etc/clickhouse-server/config.d/. Aquí tienes un ejemplo que configura ClickHouse y ClickHouse Keeper para que escuchen en todas las interfaces IPv4. Consulta la documentación o el archivo de configuración predeterminado /etc/clickhouse/config.xml para obtener más información.
/etc/clickhouse-server/config.d/networking.xml

Iniciar los servidores

Ejecutar ClickHouse Keeper

En cada servidor Keeper, ejecute los comandos de su sistema operativo; por ejemplo:

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 Keeper, verá que uno es el leader y los otros dos son followers:

Ejecute el servidor de ClickHouse

En cada servidor de ClickHouse, ejecute

Verificar el servidor de ClickHouse

Cuando agregó la configuración del clúster, se definió un único segmento replicado entre los dos nodos de ClickHouse. En este paso de verificación, comprobará que el clúster se creó cuando se inició ClickHouse y creará una tabla replicada usando ese clúster.
  • Verifique que el clúster exista:
  • Cree una tabla en el clúster usando el engine de tabla ReplicatedMergeTree:
  • Comprenda el uso de las macros definidas anteriormente Las macros shard y replica se definieron anteriormente, y en la línea resaltada a continuación puede ver dónde se sustituyen los valores en cada nodo de ClickHouse. Además, se usa el valor uuid; uuid no está definido en las macros, ya que lo genera el sistema.
Puede personalizar la ruta de ZooKeeper 'clickhouse/tables/{uuid}/{shard} que se muestra arriba configurando default_replica_path y default_replica_name. La documentación está aquí.

Pruebas

Estas pruebas verificarán que los datos se estén replicando entre los dos servidores y que se almacenen en los buckets de S3, no en el disco local.
  • Añada datos del conjunto de datos de taxis de la ciudad de Nueva York:
  • Verifique que los datos estén almacenados en S3. Esta consulta muestra el tamaño de los datos en disco y la política utilizada para determinar qué disco se usa.
    Compruebe el tamaño de los datos en el disco local. Según lo anterior, el tamaño en disco de los millones de filas almacenadas es de 36.42 MiB. Estos datos deberían estar en S3, no en el disco local. La consulta anterior también indica dónde se almacenan los datos y los metadatos en el disco local. Compruebe los datos locales:
    Compruebe los datos de S3 en cada bucket de S3 (no se muestran los totales, pero ambos buckets tienen aproximadamente 36 MiB almacenados después de las inserciones):

S3Express

S3Express es una nueva clase de almacenamiento de alto rendimiento de Amazon S3 en una única zona de disponibilidad. Puedes consultar este blog para conocer nuestra experiencia al probar S3Express con ClickHouse.
S3Express almacena los datos en una única AZ. Esto significa que los datos no estarán disponibles en caso de una caída de la AZ.

Disco S3

Para crear una tabla con almacenamiento respaldado por un bucket de S3Express, siga estos pasos:
  1. Cree un bucket de tipo Directory
  2. Aplique una política de bucket adecuada para conceder todos los permisos necesarios a su usuario de S3 (por ejemplo, "Action": "s3express:*" para permitir acceso sin restricciones)
  3. Al configurar la política de almacenamiento, indique el parámetro region
La configuración de almacenamiento es la misma que para S3 estándar y, por ejemplo, podría verse así:
A continuación, cree una tabla en el nuevo almacenamiento:

Almacenamiento S3

El almacenamiento S3 también es compatible, pero solo para rutas Object URL. Ejemplo:
también es necesario especificar la región del bucket en la configuración:

Copias de seguridad

Es posible almacenar una copia de seguridad en el disco que creamos anteriormente:
Última modificación el 3 de julio de 2026