Analyse des consommateurs par plusieurs fournisseurs¶

Un consommateur peut effectuer une analyse dans plusieurs clean rooms appartenant au même fournisseur ou à plusieurs fournisseurs en une seule requête, et voir les résultats combinés. Les résultats sont une union des résultats d’analyse de chaque clean room, et non les données du consommateur analysées par rapport à une union des données du fournisseur dans plusieurs clean rooms.

Les fournisseurs peuvent voir tous les détails de la requête, y compris les autres clean rooms interrogées et le modèle avant d’approuver la requête. Les fournisseurs ne peuvent pas voir les données des autres clean rooms, ni même les tables des fournisseurs qui font l’objet d’une requête dans d’autres clean rooms. Les données de chaque clean room sont accédées et manipulées en toute sécurité et conformément aux politiques de jonction, de colonne et autres de chaque clean room.

Les résultats d’analyse de plusieurs fournisseurs peuvent être activés si l’activation est activée dans toutes les clean rooms.

Exigences¶

Modèles : Les analyses multi-fournisseurs peuvent être exécutées sur n’importe quel modèle fourni par Snowflake ou personnalisé.
Environnement : L’analyse multi-fournisseurs ne peut être mise en œuvre qu’en utilisant l’API de clean room. Elle ne peut pas être exécutée dans l’UI de clean rooms.
La facturation : Le consommateur paie pour les requêtes multi-fournisseurs.
Autres exigences : - Toutes les clean rooms d’une analyse multi-fournisseurs doivent faire l’objet d’une politique d’adhésion des fournisseurs. Si l’analyse échoue dans une clean room, c’est toute la requête qui échoue.

Aperçu de l’analyse multi-fournisseurs¶

Voici un aperçu de haut niveau du fonctionnement de l’analyse multi-fournisseurs. Vous trouverez des échantillons de code exécutables.

Le consommateur installe toutes les clean rooms à utiliser dans son flux multi-fournisseurs, de manière standard. Clean rooms dans une analyse multi-fournisseurs sont des clean rooms standard.
Le consommateur établit des liens entre les ensembles de données et paramètre les politiques de jonction de la manière standard. Les clean rooms du fournisseur et du consommateur doivent toutes avoir défini des politiques de jonction,, que la politique soit vérifiée ou non par le modèle.
La requête porte sur un seul modèle, et toutes les clean rooms doivent avoir ce modèle installé. Si le consommateur souhaite utiliser un modèle personnalisé, il doit suivre la procédure de requête de modèle standard pour le consommateur :
1. Le consommateur appelle consumer.create_template_request pour chaque clean room, en transmettant le modèle personnalisé.
2. Le fournisseur appelle provider.list_pending_template_requests pour connaître les requêtes de modèles en attente, puis appelle provider.approve_template_request pour approuver l’ajout du modèle à sa clean room.
3. Le consommateur appelle consumer.list_template_requests pour savoir si la requête a été acceptée.
Les fournisseurs et les consommateurs établissent des politiques de colonne pour le modèle, de la manière habituelle.
Le fournisseur appelle provider.enable_multiprovider_computation dans chaque clean room pour faire remonter les requêtes du consommateur. (Les requêtes envoyées avant cet appel sont mises en file d’attente, mais ne sont pas visibles pour le fournisseur tant que cette procédure n’est pas appelée.)
Le consommateur demande l’autorisation d’exécuter un modèle. Il existe quelques variantes du flux de requêtes et d’approbations mais voici le flux par défaut :
1. Le consommateur envoie une requête multi-fournisseurs à toutes les clean rooms en appelant consumer.prepare_multiprovider_flow. Cette requête spécifie la liste des clean rooms, le modèle utilisé et tous les paramètres du modèle, y compris les tables des fournisseurs et des consommateurs. L’appel n’est effectué qu’une seule fois et est diffusé à toutes les clean rooms de la requête. Chaque clean room voit tous les détails de la requête, mais la liste des tables de fournisseurs est filtrée sur les tables de fournisseurs de cette clean room. Il renvoie un ID de requête.
2. Chaque fournisseur appelle provider.view_multiprovider_requests pour voir les requêtes multi-fournisseurs envoyées par le consommateur, puis appelle provider.process_multiprovider_request pour les approuver.
Lorsque toutes les clean rooms ont approuvé la requête, le consommateur appelle consumer.execute_multiprovider_flow pour exécuter la requête. Le modèle est exécuté dans chaque clean room avec les informations fournies dans la requête consumer.prepare_multiprovider_flow la plus récente, et les résultats combinés sont envoyés au consommateur. Le consommateur peut à nouveau appeler execute_multiprovider_flow sans autre autorisation jusqu’à ce qu’un fournisseur révoque l’autorisation de la requête ou que le consommateur épuise son budget de confidentialité différentielle (si la confidentialité différentielle est activée).

