Introdução às tabelas de objetos

Este documento descreve as tabelas de objetos, que são tabelas de leitura apenas sobre objetos de dados não estruturados que residem no Cloud Storage.

As tabelas de objetos permitem-lhe analisar dados não estruturados no Cloud Storage. Pode realizar análises com funções remotas ou realizar inferências através do BigQuery ML e, em seguida, juntar os resultados destas operações com o resto dos seus dados estruturados no BigQuery.

Tal como as tabelas do BigLake, as tabelas de objetos usam a delegação de acesso, o que desvincula o acesso à tabela de objetos do acesso aos objetos do Cloud Storage. Uma associação externa associada a uma conta de serviço é usada para estabelecer ligação ao Cloud Storage, pelo que só tem de conceder aos utilizadores acesso à tabela de objetos. Isto permite-lhe aplicar a segurança ao nível da linha e gerir a que objetos os utilizadores têm acesso.

Esquema da tabela de objetos

Uma tabela de objetos fornece um índice de metadados sobre os objetos de dados não estruturados num contentor do Cloud Storage especificado. Cada linha da tabela corresponde a um objeto e as colunas da tabela correspondem aos metadados do objeto gerados pelo Cloud Storage, incluindo quaisquer metadados personalizados.

Uma tabela de objetos também contém uma pseudocoluna data que representa o conteúdo do ficheiro em bytes não processados, que é preenchida automaticamente quando a tabela de objetos é criada. Esta pseudocoluna é usada pela função ML.DECODE_IMAGE quando executa a inferência em dados de imagens. Não pode incluir a pseudocoluna data em consultas e esta não aparece como parte do esquema da tabela de objetos.

A tabela seguinte descreve o esquema fixo usado pelas tabelas de objetos:

Nome do campo Tipo Modo Descrição
uri STRING NULLABLE uri: o identificador uniforme de recursos (URI) do objeto, no formato gs://bucket_name/[folder_name/]object_name.
generation INTEGER NULLABLE A geração deste objeto, que identifica a versão do objeto.
content_type STRING NULLABLE O Content-Type dos dados do objeto, que identifica o tipo de suporte. Se um objeto for armazenado sem um Content-Type, é publicado como application/octet-stream.
size INTEGER NULLABLE O Content-Length dos dados em bytes.
md5_hash STRING NULLABLE O hash MD5 dos dados, codificado através de base64. Para mais informações sobre a utilização do hash MD5, consulte o artigo Metadados de objetos do Cloud Storage.
updated TIMESTAMP NULLABLE A última vez que os metadados do objeto foram modificados.
metadata RECORD REPETIDO Metadados personalizados para o objeto. Cada parte dos metadados é representada como um par de chave-valor nos campos (metadata.)name e (metadata.)value do campo metadata.
(metadata.)name STRING NULLABLE Introduzir uma entrada de metadados individual.
(metadata.)value STRING NULLABLE Valor numa entrada de metadados individual.
ref STRUCT NULLABLE Metadados do Cloud Storage geridos pela Google armazenados no formato ObjectRef.
(Pré-visualização)

Pode usar esta coluna para manter os valores ObjectRef em tabelas padrão. Os valores ObjectRef permitem-lhe integrar dados de objetos com dados estruturados. Esta coluna só é criada se estiver na lista de autorizações para a pré-visualização de dados multimodais.

As linhas numa tabela de objetos têm um aspeto semelhante ao seguinte:

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|  uri                 | generation | content_type | size  | md5_hash   | updated                        | metadata...name | metadata...value  | ref.uri              | ref.version | ref.authorizer | ref.details                                              |
—----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| gs://mybucket/a.jpeg | 165842…    | image/jpeg   | 26797 | 8c33be10f… | 2022-07-21 17:35:40.148000 UTC | null            | null              | gs://mybucket/a.jpeg | 12345678    | us.conn        | {"gcs_metadata":{"content_type":"image/jpeg","md5_hash"… |
—----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| gs://mybucket/b.bmp  | 305722…    | image/bmp    | 57932 | 44eb90cd1… | 2022-05-14 12:09:38.114000 UTC | null            | null              | gs://mybucket/b.bmp  | 23456789    | us.conn        | {"gcs_metadata":{"content_type":"image/bmp","md5_hash"…  |
—----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Exemplos de utilização

