Aller au contenu principal
Dernière mise à jour le

Surveiller et gérer les coûts de sortie OpenSharing (pour les fournisseurs)

Cette page décrit les outils que vous pouvez utiliser pour surveiller et gérer les coûts d'égresse des fournisseurs cloud lorsque vous partagez des données et des assets d'IA à l'aide d'OpenSharing.

Contrairement à d'autres plateformes de partage de données, OpenSharing ne nécessite pas de réplication de données. Ce modèle présente de nombreux avantages, mais votre fournisseur de cloud pourrait facturer des frais d'extraction de données lorsque vous partagez des données entre les clouds ou les régions. Si vous utilisez OpenSharing pour partager des données et des assets d'IA au sein d'une région, vous n'engagez aucun coût d'extraction.

Si vous utilisez SecureConnect, Databricks facture le transfert de données plutôt que votre fournisseur de cloud.

Pour surveiller et gérer les coûts de sortie de données, Databricks fournit :

astuce

Assurez-vous que vos destinataires utilisent des endpoints de passerelle Virtual Private Cloud (VPC) ou des endpoints d'interface pour S3 au lieu de passerelles NAT pour l'accès au stockage dans la région, dans la mesure du possible, afin de réduire les coûts et d'améliorer la sécurité.

Notebooks de pipeline d'égresse OpenSharing​

Dans Databricks Marketplace, le listing OpenSharing Egress Pipeline comprend deux Notebooks que vous pouvez cloner et utiliser pour surveiller les modèles d'utilisation des sorties de données et les coûts associés à OpenSharing. Ces deux Notebooks créent et exécutent des Lakeflow pipelines :

  • Notebook de pipeline de mappage de plages d'adresses IP
  • Notebook du pipeline d'analyse des coûts de sortie

Lorsque vous exécutez ces Notebooks en tant que Template de pipeline LakeFlow, ils généreront automatiquement un rapport de coûts détaillé. Les Logs sont jointes à des tables de plages d'adresses IP des fournisseurs de cloud et à des tables système OpenSharing pour générer les octets de sortie transférés, attribués par partage et destinataire.

Les exigences et les instructions complètes sont disponibles dans la liste.

Répliquer les données pour éviter les coûts d'extraction​

Une approche pour éviter les coûts d'extraction consiste pour le fournisseur à créer et à synchroniser des répliques locales des données partagées dans les régions que leurs destinataires utilisent. Une autre approche consiste à ce que les destinataires clonent les données partagées vers des régions locales pour des requêtes actives, en mettant en place des synchronisations entre la table partagée et le clone local. Cette section aborde un certain nombre de modèles de réplication.

Utiliser le clonage profond Delta pour la réplication incrémentielle​

Les fournisseurs peuvent utiliser DEEP CLONE pour répliquer les tables Delta vers des emplacements externes dans les régions vers lesquelles ils partagent. Les clones profonds copient les données et les métadonnées de la table source vers la cible du clone. Les clones profonds permettent également les mises à jour incrémentielles en identifiant les nouvelles données dans la table source et en actualisant la cible en conséquence.

SQL
CREATE TABLE [IF NOT EXISTS] table_name DEEP CLONE source_table_name
   [TBLPROPERTIES clause] [LOCATION path];

Vous pouvez planifier un Job Databricks pour refresh les données de la table cible de manière incrémentielle avec les mises à jour récentes de la table partagée, en utilisant la commande suivante :

SQL
CREATE OR REPLACE TABLE table_name DEEP CLONE source_table_name;

Consultez Cloner une table sur Databricks et Lakeflow Jobs.

Activer le flux de données de modification (CDF) sur les tables partagées pour la réplication incrémentielle​

Lorsqu'une table est partagée avec son CDF, le destinataire peut accéder aux modifications et les Merge dans une copie locale de la table, où les utilisateurs effectuent des requêtes. Dans ce scénario, l'accès du destinataire aux données ne franchit pas les limites régionales et l'exportation se limite à l'actualisation d'une copie locale. Si le destinataire est sur Databricks, il peut utiliser un job de workflow Databricks pour propager les modifications à un réplica local.

Pour partager une table avec le CDF, vous devez activer le CDF sur la table et la partager WITH HISTORY.

