Base de datos ClickHouse para humanos, o Alien Technology

Alexey Lizunov, jefe del centro de competencia de canales de servicios remotos de la Dirección de Tecnologías de la Información del ICD



Como alternativa a la pila ELK (ElasticSearch, Logstash, Kibana), estamos realizando investigaciones sobre el uso de la base de datos ClickHouse como un almacén de datos para registros.

En este artículo, nos gustaría hablar sobre nuestra experiencia en el uso de la base de datos ClickHouse y sobre los resultados preliminares de la operación piloto. Cabe señalar de inmediato que los resultados fueron impresionantes.




A continuación, describiremos con más detalle cómo está configurado nuestro sistema y en qué componentes consta. Pero ahora me gustaría hablar un poco sobre esta base de datos en su conjunto, y por qué debería prestarle atención. La base de datos ClickHouse es una base de datos de columnas analíticas de alto rendimiento de Yandex. Se utiliza en los servicios de Yandex, inicialmente es el almacén de datos principal de Yandex.Metrica. El sistema de código abierto es gratuito. Desde el punto de vista del desarrollador, siempre me interesó cómo lo implementaron, porque hay datos increíblemente grandes. Y la interfaz de usuario métrica en sí es muy flexible y rápida. Al primer contacto con esta base de datos, la impresión: “¡Bueno, finalmente! Hecho "para personas"! Comenzando desde el proceso de instalación y terminando con el envío de solicitudes ".

Esta base de datos tiene un umbral de entrada muy bajo. Incluso un desarrollador experto promedio puede instalar esta base de datos en unos minutos y comenzar a usarla. Todo funciona con claridad. Incluso las personas que son nuevas en Linux pueden completar rápidamente la instalación y realizar operaciones simples. Anteriormente, cuando la palabra Big Data, Hadoop, Google BigTable, HDFS, el desarrollador habitual tenía la idea de que estaban hablando de algunos terabytes, petabytes, que algunos superhumanos estaban involucrados en la configuración y el desarrollo de estos sistemas, luego con el advenimiento de la base de datos ClickHouse obtuvimos Una herramienta simple y comprensible con la que puede resolver el rango de tareas previamente inalcanzable. Solo un automóvil bastante promedio y cinco minutos para instalar. Es decir, tenemos una base de datos como, por ejemplo, MySql, ¡pero solo para almacenar miles de millones de registros! Algún tipo de supervisor SQL. Es como si a las personas se les dieran armas de extraterrestres.

Sobre nuestro sistema de recopilación de registros

Para recopilar información, se utilizan archivos de registro IIS de aplicaciones web de formato estándar (también estamos involucrados en analizar registros de aplicaciones, pero el objetivo principal en la etapa de operación piloto con nosotros es recopilar registros IIS).

Por varias razones, no pudimos abandonar completamente la pila ELK, y continuamos usando los componentes LogStash y Filebeat, que han demostrado ser buenos y funcionan de manera bastante confiable y predecible.

El esquema general de registro se presenta en la siguiente figura:



Una característica de escribir datos en la base de datos ClickHouse es la inserción infrecuente (una vez por segundo) de registros en grandes lotes. Aparentemente, esta es la parte más "problemática" que encuentra la primera vez que trabaja con la base de datos ClickHouse: el esquema es un poco complicado.
El complemento LogStash ayudó mucho aquí, que inserta datos directamente en ClickHouse. Este componente se implementa en el mismo servidor que la base de datos en sí. Por lo tanto, en términos generales, no se recomienda hacerlo, sino desde un punto de vista práctico, para no producir servidores separados mientras se implementa en el mismo servidor. No observamos fallas o conflictos de recursos con la base de datos. Además, debe tenerse en cuenta que el complemento tiene un mecanismo de retransmisión en caso de errores. Y en caso de errores, el complemento escribe en el disco un paquete de datos que no se pudo insertar (el formato de archivo es conveniente: después de la edición, puede insertar fácilmente el paquete corregido usando clickhouse-client).

