Sistema de gestión de flujos de datos

La idea detrás de las técnicas de compresión es mantener solo un resumen de los datos, pero no todos los puntos de datos (en bruto) del flujo de datos. Los algoritmos abarcan desde la selección de puntos de datos aleatorios, denominada muestreo, hasta la generación de resúmenes mediante histogramas, ondículas o gráficos. Un ejemplo sencillo de compresión es el cálculo continuo de un promedio. En lugar de memorizar cada punto de datos, el resumen solo contiene la suma y la cantidad de elementos. El promedio se puede calcular dividiendo la suma entre la cantidad. Sin embargo, cabe mencionar que los resúmenes no pueden reflejar los datos con precisión. Por lo tanto, un procesamiento basado en resúmenes puede producir resultados inexactos.

En lugar de utilizar sinopsis para comprimir las características de flujos de datos completos, las técnicas de ventana solo consideran una parte de los datos. Este enfoque se basa en la idea de que solo los datos más recientes son relevantes. Por lo tanto, una ventana recorta continuamente una parte del flujo de datos, por ejemplo, los últimos diez elementos, y solo considera estos elementos durante el procesamiento. Existen diferentes tipos de ventanas, como las ventanas deslizantes, similares a las listas FIFO , o las ventanas rotativas, que recortan partes disjuntas. Además, las ventanas también se pueden diferenciar en ventanas basadas en elementos, por ejemplo, para considerar los últimos diez elementos, o ventanas basadas en el tiempo, por ejemplo, para considerar los últimos diez segundos de datos. También existen diferentes enfoques para implementar ventanas. Por ejemplo, hay enfoques que utilizan marcas de tiempo o intervalos de tiempo para ventanas de todo el sistema o ventanas basadas en búferes para cada paso de procesamiento. El procesamiento de consultas con ventanas deslizantes también es adecuado para su implementación en procesadores paralelos, aprovechando el paralelismo entre diferentes ventanas o dentro de cada extensión de ventana. ^{[ 1 ]}

La formulación de consultas se realiza principalmente mediante lenguajes declarativos como SQL en los sistemas de gestión de bases de datos (DBMS). Dado que no existen lenguajes de consulta estandarizados para expresar consultas continuas, existen numerosos lenguajes y variantes. Sin embargo, la mayoría se basan en SQL , como el Lenguaje de Consulta Continua (CQL), StreamSQL y ESP . También existen enfoques gráficos donde cada paso del procesamiento se representa mediante un recuadro y el flujo del procesamiento se expresa mediante flechas entre los recuadros.

El lenguaje depende en gran medida del modelo de procesamiento. Por ejemplo, si se utilizan ventanas para el procesamiento, es necesario expresar la definición de una ventana. En StreamSQL , una consulta con una ventana deslizante para los últimos 10 elementos tiene el siguiente aspecto:

SELECCIONAR PROMEDIO ( precio ) DE examplestream [ TAMAÑO 10 AVANCE 1 TUPLES ] DONDE valor > 100.0​​

Este flujo calcula continuamente el valor promedio de "precio" de las últimas 10 tuplas, pero solo considera aquellas tuplas cuyos precios son mayores que 100.0.

En el siguiente paso, la consulta declarativa se traduce en un plan de consulta lógico . Un plan de consulta es un grafo dirigido donde los nodos son operadores y las aristas describen el flujo de procesamiento. Cada operador en el plan de consulta encapsula la semántica de una operación específica, como el filtrado o la agregación. En los sistemas de gestión de datos que procesan flujos de datos relacionales, los operadores son iguales o similares a los del álgebra relacional , de modo que existen operadores para selección, proyección, unión y operaciones de conjuntos. Este concepto de operador permite un procesamiento muy flexible y versátil en un sistema de gestión de datos.

El plan de consulta lógica se puede optimizar, lo cual depende en gran medida del modelo de transmisión de datos. Los conceptos básicos para optimizar consultas continuas son los mismos que en los sistemas de bases de datos . Si existen flujos de datos relacionales y el plan de consulta lógica se basa en operadores relacionales del álgebra relacional , un optimizador de consultas puede utilizar las equivalencias algebraicas para optimizar el plan. Esto puede implicar, por ejemplo, trasladar los operadores de selección a las fuentes, ya que no son tan intensivos computacionalmente como los operadores de unión.

Además, existen técnicas de optimización basadas en costos, como en los sistemas de gestión de bases de datos (DBMS), donde se elige el plan de consulta con el menor costo entre diferentes planes equivalentes. Un ejemplo es la elección del orden de dos operadores de unión sucesivos. En los DBMS, esta decisión se basa principalmente en ciertas estadísticas de las bases de datos involucradas. Sin embargo, dado que los datos de un flujo de datos se desconocen de antemano, no existen tales estadísticas en un sistema de gestión de bases de datos (DSMS). No obstante, es posible observar un flujo de datos durante un tiempo determinado para obtener algunas estadísticas. Utilizando estas estadísticas, la consulta también se puede optimizar posteriormente. Por lo tanto, a diferencia de un DBMS, algunos DSMS permiten optimizar la consulta incluso durante la ejecución. En consecuencia, un DSMS requiere estrategias de migración de planes para reemplazar un plan de consulta en ejecución por uno nuevo.

Dado que un operador lógico solo se encarga de la semántica de una operación y no incluye ningún algoritmo, el plan de consulta lógico debe transformarse en una contraparte ejecutable. Esto se denomina plan de consulta físico. La distinción entre un plan de operador lógico y uno físico permite más de una implementación para el mismo operador lógico. La operación de unión, por ejemplo, es lógicamente la misma, aunque puede implementarse mediante diferentes algoritmos, como una unión de bucle anidado o una unión de ordenación y fusión . Cabe destacar que estos algoritmos también dependen en gran medida del flujo de datos y del modelo de procesamiento utilizados. Finalmente, la consulta está disponible como un plan de consulta físico.

Dado que el plan de consulta físico consta de algoritmos ejecutables, puede ejecutarse directamente. Para ello, se instala en el sistema. La parte inferior del gráfico (del plan de consulta) se conecta a las fuentes de entrada, que pueden ser, por ejemplo, conectores a sensores. La parte superior del gráfico se conecta a los sumideros de salida, que pueden ser, por ejemplo, una visualización. Como la mayoría de los DSMS se basan en datos, una consulta se ejecuta enviando los elementos de datos entrantes desde la fuente a través del plan de consulta hasta el sumidero. Cada vez que un elemento de datos pasa por un operador, este realiza su operación específica sobre el elemento y reenvía el resultado a todos los operadores sucesivos.