Consultar formatos de tabelas abertas com manifestos

Este documento descreve como usar ficheiros de manifesto para consultar dados armazenados em formatos de tabelas abertas, como o Apache Hudi e o Delta Lake.

Alguns formatos de tabelas abertas, como o Hudi e o Delta Lake, exportam o respetivo estado atual como um ou mais ficheiros de manifesto. Um ficheiro de manifesto contém uma lista de ficheiros de dados que criam tabelas. Com o suporte de ficheiros de manifesto no BigQuery, pode consultar e carregar dados armazenados em formatos de tabelas abertos.

Antes de começar

Funções necessárias

Para consultar tabelas BigLake com base em dados Hudi e Delta Lake, certifique-se de que tem as seguintes funções:

  • Utilizador de ligação do BigQuery (roles/bigquery.connectionUser)
  • Visualizador de dados do BigQuery (roles/bigquery.dataViewer)
  • Utilizador do BigQuery (roles/bigquery.user)

Também pode consultar tabelas externas do Hudi. No entanto, recomendamos que atualize a tabela externa para o BigLake. Para consultar tabelas externas do Hudi, certifique-se de que tem as seguintes funções:

  • Visualizador de dados do BigQuery (roles/bigquery.dataViewer)
  • Utilizador do BigQuery (roles/bigquery.user)
  • Visualizador de objetos de armazenamento (roles/storage.objectViewer)

Consoante as suas autorizações, pode atribuir estas funções a si próprio ou pedir ao seu administrador para as atribuir. Para mais informações sobre a concessão de funções, consulte o artigo Ver as funções atribuíveis aos recursos.

Para ver as autorizações exatas necessárias para consultar tabelas do BigLake, expanda a secção Autorizações necessárias:

Autorizações necessárias

Também pode conseguir estas autorizações com funções personalizadas ou outras funções predefinidas.

Consultar cargas de trabalho do Hudi

Para consultar dados do Hudi, siga estes passos:

  1. Crie uma tabela externa com base nos dados Hudi.
  2. Atualize a tabela externa para o BigLake.

Crie tabelas externas Hudi

Quando sincroniza tabelas através da ferramenta de sincronização para Hudi e BigQuery, ative a flag use-bq-manifest-file para fazer a transição para a abordagem de ficheiros de manifesto. Esta flag também exporta um ficheiro de manifesto num formato suportado pelo BigQuery e usa-o para criar uma tabela externa com o nome especificado no parâmetro --table.

Para criar uma tabela externa Hudi, siga estes passos:

  1. Para criar uma tabela externa do Hudi, envie um trabalho para um cluster do Dataproc existente. Quando cria o conetor Hudi-BigQuery, ative a flag use-bq-manifest-file para fazer a transição para a abordagem de ficheiros de manifesto. Esta flag exporta um ficheiro de manifesto num formato suportado pelo BigQuery e usa-o para criar uma tabela externa com o nome especificado no parâmetro --table.

    spark-submit \
       --master yarn \
       --packages com.google.cloud:google-cloud-bigquery:2.10.4 \
       --class org.apache.hudi.gcp.bigquery.BigQuerySyncTool  \
       JAR \
       --project-id PROJECT_ID \
       --dataset-name DATASET \
       --dataset-location LOCATION \
       --table TABLE \
       --source-uri URI  \
       --source-uri-prefix URI_PREFIX \
       --base-path BASE_PATH  \
       --partitioned-by PARTITION_BY \
       --use-bq-manifest-file
    

    Substitua o seguinte:

    • JAR: se estiver a usar o conetor Hudi-BigQuery, especifique hudi-gcp-bundle-0.14.0.jar. Se estiver a usar o componente Hudi no Dataproc 2.1, especifique /usr/lib/hudi/tools/bq-sync-tool/hudi-gcp-bundle-0.12.3.1.jar

    • PROJECT_ID: o ID do projeto no qual quer criar a tabela do BigLake Hudi

    • DATASET: o conjunto de dados no qual quer criar a tabela Hudi do BigLake

    • LOCATION: a localização na qual quer criar a tabela Hudi BigLake

    • TABLE: o nome da tabela que quer criar

      Se estiver a fazer a transição da versão anterior do conetor Hudi-BigQuery (0.13.0 e anterior) que criou vistas nos ficheiros de manifesto, certifique-se de que usa o mesmo nome da tabela, uma vez que lhe permite manter o código da pipeline a jusante existente.

    • URI: o URI do Cloud Storage que criou para armazenar o ficheiro de manifesto do Hudi

      Este URI aponta para a partição de primeiro nível. Certifique-se de que inclui a chave de partição. Por exemplo, gs://mybucket/hudi/mydataset/EventDate=*

    • URI_PREFIX: o prefixo do caminho do URI do Cloud Storage. Normalmente, é o caminho para tabelas Hudi

    • BASE_PATH: o caminho base para tabelas Hudi

      Por exemplo, gs://mybucket/hudi/mydataset/

    • PARTITION_BY: o valor da partição

      Por exemplo, EventDate

    Para mais informações acerca da configuração do conetor, consulte o artigo Conetor Hudi-BigQuery.

  2. Para definir controlos detalhados adequados ou acelerar o desempenho ativando o armazenamento em cache de metadados, consulte o artigo Atualize as tabelas do BigLake.

