Tablas de BigLake para Apache Iceberg en BigQuery

Las tablas de BigLake para Apache Iceberg en BigQuery (en adelante, tablas de Iceberg de BigLake en BigQuery) proporcionan la base para crear lakehouses de formato abierto en Google Cloud. Las tablas de Iceberg de BigLake en BigQuery ofrecen la misma experiencia totalmente gestionada que las tablas estándar de BigQuery, pero almacenan los datos en los contenedores de almacenamiento propiedad del cliente. Las tablas de Iceberg de BigLake en BigQuery admiten el formato de tabla de Iceberg abierto para mejorar la interoperabilidad con motores de cálculo de código abierto y de terceros en una sola copia de los datos.

Las tablas de BigLake para Apache Iceberg en BigQuery son distintas de las tablas externas de Apache Iceberg. Las tablas de BigLake para Apache Iceberg en BigQuery son tablas totalmente gestionadas que se pueden modificar directamente en BigQuery, mientras que las tablas externas de Apache Iceberg las gestionan los clientes y ofrecen acceso de solo lectura desde BigQuery.

Las tablas de Iceberg de BigLake en BigQuery admiten las siguientes funciones:

• Mutaciones de tablas mediante el lenguaje de manipulación de datos (DML) de GoogleSQL.
• Procesamiento unificado por lotes y de streaming de alto rendimiento mediante la API Storage Write a través de conectores de BigLake, como Spark, Dataflow y otros motores.
• Exportación de instantáneas de Iceberg V2 y actualización automática en cada mutación de tabla para acceder directamente a las consultas con motores de consulta de código abierto y de terceros.
• Evolución del esquema: te permite añadir, eliminar y cambiar el nombre de las columnas según tus necesidades. Esta función también te permite cambiar el tipo de datos de una columna y el modo de columna. Para obtener más información, consulta las reglas de conversión de tipos.
• Optimización automática del almacenamiento, que incluye el ajuste adaptativo del tamaño de los archivos, la agrupación automática en clústeres, la recolección de elementos no utilizados y la optimización de metadatos.
• Viaje en el tiempo para acceder al historial de datos en BigQuery.
• Seguridad a nivel de columna y máscara de datos.
• Transacciones con varias instrucciones (en vista previa).

Arquitectura

Las tablas de Iceberg de BigLake en BigQuery ofrecen la comodidad de la gestión de recursos de BigQuery a las tablas que residen en tus propios contenedores en la nube. Puedes usar BigQuery y motores de computación de código abierto en estas tablas sin mover los datos de los contenedores que controlas. Debes configurar un bucket de Cloud Storage antes de empezar a usar tablas de Iceberg de BigLake en BigQuery.

Las tablas de Iceberg de BigLake en BigQuery utilizan BigLake Metastore como metastore de tiempo de ejecución unificado para todos los datos de Iceberg. El metastore de BigLake proporciona una única fuente de información veraz para gestionar los metadatos de varios motores y permite la interoperabilidad entre motores.

En el siguiente diagrama se muestra la arquitectura de las tablas gestionadas a nivel general:

Esta gestión de tablas tiene las siguientes implicaciones en tu contenedor:

• BigQuery crea archivos de datos en el segmento en respuesta a las solicitudes de escritura y a las optimizaciones de almacenamiento en segundo plano, como las instrucciones DML y el streaming.
• Cuando eliminas una tabla gestionada en BigQuery, BigQuery recoge los archivos de datos asociados en Cloud Storage después de que expire el periodo de viaje en el tiempo.

Crear una tabla de Iceberg de BigLake en BigQuery es similar a crear tablas de BigQuery. Como almacena datos en formatos abiertos en Cloud Storage, debes hacer lo siguiente:

• Especifica la conexión de recursos de Cloud con WITH CONNECTION para configurar las credenciales de conexión de BigLake y acceder a Cloud Storage.
• Especifica el formato de archivo del almacenamiento de datos como PARQUET con la instrucción file_format = PARQUET.
• Especifica el formato de tabla de metadatos de código abierto como ICEBERG con la instrucción table_format = ICEBERG.

