Introducción a las tablas externas de BigLake

En este documento, se proporciona una descripción general de BigLake y asume que estás familiarizado con las tablas de base de datos y Identity and Access Management (IAM). Para consultar los datos almacenados en los almacenes de datos compatibles, primero debes crear tablas de BigLake y, luego, consultarlas con la sintaxis de GoogleSQL:

También puedes actualizar una tabla externa a BigLake. Para obtener más información, consulta Actualiza una tabla externa a BigLake.

Las tablas de BigLake te permiten consultar datos estructurados en almacenes de datos externos con delegación de acceso. La delegación de acceso separa el acceso a la tabla de BigLake del acceso al almacén de datos subyacente. Se usa una conexión externa asociada con una cuenta de servicio para conectarse al almacén de datos. Debido a que la cuenta de servicio controla la recuperación de datos del almacén de datos, solo tienes que otorgar a los usuarios acceso a la tabla de BigLake. Esto te permite aplicar seguridad detallada a nivel de tabla, incluida la seguridad a nivel de fila y a nivel de columna. Para las tablas de BigLake basadas en Cloud Storage, también puedes usar el enmascaramiento de datos dinámicos. Para obtener más información sobre las soluciones analíticas de múltiples nubes mediante tablas de BigLake con datos de Amazon S3 o Blob Storage, consulta BigQuery Omni.

Almacenes de datos compatibles

Puedes usar las tablas de BigLake con los siguientes almacenes de datos:

Compatibilidad con tablas temporales

Las tablas de BigLake basadas en Cloud Storage pueden ser temporales o permanentes. Las tablas de BigLake basadas en Amazon S3 o Blob Storage deben ser permanentes.

Varios archivos fuente

Puedes crear una tabla de BigLake basada en varias fuentes de datos externas, siempre que esas fuentes de datos tengan el mismo esquema.

Uniones entre nubes

Las uniones entre nubes te permiten ejecutar consultas que abarcan las regiones de Google Cloud y BigQuery Omni. Puedes usar las operaciones JOIN de Google SQL para analizar datos en muchas soluciones de almacenamiento diferentes, como AWS, Azure, conjuntos de datos públicos y otros servicios de Google Cloud. Las uniones entre nubes eliminan la necesidad de copiar datos entre las fuentes antes de ejecutar consultas.

Puedes hacer referencia a tablas de BigLake en cualquier parte de una instrucción SELECT como si fueran tablas estándar de BigQuery, incluidas las declaraciones de lenguaje de manipulación de datos (DML) y del lenguaje de definición de datos (DDL) que usan subconsultas para recuperar datos. Puedes usar varias tablas de BigLake de diferentes nubes y tablas de BigQuery en la misma consulta. Todas las tablas de BigQuery deben ser de la misma región.

Permisos requeridos para la unión entre nubes

Para obtener los permisos que necesitas para ejecutar una unión entre nubes, pídele a tu administrador que te otorgue el rol de IAM de editor de datos de BigQuery (roles/bigquery.dataEditor) en el proyecto en el que se ejecuta la unión. Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.

Este rol predefinido contiene los permisos necesarios para ejecutar una unión entre nubes. Para ver los permisos exactos que son necesarios, expande la sección Permisos requeridos:

Permisos necesarios

Se requieren los siguientes permisos para ejecutar una unión entre nubes:

  • bigquery.datasets.create
  • bigquery.tables.create

También puedes obtener estos permisos con roles personalizados o con otros roles predefinidos.

Las uniones entre nubes crean conjuntos de datos con el prefijo __bigquery_xregion_sink_ y tablas temporales dentro de estos conjuntos de datos, por lo que solo para otorgar acceso a los recursos creados por las uniones entre nubes, usa la condición resource.name.startsWith para los tipos de recursos Table y Dataset.

Para obtener más información sobre los roles y permisos de IAM en BigQuery, consulta Introducción a IAM.

Costos de unión entre nubes