Consultar cargas de trabalho delta

As tabelas delta são agora suportadas nativamente. Recomendamos que crie tabelas Delta do BigLake para cargas de trabalho Delta. As tabelas do BigLake Delta Lake suportam tabelas do Delta Lake mais avançadas, incluindo tabelas com remapeamento de colunas e vetores de eliminação. Além disso, as tabelas Delta do BigLake leem diretamente o instantâneo mais recente, pelo que as atualizações estão disponíveis instantaneamente.

Para consultar cargas de trabalho Delta, siga estes passos:

  1. Gere um ficheiro de manifesto.
  2. Crie uma tabela do BigLake com base no ficheiro de manifesto.
  3. Defina controlos detalhados adequados ou acelere o desempenho ativando a colocação em cache de metadados. Para o fazer, consulte o artigo Atualize tabelas do BigLake.

Gere um ficheiro de manifesto

O BigQuery suporta o ficheiro de manifesto no formato SymLinkTextInputFormat, que é uma lista de URIs delimitada por novas linhas. Para mais informações sobre como gerar um ficheiro de manifesto, consulte o artigo Configure a integração do Presto com o Delta Lake e consulte tabelas Delta.

Para gerar um ficheiro de manifesto, envie uma tarefa para um cluster do Dataproc existente:

SQL

Usando o Spark, execute o seguinte comando numa tabela Delta na localização path-to-delta-table:

GENERATE symlink_format_manifest FOR TABLE delta.`<path-to-delta-table>`

Scala

Usando o Spark, execute o seguinte comando numa tabela Delta na localização path-to-delta-table:

val deltaTable = DeltaTable.forPath(<path-to-delta-table>)
deltaTable.generate("symlink_format_manifest")

Java

Usando o Spark, execute o seguinte comando numa tabela Delta na localização path-to-delta-table:

DeltaTable deltaTable = DeltaTable.forPath(<path-to-delta-table>);
deltaTable.generate("symlink_format_manifest");

Python

Usando o Spark, execute o seguinte comando numa tabela Delta na localização path-to-delta-table:

deltaTable = DeltaTable.forPath(<path-to-delta-table>)
deltaTable.generate("symlink_format_manifest")

Crie tabelas Delta do BigLake

