Por: David Anderson, Principal Software Practice Lead en Confluent Flink SQL es un potente motor diseñado para procesar datos en tiempo real, utilizando el lenguaje SQL familiar y sus conceptos relacionales subyacentes. Este ha sido durante mucho tiempo una solución efectiva para muchos dominios de aplicaciones, especialmente las pipelines ETL y las cargas de trabajo analíticas, pero hasta ahora Flink SQL carecía de características clave a menudo necesarias para las aplicaciones orientadas a eventos. Con los desarrollos recientes aquí descritos, las APIs relacionales de Apache Flink -es decir, Flink SQL y la API de Tabla- han madurado hasta el punto de que aprovechar sus poderosas abstracciones y operadores incorporados ya no requiere comprometer el acceso a los primitivos de procesamiento de flujo de bajo nivel de Flink. Todo lo que se dice aquí se aplica igualmente tanto a Flink SQL como a la API de la Tabla. Ambos se encuentran en la parte superior del mismo tiempo de ejecución - los conceptos y las capacidades fundamentales son los mismos - solo se acceden desde Java o Python, en lugar de SQL, si elige usar la API de la Tabla. Uso de casos Estas APIs relacionales son especialmente adecuadas para dos categorías amplias de aplicaciones. Agentic AI Las aplicaciones modernas de IA a menudo requieren acceso a información dinámica en tiempo real. Flink SQL facilita la IA de agentes al hacer que sea fácil combinar flujos de eventos en tiempo real con insights de agentes, modelos y servicios. Esto significa que a medida que fluyen los datos a través de Flink, se puede enriquecer o validar consultando estos servicios en tiempo real, proporcionando un contexto fresco y preciso para la toma de decisiones de IA o la inferencia de modelos. Shift left En el mundo del procesamiento de datos, "desplazamiento a la izquierda" se refiere a realizar transformaciones y enriquecimientos de datos lo antes posible en el flujo de datos. Las APIs relacionales de Flink sobresalen aquí al permitir transformaciones en tiempo real y enriquecimiento con otros conjuntos de datos. Familiaridad combinada con novedad Tradicionalmente, SQL se ha utilizado tanto para casos de uso operativo como analítico. Flink SQL toma los conceptos y semánticas bien pensados desarrollados para el procesamiento de transacciones en línea (OLTP) y el procesamiento analítico en línea (OLAP), y los expande para satisfacer las demandas de las aplicaciones de procesamiento de flujo en tiempo real. The relational algebra remains the same Los principios fundamentales de la álgebra relacional, que forman la base de SQL, se conservan completamente en Flink SQL. Mientras que las tablas SQL tradicionales son estáticas, Flink SQL introduce el concepto de tablas dinámicas, que son representaciones lógicas de flujos de datos continuos y ilimitados. Tables: Las agregaciones (por ejemplo, 'COUNT', 'SUMO', 'AVG') se aplican a los flujos, proporcionando resúmenes en tiempo real de los datos. Aggregations: Flink SQL soporta varias operaciones de junta, permitiendo la combinación de datos de diferentes fuentes de transmisión. Estos pueden variar desde las juntas internas y externas tradicionales hasta las juntas temporales más especializadas. Joins: Cada declaración de Flink SQL calcula continuamente el resultado de una consulta en los flujos, permitiendo el acceso inmediato a los datos frecuentemente solicitados. Continuous queries (materialized views): New challenges and ideas for stream processing Por otro lado, la aplicación de estos conceptos relacionales al mundo dinámico del procesamiento de flujo introduce algunas nuevas consideraciones: Las operaciones de procesamiento de flujo a menudo necesitan mantener el "estado" - información sobre eventos pasados - para realizar sus cálculos. Por ejemplo, una agrupación necesita seguir el resultado parcialmente acumulado, y una unión puede tener que buffer los registros de un flujo mientras espera que los registros coincidan con otros. Los desarrolladores que usan Flink SQL (o la API de tabla) deben considerar cuidadosamente la gestión del estado, ya que el estado excesivo puede afectar el rendimiento y el consumo de recursos. Thinking about state: En el procesamiento de flujo, los eventos pueden llegar fuera de orden o con retrasos. Los marcadores de agua son un concepto crucial en Flink SQL que ayuda a lidiar con estas irregularidades al proporcionar una noción de "completitud" para los flujos. Los marcadores de agua definen un umbral después del cual Flink asume que no llegarán más eventos con un marcador de tiempo anterior, lo que permite agregar ventanas consistentes y resultados oportunos. Watermarks: Flink SQL incluye una serie de versiones temporales especiales de operaciones de estado, tales como agregaciones con ventana de tiempo, y juntas de ventana, que se basan en señales de agua para saber cuándo sus resultados están listos para ser emitidos (y cuándo el estado que estaban manteniendo puede ser liberado). Desarrollo reciente Los desarrollos recientes están haciendo que estas APIs relacionales sean más convincentes que nunca. Flink SQL y la API de Tabla son altamente extensibles a través del uso de Funciones Definidas por el Usuario (UDFs). Estas permiten que Java o Python se utilicen para implementar lógica personalizada que no puede expresarse directamente en SQL. Son un nuevo sabor de UDF que acaba de ser introducido como parte de Flink 2.1. A diferencia de los UDF tradicionales, los PTFs pueden procesar tablas enteras (flujos) de una manera sofisticada, utilizando los servicios de estado y temporizador gestionados de Flink. Process Table Functions (PTFs) Conectar con Flink SQL Las operaciones de unión ilustran las similitudes y diferencias cruciales en las APIs relacionales de Flink en comparación con las bases de datos SQL tradicionales.Esta sección utiliza algunos ejemplos prácticos para explorar cómo los conceptos presentados anteriormente pueden aplicarse a aplicaciones reales que usan joins. Considere, por ejemplo, un negocio en línea de procesamiento de pedidos y pagos, donde cada pago está relacionado por una referencia clave extranjera (el ordenId) a un pedido. pedidos y pagos son temas de Kafka de Apache, y queremos crear un nuevo tema Kafka para pedidos pagados que se utilizará para la ejecución de pedidos. Una solución sencilla que parece funcionar es CREATE TABLE PaidOrders AS (
  SELECT
    o.id AS orderId,
    p.id AS paymentId
  FROM
    Orders o INNER JOIN Payments p ON o.id = p.orderId
);
 Por supuesto, en una aplicación real sacaríamos un montón más de información a la salida, como el ID del cliente, su dirección de envío y los ID de los productos que se pedían. En el discurso de la comunidad de Flink, una unión como esta se llama una "unión regular" (lo que significa que no hemos hecho nada especial para permitir que Flink la ejecute de manera más eficiente).Y cuando se ejecuta por el tiempo de ejecución de streaming de Flink SQL, las uniones regulares pueden ser sorprendentemente caras. De hecho, basándose en nuestro conocimiento de cómo esta empresa ejecuta su negocio, podríamos saber que cada pedido tendrá como máximo un pago correspondiente, por lo que no hay necesidad de que Flink almacene un pedido más allá del punto donde se ha procesado su pago. Una de las cosas que podríamos hacer para que este ingreso sea menos costoso sería asumir que los pagos siempre ocurrirán dentro de dos horas de la orden (por ejemplo): CREATE TABLE PaidOrders AS (
  SELECT
    o.id AS orderId,
    p.id AS paymentId
  FROM
    Orders o INNER JOIN Payments p ON o.id = p.orderId
  WHERE
    p.paymentTime BETWEEN o.orderTime AND o.orderTime + INTERVAL '2' HOUR
);
 Esto limitará el tiempo que los pedidos se almacenan en el estado de ejecución de Flink, pero no es un enfoque muy satisfactorio.Por un lado, preferiríamos liberar el estado de un pedido tan pronto como se coincida con un pago, y por otro lado, algunos pagos podrían retrasarse por más de 2 horas. Desafortunadamente, el enriquecimiento de mensajes uno a uno que idealmente querríamos hacer en este caso no se puede expresar directamente usando conceptos SQL estándar. Aquí hay un ejemplo simplificado de lo que esto podría parecer: // Function that buffers one object from each side
