Comprendre la terminologie de base du lakehouse sans frontières vous aide à évaluer les architectures de lakehouse et à configurer les catalogues, les tables, les moteurs de requête et la gouvernance sur Google Cloud. Chaque entrée définit un concept clé utilisé dans la documentation Lakehouse et renvoie vers des guides détaillés. Pour obtenir une vue d'ensemble de l'intégration de ces composants, consultez la section Fonctionnement du lakehouse sans limites.
Principes de base des lakehouses
Les concepts suivants constituent la base de l'architecture Lakehouse de Google Cloud.
Data lakehouse
Un data lakehouse combine les économies et la flexibilité d'un lac de données avec la gestion des données et les performances d'un entrepôt de données. Il vous permet de stocker des données dans des formats ouverts sur Cloud Storage et d'utiliser les fonctionnalités de BigQuery, telles que des contrôles de sécurité précis et des requêtes rapides.
Architecture en médaillon
Un modèle de conception courant dans un data lakehouse est l'architecture en médaillon, qui organise logiquement les données en couches progressives de structure et de qualité :
- Couche Bronze (brute) : ingère et stocke les données brutes dans des formats ouverts tels qu'Apache Iceberg sur Cloud Storage.
- Couche Silver (nettoyée) : nettoie, filtre et enrichit les données brutes dans des tables standardisées.
- Couche Or (organisée) : fournit des tables entièrement organisées et agrégées au niveau de l'entreprise. BigQuery est souvent utilisé pour diffuser la couche Gold pour la consommation, la création de rapports et l'analyse hautes performances.
Interopérabilité ouverte
L'interopérabilité ouverte est la capacité de plusieurs systèmes analytiques et transactionnels (tels que BigQuery, Apache Spark, Apache Flink et Trino) à opérer sur une seule copie de données dans des formats ouverts tels qu'Apache Iceberg. Cela élimine le besoin de dupliquer les données et fournit une vue cohérente des données entre les outils.
Catalogue d'environnements d'exécution Lakehouse
Le catalogue d'environnements d'exécution Lakehouse est un service de métadonnées centralisé et sans serveur qui sert de source unique de vérité pour le Lakehouse de Google Cloud. Il permet à plusieurs moteurs, tels qu'Apache Spark, Apache Flink, Trino et BigQuery, de découvrir et d'interroger simultanément les mêmes tables. Les moteurs s'y connectent via des points de terminaison de catalogue. Pour en savoir plus, consultez À propos du catalogue d'environnements d'exécution Lakehouse.
Hiérarchie des ressources
Le catalogue d'exécution Lakehouse organise les métadonnées selon une hiérarchie qui s'aligne sur les normes Apache Iceberg et mappe les identités logiques aux chemins de stockage physiques.
Catalogue
Un catalogue est le conteneur logique de premier niveau dans le catalogue d'environnements d'exécution Lakehouse. Il définit l'emplacement de stockage des données de la table et la région qui diffuse ses métadonnées. Pour en savoir plus, consultez Créer un catalogue.
Types de catalogues
Lorsque vous créez un catalogue, vous choisissez entre deux modèles de stockage :
- Catalogue à plusieurs buckets (recommandé) : vous permet de nommer votre catalogue indépendamment et de configurer un emplacement de stockage par défaut (
default_location) et jusqu'à 128 buckets ou sous-chemins Cloud Storage supplémentaires dansrestricted_locations. Lorsque vous configurez des moteurs de requête client (tels que Spark ou Trino), définissez le chemin d'accès de l'entrepôt surbl://projects/PROJECT_ID/catalogs/CATALOG_ID. - Catalogue à bucket unique : ancienne configuration dans laquelle le catalogue est verrouillé sur un seul bucket Cloud Storage et hérite du nom du bucket.
Lorsque vous configurez des moteurs de requête client, définissez le chemin d'accès de l'entrepôt sur
gs://CLOUD_STORAGE_BUCKET_NAME.
Pour en savoir plus, consultez Catalogues et emplacements de stockage.
Espace de noms
Un espace de noms est un regroupement logique de tables dans un catalogue. Pour les utilisateurs habitués à BigQuery, un espace de noms est fonctionnellement semblable à un ensemble de données. Les espaces de noms héritent de la région de leur catalogue parent et ne sont pas compatibles avec l'imbrication.
Table
Une table est l'entité qui pointe vers des données dans Cloud Storage. Pour les tables Apache Iceberg, les métadonnées de la table contiennent le schéma, les informations de partitionnement et un pointeur vers l'état actuel de la table via un fichier metadata.json. Pour connaître les types de tables compatibles avec Lakehouse, consultez Types de tables.
Convention d'attribution de noms P.C.N.T
La convention d'attribution de noms P.C.N.T est une convention en quatre parties utilisée pour identifier et interroger de manière unique les tables du catalogue d'environnements d'exécution Lakehouse à partir de BigQuery. Il s'agit de l'abréviation de Project.Catalog.Namespace.Table :
- Projet : ID du projet Google Cloud .
- Catalogue : nom du catalogue dans le catalogue d'environnement d'exécution Lakehouse.
- Espace de noms : regroupement logique des tables (semblable à un ensemble de données).
- Table : nom de la table de données.
Points de terminaison du catalogue
Un point de terminaison de catalogue est une interface de protocole que les moteurs de requête utilisent pour se connecter au catalogue d'environnements d'exécution Lakehouse. Le point de terminaison que vous utilisez détermine les formats de table et les moteurs avec lesquels vous pouvez travailler.
Point de terminaison du catalogue REST Apache Iceberg
Le point de terminaison du catalogue REST Apache Iceberg implémente l'API de catalogue REST Iceberg, qui est une norme ouverte. Il s'agit du point de terminaison recommandé pour les nouvelles charges de travail. Il offre une interopérabilité en lecture et en écriture entre les moteurs Open Source et BigQuery. Il est compatible avec les catalogues de buckets multiples, la distribution d'identifiants et la réplication interrégionale (preview). Pour en savoir plus, consultez la présentation du point de terminaison du catalogue REST Apache Iceberg.
Point de terminaison du catalogue Apache Hive
Le point de terminaison du catalogue Apache Hive assure la compatibilité avec les charges de travail Open Source qui dépendent de l'interface du metastore Apache Hive (HMS). Étant donné que le catalogue d'environnements d'exécution Lakehouse diffuse ce point de terminaison, vous pouvez exécuter des charges de travail Apache Hive ou Spark sans avoir à gérer un metastore Hive auto-hébergé. Le point de terminaison gère les tables Hive et Spark standards plutôt que les tables Apache Iceberg, et accepte les clés de chiffrement gérées par le client (CMEK) pour les données dans Cloud Storage. Pour en savoir plus, consultez À propos du point de terminaison du catalogue Hive.
Catalogue Apache Iceberg personnalisé pour BigQuery
Le catalogue Apache Iceberg personnalisé pour BigQuery est une intégration antérieure qui utilise un plug-in de catalogue (BigQueryMetastoreCatalog) pour permettre aux moteurs Open Source de stocker les définitions de table Apache Iceberg dans BigQuery. Les espaces de noms sont mappés sur des ensembles de données BigQuery. Vous pouvez donc interroger ces tables à l'aide de la syntaxe d'ensemble de données BigQuery standard. Pour les nouvelles charges de travail, utilisez plutôt le point de terminaison du catalogue REST Apache Iceberg. Pour en savoir plus, consultez Catalogue Apache Iceberg personnalisé pour BigQuery.
Types de tables
Le lakehouse Google Cloud est compatible avec plusieurs types de tables, en fonction du moteur utilisé pour gérer les données et du point de terminaison de catalogue que vous utilisez. Pour une comparaison détaillée, consultez Comparer les types de tables.
Tables Apache Iceberg dans le catalogue d'environnements d'exécution Lakehouse
Il s'agit de tables Apache Iceberg que le catalogue d'exécution Lakehouse gère et diffuse via le point de terminaison du catalogue REST Apache Iceberg, avec des données stockées dans Cloud Storage. Les moteurs Open Source disposent d'un accès en lecture et en écriture à ces tables. BigQuery dispose d'un accès en lecture et d'un accès en écriture (preview) lorsque vous activez le LMD BigQuery. Il s'agit de l'option recommandée pour la plupart des charges de travail de lakehouse ouvertes. Pour en savoir plus, consultez Gérer les tables Apache Iceberg.
Tables Apache Hive
Il s'agit de tables Apache Hive et Spark standards, dans des formats tels que Parquet, ORC, Avro et Delta Lake, que le catalogue d'environnements d'exécution Lakehouse gère via le point de terminaison du catalogue Apache Hive. Les moteurs Open Source disposent d'un accès en lecture et en écriture, et BigQuery d'un accès en lecture seule. Pour utiliser des tables Delta Lake, vous devez les créer avec un moteur compatible avec Delta, tel qu'Apache Spark, et les enregistrer dans le métastore. Pour en savoir plus, consultez Formats et types de stockage compatibles.
les tables BigQuery
Ces tables sont gérées avec BigQuery.
Tables gérées Apache Iceberg
Il s'agit de tables Apache Iceberg que vous créez à partir de BigQuery et que vous stockez dans Cloud Storage. BigQuery gère l'ensemble de la mise en page et de l'optimisation des données. Bien que plusieurs moteurs puissent lire ces tables, BigQuery est le seul à pouvoir y écrire directement. Ces tables sont distinctes des tables Apache Iceberg du catalogue d'environnements d'exécution Lakehouse. Pour en savoir plus, consultez Tables gérées Apache Iceberg.
Tables natives
Ces tables sont gérées par BigQuery et stockent les données dans l'espace de stockage BigQuery. Vous pouvez connecter ces tables au catalogue d'environnements d'exécution Lakehouse.
Tables externes
Les tables externes résident en dehors du catalogue d'environnements d'exécution Lakehouse. Leurs données et métadonnées sont autogérées dans un espace de stockage tel que Cloud Storage, Amazon S3 ou Azure Blob Storage, et BigQuery y accède via des connexions. BigQuery ne peut que lire ces tables.
Fonctionnalités et options des tableaux
Sauf indication contraire, les fonctionnalités suivantes s'appliquent aux tables Apache Iceberg du catalogue d'environnements d'exécution Lakehouse.
Versions de table Apache Iceberg
Le catalogue d'environnements d'exécution Lakehouse est compatible avec les tables Apache Iceberg V2 et V3 (preview). Les tables V3 sont compatibles avec les vecteurs de suppression binaire, qui vous permettent de supprimer des lignes spécifiques sans réécrire des fichiers de données entiers. Les tables Iceberg V1 ne sont pas compatibles. Vous devez d'abord les mettre à niveau vers la version V2. Pour en savoir plus, consultez Utiliser des vecteurs de suppression binaire dans les tables Iceberg V3.
Évolution de la table
L'évolution des tables vous permet de modifier le schéma ou la spécification de partition d'une table au fil du temps sans réécrire les données de la table ni recréer la table. Les tables Apache Iceberg du catalogue d'environnements d'exécution Lakehouse sont également compatibles avec les noms de colonnes flexibles par défaut. Les noms de colonnes peuvent donc contenir des caractères tels que des espaces et des caractères internationaux.
Fonctionnalité temporelle
La fonctionnalité temporelle vous permet d'interroger les données d'une table telles qu'elles existaient à un moment précis ou à un ID d'instantané spécifique. Cela est utile pour l'audit, la reproduction de tests ou la restauration de données après une suppression accidentelle. Les moteurs Open Source peuvent voyager dans le temps dans la limite de la durée de conservation configurée dans les propriétés de la table, tandis que le voyage dans le temps BigQuery est limité à sept jours.
Options du tableau
Les options de table sont des propriétés de table qui activent des fonctionnalités gérées par Google pour des tables Apache Iceberg individuelles. Pour en savoir plus, consultez Configurer les options de table.
BigQuery DML
Le LMD BigQuery est en version preview. Lorsque vous définissez la propriété de table gcp.biglake.bigquery-dml.enabled, BigQuery peut créer, modifier et modifier la table à l'aide d'instructions LDD et LMD GoogleSQL (INSERT, UPDATE, DELETE et MERGE), tandis que les moteurs Open Source continuent de lire et d'écrire dans la même table.
Gestion des tables
La gestion des tables (preview) automatise la maintenance du stockage pour les tables Apache Iceberg. Lorsque vous définissez la propriété de table gcp.biglake.table-management.enabled, Lakehouse exécute en arrière-plan la compaction (coalesce), l'expiration des instantanés et la récupération de mémoire pour maintenir les performances des requêtes et l'efficacité du stockage. La gestion des tables nécessite que le catalogue utilise la distribution d'identifiants. Pour en savoir plus, consultez Activer la gestion des tables.
Historique des modifications
L'historique des modifications vous permet d'utiliser la fonction de valeur de table GoogleSQL APPENDS pour suivre les lignes ajoutées aux tables gérées Apache Iceberg sur une période spécifiée. Vous pouvez l'utiliser pour gérer de manière incrémentielle les instances répliquées, auditer les ajouts de données ou déclencher des pipelines en aval sans analyser l'intégralité de la table. Pour en savoir plus, consultez Utiliser l'historique des modifications.
Mise en cache de métadonnées
La mise en cache des métadonnées accélère les performances des requêtes pour les tables externes BigQuery. Il stocke une copie des métadonnées de la table dans l'espace de stockage BigQuery, ce qui réduit la nécessité de lire les fichiers de métadonnées depuis Cloud Storage lors de l'exécution de la requête.
Ingestion et migration des données
Lakehouse propose plusieurs méthodes pour charger des données dans des tables Apache Iceberg et déplacer des métadonnées à partir de metastores existants.
Importations de tables par lots
Les modèles de compilateur de jobs Dataflow vous permettent d'importer des tables Apache Iceberg, des tables Delta Lake et des fichiers Parquet existants dans des tables Apache Iceberg gérées par Lakehouse sans écrire de code.
Ingestion en flux continu
Vous pouvez diffuser des données en flux continu dans des tables Apache Iceberg à l'aide de moteurs Open Source (tels que Spark ou Kafka), de Dataflow ou de l'API BigQuery Storage Write (gRPC), qui fournit des écritures transactionnelles "exactement une fois". Vous pouvez également écrire le résultat des requêtes continues BigQuery directement dans des tables gérées Apache Iceberg.
Capture de données modifiées (CDC)
L'ingestion CDC synchronise les tables Apache Iceberg avec les systèmes sources en appliquant des insertions, des mises à jour et des suppressions au lieu de recharger des tables complètes. Les tables gérées Apache Iceberg sont compatibles avec l'ingestion CDC BigQuery (preview), et vous pouvez utiliser Dataflow pour migrer les journaux CDC depuis des tables Apache Iceberg et Delta Lake (preview).
Migration de metastore
La migration de metastore déplace les métadonnées de table des metastores existants vers le catalogue d'environnements d'exécution Lakehouse sans copier les fichiers de données. Vous pouvez exécuter une migration ponctuelle ou un dry run depuis Dataproc Metastore vers le point de terminaison du catalogue Apache Iceberg REST ou le point de terminaison du catalogue Apache Hive, ou migrer depuis des métastores externes tels que Hive Metastore (preview).
Accès aux données cross-cloud
L'accès aux données cross-cloud vous permet d'interroger les données stockées dans d'autres clouds et plates-formes SaaS directement depuis Google Cloud, sans migrer de fichiers ni créer de pipelines ETL. Pour en savoir plus, consultez À propos de l'accès aux données cross-cloud.
Catalogue fédéré
Un catalogue fédéré est un catalogue du catalogue d'environnements d'exécution Lakehouse qui se connecte à un fournisseur de catalogue distant et expose ses tables via le point de terminaison du catalogue REST Apache Iceberg. Vous pouvez ensuite interroger ces tables avec BigQuery, Managed Service pour Apache Spark ou Apache Spark. Les fournisseurs de catalogues distants compatibles incluent Databricks Unity Catalog, AWS Glue Data Catalog, Snowflake Horizon Catalog, Workday Data Lake et SAP Business Data Cloud (SAP BDC). Pour en savoir plus, consultez Interroger des données distantes.
Actualisation des métadonnées en arrière-plan
L'actualisation des métadonnées en arrière-plan est le processus par lequel un catalogue fédéré synchronise régulièrement les métadonnées d'espace de noms et de table à partir du catalogue distant, en fonction d'un intervalle d'actualisation. Lakehouse s'authentifie auprès du catalogue distant à l'aide de la fédération de jetons OIDC ou d'identifiants stockés dans Secret Manager.
Transport cross-cloud
L'accès aux données cross-cloud sépare l'actualisation des métadonnées en arrière-plan du transport des données de requête. Vous pouvez acheminer l'un ou l'autre, ou les deux, sur l'Internet public ou en privé via interconnexion cross-cloud pour répondre aux exigences de sécurité et de coût. Pour limiter l'exfiltration de données, vous pouvez également protéger les points de terminaison du catalogue fédéré avec VPC Service Controls.
Mise en cache multicloud
La mise en cache cross-cloud stocke localement les blocs de fichiers lus à partir du stockage d'objets distant dans la région Google Cloud où les requêtes sont exécutées. Ainsi, les requêtes répétées sont lues à partir du cache plutôt que du cloud distant. La mise en cache permet de réduire les coûts de sortie cross-cloud. Elle est désactivée par défaut. Vous pouvez l'activer sur un catalogue fédéré ou une connexion cross-cloud BigQuery. Pour en savoir plus, consultez Mise en cache intelligente.
Mode d'identité
Le mode d'identité détermine l'identité qui exécute les requêtes sur un catalogue distant :
- Identité de service (par défaut) : l'actualisation des métadonnées en arrière-plan et les requêtes s'exécutent en tant que compte de service du catalogue.
- Fédération des identités des utilisateurs : les requêtes s'exécutent en tant qu'identité de l'utilisateur final, ce qui permet au catalogue distant d'appliquer ses propres autorisations et d'attribuer des journaux d'audit à des utilisateurs individuels. Ce mode est compatible avec Databricks Unity Catalog.
Intégration SAP BDC
L'intégration SAP BDC fonctionne dans les deux sens. La fédération synchronise les partages SAP BDC dans Lakehouse à l'aide du protocole Delta Sharing afin que vous puissiez les interroger depuis BigQuery. La publication partage des tables Apache Iceberg ou des produits de données Knowledge Catalog avec SAP BDC sans migrer les données. Pour en savoir plus, consultez À propos de l'intégration de SAP BDC.
Ensembles de données publics
Borderless Lakehouse héberge des ensembles de données publics diffusés via le point de terminaison du catalogue REST Apache Iceberg, ce qui permet un accès en lecture seule pour l'exploration et les tests sans avoir à gérer l'infrastructure. Google prend en charge le stockage, et vous ne payez que pour les requêtes que vous exécutez. Pour en savoir plus, consultez Ensembles de données publics.
Sécurité et gouvernance
Lakehouse combine Identity and Access Management (IAM), la délégation d'accès au stockage et les contrôles réseau pour sécuriser votre lakehouse.
Contrôle des accès au niveau des ressources
Les stratégies IAM sur les catalogues, les espaces de noms et les tables contrôlent qui peut afficher et modifier les ressources Lakehouse. Pour en savoir plus, consultez Gérer les LCA de catalogue, d'espace de noms et de table et Rôles et autorisations.
Distribution d'identifiants
La distribution d'identifiants est un mécanisme de sécurité qui renforce le contrôle des accès lors de l'utilisation du catalogue d'environnements d'exécution Lakehouse. Au lieu d'accorder aux utilisateurs des autorisations directes sur les buckets, le point de terminaison du catalogue REST Apache Iceberg fournit des identifiants de stockage de courte durée et à champ d'application restreint, avec un accès limité aux chemins de table spécifiques dont une requête a besoin. La distribution d'identifiants est également requise pour la gestion des tables. Pour en savoir plus, consultez Distribution d'identifiants.
Connexions
Une connexion est une ressource BigQuery qui stocke les identifiants permettant d'accéder à des données externes. Dans Lakehouse de Google Cloud, les connexions délèguent l'accès à Cloud Storage en permettant au compte de service de la connexion d'accéder au bucket de stockage en votre nom.
VPC Service Controls
Les périmètres de service VPC Service Controls permettent d'empêcher l'exfiltration de données en limitant l'accès à l'API Lakehouse (biglake.googleapis.com) et aux buckets Cloud Storage qui stockent les données des tables. Pour en savoir plus, consultez Utiliser VPC Service Controls avec la distribution d'identifiants.
Points de terminaison régionaux
Les points de terminaison régionaux limitent les requêtes de sorte qu'elles ne soient traitées que si la ressource de catalogue cible existe dans l'emplacement spécifié par le point de terminaison, ce qui vous aide à respecter les exigences de résidence des données. Pour en savoir plus, consultez Points de terminaison régionaux.
Journaux d'audit
Cloud Audit Logs enregistre l'activité d'administration et d'accès aux données sur les ressources Lakehouse. Pour en savoir plus, consultez Afficher les journaux d'audit.
Gouvernance unifiée
La gouvernance unifiée vous permet de définir et d'appliquer des règles de sécurité et de gestion des données de manière centralisée grâce à l'intégration à Knowledge Catalog. Lorsque vous enregistrez des tables dans le catalogue d'exécution Lakehouse, le système enregistre automatiquement les entrées correspondantes dans Knowledge Catalog. Cela permet d'effectuer des recherches et des découvertes, de suivre la traçabilité des données, de profiler les données et de générer des insights sur les données (preview) à l'aide de l'IA sur l'ensemble des moteurs, sans déplacer ni copier de fichiers.
Moteurs et outils de requêtes
Le lakehouse de Google Cloud dissocie le stockage du calcul, ce qui permet à différents moteurs d'analyse de travailler avec les mêmes tables ouvertes.
Moteurs Open Source
Les moteurs Open Source se connectent au catalogue d'environnements d'exécution Lakehouse via le point de terminaison du catalogue REST Apache Iceberg à l'aide de la configuration client Apache Iceberg standard. Pour une configuration spécifique au moteur, consultez Apache Spark, Apache Flink et Trino. Vous pouvez également gérer les ressources Lakehouse avec Terraform.
Managed Service pour Apache Spark
Managed Service pour Apache Spark (anciennement Dataproc sans serveur) fournit un environnement d'exécution entièrement géré pour le traitement des formats de table ouverts tels qu'Apache Iceberg. Il accepte deux principaux modes d'exécution :
- Lots sans serveur : conçus pour les pipelines de traitement de données automatisés et non interactifs, ainsi que pour les charges de travail ETL. Ce modèle de paiement par exécution élimine la gestion des clusters, supprime les conflits de ressources entre les jobs et automatise la maintenance de l'infrastructure.
- Sessions interactives sans serveur : conçues pour l'analyse exploratoire des données, l'ingénierie des données et l'expérimentation en data science. Les sessions interactives alimentent les notebooks Apache Spark à l'aide de Spark Connect ou de kernels Spark distants, fournissant un environnement d'autoscaling sans configuration d'infrastructure.
Niveaux de service
Lorsque vous exécutez des charges de travail Apache Spark sur Managed Service pour Apache Spark, vous pouvez choisir entre plusieurs niveaux de service :
- Niveau Standard : niveau d'exécution par défaut adapté aux charges de travail de traitement par lot standards.
- Niveau Premium : fournit des fonctionnalités avancées, y compris la prise en charge des sessions de notebook interactives sans serveur et des fonctionnalités d'accélération des performances telles que Lightning Engine.
Modèles de session
Les modèles de session simplifient la configuration des sessions interactives sans serveur.
Ils permettent aux administrateurs de définir et de conserver des paramètres d'environnement courants (tels que les propriétés du catalogue, les configurations réseau et les versions d'exécution), ce qui favorise la cohérence et réduit les configurations répétées. Vous pouvez créer et gérer des modèles de session à l'aide de la console Google Cloud , de la CLI gcloud, de l'API REST ou de Terraform.
Conversational Analytics
L'analyse conversationnelle (preview) vous permet d'interroger des tables du catalogue d'environnements d'exécution Lakehouse, y compris des sources cross-cloud, à l'aide de requêtes en langage naturel dans BigQuery.
Fiabilité
Le catalogue d'environnements d'exécution Lakehouse fournit une reprise après sinistre gérée pour les catalogues qui utilisent le point de terminaison du catalogue REST Apache Iceberg (preview). Pour en savoir plus, consultez À propos de la réplication interrégionale et de la reprise après sinistre.
Réplication interrégionale
La réplication interrégionale copie les métadonnées du catalogue d'une région principale vers une région secondaire lorsque le catalogue utilise un bucket Cloud Storage birégional ou multirégional, ce qui permet de maintenir la disponibilité du catalogue pendant les pannes régionales. Cloud Storage réplique les données de la table sous-jacente.
Basculement
Le basculement change les régions principale et secondaire d'un catalogue, ainsi que de tous ses espaces de noms et tables. Un basculement progressif attend que toutes les données soient synchronisées avant que la nouvelle instance principale n'accepte les écritures, ce qui évite la perte de données et convient aux tests planifiés. Un basculement forcé donne la priorité à la disponibilité et permet à la nouvelle instance principale de prendre le relais, même si l'instance principale précédente est inaccessible.