Para criar uma tabela Delta do BigLake, use a CREATE EXTERNAL TABLE declaração com o campo file_set_spec_type definido como NEW_LINE_DELIMITED_MANIFEST:

  1. Aceda à página do BigQuery.

    Aceda ao BigQuery

  2. No editor de consultas, execute a declaração CREATE EXTERNAL TABLE:

    CREATE EXTERNAL TABLE PROJECT_ID.DATASET_NAME.TABLE_NAME
    WITH PARTITION COLUMNS(
    `PARTITION_COLUMN PARTITION_COLUMN_TYPE`,)
    WITH CONNECTION `PROJECT_IDREGION.CONNECTION_NAME`
    OPTIONS (
       format = "DATA_FORMAT",
       uris = ["URI"],
       file_set_spec_type = 'NEW_LINE_DELIMITED_MANIFEST',
       hive_partition_uri_prefix = "PATH_TO_DELTA_TABLE"
       max_staleness = STALENESS_INTERVAL,
       metadata_cache_mode = 'CACHE_MODE');
    

    Substitua o seguinte:

    • DATASET_NAME: o nome do conjunto de dados que criou
    • TABLE_NAME: o nome que quer dar a esta tabela
    • REGION: a localização onde a ligação se encontra (por exemplo, us-east1)
    • CONNECTION_NAME: o nome da associação que criou
    • DATA_FORMAT: qualquer um dos formatos suportados (como PARQUET)
    • URI: o caminho para o ficheiro de manifesto (por exemplo, gs://mybucket/path)
    • PATH_TO_DELTA_TABLE: um prefixo comum para todos os URIs de origem antes de começar a codificação da chave de partição
    • STALENESS_INTERVAL: especifica se as operações contra a tabela do BigLake usam metadados em cache e qual a atualização dos metadados em cache necessária para que a operação os use. Para mais informações sobre considerações de colocação em cache de metadados, consulte o artigo Colocação em cache de metadados para desempenho.

      Para desativar a colocação em cache de metadados, especifique 0. Esta é a predefinição.

      Para ativar o armazenamento em cache de metadados, especifique um valor literal de intervalo entre 30 minutos e 7 dias. Por exemplo, especifique INTERVAL 4 HOUR para um intervalo de desatualização de 4 horas. Com este valor, as operações na tabela usam metadados em cache se tiverem sido atualizados nas últimas 4 horas. Se os metadados em cache forem mais antigos, a operação obtém os metadados do Delta Lake.

    • CACHE_MODE: especifica se a cache de metadados é atualizada automaticamente ou manualmente. Para mais informações acerca das considerações sobre o armazenamento em cache de metadados, consulte Armazenamento em cache de metadados para desempenho.

      Definido como AUTOMATIC para que a cache de metadados seja atualizada a um intervalo definido pelo sistema, normalmente entre 30 e 60 minutos.

      Defina como MANUAL se quiser atualizar a cache de metadados de acordo com uma programação que determinar. Neste caso, pode chamar o procedimento do sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE para atualizar a cache.

      Tem de definir CACHE_MODE se STALENESS_INTERVAL estiver definido como um valor superior a 0.

    Exemplo:

    CREATE EXTERNAL TABLE mydataset.mytable
    WITH CONNECTION `us-east1.myconnection`
    OPTIONS (
        format="PARQUET",
        uris=["gs://mybucket/path/partitionpath=*"],
        file_set_spec_type = 'NEW_LINE_DELIMITED_MANIFEST'
        hive_partition_uri_prefix = "gs://mybucket/path/"
        max_staleness = INTERVAL 1 DAY,
        metadata_cache_mode = 'AUTOMATIC'
    );

Atualize tabelas do BigLake

Também pode acelerar o desempenho das suas cargas de trabalho tirando partido da colocação em cache de metadados e das vistas materializadas. Se quiser usar a colocação em cache de metadados, pode especificar as definições para tal ao mesmo tempo. Para obter detalhes da tabela, como o formato de origem e o URI de origem, consulte o artigo Obtenha informações da tabela.

Para atualizar uma tabela externa para uma tabela BigLake ou atualizar uma tabela BigLake existente, selecione uma das seguintes opções:

SQL

Use a declaração DDL CREATE OR REPLACE EXTERNAL TABLE para atualizar uma tabela:

  1. Na Google Cloud consola, aceda à página BigQuery.

    Aceda ao BigQuery

  2. No editor de consultas, introduza a seguinte declaração:

    CREATE OR REPLACE EXTERNAL TABLE
      `PROJECT_ID.DATASET.EXTERNAL_TABLE_NAME`
      WITH CONNECTION {`REGION.CONNECTION_ID` | DEFAULT}
      OPTIONS(
        format ="TABLE_FORMAT",
        uris = ['BUCKET_PATH'],
        max_staleness = STALENESS_INTERVAL,
        metadata_cache_mode = 'CACHE_MODE'
        );

    Substitua o seguinte:

    • PROJECT_ID: o nome do projeto que contém a tabela
    • DATASET: o nome do conjunto de dados que contém a tabela
    • EXTERNAL_TABLE_NAME: o nome da tabela
    • REGION: a região que contém a ligação
    • CONNECTION_ID: o nome da ligação a usar

      Para usar uma associação predefinida, especifique DEFAULT em vez da string de associação que contém REGION.CONNECTION_ID.

    • TABLE_FORMAT: o formato usado pela tabela

      Não pode alterar esta opção quando atualiza a tabela.

    • BUCKET_PATH: o caminho para o contentor do Cloud Storage que contém os dados da tabela externa, no formato ['gs://bucket_name/[folder_name/]file_name'].

      Pode selecionar vários ficheiros do contentor especificando um caráter universal de asterisco (*) no caminho. Por exemplo, ['gs://mybucket/file_name*']. Para mais informações, consulte o artigo Suporte de carateres universais para URIs do Cloud Storage.

      Pode especificar vários contentores para a opção uris fornecendo vários caminhos.

      Os exemplos seguintes mostram valores uris válidos:

      • ['gs://bucket/path1/myfile.csv']
      • ['gs://bucket/path1/*.csv']
      • ['gs://bucket/path1/*', 'gs://bucket/path2/file00*']

      Quando especifica valores uris que segmentam vários ficheiros, todos esses ficheiros têm de partilhar um esquema compatível.

      Para mais informações sobre a utilização de URIs do Cloud Storage no BigQuery, consulte o artigo Caminho de recurso do Cloud Storage.

    • STALENESS_INTERVAL: especifica se os metadados em cache são usados por operações na tabela e qual a atualidade dos metadados em cache para que a operação os use

      Para mais informações sobre considerações relativas ao armazenamento em cache de metadados, consulte o artigo Armazenamento em cache de metadados para desempenho.

      Para desativar a colocação em cache de metadados, especifique 0. Esta é a predefinição.

      Para ativar o armazenamento em cache de metadados, especifique um valor literal de intervalo entre 30 minutos e 7 dias. Por exemplo, especifique INTERVAL 4 HOUR para um intervalo de desatualização de 4 horas. Com este valor, as operações na tabela usam metadados em cache se tiverem sido atualizados nas últimas 4 horas. Se os metadados em cache forem mais antigos, a operação obtém os metadados do Cloud Storage.

    • CACHE_MODE: especifica se a cache de metadados é atualizada automaticamente ou manualmente

      Para mais informações sobre considerações de colocação em cache de metadados, consulte Colocação em cache de metadados para desempenho.

      Definido como AUTOMATIC para que a cache de metadados seja atualizada a um intervalo definido pelo sistema, normalmente entre 30 e 60 minutos.

      Defina como MANUAL se quiser atualizar a cache de metadados de acordo com uma programação que determinar. Neste caso, pode chamar o procedimento do sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE para atualizar a cache.

      Tem de definir CACHE_MODE se STALENESS_INTERVAL estiver definido como um valor superior a 0.

  3. Clique em Executar.

Para mais informações sobre como executar consultas, consulte o artigo Execute uma consulta interativa.

bq

Use os comandos bq mkdef e bq update para atualizar uma tabela:

  1. Gere uma definição de tabela externa, que descreve os aspetos da tabela a alterar:

    bq mkdef --connection_id=PROJECT_ID.REGION.CONNECTION_ID \
    --source_format=TABLE_FORMAT \
    --metadata_cache_mode=CACHE_MODE \
    "BUCKET_PATH" > /tmp/DEFINITION_FILE

    Substitua o seguinte:

    • PROJECT_ID: o nome do projeto que contém a associação
    • REGION: a região que contém a ligação
    • CONNECTION_ID: o nome da associação a usar
    • TABLE_FORMAT: o formato usado pela tabela. Não pode alterar esta opção quando atualiza a tabela.
    • CACHE_MODE: especifica se a cache de metadados é atualizada automaticamente ou manualmente. Para mais informações sobre considerações relativas ao armazenamento em cache de metadados, consulte Armazenamento em cache de metadados para desempenho.

      Defina como AUTOMATIC para que a cache de metadados seja atualizada a um intervalo definido pelo sistema, normalmente entre 30 e 60 minutos.

      Defina como MANUAL se quiser atualizar a cache de metadados de acordo com um horário que determinar. Neste caso, pode chamar o procedimento do sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE para atualizar a cache.

      Tem de definir CACHE_MODE se STALENESS_INTERVAL estiver definido como um valor superior a 0.

    • BUCKET_PATH: o caminho para o contentor de armazenamento na nuvem que contém os dados da tabela externa, no formato gs://bucket_name/[folder_name/]file_name.

      Pode limitar os ficheiros selecionados do contentor especificando um caráter universal (*) no caminho. Por exemplo, gs://mybucket/file_name*. Para mais informações, consulte o artigo Suporte de carateres universais para URIs do Cloud Storage.

      Pode especificar vários contentores para a opção uris fornecendo vários caminhos.

      Os exemplos seguintes mostram valores uris válidos:

      • gs://bucket/path1/myfile.csv
      • gs://bucket/path1/*.csv
      • gs://bucket/path1/*,gs://bucket/path2/file00*

      Quando especifica valores uris que segmentam vários ficheiros, todos esses ficheiros têm de partilhar um esquema compatível.

      Para mais informações sobre a utilização de URIs do Cloud Storage no BigQuery, consulte o caminho de recurso do Cloud Storage.

    • DEFINITION_FILE: o nome do ficheiro de definição da tabela que está a criar.

  2. Atualize a tabela com a nova definição de tabela externa:

    bq update --max_staleness=STALENESS_INTERVAL \
    --external_table_definition=/tmp/DEFINITION_FILE \
    PROJECT_ID:DATASET.EXTERNAL_TABLE_NAME

    Substitua o seguinte:

    • STALENESS_INTERVAL: especifica se as operações contra a tabela usam metadados em cache e qual a antiguidade máxima dos metadados em cache para que a operação os use. Para mais informações sobre considerações de colocação em cache de metadados, consulte o artigo Colocação em cache de metadados para desempenho.

      Para desativar a colocação em cache de metadados, especifique 0. Esta é a predefinição.

      Para ativar o armazenamento em cache de metadados, especifique um valor de intervalo entre 30 minutos e 7 dias, usando o formato Y-M D H:M:S descrito na documentação do tipo de dados INTERVAL. Por exemplo, especifique 0-0 0 4:0:0 para um intervalo de desatualização de 4 horas. Com este valor, as operações na tabela usam metadados em cache se tiverem sido atualizados nas últimas 4 horas. Se os metadados em cache forem mais antigos, a operação obtém os metadados do Cloud Storage.

    • DEFINITION_FILE: o nome do ficheiro de definição da tabela que criou ou atualizou.

    • PROJECT_ID: o nome do projeto que contém a tabela

    • DATASET: o nome do conjunto de dados que contém a tabela

    • EXTERNAL_TABLE_NAME: o nome da tabela

Consultar tabelas externas e do BigLake

Depois de criar uma tabela do BigLake, pode consultá-la através da sintaxe do GoogleSQL, tal como se fosse uma tabela padrão do BigQuery. Por exemplo, SELECT field1, field2 FROM mydataset.my_cloud_storage_table;.

Limitações

  • O BigQuery só suporta a consulta de tabelas do leitor do Delta Lake v1.

  • A integração do Hudi e do BigQuery só funciona para tabelas copy-on-write particionadas ao estilo do Hive.

O que se segue?