Bonnes pratiques pour les charges de travail mutualisées sur BigQuery

Ce document présente les techniques et les bonnes pratiques pour les modèles courants utilisés dans les plateformes de données mutualisées et les magasins de données d'entreprise.

Les entreprises commerciales, les fournisseurs de services SaaS (Software as a Service) et les organisations gouvernementales doivent souvent héberger des données internes et tierces en tenant compte de limites géographiques et administratives. BigQuery est un outil puissant capable de répondre de manière cohérente aux exigences de la plate-forme mutualisée pour des exaoctets de données et des centaines de milliers de consommateurs de données sur des unités commerciales disparates. Ce document est destiné aux organisations qui déploient des plates-formes mutualisées sur BigQuery et qui souhaitent comprendre les contrôles d'accès et les fonctionnalités de gestion des performances disponibles.

Les concepteurs de plates-formes mutualisées doivent souvent équilibrer les points suivants :

• Isolation des données : mettre en œuvre des contrôles stricts pour éviter les fuites de données entre les locataires.
• Constance des performances : configurer et répartir des réservations BigQuery pour maintenir des performances constantes sur tous les locataires.
• Gestion des ressources : planifier l'impact des quotas et des limites.
• Répartition géographique : rechercher les données dans les emplacements géographiques désignés et requis. Pour les questions liées à la conformité, consultez les offres de conformité de Google Cloud.
• Audit et sécurité : protéger les données des locataires des accès inappropriés et de l'exfiltration.
• Gestion des coûts : s'assurer que les coûts BigQuery pour héberger chaque locataire sont constants.
• Complexité opérationnelle : minimiser la variabilité du système nécessaire pour héberger de nouveaux locataires.

Fournisseur SaaS avec une infrastructure à locataire partagée

Les fournisseurs SaaS qui hébergent des données tierces doivent garantir la fiabilité et l'isolation pour l'intégralité de leur parc de clients. Ces clients peuvent se compter par dizaines de milliers et les données client peuvent être accessibles via une infrastructure de services partagés. Certains fournisseurs SaaS disposent également d'un datastore nettoyé et centralisé afin d'effectuer des analyses sur l'ensemble de leur parc de locataires.

Une conception avec un ensemble de données par locataire permet de réduire les problématiques suivantes qu'une entreprise peut connaître lorsqu'elle évolue vers des milliers de locataires :

• Complexité administrative : le nombre total de nouveaux projets et ressources cloud par client.
• Latence de bout en bout : mise à jour du datastore pour les locataires et les solutions d'analyse multiclients
• Exigences de performance : s'assurer que les performances du locataire restent dans les limites acceptables

Configurer des ensembles de données pour chaque locataire

Dans un projet dédié au stockage de données client, les données de chaque client sont séparées par des ensembles de données BigQuery. Dans l'organisation hôte, vous utilisez un second projet pour déployer l'analytique et le machine learning sur des données client combinées. Vous pouvez ensuite configurer le moteur de traitement des données, Dataflow, pour écrire les données entrantes en double, dans les tables internes et spécifiques aux locataires. La configuration Dataflow utilise des tables entièrement écrites plutôt que des vues autorisées. L'utilisation de tables entièrement écrites permet une gestion uniforme de la distribution géographique et permet d'éviter d'atteindre les limites des vues autorisées lorsque le nombre de locataires évolue.

La séparation du stockage et des ressources de calcul dans BigQuery permet de configurer un nombre réduit de projets pour gérer des problèmes tels que les niveaux de service et l'isolation des données, en comparaison aux entrepôts basés sur des clusters. Lorsque vous n'avez pas besoin de configurer des locataires avec des ressources cloud dédiées supplémentaires, nous vous recommandons de considérer la configuration par défaut qui consiste à utiliser un ensemble de données dédié pour chaque locataire. Le schéma suivant illustre un exemple de configuration de projet basé sur cette conception recommandée :

Figure 1 : Un nombre constant de projets gère les besoins en données et en traitement à mesure que le nombre de locataires augmente.

La configuration de projet de la figure 1 inclut les projets suivants :

