Cómo digerir 15 mil millones de registros por día y mantener las consultas grandes en menos de 1 segundo
Digerir 15 mil millones de registros diarios y mantener consultas rápidas en menos de 1 segundo.
Este caso de uso de almacenamiento de datos se trata de la escala. El usuario es China Unicom, uno de los mayores proveedores de servicios de telecomunicaciones del mundo. Utilizando Apache Doris, despliegan múltiples clústeres a escala de petabytes en docenas de máquinas para respaldar sus 15 mil millones de adiciones diarias de registros de sus más de 30 líneas de negocio. Este sistema de análisis de registros gigantesco es parte de su gestión de ciberseguridad. Para satisfacer la necesidad de monitoreo en tiempo real, rastreo de amenazas y alertas, requieren un sistema de análisis de registros que pueda recolectar, almacenar, analizar y visualizar automáticamente los registros y registros de eventos.
Desde una perspectiva arquitectónica, el sistema debe ser capaz de realizar análisis en tiempo real de varios formatos de registros y, por supuesto, ser escalable para respaldar el tamaño de datos enorme y en constante crecimiento. El resto de esta publicación trata sobre cómo se ve la arquitectura de procesamiento de registros y cómo logran la ingestión de datos estable, el almacenamiento de bajo costo y las consultas rápidas con ella.
Arquitectura del sistema
Esta es una descripción general de su canalización de datos. Los registros se recopilan en el almacén de datos y pasan por varias capas de procesamiento.
- Desbloqueando la Caja Negra Una Ley Cuantitativa para Comprender el...
- Construyendo y entrenando modelos de lenguaje grandes para código U...
- Training de Deep Learning en AWS Inferentia
- ODS: Los registros y alertas originales de todas las fuentes se recopilan en Apache Kafka. Mientras tanto, se almacenará una copia de ellos en HDFS para verificación o reproducción de datos.
- DWD: Aquí es donde se encuentran las tablas de hechos. Apache Flink limpia, estandariza, rellena y desidentifica los datos, y los escribe de nuevo en Kafka. Estas tablas de hechos también se colocarán en Apache Doris, para que Doris pueda rastrear un elemento específico o utilizarlos para la creación de paneles y generación de informes. Como los registros no son ajenos a la duplicación, las tablas de hechos se organizarán en el modelo de clave duplicada de Apache Doris.
- DWS: Esta capa agrega datos de DWD y sienta las bases para consultas y análisis.
- ADS: En esta capa, Apache Doris agrega automáticamente datos con su modelo de clave de agregación y actualiza automáticamente datos con su modelo de clave única.
La Arquitectura 2.0 evoluciona a partir de la Arquitectura 1.0, que está respaldada por ClickHouse y Apache Hive. La transición surgió de las necesidades del usuario de procesamiento de datos en tiempo real y consultas de unión de múltiples tablas. En su experiencia con la arquitectura antigua, encontraron un soporte insuficiente para la concurrencia y las uniones de múltiples tablas, manifestado por tiempos de espera frecuentes en la creación de paneles y errores de memoria insuficiente en las uniones distribuidas.
Ahora veamos su práctica en la ingestión de datos, el almacenamiento y las consultas con la Arquitectura 2.0.
Práctica de casos reales
Ingestión estable de 15 mil millones de registros al día
En el caso del usuario, su negocio genera 15 mil millones de registros todos los días. Ingerir tal volumen de datos de manera rápida y estable es un problema real. Con Apache Doris, la forma recomendada es utilizar el conector Flink-Doris. Fue desarrollado por la comunidad de Apache Doris para la escritura de datos a gran escala. El componente requiere una configuración sencilla. Implementa la carga de transmisión y puede alcanzar una velocidad de escritura de 200,000~300,000 registros por segundo, sin interrumpir las cargas de trabajo de análisis de datos.
Una lección aprendida es que al usar Flink para la escritura de alta frecuencia, es necesario encontrar la configuración de parámetros adecuada para su caso, para evitar la acumulación de versiones de datos. En este caso, el usuario realizó las siguientes optimizaciones:
- Punto de control de Flink: Aumentaron el intervalo de punto de control de 15s a 60s para reducir la frecuencia de escritura y el número de transacciones procesadas por Doris por unidad de tiempo. Esto puede aliviar la presión de escritura de datos y evitar la generación de demasiadas versiones de datos.
- Preagregación de datos: Para datos del mismo ID pero que provienen de diversas tablas, Flink los preagregará en función del ID de clave primaria y creará una tabla plana, para evitar el consumo excesivo de recursos causado por la escritura de datos de múltiples fuentes.
- Compactación de Doris: El truco aquí incluye encontrar los parámetros adecuados de la parte posterior de Doris (BE) para asignar la cantidad adecuada de recursos de CPU para la compactación de datos, configurar el número adecuado de particiones de datos, cubetas y réplicas (demasiadas tabletas de datos traerán grandes costos generales) y ajustar max_tablet_version_num para evitar la acumulación de versiones.
Estas medidas juntas aseguran la estabilidad de la ingestión diaria. El usuario ha presenciado un rendimiento estable y una puntuación de compactación baja en la parte posterior de Doris. Además, la combinación de preprocesamiento de datos en Flink y el modelo de clave única en Doris puede garantizar actualizaciones de datos más rápidas.
Estrategias de almacenamiento para reducir costos en un 50%
El tamaño y la velocidad de generación de los registros también imponen presión en el almacenamiento. Entre los inmensos datos de registro, solo una parte tiene un alto valor informativo, por lo que el almacenamiento debe ser diferenciado. El usuario tiene tres estrategias de almacenamiento para reducir costos.
- Algoritmo de compresión ZSTD (ZStandard): Para tablas mayores a 1TB, especifique el método de compresión como “ZSTD” al crear la tabla, lo que logrará una relación de compresión de 10:1.
- Almacenamiento diferenciado de datos calientes y fríos: Esto es compatible con la nueva función de Doris. El usuario establece un período de “enfriamiento” de datos de 7 días. Eso significa que los datos de los últimos 7 días (es decir, datos calientes) se almacenarán en SSD. A medida que pasa el tiempo, los datos calientes se “enfrían” (se vuelven más antiguos que 7 días), se moverán automáticamente a HDD, que es menos costoso. A medida que los datos se vuelven aún más “fríos”, se moverán al almacenamiento de objetos para reducir aún más los costos de almacenamiento. Además, en el almacenamiento de objetos, los datos se almacenarán con una sola copia en lugar de tres. Esto reduce aún más los costos y los sobrecostos causados por el almacenamiento redundante.
- Números de réplica diferenciados para diferentes particiones de datos: El usuario ha particionado sus datos por rango de tiempo. El principio es tener más réplicas para las particiones de datos más recientes y menos para las más antiguas. En su caso, los datos de los últimos 3 meses se acceden con frecuencia, por lo que tienen 2 réplicas para esta partición. Los datos que tienen entre 3 y 6 meses de antigüedad tienen dos réplicas, y los datos de hace 6 meses tienen una sola copia.
Con estas tres estrategias, el usuario ha reducido sus costos de almacenamiento en un 50%.
Estrategias de consulta diferenciadas basadas en el tamaño de los datos
Algunos registros deben ser rastreados y localizados de inmediato, como los eventos anormales o fallas. Para garantizar una respuesta en tiempo real a estas consultas, el usuario tiene diferentes estrategias de consulta para diferentes tamaños de datos:
- Menos de 100G: El usuario utiliza la función de particionamiento dinámico de Doris. Las tablas pequeñas se particionarán por fecha y las tablas grandes se particionarán por hora. Esto evita el desequilibrio de datos. Para garantizar aún más el equilibrio dentro de una partición de datos, utilizan el ID de copo de nieve como campo de agrupación. También establecen un desplazamiento inicial. Se conservarán los datos de los últimos 20 días. Este es el punto de equilibrio entre el acúmulo de datos y las necesidades analíticas.
- 100G~1T: Estas tablas tienen sus vistas materializadas, que son los conjuntos de resultados precalculados almacenados en Doris. Por lo tanto, las consultas en estas tablas serán mucho más rápidas y consumirán menos recursos. La sintaxis DDL de las vistas materializadas en Doris es la misma que en PostgreSQL y Oracle.
- Más de 100T: Estas tablas se colocan en el modelo de clave de agregación de Apache Doris y se preagregan. De esta manera, se pueden realizar consultas de 2 mil millones de registros de registro en 1-2 segundos.
Estas estrategias han acortado el tiempo de respuesta de las consultas. Por ejemplo, una consulta de un elemento de datos específico solía llevar minutos, pero ahora se puede completar en milisegundos. Además, para tablas grandes que contienen 10 mil millones de registros de datos, las consultas en diferentes dimensiones se pueden realizar en segundos.
Planes en curso
El usuario está realizando pruebas con el índice invertido recién agregado en Apache Doris. Está diseñado para acelerar la búsqueda de texto completo de cadenas, así como las consultas de equivalencia y rango de numéricos y fechas. También han proporcionado su valioso feedback sobre la lógica de particionamiento automático en Doris: Actualmente, Doris decide el número de particiones para una partición en función del tamaño de los datos de la partición anterior. El problema para el usuario es que la mayoría de sus nuevos datos llegan durante el día, pero muy poco por la noche. Entonces, en su caso, Doris crea demasiadas particiones para los datos nocturnos pero muy pocas durante el día, que es lo contrario de lo que necesitan. Esperan agregar una nueva lógica de particionamiento automático, donde la referencia para que Doris decida el número de particiones sea el tamaño de los datos y la distribución del día anterior. Han acudido a la comunidad de Apache Doris y ahora estamos trabajando en esta optimización. Zaki Lu es un antiguo gerente de producto en Baidu y ahora es DevRel para la comunidad de código abierto de Apache Doris.