Pode consultar os metadados numa tabela de objetos da mesma forma que consultaria qualquer outra tabela do BigQuery. No entanto, o exemplo de utilização principal das tabelas de objetos é tornar os dados não estruturados acessíveis para análise. Pode usar o BigQuery ML para executar a inferência em tabelas de objetos de imagens com modelos do TensorFlow, TensorFlow Lite e PyTorch. Também pode usar funções remotas para analisar dados não estruturados da forma que quiser. Por exemplo, pode criar uma função remota que lhe permita analisar imagens através do Cloud Vision ou uma que lhe permita extrair metadados de documentos PDF através do Apache Tika.

A tabela seguinte descreve os pontos de integração que pode usar para fazer aprendizagem automática nos dados da tabela de objetos:

Integração Descrição Exemplo de utilização Tutorial
A função ML.GENERATE_TEXT Gere texto através de um modelo aberto, de um parceiro ou da Vertex AI. Quer gerar texto a partir de dados de objetos. Gere texto com a função ML.GENERATE_TEXT
A função ML.GENERATE_EMBEDDING Gere incorporações através de um modelo multimodal do Vertex AI. Quer gerar incorporações para dados de vídeo ou imagem para usar em pesquisas vetoriais, entrada de modelos ou outros exemplos de utilização. Gere incorporações de imagens com a função ML.GENERATE_EMBEDDING

Gere incorporações de vídeos com a função ML.GENERATE_EMBEDDING
Modelos do BigQuery ML importados Importe modelos do TensorFlow, TensorFlow Lite ou ONNX para o BigQuery ML para executar a inferência local no BigQuery . Está a usar modelos de código aberto ou personalizados que se enquadram nas limitações suportadas. Tutorial: execute a inferência numa tabela de objetos através de um modelo de vetor de caraterísticas
Funções do Cloud Run Use funções do Cloud Run para chamar serviços ou modelos alojados. Esta é a integração mais genérica. Está a alojar os seus modelos no Compute Engine, no Google Kubernetes Engine ou noutra infraestrutura pertencente ao cliente.
A função ML.ANNOTATE_IMAGE Use a Cloud Vision API para anotar imagens. Quer anotar imagens através de um modelo pré-preparado da API Vision. Anotar imagens com a função ML.ANNOTATE_IMAGE
A função ML.PROCESS_DOCUMENT Use a API Document AI para extrair estatísticas de documentos. Quer usar processadores de documentos personalizados ou pré-preparados da Document AI. Processe documentos com a função ML.PROCESS_DOCUMENT
A função ML.TRANSCRIBE Use a API Speech-to-Text para transcrever ficheiros de áudio. Quer usar reconhecedores de voz pré-preparados ou personalizados de conversão de voz em texto. Transcreva ficheiros de áudio com a função ML.TRANSCRIBE

Pode criar uma vista ou uma tabela a partir dos resultados da sua análise se quiser juntar os resultados a outros dados estruturados. Por exemplo, a seguinte declaração cria uma tabela com base nos resultados da inferência:

CREATE TABLE my_dataset.my_inference_results AS
SELECT uri, content_type, vision_feature
FROM ML.PREDICT(
  MODEL my_dataset.vision_model,
  SELECT ML.DECODE_IMAGE(data) AS vision_input
  FROM my_dataset.object_table
);

Depois de criar a tabela, pode associá-la a outras tabelas com base em campos de metadados padrão ou personalizados, conforme mostrado abaixo:

SELECT a.vision_feature, a.uri, b.description
FROM my_dataset.my_inference_results a
JOIN my_dataset.image_description b
ON a.uri = b.uri;

Também pode criar um índice de pesquisa para otimizar as pesquisas sobre os resultados da sua análise. Por exemplo, a seguinte declaração cria um índice de pesquisa sobre os dados extraídos de ficheiros PDF:

CREATE SEARCH INDEX my_index ON pdf_text_extract(ALL COLUMNS);

Em seguida, pode usar o índice para encontrar o que precisa nesses resultados:

SELECT * FROM pdf_text_extract WHERE SEARCH(pdf_text, 'Google');

Vantagens

A análise de dados não estruturados de forma nativa no BigQuery oferece as seguintes vantagens:

  • Reduz o esforço manual, permitindo-lhe automatizar passos de pré-processamento, como ajustar os tamanhos das imagens aos requisitos do modelo.
  • Permite-lhe usar a interface SQL familiar para trabalhar com dados não estruturados.
  • Ajuda a poupar custos através da utilização de slots do BigQuery existentes, em vez de ter de aprovisionar novas formas de computação.

URLs assinados

Para aceder aos dados representados por um objeto, gere um URL assinado. Pode usar o URL assinado para ver diretamente os dados do objeto e também transmitir URLs assinados a funções remotas para lhes permitir trabalhar com dados da tabela de objetos.

Use a função EXTERNAL_OBJECT_TRANSFORM para gerar URLs assinados, conforme mostrado no exemplo seguinte:

SELECT uri, signed_url
FROM EXTERNAL_OBJECT_TRANSFORM(TABLE `mydataset.myobjecttable`, ['SIGNED_URL']);

Isto devolve resultados semelhantes aos seguintes:

---------------------------------------------------------------------------------------------------
|  uri                 | signed_url                                                               |
—--------------------------------------------------------------------------------------------------
| gs://mybucket/a.docx | https://storage.googleapis.com/mybucket/a.docx?X-Goog-Signature=abcd&... |
—-------------------------------------------------------------------------------------------------
| gs://mybucket/b.pdf  | https://storage.googleapis.com/mybucket/b.pdf?X-Goog-Signature=wxyz&...  |
—--------------------------------------------------------------------------------------------------

Os URLs assinados gerados a partir de tabelas de objetos permitem que qualquer utilizador ou procedimento que os possua leia os objetos correspondentes. Os URLs assinados gerados expiram após 6 horas. Para mais informações, consulte o artigo URLs assinados do Cloud Storage.

Controlo de acesso

As tabelas de objetos são criadas com base no BigLake, pelo que usam uma ligação externa baseada numa conta de serviço para aceder aos dados do Cloud Storage. Isto desvincula o acesso à tabela do acesso ao armazenamento de objetos subjacente através da delegação de acesso. Concede autorizações à conta de serviço para aceder a dados e metadados dos objetos e apresentá-los na tabela. Concede autorizações aos utilizadores apenas na tabela, onde pode reger o acesso aos dados através da gestão de identidade e de acesso (IAM) e da segurança ao nível da linha.

As tabelas de objetos diferem de outras tabelas que usam a delegação de acesso, uma vez que ter acesso a uma linha de uma tabela de objetos confere acesso ao conteúdo do ficheiro subjacente. Embora um utilizador não possa aceder diretamente ao objeto, pode gerar um URL assinado que lhe permite ver o conteúdo do ficheiro. Por exemplo, se o utilizador tiver acesso à linha da tabela de objetos que representa o ficheiro de imagem, pode gerar um URL assinado para apresentar o ficheiro e ver que se trata de uma imagem de uma margarida.flower.jpg

A definição de uma política de acesso ao nível da linha numa tabela de objetos restringe o acesso de um utilizador ou de um grupo aos metadados de objetos nas linhas selecionadas e também aos objetos representados por essas linhas. Por exemplo, a seguinte declaração concede ao utilizador Alice acesso apenas a linhas que representam objetos criados antes de 25 de junho de 2022:

CREATE ROW ACCESS POLICY before_20220625
ON my_dataset.my_object_table
GRANT TO ("user:alice@example.com")
FILTER USING (updated < TIMESTAMP("2022-06-25"));

