Title: Desenvolvimento de Software / Pipeline de Dados
Tags: Desenvolvimento_de_Software Resumo
On every note of this deck, unless a note says otherwise:
tldr: - Pipeline de dados é como uma rede de saneamento: coleta dados “brutos/sujos”, trata (limpa/padroniza) e entrega dados “potáveis” ao usuário final de forma automatizada e escalável.
- Objetivo central: mover dados da origem → destino com qualidade, formato correto e confiabilidade para decisões.
- ETL vs ELT
- ETL (Extract → Transform → Load): transforma antes de carregar (com staging); típico de Data Warehouse (schema-on-write).
  - Ponto forte: segurança/conformidade (LGPD), pois dá para mascarar/anonimizar antes do dado chegar ao DW.
- ELT (Extract → Load → Transform): carrega bruto e transforma depois, no destino; típico de Data Lake (schema-on-read).
  - Ponto forte: flexibilidade e velocidade de carga, útil para Big Data e exploração.
- Ferramentas em pipelines
- Orquestradores (ex.: Apache Airflow): agendam, controlam dependências, monitoram e alertam; DAGs em Python.
- Processamento/Transformação:
  - Apache Spark: processamento distribuído em memória (velocidade).
  - AWS Glue: ETL/ELT serverless (gerenciado), frequentemente com Spark.
- Ecossistemas cloud (exemplos): AWS (S3/Redshift/EMR/Kinesis), Azure (ADLS/Synapse/Data Factory), GCP (Cloud Storage/BigQuery/Dataflow).
- Tolerância a falhas (não é só infraestrutura)
- Tipos de falhas: infra (hardware/rede), lógicas (bugs), e falhas de dados / data downtime (dados errados, faltando, duplicados, atrasados).
- Em DataOps, “pipeline verde” não basta: dado incorreto é incidente tão sério quanto downtime.
- Estratégias de resiliência
- Retries para falhas transitórias; não resolvem falhas permanentes.
  - Requer idempotência (ex.: preferir UPSERT/MERGE a INSERT puro).
  - Boas práticas: exponential backoff + jitter para evitar “thundering herd”.
- Circuit breaker: para o pipeline quando regras de qualidade são violadas (protege dashboards). Pode ser automatizado via checks no orquestrador; SLA do Airflow mede tempo, não qualidade.
- Checkpoints: “save game” para retomar do último progresso (batch: reduzir retrabalho; streaming: ajudar semânticas como at-least/exactly-once). Trade-off: frequência vs overhead.
- DLQ (Dead-Letter Queue): isola registros/lotes problemáticos e mantém o pipeline rodando; ideal para erros pontuais (vs circuit breaker para falhas massivas).
- Pilar cultural
- Sistemas devem ser à prova de humanos (human-tolerant): erros operacionais são tratados como falha de sistema, mitigados com automação, controles e barreiras (testes, permissões, disjuntores).
link: https://documentacao.online/estudos/wb65.html
title: Pipeline de Dados

front: (Ano: 2025 Banca: NUCEPE Órgão: SEDUC-PI Prova: NUCEPE - 2025 - SEDUC-PI - Analista de Dados) São exemplos de ferramentas de pipelines de dados:
A) Excel e Power point.
B) Apache Airflow e AWS.
C) Excel e AWS.
D) Adobe photoshop e Power point.
E) Microsoft Word e AWS.
response: Alternativa B
comment: Vamos lá, gente. Essa questão é básica, ela quer saber se você diferencia software de escritório do dia a dia de ferramentas de engenharia de dados. Um pipeline de dados serve para automatizar o fluxo dos dados: tirar de um lugar (extração), talvez transformar (transformação) e carregar em outro (carga), o famoso ETL/ELT. Olhando as opções: As alternativas A, C, D e E estão erradas porque mencionam Excel, Power point, Photoshop ou Word. Pessoal, isso é ferramenta de produtividade (planilha, apresentação, imagem, texto). Você não usa o Word para construir um fluxo automatizado de dados que busca dados de um banco e joga em um Data Warehouse. A alternativa B é a correta. Apache Airflow é exatamente isso. É uma das ferramentas mais famosas para agendar (orquestrar) e monitorar esses fluxos (pipelines). AWS (Amazon Web Services) é a plataforma de nuvem que oferece dezenas de serviços que usamos para construir pipelines, como o AWS Glue (ETL), AWS Data Pipeline ou o S3 (armazenamento). Portanto, essa é a única alternativa que traz nomes corretos do universo de pipelines de dados.
Other fields (not shown on cards):
back: Alternativa B - Vamos lá, gente. Essa questão é básica, ela quer saber se você diferencia software de escritório do dia a dia de ferramentas de engenharia de dados. Um pipeline de dados serve para automatizar o fluxo dos dados: tirar de um lugar (extração), talvez transformar (transformação) e carregar em outro (carga), o famoso ETL/ELT. Olhando as opções: As alternativas A, C, D e E estão erradas porque mencionam Excel, Power point, Photoshop ou Word. Pessoal, isso é ferramenta de produtividade (planilha, apresentação, imagem, texto). Você não usa o Word para construir um fluxo automatizado de dados que busca dados de um banco e joga em um Data Warehouse. A alternativa B é a correta. Apache Airflow é exatamente isso. É uma das ferramentas mais famosas para agendar (orquestrar) e monitorar esses fluxos (pipelines). AWS (Amazon Web Services) é a plataforma de nuvem que oferece dezenas de serviços que usamos para construir pipelines, como o AWS Glue (ETL), AWS Data Pipeline ou o S3 (armazenamento). Portanto, essa é a única alternativa que traz nomes corretos do universo de pipelines de dados.