• Projet de pipeline de données : les principaux composants d'infrastructure qui reçoivent, traitent et distribuent les données des locataires sont empaquetés dans un seul projet.
• Projet de données de locataires combinées : le projet de données principal qui gère un ensemble de données par client. Il est prévu que les données des locataires soient accessibles via des projets de niveau de calcul.
• Projets de développement interne : projets représentant les ressources autogérées que les équipes d'analyse utilisent pour évaluer les données des locataires et créer de nouvelles fonctionnalités.
• Projets d'application des utilisateurs finaux : projets contenant des ressources conçues pour interagir avec les utilisateurs finaux. Nous vous recommandons d'utiliser des comptes de service à l'échelle du locataire pour accéder aux ensembles de données locataires et de déployer des applications à l'aide d'un pipeline de compilation robuste et sécurisé.
• Projets de niveau de calcul de réservation : projets qui mappent l'activité de requête du locataire aux réservations BigQuery.

Partager des réservations

Dans cette approche, les réservations reposent sur l'algorithme de planification équitable intégré aux réservations BigQuery. Chaque réservation de niveau de calcul est attribuée à un seul projet. Les requêtes locataires utilisent des emplacements de planification équitables disponibles pour tous les projets et niveaux de calcul, et les emplacements inutilisés de tous les niveaux sont automatiquement réutilisés dans un autre niveau. Si un locataire a des exigences de planification spécifiques, vous pouvez utiliser une paire projet/réservation dédiée afin de fournir un nombre exact d'emplacements.

Configurer des périmètres VPC Service Controls

Dans cette configuration, nous vous recommandons d'utiliser les périmètres VPC Service Controls pour éviter toute exposition accidentelle d'ensembles de données à l'extérieur de votre organisation Google Cloud et pour empêcher la jointure non autorisée des données au sein de l'entreprise.

Périmètres

Dans cette configuration, nous vous recommandons de créer les périmètres de service suivants :

• Pipeline de données : un périmètre autour des projets de pipeline de données doit appliquer tous les services qui n'ont pas besoin de recevoir des données de locataires.
• Données locataires : un périmètre autour du projet de l'ensemble de données locataire et autour des projets de calcul BigQuery locataires. Appliquer tous les services pour empêcher l'accès en dehors de l'organisation.
• Applications internes : appliquez tous les services et utilisez des niveaux d'accès pour accorder l'accès aux ressources aux équipes de service.
• Applications externes : périmètre autour de vos applications SaaS. Appliquez tous les services qui ne sont pas nécessaires au bon fonctionnement des applications.

Liaisons de périmètre

Dans cette configuration, nous vous recommandons de créer les liaisons de périmètre suivantes :

• Pipeline de données et données des locataires : permet au pipeline d'écrire des données dans des ensembles de données locataires.
• Pipeline de données et applications internes : permettent au pipeline d'écrire des données dans l'ensemble de données multiclients.
• Applications externes et données des locataires : autorisez les applications externes à interroger les données des locataires.
• Applications externes et applications internes : permettent aux applications externes de traiter des données à l'aide de modèles que les applications internes développent et déploient.

Fournisseur SaaS avec une infrastructure à locataire dédiée

Dans les scénarios plus complexes, les fournisseurs SaaS peuvent déployer une infrastructure de calcul dédiée pour chaque locataire. Dans ce scénario, l'infrastructure dédiée est responsable de la diffusion des requêtes de données de locataire dans BigQuery.

Une conception d'infrastructure de locataire dédiée répond aux préoccupations courantes suivantes lors du déploiement d'infrastructure pour chaque locataire parallèlement à BigQuery :

• Responsabilité de facturation : suivi des coûts d'infrastructure associés à chaque locataire intégré.
• Latence de bout en bout : mise à jour du datastore pour les locataires et les solutions d'analyse multiclients.
• Exigences de performance : s'assurer que les performances du locataire restent dans les limites acceptables.

Regrouper des ensembles de données avec des ressources dédiées

Lorsque vous déployez une infrastructure locataire dédiée, nous vous recommandons de créer un dossier parent pour les projets spécifiques au locataire. Ensuite, rapprochez les ensembles de données BigQuery du locataire dans les projets contenant les ressources dédiées qui accèdent à ces données pour le compte du locataire. Pour réduire la latence de bout en bout pour les données de locataire, les pipelines Dataflow insèrent les données directement dans les ensembles de données de locataire.

Cette conception gère le traitement et la distribution des données en amont, semblable à la conception précédente de l'infrastructure partagée. Toutefois, les données et les applications locataires qui accèdent aux données des locataires sont organisées dans des projets spécifiques au locataire (et éventuellement organisées sous des dossiers dédiés au locataire) afin de simplifier la facturation et la gestion des ressources. Le schéma suivant illustre un exemple de configuration de projet basé sur cette conception recommandée :