Détails de la requête et de l’approbation¶

Voici les détails de la procédure de requête et d’approbation. Il existe plusieurs variantes de ce processus.

Variations du flux de requêtes et d’approbations¶

Il existe trois flux possibles lors de l’exécution d’une analyse multi-fournisseurs :

Approbation par requête (comportement par défaut) :

Le consommateur appelle consumer.prepare_multiprovider_flow pour lui communiquer les détails de la requête.
Le fournisseur voit la requête (provider.view_multiprovider_requests) et l’approuve (provider.process_multiprovider_request). Cette étape peut être omise si le fournisseur a déjà approuvé cette requête.
Le consommateur exécute la requête (consumer.execute_multiprovider_flow).

Approbation par le consommateur et par clean room :

Le consommateur appelle consumer.prepare_multiprovider_flow pour lui communiquer les détails de la requête.
Le fournisseur voit la requête (provider.view_multiprovider_requests) et l’approuve (provider.process_multiprovider_request), en transmettant à -1 l’ID de requête plutôt que l’ID de requête actuelle. Par conséquent, le consommateur doit toujours appeler consumer.prepare_multiprovider_flow pour les requêtes futures, mais l’approbation sera accordée automatiquement, sans approbation supplémentaire de la part du fournisseur.
Le consommateur exécute la requête (consumer.execute_multiprovider_flow).

Approbation automatisée :

Le fournisseur appelle provider.resume_multiprovider_tasks dans la clean room. Toutes les requêtes de consommateurs et de fournisseurs multiples dans cette clean room seront approuvées automatiquement.
Le consommateur appelle consumer.prepare_multiprovider_flow pour lui communiquer les détails de la requête. La requête est automatiquement approuvée,
Le consommateur exécute la requête (consumer.execute_multiprovider_flow).

Dans tous les flux, vous pouvez révoquer toute approbation de requête précédemment accordée.

Critères d’approbation des requêtes¶

consumer.execute_multiprovider_flow évalue la dernière requête envoyée à consumer.prepare_multiprovider_flow pour voir si elle a déjà été approuvée. Si une requête approuvée correspondante est trouvée, la requête se poursuit. Si aucune requête antérieure correspondante n’est trouvée, consumer.execute_multiprovider_flow échouera. (Si l’autorisation générale <label-cleanrooms_approval_variations> a été accordée à ce consommateur ou à tous les consommateurs, le contrôle de l’autorisation est ignoré) Les approbations précédentes sont comparées aux valeurs suivantes :

La liste des clean rooms faisant l’objet de la requête.

Les noms des arguments sont envoyés à la clean room. Tous les noms d’arguments présents dans la requête approuvée doivent être présents dans la nouvelle requête. Les valeurs des arguments ne sont pas vérifiées, seuls les noms des arguments le sont.

Nom du modèle en cours d’exécution.

En outre, le modèle doit être conforme à toutes les politiques de la clean room, y compris les politiques relatives aux lignes, aux colonnes et à la confidentialité différentielle (si elle est activée), que des approbations générales aient été données ou non.

Historique de l’approbation¶

consumer.execute_multiprovider_flow essaie d’exécuter la dernière requête envoyée à consumer.prepare_multiprovider_flow. La requête peut être exécutée si tous les contrôles de sécurité sont positifs et si une requête correspondante a été approuvée dans le passé. Par conséquent, vous pouvez voir un flux comme celui-ci :

Le consommateur prépare la requête A.
Le fournisseur approuve A.
Le consommateur exécute A.
Le consommateur prépare la requête B.
Le fournisseur approuve B.
Le consommateur exécute B.
Le consommateur prépare à nouveau la requête A, avec tous les mêmes paramètres.
Le consommateur peut à nouveau exécuter A sans l’approbation du fournisseur, car il a déjà été approuvé. Consultez la section suivante pour savoir comment la clean room détermine si une requête a déjà été approuvée.

Activer ou désactiver l’approbation automatique des requêtes¶

L’approbation des requêtes peut être automatisée par consommateur ou pour tous les consommateurs, dans une clean room.

Pour approuver automatiquement toutes les requêtes multi-fournisseurs d’un consommateur donné dans la clean room, le fournisseur appelle provider.process_multiprovider_request avec -1 comme ID de requête. Toutes les requêtes multi-fournisseurs de ce consommateur dans cette clean room seront alors approuvées. (Le consommateur doit toujours appeler consumer.prepare_multiprovider_flow lorsqu’il modifie la requête, et le fournisseur verra toujours tous les appels consumer.prepare_multiprovider_flow dans provider.view_multiprovider_requests l’historique des requêtes.) Pour désactiver l’approbation automatique accordée à un utilisateur donné, vous devez mettre à jour le journal d’approbation.

