Fonctions scalaires définies par l’utilisateur - Scala

Article
10/25/2024

Cet article contient des exemples de fonctions définies par l’utilisateur (UDF) Scala. Il montre comment inscrire des fonctions définies par l’utilisateur, appeler des fonctions définies par l’utilisateur, ainsi que des avertissements concernant l’ordre d’évaluation des sous-expressions dans Spark SQL. Voir Fonctions scalaires externes définies par l'utilisateur (UDF) pour plus de détails.

Remarque

Les fonctions définies par l’utilisateur (UDF) Scala sur les ressources de calcul compatibles avec le catalogue Unity avec un mode d’accès partagé nécessitent Databricks Runtime 14.2 ou versions ultérieures.

Inscrire une fonction en tant que fonction définie par l’utilisateur

val squared = (s: Long) => {
  s * s
}
spark.udf.register("square", squared)

Appeler la fonction définie par l’utilisateur dans Spark SQL

spark.range(1, 20).createOrReplaceTempView("test")

%sql select id, square(id) as id_squared from test

Utiliser une fonction définie par l’utilisateur avec des tramedonnées

import org.apache.spark.sql.functions.{col, udf}
val squared = udf((s: Long) => s * s)
display(spark.range(1, 20).select(squared(col("id")) as "id_squared"))

Ordre d’évaluation et vérification de valeur null

Spark SQL (incluant SQL et les API TrameDonnées et Jeu de données) ne garantit pas l’ordre d’évaluation des sous-expressions. En particulier, les entrées d’un opérateur ou d’une fonction ne sont pas nécessairement évaluées de gauche à droite ou dans tout autre ordre fixe. Par exemple, les expressions logiques AND et OR n’ont pas de sémantique de « court-circuit » de gauche à droite.

Il est donc dangereux de s’appuyer sur les effets secondaires ou l’ordre d’évaluation des expressions booléennes, ainsi que sur l’ordre des clauses WHERE et HAVING, car ces expressions et clauses peuvent être réordonnées lors de l’optimisation et de la planification des requêtes. Plus précisément, si une fonction définie par l’utilisateur repose sur une sémantique de court-circuit dans SQL pour la vérification de valeur null, il n’est pas garanti que celle-ci intervienne avant l’appel de la fonction définie par l’utilisateur. Par exemple,

spark.udf.register("strlen", (s: String) => s.length)
spark.sql("select s from test1 where s is not null and strlen(s) > 1") // no guarantee

Cette clause WHERE ne garantit pas que la fonction définie par l’utilisateur strlen est appelée après le filtrage des valeurs null.

Pour effectuer une vérification de valeur null correcte, nous vous recommandons d’effectuer l’une des opérations suivantes :

Rendez la fonction définie par l’utilisateur sensible aux valeurs null, et effectuez une vérification de valeur null dans la fonction définie par l’utilisateur
Utilisez des expressions IF ou CASE WHEN pour effectuer la vérification de valeur null et appeler la fonction définie par l’utilisateur dans une branche conditionnelle

spark.udf.register("strlen_nullsafe", (s: String) => if (s != null) s.length else -1)
spark.sql("select s from test1 where s is not null and strlen_nullsafe(s) > 1") // ok
spark.sql("select s from test1 where if(s is not null, strlen(s), null) > 1")   // ok

API de jeu de données typé

Remarque

Cette fonctionnalité est prise en charge sur les groupements du catalogue Unity avec le mode d’accès partagé dans Databricks Runtime 15.4 ou versions ultérieures.

Les API de jeux de données typés vous permettent d’exécuter des transformations telles que mappage, filtre et agrégations sur les jeux de données résultants à l’aide d’une fonction définie par l’utilisateur.

Par exemple, l’application Scala suivante utilise l’API map() pour modifier un nombre dans une colonne de résultat en chaîne préfixée.

spark.range(3).map(f => s"row-$f").show()

Bien que cet exemple utilise l’API map(), il s’applique également aux autres API de jeu de données typé telles que filter(), mapPartitions(), foreach(), foreachPartition(), reduce(), et flatMap().

Partager via