Com esta política de acesso ao nível da linha em vigor, os seguintes resultados são verdadeiros para Alice:

  • A execução da consulta SELECT * FROM my_dataset.my_object_table; apenas devolve linhas que têm um valor updated antes de 25 de junho de 2022.
  • A execução da inferência em my_dataset.my_object_table só devolve previsões para objetos que tenham um valor updated antes de 25 de junho de 2022.
  • A geração de URLs assinados para my_dataset.my_object_table só cria URLs para objetos que tenham um valor updated antes de 25 de junho de 2022.

Também pode restringir o acesso às linhas da tabela de objetos através de metadados personalizados. Por exemplo, a seguinte declaração restringe o grupo users a aceder apenas a linhas em que o objeto foi etiquetado como não contendo informações de identificação pessoal:

CREATE ROW ACCESS POLICY no_pii
ON my_dataset.my_object_table
GRANT TO ("group:users@example.com")
FILTER USING (ARRAY_LENGTH(metadata)=1
AND metadata[OFFSET(0)].name="no_pii")

Modelo de segurança

Normalmente, as seguintes funções organizacionais estão envolvidas na gestão e na utilização de tabelas de objetos:

  • Administradores do lago de dados. Normalmente, estes administradores gerem as políticas de gestão de identidade e de acesso (IAM) em contentores e objetos do Cloud Storage.
  • Administradores do armazém de dados. Normalmente, estes administradores criam, eliminam e atualizam tabelas.
  • Analistas de dados. Normalmente, os analistas leem dados e executam consultas.

Os administradores do data lake são responsáveis por criar associações e partilhá-las com os administradores do data warehouse. Por sua vez, os administradores do data warehouse criam tabelas, definem controlos de acesso adequados e partilham as tabelas com os analistas de dados.

Ficheiros de objetos suportados

Pode criar uma tabela de objetos sobre qualquer tipo e tamanho de ficheiro de dados não estruturados, e pode criar funções remotas para trabalhar com qualquer tipo de dados não estruturados. No entanto, para realizar a inferência através do BigQuery ML, uma tabela de objetos só pode ser sobre ficheiros de imagem que cumpram vários requisitos de tamanho e tipo. Para mais informações, consulte a secção Limitações.

Colocação em cache de metadados para desempenho

Pode usar metadados em cache para melhorar o desempenho da inferência e de outros tipos de análise em tabelas de objetos. O armazenamento em cache de metadados é especialmente útil nos casos em que a tabela de objetos faz referência a um grande número de objetos. O BigQuery usa o CMETA como um sistema de metadados distribuído para processar tabelas grandes de forma eficiente. O CMETA fornece metadados detalhados ao nível da coluna e do bloco, acessíveis através de tabelas do sistema. Este sistema ajuda a melhorar o desempenho das consultas otimizando o acesso e o processamento de dados. Para acelerar ainda mais o desempenho das consultas em tabelas grandes, o BigQuery mantém uma cache de metadados. As tarefas de atualização de CMETA mantêm esta cache atualizada.

Os metadados incluem nomes de ficheiros, informações de partição e metadados físicos de ficheiros, como a contagem de linhas. Pode optar por ativar ou não a colocação em cache de metadados numa tabela. As consultas com um grande número de ficheiros e com filtros de partição do Apache Hive beneficiam mais da colocação em cache de metadados.

Se não ativar a colocação em cache de metadados, as consultas na tabela têm de ler a origem de dados externa para obter os metadados de objetos. A leitura destes dados aumenta a latência da consulta. A listagem de milhões de ficheiros da origem de dados externa pode demorar vários minutos. Se ativar a colocação em cache de metadados, as consultas podem evitar a apresentação de ficheiros da origem de dados externa e podem particionar e reduzir ficheiros mais rapidamente.

A colocação em cache de metadados também se integra com o controlo de versões de objetos do Cloud Storage. Quando a cache é preenchida ou atualizada, captura metadados com base na versão em direto dos objetos do Cloud Storage nesse momento. Como resultado, as consultas com a cache de metadados ativada leem os dados correspondentes à versão específica do objeto em cache, mesmo que versões mais recentes fiquem ativas no Cloud Storage. O acesso a dados de quaisquer versões de objetos atualizadas posteriormente no Cloud Storage requer uma atualização da cache de metadados.