front: (Ano: 2024 Banca: CESPE / CEBRASPE Órgão: ANATEL Prova: CESPE / CEBRASPE - 2024 - ANATEL - Especialista em Regulação de Serviços Públicos de Telecomunicações – Especialidade: Ciências de Dados) Pipelines de dados apresentam uma única estrutura para o recebimento dos dados originados de uma fonte não confiável.
response: Errado
comment: Pensem no pipeline como um sistema de encanamento de um prédio. Você não tem um cano único que recebe água da chuva, água do esgoto e água potável da rua, tudo misturado na mesma estrutura. Um pipeline de dados é o oposto. A principal função dele, especialmente em Big Data, é justamente conseguir lidar com diversas fontes (múltiplas) e diversos formatos (estruturas) de dados. Ele precisa pegar dados de um banco SQL (estruturado), de um arquivo de log (texto puro, não estruturado) e de uma API (JSON, semiestruturado), por exemplo. Portanto, o pipeline não apresenta uma "única estrutura" para recebimento. Ele é feito para ser flexível e se adaptar às várias fontes e formatos.
Other fields (not shown on cards):
back: Errado - Pensem no pipeline como um sistema de encanamento de um prédio. Você não tem um cano único que recebe água da chuva, água do esgoto e água potável da rua, tudo misturado na mesma estrutura. Um pipeline de dados é o oposto. A principal função dele, especialmente em Big Data, é justamente conseguir lidar com diversas fontes (múltiplas) e diversos formatos (estruturas) de dados. Ele precisa pegar dados de um banco SQL (estruturado), de um arquivo de log (texto puro, não estruturado) e de uma API (JSON, semiestruturado), por exemplo. Portanto, o pipeline não apresenta uma "única estrutura" para recebimento. Ele é feito para ser flexível e se adaptar às várias fontes e formatos.

front: (Ano: 2024 Banca: CESPE / CEBRASPE Órgão: SEPLAG-CE Prova: CESPE / CEBRASPE - 2024 - SEPLAG-CE - Analista de Gestão Pública - Área de Atuação: Ciência da Computação) Em Big Data, um pipeline de dados visa refinar e limpar os dados brutos, facilitando a utilização desses dados pelos usuários finais.
response: Certo
comment: Perfeito, pessoal. Essa é a definição clássica do porquê fazemos pipelines. É a descrição da etapa de Transformação (o 'T' do ETL/ELT). Os dados na origem (sistemas do dia a dia, sensores, logs) são "sujos" ou "brutos". Podem ter erros de digitação, campos faltando, formatos diferentes (ex: "RJ", "Rio", "Rio de Janeiro"). Dados assim são inúteis para análise. O pipeline, especialmente na etapa de transformação, serve exatamente para isso: "refinar e limpar". A gente padroniza, corrige, enriquece, agrega e organiza esses dados. Por que fazemos isso? Para "facilitar a utilização pelos usuários finais". Um analista de BI, um gestor ou um cientista de dados não quer perder tempo limpando dados toda vez; ele quer o dado pronto (limpo, refinado) para fazer a análise, criar o dashboard ou treinar o modelo de machine learning.
Other fields (not shown on cards):
back: Certo - Perfeito, pessoal. Essa é a definição clássica do porquê fazemos pipelines. É a descrição da etapa de Transformação (o 'T' do ETL/ELT). Os dados na origem (sistemas do dia a dia, sensores, logs) são "sujos" ou "brutos". Podem ter erros de digitação, campos faltando, formatos diferentes (ex: "RJ", "Rio", "Rio de Janeiro"). Dados assim são inúteis para análise. O pipeline, especialmente na etapa de transformação, serve exatamente para isso: "refinar e limpar". A gente padroniza, corrige, enriquece, agrega e organiza esses dados. Por que fazemos isso? Para "facilitar a utilização pelos usuários finais". Um analista de BI, um gestor ou um cientista de dados não quer perder tempo limpando dados toda vez; ele quer o dado pronto (limpo, refinado) para fazer a análise, criar o dashboard ou treinar o modelo de machine learning.