Prácticas recomendadas

Si cambia o añade archivos directamente al contenedor fuera de BigQuery, puede perder datos o sufrir errores irrecuperables. En la siguiente tabla se describen los posibles casos:

Prácticas recomendadas para configurar segmentos de Cloud Storage

La configuración de tu bucket de Cloud Storage y su conexión con BigLake influyen directamente en el rendimiento, el coste, la integridad de los datos, la seguridad y la gobernanza de tus tablas de Iceberg de BigLake en BigQuery. A continuación, se indican las prácticas recomendadas para llevar a cabo esta configuración:

• Selecciona un nombre que indique claramente que el bucket solo está pensado para las tablas de BigLake Iceberg de BigQuery.

• Elige segmentos de Cloud Storage de una sola región que estén ubicados en la misma región que tu conjunto de datos de BigQuery. Esta coordinación mejora el rendimiento y reduce los costes, ya que evita los cargos por transferencia de datos.

• De forma predeterminada, Cloud Storage almacena los datos en la clase de almacenamiento Estándar, que ofrece un rendimiento suficiente. Para optimizar los costes de almacenamiento de datos, puedes habilitar Autoclass para gestionar automáticamente las transiciones de clase de almacenamiento. Autoclass empieza con la clase de almacenamiento Estándar y mueve los objetos a los que no se accede a clases cada vez más frías para reducir los costes de almacenamiento. Cuando se vuelve a leer el objeto, se mueve de nuevo a la clase Standard.

• Habilita el acceso uniforme a nivel de segmento y la prevención de acceso público.

• Comprueba que los roles obligatorios se han asignado a los usuarios y las cuentas de servicio correctos.

• Para evitar que se eliminen o dañen accidentalmente datos de Iceberg en tu segmento de Cloud Storage, restringe los permisos de escritura y eliminación a la mayoría de los usuarios de tu organización. Para ello, puedes definir una política de permisos de contenedor con condiciones que denieguen las solicitudes PUT y DELETE de todos los usuarios, excepto de los que especifiques.

• Aplica claves de cifrado gestionadas por Google o gestionadas por el cliente para proteger aún más los datos sensibles.

• Habilita el registro de auditoría para disfrutar de transparencia operativa, solucionar problemas y monitorizar el acceso a los datos.

• Mantén la política de eliminación no definitiva predeterminada (conservación de 7 días) para protegerte frente a eliminaciones accidentales. Sin embargo, si detectas que se han eliminado datos de Iceberg, ponte en contacto con el equipo de Asistencia en lugar de restaurar objetos manualmente, ya que los objetos que se añaden o modifican fuera de BigQuery no se registran en los metadatos de BigQuery.

• El ajuste de tamaño de archivo adaptativo, la agrupación automática y la recogida de elementos no utilizados se habilitan automáticamente y ayudan a optimizar el rendimiento y el coste de los archivos.

• Evita las siguientes funciones de Cloud Storage, ya que no se admiten en las tablas de Iceberg de BigLake en BigQuery:

  • Espacios de nombres jerárquicos
  • Regiones duales y multirregionales
  • Listas de control de acceso (LCA) de objetos
  • Claves de cifrado proporcionadas por el cliente
  • Gestión de versiones de objetos
  • Bloqueo de objetos
  • Bloqueo de segmentos
  • Restaurar objetos eliminados temporalmente con la API de BigQuery o la herramienta de línea de comandos bq

Para implementar estas prácticas recomendadas, crea tu contenedor con el siguiente comando:

gcloud storage buckets create gs://BUCKET_NAME \
    --project=PROJECT_ID \
    --location=LOCATION \
    --enable-autoclass \
    --public-access-prevention \
    --uniform-bucket-level-access

Haz los cambios siguientes:

• BUCKET_NAME: el nombre del nuevo contenedor
• PROJECT_ID: el ID de tu proyecto
• LOCATION: la ubicación del nuevo contenedor