Existem duas propriedades que controlam esta funcionalidade:

  • O tempo máximo de desatualização especifica quando as consultas usam metadados em cache.
  • O modo de cache de metadados especifica como os metadados são recolhidos.

Quando tem a colocação em cache de metadados ativada, especifica o intervalo máximo de obsolescência dos metadados que é aceitável para operações na tabela. Por exemplo, se especificar um intervalo de 1 hora, as operações na tabela usam metadados em cache se tiverem sido atualizados na última hora. Se os metadados em cache forem mais antigos, a operação recorre à obtenção de metadados do Cloud Storage. Pode especificar um intervalo de desatualização entre 30 minutos e 7 dias.

Quando ativa o armazenamento em cache de metadados para tabelas de objetos ou do BigLake, o BigQuery aciona tarefas de atualização da geração de metadados. Pode optar por atualizar a cache de forma automática ou manual:

  • Para as atualizações automáticas, a cache é atualizada a um intervalo definido pelo sistema, normalmente entre 30 e 60 minutos. A atualização automática da cache é uma boa abordagem se os ficheiros no armazenamento na nuvem forem adicionados, eliminados ou modificados em intervalos aleatórios. Se precisar de controlar a sincronização da atualização, por exemplo, para acionar a atualização no final de uma tarefa de extração, transformação e carregamento, use a atualização manual.

  • Para atualizações manuais, executa o procedimento do sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE para atualizar a cache de metadados de acordo com uma programação que cumpra os seus requisitos. A atualização manual da cache é uma boa abordagem se os ficheiros no Cloud Storage forem adicionados, eliminados ou modificados a intervalos conhecidos, por exemplo, como resultado de um pipeline.

    Se emitir várias atualizações manuais em simultâneo, apenas uma é bem-sucedida.

A cache de metadados expira após 7 dias se não for atualizada.

As atualizações manuais e automáticas da cache são executadas com a prioridade de consulta INTERACTIVE.

Use reservas do BACKGROUND

Se optar por usar atualizações automáticas, recomendamos que crie uma reserva e, em seguida, crie uma atribuição com um BACKGROUNDtipo de tarefa para o projeto que executa as tarefas de atualização da cache de metadados. Com as reservas BACKGROUND, as tarefas de atualização usam um conjunto de recursos dedicado que impede que as tarefas de atualização concorram com as consultas dos utilizadores e impede que as tarefas falhem potencialmente se não houver recursos suficientes disponíveis para as mesmas.

Embora a utilização de um conjunto de intervalos partilhado não incorra em custos adicionais, a utilização de reservas BACKGROUND oferece um desempenho mais consistente através da atribuição de um conjunto de recursos dedicado e melhora a fiabilidade das tarefas de atualização e a eficiência geral das consultas no BigQuery.

Deve considerar a forma como os valores do intervalo de desatualização e do modo de colocação em cache de metadados interagem antes de os definir. Considere os seguintes exemplos:

  • Se estiver a atualizar manualmente a cache de metadados de uma tabela e definir o intervalo de desatualização para 2 dias, tem de executar o procedimento do sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE a cada 2 dias ou menos se quiser que as operações na tabela usem metadados em cache.
  • Se estiver a atualizar automaticamente a cache de metadados de uma tabela e definir o intervalo de desatualização como 30 minutos, é possível que algumas das suas operações na tabela possam ler a partir do Cloud Storage se a atualização da cache de metadados demorar mais do que a janela habitual de 30 a 60 minutos.

Para encontrar informações sobre tarefas de atualização de metadados, consulte a vista INFORMATION_SCHEMA.JOBS, conforme mostrado no exemplo seguinte:

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;

Para saber mais, consulte o artigo Colocação em cache de metadados.

Para mais informações sobre como definir opções de colocação em cache de metadados, consulte o artigo Crie tabelas de objetos.