front: (Ano: 2025 Banca: CESPE / CEBRASPE Órgão: TRF - 6ª REGIÃO Prova: CESPE / CEBRASPE - 2025 - TRF - 6ª REGIÃO - Analista Judiciário – Área: Apoio Especializado – Especialidade: Análise de Dados) Na etapa de ingestão de um pipeline de dados de Big Data, os dados de diversas fontes são coletados e transportados para um armazenamento centralizado.
response: Certo
comment: Item correto. O examinador aqui está descrevendo a primeira fase de um pipeline de Big Data, a "ingestão". A ingestão é exatamente isso: o ato de "coletar" os dados das "diversas fontes" (sistemas, sensores, logs, bancos de dados) e "transportar" (mover) eles para um "armazenamento centralizado". Esse local centralizado geralmente é um Data Lake (Lago de Dados), que é onde jogamos os dados brutos (do jeito que vieram, sem tratamento) para depois decidirmos o que fazer com eles.
Other fields (not shown on cards):
back: Certo - Item correto. O examinador aqui está descrevendo a primeira fase de um pipeline de Big Data, a "ingestão". A ingestão é exatamente isso: o ato de "coletar" os dados das "diversas fontes" (sistemas, sensores, logs, bancos de dados) e "transportar" (mover) eles para um "armazenamento centralizado". Esse local centralizado geralmente é um Data Lake (Lago de Dados), que é onde jogamos os dados brutos (do jeito que vieram, sem tratamento) para depois decidirmos o que fazer com eles.

