ANÚNCIO

~/questoes/dados

Qual é o principal propósito de usar macros em dbt?

Responda, confira o feedback e use o resultado para orientar sua revisão.
Dados e BI Macros em dbt Intermediario
Aula de referência dbt: visão geral para engenharia e modelagem de dados
Para fixar

Macros em dbt: Reutilização de Código e o Princípio DRY

Conceito central

Macros são funções reutilizáveis escritas em Jinja2 que encapsulam lógica comum (validações, transformações, filtros) dentro de dbt. Seu principal propósito é eliminar duplicação de código, permitindo que a mesma funcionalidade seja usada em múltiplos modelos sem copiar e colar o mesmo SQL várias vezes.

Por que essa resposta faz sentido

Macros existem especificamente para implementar o princípio DRY (Don't Repeat Yourself). Em vez de repetir uma validação de data ou um filtro de negócio em 50 modelos diferentes, você escreve uma macro uma única vez e a chama onde necessária, tornando o código mais limpo, fácil de manter e menos propenso a erros.

Armadilhas comuns

  • Confundir macros com configurações de materialização; macros não definem se um modelo é table ou view.
  • Pensar que macros servem para gerenciar segurança e permissões; esse é papel do data warehouse, não de dbt.
  • Entender macros apenas como 'atalhos', quando na verdade são funções completas que podem conter lógica complexa, loops e condicionais.

Entenda as alternativas

A

Controle de permissões e acesso a tabelas é responsabilidade do data warehouse (Snowflake, BigQuery, Redshift) e suas configurações de segurança nativas, não de macros em dbt.

B

Esta é a resposta correta. Macros encapsulam lógica reutilizável através de Jinja2, evitando repetição de código e seguindo o princípio DRY. Exemplos: validações customizadas, transformações padrão, filtros de negócio.

C

Tipo de materialização (table, view, incremental) é configurado no arquivo de config YAML do modelo ou diretamente no bloco `{{ config() }}` dentro do SQL, não através de macros.

D

Credenciais e secrets devem ser armazenados em variáveis de ambiente ou gerenciadores de secrets (como dbt Cloud ou HashiCorp Vault), nunca em repositórios git, independentemente do uso de macros.

Dica prática: Quando você se vê copiando o mesmo trecho de SQL em múltiplos modelos, esse é o sinal de que precisa criar uma macro. Por exemplo: se todos os seus modelos precisam validar datas, crie um macro `validate_date()` e reutilize em qualquer lugar com uma única linha.

Revise pensando: Se você tivesse que aplicar a mesma lógica de filtro de dados em 10 modelos diferentes, qual seria a vantagem de usar uma macro em vez de copiar e colar o código?