L'intégration de Spark et Hive au catalogue d'environnements d'exécution Lakehouse élimine la surcharge opérationnelle liée à la maintenance d'un metastore Hive (HMS) auto-hébergé, tout en permettant le partage unifié des métadonnées et les requêtes de table directes dans BigQuery.
Ce document met en évidence les contraintes fonctionnelles et les considérations de service de cette intégration. Avant de migrer ou de créer vos pipelines de base de données Open Source dans le catalogue d'environnements d'exécution Lakehouse, examinez ces limites pour déterminer si cet aperçu correspond à vos exigences techniques.
Si vous recherchez des instructions de configuration et de requête plutôt que des limites, consultez Utiliser Spark et Hive avec le catalogue d'environnements d'exécution Lakehouse.
Limites du catalogue d'environnements d'exécution Lakehouse
Cette section répertorie les limites d'utilisation du catalogue d'environnements d'exécution Lakehouse avec différents services.
Limites du metastore
- Managed Service pour Apache Spark n'est compatible qu'avec les tâches PySpark avec un metastore Lakehouse sans bordure.
- L'API Dataproc n'est pas compatible avec la définition des propriétés du metastore Lakehouse dans le champ
properties. - Vous ne pouvez pas créer de clusters Managed Service pour Apache Spark qui utilisent Kerberos, car le catalogue d'environnements d'exécution Lakehouse n'est pas compatible avec le jeton de délégation ni les API de clé primaire.
- Les bases de données et les tables peuvent utiliser un
location_uriCloud Storage distinct de leur catalogue Hive, à condition que le bucket Cloud Storage se trouve dans la même région que le catalogue Hive. - Le catalogue Hive ne peut pas contenir d'espaces de noms ni de tables Iceberg. Pour créer et utiliser des espaces de noms et des tables Iceberg, utilisez plutôt le catalogue d'environnements d'exécution Lakehouse.
Limites des tables
- Le renommage des tables n'est pas accepté.
- Le renommage des partitions n'est pas accepté.
- La suppression de tables ou de bases de données ne supprime pas les fichiers associés de Cloud Storage.
- La recherche non sensible à la casse n'est pas acceptée.
- Le clustering et le bucketing ne sont pas acceptés.
- Les vues de table ne sont pas acceptées.
Taille de 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 pour une utilisation dans l'élagage des partitions. Il est optimisé pour les lectures plutôt que pour les écritures, ce qui permet d'améliorer les performances des requêtes grâce à l'élagage des partitions.
Pour optimiser les performances d'ingestion des partitions, la taille de lot des partitions 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'est pas compatible avec les types de données
ARRAY<ARRAY<>>ouARRAY<MAP<>>. La compatibilité avecMAPdoit être ajoutée à une liste d'autorisation. Contactez biglake-help@google.com si vos charges de travail utilisentMAPde manière intensive. - Les types de clés
MAPne sont compatibles qu'avec les types de données primitifs. Vous ne pouvez pas utiliserARRAY,STRUCTniMAPcomme types de clés. - Pendant l'aperçu, BigQuery ne peut interroger que les données 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.
- Les URI d'emplacement de table ne peuvent pas inclure de caractère générique (
Limites de la réplication interrégionale et de la reprise après sinistre
Le catalogue d'environnements d'exécution Lakehouse propose une réplication interrégionale et une 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 ne fournissent pas de capacités de reprise après sinistre complètes, telles que le basculement initié par l'utilisateur.
Lorsque vous créez un catalogue Hive, vous devez définir son
primary_locationpour qu'il corresponde à la région de votre bucket Cloud Storage. Le catalogue d'environnements d'exécution 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 d'environnements d'exécution Lakehouse.
Considérations concernant l'utilisation du 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 du metastore Hive. Cette conception privilégie la compatibilité avec le ExternalCatalog Spark, qui ne nécessite pas une compatibilité totale avec le metastore Hive.
Mappage des ressources
Le tableau suivant mappe les ressources du metastore Hive aux ressources du catalogue d'environnements d'exécution Lakehouse et à leurs autorisations IAM (Identity and Access Management) requises.
| Ressource du metastore Hive | Ressource du 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 metastore 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 acceptée.
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
BatchCreateHivePartitionslimite les appels à 900 partitions.