Adoção do Flink SQL

Contexto da adoção do Flink SQL

• Havia um aplicativo legado pesado baseado em Flink, gerenciado pela Azar Matching Dev Team, que usava 96 CPUs
• Esse aplicativo implementava várias funcionalidades em uma estrutura monolítica, o que dificultava a manutenção
• Quando os nós de execução foram alterados por um trabalho de infraestrutura, surgiu um problema em que o aplicativo deixou de funcionar normalmente
• Foi necessário decidir entre continuar mantendo-o, mesmo com alta fadiga operacional, ou substituí-lo por outra abordagem

Opções que podiam ser escolhidas

• As funcionalidades importantes do aplicativo existente já haviam sido implementadas em um novo aplicativo Flink
• Foi estudada uma forma de substituir a parte de publicação de eventos condicionais e execução de lógica
  1. Implementar em um único Flink App
     • Vantagem: operação simples
     • Desvantagem: há grande chance de o aplicativo crescer demais, e se uma parte falhar, as outras funcionalidades também tendem a ser afetadas
  2. Implementar em vários Flink Apps
     • Vantagem: gerenciamento independente
     • Desvantagem: o aumento no número de aplicativos eleva a carga operacional
  3. Usar Flink SQL
     • Vantagem: é possível definir a lógica com queries e gerenciar apenas um cluster
     • Desvantagem: é difícil expressar lógicas complexas, e o gerenciamento do cluster pode ser complicado para quem não tem familiaridade

Motivos para escolher o Flink SQL e comparação com tecnologias alternativas

• Antes de adotar o Flink SQL, foram avaliados o ksqlDB e o Spark Structured Streaming
• Motivos para escolher o Flink SQL:
  1. High Availability
     • É possível salvar e restaurar o estado da aplicação com estabilidade por meio de Checkpoint e Savepoint
     • O JobManager pode ser configurado em modo HA
  2. Suporte a recursos avançados de streaming
     • Suporta várias funcionalidades de processamento de streaming com sintaxe SQL
     • Suporte a janelas, joins, processamento por event time, watermark etc.
  3. Extensibilidade com UDF e Custom Connector
     • É possível conectar funções definidas pelo usuário e diversas fontes de dados e sinks

vs ksqlDB

• Embora faça parte da plataforma Confluent, o funcionamento em HA é ineficiente em processamento de streaming stateful

vs Spark Structured Streaming

• Implementado com base no mecanismo Spark SQL, permitindo escrever UDFs e Custom Sinks
• Como opera em unidades de micro-batch, pode ser menos vantajoso para processamento em tempo real

Construção do ambiente de cluster e forma de deploy das queries

Testando de forma simples no ambiente local

• Introdução a como subir um Flink Cluster localmente e submeter queries SQL

Arquitetura do cluster no ambiente de produção

• Configuração de um Flink SQL Cluster sobre Kubernetes
• Comparação entre Application mode e Session mode

Deploy de queries usando o modelo GitOps

• Implementação do deploy de queries e da interrupção de Jobs com GitHub Actions

Principais casos operacionais e experiências de troubleshooting

Quando o JobManager ou o TaskManager falha

• Com a configuração de HA, o JobManager pode continuar o trabalho mesmo em caso de falha
• Se o TaskManager falhar, o trabalho é redistribuído e continua

Quando a query falha

• Pode acontecer com entrada de dados anormais ou falta de recursos computacionais
• É possível configurar para ignorar erros de formato JSON e definir valores padrão

Quando alguns Jobs falham ao reiniciar o cluster

• É necessário ajustar as configurações de timeout e retry

Quando se quer modificar uma condição da query e fazer o deploy novamente

• A restauração de estado com savepoint só é possível em casos de mudanças simples

Principais pontos de monitoramento

• Verificar métricas como numRunningJobs, taskmanager.cpu.load, taskmanager.memory.used etc.

Conclusão

• A adoção do Flink SQL melhorou a produtividade e a eficiência operacional
• A estabilidade é excelente, e há planos para implementar o padrão GitOps Controller

[flgkselql98]

Sistemas distribuídos como o Flink precisam manter 2 ou 3 racks para garantir HA, e parece que, ao integrá-lo ao Kubernetes, eles conseguiram garantir essa HA. Mas, no fim, ainda seria preciso considerar os recursos dos slave nodes do kube; fico pensando se montaram nós dedicados só para rodar Flink (porque, quando a carga do Flink aumentar, parece provável haver problema de queda de slave node).
Nessa perspectiva, existe alguma vantagem em usar Kubernetes?

Além disso, quando se usa funções de janela no Flink, os dados daquele intervalo ficam mantidos em memória para que o sql join funcione. Olhando pelo ponto de vista de trade-off, será que o Flink é uma boa escolha? Se, com o passar do tempo, esse SQL cada vez maior + o job morrerem, o estrago seria enorme...

Eu também fico pensando que, quando há necessidade de join na data source do topo, em vez de usar Flink, como isso poderia ser tratado descendo para o nível da aplicação.