Photon est l'un des facteurs de coût Databricks qu'il faut comprendre avant d'optimiser un workload.
Sur les clusters classiques, le calcul avec Photon activé consomme des Databricks Units (DBU) à un rythme environ deux fois supérieur à celui d'un calcul équivalent sans Photon, même si le multiplicateur exact varie selon le type d'instance. Certains workloads se terminent assez vite pour compenser ce taux de DBU plus élevé. D'autres gagnent en vitesse tout en coûtant plus cher : le temps d'exécution seul ne dit donc pas si Photon vous fait économiser de l'argent.
Dans une analyse communautaire de la tarification Databricks, LakeSentry pointe Photon comme l'un des facteurs de coût à l'origine de surprises tarifaires que la grille de prix ne rend pas évidentes. La consommation supplémentaire de DBU n'est rentable que si le workload gagne suffisamment en vitesse en contrepartie.
Ce guide se concentre sur Databricks Photon : son impact sur les coûts, où se situe le seuil de rentabilité et comment déterminer si son activation réduit le coût d'un workload.
TL;DR
- Sur les clusters classiques, Photon doit offrir une accélération supérieure à 2× pour compenser son taux de DBU plus élevé.
- Les scans, agrégations et jointures peuvent franchir ce seuil, tandis que les UDF Python, les jobs courts et les workloads à shuffle important restent souvent en dessous.
- Vous payez le tarif Photon même lorsque seule une partie du workload passe par Photon.
- Vérifiez la couverture Photon dans le panneau Aggregated task time du query profile, puis comparez les totaux réels de DBU avant et après l'activation de Photon.
Qu'est-ce que Databricks Photon ?
Databricks Photon est un moteur de requêtes qui améliore les performances des traitements de données Spark pris en charge. Il exécute les opérations supportées en C++ natif, tandis que l'optimiseur Catalyst de Spark continue de gérer la planification des requêtes.
Une différence importante à noter : la façon dont Photon traite les données. Au lieu d'exécuter les lignes une par une, il travaille sur des lots de données en colonnes pour les types de données pris en charge et utilise des instructions SIMD (Single Instruction Multiple Data) pour traiter plusieurs valeurs avec une seule instruction CPU. Cela réduit la surcharge du chemin d'exécution JVM et accélère les opérations comme les scans, filtres, agrégations, jointures et tris, lorsque Photon les prend en charge.
Photon ne remplace pas Spark : il agit comme une couche d'exécution native sous le même modèle de programmation Spark. Vos requêtes Spark ou SQL passent toujours par Catalyst pour la planification, puis les parties prises en charge du plan physique peuvent s'exécuter dans Photon. Les opérations non prises en charge retombent sur le runtime Spark standard.
Ce dernier point compte pour les coûts. Activer Photon ne signifie pas que chaque opération d'un job passe par Photon. La répartition des opérateurs détermine quelle part du workload peut utiliser Photon ; il faut donc la mesurer avant de juger des performances ou du coût.
Le multiplicateur de DBU et le calcul du seuil de rentabilité
Si Photon consomme environ 2× plus de DBU sur un cluster classique, un job doit s'exécuter plus de 2× plus vite pour que le tarif de calcul plus élevé se transforme en économie. C'est le repère à garder en tête lorsque vous examinez un benchmark Photon.
Prenons un job qui tourne normalement 60 minutes. Avec une accélération de 1,5×, Photon le ramène à 40 minutes, mais le taux de DBU doublé signifie que vous consommez encore environ 33 % de DBU en plus. Poussez l'accélération à 3× : le job se termine en 20 minutes et consomme environ deux tiers des DBU, soit une économie d'environ 33 %. À 2×, la durée plus courte et le taux de DBU plus élevé s'annulent.
Le résultat dépend fortement de ce que fait réellement la requête. Un job dominé par les scans, lisant du Parquet ou du Delta avec des filtres sélectifs, offre à Photon beaucoup de travail d'exécution native. Même chose pour une grosse agrégation sur une table de faits ou une jointure par hachage dont un côté peut être diffusé (broadcast). Ce sont les workloads pour lesquels les benchmarks publiés ont montré des accélérations au-delà du seuil de rentabilité de 2×.
La donne change lorsque la partie coûteuse du job n'est pas quelque chose que Photon peut accélérer. Une UDF Python peut renvoyer l'exécution vers la JVM et Python. Un job court peut passer plus de temps en planification et en ordonnancement qu'en exécution réelle. Un shuffle important peut passer son temps à déplacer des données sur le réseau ou à attendre le disque. Accélérer la partie CPU n'aide pas beaucoup quand ce n'est pas le CPU que le job attend.
Le tableau ci-dessous replace le seuil de rentabilité de 2× dans son contexte, en montrant quels profils de workloads ont des chances de le franchir et lesquels non.
La tendance de coût suppose un multiplicateur de DBU Photon d'environ 2× sur un calcul équivalent en cluster classique. Les taux de DBU réels varient selon le type d'instance : c'est l'accélération mesurée qui détermine le résultat.
Le seuil de 2× vous donne le calcul. Le plan d'exécution vous dit si votre job a une chance réaliste de le franchir.
Couverture des opérateurs : ce qui s'exécute en natif et ce qui bascule en fallback
Photon n'exécute pas tous les opérateurs Spark. Certains s'exécutent en natif, d'autres retombent sur la JVM. Vous payez quand même le tarif du calcul avec Photon activé, même lorsque la partie coûteuse du workload ne s'exécute pas en natif.
Prenez une requête qui lit une grande table Delta Lake, filtre la majorité des lignes, agrège ce qui reste et joint le résultat à une autre table. Ce sont les types d'opérations pour lesquels Photon a un vrai travail CPU à optimiser. Insérez maintenant une UDF Python au milieu. Cette partie emprunte un chemin d'exécution différent, et si c'est dans l'UDF que le job passe l'essentiel de son temps, Photon ne touche pas au goulot d'étranglement. Un cluster avec Photon activé ne signifie pas que toute la requête s'exécute dans Photon. C'est le plan physique qui décide quelles parties le font réellement.
Pour les workloads de données courants, Photon peut exécuter en natif les scans Parquet et Delta, les filtres, projections, agrégations et jointures par hachage. Les fonctions de fenêtrage et les tris sont également pris en charge, ainsi que les opérations courantes sur les chaînes de caractères. Les UDF Python et Scala retombent en fallback, tandis que certaines opérations regex, MAP``/``STRUCT, de streaming sink et CSV/JSON dépendent de l'opération spécifique et de la version du Databricks Runtime. Lorsque c'est possible, remplacez une UDF par une fonction Spark SQL intégrée pour garder davantage de travail sur le chemin natif. Si le temps de scan domine le job, l'organisation de vos tables influe sur ce que Photon doit scanner. Le Liquid Clustering mérite un coup d'œil pour ce volet du problème.
Le tableau ci-dessous montre les workloads que Photon peut exécuter en natif et les cas de fallback :
Le query profile et le plan physique montrent ce qui s'est passé sur votre propre job. Identifiez les opérateurs qui consomment le plus de temps d'exécution, puis vérifiez s'ils sont passés par Photon ou s'ils ont basculé en fallback. C'est la preuve dont vous avez besoin pour savoir si Photon a vraiment aidé.
Le comportement de Photon selon les surfaces de calcul
L'endroit où vous exécutez le workload change la façon dont Photon est configuré et dont la facturation fonctionne. Cela compte lorsque le même job passe d'un cluster classique à un SQL warehouse puis au serverless, et que les chiffres ne concordent soudainement plus.
Avec les SQL warehouses Databricks, Photon est activé par défaut sur le niveau Classic. Les niveaux Pro et Serverless fonctionnent exclusivement avec Photon. Si vous faites de l'analytique SQL, se demander si Photon est activé n'a donc guère d'intérêt. La bonne question, c'est ce que dit le query profile et si le travail réellement effectué par Photon suffit à justifier le calcul.
Comment activer Photon sur les clusters classiques
Sur les clusters classiques, Photon est activé par défaut pour le calcul all-purpose et jobs, et le paramètre Use Photon Acceleration permet de le désactiver. Si vous créez du calcul via l'API, vous pouvez définir explicitement runtime_engine: "PHOTON". Le type d'instance doit toutefois prendre en charge Photon.
La comparaison 2× des DBU évoquée plus haut est particulièrement utile sur les clusters classiques. Pour comprendre ce que Photon fait à un job ETL récurrent, exécutez le même workload sur le même type d'instance avec et sans Photon. Regardez à la fois le temps d'exécution et les DBU. Un job plus rapide n'est intéressant que s'il devient assez rapide pour compenser le tarif plus élevé.
Photon sur le calcul serverless
Sur le calcul serverless, Photon est activé par défaut, mais vous ne gérez pas de cluster, ne choisissez pas la famille de VM et n'activez pas le runtime vous-même. Databricks s'occupe de cette couche pour vous. Le hic : le serverless repose sur un modèle de tarification différent, et le calcul 2× des clusters classiques ne se transpose donc pas directement. Lakebase fonctionne sur ce même modèle serverless, à garder en tête si vous le chiffrez aux côtés de workloads Photon en cluster classique ; les structures de prix ne sont pas les mêmes.
La différence de tarification compte lorsque les workloads passent d'une surface de calcul à une autre. Le moteur peut rester le même alors que l'économie sous-jacente change. Qu'un job soit peu coûteux sur un cluster classique avec Photon activé ne signifie pas que son passage en serverless produira le même profil de coûts. La surface de calcul fait partie de l'équation. Si vous menez cette analyse à l'échelle de votre environnement Databricks, Databricks Cost Optimization couvre les autres leviers, de l'arrêt automatique et du dimensionnement du calcul à l'organisation des tables et à la gouvernance.
Lire le query profile pour mesurer la couverture Photon
Pour savoir si Photon a réellement amélioré les performances, commencez par le query profile, pas par le temps écoulé. Le profil montre où le workload a passé son temps et quelles parties du plan ont utilisé le moteur.
Un workload peut se terminer plus tôt et ne rien vous dire ou presque sur l'aspect économique. Si l'essentiel du temps de tâche est allé à des scans, jointures ou agrégations natifs Photon, l'accélération a une explication claire. Si les opérateurs coûteux ont basculé sur le chemin d'exécution standard, ou si la majeure partie du temps est partie en shuffle et en I/O, le moteur ne fait pas grand-chose pour la partie qui compte.
Voici à quoi cela ressemble dans le query profile :
Dans cet exemple, 93 % du temps de tâche est passé par Photon. La requête a lu 29 999 795 lignes réparties sur 10 fichiers, pour un temps de tâche total de 3,86 secondes. C'est un signe clair que Photon a géré l'essentiel de l'exécution des tâches.
Le chiffre important n'est pas seulement le pourcentage. Regardez en parallèle ce que la requête faisait réellement. Ce résultat de 93 % est un gain net parce que les opérateurs coûteux, le scan et l'agrégation, se sont tous deux exécutés en natif. Ce ne sera pas toujours aussi net. Imaginons qu'une autre requête passe 70 % de son temps dans une UDF Python ou à attendre un shuffle important. Y activer Photon ne touche pas au véritable goulot d'étranglement, quel que soit le temps d'exécution affiché ensuite. Le pourcentage ne vous apprend quelque chose qu'une fois que vous savez ce qu'il mesure.
C'est aussi là que la couverture des opérateurs vue dans la section précédente prend tout son sens : il ne s'agit pas de compter combien d'opérateurs utilisent Photon, mais de trouver où le temps de tâche est réellement parti.
C'est également ainsi que l'on explique des résultats surprenants a posteriori. Un job peut afficher une amélioration notable du temps d'exécution alors que l'essentiel du travail coûteux se situe hors de Photon. Un autre peut obtenir un gain plus important parce que ses plus gros opérateurs s'exécutent en natif. Même métrique de temps d'exécution, raisons sous-jacentes différentes : c'est le profil qui vous dit auquel des deux cas vous avez affaire.
Pour les workloads ETL et SQL récurrents, c'est la vérification à faire avant de décider si Photon mérite ses DBU : identifiez les opérateurs coûteux, regardez quel chemin ils ont emprunté, puis reliez cela au temps d'exécution et au coût.
Mesurer le coût de Photon avec SELECT
Un workload Photon plus rapide n'est pas automatiquement moins cher. Il faut relier l'amélioration du temps d'exécution aux DBU et au coût d'infrastructure avant de crier victoire.
SELECT vous permet de rattacher les dépenses Databricks aux jobs, clusters et warehouses, avec la consommation de DBU et les coûts d'infrastructure sous-jacents dans une même vue. Pour un job ETL récurrent, comparez des exécutions équivalentes avant et après le changement Photon. Comparez ensemble performances, DBU et coût total. Si le job se termine plus vite mais que le tarif Photon plus élevé fait grimper le coût, l'accélération n'a pas été rentable. La même attribution couvre les coûts de serving de modèles IA dans Agent Bricks si Photon n'est qu'une pièce d'un workload plus large.
Le taux de DBU 2× évoqué plus haut vous donne la référence. Un workload en cluster classique doit être environ 2× plus rapide pour atteindre le seuil de rentabilité. SELECT vous fournit les données d'utilisation et de coût au niveau du job pour voir où se situe réellement votre workload, au lieu d'estimer à partir du seul temps d'exécution.
Le query profile montre où le moteur a aidé. SELECT montre les DBU et le coût d'infrastructure derrière cette amélioration. Ensemble, ils révèlent si un workload ETL ou SQL récurrent devient moins cher à mesure qu'il accélère. Réservez une démo pour effectuer cette comparaison sur vos propres jobs avec Photon activé.
Questions fréquentes
Photon fonctionne-t-il avec mon code Spark existant ?
Oui. Photon s'exécute sous le même modèle de programmation Spark : vous n'avez donc pas besoin de réécrire vos jobs Spark pour l'utiliser. Vos workloads DataFrame et SQL existants peuvent utiliser Photon lorsque leur plan physique correspond à des opérateurs natifs pris en charge. Le point principal à vérifier est la couverture des opérateurs, surtout si votre pipeline s'appuie fortement sur des UDF ou d'autres opérations qui retombent sur le chemin d'exécution Spark standard.
Pourquoi mes UDF Python ne sont-elles pas plus rapides avec Photon activé ?
Parce que Photon n'exécute pas nativement les UDF Python arbitraires, l'UDF passe par le chemin d'exécution Spark et Python standard, et Photon ne peut donc pas optimiser le code Python lui-même. Si l'UDF est votre goulot d'étranglement, activer Photon ne changera pas grand-chose. Dans la mesure du possible, remplacez l'UDF par une fonction SQL intégrée. Si une UDF Python est inévitable, une pandas_udf peut réduire une partie de la surcharge Python/JVM, mais elle ne rend pas l'UDF native pour Photon.
Comment vérifier quel pourcentage de ma requête s'est exécuté sur Photon ?
Ouvrez le query profile de la requête terminée et allez dans Aggregated task time → Tasks time in Photon. Ce pourcentage vous indique quelle part du temps de tâche est passée par Photon. Vérifiez ensuite la répartition par opérateur pour voir où est allé le temps restant. Le pourcentage seul ne suffit pas : vous devez aussi savoir si Photon a géré la partie coûteuse du workload.
Photon coûte-t-il plus cher que le Databricks Runtime standard ?
Sur les clusters classiques, oui. Le calcul avec Photon activé a un taux de DBU plus élevé qu'un calcul équivalent sans Photon. Le multiplicateur exact dépend du type d'instance, mais environ 2× est le chiffre utile pour le calcul de coût. Cela signifie que le workload doit être environ 2× plus rapide pour atteindre le seuil de rentabilité.
Photon prend-il en charge l'accélération GPU ?
Non. Photon est un moteur d'exécution natif basé sur le CPU, pas un moteur d'exécution GPU. Il accélère les opérations Spark prises en charge via une exécution CPU native. Si votre workload nécessite du calcul GPU pour du machine learning ou un autre usage spécifique au GPU, Photon ne remplace pas le calcul avec GPU.