Introducción a las consultas federadas

En esta página, se presenta cómo usar las consultas federadas y se proporciona orientación para consultar los datos de Spanner, AlloyDB y Cloud SQL de BigQuery.

Las consultas federadas te permiten enviar una declaración de consulta a las bases de datos de AlloyDB, Spanner o Cloud SQL y obtener el resultado como una tabla temporal. Las consultas federadas usan la API de BigQuery Connection para establecer una conexión con AlloyDB, Spanner o Cloud SQL. En tu consulta, debes usar la función EXTERNAL_QUERY para enviar una sentencia de consulta a la base de datos externa con el dialecto SQL de esa base de datos. Los resultados se convierten en tipos de datos de GoogleSQL.

Almacenes de datos compatibles

Puedes usar consultas federadas con los siguientes almacenes de datos:

Flujo de trabajo

  • Identifica el proyecto de Google Cloud que incluye la fuente de datos que deseas consultar.
  • Un usuario bigquery.admin crea un recurso de conexión en BigQuery.
  • El usuario administrador otorga permiso para usar el recurso de conexión al usuario B.
    • Si el administrador y el usuario B son la misma persona, no hay necesidad de otorgar el permiso.
  • El usuario B escribe una consulta en BigQuery con la función de SQL EXTERNAL_QUERY nueva.

Alternativas a las consultas federadas: tablas y conjuntos de datos externos

Otra opción para consultar bases de datos operativas, como Bigtable, Spanner, Cloud Storage, Google Drive y Salesforce Data Cloud, es usar tablas y conjuntos de datos externos. Los conjuntos de datos y las tablas externos te permiten ver las tablas y sus esquemas, y consultarlos sin usar una función SQL EXTERNAL_QUERY. No tienes que volver a ingresar datos en BigQuery y puedes usar la sintaxis de BigQuery en lugar de escribir en el dialecto específico de la base de datos de SQL.

Regiones admitidas

Las consultas federadas solo son compatibles en regiones que admitan la fuente de datos externa y BigQuery. Para obtener una lista de las ubicaciones compatibles, consulta las siguientes secciones:

Puedes crear una conexión y ejecutar una consulta federada entre regiones de acuerdo con las siguientes reglas.

Regiones individuales

Una región individual de BigQuery solo puede consultar un recurso en la misma región.

Por ejemplo, si tu conjunto de datos en us-east4, puedes consultar instancias de Cloud SQL, instancias de AlloyDB o bases de datos de Spanner que se encuentran en us-east4. La ubicación de procesamiento de consultas es la región individual de BigQuery.

Multirregiones

Una multirregión de BigQuery puede consultar cualquier región de fuente de datos en la misma área geográfica grande (US, EU), por ejemplo: Las ubicaciones multirregionales no están disponibles para las instancias de Cloud SQL porque solo se usan con copias de seguridad. Una multirregión de BigQuery también puede consultar una instancia de Spanner en la misma multirregión.

  • Una consulta que se ejecuta en la multirregión US de BigQuery puede consultar cualquier región individual en el área geográfica US, como us-central1, us-east4, o us-west2.

  • Una consulta que se ejecuta en la multirregión EU de BigQuery puede consultar cualquier región individual en los estados miembros de la Unión Europea, como europe-north1 o europe-west3.

  • La ubicación en la que se ejecuta la consulta debe ser la misma que la del recurso de conexión. Por ejemplo, las consultas ejecutadas desde la multirregión US deben usar una conexión ubicada en la multirregión US.

El rendimiento de la consulta varía según la proximidad entre el conjunto de datos y la fuente de datos externa. Por ejemplo, una consulta federada entre un conjunto de datos en la multirregión US y una instancia de Cloud SQL en us-central1 es rápida. Sin embargo, si ejecutas la misma consulta entre la multirregión US y una instancia de Cloud SQL en us-east4, el rendimiento puede ser más lento.

La ubicación de procesamiento de consultas es la ubicación multirregional, ya sea US o EU.

Asignaciones de tipos de datos

Cuando ejecutas una consulta federada, los datos de la fuente de datos externa se convierten en tipos de GoogleSQL. Para obtener más información, consulta Consultas federadas de Cloud SQL.