Cuando ejecutas una operación de unión entre nubes, BigQuery analiza la consulta en partes locales y remotas. La parte local se trata como una consulta estándar en la región de BigQuery. La parte remota se convierte en una operación CREATE TABLE AS SELECT (CTAS) en la tabla de BigLake a la que se hace referencia en la región de BigQuery Omni, que crea una tabla temporal en tu región de BigQuery. Luego, BigQuery usa esta tabla temporal para ejecutar la unión entre nubes y borra la tabla automáticamente después de ocho horas.

Se generan costos por transferencia de datos para los datos en las tablas de BigLake a las que se hace referencia. Sin embargo, BigQuery ayuda a reducir estos costos mediante la transferencia de columnas y filas en la tabla de BigLake a la que se hace referencia en la consulta, en lugar de la tabla completa. Recomendamos especificar un filtro de columnas que sea lo más estrecho posible para reducir aún más los costos de transferencia. El trabajo de CTAS aparece en el historial de trabajos y muestra información como la cantidad de bytes transferidos. Las transferencias exitosas generan costos incluso si falla el trabajo de consulta principal. Si quieres obtener más información, consulta los precios de BigQuery Omni.

Considera la siguiente consulta como ejemplo:

SELECT *
FROM bigquery_dataset.bigquery_table AS clients
WHERE clients.sales_rep IN (
  SELECT id
  FROM aws_dataset.aws_table1 AS employees
  INNER JOIN aws_dataset.aws_table2 AS active_employees
    ON employees.id = active_employees.id
  WHERE employees.level > 3
);

En este ejemplo, hay dos transferencias: una de una tabla de empleados (con un filtro de nivel) y otra de una tabla de empleados activos. La unión se realiza en la región de BigQuery después de que se realiza la transferencia. Si una transferencia falla y la otra se realiza de forma correcta, se aplican los cargos por transferencia de datos para la transferencia exitosa.

Limitaciones de la unión entre nubes

  • Las uniones entre nubes no son compatibles con el nivel gratuito de BigQuery ni con la zona de pruebas de BigQuery.
  • Es posible que las agregaciones no se envíen a las regiones de BigQuery Omni si la consulta contiene declaraciones JOIN.
  • Cada tabla temporal solo se usa para una única consulta entre nubes y no se vuelve a usar incluso si la misma consulta se repite varias veces.
  • El límite de tamaño de transferencia para cada transferencia es de 60 GB. En particular, si aplicas un filtro en una tabla de BigLake y cargas el resultado, el tamaño debe ser inferior a 60 GB. Si es necesario, puedes solicitar un límite de cuota más alto. No hay límite para los bytes analizados.
  • Las consultas de unión entre nubes usan una cuota interna en la tasa de consultas. Si la tasa de consultas supera la cuota, es posible que recibas un error All our servers are busy processing data transferred between regions. Intente la consulta debería funcionar en la mayoría de los casos. Comunícate con el equipo de asistencia para aumentar la cuota interna para admitir una tasa más alta de consultas.
  • Las uniones entre nubes solo se admiten en regiones de BigQuery ubicadas en el mismo lugar con sus regiones de BigQuery Omni correspondientes y en las multirregiones US y EU. Las uniones entre nubes que se ejecutan en las multirregiones US o EU solo pueden acceder a los datos en las regiones de BigQuery Omni de EE. UU. o la UE, respectivamente.
  • Si una consulta de unión entre nubes hace referencia a 10 o más conjuntos de datos de regiones de BigQuery Omni, puede que falle con un error Not found: Dataset <BigQuery dataset> was not found in location <BigQuery Omni region>. Para evitar este problema, recomendamos especificar de forma explícita una ubicación cuando ejecutes una unión entre nubes que haga referencia a más de 10 conjuntos de datos. Ten en cuenta que si especificas de forma explícita una región de BigQuery y tu consulta solo contiene tablas de BigLake, tu consulta se ejecuta como una consulta entre nubes y genera costos de transferencia de datos.
  • No puedes consultar la seudocolumna _FILE_NAME con uniones entre nubes.
  • Cuando haces referencia a las columnas de una tabla de BigLake en una cláusula WHERE, no puedes usar literales INTERVAL ni RANGE.
  • Los trabajos de unión entre nubes no informan la cantidad de bytes que se procesan y transfieren desde otras nubes. Esta información está disponible en los trabajos secundarios de CTAS que se crean como parte de la ejecución de consultas entre nubes.
  • Las vistas autorizadas y las rutinas autorizadas que hacen referencia a las tablas o vistas de BigQuery Omni solo son compatibles con las regiones de BigQuery Omni.
  • Si tu consulta entre nubes hace referencia a columnas STRUCT o JSON, no se aplican pushdowns a ninguna subconsulta remota. Para optimizar el rendimiento, considera crear una vista en la región de BigQuery Omni que filtre las columnas STRUCT y JSON muestre solo los campos necesarios como columnas individuales.
  • Las consultas de viaje en el tiempo no son compatibles con las uniones entre nubes.

