Explicación detallada del sistema druida.

Introducción

Druid es un sistema de almacenamiento en columnas distribuido y de código abierto adecuado para el análisis de datos en tiempo real, capaz de realizar agregaciones rápidas, filtrado flexible, consultas a nivel de milisegundos e importación de datos de baja latencia.

Druid fue diseñado teniendo en mente la alta disponibilidad. La falla de varios nodos no hará que Druid deje de funcionar (pero el estado no se actualizará);
El acoplamiento entre los distintos componentes en Druid es bajo: si no se necesitan datos en tiempo real, el nodo en tiempo real se puede ignorar por completo;
Druid utiliza la indexación de mapas de bits para acelerar la velocidad de consulta del almacenamiento de columnas y utiliza el algoritmo CONCISE para comprimir la indexación de mapas de bits, lo que hace que los segmentos generados sean mucho más pequeños que el archivo de texto original;

Arquitectura

Estructura general

Un grupo de druidas contiene diferentes tipos de nodos y cada nodo está diseñado para hacer un determinado conjunto de cosas. Un diseño de este tipo puede aislar preocupaciones y simplificar la complejidad general del sistema.

Los diferentes nodos operan casi de forma independiente y tienen una interacción mínima con otros nodos, por lo que las fallas de comunicación dentro del clúster tienen muy poco impacto en la disponibilidad de los datos.

La composición y el flujo de datos del grupo de druidas se muestran en la Figura 1:

El propio Druid contiene cinco tipos de nodos: tiempo real, histórico, coordinador, corredor, indexador

Histórico El nodo histórico es un espacio de trabajo para almacenar y consultar datos "históricos" (no en tiempo real), carga segmentos de datos (Data/Segments) desde el área de almacenamiento profundo (Deep Storage), responde a la solicitud de consulta del Broker. nodo y devuelve los resultados.
El nodo histórico generalmente sincroniza localmente algunos segmentos de datos en el área de almacenamiento profundo, por lo que incluso si el área de almacenamiento profundo es inaccesible, el nodo histórico aún puede consultar los segmentos de datos sincronizados.
Tiempo real El nodo en tiempo real es un espacio de trabajo que almacena y consulta datos en tiempo real, también responderá a la solicitud de consulta del nodo Broker y devolverá los resultados.
Los nodos en tiempo real incorporarán periódicamente datos en segmentos de datos y los trasladarán a nodos históricos.
Coordinador El nodo de coordinación se puede considerar como el maestro en Druid: administra nodos históricos y nodos en tiempo real a través de Zookeeper y administra segmentos de datos a través de metadatos en Mysql.
El nodo Broker es responsable de responder a las solicitudes de consultas externas, reenviar las solicitudes a los nodos históricos y nodos en tiempo real respectivamente consultando a Zookeeper y finalmente fusionar y devolver los resultados de la consulta al exterior . El nodo Broker determina qué nodos históricos y reales Los nodos de tiempo brindan servicios a través de Zookeeper.
El nodo de índice del indexador es responsable de la importación de datos, la carga de datos por lotes y en tiempo real en el sistema, y puede modificar los datos almacenados en el sistema.

Druid contiene 3 dependencias externas: Mysql, almacenamiento profundo, Zookeeper

Mysql:
almacena metadatos sobre Druid en lugar de almacenar datos reales. Contiene 3 tablas:
"druid_config" (normalmente vacía), "druid_rules" (alguna información de reglas utilizada por los nodos colaborativos, como qué segmento se carga desde qué nodo) y "druid_segments " (almacena la información de metadatos de cada segmento);
Almacenamiento profundo: segmentos de almacenamiento, Druid actualmente admite discos locales, discos montados en NFS, HDFS, S3, etc.
Los datos de Deep Storage provienen de dos fuentes: una es la ingestión de datos por lotes y la otra proviene de nodos en tiempo real;
ZooKeeper: utilizado por Druid para administrar el estado del clúster actual, como registrar qué segmentos se han movido de nodos en tiempo real a nodos históricos;

nodo en tiempo real

Los nodos en tiempo real encapsulan las funciones de importar y consultar datos de eventos, y los datos de eventos importados a través de estos nodos se pueden consultar inmediatamente . El nodo en tiempo real solo se preocupa por los datos del evento dentro de un corto período de tiempo e importa periódicamente el lote de datos recopilados durante este período al área de almacenamiento profundo. Los nodos en vivo anuncian su estado en línea y los datos que proporcionan a través de Zookeeper.

Como se muestra en la Figura 2, el nodo en tiempo real almacena en caché los datos de eventos en un índice en la memoria y luego los conserva en el disco con regularidad . Los índices persistentes se fusionan periódicamente antes de transferirse. La consulta llega a índices tanto en memoria como persistentes. Todos los nodos en tiempo real iniciarán periódicamente tareas programadas en segundo plano para buscar índices persistentes locales. Las tareas programadas en segundo plano fusionan estos índices persistentes y generan una pieza de datos inmutables. Estos bloques de datos contienen todos los datos dentro de un período de tiempo. Los datos del evento que ha sido importado por el nodo en tiempo real se llama "Segmento" . Durante la fase de transferencia, el nodo en tiempo real carga estos segmentos en un almacenamiento de respaldo permanente y persistente, generalmente un sistema de archivos distribuido, como S3 o HDFS, llamado "Almacenamiento profundo".

