Databricks
Folha de revisão · 2 temas · Engenharia de Dados
Feita para a véspera. Imprimir esta página tira o menu e as abas.
Lakehouse e Delta Lake
É o coração da stack que o banco usa. A banca costuma abrir com 'o que é lakehouse' e fechar com 'por que Delta e não Parquet puro', que é onde se vê quem já quebrou um pipeline com escrita parcial e quem só leu o release note.
Como cai: Por que usar Delta e não simplesmente Parquet no S3?
Erros comuns
- Dizer que Delta Lake é um formato de arquivo. Não é: o arquivo continua sendo Parquet. Delta é um formato de tabela, ou seja, Parquet mais um log transacional que diz quais arquivos formam a tabela agora.
- Confundir Lakehouse com Databricks. Lakehouse é uma arquitetura; Databricks é uma plataforma que a implementa, e Iceberg e Hudi implementam a mesma ideia com outro formato.
- Achar que time travel substitui backup. O histórico vive enquanto o VACUUM não remover os arquivos antigos e enquanto o log for retido; não é cópia independente nem sobrevive à exclusão da tabela.
- Rodar VACUUM com retenção curta para economizar espaço. Isso apaga o histórico, quebra o time travel e pode derrubar leitores de longa duração que ainda apontam para arquivos antigos.
- Usar Z-ORDER em coluna de alta cardinalidade única, como o id da transação, esperando ganho. Z-ORDER ajuda em colunas usadas em filtro, e o ganho vem do data skipping, não da ordenação em si.
- Escrever com overwrite na trusted achando que é atômico no Parquet puro. Sem log transacional, um job que morre no meio deixa a tabela com parte dos arquivos novos e parte dos velhos.
Vocabulário
- concorrência otimista
- — Cada escritor lê a versão atual, faz o trabalho e tenta registrar a próxima versão. Se outro chegou primeiro, ele relê o que mudou e tenta de novo.
Databricks: a plataforma
É a plataforma que o banco usa no dia a dia, então a banca deixa de perguntar conceito e passa a perguntar operação: onde roda, quanto custa, quem tem acesso. Errar a diferença entre cluster interativo e cluster de job entrega que você nunca respondeu por uma fatura.
Como cai: Como você organizaria o acesso a dados sensíveis dentro do Databricks?
Erros comuns
- Dizer que Databricks é o Spark. Databricks é uma plataforma gerenciada construída em volta do Spark, com runtime próprio, catálogo, orquestração e governança; o Spark é o motor dentro dela.
- Rodar pipeline de produção em cluster all-purpose. Além de custar mais por DBU do que job compute, o cluster fica ligado ocioso entre execuções e vira a maior linha da fatura.
- Tratar Unity Catalog como um catálogo de metadados a mais. Ele é o ponto único de permissão, linhagem e auditoria; sem ele, o controle de acesso volta a ser por bucket e some a rastreabilidade.
- Achar que Auto Loader é só um read de diretório. Ele mantém checkpoint do que já foi processado, então reprocessamento não duplica e arquivo novo é detectado sem varrer o diretório inteiro toda vez.
- Confundir schema do Unity Catalog com schema de dados. No namespace de três níveis, schema é o nível intermediário, equivalente ao database; schema de dados é o contrato das colunas.
- Esquecer que o dado continua no S3 do banco. Databricks não guarda os dados: a computação é gerenciada, o armazenamento é da conta AWS da instituição, e isso muda a conversa com segurança.
Vocabulário
- checkpoint
- — Registro persistente de quais arquivos já foram processados, para que a próxima execução continue de onde parou.