Tablas Iceberg de BigLake en flujos de trabajo de BigQuery

En las siguientes secciones se describe cómo crear, cargar, gestionar y consultar tablas gestionadas.

Antes de empezar

Antes de crear y usar tablas de Iceberg de BigLake en BigQuery, asegúrate de haber configurado una conexión de recurso de Cloud a un segmento de almacenamiento. Tu conexión necesita permisos de escritura en el contenedor de almacenamiento, tal como se especifica en la sección Roles obligatorios. Para obtener más información sobre los roles y permisos necesarios para las conexiones, consulta Gestionar conexiones.

Roles obligatorios

Para obtener los permisos que necesitas para que BigQuery gestione las tablas de tu proyecto, pide a tu administrador que te asigne los siguientes roles de gestión de identidades y accesos:

• Para crear tablas de Iceberg de BigLake en BigQuery, sigue estos pasos:
  • Propietario de datos de BigQuery (roles/bigquery.dataOwner) en tu proyecto
  • Administrador de conexión de BigQuery (roles/bigquery.connectionAdmin) en tu proyecto
• Para consultar tablas de Iceberg de BigLake en BigQuery, sigue estos pasos:
  • Lector de datos de BigQuery (roles/bigquery.dataViewer) en tu proyecto
  • Usuario de BigQuery (roles/bigquery.user) en tu proyecto
• Concede a la cuenta de servicio de conexión los siguientes roles para que pueda leer y escribir datos en Cloud Storage:
  • Usuario de objetos de Storage (roles/storage.objectUser) en el contenedor
  • Lector de segmentos heredados de Storage (roles/storage.legacyBucketReader) en el segmento

Para obtener más información sobre cómo conceder roles, consulta el artículo Gestionar el acceso a proyectos, carpetas y organizaciones.

Estos roles predefinidos contienen los permisos necesarios para que BigQuery gestione las tablas de tu proyecto. Para ver los permisos exactos que se necesitan, despliega la sección Permisos necesarios:

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

Crear tablas de Iceberg de BigLake en BigQuery

Para crear una tabla de Iceberg de BigLake en BigQuery, selecciona uno de los siguientes métodos:

CREATE TABLE [PROJECT_ID.]DATASET_ID.TABLE_NAME (
COLUMN DATA_TYPE[, ...]
)
CLUSTER BY CLUSTER_COLUMN_LIST
WITH CONNECTION {CONNECTION_NAME | DEFAULT}
OPTIONS (
file_format = 'PARQUET',
table_format = 'ICEBERG',
storage_uri = 'STORAGE_URI');

bq --project_id=PROJECT_ID mk \
    --table \
    --file_format=PARQUET \
    --table_format=ICEBERG \
    --connection_id=CONNECTION_NAME \
    --storage_uri=STORAGE_URI \
    --schema=COLUMN_NAME:DATA_TYPE[, ...] \
    --clustering_fields=CLUSTER_COLUMN_LIST \
    DATASET_ID.MANAGED_TABLE_NAME

{
"tableReference": {
  "tableId": "TABLE_NAME"
},
"biglakeConfiguration": {
  "connectionId": "CONNECTION_NAME",
  "fileFormat": "PARQUET",
  "tableFormat": "ICEBERG",
  "storageUri": "STORAGE_URI"
},
"schema": {
  "fields": [
    {
      "name": "COLUMN_NAME",
      "type": "DATA_TYPE"
    }
    [, ...]
  ]
}
}

Importar datos a tablas Iceberg de BigLake en BigQuery

En las siguientes secciones se describe cómo importar datos de varios formatos de tabla a tablas de Iceberg de BigLake en BigQuery.

Carga estándar de datos de archivos sin formato

Las tablas de Iceberg de BigLake en BigQuery usan tareas de carga de BigQuery para cargar archivos externos en tablas de Iceberg de BigLake en BigQuery. Si tienes una tabla de Iceberg de BigLake en BigQuery, sigue la bq loadguía de la CLI o la LOADguía de SQL para cargar datos externos. Una vez cargados los datos, se escriben nuevos archivos Parquet en la carpeta STORAGE_URI/data.

