Ingestão de Streaming: Kinesis, Amazon MSK e Landing de Streams no Lake

As lições 02 até 05 colocaram arquivos, formatos e tabelas no Amazon S3. Até aqui, tudo foi movido em lotes. Esta lição é sobre a outra metade da ingestão: eventos que chegam continuamente e precisam pousar no lake sem perder a ordem, duplicar em silêncio ou custar discretamente mais do que a equipe de analytics recupera. Ao final, você será capaz de dimensionar um stream do Kinesis a partir de um número de registros por segundo, explicar exatamente onde a ordenação termina, decidir quando uma hot key é um problema de partition key e não de capacidade, configurar um buffer do Firehose que dispara na condição certa e defender um landing bronze idempotente mesmo com o pipeline em at-least-once.

Nesta lição você vai:

• enunciar o contrato de shard, 1 MB/s de escrita e 1,000 registros/s de entrada, 2 MB/s de leitura e 5 transações de leitura/s de saída, por shard, nos dois modos de capacidade, e saber o que não mudou quando os registros passaram a 10 MiB;
• escolher entre Provisioned, On-demand Standard e On-demand Advantage, incluindo o piso de 25 MB/s em nível de conta que faz do Advantage a resposta errada em volume baixo;
• rastrear uma partition key pelo MD5 até um intervalo de hash-key e um shard, e explicar por que a ordenação é uma promessa por chave e não para o stream inteiro;
• detectar e corrigir uma hot key quando o auto-scaling do on-demand não pode te ajudar;
• dimensionar fan-out compartilhado versus enhanced fan-out e precificar a diferença;
• trabalhar com o KPL (collection, aggregation, rate limiting) e o KCL (leases, checkpoints, parentShardId), e saber a data de fim de suporte do KCL 1.x;
• configurar o Amazon Data Firehose de ponta a ponta: tamanho e intervalo de buffer, lotes de transformação com Lambda, conversão de JSON para Parquet contra um schema do Glue, limites do dynamic partitioning e prefixos de erro;
• pousar dados de streaming com os três padrões de landing bronze e acoplar o rótulo certo de semântica de entrega a cada seta;
• rodar o padrão at-least-once para MERGE idempotente que torna seguro promover bronze de arquivos puros;
• rotear telemetria de dispositivos pelas regras do AWS IoT Core e saber para que serve o Kinesis Data Video Streams;
• comparar Amazon MSK provisionado, MSK Serverless, MSK Connect e MSK streaming tables, com a aritmética de break-even entre broker e serverless;
• estudar dois casos de clientes da AWS (Cisco Webex no MSK, VMware Carbon Black no Kinesis) e uma caixa de atualização de outubro de 2026 com fontes;
• praticar com 12 questões no estilo de exame mais quatro verificações interativas.

---

1. O mapa de serviços: cinco caminhos do evento para o lake

Todo design de streaming na AWS é uma composição das mesmas cinco peças. Confundi-las é o erro de arquitetura mais comum nesse espaço, porque duas delas parecem tubulações e apenas uma delas é um log que você pode dar replay.