// of the join to produce exactly one result.
public static class OrderPaymentJoin
  extends ProcessTableFunction<JoinResult> {

  public void eval(
    Context ctx,
    @StateHint(name = "result") JoinResult result,
    @ArgumentHint(SET_SEMANTIC_TABLE) Order order,
    @ArgumentHint(SET_SEMANTIC_TABLE) Payment payment
  ) {

    if (order != null) {
      if (result.orderId != null) {
        // Skip duplicates.
        return;
      } else {
        // Save the order and wait 
        // for the matching payment.
        result.orderId = order.id;
      }
    }

    if (payment != null) {
      if (result.paymentId != null) {
        // Skip duplicates.
        return;
      } else {
        // The order will precede the payment, but
        // we cannot guarantee the order will be
        // processed first. Save the payment
        // and wait for the matching order.
        result.paymentId = payment.id;
      }
    }
  
    if (result.orderId != null && 
        result.paymentId != null) {
      // Send out the final join result
      // and clear the state.
      collect(result);
      ctx.clearState("result");
    }
  }
}
 Con este PTF en su lugar, nuestra consulta se convierte en CREATE TABLE PaidOrders AS (
  SELECT
    orderId,
    paymentId
  FROM
    OrderPaymentJoin(
      order => TABLE(Orders) PARTITION BY order_id,
      payment => TABLE(Payments) PARTITION BY order_id 
    )
);
 En la práctica, este ejemplo simplificado podría extenderse para hacer algo sobre la posibilidad de acumular un número cada vez mayor de pedidos no comparados (pedidos que nunca reciben pagos). Otros desarrollos emocionantes Native support for ML models FLIP-437 (incluido en Flink 2.0) agregó soporte para modelos de aprendizaje automático como ciudadanos de primera clase en Flink SQL. Disaggregated state backend La comunidad de Flink está desarrollando un enfoque más nativo de la nube para la gestión del estado, lo que finalmente hará más práctico para que las aplicaciones utilicen enormes cantidades de estado. Esto nunca eliminará la necesidad de pensar en los requisitos del estado de sus aplicaciones de streaming, pero cambiará significativamente la forma en que debe ver los compromisos involucrados. Para los usuarios de las API de SQL y Tabla de Flink, experimentar con esto es simplemente una cuestión de cambiar su configuración de tiempo de ejecución. Para más detalles. Documentación Semi-structured types Los datos semiestructurados ofrecen mayor flexibilidad, como permitir que se añaden campos a lo largo del tiempo, campos opcionales o campos cuyo tipo puede variar de fila en fila. Actualmente, los usuarios de las API relacionales de Flink deben elegir entre ROWs con esquemas estrictos y tipos estáticos, o almacenar datos como cuerdas JSON. Se está añadiendo un tipo VARIANT para soportar datos semiestructurados que se pueden almacenar y procesar de manera eficiente. Página 521 Para una comprensión más profunda Para saber más sobre Flink SQL, Te dará comienzo. Este video en consultas continuas El Tiene varios ejemplos excelentes, si quieres sumergirte más profundamente en este tema. Documentación sobre Funciones de Tabla de Proceso Sean Falconer explica por qué . El futuro de los agentes de IA está impulsado por eventos El futuro de los agentes de IA está impulsado por eventos

This story contains new, firsthand information uncovered by the writer.

Este audio es producido en el idioma original de la historia!

Lo que necesita saber sobre las últimas actualizaciones de las APIs de tabla y SQL de Apache Flink

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Aumente su productividad con estas 18 herramientas para desarrolladores 🚀🔥

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Aumente su productividad con estas 18 herramientas para desarrolladores 🚀🔥

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps