Zalando corta 75% do estado do Flink abandonando Table API
Aprofundamento CEVIU
Aprofundamento
A Zalando trocou a Table API do Flink por uma implementação customizada em DataStream API não por falta de maturidade da primeira, mas porque o encadeamento de quatro joins declarativos gerava um estado distribuído e redundante, 240GB em RocksDB, que a arquitetura do Flink 1.20 não conseguia compactar ou compartilhar entre operadores. Cada join mantinha cópias completas dos dados de entrada para lidar com atrasos e atualizações, virando um gargalo operacional: snapshots falhavam, reinícios demoravam mais de 20 minutos e escalonamentos eram economicamente inviáveis na AWS Managed Flink.
O MultiStreamJoinProcessor, desenvolvido internamente, unificou os quatro fluxos em um único KeyedProcessFunction com chave SKU. Ele armazena apenas os eventos brutos, evita materialização intermediária e aplica lógica de juntar sob demanda, reduzindo o estado para 56GB e cortando o tempo médio de snapshot de 18 para 3 minutos. A mudança foi feita com Flink 1.20, pois a AWS ainda não suportava Flink 2.1 no início de março de 2026, apesar do Multi-Way Join Operator já estar estável desde novembro de 2025.
Por que isso importa
Isso mostra que, em streaming de larga escala, a escolha entre Table API e DataStream API não é técnica ou ideológica, é operacional. Quando o estado vira custo, risco e latência, a abstração declarativa perde espaço para o controle imperativo. A Zalando não abandonou o Flink; ela adaptou seu uso ao limite físico do estado em disco e à realidade de serviços gerenciados com restrições de versão. É um lembrete prático: pipelines de streaming não são só sobre lógica de negócios, mas sobre gestão de memória, I/O e ciclo de vida de snapshots, áreas onde a DataStream API ainda dá vantagem clara em casos extremos.
Perguntas frequentes
Por que a Table API gerou tanto estado se é supostamente mais simples?
Porque cada operador de join na Table API cria um estado isolado em RocksDB. Ao encadear quatro joins com a mesma chave, a Zalando acabou com quatro cópias redundantes dos mesmos dados, sem compartilhamento nem deduplicação. A simplicidade declarativa esconde essa explosão de estado até que ele vire um problema operacional.
O Multi-Way Join do Flink 2.1 resolve o mesmo problema?
Sim, mas de forma genérica: ele processa múltiplos streams com a mesma chave em um único operador, armazenando só os eventos brutos. A Zalando antecipou esse padrão com código customizado, pois estava presa ao Flink 1.20 na AWS Managed Flink até março de 2026. O operador experimental chegou em julho de 2025, mas só ficou disponível em produção com a 2.1.1 em novembro.
Essa otimização vale para qualquer empresa usando Flink?
Não. Funciona quando você tem múltiplos joins com a mesma chave, alta taxa de atualização de dados e necessidade de baixa latência em reinícios. Para pipelines simples ou com pouca variação temporal nos dados, a Table API continua mais rápida de desenvolver e manter. A Zalando migrou só onde o estado virou limitador físico.
Fontes
- engineering.zalando.comfonte original
- Categoria
- CEVIU DevOps
- Publicado
- 06 de março de 2026
- Editoria
- CEVIU DevOps