Figure 2. Un projet de pipelines de données gère les données d'un locataire unique issues de plusieurs autres projets.

La configuration de projet de la figure 2 inclut les projets suivants :

• Projet de pipelines de données : les principaux composants d'infrastructure qui reçoivent, traitent et distribuent les données des locataires sont empaquetés dans un seul projet.
• Projets locataires dédiés : projets contenant toutes les ressources cloud dédiées à un seul locataire, y compris les ensembles de données BigQuery. Nous vous recommandons d'utiliser Identity and Access Management (IAM) pour limiter considérablement le champ d'application des comptes et des comptes de service qui peuvent accéder aux ensembles de données client.
• Projets d'analyse interne : projets représentant les ressources autogérées que les équipes d'analyse utilisent pour évaluer les données des locataires et créer de nouvelles fonctionnalités.
• Projet de mise en réseau externe : projet qui gère et achemine les requêtes des locataires vers leurs backends dédiés.

Partager des réservations

Dans cette approche, les réservations reposent sur l'algorithme de planification équitable intégré aux réservations BigQuery. Avec cette configuration, des réservations de niveau de calcul sont attribuées à chaque projet locataire qui utilise ce niveau. Si un locataire a des exigences de planification spécifiques, vous pouvez créer une réservation dédiée afin de fournir un nombre exact d'emplacements à un projet locataire.

Utiliser les contrôles IAM et désactiver la création de clés

Les périmètres VPC Service Controls peuvent ne pas être adaptés à ce scénario. Les limitations liées aux projets empêchent une organisation d'utiliser des limites de périmètre autour de projets qui interagissent avec les projets locataires. Au lieu de cela, nous vous recommandons d'utiliser des contrôles IAM stricts et de désactiver la création de clés afin de vous protéger contre les accès externes indésirables.

Magasin de données disposant d'une autorité centrale

Les magasins de données sont un thème de conception commun dans lequel les données d'analyse principales sont stockées dans un dépôt central et les sous-ensembles sont partagés entre les secteurs d'activité. Les magasins de données comptent fréquemment des dizaines ou des centaines de locataires qui représentent des secteurs d'activité à prendre en compte.

Une conception d'un magasin de données dans BigQuery répond aux besoins suivants :

• Collaboration sécurisée basée sur les données : partage de données avec des contrôles techniques pour limiter l'accès inapproprié aux différentes équipes.
• Gouvernance de données centralisée : s'assurer que les éléments de données principales utilisés pour les rapports d'entreprise critiques sont standardisés et validés.
• Attribution des coûts par unité commerciale : suivre et ajuster l'utilisation des calculs par unités commerciales.

Utiliser un dépôt géré de manière centralisée

Dans cette conception, les données principales sont capturées dans un dépôt géré de manière centralisée. Les vues autorisées, les fonctions définies par l'utilisateur autorisées (UDF) et les règles de colonne sont fréquemment utilisées ensemble pour partager des données avec des secteurs d'activité, tout en empêchant la distribution accidentelle de données sensibles.

Les équipes des projets locataires peuvent accéder aux ensembles de données régis de manière centralisée en fonction des privilèges de leur compte. Les équipes utilisent des emplacements alloués à leurs propres projets pour créer des rapports et des ensembles de données dérivés. L'équipe responsable des données utilise des vues autorisées pour garder la propriété complète du contrôle d'accès aux éléments du magasin de données. Dans cette configuration, nous vous recommandons d'éviter de créer plusieurs couches de vues sur les objets présentés par le projet de données principal. Le schéma suivant illustre un exemple de configuration de projet basé sur cette conception recommandée :

Figure 3. Un projet de données principal gère un magasin de données centralisé accessible depuis toute l'organisation.

La configuration de projet de la figure 3 inclut les projets suivants :

• Projet de données principal : le périmètre de gouvernance pour la gestion de l'accès aux données principales et aux vues du magasin de données. Vous conservez les vues autorisées dans les ensembles de données de ce projet, et vous accordez des vues autorisées à vos équipes d'analyse en fonction de l'appartenance à un groupe.
• Infrastructure d'extraction, de transformation et de chargement (ETL, Extract, Transform, Load) pour le traitement des sources de données en amont dans les données principales. Selon les besoins en séparation administrative, vous pouvez choisir de déployer l'infrastructure ETL en tant que projet unique ou au sein du projet de données principal.
• Projets d'équipe d'analyse : les clients du magasin de données utilisent ces projets et se servent de leur propre accès aux infrastructures provisionnées pour traiter les données dans le magasin de données. Ces projets doivent pouvoir créer des ensembles de données dérivés pour une utilisation locale.

