Aller au contenu principal
Dernière mise à jour le

Configurer les paramètres liés au service de commit S3 de Databricks

Databricks exécute un service de commit qui coordonne les écritures sur Amazon S3 à partir de plusieurs clusters. Ce service s'exécute dans le plan de contrôle Databricks. Pour une sécurité accrue, vous pouvez désactiver l'optimisation de l'upload direct du service, comme décrit dans Désactiver l'optimisation de l'upload direct. Pour restreindre davantage l'accès à vos compartiments S3, consultez Restreindre l'accès à des adresses IP spécifiques.

Si vous recevez des alertes AWS GuardDuty liées au service de commit S3, consultez Alertes AWS GuardDuty liées au service de commit S3.

À propos du service de commit​

Le service de commit S3 aide à garantir la cohérence des écritures sur plusieurs clusters sur une seule table dans des cas spécifiques. Par exemple, le service de commit aide Delta Lake à implémenter les Transactions ACID.

Dans la configuration default, Databricks envoie des informations d’identification AWS temporaires du plan de compute au plan de contrôle lors de l’appel API du service commit. Les identifiants de profil d'instance sont valides pendant six heures.

Le plan de compute écrit les données directement sur S3, puis le service de commit S3 dans le plan de contrôle assure le contrôle de la concurrence en finalisant l'upload du Log de commit (complétant l'upload multipartie décrit ci-dessous). Le service de commit ne lit aucune donnée de S3. Il place un nouveau fichier dans S3 s'il n'existe pas.

Les données les plus courantes écrites sur S3 par le service de commit Databricks sont le Log Delta, qui contient des agrégats statistiques de vos données, tels que les valeurs minimales et maximales de la colonne. La plupart des données de log Delta sont envoyées vers S3 depuis le plan de contrôle à l'aide d'un Amazon S3 multipart upload.

Après que le cluster ait mis en scène les données multiparties pour écrire le Log Delta dans S3, le service de commit S3 dans le plan de contrôle Databricks termine l'upload multipart S3 en informant S3 que c'est terminé. En tant qu'optimisation des performances pour les très petites mises à jour, par default, le service de commit envoie parfois de petites mises à jour directement du plan de contrôle vers S3. Cette optimisation de la mise à jour directe peut être désactivée. Consultez Désactiver l'optimisation de l'upload direct.

En plus de Delta Lake, les fonctionnalités Databricks suivantes utilisent le même service de commit S3 :

Le service commit est nécessaire car Amazon ne fournit pas une opération qui ne place un objet que s'il n'existe pas encore. Amazon S3 est un système distribué. Si S3 reçoit simultanément plusieurs requêtes d'écriture pour le même objet, il écrase tous les objets à l'exception du dernier. Sans la possibilité de vérifier les commits de manière centralisée, les commits simultanés de différents clusters corrompraient les tables.

Alertes AWS GuardDuty liées au service de commit S3​

important

Commits aux tables gérées par Unity Catalog ne trigger pas d'alertes GuardDuty.

Si vous utilisez AWS GuardDuty et que vous accédez aux données à l'aide de profils d'instance AWS IAM, GuardDuty peut générer des alertes pour le comportement default de Databricks lié à Delta Lake, Structured Streaming, Auto Loader ou COPY INTO. Ces alertes sont liées à la détection d'exfiltration des identifiants d'instance, qui est activée par default. Ces alertes incluent le titre UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS.

Vous pouvez configurer votre déploiement Databricks pour traiter les alertes GuardDuty liées au service de commit S3 en créant un profil d'instance AWS qui assume le rôle de votre rôle IAM d'accès aux données S3 d'origine.