La lista completa de software utilizado en el esquema se presenta en la tabla:


La configuración del servidor con la base de datos ClickHouse se presenta en la siguiente tabla:

Como puede ver, esta es una estación de trabajo normal.

La estructura de la tabla para almacenar registros es la siguiente:


Utilizamos valores predeterminados para la partición (por meses) y la granularidad del índice. Todos los campos corresponden prácticamente a las entradas de registro de IIS para registrar solicitudes http. Por separado, campos separados para almacenar etiquetas utm (se analizan en la etapa de inserción en la tabla desde el campo de cadena de consulta).

También en la tabla se agregan varios campos del sistema para almacenar información sobre sistemas, componentes, servidores. Consulte la tabla a continuación para obtener una descripción de estos campos. En una tabla, almacenamos registros para varios sistemas.


Esto le permite construir gráficos de manera efectiva en Grafana. Por ejemplo, vea las solicitudes de la interfaz de un sistema específico. Esto es similar al contador del sitio en Yandex.Metrica.

Aquí hay algunas estadísticas sobre el uso de la base de datos durante dos meses.

Descripción de los componentes utilizados.

FileBeat. Transferencia de registro de archivos

Este componente supervisa los cambios en los archivos de registro en el disco y transfiere información a LogStash. Se instala en todos los servidores donde se escriben los archivos de registro (generalmente IIS). Funciona en modo de cola (es decir, solo transfiere registros agregados a un archivo). Pero por separado, puede configurar toda la transferencia de archivos. Esto es útil cuando necesita descargar datos de meses anteriores. Simplemente coloque el archivo de registro en una carpeta y él lo leerá en su totalidad.

Cuando el servicio se detiene, los datos dejan de transferirse al almacenamiento.

Un ejemplo de configuración es el siguiente:

LogStash Colector de registro

Este componente está diseñado para recibir entradas de registro de FileBeat (o a través de la cola RabbitMQ), analizar e insertar paquetes en la base de datos ClickHouse.

Para insertar en ClickHouse, se utiliza el complemento Logstash-output-clickhouse. El complemento Logstash tiene un mecanismo para recuperar solicitudes, pero con un apagado regular, es mejor detener el servicio en sí. Cuando se detiene, los mensajes se acumularán en la cola RabbitMQ, por lo que si se detiene durante un tiempo prolongado, es mejor detener Filebeats en los servidores. En un esquema donde RabbitMQ no se usa (en la red local, Filebeat envía registros directamente a Logstash), Filebeats funciona de manera bastante aceptable y segura, por lo que para ellos la inaccesibilidad de la salida no tiene consecuencias.

Un ejemplo de configuración es el siguiente:

ClickHouse. Almacenamiento de registro

Los registros de todos los sistemas se guardan en una tabla (consulte el comienzo del artículo). Está destinado a almacenar información sobre solicitudes: todos los parámetros son similares para diferentes formatos, por ejemplo, registros IIS, registros apache y nginx. Para los registros de aplicaciones en los que, por ejemplo, se registran errores, mensajes informativos, advertencias, se proporcionará una tabla separada con la estructura correspondiente (ahora en la etapa de diseño).

Al diseñar una tabla, es muy importante determinar la clave primaria (por la cual los datos se ordenarán durante el almacenamiento). El grado de compresión de datos y la velocidad de consulta dependen de esto. En nuestro ejemplo, la clave es
ORDER BY (fld_app_name, fld_app_module, logdatetime)
Es decir, por el nombre del sistema, el nombre del componente del sistema y la fecha del evento. La fecha original del evento fue en primer lugar. Después de moverlo al último lugar, las consultas comenzaron a funcionar aproximadamente dos veces más rápido. Cambiar la clave principal requerirá volver a crear la tabla y volver a cargar los datos para que ClickHouse vuelva a ordenar los datos en el disco. Esta es una operación difícil, por lo que es aconsejable pensar con anticipación qué debe incluirse en la clave de clasificación.

