Limites et points à noter

L'intégration de Spark et Hive au catalogue d'environnements d'exécution Lakehouse élimine les frais opérationnels liés à la maintenance d'un metastore Hive (HMS) auto-hébergé, tout en permettant le partage unifié des métadonnées et les requêtes directes sur les tables dans BigQuery.

Ce document met en évidence les contraintes fonctionnelles et les considérations liées au service de cette intégration. Avant de migrer ou de créer vos pipelines de bases de données Open Source dans le catalogue d'exécution Lakehouse, consultez ces limites pour déterminer si cet aperçu correspond à vos exigences techniques.

Si vous recherchez des instructions de configuration et de requête au lieu de limites, consultez Utiliser Spark et Hive avec le catalogue du runtime Lakehouse.

Limites du catalogue d'environnements d'exécution Lakehouse

Cette section liste les limites d'utilisation du catalogue d'exécution Lakehouse avec différents services.

Limites du metastore

  • Managed Service pour Apache Spark n'accepte que les jobs PySpark avec Lakehouse Metastore.
  • L'API Dataproc n'est pas compatible avec la définition des propriétés Lakehouse Metastore dans le champ properties.
  • Vous ne pouvez pas créer de clusters Managed Service pour Apache Spark qui utilisent Kerberos, car le catalogue du runtime Lakehouse n'est pas compatible avec les API de jeton de délégation ni de clé primaire.
  • Les bases de données et les tables peuvent utiliser un location_uri Cloud Storage distinct de leur catalogue Hive, à condition que le bucket Cloud Storage se trouve dans la même région que le catalogue Hive.

Limites des tables

  • Il n'est pas possible de renommer les tables.
  • Il n'est pas possible de renommer les partitions.
  • La suppression de tables ou de bases de données n'entraîne pas la suppression des fichiers associés de Cloud Storage.
  • La recherche non sensible à la casse n'est pas prise en charge.
  • Le clustering et le bucketing ne sont pas acceptés.

Taille du lot de partition

Le catalogue d'environnements d'exécution Lakehouse est compatible avec le stockage et la récupération des informations de partitionnement à utiliser dans l'élagage des partitions. Il est optimisé pour les lectures plutôt que pour les écritures, ce qui permet d'accélérer les performances des requêtes grâce à l'élagage des partitions.

Pour optimiser les performances d'ingestion des partitions, la taille des partitions par lot est limitée à 900.

Définissez la configuration suivante pour les propriétés Hive et Spark qui déterminent la taille de lot des opérations de partitionnement :

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

Limites de BigQuery

  • Par défaut, BigQuery n'accepte pas les types de données ARRAY<ARRAY<>> ni ARRAY<MAP<>>. La prise en charge de MAP doit être ajoutée à une liste d'autorisation. Contactez biglake-help@google.com si vos charges de travail utilisent MAP de manière intensive.
  • Les types de clés MAP n'acceptent que les types de données primitifs. Vous ne pouvez pas utiliser ARRAY, STRUCT ni MAP comme types de clés.
  • Pendant la version preview, BigQuery ne peut interroger que les données provenant de Cloud Storage. Les limites suivantes s'appliquent :
    • Les URI d'emplacement de table ne peuvent pas inclure de caractère générique (*).
    • Les URI d'emplacement de table doivent être des répertoires.

Limites de la réplication interrégionale et de la reprise après sinistre

Le catalogue d'environnements d'exécution Lakehouse propose la réplication interrégionale et la reprise après sinistre pour améliorer la disponibilité et la résilience de votre catalogue.

Lorsque vous utilisez le catalogue d'environnements d'exécution Lakehouse avec des catalogues Hive, les limites suivantes s'appliquent :

  • Les catalogues Hive n'offrent pas de fonctionnalités complètes de reprise après sinistre, comme le basculement initié par l'utilisateur.

  • Lorsque vous créez un catalogue Hive, vous devez définir son primary_location pour qu'il corresponde à la région de votre bucket Cloud Storage. Le catalogue du runtime Lakehouse copie ensuite automatiquement les métadonnées dans une région secondaire en fonction de la configuration birégionale ou multirégionale de votre bucket. Cette copie secondaire des métadonnées est en lecture seule et vous ne pouvez pas la promouvoir en tant que copie principale. La redondance des données dépend des paramètres birégionaux ou multirégionaux de votre bucket, qui sont distincts de la réplication des métadonnées du catalogue du runtime Lakehouse.

Éléments à prendre en compte pour utiliser le catalogue d'environnements d'exécution Lakehouse en remplacement d'un metastore Hive

La version preview du catalogue d'environnements d'exécution Lakehouse est compatible avec un sous-ensemble de l'interface Hive Metastore. Cette conception privilégie la compatibilité avec Spark ExternalCatalog, qui ne nécessite pas une compatibilité totale avec le Hive Metastore.

Mappage des ressources

Le tableau suivant mappe les ressources Hive Metastore aux ressources du catalogue du runtime Lakehouse et à leurs autorisations IAM (Identity and Access Management) requises.

Ressource Hive Metastore Ressource de catalogue d'environnements d'exécution Lakehouse Autorisation IAM
Catalogue Catalogue biglake.catalogs.*
Base de données Base de données biglake.namespaces.*
Table Table biglake.tables.*

Gouvernance

Le métastore Hive (HMS) assure la gouvernance au niveau des tables, des colonnes et des partitions. Le catalogue d'environnements d'exécution Lakehouse fournit des autorisations IAM au niveau des tables et des partitions. La gouvernance au niveau des colonnes n'est pas compatible.

Limites de stockage

  • Toutes les limites des tables externes BigQuery s'appliquent.

Limites des partitions

  • Le suivi des statistiques au niveau des colonnes au niveau des partitions n'est pas accepté.
  • L'API BatchCreateHivePartitions limite les appels à 900 partitions.

Étapes suivantes