Introdução às tabelas de objetos

Neste documento, descrevemos as tabelas de objetos, que são tabelas somente leitura sobre objetos de dados não estruturados que residem no Cloud Storage.

As tabelas de objetos permitem analisar dados não estruturados no Cloud Storage. É possível fazer análises com funções remotas ou inferência usando o BigQuery ML e, em seguida, mesclar os resultados dessas operações com o restante dos seus dados estruturados no BigQuery.

Assim como as tabelas do BigLake, as tabelas de objetos usam a delegação de acesso, o que desassocia o acesso à tabela do acesso aos objetos do Cloud Storage. Uma conexão externa associada a uma conta de serviço é usada para se conectar ao Cloud Storage. Portanto, você só precisa conceder aos usuários acesso à tabela de objetos. Isso permite aplicar a segurança no nível da linha e gerenciar a quais objetos os usuários 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 em um bucket especificado do Cloud Storage. Cada linha da tabela corresponde a um objeto, e as colunas da tabela correspondem aos metadados de objeto gerados pelo Cloud Storage, incluindo todos os metadados personalizados.

Uma tabela de objetos também contém uma pseudocoluna data que representa o conteúdo do arquivo em bytes brutos, que é preenchido automaticamente quando a tabela de objetos é criada. Essa pseudocoluna é usada pela função ML.DECODE_IMAGE quando você executa inferência em dados de imagem. Não é possível incluir a pseudocoluna data nas consultas. Além disso, ela não aparece como parte do esquema da tabela de objetos.

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

Nome do campo	Tipo	Mode	Descrição
uri	STRING	NULLABLE	uri: o identificador uniforme de recurso (URI, na sigla em inglês) do objeto, no formato gs://bucket_name/[folder_name/]object_name.
generation	NÚMERO INTEIRO	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 mídia dele. Se um objeto for armazenado sem um Content-Type, ele será exibido como application/octet-stream.
size	NÚMERO INTEIRO	NULLABLE	O Content-Length dos dados em bytes.
md5_hash	STRING	NULLABLE	O hash MD5 dos dados, codificado usando base64. Para mais informações sobre como usar o hash MD5, consulte Metadados de objeto do Cloud Storage.
updated	TIMESTAMP	NULLABLE	A última vez que os metadados do objeto foram modificados.
metadata	RECORD	REPEATED	Metadados personalizados para o objeto. Cada parte dos metadados é representada como um par de chave-valor nos campos filhos (metadata.)name e (metadata.)value do campo metadata.
(metadata.)name	STRING	NULLABLE	Chave em uma entrada de metadados individual.
(metadata.)value	STRING	NULLABLE	Valor em uma entrada de metadados individual.

As linhas em uma tabela de objetos são semelhantes a estas:

------------------------------------------------------------------------------------------------------------------------------------------------
|  uri                 | generation | content_type | size  | md5_hash   | updated                        | metadata...name | metadata...value  |
—-----------------------------------------------------------------------------------------------------------------------------------------------
| gs://mybucket/a.jpeg | 165842…    | image/jpeg   | 26797 | 8c33be10f… | 2022-07-21 17:35:40.148000 UTC | null            | null              |
—-----------------------------------------------------------------------------------------------------------------------------------------------
| gs://mybucket/b.bmp  | 305722…    | image/bmp    | 57932 | 44eb90cd1… | 2022-05-14 12:09:38.114000 UTC | null            | null              |
—-----------------------------------------------------------------------------------------------------------------------------------------------

Casos de uso

Consulte os metadados em uma tabela de objetos da mesma forma que em qualquer outra tabela do BigQuery. No entanto, o principal caso de uso das tabelas de objetos é tornar os dados não estruturados acessíveis para análise. É possível usar o BigQuery ML para executar a inferência em tabelas de objetos de imagem com os modelos do TensorFlow, TensorFlow Lite e PyTorch. Também é possível usar funções remotas para analisar dados não estruturados da maneira que você quiser. Por exemplo, é possível criar uma função remota que permita analisar imagens usando Cloud Vision ou uma opção que extraia metadados de documentos PDF usandoApache Tika.

A tabela a seguir descreve os pontos de integração que podem ser usados para fazer machine learning nos dados da tabela de objetos:

Integração	Descrição	Caso de uso	Tutorial
Modelos importados do BigQuery ML	Importe modelos do TensorFlow, do TensorFlow Lite ou do ONNX para o BigQuery ML para executar inferência local no BigQuery.	Você está usando modelos de código aberto ou personalizados que se encaixam nas limitações compatíveis.	Tutorial: executar a inferência em uma tabela de objetos usando um modelo vetorial de atributo
Funções do Cloud Run	Use o Cloud Run functions para chamar serviços ou modelos hospedados. Essa é a integração mais genérica.	Você mesmo hospeda os modelos no Compute Engine, no Google Kubernetes Engine ou em outra infraestrutura do cliente.
A ML.ANNOTATE_IMAGE função	Use a API Cloud Vision para fazer anotação em imagens.	Você quer fazer anotação em imagens usando um modelo pré-treinado da API Vision.	Fazer anotação em imagens com a função ML.ANNOTATE_IMAGE
A ML.PROCESS_DOCUMENT função	Use a API Document AI para extrair insights de documentos.	Você quer usar processadores de documentos pré-treinados ou personalizados da Document AI.	Processar documentos com a função ML.PROCESS_DOCUMENT
A ML.TRANSCRIBE função	Use a API Speech-to-Text para transcrever arquivos de áudio.	Você quer usar reconhecedores de fala pré-treinados ou personalizados da Speech-to-Text.	Transcrever arquivos de áudio com a função ML.TRANSCRIBE

É possível criar uma visualização ou tabela com base nos resultados da análise para mesclar os resultados com outros dados estruturados. Por exemplo, a instrução a seguir 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
);

Após a criação da tabela, é possível mesclá-la com outras tabelas baseadas em campos de metadados padrão ou personalizados, conforme mostrado a seguir:

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 é possível criar um índice de pesquisa para melhorar as pesquisas sobre os resultados da análise. Por exemplo, a instrução a seguir cria um índice de pesquisa sobre dados extraídos de arquivos PDF:

CREATE SEARCH INDEX my_index ON pdf_text_extract(ALL COLUMNS);

Você pode usar o índice para encontrar o que precisa nos resultados:

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

Benefícios

A análise nativa de dados não estruturados no BigQuery oferece os seguintes benefícios:

• Ela reduz o esforço manual permitindo automatizar etapas de pré-processamento, como ajustar os tamanhos de imagem aos requisitos do modelo.
• Ela permite usar a interface SQL simples e familiar para trabalhar com dados não estruturados.
• Ela ajuda a economizar custos utilizando os slots do BigQuery, em vez de provisionar novas formas de computação.

URLs assinados

Para ter acesso aos dados representados por um objeto, gere um URL assinado. É possível usar o URL assinado para visualizar diretamente os dados do objeto. Também é possível transmitir URLs assinados para funções remotas para que eles funcionem com os dados da tabela de objetos.

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

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

Isso retorna resultados semelhantes a estes:

---------------------------------------------------------------------------------------------------
|  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 de tabelas de objetos permitem que qualquer usuário ou procedimento possa ler os objetos correspondentes. Os URLs assinados gerados expiram após seis horas. Para mais informações, consulte URLs assinados do Cloud Storage.

Controle de acesso

As tabelas de objetos são criadas com base no BigLake. Portanto, elas usam uma conexão externa baseada em uma conta de serviço para acessar dados do Cloud Storage. Isso desacopla o acesso à tabela do acesso ao armazenamento de objetos subjacente por meio da delegação. Conceda à conta de serviço permissões para acessar dados e metadados dos objetos e exibi-los na tabela. Conceda permissões aos usuários apenas na tabela, em que é possível controlar o acesso aos dados usando o Identity and Access Management (IAM) e a segurança no nível da linha.

As tabelas de objetos diferem de outras tabelas que usam a delegação de acesso, porque o acesso a uma linha de uma tabela de objetos confere o acesso ao conteúdo do arquivo. Ainda que o usuário não possa acessar o objeto diretamente, ele pode gerar um URL assinado que permita conferir o conteúdo do arquivo. Por exemplo, se o usuário tiver acesso à linha da tabela de objetos que representa o arquivo de imagem flower.jpg, ele poderá gerar um URL assinado para exibir o arquivo e conferir que é uma imagem de um margarida.

Definir uma política de acesso no nível da linha em uma tabela de objetos restringe o acesso de um usuário ou grupo aos metadados do objeto nas linhas selecionadas e também aos objetos representados por essas linhas. Por exemplo, a instrução a seguir concede ao usuário acesso a Alice somente para 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:[e-mail]")
FILTER USING (updated < TIMESTAMP("2022-06-25"));

Com essa política de acesso no nível da linha, os seguintes resultados são verdadeiros para Alice:

• A execução da consulta SELECT * FROM my_dataset.my_object_table; retorna apenas linhas que têm um valor updated anterior a 25 de junho de 2022.
• A execução em inferência em my_dataset.my_object_table retorna apenas previsões para objetos que têm um valor updated anterior a 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 anterior a 25 de junho de 2022.