Cuotas y límites

  • Consultas federadas entre regiones. Si la ubicación de procesamiento de consultas de BigQuery y la ubicación de la fuente de datos externa son distintas, corresponde a una consulta entre regiones. Puedes ejecutar hasta 1 TB en consultas entre regiones por proyecto al día. El siguiente es un ejemplo de una consulta entre regiones.
    • La instancia de Cloud SQL está en us-west1, mientras que la conexión de BigQuery se basa en la multirregión US. La ubicación de procesamiento de consultas de BigQuery es US.
  • Cuota. Los usuarios deben controlar la cuota de consultas en la fuente de datos externa, como Cloud SQL o AlloyDB. No hay una configuración de cuota adicional para las consultas federadas. Para lograr el aislamiento de la carga de trabajo, se recomienda consultar solo una réplica de lectura de la base de datos.
  • Cantidad máxima de bytes facturados permitidos. Este campo no es compatible con consultas federadas. No es posible calcular los bytes facturados antes de la ejecución efectiva de las consultas federadas.
  • Número de conexiones: una consulta federada puede tener como máximo 10 conexiones únicas.
  • Se aplican cuotas y limitaciones de Cloud SQL MySQL y PostgreSQL.

Limitaciones

Las consultas federadas de Spanner están sujetas a las siguientes limitaciones:

  • Rendimiento. Es probable que las consultas federadas no sean tan rápidas como las consultas solo al almacenamiento de BigQuery. BigQuery debe esperar a que la base de datos de origen ejecute la consulta externa y mueva de forma temporal los datos de la fuente de datos externa a BigQuery. Además, es posible que la base de datos de origen no esté optimizada para consultas estadísticas complejas.

    El rendimiento de la consulta también varía según la proximidad entre el conjunto de datos y la fuente de datos externa. Para obtener más información, consulta Regiones admitidas.

  • Las consultas federadas son de solo lectura. La consulta externa que se ejecuta en la base de datos de origen debe ser de solo lectura. Por lo tanto, las declaraciones DML o DDL no son compatibles.

  • Tipos de datos no compatibles Si tu consulta externa contiene un tipo de datos que BigQuery no admite, la consulta fallará de inmediato. Puedes convertir el tipo de datos no admitido en un tipo de datos compatible diferente.

  • Project. Debes crear el recurso de conexión en el mismo proyecto que la instancia de Cloud SQL o AlloyDB.

Precios

  • Si usas el modelo de precios según demanda, se te cobrará por la cantidad de bytes que muestre la consulta externa cuando se ejecuten consultas federadas de BigQuery. Para obtener más información, consulta los precios de análisis a pedido.

  • Si usas ediciones de BigQuery, se te cobrará según la cantidad de ranuras que uses. Para obtener más información, consulta Precios de procesamiento de capacidad.

Pushdowns de SQL

Las consultas federadas están sujetas a la técnica de optimización conocida como envíos de SQL. Mejoran el rendimiento de una consulta porque delegan operaciones, como filtrar, a la fuente de datos externa en lugar de realizarlas en BigQuery. Reducir la cantidad de datos transferidos desde la fuente de datos externa puede reducir el tiempo de ejecución de consultas y disminuir los costos. Los pushdown de SQL incluyen la reducción de las columnas (cláusulas SELECT) y los pushdown de filtros (cláusulas WHERE).

Cuando usas la función EXTERNAL_QUERY, los pushdown de SQL funcionan mediante la reescritura de la consulta original. En el siguiente ejemplo, la función EXTERNAL_QUERY se usa para comunicarse con una base de datos de Cloud SQL:

SELECT COUNT(*)
FROM (
  SELECT * FROM EXTERNAL_QUERY("<connection>", "select * from operations_table")
  )
WHERE a = 'Y' AND b NOT IN ('COMPLETE','CANCELLED');

Sin las implementaciones de SQL, la siguiente consulta se envía a Cloud SQL:

SELECT *
FROM operations_table

Cuando se ejecuta esta consulta, toda la tabla se envía a BigQuery, aunque solo se necesiten algunas filas y columnas.

Con los envíos de SQL, se envía la siguiente consulta a Cloud SQL:

SELECT `a`, `b`
FROM (
  SELECT * FROM operations_table) t
WHERE ((`a` = 'Y') AND (NOT `b` IN ('COMPLETE', 'CANCELLED'))

Cuando esta consulta se ejecuta solo dos columnas, y las filas que coinciden con el predicado de filtrado se envían a BigQuery.

Los envíos de SQL también se aplican cuando se ejecutan consultas federadas con conjuntos de datos externos de Spanner.

Puedes examinar los pushdown aplicados (si los hay) en el plan de consultas.

Limitaciones

Las transferencias de SQL tienen varias limitaciones que varían según la fuente de datos externa y la forma en que consultas los datos.

Limitaciones para la federación de consultas cuando se usa EXTERNAL_QUERY

  • Las implementaciones de SQL solo se aplican a las consultas federadas del tipo SELECT * FROM T.
  • Solo se admiten la reducción de las columnas y los pushdown de filtros. Específicamente, no se admiten las operaciones de procesamiento, unión, límite, orden y agregación.
  • En el caso de las transferencias de filtros, los literales deben ser de uno de los siguientes tipos: BOOL, INT64, FLOAT64, STRING, DATE, DATETIME y TIMESTAMP. Los literales que son structs no son compatibles.
  • Las transferencias de funciones de SQL solo se aplican a las funciones que son compatibles con BigQuery y una base de datos de destino.
  • Las implementaciones de SQL solo son compatibles con, AlloyDB, Cloud SQL y Spanner.
  • Los pushdowns de SQL no son compatibles con SAP Datasphere.

Limitaciones de la federación de consultas cuando se usan conjuntos de datos externos de Spanner

  • Se admiten la reducción de las columnas, el filtrado, el procesamiento y los pushdown de agregación parcial. Específicamente, no se admiten las uniones, los límites ni el orden por agregación.
  • En el caso de las transferencias de filtros, las literales deben ser de uno de los siguientes tipos: BOOL, INT64, FLOAT64, STRING, DATE, DATETIME, TIMESTAMP, BYTE o Arrays. Los literales que son structs no son compatibles.
  • Las implementaciones de funciones de SQL solo se aplican a las funciones que son compatibles con BigQuery y Spanner.

Funciones compatibles por fuente de datos

Las siguientes son funciones de SQL compatibles por fuente de datos. SAP Datasphere no admite ninguna función.

Cloud SQL MySQL

  • Operadores lógicos: AND, OR, NOT.
  • Operadores de comparación: =, >, >=, <, <=, <>, IN, BETWEEN, IS NULL.
  • Operadores aritméticos: +, -, * (solo para INT64 y FLOAT64).

PostgreSQL y AlloyDB de Cloud SQL

  • Operadores lógicos: AND, OR, NOT.
  • Operadores de comparación: =, >, >=, <, <=, <>, IN, BETWEEN, IS NULL.
  • Operadores aritméticos: +, -, *, / (solo para tipos INT64, FLOAT64 y DATE, excepto por la resta DATE).

Spanner: Dialecto de PostgreSQL

  • Operadores lógicos: AND, OR, NOT.
  • Operadores de comparación: =, >, >=, <, <=, <>, IN, BETWEEN, IS NULL.
  • Operadores aritméticos: +, -, *, / (solo para INT64, FLOAT64, NUMERIC).

Spanner: Dialecto de GoogleSQL

  • Operadores lógicos: AND, OR, NOT.
  • Operadores de comparación: =, >, >=, <, <=, <>, IN, BETWEEN, IS NULL.
  • Operadores aritméticos: +, -, *, / (solo para INT64, FLOAT64, NUMERIC).
  • Operadores aritméticos seguros: SAFE_ADD, SAFE_SUBTRACT, SAFE_MULTIPLY, SAFE_DIVIDE (solo para INT64, FLOAT64, NUMERIC).
  • Cuando uses conjuntos de datos externos, además, haz lo siguiente:
    • Transferencia de Compute
    • Transferencia de agregación parcial
    • Funciones de cadena
    • Funciones matemáticas
    • Funciones de transmisión
    • Funciones de array.

¿Qué sigue?