front: (Ano: 2022 Banca: FGV Órgão: CGU Prova: FGV - 2022 - CGU - Auditor Federal de Finanças e Controle - Tecnologia da Informação) Uma organização deseja implementar um pipeline de dados e está avaliando a opção mais adequada para o seu contexto de operação. Em torno de 40% dos dados consumidos pela organização se encontram em planilhas eletrônicas que contêm dados sensíveis, produzidas semanalmente por suas unidades de negócio. Os outros 60% dos dados se encontram em alguns bancos de dados relacionais de sistemas de produção da organização. O tamanho da base é de moderado a pequeno, mas existe a necessidade de conformidade com normas de privacidade e confidencialidade dos dados. O objetivo do pipeline é fornecer insumos para um departamento que realiza análises de dados com métodos não supervisionados de aprendizagem de máquina para elaborar relatórios periódicos mensais. A organização está avaliando a construção de um Armazém de Dados (ETL) ou de um Lago de Dados (ELT). A proposta de modelo adequada e corretamente justificada é:
A) Armazém de Dados. Ambos os modelos são adequados, mas Lago de Dados tem maior latência até a carga (L) e custo maior;
B) Armazém de Dados. Esse modelo possui menor latência até a carga (L) e, ao contrário do Lago de Dados, opera de forma eficiente com dados relacionais;
C) Armazém de Dados. O processo ETL é mais adequado para o tratamento dos dados sensíveis e os casos de uso são bem conhecidos;
D) Lago de Dados. Esse modelo possui menor latência até a carga (L) e permite a extração (E) de dados semiestruturados e não estruturados;
E) Lago de Dados. Esse modelo não necessita de hardware especializado e, ao contrário do Armazém de Dados, possibilita tarefas de aprendizado de máquina.
response: Alternativa C
comment: Pessoal, essa questão da FGV é excelente. É um "estudo de caso". Temos que achar a melhor arquitetura (Data Warehouse ou Data Lake) para o cenário descrito. Vamos 'destrinchar' o cenário: • Dados: 40% planilhas (sensíveis) e 60% BDs (relacionais). • Requisito Crítico: "dados sensíveis" e "conformidade com normas de privacidade". • Objetivo: Relatórios mensais e ML não supervisionado (ou seja, casos de uso bem conhecidos). Agora vamos comparar as duas abordagens no contexto da privacidade (item 2), que é o ponto chave. • Armazém de Dados (Data Warehouse) usa o fluxo ETL: Extract (Extrair), Transform (Transformar), Load (Carregar). • Lago de Dados (Data Lake) usa o fluxo ELT: Extract (Extrair), Load (Carregar), Transform (Transformar). Percebam a diferença crucial: No ETL (Warehouse), a transformação acontece antes da carga. Isso é ótimo para dados sensíveis. A gente pode anonimizar, mascarar ou remover os dados de privacidade durante a transformação (o 'T') e só então carregar (o 'L') o dado já limpo e seguro no Armazém. No ELT (Lake), a gente carrega (o 'L') o dado bruto (inclusive o sensível) primeiro, e só depois transforma (o 'T'). Isso é um risco de conformidade, pois você está armazenando dados sensíveis brutos no seu Lake, mesmo que temporariamente. Como o problema exige "conformidade" e "tratamento de dados sensíveis", o ETL (associado ao Armazém de Dados) é o mais adequado. Além disso, o objetivo é "elaborar relatórios periódicos", que é o caso de uso clássico de um Data Warehouse, que armazena dados já estruturados e prontos para consulta (schema-on-write). Portanto, a alternativa C é a única correta: Armazém de Dados, pois o processo ETL é mais adequado para tratar dados sensíveis (antes da carga) e os casos de uso (relatórios) são bem conhecidos.
Other fields (not shown on cards):
back: Alternativa C - Pessoal, essa questão da FGV é excelente. É um "estudo de caso". Temos que achar a melhor arquitetura (Data Warehouse ou Data Lake) para o cenário descrito. Vamos 'destrinchar' o cenário: • Dados: 40% planilhas (sensíveis) e 60% BDs (relacionais). • Requisito Crítico: "dados sensíveis" e "conformidade com normas de privacidade". • Objetivo: Relatórios mensais e ML não supervisionado (ou seja, casos de uso bem conhecidos). Agora vamos comparar as duas abordagens no contexto da privacidade (item 2), que é o ponto chave. • Armazém de Dados (Data Warehouse) usa o fluxo ETL: Extract (Extrair), Transform (Transformar), Load (Carregar). • Lago de Dados (Data Lake) usa o fluxo ELT: Extract (Extrair), Load (Carregar), Transform (Transformar). Percebam a diferença crucial: No ETL (Warehouse), a transformação acontece antes da carga. Isso é ótimo para dados sensíveis. A gente pode anonimizar, mascarar ou remover os dados de privacidade durante a transformação (o 'T') e só então carregar (o 'L') o dado já limpo e seguro no Armazém. No ELT (Lake), a gente carrega (o 'L') o dado bruto (inclusive o sensível) primeiro, e só depois transforma (o 'T'). Isso é um risco de conformidade, pois você está armazenando dados sensíveis brutos no seu Lake, mesmo que temporariamente. Como o problema exige "conformidade" e "tratamento de dados sensíveis", o ETL (associado ao Armazém de Dados) é o mais adequado. Além disso, o objetivo é "elaborar relatórios periódicos", que é o caso de uso clássico de um Data Warehouse, que armazena dados já estruturados e prontos para consulta (schema-on-write). Portanto, a alternativa C é a única correta: Armazém de Dados, pois o processo ETL é mais adequado para tratar dados sensíveis (antes da carga) e os casos de uso (relatórios) são bem conhecidos.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) A arquitetura ELT (Extract, Load, Transform) está tipicamente associada ao conceito de Schema-on-Read, permitindo que os dados brutos sejam carregados rapidamente em um Data Lake.
response: Certo
comment: Galera, item perfeito. Está Certo. Vamos 'destrinchar' o porquê, pois cada parte dessa frase é uma afirmação de prova: • Arquitetura ELT: É o fluxo moderno. A gente Extrai (E), Carrega (L) e só depois Transforma (T). • Dados brutos sejam carregados rapidamente: Como a gente joga o dado "sujo" direto no destino, essa etapa de carga é muito rápida. • Data Lake: É o destino típico do ELT, justamente por ser um "lago" que aceita tudo, inclusive os dados brutos. • Schema-on-Read: Esse é o ponto-chave. O Data Lake usa esse método, o que significa que você joga o dado lá (o 'L') sem se preocupar com a estrutura. A estrutura (o esquema) só é definida no momento em que você vai ler ou consultar o dado. Item de revisão!
Other fields (not shown on cards):
back: Certo - Galera, item perfeito. Está Certo. Vamos 'destrinchar' o porquê, pois cada parte dessa frase é uma afirmação de prova: • Arquitetura ELT: É o fluxo moderno. A gente Extrai (E), Carrega (L) e só depois Transforma (T). • Dados brutos sejam carregados rapidamente: Como a gente joga o dado "sujo" direto no destino, essa etapa de carga é muito rápida. • Data Lake: É o destino típico do ELT, justamente por ser um "lago" que aceita tudo, inclusive os dados brutos. • Schema-on-Read: Esse é o ponto-chave. O Data Lake usa esse método, o que significa que você joga o dado lá (o 'L') sem se preocupar com a estrutura. A estrutura (o esquema) só é definida no momento em que você vai ler ou consultar o dado. Item de revisão!

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) O Apache Airflow é classificado como uma ferramenta de "Processamento e Transformação", sendo usado para executar transformações complexas em memória.
response: Errado
comment: A questão confunde o papel do Airflow (Orquestrador) com a descrição do Spark (Processador em memória). A função do Airflow é gerenciar o fluxo: agendar, monitorar, cuidar de dependências. Ele não faz o trabalho sujo.
Other fields (not shown on cards):
back: Errado - A questão confunde o papel do Airflow (Orquestrador) com a descrição do Spark (Processador em memória). A função do Airflow é gerenciar o fluxo: agendar, monitorar, cuidar de dependências. Ele não faz o trabalho sujo.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) O Apache Spark é uma ferramenta de processamento distribuído conhecida pela velocidade, pois processa dados prioritariamente em memória (RAM).
response: Certo
comment: Perfeita a definição: • Ferramenta de processamento distribuído: Sim, o Spark é o "canivete suíço" do Big Data e foi feito para rodar em cluster (distribuído). • Conhecida pela velocidade e processa dados em memória (RAM): Exato. O motivo da velocidade é que ele processa "em memória (RAM)".
Other fields (not shown on cards):
back: Certo - Perfeita a definição: • Ferramenta de processamento distribuído: Sim, o Spark é o "canivete suíço" do Big Data e foi feito para rodar em cluster (distribuído). • Conhecida pela velocidade e processa dados em memória (RAM): Exato. O motivo da velocidade é que ele processa "em memória (RAM)".

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) Os fluxos (pipelines) no Apache Airflow são definidos usando arquivos de configuração Javascript e são chamados de DAGs (Gráficos Acíclicos Direcionados).
response: Errado
comment: • Os fluxos no Airflow são chamados de DAGs (Gráficos Acíclicos Direcionados)? Sim, essa parte está correta. • Eles são definidos usando Javascript? Não! O Airflow usa Python para definição de DAGs!
Other fields (not shown on cards):
back: Errado - • Os fluxos no Airflow são chamados de DAGs (Gráficos Acíclicos Direcionados)? Sim, essa parte está correta. • Eles são definidos usando Javascript? Não! O Airflow usa Python para definição de DAGs!

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) O padrão "circuit breaker" (disjuntor), comum em fluxos de CI/CD e aplicável a pipelines de dados, tem como função principal pausar a execução do pipeline quando os dados não atendem a limites de qualidade pré- estabelecidos, evitando assim a propagação de dados ruins.
response: Certo
comment: Certíssimo, galera. O nome "disjuntor" (circuit breaker) é perfeito. Pense no disjuntor da sua casa: se tem uma sobrecarga, ele "cai" para proteger os aparelhos. Aqui é igual. Você define uma regra (ex: "não podem vir mais de 5% de valores nulos"). Se o pipeline começa a processar um lote com 10% de nulos, o disjuntor "abre" (ou "dispara"). Isso para o pipeline na hora, exatamente para evitar que esses dados de baixa qualidade contaminem o resto do sistema, como os dashboards do chefe.
Other fields (not shown on cards):
back: Certo - Certíssimo, galera. O nome "disjuntor" (circuit breaker) é perfeito. Pense no disjuntor da sua casa: se tem uma sobrecarga, ele "cai" para proteger os aparelhos. Aqui é igual. Você define uma regra (ex: "não podem vir mais de 5% de valores nulos"). Se o pipeline começa a processar um lote com 10% de nulos, o disjuntor "abre" (ou "dispara"). Isso para o pipeline na hora, exatamente para evitar que esses dados de baixa qualidade contaminem o resto do sistema, como os dashboards do chefe.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) A implementação de retentativas (retries) simples é uma estratégia eficaz para diversos tipos de falha em pipelines de dados, incluindo erros de lógica interna e falhas permanentes de conexão com a fonte de dados.
response: Errado
comment: Cuidado! Retentativas (retries) são excelentes, mas apenas para falhas transitórias (temporárias). Pensa assim: o serviço da API ficou fora por 1 segundo, ou a rede deu uma piscada. Na próxima tentativa, funciona. Agora, se a falha é permanente (ex: seu código tem um bug de divisão por zero, ou sua chave de API expirou), você pode tentar 1 milhão de vezes que vai falhar 1 milhão de vezes. Retry não conserta bug nem chave de API vencida.
Other fields (not shown on cards):
back: Errado - Cuidado! Retentativas (retries) são excelentes, mas apenas para falhas transitórias (temporárias). Pensa assim: o serviço da API ficou fora por 1 segundo, ou a rede deu uma piscada. Na próxima tentativa, funciona. Agora, se a falha é permanente (ex: seu código tem um bug de divisão por zero, ou sua chave de API expirou), você pode tentar 1 milhão de vezes que vai falhar 1 milhão de vezes. Retry não conserta bug nem chave de API vencida.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) Em processamento de dados em lote (batch processing), a utilização de checkpoints permite que um job, em caso de falha, retome o processamento a partir do último estado salvo, em vez de reiniciar todo o processamento do zero.
response: Certo
comment: Certo. Imagina processar um arquivo de 1 Terabyte. O job roda por 8 horas. Na sétima hora, PÁ, falha. Sem checkpoint, você tem que começar do zero (mais 8 horas de processamento). Com checkpoints (salvando o progresso a cada hora, por exemplo), você só retoma da sétima hora. É literalmente um "save game" do seu pipeline de dados.
Other fields (not shown on cards):
back: Certo - Certo. Imagina processar um arquivo de 1 Terabyte. O job roda por 8 horas. Na sétima hora, PÁ, falha. Sem checkpoint, você tem que começar do zero (mais 8 horas de processamento). Com checkpoints (salvando o progresso a cada hora, por exemplo), você só retoma da sétima hora. É literalmente um "save game" do seu pipeline de dados.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) Para que a estratégia de retentativas (retries) seja segura e eficaz em um pipeline de dados, é fundamental que as tarefas de transformação sejam idempotentes, garantindo que a execução múltipla da mesma tarefa produza o mesmo resultado final sem duplicar dados ou causar efeitos colaterais indesejados.
response: Certo
comment: Perfeito! Esse conceito é chave. Idempotência é a garantia de que, se você rodar a mesma tarefa várias vezes (o que acontece num retry), o resultado final é o mesmo de rodar uma vez só. Exemplo: um job que faz INSERT de dados. Se ele falha no meio e o retry roda de novo, você pode duplicar os dados. Um job idempotente usaria um UPSERT (atualiza se existe, insere se não existe), garantindo que, mesmo rodando 10 vezes, os dados fiquem corretos e sem duplicação.
Other fields (not shown on cards):
back: Certo - Perfeito! Esse conceito é chave. Idempotência é a garantia de que, se você rodar a mesma tarefa várias vezes (o que acontece num retry), o resultado final é o mesmo de rodar uma vez só. Exemplo: um job que faz INSERT de dados. Se ele falha no meio e o retry roda de novo, você pode duplicar os dados. Um job idempotente usaria um UPSERT (atualiza se existe, insere se não existe), garantindo que, mesmo rodando 10 vezes, os dados fiquem corretos e sem duplicação.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) Ferramentas de orquestração como o Apache Airflow podem utilizar "SQL Check Operators" para validar o conteúdo de um DAG, funcionando como um checkpoint de qualidade que verifica se os dados correspondem às expectativas de valores, intervalos ou limites.
response: Certo
comment: O Airflow tem operadores específicos para isso (como o SQLCheckOperator ou SQLValueCheckOperator). Você pode colocar um passo no seu DAG (seu fluxo) que roda um SQL, tipo: SELECT COUNT(*) FROM tabela_final WHERE coluna_id IS NULL. Se esse SQL retornar um valor maior que zero (ou seja, achou nulos), o operador falha e para o pipeline. Funciona como um excelente checkpoint de qualidade de dados.
Other fields (not shown on cards):
back: Certo - O Airflow tem operadores específicos para isso (como o SQLCheckOperator ou SQLValueCheckOperator). Você pode colocar um passo no seu DAG (seu fluxo) que roda um SQL, tipo: SELECT COUNT(*) FROM tabela_final WHERE coluna_id IS NULL. Se esse SQL retornar um valor maior que zero (ou seja, achou nulos), o operador falha e para o pipeline. Funciona como um excelente checkpoint de qualidade de dados.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) A estratégia de "exponential backoff" (recuo exponencial) nos retries consiste em aumentar linearmente o tempo de espera entre as tentativas, visando aliviar a carga sobre um serviço externo que pode estar temporariamente sobrecarregado.
response: Errado
comment: O erro é sutil, está na palavra "linearmente". O nome da estratégia é "recuo exponencial". A ideia é aumentar o tempo de espera de forma exponencial (ex: espera 2s, depois 4s, depois 8s, depois 16s...). Isso dá um "respiro" muito maior para o serviço que está sobrecarregado do que um aumento linear (que seria 2s, 4s, 6s, 8s...).
Other fields (not shown on cards):
back: Errado - O erro é sutil, está na palavra "linearmente". O nome da estratégia é "recuo exponencial". A ideia é aumentar o tempo de espera de forma exponencial (ex: espera 2s, depois 4s, depois 8s, depois 16s...). Isso dá um "respiro" muito maior para o serviço que está sobrecarregado do que um aumento linear (que seria 2s, 4s, 6s, 8s...).

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) Ao implementar checkpoints em pipelines de processamento de streaming, a frequência de salvamento do estado deve ser a mais alta possível, pois o custo de I/O (entrada e saída) para salvar o estado é considerado desprezível em comparação com o benefício da recuperação rápida.
response: Errado
comment: Aqui temos um trade-off clássico. Salvar o estado (checkpoint) tem um custo de performance (I/O, rede). Se você salvar a cada evento (frequência altíssima), seu pipeline vai ficar super lento. Se salvar raramente (ex: a cada 10 minutos), a performance é ótima, mas se falhar, você tem que reprocessar 10 minutos de dados. A frequência não deve ser "a mais alta possível", mas sim a ideal que equilibra performance e tempo de recuperação.
Other fields (not shown on cards):
back: Errado - Aqui temos um trade-off clássico. Salvar o estado (checkpoint) tem um custo de performance (I/O, rede). Se você salvar a cada evento (frequência altíssima), seu pipeline vai ficar super lento. Se salvar raramente (ex: a cada 10 minutos), a performance é ótima, mas se falhar, você tem que reprocessar 10 minutos de dados. A frequência não deve ser "a mais alta possível", mas sim a ideal que equilibra performance e tempo de recuperação.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) No Apache Airflow, a definição de um SLA (Service-Level Agreement) para uma tarefa permite que o orquestrador identifique quando uma consulta está se deteriorando ou demorando mais do que o esperado, marcando-a como "SLA missed", o que é uma forma de detecção de falha de desempenho.
response: Certo
comment: O SLA no Airflow não é sobre a qualidade do dado, mas sobre o tempo de execução. Você define que uma tarefa deve rodar em, no máximo, 1 hora. Se ela demorar 1h01, o Airflow marca um "SLA Missed". Isso não para a tarefa, mas gera um alerta, sendo ótimo para detectar queries que estão se degradando (ficando lentas) com o tempo.
Other fields (not shown on cards):
back: Certo - O SLA no Airflow não é sobre a qualidade do dado, mas sobre o tempo de execução. Você define que uma tarefa deve rodar em, no máximo, 1 hora. Se ela demorar 1h01, o Airflow marca um "SLA Missed". Isso não para a tarefa, mas gera um alerta, sendo ótimo para detectar queries que estão se degradando (ficando lentas) com o tempo.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) Após um número máximo de retentativas (retries) falhar para um determinado registro ou lote de dados, a melhor prática de tolerância a falhas é descartar permanentemente os dados com falha para não interromper o processamento dos dados subsequentes.
response: Errado
comment: Nada disso! A melhor prática não é simplesmente jogar dados fora porque eles falharam. A prática correta é mover esses dados "problemáticos" para uma "fila de cartas mortas" (Dead-Letter Queue - DLQ). Lá, os engenheiros podem analisar o que deu errado (era um dado mal formatado? Um bug?) e decidir o que fazer, sem travar o processamento dos dados bons que vêm em seguida.
Other fields (not shown on cards):
back: Errado - Nada disso! A melhor prática não é simplesmente jogar dados fora porque eles falharam. A prática correta é mover esses dados "problemáticos" para uma "fila de cartas mortas" (Dead-Letter Queue - DLQ). Lá, os engenheiros podem analisar o que deu errado (era um dado mal formatado? Um bug?) e decidir o que fazer, sem travar o processamento dos dados bons que vêm em seguida.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) A tolerância a falhas em pipelines de dados modernos (DataOps) foca-se mais na resiliência da infraestrutura do que na qualidade dos dados, pois falhas de infraestrutura são consideradas mais críticas do que problemas como "data downtime" (dados ausentes ou errôneos).
response: Errado
comment: Nada disso! O DataOps, inspirado no DevOps, se preocupa tanto com a infraestrutura (pipelines rodando, CI/CD) quanto com a qualidade do dado. O livro "Data Quality Fundamentals" introduz o conceito de "data downtime" (tempo em que os dados estão errados ou ausentes) como uma métrica tão crítica quanto o "downtime" de um aplicativo. A qualidade do dado é central no DataOps.
Other fields (not shown on cards):
back: Errado - Nada disso! O DataOps, inspirado no DevOps, se preocupa tanto com a infraestrutura (pipelines rodando, CI/CD) quanto com a qualidade do dado. O livro "Data Quality Fundamentals" introduz o conceito de "data downtime" (tempo em que os dados estão errados ou ausentes) como uma métrica tão crítica quanto o "downtime" de um aplicativo. A qualidade do dado é central no DataOps.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) A adição de "jitter" (variação aleatória) aos tempos de espera em uma estratégia de exponential backoff é uma técnica usada para evitar que múltiplos clientes ou tarefas tentem se reconectar exatamente ao mesmo tempo (problema da "manada trovejante"), distribuindo assim a carga de novas tentativas.
response: Certo
comment: Esse é um detalhe técnico sutil, mas importante. Imagine que 1000 clientes (ou tasks) falham ao mesmo tempo e todos usam o mesmo exponential backoff (ex: esperar 8s). Daqui a 8 segundos, os 1000 vão tentar de novo ao mesmo tempo, derrubando o serviço de novo (é a "manada trovejante"). O "Jitter" adiciona um pequeno tempo aleatório (ex: 8s + 0.3s, 8s + 0.1s...). Isso "espalha" as tentativas e evita a manada.
Other fields (not shown on cards):
back: Certo - Esse é um detalhe técnico sutil, mas importante. Imagine que 1000 clientes (ou tasks) falham ao mesmo tempo e todos usam o mesmo exponential backoff (ex: esperar 8s). Daqui a 8 segundos, os 1000 vão tentar de novo ao mesmo tempo, derrubando o serviço de novo (é a "manada trovejante"). O "Jitter" adiciona um pequeno tempo aleatório (ex: 8s + 0.3s, 8s + 0.1s...). Isso "espalha" as tentativas e evita a manada.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) Em processamento de streaming, os checkpoints são cruciais para garantir o processamento "exactly-once" (exatamente uma vez), enquanto em processamento batch, eles são primariamente usados para otimizar o tempo de recuperação (recovery time) de jobs longos.
response: Certo
comment: A função do checkpoint muda um pouco dependendo do contexto. No streaming (fluxo contínuo), o checkpoint salva o estado (ex: "já processei até o offset X") para garantir semânticas de processamento (como exactly-once ou at-least-once). No batch, como o job é finito (tem começo, meio e fim), o checkpoint é mais usado para otimizar a recuperação de jobs muito longos.
Other fields (not shown on cards):
back: Certo - A função do checkpoint muda um pouco dependendo do contexto. No streaming (fluxo contínuo), o checkpoint salva o estado (ex: "já processei até o offset X") para garantir semânticas de processamento (como exactly-once ou at-least-once). No batch, como o job é finito (tem começo, meio e fim), o checkpoint é mais usado para otimizar a recuperação de jobs muito longos.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) Segundo os princípios de DataOps, a testagem de dados (data testing) é uma medida reativa de tolerância a falhas, aplicada somente após a ocorrência de um incidente de qualidade de dados em produção.
response: Errado
comment: O DataOps prega exatamente o oposto. A testagem deve ser proativa. Assim como no DevOps se testa o código antes de ir para produção (o chamado "shift-left testing"), no DataOps se testa o dado antes dele chegar ao dashboard final. Esperar o usuário final (o "chefe") avisar que o dashboard está quebrado é a definição de uma abordagem reativa, que é o que o DataOps tenta eliminar.
Other fields (not shown on cards):
back: Errado - O DataOps prega exatamente o oposto. A testagem deve ser proativa. Assim como no DevOps se testa o código antes de ir para produção (o chamado "shift-left testing"), no DataOps se testa o dado antes dele chegar ao dashboard final. Esperar o usuário final (o "chefe") avisar que o dashboard está quebrado é a definição de uma abordagem reativa, que é o que o DataOps tenta eliminar.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) Falhas transientes, como um "timeout" momentâneo de rede ou um bloqueio temporário de banco de dados (deadlock), são os candidatos ideais para serem tratados com estratégias de retentativa (retry) automática.
response: Certo
comment: Isso é a definição de manual de para que servem os retries. Falhas transientes (ou transitórias) são aquelas que "vão embora" sozinhas. Uma piscada na rede, um serviço que reiniciou e ficou 1 segundo fora, um deadlock no banco que é resolvido automaticamente. Nesses casos, simplesmente tentar de novo alguns segundos depois resolve o problema.
Other fields (not shown on cards):
back: Certo - Isso é a definição de manual de para que servem os retries. Falhas transientes (ou transitórias) são aquelas que "vão embora" sozinhas. Uma piscada na rede, um serviço que reiniciou e ficou 1 segundo fora, um deadlock no banco que é resolvido automaticamente. Nesses casos, simplesmente tentar de novo alguns segundos depois resolve o problema.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) Em um sistema de dados robusto e tolerante a falhas, o erro humano é considerado uma falha do sistema, que deveria ser projetado para ser tolerante a humanos, e não uma falha do indivíduo que cometeu o erro.
response: Certo
comment: Certíssimo. Esse é um pilar cultural do SRE (Site Reliability Engineering) e do DataOps, que vem da ideia de "blameless postmortem" (análise de falha sem culpa). A culpa nunca é do "estagiário que rodou o script errado". A pergunta é: "Por que o sistema permitiu que o estagiário rodasse esse script em produção sem uma validação?" Um sistema robusto tem proteções (checkpoints, testes, circuit breakers) que tornam difícil para um humano, por acidente, quebrá-lo.
Other fields (not shown on cards):
back: Certo - Certíssimo. Esse é um pilar cultural do SRE (Site Reliability Engineering) e do DataOps, que vem da ideia de "blameless postmortem" (análise de falha sem culpa). A culpa nunca é do "estagiário que rodou o script errado". A pergunta é: "Por que o sistema permitiu que o estagiário rodasse esse script em produção sem uma validação?" Um sistema robusto tem proteções (checkpoints, testes, circuit breakers) que tornam difícil para um humano, por acidente, quebrá-lo.