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.

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 que se conoce como pushdown de SQL. Mejoran el rendimiento de una consulta mediante la delegación de 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 las consultas y reducir 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.

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

Limitaciones

  • Las pushdown de SQL solo se aplican a consultas federadas con el formato SELECT * FROM T.
  • Solo se admiten la reducción de las columnas y los pushdown de filtros. No se admiten los pushdown de procesamiento, unión y agregación.
  • Para los pushdown de filtros, los literales deben ser de uno de los siguientes tipos: BOOL, INT64, FLOAT64, STRING, DATE, DATETIME, TIMESTAMP Los literales que son structs o arrays no son compatibles.
  • Las implementaciones de SQL solo son compatibles con, AlloyDB, Cloud SQL y Spanner. Los pushdown de SQL no son compatibles con SAP Datasphere.

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).

Funciones compatibles con 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

El dialecto GoogleSQL admite las mismas funciones que el dialecto PostgreSQL y, además, lo siguiente:

  • Operadores aritméticos seguros: SAFE_ADD, SAFE_SUBTRACT, SAFE_MULTIPLY, SAFE_DIVIDE (solo para INT64, FLOAT64, NUMERIC).

¿Qué sigue?