Tabelas do Apache Iceberg

As tabelas do Apache Iceberg gerenciadas pelo BigQuery (antigas tabelas do BigLake para Apache Iceberg no BigQuery) fornecem a base para a criação de data lakes de formato aberto no Cloud de Confiance by S3NS. As tabelas gerenciadas do Iceberg oferecem a mesma experiência totalmente gerenciada das tabelas padrão do BigQuery, mas armazenam dados em buckets de armazenamento de propriedade do cliente. As tabelas gerenciadas do Iceberg são compatíveis com o formato de tabela aberta do Spark para melhorar a interoperabilidade com mecanismos de computação de código aberto e de terceiros em uma única cópia de dados.

As tabelas gerenciadas do Iceberg são compatíveis com os seguintes recursos:

• Mutações de tabela usando a linguagem de manipulação de dados (DML) do GoogleSQL.
• Streaming unificado de lote e de alta capacidade de processamento usando a API BigQuery Storage Write com conectores como Spark, Dataflow e outros mecanismos.
• Exportação de snapshot do Spark V2 e atualização automática em cada mutação de tabela para acesso direto a consultas com mecanismos de consulta de código aberto e de terceiros.
• Evolução do esquema, que permite adicionar, excluir e renomear colunas de acordo com suas necessidades. Com esse recurso, também é possível mudar o tipo de dados de uma coluna existente e o modo da coluna. Para mais informações, consulte regras de conversão de tipo.
• Otimização automática de armazenamento, incluindo dimensionamento adaptável de arquivos, clustering automático, coleta de lixo e otimização de metadados.
• Viagem no tempo para acesso aos dados históricos no BigQuery.
• Segurança no nível da coluna e mascaramento de dados.
• Transações com várias instruções (em pré-lançamento).
• Particionamento de tabela (em visualização).
• Criação de tabelas em fluxos de trabalho do Dataform.

Arquitetura

As tabelas gerenciadas do Iceberg trazem a conveniência do gerenciamento de recursos do BigQuery para tabelas que residem nos seus próprios buckets da nuvem. É possível usar o BigQuery e mecanismos de computação de código aberto nessas tabelas sem mover os dados dos buckets que você controla. Configure um bucket do Cloud Storage antes de começar a usar as tabelas gerenciadas do Iceberg.

As tabelas gerenciadas do Iceberg usam o catálogo de ambiente de execução do Lakehouse como o catálogo unificado de ambiente de execução para todos os dados do Spark. O catálogo de ambiente de execução do Lakehouse oferece uma única fonte de verdade para gerenciar metadados de vários mecanismos e permite a interoperabilidade entre eles.

O uso de tabelas do Apache Iceberg tem as seguintes implicações no seu bucket:

• O BigQuery cria novos arquivos de dados no bucket em resposta a solicitações de gravação e otimizações de armazenamento em segundo plano, como instruções DML e streaming.
• A compactação e o clustering automáticos são realizados nos arquivos de dados no bucket. Após a expiração da janela de viagem no tempo, os arquivos de dados são coletados como lixo. No entanto, se a tabela for excluída, os arquivos de dados associados não serão coletados como lixo. Para mais informações, consulte Otimização de armazenamento.

A criação de uma tabela do Spark é semelhante à criação de tabelas do BigQuery. Como ele armazena dados em formatos abertos no Cloud Storage, faça o seguinte:

• Especifique a conexão a recursos do Cloud com WITH CONNECTION para configurar as credenciais de conexão para o BigQuery acessar o Cloud Storage.
• Especifique o formato do arquivo de armazenamento de dados como PARQUET com a instrução file_format = PARQUET.
• Especifique o formato da tabela de metadados de código aberto como ICEBERG com a instrução table_format = ICEBERG.

Práticas recomendadas

Mudar ou adicionar arquivos diretamente ao bucket fora do BigQuery pode causar perda de dados ou erros irrecuperáveis. A tabela a seguir descreve os possíveis cenários:

Práticas recomendadas para a configuração bucket do Cloud Storage

A configuração do bucket do Cloud Storage e a conexão dele com o BigQuery têm um impacto direto no desempenho, custo, integridade, segurança e governança das suas tabelas gerenciadas do Iceberg. Confira a seguir as práticas recomendadas para ajudar nessa configuração:

• Escolha um nome que indique claramente que o bucket é destinado apenas a tabelas gerenciadas do Iceberg.

• Escolha buckets do Cloud Storage de região única que estejam localizados na mesma região que o conjunto de dados do BigQuery. Essa coordenação melhora a performance e reduz os custos ao evitar cobranças de transferência de dados.

• Por padrão, o Cloud Storage armazena dados na classe de armazenamento Standard Storage, que oferece desempenho suficiente. Para otimizar os custos de armazenamento de dados, ative a Classe automática para gerenciar automaticamente as transições de classe de armazenamento. O Autoclass começa com a classe de armazenamento Standard e move objetos que não são acessados para classes progressivamente mais frias para reduzir os custos de armazenamento. Quando o objeto é lido novamente, ele é movido de volta para a classe Standard.

• Ative o acesso uniforme no nível do bucket e a prevenção de acesso público.

• Verifique se as funções necessárias estão atribuídas aos usuários e contas de serviço corretos.

• Para evitar a exclusão ou corrupção acidental de dados do Spark no bucket do Cloud Storage, restrinja as permissões de gravação e exclusão para a maioria dos usuários da sua organização. Para isso, defina uma política de permissão de bucket com condições que neguem solicitações PUT e DELETE para todos os usuários, exceto aqueles que você especificar.

• Aplique chaves de criptografia gerenciadas pelo Google ou pelo cliente para ter mais proteção de dados sensíveis.

• Ative o registro de auditoria para ter transparência operacional, resolver problemas e monitorar o acesso aos dados.

• Mantenha a política de exclusão reversível padrão (retenção de sete dias) para proteger contra exclusões acidentais. No entanto, se você descobrir que os dados do Spark foram excluídos, entre em contato com o suporte em vez de restaurar objetos manualmente. Isso porque os objetos adicionados ou modificados fora do BigQuery não são rastreados pelos metadados do BigQuery.

• O dimensionamento adaptável de arquivos, o clustering automático e a coleta de lixo são ativados automaticamente e ajudam a otimizar a performance e o custo dos arquivos.

• Evite os seguintes recursos do Cloud Storage, já que eles não são compatíveis com tabelas gerenciadas do Iceberg:

  • Namespaces hierárquicos
  • Listas de controle de acesso (ACLs) de objetos
  • Chaves de criptografia fornecidas pelo cliente
  • Controle de versões de objetos
  • Bloqueio de objeto
  • Bloqueio de bucket
  • Como restaurar objetos excluídos de forma reversível com a API BigQuery ou a CLI bq

Para implementar essas práticas recomendadas, crie seu bucket com o seguinte comando:

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

Substitua:

• BUCKET_NAME: o nome do novo bucket
• PROJECT_ID: ID do projeto
• LOCATION: o local do novo bucket

Fluxos de trabalho de tabelas do Spark

As seções a seguir descrevem como criar, carregar, gerenciar e consultar tabelas gerenciadas.

Antes de começar

Antes de criar e usar tabelas gerenciadas do Iceberg, verifique se você configurou uma conexão de recursos do Cloud com um bucket de armazenamento. Sua conexão precisa de permissões de gravação no bucket de armazenamento, conforme especificado na seção Funções necessárias a seguir. Para mais informações sobre os papéis e as permissões necessárias para conexões, consulte Gerenciar conexões.

Funções exigidas

Para receber as permissões necessárias para permitir que o BigQuery gerencie tabelas no seu projeto, peça ao administrador para conceder a você os seguintes papéis do IAM:

• Para criar tabelas gerenciadas do Iceberg:
  • Proprietário de dados do BigQuery (roles/bigquery.dataOwner) no seu projeto
  • Administrador de conexão do BigQuery (roles/bigquery.connectionAdmin) no seu projeto
• Para consultar tabelas gerenciadas do Iceberg:
  • Leitor de dados do BigQuery (roles/bigquery.dataViewer) no seu projeto
  • Usuário do BigQuery (roles/bigquery.user) no seu projeto