En tant qu'alternative à l'utilisation des informations d'identification du profil d'instance, ce nouveau profil d'instance peut configurer les clusters pour assumer un rôle avec des jetons de courte durée. Cette capacité existe déjà dans toutes les versions récentes de Databricks Runtime et peut être appliquée globalement via les stratégies de clusters.

  1. Si vous ne l’avez pas déjà fait, créez un profil d’instance normal pour accéder aux données S3. Ce profil d'instance utilise des informations d'identification de profil d'instance pour accéder directement aux données S3.

    Cette section fait référence à l'ARN de rôle dans ce profil d'instance en tant que <data-role-arn>.

  2. Créez un nouveau profil d'instance qui utilisera des jetons et fera référence à votre profil d'instance qui accède directement aux données. Votre cluster fera référence à ce nouveau profil d'instance basé sur des jetons. Consultez Tutoriel : Configurer l'accès S3 avec un profil d'instance.

    Ce profil d'instance n'a pas besoin d'un accès direct à S3. Il ne lui faut plutôt que les autorisations nécessaires pour assumer le rôle IAM que vous utilisez pour l'accès aux données. Cette section fait référence à l'ARN de rôle dans ce profil d'instance comme <cluster-role-arn>.

    1. Ajoutez une politique IAM attachée au rôle IAM du nouveau profil d'instance de cluster (<cluster-role-arn>). Ajoutez l'instruction de politique suivante à votre nouveau rôle IAM de profil d'instance de cluster et remplacez <data-role-arn> par l'ARN de votre profil d'instance d'origine qui accède à votre compartiment.

      JSON
      {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "<data-role-arn>"
      }

    2. Ajoutez une instruction de politique de confiance à votre rôle IAM d'accès aux données existant et remplacez <cluster-role-arn> par l'ARN du profil d'instance d'origine qui accède à votre compartiment.

      JSON
      {
        "Effect": "Allow",
        "Principal": {
          "AWS": "<cluster-role-arn>"
        },
        "Action": "sts:AssumeRole"
      }

  3. Pour utiliser le code de Notebook qui établit une connexion directe à S3 sans utiliser DBFS, configurez vos clusters pour qu'ils utilisent le nouveau profil d'instance basé sur un jeton et qu'ils assument le rôle d'accès aux données.

    • Configurez un des clusters pour l'accès S3 à tous les buckets. Ajoutez les éléments suivants à la configuration Spark du cluster :

      ini
      fs.s3a.credentialsType AssumeRole
      fs.s3a.stsAssumeRole.arn <data-role-arn>

    • Vous pouvez configurer cela pour un bucket spécifique :

      ini
      fs.s3a.bucket.<bucket-name>.aws.credentials.provider org.apache.hadoop.fs.s3a.auth.AssumedRoleCredentialProvider
      fs.s3a.bucket.<bucket-name>.assumed.role.arn <data-role-arn>

Désactiver l'optimisation de l'upload direct​

Comme optimisation des performances pour les très petites mises à jour, le service de commit pousse parfois default de petites mises à jour directement du plan de contrôle vers S3. Pour désactiver cette optimisation, définissez le paramètre Spark spark.hadoop.fs.s3a.databricks.s3commit.directPutFileSizeThreshold sur 0. Vous pouvez appliquer ce paramètre dans la configuration Spark du cluster ou le définir à l'aide de règles de cluster.

La désactivation de cette fonctionnalité peut entraîner un léger impact sur les performances pour les queries Structured Streaming quasi en temps réel avec de petites mises à jour constantes. Envisagez de tester l'impact sur les performances avec vos données avant de désactiver cette fonctionnalité en production.

Restreindre l'accès à des adresses IP spécifiques​

Vous pouvez limiter l'accès à des compartiments S3 spécifiques à partir d'adresses IP spécifiques uniquement. Par exemple, vous pouvez restreindre l'accès à votre propre environnement et aux adresses IP du plan de contrôle Databricks uniquement, y compris le service de commit S3. Cela réduit le risque que les identifiants soient utilisés depuis d'autres emplacements. Voir (Facultatif) Restreindre l'accès aux compartiments S3.

Sur cette page