Ainda me lembro da primeira vez que me deparei com o dbt Labs. Foi por volta de meados de 2019 e, como a maioria das consultorias de dados naquela época, nosso trabalho era principalmente baseado em pipelines de ETL escritos em código usando infraestrutura de cloud de nível mais baixo, como se via na maioria dos blogs de engenharia de startups de tecnologia. O ETL baseado em código, antes do dbt, exigia engenheiros de dados experientes. Como uma consultoria relativamente pequena em um mercado de engenharia de dados extremamente aquecido, achávamos difícil escalar nosso time sem uma abordagem diferente. Além disso, a maior parte da nossa equipe não tinha formação em engenharia naquela época. Nosso CTO insistia na adoção de boas práticas de engenharia de software aplicadas a dados, com base na experiência que teve trabalhando com pipelines de big data em seu trabalho anterior. Depois de ler alguns posts do blog de Tristan Handy sobre Analytics Engineering e dbt, ficou claro para nós que o dbt poderia ser a peça que faltava para permitir que nossos analistas trabalhassem como engenheiros ou, de forma simples, que se tornassem analytics engineers.

Olhando em retrospectiva, a genialidade das primeiras versões do dbt não estava na complexidade do código ou das funcionalidades, mas sim na sua simplicidade. A maioria das ferramentas legadas de ETL, como Informatica ou Pentaho, voltadas para profissionais não engenheiros, eram pesadas, muito cheias de funcionalidades e, pior ainda, tinham praticamente 0% de cobertura de boas práticas de engenharia de software, que são indispensáveis para o trabalho moderno com dados. Por outro lado, trabalhar com plataformas modernas de dados, como Snowflake e Databricks, exige um nível de conhecimento técnico muito mais profundo do que um analista de dados típico costuma ter, tornando esse ambiente praticamente exclusivo de engenheiros de dados. Isso significava que, para a maioria das empresas, mesmo sendo possível construir pipelines de dados ordens de magnitude mais rapidamente do que as tecnologias anteriores permitiam, havia uma limitação real na capacidade de escalar a área de dados, já que existiam poucos profissionais capazes de trabalhar com essas plataformas. Para piorar, muitos engenheiros de dados não gostam de falar com usuários de negócios ou até mesmo de escrever queries SQL, o que acabava mantendo a área de dados inevitavelmente distante das linhas de negócios onde, de fato, está o valor dos dados.

Naquela época, apesar de o dbt ainda estar em seus estágios iniciais, em poucos meses conseguimos construir uma prática totalmente nova de analytics engineering baseada nele, formada por profissionais sem formação em engenharia de software, mas com habilidades analíticas muito fortes. Para acelerar esse movimento, desenvolvemos nosso curso de analytics engineering, aberto ao público, que desde então já formou mais de 1000 analytics engineers que hoje trabalham na Indicium, em nossos clientes ou em diversas outras empresas. Até hoje estamos entre os parceiros dbt com mais certificações no mundo. Não há dúvida de que o dbt é uma peça fundamental para qualquer time moderno de dados.

E o dbt Cloud?

Bem, para muitos adotantes iniciais como nós, o dbt Core já era suficiente para o nosso trabalho. Além disso, muitas das funcionalidades lançadas nas primeiras versões do dbt Cloud já haviam sido desenvolvidas pelos nossos times de plataforma ou pela comunidade open source. Até pouco tempo atrás, em certo sentido, fazia sentido continuar apenas com o dbt Core. E não me entenda mal: muitas dessas funcionalidades são necessárias para que o dbt Cloud seja, por si só, uma boa ferramenta. O problema para o dbt Labs era que, para muitas empresas que adotavam o dbt, conforme elas saíam da caverna de Platão da ignorância em relação ao modern data stack, surgiam tantas possibilidades de melhorar as práticas da plataforma de dados com dbt que a maioria dos times de plataforma acabava se tornando usuária avançada da ferramenta, o que, na minha opinião, não correspondia à principal persona do dbt Cloud. Mas então, quem seria essa persona?