Si se siguen las instrucciones anteriores sin una tabla de Iceberg de BigLake en BigQuery, se creará una tabla de BigQuery.

Consulta los siguientes ejemplos específicos de herramientas para realizar cargas por lotes en tablas gestionadas:

LOAD DATA INTO MANAGED_TABLE_NAME
FROM FILES (
uris=['STORAGE_URI'],
format='FILE_FORMAT');

bq load \
  --source_format=FILE_FORMAT \
  MANAGED_TABLE \
  STORAGE_URI

Carga estándar de archivos con particiones de Hive

Puedes cargar archivos con particiones de Hive en tablas de Iceberg de BigLake en BigQuery con trabajos de carga estándar de BigQuery. Para obtener más información, consulta Cargar datos con particiones externas.

Cargar datos de streaming de Pub/Sub

Puedes cargar datos de streaming en tablas Iceberg de BigLake en BigQuery mediante una suscripción de Pub/Sub a BigQuery.

Exportar datos de tablas Iceberg de BigLake en BigQuery

En las siguientes secciones se describe cómo exportar datos de tablas de BigLake Iceberg en BigQuery a varios formatos de tabla.

Exportar datos a formatos sin estructura

Para exportar una tabla Iceberg de BigLake en BigQuery a un formato plano, utilice la sentencia EXPORT DATA y seleccione un formato de destino. Para obtener más información, consulta el artículo Exportar datos.

Crear una tabla de Iceberg de BigLake en las instantáneas de metadatos de BigQuery

Para crear una tabla de Iceberg de BigLake en una instantánea de metadatos de BigQuery, sigue estos pasos:

1. Exporta los metadatos al formato Iceberg V2 con la instrucción SQL EXPORT TABLE METADATA.

2. Opcional: Programa la actualización de la captura de metadatos de Iceberg. Para actualizar una captura de metadatos de Iceberg en función de un intervalo de tiempo determinado, usa una consulta programada.

3. Opcional: Habilita la actualización automática de metadatos de tu proyecto para actualizar automáticamente la instantánea de metadatos de la tabla Iceberg en cada mutación de la tabla. Para habilitar la actualización automática de metadatos, ponte en contacto con bigquery-tables-for-apache-iceberg-help@google.com. Se aplican EXPORT METADATA costes en cada operación de actualización.

En el siguiente ejemplo se crea una consulta programada llamada My Scheduled Snapshot Refresh Query con la instrucción DDL EXPORT TABLE METADATA FROM mydataset.test. La instrucción DDL se ejecuta cada 24 horas.

bq query \
    --use_legacy_sql=false \
    --display_name='My Scheduled Snapshot Refresh Query' \
    --schedule='every 24 hours' \
    'EXPORT TABLE METADATA FROM mydataset.test'

Ver una tabla Iceberg de BigLake en una instantánea de metadatos de BigQuery

Después de actualizar la tabla de Iceberg de BigLake en la instantánea de metadatos de BigQuery, puedes encontrar la instantánea en el URI de Cloud Storage en el que se creó originalmente la tabla de Iceberg de BigLake en BigQuery. La carpeta /data contiene los fragmentos de datos del archivo Parquet y la carpeta /metadata contiene la tabla de Iceberg de BigLake en la instantánea de metadatos de BigQuery.

SELECT
  table_name,
  REGEXP_EXTRACT(ddl, r"storage_uri\s*=\s*\"([^\"]+)\"") AS storage_uri
FROM
  `mydataset`.INFORMATION_SCHEMA.TABLES;

Ten en cuenta que mydataset y table_name son marcadores de posición de tu conjunto de datos y tabla reales.

Leer tablas de Iceberg de BigLake en BigQuery con Apache Spark

En el siguiente ejemplo se configura el entorno para usar Spark SQL con Apache Iceberg y, a continuación, se ejecuta una consulta para obtener datos de una tabla de BigLake Iceberg especificada en BigQuery.