Ejemplos de unión entre nubes

La siguiente consulta une una tabla orders en una región de BigQuery con una tabla lineitem en una región de BigQuery Omni:

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN aws_dataset.lineitem
  ON orders.o_orderkey = lineitem.l_orderkey
WHERE
  l_shipmode IN ('AIR', 'REG AIR')
  AND l_commitdate < l_receiptdate
  AND l_shipdate < l_commitdate
  AND l_receiptdate >= DATE '1997-01-01'
  AND l_receiptdate < DATE '1997-02-01'
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

Esta consulta se divide en partes locales y remotas. La siguiente consulta se envía a la región de BigQuery Omni para ejecutarse primero. El resultado es una tabla temporal en la región de BigQuery. Puedes ver este trabajo de CTAS secundario y sus metadatos en tu historial de trabajos.

CREATE OR REPLACE TABLE temp_table
AS (
  SELECT
    l_shipmode,
    l_linenumber,
    l_orderkey
  FROM aws_dataset.lineitem
  WHERE
    l_shipmode IN ('AIR', 'REG AIR')
    AND l_commitdate < l_receiptdate
    AND l_shipdate < l_commitdate
    AND l_receiptdate >= DATE '1997-01-01'
    AND l_receiptdate < DATE '1997-02-01'
);

Después de crear la tabla temporal, se completa la operación JOIN y se ejecuta la siguiente consulta:

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN temp_table
  ON orders.o_orderkey = lineitem.l_orderkey
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

Como otro ejemplo, considera la siguiente unión entre nubes:

SELECT c_mktsegment, c_name
FROM bigquery_dataset.customer
WHERE c_mktsegment = 'BUILDING'
UNION ALL
SELECT c_mktsegment, c_name
FROM aws_dataset.customer
WHERE c_mktsegment = 'FURNITURE'
LIMIT 10;

En esta consulta, la cláusula LIMIT no se envía a la región de BigQuery Omni. Todos los clientes del segmento FURNITURE del mercado se transfieren primero a la región de BigQuery y, luego, se aplica el límite de 10.

Conectores

Puedes acceder a los datos en tablas de BigLake basadas en Cloud Storage desde otras herramientas de procesamiento de datos mediante conectores de BigQuery. Por ejemplo, puedes acceder a los datos en tablas de BigLake desde Apache Spark, Apache Hive, TensorFlow, Trino o Presto. La API de almacenamiento de BigQuery aplica políticas de administración a nivel de fila y columna en todo el acceso a los datos a tablas de BigLake, incluidos los conectores.

Por ejemplo, en el siguiente diagrama, se muestra cómo la API de BigQuery Storage permite que los usuarios accedan a datos autorizados mediante motores de consultas de código abierto, como Apache Spark:

Arquitectura de BigLake.

Para obtener más información sobre los conectores compatibles con BigQuery, consulta Conectores de BigQuery.

Tablas de BigLake en almacenes de objetos

