FileLog le permite:
- Suscribirse a archivos de registro.
- Procesar nuevos registros a medida que se añaden a los archivos de registro a los que se haya suscrito.
Crear una tabla
path_to_logs– Ruta de los archivos de registro a los que suscribirse. Puede ser la ruta a un directorio con archivos de registro o a un único archivo de registro. Tenga en cuenta que ClickHouse solo permite rutas dentro del directoriouser_files.format_name- Formato del registro. Tenga en cuenta que FileLog procesa cada línea de un archivo como un registro independiente y que no todos los formatos de datos son adecuados para ello.
poll_timeout_ms- Tiempo de espera para una sola operación de sondeo del archivo de registro. Predeterminado: stream_poll_timeout_ms.poll_max_batch_size— Número máximo de registros que se pueden sondear en una sola operación. Predeterminado: max_block_size.max_block_size— Tamaño máximo del lote (en registros) para el sondeo. Predeterminado: max_insert_block_size.max_threads- Número máximo de hilos para analizar archivos; el valor predeterminado es 0, lo que significa que el número será max(1, physical_cpu_cores / 4).poll_directory_watch_events_backoff_init- Valor de espera inicial para el hilo de supervisión del directorio. Predeterminado:500.poll_directory_watch_events_backoff_max- Valor de espera máximo para el hilo de supervisión del directorio. Predeterminado:32000.poll_directory_watch_events_backoff_factor- Velocidad del backoff; de forma predeterminada, es exponencial. Predeterminado:2.handle_error_mode— Cómo gestionar los errores del motor FileLog. Valores posibles: default (se lanzará una excepción si no se puede analizar un mensaje), stream (el mensaje de excepción y el mensaje sin procesar se guardarán en las columnas virtuales_errory_raw_message).
Descripción
Los registros entregados se controlan automáticamente, de modo que cada registro de un archivo de registro solo se cuenta una vez.SELECT no resulta especialmente útil para leer registros (excepto para depuración), porque cada registro solo puede leerse una vez. Es más práctico crear hilos en tiempo real mediante vistas materializadas. Para ello:
- Use el motor para crear una tabla FileLog y considérela un flujo de datos.
- Cree una tabla con la estructura deseada.
- Cree una vista materializada que convierta los datos del motor y los inserte en una tabla creada previamente.
MATERIALIZED VIEW se conecta al motor, comienza a recopilar datos en segundo plano. Esto le permite recibir continuamente registros de archivos de registro y convertirlos al formato requerido mediante SELECT.
Una tabla FileLog puede tener tantas vistas materializadas como desee; no leen datos de la tabla directamente, sino que reciben nuevos registros (en bloques). De este modo, puede escribir en varias tablas con distintos niveles de detalle (con agrupación y agregación, y sin ellas).
Ejemplo:
ALTER, le recomendamos deshabilitar la vista materializada para evitar discrepancias entre la tabla de destino y los datos de la vista.
Columnas virtuales
_filename- Nombre del archivo de registro. Tipo de dato:LowCardinality(String)._offset- Desplazamiento en el archivo de registro. Tipo de dato:UInt64.
handle_error_mode='stream':
_raw_record- Registro sin procesar que no pudo analizarse correctamente. Tipo de dato:Nullable(String)._error- Mensaje de excepción que se produjo durante un análisis fallido. Tipo de dato:Nullable(String).
_raw_record y _error solo se rellenan en caso de excepción durante el análisis; siempre son NULL cuando el mensaje se analiza correctamente.
Durabilidad de los datos
El motorFileLog registra el desplazamiento consumido de un fragmento antes de que se confirme el insert al que pertenece, por lo que una interrupción del servidor puede dejar el desplazamiento registrado por delante de los datos que llegaron a la tabla de destino. Al reiniciarse, cada archivo de registro se reanuda desde el desplazamiento registrado en su directorio de metadatos, por lo que esas filas no se vuelven a leer: se pierden sin que se produzca ningún error y count() es simplemente menor. Basta un fallo normal del proceso para que esto ocurra, sin necesidad de una pérdida de alimentación, ya que el desplazamiento se registra en un archivo de metadatos que se renombra en su ubicación definitiva mientras la parte de destino aún se está escribiendo.
La pérdida de la caché de páginas del SO también puede descartar datos que ya se habían escrito en la tabla de destino; por ejemplo, una pérdida de alimentación a nivel de dispositivo o un reinicio no limpio del host o del kernel. Los archivos de metadatos que contienen los desplazamientos se escriben sin ejecutar fsync en el archivo ni en su directorio, por lo que tampoco ofrecen por sí mismos ninguna garantía de durabilidad.
A diferencia de los motores de intermediarios de mensajes, FileLog no puede protegerse frente a esto haciendo primero duradero el destino. Como el desplazamiento se registra dentro del pipeline de lectura, antes de que finalice el insert al que pertenece, establecer fsync_after_insert = 1 en las tablas MergeTree de destino no garantiza que la parte insertada sea duradera antes de que avance el desplazamiento. Trate el consumo de FileLog como un seguimiento de archivos locales de mejor esfuerzo: si no se puede perder ninguna fila, conserve los archivos de registro de origen hasta verificar los datos consumidos en el destino, de modo que el consumo pueda repetirse. Eliminar y volver a crear la tabla descarta los desplazamientos registrados y vuelve a leer los archivos desde el principio.