• 📚 Você sabia? O nome Firehose na sua frente é cosmético, mas carrega peso para material mais antigo: a AWS renomeou Amazon Kinesis Data Firehose para Amazon Data Firehose em 9 de fevereiro de 2024, e afirma que "não há outras mudanças, incluindo endpoints do serviço, APIs, AWS Command Line Interface (AWS CLI), políticas de acesso do AWS Identity and Access Management (IAM) e métricas do Amazon CloudWatch" (AWS What's New, 2024-02-09; histórico de documentos do Firehose, acesso em 2026-10). Então as ações de IAM continuam sendo firehose:*, e um blog antigo que fala "Kinesis Data Firehose" está descrevendo exatamente o mesmo serviço que você está configurando hoje.

---

2. Kinesis Data Streams: o contrato de shard

2.1 Um número governa tudo

Uma shard é "uma sequência de registros de dados identificada de forma única em um stream" e "uma unidade básica de throughput de um Kinesis data stream." O contrato, idêntico nos modos de capacidade provisioned e on-demand, é:

Duas coisas são verdadeiras ao mesmo tempo e os alunos rotineiramente colapsam as duas em uma: bytes e contagem de registros são limites independentes. Um stream de registros de 400 bytes bate na parede de 1,000 registros/s com apenas 0.38 MB/s, então registros por segundo limita muito antes dos bytes. Em sentido inverso, registros de 2 KB a 1,000/s usam apenas 2 MB/s do orçamento de leitura, mas exatamente a taxa completa de escrita em registros.

A mudança de tamanho de registro de 2025 é a armadilha desta seção. Em 28 de outubro de 2025 a AWS elevou o tamanho máximo de registro "até 10MiB, um aumento de dez vezes em relação ao limite anterior" e dobrou o teto de requisição do PutRecords para 10 MiB, afirmando claramente que "os limites de throughput individuais de shard de 1MiB/s para escritas e 2MiB/s para leituras permanecem inalterados", registros grandes "expelem temporariamente até 10MiB/s, terminando por fazer média de 1MiB por segundo." A AWS recomenda manter registros grandes em "1-2% do seu total de registros para um desempenho ótimo." A página de conceitos ainda carrega a frase antiga de que "o data blob pode ter até 1 MB" (acesso em 2026-10); a página de limites e o anúncio de outubro de 2025 são os fatos atuais.

• 📚 Você sabia? PutRecords é deliberadamente não atômico: o AWS Big Data Blog registra que "o PutRecords sempre retorna um resultado 200, mesmo que alguns registros dentro do lote tenham falhado" e que "uma falha de um único registro não interrompe o processamento dos registros seguintes." Então um 200 OK do PutRecords significa a requisição foi aceita, não o seu lote pousou, você precisa inspecionar FailedRecordCount e os valores de ErrorCode por registro. Em um único host, um loop cru de PutRecord mediu cerca de 5,500 RPS com PutRecords em lote versus cerca de 76,000 RPS pelo KPL, "cerca de 800 vezes maior" (AWS Big Data Blog, 2015-08-07).

2.2 Modos de capacidade: três formas, um contrato

Regras práticas que saem dessa tabela:

• Você pode trocar de modo duas vezes a cada 24 horas por stream: uma barreira de proteção, não um toggle livre. Projete a troca como um evento, não como um loop.
• On-demand não é "sem limites." Um stream on-demand novo começa em 4/8 MB/s, Regiões não principais estouram em 200/400 MB/s, e, o ponto importante, o on-demand "se adapta automaticamente para lidar com padrões de distribuição de dados desiguais a menos que uma única partition key exceda os limites de 1 MB/s de throughput e 1000 registros por segundo de uma shard."
• Advantage é mais barato por GB, mas tem um piso. O anúncio é explícito: a conta "compromete-se a fazer streaming com pelo menos 25 MiB/s de ingestão de dados e 25 MiB/s de uso de recuperação de dados", em troca de dados ingeridos com preço 60% menor, recuperação 60% menor, recuperação de enhanced fan-out 68% menor e retenção estendida 77% menor (AWS Big Data Blog, 2025-11-03). Um stream de desenvolvimento de 0.5 MB/s vai pagar por 25 MB/s que não usa.

2.3 Retenção: da janela de replay para o arquivo de longo prazo

A retenção padrão é 24 horas, e é o mínimo; IncreaseStreamRetentionPeriod aceita até 8,760 horas (365 dias). Três faixas de custo ficam atrás desse controle:

Replay é o motivo de a retenção existir: o Kinesis "fornece a ordenação de registros, bem como a capacidade de ler e/ou repetir os registros na mesma ordem para múltiplas Amazon Kinesis Applications." Uma janela de 24 horas significa que um bug de consumidor descoberto às 09:00 pode ser corrigido e reprocessado a partir das 09:00 do dia anterior, e nada mais do que isso. Se o seu landing bronze-no-S3 é a cópia durável (lição 05), a retenção do stream é um orçamento de reprocessamento, não a sua estratégia de backup.

---

3. Partition keys, ordenação e shards quentes

3.1 O caminho que um registro realmente percorre

O producer fornece uma partition key: "Partition keys são strings Unicode, com um limite máximo de comprimento de 256 caracteres para cada chave." A AWS então usa "uma função hash MD5 … para mapear partition keys para valores inteiros de 128 bits e para mapear os registros de dados associados para shards usando os hash key ranges das shards." Todos os registros que compartilham uma chave caem na mesma shard, e é por isso que "a Kinesis Client Library (KCL) entrega todos os registros de uma dada partition key para o mesmo record processor."

Ordenação, enunciada com precisão, tem exatamente três escopos e nenhum a mais:

1. Dentro de uma shard: "os registros que o Kinesis Data Streams recebe por uma chamada GetRecords são estritamente ordenados por número de sequência."
2. Dentro de uma partition key: a chave sempre mapeia para uma shard, então a ordem local à chave sobrevive.
3. Mesmo cliente, mesma chave, opt-in: SequenceNumberForOrdering "garante números de sequência estritamente crescentes, para puts do mesmo cliente e para a mesma partition key … Se este parâmetro não for definido, os registros são ordenados de forma grosseira com base no tempo de chegada."

Não existe ordem para o stream inteiro, e o PutRecords nem ordena dentro do próprio lote. Se o seu MERGE downstream assume uma sequência global, você projetou uma garantia que o serviço não oferece.

3.2 Exemplo resolvido E1, registros/s limita primeiro: dimensionamento e custo

Cenário (em out 2026): 2,500 registros/s com média de 400 bytes, contínuo 24x7, US East (N. Virginia).

Note as duas regras de arredondamento que deixam as faturas de streaming surpreendentes: o data-in do Kinesis arredonda cada registro para cima até 1 KB ("se os seus registros de dados têm 4.5 KB cada, o Kinesis Data Streams vai contar cada registro como 5 KB"), enquanto o medidor PUT provisionado cobra em unidades de payload de 25 KB. Um pipeline de registros de 900 bytes é cobrado como 1 KB por registro em on-demand e como uma unidade por registro em provisioned, e são os registros por segundo que dimensionam as suas shards de qualquer forma.

3.3 Exemplo resolvido E2: a hot key que o auto-scaling não conserta

Cenário: uma única chave tenant_id = acme envia 1,500 registros/s de 80 bytes.

Os próprios remédios da AWS: "use a operação de split-shard … Se a localidade ou a ordenação baseada na partition key atual não for necessária, mude o esquema da partition key para aumentar a distribuição dela. Se a aplicação producer estiver excedendo o limite de throughput de uma shard devido a uma única partition key (problema de hot key), mude o esquema da partition key." Producers avançados podem contornar o mapeamento MD5 com ExplicitHashKey para posicionar uma chave deliberadamente: útil para drenar uma shard quente, perigoso se você usá-lo para maquiar um design de chave que deveria mudar.

• 📚 Você sabia? Uma heurística útil de produção vem da plataforma de fraude da Chime Financial: o texto da AWS sobre a stack de streaming deles observa "chegamos a um mapeamento 1:1 entre Kinesis Shard e núcleo de vCPU" enquanto ingeriam "mais de 1 milhão de eventos por segundo" com latência de ponta a ponta "menos de 15 segundos" (AWS Big Data Blog, 2023-09-19). Trate como a regra de bolso de dimensionamento de workers de um único time para uma frota de KCL, não como uma cota de serviço: a contagem de workers ainda precisa ser no mínimo igual à contagem de shards para paralelismo, e todo lease vive no DynamoDB.

---

4. Fan-out: leituras compartilhadas versus enhanced fan-out

Um stream só é útil se vários consumidores conseguem lê-lo. O Kinesis dá você dois mecanismos com economias genuinamente diferentes.

A frase da FAQ que importa: "Os consumidores de fan-out compartilhado todos compartilham os 2 MB/s de throughput de leitura e o limite de cinco transações por segundo de uma shard … Um consumidor de enhanced fan-out recebe sua própria cota de 2 MB/s de throughput de leitura." Adicione um segundo consumidor em polling e a taxa efetiva de leitura de cada um cai pela metade, o sintoma clássico de produção em que "adicionar um consumidor deixou tudo mais lento."

4.1 Exemplo resolvido E3: dimensionamento de fan-out e a conta do EFO

Cenário: um stream de 4 shards com três leitores: (a) um poller de Lambda usando o caminho compartilhado, (b) uma aplicação Flink que precisa de baixa latência, (c) o Firehose lendo do Kinesis Data Streams.

O comportamento na própria FAQ do Firehose é o que força a decisão: "O Firehose chama o GetRecords() do Kinesis Data Streams uma vez a cada segundo para cada shard do Kinesis." Se o Firehose é o seu sink, assuma que o pool compartilhado já está falado.

---

5. Producers e consumers: KPL, KCL e a tabela de lease

5.1 KPL: collection, aggregation, rate limiting

A Kinesis Producer Library roda como "um processo separado, e comunica-se com o seu processo pai de usuário via IPC", e faz quatro trabalhos: retries automáticos, collection (agrupar muitos registros em requisições PutRecords), aggregation (empacotar muitos registros de usuário em um registro do Kinesis) e rate limiting por shard com um token bucket "por padrão … definido 50 por cento acima do limite real da shard." Ela também publica métricas do CloudWatch em seu nome e adiciona latência até RecordMaxBufferedTime.

Exemplo resolvido E4, o aggregation derrota o teto de registros/s.

O exemplo da própria AWS bate: "Com o aggregation do KPL, você pode empacotar 1,000 registros em apenas 10 registros do Kinesis Data Streams, reduzindo o RPS para 10 (a 50 KB cada)", e "O limite de registros por segundo do Kinesis Data Streams é o que limita clientes com registros menores que 1 KB."

Portabilidade é o imposto. Pela matriz de uso da AWS, um producer em qualquer linguagem diferente de Java não pode usar o KPL, e um producer Java do KPL alimentando um consumer não-Java precisa desabilitar o aggregation: caso contrário o consumer tem que desagregar registros que nunca esperou. PutRecords cru é portável; o batching, o tratamento de falha parcial, os retries e o backoff são seus.

5.2 KCL: leases, checkpoints e parentShardId

A Kinesis Client Library é compilada no seu consumer e te dá:

• Leases: "Cada shard é vinculada a apenas um worker por um lease em qualquer momento dado", rastreado em uma tabela de lease do DynamoDB. O KCL 3.x cria três tabelas por padrão (lease, métricas de worker, estado do coordinator); a partir do KCL 3.5 o formato de tabela única consolida todos os metadados na tabela de lease.
• Checkpointing: "o processo de armazenar persistentemente a posição do último registro processado com sucesso em uma shard", armazenado nessa tabela de lease. Reinicie a partir do checkpoint, não a partir de "agora".
• parentShardId: "Usado para garantir que a shard pai seja totalmente processada antes que o processamento comece nas shards filhas. Isso garante que os registros sejam processados na mesma ordem em que foram colocados no stream." Este é o único mecanismo que mantém a ordenação através de um evento de reshard.

Duas datas importam aqui. O KCL 1.x chegou ao fim de suporte em 30 de janeiro de 2026, e a orientação da AWS é "migrar as suas aplicações KCL usando a versão 1.x para a versão mais recente do KCL": nesta lição essa data já passou, então qualquer consumer 1.x está rodando com tempo emprestado. E o KCL não é infraestrutura de graça: as tabelas do DynamoDB (capacidade on-demand recomendada) e as métricas do CloudWatch acompanham, e worker count ≥ shard count é um requisito de paralelismo, não uma preferência de tuning.

---

6. Amazon Data Firehose: um serviço de entrega, não um processador

6.1 O pipeline, etapa por etapa

O Firehose é "um serviço totalmente gerenciado para entregar dados de streaming em tempo real para destinos como o Amazon Simple Storage Service (Amazon S3), Amazon Redshift, Amazon OpenSearch Service, Amazon OpenSearch Serverless, Splunk, Apache Iceberg Tables e qualquer endpoint HTTP customizado." Suas etapas, em ordem:

1. Origem: Direct PUT, Kinesis Data Streams, Amazon MSK, CloudWatch Logs, EventBridge, IoT, WAF, Network Firewall, HTTP.
2. Buffer: "o Amazon Data Firehose armazena em buffer os dados de streaming recebidos até um certo tamanho ou por um certo período de tempo antes de entregá-los aos destinos"; a condição que for atendida primeiro dispara a entrega.
3. Transformação com Lambda (opcional): invoke por lote, payload limitado a 6 MB síncrono, invocação de até 5 minutos, 3 retries por padrão (configurável de 0 a 300).
4. Conversão de formato de registro (opcional): JSON para Parquet ou ORC usando um schema no AWS Glue Data Catalog (deserializer, schema, serializer).
5. Dynamic partitioning (opcional): chaveamento por JQ em prefixos do S3, até 500 partições ativas (elevável para 2,500).
6. Destino, S3, tabelas Iceberg, Redshift (via S3 + COPY), OpenSearch, Splunk, Snowflake, HTTP, mais prefixos de erro e de backup.

6.2 Exemplo resolvido E5: qual condição de buffer dispara primeiro

Dicas de buffering para um destino S3: tamanho 1 to 128 MB (padrão 5), intervalo 0 to 900 s (padrão 300).

Três modificadores mudam a aritmética:

• A conversão de formato sobe o piso. Com a conversão habilitada você "não pode definir SizeInMBs em um valor menor que 64", e "O valor passa a ser 128 quando você a habilita."
• O dynamic partitioning custa latência. "O Firehose usa buffering multi-stage internamente. Portanto, o atraso de ponta a ponta de um lote de registros pode ser 1.5 vezes o tempo de dica de buffering configurado", e o zero buffering não está disponível com a feature.
• Buffering abaixo de 60 segundos muda a fatura do S3. "O Firehose usa upload multipart para o destino S3 quando você configura um intervalo de tempo de buffer menor que 60 segundos … você verá algum aumento nos custos de API PUT do S3."

• 📚 Você sabia? A página de cotas do Firehose contém discretamente o argumento de escala para o Kinesis como origem: o Direct PUT no Firehose é limitado (em us-east-1/us-west-2/eu-west-1) a "500,000 registros/segundo, 2,000 requisições/segundo e 5 MiB/segundo", mas "Quando o Kinesis Data Streams é configurado como a origem dos dados, esta cota não se aplica, e o Amazon Data Firehose escala para cima e para baixo sem limite." E como o Firehose lê "uma vez a cada segundo para cada shard do Kinesis", os dois serviços compartilham o seu dimensionamento de shards: mais shards significam mais leituras paralelas do Firehose, não apenas mais capacidade de escrita.

---

7. Landing no lake com o Firehose

7.1 O que o Firehose realmente promete

A semântica de entrega difere por destino, e esta é a área mais citada fora de contexto em toda a lição:

A consequência de projeto: qualquer coisa que pouse como arquivos puros em um prefixo bronze é at-least-once. Duplicatas não são um bug que você configura para longe: elas são o contrato. Você torna a tabela correta downstream (Seção 9.3), não a entrega perfeita.

7.2 Exemplo resolvido E6: uma fatura do Firehose para um landing JSON to Parquet no lake

Cenário: 100 registros/s x 3 KB, JSON convertido para Parquet, entregue no S3, US East (N. Virginia), 30 dias.

O ponto didático é a forma da fatura, não os centavos: a ingestão é a alavanca menor quando você liga features. Conversão e dynamic partitioning juntos mais que dobram os $35.84 base, e cada um deles é uma feature que você escolheu em troca de Parquet consultável em prefixos particionados em vez de um monte de JSON. Note também as taxas dependentes da origem: uma origem Kinesis Data Streams cobra $0.029/GB, uma origem Amazon MSK cobra $0.055/GB sem arredondamento de 5 KB, logs cedidos $0.13/GB, um destino Iceberg (origem Kinesis) $0.045/GB, e entrega por VPC $0.01/GB mais $0.01 por AZ-hour.

7.3 Data delivery do Kinesis e streaming tables (sem Firehose)

Em outubro de 2026 um stream do Kinesis pode pousar no lake sem o Firehose. O data delivery suporta "dois tipos de destino: streaming tables em Apache Iceberg e buckets Amazon S3 de propósito geral", com "compactação inteligente embutida [que] elimina a proliferação de arquivos pequenos." Requisitos e preços:

Resultados declarados pela AWS para as streaming tables: "reduzir custos de data delivery para S3 Tables em até 50% em comparação com alternativas autogerenciadas e reduzir custos de consulta downstream em até 30% por meio da compactação inteligente embutida", com os dados "consultáveis em minutos após serem publicados no seu stream." O modo provisionado não suporta data delivery nem streaming tables: um fato que tira o modo provisionado da consideração para este padrão.

---

8. Regras do AWS IoT Core e Kinesis Data Video Streams

8.1 MQTT, regra, ação, lake

O AWS IoT Core é o ingress de telemetria de dispositivos. Uma regra avalia uma mensagem MQTT com AWS IoT SQL e invoca uma ou mais ações. A lista documentada de ações inclui kinesis (Kinesis Data Streams), firehose, s3, timestream, lambda, sqs, sns, dynamodb, kafka (Apache Kafka), stepFunctions, openSearch, republish, cloudWatch, location, influxDB e iotSiteWise.

A ação do Kinesis leva três parâmetros que você precisa acertar: o stream, a partitionKey, "geralmente composta por uma expressão (por exemplo, ${topic()} ou ${timestamp()})", e o roleArn, "Um papel do IAM que o AWS IoT pode assumir para executar a operação kinesis:PutRecord." Escolher ${topic()} significa que todas as mensagens de um mesmo tópico MQTT fazem hash para uma shard: elegante para ordenação, um gerador de hot key em volume. Escolher uma chave no nível do dispositivo ou do evento espalha a carga e derruba a ordenação por tópico.

Um controle de custo vale decorar: "Você também pode usar o recurso Basic Ingest para enviar com segurança os dados dos dispositivos para os serviços AWS listados anteriormente, sem incorrer em custos de mensageria. O recurso Basic Ingest otimiza o fluxo de dados removendo o broker de mensagens publish/subscribe do caminho de ingestão." Se os dados nunca precisam de fan-out por MQTT, não pague pelo salto do broker.

8.2 Kinesis Data Video Streams: a faixa de mídia, em resumo

O Amazon Kinesis Video Streams carrega "mídia de dispositivos conectados para a AWS, para armazenamento, análise, machine learning (ML), reprodução e outros processamentos", com reprodução gerenciada HLS e DASH, WebRTC para streaming bidirecional de latência ultra-baixa, e integrações com Rekognition Video e SageMaker. É a resposta certa para câmeras, áudio e binários serializados no tempo: não para registros de eventos em JSON.

Preços em US East (em out 2026): $0.0085/GB ingerido, $0.0085/GB consumido (consumo HLS $0.0119/GB), armazenamento $0.023/GB-mês no tier quente; o WebRTC acrescenta $0.03 por mês por canal de sinalização ativo, $2.25 por milhão de mensagens de sinalização e $0.12 por mil de minutos de streaming TURN. Um warm storage tier (feature datada de 26 de novembro de 2025) oferece ingestão a $0.0100 por 1,000 fragmentos persistidos e armazenamento a $0.0125/GB-mês com retenção mínima de 30 dias, o equivalente em vídeo ao ajuste de retenção de streams do Kinesis.

• 📚 Você sabia? A regra de IoT mais barata costuma ser a que você apaga. Regras com curingas podem casar com a maioria das mensagens, e cada ação assume um papel do IAM e cobra o serviço alvo, então uma única regra ampla fazendo fan-out para Kinesis e Firehose e S3 são três faturas para uma mensagem. Projete o SQL da regra com a mesma estreiteza com que você projetaria um índice de banco de dados, e recurra ao Basic Ingest quando o broker não acrescenta nada.

---

9. Amazon MSK: Kafka gerenciado e como sair do stream para a tabela

9.1 Provisioned versus Serverless

A própria orientação da AWS sobre tamanho de broker: "Brokers M7g usam processadores AWS Graviton … Brokers M7g oferecem melhor desempenho por preço em relação a instâncias M5 comparáveis" e "Brokers M7g e M5 são recomendados para cargas de trabalho de produção." A lógica de break-even é o exercício: o provisioned tem um piso fixo (horas equivalentes a três brokers, mais armazenamento que você pague chegue tráfego ou não), enquanto o serverless mede partições e bytes, então um stream contínuo de alto volume pode custar mais no Serverless do que em brokers provisionados, e o teto de ingress de 200 MBps é uma parada dura, não um aviso.

Exemplo resolvido E8: a forma do break-even (exemplos publicados pela AWS, em out 2026).

9.2 MSK Connect e sinks de stream para o lake

O MSK Connect "facilita que desenvolvedores façam streaming de dados para dentro e para fora dos seus clusters Apache Kafka … usa as versões 2.7.1 ou 3.7.x do Kafka Connect", pode "implantar conectores desenvolvidos por terceiros como o Debezium … ou implantar um conector existente sem mudanças de código", e "Conectores escalam automaticamente para se ajustar às mudanças de carga e você paga apenas pelos recursos que usa", com reinício automático de tasks e PrivateLink para conectividade privada.

Os caminhos de sink que importam para este curso:

• S3 sink (conector Confluent no MSK Connect): "connector.class": "io.confluent.connect.s3.S3SinkConnector", com "flush.size": "1" controlando o tamanho do objeto e a capacidade provisionada expressa como mcuCount / workerCount.
• Iceberg sink: a receita de lake em CDC em tempo real publicada pela AWS é MSK Connect + Iceberg Kafka Connect (AWS Big Data Blog, 2026-02-03), onde o iceberg.control.commit.interval-ms do conector define com que frequência os offsets do stream viram snapshots da tabela.
• Firehose com MSK como origem: caminho na console: "Em Origem, escolha Amazon MSK. Em Destino, escolha Apache Iceberg Tables." Note o preço: ingestão com origem MSK é $0.055/GB contra $0.029/GB de uma origem Kinesis.
• MSK streaming tables, tópicos Kafka materializados como Iceberg em S3 Tables: "Brokers Amazon MSK Express gravam os seus registros como arquivos de dados Apache Parquet e fazem commit deles na tabela", escalando até "10 GBps de throughput de entrega" a $10.00 por TB entregue, frescor configurado entre 5 e 15 minutos, com bucket de dead-letter queue obrigatório e a ressalva explícita de que "Um Channel não faz backfill de dados produzidos anteriormente, apenas dados produzidos após a habilitação são entregues."

Para trabalho de laboratório, o MSK Data Generator do awslabs é um conector source do Kafka Connect (genkp.<topic>.with para a partition key, genv.<field>.with para os valores) implantável no MSK Connect ou em um container ECS, o equivalente de streaming de um script de seed.

9.3 Exemplo resolvido E7: bronze at-least-once para silver idempotente

Cenário: o Firehose entregou uma janela de 10 minutos de arquivos JSON-to-Parquet em s3://lake/bronze/events/dt=2026-10-11/hr=09/, e um retry duplicou 1,412 deles. Promova para uma tabela silver de Iceberg.

Regras que viajam com este padrão: o MERGE do Iceberg aceita apenas um registro de origem por linha de destino: dedupe primeiro, sempre; e a condição s.event_ts > t.event_ts faz de um evento mais antigo reexecutado um no-op em vez de um downgrade. A alternativa é pular arquivos puros completamente e usar um destino exactly-once (Firehose para Iceberg, ou streaming tables), onde a coordenação de escrita cuida das duplicatas para você.

O balanço de semântica, enunciado uma vez e nunca borrado:

• Arquivos puros em bronze = at-least-once. Planeje dedupe (id determinístico do evento mais janela de commit) ou MERGE em um id surrogado com um timestamp de origem monotonicamente crescente.
• Exactly-once documentado existe, mas com escopo: o destino Iceberg do Firehose ("o Firehose garante entrega exactly-once para tabelas Iceberg"), as streaming tables do Kinesis ("semântica de entrega exactly-once em todas as shards") e o processamento exactly-once do Flink.
• "Exactly-once" em um slide de vendor não é a mesma afirmação que "exactly-once na documentação." Pergunte qual destino, qual catálogo, e o que acontece em um timeout de entrega.

---

10. Escolha: a matriz de decisão

---

Atualizações de 2026 (em outubro de 2026)

---

Casos Reais

Caso A, Cisco Webex: 12 clusters MSK e o plantão que você recupera

Cisco (plataforma de observabilidade do Webex). O estudo de caso da AWS descreve uma frota de Kafka autogerenciado para a stack de observabilidade/ELK cuja carga operacional recaía sobre um time superprovisionando "instâncias de tamanho único para todos" enquanto indisponibilidades atingiam milhares de usuários internos. A própria migração foi dimensionada com honestidade: "A equipe de observabilidade gastou 5 meses engenheirando a migração do Kafka autogerenciado para o Amazon MSK e depois implementou a nova stack em 6 semanas."

O estado estável publicado é o número que torna concreta a seção de MSK desta lição: "O sistema inteiro é composto por 12 clusters Amazon MSK com um total de 66 brokers. O sistema lida de forma transparente com um throughput diário de 147 TB de dados e mais de 100 bilhões de mensagens." Efeitos downstream: "Mais de 4,000 desenvolvedores, gerentes e membros de equipe do Webex … se beneficiaram", e "reduziu o tempo de transporte de dados do backend para o usuário, de modo que os tempos de recuperação ficam abaixo de 10 segundos." O resumo da AWS do desfecho: "A Cisco reduziu sua sobrecarga operacional a praticamente zero, com economia de custos e menos indisponibilidades de serviço." Robert Labrie, gerente de observabilidade do Webex: "Rodamos uma stack de observabilidade federada globalmente em escala, e simplesmente funciona."

Ângulo da lição: Kafka gerenciado converte um problema de equipe em um problema de capacidade. O protocolo, os clients e o ecossistema Connect permaneceram; o que desapareceu foi o babysitting de brokers, e a linha dos 5 meses de migração é o preço honesto dessa troca. 66 brokers em 12 clusters também é a escala em que a aritmética de broker-hours da Seção 9.1 deixa de ser uma curiosidade de planilha.

Números relatados pelo cliente em uma página de estudo de caso da AWS (sem data, acesso em 2026-10-11); não é um compromisso da AWS.

Caso B, VMware Carbon Black: 1 PB por dia e a elasticidade de shard como alavanca de custo

VMware Carbon Black (segurança de endpoint). Da página de clientes do Kinesis Data Streams da AWS: "A VMware Carbon Black analisa mais de um trilhão de eventos todos os dias … Agora eles processam 1 PB de dados de streaming por dia com custos operacionais e de infraestrutura reduzidos." A arquitetura ingere de "milhões de dispositivos de edge distribuídos" para o Amazon Kinesis Data Streams, com analítica em tempo real em milissegundos.

A citação que explica por que Kinesis em vez de uma frota de brokers é de Stoyan Dimkov, Staff Engineer e Software Architect: "Quando os dados de clientes individuais aumentam ou diminuem, podemos usar a elasticidade do Amazon Kinesis Data Streams para escalar a computação para cima ou para baixo, processando os dados de forma confiável enquanto gerenciamos nosso custo de forma eficaz."

Ângulo da lição: a 1 PB/dia o número interessante não é a contagem de shards: é que a elasticidade por workload de cliente é o modelo de custo. Dimensionar esse stream é a aritmética de E1 em escala (1 PB/dia é em média cerca de 11.6 MB/s antes de réplicas, o que o on-demand absorve sem uma planilha de shards), e as oscilações de volume por cliente são exatamente o que torna doloroso o planejamento de shards provisionados.

Números relatados pelo cliente em uma página de cliente de produto da AWS (sem data, acesso em 2026-10-11); não é um compromisso da AWS.

Caso C, TrueCar: remover o agendamento, não afinar o motor

TrueCar (mercado automotivo). Na mesma página de clientes do Kinesis da AWS: "Ao adotar uma estratégia de dados de streaming com o Amazon Kinesis Data Streams, a TrueCar melhorou em 48 vezes a velocidade de insight da analítica de clickstream, automatizou seu processo de extract, transform, load (ETL) e melhorou a observabilidade de suas métricas." 48x é uma história de latência, não de throughput, o agendamento do ETL em lote era o gargalo, e o stream o removeu.

Números relatados pelo cliente em uma página de cliente de produto da AWS (sem data, acesso em 2026-10-11); não é um compromisso da AWS.

---

Perguntas de Prática (Practice Questions)