Implementação de dbt
Configuramos o dbt com modelos organizados em camadas, testes junto ao código e lançamentos via Git. A Fokker Services Group utiliza dbt na sua plataforma de dados.
Na Fokker Services Group, os dados de várias fontes são limpos e modelados em Databricks com dbt
“A plataforma de dados é, para nós, o ponto central onde os dados se reúnem. Permite-nos disponibilizar dados para obter insights de negócio em toda a empresa e, ao mesmo tempo, garantir que existe apenas 1 versão da realidade” Daan Mastenbroek, engenheiro principal de dados e arquiteto
Como é que dois dashboards podem apresentar valores de faturação diferentes para o mesmo período?
A regra de cálculo da faturação está numa view que ninguém se atreve a alterar, numa medida do Power BI e no notebook de um colega que já saiu. O dbt reúne essa lógica num só lugar, em modelos SQL no Git, com testes.
A sua equipa fica com um projeto dbt que consegue ler, testar e expandir por si própria
Modelos em três camadas
A camada staging renomeia os dados de origem e atribui-lhes tipos; a intermediate faz os cálculos; e a marts fornece tabelas por tema. Assim, cada cálculo fica num único local.
Testes junto dos modelos
Os data tests verificam chaves e referências; os unit tests verificam a lógica mais complexa. Na plataforma de dados da Vivara, o dbt está a par do Databricks e do Terraform.
Releases através de pull requests
Cada alteração é primeiro construída num esquema próprio e passa pelos testes. Só depois de uma revisão e de uma verificação positiva é que chega à produção.
Documentação e lineage
O dbt gera documentação e um grafo de dependências a partir do código. Para o Koninklijk Concertgebouworkest, trabalhamos com dbt, Delta Lake e Unity Catalog.
Primeiro, os números em discussão; depois, o resto da fonte de dados
-
Mapear a lógica existente
Reunimos as views, stored procedures e measures que atualmente fazem os cálculos e decidimos quais os números a migrar primeiro.
-
Primeiros modelos com testes
Fontes, staging e um mart para esses números, com testes e uma verificação de CI em cada pull request.
-
Transferir e expandir
A sua equipa participa no desenvolvimento dos modelos, as decisões ficam documentadas no repositório e as views antigas só são desativadas quando os números estiverem corretos.
É o dbt a camada certa para as nossas transformações?
É adequado se
Os seus dados já estão num data warehouse ou lakehouse, a sua equipa escreve SQL e as regras de cálculo estão dispersas por views, scripts e relatórios. O dbt reúne-as, com controlo de versões e testes.
Não é adequado se
Os dados ainda têm de ser extraídos dos sistemas de origem: o dbt não carrega dados por si só, pelo que é primeiro necessária uma pipeline ou um conector. Se precisar apenas de alguns relatórios de um único sistema, um modelo Power BI é muitas vezes suficiente.
Do que depende a dimensão do trabalho
Do número de fontes e de views existentes, da quantidade de lógica que está atualmente nos relatórios, da existência de Git e de uma pipeline de CI, da plataforma subjacente e de quem fará a manutenção dos modelos depois.
Ficamos depois dependentes da dbt Labs?
Os modelos são ficheiros SQL e YAML no seu próprio repositório Git. O dbt v1 e o dbt OSS estão abrangidos pela licença open-source Apache 2.0. A plataforma dbt alojada é um produto separado, com condições próprias.
Devemos executar o dbt Core por nossa conta, escolher a plataforma dbt ou executar o dbt no Databricks ou no Fabric?
Executar o dbt Core por sua conta
Escolha esta opção se já tiver um orquestrador e uma pipeline de CI, e quiser gerir as execuções, a documentação e as atualizações do dbt.
A plataforma dbt
Escolha esta opção se várias equipas e analistas trabalharem em dbt. Terá um IDE no navegador, agendamento, CI por pull request e documentação alojada.
No Databricks ou no Fabric
Escolha esta opção se a plataforma já estiver definida: uma tarefa dbt no Lakeflow Jobs ou um job dbt no Fabric é executado juntamente com as suas pipelines. A nossa recomendação para uma única equipa.
Usamos dbt nas plataformas de dados da Fokker Services Group, da Vivara e do Concertgebouworkest
A Data Science Lab trabalha com dados e IA desde 2016 e é Databricks Partner e Microsoft Partner. Escolhemos uma plataforma adequada à sua organização e configuramos nela o dbt como camada para as suas transformações.

