Estrategia de operación en paralelo
- Riesgo mínimo: al ejecutar ambos sistemas en paralelo, mantienes el acceso a los datos y dashboards existentes mientras validas ClickStack y familiarizas a tus usuarios con el nuevo sistema.
- Expiración natural de los datos: la mayoría de los datos de observabilidad tienen un período de retención limitado (normalmente, de 30 días o menos), lo que permite una transición natural a medida que los datos caducan en Elastic.
- Migración simplificada: no es necesario utilizar herramientas o procesos complejos de transferencia para mover datos históricos entre sistemas.
Migración de datosMostramos un enfoque para migrar datos esenciales de Elasticsearch a ClickHouse en la sección “Migración de datos”. No debe usarse para conjuntos de datos más grandes, ya que rara vez ofrece un buen rendimiento: está limitado por la capacidad de Elasticsearch para exportar de forma eficiente y solo admite el formato JSON.
Pasos de implementación
Configurar la ingestión dual
Configure su pipeline de recopilación de datos para enviar datos tanto a Elastic como a ClickStack de forma simultánea.La forma de hacerlo depende de los agentes que utilice actualmente para la recopilación; consulte “Migración de agentes”.Validar y comparar
- Ejecute consultas en ambos sistemas para garantizar la coherencia de los datos
- Compare el rendimiento y los resultados de las consultas
- Migre los dashboards y las alertas a ClickStack. Actualmente, este proceso es manual.
- Verifique que todos los dashboards y alertas críticos funcionen como se espera en ClickStack
Transición gradual
- A medida que los datos caduquen de forma natural en Elastic, dependerá cada vez más de ClickStack
- Una vez que haya adquirido confianza en ClickStack, podrá empezar a redirigir consultas y dashboards
Retención a largo plazo
- Mantenga ambos sistemas en funcionamiento en paralelo hasta que todos los datos hayan caducado en Elastic
- Las capacidades de ClickStack para almacenamiento por niveles pueden ayudar a gestionar eficientemente los datos a largo plazo.
- Considere usar vistas materializadas para mantener datos históricos agregados o filtrados, permitiendo que los datos sin procesar caduquen.
Plazos de la migración
- Retención de 30 días: La migración puede completarse en un mes.
- Retención más prolongada: Mantenga la operación en paralelo hasta que los datos caduquen en Elastic.
- Datos históricos: Si es absolutamente necesario, considere usar Migración de datos para importar datos históricos concretos.
Configuración para la migración
Configuración recomendada
- ClickHouse Cloud: Usa de forma predeterminada una arquitectura de un solo segmento con múltiples réplicas. El almacenamiento y el cómputo escalan de forma independiente, lo que la hace ideal para casos de uso de observabilidad con patrones de ingesta impredecibles y cargas de trabajo con muchas lecturas.
- ClickHouse OSS: En implementaciones autogestionadas, recomendamos:
- Empezar con un solo segmento
- Escalar verticalmente con CPU y RAM adicionales
- Usar almacenamiento por niveles para ampliar el disco local con almacenamiento de objetos compatible con S3
- Usar
ReplicatedMergeTreesi se requiere alta disponibilidad - Para la tolerancia a fallos, 1 réplica de su segmento suele ser suficiente en cargas de trabajo de observabilidad.
Cuándo segmentar
- La tasa de ingesta supera la capacidad de un único nodo (normalmente, >500K filas/s)
- Necesita aislamiento entre tenants o separación regional de los datos
- El volumen total de datos es demasiado grande para un único servidor, incluso con almacenamiento de objetos
Retención y TTL
- Eliminar automáticamente los datos vencidos
- Mover los datos más antiguos al almacenamiento de objetos en frío
- Conservar solo los logs recientes que se consultan con frecuencia en disco rápido
Migración de datos
- Tablas de búsqueda pequeñas usadas para el enriquecimiento de datos (p. ej., asignaciones de usuarios, catálogos de servicios)
- Datos de negocio almacenados en Elasticsearch que deben correlacionarse con datos de observabilidad; las capacidades SQL de ClickHouse y sus integraciones de inteligencia empresarial facilitan el mantenimiento y la consulta de estos datos en comparación con las opciones de consulta más limitadas de Elasticsearch.
- Datos de configuración que deben conservarse durante la migración
Migrar el esquema
Cree una tabla en ClickHouse para el índice que se está migrando desde Elasticsearch. Puede mapear los tipos de Elasticsearch a su equivalente en ClickHouse. Como alternativa, puede utilizar el tipo de dato JSON en ClickHouse, que creará columnas del tipo adecuado de forma dinámica a medida que se inserten los datos.Considere el siguiente mapeo de Elasticsearch para un índice que contiene datos desyslog:mapping de Elasticsearch
mapping de Elasticsearch
Esquema de ClickHouse
Esquema de ClickHouse
- Las tuplas se utilizan para representar estructuras anidadas en lugar de la notación de punto
- Se utilizaron los tipos de ClickHouse adecuados según el mapeo:
keyword→Stringdate→DateTimeboolean→UInt8long→Int64ip→Array(Variant(IPv4, IPv6)). Aquí usamos unVariant(IPv4, IPv6)porque este campo contiene una mezcla deIPv4yIPv6.object→JSONpara el objeto syslog, cuya estructura es impredecible.
- Las columnas
host.ipyhost.macson explícitamente del tipoArray, a diferencia de Elasticsearch, donde todos los tipos son arrays. - Se añade una cláusula
ORDER BYcon timestamp y hostname para consultas temporales eficientes MergeTree, que es óptimo para los datos de registros, se utiliza como motor
- Validación de datos – aplicar un esquema estricto evita el riesgo de proliferación de columnas, salvo en estructuras específicas.
- Evita el riesgo de explosión de columnas: aunque el tipo JSON puede escalar potencialmente a miles de columnas, donde las subcolumnas se almacenan como columnas dedicadas, esto puede provocar una explosión de archivos de columnas, en la que se crea un número excesivo de archivos de columnas que afecta al rendimiento. Para mitigar esto, el tipo Dynamic subyacente que usa JSON ofrece un parámetro
max_dynamic_paths, que limita el número de rutas únicas almacenadas como archivos de columnas independientes. Una vez alcanzado el umbral, las rutas adicionales se almacenan en un archivo de columnas compartido mediante un formato codificado compacto, lo que mantiene el rendimiento y la eficiencia de almacenamiento, al tiempo que permite una ingestión de datos flexible. Sin embargo, acceder a este archivo de columnas compartido no ofrece el mismo rendimiento. No obstante, la columna JSON puede usarse con pistas de tipo. Las columnas “con pistas” ofrecerán el mismo rendimiento que las columnas dedicadas. - Introspección más sencilla de rutas y tipos: aunque el tipo JSON admite funciones de introspección para determinar los tipos y las rutas inferidos, las estructuras estáticas pueden ser más fáciles de examinar, por ejemplo, con
DESCRIBE.
Como alternativa, puede crear simplemente una tabla con una columna
JSON.Proporcionamos una indicación de tipo para las columnas
host.name y timestamp en la definición JSON, ya que las usamos en la clave de ordenación/clave primaria. Esto ayuda a ClickHouse a saber que estas columnas no serán nulas y garantiza que sepa qué subcolumnas usar (puede haber varias para cada tipo, por lo que, de otro modo, sería ambiguo).JSON únicamente para subestructuras dinámicas cuando sea necesario.Para obtener más detalles sobre el uso del tipo JSON en esquemas y cómo aplicarlo de forma eficiente, recomendamos la guía “Designing your schema”.Instala elasticdump
Recomendamos elasticdump para exportar datos desde Elasticsearch. Esta herramienta requiere node y debe instalarse en una máquina con conectividad de red tanto con Elasticsearch como con ClickHouse. Recomendamos un servidor dedicado con al menos 4 núcleos y 16 GB de RAM para la mayoría de las exportaciones.elasticdump ofrece varias ventajas para la migración de datos:- Interactúa directamente con la API REST de Elasticsearch, lo que garantiza una exportación correcta de los datos.
- Mantiene la consistencia de los datos durante el proceso de exportación mediante la API Point-in-Time (PIT); esto crea una instantánea consistente de los datos en un momento determinado.
- Exporta los datos directamente en formato JSON, que puede enviarse en streaming al ClickHouse client para su inserción.
elastic dump en la misma zona de disponibilidad o centro de datos para minimizar el tráfico de salida de red y maximizar el rendimiento.Instala el cliente de ClickHouse
Asegúrate de que ClickHouse esté instalado en el servidor donde se encuentraelasticdump. No inicies un servidor de ClickHouse; estos pasos solo requieren el cliente.Transferir datos
Para transferir datos entre Elasticsearch y ClickHouse, use el comandoelasticdump y canalice la salida directamente al cliente de ClickHouse. El siguiente comando inserta los datos en la tabla bien estructurada logs_system_syslog.elasticdump:type=data- limita la respuesta únicamente al contenido del documento en Elasticsearch.input-index- nuestro índice de entrada de Elasticsearch.output=$- redirige todos los resultados a stdout.- Opción
sourceOnly, que garantiza que omitamos los campos de metadatos en la respuesta. - Opción
searchAfterpara usar lasearchAfterAPI y paginar los resultados de forma eficiente. pit=truepara garantizar resultados consistentes entre consultas mediante la point in time API.
Los parámetros de nuestro cliente de ClickHouse aquí (aparte de las credenciales) son:
max_insert_block_size=1000- El cliente de ClickHouse enviará los datos una vez que se alcance este número de filas. Aumentarlo mejora el rendimiento a costa del tiempo necesario para formar un bloque; por tanto, aumenta el tiempo hasta que los datos aparecen en ClickHouse.min_insert_block_size_bytes=0- Desactiva la compactación de bloques del servidor por bytes.min_insert_block_size_rows=1000- Compacta en el servidor los bloques procedentes de los clientes. En este caso, lo establecemos enmax_insert_block_sizepara que las filas aparezcan inmediatamente. Auméntelo para mejorar el rendimiento.query="INSERT INTO logs_system_syslog FORMAT JSONAsRow"- Inserta los datos en formato JSONEachRow. Esto es apropiado si se envían a un esquema bien definido comologs_system_syslog.
Puede esperar un rendimiento del orden de miles de filas por segundo.
Insertar en una única fila JSONSi inserta en una única columna JSON (consulte el esquema Consulte “Leer JSON como un objeto” para obtener más información.
syslog_json anterior), puede usar el mismo comando de inserción. Sin embargo, debe especificar JSONAsObject como formato en lugar de JSONEachRow; por ejemplo:Transformar datos (opcional)
Los comandos anteriores asumen una correspondencia 1:1 entre los campos de Elasticsearch y las columnas de ClickHouse. Los usuarios suelen necesitar filtrar y transformar los datos de Elasticsearch antes de insertarlos en ClickHouse.Esto puede lograrse con la table functioninput, que nos permite ejecutar cualquier consulta SELECT sobre la salida estándar.Supongamos que solo queremos almacenar los campos timestamp y hostname de los datos anteriores. El esquema de ClickHouse:elasticdump en esta tabla, podemos usar simplemente la función de tabla input, utilizando el tipo JSON para detectar y seleccionar dinámicamente las columnas necesarias. Ten en cuenta que esta consulta SELECT podría incluir fácilmente un filtro.@timestamp y usar el formato de entrada JSONAsObject.