dbt
JuniorClickHouse ya está en la plataforma dbt — qué significa esto realmente para tu pipeline
ClickHouse se convirtió en el primer adaptador v2 construido por un partner en la plataforma dbt, impulsado por el nuevo motor Fusion de dbt basado en Rust — esto es lo que realmente puedes usar hoy.
Si has estado corriendo dbt contra Snowflake, BigQuery o Postgres y te preguntas si ClickHouse es ahora un destino realista, la respuesta honesta es: se está acercando, pero todavía no para producción.
Qué se anunció realmente
ClickHouse es ahora el primer adaptador v2 construido por un partner en la plataforma dbt, y el primer miembro del Partner Adapter Program de dbt Labs. El nuevo adaptador corre sobre el motor v2 de dbt, con nombre en código Fusion — una reescritura en Rust del núcleo de dbt, pensada para la velocidad, en lugar del motor anterior basado en Python. Soporta tanto ClickHouse self-managed como ClickHouse Cloud como destinos, y (por separado) el conector dbt-clickhouse ya existente funciona con transformaciones gestionadas por Fivetran.
Qué está listo hoy, y qué no
Esta es la parte donde vale la pena ser precisos, porque "recién anunciado" y "listo para apuntar tu pipeline de producción ahí" son cosas muy distintas aquí. Según la propia guía de ClickHouse:
- El adaptador v2 está en beta — instálalo y pruébalo localmente, en una instancia self-managed de un solo nodo o en ClickHouse Cloud, en dev o staging.
- Explícitamente no se recomienda todavía para cargas de producción.
- Contra el propio test suite de integración v1 de dbt, pasa más del 81% de la suite completa y el 92% de los tests que realmente aplican a ClickHouse Cloud específicamente (ver el gráfico arriba).
- Las capacidades de Fusion que dbt todavía está construyendo para este adaptador incluyen validación consciente del dialecto, análisis estático, el language server, reconocimiento de columnas en la extensión de VS Code, y linaje a nivel de columna del lado del motor — nada de eso está completamente listo aún.
Si ya usas el adaptador dbt-clickhouse más antiguo y establecido contra dbt Core (no el nuevo camino v2/Fusion), esa es una integración separada y más madura que es anterior a este anuncio y no se ve afectada por él.
Por qué vale la pena prestarle atención de todos modos
Hay dos cosas genuinamente interesantes aquí, independientes del estado beta. Primero, ClickHouse en sí está construido para consultas analíticas rápidas con un perfil de costo difícil de igualar para almacenes orientados a filas, en la forma de carga de trabajo correcta (agregaciones de alta cardinalidad, analítica en tiempo real) — una integración de primera clase con dbt baja la barrera para probar ese encaje en lugar de escribir SQL a mano fuera del grafo de dependencias y el framework de testing de dbt. Segundo, el motor Rust de Fusion es la propia respuesta de dbt a los ciclos de desarrollo local lentos — si las afirmaciones de velocidad se sostienen a medida que madura, es un cambio real de calidad de vida para cualquier flujo de trabajo de dbt, no solo para usuarios de ClickHouse.
Dónde se cruza esto con opti-pipe, con honestidad: las reglas de dbt aquí leen datos de tiempo y conteo de filas directamente de run_results.json — elapsed_time y execution_time por modelo — que dbt escribe con la misma forma sin importar qué adaptador o warehouse produjo la corrida. En principio, el run_results.json de un proyecto con destino ClickHouse debería funcionar a través del mismo flujo de carga que cualquier otro. Dicho esto, no se ha probado específicamente contra un archivo producido por el adaptador de ClickHouse todavía, así que trátalo como una expectativa razonable, no como una afirmación verificada.
Mira cómo se ve esto en tu propio pipeline.
Sube un event log real de Spark, un run_results.json de dbt, o una exportación de métricas de Flink, y recibe recomendaciones concretas para aprobar — no otra regla general más.
Fuente: el anuncio oficial de ClickHouse, contrastado con la cobertura del propio summit de dbt Labs y el repositorio de GitHub de dbt-clickhouse.