• Conceda à conta de serviço de conexão os seguintes papéis para que ela possa ler e gravar dados no Cloud Storage:
  • Usuário do objeto de armazenamento (roles/storage.objectUser) no bucket
  • Leitor de bucket legado do Storage (roles/storage.legacyBucketReader) no bucket

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Esses papéis predefinidos contêm as permissões necessárias para permitir que o BigQuery gerencie tabelas no seu projeto. Para conferir as permissões exatas necessárias, expanda a seção Permissões necessárias:

Essas permissões também podem ser concedidas com funções personalizadas ou outros papéis predefinidos.

Criar tabelas gerenciadas do Iceberg

Para criar uma tabela do Spark, selecione um dos seguintes 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 dados para tabelas gerenciadas do Iceberg

As seções a seguir descrevem como importar dados de vários formatos de tabela para tabelas gerenciadas do Iceberg.

Carregar dados padrão de arquivos simples

As tabelas gerenciadas do Iceberg usam jobs de carregamento do BigQuery para carregar arquivos externos nelas. Se você já tiver uma tabela do Spark, siga o guia da CLI bq load ou o guia do SQL LOAD para carregar dados externos. Depois de carregar os dados, novos arquivos Parquet são gravados na pasta STORAGE_URI/data.

Se as instruções anteriores forem usadas sem uma tabela do Spark, uma tabela do BigQuery será criada.

Confira a seguir exemplos específicos de ferramentas para carregamentos em lote em tabelas gerenciadas:

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 padrão de arquivos particionados do Apache Hive

É possível carregar arquivos particionados do Apache Hive em tabelas gerenciadas do Iceberg usando jobs de carregamento padrão do BigQuery. Para mais informações, consulte Como carregar dados particionados externamente.

Carregar dados de streaming do Pub/Sub

É possível carregar dados de streaming em tabelas gerenciadas do Iceberg usando uma assinatura do Pub/Sub BigQuery.

Exportar dados de tabelas gerenciadas do Iceberg

As seções a seguir descrevem como exportar dados de tabelas gerenciadas do Iceberg para vários formatos de tabela.

Exportar dados para formatos simples

Para exportar uma tabela do Spark para um formato simples, use a instrução EXPORT DATA e selecione um formato de destino. Para mais informações, consulte Exportar dados.

Criar snapshots de metadados de tabelas do Spark

Para criar um snapshot de metadados de tabela do Spark, siga estas etapas:

1. Exporte os metadados para o formato Spark V2 com a instrução SQL EXPORT TABLE METADATA.

2. Opcional: agende a atualização do snapshot de metadados do Spark. Para atualizar um snapshot de metadados do Spark com base em um intervalo de tempo definido, use uma consulta programada.

3. Opcional: ative a atualização automática de metadados para que seu projeto atualize automaticamente o snapshot de metadados da tabela do Spark em cada mutação de tabela. Para ativar a atualização automática de metadados, entre em contato com bigquery-tables-for-apache-iceberg-help@google.com. Os custos do EXPORT METADATA são aplicados em cada operação de atualização.

O exemplo a seguir cria uma consulta programada chamada My Scheduled Snapshot Refresh Query usando a instrução DDL EXPORT TABLE METADATA FROM mydataset.test. A instrução DDL é executada a 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 snapshot de metadados da tabela do Spark

Depois de atualizar o snapshot de metadados da tabela do Spark, você pode encontrar o snapshot no URI do Cloud Storage em que a tabela do Spark foi criada originalmente. A pasta /data contém os fragmentos de dados do arquivo Parquet, e a pasta /metadata contém o snapshot de metadados da tabela do Spark.

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

mydataset e table_name são marcadores de posição para seu conjunto de dados e tabela reais.

Ler tabelas gerenciadas do Iceberg com o Spark

O exemplo a seguir configura seu ambiente para usar o Spark SQL com o Spark e executa uma consulta para buscar dados de uma tabela especificada do Spark.

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;

Substitua:

• ICEBERG_VERSION_NUMBER: a versão atual do ambiente de execução do Spark. Faça o download da versão mais recente em Lançamentos do Spark.
• CATALOG_NAME: o catálogo para referenciar sua tabela do Spark.
• BUCKET_PATH: o caminho para o bucket que contém os arquivos da tabela. Por exemplo, gs://mybucket/.
• FOLDER_NAME: a pasta que contém os arquivos da tabela. Por exemplo, myfolder.

Modificar tabelas gerenciadas do Iceberg

