Apache Flink em 2026: Processamento de Streams, Event Time e Perguntas de Entrevista
Guia completo sobre Apache Flink 2.3 para processamento de streams em tempo real. Watermarks, janelas, gerenciamento de estado e preparação para entrevistas de data engineering.

Apache Flink 2.3 representa a referência em processamento de streams distribuído com latência inferior a um segundo e garantias exactly-once. Diferente dos sistemas orientados a batch, o Flink processa dados continuamente à medida que chegam, tornando-se o framework preferido para analytics em tempo real, detecção de fraude e arquiteturas orientadas a eventos.
O Flink se diferencia do Spark Streaming através de um verdadeiro processamento de streams: o Flink processa eventos um por um com semântica event time, enquanto o Spark Streaming processa micro-batches com processing time por padrão.
Arquitetura do Flink 2.3 para Processamento de Streams
O Flink executa em uma arquitetura distribuída com um JobManager coordenando o trabalho entre múltiplos TaskManagers. Cada TaskManager executa task slots que processam porções dos operadores paralelos do job. Essa separação permite ao Flink escalar horizontalmente mantendo tolerância a falhas através de checkpoints distribuídos.
O modelo dataflow no Flink representa computações como grafos acíclicos direcionados (DAGs). Os dados fluem das fontes através das transformações até os sinks, com cada operador potencialmente executando em múltiplas instâncias paralelas.
// Basic Flink streaming application setup
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
// Enable checkpointing every 10 seconds for fault tolerance
env.enableCheckpointing(10000, CheckpointingMode.EXACTLY_ONCE);
// Configure state backend for large state
env.setStateBackend(new EmbeddedRocksDBStateBackend());
// Define the data source - Kafka in production scenarios
DataStream<String> rawStream = env.addSource(
new FlinkKafkaConsumer<>("events", new SimpleStringSchema(), kafkaProps)
);
// Parse and transform the stream
DataStream<Event> events = rawStream
.map(json -> objectMapper.readValue(json, Event.class))
.assignTimestampsAndWatermarks(
WatermarkStrategy.<Event>forBoundedOutOfOrderness(Duration.ofSeconds(5))
.withTimestampAssigner((event, timestamp) -> event.getTimestamp())
);A configuração de checkpoint acima armazena snapshots do estado distribuído a cada 10 segundos. Se ocorrer uma falha, o Flink restaura a partir do último checkpoint completado e reproduz os registros do Kafka.
Event Time vs Processing Time: Entendendo as Semânticas Temporais
Event time refere-se ao momento em que um evento realmente ocorreu, incorporado nos próprios dados. Processing time é quando o Flink processa o registro. Essa distinção é importante porque atrasos de rede, entregas fora de ordem e atrasos de processamento tornam o processing time não confiável para operações baseadas em tempo.
// Configuring event time with watermarks
public class EventTimeProcessor {
public DataStream<AggregatedMetric> processWithEventTime(
DataStream<SensorReading> readings) {
return readings
// Extract timestamp from the event payload
.assignTimestampsAndWatermarks(
WatermarkStrategy
.<SensorReading>forBoundedOutOfOrderness(Duration.ofMinutes(2))
.withTimestampAssigner((reading, ts) -> reading.getEventTime())
.withIdleness(Duration.ofMinutes(5)) // Handle idle partitions
)
// Window by event time, not wall clock
.keyBy(SensorReading::getSensorId)
.window(TumblingEventTimeWindows.of(Time.minutes(1)))
.aggregate(new AverageAggregator());
}
}A estratégia forBoundedOutOfOrderness indica ao Flink que eventos podem chegar com até 2 minutos de atraso. Os watermarks avançam quando o Flink determina que nenhum evento com timestamp anterior ao watermark chegará mais.
O que acontece com eventos atrasados no Flink? Por padrão, eventos que chegam depois que o watermark passou o tempo final da janela são descartados. É possível configurar latência permitida com .allowedLateness(Time.minutes(10)) para processar chegadas tardias, ou usar side outputs para capturá-las e tratá-las separadamente.
Estratégias de Janelamento para Analytics em Tempo Real
O Flink fornece quatro tipos de janelas: tumbling, sliding, session e global. Cada uma atende diferentes necessidades analíticas.
// Different windowing approaches for stream processing
public class WindowingStrategies {
// Tumbling windows: fixed-size, non-overlapping
// Use case: hourly aggregations, daily summaries
public DataStream<Summary> tumblingAggregation(DataStream<Transaction> txns) {
return txns
.keyBy(Transaction::getAccountId)
.window(TumblingEventTimeWindows.of(Time.hours(1)))
.sum("amount");
}
// Sliding windows: fixed-size, overlapping
// Use case: moving averages, rolling metrics
public DataStream<Double> slidingAverage(DataStream<Metric> metrics) {
return metrics
.keyBy(Metric::getCategory)
.window(SlidingEventTimeWindows.of(Time.minutes(10), Time.minutes(1)))
.aggregate(new AverageAggregator());
}
// Session windows: activity-based, variable size
// Use case: user sessions, conversation analysis
public DataStream<Session> sessionAnalysis(DataStream<ClickEvent> clicks) {
return clicks
.keyBy(ClickEvent::getUserId)
.window(EventTimeSessionWindows.withGap(Time.minutes(30)))
.process(new SessionBuilder());
}
}As janelas de sessão fecham após um período configurável de inatividade. Esse padrão funciona para análise de comportamento de usuários onde a duração das sessões varia conforme o engajamento.
Pronto para mandar bem nas entrevistas de Data Engineering?
Pratique com nossos simuladores interativos, flashcards e testes tecnicos.
Gerenciamento de Estado e Checkpointing
O Flink mantém o estado dos operadores e o estado keyed durante todo o processamento. O estado keyed particiona os dados por chave, permitindo processamento paralelo enquanto mantém registros relacionados juntos. O estado do operador se aplica a toda a instância do operador.
// Managing state in a Flink KeyedProcessFunction
public class FraudDetector extends KeyedProcessFunction<String, Transaction, Alert> {
// Keyed state: one value per key (account)
private ValueState<Double> lastAmountState;
private ValueState<Long> lastTransactionTimeState;
private MapState<String, Integer> merchantCountState;
@Override
public void open(Configuration parameters) {
// Initialize state descriptors
lastAmountState = getRuntimeContext().getState(
new ValueStateDescriptor<>("lastAmount", Double.class));
lastTransactionTimeState = getRuntimeContext().getState(
new ValueStateDescriptor<>("lastTime", Long.class));
merchantCountState = getRuntimeContext().getMapState(
new MapStateDescriptor<>("merchantCounts", String.class, Integer.class));
}
@Override
public void processElement(Transaction txn, Context ctx, Collector<Alert> out)
throws Exception {
Double lastAmount = lastAmountState.value();
Long lastTime = lastTransactionTimeState.value();
// Detect suspicious patterns
if (lastAmount != null && lastTime != null) {
long timeDelta = txn.getTimestamp() - lastTime;
// Flag transactions 10x larger than previous within 1 minute
if (txn.getAmount() > lastAmount * 10 && timeDelta < 60000) {
out.collect(new Alert(txn.getAccountId(), "SUSPICIOUS_SPIKE", txn));
}
}
// Update state for next transaction
lastAmountState.update(txn.getAmount());
lastTransactionTimeState.update(txn.getTimestamp());
// Track merchant frequency
Integer count = merchantCountState.get(txn.getMerchantId());
merchantCountState.put(txn.getMerchantId(), (count == null ? 0 : count) + 1);
}
}Esse processador com estado rastreia padrões de transação por conta. O estado persiste através dos checkpoints, sobrevivendo a falhas sem perder o contexto de detecção de fraude.
Flink SQL e Table API para Processamento de Streams
O Flink 2.3 expande suas capacidades SQL com Materialized Tables para manutenção incremental de views. A Table API fornece uma interface unificada para processamento batch e streaming.
-- flink_sql_streaming.sql
-- Create a streaming source table from Kafka
CREATE TABLE orders (
order_id STRING,
customer_id STRING,
product_id STRING,
amount DECIMAL(10, 2),
order_time TIMESTAMP(3),
-- Define watermark for event time processing
WATERMARK FOR order_time AS order_time - INTERVAL '5' SECOND
) WITH (
'connector' = 'kafka',
'topic' = 'orders',
'properties.bootstrap.servers' = 'kafka:9092',
'format' = 'json',
'scan.startup.mode' = 'earliest-offset'
);
-- Streaming aggregation with tumbling window
SELECT
customer_id,
TUMBLE_START(order_time, INTERVAL '1' HOUR) AS window_start,
COUNT(*) AS order_count,
SUM(amount) AS total_amount
FROM orders
GROUP BY
customer_id,
TUMBLE(order_time, INTERVAL '1' HOUR);A abordagem SQL simplifica o desenvolvimento para analistas familiarizados com SQL enquanto o Flink gerencia a complexidade do processamento de streams internamente.
Flink vs Spark Structured Streaming: Comparação Técnica
Ambos os frameworks processam dados em streaming, mas suas arquiteturas diferem fundamentalmente. O Flink processa registros individualmente com verdadeiro streaming, enquanto o Spark processa micro-batches. Para comparações com Apache Spark, os trade-offs entre latência e consistência importam em produção.
| Aspecto | Flink | Spark Structured Streaming |
|---|---|---|
| Modelo de Processamento | Verdadeiro streaming | Micro-batch |
| Latência | Milissegundos | Segundos (intervalo batch) |
| State Backend | RocksDB, HashMaps | Em memória, HDFS |
| Exactly-Once | Nativo com checkpoints | Requer sinks idempotentes |
| Event Time | Suporte nativo | Suportado desde 2.1 |
| Suporte SQL | SQL streaming completo | Janelamento limitado |
Quando perguntado sobre Flink vs Spark para streaming, é importante focar na adequação ao caso de uso. O Flink se destaca em processamento de eventos de baixa latência e padrões de eventos complexos. O Spark Streaming é adequado para organizações que já usam Spark para batch e precisam de processamento unificado batch-stream.
Perguntas Comuns de Entrevista sobre Flink com Respostas
Como o Flink alcança a semântica exactly-once?
O Flink combina checkpointing com two-phase commit para sinks que suportam transações. Durante um checkpoint, o Flink captura um snapshot do estado dos operadores e registra os offsets das fontes. Para sinks Kafka, o Flink pré-commita registros no Kafka, completa o checkpoint, então commita a transação. Se uma falha ocorrer antes da conclusão do checkpoint, registros não commitados são descartados e o processamento é retomado a partir do último checkpoint.
Como explicar a propagação de watermarks em uma topologia multi-fonte?
Quando um job lê de múltiplas partições ou fontes, cada uma gera seus próprios watermarks baseados nos eventos recebidos. O watermark do operador downstream é igual ao watermark mínimo de todos os canais de entrada. Isso garante que nenhuma janela feche prematuramente devido a uma partição rápida avançando antes das mais lentas. A configuração de withIdleness() permite avançar os watermarks quando algumas partições param de enviar dados.
O que causa backpressure no Flink e como diagnosticá-lo?
Backpressure ocorre quando operadores downstream não conseguem acompanhar a taxa de dados upstream. A UI Web do Flink mostra o status de backpressure por operador. Causas comuns incluem:
- Chamadas lentas a sistemas externos (consultas ao banco de dados, chamadas de API)
- Computações custosas em funções map/process
- Paralelismo insuficiente para o volume de dados
- Operações de estado grandes bloqueando o processamento
Para resolver, pode-se aumentar o paralelismo, otimizar operações lentas ou usar I/O assíncrono para chamadas externas.
Qual é a diferença entre savepoints e checkpoints?
Checkpoints são automáticos, incrementais e otimizados para recuperação de falhas. O Flink gerencia seu ciclo de vida e deleta automaticamente os antigos. Savepoints são disparados pelo usuário, são snapshots completos destinados a tarefas operacionais: implantar novo código, redimensionar o job ou migrar entre clusters. Savepoints persistem até deleção explícita e suportam evolução de esquema.
Implantando Flink no Kubernetes
O Flink Kubernetes Operator 1.15 simplifica a implantação com recursos customizados FlinkDeployment. Ele gerencia o ciclo de vida dos jobs, atualizações e escalamento.
# flink-deployment.yaml
# Kubernetes deployment for a Flink application
apiVersion: flink.apache.org/v1beta1
kind: FlinkDeployment
metadata:
name: fraud-detection-job
spec:
image: flink:1.20
flinkVersion: v1_20
flinkConfiguration:
taskmanager.numberOfTaskSlots: "4"
state.backend.type: rocksdb
state.checkpoints.dir: s3://flink-checkpoints/fraud-detection
execution.checkpointing.interval: "30s"
serviceAccount: flink
jobManager:
resource:
memory: "2048m"
cpu: 1
taskManager:
resource:
memory: "4096m"
cpu: 2
replicas: 3
job:
jarURI: s3://flink-artifacts/fraud-detection-1.0.jar
entryClass: com.example.FraudDetectionJob
parallelism: 12
upgradeMode: savepointA configuração upgradeMode: savepoint garante que o operador tire um savepoint antes de atualizar, preservando o estado entre implantações.
Otimizando Aplicações Flink para Produção
Implantações em produção requerem atenção ao paralelismo, memória e configuração do state backend. Consulte os padrões ETL e pipelines de dados para considerações de integração.
// Production-ready Flink configuration
public class ProductionConfig {
public static void configureForProduction(StreamExecutionEnvironment env) {
// Checkpoint configuration
CheckpointConfig checkpointConfig = env.getCheckpointConfig();
checkpointConfig.setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);
checkpointConfig.setMinPauseBetweenCheckpoints(30000); // 30 seconds
checkpointConfig.setCheckpointTimeout(600000); // 10 minutes
checkpointConfig.setMaxConcurrentCheckpoints(1);
checkpointConfig.setExternalizedCheckpointRetention(
ExternalizedCheckpointRetention.RETAIN_ON_CANCELLATION);
// State backend with incremental checkpoints
EmbeddedRocksDBStateBackend rocksDB = new EmbeddedRocksDBStateBackend(true);
rocksDB.setDbStoragePath("/tmp/rocksdb");
env.setStateBackend(rocksDB);
// Restart strategy with exponential backoff
env.setRestartStrategy(RestartStrategies.exponentialDelayRestart(
Duration.ofSeconds(1), // Initial delay
Duration.ofMinutes(5), // Max delay
2.0, // Backoff multiplier
Duration.ofHours(1), // Reset backoff after
0.1 // Jitter
));
}
}Checkpoints incrementais reduzem o tamanho dos checkpoints escrevendo apenas o estado modificado desde o último checkpoint. Essa otimização se torna crítica ao gerenciar gigabytes de estado keyed.
Comece a praticar!
Teste seus conhecimentos com nossos simuladores de entrevista e testes tecnicos.
Pontos-Chave do Processamento de Streams com Apache Flink
- O Flink 2.3 processa eventos individualmente com latência de milissegundos, diferente dos sistemas micro-batch
- A semântica event time com watermarks trata corretamente dados fora de ordem, respondendo à pergunta comum de entrevista sobre eventos atrasados
- O estado keyed particiona dados para processamento paralelo enquanto mantém registros relacionados juntos
- Os checkpoints fornecem garantias exactly-once através de snapshots distribuídos e two-phase commit
- O Kubernetes Operator automatiza implantação, escalamento e atualizações com preservação de estado baseada em savepoints
- O Flink é preferível ao Spark Streaming quando latência sub-segundo ou padrões de eventos complexos são importantes
- Recomenda-se configurar RocksDB com checkpoints incrementais para workloads de produção com estado volumoso
Você saberia encontrar o bug em Data Engineering?
Um trecho real, um bug escondido, uma tentativa por dia. Sem conta para testar.

Escrito por
Anthony Fillion-MailletFundador da SharpSkill
Desenvolvedor fullstack há mais de 10 anos. Dirige a SharpSkill e responde por tudo o que é publicado aqui.
Atualizado em 28 de agosto de 2026
Tags
Compartilhar
Artigos relacionados

Apache Beam vs Spark em 2026: Pipelines Unificados e Perguntas de Entrevista
Comparação detalhada entre Apache Beam e Spark para pipelines de dados em 2026. Portabilidade, windowing, performance e perguntas técnicas de entrevista.

Snowflake em 2026: arquitetura, SQL e perguntas de entrevista para engenheiro de dados
Um guia de 2026 sobre a arquitetura do Snowflake para engenheiros de dados: como armazenamento e computação se separam, como funcionam virtual warehouses e micro-partitions e as perguntas de entrevista que testam experiência de produção.

Top 25 Perguntas de Entrevista para Engenharia de Dados em 2026
Guia completo com as 25 perguntas mais relevantes para entrevistas de engenharia de dados em 2026. Inclui SQL, Spark, Kafka, ETL/ELT, modelagem de dados e design de pipelines.