Para los administradores de data lakes, BigLake te permite configurar el control de acceso en las tablas en lugar de en los archivos, lo que te brinda opciones más específicas cuando configuras el acceso de los usuarios a los datos en el data lake.

Debido a que las tablas de BigLake simplifican el control de acceso de esta manera, recomendamos usar tablas de BigLake para compilar y mantener conexiones a almacenes de objetos externos.

Puedes usar tablas externas en los casos en que la administración no sea un requisito o para el descubrimiento y la manipulación de datos ad hoc.

Limitaciones

  • Todas las limitaciones para tablas externas se aplican a las tablas de BigLake.
  • Las tablas de BigLake en los almacenes de objetos están sujetas a las mismas limitaciones que las tablas de BigQuery. Para obtener más información, consulta Cuotas.

  • BigLake no admite credenciales de alcance reducido de la autenticación del clúster personal de Dataproc. Como solución alternativa, para usar clústeres con la autenticación de clústeres personales, debes insertar tus credenciales con un límite de acceso a credenciales vacío que tenga la marca --access-boundary=<(echo -n "{}"). Por ejemplo, el siguiente comando habilita una sesión de propagación de credenciales en un proyecto llamado myproject para el clúster llamado mycluster: 

    gcloud dataproc clusters enable-personal-auth-session \
    --region=us \
    --project=myproject \
    --access-boundary=<(echo -n "{}") \
    mycluster

  • Las tablas de BigLake son de solo lectura. No puedes cambiar las tablas de BigLake con declaraciones DML ni otros métodos.

  • Las tablas de BigLake admiten los siguientes formatos:

  • No puedes usar metadatos almacenados en caché con tablas externas de BigLake para Apache Iceberg. BigQuery ya usa los metadatos que captura Iceberg en archivos de manifiesto.

  • La API de BigQuery Storage no está disponible en otros entornos de nube, como AWS y Azure.

  • Si usas metadatos almacenados en caché, se aplican las siguientes limitaciones:

    • Solo puedes usar metadatos almacenados en caché con tablas de BigLake que usen formatos Avro, ORC, Parquet, JSON y CSV.
    • Si creas, actualizas o borras archivos en Amazon S3, la consulta de los archivos no muestra los datos actualizados hasta la próxima actualización de la caché de metadatos. Esto puede generar resultados inesperados. Por ejemplo, si borras un archivo y escribes uno nuevo, los resultados de la consulta pueden excluir los archivos antiguos y los nuevos según la última vez que se actualizaron los metadatos en caché.
    • El uso de claves de encriptación administradas por el cliente (CMEK) con metadatos almacenados en caché no es compatible con las tablas de BigLake que hacen referencia a datos de Amazon S3 o Blob Storage.

Modelo de seguridad

Por lo general, los siguientes roles de la organización participan en la administración y el uso de las tablas de BigLake:

  • Administradores de data lakes. Estos administradores suelen gestionar las políticas de Identity and Access Management (IAM) en los buckets y objetos de Cloud Storage.
  • Administradores de almacenes de datos. Estos administradores suelen crear, borrar y actualizar tablas.
  • Analistas de datos. Por lo general, los analistas leen datos y ejecutan consultas.

Los administradores de data lakes son responsables de crear conexiones y compartirlas con administradores de almacenes de datos. A su vez, los administradores de almacenes de datos crean tablas, establecen controles de acceso adecuados y comparten las tablas con los analistas de datos.

Almacenamiento en caché de metadatos para rendimiento

Puedes usar metadatos almacenados en caché para mejorar el rendimiento de las consultas en algunos tipos de tablas de BigLake. El almacenamiento de metadatos en caché es muy útil en los casos en que trabajas con grandes cantidades de archivos o si los datos están particionados como subárbol. Los siguientes tipos de tablas de BigLake admiten el almacenamiento de metadatos en caché:

  • Tablas de BigLake de Amazon S3
  • Tablas de BigLake de Cloud Storage