Pour approuver automatiquement toutes les requêtes multi-fournisseurs pour tous les consommateurs, le fournisseur appelle provider.resume_multiprovider_tasks dans la clean room. Toutes les requêtes multi-fournisseurs de tous les consommateurs seront alors approuvées automatiquement. (Le consommateur doit toujours appeler consumer.prepare_multiprovider_flow lorsqu’il modifie la requête, et le fournisseur verra toujours tous les appels consumer.prepare_multiprovider_flow dans provider.view_multiprovider_requests l’historique des requêtes.) Pour désactiver l’approbation automatique ainsi accordée, appelez provider.suspend_multiprovider_tasks.

Conception de votre modèle¶

Par conséquent, assurez-vous que votre modèle est correct avant de l’utiliser en le testant dans un flux de base créé par le fournisseur et géré par le consommateur avant de l’utiliser dans un flux multi-fournisseurs.

Chaque clean room utilise exactement le même modèle, mais la liste source_table transmise à chaque clean room peut varier en longueur et en nom de table, car la liste est filtrée pour n’afficher que les tables des fournisseurs de cette clean room. Par conséquent, en fonction de votre requête, vous devrez peut-être utiliser les instructions de bouclage et les instructions conditionnelles de Jinja pour gérer les variations de la longueur des listes ou des noms de tables.

Gestion des approbations automatisées et modification de votre statut d’approbation¶

Connecter l’historique des requêtes¶

Lorsque le fournisseur appelle provider.enable_multiprovider_computation, il crée une table de connexion nommée samooha_cleanroom_cleanroom_ID.admin.request_log_multiprovider. Chaque fois qu’un fournisseur approuve une analyse multi-fournisseurs pour une clean room, la requête est connectée ici. Il s’agit de la table que les clean rooms vérifient lorsqu’un consommateur demande l’exécution d’une requête multi-fournisseurs. La table comprend une colonne approved qui indique si la requête est autorisée à être exécutée. Comme une requête doit être approuvée avant d’être ajoutée à la table, le statut initial approved sera true, mais vous pouvez le modifier ultérieurement si vous décidez de révoquer l’approbation.

La table d’enregistrement connecte les requêtes du consommateur à provider.process_multiprovider_request, et non les exécutions de requêtes par le consommateur. Les exécutions de requêtes par les consommateurs ne sont pas connectées.

Refuser une requête précédemment approuvée¶

Pour refuser une requête précédemment approuvée, vous devez mettre à jour la colonne approved dans la table du journal des requêtes multi-fournisseurs en la remplaçant par FALSE.

Étant donné qu’un consommateur peut soumettre la même requête plusieurs fois et que toute approbation d’une requête donnée permet son exécution, le moyen le plus sûr de désactiver une requête multi-fournisseurs est de paramétrer approved=false pour toutes les requêtes d’un consommateur donné, puis de demander au consommateur de soumettre à nouveau toutes les requêtes qu’il souhaite exécuter en appelant consumer.prepare_multiprovider_flow.

-- Revoke access to a query you had previously approved
UPDATE samooha_cleanroom_Samooha_Cleanroom_Multiprovider_Clean_Room_1.admin.request_log_multiprovider
  SET APPROVED=FALSE
  WHERE PARTY_ACCOUNT='<CONSUMER_LOCATOR>';

Copy

Autoriser une requête précédemment refusée¶

Si vous avez déjà approuvé une requête, que vous l’avez ensuite refusée et que vous souhaitez la réapprouver, il est généralement plus sûr de demander au consommateur de soumettre à nouveau sa requête et de l’approuver dans le flux standard, plutôt que de connecter la table du journal des requêtes.

Révoquer les approbations automatisées¶

Si vous avez activé l’approbation automatique pour tous les consommateurs dans une clean room en appelant provider.resume_multiprovider_tasks, appelez provider.suspend_multiprovider_tasks pour révoquer les approbations générales pour tous les utilisateurs.
Si vous avez activé l’approbation automatique pour un consommateur spécifique dans une clean room en spécifiant -1 comme ID de requête dans provider.process_multiprovider_request, voir Refuser une requête précédemment approuvée.

Échantillons de code¶

Téléchargez les cahiers d’exercices suivants pour tester le flux d’analyse multi-fournisseurs. Vous avez besoin de deux comptes Snowflake avec le programme d’installation des API de clean rooms : un pour servir de fournisseur et un autre pour servir de consommateur. Le compte du fournisseur crée deux clean rooms, qui se comportent de la même manière que plusieurs fournisseurs disposant chacun d’une clean room.