dbt
JuniorO ClickHouse agora está na plataforma dbt — o que isso realmente significa para o seu pipeline
O ClickHouse se tornou o primeiro adaptador v2 construído por um parceiro na plataforma dbt, com o novo motor Fusion do dbt baseado em Rust — isto é o que já dá para usar hoje.
Se você roda dbt contra Snowflake, BigQuery ou Postgres e está se perguntando se o ClickHouse agora é um destino realista, a resposta honesta é: está chegando lá, mas ainda não para produção.
O que foi realmente anunciado
O ClickHouse é agora o primeiro adaptador v2 construído por um parceiro na plataforma dbt, e o primeiro membro do Partner Adapter Program da dbt Labs. O novo adaptador roda sobre o motor v2 do dbt, batizado de Fusion — uma reescrita em Rust do núcleo do dbt, feita para velocidade, no lugar do antigo motor baseado em Python. Ele suporta tanto ClickHouse self-managed quanto ClickHouse Cloud como destinos, e (separadamente) o conector dbt-clickhouse já existente já funciona com transformações gerenciadas pelo Fivetran.
O que está pronto hoje, e o que não está
Essa é a parte que vale a pena ser precisa, porque "acabou de ser anunciado" e "pronto para apontar seu pipeline de produção" são coisas bem diferentes aqui. Segundo a própria orientação do ClickHouse:
- O adaptador v2 está em beta — instale e teste localmente, em uma instância self-managed de nó único ou no ClickHouse Cloud, em dev ou staging.
- Ele é explicitamente não recomendado para cargas de produção ainda.
- Contra a própria suíte de testes de integração v1 do dbt, ele passa em mais de 81% da suíte completa e 92% dos testes que realmente se aplicam ao ClickHouse Cloud especificamente (veja o gráfico acima).
- Capacidades do Fusion que o dbt ainda está construindo para esse adaptador incluem validação com reconhecimento de dialeto, análise estática, o language server, reconhecimento de colunas na extensão do VS Code, e lineage em nível de coluna no lado do motor — nada disso está totalmente pronto ainda.
Se você já usa o adaptador dbt-clickhouse mais antigo e estabelecido contra o dbt Core (não o novo caminho v2/Fusion), essa é uma integração separada e mais madura que é anterior a este anúncio e não é afetada por ele.
Por que vale a pena prestar atenção mesmo assim
Duas coisas são genuinamente interessantes aqui, independente do status beta. Primeiro, o próprio ClickHouse é feito para consultas analíticas rápidas com um perfil de custo difícil de igualar por warehouses orientados a linha, para o formato certo de carga de trabalho (agregações de alta cardinalidade, analytics em tempo real) — uma integração de primeira classe com o dbt baixa a barreira para realmente testar esse encaixe em vez de escrever SQL manualmente fora do grafo de dependências e do framework de testes do dbt. Segundo, o motor Rust do Fusion é a própria resposta do dbt para ciclos de desenvolvimento local lentos — se as promessas de velocidade se confirmarem conforme ele amadurece, é uma mudança real de qualidade de vida para qualquer fluxo de trabalho dbt, não só para quem usa ClickHouse.
Onde isso cruza com o opti-pipe, com honestidade: as regras de dbt aqui leem dados de tempo e contagem de linhas direto do run_results.json — elapsed_time e execution_time por modelo — que o dbt grava no mesmo formato independente de qual adaptador ou warehouse produziu a execução. Em princípio, o run_results.json de um projeto com destino ClickHouse deveria funcionar pelo mesmo fluxo de upload que qualquer outro. Dito isso, isso ainda não foi testado especificamente contra um arquivo produzido pelo adaptador do ClickHouse, então trate isso como uma expectativa razoável, não uma afirmação verificada.
Veja como isso fica no seu próprio pipeline.
Envie um event log real do Spark, um run_results.json do dbt, ou uma exportação de métricas do Flink, e receba recomendações concretas para aprovar — não mais uma regra de bolso.
Fonte: o anúncio oficial do ClickHouse, conferido com a cobertura do próprio summit da dbt Labs e o repositório do dbt-clickhouse no GitHub.