Los metadatos incluyen nombres de archivo, información de partición y metadatos físicos de archivos, como recuentos de filas. Puedes elegir si deseas habilitar o no el almacenamiento de metadatos en caché en una tabla. Las consultas con una gran cantidad de archivos y con filtros de partición de subárbol se benefician más del almacenamiento de metadatos en caché.

Si no habilitas el almacenamiento de metadatos en caché, las consultas en la tabla deben leer la fuente de datos externa para obtener metadatos de objeto. Leer estos datos aumenta la latencia de la consulta, ya que enumerar millones de archivos de la fuente de datos externa puede tardar varios minutos. Si habilitas el almacenamiento de metadatos en caché, las consultas pueden evitar la enumeración de archivos de la fuente de datos externa y pueden particionar y reducir los archivos más rápido.

Hay dos propiedades que controlan esta característica:

  • La inactividad máxima especifica cuándo las consultas usan metadatos almacenados en caché
  • El modo de almacenamiento de metadatos en caché especifica cómo se recopilan los metadatos

Cuando tienes habilitado el almacenamiento de metadatos en caché, debes especificar el intervalo máximo de inactividad de metadatos que es aceptable para las operaciones en la tabla. Por ejemplo, si especificas un intervalo de 1 hora, las operaciones en la tabla usan metadatos almacenados en caché si se actualizaron en la última hora. Si los metadatos almacenados en caché son más antiguos que eso, la operación recurre a la recuperación de metadatos desde el almacén de datos (Amazon S3 o Cloud Storage). Puedes especificar un intervalo de inactividad de entre 30 minutos y 7 días.

Puedes actualizar la caché de forma automática o manual:

  • Para las actualizaciones automáticas, la caché se actualiza a un intervalo definido por el sistema, que suele estar entre 30 y 60 minutos. Actualizar la caché de forma automática es una buena estrategia si los archivos de almacén de datos se agregan, borran o modifican a intervalos aleatorios. Si necesitas controlar el momento de la actualización, por ejemplo, para activarla al final de un trabajo de extracción, transformación y carga, usa la actualización manual.

  • En el caso de las actualizaciones manuales, ejecuta el procedimiento del sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE para actualizar la caché de metadatos en una programación que cumpla con tus requisitos. Para las tablas de BigLake, puedes actualizar los metadatos de forma selectiva si proporcionas subdirectorios del directorio de datos de tablas. Esto te permite evitar el procesamiento de metadatos innecesario. Actualizar la caché de forma manual es una buena estrategia si se agregan, se borran o se modifican los archivos en el almacén de datos, a intervalos conocidos, por ejemplo, como resultado de una canalización.

    Si emites varias actualizaciones manuales simultáneas, solo una tendrá éxito.

La caché de metadatos vence después de 7 días si no se actualiza.

Las actualizaciones de caché manuales y automáticas se ejecutan con la prioridad de consulta INTERACTIVE.

Si eliges usar actualizaciones automáticas, te recomendamos que crees una reserva y, luego, una asignación con un tipo de trabajo BACKGROUND para el proyecto que ejecuta los trabajos de actualización de caché de metadatos. Esto evita que los trabajos de actualización compitan con las consultas de los usuarios por recursos y que puedan fallar si no hay suficientes recursos disponibles para ellos.

Debes considerar cómo interactuarán los valores del intervalo de inactividad y el modo de almacenamiento de metadatos en caché antes de configurarlos. Considera los siguientes ejemplos:

  • Si actualizas la caché de metadatos de una tabla de manual y estableces el intervalo de inactividad en 2 días, debes ejecutar el procedimiento del sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE cada 2 días o menos si deseas operaciones en la tabla para usar metadatos almacenados en caché.
  • Si actualizas de foma automática la caché de metadatos de una tabla y estableces el intervalo de inactividad en 30 minutos, es posible que algunas de las operaciones para la tabla lean desde el almacén de datos si los metadatos La actualización de la caché lleva más tiempo del período habitual de 30 a 60 minutos.