Pour plus d’informations sur l’utilisation du CDF, consultez Utiliser le flux de données de modification sur Databricks et Ajouter des tables à un partage.

Utilisez les répliques Cloudflare R2 ou migrez le stockage vers R2​

Le stockage d'objets Cloudflare R2 n'entraîne pas de frais de sortie. La réplication ou la migration des données que vous partagez vers R2 vous permet de partager des données à l'aide d'OpenSharing sans frais d'extraction. Cependant, cela ne s'applique pas au partage de vues, qui pourrait toujours entraîner des frais de sortie. Cette section décrit comment répliquer les données vers un emplacement R2 et activer les mises à jour incrémentielles à partir des tables source.

Exigences​

  • Workspace Databricks activé pour Unity Catalog.
  • Databricks Runtime 14.3 ou version ultérieure, ou SQL warehouse 2024.15 ou version ultérieure.
  • Compte Cloudflare. Consultez https://dash.cloudflare.com/sign-up.
  • Rôle d'administrateur Cloudflare R2. Consultez la documentation sur les rôles Cloudflare.
  • CREATE STORAGE CREDENTIAL privilège sur le métastore Unity Catalog attaché au Workspace. Les administrateurs de compte et les administrateurs de métastore disposent de ce privilège par default.
  • CREATE EXTERNAL LOCATION privilège sur le métastore et les identifiants de stockage référencés dans l'emplacement externe. Les administrateurs de métastore disposent de ce privilège par default.
  • CREATE MANAGED STORAGE privilège sur l'emplacement externe.
  • CREATE CATALOG sur le métastore. Les administrateurs de métastore disposent de ce privilège par default.

Limitations pour Cloudflare R2​

Les fournisseurs ne peuvent pas partager les tables R2 qui utilisent le clustering liquide et le checkpoint V2.

Montez un compartiment R2 comme un emplacement externe dans Databricks.​

  1. Créez un compartiment Cloudflare R2.

    Voir Étape 1 : configurer un compartiment R2.

  2. Créer un identifiant de stockage dans Unity Catalog qui donne accès au compartiment R2.

    Consultez l'Étape 2 : Créer l'identifiant de stockage.

  3. Utilisez l'identifiant de stockage pour créer un emplacement externe dans Unity Catalog.

    Voir Étape 3 : créer l’emplacement externe.

Créer un nouveau catalogue à l'aide de l'emplacement externe​

Créer un catalogue qui utilise le nouvel emplacement externe comme emplacement de stockage géré.

Consultez Créer des catalogues.

Lorsque vous créez le catalogue, veuillez procéder comme suit :

  • Sélectionnez un type de catalogue Standard .
  • Sous Emplacement de stockage , sélectionnez Sélectionner un emplacement de stockage et saisissez le chemin d'accès au bucket R2 que vous avez défini comme emplacement externe. Par exemple : r2://mybucket@my-account-id.r2.cloudflarestorage.com

Clonez les données que vous souhaitez partager dans une table du nouveau catalogue​

Utilisez DEEP CLONE pour répliquer les tables dans S3 vers le nouveau catalogue qui utilise R2 pour le stockage géré. Les clones profonds copient les données et les métadonnées de la table source vers la cible du clone. Les clones profonds permettent également les mises à jour incrémentielles en identifiant les nouvelles données dans la table source et en actualisant la cible en conséquence.

SQL
CREATE TABLE IF NOT EXISTS new_catalog.schema1.new_table DEEP CLONE old_catalog.schema1.source_table
  LOCATION 'r2://mybucket@my-account-id.r2.cloudflarestorage.com';

Vous pouvez planifier un Job Databricks pour refresh les données de la table cible de manière incrémentale avec les mises à jour récentes dans la table source, à l'aide de la commande suivante :

SQL
CREATE OR REPLACE TABLE new_catalog.schema1.new_table DEEP CLONE old_catalog.schema1.source_table;

Consultez Cloner une table sur Databricks et Lakeflow Jobs.

Partager la nouvelle table​

Lorsque vous créez le partage, ajoutez les tables qui se trouvent dans le nouveau catalogue, stockées dans R2. Le processus est le même que l'ajout de toute table à un partage.

Voir Créer des partages pour OpenSharing.

Sur cette page