Limitações

  • As tabelas de objetos são só de leitura, porque são mapeadas para objetos de dados não estruturados no Cloud Storage. Não pode alterar uma tabela de objetos nem modificar os dados da tabela de objetos.
  • O suporte de tabelas de objetos não está disponível no SQL antigo nem noutros ambientes de nuvem, como os serviços Web da Amazon (AWS) e o Microsoft Azure.
  • Se quiser realizar a inferência através do BigQuery ML, o modelo e a tabela de objetos que usa têm de cumprir os requisitos descritos nas Limitações.
  • As consultas que incluem tabelas de objetos não podem aceder a mais de 10 GB de metadados de objetos. Por exemplo, se uma consulta aceder a 100 TB a partir de uma combinação de colunas de metadados em tabelas de objetos e dados de objetos através de URLs assinados, apenas 10 GB desses 100 TB podem ser das colunas de metadados.
  • As tabelas de objetos estão sujeitas às mesmas limitações que todas as outras tabelas externas do BigQuery. Para mais informações, consulte a secção Quotas.
  • As consultas em tabelas de objetos estão sujeitas às mesmas limitações que todas as outras consultas do BigQuery. Para mais informações, consulte a secção Quotas.
  • As funções remotas que processam dados não estruturados de tabelas de objetos estão sujeitas às mesmas limitações que todas as outras funções remotas.
  • Os URLs assinados gerados para os objetos numa tabela de objetos expiram após 6 horas, que é o limite de tempo de execução da consulta.
  • A inferência com o BigQuery ML não é suportada com os preços a pedido nem com a edição Standard.

  • As seguintes funções não são suportadas com os preços a pedido nem com a edição Standard:

  • As tabelas de objetos têm um máximo de 60 milhões de linhas. Para participar num lançamento de pré-visualização que aumenta o número máximo de linhas para 300 milhões, preencha este formulário de solicitação.

Custos

Os custos estão associados aos seguintes aspetos das tabelas de objetos:

Se tiver reservas de slots, não lhe é cobrado qualquer valor pela consulta de tabelas externas. Em vez disso, são consumidos slots para estas consultas.

A tabela seguinte mostra como o seu modelo de preços afeta a forma como estes custos são aplicados:


Preços a pedido
Edições Standard, Enterprise e Enterprise Plus

Consultas
A faturação é feita com base nos bytes processados pelas consultas dos utilizadores.
Os slots nas atribuições de reservas com um QUERYtipo de tarefa são consumidos durante o tempo de consulta.

Atualizar manualmente a cache de metadados.
A faturação é feita pelos bytes processados para atualizar a cache.
Vagas em atribuições de reservas com um QUERYtipo de tarefa são consumidas durante a atualização da cache.

Atualizar automaticamente a cache de metadados.
A faturação é feita pelos bytes processados para atualizar a cache.
Vagas em atribuições de reservas com um BACKGROUNDtipo de tarefa são consumidas durante a atualização da cache.

Se não existirem reservas BACKGROUND disponíveis para atualizar a cache de metadados, o BigQuery usa automaticamente as posições nas reservas QUERY, se estiver a usar a edição Enterprise ou Enterprise Plus.

Também lhe é cobrado o armazenamento e o acesso aos dados pelo Cloud Storage, Amazon S3 e Azure Blob Storage, sujeito às diretrizes de preços de cada produto.

Usar tabelas de objetos com a partilha do BigQuery

As tabelas de objetos são compatíveis com a partilha do BigQuery (anteriormente Analytics Hub). Os conjuntos de dados que contêm tabelas de objetos podem ser publicados como partilhas de fichas. Os subscritores da partilha podem subscrever estas fichas, que aprovisionam um conjunto de dados só de leitura, denominado conjunto de dados associado, no respetivo projeto. Os subscritores podem consultar todas as tabelas no conjunto de dados associado, incluindo todas as tabelas de objetos. Para mais informações, consulte o artigo Subscreva uma ficha.

O que se segue?