Sabatina oral com banca

Resposta-modelo

Big Data é o conjunto de situações em que volume, velocidade e variedade dos dados, juntos, quebram a abordagem de um banco relacional único. O termo existe porque a resposta clássica, comprar uma máquina maior, parou de escalar em custo e em teto físico, e porque passaram a chegar dados que não cabem num schema fixo, como log, JSON e áudio. A virada foi passar a distribuir armazenamento e processamento por muitas máquinas comuns. Hoje eu acrescentaria veracidade, que trata da confiabilidade do dado, e valor, que cobra retorno de tudo que a gente guarda. Na prática, no banco, isso aparece quando o caso de uso mistura transação estruturada com clique de app e áudio de atendimento, e ainda precisa de resposta rápida.

O que o avaliador espera

• 1Definiu Big Data como característica do problema, não como ferramenta
• 2Citou os 3 Vs e explicou cada um com uma frase própria
• 3Explicou por que escalar verticalmente parou de resolver
• 4Acrescentou veracidade e valor ligando ao negócio
• 5Deu um exemplo concreto do contexto bancário

Resposta-modelo

Como camada de armazenamento primária, na maioria dos casos não. O motivo estrutural é que o HDFS acopla armazenamento e computação: para guardar mais dado eu preciso manter mais nós ligados, mesmo sem processar nada. Com S3 eu separo os dois: pago armazenamento durável barato o tempo todo e subo computação só enquanto o job roda, com vários clusters lendo o mesmo dado. Some a isso durabilidade e disponibilidade gerenciadas, sem NameNode para operar, e o custo por terabyte, que é bem menor que manter réplica 3 em disco de servidor. O argumento clássico a favor do HDFS era data locality, mas a rede de datacenter ficou rápida o suficiente para isso deixar de ser decisivo. Onde eu ainda usaria HDFS: como armazenamento temporário dentro do cluster para estágio intermediário, e em parque on-premises já pago ou com restrição regulatória de residência do dado.

O que o avaliador espera

• 1Nomeou separação de armazenamento e computação como razão principal
• 2Explicou o ganho de elasticidade e de custo com exemplo concreto
• 3Disse que data locality perdeu peso e por quê
• 4Apontou pelo menos um caso em que HDFS ainda se justifica
• 5Não reduziu o argumento a 'Spark é mais rápido'

Resposta-modelo

Depende de qual fraude. Para bloquear a autorização enquanto a compra acontece, só existe stream: o score precisa sair em algo como duzentos milissegundos, então eu leio o evento de autorização de um tópico, mantenho estado por cartão com as últimas transações e aplico o modelo em memória. O preço disso é cluster ligado o tempo todo, estado para operar, plantão e reprocessamento difícil quando a regra muda. Para investigação e para o reporte de operações suspeitas, eu faço batch: janela diária, todo o histórico disponível, lógica mais pesada e resultado reproduzível para auditoria. Na prática eu desenharia os dois em cima do mesmo evento: stream para a decisão em linha e batch para reprocessar, recalibrar o modelo e corrigir o que o stream errou. E eu usaria event time da autorização, não a hora de chegada, para que o número do dia não mude a cada reprocessamento.

O que o avaliador espera

• 1Separou fraude em linha, que exige stream, de investigação e reporte, que cabe em batch
• 2Citou um número de latência para a decisão em linha e ligou a decisão a esse requisito
• 3Nomeou os custos do stream: cluster contínuo, estado, operação, reprocessamento
• 4Propôs a combinação das duas rotas sobre o mesmo evento em vez de escolher só uma
• 5Mencionou event time e por que ele importa para reprodutibilidade

Resposta-modelo

Até a chamada de count, nada tinha executado: filter, withColumn e groupBy só foram acrescentando nós ao plano lógico, porque transformação no Spark é lazy. Quando eu chamo count, que é uma ação, o driver fecha o plano, passa pelo Catalyst para otimizar, gera o plano físico e monta o DAG. Aí ele divide esse DAG em stages, e a fronteira de cada stage é um shuffle: o groupBy precisa juntar a mesma chave no mesmo executor, então tudo que vem antes vira um stage e o que vem depois vira outro. Cada stage é quebrado em tasks, uma por partição, e o driver agenda essas tasks nos executores que o cluster manager alocou. Os executores leem suas partições, aplicam as operações e, no fim do stage com shuffle, gravam a saída para o próximo stage ler. No último estágio, cada task devolve uma contagem parcial e o driver soma. O único dado que volta ao driver é esse número.

O que o avaliador espera

• 1Afirmou que nada executou antes da ação e nomeou lazy evaluation
• 2Descreveu a cadeia plano lógico, otimização, plano físico, DAG
• 3Explicou a divisão em stages pelo shuffle causado pelo groupBy
• 4Disse que cada stage vira tasks, uma por partição, agendadas pelo driver nos executores
• 5Deixou claro o que volta ao driver e por que isso é pouco no caso do count

Resposta-modelo

Sem zona, o lake vira pântano: todo mundo grava onde quer, ninguém sabe o que existe, e o dado deixa de ser confiável mesmo estando lá. Zonear é declarar um contrato por camada. A transient é área de pouso, onde o arquivo espera checagem de integridade e é expurgado em horas. A raw é a cópia fiel da origem, imutável, e é o que me permite reprocessar quando uma regra muda. A trusted é o dado já validado, deduplicado e padronizado, com schema estável, que outro time consome sem reler a origem. A refined é o dado modelado para uma pergunta de negócio, como gasto por cliente e categoria. E zona não é só pasta: cada uma tem retenção, permissão, dono e regra de qualidade próprios. É isso que evita que o lake vire um diretório caro de arquivos órfãos.

