Introducción a las tablas 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.

Combinaciones

Las tablas de BigLake basadas en Cloud Storage se pueden unir a otras tablas de BigQuery, sujetas a las consideraciones de ubicación. Las tablas de BigLake basadas en Amazon S3 o Blob Storage solo se pueden unir con otras tablas de BigLake en la misma ubicación.

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.

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 las 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 modificar las tablas de BigLake con declaraciones DML ni otros métodos.

  • Las tablas de BigLake admiten los siguientes formatos:

    • Avro
    • CSV
    • Iceberg
    • JSON
    • ORC
    • Parquet

  • No puedes usar metadatos almacenados en caché con tablas de Apache Iceberg BigLake. 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 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 tablas de BigLake. Es útil en los casos en que trabajas con grandes cantidades de archivos o si los datos están particionados.

Las tablas de BigLake y de los objetos admiten el almacenamiento en caché de metadatos sobre archivos de fuentes de datos externas, como Cloud Storage y Amazon Simple Storage Service (Amazon S3) (vista previa). 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, lo que 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 lograr una reducción más rápida de las particiones y los archivos.

Hay dos propiedades que controlan esta característica:

  • Inactividad máxima, que controla cuándo las consultas usan metadatos almacenados en caché
  • Modo de almacenamiento de metadatos en caché, que controla 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 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 la fuente de datos externa 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 la programación que determines. Actualizar la caché de forma manual es un buen enfoque si se agregan, borran o modifican los archivos en z en intervalos conocidos, por ejemplo, como el 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.

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 forma 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 automáticamente 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 Cloud Storage 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;

Puedes usar vistas materializadas en tablas habilitadas para caché de metadatos de BigLake para mejorar el rendimiento y la eficiencia cuando se consultan datos estructurados almacenados en Cloud Storage. 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.

En las tablas de BigLake basadas 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 sobre cómo configurar las opciones de almacenamiento en caché, consulta Crea una tabla de BigLake o Actualiza una tabla de BigLake.

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 Suscríbete a una ficha.

BigQuery ML

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

Protección de datos sensibles

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:

En la siguiente tabla, se muestra cómo tu modelo de precios afecta la forma 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 manualmente la caché de metadatos.
Se te facturará por los bytes procesados a fin de 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 automáticamente la caché de metadatos.
Se te facturará por los bytes procesados a fin de 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 automáticamente ranuras en reservas QUERY en su lugar si utilizas la edición Enterprise o Enterprise Plus.

¿Qué sigue?