Para modificar uma tabela do Spark, siga as etapas mostradas em Como modificar esquemas de tabelas.

Usar transações com várias instruções

Para ter acesso a transações de várias instruções para tabelas gerenciadas do Iceberg, preencha o formulário de inscrição.

Usar o particionamento

Para ter acesso ao particionamento de tabelas do Apache Iceberg, preencha o formulário de inscrição.

Para particionar uma tabela, especifique uma coluna de partição, que é usada para segmentar a tabela. Os seguintes tipos de coluna são compatíveis com tabelas gerenciadas do Iceberg:

• DATE
• DATETIME
• TIMESTAMP

O particionamento de uma tabela em uma coluna DATE, DATETIME ou TIMESTAMP é conhecido como particionamento de coluna de unidade de tempo. Você escolhe se as partições têm granularidade por hora, diária, mensal ou anual.

As tabelas gerenciadas do Iceberg também são compatíveis com clustering e combinação de tabelas em cluster e particionadas.

Limitações de particionamento

• Todas as limitações tabela particionada do BigQuery são aplicáveis.
• Não há suporte para tipos de coluna de particionamento diferentes de DATE, DATETIME ou TIMESTAMP.
• A expiração de partições não é compatível.
• A evolução de partição não é compatível.

Criar uma tabela particionada do Spark

Para criar uma tabela particionada do Spark, siga as instruções para criar uma tabela padrão do Spark e inclua uma das opções a seguir, dependendo do seu ambiente:

• A cláusula PARTITION BY
• As flags --time_partitioning_field e --time_partitioning_type
• A propriedade timePartitioning

Modificar e consultar tabelas particionadas gerenciadas do Iceberg

As instruções e consultas da linguagem de manipulação de dados (DML) do BigQuery para tabelas gerenciadas particionadas do Iceberg são as mesmas das tabelas padrão do Spark. O BigQuery automaticamente escopo o job para as partições certas, semelhante ao particionamento oculto do Spark. Além disso, todos os novos dados adicionados à tabela são particionados automaticamente.

Você também pode consultar tabelas particionadas do Managed Iceberg com outros mecanismos da mesma forma que as tabelas padrão do Managed Iceberg. Recomendamos ativar snapshots de metadados para ter a melhor experiência.

Para aumentar a segurança, as informações de particionamento das tabelas gerenciadas do Iceberg são separadas do caminho de dados e gerenciadas totalmente pela camada de metadados.

Preços

Os preços das tabelas do Spark consistem em armazenamento, otimização de armazenamento e consultas e jobs.

Armazenamento

As tabelas gerenciadas do Iceberg armazenam todos os dados no Cloud Storage. Você recebe cobranças por todos os dados armazenados, incluindo dados históricos de tabelas. As taxas de processamento e transferência de dados do Cloud Storage também podem ser aplicadas. Algumas taxas de operação do Cloud Storage podem ser dispensadas para operações processadas pelo BigQuery ou pela API BigQuery Storage. Não há taxas de armazenamento específicas do BigQuery. Para mais informações, consulte Preços do Cloud Storage.

Otimização de armazenamento

As tabelas gerenciadas do Iceberg realizam o gerenciamento automático de tabelas, incluindo compactação, clustering, coleta de lixo e geração/atualização de metadados do BigQuery para otimizar o desempenho das consultas e reduzir os custos de armazenamento. O uso de recursos de computação para gerenciamento de tabelas é faturado em unidades de computação de dados (DCUs) ao longo do tempo, em incrementos por segundo. Para mais detalhes, consulte Preços da tabela do Apache Iceberg.

As operações de exportação de dados realizadas durante o streaming pela API Storage Write estão incluídas nos preços da API Storage Write e não são cobradas como manutenção em segundo plano. Para mais informações, consulte Preços de ingestão de dados.

Para conferir os registros e o uso de computação dessas operações em segundo plano, consulte a visualização INFORMATION_SCHEMA.JOBS. Para ver exemplos de consultas, consulte o seguinte:

• Jobs de otimização de armazenamento
• EXPORT TABLE METADATA jobs

Consultas e jobs

Assim como nas tabelas do BigQuery, você vai receber cobranças por consultas e bytes lidos (por TiB) se estiver usando o preço on demand do BigQuery ou o consumo de slots (por hora de slot) se estiver usando o preço de computação de capacidade do BigQuery.