Também é possível restringir o acesso a linhas da tabela de objetos usando metadados personalizados. Por exemplo, a instrução a seguir restringe o grupo users a acessar apenas as linhas em que o objeto foi marcado 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:[e-mail]")
FILTER USING (ARRAY_LENGTH(metadata)=1
AND metadata[OFFSET(0)].name="no_pii")

Modelo de segurança

Os papéis organizacionais a seguir geralmente são envolvidos no gerenciamento e no uso de tabelas de objetos:

• Administradores do data lake. Esses administradores normalmente gerenciam políticas de gerenciamento de identidade e acesso (IAM) em buckets e objetos do Cloud Storage.
• Administradores de armazenamento de dados. Esses administradores geralmente criam, excluem e atualizam tabelas do BigLake.
• Analistas de dados. Normalmente, os analistas leem dados e executam consultas.

Os administradores do data lake são responsáveis por criar conexões e compartilhá-las com administradores de data warehouses. Por sua vez, os administradores de data warehouse definem tabelas, definem controles de acesso apropriados e compartilham as tabelas com analistas de dados.

Cuidado: os analistas de dados não podem ter o seguinte:

• A capacidade de ler objetos diretamente no Cloud Storage (consulte o papel de Leitor de objetos do Storage) permite que os analistas de dados burlem os controles de acesso colocados por administradores de armazenamento de dados.

• A capacidade de vincular tabelas a conexões (como o administrador de conexão do BigQuery).

  Caso contrário, os analistas de dados poderão criar novas tabelas do BigLake que não têm controles de acesso, burlando os controles feitos pelos administradores de data warehouse.

Arquivos de objetos compatíveis

É possível criar uma tabela de objetos em qualquer tipo e tamanho de arquivo de dados não estruturados e criar funções remotas para trabalhar com qualquer tipo de dados não estruturados. No entanto, para fazer inferência usando o BigQuery ML, uma tabela de objetos só pode ser sobre arquivos de imagem que atendam a vários requisitos de tamanho e tipo. Saiba mais em Limitações.

Armazenamento em cache de metadados para desempenho

É possível usar metadados em cache para melhorar o desempenho da inferência e 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. Os metadados incluem nomes de arquivos, informações de particionamento e metadados físicos de arquivos, como contagens de linhas. Você pode escolher se quer ativar o armazenamento em cache de metadados em uma tabela. As consultas com um grande número de arquivos e os filtros de partição do Hive são mais beneficiados com o armazenamento em cache de metadados.

Se você não ativar o armazenamento em cache de metadados, as consultas na tabela precisarão ler a fonte de dados externa para receber os metadados do objeto. A leitura desses dados aumenta a latência da consulta. Listar milhões de arquivos da fonte de dados externa pode levar vários minutos. Se você ativar o armazenamento em cache de metadados, as consultas podem evitar a listagem de arquivos da fonte de dados externa e podem particionar e remover arquivos mais rapidamente.

Há duas propriedades que controlam esse recurso:

• A inatividade máxima especifica quando as consultas usam metadados armazenados em cache.
• O modo de cache de metadados especifica como os metadados são coletados.

Quando o armazenamento em cache de metadados está ativado, você especifica o intervalo máximo de inatividade dos metadados que é aceitável para operações na tabela. Por exemplo, se você especificar um intervalo de uma hora, as operações na tabela usarão metadados em cache se eles tiverem sido atualizados na última hora. Se os metadados armazenados em cache forem mais antigos que isso, a operação retornará aos metadados do Cloud Storage. É possível especificar um intervalo de inatividade entre 30 minutos e 7 dias.

É possível atualizar o cache de maneira automática ou manual:

• Para atualizações automáticas, o cache é atualizado em um intervalo definido pelo sistema, geralmente entre 30 e 60 minutos. A atualização automática do cache é uma boa abordagem quando os arquivos no Cloud Storage são adicionados, excluídos ou modificados em intervalos aleatórios. Se você precisar controlar o tempo da atualização, por exemplo, para acioná-la no final de um job extract-transform-load, use a atualização manual.

• No caso de atualizações manuais, execute o procedimento do sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE para atualizar o cache de metadados de acordo com uma programação que atenda aos seus requisitos. A atualização manual do cache é uma boa abordagem quando os arquivos no Cloud Storage são adicionados, excluídos ou modificados em intervalos conhecidos, como a saída de um pipeline.

  Se você emitir várias atualizações manuais simultâneas, apenas uma vai ser bem-sucedida.

O cache de metadados expira após sete dias se não for atualizado.

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

Se você optar por usar atualizações automáticas, recomendamos que crie uma reserva e, em seguida, crie umuma tarefaBACKGROUND tipo de job para o projeto que executa os jobs de atualização do cache de metadados. Isso impede que os jobs de atualização compitam com as consultas do usuário por recursos e podem falhar se não houver recursos suficientes disponíveis.

