Construya un almacén de datos en tiempo real basado en Flink sql
Diagrama de arquitectura de almacén fuera de línea:
Diagrama de arquitectura de almacén en tiempo real:
Actualmente, las tablas de dimensiones en tiempo real y los datos de la capa DM se almacenan en hbase, real -time public**** La capa se almacena en Kafka y los registros continuos se escriben en HDFS (se utiliza principalmente para verificar datos). De hecho, hay mucho trabajo que se puede hacer aquí. El clúster Kafka, el clúster flink y el clúster hbase son independientes entre sí, lo que plantea ciertos desafíos para la estabilidad de todo el almacén de datos en tiempo real.
Para que un almacén de datos se convierta en un sistema y un activo, no puede prescindir de la división de dominios de datos. Por lo tanto, en referencia a la idea del almacén de datos fuera de línea, exploramos el almacén de datos en tiempo real. En teoría, se puede realizar fuera de línea y en tiempo real. A juzgar por los resultados obtenidos hasta ahora, la división de los dominios de datos es aproximadamente la misma que fuera de línea, incluido el dominio de tráfico, el dominio de transacciones, el dominio de marketing, etc. Por supuesto, esto implica el diseño, desarrollo e implementación de tablas de dimensiones, tablas de hechos de transacciones múltiples, tablas de instantáneas acumulativas y tablas de instantáneas periódicas.
Las tablas de dimensiones también son una parte integral de todo el almacén de datos en tiempo real. A juzgar por la construcción actual de todo el almacén de datos en tiempo real, la tabla de dimensiones tiene las características de un gran volumen de datos pero pequeños cambios. Hemos intentado crear una tabla de dimensiones de productos en tiempo real o una tabla de dimensiones de miembros en tiempo real. Toda la plataforma, pero este tipo de tabla de dimensiones es demasiado compleja, por lo que a continuación se presenta una introducción a este tipo de tabla de dimensiones. También hay una tabla de dimensiones relativamente simple. Este tipo de dimensión puede corresponder a una única tabla mysql en el sistema empresarial, o una tabla que se puede generar simplemente realizando ETL en varias tablas. tiempo. Los siguientes son varios puntos clave de implementación:
La siguiente figura es el diagrama de la arquitectura de sincronización de datos fuera de línea:
El acceso a datos en tiempo real es en realidad el mismo en la arquitectura subyacente, pero es A diferencia del lado de Kafka, es lo mismo: flink UDTF se usa para análisis en tiempo real, mientras que sin conexión se lleva a HDFS con regularidad (actualmente cada hora) usando camus y luego se carga con regularidad. Los datos HDFS se cargan en tablas de colmena, lo que permite el acceso a datos sin conexión. El acceso a datos en tiempo real utiliza flink para analizar los datos de Kafka y luego los escribe en Kafka.
Dado que los datos sin conexión se han estado ejecutando de manera estable durante mucho tiempo, los datos de acceso en tiempo real se pueden comparar con los datos sin conexión, pero los datos sin conexión son datos de colmena por horas y los datos en tiempo real se almacenan en Kafka y no pueden compararse directamente, por lo que Para realizar el procesamiento relacionado, use parpadear para escribir registros continuos de HDFS para escribir datos de Kafka en HDFS, y luego use un temporizador por hora para configurar la tabla de colmena. Al configurar tablas de colmena, los archivos en HDFS se pueden cargar cada hora para obtener datos en tiempo real.
Después de completar los dos puntos anteriores, hay una cosa más que debe considerarse. Todas son tareas por horas. ¿Qué campos se deben utilizar en este punto de estancamiento? Lo primero que debe asegurarse es que los campos de tiempo de la tarea fuera de línea y las tarjetas de tarea en tiempo real deben ser consistentes; de lo contrario, definitivamente ocurrirán problemas. Actualmente, camus se usa sin conexión para extraer datos de Kafka a HDFS, y las tareas por horas usan el campo de tiempo nginx_ts para verificar si hay puntos atascados. Este campo es el momento en que el servidor nginx informa el registro.
El acceso a datos en tiempo real utiliza flink para consumir datos de Kafka, los escribe en HDFS en forma de registros continuos y luego carga el archivo HDFS en la tabla de colmena creada para obtener los datos. Aunque esta colmena también es una partición secundaria de día/hora. , la tabla fuera de línea se basa en nginx_ts para particionar los puntos atascados, pero la tabla de colmena en tiempo real se divide según el momento en que la tarea comienza a cargarse, pero la tabla de colmena en tiempo real se divide según el momento cuando la tarea comienza a cargar el archivo, esto es diferente Filtrado directo Habrá algunas diferencias al comparar los datos de partición y fuera de línea. El enfoque debe ser filtrar primero el rango de particiones y luego filtrar el intervalo de tiempo de nginx_ts. Es razonable compararlo con datos fuera de línea.
Actualmente, la principal latencia en la capa de acceso a datos en tiempo real reside en el análisis de la función UDTF. La función UDTF en tiempo real se desarrolla en función del formato de registro informado y puede completar la función de análisis de registros.
El diagrama de flujo de análisis es el siguiente:
El diagrama de tasa de análisis es el siguiente:
La cifra no está en el pico del volumen de datos interceptados, pero se basa en los 800 registros/segundo actuales. La velocidad de análisis es de aproximadamente 1,25 ms para 1 registro.
El número de núcleos asignados por el recurso flink de la tarea actual es 1. Suponiendo que la velocidad de análisis. es de 1,25 ms para un registro, la velocidad máxima es de 1,25 ms para un registro y luego la velocidad de análisis es de 1,25 ms para un registro.
Presente el estado actual de las tablas de dimensiones fuera de línea. Tomando la tabla de dimensiones del producto como ejemplo, hay casi cientos de millones de registros en todos los ámbitos. La lógica de cálculo proviene de la tabla de datos del 40-50. La lógica de cálculo de la capa ods es bastante compleja. Si la tabla de dimensiones en tiempo real aún está fuera de línea, los costos de desarrollo y mantenimiento serán muy altos y también será un gran desafío para la tecnología. Además, actualmente no es necesario exigir que los atributos de dimensión sean 100% precisos y también es necesario garantizar que los atributos de dimensión se puedan utilizar en tiempo real. No existe ningún requisito de precisión de los atributos de anotación. Por lo tanto, la tabla de dimensiones en tiempo pseudo-real está lista para generarse a las 24:00 de ese día, y la tabla de dimensiones de ese día será utilizada por la capa de **** pública en tiempo real al día siguiente, es decir , el modelo T-1. La lógica de cálculo de la tabla de dimensiones en tiempo pseudo-real se refiere a la tabla de dimensiones fuera de línea, pero para garantizar la salida antes de las 24:00, es necesario simplificar la lógica de cálculo fuera de línea y eliminar algunos campos poco comunes para garantizar que la tabla de dimensiones pseudo-en tiempo real La tabla de dimensiones en tiempo real se puede generar más rápido.
Diagrama de flujo de cálculo de la tabla de dimensiones en tiempo real:
Actualmente, flink se utiliza como el principal motor de cálculo en tiempo real de la empresa, la memoria se utiliza como backend de estado y los puntos de control se realizan en intervalos fijos de 30 segundos, y HDFS se utiliza como componente de almacenamiento de punto de control. El punto de control también es una base importante para restaurar el estado después de reiniciar la tarea. Las personas que están familiarizadas con flink deben saber que la memoria se usa como backend de estado. Esta memoria es la memoria de almacenamiento dinámico de la JVM. Después de todo, es algo limitado. Si se usa incorrectamente, OOM es común. memoria si se completa Cálculos generales.