O que o avaliador espera

• 1Nomeou o pântano de dados como o risco concreto de não zonear
• 2Listou as quatro zonas e disse a garantia de cada uma, não só o nome
• 3Explicou por que a raw é imutável, ligando a reprocessamento e auditoria
• 4Disse que zona inclui retenção, acesso, dono e contrato de schema, não só pasta
• 5Usou pelo menos um exemplo bancário concreto

Resposta-modelo

O data lake é barato, aberto e aceita qualquer formato, mas não dá garantia nenhuma: a tabela é o que estiver no diretório, então escrita parcial vira número errado e ninguém sabe qual versão do dado leu. O data warehouse dá transação, schema e governança, mas cobra caro, prende o dado em formato proprietário e não lida bem com log e arquivo não estruturado. O Lakehouse junta as duas metades boas: os dados ficam em arquivo aberto no object storage, e por cima entra um formato de tabela, como o Delta Lake, que traz transação ACID, controle de schema, histórico de versões e estatísticas para performance. Na prática, no banco, isso significa manter uma cópia só do dado, servindo ao mesmo tempo o pipeline de engenharia, o painel de negócio e o modelo de fraude, com governança única no Unity Catalog.

O que o avaliador espera

• 1Nomeou a limitação concreta do lake (sem garantia transacional) e a do warehouse (custo e formato fechado)
• 2Definiu Lakehouse como arquitetura, não como produto
• 3Citou o formato de tabela como a peça que fecha a lacuna
• 4Deu um benefício operacional concreto, como cópia única de dado servindo vários consumos

Resposta-modelo

Eu separaria em duas decisões. Na entrada, gravo o JSON cru na raw, sem tocar em nada, porque é a evidência do que o produtor mandou e é o que me permite reprocessar quando o schema mudar. Na leitura, eu declaro o schema explicitamente em vez de deixar o Spark inferir: inferência lê um pedaço do arquivo, custa tempo e, pior, muda o resultado quando a amostra muda. Na trusted, eu achato o que o negócio consulta de fato, usando explode para os arrays de parcela, e materializo em tabela Delta colunar particionada por data. O que é genuinamente variável eu mantenho num campo de mapa ou string, para não quebrar o contrato a cada campo novo. Assim o consumidor consulta tabela colunar barata, e eu ainda tenho o cru para voltar atrás. Guardar JSON cru na camada analítica é o erro que eu evitaria: custa mais para ler e não aproveita estatística nem poda de partição.

O que o avaliador espera

• 1Separou armazenamento na raw do formato de consumo na trusted
• 2Disse que declara o schema em vez de inferir, com justificativa
• 3Citou achatamento ou explode de estrutura aninhada
• 4Justificou o formato colunar no consumo por custo de leitura ou data skipping
• 5Disse o que deixaria flexível e por quê

Resposta-modelo

Primeiro eu contenho: aviso o consumidor do relatório, marco o número como suspeito e uso a linhagem para achar onde a divergência nasceu, comparando com a fonte no core. Depois separo o tipo de erro. Se foi regra de negócio mal definida, isso é do data owner da área, e a correção é acertar a definição no glossário e no catálogo. Se foi execução, é minha, como custodiante, e a correção é no pipeline mais um teste que pegue aquilo antes de publicar. Para não repetir, eu quero três coisas: dono nomeado para aquele indicador, teste de qualidade que rode antes da publicação e falhe o job, e o número publicado por uma única tabela certificada, não por cada área recalculando do seu jeito. Fecho registrando o incidente com causa raiz, porque em banco isso vira evidência para auditoria.

O que o avaliador espera

• 1Separou contenção imediata de correção estrutural
• 2Usou linhagem para localizar a origem da divergência
• 3Atribuiu responsabilidade ao papel certo: owner define a regra, custodiante executa
• 4Propôs controle preventivo verificável, como teste que barra a publicação
• 5Citou fonte única certificada em vez de cálculo replicado por área

Resposta-modelo

Eu uso window function. Numa CTE, faço ROW_NUMBER particionado por id_conta e ordenado por data_transacao descendente, e fora da CTE filtro pela numeração igual a um. Não uso GROUP BY porque a agregação colapsa o grupo: eu conseguiria o MAX da data, mas perderia valor, estabelecimento e canal daquela linha, e precisaria de um segundo join com a mesma tabela para recuperá-los, o que custa outra leitura e outro shuffle. Um detalhe que eu cuidaria é o desempate: se duas transações tiverem exatamente o mesmo timestamp, ROW_NUMBER escolhe uma arbitrariamente, então eu acrescento o id_transacao como segundo critério de ordenação para o resultado ser determinístico e o reprocessamento dar sempre o mesmo dado. Em Databricks eu escreveria isso com QUALIFY, que dispensa a CTE; em Spark SQL puro, mantenho a CTE.

O que o avaliador espera

• 1Escolheu ROW_NUMBER com PARTITION BY e ORDER BY corretos
• 2Explicou por que GROUP BY perde as demais colunas e custaria um segundo join
• 3Tratou desempate para tornar o resultado determinístico
• 4Citou QUALIFY como alternativa e disse em qual motor ela existe