Utiliser une conception de réservation à deux niveaux

Lorsque vous travaillez avec des magasins de données, nous vous recommandons d'utiliser une conception à deux niveaux. Dans une conception à deux niveaux, vous attribuez à la ressource d'organisation une réservation qui contient un petit nombre d'emplacements pour couvrir l'utilisation générale. Si les équipes ont des besoins plus importants, attribuez des réservations au niveau du projet ou du dossier.

Configurer des périmètres VPC Service Controls

Dans cette configuration, nous vous recommandons d'utiliser les périmètres VPC Service Controls pour éviter une exposition accidentelle d'ensembles de données BigQuery en dehors de votre organisation Google Cloud.

Périmètres

Dans cette configuration, nous vous recommandons de créer les périmètres de service suivants :

• Données principales : périmètre permettant de protéger l'entrepôt de données et les ensembles de données des magasins de données.
• Pipelines de données : périmètre du projet de l'infrastructure ETL. Si les pipelines de données doivent effectuer des requêtes en dehors de votre organisation Google Cloud, nous vous recommandons de séparer ce périmètre du périmètre de données principal.
• Analyse : périmètre permettant de créer et de déployer des éléments d'analyse internes à votre organisation. Ce périmètre doit avoir une règle d'accès plus permissive que le périmètre de données principal avec lequel il est lié.

Liaisons de périmètre

Dans cette configuration, nous vous recommandons de créer les liaisons de périmètre suivantes :

• Pipelines de données et données principales : permettent aux pipelines de données d'écrire dans le projet de données principal.
• Données et analyses principales : permettent aux utilisateurs des projets d'analyse d'interroger les vues autorisées.

Copier des ensembles de données pour des configurations multirégionales

Comme BigQuery interdit les requêtes interrégionales, vous ne pouvez pas utiliser la stratégie de segmentation des données avec des vues autorisées lorsque les magasins de données doivent exister dans plusieurs régions. À la place, vous pouvez utiliser le service de transfert de données BigQuery pour copier les ensembles de données pertinents dans une autre région. Dans ce scénario, vous créez des règles de colonne dans le catalogue de données pour chaque région supplémentaire dans laquelle se trouvent les données. Le schéma suivant représente une configuration multirégionale :

Figure 4. Une configuration multirégionale utilise le service de transfert de données BigQuery pour copier des ensembles de données entre différentes régions.

La configuration de projet de la figure 4 inclut les projets suivants :

• Projet de données principal : le périmètre de gouvernance pour la gestion de l'accès aux données principales et aux vues du magasin de données. Les données sont copiées et conservées dans des ensembles de données régionaux pouvant être transmis aux équipes à l'échelle mondiale.
• Infrastructure ETL : infrastructure permettant de traiter les sources de données en amont dans les données principales. Selon les besoins en séparation administrative, vous pouvez choisir de déployer l'infrastructure ETL en tant que projet unique ou au sein du projet de données principal.
• Projets d'équipe d'analyse : les clients du magasin de données utilisent ces projets et se servent de leur propre infrastructure provisionnée pour traiter les données dans les ensembles de données régionaux du magasin de données. Ces projets doivent pouvoir créer des ensembles de données dérivés pour une utilisation locale.

Le service de transfert de données BigQuery est un composant planifié supplémentaire disposant de quelques restrictions. Le programmeur de services intégré est limité à un intervalle d'au moins 15 minutes et il doit copier toutes les tables depuis l'ensemble de données source. Il n'existe aucun moyen d'intégrer des scripts supplémentaires pour créer des sous-ensembles de données spécifiques à la région dans le programmeur du service de transfert de données BigQuery.

Si votre organisation a besoin d'une plus grande flexibilité, les options suivantes sont disponibles :

• Tâches Cloud Composer : vous pouvez programmer des tâches Cloud Composer pour exécuter des tâches ETL qui créent des sous-ensembles régionaux avant de déclencher le service de transfert de données BigQuery via son API cliente. Nous vous recommandons cette option si votre organisation peut gérer la latence supplémentaire.
• Infrastructure ETL : une infrastructure ETL telle que Dataflow peut doubler l'écriture pour des sous-ensembles régionaux placés dans des régions cibles. Si votre organisation nécessite une latence de données minimale entre les régions, nous vous recommandons cette option.

Magasins de données disposant d'une autorité décentralisée

