Microsoft Fabric lleva a disponibilidad general la réplica continua de Google BigQuery en OneLake

Ilustración de una infraestructura de computación en la nube

Microsoft anunció el 17 de septiembre la disponibilidad general de Mirroring for Google BigQuery en Microsoft Fabric, la función que replica de forma continua tablas de BigQuery en OneLake, el almacenamiento unificado de Fabric. Tras su paso por vista previa, la réplica admite ya cargas de producción con soporte completo y está disponible en todas las regiones de Fabric.

El funcionamiento es el habitual del mirroring de Fabric. Al configurarlo se crean en el área de trabajo una base de datos replicada, que gestiona la copia de los datos a OneLake y su conversión a Parquet en tablas Delta, y un punto de conexión de análisis SQL de solo lectura sobre esas tablas. Desde ahí se pueden crear vistas y procedimientos almacenados, lanzar consultas que crucen almacenes y lakehouses del mismo espacio de trabajo y alimentar Power BI, Spark o cargas de ciencia de datos sin construir procesos ETL. La captura de cambios se apoya en la función CHANGES de BigQuery, basada en su historial de cambios, lo que permite una réplica casi en tiempo real. La conexión admite la pasarela de datos local, a partir de la versión 3000.286.6, y redes virtuales.

El modelo de costes tiene dos caras. En Fabric, el cómputo de replicación es gratuito, el almacenamiento del espejo no se cobra hasta un límite que depende de la capacidad contratada y no hay cargos por la entrada de datos en OneLake; las consultas con SQL, Power BI o Spark se facturan a la tarifa habitual. En Google Cloud, en cambio, la réplica sí genera costes: la captura de cambios consume cómputo de BigQuery, la ingesta usa la Storage Write API y el almacenamiento asociado también se paga.

La documentación recoge además limitaciones que conviene conocer. Las tablas sin clave primaria solo admiten inserciones: si se detectan actualizaciones o borrados, la tabla se vuelve a copiar entera, y si la situación se repite, la réplica entra temporalmente en modo de espera. Los cambios solo se recuperan dentro de la ventana de time travel de la tabla, normalmente de siete días, y el historial de cambios debe estar activado de antemano. El motor necesita, por último, permisos amplios en BigQuery, incluida la creación de conjuntos de datos y trabajos temporales, algo que, según reconoce Microsoft, frena a algunos clientes.

Es frecuente que las organizaciones convivan con más de una nube por herencia o por adquisiciones, y la integración entre BigQuery y el ecosistema de Microsoft solía resolverse con pipelines propios. La disponibilidad general convierte la réplica en una opción soportada para producción, útil para consolidar informes en Power BI o combinar datos de ambas nubes sin migrar el almacén de origen. El coste en el lado de Google y el requisito de clave primaria para las tablas con actualizaciones son los dos puntos que hay que evaluar antes de activarla sobre tablas grandes.

Más en Dataprix: ETL vs ELT: cuándo transformar en origen o en destino

Fuente: Microsoft Learn — Mirrored databases from Google BigQuery in Microsoft Fabric

Contenido elaborado con asistencia de inteligencia artificial — Equipo Editorial Dataprix. Verifica la información antes de tomar decisiones.

Cada semana, estas noticias y lo mejor de Dataprix en tu correo

Suscribirme al boletín