Para ejecutar consultas en tiempo real de datos analíticos junto con tus datos operativos
sin crear canalizaciones complejas, puedes usar la federación de lakehouse en
AlloyDB para PostgreSQL. Con la tecnología de la extensión bigquery_fdw, AlloyDB
enruta tus consultas a BigQuery para acceder a datos en vivo y formatos abiertos,
como Apache Iceberg, a través de tablas externas de BigLake, lo que elimina la necesidad de
migraciones de ETL (extracción, transformación y carga) complejas.
Como alternativa, para consultar tablas de Apache Iceberg almacenadas en Cloud Storage o registradas en el catálogo de tiempo de ejecución de Lakehouse sin enrutar la ejecución de consultas a través de BigQuery, puedes usar el motor de columnas de AlloyDB. Para obtener más información, consulta Accede a los datos de Iceberg desde AlloyDB.
Beneficios de la federación de lakehouse
El enfoque de federación de lakehouse ofrece los siguientes beneficios:
- Zero ETL: Consulta datos analíticos directamente sin crear ni mantener canalizaciones complejas.
- Sintaxis conocida: Usa la sintaxis estándar de PostgreSQL para consultar datos de BigQuery.
- Estadísticas en tiempo real: Accede a datos actualizados junto con tus tablas operativas.
- Descarga el procesamiento: Usa el motor distribuido de BigQuery para el trabajo pesado a través de la optimización de pushdown.
- Acceso autorizado: Para garantizar que solo las cuentas de servicio autorizadas puedan consultar datos externos, usa Identity and Access Management (IAM) para el control de acceso centralizado.
Casos de uso
La federación de Lakehouse admite los siguientes casos de uso empresariales y técnicos:
- Cargas de trabajo de procesamiento transaccional y analítico híbrido (HTAP): Puedes consultar datos operativos en tiempo real en AlloyDB y datos históricos o analíticos en BigQuery o Cloud Storage de forma simultánea sin afectar el rendimiento transaccional.
- Estadísticas en tiempo real sin canalizaciones frágiles: Puedes evitar la latencia y los modos de falla de los procesos de ETL tradicionales. Accede a datos analíticos recientes de forma instantánea para tomar decisiones empresariales basadas en la información más actualizada.
- Materialización de datos para flujos de trabajo de agentes: Puedes materializar datos analíticos externos en AlloyDB para usar el motor de columnas de AlloyDB y las capacidades de AlloyDB AI. Esto permite realizar búsquedas de vectores de alto rendimiento, embeddings de aprendizaje automático y flujos de trabajo de agentes avanzados impulsados por IA en tus datos federados.
Arquitectura y flujo de datos
En el siguiente diagrama, se muestra el flujo de datos y las interacciones de los componentes cuando usas la federación de lakehouse:
A continuación, se describe el proceso de flujo de datos para la federación de lakehouse en AlloyDB:
- Envío de consultas: Envías una consulta estándar de PostgreSQL a tu instancia de AlloyDB.
- Planificación y optimización de consultas: El planificador de consultas de AlloyDB identifica las tablas que se asignan a conjuntos de datos externos de BigQuery con el wrapper de datos externos (FDW) de BigQuery.
- Optimización de pushdown: AlloyDB optimiza la consulta enviando filtros y agregaciones específicos directamente a BigQuery. Esto garantiza que la red solo transfiera las filas filtradas pertinentes o los resúmenes agregados previamente.
- Ejecución y recuperación: BigQuery ejecuta su parte de la consulta, analiza directamente el almacenamiento integrado de BigQuery o lee las tablas de Apache Iceberg almacenadas en Cloud Storage, y transmite el conjunto de datos resultante de vuelta a AlloyDB.
- Procesamiento y respuesta finales: AlloyDB combina los datos externos con cualquier tabla operativa local, completa cualquier procesamiento de consultas restante y devuelve el resultado final a tu aplicación.
Consideraciones sobre los tipos de datos para las consultas federadas
Cuando consultas una tabla externa de BigQuery desde
AlloyDB con la federación de lakehouse, el planificador de consultas de AlloyDB
interpreta los tipos de datos de BigQuery como los tipos de datos de PostgreSQL
correspondientes. Comprender estas asignaciones es fundamental para escribir
consultas correctas y para las definiciones de tablas externas que usa la extensión
bigquery_fdw.
Si un tipo de datos de BigQuery no tiene una asignación directa o requiere
un manejo especial, es posible que debas usar funciones CAST explícitas en tus
consultas o crear una vista en BigQuery que presente los datos con
tipos compatibles.
Para obtener una lista de los tipos de datos admitidos y sus tipos de PostgreSQL correspondientes, consulta Asignaciones de tipos de datos.
Seguridad y control de acceso
El acceso a los datos de BigQuery desde AlloyDB se administra a través de IAM. Debes otorgar roles de IAM específicos a la cuenta de servicio del clúster de AlloyDB para definir qué conjuntos de datos y tablas se pueden consultar. Esto ayuda a garantizar que las consultas federadas cumplan con las políticas de administración de datos centralizadas de tu organización sin comprometer la seguridad. Para obtener más información, consulta las Funciones requeridas.
Pushdown
Puedes usar técnicas de aplicación de filtros y agregaciones, que aceleran las consultas y reducen los costos filtrando o resumiendo los datos en BigQuery antes de que AlloyDB los mueva o procese. Este enfoque minimiza el tráfico de red y el uso de memoria, lo que te permite analizar conjuntos de datos masivos de forma rápida y eficiente sin exceder los límites de recursos.
Pushdown de filtro
La reducción de filtros, también conocida como reducción de predicados, es una técnica de optimización
que acerca el filtrado de datos a la capa de almacenamiento
lo más posible moviendo los filtros de consulta (con la cláusula WHERE) de
AlloyDB a BigQuery.
Con la aplicación de filtros, puedes usar consultas en SQL con una cláusula WHERE para acceder a un subconjunto
de datos de la tabla remota. Estos datos también se pueden materializar en una tabla local
o adjuntarse como una partición local a una tabla de PostgreSQL.
Entre las operaciones admitidas para la aplicación de filtros, se incluyen las siguientes:
- Operadores de comparación estándar:
=,<,>,<=,>=,<> - Operadores lógicos:
AND,ORyNOT - Coincidencia de patrones:
LIKEyNOT LIKE - Verificaciones nulas:
IS NULLyIS NOT NULL
Pushdown de agregación
La reducción de agregación es una optimización avanzada de la base de datos que realiza
cálculos, por ejemplo, SUM, COUNT, AVG o GROUP BY, lo más
cerca posible de la capa de almacenamiento. Esta delegación evalúa las funciones de resumen
directamente en BigQuery, lo que puede reducir de forma significativa la cantidad
de filas que se devuelven a AlloyDB.
Entre las operaciones admitidas para la aplicación de agregación, se incluyen las siguientes:
SUMCOUNTAVGMINMAX
Pushdown de límite
La reducción de límites (que incluye la reducción de OFFSET) es una técnica de optimización que mueve las cláusulas LIMIT y OFFSET de tu consulta de AlloyDB a BigQuery.
Esto permite que BigQuery devuelva solo el subconjunto específico de filas solicitadas, lo que reduce de manera significativa el tráfico de red y la latencia de las consultas.
La reducción de límites se aplica automáticamente siempre que sea posible. Asegúrate de que se cumplan las siguientes condiciones:
- La consulta no usa la opción
WITH TIESen la cláusulaFETCH FIRST. - Las expresiones
LIMITyOFFSETson constantes o expresiones básicas que se pueden evaluar de forma remota.
Costo y facturación de BigQuery
El wrapper de datos externos de BigQuery depende de lo siguiente:
- Precios de procesamiento de BigQuery
- Precios de la API de BigQuery Storage
Para obtener más información, consulta los precios de BigQuery.
Proyectos de entorno de ejecución
En BigQuery, puedes almacenar tus datos en un proyecto y ejecutar tus consultas en otro. El proyecto que ejecuta las consultas y acumula los costos de procesamiento se conoce como proyecto de entorno de ejecución (o proyecto de facturación).
Separar el proyecto de entorno de ejecución del proyecto de almacén de datos te permite aislar los costos de cómputo en centros de costos específicos, administrar las cuotas de forma independiente y controlar los gastos en diferentes cargas de trabajo sin mover los datos subyacentes.
Cuando configuras AlloyDB para acceder a los datos de BigQuery, puedes especificar un proyecto de entorno de ejecución a nivel del servidor (que se aplica a todas las tablas externas asociadas) o a nivel de la tabla individual. Si no especificas un proyecto de entorno de ejecución, AlloyDB usa de forma predeterminada el proyecto propietario de los datos.
Limitaciones
Es posible que AlloyDB y BigQuery usen intercalaciones predeterminadas diferentes, lo que puede generar resultados de ordenamiento de datos o comparación de cadenas que difieran entre los dos sistemas. Por ejemplo, la intercalación predeterminada de PostgreSQL en las versiones 15, 16 y 17 puede controlar la distinción entre mayúsculas y minúsculas de manera diferente durante la ordenación que la intercalación predeterminada de BigQuery, que evalúa estrictamente las cadenas en función de sus puntos de código Unicode.
Para cualquier parte de una consulta que se ejecute de forma remota en BigQuery, la intercalación sigue la configuración de BigQuery. Para reducir los conflictos de intercalación, considera usar la intercalación
C.UTF-8sin ICU en AlloyDB y la intercalación predeterminada (vacía) en BigQuery.Las consultas que muestran una gran cantidad de datos de BigQuery, después de la reducción, no se optimizan.
Cuando creas una tabla externa, AlloyDB no valida de forma activa la existencia ni el esquema de la tabla remota de BigQuery.
Si una consulta federada requiere leer una gran cantidad de datos, por ejemplo, si no se pueden aplicar las reducciones de filtros, es posible que la consulta falle debido a los límites de tamaño de la respuesta de la API de BigQuery. Se siguen aplicando los límites de tamaño máximo de respuesta de BigQuery. Para obtener más información sobre estos límites, consulta Cuotas y límites.
PostgreSQL y BigQuery manejan la precisión decimal, la división y los cálculos intermedios de manera diferente. Estas diferencias pueden generar variaciones de redondeo, pérdida de precisión o errores de desbordamiento durante cálculos complejos. Para obtener más información, consulta Tipos decimales y Operadores aritméticos.
Database Migration Service no admite la migración de tablas externas creadas con la extensión
bigquery_fdw. Como solución alternativa, puedes excluir las tablas externas de tu trabajo de migración o puedes descartarlas antes de iniciar la migración y, luego, volver a crearlas en el clúster de AlloyDB de destino una vez que se complete la migración.Cuando consultas tablas externas con la extensión
bigquery_fdw, BigQuery evalúa los permisos de acceso a los datos según la cuenta de servicio del clúster de AlloyDB. Incluso si los usuarios de la base de datos acceden con la autenticación de la base de datos de IAM, sus permisos de usuario de IAM individuales no se verifican con las tablas remotas de BigQuery. Para obtener información, consulta Otorga acceso de AlloyDB al conjunto de datos de BigQuery.