Utilisez l'autorité décentralisée lorsque vous avez besoin d'une séparation administrative par propriétaire de système, secteur d'activité ou problème géographique.

Un magasin de données décentralisé a les caractéristiques suivantes, différentes de celles d'un magasin de données standard :

• Collaboration sécurisée basée sur les données : partage de données avec des contrôles techniques pour limiter l'accès inapproprié aux différentes équipes.
• Visibilité des données : les équipes doivent pouvoir détecter et interroger l'accès aux ensembles de données.
• Provenance des données : sans équipe d'organisation centrale, les équipes doivent pouvoir être responsables de l'origine des données transmises par leurs produits d'analyse.

Déléguer l'administration des données principales

Cette conception est différente d'une approche traditionnelle de la gestion des données, car l'autorité décentralisée délègue les principales décisions d'administration des données aux sous-groupes de composants de l'organisation. Lorsque vous utilisez une autorité décentralisée, vous conservez un contrôle centralisé de la sécurité et de la capacité BigQuery à l'aide de Cloud Key Management Service (Cloud KMS), des stratégies de colonnes, de VPC Service Controls et des réservations. Ainsi, vous évitez la prolifération des données qui est courante avec les entrepôts autogérés. Le schéma suivant illustre une architecture utilisant une autorité décentralisée :

Figure 5. Un projet de gouvernance principal permet de garantir une sécurité cohérente pendant que des groupes individuels gèrent leurs opérations de données.

La configuration de projet de la figure 5 inclut les projets suivants :

• Projet de gouvernance principal : projet responsable des problématiques de gestion inter-organisation. Dans ce projet, vous créez des ressources de sécurité telles que des trousseaux de clés Cloud KMS et des règles de colonne de catalogue de données. Ce projet joue le rôle de projet d'administration des réservations BigQuery, ce qui permet le partage d'emplacements à l'échelle de l'organisation.
• Projets de données liées aux unités organisationnelles : propriétaires de magasins de données autogérés au sein de l'organisation dans son ensemble. Le projet de gouvernance principal gère le champ d'application restreint des projets de données liées aux unités organisationnelles.
• Projets d'équipe d'analyse : projets utilisés par les utilisateurs des magasins de données Ces projets utilisent leur infrastructure et leurs emplacements provisionnés pour accéder aux données et les traiter au sein du magasin de données.

Utiliser une conception de réservation à deux niveaux

Nous vous recommandons d'utiliser des magasins de données décentralisés dotés de la même conception à deux niveaux que les magasins de données standards. Dans cette conception, vous attribuez à la ressource d'organisation une réservation qui contient un petit nombre d'emplacements pour couvrir l'utilisation générale. Si les équipes ont des besoins plus importants, attribuez des réservations au niveau du projet ou du dossier.

Utiliser un catalogue de données

Le catalogue de données fournit des fonctionnalités de découverte, d'ajout de tags de métadonnées et de configuration de règles de colonnes, à l'échelle de l'organisation. La détection de Dataplex crée automatiquement des entrées de métadonnées pour toutes les nouvelles tables BigQuery de votre organisation. Les fonctionnalités de Dataplex aident également les administrateurs de la gouvernance des données à identifier rapidement les nouveaux éléments de données et à appliquer des contrôles appropriés.

Configurer des périmètres VPC Service Controls

Dans cette configuration, nous vous recommandons d'utiliser les périmètres VPC Service Controls pour éviter une exposition accidentelle d'ensembles de données BigQuery en dehors de votre organisation Google Cloud.

Périmètres

Dans cette configuration, nous vous recommandons de créer les périmètres de service suivants :

• Données principales : périmètre permettant de protéger l'entrepôt de données et les ensembles de données des magasins de données. Ce périmètre doit inclure tous les projets d'unités organisationnelles et le projet de gouvernance des données.
• Analytique : périmètre permettant de créer et de déployer des éléments d'analyse internes à l'organisation. Ce périmètre doit avoir une règle d'accès plus permissive que le périmètre de données principal avec lequel il est lié.

Liaisons de périmètre

Dans cette configuration, nous vous recommandons de créer les liaisons de périmètre suivantes :

• Données et analyses principales : permettent aux utilisateurs des projets d'analyse d'interroger les vues autorisées.

Partage de données multi-organisation

Le partage multi-organisation est un aspect particulier de la conception d'un magasin de données. Cette conception de partage de données est destinée aux organisations qui souhaitent partager de manière sécurisée leurs ensembles de données avec une autre entité disposant de sa propre organisation Google.