Pense em como os valores do intervalo de inatividade e do modo de armazenamento em cache de metadados vão interagir antes de serem definidos. Confira estes exemplos:

• Se você estiver atualizando manualmente o cache de metadados de uma tabela e definir o intervalo de inatividade como dois dias, será necessário executar o procedimento do sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE a cada dois dias ou menos se quiser operações na tabela para usar metadados em cache.
• Se você estiver atualizando automaticamente o cache de metadados de uma tabela e definir o intervalo de inatividade como 30 minutos, é possível que algumas das operações na tabela sejam lidas pelo Cloud Storage se a atualização dos metadados de cache levar mais tempo do que a janela normal de 30 a 60 minutos.

Para encontrar informações sobre jobs de atualização de metadados, consulte a visualização INFORMATION_SCHEMA.JOBS, como mostrado no exemplo a seguir:

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 Armazenamento de metadados em cache.

Para mais informações sobre como definir opções de armazenamento em cache de metadados, consulte Criar tabelas de objetos.

Limitações

• As tabelas de objetos são somente leitura porque são mapeadas para objetos de dados não estruturados no Cloud Storage. Não é possível alterar uma tabela de objetos nem modificar os dados dela.
• O suporte a tabelas de objetos não está disponível no SQL legado ou em outros ambientes de nuvem, como AWS e Microsoft Azure.
• Para realizar a inferência usando o BigQuery ML, o modelo e a tabela de objetos usados precisam atender aos requisitos descritos em Limitações.
• As consultas que incluem tabelas de objetos não podem acessar mais de 10 GB de metadados de objetos. Por exemplo, se uma consulta acessa 100 TB de uma combinação de colunas de metadados em tabelas de objetos e dados de objeto em 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 Cotas.
• 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 Cotas.
• As funções remotas que processam dados não estruturados das tabelas de objetos estão sujeitas às mesmas limitações de todas as outras funções remotas.
• Os URLs assinados gerados para os objetos em uma tabela de objetos expiram após seis horas, que é o limite de tempo de execução da consulta.
• A inferência com o BigQuery ML não é compatível com preços sob demanda ou com a edição Standard.

• As funções a seguir não são compatíveis com preços sob demanda ou com a edição Standard:

  • ML.CONVERT_COLOR_SPACE
  • ML.CONVERT_IMAGE_TYPE
  • ML.RESIZE_IMAGE

Custos

Os custos são associados aos seguintes aspectos das tabelas de objetos:

• Consultar as tabelas.
• Atualização do cache de metadados.

Se você tiver reservas de slot, não receberá cobranças por consultar tabelas externas. Em vez disso, os slots são consumidos por essas consultas.

A tabela a seguir mostra como o modelo de preços afeta a aplicação desses custos:

	Preços sob demanda	Edições Standard, Enterprise e Enterprise Plus
Consultas	Você é cobrado pelos bytes processados pelas consultas do usuário.	Slots em atribuições de reserva com um tipo de job QUERY são consumidos durante o tempo de consulta.
Atualização manual do cache de metadados.	Você paga pelos bytes processados para atualizar o cache.	Slots em atribuições de reserva com um tipo de job QUERY são consumidos durante a atualização do cache.
Atualização automática do cache de metadados.	Você paga pelos bytes processados para atualizar o cache.	Slots em atribuições de reserva com um tipo de job BACKGROUND são consumidos durante a atualização do cache. Se não houver reservas BACKGROUND disponíveis para atualizar o cache de metadados, o BigQuery usará automaticamente slots em reservas QUERY se você estiver usando a edição Enterprise ou Enterprise Plus.

O Cloud Storage, Amazon S3, e o Armazenamento de Blobs do Azure também cobra pelo armazenamento e acesso, sujeitos sàs diretrizes de preços de cada produto.

Como usar tabelas de objetos com o Analytics Hub

As tabelas de objeto são compatíveis com o Analytics Hub. Os conjuntos de dados que contêm tabelas do objeto podem ser publicados como listagens do Analytics Hub. Os assinantes do Analytics Hub podem se inscrever nessas listagens, que provisionam um conjunto de dados somente leitura, chamado de conjunto de dados vinculado no projeto. Os assinantes podem consultar todas as tabelas no conjunto de dados vinculado, incluindo todas as tabelas do objeto. Para mais informações, consulte Assinar uma lista.

A seguir

• Saiba como criar uma tabela de objetos.
• Saiba como executar inferência em tabelas de objetos de imagem.
• Saiba como analisar tabelas de objetos usando funções remotas.