nodo histórico

La arquitectura que siguen los nodos históricos shared-nothingpara que no haya un único punto de problema entre los nodos. Los nodos son independientes entre sí y los servicios que brindan son simples, sólo necesitan saber cargar, eliminar y procesar Segmentos. Al igual que los nodos en tiempo real, los nodos históricos anuncian su estado en línea y los datos que brindan en Zookeeper. Las instrucciones para cargar y eliminar segmentos se emitirán a través de Zookeeper. Las instrucciones incluirán información sobre dónde se almacenan los segmentos en el almacenamiento profundo y cómo descomprimirlos y procesarlos.

Como se muestra en la Figura 3, antes de que el nodo histórico descargue un segmento del área de almacenamiento profundo, primero verificará la información de la caché local para ver si el segmento ya existe en el nodo. Si el segmento no existe en la caché, el nodo histórico El nodo lo descargará desde el área de almacenamiento profundo.Segmento a local. Una vez completada esta etapa de procesamiento, el segmento será notificado en Zookeeper. En este punto, el segmento se puede consultar y es necesario cargar el segmento en la memoria antes de realizar la consulta.

Nodo coordinador

El nodo de coordinación es el principal responsable de la gestión y distribución de segmentos en nodos históricos. El nodo coordinador les dice a los nodos históricos que carguen datos nuevos, descarguen datos caducados, copien datos y muevan datos para equilibrar la carga. Para mantener una vista estable, Druid utiliza un protocolo de intercambio de control de concurrencia de múltiples versiones para administrar segmentos inmutables. Si algún segmento inmutable contiene datos que han quedado completamente obsoletos debido a los nuevos segmentos, el segmento caducado se descargará del clúster. El nodo de coordinación pasará por un proceso de elección de líder para determinar un nodo independiente que realice la función de coordinación, y los nodos de coordinación restantes servirán como nodos de respaldo redundantes.

Nodo intermediario

Los nodos de intermediario son rutas de consulta para nodos históricos y nodos en tiempo real . El nodo Broker conoce la información del segmento publicada en Zookeeper y puede enrutar la solicitud de consulta entrante al nodo histórico correcto o al nodo en tiempo real. El nodo Broker también fusionará los resultados locales del nodo histórico y los resultados en tiempo real . nodo y luego regresar. El resultado final combinado se entrega a la persona que llama. El nodo Broker contiene un caché que admite la política de vencimiento de LRU .

Como se muestra en la Figura 4, cada vez que el nodo Broker recibe una solicitud de consulta, primero asignará la consulta a un conjunto de segmentos. Es posible que los resultados de un determinado conjunto de segmentos ya existan en la memoria caché y no sea necesario volver a calcularlos. Para aquellos resultados que no existen en el caché, el nodo Broker reenviará la consulta al nodo histórico correcto y al nodo en tiempo real. Una vez que el nodo histórico devuelva los resultados, el nodo Broker almacenará en caché estos resultados para uso futuro. Este proceso se muestra en la Figura 6. Los datos en tiempo real nunca se almacenan en caché, por lo que las solicitudes de consulta de datos de nodos en tiempo real siempre se reenvían al nodo en tiempo real. Los datos en tiempo real cambian constantemente, por lo que el almacenamiento en caché de datos en tiempo real no es confiable.

Nodo indexador

El servicio de indexación es un servicio distribuido de alta disponibilidad relacionado con la ejecución de tareas de indexación. El servicio de indexación crea (y a veces destruye) segmentos de Druida. El servicio de indexación tiene una arquitectura tipo maestro/esclavo.

El servicio de indexación se compone de tres partes principales: el componente de peón que puede ejecutar una sola tarea, el componente de gestión intermedia para gestionar peones y el componente de señor supremo que distribuye las tareas de gestión al componente de gestión intermedia. El componente de señor supremo y el componente de gestión intermedia pueden ejecutarse en el mismo nodo o en varios nodos, mientras que el componente de gestión intermedia y el componente de peón siempre se ejecutan en el mismo nodo.

guardián del zoológico

Druid usa ZooKeeper (ZK) para administrar el estado actual del clúster. Las operaciones que ocurren en ZK son:

1. Coordinar la elección de líderes de nodos.

2. Los nodos históricos y en tiempo real publican protocolos de segmento.

3. Protocolo de carga/caída de segmentos entre nodos de coordinación y nodos históricos

4.Elección del líder supremo

5. Gestión de tareas del servicio de índice

Druida vs otros sistemas

Druida vs Impala/Tiburón

La comparación entre Druid, Impala y Shark básicamente se puede reducir a qué tipo de sistema se debe diseñar.

