Para ejecutar consultas en tiempo real de datos analíticos junto con tus datos operativos sin compilar canalizaciones complejas, puedes usar la federación de lakehouse en AlloyDB para PostgreSQL. Con 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 complejas de ETL (extraer, transformar y cargar).
Beneficios de la federación de lakehouse
El enfoque de federación de lakehouse ofrece los siguientes beneficios:
- Cero ETL: Consulta datos analíticos directamente sin compilar ni mantener canalizaciones complejas.
- Sintaxis familiar: 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 la computación: Usa el motor distribuido de BigQuery para realizar tareas pesadas 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 tradicionales de ETL. Accede a datos analíticos actualizados de inmediato para tomar decisiones comerciales 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 IA de AlloyDB. Esto permite búsquedas de vectores de alto rendimiento, incorporaciones de aprendizaje automático y flujos de trabajo de agentes avanzados basados en 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 mediante el envío de filtros y agregaciones específicos directamente a BigQuery. Esto garantiza que la red solo transfiera las filas relevantes y filtradas o los resúmenes preagregados.
- 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 a AlloyDB.
- Procesamiento y respuesta finales: AlloyDB combina los datos externos con las tablas operativas locales, completa el procesamiento de consultas restante y muestra 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 poner en riesgo la seguridad. Para obtener más información, consulta las Funciones requeridas.
Desplegable
Puedes usar técnicas de pushdown de filtros y agregaciones, que aceleran las consultas y reducen los costos mediante el filtrado o el resumen de 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 filtros
El pushdown de filtros, también conocido como pushdown de predicados, es una técnica de optimización
que mueve el filtrado de datos lo más cerca posible de la capa de almacenamiento.
Para ello, mueve los filtros de consulta (con la cláusula WHERE) de
AlloyDB a BigQuery.
Con el pushdown de filtros, puedes usar consultas de 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 adjuntar como una partición local a una tabla de PostgreSQL.
Las operaciones admitidas para el pushdown de filtros 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 - Evaluación en la lista:
INyNOT IN
Pushdown de agregaciones
El pushdown de agregaciones 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. Este pushdown evalúa las funciones de resumen directamente en BigQuery, lo que puede reducir significativamente la cantidad de filas que se muestran a AlloyDB.
Las operaciones admitidas para el pushdown de agregaciones incluyen las siguientes:
SUMCOUNTAVGMINMAX
Pushdown de límites
El pushdown de límites (que incluye el pushdown 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 muestre solo el subconjunto específico de filas solicitado, lo que reduce significativamente el tráfico de red y la latencia de las consultas.
El pushdown 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 básicas o expresiones 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 información, consulta 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 el proyecto de entorno de ejecución (o proyecto de facturación).
Separar tu proyecto de entorno de ejecución de tu proyecto de almacenamiento de datos te permite aislar los costos de procesamiento en centros de costos específicos, administrar las cuotas de forma independiente y controlar el gasto 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 usará de forma predeterminada el proyecto que posee los datos.
Limitaciones
AlloyDB y BigQuery pueden usar 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 clasificación que la intercalación predeterminada de BigQuery, que evalúa estrictamente las cadenas según 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 del pushdown, no están optimizadas.
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 los pushdowns de filtros), es posible que la consulta falle debido a los límites de tamaño de respuesta de la API de BigQuery. Se siguen aplicando los límites máximos de tamaño de respuesta de BigQuery. Para obtener más información sobre estos límites, consulta Cuotas y límites.
PostgreSQL admite una mayor precisión para los cálculos intermedios, mientras que BigQuery controla estrictamente la precisión decimal. Esta diferencia puede generar pérdida de precisión o errores de desbordamiento durante cálculos complejos. Para obtener más información, consulta Tipos decimales.
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 quitarlas 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, no se verifican sus permisos de usuario de IAM individuales en las tablas remotas de BigQuery. Para obtener información, consulta Otorga acceso de AlloyDB al conjunto de datos de BigQuery.