La piedra angular de Flink: el modelo de flujo de datos de Google
El modelo de flujo de datos fue propuesto por un grupo de ejecutivos de Google en 2015. Actualmente, existe un servicio correspondiente en Google Cloud llamado Cloud Dataflow. A través de Apache Beam, centrándose en "simplificar el procesamiento de datos por lotes y flujos", el sitio web oficial está aquí.
La idea del modelo de flujo de datos se refleja en el artículo "Modelo de flujo de datos: un enfoque práctico para equilibrar la corrección, la latencia y el costo en el procesamiento de datos desordenados, ilimitados y a gran escala". ". Es un tema largo, pero vale la pena reflexionar:
Los jefes de Google creen que cuando decimos la palabra "flujo", en realidad nos referimos a procesar datos continuos. Por el contrario, cuando nos referimos a la palabra "procesamiento por lotes", nos referimos al procesamiento de una o varias piezas de datos limitadas, es decir, "limitadas". En este artículo, preferimos usar ilimitado/limitado en lugar de streaming/por lotes, porque este último suena como la semántica de describir el motor de cálculo, mientras que el primero es una característica de los datos en sí.
El procesamiento de datos ilimitados debe generar resultados a tiempo; de lo contrario, no tendrá sentido. El resultado de salida son datos naturalmente limitados, por lo que en el modelo de flujo de datos, el procesamiento por lotes puede considerarse como un subproblema del procesamiento de flujos, con el propósito de lograr la fusión de flujos por lotes. Sin duda, esto es avanzado en comparación con la arquitectura Lambda tradicional (sitio web oficial aquí), porque esta última requiere mantener dos conjuntos diferentes de componentes para el procesamiento de flujo y por lotes, lo cual es muy engorroso.
Todos entendemos que inevitablemente se producirán varios retrasos durante la generación, recopilación y transmisión de datos, lo que significa que al procesar datos ilimitados, es probable que su orden sea diferente del orden original de la lógica empresarial. . Para dar un ejemplo simple, un usuario navega por la página de detalles de un producto a las 7:55, luego lo agrega al carrito de compras a las 7:56 y realiza un pedido en 57, pero el pedido en la cola de registro puede convertirse en "Realizar un ordenar → Agregar a compras" Coche → Explorar”.
En el procesamiento por lotes bajo la arquitectura Lambda, la posibilidad de que se produzcan problemas causados por datos desordenados suele ser muy pequeña. Sin embargo, bajo la idea de la integración del flujo de datos por lotes, es muy importante manejar correctamente los datos desordenados para garantizar la exactitud de todo el servicio de big data. Echemos un vistazo más profundo a cómo el flujo de datos aborda estos puntos clave en el tema del artículo.
En primer lugar, debemos distinguir el par de conceptos básicos más importantes en el flujo de datos, a saber, tiempo de evento y tiempo de procesamiento, que también es muy simple:
La siguiente figura muestra tiempo del evento y relación de procesamiento entre el tiempo. En un mundo ideal, los datos siempre estarían disponibles para su procesamiento de manera oportuna y las relaciones entre ellos deberían ser como lo muestran las líneas de puntos. Sin embargo, debido a la existencia de varios retrasos, la situación real está más representada por una flecha roja gruesa y habrá cierta desviación entre los dos.
Distinguir el tiempo del evento y el tiempo de procesamiento y utilizar el tiempo del evento como características de tiempo es un avance importante en el flujo de datos.
El flujo de datos descompone el problema de procesamiento de datos ilimitado anterior en cuatro subproblemas a considerar:
Esto es mucho más claro. Para resolver los cuatro subproblemas anteriores, Dataflow propuso las siguientes soluciones:
En cuanto a los problemas más básicos, por supuesto, los usuarios deben considerarlos ellos mismos. Estos tres modelos se analizan a continuación.
En los cursos de redes informáticas de la universidad todos hemos aprendido el concepto de Windows, por lo que es beneficioso para todos entenderlo.
Como se mencionó anteriormente, el procesamiento de datos ilimitados debe generar resultados a tiempo; de lo contrario, no tendrá sentido. Entonces, ¿con qué rango temporal de datos deberíamos tratar? Los datos ilimitados se pueden dividir en un número limitado de conjuntos de datos en el dominio del tiempo a través de ventanas, y luego se pueden realizar en ellos operaciones avanzadas como agrupación, agregación y conexión. La siguiente imagen muestra una ventana de tiempo de evento desordenada.
En otras palabras, el flujo de datos mejora la tupla (clave, valor) en el procesamiento de flujo tradicional a la cuádruple (clave, valor, tiempo_evento, ventana) a través del modelo de ventana.
Hay tres formas comunes de abrir ventanas, a saber, ventanas fijas/enrollables, ventanas deslizantes y ventanas de sesión, como se muestra en la siguiente figura.
La ventana fija es obviamente la más simple, como una ventana fija de 5 minutos: [7:00, 7:05], [7:05, 7.10], [7:10, 7.15), ... Las ventanas correderas son para nosotros viejas conocidas. Por ejemplo, una ventana deslizante con una duración de ventana de 65, 438+0 horas y una ventana deslizante de 65, 438+00 minutos serían los siguientes intervalos: [7:00, 8:00], [7:65, 438 +00, 8: 65, 438+00], [7: 20,
Las ventanas de diálogo son menos comunes, y eso es lo que Google ha concluido en la práctica. En términos sencillos, una clave aparece continuamente para formar una ventana. Si la clave no aparece durante un período de tiempo determinado, se dividirá en la siguiente ventana después de que vuelva a aparecer. Este método es relativamente flexible y se puede utilizar fácilmente para la detección del comportamiento del usuario, detección de anomalías, etc.
Si utilizamos el tiempo de procesamiento en lugar del tiempo del evento, no hay necesidad de considerar el modelo de activación porque los límites de la ventana no tienen nada que ver con los datos. Pero una vez que se usa el tiempo del evento, debido a que los datos llegarán tarde, los límites de la ventana se volverán borrosos, es decir, es imposible saber si los datos en la ventana han estado completamente vivos y la materialización de los resultados del disparador se vuelve un problema. Entonces aquí se introduce un concepto importante, que es la marca de agua.
Una marca de agua es esencialmente una marca de tiempo. Para una fuente de datos ilimitada, la marca de agua T significa que todos los datos T T se considerarán retrasados y luego se podrán generar. Al interpretar el tiempo del evento y el tiempo de procesamiento, la flecha roja en la figura es el tiempo real de la marca de agua.
Evidentemente la marca de agua es ideal si no hay datos retrasados o podemos tener una percepción completa de los datos de entrada. La fuente de datos ilimitada en sí misma determina que no podemos percibir completamente las características de los datos de entrada, por lo que la configuración de la marca de agua es en su mayoría heurística, es decir, según indicadores históricos, la integridad de los datos dentro de la ventana está asegurada tanto como sea posible, pero No se puede garantizar el 100% de fiabilidad. Sexo, ni demasiado rápido ni demasiado lento. Por supuesto, también se pueden utilizar métodos más simples y violentos (como marcas de agua periódicas y marcas de agua de conteo) según la situación empresarial. La ventaja es que es más flexible, pero menos fiable.
Dado que la marca de agua heurística no puede garantizar el 100 % de confiabilidad, es necesario utilizar datos posteriores para corregir la exactitud de la ventana anterior, es decir, una actualización incremental, también llamada relleno. El flujo de datos en sí define las siguientes tres estrategias de reabastecimiento:
Existen los siguientes ejemplos de entrada.
Tenga en cuenta que el tiempo del evento comienza a las 12:00 y el tiempo de procesamiento comienza a las 12:05. La línea de marca de agua ideal se muestra como una línea delgada en la figura, y la marca de agua real es una línea gruesa, lo que indica la presencia de datos posteriores.
La siguiente figura es un diagrama de flujo de procesamiento de microlotes similar a Spark Flow. Como puede verse, el procesamiento se basa en el tiempo de procesamiento y no tiene nada que ver con el tiempo del evento.
La siguiente imagen es una ventana fija + mecanismo de transmisión similar a Flink.
En esta imagen podemos ver el problema con las marcas de agua heurísticas: los datos 9 en realidad no llegaron cuando se activa la marca de agua, porque la marca de agua es demasiado rápida. Los datos 7 no se generarán hasta que 8 active la marca de agua, lo que significa que la marca de agua es demasiado lenta.
Escribir mientras ves fútbol, poco entusiasta, nivel limitado, que así sea~