¿Cómo desarrollar una suite SQL estándar para un proceso de transmisión sólido?

En la era actual de la digitalización, las empresas necesitan análisis y gestión de datos en tiempo real para mantenerse a la vanguardia. SQL ha estado a la vanguardia de este tipo de análisis y gestión de transmisión de datos. Sin embargo, existen ciertas limitaciones, lo que limita el proceso de transmisión.

Las empresas utilizan una combinación de tablas y flujos junto con datos históricos para realizar un análisis de datos para varias aplicaciones, como la toma de decisiones y otras operaciones comerciales. A pesar del inicio del análisis de datos y la inteligencia artificial, SQL sigue siendo uno de los principales lenguajes de consulta utilizados para los procesos de transmisión de datos.

Entonces, aquí vamos a usar tres metodologías diferentes para lograr que el proceso de transmisión de SQL sea más eficiente a través de:

• Relaciones variables en el tiempo
• Semántica de tiempo de evento
• Controles de materialización

Pero, antes de aprovechar estas metodologías, conozcamos los enfoques actuales hacia SQL:

• Apache Spark: 
  Construida sobre el optimizador y el motor de ejecución de Spark SQL, esta API declarativa es en realidad una API de conjunto de datos de Spark. Normalmente, los programas de conjuntos de datos se ejecutan en flujos de datos finitos. La transmisión por secuencias para Dataset API se conoce popularmente como transmisión estructurada . Las consultas de transmisión estructuradas se evalúan a través de un motor de ejecución de microlotes que procesa los flujos de datos en pequeños lotes y encuentra garantías de tolerancia a fallas.
• KSQL:
  se basa en flujos de Kafka, que es un marco de procesamiento de flujo desarrollado bajo el proyecto Apache Kafka. KSQL es un contenedor declarativo que cubre los flujos de Kafka y desarrolla una sintaxis de tipo SQL personalizada para declarar flujos y tablas. Está más centrado en la semántica de la vista materializada.
• Apache Flink:
  está hecho de dos API relacionales: API de tabla de estilo LINQ y SQL. Utiliza una representación de plan lógico común y una calcita de Apache optimizada para consultas de ambas API relacionales. Luego, la ejecución se lleva a cabo como un proceso por lotes o de transmisión.
• Apache Beam:
  Está específicamente desarrollado teniendo en cuenta la optimización de la unificación del haz de procesamiento de datos acotados y no acotados. Utiliza un subconjunto de semántica para la ejecución de los flujos de datos.
• Apache Calcite:
  Es un popular analizador de flujo de SQL en Flink SQL y Beam SQL. Analiza, optimiza y admite la semántica de procesamiento de flujo. 

  Ahora, pasemos a tres nuevos enfoques para la transmisión de SQL.

• Relaciones Variantes en el Tiempo:
  Esta metodología se enfoca en el elemento “Tiempo” . Siempre que estemos tratando con las relaciones de transmisión, debemos considerar las relaciones de tiempo relativas que varían con el tiempo. Para ello, podemos utilizar una relación variable en el tiempo (TVR) que es un tipo de relación, cuyos contenidos cambian con el tiempo. 

  Los TVR pueden codificarse o materializarse de muchas maneras, especialmente como una secuencia de relaciones clásicas o como una secuencia de operaciones «INSERTAR» y «ELIMINAR». Estas dos codificaciones son duales entre sí y corresponden a las tablas y flujos. Si bien la dualidad de las codificaciones puede ser un problema, tenemos la intención de utilizarlo como una ventaja.

  Podemos aprovechar el hecho de que tanto las secuencias como las tablas son representaciones de un objeto de semántica común. Aunque podemos tratar TVR de manera uniforme, utilizando los cambios en la transmisión en sí, TVR puede optimizar y materializar las transmisiones para obtener mejores resultados en las consultas.

• Semántica del tiempo del evento: 
  en muchos casos se supone que los datos asumidos están de acuerdo con el tiempo del evento y esto no es cierto para el desarrollo de aplicaciones móviles, sistemas distribuidos o datos de archivo fragmentados. A menudo, los datos se agilizan de acuerdo con el momento del evento y, sin embargo, el progreso de la lógica de ejecución no cumple con el mismo.

  Esto se debe al hecho de que una hora de tiempo de procesamiento no tiene relación con una hora de tiempo de evento. Por lo tanto, se debe tener en cuenta el tiempo del evento para lograr resultados correctos. El sistema STREAM contabiliza la hora del evento e incluye una característica llamada latidos que almacena en búfer los datos que no están en el orden de la hora del evento y los introduce en el procesador de consultas. Esto permite sesgar la marca de tiempo al inducir latencia. Mientras que el sistema Millwheel utiliza marcas de agua, que pueden calcular los datos que están desordenados junto con los metadatos.

  Sin embargo, la mejor práctica es una combinación de marcas de tiempo y marcas de agua, ya que juntas pueden permitir el cálculo correcto de la hora del evento. Estos cálculos se realizan agrupando intervalos de tiempo y ejecutándolos sin recursos ilimitados. 

• Controles de materialización: 
  este enfoque proporciona control sobre cómo se representan las relaciones cuando se materializan las filas. En el primer enfoque, podemos usar registros de cambios de transmisión que capturan las diferencias de elemento a elemento entre dos versiones de la relación y, además, usar la secuencia de codificación de INSERTAR y ELIMINAR para mutar los TVR. 

  Otro enfoque es el « retraso de la materialización « : este enfoque se utiliza modelando las tablas y los flujos como TVR y la relación resultante lograda es TVR.

Un ejemplo basado en el punto de referencia NEXmark para consultas sobre flujos de datos:

Cuando la consulta monitorea los artículos de precio más alto actualmente en subasta con un resultado relativo de tiempo de cada 10 minutos, obtiene un resultado con la oferta más alta.

Una consulta en CQL:

SELECT
     Rstream ( B . price, B . itemid )
FROM
     Bid [ RANGE 10 MINUTE SLIDE 10 MINUTE ] B
WHERE
B . price =
       ( SELECT MAX ( B1 . price ) FROM BID
       [ RANGE 10 MINUTE SLIDE 10 MINUTE ] B1 );

Una consulta en SQL:

SELECT
MaxBid . wstart, MaxBid . wend,
Bid . bidtime, Bid . price, Bid . itemid
FROM
Bid,
( SELECT
     MAX ( TumbleBid . price ) maxPrice,
     TumbleBid . wstart wstart,
     TumbleBid . wend wend
FROM
     Tumble (
         data = > TABLE ( Bid ),
         timecol = > DESCRIPTOR ( bidtime )
         dur = > INTERVAL '10 ' MINUTE ) TumbleBid
 GROUP BY
     TumbleBid . wend ) MaxBid
  
WHERE
     Bid . price = MaxBid . maxPrice AND
     Bid . bidtime >= MaxBid . wend
                  - INTERVAL '10 ' MINUTE AND
     Bid . bidtime < MaxBid . wend ;

Conclusiones: 
a diferencia de los enfoques anteriores, este enfoque utiliza marcas de tiempo como datos explícitos y las filas en el flujo de ofertas no aparecen en orden de tiempo de oferta . Tumble es un TVR que asigna cada secuencia de ofertas con intervalos de 10 minutos que contienen bidtime . 

Con el ejemplo anterior, podemos ver que a medida que la relación de oferta evoluciona con el tiempo y se agregan nuevos elementos con el tiempo, la relación definida por la consulta también evoluciona con ella. Por lo tanto, podemos usar el enfoque anterior e inducir un TVR que puede evolucionar con los cambios en los elementos de una consulta.