Limitações e considerações

A integração do Spark e do Hive com o catálogo de ambientes de execução do lakehouse elimina o overhead operacional de manter um metastore Hive (HMS) auto-hospedado, além de permitir o compartilhamento unificado de metadados e consultas diretas de tabelas no BigQuery.

Este documento destaca as restrições funcionais e considerações de serviço dessa integração. Antes de migrar ou criar seus pipelines de banco de dados de código aberto no catálogo de tempo de execução do Lakehouse, consulte estas limitações para determinar se esta prévia atende aos seus requisitos técnicos.

Se você estiver procurando instruções de configuração e consulta em vez de limites, consulte Usar o Spark e o Hive com o catálogo de tempo de execução do Lakehouse.

Limitações do catálogo de ambientes de execução do Lakehouse

Nesta seção, listamos as limitações de uso do catálogo de tempo de execução do Lakehouse com vários serviços.

Limitações do Metastore

  • O Serviço Gerenciado para Apache Spark é compatível apenas com jobs do PySpark com o metastore do Lakehouse.
  • A API Dataproc não oferece suporte à definição de propriedades do metastore do Lakehouse no campo properties.
  • Não é possível criar clusters do Serviço Gerenciado para Apache Spark que usam o Kerberos porque o catálogo do ambiente de execução do Lakehouse não é compatível com APIs de token de delegação ou chave primária.
  • Os bancos de dados e as tabelas podem usar um location_uri do Cloud Storage diferente do catálogo do Hive, desde que o bucket do Cloud Storage esteja na mesma região do catálogo do Hive.
  • O catálogo do Hive não pode conter namespaces e tabelas do Iceberg. Para criar e usar namespaces e tabelas do Iceberg, use o catálogo de tempo de execução do Lakehouse.

Limitações da tabela

  • Não é possível renomear a tabela.
  • Não é possível renomear partições.
  • A exclusão de tabelas ou bancos de dados não remove os arquivos associados do Cloud Storage.
  • A pesquisa sem diferenciação de maiúsculas e minúsculas não é compatível.
  • Não há suporte para clustering e agrupamento em intervalos.

Tamanho do lote de partição

O catálogo de tempo de execução do Lakehouse oferece suporte ao armazenamento e à recuperação de informações de particionamento para uso na remoção de partições. Ele é otimizado para leituras em vez de gravações, o que resulta em um desempenho de consulta mais rápido com a remoção de partições.

Para otimizar o desempenho da ingestão de partições, o tamanho do lote é limitado a 900.

Defina a seguinte configuração para as propriedades do Hive e do Spark que determinam o tamanho do lote das operações de particionamento:

  • SET hive.msck.repair.batch.size = 900;
  • SET spark.sql.addPartitionInBatch.size = 900;

Limitações do BigQuery

  • Por padrão, o BigQuery não oferece suporte aos tipos de dados ARRAY<ARRAY<>> ou ARRAY<MAP<>>. O suporte para MAP precisa ser adicionado a uma lista de permissões. Entre em contato com biglake-help@google.com se suas cargas de trabalho usarem MAP com frequência.
  • Os tipos de chave MAP só aceitam tipos de dados primitivos. Não é possível usar ARRAY, STRUCT ou MAP como tipos de chave.
  • Durante a prévia, o BigQuery só pode consultar dados do Cloud Storage. As seguintes limitações são aplicáveis:
    • Os URIs de local da tabela não podem incluir um caractere curinga (*).
    • Os URIs de local da tabela precisam ser diretórios.

Limitações da replicação entre regiões e da recuperação de desastres

O catálogo de ambientes de execução do Lakehouse oferece replicação entre regiões e recuperação de desastres para melhorar a disponibilidade e a resiliência do catálogo.

Ao usar o catálogo de ambientes de execução do Lakehouse com catálogos do Hive, as seguintes limitações se aplicam:

  • Os catálogos do Hive não oferecem recursos completos de recuperação de desastres, como failover iniciado pelo usuário.

  • Ao criar um catálogo do Hive, defina o primary_location dele para corresponder à região do bucket do Cloud Storage. Em seguida, o catálogo do tempo de execução do Lakehouse copia automaticamente os metadados para uma região secundária com base na configuração birregional ou multirregional do bucket. Essa cópia secundária de metadados é somente leitura e não pode ser promovida a principal. A redundância de dados depende das configurações birregionais ou multirregionais do bucket, que são separadas da replicação de metadados do catálogo de tempo de execução do Lakehouse.

Considerações sobre o uso do catálogo de ambientes de execução do Lakehouse como substituto do metastore do Hive

A versão prévia do catálogo de tempo de execução do Lakehouse é compatível com um subconjunto da interface do metastore do Hive. Esse design prioriza a compatibilidade com o Spark ExternalCatalog, que não exige compatibilidade total com o metastore do Hive.

Mapeamento de recursos

A tabela a seguir mapeia os recursos do metastore do Hive para os recursos do catálogo de tempo de execução do Lakehouse e as permissões necessárias do Identity and Access Management (IAM).

Recurso do metastore do Hive Recurso do catálogo de ambientes de execução do Lakehouse Permissão do IAM
Catálogo Catálogo biglake.catalogs.*
Banco de dados Banco de dados biglake.namespaces.*
Tabela Tabela biglake.tables.*

Governança

O metastore Hive (HMS) oferece governança nos níveis de tabela, coluna e partição. O catálogo de ambientes de execução do Lakehouse oferece permissões de IAM no nível da tabela e da partição. A governança no nível da coluna não é compatível.

Limitações de armazenamento

  • Todas as limitações de tabelas externas do BigQuery são aplicáveis.

Limitações de partições

  • Não é possível rastrear estatísticas no nível da coluna no nível da partição.
  • A API BatchCreateHivePartitions limita as chamadas a 900 partições.

A seguir