Druida está diseñado para:

Servicio siempre activo
Obtenga datos en tiempo real
Maneje consultas sobre la marcha al estilo de corte y corte

Las velocidades de consulta varían:

Druid es un método de almacenamiento en columnas. Los datos se comprimen y se agregan a la estructura de índice. La compresión aumenta la capacidad de almacenamiento de datos en la RAM y permite que la RAM se adapte al acceso rápido de más datos.
La estructura del índice significa que al agregar filtros a una consulta, Druid tiene que procesar menos y la consulta será más rápida.
Impala/Shark puede considerarse como una capa de almacenamiento en caché de programa en segundo plano sobre HDFS.
Pero no fueron más allá del almacenamiento en caché para mejorar realmente la velocidad de consulta.

La adquisición de datos es diferente:

Druid puede obtener datos en tiempo real.
Impala/Shark se basa en HDFS u otro almacenamiento de respaldo, lo que limita la velocidad de adquisición de datos.

La consulta toma diferentes formas:

Druid admite series temporales y consultas de estilo grupal, pero no uniones.
Impala/Shark admite consultas de estilo SQL.

Druida vs Elasticsearch

Elasticsearch (ES) es un servidor de búsqueda basado en Apache Lucene. Proporciona un modo de búsqueda de texto completo y proporciona acceso a datos sin procesar a nivel de evento. Elasticsearch también proporciona soporte de análisis y agregación. Según la investigación, ES utiliza más recursos para la adquisición y agregación de datos que Druid.

Druid se centra en los flujos de trabajo OLAP. Druid está optimizado para un alto rendimiento (agregación y recuperación rápidas) a bajo costo y admite una amplia gama de operaciones de análisis. Druid proporciona soporte de búsqueda básico para datos de eventos estructurados.

Druida vs Chispa

Spark es un marco de computación en clúster construido en torno al concepto de conjuntos de datos distribuidos elásticos (RDD), que puede considerarse como una plataforma de análisis en segundo plano. RDD permite la reutilización de datos y mantiene los resultados intermedios en la memoria, lo que proporciona a Spark un algoritmo iterativo para cálculos rápidos. Esto es especialmente beneficioso para ciertos flujos de trabajo, como el aprendizaje automático, donde las mismas operaciones se pueden aplicar una y otra vez hasta que los resultados converjan. Spark brinda a los analistas la capacidad de ejecutar consultas con una variedad de algoritmos diferentes y analizar grandes cantidades de datos.

Druid se centra en la adquisición de datos y la prestación de servicios para consultar datos. Si se establece una interfaz web, los usuarios pueden ver los datos a voluntad.

Escenarios adecuados para que Druid se utilice como base de datos:

Hay muchas inserciones de datos y pocas actualizaciones.
La mayoría de los datos de consulta son consultas de agregación y de informes, pero también hay datos de búsqueda y escaneo.
Consulta en 100 ms a segundos
Hay tiempo en los datos (Druid ha optimizado y diseñado especialmente el tiempo).
Cada consulta selecciona algunos campos en una tabla grande. (No se admite unirse).
Hay columnas de alta cardinalidad (por ejemplo, URL, ID de usuario) donde el recuento y la clasificación se pueden realizar rápidamente.
Ingerir datos de Kafka, HDFS, sistemas de archivos, Amazon S3.

Escenarios no aptos para Druida

Actualizaciones de baja latencia para registros de claves primarias. Druid admite la transmisión de datos, pero no admite actualizaciones de datos de transmisión. (Las actualizaciones de datos de transmisión se pueden actualizar en lotes en segundo plano)
Con un sistema de informes fuera de línea, no se presta mucha atención a la latencia de los datos .
Se requiere una combinación grande (las tablas en tiempo real están conectadas entre sí) y la consulta tarda mucho en completarse.

consulta TopN

TopN · Documentación técnica china de ApacheDruid www.apache-druid.cn/Querying/topn.html

La consulta Apache Druid TopN devuelve un conjunto de resultados ordenados de valores en una dimensión determinada según ciertos criterios. Conceptualmente, pueden verse como una GroupByQuery aproximada con clasificación en una sola dimensión . En este escenario, las consultas TopN son más eficientes que las consultas GroupBy. Estos tipos de consultas toman un objeto de consulta topN y devuelven una matriz de objetos JSON, donde cada objeto representa el valor solicitado por la consulta topN.

TopN es una consulta aproximada porque cada proceso de datos ordenará sus K resultados principales y solo devolverá esos K resultados principales al Broker. El valor predeterminado de K en Druid es max(1000, threshold) . En la práctica, esto significa que si solicita consultar los primeros 1000 datos, la precisión de los primeros 900 datos será del 100% y no se garantizará el orden de los resultados posteriores. Los TopN se pueden hacer más precisos aumentando el umbral.

Declaración de derechos de autor: el texto original se reproduce a partir de una explicación detallada del sistema druida - Zhihu