Aller au contenu principal
Dernière mise à jour le

Lakehouse Replay

info

Bêta

Cette fonctionnalité est en Bêta. Les administrateurs du Workspace peuvent contrôler l'activation de cette fonctionnalité à partir de la page Prévisualisations du Workspace. Consultez Gérer les aperçus Databricks.

Lakehouse Replay améliore la qualité et la stabilité des futures versions de Databricks Runtime en rejouant automatiquement un petit sous-ensemble de charges de travail en lecture seule de votre workspace par rapport aux prochaines versions de runtime avant qu'elles n'atteignent la production. Lorsqu'une charge de travail réussit en production mais échoue sur la prochaine version d'exécution, Databricks identifie et corrige la régression avant la publication de cette version. Cela rend les mises à niveau du runtime plus sûres, sans configuration ni maintenance requises.

Lakehouse Replay échantillonne les charges de travail uniquement à partir du compute serverless, mais les régressions qu'il détecte améliorent chaque version de Databricks Runtime, y compris classique et serverless. L'exécution sur serverless permet à Databricks d'effectuer ce test sur du compute géré, de sorte que le travail de relecture ne vous est pas facturé.

Fonctionnement de Lakehouse Replay​

Lakehouse Replay utilise l'exécution fantôme pour tester les futures versions de runtime :

  1. Vos charges de travail s'exécutent en production comme d'habitude.
  2. Lakehouse Replay sélectionne un petit sous-ensemble de charges de travail sûres et en lecture seule à des fins de test.
  3. Lakehouse Replay réexécute les plans Spark des charges de travail sélectionnées sur un compute fantôme géré par Databricks exécutant une prochaine version du runtime.
  4. Si une charge de travail réussit en production mais échoue sur le compute fantôme, Databricks enquête et résout la régression avant de publier la version d'exécution.

Le compute fantôme s'exécute entièrement au sein de votre Workspace Databricks et n'a aucune incidence sur vos charges de travail ou Jobs de production.

Charges de travail prises en charge​

Lakehouse Replay ne rejoue que les charges de travail qui répondent à des exigences de sécurité strictes :

  • Charges de travail SQL et DataFrame en lecture seule provenant de SQL Warehouses Serverless, de Notebooks Serverless et de Jobs Serverless.
  • Charges de travail qui lisent uniquement les tables Delta de Unity Catalog.

Pour les charges de travail DataFrame, Lakehouse Replay rejoue uniquement le plan Spark soumis au cluster de production. Les cellules Python précédentes ne sont pas exécutées.

Les charges de travail suivantes sont exclues :

  • Opérations d'écriture
  • Fonctions définies par l'utilisateur (UDF)
  • Fonctions d'IA telles que ai_query
  • Charges de travail fédérées qui accèdent à des bases de données externes
  • Charges de travail avec contrôle d'accès basé sur les attributs ou basé sur les rôles (ABAC/RBAC)

Sécurité et confidentialité des données​

Lakehouse Replay ne modifie pas votre posture existante en matière de sécurité et de confidentialité des données :

  • Aucune exportation de données : Lakehouse Replay compare uniquement l'état d'exécution et les métriques d'exécution pour détecter les incohérences. Il ne lit, n'exporte ni ne stocke les résultats de query.
  • Exécuter avec les mêmes autorisations : Les charges de travail rejouées s'exécutent avec la même identité d'utilisateur que la query de production originale et respectent les autorisations Unity Catalog au moment de la relecture.
  • Exécution isolée : le compute fantôme Databricks utilisé pour la relecture est isolé de votre compute de production et ne peut pas accéder aux APIs externes, aux bases de données ou à d'autres workspaces.

Facturation​

Lakehouse Replay utilise le compute serverless géré par Databricks pour exécuter la relecture, et les clients ne sont pas facturés pour les coûts de compute associés. Les charges de travail relues peuvent entraîner des coûts d'API de stockage d'objets minimes, car une charge de travail relue lit les données en utilisant les mêmes autorisations et le même chemin de stockage que la charge de travail originale.

Logs d'audit​

L'activité de Lakehouse Replay est enregistrée dans la table système des logs d'audit sous le service lakehouseReplay. Consultez les événements Lakehouse Replay.

Questions fréquemment posées​

Dois-je faire quelque chose pour utiliser Lakehouse Replay ?​

Non. S'il est activé dans votre Workspace, Lakehouse Replay s'exécute automatiquement sans configuration ni maintenance.

Lakehouse Replay affecte-t-il mes charges de travail de production ?​

Non. Le compute shadow s'exécute séparément de votre compute de production et n'affecte pas les charges de travail en cours d'exécution, les planifications de Job ou les performances des query.

Comment savoir si mes workloads sont rejoués ?​

Les charges de travail rejouées n'apparaissent pas dans l'historique de vos exécutions de Job ou de vos requêtes. L'activité de relecture Lakehouse est disponible dans la table système du journal d'audit.

À quelle fréquence les workloads sont-ils rejoués ?​

La fréquence d'échantillonnage est probabiliste et basée sur le trafic du workspace et le type de charge de travail. La plupart des charges de travail sont rejouées dans l'heure suivant l'exécution initiale.

Que se passe-t-il si un workload rejoué échoue ?​

Si une charge de travail échoue sur le compute de l'ombre mais réussit en production, Databricks investigue. Si Databricks confirme l'échec comme une régression, Databricks résout le problème avant de publier la version d'exécution. Databricks ne vous avertit pas des échecs individuels à moins qu'il n'ait besoin d'un contexte supplémentaire.

Quels types de régressions Lakehouse Replay détecte-t-il ?​

Lakehouse Replay détecte les échecs d'exécution. Il s'agit de charges de travail qui réussissent en production mais échouent sur la prochaine version d'exécution.

Sur cette page