Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Búsquedas globales

Las consultas globales te permiten ejecutar consultas en SQL que hacen referencia a datos almacenados en más de una región. Por ejemplo, puedes ejecutar una consulta global que una una tabla ubicada en us-central1 con una tabla ubicada en europe-central2. En este documento, se explica cómo habilitar y ejecutar consultas globales en tu proyecto.

Antes de comenzar

Verifica que las búsquedas globales estén habilitadas para tu proyecto y asegúrate de tener los permisos necesarios para ejecutarlas.

Habilita las búsquedas globales

Para habilitar las consultas globales en tu proyecto u organización, usa la declaración ALTER PROJECT SET OPTIONS o la declaración ALTER ORGANIZATION SET OPTIONS para cambiar la configuración predeterminada.

Para ejecutar consultas globales en una región, establece el argumento enable_global_queries_execution en true en esa región para el proyecto que ejecuta la consulta.
Para permitir que las consultas globales copien datos de una región, establece el argumento enable_global_queries_data_access en true en esa región para el proyecto que contiene los datos.
Estas opciones se verifican cada vez que tu consulta accede a tablas remotas.
Las consultas globales se pueden ejecutar en un proyecto y extraer datos de otras regiones de otro proyecto.

Ejemplo: Configuración entre proyectos

En el siguiente ejemplo, se muestra cómo ejecutar una consulta en un proyecto que accede a una tabla en otro proyecto.

Supongamos que tienes un proyecto query_project que ejecuta trabajos en la región us-central1 y deseas ejecutar una consulta que acceda a una tabla data_project.dataset.my_table ubicada en la región europe-west1:

SET @@location='us-central1';
SELECT
  *
FROM
  `query_project.dataset.my_table`
  JOIN `data_project.dataset.my_other_table` USING id;

Para que esta consulta global se ejecute correctamente, se requiere la siguiente configuración:

Debes habilitar la ejecución de consultas globales en el proyecto (query_project) en la región que ejecuta una consulta global (us-central1):
```
ALTER PROJECT `query_project`
SET OPTIONS (
`region-us-central1.enable_global_queries_execution` = TRUE
);
```
Debes habilitar la copia de datos por medio de consultas globales desde el proyecto que contiene los datos (data_project) para su región (europe-west1):
```
ALTER PROJECT `data_project`
SET OPTIONS (
`region-europe-west1.enable_global_queries_data_access` = TRUE
);
```

Para crear y usar vistas que contengan tablas remotas, se aplican los mismos principios: el proyecto que ejecuta las consultas debe tener habilitado enable_global_queries_execution.

Estas operaciones de ALTER PROJECT deben ejecutarse por separado, ya que hacen referencia a diferentes proyectos y regiones. El cambio puede tardar varios minutos en aplicarse.

Permiso necesario

Para ejecutar una consulta global, debes tener el permiso bigquery.jobs.createGlobalQuery. El rol de administrador de BigQuery es el único rol predefinido que contiene este permiso. Para otorgar permiso para ejecutar consultas globales sin otorgar el rol de administrador de BigQuery, sigue estos pasos:

Crea un rol personalizado, por ejemplo, "Ejecutor de consultas globales de BigQuery".
Agrega bigquery.jobs.createGlobalQuery a este rol.
Asigna este rol a los usuarios o las cuentas de servicio seleccionados.

Consulta los datos

Para ejecutar una consulta global, escribe una consulta en SQL como lo harías si tus datos estuvieran en una sola ubicación. Si los datos a los que hace referencia la consulta se almacenan en más de una ubicación, BigQuery intenta ejecutar una consulta global. Si no especificas la ubicación en la que se ejecutará la consulta, BigQuery la seleccionará automáticamente en función de las ubicaciones de las tablas a las que se hace referencia. Para obtener más información, consulta Elige una ubicación. Los datos a los que hace referencia la consulta y que no residen en la ubicación seleccionada se copian a esa ubicación.

En el siguiente ejemplo, se ejecuta como una consulta global que une tablas de dos conjuntos de datos diferentes almacenados en dos ubicaciones diferentes:

SELECT id, tr_date, product_id, price FROM us_dataset.transactions
UNION ALL
SELECT id, tr_date, product_id, price FROM europe_dataset.transactions

Elige una ubicación

Para configurar dónde se ejecutará la consulta global, especifica una ubicación. Cuando decidas una ubicación de ejecución para la consulta global, ten en cuenta lo siguiente:

Residencia de datos: Las búsquedas globales copian temporalmente los datos de una ubicación a otra. Si tu organización tiene requisitos de residencia de datos y no quieres que tus datos salgan de una ubicación determinada, establece la ubicación de la consulta en esa ubicación.
Costo y rendimiento de la transferencia: Para minimizar la cantidad de datos transferidos entre ubicaciones y reducir el costo de la consulta, ejecútala en la región en la que se almacena la mayor parte de los datos consultados.