Le partage de données multi-organisation permet de répondre aux préoccupations suivantes concernant le partage de données :

• Partage de la confidentialité : seule la partie souhaitée peut accéder aux données partagées.
• Protection contre les accès inappropriés : seules les ressources destinées à être accessibles en externe sont accessibles.
• Séparation des calculs : les parties externes sont facturées pour les requêtes qu'elles lancent.

Protéger les projets internes des projets de données partagés

La conception de partage de données multi-organisation se concentre sur la protection des projets internes de l’organisation contre les activités dans des projets de données partagés. Le projet d'ensemble de données partagé sert de tampon pour interdire l'accès au traitement de données internes sensibles, tout en offrant la possibilité de partager des données en externe.

Les requêtes lancées à partir du projet externe utilisent les ressources de calcul du projet appelant. Si tous les ensembles de données interrogés partagent la même région Google Cloud, ces requêtes peuvent joindre des données appartenant à plusieurs organisations. Le schéma suivant montre comment les ensembles de données sont partagés dans une configuration de projet multi-organisation :

Figure 6. Une organisation externe interroge les données de plusieurs ensembles de données dans des projets partagés.

La configuration de projet de la figure 6 inclut les projets suivants :

• Projet interne de l'organisation : projet contenant des données internes sensibles. Le projet interne peut partager des données en externe en copiant les données nettoyées dans les ensembles de données du projet de données partagé. Le projet interne doit posséder le compte de service responsable de la mise à jour des données partagées.
• Projet de données partagées : projet contenant les informations nettoyées copiées à partir du projet interne. Utilisez des groupes d'utilisateurs externes pour gérer l'accès des tierces parties. Dans ce scénario, vous gérez l'appartenance à un groupe en tant que fonction administrative et vous autorisez les comptes externes à afficher l'ensemble de données par l'intermédiaire des groupes.

Configurer des périmètres VPC Service Controls

Dans cette configuration, nous vous recommandons d'utiliser les périmètres VPC Service Controls pour partager des données en externe et éviter l'exposition accidentelle d'ensembles de données BigQuery en dehors de vos projets internes.

Périmètres

Dans cette configuration, nous vous recommandons de créer les périmètres de service suivants :

• Données internes : périmètre servant à protéger les éléments de données principales. VPC Service Controls contrôle l'accès à BigQuery.
• Données partagées en externe : périmètre permettant d'héberger des ensembles de données pouvant être partagés avec des organisations externes. Ce périmètre désactive l'application de l'accès à BigQuery.

Liaisons de périmètre

Dans cette configuration, nous vous recommandons de créer la liaison de périmètre suivante :

• Données internes vers données externes : une liaison de périmètre permet aux projets de données internes plus protégés de sortir des données dans des projets de partage de données externes.

Informations complémentaires sur les systèmes mutualisés

Cette section se penche plus en profondeur sur des cas particuliers que vous pouvez prendre en compte avec les bonnes pratiques précédentes.

Limites et quotas de ressources Google Cloud

• Les comptes de service sont limités à un quota souple de 100 comptes de service par projet. Vous pouvez demander un quota via la console Google Cloud pour les projets qui gèrent des comptes de service locataires.
• Par défaut, BigQuery offre une simultanéité jusqu'à 100 requêtes par projet émetteur de requêtes (les projets contenant des ensembles de données ne font pas l'objet de telles limitations). Pour augmenter ce quota souple, contactez votre conseiller commercial.
• VPC Service Controls est limité à 10 000 projets dans les périmètres de service à l'échelle de l'organisation. Si votre conception basée sur un projet par locataire connaît un important scaling à la hausse, nous vous recommandons plutôt d'utiliser une conception avec un ensemble de données par locataire.
• VPC Service Controls est limité à 100 périmètres par organisation, y compris les liaisons.

Utiliser des vues autorisées ou des tables de sous-ensembles matérialisées

Pour gérer l'accès des locataires à des sous-ensembles de tables de faits importants, vous pouvez utiliser des vues autorisées spécifiques à un locataire ou créer des tables de sous-ensembles spécifiques à un locataire. Le tableau suivant compare ces approches :