También debe tenerse en cuenta que relativamente en las versiones recientes ha aparecido el tipo de datos LowCardinality Al usarlo, el tamaño de los datos comprimidos se reduce drásticamente para aquellos campos que tienen baja cardinalidad (pocas opciones).

Ahora se usa la versión 19.6, y planeamos intentar actualizar la versión a la última. Incluyeron características tan maravillosas como Adaptive Granularity, Skipping indices y el códec DoubleDelta, por ejemplo.

De forma predeterminada, durante la instalación, el nivel de registro de configuración está configurado para rastrear. Los registros se rotan y archivan, pero se expanden a un gigabyte. Si no es necesario, puede establecer el nivel de advertencia, luego el tamaño del registro disminuye drásticamente. La configuración de registro se establece en el archivo config.xml:

 <!-- Possible levels: https://github.com/pocoproject/poco/blob/develop/Foundation/include/Poco/Logger. h#L105 --> <level>warning</level> 

LogStash FileBeat log router a la cola RabbitMQ

Este componente se utiliza para enrutar registros que vienen de FileBeat a la cola RabbitMQ. Hay dos puntos:

1. Desafortunadamente, FileBeat no tiene un complemento de salida para escribir directamente en RabbitMQ. Y tal funcionalidad, a juzgar por el ish en su github, no está planificada para su implementación. Hay un complemento para Kafka, pero por alguna razón no podemos usarlo en casa.
2. Hay requisitos para recopilar registros en la DMZ. En función de ellos, los registros primero deben agregarse a la cola y luego LogStash desde el exterior lee las entradas de la cola.

Por lo tanto, es precisamente para el caso de la ubicación del servidor en la DMZ que debe usar un esquema tan ligeramente complicado. Un ejemplo de configuración es el siguiente:

RabbitMQ. Cola de mensajes

Este componente se utiliza para almacenar las entradas de registro en la DMZ. La grabación se realiza a través de un montón de Filebeat → LogStash. La lectura se realiza desde fuera de la DMZ a través de LogStash. Cuando se opera a través de RabboitMQ, se procesan aproximadamente 4 mil mensajes por segundo.

El enrutamiento de mensajes se configura según el nombre del sistema, es decir, según los datos de configuración de FileBeat. Todos los mensajes caen en una cola. Si, por alguna razón, el servicio de cola se detiene, esto no conducirá a la pérdida de mensajes: FileBeats recibirá errores de conexión y suspenderá el envío temporal. Y LogStash, que lee desde la cola, también recibirá errores de red y esperará a que se reanude la conexión. Los datos en este caso, por supuesto, ya no se escribirán en la base de datos.

Las siguientes instrucciones se utilizan para crear y configurar colas:

 sudo /usr/local/bin/rabbitmqadmin/rabbitmqadmin declare exchange --vhost=/ name=monitor.direct type=direct sudo /usr/local/bin/rabbitmqadmin/rabbitmqadmin declare queue --vhost=/ name=web_log durable=true sudo /usr/local/bin/rabbitmqadmin/rabbitmqadmin --vhost="/" declare binding source="monitor.direct" destination_type="queue" destination="web_log" routing_key="site1.domain.ru" sudo /usr/local/bin/rabbitmqadmin/rabbitmqadmin --vhost="/" declare binding source="monitor.direct" destination_type="queue" destination="web_log" routing_key="site2.domain.ru" 

Grafana Tableros

Este componente se utiliza para visualizar datos de monitoreo. En este caso, debe instalar la fuente de datos ClickHouse para el complemento Grafana 4.6+. Tuvimos que ajustarlo un poco para aumentar la eficiencia del procesamiento de los filtros SQL en un tablero.

Por ejemplo, usamos variables, y si no están establecidas en el campo de filtro, nos gustaría que no genere una condición en la forma WHERE (uriStem = `` AND uriStem! = ''). En este caso, ClickHouse leerá la columna uriStem. En general, probamos diferentes opciones y finalmente arreglamos el complemento (macro $ valueIfEmpty) para que, en caso de un valor vacío, devuelva 1, sin mencionar la columna en sí.

