Então, por que todos estão tão empolgados com a aquisição recentemente anunciada e a futura integração do SDF, "uma cadeia de ferramentas de alto desempenho para desenvolvimento de SQL", ao dbt? Isso faz alguma diferença para o engenheiro de Analytics que adora o dbt por sua simplicidade? Na verdade, sim. E por alguns motivos diferentes.

Primeiro, à medida que os casos de uso do dbt se tornaram mais complexos, ficou claro que algumas escolhas de design em seu funcionamento interno prejudicaram parte da experiência do desenvolvedor. O ponto mais importante é que o dbt não é um analisador de SQL. Em termos mais simples, ele não entende SQL.

O dbt utiliza uma linguagem de modelos para adicionar lógica específica de banco de dados ao código SQL simples que os usuários escrevem. Embora eu não vá me aprofundar muito nesse assunto (você pode ler o anúncio oficial do dbt Labs aqui com explicações detalhadas), o fato de não ter um analisador significa que o dbt não pode otimizar o código SQL sem executá-lo no banco de dados, o que, em alguns projetos grandes, pode levar dezenas de minutos de tempo de engenharia desperdiçado em cada execução (ou horas por semana para cada desenvolvedor).

Além disso, isso obrigava as equipes de dados com arquiteturas complexas e multiplataforma a escrever macros sofisticadas para lidar com os diferentes dialetos de SQL de cada banco. Da mesma forma, migrações de banco de dados exigiam muito mais esforço do que será necessário quando o analisador de SDF estiver totalmente integrado ao dbt.

Em segundo lugar, há uma pressão competitiva vinda de outras empresas que ofereceram uma ferramenta semelhante ao dbt com analisadores de SQL, o que também torna esse movimento do dbt Labs uma estratégia defensiva. Com um analisador de SQL de alto desempenho, uma comunidade forte e uma adoção crescente por grandes empresas, o dbt está muito perto de se consolidar como o padrão definitivo em transformação de dados.