Caractéristique	Vues autorisées	Tables de sous-ensembles
Nombre de locataires acceptés	Il existe une limite stricte de 2 500 vues autorisées par ensemble de données.	Les ressources autorisées incluent les vues autorisées, les ensembles de données autorisés et les fonctions autorisées. Le nombre d'ensembles de données dans un projet ou de tables dans un ensemble de données n'est pas limité.
Partitionnement et filtrage par cluster	Les vues autorisées doivent partager le schéma de partitionnement et de regroupement de la table de base. Pour améliorer les performances de la segmentation locataire, nous vous recommandons de regrouper la table parente sur l'ID de locataire.	Vous pouvez partitionner la table de sous-ensemble et la regrouper selon les besoins du locataire.
Régionalisation	Les vues autorisées ne peuvent pas être réparties sur plusieurs régions et doivent se trouver dans la région Google Cloud de la table de base. La régionalisation affecte les locataires géographiquement distants.	Les tables de sous-ensembles peuvent exister dans la région la plus appropriée pour le locataire. Des coûts supplémentaires peuvent s'appliquer.
Application des stratégies de colonnes	Les stratégies de colonnes d'une table de base sont appliquées à toutes les vues autorisées, indépendamment des autorisations accordées à ces vues.	Chaque tableau de sous-ensemble doit appliquer la stratégie de colonnes pour qu'elle soit prise en compte.
Journalisation des accès aux données	Les journaux d'accès aux données sont reflétés dans la journalisation de la table de base.	L'accès à chaque table de sous-ensemble est consigné séparément.
Flexibilité de transformation	Les vues autorisées permettent de redéfinir instantanément l'objet auquel les locataires accèdent.	Des modifications complexes des schémas sont requises pour modifier des tables de sous-ensembles.

Contrôler les données sensibles

Pour empêcher tout accès non autorisé aux données, BigQuery propose plusieurs fonctionnalités en plus des autorisations IAM standards.

Chiffrement fourni par le client

Le chiffrement des données client couvre les cas où une organisation d'hébergement stocke et traite les données pour le compte d'un locataire, mais ne peut pas accéder à certains contenus. Par exemple, l'organisation hôte peut être empêchée d'accéder aux données personnelles ou aux données d'appareils considérées comme sensibles.

Nous recommandons à l'expéditeur des données de chiffrer les données sensibles à l'aide des clés de chiffrement AEAD, depuis la bibliothèque Tink Open Source. Les clés de chiffrement AEAD de la bibliothèque Tink sont compatibles avec les fonctions AEAD de BigQuery. Le locataire peut ensuite déchiffrer les données en accédant au matériel de clé dans une fonction définie par l'utilisateur autorisée ou en le transmettant en tant que paramètre de requête vers BigQuery, où l'organisation hôte ne peut pas consigner la clé.

Stratégies d'accès aux colonnes

Dans les magasins de données mutualisés, les stratégies de colonne sont fréquemment utilisées pour éviter toute fuite accidentelle de contenu sensible entre des équipes qui collaborent. Les vues autorisées constituent le mécanisme privilégié pour partager des données entre équipes dans un scénario de magasin de données. Les vues autorisées ne peuvent pas accorder l'accès à une colonne protégée.

Lorsque vous définissez la stratégie pour appliquer le contrôle des accès, vous empêchez les utilisateurs qui ne disposent pas du rôle de lecteur détaillé d'accéder à la stratégie. Même lorsque la stratégie n'est pas appliquée, elle consigne tous les accès utilisateur à la colonne catégorisée.

Protection des données sensibles

La protection des données sensibles fournit des API et des utilitaires d'analyse qui vous aident à identifier et à limiter le contenu sensible stocké dans les ensembles de données BigQuery ou Cloud Storage. Dans les scénarios d'architecture mutualisée, les organisations utilisent fréquemment l'API DLP (faisant partie de la protection des données sensibles) pour identifier et éventuellement segmenter des données sensibles avant leur stockage.

Gestion des réservations d'emplacements

La gestion des réservations dans les systèmes mutualisés permet de contrôler les coûts au fur et à mesure que les locataires évoluent, et d'assurer des garanties en termes de performances pour chaque locataire.

Pour gérer les réservations, nous vous recommandons de créer un seul projet d'administration de réservation. Les engagements d'emplacements achetés dans un même projet d'administration peuvent être partagés entre toutes les réservations provenant du projet d'administration. Un projet qui utilise des engagements d'emplacements ne peut être attribué qu'à une seule réservation à la fois. Toutes les requêtes provenant d'un projet partagent des emplacements en fonction des ressources disponibles.

Pour vous assurer que les objectifs de niveau de service (SLO) des locataires sont atteints, vous pouvez surveiller les réservations en utilisant Cloud Logging et le schéma d'informations BigQuery. Les entreprises qui connaissent des périodes de forte activité (analytique ou tâches prioritaires par exemple) peuvent allouer de la capacité supplémentaire à l'aide d'emplacements Flex.

