dbt Labs anunció soporte nativo de lectura y escritura sobre Amazon Redshift Data Sharing, la función de Redshift que permite exponer datos de un clúster a otro sin copiarlos. Con este cambio, dbt puede materializar modelos que combinan tablas de distintos clústeres Redshift como si fueran parte de un único proyecto, sin mover los datos de un sitio a otro.
El mecanismo pasa por una nueva credencial de perfil, datasharing: true, que cambia las consultas de metadatos del adaptador hacia las vistas nativas SVV_* de Redshift y sus API SHOW, que sí son capaces de resolver objetos en bases de datos a las que el cliente no está conectado directamente. Hasta ahora, el adaptador de dbt para Redshift heredaba las API de metadatos de Postgres, que no tienen ese alcance entre bases de datos; el cambio también mejora la fiabilidad del propio adaptador bajo cargas con mucha concurrencia, al margen del uso de data sharing.
La consecuencia arquitectónica es la que importa. Hasta ahora, compartir datos entre equipos que operan clústeres Redshift independientes exigía copiar tablas, mantener vistas externas o montar un proceso de sincronización propio. Con esta función, un equipo productor expone sus tablas vía data sharing y los equipos consumidores las usan directamente en sus propios modelos dbt, sin ninguna copia intermedia que mantener actualizada ni que gobernar por duplicado.
El patrón encaja con organizaciones donde cada dominio de negocio posee su propio clúster —lo que en la práctica de datos se suele llamar un enfoque de malla de datos— y necesita que otros equipos consuman una parte de su información sin perder la propiedad sobre ella. Antes de esta función, ese modelo organizativo chocaba con la mecánica real de mover datos entre clústeres; ahora dbt lo soporta como una opción de configuración, no como una integración a medida.
El límite está en lo que la función no resuelve: dbt se apoya en Redshift Data Sharing para la mecánica, pero no decide quién puede compartir qué con quién. Esa gobernanza —qué clúster expone qué tablas y a qué consumidores— sigue siendo una decisión y una configuración de Redshift, anterior a cualquier modelo de dbt que se construya encima.
El anuncio también confirma que la migración del adaptador hacia las vistas nativas de Redshift no es solo cosmética: al abandonar las API de metadatos heredadas de Postgres, dbt deja de arrastrar una capa de compatibilidad pensada para un motor distinto al que realmente ejecuta las consultas, lo que explica la mejora de fiabilidad bajo concurrencia alta que el propio equipo atribuye al cambio, incluso en proyectos que no usan data sharing en absoluto.
Más en Dataprix: sección de integración de datos de Dataprix
Fuente: AWS Big Data Blog
Contenido elaborado con asistencia de inteligencia artificial — Equipo Editorial Dataprix. Verifica la información antes de tomar decisiones.