Y ahora puedes usar esta consulta para el gráfico

 $columns(response, count(*) c) from $table where $adhoc and $valueIfEmpty($fld_app_name, 1, fld_app_name = '$fld_app_name') and $valueIfEmpty($fld_app_module, 1, fld_app_module = '$fld_app_module') and $valueIfEmpty($fld_server_name, 1, fld_server_name = '$fld_server_name') and $valueIfEmpty($uriStem, 1, uriStem like '%$uriStem%') and $valueIfEmpty($clientRealIP, 1, clientRealIP = '$clientRealIP') 

que se convierte a dicho SQL (tenga en cuenta que los campos uriStem vacíos se convirtieron a solo 1)

 SELECT t, groupArray((response, c)) AS groupArr FROM ( SELECT (intDiv(toUInt32(logdatetime), 60) * 60) * 1000 AS t, response, count(*) AS c FROM default.log_web WHERE (logdate >= toDate(1565061982)) AND (logdatetime >= toDateTime(1565061982)) AND 1 AND (fld_app_name = 'site1.domain.ru') AND (fld_app_module = 'web') AND 1 AND 1 AND 1 GROUP BY t, response ORDER BY t ASC, response ASC ) GROUP BY t ORDER BY t ASC 

Conclusión

La aparición de la base de datos ClickHouse se ha convertido en un evento histórico en el mercado. Era difícil imaginar que de forma gratuita en un instante, estuviéramos armados con una herramienta poderosa y práctica para trabajar con big data. Por supuesto, con las crecientes necesidades (por ejemplo, fragmentación y replicación en múltiples servidores), el esquema se volverá más complejo. Pero a primera vista, trabajar con esta base de datos es muy bueno. Se puede ver que el producto está hecho "para personas".

En comparación con ElasticSearch, el costo de almacenar y procesar registros, según estimaciones preliminares, se reduce de cinco a diez veces. En otras palabras, si para la cantidad actual de datos tendríamos que configurar un clúster de varias máquinas, cuando usemos ClickHouse solo necesitamos una máquina de bajo consumo. Sí, por supuesto, ElasticSearch también tiene mecanismos para comprimir datos en el disco y otras características que pueden reducir significativamente el consumo de recursos, pero en comparación con ClickHouse, esto será costoso.

Sin ninguna optimización especial por su parte, en la configuración predeterminada, cargar datos y recuperar datos de la base de datos funciona a una velocidad sorprendente. Hasta ahora tenemos algunos datos (alrededor de 200 millones de registros), pero el servidor en sí es débil. En el futuro, podemos usar esta herramienta para otros fines no relacionados con el almacenamiento de registros. Por ejemplo, para análisis de extremo a extremo, en el campo de la seguridad, el aprendizaje automático.

Al final, un poco sobre los pros y los contras.

Contras

1. Descarga de registros en grandes paquetes. Esto, por un lado, es una característica, pero aún debe usar componentes adicionales para almacenar registros. Esta tarea no siempre es simple, pero aún tiene solución. Y me gustaría simplificar el esquema.
2. Algunas funciones exóticas o nuevas características a menudo se rompen en nuevas versiones. Esto plantea preocupaciones, reduciendo el deseo de actualizar a una nueva versión. Por ejemplo, el motor de tabla Kafka es una característica muy útil que le permite leer directamente eventos de Kafka, sin la implementación de los consumidores. Pero a juzgar por la cantidad de problemas en el github, aún desconfiamos de usar este motor en la producción. Sin embargo, si no realiza movimientos bruscos hacia un lado y utiliza la funcionalidad básica, entonces funciona de manera estable.

Pros

1. No se ralentiza.
2. Umbral de entrada bajo.
3. Código abierto
4. Es gratis
5. Escala bien (fragmentación / replicación de fábrica)
6. Está incluido en el registro de software ruso recomendado por el Ministerio de Comunicaciones.
7. La presencia de apoyo oficial de Yandex.