No nosso banco de questões do MLA-C01, cerca de 46 questões têm Kinesis, Lambda, EventBridge ou Step Functions como conceito central. O guia do exame cobra as mesmas habilidades: a tarefa 1.1 trata da ingestão de dados em streaming com Kinesis, Apache Flink e Apache Kafka, a tarefa 1.2 da transformação de dados em streaming com Lambda e Spark, a tarefa 3.1 da escolha do orquestrador entre Apache Airflow e SageMaker Pipelines, e a tarefa 3.3 da configuração de trabalhos de treinamento e inferência com regras do EventBridge. O essencial é como receber os dados que chegam em tempo real, onde processá-los e o que desperta a etapa seguinte.
Este artigo começa pela diferença entre lote e streaming e depois cobre os quatro serviços de streaming, os detalhes do Firehose, como fazer inferência em tempo real sobre um fluxo, como despertar pipelines com eventos do S3 e o EventBridge, os três orquestradores e os serviços que mudaram de nome ou foram descontinuados. O data lake baseado no S3 e os formatos de dados foram tratados antes em Ingestão e Armazenamento de Dados.
---
Lote e Streaming: o Que Muda?
Um serviço de entregas junta as encomendas e envia tudo de uma vez em um horário fixo. A água da torneira corre sem parar assim que você a abre. Se o processamento em lote é o serviço de entregas, o streaming é a torneira.
| Aspecto | Lote | Streaming | |------|------|------| | Quando processa | Acumula e processa de uma vez em intervalos | Continuamente, assim que os dados chegam | | Latência | Minutos a horas | Milissegundos a segundos | | Ferramentas típicas | Glue ETL, EMR, SageMaker Processing, Batch Transform | Kinesis, Firehose, Managed Service for Apache Flink, MSK | | Exemplo de ML | Retreinamento semanal, pontuar todos os clientes toda noite | Detecção de fraude no momento do pagamento, atualizar recomendações a cada clique |
Os sistemas reais usam os dois. O desenho mais comum toma decisões em tempo real sobre o fluxo enquanto guarda os mesmos dados no S3 para retreinar em lote.
---
Os Quatro Serviços de Streaming
| Serviço | Função | Características principais | Pista na questão | |------|------|------|------| | Kinesis Data Streams | Ingestão em tempo real e retenção temporária | Vazão por shard; vários consumidores leem os mesmos dados separadamente e podem relê-los | "várias aplicações processam o mesmo fluxo em tempo real" | | Amazon Data Firehose | Entrega automática a um destino | Sem servidores nem shards para gerenciar; acumula e carrega no S3, Redshift ou OpenSearch | "salvar dados de streaming no S3 sem escrever código" | | Managed Service for Apache Flink | Processamento de fluxos com estado | Agregações por janelas de tempo, junções de fluxos, detecção de anomalias em tempo real | "média móvel de 5 minutos", "agregação em tempo real sobre o fluxo" | | Amazon MSK | Apache Kafka gerenciado | Usar como estão as aplicações e ferramentas Kafka existentes | "já usamos Kafka" |
Um shard do Kinesis Data Streams aceita 1 MB ou 1.000 registros por segundo e entrega 2 MB por segundo. Se a vazão não for suficiente, adicione shards ou use o modo sob demanda, que gerencia a capacidade automaticamente. Os dados ficam retidos por 24 horas por padrão e por até 365 dias, então podem ser relidos depois de uma falha. Para vídeo, faça a ingestão com o Kinesis Video Streams e analise com o Rekognition ou com um modelo do SageMaker AI.
Dica: "Só receber os dados e guardá-los no S3" é o Firehose, "vários consumidores processam os dados recebidos em tempo real" é o Kinesis Data Streams, e "agregações por janelas de tempo e estado sobre o fluxo" é o Managed Service for Apache Flink.
!Pipeline de ML em streaming em que os eventos recebidos pelo Kinesis Data Streams são pontuados em tempo real pelo Lambda e por um endpoint do SageMaker, enquanto o Firehose os guarda no S3 para retreinamento
---
O Firehose em Detalhe: Buffer, Transformação e Formatos
O exame pergunta com frequência sobre os recursos específicos do Firehose.
| Recurso | O que faz | Pista na questão | |------|------|------| | Buffer | Entrega quando atinge primeiro o tamanho do buffer (1–128 MiB) ou o intervalo do buffer (até 900 segundos) | "quase em tempo real é suficiente" | | Transformação com Lambda | Limpa registros ou acrescenta campos antes da entrega | "remover os campos com dados pessoais antes de carregar" | | Backup dos registros de origem | Guarda os registros originais, sem transformação, em outro caminho do S3 | "manter tanto o resultado transformado quanto o original" | | Conversão de formato | Converte JSON para Parquet ou ORC antes de salvar (com um esquema do Catálogo de Dados do Glue) | "formato colunar para reduzir o custo das consultas do Athena" | | Particionamento dinâmico | Divide o caminho do S3 por valores do registro (como data ou ID do cliente) | "separar automaticamente em uma pasta por cliente" |
A conversão de formato espera entrada em JSON. Outros formatos, como CSV, são convertidos antes para JSON com uma transformação do Lambda. Na entrega ao Redshift, o Firehose grava primeiro os dados no S3 e depois os carrega no Redshift (COPY).
Dica: "Um atraso de cerca de um minuto é aceitável e os dados precisam chegar ao S3 como Parquet sem esforço operacional" é o Firehose com conversão de formato. Por causa do buffer, o Firehose não serve para processamento em tempo real na escala de milissegundos.
---
Inferência em Tempo Real sobre um Fluxo
Para decidir se um pagamento é fraudulento no momento em que acontece, é preciso chamar o modelo a cada evento do fluxo.
| Etapa | Serviço | O que faz | |------|------|------| | Ingestão | Kinesis Data Streams | Recebe os eventos de pagamento em tempo real | | Processamento e chamada | Lambda (ou Managed Service for Apache Flink) | Lê os eventos em lotes, pré-processa e chama o endpoint do SageMaker | | Inferência | Endpoint em tempo real do SageMaker AI | Devolve a pontuação de fraude | | Guardar resultados e avisar | DynamoDB, SNS | Guarda a pontuação e avisa acima do limite | | Dados de retreinamento | Firehose → S3 | Acumula os eventos originais para retreinar em lote |
Quando um fluxo do Kinesis é ligado ao Lambda como origem de eventos, o Lambda recebe e processa os registros em lotes. Atributos que precisam de uma janela de tempo, como o número de transações dos últimos 10 minutos, é melhor calcular no Flink. Se você gravar os atributos calculados em tempo real no armazenamento online do SageMaker Feature Store, a inferência lê os mesmos valores e os atributos de treinamento e de serviço ficam consistentes.
Dica: "Pontuar cada transação do fluxo em tempo real e guardar os dados originais para retreinamento" é Kinesis Data Streams + Lambda + um endpoint do SageMaker, combinado com Firehose → S3.
---
Despertar Pipelines com Eventos: Eventos do S3 e EventBridge
A automação orientada a eventos faz a etapa seguinte começar sozinha quando algo acontece, sem alguém precisar apertar um botão toda vez.
| Gatilho | Exemplo | Ao que se conecta | |------|------|------| | Notificação de eventos do S3 | Um novo arquivo de dados de treinamento é enviado | Lambda, SQS, SNS ou EventBridge | | Regra agendada do EventBridge | Todo domingo às 2h | Uma execução de pipeline do SageMaker | | Eventos de mudança de estado do SageMaker | Trabalho de treinamento concluído ou com falha, mudança de estado do endpoint | Avisos com Lambda, início da etapa seguinte | | Model Package State Change | Um modelo é aprovado no registro de modelos | Um pipeline de implantação (CodePipeline etc.) | | Alarme do CloudWatch | O Model Monitor detecta uma violação por desvio | Um pipeline de retreinamento |
O EventBridge aceita o SageMaker Pipelines como destino direto, então, quando chega um evento que atende à regra, ele pode iniciar uma execução do pipeline (StartPipelineExecution) sem passar pelo Lambda. Enviar os eventos do S3 ao EventBridge permite distribuir o mesmo evento para vários destinos e aplicar condições mais finas.
Dica: "Executar automaticamente o pipeline de retreinamento quando chegarem dados novos ao S3" é evento do S3 → EventBridge → SageMaker Pipelines. "Implantar automaticamente quando um modelo for aprovado" é uma regra do EventBridge que recebe o evento Model Package State Change.
---
Escolher o Orquestrador: SageMaker Pipelines, Step Functions ou MWAA
| Orquestrador | Pontos fortes | Quando usar | |------|------|------| | SageMaker Pipelines | Etapas próprias de ML, como processamento, treinamento, ajuste, avaliação, condições e registro do modelo; cache de etapas; rastreamento de linhagem; integração com o registro de modelos | Automatizar o próprio fluxo de ML com o mínimo de operação | | AWS Step Functions | Máquina de estados de uso geral, integrações diretas com muitos serviços da AWS, novas tentativas e desvios em caso de erro, processamento paralelo com o estado Map, espera por aprovação humana | Um só fluxo que une vários serviços, como Lambda, Glue, SageMaker e tradução | | Amazon MWAA | Apache Airflow gerenciado, DAGs em Python, operadores do SageMaker | Equipes que já operam pipelines de dados como DAGs do Airflow |
O Step Functions oferece uma integração (.sync) que inicia um trabalho longo, como um treinamento do SageMaker, e espera até ele terminar. O estado Map é usado para dividir milhares de arquivos do S3 e processá-los ao mesmo tempo (por exemplo, traduzir milhares de documentos em paralelo).
Dica: "A empresa já opera centenas de DAGs do Airflow" é o MWAA, "um pipeline feito só de etapas de ML com o menor esforço operacional" é o SageMaker Pipelines, e "um fluxo que mistura Lambda, Glue, SageMaker e aprovação humana" é o Step Functions.
---
Serviços Renomeados ou Descontinuados
Materiais antigos e bancos de questões costumam usar os nomes antigos.
| Nome antigo | Agora | Observações | |------|------|------| | Kinesis Data Firehose | Amazon Data Firehose | Renomeado em 2024; mesmos recursos | | Ki