Acredito que existam três principais personas para o dbt Cloud: a) empresas que já nascem dentro do modern data stack e não têm ou não querem manter um time de dados grande; b) empresas enterprise que querem escalar sua implementação de dbt Core para as linhas de negócio e buscam uma ferramenta que permita aplicar boas práticas de gestão e governança de dados, mantendo a complexidade baixa para times de analytics de LOB menos técnicos; e c) empresas que demoraram mais para adotar um data warehouse em cloud e que agora estão migrando para longe de tecnologias legadas de dados, como Talend e Informatica. Até aqui, nem sempre a proposta era convincente o suficiente para que algumas dessas personas adotassem e implementassem o dbt Cloud. Então por que eu acho que isso vai mudar?

Na minha visão, os novos anúncios do dbt no Coalesce deste ano apontam todos na direção certa. Primeiro, o dbt está reconhecendo que precisa fazer mais do que apenas a transformação de dados se quiser se tornar a ferramenta única de dados para organizações menores e/ou para empresas que não contam com um time dedicado de plataforma de dados. Recursos como orquestração, catalogação de dados e até ingestão de dados são necessários. Hoje, todos eles exigem um conjunto de ferramentas diferentes, que podem ser difíceis de integrar e também custosas. A visão de o dbt se tornar um data control plane faz sentido e acompanha a tendência de consolidação que nós, na Indicium, temos observado no espaço do modern data stack nos últimos anos.

A estratégia One dbt

Possivelmente, o maior anúncio do Coalesce foi a estratégia One dbt. Em primeiro lugar, há valor real em uma abordagem híbrida entre dbt Core e dbt Cloud, em que o primeiro é desenvolvido por times de plataforma ou centros de excelência, enquanto o segundo é voltado a times de LOB menos técnicos. Uma experiência de primeira linha para esse modelo híbrido dentro do dbt Cloud é algo essencial para muitos dos nossos clientes enterprise.

Em segundo lugar, embora a maioria das funcionalidades avançadas do dbt Cloud já tivesse sido desenvolvida internamente por usuários avançados de dbt, isso não se aplica às arquiteturas híbridas de cloud e data mesh. Não existe hoje uma única ferramenta ou plataforma capaz de lidar com essa prática, cada vez mais comum em grandes empresas, mesmo quando se usa o mesmo provedor de cloud, como em ambientes com Databricks e Snowflake. Com o Iceberg se consolidando como padrão de fato para armazenamento moderno de dados, existe uma oportunidade real para o dbt se tornar a peça que falta entre essas plataformas, permitindo que os times desenvolvam suas ferramentas sem abrir mão da governança e das boas práticas de DataOps.

Por fim, embora exista há muito tempo um impasse entre desenvolvimento em código e desenvolvimento no-code ou low-code para transformação de dados, esse é um recurso indispensável para engenheiros menos técnicos e uma exigência muito comum em empresas enterprise. Ter essa funcionalidade dentro do dbt Cloud e integrada ao ciclo de desenvolvimento do dbt é uma decisão acertada da dbt.

Estou convencido de que o dbt é a ferramenta mais disseminada da plataforma moderna de dados. Mais do que uma ferramenta, o dbt permitiu que as empresas reduzissem a distância entre negócios e dados com o surgimento do papel de Analytics Engineering. Para o dbt Labs, ironicamente, o produto dbt Cloud acabou sofrendo justamente por causa das qualidades do produto original. Embora sempre tenham existido empresas para as quais o dbt Cloud fosse a melhor escolha, uma parte significativa do mercado tinha dificuldade para enxergar com clareza onde o dbt Core deixava lacunas. Com a nova estratégia e os anúncios de lançamento, o dbt Cloud passa a resolver necessidades técnicas reais e a atender demandas de negócio que o dbt Core não consegue cobrir, e eu consigo ver cada vez mais casos de uso em que o dbt Cloud oferece uma vantagem realmente convincente em relação a rodar apenas o dbt Core.