Ir para o conteúdo

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

Leia o caso de estudo

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.

Agende uma conversa
Een man wijst een collega op een cijfer in een uitgeprinte rapportage, met een laptop
# ernaast.

A sua equipa fica com um projeto dbt que consegue ler, testar e expandir por si própria

Fale connosco sobre o seu projeto dbt

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

  1. 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.

  2. 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.

  3. 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?

Avalie numa conversa

É 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.

Agende uma reunião de apresentação

Na primeira conversa, falamos sobre onde estão atualmente as suas regras de cálculo

Stef Stoelwinder

Stef Stoelwinder

Desenvolvimento de Negócio

Stef é 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.

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.

Introduza um endereço de e-mail válido.

Diga-nos como podemos ajudar.

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.