Por ejemplo, tienes una tienda en línea y mantienes una lista de tus productos en la ubicación us-central1, pero mantienes tus transacciones en la región us-south1. Si hay más transacciones que productos en tu catálogo, debes ejecutar la consulta en la región us-south1.
Reservas y capacidad de procesamiento: Especifica la ubicación de la consulta para controlar qué reservas o ranuras regionales procesan la consulta.

Si no especificas una ubicación de forma manual, BigQuery determina automáticamente la ubicación de ejecución según los siguientes criterios:

En el caso de las consultas de lenguaje de manipulación de datos (DML) (sentencias INSERT, UPDATE y DELETE), se selecciona la ubicación de la tabla de destino como la ubicación de ejecución.
En el caso de las consultas del lenguaje de definición de datos (DDL) (como las instrucciones CREATE TABLE AS SELECT), se selecciona como ubicación de ejecución la ubicación en la que se crea o modifica el recurso.
En el caso de las consultas con una tabla de destino especificada, se selecciona la ubicación de la tabla de destino como la ubicación de ejecución.
Para todas las demás consultas, la ubicación de ejecución se selecciona de forma arbitraria como una de las ubicaciones de los conjuntos de datos a los que se hace referencia.

Información sobre las búsquedas globales

Para ejecutar consultas globales de manera eficiente y rentable, es importante comprender el mecanismo detrás de su ejecución.

Para usar datos que residen en diferentes ubicaciones, se deben replicar en una sola ubicación. A continuación, se muestra una abstracción del flujo de trabajo de consultas global que lleva a cabo BigQuery:

Determina dónde se debe ejecutar la búsqueda, ya sea desde la declaración del usuario o de forma automática. Esta ubicación se denomina ubicación principal, y todas las demás ubicaciones a las que hace referencia la consulta son remotas.
Ejecuta una subconsulta en cada región remota para recopilar los datos necesarios para finalizar la consulta en la región principal.
Copiar estos datos de ubicaciones remotas a la ubicación principal
Guarda los datos en tablas temporales en la ubicación principal durante 24 horas.
Ejecuta una consulta final con todos los datos recopilados en la ubicación principal.
Devuelve los resultados de la búsqueda.

BigQuery intenta minimizar la cantidad de datos transferidos entre regiones. Considera el siguiente ejemplo:

SET @@location = 'EU';
SELECT
  t1.col1, t2.col2
FROM
  eu_dataset.table1 t1
  JOIN us_dataset.table2 t2 using col3
WHERE
  t2.col4 = 'ABC'

BigQuery no necesita replicar toda la tabla t2 de EE.UU. a la UE. Es suficiente transferir solo las columnas solicitadas (col2 y col3) y solo las filas que coinciden con la condición WHERE (t2.col4 = 'ABC'). Sin embargo, estos mecanismos, conocidos como pushdowns, dependen de la estructura de la consulta y, a veces, la cantidad de datos transferidos puede ser grande. Te recomendamos que pruebes las consultas globales en un pequeño subconjunto de datos y confirmes que los datos solo se transfieren cuando es necesario.

Observabilidad

Para supervisar las consultas globales y analizar su ejecución en las distintas regiones, puedes usar los siguientes métodos:

Historial de trabajos

Para ver el texto de la consulta que se envió a la región remota, consulta el historial de trabajos. El trabajo remoto tiene el mismo ID de trabajo que la búsqueda original, con un sufijo _xregion adicional.

API de REST de Jobs

Cuando llamas al método jobs.get, el recurso Job que se devuelve contiene los siguientes campos en el objeto JobStatistics:

statistics.global_query_remote_regions: Es un array de cadenas que representa las regiones remotas desde las que una búsqueda global accede a los datos. Este campo solo se completa para los trabajos de consultas globales principales en la región de ejecución principal. Está vacío para los trabajos de consultas globales secundarias y las consultas de una sola región.
statistics.parent_global_query_job: Es un objeto JobReference (projectId, jobId, location) que identifica el trabajo de la consulta global principal. Este campo solo se propaga para los trabajos de consultas globales secundarios (subconsultas remotas y trabajos de copia entre regiones) que se ejecutan en regiones remotas en nombre de una consulta global. No se establece para los trabajos de consultas globales principales y las consultas de una sola región.

Registros de auditoría

En Registros de auditoría de Cloud, el objeto BigQueryAuditMetadata contiene los siguientes campos en el objeto JobStats:

jobStats.globalQueryRemoteRegions: Es un array de cadenas que representa las regiones remotas a las que accede la búsqueda. Este campo solo se completa para los trabajos de consultas globales principales en la región de ejecución principal.
jobStats.parentGlobalQueryJobId: Es el ID del trabajo de la tarea de consulta global principal. Este campo se propaga para los trabajos secundarios que se ejecutan en regiones remotas.
jobStats.parentGlobalQueryJobLocation: Es la ubicación del trabajo de consulta global principal. Este campo se propaga para los trabajos secundarios que se ejecutan en regiones remotas.

Cómo encontrar trabajos secundarios remotos para una búsqueda global

Para encontrar todos los trabajos secundarios remotos asociados a una búsqueda global principal, puedes consultar los registros de auditoría con Log Analytics o un conjunto de datos del receptor de registros exportado:

SELECT
  timestamp,
  proto_payload.audit_log.resource_name AS resource_name,
  JSON_VALUE(proto_payload.audit_log.metadata.jobChange.job.jobConfig.queryConfig.query) AS query
FROM
  `PROJECT_ID.LOG_DATASET._AllLogs`
WHERE
  JSON_VALUE(proto_payload.audit_log.metadata.jobChange.job.jobStats.parentGlobalQueryJobId) = 'PARENT_JOB_ID';

Reemplaza lo siguiente:

PROJECT_ID: Es el ID de tu proyecto de Google Cloud.
LOG_DATASET: Es el conjunto de datos vinculado de BigQuery para Log Analytics o el conjunto de datos de destino del receptor de registros.
PARENT_JOB_ID: Es el ID del trabajo de consulta global principal.

Cómo desactivar las búsquedas globales

Para inhabilitar las búsquedas globales en tu proyecto u organización, usa ALTER PROJECT SET OPTIONS statement o ALTER ORGANIZATION SET OPTIONS statement para cambiar la configuración predeterminada.

Para desactivar las consultas globales en una región, establece el argumento enable_global_queries_execution en false o NULL en esa región.
Para prohibir que las consultas globales copien datos de una región, establece el argumento enable_global_queries_data_access en false o NULL en esa región.

En el siguiente ejemplo, se muestra cómo inhabilitar las búsquedas globales a nivel del proyecto:

ALTER PROJECT PROJECT_ID
SET OPTIONS (
  `region-REGION.enable_global_queries_execution` = false,
  `region-REGION.enable_global_queries_data_access` = false
);

Reemplaza lo siguiente:

PROJECT_ID: Es el nombre del proyecto que se modificará.
REGION: Es el nombre de la región en la que se inhabilitarán las búsquedas globales.

El cambio puede tardar varios minutos en aplicarse.

Precios

El costo de una consulta global consta de los siguientes componentes:

El costo de procesamiento de cada subconsulta en ubicaciones remotas, según tu modelo de precios en esas ubicaciones
El costo de procesamiento de la búsqueda final en la región en la que se ejecuta, según tu modelo de precios en esa región
El costo de copiar datos entre diferentes ubicaciones, según los precios de replicación de datos
El costo de almacenar los datos copiados de regiones remotas a la región principal (durante 24 horas), según los precios de almacenamiento

Cuotas

Para obtener información sobre las cuotas relacionadas con las consultas globales, consulta Trabajos de consulta.

Limitaciones

Los detalles de ejecución y el gráfico de ejecución de una consulta no muestran la cantidad de bytes procesados y transferidos desde ubicaciones remotas. Esta información aparece en los trabajos de copia que puedes encontrar en tu historial de trabajos. El ID de trabajo de un trabajo de copia creado por una consulta global tiene el ID de trabajo del trabajo de consulta como prefijo.
Las consultas globales no se admiten en el modo de zona de pruebas.
Las búsquedas globales no son compatibles cuando se usan extremos regionales.
Las consultas globales generan una latencia mayor que las consultas de una sola región debido al tiempo que se requiere para transferir datos entre regiones.
Las búsquedas globales no usan ninguna caché para evitar la transferencia de datos entre regiones.
No puedes consultar seudocolumnas, como _PARTITIONTIME, con consultas globales.
No puedes consultar columnas de tipo RANGE con consultas globales.
No puedes consultar columnas con nombres de columna flexibles con consultas globales.
No puedes consultar vistas de INFORMATION_SCHEMA desde una región remota en una consulta global.
No se admiten las vistas autorizadas ni las rutinas autorizadas globales (cuando una vista o una rutina en una ubicación está autorizada para acceder a un conjunto de datos en otra ubicación). En su lugar, crea vistas autorizadas en la región en la que se encuentran tus datos y consulta las vistas autorizadas a través de consultas globales.
No se admiten las vistas materializadas sobre consultas globales.
Si tu consulta global hace referencia a columnas STRUCT, no se aplican pushdowns a ninguna subconsulta remota. Para optimizar el rendimiento, considera crear una vista en la región remota que filtre las columnas STRUCT y muestre solo los campos necesarios como columnas individuales.
Las consultas globales no se ejecutan de forma atómica. En los casos en que la replicación de datos se realiza correctamente, pero la consulta general falla, se te facturará la replicación de datos.
Las tablas temporales creadas en regiones remotas como parte de la ejecución de consultas globales solo se encriptan con claves de encriptación administradas por el cliente (CMEK) si una clave CMEK configurada para encriptar los resultados de la consulta global (ya sea a nivel de la tabla, el conjunto de datos o el proyecto) es global. Para garantizar que las tablas temporales remotas siempre estén protegidas con CMEK, establece una clave de KMS predeterminada para el proyecto que ejecuta consultas globales en la región remota.
Las consultas globales no se admiten en Assured Workloads.
Una sola consulta global puede acceder a hasta 10 tablas remotas por región.
Las consultas globales solo se admiten en Data Studio cuando se incluyen en una vista y se configuran para usar las credenciales del usuario.