Na primeira conversa, falamos sobre onde estão atualmente as suas regras de cálculo
Stef Stoelwinder
Desenvolvimento de NegócioStef é o seu primeiro ponto de contacto. Na primeira conversa, falamos sobre a sua plataforma, onde estão atualmente as regras de cálculo e quem ficará responsável pela sua manutenção.
E-mail info@datasciencelab.nl
Telefone +31 (0)20 3636 724
Que cálculos devem ser migrados primeiro para o dbt?
Descreva a sua plataforma e onde são atualmente executadas as transformações. Receberá uma resposta por e-mail ou agendaremos uma primeira conversa.
Mensagem enviada
Obrigado pela sua mensagem. Entraremos em contacto consigo o mais rapidamente possível.
Perguntas frequentes
O dbt é uma ferramenta para o T de ELT: transforma dados que já estão no seu warehouse ou lakehouse. Escreve um modelo como uma instrução SQL SELECT ou um dataframe em Python, e o dbt transforma-o numa view ou tabela e trata do DDL.
Os modelos referenciam-se entre si com ref(), pelo que o dbt conhece a ordem e a lineage. Os testes e a documentação ficam junto do código. O dbt não carrega dados dos sistemas de origem. É um dos componentes da sua fundação de dados.
O dbt Core é a versão de linha de comandos que instala e executa por sua conta. O dbt Cloud é o produto alojado, a que a dbt Labs agora chama dbt platform. Acrescenta um IDE no browser, agendamento de jobs, CI por pull request, documentação alojada e notificações. O Catalog e a Semantic Layer só estão disponíveis em determinadas subscrições.
O motor tem agora duas gerações. O dbt v1 é a versão em Python, ainda mantida e distribuída sob a licença Apache 2.0. O dbt v2 funciona num novo motor em Rust e é a instalação predefinida; o dbt OSS é a sua versão distribuída sob a licença Apache 2.0.
A dbt Labs recomenda três camadas. A camada Staging cria um modelo limpo por tabela de origem, com o prefixo stg_. A camada Intermediate combina dados e faz cálculos para um objetivo específico. Os marts disponibilizam as entidades com que a organização trabalha, como clientes e encomendas. Assim, os dados passam da estrutura da origem para a linguagem do negócio.
Comece com views; transforme em tabelas os modelos que o Power BI lê. Use modelos incrementais, que processam apenas linhas novas, quando as execuções se tornarem demasiado lentas.
Os data tests verificam os dados depois da construção do modelo: uma chave é única, não faltam valores, cada encomenda remete para um cliente existente? Os unit tests verificam a sua lógica SQL com um pequeno exemplo fixo antes da construção; a dbt Labs recomenda executá-los apenas durante o desenvolvimento e em CI.
Para os modelos de que outras equipas dependem, defina um contrato com os nomes das colunas e os tipos de dados; se o resultado não corresponder, o modelo não é construído. Saiba que regras deve monitorizar em melhorar a qualidade dos dados.
No Databricks, usa o adaptador dbt-databricks e executa o projeto como uma tarefa dbt no Lakeflow Jobs, num SQL warehouse. A identidade com que o job é executado precisa de permissões no Unity Catalog para o catálogo, o esquema e as tabelas que os modelos leem e escrevem. O Databricks recomenda fixar a versão do adaptador. Consulte implementação do Databricks.
No Fabric, existe um job dbt no Data Factory, ainda em preview, que executa o dbt Core num warehouse ou lakehouse. Consulte implementação do Microsoft Fabric.
Com um snapshot. O dbt regista cada alteração como uma nova linha, com as colunas dbt_valid_from e dbt_valid_to: uma slowly changing dimension de tipo 2. É preferível ter uma coluna updated_at; se não existir, o dbt compara as colunas que indicar.
Se os dados da origem chegarem demasiado tarde, o source freshness assinala-o com um aviso ou um erro. Atenção: o dbt build não executa esta verificação; é necessário adicioná-la como um passo separado no job.
Muitas vezes, na migração direta das views antigas: a mesma confusão passa a estar no dbt, apenas em Git. Sem um responsável por cada mart, o projeto também se torna uma teia de modelos que ninguém se atreve a remover.
Outras dificuldades são usar modelos incrementais demasiado cedo, não ter uma verificação de CI — pelo que os erros só são detetados em produção — e ter testes que emitem sempre avisos e, por isso, acabam por ser ignorados. O carregamento dos dados de origem pertence à data engineering; podemos tratar da manutenção posterior através da gestão e melhoria contínua.
Se criar alguns relatórios a partir de um único sistema e a lógica couber num só modelo do Power BI, o dbt acrescenta uma camada que alguém terá de manter. Da mesma forma, se a maior parte do trabalho envolver streaming ou processamento intensivo em Spark, esse trabalho pertence às pipelines; o dbt é adequado para os modelos que vêm depois.
E se ninguém na equipa quiser escrever ou rever SQL, um projeto dbt traz pouco valor. Se uma solução mais simples for mais adequada, dizemo-lo. Se quiser comparar fornecedores primeiro, consulte a nossa visão geral das consultoras de plataformas de dados.
Que componentes são necessários, além do dbt, para uma plataforma de dados fiável?
- Fundação de dadosComo construímos um ambiente de dados fiável, com dbt como camada de transformação.
- Data engineeringA extração e o carregamento de dados dos seus sistemas de origem, antes de dbt os processar.
- Melhorar a qualidade dos dadosQue verificações implementar na pipeline e na origem, e quem trata dos erros.