Práctica de druidas en Yauzan
Druid es un sistema de análisis y almacenamiento de datos desarrollado por MetaMarket Company. Está diseñado para OLAP (procesamiento analítico en línea) de alto rendimiento de conjuntos de datos masivos y actualmente está siendo incubado por la Fundación Apache. Strong>Áreas comunes de Druid:
Como empresa SaaS, Youzan tiene muchos escenarios comerciales y una gran cantidad de datos en tiempo real y fuera de línea. Antes de usar Druid, algunos escenarios OLAP usaban SparkStreaming o Storm para el análisis. El uso de este tipo de programa requiere un almacenamiento cuidadoso de las consultas además de escribir tareas en tiempo real. El problema es: el ciclo de desarrollo es largo; el diseño de almacenamiento inicial no puede satisfacer las necesidades del desarrollo iterativo y no es escalable;
Después de usar Druid, los desarrolladores solo necesitan completar la configuración de ingesta de datos y especificar dimensiones e indicadores para completar la ingesta de datos. A partir de las funciones de Druid presentadas anteriormente, sabemos que Druid admite SQL y la aplicación de la aplicación puede; utilizarse como datos de consulta como JDBC normal. Con la ayuda de la plataforma OLAP de desarrollo propio de Youzan, la configuración de la ingesta de datos se ha vuelto más simple y conveniente. Solo toma unos 10 minutos crear una tarea en tiempo real, lo que mejora enormemente la eficiencia del desarrollo.
La arquitectura de Druid es una arquitectura Lambda, dividida en capa de tiempo real (Overlord, MiddleManager) y capa por lotes (Broker e Histórico). Los nodos principales incluyen (nota: todas las funciones de Druid están en el mismo paquete y se inician con diferentes comandos):
4.1 Los objetivos principales de la plataforma OLAP Yauzan:
4.2 Yauzan Arquitectura de la plataforma OLAP
La plataforma Yauzan OLAP se utiliza para gestionar Druid y el sistema de gestión de componentes circundante. Las características principales de la plataforma OLAP:
La plataforma OLAP utiliza la herramienta Tranquility para la ingesta de datos y asigna un número diferente de instancias de Tranquility a cada fuente de datos según el tamaño del tráfico; se envía al Agente-Maestro. La configuración de la fuente de datos se envía al Agent-Master. El Agent-Master recopila el uso de recursos de cada servidor y selecciona una máquina rica en recursos para iniciar la instancia de Tranquility. Actualmente, solo se consideran los recursos de memoria del servidor. Al mismo tiempo, la plataforma OLAP también admite las funciones de inicio/detención, expansión y reducción de instancias de Tranquility.
El marco de procesamiento de datos de transmisión tiene una ventana de tiempo y los datos que lleguen después de esa ventana se descartarán. ¿Cómo podemos garantizar que los datos que llegan tarde se incorporen a los segmentos y al mismo tiempo evitar que la ventana de tareas en tiempo real se cierre durante largos períodos de tiempo? Desarrollamos capacidades de compensación de datos de Druid para configurar la transmisión ETL a través de la plataforma OLAP para almacenar datos sin procesar en HDFS. La ETL de transmisión basada en Flume puede garantizar que los datos de la misma hora estén en la misma ruta de archivo según la hora del evento.
ETL basado en Flume utiliza HDFS Sink para sincronizar datos, implementar un interceptor de marca de tiempo y crear archivos (una carpeta por hora) según el campo de marca de tiempo del evento. Los datos retrasados se almacenan en la misma ruta del archivo. . (carpeta), los datos retrasados se archivan correctamente en los archivos horarios correspondientes.
Con el aumento de las visitas comerciales y la extensión del tiempo de ejecución, el tamaño de los datos también es cada vez mayor. El nodo histórico carga una gran cantidad de datos segmentados. Se observa que la mayoría de las consultas se concentran en los últimos días. En otras palabras, los datos calientes de los últimos días se pueden consultar fácilmente. Los datos son muy importantes para mejorar la eficiencia de las consultas.
Druid proporciona un mecanismo de agrupación de capas históricas y un mecanismo de reglas de carga de datos, que se pueden configurar para separar datos fríos y activos.
Primero, agrupe el clúster histórico. El grupo predeterminado es "_default_tier". Planifique una pequeña cantidad de nodos históricos como un grupo "activo" y utilice discos SATA como ". hot" y utilice el disco SSD. Luego configure una regla de carga para cada fuente de datos:
Aumente el valor druid.server.priority para el clúster "activo" (el valor predeterminado es 0) y las consultas de datos activos se dirigirán al clúster "activo". .
Cada componente de la arquitectura Druid es altamente tolerante a fallas. Incluso si ocurre un solo punto de falla, el clúster aún puede brindar servicios al mundo exterior: Coordinator y Overlord tienen garantía de HA para el segmento; y se almacena en HDFS /S3; los nodos Segment para cargas históricas y los nodos Peon para ingerir datos en tiempo real se pueden configurar como copias múltiples para brindar servicios al mundo exterior. Los nodos de segmento y los nodos Peon que ingieren datos en tiempo real se pueden configurar como servicios de copia múltiple. Al mismo tiempo, para poder enviar mensajes de alarma lo antes posible cuando un nodo/clúster entre en mal estado o alcance el límite de capacidad. Al igual que con otros marcos de big data, tenemos entradas detalladas de monitoreo y alertas para Druid, divididas en dos niveles:
Los clústeres históricos se implementan de manera consistente con los datos fríos y calientes descritos en la Sección 4.4 Correspondiente al separación, el clúster SSD se usa para almacenar los datos activos de los últimos N días (el número de días de carga es ajustable), mientras que el modelo Sata relativamente económico se usa para almacenar datos fríos con un largo historial, mientras se aprovecha al máximo el Clúster Sata para almacenar los últimos N días de datos fríos. Usamos clústeres SSD para almacenar datos activos durante los últimos N días (la cantidad de días de carga se puede ajustar) y usamos el modelo Sata relativamente económico para almacenar datos fríos durante períodos de tiempo más largos, mientras aprovechamos al máximo las capacidades IO de Sata para cargar segmentos en diferentes discos. En el clúster MiddleManager, además de implementar tareas de índice (tareas basadas en memoria), también implementamos algunas tareas Tranquility (tareas basadas en CPU) de alto tráfico para mejorar la utilización de recursos del clúster MiddleManager.
En el caso de SQL On Broker/Router, descubrimos que con una pequeña cantidad de consultas lentas, el cliente dejaría de responder a la consulta y las conexiones serían cada vez más difíciles de obtener. Después de iniciar sesión en el lado del servidor del Broker, descubrimos que la cantidad de conexiones disponibles se redujo drásticamente hasta agotarse y había muchos TCP Close_Wait. Después de solucionar el problema con la herramienta jstack, encontramos una situación de punto muerto. Consulte el EDICIÓN 6867 para conocer la pila específica.
Después de profundizar en el código fuente, descubrimos que DruidConnection registra una devolución de llamada para cada Declaración. En circunstancias normales, una vez finalizada la Declaración, se ejecutará la función de devolución de llamada para eliminar su estado de la declaración de DruidConnection. Si ocurre una consulta lenta (que excede el tiempo máximo de conexión o Kill del cliente), la conexión se cerrará a la fuerza; this Al mismo tiempo, se cerrarán todas las declaraciones siguientes y se cerrarán ambos hilos (todas las declaraciones cerradas). Si la consulta es lenta (se superó el tiempo máximo de conexión o se canceló el cliente), la conexión se cerrará a la fuerza, al igual que todas las declaraciones que contiene.
Después de solucionar el problema, también presentamos el PR-6868 a la comunidad. Ahora se ha fusionado con éxito en la rama master y se lanzará en la versión 0.14.0.
Si encuentra este problema, puede contratar un PR para solucionarlo en su propia sucursal.
Las soluciones de ingesta de datos más comunes son KafkaIndex y Tranquility. Usamos la solución de Tranquility. Tranquility admite Kafka y Http para ingerir datos, pero esta no es una forma rica de ingestión de datos; Tranquility también es un proyecto de código abierto de MetaMarket, pero su velocidad de actualización es lenta y carece de muchas funciones. funciones de seguimiento. Lo más importante es la falta de funciones de monitoreo, por lo que no podemos monitorear el estado de ejecución, la tasa de ingesta, el trabajo pendiente, la pérdida, etc. de la instancia.
Actualmente, administramos las instancias de Tranquility de la misma manera que el MiddleManager de Druid administra los nodos Peon: iniciar/detener, escalar hacia arriba/abajo, etc. Al convertir Tranquility o nuestra propia herramienta de ingesta en una aplicación Yarn o Docker, podemos entregar la programación de recursos y la gestión de instancias a un programador más confiable.
Druid actualmente no admite consultas JOIN y todas las consultas agregadas están limitadas a una única fuente de datos. Sin embargo, en escenarios de aplicaciones del mundo real, a menudo necesitamos múltiples fuentes de datos para realizar consultas JOIN y obtener los resultados deseados. Este es un problema para nosotros y el equipo de desarrollo de Druid.
Para escenarios de consultas OLAP en C-suite, RT es más exigente. Dado que Druid creará la tarea de índice para la hora actual en punto, si la consulta recae en la tarea de índice recién creada, el problema de la consulta será muy grande, como se muestra en la siguiente figura:
Ya hemos hecho algunos Para la optimización y el ajuste, el primer paso es ajustar el parámetro WarmingPeriod e iniciar la tarea de indexación de Druid antes de la hora. Para algunos servidores de datos con TPS bajo pero QPS alto, los requisitos de RT son muy altos, por lo que no lo haremos; capaz de utilizarlo. Para algunas fuentes de datos con TPS bajo pero QPS alto, ajustamos la granularidad de segmento en la mayoría de las consultas que consultan datos dentro de las últimas 24 horas, lo que garantiza que los datos de la consulta estén en la memoria, lo que reduce las nuevas tareas de índice y los fallos de consulta se han mejorado enormemente. Sin embargo, esto todavía está lejos de lo que queremos, así que sigamos optimizando el código fuente.
La granularidad del segmento de la mayoría de las fuentes de datos ahora se calcula cada hora, y los segmentos almacenados en HDFS también se calculan cada hora. Cuando el período de tiempo a consultar es relativamente grande, la consulta será muy lenta, ocupará una gran cantidad de recursos históricos e incluso provocará Broker OOM. Aparece el corredor OOM. Si crea un trabajo por lotes de Hadoop para datos Rull-Up de hace una semana (por ejemplo) y reconstruye el índice con una granularidad de un día, debería obtener buenos resultados al comprimir el almacenamiento y mejorar el rendimiento de las consultas. Hemos entrado en la etapa práctica de Rull-Up sobre datos históricos, que presentaremos más adelante en el blog.
Finalmente, el equipo de infraestructura del equipo de big data de Youzan es responsable de una serie de tecnologías, incluida la plataforma de datos (DP) de Youzan, la computación en tiempo real (Storm, Spark Streaming, Flink) y la computación fuera de línea ( HDFS, YARN, HIVE, SPARK SQL), almacenamiento en línea (HBase), OLAP en tiempo real (Druid), etc. Druid) y muchos otros productos técnicos, los socios interesados pueden ponerse en contacto con zhaojiandong@youzan.com