spark-sql \
  --packages org.apache.iceberg:iceberg-spark-runtime-ICEBERG_VERSION_NUMBER \
  --conf spark.sql.catalog.CATALOG_NAME=org.apache.iceberg.spark.SparkCatalog \
  --conf spark.sql.catalog.CATALOG_NAME.type=hadoop \
  --conf spark.sql.catalog.CATALOG_NAME.warehouse='BUCKET_PATH' \

# Query the table
SELECT * FROM CATALOG_NAME.FOLDER_NAME;

Haz los cambios siguientes:

• ICEBERG_VERSION_NUMBER: la versión actual del tiempo de ejecución de Apache Spark Iceberg. Descarga la última versión desde Lanzamientos de Spark.
• CATALOG_NAME: el catálogo para hacer referencia a tu tabla Iceberg de BigLake en BigQuery.
• BUCKET_PATH: la ruta al contenedor que contiene los archivos de tabla. Por ejemplo, gs://mybucket/.
• FOLDER_NAME: la carpeta que contiene los archivos de la tabla. Por ejemplo, myfolder.

Modificar tablas de Iceberg de BigLake en BigQuery

Para modificar una tabla de Iceberg de BigLake en BigQuery, sigue los pasos que se indican en Modificar esquemas de tablas.

Usar transacciones con varias instrucciones

Para obtener acceso a las transacciones de varias instrucciones de las tablas de Iceberg de BigLake en BigQuery, rellena el formulario de registro.

Precios

Los precios de las tablas de Iceberg de BigLake en BigQuery se basan en el almacenamiento, la optimización del almacenamiento, las consultas y los trabajos.

Almacenamiento

Las tablas Iceberg de BigLake en BigQuery almacenan todos los datos en Cloud Storage. Se te cobra por todos los datos almacenados, incluidos los datos históricos de las tablas. También se pueden aplicar cargos por tratamiento y transferencia de datos de Cloud Storage. Es posible que no se cobren algunas tarifas de operaciones de Cloud Storage por las operaciones que se procesan a través de BigQuery o de la API Storage de BigQuery. No se aplican tarifas de almacenamiento específicas de BigQuery. Consulta más información en la página Precios de Cloud Storage.

Optimización del almacenamiento

Las tablas de Iceberg de BigLake en BigQuery realizan una optimización automática del almacenamiento, que incluye el ajuste adaptativo del tamaño de los archivos, la creación automática de clústeres, la recogida de elementos no utilizados y la optimización de metadatos. Estas operaciones de optimización usan slots de pago por uso de la edición Enterprise y no utilizan reservas de BACKGROUND.

Las operaciones de exportación de datos que se realicen durante la transmisión a través de la API Storage Write de BigQuery se incluyen en los precios de la API Storage Write y no se cobran como mantenimiento en segundo plano. Para obtener más información, consulta los precios de ingestión de datos.

La optimización del almacenamiento y el uso de EXPORT TABLE METADATA se muestran en la vista INFORMATION_SCHEMA.JOBS.

Consultas y tareas

Al igual que con las tablas de BigQuery, se te cobra por las consultas y los bytes leídos (por TiB) si usas los precios bajo demanda de BigQuery, o por el consumo de ranuras (por hora de ranura) si usas los precios de computación de capacidad de BigQuery.

Los precios de BigQuery también se aplican a la API Storage Read de BigQuery y a la API Storage Write de BigQuery.

Las operaciones de carga y exportación (como EXPORT METADATA) usan espacios de pago por uso de la edición Enterprise. Esto es diferente de las tablas de BigQuery, que no se cobran por estas operaciones. Si hay reservas PIPELINE con espacios de Enterprise o Enterprise Plus disponibles, las operaciones de carga y exportación usarán preferentemente estos espacios de reserva.

Limitaciones

Las tablas Iceberg de BigLake en BigQuery tienen las siguientes limitaciones:

• Las tablas de Iceberg de BigLake en BigQuery no admiten operaciones de cambio de nombre ni instrucciones ALTER TABLE RENAME TO.
• Las tablas de Iceberg de BigLake en BigQuery no admiten copias de tablas ni instrucciones CREATE TABLE COPY.
• Las tablas Iceberg de BigLake en BigQuery no admiten clones de tablas ni instrucciones CREATE TABLE CLONE.
• Las tablas de Iceberg de BigLake en BigQuery no admiten instantáneas de tablas ni instrucciones CREATE SNAPSHOT TABLE.
• Las tablas de Iceberg de BigLake en BigQuery no admiten el siguiente esquema de tabla:
  • Esquema vacío
  • Esquema con tipos de datos BIGNUMERIC, INTERVAL, JSON, RANGE o GEOGRAPHY.
  • Esquema con ordenaciones de campos.
  • Esquema con expresiones de valor predeterminado.
• Las tablas de Iceberg de BigLake en BigQuery no admiten los siguientes casos de evolución de esquemas:
  • Coerciones de tipo de NUMERIC a FLOAT
  • Coerciones de tipo de INT a FLOAT
  • Añadir campos anidados a columnas RECORD mediante instrucciones DDL de SQL
• Las tablas de Iceberg de BigLake en BigQuery muestran un tamaño de almacenamiento de 0 bytes cuando se consultan mediante la consola o las APIs.
• Las tablas de Iceberg de BigLake en BigQuery no admiten vistas materializadas.
• Las tablas Iceberg de BigLake en BigQuery no admiten vistas autorizadas, pero sí control de acceso a nivel de columna.
• Las tablas de Iceberg de BigLake en BigQuery no admiten actualizaciones de captura de datos de cambios (CDC).
• Las tablas de Iceberg de BigLake en BigQuery no admiten la recuperación tras fallos gestionada.
• Las tablas de Iceberg de BigLake en BigQuery no admiten particiones. Puedes usar el clustering como alternativa.
• Las tablas de Iceberg de BigLake en BigQuery no admiten la seguridad a nivel de fila.
• Las tablas de Iceberg de BigLake en BigQuery no admiten ventanas de seguridad.
• Las tablas de Iceberg de BigLake en BigQuery no admiten trabajos de extracción.
• La vista INFORMATION_SCHEMA.TABLE_STORAGE no incluye tablas de Iceberg de BigLake en BigQuery.
• Las tablas de Iceberg de BigLake en BigQuery no se admiten como destinos de resultados de consultas. En su lugar, puedes usar la instrucción CREATE TABLE con el argumento AS query_statement para crear una tabla como destino del resultado de la consulta.
• CREATE OR REPLACE no admite la sustitución de tablas estándar por tablas de Iceberg de BigLake en BigQuery, ni de tablas de Iceberg de BigLake en BigQuery por tablas estándar.
• Las cargas por lotes y las instrucciones LOAD DATA solo permiten añadir datos a las tablas de Iceberg de BigLake que ya existen en BigQuery.
• Las cargas por lotes y las instrucciones LOAD DATA no admiten actualizaciones de esquemas.
• TRUNCATE TABLE no admite tablas de Iceberg de BigLake en BigQuery. Tienes dos alternativas:
  • CREATE OR REPLACE TABLE, con las mismas opciones de creación de tablas.
  • DELETE FROM table WHERE true
• La función con valores de tabla (TVF) APPENDS no admite tablas de Iceberg de BigLake en BigQuery.
• Es posible que los metadatos de Iceberg no contengan datos que se hayan transmitido a BigQuery mediante la API Storage Write en los últimos 90 minutos.
• El acceso paginado basado en registros mediante tabledata.list no es compatible con las tablas de Iceberg de BigLake en BigQuery.
• Las tablas de Iceberg de BigLake en BigQuery no admiten conjuntos de datos vinculados.
• Solo se puede ejecutar una instrucción DML de mutación simultánea (UPDATE, DELETE y MERGE) por cada tabla Iceberg de BigLake en BigQuery. Se han puesto en cola instrucciones DML de mutación adicionales.