Réservations en tant que niveaux de calcul du locataire

Les fournisseurs SaaS comptant des dizaines, voire des milliers de locataires, configurent généralement un nombre limité de réservations BigQuery en tant que ressources partagées.

Si vous êtes un fournisseur SaaS disposant d'une infrastructure de locataire partagée, nous vous recommandons de dédier chaque réservation à un seul projet et de regrouper les locataires afin qu'ils partagent ce projet pour leurs ressources calcul BigQuery. Cette conception réduit les coûts administratifs liés à la présence de milliers de projets et de réservations supplémentaires, tout en permettant à votre organisation d'allouer une capacité d'emplacements minimale pour répondre aux besoins de performances anticipés pour la réservation.

Si la rapidité du traitement des données ELT est une priorité, nous vous recommandons d'allouer une réservation pour gérer le traitement. Afin d'éviter l'utilisation d'emplacements supplémentaires pouvant être utilisés pour des charges de travail ad hoc, définissez la réservation pour qu'elle ignore les emplacements inactifs.

Voici un exemple de configuration des réservations en tant que niveaux de calcul du locataire :

• Traitement des données : 2 000 emplacements, ignore les emplacements inactifs. Cette réservation est configurée pour respecter les SLO de traitement des données.
• Projets internes : 1 000 emplacements, autorise les emplacements inactifs. Cette réservation est appliquée aux projets utilisés pour l'analyse interne. Les emplacements sont réutilisés s'ils sont issus du traitement des données ou de niveaux de calcul.
• Niveau de calcul faible : 2 000 emplacements, ignore les emplacements inactifs. Cette réservation est appliquée aux locataires disposant de peu de ressources. Contrairement au niveau élevé, cette réservation ignore les emplacements inactifs.
• Niveau de calcul élevé : 3 000 emplacements, autorise les emplacements inactifs. Cette réservation est appliquée aux locataires disposant de beaucoup de ressources. Pour accélérer les requêtes, les emplacements inactifs associés à d'autres réservations sont automatiquement appliqués.

Si vos locataires utilisent une infrastructure dédiée, nous vous recommandons d'attribuer le dossier ou le projet désigné à la réservation partagée correspondante.

Réservations par équipe

Lorsque vous travaillez avec des équipes dans un environnement de magasin de données, nous vous recommandons de créer une réservation pour chaque équipe nécessitant des ressources de calcul supplémentaires. Attribuez ensuite cette réservation au dossier parent qui contient les projets de l'équipe. Tous les nouveaux projets de cette équipe utilisent des emplacements de planification équitable issus de la même allocation de ressources.

Voici un exemple de configuration des réservations par équipe :

• Réservation au niveau de l'organisation : 500 emplacements, autorise les emplacements inactifs. Cette réservation est attribuée à l'organisation racine, et fournit des emplacements à tout utilisateur BigQuery qui n'utilise pas de projet disposant d'une réservation dédiée.
• Traitement des données : 1 000 emplacements, ignore les emplacements inactifs. Cette réservation est configurée pour respecter les SLO minimum de traitement des données.
• Administration des données principales : 500 emplacements, autoriser l'inactivité. Cette réservation est appliquée aux projets utilisés pour l'administration interne. Les emplacements restants (traitement de données, niveaux de calcul) sont réutilisés.
• Réservations de traitement d'analyses : 500 emplacements, autorise les emplacements inactifs. Il s'agit d'une réservation dédiée, donnée à une équipe d'analyse.

Exigences d'hébergement multirégional

Les exigences d'hébergement multirégional résultent généralement de la réduction de la latence des données pour les consommateurs ou du respect des obligations légales.

Les projets dans Google Cloud sont considérés comme globaux et peuvent fournir des ressources dans n'importe quelle région. BigQuery considère que les ensembles de données, les règles de colonne et les engagements d'emplacements sont des ressources régionales. Les emplacements ne peuvent accéder qu'aux ensembles de données de la région locale, et les règles relatives aux colonnes ne peuvent être appliquées qu'aux tables situées dans les ensembles de données locaux. Pour utiliser la tarification basée sur la capacité, vous devez acheter des emplacements dans chaque région contenant des ensembles de données.

Pour obtenir des conseils concernant le respect des exigences réglementaires, contactez votre conseiller commercial.

Étapes suivantes

• Découvrez les bonnes pratiques IAM.