Para obtener información sobre los trabajos de actualización de metadatos, consulta la vista INFORMATION_SCHEMA.JOBS, como se muestra en el siguiente ejemplo:

SELECT *
FROM `region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE job_id LIKE '%metadata_cache_refresh%'
AND creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)
ORDER BY start_time DESC
LIMIT 10;

En las tablas de Cloud Storage BigLakebasadas en archivos de Parquet, las estadísticas de tablas se recopilan durante la actualización de la caché de metadatos y se usan para mejorar los planes de consultas.

Para obtener más información, consulta Almacenamiento en caché de metadatos.

Para obtener más información acerca de la configuración de opciones de almacenamiento de metadatos en caché, consulta Crea tablas de BigLake de Amazon S3 o Crea tablas de BigLake de Cloud Storage.

Tablas habilitadas para caché con vistas materializadas

Puedes usar vistas materializadas en las tablas habilitadas para caché de metadatos de BigLake a fin de mejorar el rendimiento y la eficiencia cuando se consultan datos estructurados almacenados en Cloud Storage o Amazon Simple Storage Service (Amazon S3). Estas vistas materializadas funcionan como vistas materializadas en tablas de almacenamiento administradas por BigQuery, incluidos los beneficios de actualización automática y ajuste inteligente.

Integraciones

Se puede acceder a las tablas de BigLake desde otras funciones de BigQuery y servicios de la CLI de gcloud, incluidos los siguientes servicios destacados.

Analytics Hub

Las tablas de BigLake son compatibles con Analytics Hub. Los conjuntos de datos que contienen tablas de BigLake se pueden publicar como listas de Analytics Hub. Los suscriptores de Analytics Hub pueden suscribirse a estas listas, que aprovisionan un conjunto de datos de solo lectura, llamado conjunto de datos vinculados, en su proyecto. Los suscriptores pueden consultar todas las tablas en el conjunto de datos vinculado, incluidas todas las tablas de BigLake. Para obtener más información, consulta Visualiza y suscríbete a fichas.

BigQuery ML

Puedes usar BigQuery ML para entrenar y ejecutar modelos en BigLake en Cloud Storage.

Sensitive Data Protection

La protección de datos sensibles analiza tus tablas de BigLake para identificar y clasificar datos sensibles. Si se detectan datos sensibles, las transformaciones de desidentificación de protección de datos sensibles pueden enmascarar, borrar o, de otro modo, ocultar esos datos.

Costos

Los costos se asocian con los siguientes aspectos de las tablas de BigLake:

Si tienes reservas de ranuras, no se te cobra por consultar tablas externas. En cambio, se consumen las ranuras para estas consultas.

En la siguiente tabla, se muestra cómo tu modelo de precios afecta la en que se aplican estos costos:


Precios según demanda
Ediciones Standard, Enterprise y Enterprise Plus

Consultas
Se te facturará por los bytes procesados por consultas de usuarios.
Las ranuras en asignaciones de reservas con un tipo de trabajo QUERY se consumen durante el tiempo de consulta.

Actualiza de manual la caché de metadatos.
Se te facturará por los bytes procesados para actualizar la caché.
Las ranuras en asignaciones de reservas con un tipo de trabajo QUERY se consumen durante la actualización de la caché.

Actualiza de foma automática la caché de metadatos.
Se te facturará por los bytes procesados para actualizar la caché.
Las ranuras en asignaciones de reservas con un tipo de trabajo BACKGROUND se consumen durante la actualización de la caché.

Si no hay reservas BACKGROUND disponibles para actualizar la caché de metadatos, BigQuery usa de forma automática ranuras en reservas QUERY en su lugar si utilizas la edición Enterprise o Enterprise Plus.

También se te cobra por el almacenamiento y el acceso a los datos mediante Cloud Storage, Amazon S3 y Azure Blob Storage, con sujeción a los lineamientos de precios de cada producto.

¿Qué sigue?