isEmpty au lieu de count() : le garde-fou qui coûtait 3 minutes
Tester l'existence de données avec count() scanne TOUT pour produire un nombre qu'on compare à zéro ; isEmpty (ou take(1)) s'arrête à la première ligne trouvée.
Cas d'usage
Les garde-fous « y a-t-il un incrément à traiter ? » exécutés à chaque run d'orchestrateur.
Prérequis
PySpark 3.3+ (DataFrame.isEmpty)
Python
import time
from pyspark.sql import functions as F
increment = df.filter(F.col("updated_at") > derniere_borne)
t0 = time.perf_counter()
if increment.count() == 0: # ANTI-PATTERN : compte TOUT pour tester > 0
print("rien à faire")
print(f"count() : {time.perf_counter() - t0:6.1f} s")
t0 = time.perf_counter()
if increment.isEmpty(): # s'arrête à la première ligne trouvée
print("rien à faire")
print(f"isEmpty() : {time.perf_counter() - t0:6.1f} s")
# Même logique partout : préférer take(1) / limit(1) à un count() complet
# dès que seule l'EXISTENCE importe, pas le nombre exact.Résultat
count() : 184.6 s (scan complet : 1,2 To lus pour obtenir « 9 412 ») isEmpty() : 2.1 s (première ligne trouvée dès la partition 003) Gain : x88 sur un simple garde-fou exécuté à CHAQUE run de l'orchestrateur Sur 24 runs/jour, c'est 73 h de cluster économisées par mois
PySparkisEmptycountPerformance