Como empresa de internet, los registros de monitoreo de sitios web son, por supuesto, la mayor fuente de datos. Nuestra escala actual no es grande, el volumen de registro diario es de aproximadamente 1 TB. Más del 90% del seguimiento del negocio debe completarse en función de los registros. Anteriormente, los requisitos en tiempo real en el negocio no eran altos, a lo sumo era casi en tiempo real (más de media hora de retraso). Realizar limpieza y análisis.
Más tarde, de acuerdo con las necesidades comerciales, tenemos dos clústeres de Hadoop y se implementan en diferentes lugares (Beijing y Xi'an), y todos los servidores de recopilación de registros están en Beijing, por lo que debemos transferir los datos de registro a Xi'an a través de la red externa, por lo que tenemos Tal despliegue:
Pronto, los datos que fluyeron al clúster Xi'an Hadoop a través de Flume encontraron un problema, más o menos que los datos originales. La razón principal de este problema es el proceso de enviar el Agente de Flume de Beijing a Xi'an Flume Collector en el caso de una red inestable En el proceso, el envío fallará o la respuesta fallará. Además, los datos casi en tiempo real no pueden satisfacer las necesidades del negocio.
Para resolver el problema de la transmisión de datos en tiempo real a través de la red externa y el negocio en tiempo real, existe la arquitectura actual:
-
Presente Kafka e impleméntelo con el servidor de recopilación de registros en la misma sala de computadoras en Beijing;
-
Flume Agent en cada servidor de recopilación de registros envía datos a Kafka a través de la intranet;
-
El primer consumidor de Kafka, Flume en Beijing Gateway, es responsable de consumir datos de Kafka y luego transmitirlos al clúster Hadoop de Beijing;
-
El segundo consumidor de Kafka, Flume en Xi'an Gateway, es responsable de consumir datos de Kafka y luego transmitirlos al clúster Xi'an Hadoop; aquí está Xi'an Flume que se conecta a Kafka en Beijing a través de una red externa para extraer datos activamente si la red es inestable Luego, la extracción actual del lote falla, como máximo una vez, los datos no ingresarán al canal Flume ni fluirán a HDFS. Por lo tanto, este método no causará pérdida o duplicación de datos en el caso de una red inestable;
-
El tercer consumidor de Kafka, el módulo de computación en tiempo real en el portal de Beijing, se describirá más adelante;
-
El enésimo consumidor de Kafka, otros;
Partición de datos y copia en Kafka
Bajo esta arquitectura, Kafka se convierte en un proveedor unificado de datos de registro, lo cual es muy importante. Actualmente tenemos 4 nodos Broker, cada tema especifica 4 particiones en el momento de la creación, y el número de copias es 2;
Cuando los datos ingresan a la partición Kafka, el interceptor de Flume se usa para extraer la identificación de usuario del registro y luego tomar el módulo a través de HASH para transmitir los datos a la partición Kafka correspondiente. De esta manera, por un lado, completa el equilibrio de carga simple, por otro lado, asegura que los mismos datos de usuario estén en la misma partición, lo que proporciona una gran comodidad para las estadísticas del módulo de cálculo en tiempo real detrás.
Uso del interceptor de canales
En todo el proceso, se utiliza el mismo Interceptor Flume (Interceptor Regex Extractor) en dos lugares, que es extraer datos del mensaje en Flume Source y agregarlo al Encabezado para que Sink lo use;
1. Uno es Flume Source implementado en LogServer. Extrae la identificación del usuario del registro original y la agrega al Encabezado. Antes de que Flume Sink (Kafka Sink) vuelva a entrar en Kafka, toma la identificación del usuario del Encabezado y luego Al aplicar las reglas de partición, escriba este mensaje en la partición correspondiente de Kafka;
2. Otro lugar es la Fuente Flume desplegada en Xi'an. Después de leer el mensaje de Kafka, extrae el campo de tiempo del mensaje y lo agrega al Encabezado. El siguiente Sumidero Flume (HDFS Sink) lee la hora en el Encabezado , Según la hora del mensaje, escriba los datos en los directorios y archivos correspondientes de HDFS.
Si solo se usa la hora actual para determinar el directorio HDFS y el nombre del archivo en el sumidero HDFS, esto causará una pequeña cantidad de datos que no se escriben en el directorio y archivo correctos, por ejemplo: 8:59:59 en el registro puede estar Es normal escribir en el directorio y archivo de las 9 en punto en HDFS, porque los datos originales se transmiten a Flume en Xi'an a través de la red externa a través de Kafka, y hay un retraso de unos segundos.
Canal de equilibrio de carga del consumidor y tolerancia a fallas
Flume desplegado en Beijing, usando Kafka Source para leer datos de Kafka al clúster Hadoop de Beijing, el mismo es el caso en Xi'an, cuando consumimos las mismas noticias de Topic, iniciamos dos Agentes Flume en dos máquinas, y configuramos El grupo de consumo unificado (group.id), de acuerdo con el mismo tema en Kafka, un mensaje solo puede ser consumido por un consumidor en el mismo grupo de consumo, por lo tanto, un mensaje en Kafka solo será utilizado por uno de los dos Agentes Flume Consumo, si un Agente Flume se cuelga, el otro consumirá todos los mensajes; si desea aprender Big Data sistemáticamente, puede unirse a la tecnología de Big Data para conocer la deducción : 522189307
De esta forma, el equilibrio de carga y la tolerancia a fallas también se realizan en el lado del consumidor de HDFS.
Módulo de cálculo en tiempo real
En la actualidad, nuestro negocio de cálculo en tiempo real es relativamente simple, lo que es similar a contar PV y UV de acuerdo con diferentes dimensiones. Por ejemplo: estadísticas en tiempo real de los números acumulados de PV, UV e IP de un sitio web para el día . En la actualidad, el programa JAVA que desarrollamos directamente utiliza streamlib para contar estos indicadores. Los indicadores que deben deduplicarse, como los números UV e IP, tienen un error dentro del 2%. Aceptable
El módulo de cálculo en tiempo real utiliza la API de bajo nivel de Kafka. Para cada tema, se utilizan hilos con el mismo número de particiones para el procesamiento. Cada hilo consume una partición de datos. Dado que los datos entran en la partición de Kafka, pasan las reglas correspondientes. Partición, por lo que los datos del mismo usuario estarán en la misma partición;
Además, cada hilo mantendrá sus propias compensaciones actuales en Redis, por ejemplo: en el escenario comercial de calcular los indicadores acumulativos en tiempo real en tiempo real, registre las compensaciones actuales en Redis a 0 días todos los días, de modo que si el programa de cálculo en tiempo real se cuelga, la próxima vez Al inicio, lea las compensaciones del día de Redis, vuelva a leer y calcule todos los mensajes del día.
Debido a que nuestras necesidades son indicadores estadísticos en tiempo real acumulados en el día, y podemos aceptar un cierto error, entonces se utiliza este método. Si necesita calcular con precisión el indicador de deduplicación acumulada, es posible que necesite usar otros métodos, tales como: estadísticas precisas del número de usuarios acumulados en tiempo real en el día. Un método simple es usar un contador en HBase para cooperar.
Otros consumidores de datos en tiempo real
Si necesita estadísticas en tiempo real de PV, UV y otros indicadores en un corto período de tiempo (como diez minutos o una hora), puede usar SparkStreaming para completarlo, lo cual es relativamente simple. Si usa Spark Streaming solo para completar las estadísticas de deduplicación acumuladas para una gran cantidad de datos en un día, todavía no sé cuál es una buena solución.
Además, OLAP en tiempo real también se puede utilizar como aplicaciones de consumo en tiempo real de Kafka, como Druid.
