Introducción a Flink SQL

Antecedentes de la adopción de Flink SQL

• Había una aplicación legacy pesada basada en Flink, administrada por el Azar Matching Dev Team, que usaba 96 CPU
• Esta aplicación implementaba varias funciones en una estructura monolítica, por lo que era difícil de mantener
• Al cambiar los nodos de ejecución por un trabajo de infraestructura, surgió un problema que impedía que la aplicación funcionara correctamente
• Fue necesario decidir entre seguir manteniéndola asumiendo una alta carga operativa o reemplazarla por otro método

Opciones disponibles

• Las funciones importantes de la aplicación existente ya estaban implementadas en una nueva aplicación de Flink
• Se evaluó cómo reemplazar la parte de publicación de eventos condicionales y ejecución de lógica
  1. Implementarlo como una sola Flink App
     • Ventaja: la operación es sencilla
     • Desventaja: es muy probable que la app crezca demasiado y, si una parte falla, sea fácil que otras funciones también se vean afectadas
  2. Implementarlo como varias Flink App
     • Ventaja: se pueden administrar de forma independiente
     • Desventaja: la carga aumenta a medida que crece la cantidad de apps
  3. Usar Flink SQL
     • Ventaja: permite definir la lógica con consultas y administrar un solo clúster
     • Desventaja: es difícil expresar lógica compleja y puede ser complicado si no se tiene experiencia administrando clústeres

Razones para elegir Flink SQL y comparación con tecnologías alternativas

• Antes de adoptar Flink SQL, se revisaron ksqlDB y Spark Structured Streaming
• Razones para elegir Flink SQL:
  1. High Availability
     • Permite guardar y restaurar de forma estable el estado de la app mediante Checkpoint y Savepoint
     • JobManager puede configurarse en modo HA
  2. Soporte para funciones avanzadas de streaming
     • Ofrece varias capacidades de procesamiento de streaming con sintaxis SQL
     • Soporta ventanas, joins, procesamiento por tiempo de evento, watermark, etc.
  3. Extensibilidad mediante UDF y Custom Connector
     • Permite conectar funciones definidas por el usuario y diversas fuentes de datos y sink

vs ksqlDB

• Aunque está incluido en la plataforma de Confluent, su funcionamiento HA en procesamiento de streaming con estado es ineficiente

vs Spark Structured Streaming

• Está implementado sobre el motor Spark SQL y permite escribir UDF y Custom Sink
• Como funciona en unidades de micro-batch, puede ser desventajoso para el procesamiento en tiempo real

Construcción del entorno de clúster y método de despliegue de consultas

Probar de forma simple en local

• Se presenta un método para levantar un Flink Cluster localmente y enviar consultas SQL

Arquitectura del clúster en el entorno de producción

• Configuración de un Flink SQL Cluster sobre Kubernetes
• Comparación entre Application mode y Session mode

Despliegue de consultas usando GitOps

• Implementación del despliegue de consultas y detención de jobs usando GitHub Actions

Casos principales de operación y experiencia de troubleshooting

Cuando JobManager o TaskManager fallan

• JobManager puede seguir ejecutando el trabajo incluso si falla, gracias a la configuración HA
• Si TaskManager falla, el trabajo se redistribuye y continúa

Cuando una consulta falla

• Puede ocurrir cuando entran datos anómalos o faltan recursos de cómputo
• Es posible configurar que se ignoren errores de formato JSON y establecer valores predeterminados

Cuando algunos jobs fallan al reiniciar el clúster

• Es necesario ajustar la configuración de timeout y retry

Cuando se quiere modificar una condición de la consulta y volver a desplegar

• Solo en cambios simples es posible restaurar el estado usando savepoint

Principales puntos de monitoreo

• Revisar métricas como numRunningJobs, taskmanager.cpu.load, taskmanager.memory.used, entre otras

Cierre

• La adopción de Flink SQL mejoró la productividad y la eficiencia operativa
• Ofrece una gran estabilidad y se planea implementar el patrón GitOps Controller

[flgkselql98]

En sistemas distribuidos como Flink, parece que hay que mantener 2 o 3 racks para asegurar HA, y da la impresión de que al integrarlo con Kubernetes lograron garantizar esa alta disponibilidad. Pero al final también habría que pensar en los recursos de los nodos worker de Kubernetes, así que me hace preguntarme si armaron nodos dedicados solo para Flink (porque cuando Flink tenga carga, podría haber problemas de caída en los nodos worker).
Desde esa perspectiva, ¿realmente hay ventajas en usar Kubernetes?

Además, cuando usas funciones de ventana en Flink, esos datos se mantienen en memoria mientras funciona el JOIN en SQL, así que viéndolo desde el punto de vista del trade-off, me pregunto si Flink realmente es una buena opción. Si con el tiempo ese SQL + job que se vuelve cada vez más grande termina muriendo, el problema que se genera sería enorme.

Yo también me pregunto, en situaciones donde se necesita un JOIN en el data source de más alto nivel, cómo se podría bajar eso al nivel de la aplicación y procesarlo sin usar Flink.