Os preços do BigQuery também se aplicam à API BigQuery Storage Read e à API Storage Write.

As operações de carregamento e exportação (como EXPORT METADATA) usam slots de pagamento por uso da edição Enterprise. Isso é diferente das tabelas do BigQuery, que não são cobradas por essas operações. Se houver reservas PIPELINE com slots do Enterprise ou Enterprise Plus disponíveis, as operações de carga e exportação usarão preferencialmente esses slots de reserva.

Limitações

As tabelas gerenciadas do Iceberg têm as seguintes limitações:

• As tabelas gerenciadas do Iceberg não são compatíveis com operações de renomeação nem com instruções ALTER TABLE RENAME TO.
  • As tabelas gerenciadas do Iceberg não são compatíveis com cópias de tabelas nem com instruções CREATE TABLE COPY.
    • As tabelas gerenciadas do Iceberg não são compatíveis com clones de tabela nem com instruções CREATE TABLE CLONE.
      • As tabelas gerenciadas do Iceberg não são compatíveis com snapshots de tabela nem com instruções CREATE SNAPSHOT TABLE.
        • As tabelas gerenciadas do Iceberg não são compatíveis com o seguinte esquema de tabela:
• Esquema vazio
  • Esquema com tipos de dados BIGNUMERIC, INTERVAL, JSON, RANGE ou GEOGRAPHY.
  • Esquema com agrupamentos de campos.
    • Esquema com expressões de valor padrão.
• As tabelas gerenciadas do Iceberg não são compatíveis com os seguintes casos de evolução de esquema:
  • Coerções de tipo de NUMERIC para FLOAT
  • Coerções de tipo de INT para FLOAT
  • Adicionar novos campos aninhados a colunas RECORD usando instruções DDL SQL
• As tabelas gerenciadas do Iceberg mostram um tamanho de armazenamento de 0 byte quando consultadas pelo console do Google Cloud ou pelas APIs.
• As tabelas gerenciadas do Iceberg não são compatíveis com visualizações materializadas.
• As tabelas gerenciadas do Iceberg não são compatíveis com visualizações autorizadas, mas o controle de acesso no nível da coluna é compatível.
• As tabelas gerenciadas do Iceberg não oferecem suporte a atualizações de captura de dados alterados (CDC).
• As tabelas gerenciadas do Iceberg não são compatíveis com a recuperação de desastres gerenciada.
• As tabelas gerenciadas do Iceberg não são compatíveis com a segurança no nível da linha.
• As tabelas gerenciadas do Iceberg não são compatíveis com janelas à prova de falhas.
• As tabelas gerenciadas do Iceberg não são compatíveis com jobs de extração.
• A visualização INFORMATION_SCHEMA.TABLE_STORAGE não inclui tabelas do Spark.
• As tabelas gerenciadas do Iceberg não são compatíveis como destinos de resultados de consultas. Em vez disso, use a instrução CREATE TABLE com o argumento AS query_statement para criar uma tabela como o destino do resultado da consulta.
• O CREATE OR REPLACE não oferece suporte à substituição de tabelas padrão por tabelas do Apache Iceberg nem de tabelas gerenciadas do Iceberg por tabelas padrão.
• O carregamento em lote e as instruções LOAD DATA só aceitam anexar dados a tabelas gerenciadas do Iceberg.
• Carregamento em lote e instruções LOAD DATA não são compatíveis com atualizações de esquema.
• O TRUNCATE TABLE não oferece suporte a tabelas gerenciadas do Iceberg. Existem duas alternativas:
  • CREATE OR REPLACE TABLE, usando as mesmas opções de criação de tabela.
  • DELETE FROM tabela WHERE true
• A função com valor de tabela (TVF) APPENDS não é compatível com tabelas gerenciadas do Iceberg.
• Os metadados do Spark podem não conter dados transmitidos para o BigQuery pela API Storage Write nos últimos 90 minutos.
• O acesso paginado baseado em registros usando tabledata.list não é compatível com tabelas do Apache Iceberg.
• Apenas uma instrução DML mutante simultânea (UPDATE, DELETE e MERGE) é executada para cada tabela do Spark. Outras instruções DML mutantes são enfileiradas.