Blog d'Univalence

Focus sur le Z-Ordering et le Liquid Clustering avec Delta Lake

2024-04-04T22:00:00Z

Dans mon apprentissage de Delta Lake, un format de stockage open-source qui permet notamment d’avoir les propriétés ACID sur des systèmes de stockage qui de base ne les ont pas, entre autres, on m’a parlé de Z-Ordering et de Liquid Clustering pour améliorer les performances des requêtes. Mais que sont-ils ? À quoi peuvent-ils servir ? Nous vous expliquerons tout cela dans cet article.

Z-Ordering

Data-skipping

Un des aspects qui améliore les performances, est le data-skipping (ou file-skipping), en effet la lecture d’un fichier pour le transférer dans la mémoire est coûteux, donc moins nous lisons de fichier, plus la requête sera performante. Pour cela Delta utilise les métadonnées de ses fichiers pour savoir si le fichier doit être lu ou non, on y trouve le minimum et le maximum de chaque colonne par fichier ce qui permet de le déterminer.

Compaction

Un autre aspect, est la réduction de nombre de fichier avec la compaction, en compactant la table, c’est à dire que moins de fichier seront à lire.

Illustration

Le Z-Ordering utilise ces aspects d’amélioration de performance, en effet si nous utilisons le Z-Order selon une colonne id par exemple, alors toutes les occurrences d’un même id vont être colocalisés au sein d’un fichier mais de façon ordonnée et les plages d’id de chaque fichier sera plus petite.

Dans l’exemple simplifié ci-dessous, à droite nous avons notre donnée non ordonné repartie sous 4 partitions, on voit dans les métadonnées de chaque partition le minimum et le maximum de la colonne id.

Après l’application du Z-Order, à droite, nous n’avons plus que 2 partitions, et elles sont ordonnées par plage, la partition 1 contient les ids entre 1 et 5 et la partition 2 contient ceux entre 6 et 10.

Imaginions que nous voulions faire un SELECT * FROM table where id = 5 dans le premier cas nous aurions lu un total de trois partitions contre un après le Z-Order.

OK, mais comment cela fonctionne à partir de 2 colonnes ?

extrait de la page Wikipedia https://en.wikipedia.org/wiki/Z-order_curve

Imaginez que nous vous utiliser le Z order sur les colonnes x et y, l’algorithme va calculer les coordonnées Z (ou z-values) de la façon suivante, il va d’abord changer chaque valeur de colonne en binaire, puis va interchanger la valeur binaire de x et y pour donner z, exemple :

Si l’on prend x = 3 (011) et y = 7 (111) on obtiendra z = 47 (101111)

Si nous parcourrons les valeurs de z dans l’ordre croissant, nous obtenons le schéma ci-dessus, qui étonnement forme aussi un Z (à plusieurs niveaux en plus) ! On appelle cela le Z-Order curve (ou Courbe de Lebesgue en français).

L’emploi de la commande du Z-Order va appliquer ce qu’on a vu pour une colonne à ces coordonnées Z pour réorganiser notre table, avec des plages de coordonnées Z sous la même partition (sur l’illustration, on peut imaginer que chaque carré de pointillé devient une partition), donc c’est un peu comme transformer le problème à plusieurs dimensions en un problème à une dimension.

Comparaison

Voici un exemple donné dans le design sketch de la fonctionnalité.

Ici, chaque fichier à 4 occurrences, à gauche nous avons le tri naturel, on ordonne d’abord par x puis par y, et à droite le Z-Order comme sur la figure précédente.

Voici ce qui se passerait avec la requête SELECT * FROM points WHERE x = 2 OR y = 3

À gauche, nous scannons 9 fichiers avec 21 occurrences qui ne nous intéressent pas.
À droite, nous scannons 7 fichiers avec 13 occurences qui ne nous intéressent pas.

C’est pourquoi avec cette courbe nous avons un data-skipping plus efficace pour un prédicat qui contient x et y.

Quand l’utiliser ?

Il faut faire le Z-Order si vos colonnes sont souvent utilisées dans vos requêtes et si elles ont une haute cardinalité (beaucoup de valeurs distinctes).

Le prérequis est que vos colonnes doivent avoir la collecte de statistiques activée (pour utiliser les métadonnées afin d’enclencher le data-skipping).

Il ne faut pas non plus ajouter chaque colonne, en effet augmenter la dimension fera diminuer les performances si l’on utilise très peu les colonnes ajoutées dans nos prédicats.

Le Z-Ordering est aussi compatible avec le Hive-Style-Partitioning (où les valeurs de la colonne de partition seront utilisés comme dossier pour séparer les fichiers), dans le sens où l’on peut réordonner les fichier au sein de ses dossiers, mais on ne pourra pas utiliser la colonne de partition pour le Z-Ordering.

Par contre la commande doit être ré-exécuté assez régulièrement, quand nous avons de nouvelles données par exemple, l’opération est coûteuse, en effet on réécrit tous les fichiers ce qui peut en faire aussi un désavantage, il faut aussi se souvenir des colonnes utilisées pour le Z-Order. Aussi si l’opération d’optimisation échoue, il faut la recommencer.

Mais justement nous allons voir qu’une autre fonctionnalité existe et arrive avec le Liquid Clustering qui remédie à ses limitations.

Pour aller plus loin

Pour plus d’informations, n’hésitez pas à regarder la documentation, et l’article officiel de Delta Lake, ainsi que leur notebook. Par curiosité allez voir le sketch pour créer la fonctionnalité. Cette vidéo explicative est pas mal aussi.

Liquid Clustering

L’annonce de Delta Lake version 3.0 en Juin 2023 s’est vu accompagné de la venu du Liquid Clustering, qui simplifierait la façon d’obtenir les meilleurs performances pour nos requêtes et son coût pour l’obtenir en même temps que la donnée grandit.

Aujourd’hui avec Delta Lake 3.1, la fonctionnalité est présente mais est toujours en expérimentation.

Toutes les illustrations proviennent de leur Design Doc .

Nous avions vu que le Hive-Style-Partitioning et le Z-Order pouvait cohabiter et être une bonne approche pour partitionner nos tables. Mais ils viennent avec leur limitation :

Le Hive-Style-Partitioning permet de cloisonner nos fichiers, mais si les colonnes de partitions ont une haute cardinalité cela va créer plusieurs petits fichiers que l’on ne peut combiner. Changer de stratégie de partitions peut être difficile, donc moins adaptable à la façon dont nous requêtons.
Pour le Z-Order, toutes les limitations vu plus tôt.

L’idée avec le Liquid Clustering est de supprimer toutes ses limitations :

En mettant les colonnes de clustering directement au moment de la création de la table
- elles seront persistées dans les métadonnées
- on peut changer les colonnes de clustering pour s’adapter aux nouvelles stratégie de requêtage ou autre, sans pour autant tout recalculer.
Le clustering se fait de manière incrémentale, sans toucher à l’intégralité des données

Courbe de Hilbert

Avec le Z-Order, nous avons vu l’application de la Z-Order curve (Courbe de Lebesgue), ici dans l’image ci-dessous provenant de leur Design Doc, ils veulent utiliser une autre courbe qui est la Courbe de Hilbert où la distance entre chaque point selon la courbe est de 1.

De manière similaire au Z-Order, on peut les partitionner par 4 en suivant la courbe.

Comparaison

Sur le schéma ci-dessus nous avons au final un même partionnement que pour le Z-Order, donc en quoi est-ce que la Courbe de Hilbert est mieux ?

Une bonne illustration est de voir ce qui se passe si nous partitionnons avec 6 éléments en suivant la courbe de chacun :

Avec Z-Order :

Le problème est bien visible ici, sur la partition entourée rouge, en effet avec Z-Order nous avons des “sauts” ce qui a pour impact d’avoir une trop grand plage de données, ici on aurait :

pour y : min = 3 et max = 5
mais pour x : min = 0 et max = 7 !

Avec Courbe de Hilbert :

Avec cette courbe, la distance entre toujours réduite, l’écart maximal est de 4.

Avec Z-Order, il y aurait un fichier qu’on lirait tout le temps si on cherche n’importe quel x, alors qu’avec l’autre courbe il n’existe pas de tel fichier.

Incremental Clustering

Le concept tourne autour de ZCube : un groupement de fichier produit par le même job OPTIMIZE.

Il y a une distinction à faire entre :

les fichiers provenant de ZCube “stables”, donc optimisé.
les nouveaux fichiers ou fichiers non optimisées qui appartienent à un ZCube partiel.

Il y a deux paramètre de configuration pour définir ce qu’est un ZCube et ZCube partiel.

MIN_CUBE_SIZE : Taille du ZCube pour laquelle les nouvelles données ne seront plus fusionnées avec celui-ci lors du OPTIMIZE incrémentiel. La valeur par défaut est 100 Go.
TARGET_CUBE_SIZE : taille cible des ZCubes que nous allons créer. Il ne s’agit pas d’un maximum absolu ; nous continuerons à ajouter des fichiers à un ZCube jusqu'à ce que leur taille combinée dépasse cette valeur. Cette valeur doit être supérieure ou égale à MIN_CUBE_SIZE. La valeur par défaut est 150 Go.

Un ZCube est partiel si sa taille est plus petite que le MIN_CUBE_SIZE.

Que se passe-t-il lors du déclenchement d’un OPTIMIZE ?

Un ensemble de fichiers candidats va être sélectionnés, ils proviennent soient de :

ZCubes partiels
ou de nouveaux fichiers qui ont été ajoutés après

Pour les rassembler en plusieurs ZCubes, où l’algorithme de la courbe va être appliqué. Chaque ZCube créé produit un commit, ce qui permet de sauvegarder le résultat partiel en cas de crash.

Une analogie intéressante, qui illustre un peu le comportement du Liquid Clustering est que cela ressemble à une défragmentation de disque dur, on va chercher à remplir les ZCube au maximum pour éviter les petits fichiers.

Quand l’utiliser ?

De la même manière que Z-Order, il faut le faire sur des colonnes souvent utilisées comme prédicat et qui ont une haute cardinalité.

Le liquid clusturing offre surtout une flexibilité accrue par rapport au Z-Ordering, par rapport à la construction du clustering et sa maintenance, donc il conviendra mieux aux tables dont les requêtes sont voués à changer souvent, et aux tables qui grandissent vite.

Si les colonnes de clusturing changent, alors les fichiers produits et déjà optimisés précédemment avec l’ancien set de colonnes ne seront pas touchés. Seul les nouvelles données seront clusterisés avec le nouveau set de colonnes.

Cela n’est pas compatible avec le Z-Order et le Hive-Style-partitioning, pour convertir ces tables il faudra utiliser les colonnes de partitions et Z-Order comme colonnes de Liquid Clusturing.

Comme dit en début de cette section, le Liquid Clustering est encore en phase expérimentale, toutes les fonctionnalités ne sont pas encore supportés dans la version 3.1 de Delta Lake.

Pour aller plus loin

Design Doc de la fonctionnalité, documentation officielle. Un extrait de la vidéo de la Keynote d’annonce des nouveautés de Delta Lake 3.0 au Data + AI Summit, qui illustre rapidement le Liquid Clustering.

Conclusion

J’espère que vous en savez maintenant plus sur ce qu’est le Z-Ordering et le Liquid Clustering, et comment ils peuvent améliorer les performances de vos tables, Il faudra surveiller de près ce qui fait autour de ce dernier.

Créer ou modifier un tableau croisé dynamique à partir de ses données Spark avec Apache POI

2024-04-03T22:00:00Z

Il peut vous arriver lors de votre carrière que l’on vous demande de créer un fichier Excel à partir de vos données, que soit pour du reporting ou autres. Pour créer des fichiers Excel en Scala, on va devoir utiliser l’interopérabilité avec Java et utiliser une bibliothèque Java Open Source bien connue pour manipuler les fichiers Microsoft, Apache POI.

Configuration

Dans notre build.sbt il faut importer les librairies Spark et POI, ici leur dernière version à date.

libraryDependencies ++= Seq(
  "org.apache.poi" % "poi" % "5.2.5",
  "org.apache.poi" % "poi-ooxml" % "5.2.5",
  "org.apache.poi" % "poi-ooxml-lite" % "5.2.5",
  "org.apache.spark" %% "spark-core" % "3.5.1",
  "org.apache.spark" %% "spark-sql" % "3.5.1"
)

Pour le jeu de données que l’on va utiliser en exemple, nous allons prendre ces données Open Data de Paris https://opendata.paris.fr/explore/dataset/compte-de-resultat/information/ qui sont les comptes de résultats de la ville, l’export parquet a été utilisé.

Comment créer un fichier Excel à partir de mes données Spark ?

Pour faire cela, il n’y a pas vraiment d’autres choix que d’abord “collecter” vos données, (après agrégation ou non), et de transformer vos lignes afin de créer chaque cellule de notre fichier Excel.

Pour la création de cellules, cela se fait de manière “classique” :

D’abord en instanciant un objet XSSFWorkbook pour travailler avec le type de fichier .xlsx.
Ensuite nous aurons besoin d’une feuille, pour cela il faudra créer un objet XSSFSheet, à l’aide de la méthode createSheet sur l’objet XSSFWorkbook.
Il vous faudra ensuite créer les lignes à partir de ce dernier avec createRow, ce qui nous donne un objet XSSFRow.
Puis créer les cellules avec createCell sur les objets XSSRow, ce qui donnera un objet XSSFCell.
Et enfin pour modifier le contenu de vos cellules, il faudra utiliser la méthode setCellValue.

Pour écrire notre fichier, on utilisera la méthode write du XSSFWorkbook, qui prend en paramètre un OutputStream.

Voici un exemple de code :

import org.apache.poi.xssf.usermodel.{XSSFCell, XSSFRow, XSSFSheet, XSSFWorkbook}
import org.apache.spark.sql.{Row, SparkSession}
import java.io.{FileNotFoundException, FileOutputStream, IOException}

val spark = SparkSession.builder()
  .master("local[*]")
  .getOrCreate()
  
val compteDeResultatDf = spark.read.parquet("compte-de-resultat.parquet")

/*
compteDeResultatDf.printSchema()
root
 |-- exercice_comptable: string (nullable = true)
 |-- type_de_resultat: string (nullable = true)
 |-- produit_charge: string (nullable = true)
 |-- poste: string (nullable = true)
 |-- detail_postes: string (nullable = true)
 |-- montant_en_eur: double (nullable = true)
 */
 
//certains montants sont à null, on leur donne le montant 0 par défaut.
//et mise à négatif du montant quand son type est charges.
val dfCleaned = compteDeResultatDf
  .na.fill(0, Seq("montant_en_eur"))
  .withColumn("montant_en_eur",
    when($"produit_charge" === "CHARGES", -$"montant_en_eur") //mise à négatif du montant quand son type est charges
      .otherwise($"montant_en_eur")
  )
  
val dataCollected = dfCleaned
        .collect()

val wb: XSSFWorkbook = new XSSFWorkbook() //création du workbook
val sheet: XSSFSheet = wb.createSheet("ma feuille") //création d'une feuille dans le workbook

//Création d'un style de cellule pour les montants, ici pour obtenir 2 chiffres après la virgule dans Excel
val amountStyle= wb.createCellStyle()
  amountStyle.setDataFormat(wb.createDataFormat().getFormat("0.00"))
  
//notre première ligne sera le header de nos données
val header = dfCleaned.columns
val headerRow = sheet.createRow(0)
for {
  i <- header.indices
  cell = headerRow.createCell(i)
} yield cell.setCellValue(header(i))

for {
  i <- dataCollected.indices
  poiRow: XSSFRow = sheet.createRow(i) //pour chaque ligne de nos données, on créé une ligne Excel, en sautant la première ligne dans l'Excel
  sparkRow: Row = dataCollected(i) //on prend aussi la Row en cours
  j <- 0 until sparkRow.size
  cell: XSSFCell = poiRow.createCell(j) //pour chaque colonne de nos données, on créé une cellule Excel
  value: Any = sparkRow(j) //on prend la valeur de la colonne en cours
} yield value match {
  //Pattern matching pour éventuellement convertir certaines données,
  //en effet setCellValue n'accepte que certains types en entrée.
  //Ici que Double et String car le schéma de notre DataFrame ne contient que ces derniers pour l'exemple.
  //On peut y ajouter du Style/Formattage selon le type auquel on match,
  //ici le format qui nous permet d'avoir 2 chiffres après la virgule.
  case d: Double => {
    cell.setCellStyle(amountStyle)
    cell.setCellValue(d)
  }
  case s: String => cell.setCellValue(s)
}

//pour régler la largeur de nos colonnes automatiquement, attention plus vous avez de données, plus cela est coûteux
header.indices.foreach(sheet.autoSizeColumn)

//écriture de notre fichier
val os = new FileOutputStream("workbook.xlsx")
try {
  wb.write(os)
} catch {
  case fnf: FileNotFoundException => fnf.printStackTrace()
  case ioe: IOException => ioe.printStackTrace()
} finally {
  os.close()
}

Voici le résultat après ouverture du fichier sous Excel :

Comment faire pour créer un tableau croisé dynamique avec Apache POI ?

Maintenant que nous avons vu comment comment créer un fichier Excel à l’aide de nos données, nous allons voir comment créer un tableau croisé dynamique.

Une fois notre XSSFWorkbook instancié et rempli de données, il suffira d’utiliser la méthode .createPivotTable sur un objet XSSFSheet. La méthode prend en paramètre :

le tableau source qui sera utilisé pour le tableau croisé dynamique, ci-dessous on utilisera un objet AreaReference pour indiquer la plage du tableau
la cellule qui recevra le TCD, on utilise un objet CellReference pour cela, la cellule est dans la feuille avec laquelle on a invoqué la méthode
en option, un object XSSFSheet, si la source est dans une autre feuille, cela sera le cas de notre exemple

On reprend le code précédent juste avant l’écriture du fichier:

import org.apache.poi.ss.usermodel.DataConsolidateFunction
import org.apache.poi.ss.util.{AreaReference, CellReference}
import org.apache.poi.xssf.usermodel.{XSSFCell, XSSFPivotTable, XSSFRow, XSSFSheet, XSSFWorkbook}

/*
code précédent de création
*/

//on créé une nouvelle feuille qui va contenir notre TCD
val tcdSheet: XSSFSheet = wb.createSheet("TCD")
val pivotTable: XSSFPivotTable = tcdSheet.createPivotTable(
  new AreaReference("A1:F288", null), //les coordonnées du tableau source, null car la méthode prend par défaut un deuxième paramètre qui est la version du spreadsheet
  new CellReference("A1"), //celulle qui recevra le TCD
  sheet) //on reference la feuille source optionnellement, par défaut la feuille source est celle utilisée pour invoquer la méthode createPivotTable 
      
 
//Nous allons utiliser comme étiquette de lignes :
pivotTable.addRowLabel(0) //exercice_comptable -> colonne 0 de notre tableau source
pivotTable.addRowLabel(1) //type_de_resultat
pivotTable.addRowLabel(2) //produit_charge
//Nous ajoutons une colonne qui sommera les montants
pivotTable.addColumnLabel(DataConsolidateFunction.SUM, 5)

//écriture de notre fichier
val os = new FileOutputStream("workbook.xlsx")
try {
  wb.write(os)
} catch {
  case fnf: FileNotFoundException => fnf.printStackTrace()
  case ioe: IOException => ioe.printStackTrace()
} finally {
  os.close()
}

On retrouve notre TCD dans la feuille “TCD” :

Comment faire pour modifier un fichier Excel déjà existant avec mes données ?

Et si nous souhaitons, mettre à jour nos données ? Imaginons que c’est une correction de montants à appliquer. Nous allons créer la case class CompteDeResultat et créer un petit Dataset de correction.

case class CompteDeResultat(
                             exercice_comptable: String,
                             type_de_resultat: String,
                             produit_charge: String,
                             poste: String,
                             details_postes: String,
                             montant_en_eur: Double
                           )

import org.apache.poi.ss.usermodel.{Cell, Row, Sheet, Workbook, WorkbookFactory}
import org.apache.spark.sql.{Dataset, SparkSession}

import java.io.{FileInputStream, FileNotFoundException, FileOutputStream, IOException}
import scala.jdk.CollectionConverters._

//création "rapide" d'un dataset de correction de montants, cela aurait pu venir d'une table de correction
val spark = SparkSession.builder()
  .master("local[*]")
  .getOrCreate()
  
import spark.implicits._

val correctionDS: Dataset[CompteDeResultat] = List(
  CompteDeResultat("2016","EXPLOITATION","PRODUITS","PRODUITS COURANTS NON FINANCIERS","Production stockée", 99999999999.0),
  CompteDeResultat("2016","FINANCIER","PRODUITS","PRODUITS COURANTS FINANCIERS","Valeurs mob et créances de l'actifimmo", 55555555555.0)
).toDS
/*
correctionDS.printSchema()
root
 |-- exercice_comptable: string (nullable = true)
 |-- type_de_resultat: string (nullable = true)
 |-- produit_charge: string (nullable = true)
 |-- poste: string (nullable = true)
 |-- detail_postes: string (nullable = true)
 |-- montant_en_eur: double (nullable = false)
 */

Utilisons le fichier que nous avons précédemment créé, l’idée est que nous connaissons déjà son schéma, sa structure ne changera pas, donc nous savons comment le lire, c’est à dire que le code que l’on va définir sera assez spécifique à notre fichier Excel, ici on sait que c’est le montant que l’on veut modifier.

On va créer deux Map :

À partir du fichier Excel, une qui associe toutes les colonnes (hors colonnes à modifier) aux coordonnées des cellules à modifier
À partir de notre dataFrame, une Map qui aura la même clé et qui associe la nouvelle valeur

Pour créer ces Maps, nous définirons ces méthodes :

def getMapFromWorkbook(wb: Workbook, sheetName: String, columnToModify: String): Map[List[String], (Int, Int)] = {
  val sheet: Sheet = wb.getSheet(sheetName)
  //on récupère du header, l'index des colonnes à exclure
  val headerRow = sheet.getRow(0)
  val columnIndexToExcludeFromKey = headerRow.cellIterator().asScala.toList
    .find(cell => cell.getStringCellValue == columnToModify)
    .map(_.getColumnIndex)
    .getOrElse(-1)
  //création de la Map qui associe chaque clé aux coordonnées des cellules à modifier
  (for {
    row: Row <- sheet.rowIterator().asScala.toList.tail
    cells: List[Cell] = row.cellIterator().asScala.toList.filterNot(_.getColumnIndex == columnIndexToExcludeFromKey)
  } yield cells.map(_.getStringCellValue) -> (row.getRowNum, columnIndexToExcludeFromKey)
    ).toMap
}
/*extrait de la Map après execution
HashMap(
List(2021, EXPLOITATION, CHARGES, CHARGES D'INTERVENTION, Dont autres organismes publics) -> (212,5),
List(2019, FINANCIER, CHARGES, CHARGES FINANCIERES, Charges nettes sur cessions de valeurs mobilières de placement) -> (44,5),
...)
*/

def getMapFromDataset(ds: Dataset[CompteDeResultat]): Map[List[String], Double] = {
  ds.collect
    .map(row => List(
      row.exercice_comptable,
      row.type_de_resultat,
      row.produit_charge,
      row.poste,
      row.details_postes
    ) -> row.montant_en_eur
    ).toMap
}
/*extrait de la Map
Map(List(2016, EXPLOITATION, PRODUITS, PRODUITS COURANTS NON FINANCIERS, Production stockée) -> 9.99999999E8,
List(2016, FINANCIER, PRODUITS, PRODUITS COURANTS FINANCIERS, Valeurs mob et créances de l'actifimmo) -> 5.55555555E8)
*/

Pour lire un Excel avec POI, on utilise un FileInputStream et POI propose un WorkbookFactory qui nous permet d’obtenir un Workbook à partir de l’input stream.

On fait ensuite correspondre les deux Maps pour appliquer les modifications, enfin on écrit le workbook dans un autre fichier Excel new_workbook.xlsx.

val inp = new FileInputStream("workbook.xlsx") //lecture de notre Excel
try {
  val wb: Workbook = WorkbookFactory.create(inp) //création d'un objet workbook à partir de la bibliothèque
  val mapWB = getMapFromWorkbook(wb, "ma feuille", "montant_en_eur")
  val mapDS = getMapFromDataset(correctionDS)
  val sheet = wb.getSheet("ma feuille")
  //modifications des cellules à partir des deux Maps
  for {
    modifications: (List[String], Double) <- mapDS
    coordinates: (Int, Int) = mapWB(modifications._1)
    row = sheet.getRow(coordinates._1)
    cell = row.getCell(coordinates._2)
  } yield {
        cell.setCellValue(modifications._2)
    }
  //écriture de notre fichier sous le nom new_workbook.xlsx
  val os = new FileOutputStream("new_workbook.xlsx")
  try {
    wb.write(os)
  } catch {
    case fnf: FileNotFoundException => fnf.printStackTrace()
    case ioe: IOException => ioe.printStackTrace()
  } finally {
    os.close()
  }
} finally if (inp != null) inp.close()

Sur le nouveau fichier nous voyons bien les deux lignes modifiées (en surbrillance sur la capture) :

Sur le TCD, on a bien les valeurs à jour aussi :

Conclusion

Nous avons vu comment créer un modifier un fichier Excel à partir de nos données Spark avec Apache POI, avec un focus sur son module XSSF permettant de créer des .xlsx, et avec un exemple sur comment créer un tableau croisé dynamique, je vous invite à regarder sa documentation officielle https://poi.apache.org/components/spreadsheet/how-to.html.

Retour sur ScalaIO 2024

2024-03-17T23:00:00Z

Le précédent ScalaIO s’était déroulé en Novembre 2022 à Paris, l’édition 2023 manquant à l’appel, c’était avec grand plaisir que nous ayons pu assister à la récente édition qui a pu se faire en ce début d’année, les 15 et 16 Février 2024 à Nantes dans Le Palace, un espace de coworking et d’évènements. Pour rappel ScalaIO est une conférence autour du langage Scala (le langage, des librairies, …), mais pas seulement, on peut y trouver des sujets autour de la programmation fonctionnelle (dans d’autres langages ou non), de data engineering, de communauté, et aussi, ce qui fait beaucoup parler en ce moment, d’intelligence artificielle.

Les talks

A savoir que cette édition, nous retrouvons beaucoup de talks multilingues, beaucoup d’anglais, et certaines en français, et il y en avait pour tous les niveaux, de sujets plus ou moins avancés. Voici un retours sur quelques unes de ces présentations.

Keynote d’ouverture - Une autre introduction aux GADTs de Xavier Van de Woestyne :

Le speaker fait essentiellement du OCaml et du Kotlin cela peut être surprenant pour ceux qui seraient venus assister pour la première fois à ScalaIO, en effet ce n’était pas un sujet purement Scala mais plutôt un sujet d’algèbre/programmation fonctionnelle.

Xavier nous introduit aux Generalized Algebraic Data Types, il nous réexplique d’abord rapidement ce que sont les Product Types et Sum Types, et qu’ils ont tous un cas minimal qui permet de décrire tous les autres Types Product et Sum :

//code repris de la présentation
//cas minimal de Product Type
case class Prod[+A, +B](fst: A, snd: B)

//permet d'écrire ce produit à 4 éléments
val quad = Prod(1, Prod(2, Prod(3, 4)))

//cas minimal de Sum type, qui en fait un Either
enum Sum[+A, +B]:
	case Left(x: A)
	case Right(x: B)

//on peut écrire ce type Triple à partir de notre Sum de la manière suivante
type Triple = Sum[Int, Sum[Double, String]]
val a : Triple = Sum.Left(1)
val b : Triple = Sum.Right(Sum.Left(1.0))
val c : Triple = Sum.Right(Sum.Rigth("1"))

Puis Xavier nous donne cette définition :

“A Generalized Algebraic Data Type is a sum type that allows its contructors to be non-surjective on one or more of its type parameters and introduces local type-equality constraints in pattern-matching branches, making the expression of existential types trivial”

Wow, mais que cela veut-il dire ?

a sum type that allows its contructors to be non-surjective on one or more of its type parameters :

Rendre les constructeurs de son Sum Type non-surjectifs sur un ou plus de ses paramètres de types, c’est en quelque sorte limiter ce que peut être le A dans les constructeurs du GADT :

//code repris de la présentation
enum AST[A]:
	case I(x: Int)                                   extends AST[Int]
	case B(x: Boolean)                               extends AST[Boolean]
	case Add(l: AST[Int], r: AST[Int])               extends AST[Int]
	case Mul(l: AST[Int], r: AST[Int])               extends AST[Int]
	case Equal(l: AST[A], r: AST[A])                 extends AST[Boolean]
	case Cond(c: AST[Boolean], t: AST[A], f: AST[A]) extends AST[A]

def eval[A](ast: AST[A]): A =
	import AST.*
	ast match
		case I(x)            => x
		case B(x)            => x
		case Add(l, r)       => eval(l) + eval(r)
		case Mul(l, r)       => eval(l) * eval(r)
		case Equal(l, r)     => eval(l) == eval(r)
		case Cond(c, t, f)   => if(eval(c)) then eval(t) else eval(f)

Xavier nous explique que cet exemple fonctionne en Scala 2, et qu’on pourrait penser que cela suffit à démontrer que l’on gère les GADT, sauf qu’il manque la suite de sa définition. Cet exemple ne suffit donc pas.

introduces local type-equality constraints in pattern-matching branches :

L’idée pour comprendre cette partie est alors de trouver le “GADT minimal” pour prouver la définition du dessus, de manière similaire à ce qui a été décrit pour les Product Type et Sum Type.

//code repris de la présentation
//definit l'égalité entre A et B
enum Eq[A, B]:
	case Refl[A]() extends Eq[A, A]
//Le seul constructeur possible est celui qui étend Eq[A, A], donc que A = B

type Z = Int
val a : Eq[Int, String] = Eq.Refl() //ne compile pas
val b : Eq[Int, Int] = Eq.Refl()
val c : Eq[Int, Z] = Eq.Refl()

L’idée est que si l’on peut instancier un Refl, c’est que A et B sont égaux localement.

Pour garantir l’égalité, on a des principes de substitution à respecter :

//code repris de la présentation

//Symmetry
def symmetry[A, B](witness: Eq[A, B]): Eq[B, A] =
	witness match
		case Eq.Refl() => Eq.Refl()

//Transitivity
def transitivity[A, B, C](witnessA: Eq[A, B], witnessB: Eq[B, C]): Eq[A, C] =
	(witnessA, witnessB) match
		case (Eq.Refl(), Eq.Refl()) => Eq.Refl()

//Free Cast
def cast[A, B](witness: Eq[A, B], value: A): B =
	witness match
		case Eq.Refl() => value

//Injectivity
def injectivity[T[_], A, B](witness: Eq[A, B]): Eq[T[A], T[B]] =
	witness match
		case Eq.Refl() => Eq.Refl()

C’est le cas de l’injectivité qui prouve que le cas des égalités locales est correctement implémenté dans le langage, et cela n’était pas possible en Scala 2 en n’utilisant que Eq, cela fonctionne seulement depuis Scala 3. Le support de ce cas est la preuve qu’on a des GADT.

Il nous présentera ensuite des exemples de types existentiels avec les GADT et un cas pour printer des URLs.

Présenté avec humour et enthousiasme avec quelques gentilles piques à Scala (typeclasses), cette Keynote nous met bien dans le bain, en effet nombreux talks de cette édition reprendront, de près ou de loin, de notions vues dans celle-ci.

Pour en savoir plus, retrouvez le replay de cette keynote ici.

Songwriting in Scala - Creating a DSL for writing Music with ADT's de Paul Matthews, la présentation Rock ! :

Pour rester dans le thème des ADT, nous avons eu une présentation très originale de Paul Matthews, dont le parcours est très atypique, en effet c’est une rockstar ! Bassiste du groupe I Am Giant, auteur-compositeur et ingénieur du son, l’industrie changeante etc. il a du trouver un nouveau but, et c’est en obtenant son diplôme en informatique qu’il est devenu un ingénieur Scala.

C’est tout du moins naturel donc que Paul nous fasse une présentation sur le thème de la musique!
L’idée de la présentation est de partir d’ADT qui représente une portion de musique, et d’interpréter un morceau écrit avec ce dernier à l’aide d’un module Scala.js/Tone.js.

C’est en apprenant le Scala, qu’il a d’abord écrit cet ADT

//code repris de la présentation
sealed trait MusicEvent
final case class Note(noteName: NoteName, duration: Duration) extends MusicEvent
final case class Melody(left: MusicEvent, right: MusicEvent)  extends MusicEvent
final case class Harmony(notes: Vector[Note])                 extends MusicEvent
final case class Rest(duration: Duration)                     extends MusicEvent

Puis de fil en aiguille, il nous montre comment il améliore ses différents Product Type, il se rend compte qu’il peut mieux définir certaines classes, en rajouter, ou en y ajoutant plus de paramètres, etc., avec Note par exemple :

//code repris de la présentation
final case class Note(
	pitch: NoteName,
	accidental: Accidental = Natural,
	duration: Duration = Quarter(),
	velocity: Int,
	octave: Int = 3
) extends MusicEvent

À propos de la velocity, il nous explique qu’il avait besoin de “cloisonner” un peu les différents niveau pour modéliser une MIdi Velocity, en effet un Int peut être négatif ou très grand, mais que dans les plages standards il n’est possible que d’être entre 0 et 127, de plus Tone.js lui ne prend que des valeurs entre 0 et 1. La solution qu’il a trouvé est de créer un autre ADT Velocity:

//code repris de la présentation
enum Velocity(val midiVelocity: Int) {
	def getNormalisedVelocity: Double = {(1.0/127) * this.midiVelocity}
	}
case TheSilentTreatment   extends Velocity(0)
case Softest              extends Velocity(10)
case Sof                  extends Velocity(50)
case Medium               extends Velocity(80)
case Assertively          extends Velocity(100)
case Loud                 extends Velocity(115)
case OnFull               extends Velocity(127)
case Napalm               extends Velocity(13335)

Il nous détaillera tout au long du talk chaque définition de classes qu’il a conçues pour représenter un élément musical.

C’était vraiment une bonne présentation pour comprendre la construction ADT d’une manière beaucoup moins abstraite et concrète, avec le bonus d’entendre la musique codée en live et le tout avec beaucoup de passion.

Je vous invite à voir la présentation ici.

Scala 3 Compiler Academy Journey de Anatolii Kmetiuk

À ScalaIO on a aussi des talks communautaires, comme celui d’Anatolii Kmetiuk qui travaille au sein du Scala Center à l’EPFL. Il nous fera un retour d’expérience sur la création du Scala 3 Compiler Academy.

Il nous dira que le plus important dans la création d’un logiciel ce sont les personnes, ce sont eux qui le créent, le maintiennent et qui le gardent à jour, c’est pourquoi ce projet d’académie est né avec l’aspect communautaire mis en avant.

Ce talk peut s’adresser et s’appliquer à n’importe quel projet Open Source qui souhaite développer son aspect communautaire pour in fine agrandir le nombre de mainteneurs.

Qu’est - ce que Scala 3 Compiler Academy ?

Il se compose de sessions de Pair programming en ligne avec les équipes principales de Scala 3, principalement sur les sujets de compilateur Scala 3 et notamment ceux visant à corriger le compilateur. Toute personne intéressée par ces sujets peut rejoindre l’équipe, à raison d’environ une session par mois.

Le parcours
L’idée date depuis 2021, puis en 2022 était la phase d’expérimentation pour arriver à une stabilité en 2023.
- 2021
  - Contexte : COVID ⇒ travail en remote, rester en contact devient plus difficile, Scala 3.0.0 venait de sortir, donc beaucoup de charge sur l’équipe de maintenance (surtout que l’équipe qui s’en occupe est une équipe de recherche dont le but premier n’est pas le support).
  - Cela a d’abord commencé avec des sessions de 2 heures avec surtout du transfert de connaissance avec l’équipe principale le tout en interne, pour être sûr que ce format fonctionne. Le tout en ligne dû au contexte sanitaire de l’époque, ce qui était nouveau pour eux.
  - À chaque session, ils collectaient des retours (ce qui marchait bien, et ce qui ne marchait pas bien) jusqu’à ne plus avoir de retours négatifs.
  - Fun fact : ils cherchaient des outils de conférence qui utilisent le moins de ressources CPU, en effet comme ces ressources étaient utilisés pour la conférence cela empêchait de compiler.
  - Focus sur le contenu des sessions : le temps, le découpage ⇒ la conclusion est le plus simple le mieux, aussi bien pour l’organisateur que pour les participants afin qu’ils comprennent tout de suite le déroulé.
  Ouverture à l’extérieur
  - Communications via Twitter, puis après ajout de Mastodonte, Discord, Slack.
  - Il fallait s’adapter aux horaires mondiaux cette fois ci pour les sessions, les retours étaient toujours collectés.
  - La nouveauté c’est le “onboarding call” à la différence d’en interne, où il faut prendre le temps d’expliquer au volontaire externe ce qu’il faut faire et comment il peut participer et aussi s’il a besoin de guidage.
  - Un autre challenge qui est apparu, c’est l’équilibrage des équipes, certains sont plus experts dans un domaine du compilateur plutôt qu’un autre. Ils font cela via un formulaire Google Form où chacun choisit l’issue sur lequel il veut travailler, et aussi une option sur une autre issue si jamais ils ne peuvent pas être dispatché dans tel équipe.
- 2022
  - L’idée de cette année était de monter en volume, aussi bien en nombre de fix à résoudre qu’en nombre de participants.
  - Forcément un des problèmes était le temps des mentors.
  - Une chaîne YouTube a été ouverte aussi pour permettre aux personnes d’apprendre.
  - Un template a été créé avec une checklist pour chaque organisation de spree, pour faciliter la création de ceux-ci et libérer de la charge à l’organisateur.
    Ils ont automatisé tout cela via des outils NoCode.
- 2023 et aujourd’hui
  - Il y a une stabilité de participants, plus de 80 participants uniques ont participé au projet depuis sa naissance en 2021.
  - Aujourd’hui c’est un format de 3 semaines pour chaque spree

Cela était très intéressant de voir comment s’organise le développement autour d’un projet Open Source comme le compilateur Scala, on ne se rend pas forcément compte des difficultés qui peuvent subvenir pour le bon fonctionnement d’un projet comme celui-ci.

Plus de détails dans la vidéo du talk ici.

Et plein d’autres présentations !

Bien sûr, ce n’était qu’un bref aperçu de quelques présentations de ce ScalaIO 2024, vous pouvez retrouver tous les talks sur la chaîne YouTube de ScalaIO.

Le reste, comment c’était ?

Pour cette édition, une seule salle de conférence, et un endroit pour le partage et/ou la pause. De taille plus modeste pour cette itération, la salle était quand même bien remplie surtout que parallèlement se tenait une grève nationale de transport affectant beaucoup la venue de participants, cela était très plaisant de voir toujours autant de monde intéressé par cette conférence, et de manière générale le Scala.

D’autres aspects qui peuvent vous être intéressants :

Enchaînement des présentations très fluide, pas de retard, et je n’ai pas vu de problèmes techniques.
Le lieu était vraiment très bien, bien placé dans le centre-ville de Nantes, des logements se trouvaient à proximité, donc pas besoin de transports pour y arriver.
Les repas étaient vraiment au top pour les midis ainsi que le traiteur pour la Community Party du premier soir qui se déroulait dans les même locaux.
Ambiance générale toujours plaisante, tout le monde est accessible et prêt à échanger.

Je remercie beaucoup les organisateurs pour cette édition du ScalaIO, toujours de qualité, et on attend la prochaine session avec impatience !

Double jointures dans Kafka Streams

2024-01-30T23:00:00Z

Intention

Imaginez que vous disposez de deux flux : l'un représente le stock des produits d’un magasin, et l'autre concerne les commandes des clients. Vous souhaitez combiner ces deux flux afin de créer une projection précise du niveau de stock pour chaque produit. Les scénarios sont les suivants :

Lorsqu'une commande client est passée, elle doit réduire le niveau de stock correspondant. Par conséquent, il est nécessaire que l'arrivée d'une commande déclenche un calcul et une mise à jour de la projection.
Lorsque le stock des produits dans le magasin est actualisé, il doit également mettre à jour le dernier stock de base de chaque produit, déclenchant ainsi un nouveau calcul et une nouvelle projection.

En d’autre termes, nous avons besoin de faire une double jointure entre le flux des stocks et le flux des commandes et tout cela en temps réel. Comment faire cela dans Kafka Streams ?

Jointure KTable-KTable

Kafka Streams est un outil pour traiter des données en temps réel. Pour effectuer une jointure en temps réel entre deux flux de données (KStream), on peut faire :

Jointure KStream-KStream : On conserve les deux flux de données KStream et on utilise une fenêtre (windowing) pour associer tous les éléments correspondants dans une période de temps spécifique.
Dans ce cas, on a bien le flux de commandes qui se joint avec celui des stocks et vice-versa, mais seulement pour ceux arrivant dans la même fenêtre. Il faudrait une fenêtre de temps énorme pour récupérer tout les changements, ce qui fait que l’on ne serait plus en temps réel.
Jointure KStream-KTable : On transforme l'un des flux en une KTable pour garder les changements d'état, puis on associe chaque élément du flux KStream avec chaque élément de la table KTable.
Dans ce cas, les éléments du flux de KStream (stock ou commande) viendrait se joindre avec la KTable, ce qui produit bien une projection. Mais les éléments de la KTable ne se joindrait pas avec ceux de la KStream, ce qui ne produit pas une projection.
Jointure KTable-KTable : On transforme les deux flux en deux Ktable, ce qui nous permet de garder les changement d’état des deux sources, et nous permet de joindre chaque élément comme en SQL.

Au vu des descriptions, cela ressemble plus à une jointure KTable-KTable qu’il faudrait faire ! Faisons donc cela.

Voici le modèle de données des stocks et des commandes (orders ici) :

 case class Stock(
    store: String,
    product: String,
    checkedAt: Instant,
    quantity: Double
)

case class Order(
    orderId: String,
    store: String,
    createdAt: Instant,
    items: List[OrderItem],
    deliverAt: Instant,
    status: String
)

Et voici un exemple de construction de la topologie dans Kafka Streams :

/* Create the stock KStream from the stock topic.
 */
val stocks: KStream[Key, Stock] =
  builder.stream(StockTopic)(
    Consumed.`with`(Key.keySerde, Stock.valueSerde)
  )

/* Create a KStream for orders the same way.
 */
val orders: KStream[Key, Order] =
  builder.stream(OrderTopic)(
    Consumed.`with`(Key.keySerde, Order.valueSerde)
  )

val orderTable: KTable[Key, Order] =
  orders
    .groupByKey(Grouped.`with`(Key.keySerde, Order.valueSerde))
    .reduce((order1, order2) => mergeOrders(order1, order2))(
      Materialized.as("order-table")(Key.keySerde, Order.valueSerde)
    )

val stockTable: KTable[Key, Stock] =
  stocks
    .groupByKey(Grouped.`with`(Key.keySerde, Stock.valueSerde))
    .reduce((stock1, stock2) => moreRecentOf(stock1, stock2))(
      Materialized.as("stock-table")(Key.keySerde, Stock.valueSerde)
    )

val projections: KStream[Key, Projection] =
  stockTable
    .leftJoin(orderTable)((stock, order) =>
      project(Option(stock), Option(order))
    )
    .toStream
    .flatMapValues(_.toList)


projections.to(ProjectionTopic)(
  Produced.`with`(Key.keySerde, Projection.valueSerde)
)

Vous trouverez le code complet ici :

https://github.com/univalence/double_jointures_ks/blob/main/src/main/scala/io/univalence/double_jointures_ks/KTableJoinMain.scala

Pouvons nous faire mieux ?

Une autre manière de faire cette jointure est de passer directement par les states stores. Cette méthode consiste à utiliser l’API de bas niveau de Kafka Streams afin de faire une double jointure partielle à l’aide des méthodes .get et .put des state stores. Cela nous permet de ne pas devoir transformer les données de KStream en KTable, et donc de faire une jointure KStream sans fenêtrage qui répond à nos attentes.

Le code se trouve ici avec l’utilisation de la case class ExtraStreamBuilder :

https://github.com/univalence/double_jointures_ks/blob/main/src/main/scala/io/univalence/double_jointures_ks/DoublePartialJoinMain.scala

En faisant une visualisation de la topologie pour chaque code, nous voyons bien la simplification (à gauche jointure KTable-KTable, à droite double jointure partielle)

Encore mieux ??

En allant un peu plus loin, pour optimiser cette double jointure on peut aussi… supprimer la notion de jointure des deux flux. Non ce n’est pas un clickbait ! Cette méthode consiste à prendre les deux flux et à les fusionner dans un seul schéma dès le début. Cela semble bizarre dit comme ça, mais voyons un exemple pour mieux comprendre.

Pour rappel nous avons les deux flux de stocks et de commandes :

case class Stock(
    product: String,
    checkedAt: Instant,
    quantity: Double
)

case class Order(
    product: String,
    quantity: Double
)

Nous fusionnons ces deux schémas en un seul en utilisant les mettant en Option tous les deux :

case class StockAndOrder(
	  stock: Option[Stock],
	  order: Option[Order]
)

Et voilà ! Nous avons un ADT qui représente toutes nos sources (ici il n’y en a que deux mais il pourrait y en avoir d’autres).

Nous transformons ensuite le stream des commandes avec le schéma StockAndOrder :

val orders: KStream[Key, Order] =
  builder.stream(OrderTopic)(
    Consumed.`with`(Key.keySerde, Order.valueSerde)
  )

val finalOrders = orders.mapValues(_.toStockAndOrder)

Et pareil pour le stream des stocks :

val stocks: KStream[Key, Stock] =
  builder.stream(StockTopic)(
    Consumed.`with`(Key.keySerde, Stock.valueSerde)
  )

val finalStocks = stocks.mapValues(_.toStockAndOrder)

Nous fusionnons les deux streams avec un merge (car ils ont maintenant le même schéma)

val mergedStream = finalOrders.merge(finalStocks)

Puis nous aggrégeons le tout dans une KTable. Dans cette étape, nous faisons un groupByKey qui va permettre d’aggréger deux StockAndOrder. Selon qu’on ait l’information de stock ou l’information d’order dedans qui est définie, on peut avec un match décider quelle information va être apportée dans la KTable (current.copy). Enfin en sortie, nous pouvons transformer StockAndOrder en Projection avec un flatMapValues

val projections =
  mergedStream
    .groupByKey(Grouped.`with`(Key.keySerde, StockAndOrder.valueSerde))
    .aggregate(StockAndOrder.empty){
      (_, newValue, current) =>
        (newValue, current) match {
          case (_, StockAndOrder.empty) => newValue
          case (StockAndOrder(None, _), _) => current.copy(order = newValue.order)
          case (StockAndOrder(_, None), _) => current.copy(stock = newValue.stock)
        }
    }(
      Materialized.as("stock-and-order-agg")(Key.keySerde, StockAndOrder.valueSerde)
    )
    .toStream
    .flatMapValues { v =>
      project(v.stock, v.order) match {
        case Some(v) => Seq(v)
        case None => Seq.empty
      }
    }

Le principal avantage avec cette méthode, c’est que nous évitons du shuffle puisque nous supprimons les jointures. Nous avons également une seule source en entrée avant l’aggrégation, nous pouvons donc remplacer le début de cette topologie plusieurs micro-services sources qui viendraient alimenter un unique topic.

Scala côté frontend grâce à Laminar

2023-02-22T23:00:00Z

Le langage Scala est généralement utilisé dans deux cas : la mise en place de serveurs backend (microservices ou monolithes) et la création de pipeline de données (Spark, Kafka Streams ou autre). Pour beaucoup, ses capacités s’arrêtent ici.

Pourtant, ce n’est pas le cas. Ces dernières années, nous avons vu émerger dans la communauté deux game changers dans des domaines complétement différents :

Scala Native qui permet de développer des applications embarquées
ScalaJS qui permet de développer des applications frontend

Je n’ai pas encore eu le temps de creuser Scala Native, alors je vous propose aujourd’hui que l'on aborde ScalaJS ensemble afin de vous montrer comment ce dernier peut vous être utile.

Pourquoi ScalaJS ?

ScalaJS offre un avantage considérable comparé aux solutions existantes, son interopérabilité avec les autres librairies Scala. En effet, c’est selon moi l’élément à prendre en compte si l’on considère utiliser ScalaJS en production. Utiliser le même langage côté Frontend et Backend permet de ne pas se répéter et de rester DRY. En effet, généralement lorsque nous utilisons ScalaJS, nous avons trois projets dans notre repository:

L’application Frontend
L’application Backend
La librairie partagée

Les deux applications sont assez communes, ce qui nous intéresse ici, c'est la librairie partagée. Cette dernière a comme particularité d’abriter du code Scala qui va être utilisé par l’application backend en Scala et l’application frontend en ScalaJS. Généralement, nous entreposons dans cette librairie les choses suivantes :

Notre domaine, à savoir les case class qui décrivent l’aspect métier qu’essaye de résoudre notre application. Généralement, ce sont des case class partagées entre le front et le back via une API REST.
Nos encoders et decoders, qui nous permettent de partager ce domaine entre nos deux applications.
Nos descriptions de routes, ces dernières ne sont pas obligatoires, mais je vous encourage fortement à les implémenter en utilisant Tapir, par exemple. Cela va permettre de réutiliser ces descriptions pour créer notre serveur côté Backend et notre client côté Frontend rapidement et facilement.

Comme je l’ai mentionné auparavant, rajouter cette librairie permet de ne pas se répéter dans les points mentionnés précédemment. Ce n’est pas le seul avantage, cette librairie permet de garder une version unifiée de notre système. Ainsi, si vous changez votre domaine en rajoutant un champ, par exemple, ou alors si vous rajoutez un query parameter dans l’une de vos routes, c’est automatiquement répercuté côté back et front en même temps.

On évite les erreurs humaines, on rend notre boucle de développement plus rapide et on utilise le même langage pour toute notre équipe. Voici où réside la puissance de ScalaJS. La question à se poser ensuite est la suivante : est-ce que l’écosystème ScalaJS est assez riche pour pouvoir mettre en place une application frontend ?

L’écosystème de ScalaJS

Je vous ai parlé de la librairie partagée comme étant la solution idéale pour réunir le frontend et le backend, trop longtemps séparés. Il y a juste un seul problème que je n’ai pas mentionné auparavant. Pour que cela fonctionne, il faut que les librairies utilisées soient compatibles avec Scala et ScalaJS.

ScalaJS génère du code JavaScript. Il vous sera impossible d’utiliser une librairie Java dans le projet partagé du moment où ce même morceau de code doit être utilisé côté frontend et backend. Ainsi, si vous utilisez Gson pour la serialization / deserialization de vos JSON, cela n’est pas forcément adapté à la situation. Vous pouvez tout de même utiliser une grande partie du JDK puisque ce dernier a été partiellement réécrit en ScalaJS.

Fort heureusement pour nous, dans le cas des librairies Scala, pléthore de librairies diverses et variées supportent Scala ET ScalaJS, pour ne pas les citer : ZIO, Tapir, Circe, par exemple. Pour une liste un peu plus exhaustive, je vous conseille ce lien : https://www.scala-js.org/libraries/libs.html.

Pour ce qui est du projet Frontend fait en ScalaJS, ce dernier supporte aussi tout l’écosystème JavaScript. Pour cela, il faut utiliser les façades. Pour ceux qui sont familiers avec TypeScript, le principe est le même. Comme JavaScript est typé dynamiquement, cette étape consiste à rajouter des types aux différentes fonctions de ladite librairie. Vous pouvez créer vos propres faces simplement, utiliser ceux déjà écrits par la communauté ou alors utiliser directement les types defintions typescript.

Pour saupoudrer le tout, la communauté a aussi créé des librairies exclusivement destinées à ScalaJS. C’est le cas de Laminar, une librairie frontend fait pour Scala que je trouve prometteur.

Créer votre site internet avec Laminar

Laminar est une librairie pour créer des applications Web, au même titre que React ou encore Angular. Outre le fait que cette librairie a été faite pour ScalaJS, je la trouve particulièrement plaisante à utiliser. Elle se base sur un principe peu commun en programmation, le reactive programming.

Sa syntaxe est assez naturelle et ne devrait pas trop dépayser les personnes développant des applications frontend. Voici un exemple :

import com.raquo.laminar.api.L.{*, given}
import org.scalajs.dom

object Main {
	val app = div(
		h1("Hello World", className := "title")
		className := "body"
	)

	renderOnDomContentLoaded(dom.document.querySelector("#app"), app)
}

Là où l’application se démarque, c’est sur son côté réactif. En effet, Laminar se base sur une autre librairie écrite par le même auteur (raquo) nommé Airstream. Le principe est le suivant : l’état de votre application est contenu dans des streams. Nos différents éléments Html peuvent alors mettre à jour ces streams ou alors récupérer l’état de ces streams pour automatiquement s'actualiser.

Implémentation d’un générateur de nombre aléatoire

Imaginons que nous voulons créer une application qui tire un nombre aléatoire et que nous voulons l’afficher. L’état de l’application est ce nombre aléatoire. Comme nous voulons à la fois le mettre à jour et récupérer son état, nous devons créer un Var.

val state: Var[Int] = Var(0)

Nous allons maintenant créer le composant qui va s’abonner à cette valeur :

val display: Div = div(
	child <-- state.signal.map(span(_)),
  className := "display"
)

Ce dernier est un div qui va contenir un span contenant la valeur du Var à l’intérieur. À tout moment, si la valeur du Var change, alors le span sera de nouveau généré. L’opérateur ←- permet ici de consommer le signal.

Ce nombre ne risque pas de se générer tout seul ! Alors, il faut aussi un composant pour mettre à jour cette valeur :

val generator: Button = button(
  "Generate a new number",
  onClick.map { _ => Random.nextInt() } --> state,
  className := "generator"
)

Ce qui nous intéresse ici, c'est ce qui se passe lorsqu’on clique sur ce bouton. onClick renvoie l’événement de la souris, ce dernier ne nous intéresse pas, donc on map cette valeur pour, à la place, générer un nombre aléatoire. Tout comme <-- permet de consommer une valeur, —-> permet de produire une valeur, en l’occurrence, le nombre aléatoire.

Et c’est tout ! Les deux composants communiquent à présent ensemble. L’un actualise l’état de l’application. L’autre le consomme et se met à jour lorsque l’état change. Il faut un certain temps d’adaptation pour manipuler les streams avec aisance, mais croyez-moi, cela en vaut la chandelle.

J’ai créé spécialement pour cet article un repository qui implémente le code ci-dessus : https://github.com/univalence/laminar-article. Ce dernier peut aussi vous être utile pour mettre en place une codebase ScalaJS comportant notamment le préprocesseur SCSS et Vite. Cette codebase est en très grande partie inspirée du talk de Sebastien Doeraene que nous avons notamment eu la chance d’écouter lors du Scala.IO 2022.

Les tradeoffs

Cet avant-gout devrait déjà vous avoir partiellement convaincu. J’ai personnellement été bluffé de voir à quel point le développement frontend devenait plaisant et intuitif avec Laminar. Je n’ai bien sûr qu’effleuré la surface et je vous conseille d’aller creuser dans la documentation si cette dernière vous intéresse.

Maintenant, afin que vous optiez pour la solution qui convient le plus à votre projet, il est de mon devoir de vous faire part des points négatifs d’un tel environnement de développement. Nous avons longuement vu pourquoi opter pour ScalaJS. Voici certaines choses qui pourraient vous manquer si jamais vous sautiez le pas.

Le point le plus important selon moi, c’est le tooling. Ce dernier n’est pas très optimisé pour ScalaJS. Il suffit de voir le repository de l’exemple ci-dessus pour se rendre compte qu’il faut tout de même pas mal de code custom pour rattacher les pièces ensemble. De plus, certains outils très intéressant n’existent pas pour ScalaJS, ce qui me manque personnellement, c'est le support de Storybook. Cet outil est devenu un incontournable du développement frontend et permet véritablement à une équipe d’avoir plus de visibilité sur ses composants et de créer un design system déclinable et efficace.

L’écosystème étant encore très jeune, il manque de librairies et de frameworks. Comme dit au-dessus, ScalaJS est compatible avec toutes les libraires Javascript à condition d’avoir une façade. Cependant, comme utiliser une librairie en Java dans un projet Scala n’est pas agréable, il en va de même pour une librairie Javascript dans un projet ScalaJS. Cette fonctionnalité permet de dépanner le développeur en lui assurant, par exemple, de toujours trouver chaussure à son pied. Cependant, on ne lésinerait pas sur plus de librairies directement faites en ScalaJS, tel que Laminar, adoptant ainsi les conventions implicites du langage, tel que la composition, l’omniprésence des fonctions anonymes ou encore l’intégration avec le standard librairie de Scala.

Ces tradeoffs ne sont pas une fatalité en soi. Ils ne sont que la conséquence d’un écosystème encore assez jeune et ambitieux. Néanmoins, la stabilité reste une métrique très importante à prendre en compte lorsqu’on choisit une technologie pour un projet professionnel et je devais souligner ces points.

Conclusion

Depuis que j’ai vu la présentation sur ScalaJS et Laminar de Sébastien Doeraene au Scala.IO 2022, j’ai été conquis par la solution. Elle réunit dans une seule et même stack notre code frontend et backend, elle permet d’avoir un code typé, dry et safe. Selon moi, ScalaJS a réussi son coup, à savoir permettre à des développeurs Scala de coder des applications frontend sans que cela soit un supplice.

La technologie reste assez jeune et vous ne retrouverez pas tous les outils présents dans l’écosystème Javascript. Mais c’est largement suffisant pour construire des projets d’ampleurs sans trop de soucis. Essayer c’est l’adopter !

Comment la génération de code de zio-spark fonctionne

2023-01-18T23:00:00Z

Introduction

Intégrer une librairie existante dans ZIO est souvent assez direct. Pour simplifier, dans les (très) grandes lignes, il suffit de wrapper toutes les fonctions qui causent des effets dans ZIO. Ces fonctions auront ainsi pleins de nouveaux superpouvoirs tels que la parallélisation, la gestion des erreurs intégrée, le scheduling et j’en passe.

Avec ceci en tête, nous avons donc décidé de faire zio-spark. Nous utilisions déjà ZIO et Spark dans nos pipelines et le but était ainsi d’avoir une meilleure syntaxe. Nous sommes aujourd’hui fiers de cette librairie, mais ceci ne s'est pas passé sans son lot de difficultés.

Je vous propose de ce fait de retracer son histoire afin de voir les différentes problématiques qui se sont posées et comment nous les avons traités.

La méthode naïve

Nous voulions une API qui se rapproche le plus possible de celle de Spark. Le but étant que l’utilisateur puisse aisément transformer du code Spark and du code zio-spark.

Ainsi si nous prenons le code suivant :

import org.apache.spark.sql._

val df: DataFrame = ???
val res: Int = df.filter("").count

Le but est d’avoir une API similaire pour zio-spark :

import zio._
import zio.spark.sql._

val df: DataFrame = ???
val res: Task[Int] = df.filter("").count

Pour ce faire, nous avons créé notre propre objet Dataset[T] de la manière suivante, sachant qu’un DataFrame n’est qu’un Dataset[Row] :

package zio.spark.sql

import org.apache.spark.sql.{Dataset => UnderlyingDataset}
import zio._

case class Dataset[T](underlying: UnderlyingDataset[T]) {
	def filter(conditionExpr: String): Dataset[T] = 
		Dataset(underlying.filter(conditionExpr))

	def count(implicit trace: Trace): Task[Long] = 
		ZIO.attempt(underlying.count)
}

Cela fonctionne très bien et répondait à notre problématique puisque l’utilisateur pouvait à partir de maintenant manipuler des DataFrame dans lesquels toutes actions étaient transformées en effets grâce à ZIO nous permettant d’ores et déjà de scheduler nos jobs par exemple.

Toutes actions ? Pas vraiment… Dans l’état actuel des choses, notre nouveau Dataset n’en a qu’une seule, la fonction count. Le reste, que ce soit les transformations ou les actions, il va falloir les implémenter nous même et autant vous dire que l’API de Spark ne rigole pas. Pour être précis, il y a, pour la version Spark 3.3.1 en Scala 2.13, 216 fonctions dans la class Dataset (On ne prend pas en compte ses déclinaisons telles que le RelationalGroupedDataset par exemple).

Nous sommes vite arrivés à la conclusion qu’il fallait qu’on réfléchisse autrement.

La génération de code

Nous sommes partis d’un postulat simple : un Dataset possède majoritairement deux types d’opérations, les actions et les transformations.

Les transformations sont pures (ou presque) puisqu’elles servent juste à mettre à jour le LogicalPlan qui n’est rien d’autre qu’un ADT représentant un programme Spark.
Les actions sont impures parce qu’elles appliquent le LogicalPlan et doivent donc être “wrappées” dans ZIO.

C’est une façon de penser assez binaire et même un robot pourrait réécrire notre version d’un Dataset. S’il pourrait, pourquoi ne le ferait-il pas ?

Il s’avère que pendant cette période, je suis tombé sur un article de Vigoo, un développeur Scala qui travaillait actuellement pour Ziverge, la boite en charge de ZIO. Ce dernier expliquait comment il avait fait pour générer zio-aws, une librairie qui créé un client Scala pour tous les services AWS basés sur ZIO. Cela nous a servi de base pour zio-spark !

Le plugin SBT

Nous n’avons pas réinventé la roue pour générer nos fichiers .scala. En effet, nous avons suivi à la lettre l’article de blog de Vigoo à ce niveau-là. Nous avons créé un plugin SBT local nommé zio-spark-codegen chargé de générer ces fichiers.

Pour les générer, nous devions nous baser sur le code source Spark. Notre programme devait ainsi, à l’instar de zio-aws qui se basait sur des jsons, créer un programme capable de lire du code Scala pour en générer à son tour.

Scalameta à la rescousse

Nous avons tout d’abord testé la réflexion pour lire le code Spark. Malheureusement, ceci s'est très vite avéré inefficace. Le Type Erasure nous empêchait de récupérer des informations primordiales sur les différents types, rendant la tâche très difficile voir impossible. Certaines choses nous semblaient aussi impossible avec cette technique. On ne voyait pas, par exemple, comment on aurait pu récupérer les docstrings des différentes fonctions sans une étape manuelle.

Après avoir essayé et raté, nous nous sommes donc tournés vers Scalameta. Scalameta n’utilise pas du tout la réflexion, cette librairie crée depuis un ADT représentant un programme depuis du code Scala (un String). Il permet de valider qu’un programme est correct, que deux programmes soient synthétiquement équivalents (même si la forme n’est pas la même), de créer des règles de syntaxe (scalafmt et scalafix se basent sur scalameta) et dans notre cas d’interpréter l’ADT pour regénérer du code Scala depuis ce dernier.

Jusqu’à présent, voici comment le plugin fonctionne dans les grandes lignes :

On récupère le classpath
On récupère le code source Dataset.scala
On récupère son ADT grâce à Scalameta
On traverse cet ADT pour générer notre Dataset.scala sous la forme d’un simple String
On écrit ce String dans l’endroit de notre choix

Du code custom dans du code généré

Félicitations, nous avons notre Dataset généré de A à Z en suivant la règle binaire érigé au-dessus (on wrap toutes les actions dans des effets et on retranscrit comme tels les transformations). Malheureusement pour nous, le monde n’est pas si manichéen. Ce modèle automatique est devenu assez restrictif lorsque nous avons eu besoin de customiser certaines fonctions de Dataset.

En effet, au fur et à mesure que nous avancions, nous avons eu besoin d’avoir, au sein de nos Dataset, du code custom. Nous avions besoin plus précisément de cette feature pour deux cas particulier.

Créer nos propres fonctions

Créer nos fonctions se comprend assez facilement, nous voulions notamment rajouter une fonction headOption afin de profiter du type system de Scala.

Éditer manuellement des fonctions existantes

Mais pourquoi voudrions-nous éditer manuellement les fonctions de Spark ? Car ZIO ne se résume pas qu’à wrapper les effets dans ZIO. Prenons l’exemple de la fonction show. Cette dernière affiche par défaut les 20 premières lignes d’un Dataset dans la console. C'est une action, ainsi notre plugin va générer la fonction suivante :

def show(): Task[Unit] = ZIO.attempt(underlying.show())

Cette fonction est ennuyante à tester pour l’utilisateur, il va forcément devoir passer par un mock puisque show se base sur la fonction println de Scala. Un utilisateur de ZIO n’a pas l’habitude de mocker print parce qu’il utilise Console.printLine à la place ! C’est chose faite dans zio-spark, la fonction show a été réécrite pour se baser sur Console.printLine. Ainsi, vous pouvez écrire le test suivant sans encombre :

test("Dataset should implement show correctly") {
  val result =
    """+---------+---+
      >|     name|age|
      >+---------+---+
      >|    Maria| 93|
      >|     John| 24|
      >|    Peter| 19|
      >|Cassandra| 46|
      >+---------+---+
      >
      >""".stripMargin('>')
  for {
    df     <- read
    _      <- df.show
    output <- TestConsole.output
    representation = output.mkString("\n")
  } yield assertTrue(representation == result)
} @@ silent

Ce comportement est très spécifique à la fonction show, la génération automatique de code n’est pas faite pour cela, alors comment l’intégrer ?

Insérer du code custom dans la génération

Ce code, il va falloir l’écrire nous même pardi ! Rassurez vous, si c'était aussi simple, je n’aurais pas pris la peine d’écrire cette partie.

La façon la plus naïve de le faire est de tagger cette fonction afin qu’elle ne soit pas automatiquement générée puis de la rajouter à la main en l’écrivant sous forme de string pour l’insérer dans le string final. Avec cette méthode, nous manipulons un string ainsi, il n’y a pas d’autocomplétion, pas d’erreurs au compile time, pas de coloration syntaxique. Pour résumer, ce n’est pas plaisant.

Il nous fallait un moyen d’écrire du code Scala qui serve uniquement pour la génération de code. Ce dernier doit se baser sur l’ancienne classe déjà générée d’un Dataset afin de pouvoir réutiliser des fonctions déjà générées auparavant.

Voici la marche à suivre que nous avons adoptée :

Nous nous sommes servis du dossier it pour entreposer le code custom de nos générations. Ce dossier est censé être destiné aux tests d’intégrations comme l’indique la documentation de SBT. Nous l’avons un peu détourné de son but premier. Il a l’avantage d’être reconnu aisément par l’IDE et de pouvoir utiliser notre librairie zio-spark.
Dans ce dossier, nous avons créé des fichiers “overlay”. Ces fichiers contiennent les fonctions qui seront insérées lors de la prochaine génération de code. Il existe deux types de fichiers d’overlay, dans le cas du Dataset, DatasetOverlay.scala et SpecificDatasetOverlay.scala. Le premier contient le code à insérer dans la génération, qu’importe la version de Scala. Le deuxième quant à lui est associé à une version.
Un fichier “overlay” n’est pas qu’une série de fonctions. Comme je vous l’ai dit, ce code doit compiler et donc être du code valide. Pour ce faire, nous avons opté pour la structure suivante :
```
import zio._
import zio.spark.sql._

class DatasetOverlay[T](self: Dataset[T]) {
  import self._

  // template:on
  
  // template:off
}
```
Le code à l’intérieur de la class DatasetOverlay, entre les balises template sera pris en compte lors de la génération. Il faut voir cette classe comme une extension d’un Dataset, ce faisant, il peut utiliser toutes ses fonctions.
Maintenant que nous avons ces fichiers, le plugin va les prendre en compte lors de la génération. Tout comme pour les fichiers Spark, nous avons utilisé Scalameta pour extraire les fonctions entre les balises template. Nous les rajoutons ensuite dans le fichier final généré.

Conclusion

Voilà dans les grandes lignes comment nous sommes arrivés à générer du code zio-spark à partir du code Spark. Je me suis concentré ici sur la class Dataset, mais cette méthode a ensuite été généralisée pour d’autres classes de Spark telle que la classe SparkContext. Je l’ai rapidement mentionné avec les fichiers “overlay” mais cette méthode fonctionne pour différentes versions de Scala et de Spark au sein de notre système.

La génération nous a fait gagner énormément de temps puisqu’elle nous a évité d’écrire une énorme partie de notre codebase manuellement. Elle s’est aussi avérée très utile lorsque nous avons eu besoin de faire des gros refactoring. Ça a notamment été le cas lorsqu’il a fallu rajouter les traces avec ZIO 2 ou alors lorsque nous avons décidé de supporter Scala 3. Là où de telles actions auraient dû être coûteuses à implémenter, elles n’ont pris que quelques minutes.

Si jamais vous voulez aller plus loin, je vous conseille de regarder le plugin directement : https://github.com/univalence/zio-spark/tree/master/zio-spark-codegen.

Introduction a zio-spark

2023-01-02T08:00:00Z

Introduction

Il y a deux semaines, nous avons décidé d’annoncer zio-spark. C’est un projet qui nous tient particulièrement à cœur puisqu’il résulte de la combinaison de deux outils que nous affectionnons particulièrement, à savoir ZIO et Spark. Son objectif premier est de faciliter l’intégration de Spark dans l’écosystème ZIO afin de profiter des différents avantages de ce dernier.

Le but de cet article est de vous montrer comment la combinaison de ces deux librairies peut vous faciliter la vie au quotidien.

Installation

Cet article se base sur la version 0.10.0 de zio-spark. Les dépendances suivantes ont été utilisées :

val dependencies = Seq(
	"org.apache.spark" %% "spark-core" % "3.2.2",
	"org.apache.spark" %% "spark-sql" % "3.2.2",
	"io.univalence"    %% "zio-spark"  % "0.10.0"
)

Avantages liés à ZIO

Les caractéristiques de ZIO sont surtout utiles lorsque nous devons manipuler nos jobs. En effet, ici, on opère au niveau du driver, il n’a pas d’effet sur les workers et donc sur les traitements des jobs Spark.

L’objectif premier est d’optimiser l’allocation des ressources en permettant à l’utilisateur de facilement lancer plusieurs jobs en parallèle et de pouvoir programmer ses différents jobs comme il le sent.

Voyons voir ces différentes facettes.

Planification des jobs

Il y a un moment où il faut se demander comment faire pour planifier nos jobs. On veut, par exemple, pouvoir lancer un job en particulier chaque début de semaine, le lundi à 9h du matin.

Généralement, les ingénieurs choisissent d’utiliser Airflow pour répondre à cette problématique.

C’est un outil qui y répond parfaitement, mais qui peut paraitre un peu overkill pour certains projets. En effet, pour ce simple besoin, il va falloir :

Gérer une instance Airflow ou payer pour un service serverless équivalent
Former les ingénieurs à la notion de DAG et autres spécificités liées à l’outil

ZIO donne une alternative beaucoup moins coûteuse en ressources et en temps grâce aux Schedules. Il permet de répondre à cette problématique directement depuis notre code.

Voici un exemple qui répond à la problématique ci-dessus :

import zio._
import zio.spark.sql._

val job: ZIO[SparkSession, Throwable, Int] = ???
val eachMondayAt9AM = Schedule.dayOfWeek(1) && Schedule.hourOfDay(9)

val app = job schedule eachMondayAt9AM

Gestions des erreurs

On peut aussi simplement gérer nos erreurs de pipeline et réagir en conséquence. Dans l’exemple ci-dessous, on lance un autre job si le premier crash :

import zio._
import zio.spark.sql._

val job: ZIO[SparkSession, Throwable, Int] = ???
val fallbackJob: ZIO[SparkSession, Throwable, Int] = ???

val app = job orElse fallbackJob

Nous ne sommes pas obligés de régler un problème de job Spark en lançant un autre job Spark, on aurait aussi très bien pu envoyer un mail à un service de support ou autre à la place.

Parallélisation des jobs

Comme dit au-dessus, l’avantage de zio-spark est de pouvoir facilement lancer en parallèle nos différents jobs et ainsi permettre à nos workers de toujours être occupés lorsqu’il y a du travail.

Voici un exemple pour lancer deux jobs simultanément :

import zio._
import zio.spark.sql._

val job: ZIO[SparkSession, Throwable, Int] = ???
val otherJob: ZIO[SparkSession, Throwable, Int] = ???

val app = job zipPar otherJob

Bien évidemment, toutes ces caractéristiques ne sont pas propres à zio-spark mais à ZIO, j’ai notamment fait un article qui va un peu plus loin sur le sujet.

Qu’est-ce que zio-spark apporte en plus ?

Avant que zio-spark existe, de nombreux ingénieurs ont déjà utilisé Spark et ZIO ensemble pour jouir des caractéristiques citées ci-dessus. Nous étions aussi dans ce cas et c’est pour cela que nous avons eu envie d’aller un peu plus loin afin d’avoir une intégration plus intelligente et plus transparente.

Une API plus plaisante et safe

Le principal objectif de zio-spark est de wrapper l’api spark pour l’adapter à ZIO. Pour comprendre la différence, le mieux est de regarder du code avec zio-spark et sans zio-spark compatible avec Zio.

Sans Zio-spark compatible avec Zio :

import zio._
import org.apache.spark.sql._

val sparksession = SparkSession.builder().master("local[1]").getOrCreate()
val dataframe    = ZIO.attempt(sparksession.read.csv(""))
val result       = dataframe.flatMap(df => ZIO.attempt(df.count()))

val app = result

Avec zio-spark :

import zio.spark.sql._

val sparksession = SparkSession.builder.master("local[1]").asLayer
val dataframe    = SparkSession.read.csv("")
val result       = dataframe.flatMap(_.count)

val app = result.provide(sparksession)

Avec cet exemple, on peut noter plusieurs changements :

zio-spark utilise le système de Layer de ZIO pour passer la spark session. Cela a plusieurs avantages. Le premier étant que l’utilisateur n’a pas besoin de passer la spark session manuellement tout le long de son implication, il peut juste assumer qu’à la fin du monde une spark session sera donné et ne plus y penser. Cela permet aussi de scoper la spark session. Ainsi, en cas de crash ou autre, la spark session se ferme automatiquement.
zio-spark fait en sorte que toutes les actions soient automatiquement des effets. Ainsi, vous n’avez pas besoin de penser à ce qu’est ou non une action. Il suffit de regarder le type de retour pour s’en rendre compte. Cela rend aussi le code beaucoup plus lisible.

Une intégration pensée pour ZIO

zio-spark essaye d’intégrer au maximum les caractéristiques de ZIO dans Spark. Nous avons déjà vu l’utilisation de layer pour la spark session, mais ça ne s’arrête pas là.

À titre d’exemple, la fonction printSchema utilise la Console de ZIO et non print de Scala. Cela permet d’utiliser l’output dans nos tests. Voici un exemple de test rendu possible grâce à ce mécanisme (cela aurait aussi été possible avec Spark mais il aurait fallu faire un mock pour y arriver) :

import zio._
import zio.test._
import zio.test.TestAspect._
import zio.spark.sql._

test("Dataset should have the correct schema") {
  val result =
    """root
      > |-- name: string (nullable = true)
      > |-- age: integer (nullable = true)""".stripMargin('>')

  for {
    df     <- SparkSession.read.csv("")
    _      <- df.printSchema
    output <- TestConsole.output
    representation = output.mkString("\n")
  } yield assertTrue(representation.contains(result))
} @@ silent

Nous avons aussi essayé de rendre les jobs Spark annulable. En effet, ZIO joue beaucoup sur la concurrence et nous voulions que ceci s’applique aussi aux jobs Spark. Malheureusement, ceci ne fonctionne pas par le simple fait de wrapper notre action Spark dans ZIO. Le cas échéant, la fiber contenant le job sera supprimée, mais le job au niveau des workers continuera d’être traité. Nous fournissons un moyen pour répondre à cette problématique et je vous invite à regarder la documentation pour plus d’informations.

Conclusion

J’espère, après lecture de cette introduction, que vous vous sentez plus à l’aise avec cette librairie, pourquoi nous l’avons créé et ce qu’elle peut vous apporter dans votre quotidien.

Vous vous demandez peut-être comment tout cela fonctionne sous le capot, pour cela, il faudra attendre le prochain article où nous expliquerons comment faire une librairie zio (zio-spark, zio-notion, zio-aws, …) et où nous parlerons de code generation !

Configurer RouterOS comme client WireGuard

2022-12-21T23:00:00Z

⚠️

Les ressources de cet article ne sont pas supposées être utilisé en production, il y a une multitude de paramètres à affiner avant un passage en production.

Cet article fait suite à la configuration de RouterOS comme client OpenVPN, autant la configuration avec OpenVPN est fastidieuse que celle avec WireGuard est enfantine.

Pré-requis

Pour réaliser les étapes suivantes, nous aurons besoins de :

RouterOS 7.7
WireGuard

En dehors de ces versions, vous devrez peut-être adapter les instructions.

Obtenir une configuration cliente

La distribution d’une configuration WireGuard se fait régulièrement sous forme de QR Code.

Dans notre cas, nous avons besoin d’exploiter le contenu du fichier de configuration client, donc il faudra d’abord le décoder si l’on n'a que le QR Code.

[Interface]
PrivateKey = *REDACTED*
Address = 192.168.27.90/32
DNS = 8.8.8.8
MTU = 1360

[Peer]
PublicKey = *REDACTED*
Endpoint = wireguard.server.io:13231
AllowedIPs = 192.168.27.64/27, 192.168.0.0/24
PersistentKeepalive = 10
PresharedKey = *REDACTED*

Configurer WireGuard dans RouterOS

Avec Winbox

Ajouter l’interface WireGuard dans RouterOS

Dans le menu WireGuard à gauche, ajoutons une interface comme ce qui suit.

Dans le volet General, définissons le nom de l’interface, ainsi que le MTU, Listen Port et la Private Key tel qu’ils sont indiqués dans le fichier de configuration.

Ajouter le `Peer`dans RouterOS

Toujours dans la fenêtre WireGuard, dans le volet Peers, ajoutons un nouveau Peer.

Sélectionnons l’interface WireGuard créée juste avant et indiquons la Public Key du fichier de configuration, indiquons de même le Endpoint.

Pour chaque AllowedIPsdu fichier, mettre une des IP autorisée à transiter par le VPN, chaque ligne est une adresse CIDR unique et la flèche vers le bas permet d’en ajouter d’autres.

Indiquons la Preshared key puisque le serveur en fournie une.

Il faut aussi reporter la valeur de maintien de connexion, Persistent Keepalive, exprimée en secondes dans le fichier de configuration et à indiquer dans la fenêtre.

Ajouter l’adresse dans RouterOS

Dans le menu IP, Addresses, ajoutons l’IP telle qu’indiquée dans le fichier de configuration et le segment CIDR ici. Dans mon exemple, le client à l’ip 192.168.27.90 et le masque /27.

Et z’est parti 🎉

📃

Si pour raison inconnue, cela ne fonctionne pas, regardez les logs de RouterOS et ceux du serveur WireGuard.
Il suffit normalement de reporter toutes les valeurs du fichier de configuration client que vous avez.

Avec la console

Voici la version console des étapes ci-dessus.

Ces étapes impliquent que nous ayons accès à la console de RouterOS.

Ajouter l’interface WireGuard dans RouterOS

/interface/wireguard/add \
    name=wireguard_interface \
    listen-port=13231 \
    mtu=1360 \
    private-key="**REDACTED**"

Ajouter le `Peer`dans RouterOS

/interface/wireguard/peers/add \
    allowed-address=192.168.167.0/24,0.0.0.0/0 \
    endpoint-address=wireguard.server.io \
    endpoint-port=13231 \
    interface=wireguard_interface \
    persistent-keepalive=10s \
    preshared-key="**REDACTED**" \
    public-key="**REDACTED**"

Ajouter l’adresse dans RouterOS

/ip/address/add \
    address=192.168.27.90/27 \
    interface=wireguard_interface

Et z’est parti 🎉

Configurer RouterOS comme client OpenVPN

2022-12-21T23:00:00Z

⚠️

Les ressources de cet article ne sont pas supposées être utilisé en production, il y a une multitude de paramètres à affiner avant un passage en production.

Pré-requis

Pour réaliser les étapes suivantes, nous aurons besoins de :

RouterOS 7.7
OpenVPN 2.4.7
OpenSSL/LibreSSL 3.3.6

En dehors de ces versions, vous devrez peut-être adapter les instructions.

Configuration requise du serveur OpenVPN

À l’heure de la version 7.7rc2 de RouterOS, celle-ci ne supporte pas encore tls-auth, donc dans la configuration du serveur le paramètre doit être absent ou commenté avec #.

De même, RouterOS ne supporte pas la compression LZO, ainsi dans la configuration serveur, commenter comp-lzo no et ajouter push "comp-lzo no".

Sur 7.7rc2, nous avons le support de la connectivité UDP.

Voici un exemple de la configuration serveur.

server 192.168.255.0 255.255.255.0
verb 3
key /etc/openvpn/pki/private/openvpn.server.io.key
ca /etc/openvpn/pki/ca.crt
cert /etc/openvpn/pki/issued/openvpn.server.iovfgb.crt
dh /etc/openvpn/pki/dh.pem
#tls-auth /etc/openvpn/pki/ta.key
key-direction 0
keepalive 10 60
persist-key
persist-tun

cipher AES-256-CBC
auth sha1

proto udp4
port 1194
dev tun0
status /tmp/openvpn-status.log

user nobody
group nogroup
#comp-lzo no

### Route Configurations Below
route 192.168.254.0 255.255.255.0

### Push Configurations Below
push "block-outside-dns"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
push "comp-lzo no"
push "compress stub-v2"

Obtenir un fichier `client.ovpn`

Selon le serveur, le service ainsi que les choix techniques, il existe beaucoup de méthodes pour obtenir un fichier client OpenVPN.

Pour les besoins de cet article, nous avons utilisé PiVPN afin de créer la configuration du serveur de même que celle des clients.

Par exemple, il existe aussi l’image docker 🐳 kylemanna/openvpn qui permet rapidement de mettre en place un serveur.

Une fois le fichier .ovpn récupéré (ou les différents fichiers), nous allons extraire les informations nécessaires à la configuration de RouterOS.

Préparer les certificats pour RouterOS

Notre fichier utilisateur ressemble à ça,

client
nobind

#ROS: Mode ip
dev tun

remote-cert-tls server

#ROS: Connect To / Port / Protocol
remote openvpn.server.io 1194 udp

#ROS: Clé privée
<key>
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIFHDBOBgkqhkiG9w0BBQ0wQTApBgkqhkiG9w0BBQwwHAQIqCo7o53TV4YCAggA
**REDACTED**
1IyGuqUkRXJd2HY1SC3i3w==
-----END ENCRYPTED PRIVATE KEY-----
</key>

#ROS: Certificat client
<cert>
-----BEGIN CERTIFICATE-----
MIIDVzCCAj+gAwIBAgIRAPVtgQ89n79UIpllih8JZjUwDQYJKoZIhvcNAQELBQAw
**REDACTED**
4iasQhOPIRyN4vIMIU2IRLuycLS29OFiKo0dB3EOa/c0zZk7683LnxKv/Q==
-----END CERTIFICATE-----
</cert>

#ROS: Certificat de l'autorité de certification
<ca>
-----BEGIN CERTIFICATE-----
MIIDSzCCAjOgAwIBAgIUXb0Dr/Lrq6q3mhdgzUfNAoCmhjswDQYJKoZIhvcNAQEL
**REDACTED**
4JqvkASv/EK0BkLec83s4Y1Pcppx+h+5YeTz2/+T4g==
-----END CERTIFICATE-----
</ca>
key-direction 1
<tls-auth>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
d4b81257b426595a5d3faaf040a362ae
**REDACTED**
90863f9cdf9e1eb6d3815f6443a6383c
-----END OpenVPN Static key V1-----
</tls-auth>

redirect-gateway def1

Extraire les certificats et la clé

Nous allons extraire le certificat du serveur, le certificat client et la clé.

La clé arrive par défaut sous sa forme chiffrée dans la configuration.

C’est la data qui se trouve entre <key>…</key>, RouterOS échouera à la lire directement, donc nous allons devoir la convertir avant son import.

Le certificat client entre<cert>…</cert>, et le certificat de l’autorité de certification <ca>…<⁣/ca> sont à extraire également.

On peut ouvrir le fichier avec un éditeur de texte et copier-coller les différentes sections dans les fichiers ca.pem, client.pem, client.pem ou en shell avec grep.

grep -Poz '(?s)\K<key>(.*)</key>?' client.ovpn | sed -E '/<?key>/d' > client.key
grep -Poz '(?s)\K<cert>(.*)</cert>?' client.ovpn | sed -E '/<?cert>/d' > client.pem
grep -Poz '(?s)\K<ca>(.*)</ca>?' client.ovpn | sed -E '/<?ca>/d' > ca.pem

🍎

Les opérations réalisées avec le terminal ci-dessus utilisent la version gnu de grep, par défaut sous macOS indisponible, elle peut être installée avec brew install grep.
Pour la compatibilité, les commandes sont préfixées avec g, c'est pourquoi on doit utiliser ggrep et non grep avec macOS.

Déchiffrer la clé

Maintenant, nous allons créer un fichier pem qui va nous permettre d’importer le tout dans RouterOS, cependant, la clé est actuellement sous sa forme chiffrée donc nous allons la déchiffrer.

openssl rsa -in ./client.key -out ./client.key

Si tout est bon, la clé est déchiffrée. Dans le contenu

----BEGIN ENCRYPTED PRIVATE KEY----- devient ----BEGIN RSA PRIVATE KEY-----

Création du fichier PEM

À présent, créons le fichier pem contenant le la clé, le certificat client et le certificat de l’autorité de certification.

cat ca.pem client.pem client.key > certificate.pem

Le certificat client.pem ressemble à ça,

L’ordre des certificats dans le fichier PEM a son importance, RouterOS les importe de manière séquentielle et s’il ne peut trouver le certificat auquel correspond la clé, ou le certificat permettant de vérifier l’autorité de certification, il ignorera ces derniers ou ne les approuvera pas.

Ainsi l’ordre de lecture est en premier le certificat CA, puis le certificat client et la clé privée. Cela évite de répéter l’opération d’import 3 fois.

Configuration de l’interface OpenVPN-Client sur RouterOS

Avec winbox

Import du fichier PEM

Allons dans Files, ensuite, téléversons le fichier certificate.pem que nous avons créé plus haut,

Ajout des certificats au gestionnaire de RouterOS

Dans le menu System, Certificates, cliquons sur Import.

Dans Name, on peut changer la racine du nom du certificat ou le laisser la valeur par défaut prise depuis le nom du fichier que l’on va importer.

Indiquons le fichier que l’on a téléversé comme File Name.

La Passphrase reste vide, car on a déchiffré la clé juste avant et nous n’avons pas chiffré le contenu du fichier PEM.

Une fois ajouté, deux lignes sont apparues dans le gestionnaire.

Dans mon exemple certificat.pem_0 avec les attributs K et T et certificat.pem_1 avec juste T en attribut.

Double-cliquez sur celui ayant les attributs KT, c’est le certificat client et renommons-le en openvpn_client par exemple.

Faisons de même pour le second et renommons-le en openvpn_ca.

📌

Le K signifie que la clé pour ce certificat est présente dans le gestionnaire
Le T signifie que le certificat est approuvé (trusted) dans le gestionnaire.

Le fait d’ajouter un certificat autosigné implique que la vérification ne peut se faire qu’avec le certificat de l’autorité de certification depuis laquelle nous l’avons demandé.
Si le certificat de l’autorité de certification (CA) est absent, lors de la configuration de l’interface OpenVPN-client, l’option Verify Server Certificate doit être désactivé, sinon la vérification du certificat client échouera et la connexion ne s’établira pas.

Création du profil Point-to-Point

Dans le menu PPP, nommons-le ovpn, dans le volet Protocols, définissons IPv6 sur no, MPLS sur no, Compression sur yes et Encryption sur required.

Ajout de l’interface OpenVPN-client

Dans le menu Interfaces, dans le volet Interface, ajoutons une interface OVPN Client.

On fait correspondre les différents champs au contenu du fichier client.ovpn, l’User correspond à l'username de profil OpenVPN, les paramètres Auth. et Cipher sont à adapter de votre serveur OpenVPN.

Dans notre exemple, je n’ai pas coché l’ajout de la route par défaut ainsi que de celles qui seraient poussées par le serveur, car cela routerait tout le trafic sortant de RouterOS au travers du tunnel une fois ouvert.

Indiquons le profil PPP ovpn que l’on a créé juste avant. Faisons Apply puis vérifions dans le volet Status que tout est bon.

Et z’est parti 🎉

Désormais, à l’aide d’un autre client du même serveur OpenVPN, on doit pouvoir exécuter un ping vers l’IP du matériel exécutant RouterOS.

Pour connaitre l’adresse obtenue par le serveur, on peut la voir dans les logs du serveur ainsi que le menu IP, Addresses à la ligne de l’interface OpenVPN-Client.

📃

Si pour raison inconnue, cela ne fonctionne pas, il faut regarder les logs de RouterOS et ceux du serveur OpenVPN.
Cela donne une grande aide pour corriger les options de chiffrement qui ne seraient pas les bonnes par rapport au serveur et bien d’autres paramètres qui ne seraient pas cohérents.

Avec la console

Voici la version console des étapes ci-dessus.

Ces étapes impliquent d’avoir l’accès SCP pour téléverser le fichier PEM sur RouterOS et l’accès console (voir la configuration dans IP, Services).

Import du fichier PEM avec SCP

scp ./certificat.pem admin@192.168.167.250:certificat.pem

Ajout des certificats au gestionnaire de RouterOS

/certificate/import \
    file-name=certificat.pem \
    name=openvpn \
    passphrase=""

La sortie doit afficher comme ce qui suit

certificates-imported: 2
private-keys-imported: 1
files-imported: 1
decryption-failures: 0
keys-with-no-certificate: 0

Renommage des certificats importés

/certificate/set openvpn_1 name="openvpn_ca"
/certificate/set openvpn name="openvpn_client"

Création du profil Point-to-Point

/ppp/profile/add \
    use-ipv6=no \
    use-compression=yes \
    use-encryption=required \
    use-mpls=no \
    name=ovpn

Ajout de l’interface OpenVPN-client

/interface/ovpn-client/add \
    connect-to="openvpn.server.io" \
    port=1194 \
    mode=ip \
    protocol=udp \
    user="utilisateur" \
    profile=ovpn \
    certificate=openvpn_client \
    verify-server-certificate=yes \
    tls-version=any \
    auth=sha1 \
    cipher=aes256-cbc \
    add-default-route=no \
    route-nopull=yes

Et z’est parti 🎉

Importing a pem certificat

When a pem certificate is imported that holds the ca, crt and the private key (client.pem). The key is not handled/recognised. When the pem without the key (client_wokey.pem) is imported and after that the private key (…

https://forum.mikrotik.com/t/importing-a-pem-certificat/105545

Mikrotik router as OpenVPN Client

configure your mikrotik routerboard as an openvpn client

http://missinglink.github.io/mikrotik-openvpn-client/

Comment augmenter la sûreté de nos types en Scala (partie 2)

2022-12-18T07:00:00Z

Nous avons vu dans la partie 1 comment rendre nos types plus forts en utilisant seulement les outils que nous donne le langage sans utiliser aucune librairie. Dans cette partie, nous allons voir les réponses de la communauté pour répondre aux deux problématiques que j’avais établi dans le premier article, à savoir :

Deux valeurs du même type peuvent être interchangeables (un paramètre String peut recevoir à la fois un mail et un nom d’utilisateur sans provoquer une erreur).
Une valeur peut avoir un domaine plus restreint que ce que permet un type (un email est un String, mais tous les Strings ne sont pas des emails).

La première problématique

Nous avons déjà longuement répondu à cette dernière et la réponse fournie par le langage semble avoir aussi convaincu toute la communauté puisque, à ma connaissance, il n’y a pas eu beaucoup de travaux open source pour répondre à cette problématique.

La seule véritable proposition atypique que j’ai croisée est celle de Miles Sabin qui a été ensuite implémentée par softwaremill. Elle repose sur la tagging pour différencier deux mêmes types. Si on reprend l’exemple de la partie 1 :

import com.softwaremill.tagging._

case class User {
	id: String @@ UserId
}

trait UserId

case class Team {
	id: String @@ TeamId,
	users: List[User]
}

trait TeamId

On peut résoudre correctement l’exemple ci-contre :

val user = User("uuid".taggedWith[UserId])

def getWorkingHoursLastWeek(id: String @@ TeamId): Int = ???

val hours = getWorkingHoursLastWeek(user.id) // It does not compile 🔥

Ça fonctionne ! Cette méthode a aussi l’avantage d’être totalement transparente au runtime (tout comme les types opaques et dans une moindre mesure les value classes). Il a aussi un autre avantage comparé à ce qu’on a déjà vu : on peut automatiquement récupérer n’importe quelle typeclass du type taggé avec quasiment aucun overhead.

Il suffit d’utiliser l’import suivant :

import com.softwaremill.tagging.AnyTypeclassTaggingCompat._

La deuxième problématique

Passons maintenant à la deuxième problématique que j’ai soulevée. Afin de comprendre en quoi cela en est une, nous allons pour cela prendre le cas d’une fonction assez connue :

def take[A](list: List[A], n: Int): List[A] = ???

Cette dernière prend les n premiers éléments d’une List. Vous êtes-vous déjà demandé ce qui arriverait si on renseignait un n négatif ?

Il existe une infinité de possibilités, les plus courantes sont les suivantes :

La fonction renvoie une exception
La fonction gère les valeurs incohérentes de n en les remplaçant par zéro
La fonction renvoie la List à partir du dernier élément (coucou python)

On pourrait discuter des heures sur laquelle de ces possibilités est la meilleure. En réalité, le problème ici est que la fonction devrait ne pouvoir prendre que des nombres supérieurs à zéro.

Malheureusement, le langage ne nous fournit pas les moyens pour régler ce genre de problème directement au compile time. Fort heureusement, des librairies permettent de pallier ce besoin.

Refined

La plus connue est très certainement refined. Si on reprend l’exemple précédent :

import eu.timepit.refined.api.Refined
import eu.timepit.refined.auto._
import eu.timepit.refined.numeric._

def take[A](list: List[A], n: Int Refined Positive): List[A] = ???

Grâce à refined, on peut spécialiser nos types. Ici, on précise que n, en plus de devoir être un int, doit aussi être un nombre positif (cela n’a pas de sens de demander un nombre négatif comme dit au-dessus, mais 0 n’a aussi pas vraiment de sens). Refined fournis un grand nombre de modificateurs que vous pouvez combiner avec un grand nombre de types. À titre d’exemple, vous pouvez :

Forcer des Strings à être des URLs
Forcer des Strings à ne pas être vide
Forcer des Strings à être des adresses mails
Forcer des Floats à être entre 0 et 1

Bien évidemment, la librairie vous donne aussi la possibilité de créer vos propres modificateurs, je vous invite à lire la documentation pour plus d’informations.

Il faut cependant différencier les valeurs reçues au compile time de celles reçues au runtime. Cette librairie ne peut pas savoir à l’avance que la valeur rentrée par un utilisateur correspond au prédicat. Pour pallier ce problème, une fonction vous permet de récupérer la valeur ou une erreur dans le cas où le prédicat n’est pas respecté au runtime :

val userPositiveInt: Either[String, Int Refined Positive] = refineV[Positive](???)

NewType

Refined répond parfaitement à la problématique numéro 2. Malheureusement, cela ne répond pas à la problématique numéro 1 et il nous faudra alors combiner deux méthodes pour obtenir quelque chose de concluant.

Pour être honnête, ce genre de syntaxe est assez lourde :

case class User {
	id: String Refined NonEmpty @@ UserId
}

Ce serait génial si une librairie pouvait faire les deux en même temps !

Fort heureusement pour nous, il existe une solution : les NewTypes de zio-prelude. Prenons le cas de notre User :

import zio.prelude.Assertion.isEmptyString
import zio.prelude.Subtype

case class User(id: UserId)

object UserId extends Subtype[String] {
  override def assertion = assert { !isEmptyString }
}

type UserId = UserId.Type

La réponse donnée par les NewTypes répond bien aux deux problématiques puisque :

UserId est un type bien définit qui ne peut pas être remplacé par un String, ce qui permet d’empêcher les erreurs d’étourderies.
UserId a une “assertion” qui permet au compile time de valider que la donnée renseignée est celle attendue

Tout comme pour refined, vous pouvez aussi saisir des valeurs au runtime de la manière suivante :

val userPositiveInt: Validation[String, UserId] = UserId.make(???)

Conclusion

Il existe beaucoup de possibilités dans l’écosystème Scala pour avoir des types beaucoup plus précis, au compile time et sans overhead. Selon moi, chacun à son utilité, ses avantages et ses inconvénients.

Si vous voulez mon avis, le choix devrait dépendre du contexte :

Refined offre une syntaxe très élégante lorsqu’il s’agit de traiter des cas génériques, mais qui ne permet pas de différencier les types métiers.
Les NewTypes de zio-prelude quant à eux offrent une syntaxe plus encombrante, mais gère correctement le besoin d’avoir des types ayant les mêmes prédicats, mais pas la même signification d’un point de vue métier.
Les opaque types sont directement intégrés au langage et donc censés mieux résister à l’épreuve du temps, mais ils ne prennent pas en compte l’aspect validation au compile time.

Comment augmenter la sûreté de nos types en Scala (partie 1)

2022-12-11T07:00:00Z

Produire du code qui fonctionne du premier coup est une sensation incroyable. Au-delà de l’accomplissement personnel, cela réduit aussi considérablement le temps de développement. En effet, lorsque le projet prend de l’ampleur, il n’est pas toujours facile de remarquer les erreurs d’étourderies et ces dernières se manifestent (normalement) dans l’environnement de test.

Le problème ? Le temps pour que le code arrive en test est incroyablement long, il faut que la CI lance tous les checks, que la PR soit validée, puis qu’elle soit déployée, et ensuite que le bug soit détecté manuellement. Et même si on se dit qu’avec tous ces filtres, l’étourderie devrait disparaitre, en réalité, il m’est déjà arrivé un nombre incalculable de fois que cette dernière persiste jusqu’en production.

Le typage fort à la rescousse !

C’est pour cette raison que j’estime qu’un typage fort est un véritable plus. Il est peut-être embêtant sur le court terme (pour des POCs par exemple), mais sur le long terme, il permet une très grande stabilité.

On a de la chance, avec Scala c’est exactement ce qu’on a ! Ce genre d’ânerie n’est pas possible puisque le compilateur ne voudra pas laisser passer votre code :

val id: String = 5

Comme toute bonne chose, on en veut toujours plus ! Les Strings, les Ints, tout cela reste très générique dans l’idée.

Cela soulève deux problèmes :

Deux valeurs du même type peuvent être interchangeables (un paramètre String peut recevoir à la fois un mail et un nom d’utilisateur sans provoquer une erreur).
Une valeur peut avoir un domaine plus restreint que ce que permet un type (un email est un String, mais tous les Strings ne sont pas des emails).

Aujourd’hui, je vous propose de répondre au premier problème et de voir les solutions que nous avons à notre disposition pour le résoudre.

Partons d’un modèle de donnée qui regroupe des utilisateurs repartis dans des projets. On peut créer le domaine de la manière suivante :

case class User (
	id: String
)

case class Team (
	id: String,
	users: List[User]
)

Jusque-là, il n’y a aucun souci particulier. Mais, imaginons maintenant que vous avez la fonction suivante :

def getWorkingHoursLastWeek(id: String): Int = ???

Pouvez-vous me dire, en étant 100% sûr de vous, à quoi fait référence id ?

Utiliser un alias de type

Un moyen simple pour régler ce quiproquo est d’utiliser les alias de type. Voici comment faire avec notre exemple :

case class User (
	id: UserId
)

type UserId = String

case class Team (
	id: TeamId,
	users: List[User]
)

type TeamId = String

Il faut bien comprendre que UserId et TeamId sont des alias de String et peuvent être utilisés à la place de String en affectant uniquement la lisibilité du code.

Et voilà la nouvelle fonction associée :

def getWorkingHoursLastWeek(id: TeamId): Int = ???

On y voit tout de suite plus clair ! L’utilisation des alias de type rentre dans le cadre du “types as documentation”. Ici, la signature de la fonction se suffit à elle-même, nous n’avons ni besoin de lire le contenu de la fonction pour comprendre ce qu’elle fait, ni besoin de rédiger une docstring pour l’expliquer.

Malheureusement, ce n’est pas aussi simple et il y a un hic…

val user = User("uuid")

val hours = getWorkingHoursLastWeek(user.id) // It compiles 💀

Les alias de types aiguillent les programmeurs, mais pas le compilateur. Pour lui, ce n’est que des simples String sous le capot. Il va falloir changer de stratégie.

Utiliser une case class

Reprenons l’exemple précédent, mais au lieu d’utiliser un alias de type, nous allons utiliser une case class pour représenter notre id :

case class User (
	id: UserId
)

case class UserId(value: String)

case class Team (
	id: TeamId,
	users: List[User]
)

case class TeamId(value: String)

Si on reprend là où on s’était arrêté :

val user = User(UserId("uuid"))

val hours = getWorkingHoursLastWeek(user.id) // It does not compile 🔥

C’est plutôt pas mal ! Notre fonction nous indiquera immédiatement si l’id qu’on lui renseigne est bien un id de team ou pas. Cela rajoute un peu d’overhead puisqu’il faut wrapper l’id dans une case class. Mais en réalité, hormis dans les tests, on ne le fait quasiment jamais. Généralement, l’utilisateur sera créé suite à un processus de désérialisation.

À ce sujet, je vous conseille de vous-même définir des Encoders et des Decoders qui imite le comportement d’un String dans ce cas précis, voici un exemple avec zio-json :

case class UserId(value: String)

object UserId {
	implicit val codec:JsonCodec[UserId] = JsonCodec.string.transform(UserId.apply, _.value)
}

En utilisant ce codec, le JSON ressemblera à ceci :

{"id": "uuid"}

Alors que si on utilise l’auto-dérivation, le JSON ressemblera à :

{"id": {"value": "uuid"}}

Cela alourdit le format pour rien puisque value ne donne aucune information supplémentaire.

Wrapper l’id a aussi un autre avantage, vous ne pouvez plus utiliser les opérations de String sur un UserId. Concaténer des ids n’a, par exemple, aucun sens. Vous pouvez donc définir vos propres opérations et créer une véritable API autour de votre type.

Mais il y a encore un hic… Cette façon de faire va créer un overhead qui, sur le long terme, peut impacter les performances de vos applications. Il va falloir peaufiner notre stratégie.

Utiliser une value class

Il existe une manière pour enlever cette overhead au runtime : les value class (depuis Scala 2.10). Si vous voulez plus d’informations, vous pouvez vous rendre dans la documentation (liée au SIP-15) sur le site du langage Scala. C’est assez simple à mettre en place en reprenant l’exemple précédent :

case class User (
	id: UserId
)

case class UserId(value: String) extends AnyVal

case class Team (
	id: TeamId,
	users: List[User]
)

case class TeamId(value: String) extends AnyVal

Pour vous, rien ne change. Mais au runtime tous les UserId et TeamId seront considérés comme des Strings. On élimine complétement l’overhead !

En fait, non ! Il y a encore un hic… J’ai menti, l’overhead n’est pas complétement éliminé. Je vous laisse lire la partie motivation des types opaques (que nous allons voir ci-dessous) dans la documentation du SIP-35 pour en apprendre plus à ce sujet.

Utiliser un opaque type (Scala 3 only)

Comme dit précédemment, une value class n’élimine pas complétement l’overhead. Scala 3 introduit en conséquence une nouvelle feature qui est censé régler ce problème, à savoir les opaques types. Reprenons donc notre exemple :

case class User (
	id: UserId
)

opaque type UserId = String

object UserId {
	def apply(value: String): UserId = value
}

case class Team (
	id: TeamId,
	users: List[User]
)

opaque type TeamId = String

object TeamId {
	def apply(value: String): TeamId = value
}

Cette manière de faire ne comporte plus aucun overhead et répond 100% à notre problématique de départ.

Mais il y a encore un hic… Pour l’avoir utilisé à titre personnel, ces derniers ne sont pas encore bien supportés par les différentes librairies qui composent l’écosystème Scala. J’ai eu notamment des problèmes avec Tapir et ZIO quill notamment.

Conclusion

Pour conclure, il y a eu un énorme chemin de parcouru pour arriver à avoir des sous types safes et sans overhead. Avoir des sous types qui précisent les différentes valeurs que nous manipulons permet d’avoir un code encore plus clair et précis qu’avec les types de base. C’est selon moi un vrai plus dans une codebase et je n’ai, pour l’instant, vu aucun point négatif à les utiliser. Les opaques types semblent extrêmement prometteurs dans ce sens-là. Mais du fait du manque de compatibilité actuel, je ne vous les conseille pas en production pour autant. De manière plus étendue, comme Scala 3 reste assez jeune (cette version est sortie l’année dernière), je considère qu’il vaut mieux attendre avant de l’envoyer en production. Particulièrement avec l’effort fourni par VirtusLab qui propose gratuitement de migrer les projets Scala 2 vers 3, quasiment tout l’écosystème est d’ores et déjà fonctionnel en Scala 3 ! Selon moi, ce sont surtout les IDEs qui peinent pour le moment à s’adapter.

À titre personnel, je me suis résigné à repasser aux value classes pour le moment.

Dans cet article, nous avons vu les solutions que proposait le langage Scala. Dans le prochain article, nous passerons aux différentes librairies qui composent cet écosystème et qui nous permet d’être encore plus précis et safe.

Scala Thank You : Organizing Scala.IO

2022-11-09T23:00:00Z

Scala.IO is done for this year, only a couple of things to wrap up (publishing the talks, a bit of accounting, …) before we move on to the organization of Scala.IO 2023!

This edition was outstanding. We had such a warm support from the community, from our speakers, our sponsors and our attendees. It was a bit overwhelming at some point, and very very friendly.

Personally, I have been in the Scala Community for the major part of my professional life, so seeing people again, growing with them and sharing those moments is highly rewarding.

What went wrong?

Not much, it went well, a couple of things we need to fix for the next edition :

We had to cancel workshops, we announced them too late, so we were unable to gather enough participants. However, having the Scala Spree was a success.
Video problems with MacOS. That led to reprogramming the talk by Jules Ivanic (GraphQL/ zio-test / Caliban) + a couple of issues repeatedly during the day. We have a fix and a backup process for next year.
Catering problems. Water and drinks were not freely available during the afternoon due to a misunderstanding with our caterer. That will be fixed, we will make sure you stay hydrated and caffeinated if needed.
Women attendance and beginner attendance. We had very few attendees (and speakers) from those two populations. We don’t have a fix on it yet, but we will make sure to make efforts in that direction to gather more new and diverse people for the next edition.

How do you manage?

There have been plenty of friendly questions in that direction. Short answer: we don't!

More seriously, from year to year, the team pretty much follows this structure:

core organization team (managing sponsors, suppliers, speakers, tickets, communications before the event + leading the pace during the event).
additional team members (CFP, communications, support before the event + crowd and room management during the event).
and outside event organizers, especially for Paris (suppliers, stands, venue … and everything that can go wrong during the installation of the event)

We have a very efficient event organizer in Paris (http://321idcom.fr/), Karine manages all the things that could go wrong fast directly, and she comes back to us for the rest which makes everything easy.

We had a lot of core team members from the French Scala community over the years, with Jean Helou being invested a lot in the conference since 2013, Fabrice Sznajderman since 2016 … Valentin Kasas for past editions in Lyon, François Sarradin and I since 2013, on and off depending on the editions…

This year we pushed and helped Fabrice restart the conference as fast as possible, with people from Univalence (Dylan Do Amaral, François Sarradin and I), with additional members (Valentin Bergeron, Nicolas Couturier, William Machi) to help with the call for papers, tickets, suppliers …

We were joined for the day of the event by Jean Helou himself, and Warris Radji who help a lot with the organization during the day.

With all of that, things fall in motion once set, and we are happy with the outcome.

Why and what’s next?

Scala.IO was created in 2013 to help people use Scala professionally. At the time, the population in the meetups were split between people that would use Scala at work and others that would use it on the weekends. The creation of the conference helped with the implantation of Scala, especially for hobbyists to make a career out of it.

This edition was significant for us, we haven’t really had time to meet and share our passion for Scala, and its ecosystem over the past 3 years. It was lovely to meet again.

Since Scala has gained a lot more traction, in the future we aim to leverage the conference to welcome newcomers and ease the transition to Scala using the friendly vibes and kindness we have around the event.

It was very interesting to be able to connect during the event with the Scala Center and Darja to start to see what can be done for the community with the leverage of common resources, and help go in that direction.

There is a lot of movement in Scala with the adoption of Scala 3, the different IOs, and all the great things that are coming in our ecosystem. We are pleased to be a part of it and follow through.

Next format

We are going back to what we were doing. For the next edition, on the 26th and 27th of October 2023, we are aiming for something closer to our old format:

2 days
3 tracks, 48 talks
at least 12 talks for beginner in Scala (dedicated track for 1.5 days)
Workshops on Wednesday (beginner, effect systems, spark, …)
a bigger community Party on Thursday
crêpes (we make sure they come back to the event)
…

For 300, up to 400 attendees, if we can convince more students and beginners to come.

We will use all the experience gathered for the past 10 years, and we will make a well-rounded event in Paris, and we can’t wait to share that with you again!

Thank you and see you soon

As always, thanks a lot to Martin Odersky, for everything and especially greeting us with a great keynote.

Thanks to all the attendees, speakers, sponsors for making that moment memorable.

See you very soon!

Dérivation récursive de typeclass avec Scala 3

2022-11-09T23:00:00Z

Dans un précédent article, nous avions parlé de dérivation de typeclass en Scala 2 avec Magnolia. Nous avions vu qu’il est possible de dériver des typeclass pour des sealed trait à l’aide de la méthode split. En revanche, nous avons aussi observé que dans les cas de dérivation récursive, il nous fallait forcer la dérivation de notre sealed trait.

Dans cet article, nous allons tâcher de montrer comment faire une dérivation récursive de typeclass avec magnolia en Scala 3.

Reprenons…

Imaginons que l’on ait le co-produit suivant :

sealed trait A
case object B(str: String) extends A
case class C(next: A)      extends A

Figure 1 : Trait A et case class / objects

On souhaite dériver la typeclass Show suivante pour toute instance de A :

trait Show[T] {
  def show(t: T): String
}

trait ShowObj[T] extends Show[T] {
  def showObj(t: T): String
}

On peut se demander pourquoi nous avons Show et ShowObj ?

Ce pattern peut être utile lorsque l’on ne souhaite pas implémenter des comportements spécifiques à un type.

Par exemple, on peut imaginer que l’on ait besoin de Show pour afficher les types primitifs sur la console (String, Int…) et ShowObj pour afficher les case class

Figure 2 : Schéma de dérivation de typeclass qui explique pourquoi avoir Show et ShowObj

Unsupported block 2e2d5288-2960-45c8-9bcc-ef822fbcd276 unsupported
in https://www.notion.so/D-rivation-r-cursive-de-typeclass-avec-Scala-3-bb1ec3911d08498ca4514f53d0cf00f0

Dans notre exemple, on va essayer de dériver Show de manière à obtenir :

Show[String]
Show[Int]
ShowObj[CaseClassOne]
ShowObj[CaseClassTwo]

Maintenant, projetons notre exemple sur notre Trait A

Figure 3 : Schéma de dérivation de typeclass pour l’ADT de la Figure 1

On remarque que l’on va souhaiter obtenir les dérivations suivantes :

Show[String]
ShowObj[A] → va être obtenu par la méthode split
ShowObj[B]
ShowObj[C]

On peut voir avec la figure 3 que Show[C] va être récursive.

En effet, C contient un A qui peut être un C qui contient un A…

Nous avons vu qu’avec Magnolia en Scala 2, la dérivation récursive de typeclass semble avoir des bugs. Partons d’un exemple rapide proche de ce que nous voulons faire.

trait Tc[T]

trait TcObj[T] extends Tc[T]

object ShowDerivation {
  type Typeclass[T] = Tc[T]

  def join[T](ctx: CaseClass[Tc, T]): TcObj[T] = new TcObj[T] {}
  def split[T](ctx: SealedTrait[Tc, T]): TcObj[T] = new TcObj[T] {}

  def gen[T]: Tc[T] = macro Magnolia.gen[T]
  def genObj[T]: TcObj[T] = macro Magnolia.gen[T]
}

Voici l’utilisation de ce code.

ShowDerivation.gen[B.type]    // success ☑️

ShowDerivation.genObj[B.type] // success ☑️

ShowDerivation.gen[A]         // success ☑️

//ShowDerivation.genObj[A]    // failure ❌
/*
type mismatch;
 found   : Playground.ShowDerivation.Typeclass[Playground.A]
    (which expands to)  Playground.Tc[Playground.A]
 required: Playground.TcObj[Playground.A]
*/

implicit val tca:Tc[A] = null

ShowDerivation.gen[C]        // success ☑️

ShowDerivation.genObj[C]     // success ☑️

Qu’en est-il en Scala 3 ?

On est toujours obligé de forcer la dérivation. La documentation de Magnolia l’explique ici : https://github.com/softwaremill/magnolia#limitations.

Un exemple

Dans cet exemple, l’idée est de reprendre le problème de la figure 2, mais en Scala 3.

On va tâcher de dériver la typeclass Show pour le trait suivant :

  sealed trait Kind
  case class Human(name: String) extends Kind
  case class Elf(elvishName: String) extends Kind
  case class Hybrid(kind: Kind, other: Kind) extends Kind

Le type Kind représente donc soit des humains, soit des elfes, soit des êtres hybrides (avec deux noms ^^).

Reprenons le code de la figure 4 pour le porter en Scala 3 :

object Show extends Derivation[Show]{

  override def join[T](ctx: CaseClass[Show, T]): ShowObj[T] = new ShowObj[T] {???}

  override def split[T](ctx: SealedTrait[Show, T]): ShowObj[T] = new ShowObj[T] {???}

  inline given autoDerived[A](using Mirror.Of[A]): Show[A] =
    derived.asInstanceOf[Show[A]]

  inline given derivedObj[A](using Mirror.Of[A]): ShowObj[A] =
    derived.asInstanceOf[ShowObj[A]]
}

Comme on l’a vu dans la Figure 3 nous allons avoir besoin de Show[String] pour afficher les String sur la console

  given Show[String] with
    def show(t: String): String = s"$t"

Désormais, nous avons un moyen d’afficher nos String et le squelette principal de notre dérivation.

Il nous faut alors implémenter split et join qui vont nous permettre de dériver les typeclass pour les sealed trait et les case class :

  override def join[T](ctx: CaseClass[Show, T]): ShowObj[T] = new ShowObj[T] {
    override def show(t: T): String = t.toString.toUpperCase()

    override def showObj(t: T): String =
      ctx.params.map(param => param.typeclass match {
        case showObj: ShowObj[param.PType] =>
          s"${param.label} part: [ ${showObj.showObj(param.deref(t))} ] "
        case show: Show[param.PType] =>
          s"${param.label}: [${show.show(param.deref(t))}]"
      }).mkString
  }

  override def split[T](ctx: SealedTrait[Show, T]): ShowObj[T] = new ShowObj[T] {
    override def show(t: T): String = ctx.choose(t) { sub =>
      sub.typeclass.show(sub.cast(t))
    }
    override def showObj(t: T): String = ctx.choose(t) { sub =>
      val tc = sub.typeclass.asInstanceOf[ShowObj[T]]
      tc.showObj(sub.cast(t))
    }
  }

Arrêtons-nous sur deux choses :

Le showObj de join :
- On regarde si on souhaite dériver un Show ou un ShowObj de notre case class (en l’occurrence, on voudra un Show, si on a un type primitif, ou un ShowObj, si on a une case class).
- On formate correctement les valeurs des paramètres en les déréférençant, c'est-à-dire en récupérant leur valeur “réelle”.
Le showObj de split :
- On parcourt tous les sous-types d’un sealed trait (en l’occurrence, les sous-types de Kind) pour trouver celui que l’on cherche à dériver.
- On cast notre sous-type dans son type réel (eg. j’ai un sous-type de Kind, si je vois que son type réel est Elf, alors je le cast en Elf) et on appelle showObj pour ce bon type.

Utilisons tout cela désormais.

val aelfraed: Kind = Elf("Aelfraed")
val maeva: Kind = Human("Maeva")
val kind :Kind = Hybrid(aelfraed, maeva)

given instance2: Show[Kind] = Show.derived

val showKind: Show[Kind] = summon[Show[Kind]]
println(s"1 - ${showKind.show(kind)}")

given instance3: ShowObj[Kind] = Show.derivedObj

val showObjKind: ShowObj[Kind] = summon[ShowObj[Kind]]
println(s"2 - ${showObjKind.showObj(kind)}")

Ce qui donne.

1 - HYBRID(ELF(AELFRAED),HUMAN(MAEVA))
2 - kind part: [ elvishName: [Aelfraed] ] other part: [ name: [Maeva] ]

Si on retourne sur la Figure 3 on voit que l’on a bien obtenu :

Show[String]
ShowObj[A] → obtenu par la méthode split
ShowObj[B]
ShowObj[C]

Et que Show[T] peut aussi dériver un A (cf. HYBRID(ELF(AELFRAED),HUMAN(MAEVA))) comme indiqué dans la Figure 2.

Voilà le code exécutable dans une worksheet, happy hacking!

import language.experimental.macros
import magnolia1.*

import scala.deriving.Mirror

trait Show[T] {
  def show(t: T): String
}
trait ShowObj[T] extends Show[T] {
  def showObj(t: T): String
}

object Show extends Derivation[Show]{
  given Show[String] with
    def show(t: String): String = s"$t"

  given Show[Int] with
    def show(t: Int): String = s"#${t.toString} -"

  override def join[T](ctx: CaseClass[Show, T]): ShowObj[T] = new ShowObj[T] {
    override def show(t: T): String = t.toString.toUpperCase()
    override def showObj(t: T): String =  ctx.params.map(param => param.typeclass match {
      case showObj: ShowObj[param.PType] => s"${param.label} part: [ ${showObj.showObj(param.deref(t))} ] "
      case show: Show[param.PType] => s"${param.label}: [${show.show(param.deref(t))}]"
    }).mkString
  }

  override def split[T](ctx: SealedTrait[Show, T]): ShowObj[T] = new ShowObj[T] {
    override def show(t: T): String = ctx.choose(t) { sub =>
      sub.typeclass.show(sub.cast(t))
    }
    override def showObj(t: T): String = ctx.choose(t) { sub =>
      val tc = sub.typeclass.asInstanceOf[ShowObj[T]]
      tc.showObj(sub.cast(t))
    }
  }

  inline given autoDerived[A](using Mirror.Of[A]): Show[A] = derived.asInstanceOf[Show[A]]
  inline given derivedObj[A](using Mirror.Of[A]): ShowObj[A] = derived.asInstanceOf[ShowObj[A]]
}

Et voici l’utilisation.

import Show.given_Show_String

sealed trait Root
case object B extends Root
case class C(next:Root) extends Root

given instance: Show[Root] = Show.derived

val showA: Show[Root] = summon[Show[Root]]
val root: Root = C(C(B))
println(showA.show(root))

sealed trait Kind
case class Human(name: String) extends Kind
case class Elf(elvishName: String) extends Kind
case class Hybrid(kind: Kind, other: Kind) extends Kind

val aelfraed: Kind = Elf("Aelfraed")
val maeva: Kind = Human("Maeva")
val kind :Kind = Hybrid(aelfraed, maeva)

given instance2: Show[Kind] = Show.derived

val showKind: Show[Kind] = summon[Show[Kind]]
println(showKind.show(kind))

given instance3: ShowObj[Kind] = Show.derivedObj
val showObjKind: ShowObj[Kind] = summon[ShowObj[Kind]]
println(showObjKind.showObj(kind))

Ressources

code de l’article : https://github.com/univalence/recursive-derivation-magnolia/blob/main/src/main/scala/ShowDerivationMagnolia3.scala

HR-OPS: Automatiser la création de documents administratifs avec zio-notion

2022-10-19T22:00:00Z

Introduction

Quand l’informatique est perçue comme une source de coûts, on peut être tenté d’utiliser des outils de no-code pour répondre à ses problèmes.

Et le no-code, ça marche bien jusqu’à ce que ça marche plus. La question de savoir ce que l’on veut faire est progressivement remplacée par “qu’est-ce que l’on peut faire” ?

Certaines tâches administratives et de gestion coûtent du temps, sont répétitives, sont difficilement automatisable par des solutions de no-code, en particulier quand il s’agit de faire des transformations avec un contexte entier qui ne se gère pas avec du 1 pour 1 (ex. N notes de frais, M personnes ⇒ M piéces pour la comptabilité, avec une synthèse et une concatenation des éléments des notes frais)

Dans cet article, nous allons voir comment faire un générateur de PDF qui source ces données depuis Notion.

Étude de cas

Imaginons plusieurs cas d’usage :

Notes de frais : Vous devez rassembler les notes de frais de vos équipiers dans un simple document, par équipier, pour l’envoyer à la comptabilité tous les mois.
Dossiers locatifs : si vous cherchez un endroit où habiter/travailler, il est possible que vous ayez à envoyer plusieurs dossiers. Certaines pièces changent régulièrement (3 derniers bulletins de salaire, justificatif de domicile récent, etc.) le reste de pièces est stable dans le temps.
Proposition commerciale pour enseigner dans une école : le programme change, le CV des formateurs évoluent moins vite.

Toutes ces pièces jointes sont soigneusement rangées dans votre base documentaire

Figure 1 - Base de données Notion regroupant des fichiers PDF ainsi que leurs informations contextuelles

Vous aimeriez pouvoir fusionner les PDF pour constituer un document à partir de votre page Notion, tout en gardant des informations sur le contenu de votre page, et en annotant les pièces avec des éléments supplémentaires (en tête, pagination, etc.).

Prérequis

Vous faites du Scala ;
Vous utilisez les effets ZIO ;

Zio-notion

zio-notion est une bibliothèque logicielle qui permet d’interagir avec Notion.

zio-notion est livré avec en ensemble de features pratiques telles que :

Un DSL pour écrire des filtres ou manipuler des colonnes :

Figure 2 - Exemple de filtre sur l’interface Notion

Et son équivalent avec zio-notion :

val filters: Filter =
    $"Tag".asSelect equals "filter-1" and
      $"Author".asPeople.contains("Bastien Guihard")

Un mécanisme de déstructuration :

Vous pouvez choisir de déstructurer une page et la représenter par une case class directement.

Soit une case class DatabaseEntry :

final case class DatabaseEntry(
      @NotionColumn("Name")   name: String,
      @NotionColumn("Author") author: String
)

Déstructuration de la Page en DatabaseEntry :

for {
      database   <- Notion.queryAllDatabase("ID-DB-FIGURE-1", filter)
      maybeEntry <- database.results.headOption.map(_.propertiesAs[DatabaseEntry].toZIO)
			_          <- maybeEntry match {
		     case Some(entry) => Console.printLine(entry.name)
         case None.       => Console.printLine("There is no database entry.") 
	    } 
} yield()

Vous pouvez retrouver la documentation ici : https://univalence.github.io/zio-notion/

Fusionneur de PDF “maison”

Revenons à notre projet initial

Notre projet doit être capable

D’interagir avec Notion ;
De télécharger les PDF à fusionner ;
De créer un PDF contenant une page récapitulative et les PDF fusionnés ;

Figure 3 - Architecture de notre fusionneur de PDF fait maison

Le projet de cet article est disponible ici : https://github.com/univalence/hr-ops

On va se pencher sur la logique de l’application :


/**
 * DocumentContext représente un document PDF une fois telechargé augmenté de 
 * son nom, son nombre de pages et les informations de la base de donnée
 */
final case class DocumentContext(name: String, bytes: Array[Byte], numberOfPage: Int, databaseRow: DatabaseEntry)

...

/**
 * Tout d'abord on souhaite fusionner les PDF dont la valeur de Tag
 * est égale à "filter-1"
 */
val filter: Filter = $"Tag".asSelect.equals("filter-1")

...

def program: ZIO[Downloader with Notion, Throwable, Unit] =
    for {
			/**
			 * `queryAllDatabase` nous permet de passer en revue l'intégralité de la base de données
			 * 
			 * En effet, zio-notion est livré avec une gestion de la pagination des bases de données, 
			 * vous pouvez aisément parcourir votre base de donnée de manière séquentielle
			 * https://univalence.github.io/zio-notion/pagination
			 */
      database <- Notion.queryAllDatabase(Constants.dbId, filter)
			// on destructure toutes les entrées qui nous interesse
      destructureEffects = database.results.map(_.propertiesAs[DatabaseEntry].toZIO)
      entries <- ZIO.collectAllPar(destructureEffects)
      // On construit les effets qui représentent le téléchargement des documents
			contextualizeEffects = entries.map(_.contextualize)
      documentContexts <- ZIO.collectAllPar(contextualizeEffects)
      flattenDocumentContexts = documentContexts.flatten
			// La création d'un encodeur déclaratif rend la construction d'un PDF évidente 
      documentDescription =
        CreateNewPDF >>
          AddTable(flattenDocumentContexts) >> AddPDFs(flattenDocumentContexts) >> Paginate >> SavePDF("concat")
			/**
			 * On interprete cette description, en l'occurence via PDF BOX
			 * 
			 * Pour changer de technologie il nous suffit de changer d'interpreteur, 
			 * la description reste la même
			 */
      _ <- documentDescription.interpret.orDie
    } yield ()

Conclusion

En deux coups de cuillère à pot, vous pouvez vous affranchir des limites du no code.

La stack de ce projet (Scala + Notion + zio-notion) nous donne un ensemble de garanties :

Vous conservez la modularité de Notion pour organiser votre contenu ;
Zio-notion vous assure d’interagir avec notion d’une manière pratique, idiomatique de Scala ;

Les solutions no-code restent des solutions viables dans pas mal de cas, mais il est intéressant de prendre en compte dans votre choix d’outil que vous ne serez pas coupé dans votre élan.

La garantie de pouvoir interagir avec un outil no-code/low-code par le biais d’un SDK ou d’une API publique de qualité est un élément essentiel à prendre en compte dans son choix d’outillage.

Scala : Sandwich de versions et rétrocompatibilité

2022-10-17T22:00:00Z

Introduction

Dans son article https://univalence.io/blog/articles/scala-3-un-nouveau-langage/ François nous présentait les nouveautés de Scala 3 et nous donnait des conseils vis-à-vis de la migration de projets en Scala 2 vers Scala 3.

Dans cet article, nous parlerons un peu plus en détail des problèmes liés aux migrations et cohabitations entre Scala 2 et Scala 3.

Prérequis

Avant de commencer, débutons par les mauvaises nouvelles.

Vous allez avoir des problèmes pour migrer votre code base si :

Vous dépendez d’une bibliothèque logicielle qui fait usage de macro Scala 2
- Si c’est le cas, vous pouvez aller voir ici l’état de la migration des dépendances populaires.
Votre projet dépend d’un plugin sbt qui n’a pas d’équivalent pour Scala 3
- Si c’est le cas, allez jeter un œil aux alternatives.
Votre projet dépend de scala-reflect
- Si c’est le cas… Je n’ai pas encore de solution pour vous.

Jar Hell

Toujours avant de commencer, il est important d’avoir une vue rapide sur ce que l'on appelle le Jar Hell. Le Jar Hell c’est ce qui qualifie les problèmes que l'on peut rencontrer avec les mécanismes de classloading de la JVM.

Voilà une liste non exhaustive de ces problèmes :

Unexpressed deps
- Un jar n'indique pas de quels autres jars, il dépend. Dès lors, c'est au développeur de résoudre lui-même certaines dépendances.
Dépendances transitives
- Certaines bibliothèques logicielles dépendent de certaines autres bibliothèques (qui dépendent elles-mêmes d’autres bibliothèques, etc.). C’est, là encore, au développeur de récupérer les sous-dépendances.
Shadowing
- Un projet peut dépendre de deux versions différentes d’une même bibliothèque. Cela arrive, par exemple, lorsque deux des dépendances d’un projet dépendent d’une même bibliothèque, mais pour des versions différentes. Dans le meilleur des cas, il est possible de ne conserver que la version la plus récente. Mais il peut arriver que les deux versions soient incompatibles (par exemple, une fonction est disponible dans les deux versions, mais la signature a changé avec des paramètres différents et/ou un type de retour différent).
Conflit de versions
- Deux bibliothèques dépendent de deux bibliothèques incompatibles.

TASTy ?

Si vous êtes intéressé par Scala 3, vous avez surement déjà dû entendre parler de TASTy.

TASTy (Typed Abstract Syntax Trees) est un format d’échange entre votre code et votre code compilé (.class file).

Concrètement, ce sont des fichiers qui contiennent toute l’information utile sur le code.

Le format TASTy permet de palier à certains désavantages de la compilation en bytecode, les fameux .class, dans la mesure où ces derniers contiennent une représentation incomplète du code.

Par exemple, une fois compilé en bytecode (.class), les types génériques subissent un effacement de type (type erasure).
Le code Scala suivant :

val xs: List[Int] = List(1, 2, 3)

sera converti en

public scala.collection.immutable.List<java.lang.Object> xs();

Cela assure une compatibilité du code source et du code binaire entre les versions de la JVM, pour des raisons historiques, puisque les premières versions de Java ne disposaient pas de types génériques (implémentés dans Java 1.5 par Martin Ordersky). Cela vous évite entre autres de recompiler vos applications lorsque vous migrez vers des versions plus récentes de la JVM.

Les avantages d’avoir un format tel que TASTy sont multiples :

Un outil de build peut s’en servir pour construire le projet pour plusieurs versions de la JVM.
Permet une inspection du code profonde par des outils de métaprogrammation et permet de générer du code dans des cas avancés.

Qu’est-ce que cela autorise à faire de base ?

La lib ne doit pas dépendre de scala.reflect (donc pas de macro).

La lib ne doit pas dépendre du nouveau type de métaprogrammation (inline statements…).
Inclure l’option de compilateur -Ytasty-reader.

Notez que si vous souhaitez utiliser une bibliothèque Scala 3 dans votre projet Scala 2, vous allez soit :

Devoir écrire manuellement que votre lib est en Scala 3.
Par exemple :

"org.legogroup" %% "woof-core"  % "0.2.0"

Deviendra dans un build en Scala 2
"org.legogroup" % "woof-core_3" % "0.2.0"

lazy val main = project.in(file("main"))
  .settings(
		scalaVersion:= scala2,
		scalacOptions+= "-Ytasty-reader",
		libraryDependencies++=Seq(
      "org.legogroup" % "woof-core_3"   % "0.2.0"
     )
  )
  .dependsOn(middle)

Soit utiliser l’opérateur cross

lazy val main = project.in(file("main"))
  .settings(
		scalaVersion:= scala2,
		scalacOptions+= "-Ytasty-reader",
		libraryDependencies++=Seq(
      "org.legogroup" %% "woof-core" % "0.2.0" cross CrossVersion.for2_13Use3
     )
  )
  .dependsOn(middle)

sbt Reference Manual — Cross-building

https://www.scala-sbt.org/1.x/docs/Cross-Build.html#Scala+3+specific+cross-versions

Étude de cas

Nous allons étudier la compatibilité de Magnolia au sein de projets composants Scala 2 et Scala 3.

Rappelons que les versions Scala 2 et 3 de Magnolia tirent parti respectivement des macros et des nouvelles fonctionnalités de métaprogrammation.

Nous allons tenter de répondre aux questions suivantes :

Peut-on utiliser Magnolia pour Scala 2 au sein d’un projet Scala 3 ?
Peut-on utiliser Magnolia 3 au sein d’un projet Scala 2 ?
Est-ce qu’un projet Scala 2 peut dépendre d’un projet Scala 3 qui utilise Magnolia 3 ?
Est-ce qu’un projet Scala 3 peut dépendre d’un projet Scala 2 qui utilise Magnolia 2 ?
Est-ce que les ADT et Typeclass de Scala 3 peuvent être dérivés par Magnolia 2 ?

Note sur IntelliJ

L’outillage de IntelliJ vis-à-vis de Scala 3 étant encore en développement, nous vous conseillons d’utiliser les commandes sbt build, sbt run depuis un terminal directement.

Schéma d’une application mélangeant Scala 2, Scala 3 et Magnolia pour Scala 2 et 3.

Une précision sur le schéma :

genX[TcY[ADTZ]] signifie que la classe expose une dérivation via magnolia pour Scala X, sur des typeclass écrites en Scala Y paramétrés par des ADT Scala Z avec X, Y et Z pouvant être égal à 2 ou 3.

Notez que la topologie suivante ne marche pas :

💩 cette topologie ne marche pas

✅ Cette topologie fonctionne si :

On garde qu’une seule version de Magnolia
Et l'on dérive les typeclasses avec le bon compilateur :
- Dans le Scala 3 module si on utilise magniola pour Scala 3
- Dans le Scala 2 project si on utilise magniola pour Scala 2

Répondons aux questions précédemment posées :

Peut-on utiliser Magnolia 2 au sein d’un projet Scala 3 ?
- Non. En effet, générer une typeclass via Magnolia 2 fait usage de scala.reflect.macro, ce qui est impossible à faire avec le compilateur de Scala 3 (ces fonctionnalités ont été abandonnées).
Peut-on utiliser Magnolia 3 au sein d’un projet Scala 2 ?
- Non plus, ici ce sont les nouvelles fonctionnalités de métaprogrammation qui ne sont pas supportées par le compilateur de Scala 2.
Est-ce qu’un projet Scala 2 peut dépendre d’un projet Scala 3 qui utilise Magnolia 3 ?
- Oui, car on dépend du bon compilateur.
Est-ce qu’un projet Scala 3 peut dépendre d’un projet Scala 2 qui utilise Magnolia 2 ?
- Oui aussi, pour les mêmes raisons que précédemment.
Est-ce que les ADT et Typeclass de Scala 3 peuvent être dérivés par Magnolia 2
- Les enums de Scala 3 semblent poser un problème lorsqu’on tente de les dériver en Scala 2. En revanche, les ADT et typeclass de Scala 3, même avec leurs nouvelles features, paraissent ne pas poser problème, ni à l’utilisation, ni à la dérivation.

Si vous souhaitez expérimenter un peu avec les sandwiches, vous pouvez démarrer avec le code de cet article : https://github.com/univalence/scala-sandwich

Les outils pour aider à la migration

sbt est livré avec un outil de migration sbt migration plugin.

Il permet de :

Migrer les dépendances disponibles en Scala 3.
Migrer les options de compilation vers leur équivalent en Scala 3.
Aider à migrer la syntaxe.
Repérer les types qu’il sera impératif d’annoter manuellement du fait que le mécanisme d’inférence de type change en Scala 3.

Si vous avez des dépendances de versions de Scala différentes, vous pouvez envisager d’utiliser Mima pour prévenir les incompatibilités binaires.

Conseils

Un jour viendra où il faudra impérativement arrêter d’utiliser des libs en Scala 2 qui ne seront plus maintenues notamment pour des raisons de sécurité. En effet, être compatible avec Scala 3 ne signifie pas que vous n’aurez jamais à migrer.

Voici quelques conseils pour préparer l’échéance :

Effectuer la migration progressivement pour fixer les problèmes petit à petit.
Arrêter le support des applications en Scala 2.12 et antérieures pour faciliter le passage a Scala 3.
Faites des tests de non-régression avec une bonne couverture de test (un couverture autour de 80% semble être une bonne recommandation).
Lisez la doc de Scala à propos de la migration.
Regardez l’état de la migration des libs dont vous dépendez.
Arrêtez d’utiliser les technologies/features dont vous savez à l’avance qu’elles ne seront pas portées en Scala 3 (les macros, scala reflect).

Erreurs

signature has wrong version

[error] (class scala.tools.tasty.UnpickleException/TASTy signature has wrong version.
[error]  expected: {majorVersion: 28, minorVersion: 1}
[error]  found   : {majorVersion: 28, minorVersion: 2}

Cela arrive quand les versions de scala 2.13 et scala 3 ne sont pas compatible, il faut en général monter la version de scala 2.13 (la dernière c’est 2.13.9).

inline in scala 2

[error] scala.reflect.internal.Types$TypeError: Unsupported Scala 3 inline method deriveSubtype; found in trait magnolia1.Derivation.


[error] stack trace is suppressed; run last c / Compile / compileIncremental for the full output
[error] (c / Compile / compileIncremental) scala.reflect.internal.Types$TypeError: Unsupported Scala 3 inline method deriveSubtype; found in trait magnolia1.Derivation.

WeakTypeTag evidences

[error][...] scala:26:51: macro implementations cannot have implicit parameters other than WeakTypeTag evidences
[error]implicit def gen[T]: Show[T] = macro Magnolia.gen[T]

Cela arrive si scala-reflect est manquant dans un projet magnolia - Scala 2.

Magnolia (chopped and screwed)

2022-09-15T22:00:00Z

Introduction

Vous l’aurez surement remarqué, écrire des typeclass peut être assez mécanique et répétitif.

Magnolia est une bibliothèque logicielle qui permet de faire de la dérivation de typeclass, c'est-à-dire, d’écrire des typeclass pour nous.

La littérature technique à propos de magnolia n’est pas simple à comprendre.

Dans cet article, nous allons tâcher de comprendre, par étape, comment fonctionne magnolia par la pratique.

https://fr.wikipedia.org/wiki/Chopped_and_screwed

Qu’est-ce qu’on bricole ?

Imaginons un ensemble de case class assez différentes les unes des autres :

  sealed trait Race
  case class Human(firstName: String, sound: String, socialSecurityNumber: Int) extends Race
  case class Dwarf(name: String, sound: String, goldAmount: Int)                extends Race
  case class Elf(name: String, skincareRoutine: String)                         extends Race

Pour chacune de ces case class, on souhaite pouvoir écrire le code suivant :

val human = Human(firstName = "John", lastName = "Doe", sound = "Hello", socialSecurityNumber = 123)

println(human.shout)            
println(human.epicDescription)

Et obtenir une super sortie épique sur notre terminal :

John Doe shouts: HELLO

FIRSTNAME              : John
LASTNAME               : Doe
SOUND                  : Hello
SOCIAL SECURITY NUMBER : 123

Approches naïves : Pourquoi utiliser la dérivation de typeclass ?

Afin d’apprécier les bénéfices d’un système de dérivation de typeclass tel que magnolia, intéressons-nous à ce que serait la vie sans magnolia.

Méthode à la mano

On va commencer par écrire une typeclass qui représente notre comportement.

On veut que nos personnages soient en mesure de pousser un cri et de décrire leurs attributs :

  sealed trait Shout[A] {
    def epicDescription(a: A): String
    def shout(a: A): String
  }

Commençons par implémenter ce comportement pour un Human et un Dwarf:

  val shoutingHuman: Shout[Human] =
    new Shout[Human] {
      override def epicDescription(a: Human): String =
        s"""
           |FIRSTNAME              : ${a.firstName}
           |LASTNAME               : ${a.lastName}
           |SOUND                  : ${a.sound}
           |SOCIAL SECURITY NUMBER : ${a.socialSecurityNumber}
           |""".stripMargin
      override def shout(a: Human): String = a.sound.toUpperCase
    }

  val shoutingDwarf: Shout[Dwarf] =
    new Shout[Dwarf] {
      override def epicDescription(a: Dwarf): String =
        s"""
           |NAME  : ${a.name}
           |SOUND : ${a.sound}
           |GOLD  : ${a.goldAmount}
           |""".stripMargin
      override def shout(a: Dwarf): String = a.sound.toUpperCase
    }

On se rajoute une petite classe implicite afin de faciliter l’écriture de notre comportement :

  implicit class HumanOps(human: Human) {
    def shout: String           = shoutingHuman.shout(human)
    def epicDescription: String = shoutingHuman.epicDescription(human)
  }

  implicit class DwarfOps(dwarf: Dwarf) {
    def shout: String           = shoutingDwarf.shout(dwarf)
    def epicDescription: String = shoutingDwarf.epicDescription(dwarf)
  }

Et voilà le travail :

val johnDoe = Human(firstName = "John", lastName = "Doe", sound = "Hello", socialSecurityNumber = 123)

println(johnDoe.shout)
println(johnDoe.epicDescription)

//  HELLO
//
//  FIRSTNAME              : John
//  LASTNAME               : Doe
//  SOUND                  : Hello
//  SOCIAL SECURITY NUMBER : 123

Vous pouvez trouver le code de cette implémentation ici

Allez courage, il en reste encore un comme ça… pour le moment

On remarque que le code de shoutingDwarf et shoutingHuman est sensiblement le même, bien que l’on ne puisse pas le généraliser “facilement”.

Vous l’aurez compris, on va pouvoir se passer du processus répétitif d’implanter, plus ou moins, la même typeclass plusieurs fois.

Pour nous permettre d’être plus efficace, on va avoir une approche réflexive, autrement dit que l’on va chercher à écrire un programme capable de s’inspecter lui-même.

Il existe deux types de réflexion :

la réflexion au runtime :
- Elle permet d’inspecter les types des objets y compris génériques (après réification)
- D’instancier de nouveau objets
- D’appeler des méthodes d’un objet
la réflexion au compiletime :
- Permet de faire de la métaprogrammation, c'est-à-dire du code qui va explorer le code (en particulier pour magnolia, la structure des types) via certaines instructions spéciales et générer du code

C’est la deuxième approche qui nous intéresse.

En effet, on veut que notre compilateur “écrive” les typeclasses pour nous.

Un des avantages de la réflexion au compiletime est que le compilateur vérifie que le code généré est correct. À l’instar de la réflexion au runtime qui peut planter… au runtime

C’est là que magnolia intervient

Niveau 1 : `Join`

Dans un premier temps, nous allons chercher à faire en sorte que le comportement de notre typeclass soit disponible pour n’importe quelle case class

C’est la fonction join qui permet de faire ça. On trouve aussi cette fonction sous le nom combine

Ci-dessous, la structure de base d’une dérivation de typeclass :

object ShoutDerivation {

  // Alias de type
  type Typeclass[T] = Shout[T]

  // Fonction qui va permettre de dériver notre comportement
  def join[T](ctx: CaseClass[Shout, T]): Shout[T] =
    new Shout[T] {
      override def epicDescription(a: T): String = ???

      override def shout(a: T): String = ???
    }

	// Cette fonction nous permet de générer nos typeclass
  implicit def gen[T]: Shout[T] = macro Magnolia.gen[T]
}

Commençons par dériver la méthode shout :

On sait que nos case class ont généralement un argument sound
On voudrait que la sortie ressemble à SOUND TO UPPER CASE
Les paramètres de nos case class sont accessibles via ctx.parameters

override def shout(a: T): String =
        // on cherche un argument sound
        ctx.parameters.find(_.label == "sound") match {
          // si il existe on le renvoie en capitales
          case Some(value) => value.typeclass.shout(value.dereference(a)).toUpperCase
          // sinon tant pis
          case None        => "I can't shout"
        }

Si on essaye de compiler maintenant, voilà ce qu’il risque d’arriver :

magnolia: could not find Shout.Typeclass for type String
    in parameter 'firstName' of product type io.univalence.magnolia_chopped_and_screwed.Race.Human

  val shoutingHuman: Shout[Human] = ShoutDerivation.gen[Human]

Effectivement, à ce stade, magnolia ne sait pas quoi faire des String et des Int qui composent nos Race

Pour notre sujet, nous avons juste besoin de renvoyer leur valeur sous forme de String :

implicit val shoutString: Shout[String] =
    new Shout[String] {
      override def epicDescription(a: String): String = ??? // on garde l'implantation d'epicDescription pour le niveau 2
      override def shout(a: String): String           = a
    }

implicit val shoutInt: Shout[Int] =
    new Shout[Int] {
      override def epicDescription(a: Int): String = ???
      override def shout(a: Int): String           = a.toString
    }

Et ça marche !

val shoutingHuman: Shout[Human] = ShoutDerivation.gen[Human]

val human: Human = Human(firstName = "John", lastName = "Doe", sound = "Hello world", socialSecurityNumber = 123)
println(shoutingHuman.shout(human))

//HELLO WORLD

Résumé du Niveau 1 :

Le code du Niveau 1 est disponible ici
La méthode join nous permet de dériver le comportement d’une typeclass sur n’importe quelle case class
On peut agir sur les paramètres de nos case class
Il faut décrire le comportement des primitives telles que String et Int afin d’effectuer une dérivation

Comment améliorer le Niveau 1 :

On se rend compte que c’est un peu bizarre de devoir définir epicDescription pour un String ou un Int
Il n’est pas très ergonomique d’écrire shoutingHuman.shout(human) mais human.shout

Niveau 2

Dans un premier temps, nous allons commencer par découper notre typeclass Shout

  sealed trait Shout[A] {
    def shout(a: A): String
  }

  // Comportement spécifiques aux case class
  trait ShoutCC[A] extends Shout[A] {
    def epicDescription(a: A): String
  }

  // Comportement pour les valeurs (String et Int dans notre cas)
  trait ShoutValue[A] extends Shout[A]

Les avantages de ce pattern sont multiples.

Dans un premier temps, il nous permet de définir plus facilement la manière dont nos valeurs doivent se comporter

On verra un autre intérêt lorsqu’on s’attaquera au code de join

implicit val shoutString: ShoutValue[String] = str => str
implicit val shoutInt: ShoutValue[Int]       = i => i.toString // plus besoin de définir epicDescription pour un String ou un Int

Aussi, on peut ajouter une implicit class qui va nous permettre d’écrire human.shout

// On prend n'importe quelle case class et, si disponible, son implantation de Shout
implicit class ShoutCCOps[A <: AnyRef with Product](a: A)(implicit shoutCC: ShoutCC[A]) {
    // on expose pour les case class shout et epicDescription
    def shout: String           = shoutCC.shout(a)
    def epicDescription: String = shoutCC.epicDescription(a)
  }

val human = Human(firstName = "John", lastName = "Doe", sound = "Hello world", socialSecurityNumber = 123)

// Grace à l'implicit class précédente, on peut écrire :
println(human.shout) //HELLO WORLD

Intéressons-nous maintenant au code de join pour epicDescritpion.

C’est un cas classique, ctx nous permet d’obtenir le nom des paramètres et le déréférencement de la case class nous permet d’obtenir les valeurs associées.

def join[T](ctx: CaseClass[Shout, T]): ShoutCC[T] =
    new ShoutCC[T] {
      override def epicDescription(a: T): String =
        ctx.parameters
          .map(param => s"\n \t${param.label.toUpperCase} = ${param.dereference(a)}")
          .mkString

Jusqu’ici tout va bien :

  FIRSTNAME = John
 	LASTNAME = Doe
 	SOUND = Hello world
 	SOCIALSECURITYNUMBER = 123

Mais imaginons maintenant que l’on décide d’ajouter une nouvelle case classe, composée de deux autres

Par exemple, une petite personne qui serait le produit d’un humain et d’un nain

case class LittlePerson(human: Human, dwarf: Dwarf)extends Race

val human        = Human(firstName = "John", lastName = "Doe", sound = "Hello world", socialSecurityNumber = 123)
val dwarf        = Dwarf(name = "gimli", sound = "uh", goldAmount = 1000)

val littlePerson = LittlePerson(human, dwarf)
println(littlePerson.epicDescription)

On peut facilement imaginer que la sortie ne va pas ressembler à notre super formatage avec des sauts de lignes et des tabulations 🥲

HUMAN = Human(John,Doe,Hello world,123) 	
DWARF = Dwarf(gimli,uh,1000)

Effectivement rien ne va plus et c’est là que notre pattern qui visait à séparer le comportement des valeurs et des cases classes devient pratique :

def join[T](ctx: CaseClass[Shout, T]): ShoutCC[T] =
    new ShoutCC[T] {
      override def epicDescription(a: T): String =
        ctx.parameters
          .map(param =>
            param.typeclass match {
              // On pattern match sur le type des arguments
              case cc: ShoutCC[param.PType] => s"${param.label} part: [${cc.epicDescription(param.dereference(a))}] \n"
              case cc: ShoutValue[param.PType] => s"\n \t${param.label.toUpperCase} = ${cc.shout(param.dereference(a))}"
            }
          )
          .mkString

En faisant du pattern matching sur la typeclass (disponible dans ctx) on peut avoir des comportements distincts pour chaque type :

human part: [
 	FIRSTNAME = John
 	LASTNAME = Doe
 	SOUND = Hello world
 	SOCIALSECURITYNUMBER = 123] 
dwarf part: [
 	NAME = gimli
 	SOUND = uh
 	GOLDAMOUNT = 1000]

Résumé du Niveau 2 :

Le code du Niveau 2 est disponible ici
Séparer les comportements des valeurs et des case classes nous permet d’écrire du code plus concis et nous facilite l’écriture de la dérivation.
La dérivation de typeclass ne nous empêche pas de créer une classe implicite

Comment améliorer le Niveau 2 :

Dans cet exemple, on ne manipule jamais Race directement, il se passe quoi si on fait ça ?

Niveau 3

Imaginons encore une fois une nouvelle case class composée de deux Race dont on ne connait pas le type.

case class GenericHybrid(race1: Race, race2: Race) extends Race

À l’image du niveau 2, si on combine notre humain et notre nain, on aimerait avoir le même comportement que précédemment

val human        = Human(firstName = "John", lastName = "Doe", sound = "Hello world", socialSecurityNumber = 123)
val dwarf        = Dwarf(name = "gimli", sound = "uh", goldAmount = 1000)  
val hybrid       = GenericHybrid(human, dwarf)

println(AdvancedShoutDerivation.gen[GenericHybrid].shout(hybrid))

Sauf que :

magnolia: the method `split` must be defined on the derivation object AdvancedShoutDerivation to derive typeclasses for sealed traits
  println(AdvancedShoutDerivation.gen[GenericHybrid].shout(hybrid))

On nous demande d’implémenter split afin de pouvoir dériver des typeclass pour des sealed trait, dans notre cas Race

Dans notre cas, l’implantation de split consiste à :

Trouver pour une instance a de type T, le sous-type de Race auquel T correspond
Une fois trouvé, d’invoquer shout ou epicDescription avec l’instance de Race fournie(ici a), castée dans le bon sous type de Race

def split[T](ctx: SealedTrait[ShoutCC, T]): Shout[T] =
    new ShoutCC[T] {
      override def shout(a: T): String =
        // On cherche le bon type de `Race`
        ctx.split(a) { sub =>
          sub.typeclass.shout(sub.cast(a))
        }

      override def epicDescription(a: T): String =
        ctx.split(a) { sub =>
          sub.typeclass.epicDescription(sub.cast(a))
        }
    }

Cette implémentation de split conviendrait pour un autre sealed trait que Race mais malheureusement magnolia est limité quand il s’agit de dérivations récursives (des races dans des races).

Pour palier a ce problème, on est obligé de forcer la dérivation de Race:

...
// on force la dérivation de Race
implicit val shoutRace: Shout[Race] = AwesomeShoutDerivation.bugGenR[Race]
println(AwesomeShoutDerivation.gen[GenericHybrid].epicDescription(hybrid))

}
object AwesomeShoutDerivation {
  import Awesome._

  implicit def gen[T]: ShoutCC[T] = macro Magnolia.gen[T]

  def bugGenR[T]: Shout[T] = macro Magnolia.gen[T]

  type Typeclass[T] = Shout[T]

  def split[T](ctx: SealedTrait[Shout, T]): ShoutCC[T] =
    new ShoutCC[T] {
      override def shout(a: T): String =
        ctx.split(a) { sub =>
          sub.typeclass.asInstanceOf[ShoutCC[sub.SType]].shout(sub.cast(a))
        }

      override def epicDescription(a: T): String =
        ctx.split(a) { sub =>
          sub.typeclass.asInstanceOf[ShoutCC[sub.SType]].epicDescription(sub.cast(a))
        }
    }
...

Résumé du Niveau 3 :

Le code du Niveau 3 est disponible ici
On peut dériver des typeclass pour des sealed trait à l’aide de la méthode split
On est obligé de forcer la dérivation de notre sealed trait dans le cas de dérivations récursives.

À suivre

Dans un prochain article, nous regarderons si Scala 3 nous permet de faire plus facilement des dérivations récursives de typeclass

Pour aller plus loin

https://univalence.io/blog/articles/typeclass-derivation-faites-eclore-vos-instances-avec-magnolia/

ZIO qu'est-ce que c'est ?

2022-08-15T07:00:00Z

Vous faites du Scala, mais vous ne connaissez pas ZIO ? Pour vous, ZIO n’est qu’un buzzword ? Vous ne comprenez pas à quoi cela sert ?

Personnellement, j’ai eu du mal au début à comprendre en quoi cela pouvait m’être utile. Aujourd’hui, je vois mal comment je pourrais m’en passer. Alors, je vais essayer de vous expliquer exactement pourquoi je pense que vous allez l’adorer.

Pourquoi ZIO existe ?

Quand j’ai commencé à rentrer dans le monde fonctionnel, il y avait une chose que je n’arrivais vraiment pas à assimiler.

Comment gérer les effets ?

J’arrivais à créer des programmes fonctionnels et pures. Mais, je ne pouvais rien faire d’essentiellement utile, puisque je ne savais pas comment communiquer avec une API, une base de données ou autre.

J’ai ensuite commencé à m’intéresser à cette question et je suis tombé sur cet adage : “On ne peut pas faire un programme entièrement pur. L’objectif, c'est de retarder la gestion des effets le plus tard possible dans notre code.”

Pour être honnête, je n’avais pas compris comment faire avec cette phrase non plus… J’avais juste compris qu’il fallait essayer d’avoir le plus de fonctions pures puisqu’elles sont :

prévisibles (déterministes)
faciles à tester
faciles à réutiliser

L’IO monad

J’ai compris ce que cela impliquait réellement avec cette vidéo présentant l’IO monad :

C’est l’origine de ZIO et d’autres bibliothèques à “effets” comme Cats Effect ou ScalaZ. Toutes ces librairies ne sont que des implémentations différentes de cette monade.

Le nom est assez barbare, mais la logique derrière la monade est plus simple à appréhender : “On n’exécute pas nos effets immédiatement, on décrit notre programme qu’on interprètera qu’à la fin de notre code.”

Tout commence par cette déclaration :

case class IO[A](unsafeRun: () => A) {
	def map[B](f: A => B): IO[B] = ???

	def flatMap[B](f: A => IO[B]): IO[B] = ???
}

val printHello = IO(() => print("hello"))
val printWorld = IO(() => print(" world"))

printHello.unsafeRun() // Programme qui affiche que "hello"
printHello.flatMap(_ => printWorld).unsafeRun() // Programme qui affiche "hello world"

Ici, printHello et printWorld sont des valeurs qui décrivent un affichage console. Cela veut dire qu’au moment où on les déclare, rien n’est réellement lancé. On peut faire un lien avec les transformations pour Spark, une transformation décrit seulement ce que les workers vont devoir faire, mais rien n’est concrètement lancé au niveau d’une transformation. Pour que cela se lance, il faut une action. Ici notre action, c'est unsafeRun.

ZIO, la monade divine

ZIO, comme on l’a dit auparavant, n’est pas la seule IO monad, mais elle se démarque des autres, car elle a transcendé son être pour devenir ce qu’on appelle une god monad.

ZIO porte ce surnom parce qu'elle est à la fois :

Une IO monad
Une Either monad
Une State monad
Une Future monad

Là où les autres ont parié sur la composition et sur l’utilisation massive du tagless final, ZIO a préféré généraliser tous ces concepts dans un seul et même endroit, rendant son utilisation beaucoup plus simple et naturelle.

ZIO dans les grandes lignes

Pour gérer autant d’aspects différents, ZIO ne peut pas se contenter d’un type générique A comme c’est le cas pour une monade IO[A].

ZIO possède pas moins de trois types génériques et s’écrit donc ZIO[R, E, A] :

Le type A décrit la valeur de retour de notre effet dans le cas nominal
Le type E décrit la valeur de retour de notre effet en cas d’échec
Le type R décrit les dépendances que notre fonction a besoin pour être exécutée

ZIO utilise la hiérarchie des types en Scala (https://docs.scala-lang.org/tour/unified-types.html) dans le cas où vous ne voulez pas de dépendances ou d’erreurs.

Vous voulez décrire un effet qui n’a pas de dépendance ? Il suffit de créer un ZIO[Any, E, A]. Parce que ne pas avoir besoin de dépendances signifie que notre fonction peut accepter n’importe quelle dépendance.

Vous voulez un effet qui n’échoue pas ? Il suffit de créer un ZIO[R, Nothing, A]. Parce que ne pas avoir d’erreurs signifie que le type erreur ne peut pas être défini. Or, le type Nothing n’a pas de valeur associée.

Les aspects de ZIO qui vont vous faciliter la vie

Comme nous l’avons expliqué auparavant, le datatype ZIO crée une description de nos effets qui ne sera interprétée qu’à la fin de notre programme.

💡

On fait souvent l’analogie avec une recette de cuisine, et je trouve la comparaison très bonne. Plutôt que d’être la personne qui cuisine, avec ZIO, on est celui qui écrit la recette. On va ensuite passer cette recette au Runtime de ZIO qui va se charger de la réaliser.

Ce qui est intéressant avec ce principe, c'est qu’on peut très facilement augmenter notre effet et lui rajouter certaines capacités automatiquement et sans overhead.

1. La gestion explicite des erreurs

ZIO rend explicite nos erreurs. Lorsqu’on manipule un effet, on sait exactement si notre effet peut rater et si oui, qu’elle est l’erreur en question que l’on va devoir gérer.

Cela nous permet de mieux appréhender les différents cas non prévus de nos applications et de réduire considérablement le nombre de bugs en production.

ZIO vient avec une pléthore de fonctionnalités pour gérer les erreurs :

vous pouvez décider de les ignorer
vous pouvez décider de les gérer
vous pouvez décider de relancer votre fonction jusqu’à ce qu’elle réussisse
vous pouvez propager les erreurs
vous pouvez transformer les erreurs

Voici, par exemple, comment gérer une erreur :

import zio._

val getUser(id: Int): ZIO[Database, UserNotFound, User] = ???

val printUser: ZIO[Database, Nothing, Unit] = getUser(10).fold(
	failure = _    => Console.printLine("L'utilisateur 10 n'existe pas."),
	success = user => Console.printLine(s"L'utilisateur 10 est ${user.name}.")
)

Ici, on a un nouvel effet printUser qui récupère l’utilisateur numéro 10, puis gère le cas où l'on récupère l’utilisateur de la base de données et le cas où l'on ne le récupère pas :

Si on récupère l’utilisateur, on affiche : “L'utilisateur 10 est John Doe.”.
Si on a une erreur, on affiche : “L'utilisateur 10 n'existe pas.”.

À noter, qu’ici, notre nouvel effet n’a plus d’erreurs (d’où le type Nothing) puisqu’on a géré le cas d’erreur via la fonction fold.

2. La programmation concurrente

On peut, par exemple, lancer une liste d’effet en parallèle sans avoir à s’en soucier plus que ça.

Ces effets seront lancés dans des fibers (en quelque sorte, des greens threads gérés par ZIO). L’avantage des fibers par rapport aux threads de notre ordinateur, c’est qu’on peut en lancer des dizaines de milliers, voire des millions avec un impact faible sur les ressources de la machine ! De notre côté, on ne s’en soucie pas trop. On ne s’occupe que de la logique de notre application.

Voici un exemple dans lequel on récupère une liste d’utilisateurs depuis une base de données de manière concurrente :

import zio._

val getUser(id: Int): ZIO[Database, UserNotFound, User] = ???

// Récupère les utilisateurs de 10 à 20
val getUsers: ZIO[Database, UserNotFound, List[User]] = 
	ZIO.foreachPar((10 to 20).toList)(getUser)

On peut bien évidemment aller beaucoup plus loin. ZIO est rempli de structures concurrentes à la fois pratiques et suffisamment sûres pour vous aider à mener à bien vos projets. Pour plus d’informations : https://zio.dev/overview/overview_basic_concurrency.

3. L’injection de dépendances

Un autre point important de ZIO, c’est le système de Layers. Cette feature prend tout son sens depuis la version 2.0 de ZIO, car elle est devenue plus confortable à utiliser.

Si on reprend l’analogie de la recette de cuisine, cette dernière a souvent besoin d’ustensiles pour fonctionner qu’il va falloir préparer en amont pour la réaliser (eg. le four à faire chauffer à 200ºC et quel sera le temps de la cuisson). Pour les Layers, c’est exactement pareil. Votre programme va avoir besoin de dépendances pour fonctionner tout au long de sa durée de vie. Cela peut être :

Une configuration du programme
Un service pour communiquer avec une API tierce
Une connexion à une base de données pour pouvoir la requêter

Tout ceci peut être fait avec des Layers et cela va grandement vous améliorer la vie. Ce sujet mérite un article de blog à part entière. Si vous voulez plus d’informations, je vous conseille : https://zio.dev/references/contextual/zlayer.

4. Le scheduling

Le dernier point qui est fréquemment mis en second plan, mais que je trouve très important, c’est la possibilité de planifier nos effets.

Avec ZIO, on peut très bien :

répéter un effet 10 fois
répéter un effet tous les mardis à 10 heures du matin
appliquer une stratégie pour que l’effet se relance en cas d’erreur avec entre chaque essai un délai exponentiel
relancer la fonction jusqu’à ce qu’elle réussisse et compter le nombre de fois qu’il a fallu pour qu’elle réussisse

Cette feature est très puissante et permet de remplacer, dans certains cas, des outils d’orchestration un peu trop overkill.

Prenons le cas d’un programme en Scala qui s’assure que github.com est up :

import zio._

def pingGithub: ZIO[Any, ConnectionError, Unit] = ???

val app = 
	pingGithub
		.retry(Schedule.exponential(1.second) && Schedule.recurs(5))
		.schedule(Schedule.spaced(1.minute))
		.orElse(Console.printLine("Github is unreachable"))

Ici l’effet “app”, quand il sera exécuté par le Runtime de ZIO, va ping Github en suivant cette logique :

Il va se lancer toutes les minutes sans interruption (schedule).
Il va se relancer jusqu’à 5 fois si GitHub ne répond pas (retry), d’abord avec 1 seconde de délais, puis avec un délai exponentiel.
Si au bout de 5 fois Github ne répond toujours pas alors, on notifie l’utilisateur (orElse) avec un message dans la console.

Personnellement, la première fois que j’ai écrit ce genre de code, j’ai été impressionné ! En si peu de lignes, on peut écrire un code entièrement fonctionnel, qui gère parfaitement les mauvais cas et qui en plus vient avec un DSL plaisant à lire.

À vous de jouer !

ZIO c’est beaucoup plus que ce que je vous ai présenté. Il y a d’autres fonctionnalités qui sont potentiellement plus pratiques dans vos cas d’usage, comme la gestion des streams, les métriques ou la gestion de la configuration de vos services... Il définit une nouvelle manière d’écrire du code et vous accompagne tout le long du développement de votre application, sans pour autant être clivant comme peuvent l’être les grands frameworks que sont Spring ou Play par exemple.

Si vous avez besoin de plus de ressources, je vous conseille la documentation de ZIO https://zio.dev/ ou encore la chaine YouTube de Ziverge https://www.youtube.com/channel/UCeIg_PnAoyd1w6y8BelLdiQ.

Vous verrez, l’essayer c’est l’adopter !

Je ne suis pas responsable si vous ne pouvez plus vous en passer par la suite ;)

Log4Shell + SBT

2021-12-11T19:00:00Z

Si par hasard, on a un doute sur log4j (CVE-2021-44228), et que l'on utilise Play Framework (2)/sbt, on peut rapidement savoir si on est dans la semoule (une version < 2.15 ou pire inférieur à 2.10.0) :

sbt dependencyTree | grep log4j #dependencyTree est de base dans SBT maintenant

Pour en savoir un peu plus, on peut regarder avec l'analyse de dépendances depuis un terminal (sbt versions >= 0.13.10)

echo 'addSbtPlugin("net.virtual-void" % "sbt-dependency-graph" % "0.10.0-RC1")' >> project/plugins.sbt
sbt "whatDependsOn org.apache.logging.log4j log4j-core"

Les fixs, le truc que j'ai trouvé le plus simple pour passer le week-end "normalement", on ajoute ça aux lanceurs java du côté de la prod :

-Dlog4j2.formatMsgNoLookups=True

On bump la dépendance à 2.15.0 (si possible).

libraryDependencies += "org.apache.logging.log4j" % "log4j-core" % "2.15.0"

Bon week-end !

Plus d’infos :

Apache Logging Services

https://logging.apache.org/security.html

https://www.cve.org/CVERecord?id=CVE-2021-44228

Project LOOM: Les Continuations & les Thread virtuels

2021-09-02T22:00:00Z

Introduction

Dans cet article nous allons parler du projet Loom.

Le projet Loom est une version bêta de l'OpenJDK qui vise à introduire un modèle de concurrence léger à Java.

En effet, pas mal de langages proposent des implantations plus ou moins performantes de modèles qui facilitent les exécutions concurrentes.

Par exemple, Clojure dispose d'un modèle CSP-like qui permet d'envoyer des processus dans un thread pool relativement aisément. Go dispose de ses fameuses go-routines, inspirées des coroutines que nous retrouvons dans Kotlin. Scala propose plusieurs modèles d'exécution comme les acteurs et les fibers (coroutines). L'approche Async/Await de JavaScript…

Loom introduit deux features principales qui sont les suivantes :

Les Continuations :
Les continuations sont un ensemble de fonctions capables d'être interrompues et stockées sur le tas puis reprises plus tard dans l’exécution du programme.
Les Fibers / Threads virtuels (terme privilégié) :
Les threads virtuels sont similaires aux coroutines de Kotlin ou au fameux Async/Await de JavaScript, à l'exception près que les fibers sont gérées directement par la VM et pas par le compilateur.

Intérêt et cas d'usage

Pourquoi porter son attention sur ce modèle de concurrence ?

Meilleures performances

L'idée derrière les Threads virtuels est juste d'avoir un thread dont la création et le blocage sont peu couteux.

Pour expliquer ça, il faut comprendre deux-trois choses :

java.lang.Thread est un simple wrapper sur des threads machine. Les threads machines sont assez lourds, puisqu'ils nécessitent :

Un support dans un maximum de langages.
D’avoir la possibilité d’arrêter et de reprendre l’exécution d'un calcul, donc de préserver son état (pointeur, données locales).
D’allouer une pile suffisamment grande pour pouvoir convenir à tous les langages, puisqu’un thread machine ne sait pas comment chaque langage gère la mémoire.
Enfin, ils doivent assigner les exécutions aux CPU disponibles.

Les threads virtuels diffèrent d'une manière assez chouette : tout le contrôle des exécutions (interrompre, reprendre un calcul…) est géré par... un objet Java !

Les objets Java sont mieux taillés pour modéliser l’exécution d'un programme Java efficacement.

Un autre avantage niveau performance est que l'on peut choisir soi-même le scheduler le mieux adapté à notre besoin (par défaut, c’est un work-stealing-fork-join-pool).

En gros, la meilleure aisance du runtime Java avec Java par rapport aux threads machine permet de faire baisser le coût du spawning de thread drastiquement.

Simplicité d'écriture de programmes concurrents

Un des problèmes lié au fait d'utiliser des threads machines est que cette pratique permet tout au plus de spawner quelques milliers de threads simultanément actifs, bien loin des besoins réels d'un serveur Web supportant — par exemple — plusieurs millions de connexions concurrentes.

On est alors obligé d'avoir recours à des stratagèmes compliqués, comme le pooling qui consiste à mutualiser plusieurs threads pour effectuer des tâches simultanément. Mais, aucun thread pool ne saurait représenter l'état complet du programme.

L'avantage des threads virtuels est que la JVM peut en spawner… des masses ; plusieurs millions simultanément sans problèmes.

Dès lors, plus besoin d'architectures compliquées. Pour chaque traitement, on spawn un thread virtuel un point, c’est tout.

Prérequis

Openjdk

Vous pouvez trouver une version du projet loom ici

Config OSX + Jenv

Si vous n'utilisez pas déjà Jenv je vous conseille d'aller jeter un oeil ici

Setup d'IntelliJ

Passer le compilateur à Java 15

Passer le SDK a 17 avec un niveau de langage java 15 pour l'ensemble du projet:

Les fibers / Threads virtuels

Prérequis:

Si vous avez déjà fait des algos concurrents en Java alors vous n'avez pas grand-chose d'autre à savoir. Pensez juste que désormais, spawner un thread ne coute pas grand-chose

Exemple

package fr.guihardbastien.boilerplate;

import java.time.Duration;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.locks.ReentrantLock;

public class Main {

    private final ReentrantLock lock = new ReentrantLock();
    private int counter = 0;

    public void syncAdd() {
        lock.lock();
        try {
            counter++;
        } finally {
            lock.unlock();
        }
    }

    public void fibersHelloWorld() throws InterruptedException {
        var a = new ArrayList<Thread>();
        for (int i = 0; i < 1_000_000; i++) {
            var t = Thread.ofVirtual().start(() -> {
                try {
                    Thread.sleep(Duration.ofSeconds(1));
                    this.syncAdd();
                } catch (InterruptedException e) {
                    System.out.println(Thread.currentThread().getName() + "-- Interrupted");
                }
            });
            a.add(t);
        }

        for (var t : a) {
            t.join();
        }
        System.out.println(this.counter);
    }

    public static void main(String[] args) throws InterruptedException {
        var m = new Main();
        m.fibersHelloWorld();
    }
}

Les continuations

Prérequis

Pour rappel les continuations sont des fonctions pouvant être interrompues et stockées sur le tas facilement. Il y a 5 choses à savoir pour espérer utiliser des continuations:

Scope: Une continuation s’exécute dans un scope fourni par la classe ContinuationScope (c'est globalement juste une classe qui contient un champs name)
Runnable: La classe Continuation prend en arguments un scope et un Runnable (type : () → void)
.yield : Yield est la méthode qui permet d'interrompre un continuation.
.run : Run est la méthode qui permet de lancer ou reprendre la continuation.
.isDone : Is Done renvoie un booléen vrai si l’exécution du runnable est terminée.

Example

public class Main {
    public static void continuationHelloWorld() {
        var scope = new ContinuationScope("scope");
        var continuation1 = new Continuation(scope, () -> {
            System.out.println("start 1");
            Continuation.yield(scope);
            System.out.println("middle 1");
            Continuation.yield(scope);
            System.out.println("end 1");
        });
        var continuation2 = new Continuation(scope, () -> {
            System.out.println("start 2");
            Continuation.yield(scope);
            System.out.println("middle 2");
            Continuation.yield(scope);
            System.out.println("end 2");
        });
        var list = List.of(continuation1, continuation2);

        while (!continuation1.isDone()) {
            list.forEach(Continuation::run);
        }
    }
    
    public static void main(String[] args) {
        continuationHelloWorld();
    }
}

Conclusions

En somme les thread virtuels permettent une construction facile de programmes concurrents et sont très performants, notamment au niveau de la mémoire :

☕

JDK 11 occupied a heap of 6.8 GB with a peak use of 4.7 GB
JDK 16 without Virtual Threads occupied a heap of 4.6 GB with a peak use of 3.7 GB
JDK 16 with Virtual Threads occupied a heap of 2.7 GB with a peak use of 2.37 GB

So, using JDK 16 with these light-weight virtual threads resulted in:

only 50% usage of heap memory compared to JDK 11
only 64% usage of heap memory compared to JDK 16 without virtual threads

https://www.jobrunr.io/en/blog/2020-08-17-jobrunr-loom-virtual-threads/

Pour finir, voilà un petit boilerplate pour commencer à jouer avec !

Ressources

Décoder le passe sanitaire

2021-07-22T22:00:00Z

Vous voilà vacciné contre la (le ?) Covid-19 avec 1, 2, voire 3 doses espacées. Pour l'occasion, on vous remet un certificat de vaccination avec un immense QR code à enregistrer dans l'application TousAntiCovid.

Un QR code (et tout système de code barre apparenté) est un moyen de stocker de l’information. Les versions récentes du pass sanitaire sont alignées depuis le 1er juillet 2021 sur son équivalent européen : le Digital Green Certificate (DGC), devenu European Digital Covid Certificate (EUDCC), qui se base justement sur un QR code. Que contient-il ?

Nous allons d'abord voir comment récupérer le contenu du QR code. Puis, nous verrons rapidement ce contenu. Ensuite, nous parlerons de la sécurité mise en place autour du certificat et nous finirons en comparant avec le système existant.

Récupérer le contenu

Pour pouvoir lire le contenu, vous pouvez au choix utiliser une bibliothèque comme ZXing ou allez directement faire une recherche sur "online qr code scanner", pour trouver un scanner qui fonctionne avec votre navigateur et votre webcam (par exemple, https://webqr.com/).

Ce QR code contient un certificat compatible, mais non valide. Vous ne pourrez pas le lire avec l'application TousAntiCovid. En dehors du problème de signature, il indique que Jean Martin (né le 3 février 1970) s'est fait vacciner le 1er juillet 2021 avec le vaccin de Pfizer.

Vous récupérez une chaîne de caractères commençant par HC (pour Health Certificate), un numéro de version (1, 2...), : et succession de caractères.

Le QR code ci-dessus donne la chaîne suivante (les sauts de ligne ont été ajoutés pour des questions de présentation) :

HC1:6BF$RDA-SMAHN-H6SKJPT.-7G2TZ97+S8Y4CXEJW.TFJTXG4DCESYCTSJ2TP$2G*P5Y
IJ6S4HZ6SH9+2QH/56SP.E5BQ95ZM376ZIE7PM1VE.Q6T:H:1NPK9/1AAJ1KK9%OC+G9QJP
NF67J6QW6D9RY466PPXY0E7J7UJQWT.+S1QDC8CI6C6XIO$9KZ56DE/.QC$Q3J62:6LZ6O5
9++9-G9+E93ZM$96PZ6+Q6X46+E54A9NF625F646L+9AKPCPP7ZMN27QW6ZOQ.NE/E2$4JY
/K9:K4F7D*G2SV /KF-KXIN2SV6AL3*I**GYZQVG9YJC/HLIJLKNF8JF1727WLTPL 6KNYM
B26REDFAQOQUX9RGQR.RE1G6*%3PNNPXSAXB*LM.NEMUN50I++VKZ39GTLV75+UJ+0W8J:A
T0F6 WAKWVV7U*V7J:VM30AGRK2

Le contenu de cette chaîne de caractères se base sur des technologies standardisées (ou presque...). En effet, en retirant l'en-tête (HC1:), la chaîne que vous obtenez est une chaîne encodée en Base 45. Base 45 est lié à une future RFC (encore en brouillon actuellement) qui se base sur un ensemble de 45 caractères pour encoder des données binaires. Il faut 3 caractères pour encoder 2 octets.

Il est possible de trouver une bibliothèque Java pour gérer l'encodage Base 45.

"io.github.ehn-digital-green-development" % "base45" % "0.0.3"

Cette bibliothèque est directement développée par l'organisation Github, responsable de la mise en place du système EUDCC : European eHealth Network - Digital Covid Certificate Coordination.

Elle s'utilise ainsi :

val base45Content: String   = qrCodeData.split(":", 2)(1).trim
val binaryData: Array[Byte] = Base45.getDecoder.decode(base45Content)

Les données obtenues sont des données compressées avec ZLIB. Le JDK inclut cette lib.

val inflater = new Inflater()
inflater.setInput(binaryData)
val buffer: Array[Byte] = Array.ofDim[Byte](2048)
val length: Int         = inflater.inflate(buffer)
inflater.end()

val data: Array[Byte] = Array.copyOf(buffer, length)

À ce niveau, nous obtenons une structure de type CBOR. CBOR est un format de donnée binaire qui est un sur-ensemble de JSON sur le plan sémantique et qui permet d'avoir un encodage compact. CBOR est spécifié par la RFC 8949.

La structure CBOR que nous récupérons du QR code répond aux spécifications COSE (RFC 8152 - draft). Cette structure présente 3 champs :

protected : contenant un document CBOR au format binaire et représentant des paramètres.
unprotected : contenant une table représentant des paramètres complémentaires.
Le contenu du message au format binaire

Un dernier champ peut être ajouté afin d'y déposer une signature calculée en fonction des champs précédents.

Il existe différentes bibliothèques gérant le format CBOR, dont une extension de Jackson. Cependant, cette extension ne permet d'avoir qu'une perception limitée à la perception JSON, sans pouvoir explorer la variété de type que propose CBOR. La plupart des projets autour du certificat européen utilisent la bibliothèque CBOR-Java.

Je vous propose d'utiliser ici la bibliothèque ci-dessous, ce qui permettra en plus de vérifier le respect du standard au niveau du certificat européen.

"co.nstant.in" % "cbor" % "0.9"

La récupération du modèle mémoire de la structure s'obtient de la manière suivante :

val healthCertificate: List[DataItems] = CborDecoder.decode(data)

Pour rappel, les étapes pour récupérer de l'information intelligible sont :

Analyse et retrait du préfixe HCn:
Décodage base 45
Décompression ZLIB
Analyse avec un parser CBOR

Dans ces phases, nous n'avons pas eu affaire à du chiffrement. Il n'y a pas de mot de passe ou d'autres systèmes permettant de protéger le contenu. Au contraire, ce contenu est directement accessible à partir de bibliothèques librement accessibles.

Contenu

Il y a trois champs qui vont nous intéresser :

protected qui contient des informations sur l'algorithme utiliser pour la signature et un keyId qui permet de retrouver la clé publique pour vérifier la signature. Nous en parlerons plus loin.
Le contenu qui conserve les informations du certificat.
La signature qui garantit la validité du certificat. Nous en parlerons aussi plus loin.

Le champ unprotected n'est apparemment pas utilisé actuellement.

La partie contenu est équivalente à un document JSON avec 3 niveaux d'imbrication. Le premier niveau donne l'identifiant de l'émetteur du certificat et sa période de validité. De notre exemple précédent, on obtient :

Issuer (field 1):     CNAM
Issued at (field 4):  2021-07-01
Expired at (field 6): 2023-07-01

Un 4e champ accompagne cette structure. Ce champ est annoté -260 et il contient les faits à l'origine du certificat.

Parmi ces informations, il y a tout d'abord la version du schéma de certificat utilisé (clé ver). Nous y trouvons une structure contenant votre nom (clé nam), ainsi que votre nom encodé à la manière de ce que vous pouvez trouver en bas des cartes d'identité ou des passeports. Vous trouvez aussi votre date de naissance (clé dob).

Un dernier champ contient la liste des vaccins (clé v). Avec une capacité maximale théorique de 2953 octets, il est, en effet, possible de stocker plusieurs actes dans un QR code, qu'il s'agisse de tests, de vaccins ou d'infection. À titre indicatif, la structure complète de l'exemple vu ci-dessus fait 300 octets. De ce fait, le QR code EUDCC peut faire office de carnet de vaccination.

Au niveau de chaque acte de "vaccination", nous avons tout d'abord un identifiant unique appelé UVCI (clé ci), qui apparait dans notre structure sous forme d'URN. Nous décrirons cet identifiant plus loin. Nous avons ensuite le pays émetteur (clé co). Pour les vaccins, nous trouvons derrière, le nombre de doses reçues (clé sd), le nombre de doses nécessaires (clé dn), la date de la dernière dose (clé dt), le code du fabricant du vaccin (clé ma) et le code produit administré (clé mp). Pour ces codes, l'ensemble des valeurs sont décrites dans un document accessible. Dans cette structure, nous allons aussi trouver l'agent ciblé (clé tg — c'est la Covid-19), le type d'administration.

Avec notre exemple, nous avons les données suivantes :

ci: urn:uvci:01:FR:AB123Z#8
co: FR
dn: 2
dt: 2021-07-01
is: CNAM
ma: ORG-100030215 (Biontech Manufacturing GmbH)
mp: EU/1/20/1528 (Comirnaty)
sd: 2
tg: 840539006 (COVID-19)
vp: J07BX03 (covid-19 vaccines)

Les données que nous voyons sont certes un exemple avec un faux certificat, mais elles sont proches de ce que vous avez comme certificats (si vous êtes vaccinés) ou de ce que vous aurez (si vous comptez vous faire vacciner). Ces données sont avant tout factuelles et traduisent en partie le manque de connaissance scientifique sur la Covid-19 de par l'absence de date de fin de validité du vaccin. Nous avons seulement une absence de validité du certificat, ce qui est différent.

Unicité de l'information

Nous voyons qu’en utilisant quelques bibliothèques sur le Net, nous pouvons accéder à des informations personnelles du certificat, sachant que ces informations ne sont pas chiffrées. Néanmoins, elles ne sont pas nécessairement suffisantes pour vous identifier : combien de Jean Martin sont nés le même jour dans tous les pays participants au programme DGC ? D’un autre côté, il n’y a probablement pas beaucoup de Côme Batz de Saint-Anmien. Il est nécessaire d'accompagner le certificat d'un document de type CNI ou passeport, par exemple, pour être sûr qu'il n'y a pas usurpation d'identité. Il reste à ce niveau à comprendre ce que vaut l’UVCI vu précédemment.

L'UVCI est un identifiant unique qui correspond à un Unique Vaccination Certificate/Assertion Identifier. L'UVCI n'est pas nécessairement un URN, mais il doit contenir un numéro de version et un code pays émetteur en préfixe, ainsi qu'un checksum en suffixe. Le reste de l'UVCI ainsi que le format peut varier d'un pays à l'autre.

C'est l'UVCI qui assure l'unicité de l'acte de vaccination (ou du test ou de l'infection). Il n'est pas exploitable directement à partir d'un scanner sans connexion. En effet, il ne doit pas contenir de données personnelles. Par contre, il peut agir comme une clé étrangère et permet de retrouver des informations complémentaires sur une autre base de données. On s'attend à ce que cette base soit gérée par un organisme de Sécurité sociale et ne soit pas si facilement accessible (!?).

Sécurité

À ce niveau, nous n’avons pas encore vérifié si le pass est valide. Nous avons accès à certaines informations personnelles, mais nous n’avons pas montré si ces informations sont certifiées (y a-t-il un cachet, un tampon, une signature d’une autorité reconnue ?) et nous ne savons pas si les informations sanitaires sont valides.

Pour cela, il faut s’intéresser au reste de la structure COSE. Dans la partie protected, qui contient le binaire d'une structure CBOR, nous allons trouver deux champs :

1 représentant l'algorithme de chiffrement (ici -7).
4 représentant le kid ou KeyID.

Le kid est un identifiant en base 64 faisant référence à une entrée dans une base de données des organismes délivrant le certificat numérique (organisme administratif de Sécurité sociale, hôpital, centre de test...). Cette base de données contient des informations au format LDAP concernant l'organisme. Elle contient la clé publique de ces organismes. Chaque pays a une copie de cette base de données (une copie est disponible dans le projet sanipasse).

La partie signature de la structure récupérée se base sur algorithme de chiffrement utilisant un système de clé privée / clé publique. La signature est générée à partir du contenu de la structure COSE, de la clé privée de l'organisme faisant autorité et d'un sel "Signature1" (appelé context string). L'algorithme utilisé est ECDSA avec la fonction de hachage SHA-256. La vérification se fait en utilisant la clé publique, le contenu COSE, le sel et la signature. L'algorithme indique si l'ensemble est cohérent. Si la moindre information est changée dans la structure COSE ou dans la signature, la vérification échouera.

Cette approche permet de ne pas communiquer d'information lors d'une vérification. Seule la clé de l'organisme (le kid) est transmis pour récupérer la clé publique. D'ailleurs, il est possible de conserver la base des organismes au sein du système de vérification.

Fiabilité de la signature

Tant que l'algorithme utilisé est considéré comme suffisamment sûr pour signer des documents et vérifier ces signatures, il n'y a pas de faille. Par contre, c'est l'employé qui crée la liaison entre l'acte médical et le certificat. Il a ainsi la possibilité de délivrer certificat sans acte médical s'il le souhaite. Le certificat est alors techniquement valide et passera tous les contrôles, mais il est faux vis-à-vis de la loi. C'est ce qui est arrivé durant le mois de juillet.

⛔

Pour rappel, posséder un faux certificat (tout comme n'importe quel faux documents) est punie par de l'emprisonnement et une amende (Code Pénal, article 441-1 à 441-12), pouvant impliquer des peines complémentaires. La peine est plus lourde dans le cas de son utilisation. Il en va de même pour la personne qui crée un faux certificat.

Systèmes existants

On peut s’intéresser à faire un rapprochement entre l’EUDCC d’un côté et le numéro de Sécurité sociale et le carnet de santé de l’autre.

Le numéro de Sécurité sociale est une invention de René Carmille (par la suite résistant français, mort à Dachau) adoptée par la Sécurité sociale en 1946. Certaines utilisations controversées de ce numéro ont conduit à la création de la loi Informatique et Liberté en 1978, ainsi qu’à la création de la CNIL. Le numéro de Sécurité sociale est un numéro qui permet d’identifier indirectement une personne. Il ne contient ni nom et prénom, ni dossier médical, mais il permet de connaître le sexe d’une personne, sa date de naissance, sa commune de naissance. Il est unique à chaque personne enregistrée au sein de la Sécurité sociale.

Le carnet de santé est créé en 1938 par l’artiste Louise Hervieu. Il est adopté un an plus tard par le gouvernement et est rendu obligatoire en 1945. Son contenu a évolué au cours du temps. Mais il est avant tout personnel et soumis au secret professionnel. Ce carnet contient l’identification de la personne, son numéro de Sécurité sociale, un suivi détaillé de la santé de la personne durant son enfance, ainsi que l’ensemble des vaccins réalisés.

Si votre organisme de Sécurité sociale ne connait pas le contenu de votre carnet de santé, elle voit régulièrement passer vos actes médicaux, afin de vous fournir les remboursements qui vous sont dus. Ainsi que votre mutuelle, si vous en avez une. Ces actes médicaux ne sont pour la plupart pas inscrit dans votre carnet de santé. Ces organismes possèdent même de plus de détails en cas d'arrêt de travail.

Mais en dehors de votre organisme de Sécurité sociale, aucun autre organisme ne possède d'information santé… À part, votre mutuelle, votre smartphone et ce qu'il peut y avoir derrière.

Conclusion

Le passe sanitaire est devenu depuis le 1er juillet 2021 un certificat européen de vaccination ou non-infection, qui pour le moment s'applique à la Covid-19. Il apparaît sous forme de QR code qui se décode en se basant sur des technologies standardisées ou clairement documentées.

Cependant, le certificat contient certaines données personnelles qui sont portées à la connaissance des personnes physiques ou morales en charge de la vérification. Elles ne suffisent pas pour vous identifier complètement, mais elles ont néanmoins un fort potentiel.

Au niveau sécurité, la falsification d'un certificat est très difficile sans avoir la clé privée utilisée par signer le document. Les récents événements ont montré que le manque de loyauté du personnel ayant accès à la clé privée est un risque à prendre en compte dans ce système, même si ce sujet est pris en compte par le législateur.

Il reste que le certificat Covid européen nous met face à un niveau d'échange de données personnelles, en particulier de données de santé, que nous n'avons pas encore connu dans notre société moderne. Les circonstances étant exceptionnelles, il serait alors normal d'accepter ce dispositif.

Il y a un message caché dans le QR code du certificat ci-dessous…

Lien

European eHealth network - Digital Covid Certificate Coordination est une organisation Github qui regroupe l'ensemble des projets autour du certificat Covid européen, afin de proposer aux États membres une plateforme commune sur ce sujet : https://github.com/ehn-dcc-development

Le lien précédent est à compléter avec cette organisation Github autour de l'EUDCC : https://github.com/eu-digital-green-certificates

Le projet sanipasse de Ophir LOJKINE propose un service hébergeable permettant de vérifier des passes sanitaires et autres certificats Covid européens.

Le thread Twitter de @gilbsgilbs ci-dessous permet de compléter les explications de l'article.

Sortie de gâteau pour ZIO 1.0

2021-06-30T22:00:00Z

⚠️

Attention, on est maintenant en ZIO 2.0, la gestion de l’enviRonement dans ZIO[-R, +E, +A] a changé.

Avant la RC-18, on avait une sorte de cake pattern pour gérer R (et donc la composition était complexe)
Avec la RC-18 / ZIO 1.0, on a eu Has qui a permis de composer facilement, sans encodage, le set hétérogène des ressources que l’IO va utiliser (dépendances)
Avec ZIO 2.0, on a un système beaucoup plus à plat pour gérer l’enviRonement, qui est beaucoup plus intégré. Par exemple, si on a besoin d’une DB, et d’une API, on va avoir un ZIO[DB with API, E, A], au lieu de ZIO[Has[DB] with Has[API], E, A].

Parlons un peu de Has et du Zlayer, ZIO approche bientôt la version 1.0, néanmoins beaucoup de choses ont changé entre le RC17 et la RC18.

ZIO c'est le Future

L'objectif principal de ZIO est de fournir l'outil qui permet de faire de la programmation fonctionnelle pleinement.

Une fonction A ⇒ B se doit d'être pure, c'est-à-dire :

être complète
être déterministe
sans effet de bord

Les outils classiques pour résoudre ce genre de problèmes sont :

Either, qui offre une sortie alternative pour être complète, A ⇒ Either[E, B]
State, qui permet de représenter de manipuler qui ont besoin d'un état : (S, A) ⇒ (S, B)
Reader, qui permet de manipuler des fonctions qui ont besoin d'une dépendance : (R, A) ⇒ B (ou A ⇒ R ⇒ B)
IO ou Task, qui permet de marquer une valeur comme étant disponible que si on exécute le programme : A ⇒ IO[B]

Ce qui donne une pile assez classique :

A ⇒ IO[Reader[R, State[S, Either[E, B]]]] !

Sans parler du reste pour faire de la programmation concurrente.

Finalement A ⇒ ZIO[R, E, B] est une réponse moderne, en un seul type, à l'équivalent de A ⇒ Reader[R, IO[Either[E, B]]], mais avec un type et les combinateurs qui vont avec ! Qui est efficace pour représenter les différents cas limites :

B
IO[B]
IO[Either[Throwable, B]]
R => IO[Either[E, B]]
(R, IO[Reader[R, Either[E, B]]]) // Provide
...

Pourquoi intégrer aussi le Reader ? ZIO fournit à la base pour les erreurs dans IO[+E, +B] , au lieu de faire IO[Either[E, B]], cela a permis de mieux gérer les erreurs et l'absence d'erreur. Néanmoins dans les cas d'usage classique, on devait continuer à se trainer des fonctions tout le temps.

L'année dernière ZIO est passé de

def println(line: String): Console => IO[Nothing, Unit]
// Console : Il faut fournir une Console
// Nothing : Il n'y a pas d'erreur attendue
// Unit : Il n'a a pas de valeur de retour attendue

def println(line: String): ZIO[Console, Nothing, Unit]

Comme à l'arrivée du rasoir à 5 lames, on s'est demandés si ZIO n'allait pas ajouter un nouveau type chaque année. Pour l'instant ce n'est pas le cas, néanmoins il y a du changement.

Composition

Pour la composition, ZIO a choisi de rester très proche de ce qui est offert par le design de Scala 2, en se basant sur la covariance et la contravariance. On a un ZIO[-R, +E, +A] qui a même variance qu'une fonction R => Either[E, A].

Pour la composition, on utilise flatMap qui repose sur le mécanisme de variance :

trait ZIO[-R, +E, +A] {
  def flatMap[R1 <: R, E1 >: E, B](k: A => ZIO[R1, E1, B]): ZIO[R1, E1, B]
}

Si on n'avait pas cette variance, on aurait des compositions un peu étranges et besogneuses.

Le error channel

Avec les fonctions :

def get: IO[E1, A]
def set(a: A): IO[E2, Unit]

Si on compose sans utiliser le mécanisme de variance, on obtient :

val prg: IO[E1 Either E2, Unit] = for {
  a <- get
  _ <- set(a)
} yield {}

Plus on compose, plus on va avoir un type complexe sur l'erreur qui va devenir difficilement gérable. Ici on a Either[E1, E2] (que l'on peut écrire E1 Either E2), mais avec plusieurs erreurs obtient des Either[E1, Either[E2, Either[E3, ...]].

La composition sur l'erreur se fait en utilisant la covariance :

trait IO[+E, +A] {
  def flatMap[B, EE >: E](f: A => IO[EE, B]): IO[EE, B]
  //def flatMap[B, E2](f: A => IO[E2, B]): IO[Either[E, E2], B]
}

Dans notre cas, le compilateur Scala va chercher un type EE, qui est un supertype de E1 et de E2.

Lorsque l'on définit les erreurs avec un super type (ici KVSError), le compilateur fait le reste.

sealed abstract class KVSError(msg:String) extends Throwable(msg)

class E1 extends KVSError("e1 error")

class E2 extends KVSError("e2 error")

class E3 extends KVSError("e3 error")


val prg: IO[KVSError, Unit] = for {
  a <- get
  _ <- set(a)
} yield {}

Pour avoir soit E1, soit E2, le compilateur trouve le type juste au-dessus, une solution qui est moins précise que Either[E1, E2], mais beaucoup plus utilisable pour faire de la composition.

def toKVSError(e: Either[E1, E2]): KVSError = e.merge

//Ici on est moins précis, KVSError est un supertype de E3 aussi.
def toEither(e: KVSError): Option[Either[E1, E2]] = {
  e match {
    case e1: E1 => Some(Left(e1))
    case e2: E2 => Some(Right(e2))
    case _      => None
  }
}

R (l'injection de dépendance)

Pour R, il va se passer relativement la même chose. Avec les fonctions suivantes. Sans le R dans ZIO[-R, +E, +A]

type IO[E, A] = ZIO[Any, E, A]
type UIO[A]   = IO[Nothing, A]

def currentTime(unit: TimeUnit): Clock => UIO[Long]
def putStrLn(line: String): Console => UIO[Unit]

def printTime: (Clock, Console) => UIO[Unit] = 
  (clock, console) => for {
    t <- currentTime(TimeUnit.SECONDS)(clock)
    _ <- putStrLn(t + "s")(console)
  } yield {}

ou avec les implicites

type IO[E, A] = ZIO[Any, E, A]
type UIO[A]   = IO[Nothing, A]

def currentTime(unit: TimeUnit)(implicit clock: Clock): UIO[Long]
def putStrLn(line: String)(implicit console: Console): UIO[Unit]

def printTime(implicit clock: Clock, console: Console): UIO[Unit] = 
  for {
    t <- currentTime(TimeUnit.SECONDS)
    _ <- putStrLn(t + "s")
  } yield {}

Avec le nouveau paramètre, on va avoir :

type IO[E, A]   = ZIO[Any, E, A]
type UIO[A]     = IO[Nothing, A]
//URIO est un effet qui dépend de R pour produire sans erreur un A
type URIO[R, A] = ZIO[R, Nothing, A]

def currentTime(unit: TimeUnit): URIO[Clock, Long]
def putStrLn(line: String): URIO[Console, Unit]

def printTime: URIO[Clock with Console, Unit] = 
  for {
    t <- currentTime(TimeUnit.SECONDS)
    _ <- putStrLn(t + "s")
  } yield {}

Pour le channel d'erreur en sortie Either[E1, E2] par EE avec EE >: E1, EE >: E2.
En entrée, on va pouvoir remplacer (R1, R2) par R = Env[R1 with R2] avec R <: R1, R <: R2.

trait Env[+T] {
	//def get[A >: T]:A
	//def add[A](a: A): Env[T with A]
}

object Env {
	//def zero: Env[Any]
}

def toT[R1, R2](r: Env[R1 with R2]): (R1, R2) = ???
def toR[R1, R2](r1: R1, r2: R2): Env[R1 with R2] = ??? // à la main ou macro ...

Le code compose mieux et permet de gérer automatiquement les dépendances que l'on a lors de la composition. A condition que l'on puisse faire la composition :

def toR[R1, R2](r1: R1, r2: R2): R1 with R2

Les dépendances que l'on va pouvoir récupérer au fur à mesure que l'on en a besoin dans ZIO :

Les resources de ZIO

Les ressources qui sont disponibles par défaut dans ZIO sont des re-implémentations des composants de base de la JVM pour que l'on puisse les utiliser en FP, ainsi que les manipuler lors des tests unitaires.

Clock

def currentTime(unit: TimeUnit): URIO[Clock, Long]
def currentDateTime: ZIO[Clock, DateTimeException, OffsetDateTime]
def nanoTime: URIO[Clock, Long]
def sleep(duration: Duration): URIO[Clock, Unit]

Si on prend nanoTime , cela se lit comme un Clock => IO[Long].

Console

On est sur le classique, comment lire et écrire dans la console

def putStr(line: String): URIO[Console, Unit]
def putStrLn(line: String): URIO[Console, Unit]
def getStrLn: ZIO[Console, IOException, String]

avec Clock et Console, on va pouvoir faire des programmes assez classiques :

object Hello {
  import zio._
  import zio.console._
  import zio.clock._

  val prg: ZIO[Console with Clock, Exception, Unit] = for {
    _    <- putStr("Hello, what is your name ? > ")
    name <- getStrLn
    dt   <- currentDateTime
    _    <- putStrLn(s"Hello $name, it is $dt")
  } yield {}

  def main(args: Array[String]): Unit = {
    zio.Runtime.default.unsafeRun(prg)
  }
}

Notre programme est un ZIO[Console with Clock, Exception, Unit] alors que cela utilise avec des effets une fois l'horloge et trois fois la console.

System

def env(variable: String): ZIO[System, SecurityException, Option[String]]
def property(prop: String): ZIO[System, Throwable, Option[String]]
def lineSeparator: URIO[System, String]

Random

def nextBoolean: ZIO[Random, Nothing, Boolean]                  
def nextBytes(length: => Int): ZIO[Random, Nothing, Chunk[Byte]]
def nextDouble: ZIO[Random, Nothing, Double]                    
def nextFloat: ZIO[Random, Nothing, Float]                      
def nextGaussian: ZIO[Random, Nothing, Double]                  
def nextInt(n: => Int): ZIO[Random, Nothing, Int]               
def nextInt: ZIO[Random, Nothing, Int]                          
def nextLong: ZIO[Random, Nothing, Long]                        
def nextLong(n: => Long): ZIO[Random, Nothing, Long]            
def nextPrintableChar: ZIO[Random, Nothing, Char]               
def nextString(length: => Int): ZIO[Random, Nothing, String]    
def shuffle[A](list: => List[A]): ZIO[Random, Nothing, List[A]]

Blocking

Blocking sert à wrapper les effets qui ont besoin d'être mis dans une Thread Pool à part (explication). Par exemple, dans le dernier article à la fin :

def blocking[R <: Blocking, E, A](zio: ZIO[R, E, A]): ZIO[R, E, A]
def effectBlocking[A](effect: => A): ZIO[Blocking, Throwable, A]
def effectBlockingCancelable[A](effect: => A)(cancel: UIO[Unit]): ZIO[Blocking, Throwable, A]
def effectBlockingIO[A](effect: => A): ZIO[Blocking, IOException, A]
def effectBlockingInterrupt[A](effect: => A): ZIO[Blocking, Throwable, A]

(R1, R2) ⇒ R1 with R2

La clé pour rendre le code composable est la contravariance sur R, qui permet de composer différent effet qui dépendent de différents R, sans combiner à la main.

Une fois que l'on a un val prg = IO[Console with Clock, Exception, Unit] il faut lui fournir d'une manière ou d'une autre un Console with Clock

Jusqu'en RC17, ZIO utilisait la Service pattern, ce qui permet de mettre en râteau les différentes parties.

// (Clock, Console) => Clock with Console
def mix(clock_ : Clock, console_ : Console) = new Clock with Console {
  override val clock   = clock_.clock
  override val console = console_.console
}

def main(args: Array[String]): Unit = {
  val providedPrg: ZIO[Any, Exception, Unit] = 
    prg.provide(mix(Clock.Live, Console.Live))
  
  new DefaultRuntime {}.unsafeRun(providedPrg)
}

Chaque service est défini en plusieurs morceaux, ce qui le rend utilisable et injectable.

trait Clock {
  val clock: Clock.Service[Any]
}

object Clock extends Serializable {

  trait Service[R] {
    def currentTime(unit: TimeUnit): ZIO[R, Nothing, Long]
    def currentDateTime: ZIO[R, Nothing, OffsetDateTime]
    val nanoTime: ZIO[R, Nothing, Long]
    def sleep(duration: Duration): ZIO[R, Nothing, Unit]
  }

  trait Live extends Clock {
    val clock: Clock.Service[Any] = 
      /**
       * ... Implementation
       */
  }

  object Live extends Live
}

package object clock extends Clock.Service[Clock] {
  /**
   * ...
   */
}

Cela a été remis à plat avec la RC18.

Has et ZLayer

Le gros changement depuis la RC18, c'est la refonte de la gestion de R. En tant qu'utilisateur la code de base ne va pas beaucoup changer, on va voir que la composition est meilleure quand on veut fournir les ressources :

val providedPrg: Task[Unit] = prg.provideLayer(Clock.live ++ Console.live)

//prg.provideSomeLayer(Clock.live).provideLayer(Console.live)

zio.Runtime.default.unsafeRun(providedPrg)

On va même pouvoir fournir pas à pas :

//val prg: ZIO[Console with Clock, Exception, Unit]
val prgWithClock: RIO[Console, Unit] = prg.provideSomeLayer(Clock.live)
val providedPrg: Task[Unit] = prgWithClock.provideLayer(Console.live)


zio.Runtime.default.unsafeRun(providedPrg)

Le gain de composition vient de l'introduction d'un mécanisme de "Tagging" qui permet de composer facilement des types hétérogènes qui représente le set dépendance nécessaire pour exécuter l'effet. Ce mécanisme c'est le Has.

Has, le HSet sans les Shapelesseries

Has[_] stocke une Map[TagType, Scala.Any] :

final class Has[A] private (private val map: Map[TagType, scala.Any]) {
  def size: Int = map.size
	
  override def equals(that: Any): Boolean = that match {
    case that: Has[_] => map == that.map
  }
  
  override def hashCode: Int = map.hashCode

  override def toString: String = map.mkString("Map(", ",\n", ")")
}

Ce qui permet de l'utiliser comme une map hétérogène strictement typée avec la méthode get :

import zio.Has

val h1: Has[String] = Has("A")
val h2: Has[Int] = Has(1)

type H3 = Has[String] with Has[Int]

val h3: H3 = h1 ++ h2
/*Map(      String    -> A,
               Int    -> 1)

   */

assert(h3.get[Int] == 1)
assert(h3.get[String] == "A")

//Has.HasSyntax(h3).get[String](evidence,tag) == "A"

type H4 = H3 with Has[Option[Int]] with Has[Option[String]]

val h4: H4 = h3 add Option(2) add Option("B")

/*Map(      String    -> A,
               Int    -> 1,
      Option[+Int]    -> Some(2),
      Option[+String] -> Some(B))
   */

assert(h4.get[Option[Int]]    == Option(2))
assert(h4.get[Option[String]] == Option("B"))

On peut même utiliser des "kinds" comme Option, ce qui pourrait permettre d'utiliser Has dans des contextes où l'on modélise l'accès les accès aux données.

type Domain = Has[Repo[Account]] with Has[Repo[Transaction]]

La structure est aussi covariante :

sealed trait A
case object B extends A

val b = Has(B)

assert(b.get[A] == B)

Néanmoins cela peut devenir non-déterministe sur le résultat

case object C extends A
val bc = b add C

bc.get[A]
//res1: A = B
bc.get[B.type]
//res2: B.type = B
bc.get[C.type]
//res3: C.type = C

Et cela contient un cache, pour éviter de casser les perfs lors des recherches de la bonne valeur.

Donc Has est un Set, avec les super pouvoir du type system de Scala et une garantie que Has est non vide.

import zio.Has

val set = Set(1, "A")
set.size // 2

val has = Has.allOf(1, "A")
has.size // 2

set.exists(_.isInstanceOf[Int]) // true
has.isInstanceOf[Has[Int]] // true

set.collectFirst({ case i: Int => i }) // Option(1)
has.get[Int] // 1

set.collectFirst({ case i: Long => i }) // None
has.get[Long] // DON'T COMPILE
//Cannot prove that zio.Has[Int] with zio.Has[String] <:< zio.Has[_ <: Long]

Has est donc un cas solide pour faire le mix-in, à condition de l'utiliser en premier paramètre de ZIO.

def toR[R1 <: Has[_], R2 <: Has[_]](r1: R1, r2: R2): R1 with R2 = r1 ++ r2

Revenons à la gestion du R

Aussi la définition d'une dépendance est beaucoup plus propre. On va avoir l'object qui tient le tag Has , le trait pour le Service, l'implémentation et quelques méthodes pour faciliter l'expérience utilisateur comme : Clock.live, ou les méthodes dans clock qui retournent des ZIO[Clock, E, A].

package object clock {

  type Clock = Has[Clock.Service]

  object Clock {
    trait Service {
      def currentTime(unit: TimeUnit): UIO[Long]
      def currentDateTime: IO[DateTimeException, OffsetDateTime]
      def nanoTime: UIO[Long]
      def sleep(duration: Duration): UIO[Unit]
    }

    object Service {
      val live: Service = new Service {
        /**
         *
         */
      }
    }
    
    val live: Layer[Nothing, Clock] = ZLayer.succeed(Service.live)
  }
  

  def currentTime(unit: => TimeUnit): ZIO[Clock, Nothing, Long] =
    ZIO.accessM(_.get.currentTime(unit))
}

On peut injecter les ressources mieux qu'avant, vu que le mix in est inclus avec Has

val providedPrg: Task[Unit] = prg.provideLayer(Clock.live ++ Console.live)

zio.Runtime.default.unsafeRun(providedPrg)

Aussi pas à pas

val prgWithClock: ZIO[Console, Exception, Unit] = prg
  .provideSome[Console](x => x ++ Has(Clock.Service.live))

val providedPrg: IO[Exception, Unit] =
  prgWithClock.provide(Has(Console.Service.live))

zio.Runtime.default.unsafeRun(providedPrg)

Grâce à la magic de Has ! Problème résolu donc, ZIO[R, E, A] est :

facilement utilisable, pas de "boilerplate"
facilement extensible, on peut utiliser nos propres ressources, en dehors de Random, Console, Clock, System et Blocking.

Néanmoins ZIO est allé beaucoup loin que Has, et propose une solution pour résoudre le problème de la construction des dépendances.

Le ZLayer, c'est la fin du printemps

Le ZLayer est l'injection de ressources pour ZIO, les ressources sont disponibles à l'usage et libérées dès que l'on en a plus besoin.

Pour rentrer dans les détails du fonctionnement du ZLayer, il faut d'abord aller voir un autre type, le ZManaged.

Le ZManaged

Le ZManaged est un type spécifique de ZIO qui permet l'acquisition des ressources de manière composable.
En Java ou en impératif, nous allons utiliser soit un try/catch/finally ou une syntaxe dédiée pour faire cela.

import java.io.FileNotFoundException;
import java.io.PrintWriter;

public class PrintHelloFromJava {
    
    public static void main(String[] args) throws FileNotFoundException {

        try(PrintWriter obj = new PrintWriter("log.txt")) {
            obj.println("Hello from Java!");
        }

        System.exit(0);
    }
}

ou avec try finally

        PrintWriter obj = new PrintWriter("log.txt");
        try {
            obj.println("Hello from Java!");
        } finally {
            obj.close();
        }

Avec ZIO on va pouvoir utiliser l'abstraction sur les effets pour faire la même chose avec les fonctions suivantes :


//1. la structure
def makeExit[R, E, A](acquire: ZIO[R, E, A])
                     (release: (A, Exit[Any, Any]) => ZIO[R, Nothing, Any]
  ): ZManaged[R, E, A] = //???


//2. avec un helper pour ne pas gérer l'exit
def make[R, E, A](acquire: ZIO[R, E, A])
                 (release: A => ZIO[R, Nothing, Any]
  ): ZManaged[R, E, A] = //makeExit(acquire)((a, _) => release(a))


//3. depuis l'interfaçe AutoCloseable de Java
def fromAutoCloseable[R, E, A <: AutoCloseable](fa: ZIO[R, E, A]
  ): ZManaged[R, E, A] = //make(fa)(a => UIO(a.close()))

L' Exit est un type algébrique qui représente un Either[Cause[E], A] (spécialisé):

case class Success[+A](value: A)   extends Exit[Nothing, A]
class Failure[+E](cause: Cause[E]) extends Exit[E, Nothing]

La Cause est un autre type algébrique (généralisé et récursif) qui représente la sortie d'une exécution sinistre :

case object Empty extends Cause[Nothing]
case class Both[+E](left: Cause[E], right: Cause[E]) extends Cause[E]
case class Die(value: Throwable) extends Cause[Nothing]
case class Fail[+E](value: E) extends Cause[E]
case class Interrupt(fiberId: Fiber.Id) extends Cause[Nothing]
case class Meta[+E](cause: Cause[E], data: Data) extends Cause[E]
case class Then[+E](left: Cause[E], right: Cause[E]) extends Cause[E]
case class Traced[+E](cause: Cause[E], trace: ZTrace) extends Cause[E]

Cause permet de gérer les cas d'erreur par exception, erreur en contexte d'exécution parallèle, le suivit de la stack dans un contexte d'exécution concurrente.

Donc dans le ZManaged, on va :

indiquer comment on va acquérir une "ressource" A avec ZIO[R, E, A]
Donner la commande que l'on doit exécuter à la fin de l'utilisation de la ressource

Exemple avec le fichier :

object HelloFromScala extends zio.App {

  //ZIO[zio.ZEnv, Nothing, ExitCode]
  override def run(args: List[String]) = prg.useNow.orDie.exitCode

  //ZManaged[Any, Throwable, Unit]
  lazy val prg = printer.mapEffect(obj => obj.println("Hello From ZIO!"))
  
	
  //ZManaged[Any, Throwable, PrintWriter]
  lazy val printer = ZManaged.fromAutoCloseable(ZIO(new PrintWriter("log.txt")))
}

Conclusion

ZIO a revu complètement la façon de composer R et de gérer les ressources pour sortir une version 1.0 avec une ergonomie intéressante.

On a pu voir, avec quelques exemples, comment gérer R, et la capture des ressources.

Emit-on-change avec Kafka Streams

2021-06-15T22:00:00Z

Imaginez : vous constituez une topologie pour votre service Kafka Streams. Pour éviter de surcharger un consommateur (parce qu'il est un peu lent) ou de surcharger Kafka (parce que son cluster n'a pas la dimension qui convient), sachant que vous avez des messages qui se ressemblent d'un point de vue métier, vous ne souhaitez émettre des messages en sortie que lorsqu'il y a une véritable modification dans les données.

Pour cela, d'un point de vue code, on pourrait bénéficier d'une méthode withEmitOnChange.

val builder = new StreamsBuilder()

builder.stream(inputStream)
  .withEmitOnChange
  .to(outputStream)

Cette fonctionnalité a été imaginée dans Kafka Streams et est référencée dans le document KIP-557: Add emit on change support for Kafka Streams. La solution proposée se base par contre sur une comparaison binaire des données sérialisées pour détecter les modifications.

La fonctionnalité a été livrée dans la version 2.6 de Kafka Streams... Puis a été retirée, parce que des pertes de données ont été constatées. Le Confluence du projet Kafka sur la partie Adopted de la page Kafka Streams indique :

KIP-557: Add emit on change support for Kafka Streams (partially implemented in v2.6 reverted again in 2.8.0, 2.7.1, and 2.6.2 due to potential data loss)

Mais, commençons avec un exemple.

Gestion de stock magasin

Je gère un magasin et dans ce magasin, je gère le stock des produits que je vends sur mon site e-commerce.

Je peux représenter mon stock produit sous la forme d'une case class.

case class ProductKey(storeId: String, id: String)
case class Stock(productId: ProductKey, quantity: Double)

J'ai besoin d'un endpoint qui m'indique si un produit est disponible ou non. Voici la représentation de l'information.

case class ProductAvailability(productId: ProductKey, isAvailable: Boolean)

Ici, le champ isAvailable est true que lorsque le stock strictement positif.

Nous avons donc là un flux de type KStream[ProductKey, ProductAvailability], en supposant que la structure ProductKey sert ici de clé dans le flux.

Donc, un nouveau produit avec un stock à 10.0 donnera une disponibilité à true et j'ai message qui est créé et qui est envoyé en direction de mon endpoint. Si le stock de ce produit passe à 5.0, la disponibilité reste à true, mais je produis néanmoins un nouveau message pour le endpoint. Si le stock passe à 0.0, alors la disponibilité passe à false et je produis encore une fois un nouveau message. Ici, seule le deuxième message n'est pas utile.

Ce que nous devrions avoir, c'est ce diagramme :

Le but est de n'émettre un message que lorsque la disponibilité passe de oui à non ou de non à oui.

Peut-on contourner l'absence de sémantique emit-on-change ?

Kafka Streams propose deux stratégies d'émission de message :

emit-on-update
emit-on-window-close

emit-on-update est une stratégie qui va se traduire par une émission de message pour tout message reçu. On a donc une relation 1..1 entre les données entrantes et les données sortantes.

emit-on-window-close est une stratégie qui consiste à rassembler un ensemble de messages sur des fenêtres de temps et de les agréger pour produire un message en sortie. On a ici une relation *..1 entre les données entrantes et les données sortantes.

La stratégie emit-on-window-close pourrait être utilisée pour mettre en place une stratégie se rapprochant (mais de loin) de la stratégie emit-on-change, en émettant seulement le dernier message de chaque fenêtre (pour des fenêtres fixes), si la véritable problématique provient d'un consommateur trop lent. Il faudra alors trouver une taille de fenêtre adéquate permettant de ne pas trop envoyer de message et en même temps ne pas perdre trop d'information.

Mais peut-on faire mieux ?

L'idée de base de la stratégie emit-on-change est de n'émettre un message que si on observe une modification dans les données en entrée.

Puisque la stratégie emit-on-window-close ne permet pas vraiment d'approcher de la stratégie emit-on-change, nous allons partir de la stratégie emit-on-update.

Nous aurons aussi besoin d'un outil de comparaison permettant de détecter un changement dans la donnée. Il nous faut aussi un stockage pour conserver la dernière version de la donnée, qui servira comme base pour la comparaison avec la donnée arrivant en entrée.

Pour créer notre stockage, nous allons pouvoir nous baser sur un KTable qui sera créé à partir d'un KStream fournit en entrée. Pour cela, nous allons nous baser sur .groupByKey, puis nous avons le choix entre reduce et aggregate. Cependant, reduce ne permet pas de faire la distinction entre ce qui provient du stream entrant et les données qui proviennent du stockage dans la fonction qu'on lui passe en paramètre. Ce qui n'est pas le cas de l'opération aggregate. Nous allons nous baser sur cette opération pour générer un KTable.

À chaque message qui arrive au niveau d'aggregate, un message en sort, du fait de la sémantique emit-on-update. Pour changer de sémantique, nous allons utiliser un filtrage qui permettra d'avoir une sémantique emit-on-change. Mais pour ça, nous devons ajouter une information, un flag qui indiquera si le message doit être émis ou non.

OK, on va revenir à notre exemple de stock disponible, pour pouvoir mieux concevoir tout ça.

Emit-on-change sans emit-on-change

Si nous gardons notre structure ProductAvailability tel que, il n'y a rien qui permettra au filtre de déterminer s'il faut émettre ou non le message. Pour cela il faudrait ajouter un flag qui sera positionné au sein de l'opération aggregate, qui représente le seul endroit dans la topologie, où il est possible de constater une variation de valeur.

case class ProductAvailabilityState(
  state: ProductAvailability,
  shouldEmit: Boolean
)

Nous avons besoin ici d'une valeur empty, car aggregate a besoin d'une valeur initiale.

Les règles prises en compte par la fonction passé en paramètre d'aggregate sont :

val changeLogic:(ProductAvailability, ProductAvailabilityState) => ProductAvailabilityState = {
  case (availability, null) =>
    ProductAvailabilityState(availability, true)

  case (availability, ProductAvailabilityState(storedValue, _))
      if availability == storedValue => // <-- the comparison is here
    ProductAvailabilityState(availability, false)

  case (availability, ProductAvailabilityState(_, _)) =>
    ProductAvailabilityState(availability, true)
}

Ici, pour la comparaison, on utilise l'égalité de Scala (comparaison récursive champ par champ).

En sorti d'aggregate, nous avons une KTable[ProductKey, ProductAvailabilityState] que nous pouvons passer au filtre. Ce filtre va simplement vérifier que le flag shouldEmit de notre structure est à true. Après quoi, avec un mapValues, on récupère le champ state. Ce qui nous donne en sortie un flux de type KStream[ProductKey, ProductAvailability] avec une sémantique emit-on-change.

Voici le code correspondant pour la topologie.

availabilityStream
  .groupByKey
  .aggregate(null: ProductAvailabilityState) {
    case (availability, null) =>
      ProductAvailabilityState(availability, true)

    case (availability, ProductAvailabilityState(storedValue, _))
        if availability == storedValue =>
      ProductAvailabilityState(availability, false)

    case (availability, ProductAvailabilityState(_, _)) =>
      ProductAvailabilityState(availability, true)
  }
  .filter(_.shouldEmit)   // apply emit-on-change semantic
  .mapValues(_.state.get) // due to filter we are sure to have an instance of Some

Ce qui forme la topologie suivante :

Cette topologie met en œuvre le workflow ci-dessous.

Généralisons

Il est possible de généraliser ce que nous venons de voir à n'importe quel type d'entité utilisée dans vos topologies Kafka Streams.

case class State[A: Equiv](data: A, shouldEmit: Boolean) {
  def changeBasedOn(newData: A): State[A] =
    State(newData, shouldEmit = !Equiv[A].equiv(data, newData))
}

La contrainte Equiv (provenant du package scala.math), implique d'apporter pour le type A un prédicat permettant de vérifier l'équivalence entre deux éléments du type A.

On peut aussi ajouter aux KStream une opération indiquant explicitement que vous passez en sémantique emit-on-change. Il faudra néanmoins fournir une serde pour les entités de type State[A]. Pour on peut utiliser les méthodes d'extension de Scala.

implicit class KStreamEmitOnChange[K, V: Equiv](ks: KStream[K, V]) {
  def withEmitOnChange(implicit
        keySerde: Serde[K],
        serde: Serde[V],
        stateSerde: Serde[State[V]]): KStream[K, V] =
    ks
      .groupByKey(Grouped.`with`(keySerde, serde))
      .aggregate(null: State[V]) {
        case (_, data, null) => State(data, shouldEmit = true)
        case (_, data, state) => state.changeBasedOn(data)
      }(
        Materialized.`with`(keySerde, stateSerde)
      )
      .toStream
      .filter { case (_, state) => state.shouldEmit }
      .mapValues(_.data.get)
  }

Ce qui dans notre exemple donnerait

implicit val stateSerde: Serde[ProductAvailability] = ???

val builder = new StreamsBuilder()

builder.stream(inputStream)
  .withEmitOnChange
  .to(outputStream)

Parlons performance et volume

La sémantique emit-on-change présentée ici implique de stocker des données dans un state store local au service Kafka Streams exécuté. Ce volume est relatif à la taille de la structure gérée (dans notre exemple, il s'agit de ProductAvailability) à laquelle il faut ajouter la taille utilisée pour le flag (selon le format de sérialisation, c'est soit une chaîne de caractères de taille 4 (true) ou 5 (false), soit un entier sur un octet (8 bit), soit un bit). Cette valeur est à multiplier par le nombre de clé possible.

Si nous reprenons notre exemple avec un format de sérialisation Avro (sans ajout d'en-tête), en supposant que les produits et les magasins sont encodés sur 5 caractères, nous avons donc 13 octets par instance de ProductAvailability (productId et storeId font 2 * (5 octets + 1 octet pour la taille) et le flag fait 1 octet). Si nous avons 5 magasins et 1000 produits par magasin, il faudra prévoir un espace de 65 Ko juste pour la partie data, sachant, qu'il faut ajouter l'ensemble des métadonnées gérées par la couche de persistance RocksDB et plus si vous faites de la réplication.

A priori, dans notre code, nous n'introduisons pas de changement de clé. Il n'y aura pas d'échange de données si vous multipliez les instances de votre service Kafka Streams. Donc la solution devrait scaler. L'exception à cette règle est lorsque withEmitOnChange est précédée d'une opération lazy dans laquelle un changement de clé effectué, ce que permet par exemple .map. Dans ce cas, l'opération .groupByKey va exécuter un re-partitionnement des données. J'écris cependant au conditionnel ici, car je me fis à la documentation Kafka Streams et à l'expérience que j'ai sur les opérations Kafka Streams que j'utilise dans le code. Mais je n'ai actuellement pas de retour suffisamment parlant pour la solution emit-on-change présentée dans cet article.

Conclusion

Nous avons vu dans cet article que la sémantique emit-on-change apporte un moyen de ne pas surcharger Kafka dans de consommateur trop lent ou d'un cluster sous-dimensionné. Il y a une volonté chez les contributeurs Kafka Streams de mettre en place une sémantique emit-on-change, mais cette fonctionnalité rencontre des problèmes de perte de données et est donc retirée.

Nous proposons ainsi une solution intégrant une sémantique emit-on-change qui se base sur les opérations du DSL Kafka Streams. Cette solution est assez simple et n'entraverait pas la scalabilité de l'application.

Il est intéressant de voir qu'avec Kafka Streams il est possible d'ajouter des fonctionnalités au framework en se basant sur son propre DSL. Il est ainsi possible d'imaginer et de cataloguer des patterns de topologie pour faciliter la mise en place sémantiques qui ne sont pas directement couverts par Kafka Streams.

Une proposition alternative est présentée dans cette réponse dans Stack Overflow.

JAVA 16: Premier contact avec l'API de vectorisation

2021-06-14T22:00:00Z

Introduction

Java 16 viens d'être annoncé par Oracle avec un certain nombre de nouveautés intéressantes à voir en détail ici. L'une d'entre elles est la possibilité d'écrire des opérations qui utilisent la pleine puissance des processeurs vectoriels.

On va regarder ensemble rapidement ce qu'il en est et comment utiliser cette API.

Intérêt et cas d'usage

Quand on parle de vectorisation, on parle effectivement de parallélisme, mais pas n'importe lequel. En effet, on pourrait paralléliser un calcul sur plusieurs machines. On parlerait alors d'une architecture en cluster. On pourrait paralléliser un calcul sur plusieurs cœurs d'un même processeur. On parlerait alors de parallélisation inter-coeur.

Dans notre cas, on va chercher à effectuer une parallélisation intra-coeur, c'est-à-dire qu'on va paralléliser un calcul au sein d'un seul cœur à l'aide d'instructions particulières.

On est alors en mesure de se poser la question suivante : "Pourquoi diable voudrait-on s'infliger ça" ?

Les unités de calcul vectoriel sont très présentes dans les GPU, mais on en trouve aussi dans la plupart des processeurs grand public. Avant ça, son usage était réservé aux supercalculateurs (ie. la grande époque des Cray).

L’intérêt du calcul vectoriel est qu'il permet de réduire le nombre de chargements d'instructions. En effet, avec une approche traditionnelle, l'augmentation du nombre de cycles par instruction accélère l'horloge du CPU. Utiliser une approche vectorielle garantie des performances intéressantes comme nous le verrons plus tard dans cet article.

L'optimisation vectorielle permet alors aux processeurs de consommer moins d’électricité et par effet, de prendre plus soin de la planète💡🌎.

Cas d'usage

Typiquement, on peut utiliser la vectorisation pour toutes les opérations faites sur un tableau d’élément.

Prenons l'exemple du calcul de la distance euclidienne entre deux points.

On pourrait modéliser ce problème sous forme de calcul vectoriel comme suit :

Pensons deux vecteurs A et B avec :

\to A = X a, Y a, Z a \to B = X b, Y b, Z b

lane 0	lane 1	lane 2	nbr opérations
$X a$	$Y a$	$Z a$
$-$	$-$	$-$	$1$
$X b$	$Y b$	$Z b$
$*$	$*$	$*$	$2$
reduce lanes (ADD)	$Y b$	$Z b$	$3$
$\sqrt$			$4$

On remarque que si le nombre de dimensions de notre vecteur augmente - dans une certaine mesure - le nombre d'operations de notre calcul ne change pas.

Prérequis

IDE

Pour pouvoir utiliser un IDE avec Java 16, il vous faudra certainement le mettre à jour :

IntelliJ:

Il vous faudra une version supérieure ou égale à 2021.1.1

Eclipse:

Il vous faudra une version supérieure ou égale à 4.20M1

Installer Java 16

Le JDK 16 est disponible sur le site officiel d'oracle vous pouvez le trouver ici

Distributions linux :

sudo dnf install java-latest-openjdk.x86_64

OSX :

Installation manuelle :

# extract your JDK here
cd /Library/Java/JavaVirtualMachines/
# Change your JAVA_HOME to /Library/Java/JavaVirtualMachines/jdk-16.jdk/Contents/Home

Si vous n'utilisez pas déjà Jenv :

# installez jenv : https://www.jenv.be/
jenv add /System/Library/Java/JavaVirtualMachines/jdk-16.jdk/Contents/Home
jenv global 16

Configuration d'IntelliJ

Pour les flemmards :

Je vous ai préparé un projet maven out of the box à lancer dans votre IDE ici

Au passage voici un petit tips de productivité : vous pouvez lancer vos projets dans IntelliJ directement depuis le terminal en ajoutant un petit alias a votre .zshrc comme ceci

# open current dir in intelliJ
 alias intellijize="open -na 'IntelliJ IDEA CE.app' --args './'"

Config manuelle

pom.xml:

dependencies :

<dependencies>
<!--Unit testing-->
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter-api</artifactId>
      <version>5.7.1</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter-params</artifactId>
      <version>5.7.1</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter-engine</artifactId>
      <version>5.7.1</version>
      <scope>test</scope>
    </dependency>
<!--Benchmarking tools for perf review-->
    <dependency>
      <groupId>org.openjdk.jmh</groupId>
      <artifactId>jmh-core</artifactId>
      <version>1.28</version>
    </dependency>
    <dependency>
      <groupId>org.openjdk.jmh</groupId>
      <artifactId>jmh-generator-annprocess</artifactId>
      <version>1.28</version>
      <scope>provided</scope>
    </dependency>
  </dependencies>

Build:

<build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.1</version>
                <configuration>
                    <release>16</release>
                    <compilerArgs>
                        <compilerArg>--add-modules</compilerArg>
                        <compilerArg>jdk.incubator.vector</compilerArg>
                    </compilerArgs>
                    <annotationProcessorPaths>
                        <path>
                            <groupId>org.openjdk.jmh</groupId>
                            <artifactId>jmh-generator-annprocess</artifactId>
                            <version>1.27</version>
                        </path>
                    </annotationProcessorPaths>
                </configuration>
            </plugin>

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>3.0.0-M5</version>
                <configuration>
                    <argLine>--add-modules jdk.incubator.vector</argLine>
                </configuration>
            </plugin>

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-shade-plugin</artifactId>
                <version>3.2.4</version>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>shade</goal>
                        </goals>
                        <configuration>
                            <finalName>benchmarks</finalName>
                            <transformers>
                                <transformer
                                        implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                                    <mainClass>org.openjdk.jmh.Main</mainClass>
                                </transformer>
                            </transformers>
                            <filters>
                                <filter>
                                    <artifact>*:*</artifact>
                                    <excludes>
                                        <exclude>**/module-info.class</exclude>
                                        <exclude>META-INF/MANIFEST.MF</exclude>
                                    </excludes>
                                </filter>
                            </filters>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

config intellij:

Vérifiez que les dépendences de Modules sont bien en java 16

Un coup d’œil aux CPU "modernes"

L'apparition d'instructions SIMD (lire : Single instruction, Multiple Data) sur les processeurs grand public date des années 90 avec l’extension MMX sur Intel Pentium. On parle plus généralement de processeurs vectoriels.

La page Wikipédia des processeurs vectoriels est très exhaustive. Je vous suggère de la consulter. Pour aller plus loin vous pouvez aussi consulter ce lien et celui ci

Registres & Lanes

Les registres vectorisés ont une taille supérieur aux registres normaux. Sur les CPU Intel on trouve des registres spécialisés (xmm0, ymm0, zmm0.. cf : https://fr.wikipedia.org/wiki/Advanced_Vector_Extensions) qui effectuent une même opération sur plusieurs lanes

Une opération SIMD indique l'opération, la taille d'une lane et la taille des registres.

Pour l'exemple précédent on a : PADDW xmm0, xmm2, xmm3

avec

Préfixe

P pour 128 bits

VEX VP pour 256 bits

EVEX VP pour 512 bits

Opération

ADD pour l’opération

Taille d’une ligne

B (byte) = 8 bits

W (word) = 32bits

D (double) = 64bits

Q (quad) = 128bits

Les éléments principaux de l'API

Pour lancer une classe avec les bons modules :

java --add-modules jdk.incubator.vector fr.guihardbastien.boilerplate.Main

Premiers pas

Pour étudier les éléments important de l'API prenons des exemples simple:

package com.univalence.boilerplate;

import jdk.incubator.vector.IntVector;
import jdk.incubator.vector.VectorSpecies;

public class Main {
    public static void main(String[] args) {
        VectorSpecies<Integer> species = IntVector.SPECIES_PREFERRED;
        IntVector v1 = IntVector.broadcast(species, 20);
        IntVector v2 = IntVector.broadcast(species, 22);
        IntVector v3 = v1.add(v2);
        for (var i = 0; i < v3.length(); i++) {
            System.out.println(v3.lane(i));
        }
    }
}

VectorSpecies

Un VectorSpecies indique un type (en l’occurrence Integer) et une shape (taille en bits).

On peut faire référence à IntVector.SPECIES_[64|128|256|512] pour obtenir la shape.

Ici on fait référence a SPECIES_PREFERRED pour - d'après la doc - :

☕

make the code dynamically adapt to optimal shape for the platform on which it runs

IntVector v1 = IntVector.broadcast(species, 20);

C'est ici qu'on "rempli" nos lanes décrites par le VectorSpecies avec la valeur 20.

Opération

On effectue une addition des deux registres vectorisés : IntVector v3 = v1.add(v2);

Sortie

Sur ma machine on peut voir la sortie suivante :

WARNING: Using incubator modules: jdk.incubator.vector
42
42
42
42
42
42
42
42

Les huit affichages nous indiquent que mes registres vectorisés mesurent 256 bits (on additionne 8 int encodés sur 32 bits simultanément)

Deuxième exemple

public class Main {
    public static void main(String[] args) {
        VectorSpecies<Integer> species = IntVector.SPECIES_PREFERRED;
        var arr = new int[]{0, 1, 2, 3, 4, 5, 6, 7};
        var b = new int[8];

        IntVector vectorizedArray = IntVector.fromArray(species, arr, 0);
        IntVector conditionVector = IntVector.broadcast(species, 6);
        IntVector addTermVector = IntVector.broadcast(species, 10);
        VectorMask<Integer> mask =  vectorizedArray.lt(conditionVector); // lt -> lower than

        // on ajoute 10 respectivement au mask
	IntVector vb = vectorizedArray.add(addTermVector, mask);
        vb.intoArray(b, 0);
        System.out.println(Arrays.toString(b));

    }
}

/* output

WARNING: Using incubator modules: jdk.incubator.vector
[10, 11, 12, 13, 14, 15, 6, 7]

*/

Concrètement ici, on effectue une condition relative a un vecteur en créant un masque. En gros, on fait un if vectorisé. Dans notre exemple le masque ressemble à ça : TTTTTTFF.

Pour toutes les lanes qui sont true sur le masque, on leur ajoute 10.

Post-loop & Mask

Pour l'exemple suivant, l'idée est de manipuler un array de manière vectorisée et du finir avec un reduce directement sur les vecteurs.

L'explication du code est faite directement en commentaire.

private static final VectorSpecies<Integer> SPECIES = IntVector.SPECIES_PREFERRED;

    public static int sum(int[] array) {
        var length = array.length;

	// loopBound permet de savoir jusqu'ou on peut vectoriser l'array
	// On se servira plus tard d'une "post-loop" pour finir le travail
        var loopBound = length - length % SPECIES.length();

	// la methode .zero est equivalente à 
	// IntVector.broadcast(species, 0);
        var v0 = IntVector.zero(SPECIES);
        var i = 0;
        for (; i < loopBound; i += SPECIES.length()) {
	    // chunk vector of array
            var v = IntVector.fromArray(SPECIES, array, i);
	    // on additionne le contenu des lanes entre eux
            v0 = v0.add(v);
        }
	// ici on on additionne les lanes entres elles
        int sum = v0.reduceLanes(VectorOperators.ADD);

	// La post-loop qui nous permet de finir le traitement complet de l'array
        for (; i < length; i++) {
            sum += array[i];
        }
        return sum;
    }

Voici un équivalent avec un masque :

public static int sumMask(int[] array) {
        var length = array.length;
        var loopBound = length - length % SPECIES.length();
        var v0 = IntVector.zero(SPECIES);
        var i = 0;
        for (; i < loopBound; i += SPECIES.length()) {
            var v = IntVector.fromArray(SPECIES, array, i);
            v0 = v0.add(v);
        }
        int sum = v0.reduceLanes(VectorOperators.ADD);

        var mask = SPECIES.indexInRange(i, length);
        var vMask = IntVector.fromArray(SPECIES, array, i, mask);
        int sumMask = vMask.reduceLanes(VectorOperators.ADD);

        return sum + sumMask;
    }

Test avec benchmark

Classe VectorComputation

import jdk.incubator.vector.IntVector;
import jdk.incubator.vector.VectorOperators;
import jdk.incubator.vector.VectorSpecies;

public class VectorComputation {
    private static final VectorSpecies<Integer> SPECIES = IntVector.SPECIES_PREFERRED;

    public static int sum(int[] array) {
        var length = array.length;
        var loopBound = length - length % SPECIES.length();
        var v0 = IntVector.zero(SPECIES);
        var i = 0;
        for (; i < loopBound; i += SPECIES.length()) {
            var v = IntVector.fromArray(SPECIES, array, i);
            v0 = v0.add(v);
        }
        int sum = v0.reduceLanes(VectorOperators.ADD);
        for (; i < length; i++) {
            sum += array[i];
        }
        return sum;
    }

    public static int sumMask(int[] array) {
        var length = array.length;
        var loopBound = length - length % SPECIES.length();
        var v0 = IntVector.zero(SPECIES);
        var i = 0;
        for (; i < loopBound; i += SPECIES.length()) {
            var v = IntVector.fromArray(SPECIES, array, i);
            v0 = v0.add(v);
        }
        int sum = v0.reduceLanes(VectorOperators.ADD);

        var mask = SPECIES.indexInRange(i, length);
        var vMask = IntVector.fromArray(SPECIES, array, i, mask);
        int sumMask = vMask.reduceLanes(VectorOperators.ADD);

        return sum + sumMask;
    }
}

VectorComputationBenchmark

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.infra.Blackhole;

import java.util.Random;
import java.util.concurrent.TimeUnit;

@Warmup(iterations = 5, time = 5, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 5, timeUnit = TimeUnit.SECONDS)
@Fork(value = 1, jvmArgs = {"--add-modules", "jdk.incubator.vector"})
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
@State(Scope.Benchmark)
@SuppressWarnings("static-method")
public class VectorComputationBenchMark {
    private final int[] array = new Random(0).ints(100_000, 0, 1_000).toArray();

    @Benchmark
    public int sum_loop_array(Blackhole blackhole) {
        var sum = 0;
        for (var value : array) {
            sum += value;
        }
        return sum;
    }

    @Benchmark
    public int sum_vector_array(Blackhole blackhole) {
        return VectorComputation.sum(array);
    }

}

Benchmark

Lancer le benchmark

Branchez votre machine sur secteur puis :

cd ./maven-loom-intellij-boilerplate
mvn clean install
cd ./lab1/target
java -jar ./benchmarks.jar

Conclusions

REMEMBER: The numbers below are just data. To gain reusable insights, you need to follow up on
why the numbers are the way they are. Use profilers (see -prof, -lprof), design factorial
experiments, perform baseline and negative tests that provide experimental control, make sure
the benchmarking environment is safe on JVM/OS/HW level, ask for reviews from the domain experts.
Do not assume the numbers tell you what you want them to tell.

Benchmark                                    Mode  Cnt   Score   Error  Units
VectorComputationBenchMark.sum_loop_array    avgt    5  23,589 ± 2,136  us/op
VectorComputationBenchMark.sum_vector_array  avgt    5   5,612 ± 0,284  us/op

Ressources

sbt-dynver : un script de release

2021-05-30T22:00:00Z

Nous avons vu dans un précédent article le plugin sbt-dynver qui permet de versionner votre code en se basant sur les tags Git. Il manquait un processus de release automatisé tout comme sbt-release tout en restant plus léger.

Voici un script permettant d'effectuer ce processus de release. Il effectue les tâches suivantes :

Vérifier que vous êtes sur la branche prévue pour les releases.
Vérifier s'il n'y a pas de modifications non commitées.
Lire et vérifier le nouveau numéro de version (en affichant la version actuelle).
Création du tag en se basant sur le nouveau numéro de version.
Pousser toutes les dernières modifications (tag inclus) sur le repo distant

#!/bin/sh
# Release script
#
# This script asks the user for the new version tag and push the
# code with the new tag.
#
# You should:
# - have release based on Git tags
# - be in your main branch
# - have a tag that starts with 'v' and the rest looks like
#   [semver](https://semver.org/)

release_branch=master
remote_repository=origin
version_tag_regexp='v[0-9]+(\.[0-9]+)+(-.*)?'

# check current branch
current_branch=$(git branch --show-current)
if [ "$current_branch" != "$release_branch" ]; then
  echo "current branch is not $release_branch (current: $current_branch)"
  exit 1
fi

# check there are no uncommitted files
modified_files=$(git ls-files --modified --deleted --exclude-standard --others)
if [ "$modified_files" != "" ]; then
  echo "those files have been modified, deleted, and/or added:"
  echo "$modified_files"
  exit 1
fi

# get the last available tag
last_tag=$(git tag --list --sort=-v:refname | grep -E "$version_tag_regexp" | head -n 1)

# read and check the new tag
read -r -p "Enter new version (prefix with 'v') [last version:$last_tag]: " new_tag
if [ "$new_tag" = "" ]; then
  echo "the tag input is empty"
  exit 1
fi
if [ "$(echo "$new_tag" | grep -E "$version_tag_regexp")" = "" ]; then
  echo "bad tag format: $new_tag"
  exit 1
fi

# proceed the new release

echo "set version to $new_tag"
git tag "$new_tag" -m "Set version to $new_tag"

echo "push new tag and last commit to remote"
git push --atomic "$remote_repository" "$release_branch" "$new_tag"

Mettez ce script dans un fichier nommé release.sh. Rendez-le exécutable et ajoutez son répertoire dans votre PATH ou déposez-le dans un sous-répertoire dédié aux scripts dans votre projet.

Scala 3 : un nouveau langage ?

2021-05-17T22:00:00Z

TL;DR : Oui.

Scala 3 vient tout juste de sortir.

Il succède à Scala 2.13, dont nous avons parlé il y a deux ans. De cette nouvelle version, qui jusque-là apparaissait comme le projet Dotty, que devons-nous attendre ? Qu'apportent les améliorations ? Quel sera le coût de la migration depuis la version 2 ?

Nous allons voir parmi ces nouveautés, celles qui sont les plus impactantes pour le développeur Scala usuel et discuter de l'aspect migration.

Syntaxe

Scala 3 propose une nouvelle syntaxe pour écrire le code. Elle me fait penser à un mix entre l'ancienne syntaxe Scala, celle de Python et celle de Pascal et Ruby. Cette nouvelle syntaxe est optionnelle et il est toujours possible d'utiliser l'ancienne syntaxe (avec quelques restrictions), voire de mixer des deux.

Structure de contrôle

Au niveau structure de contrôle, voici le if.

// 1 - old Scala syntax (available), braces are optional here
if (age >= 18) {
  "adult"
} else {
  "kid"
}

// 2 - new Scala syntax (end if), semi-indent sensitive
if age >= 18 then
  "adult"
else
  "kid"

// 3 - new Scala syntax (Pascal/Ruby-style)
if age >= 18 then
  "adult"
else
  "kid"
end if

S'ajoute ainsi le then et la perte des parenthèses pour la condition. Un marqueur de fin peut être ajouté en fin de structure. On retrouve une syntaxe équivalente avec while...do, avec for...do/yield et avec try...catch et le pattern matching.

Structure de données

Pour les structures de données, voici la nouvelle syntaxe côté classe.

// 1 - old syntax (available), braces are optional here
class Message1(message: String) {
  def display: Unit = {
    println(message)
  }
}

// 2 - new syntax (Python-style), indent sensitive
class Message2(message: String):
  def display: Unit =
    println(message)

// 3 - new syntax, indent sensitive
class Message3(message: String):
  def display: Unit =
    println(message)
  end display
end Message3

Sur la deuxième version de l'exemple ci-dessus, l'inspiration de Python est très présente. Il y avait déjà le def, le rappel du nom des paramètres à l'appel et les valeurs par défaut pour les paramètres. Maintenant, les accolades ont fait place aux deux-points en fin de déclaration. Et c'est l'indentation qui détermine si les déclarations qui suivent font partie de la classe ou si elles sont en dehors de son scope. Si vous souhaitez délimiter les blocs sans accolades, utilisez alors la troisième version dans l'exemple.

Toplevel function

En aparté, vous pouvez déclarer des fonctions qui ne sont rattachés à aucune classe ou structure équivalente directement dans un fichier. Ce qui rappelle l'une des possibilités offertes par Kotlin. Cette approche remplace la syntaxe package object de la version 2 de Scala.

Main

Du côté du main :

// 1 - old syntax
object Main {
  def main(args: Array[String]): Unit =
    println("You're the best!!!")
}

// 2 - new, no parameter
@main def mySuperProgram: Unit:
  println("You're the best!!!")

// 3 - new, with parameter
@main def hello(message: String): Unit:
  println(s"hello $message")

L'entrée de votre application n'est pas nécessairement une méthode appelée main, mais elle peut être une fonction ayant n'importe quel nom. Il faut qu'elle soit précédée de l'annotation @main. Et plutôt que de passer en paramètre un conteneur récupérant les paramètres, vous devez ici préciser les paramètres dont vous avez besoin exactement en précisant leur type (String, Int, Boolean...). Si vous ne connaissez pas par avance le type et la quantité de paramètres, il est possible d'indiquer String* ou de revenir à l'ancienne syntaxe.

Lorsque vous utilisez la nouvelle syntaxe pour déclarer l'entrée de votre application, Scala crée une classe JVM dont le nom correspond au nom de la fonction annotée @main, dans laquelle il ajoute la méthode statique main. Cette méthode main fait alors appel à un analyseur de paramètre avant de passer la main au code de la fonction. Vous pouvez ainsi avoir plusieurs fonctions @main dans le même fichier.

Package

Enfin, pour les packages :

def f: String = p1.p2.hello

package p1:
  package p2:
    def hello: String = "hello world"

Enum

Ça fait bien longtemps que les développeurs Scala l'attendait : une déclaration d'enum. Il y a déjà une telle déclaration du côté Java depuis la version 5, qui permet de déclarer des constantes. Mais il manquait un équivalent aussi pratique du côté Scala pour pouvoir déclarer des ADT et des GADT. Une tentative a été mise au point, mais l'implémentation bien qu'encore présente est loin de valoir le confort offert par les enums Java. La meilleure façon de mettre en place un ADT en Scala en version 2 est d'utiliser des sealed trait et des case class. Par exemple, voici un ADT permettant de représenter des expressions arithmétiques :

sealed trait Expression
case class Const(value: Double) extends Expression
case class Add(left: Expression, right: Expression) extends Expression
case class Mul(left: Expression, right: Expression) extends Expression

Scala 3 introduit une forme de déclaration d'enum qui est plus similaire aux enum Java, en ayant la possibilité en plus de déclarer des ADT et des GADT.

// series of constant
enum MusicalMode:
  case Ionian, Dorian, Phrygian, Lydian, Mixolydian, Aeolian, Locrian

// ADT: parameterized symbols
enum Expression:
  case Const(value: Double)
  case Add(Left: Expression, right: Expression)
  case Mul(Left: Expression, right: Expression)
  case Variable

// GADT to represent computations
enum Computation[+A]:
  def map[B](f: A => B): Computation[B] =
    Computation.Map(this, f)

  def filter(p: A => Boolean): Computation[A] =
    Computation.Filter(this, p)

  case Effect(a: () => A) extends Computation[A]
  case Map[A, B](computation: Computation[A], f: A => B) extends Computation[B]
  case Filter[A](computation: Computation[A], p: A => Boolean) extends Computation[A]

object Computation:
  def apply[A](a: =>A): Computation[A] = Computation.Effect(() => a)

L'instanciation d'un élément de l'enum sera typé par rapport à l'enum. Ainsi, que le type de Expression.Const(2.0) est Expression.

Sur des enums de type liste de constantes, Scala fournit des fonctions d'exploration, comme valueOf, name ou ordinal, que nous avons déjà côté Java.

D'ailleurs, pour avoir des enum compatibles avec Java, il suffit d'étendre java.lang.Enum.

enum MusicalMode1 extends Enum[MusicalMode1]:
  case Ionian, Dorian, Phrygian, Lydian, Mixolydian, Aeolian, Locrian

enum MusicalMode2(degree: Int) extends Enum[MusicalMode2]:
  case Ionian     extends MusicalMode2(1)
  case Dorian     extends MusicalMode2(2)
  case Phrygian   extends MusicalMode2(3)
  case Lydian     extends MusicalMode2(4)
  case Mixolydian extends MusicalMode2(5)
  case Aeolian    extends MusicalMode2(6)
  case Locrian    extends MusicalMode2(7)

Les méthodes d'extension

Les méthodes d'extension ne sont pas exactement une nouveauté en Scala. Mais il faut en Scala version 2 passer par une syntaxe verbeuse et peu explicite. En Kotlin et en C#, cette fonctionnalité existe avec une syntaxe plus explicite.

Par exemple, on reçoit en entrée une série d'événements sur des stocks de produits indiquant leur quantité constatée et l'heure à laquelle le constat a été fait. Le problème est que notre classe représentant ces événements a été générée automatiquement (par exemple, depuis une représentation en Avro, Thrift ou Protobuf). Il n'est pas envisageable de modifier cette classe pour ajouter une méthode permettant de composer deux événements de stock.

// AUTO-GENERATED
case class StockEvent(product: String, quantity: Double, timestamp: Instant)

Pour pallier ce problème en Scala 2, il faut créer une classe implicite qui pourra être utilisée dès que la méthode de composition sera appelée sur des événements de stock. Et pas que...

implicit class RichStockEvent(event: StockEvent) {
  def combineWith(other: StockEvent): StockEvent = ???
  def isEmpty: Boolean = event.quantity == 0
}

En Scala 3, la syntaxe est bien plus explicite.

extension (event: StockEvent)
  def combineWith(other: StockEvent): StockEvent = ???
  def isEmpty: Boolean = event.quantity == 0

Dans ce cas, la syntaxe est un peu plus légère et est comprise comme le fait d'ajouter une nouvelle méthode à une classe existante. De plus, il n'est pas nécessaire de trouver à cette structure un nom qui ne sera pas utilisé.

Import

La syntaxe des imports change quelque peu sur des aspects spécifiques. Pour importer le contenu d'un module, on utilisera désormais le symbole * à la place de _. Par exemple : import java.time.*.

Si vous souhaitez renommer un import, il faudra utiliser le mot-clé as à la place du symbole =>. Par exemple import java.lang.{Double as JDouble}.

Ce qui disparaît

La syntaxe procédurale (le fait d'écrire def f() {...}) n'est plus permise en Scala 3. Il vous faudra écrire plus explicitement def f() = {...} ou def f(): Unit = {...}.

La structure do...while disparaît notamment parce qu'elle est rarement utilisée, qu'il y a des alternatives et que le do est utilisable par d'autres structures, comme le for...do et le while...do. Ceci évite la confusion.

Il n'y a plus de limite à 22 paramètres pour les fonctions et les tuples. Dans les faits, il y a une représentation directe jusqu'à 22 paramètres — eg. pour les fonctions, on a les types scala.Function1, .scala.function2, ..., scala.Function22. Au-delà, on a les types génériques scala.runtime.FunctionXXL pour les fonctions et scala.runtime.TupleXXL pour les tuples.

Disparaissent aussi

Les package object (les déclarations de cet ordre se font directement dans le fichier).
Les littéraux de type symbole (eg. `mySymbol), qu'il faudra remplacer par des appels à Symbol.
L'initialisation par joker (eg. var v: Int = _). Il faudra utiliser scala.compiletime.uninitialized.

Tooling

Le compilateur fournit des options (exclusives) permettant de choisir entre 4 styles de syntaxe :

-old-syntax vérifie que les structures de contrôle suivent l'ancienne syntaxe (eg. if (cond) ... else ...).
-new-syntax vérifie que les structures de contrôle suivent la nouvelle syntaxe (eg. if cond then ... else ...).
-indent permet les indentations significatives (eg. class MyClass: ...).
-noindent ne permet que les accolades délimiter les blocs (eg. class MyClass { ... }).

Avec l'option -rewrite, le compilateur Scala réécrit le code par rapport au style de syntaxe sélectionné. Ce qui permet d'avoir une homogénéité de style de syntaxe sur l'ensemble du code d'un projet.

Une discussion est en cours pour l'ajout d'une option qui permettrait de gérer les marqueurs de fin de bloc basé sur la syntaxe end <name>.

En dehors des options du compilateur, SBT et Scalafmt sont compatibles avec Scala 3. De leur côté, le plugin Scala pour Maven et Scalafix sont en cours de développement pour cette nouvelle version.

Migration de Scala 2 vers Scala 3

C'est certainement le sujet le plus sensible ici. Bien évidemment, si vous avez la possibilité de commencer un nouveau projet, ça peut valoir le coup de passer à Scala 3 ou de l'intégrer de manière sporadique sur un petit projet ou un module plus ou moins séparé. Encore faut-il que les bibliothèques, les frameworks et le reste de l'écosystème est suivi...

Concernant le code, le fait d'ajouter l'option de compilation -source:3.0-migration, fait passer le compilateur en mode migration. Il est alors plus laxiste sur certains aspects syntaxiques et fait alors apparaître des warnings sur les fonctionnalités retirées dans Scala 3. Cette option peut être utilisée conjointement avec l'option -rewrite pour que le compilateur réécrive le code dans un format plus en adéquation avec Scala 3. Néanmoins, il est vivement conseillé de procéder par étape afin d'éviter de se trouver dans une impasse résultant par l'apparition de bug dans vos applications, car la réécriture n'est que techniquement sûre : 1/ compiler sans l'option -rewrite 2/ commiter le projet pour conserver une version avant réécriture 3/ utiliser l'option -rewrite. Pour faciliter, la compréhension des warnings, les options de compilation -explain et -explain-types devrait pouvoir vous aider.

Sur le plan des dépendances, il y a un certain nombre de bibliothèques et de frameworks qui sont déjà disponibles pour Scala 3 parmi les plus populaires et les plus actifs. Mais ce n'est pas le cas de tous (par exemple, nous attendons avec impatience une version de Spark fonctionnant avec Scala 3). Néanmoins, les contributeurs Scala avaient annoncé une interopérabilité entre Scala 3 et Scala 2, et plus spécifiquement avec la version 2.13. Ainsi, la bibliothèque officielle de Scala 3 est la bibliothèque de Scala 2.13.

Du côté du développement Scala quotidien, si vous travaillez avec Scala 3 et que vous avez besoin d'une dépendance en 2.13, il vous suffira d'ajout dans vos fichiers SBT l'option CrossVersion.for3Use2_13 sur vos dépendances (eg. libraryDependencies += ("org.bar" %% "bar" % "1.0.0").cross(CrossVersion.for3Use2_13)), s'il s'agit d'une dépendance externe. Pour une dépendance locale, il n'y a rien à faire à part de l'indiquer comme d'habitude (eg. .dependsOn(my_scala3_module)). À l'inverse, si vous travaillez en Scala 2.13 et que vous avez besoin d'une dépendance en version 3, vous avez l'option -Ytasty-reader à ajouter au niveau des options de compilation. Dans ce cas, si vous avez une dépendance externe, vous devez ajouter l'option CrossVersion.for2_13Use3 à votre dépendance. Il n'y a rien de plus à faire pour une dépendance interne.

Le projet Scala fournit une documentation assez complète sur la migration vers Scala 3. Une matrice des incompatibilités et des modifications d'option de compilation sont aussi consultables.

Conclusion

Scala 3 arrive avec une syntaxe assez différente de Scala 2. Ce qui fait de Scala 3 un langage différent, mais avec des compatibilités vis-à-vis de l'ancienne version. Du côté écosystème, les contributeurs font émerger des mises à jour de leur projet basé sur Scala au fur et à mesure.

Néanmoins, le spectre douloureux de la migration Python 2 vers Python 3 qui s'est étalé sur une décennie est relativement présent autour de l'adoption de Scala 3. La difficulté de cette migration fait qu'il est apparu un mur de la honte indiquant les bibliothèques n'étant pas encore passées à Python 3 et qu'il a été imposé une date de fin de maintenance de la version 2.

De son côté, la communauté Scala (en dehors de ses dramas) semble vouloir avancer dans le même sens pour l'adoption de Scala 3. Elle est tout à fait consciente des difficultés de la migration Python 2 vers Python 3. Néanmoins, Scala n'est pas Python. Il n'a ni son organisation ni le même périmètre d'utilisation. Le projet sur lequel repose Scala 3 existe depuis 8 ans. Des annonces ont régulièrement été faites pour montrer les nouveautés à venir et donner une roadmap de plus en plus précise. Les fonctionnalités de Scala 3 pouvaient être testées bien avant ça sortie. Les principales bibliothèques ont régulièrement sorti des releases sur les pré-versions de Scala 3. Des workshops ont été organisés sur Scala 3. Les pré-versions de Scala 3 ont été automatiquement testées pour tenter de compiler un ensemble de projets Scala OSS. On peut s'attendre ainsi à une migration relativement simple entre Scala 2 et Scala 3, même si en réalité ce n'est jamais simple.

Photographie par Jack Hunter sur Unsplash.

Retour d'expérience : optimisation de traitement Spark - Le piège du tout DataFrame

2021-02-16T23:00:00Z

Le traitement

Nous avons en entrée une structure comme celle-ci

{
  "id": "1234",
  "created": "2021-01-01T00:00:00",
  "criteriaA_periods": [
    { "begin": "2021-01-03T00:00:00", "end": "2021-01-05T00:00:00" },
    { "begin": "2021-01-07T00:00:00", "end": "2021-01-08T00:00:00" },
  ],
  "criteriaB_periods": [],
  "criteriaC_periods": [],
  "criteriaD_periods": [
    { "value": 12,
      "begin": "2021-01-02T00:00:00", "end": "2021-01-05T00:00:00" }
  ],
}

Elle contient des périodes d'application de divers critères A, B, C, et D. En période d'application, on utilise la valeur 1, sinon c'est 0. Pour le critère D, en période d'application on utilise la valeur fournit dans le critère, sinon c'est une valeur par défaut.

Par transformation Spark, on veut une structure plus linéaire qui au 1er janvier 2021 ressemble à

{
  "id": "1234",
  "created": "2021-01-01T00:00:00",
  "applicationDatetime": "2021-01-01T00:00:00",
  "criteriaA_availability": [ 0,  0,  1,  1,  1,  0,  1,  1],
  "criteriaB_availability": [ 0,  0,  0,  0,  0,  0,  0,  0],
  "criteriaC_availability": [ 0,  0,  0,  0,  0,  0,  0,  0],
  "criteriaD_availability": [30, 12, 12, 12, 12, 30, 30, 30],
}

Dans la structure de sortie, chaque critère contient une liste dans laquelle l'indice (commençant à 0) représente le décalage par rapport à un jour donné (ie. l'indice 0 correspond à J, 1 à J+1, 2 à J+2...).

Les données d'entrée sont stockées dans une base et nous devons utiliser Spark pour les récupérer, calculer la nouvelle structure et les intégrer dans une partie d'un autre traitement Spark.

Deux solutions s'offrent à nous avec Spark SQL : API SQL ou API fonctionnelle. Et il y a une contrainte : c'est du Spark 2.2.

Avec l'API SQL

J'ai l'habitude de penser que par défaut il faut utiliser Spark SQL et les fonctions que fournit le module. Ainsi, nous pouvons bénéficier des optimisations proposées par Catalyst, sachant qu'il y a de fortes chances que Catalyst se débrouille mieux que nous pour obtenir des jobs performants.

Le code récupéré permettant de résoudre le problème présenté ici est en effet basé sur l'API SQL de Spark SQL. Sur un problème qui semble linéaire, je me suis retrouvé avec des requêtes Spark SQL utilisant des explodes, divers filtres et des jointures effectuées sur le même datasource. Le DAG de la requête est assez monstrueux, avec 5 scans (LocaTableScan) des mêmes données !

On a un total de 5 jobs et 10 stages.

La base du calcul est représentée par cette fonction qui pour chaque critère (représenté par la colonne en paramètre) va créer un array de flag.

def availability(dataset: DataFrame,
                 criteriaColumn: Column,
                 dayCount: Int,
                 currentDate: String,
                 value: Option[Int],
                 defaultValue: Int): DataFrame =
  (0 to dayCount)
    .foldLeft(dataset.withColumn("interval", explode(criteriaColumn))) {
      case (ds, i) =>
        ds.withColumn(s"int_$i",
          when(
            date_add(lit(currentDate), days=i)
              .between($"interval.begin", $"interval.end"),
            value
              .map(c => col(s"interval.$c"))
              .getOrElse(1)
          ).otherwise(defaultValue)
        )
    }
    .groupBy("id")
    .agg(array(
      (0 to dayCount).map { i => max(s"int_$i") }: _*
    ) as "ints")

Cette fonction est donc appelée 4 fois (1 fois par critère) sur le même dataframe. Chaque appel fournit un dataframe. Ces dataframes sont ensuite regroupés par des jointures successives basées sur l'id. Un filtrage est aussi réalisé sur le dataframe de base. On arrive ainsi à 5 scans !

L'une des raisons de cette complexité est due au fait que l'API SQL de Spark SQL ne permet pas de travailler finement sur les données prises lignes par lignes, sauf à utiliser éventuellement des UDF. Ça ne veut pas dire que cette approche est mauvaise. Sur des requêtes ayant des formes plus classiques (du simple SELECT à une série de jointures sur des formats divers impliquant des transformations usuelles de colonnes) Spark SQL aura probablement de meilleures performances que ce que vous pourrez faire avec Spark Core ou l'API fonctionnel des Datasets. Le problème ici n'est pas classique d'un point de vue Spark SQL et l'effet est à peu près le même que d'utiliser une formule 1 sur de l'herbe : ça ne va pas aller très vite parce que ce n'est pas prévu pour ça.

Vers l'API fonctionnelle

Réfléchissons en se demandant comment faire si nous n'avions pas Spark sous la main ?

Réponse : on parcourrait les données en une passe. Pour chaque donnée rencontrée on ferait une conversion de la structure d'entrée en structure de sortie sans faire appel à des données externes à part d'éventuels paramètres intégrés au traitement. Si on veut accélérer les choses on peut même partitionner les données en fonction du nombre de machines et de cœurs mis à disposition. On a ainsi un traitement linéaire et plutôt simple.

Si on revient à Spark, on peut récupérer les données au sein d'un dataset et faire appel à la fonction map. Spark s'occupera ensuite du partitionnement, de la parallélisation et la distribution du traitement.

Résultat : un seul job avec un seul stage et un beau DAG bien linéaire !

Son DAG indique que les données ne sont parcourues qu'une seule fois. Les 100 000 lignes sont traitées en 1,3 secondes (sur ma machine) avec en extrémité des phases de sérialisation. On peut regarder dans le détail

Dans le graphique ci-dessous, les phases de scheduler delay et de serde représente un overhead de ~350 ms contre 1 seconde de traitement (toujours sur ma machine).

Le principe de la solution consiste d'abord à convertir chaque ligne sous la forme d'une case class appropriée sous la forme dataframe.as[MyCaseClass]. La conversion linéaire est ensuite réalisée en faisant un map sur le dataset, qui permettra d'obtenir pour chaque ligne une case class correspondant au schéma attendu en sortie.

Chaque période est d'abord convertit en WeightedPeriod, dont le poids vaut 1 pour les critères A, B et C.

case class WeightedPeriod(weight: Int,
                          begin: LocalDateTime,
                          end: LocalDateTime) {
  def contains(ts: LocalDate): Boolean =
    (begin.equals(ts)
      || end.equals(ts)
      || (ts.isAfter(begin) && ts.isBefore(end)))
}

Puis les périodes des critères sont transformées en tableau de flags avec cette méthode

def availability(periods: Seq[WeightedPeriod],
                 dayCount: Int,
                 current: LocalDateTime,
                 defaultValue: Int): Seq[Int] =
  (0 to dayCount)
    .map { deltaDay =>
      val offsetDay = current.plusDays(deltaDay)

      periods.find(_.contains(offsetDay))
        .map(_.weight)
        .getOrElse(defaultValue)
    }

Ce qui donne

dataframe
  .as[InputEntity]
  .map(input => OutputEntity(
    id = input.id,
    created = id.created,
    criteriaA_availability = availability(id.criteriaA_periods.map(_.withWeight(1), dayCount, currentDateTime, defaultValue=0),
    criteriaB_availability = availability(id.criteriaB_periods.map(_.withWeight(1), dayCount, currentDateTime, defaultValue=0),
    criteriaC_availability = availability(id.criteriaC_periods.map(_.withWeight(1), dayCount, currentDateTime, defaultValue=0),
    criteriaD_availability = availability(id.criteriad_periods.map(_.toWeight, dayCount, currentDateTime, defaultValue=defaultD),
  ))

Conclusion

Spark SQL est un outil formidable, permettant de réaliser simplement des traitements complexes et avec un niveau d'optimisation difficile à obtenir à la main. Néanmoins, l'API SQL de ce framework ne doit pas nous faire oublier qu'il faut analyser ce qu'il se passe lorsqu'on envoie nos requêtes à Spark. Car cette API n'est pas adaptée à tous les cas. Il est des cas où elle peut être plus une lourdeur qu'un véritable atout. Il faut dans ce cas ne pas hésiter à utiliser des UDF ou alors à se rapprocher de l'API fonctionnelle afin de retrouver des performances raisonnables. Car Spark reste néanmoins l'un des frameworks les plus performants pour ce qui concerne les traitements Big Data (qu'il faut bien comprendre comme de la donnée éparpillée sur un cluster, trop volumineuse pour tenir sur une seule machine) avec une API relativement confortable.

Ceci dit, nous sommes en Spark 2.2 dans ce REX. Ce qui signifie que cette conclusion est à édulcorer. Sachant que les versions plus récentes de Spark permettent d'intégrer des fonctions d'ordre supérieur dans les requêtes SQL, il serait possible d'exprimer simplement une solution à ce problème dans une requête.

Photographie par Laura Ockel sur Unsplash.

Retour d'expérience : donner une étude de cas à des étudiants

2021-02-10T23:00:00Z

Je vous propose un retour d’expérience sur un dispositif d'évaluation que nous avons eu l'occasion de mettre en place dans le cadre d'une formation auprès de l'école d'ingénieur ESIPE de l'Université Gustave Eiffel. La formation était donnée à des étudiants en 3e année de cycle ingénieur sur le thème des bases de données pour le big data, que j'ai orienté pour évoquer différentes technologies NoSQL, l'utilisation des techniques NoSQL pour mettre en place une plateforme de stream processing (hello Kafka) et surtout un cas d'usage en introduction pour montrer un exemple où le métier de data engineer est nécessaire et ce qu'il implique.

Nous sommes alors autour d'octobre-novembre 2020. Si les premiers cours ont eu lieu sur place mais masqué (sur un slide de présentation, j'avais alors montré une photo de moi-même en disant : "voilà, c'est moi sans le masque."), les cours suivants se sont faits à distance. Il n'y avait ni TD ni TP par manque de temps de préparation. Il restait alors la question de la validation du module de formation pour les étudiants.

Que doit retenir un étudiant d'un module de formation ?

Bien souvent, la validation d'un module passe par la validation des connaissances acquises lors d'un examen donné sur un temps limité. Nous avons tous vécu ça. Et si ce format permet de vérifier que les leçons sont (partiellement) bien apprises et de faciliter les corrections, son intérêt s'arrête là ! La place pour la créativité est très limitée. C'est pourtant un point essentiel pour un domaine — le domaine de l'informatique tout entier — qui se renouvelle régulièrement.

Lors de mon cours, j'ai cherché à montrer qu'avec de bonnes bases (principalement le livre de Martin Kleppmann d'un côté et du code source de l'autre), le fonctionnement de systèmes NoSQL devient plus limpide, incluant d'ailleurs quelques live coding pour recréer des commits logs ou des protocoles pour gérer des requêtes... Le point étant que les technologies présentées dans le cours sont beaucoup plus accessibles qu'elles n'y paraissent. Si lors du cours, il n'est pas possible de tout voir, il doit fournir un minimum de pointeurs pour permettre d'en apprendre plus par la suite (et même avec ça, ce n'est pas suffisant *frustration personnelle*).

Comme je sentais que le cours ne suffisait pas, j'avais envie que la partie validation du module soit un complément où l'étudiant aurait l'occasion de voir et apprendre par lui-même. Et donc, l'examen en mode devoir sur table ne me convenait pas.

J'ai dans ma carrière participé à des missions d'audit et de conseil. En peu de temps, il faut fournir une solution à un client suite à un problème rencontré. Dans ce laps de temps, il faut à la fois se baser sur ses connaissances et son expérience pour imaginer des solutions adaptées, et dans la mesure cela ne suffit pas, éventuellement effectuer des recherches sur l'existant pour trouver de nouvelles façons de faire ou valider des idées.

J'ai trouvé cette approche beaucoup plus adaptée par rapport à ce que je cherchais à mettre en place pour la validation du module de formation. Pour un étudiant sans expérience, elle implique en effet :

De voir un exemple de problématique rencontré chez des clients (j'avais alors choisi un sujet proche d'une de mes expériences).
D'avoir un complément par rapport au cours et tout en ayant la possibilité d'y apporter un regard critique.
D'effectuer des recherches et explorer des solutions existantes pour répondre au besoin.
Éventuellement de confronter ses ébauches de solutions face à des personnes ayant plus d'expériences.

Pour faciliter le travail, surtout en période de confinement, les étudiants étaient regroupés, sur fond de pizza team !

Sujet

Une entreprise gère indépendamment un ensemble de sources de données concernant des utilisateurs de son offre numérique (site web, applis mobiles, réseau social...). Elles sont mises à disposition pour différents usages métiers. Ces sources ont un certains débits : certaines sont "continues" ou aléatoires, d'autres fournissent des données à intervalle fixe. Elle ne dépasse pas le gigaoctet a par une seule qui fournit 400 Go par jour. Ces sources sont localisées dans des bases de données ou des fichiers localisés dans l’entreprise ou dans des stockages de type cloud.

L'entreprise souhaite concentrer sur une seule plateforme ces données concernant ses utilisateurs pour des usages marketing.

Il est demandé de proposer une recommandation architecturale sur laquelle reposerait une telle plateforme.

Le sujet précise :

L'usage actuel des sources avec plus ou moins de précisions.
Le temps de rétention pour certaines sources de données (90 jours).
La fréquence de mise à jour attendue des données de la plateforme (1 fois par jour).

Il est précisé aussi que le client a une équipe technique, mais que ses connaissances en termes de base de données se limitent à MySQL et Elasticsearch.

Le sujet tient sur deux pages et est volontairement incomplet. Le fait que les étudiants demandent des précisions par la suite fait partie de l'exercice.

Des questions sont ajoutées au sujet, demandant par exemple de calculer l'espace de stockage à prévoir (cachée dans une question qui demande le volume des données, ce qui implique de penser au facteur de réplication) et d’imaginer en conclusion des points qui auraient pu être abordés dans l'étude.

Mise en situation et déroulement

Dans le cadre de ce sujet, le groupe d'étudiants est vu comme un groupe d'experts ayant acquis des connaissances dans le domaine de la data ingénierie et capable de recommander une entreprise sur la mise en place d'une "plateforme data".

Certains ont même baptisé leur équipe. Je vous laisse juge...

Les étudiants ont eu un mois pour proposer une solution. Un mois c'est court, d'autant plus pour des étudiants sachant qu'avec les autres modules, ils ne sont pas à 100% de la journée dessus.

Dans cet exercice, je joue tour à tour le rôle d'enseignant, coach et client. En tant que coach, j'oriente leur façon d'aborder le sujet et leurs recherches. Je les mets plus en situation sur la relation qu'ils devront entretenir avec le client. En tant qu'enseignant, j'émets des avis techniques sur leurs ébauches, je les oriente sur des solutions correspondant à leur souhait. En tant que client, j'apporte un jugement sur les ébauches de solution qui me sont présentés. Dans tout ça, j'évite d'imposer un point de vue purement personnel et de les enfermer dans certaines solutions. Il vaut indiquer un ensemble des technologies ou d'approches pouvant répondre au problème sans entrer dans les détails plutôt que de ne parler que d'une seule techno. C'est aux étudiants de faire l'effort de découvrir les technologies et d'en vérifier l'adéquation avec le sujet.

Dans tout ça, il est nécessaire pour l'enseignant de suivre l'avancée. Ce suivi a surtout été à l'initiative de certains étudiants. En y voyant l'intérêt, j'ai fini par imposer des points de suivi à d'autres groupes.

Un aspect, qui est probablement venu un peu tard, fût de les pousser à rencontrer des professionnels pour confronter leurs solutions. L'avantage est évidemment certain, et ce n'est pas faute de les avoir encouragés :

Ces sociétés sont suffisamment ouvertes pour comprendre qu’elles ont tout intérêt à aider des étudiants (qui pourraient être de futurs recrues ou des futures « évangélistes » de leurs solutions). Le cas échéant, faites en part dans votre rapport, ça rassurera le client. Et si certaines vous disent non, vous saurez celles qui ne méritent pas votre CV 😉

Il est venu un peu tard dans le déroulement. Finalement, un seul groupe a utilisé cette possibilité.

La phase mise en place et déroulement se sont particulièrement bien passés et a été enrichissant pour tout le monde, moi y compris, comme je l'explique dans ces tweets :

Soutenance & rapport

La partie soutenance s'est faite groupe par groupe... à distance. Chaque groupe ayant 20mn de présentation et 10mn de questions. Les étudiants devaient ensuite rendre un rapport de quelques pages. J'étais alors accompagné par un collègue expérimenté.

L’un des problèmes posés par cette approche est de pousser les groupes à la limite du bluff. Un mois de préparation pour des personnes qui ne peuvent pas consacrer 100% de leur temps à cet exercice, du fait des cours et d’autres préparations diverses à mettre en place, laisse peu de temps pour l’expérimentation. Comme le sujet implique d’imaginer l’usage de systèmes complets de stockage et de manipulation de données utilisées sur des problématiques techniquement avancés en entreprise, le défi représenté est passionnant pour les étudiants, mais nécessite en réalité une bonne expérience avec ces outils. Ils ne peuvent que se baser sur de la documentation accessible pour imaginer ce qui pourrait être mis en place.

Il y aurait différents moyens de pallier ce problème :

Un cours insistant sur les usages attendus des différents types de systèmes de stockage et traitement de la donnée.
Un suivi des travaux en cours par l’enseignant avec de l’accompagnement ponctuel.
Forcer un peu plus les groupes à demander l’avis d’un expert technique.

Le point 1. est à mon sens pas très simple à mettre en place. Les possibilités d’une base de données sont relativement vastes. Il y a moyen de passer une bonne partie du cours sur les cas d'usage de chaque type de base.

Le point 3. a été très partiellement suivi. Son avantage est en apparence majeur, mais comporte une potentielle difficulté. L'expert peut voir le sujet à sa façon (sachant que le sujet comporte des imprécisions) qui ne correspond pas à ce qui doit être compris et insister sur des technologies qui ne sont pas nécessaires (ça arrive même aux meilleurs 😄). Dans ce cadre, c'est au groupe de cadrer et challenger les recommandations de l'expert.

Le point 2. est un point qui a été mis en place et qui a mon sens est celui qui est le plus intéressant. Il est intéressant, car il permet à la fois d’insister sur les détails du cours dans un cadre pratique et d’éviter que le groupe ne se disperse.

Notation

C'est la partie la plus compliquée. Dans un cas comme celui-là, il faut être capable de diviser le travail réalisé par les groupes en items à valider. Pour imaginer ces items, on peut commencer par imaginer les cas extrêmes et même des cas extrêmes du point de vue du potentiel client de l'étude.

Le pire des cas apparaît lorsqu'un groupe ne montre aucun intérêt et remet des livrables excessivement bâclés ou ne remet pas de travail du tout sans justification compréhensible. C'est un manque de respect notoire et va créer auprès du client de la frustration, qui n'aura aucun souci à aller voir ailleurs. (Ce cas n'est pas arrivé dans les groupes que j'ai fréquentés) ⇒ 0-5

Il y a un autre cas extrême : problème administratif ⇒ pas de note (ce n'est pas un 0, hein !)

Le meilleur des cas : l'architecture répond au besoin du client, les livrables sont corrects. En se basant sur ces livrables, le client peut avec un effort moindre mettre en place sa plateforme data ⇒ 20

L'architecture et les livrables dépassent les attentes du client : c'est potentiellement une bonne idée de réaliser une proposition qui va au-delà des attentes, mais elle va se faire généralement au détriment d'autres aspects d'ordre professionnels et/ou privés, qui risquent de se traduire par une diminution à moyen terme de la qualité de service rendu par l'équipe. Dans la vie professionnelle cela se traduit par le fait d'avoir trop travaillé sur un sujet au détriment d'autres sujets potentiellement plus importants, ce qui peut mettre à mal une carrière. De plus, ce surplus n'est généralement pas payé (du moins à court terme) ⇒ 20

Les cas vont être notés ensuite en fonction des éléments d'architecture en place (eg. toutes les sources sont-elles bien présentes ? Comment sont-elles ingérées par le système ? Comment est effectué le traitement ?...) et de l'effort que devra fournir le client pour mettre en place une plateforme data convenable selon son besoin.

Le système de notation ici n'est pas parfait, mais il permet d'être relativement objectif par rapport à l'ensemble des travaux rendus.

Amélioration possible

Ce fût ma première expérience avec ce type d'exercice. Je l'ai trouvé vraiment intéressant et j'ai très envie de recommencer. De plus, elle s'adapte assez bien vis-à-vis des contraintes sanitaires rencontrées durant cette période.

Je pense que quelques améliorations peuvent être apportées néanmoins.

C'est un détail, mais je pense que je devrais insister sur le fait que la soutenance et le rapport soient à destination du client. Dans les rapports, j'ai en effet trouvé des phrases du style "C'est un exercice demandé dans le cadre du cours de M. François Sarradin" ou "Nous avons beaucoup appris avec ce sujet...". Ces phrases n'ont pas à être dans un rapport.
Fixer des rendez-vous de suivi de 30mn pour chaque groupe durant les sessions de TP, avec au moins.
- Un rendez-vous où le groupe aura préparé une série de questions à poser au client (questions fonctionnelles et techniques), ainsi que les critères de satisfaction.
- Un rendez-vous pré-soutenance de présentation de l'architecture au client pour avoir les premiers retours.
Dans le cours, parler un peu plus des usages attendus de certains types de base de données.
Laisser du temps (quelques jours) pour rendre le rapport, afin que les étudiants y apportent des corrections par rapport à ce qui a été vu lors de la soutenance.

Photographie par Surface sur Unsplash.

Unison langage

2021-01-10T23:00:00Z

Let's talk about the Unison language.

Unison is a statically typed langage whose main influences are Haskell, Erlang and Frank. It is built upon a simple idea that has really appealing consequences:

Code is content-addressed and immutable

In many langages, the main way to identify something is its name. In Unison, definitions are identified by a hash computed after its content. For instance, those two definitions below have different names but their body is identical. So they share the same hash.

inc x = x + 1

add1 z = z + 1

For each hash, an AST is stored in the unison codebase.

In fact, the text representation that we have seen above is not the primary representation for unison code. The AST is. Text is one of many possible way to create/view/update unison code.

For instance, if we need our previously defined inc function to define something else, its name will be substituted by its hash in the resulting AST.

add2 x = inc (inc x)

Assuming that the corresponding hash for inc is #12345 , the below code will be preprocessed as this:

add2 x = #12345 (#12345 x)

Then, argument names are substituted by normalized ones:

add2 arg1 = #12345 (#12345 arg1)

With this hash based representation of our definition, we can compute an AST that is independant of names declared by developers.

This implies that we can change the name inc for another name without changing the definition of add2 .

Also once inc has been compiled, if you change its name, then is hash will not be modified. This mean that you do not need to recompile that function or other already compiled definitions that depends on it!

Installation

It is much more fun to try those things on your own machine while following along this article. So I suggest to do so, knowing that Unison is really easy to install, so I invite you to do so:

OSX (with homebrew)

brew tap unisonweb/unison
brew install unison-language

Once Unison is installed on your machine, you need to create a directory that unison will be launched against and cd inside it.

mkdir Unison # create a dir to start with
cd Unison

then initialize unison and launch the unison codebase manager

ucm init # init the codebase
ucm # entering unison

You should see something like this:

   _____     _             
  |  |  |___|_|___ ___ ___ 
  |  |  |   | |_ -| . |   |
  |_____|_|_|_|___|___|_|_|
  
  Welcome to Unison!
  
  You are running version: release/M1m
  
  I'm currently watching for changes to .u files under ~/Code/Unison
  
  Type help to get help.

.>

Once in the Unison REPL is launched, we import the base library.

.> pull https://github.com/unisonweb/base:.releases._latest base

And we are good to go!

The unison codebase manager

Once you have launched ucm, any file within the current directory is watched. Let's first create a file named scratch.u with our inc definition in it.

inc x = x + 1

When saving this file, you can see the output of the ucm process.

I found and typechecked these definitions in scratch.u. If you do an `add` or `update`, here's
how your codebase would change:
  
  ⍟ These new definitions are ok to `add`:
    
    inc : Nat -> Nat

Indicating that our definition is valid.

Now, if we want to try our inc function, we can add a watch expression. To do so, just add the following line at the end of scratch.u (you have to include the '>' symbol).

> inc 10

On saving the file, ucm will spot it and display:

Now evaluating any watch expressions (lines starting with `>`)... Ctrl+C cancels.


    3 | > inc 10
          ⧩
          11

Since our inc function seems to work as intended, we can add it to the codebase.

At the ucm prompt just type add:

.> add 
  
  ⍟ I've added these definitions:
  
    inc : Nat -> Nat

Now that our inc function is in the codebase, we can delete the content of scratch.u.

We can ask ucm to find it like this:

.> find inc

  1. inc : Nat -> Nat
  2. base.Int.increment : Int -> Int
  3. base.List.distinct : [a] -> [a]
  4. base.Nat.increment : Nat -> Nat
  5. base.Store.modify.examples.increment : Nat

In the list of results, the first item is our function. We can ask ucm to view it.

.> view 1

  inc : Nat -> Nat
  inc x =
    use Nat +
    x + 1

This is it! Enhanced with its infered type declaration and import statement (+ function from module Nat).

The find operation is handful to explore the current codebase. For instance, we can search for all definitions of a given type:

.> find : Nat -> Nat

  1.  base.Nat.complement : Nat -> Nat
  2.  base.Nat.increment : Nat -> Nat
  3.  base.Nat.leadingZeros : Nat -> Nat
  4.  base.Nat.trailingZeros : Nat -> Nat
  5.  base.Nat.decrement : Nat -> Nat

Changing names

Let's define another useful function:

scratch.u

add2 x = inc (inc x)

Once add2 is added to our codebase (with the add command), we can retrieve its definition with the view command

.> view add2

  add2 : Nat -> Nat 
  add2 x = inc (inc x)

We suddenly decide that we want to change the name of the inc function to add1.

In any other langage we would had to navigate to the inc definition, change its name, then change all its usages accordingly, but in unison we only have to run this simple ucm command:

.> move.term inc add1

As we can see, the add2 definition has been correctly updated:

.> view add2

  add2 : Nat -> Nat 
  add2 x = add1 (add1 x)

No recompilation is needed neither, it just works!

Navigating the history

With immutability comes great benefits, as functional programmers often says.

Since our codebase is always a well-typed immutable value, we have time travel for free.

.> reflog

  Here is a log of the root namespace hashes, starting with the most recent, along with the command
  that got us there. Try:
  
    `fork 2 .old`             
    `fork #fpkooer5hq .old`   to make an old namespace accessible again,
                              
    `reset-root #fpkooer5hq`  to reset the root namespace and its history to that of the specified
                              namespace.
  
  1.  #fiviinv92c : move.term ..inc .add1
  2.  #1mlujphnkc : add
  3.  #cb6lu9ahad : add
  4.  #lqs21dco5d : pull https://github.com/unisonweb/base:.releases._latest .base
  5.  #7asfbtqmoj : (initial reflogged namespace)

Documentation

in Unison documentation is first class, it has type Doc and a dedicated literal.

As an example, let's write documentation for our inc function:

inc.docs = [:
  `@inc n` returns `n + 1`

  the source for @inc is
  @[source] inc

  the result of evaluating `(@inc 1)` is @[evaluate] inc.ex1

  its signature is:
  `@[signature] inc`

  :]

You can then display this docs in ucm:

.> display inc.docs

  `inc n` returns `n + 1`
  
  the source for inc is
  inc x =
    use Nat +
    x + 1
  
  the result of evaluating `(inc 1)` is 2
  
  its signature is: `inc : Nat -> Nat`

To get more details on documentation inner syntax please see this page.

One neat thing to keep in mind is that the names you use in your docs have the same behaviour in case of renaming. For instance if we rename inc to add1 with:

.> move.term inc add1

and then display the doc again:

.> display inc.docs

  `add1 n` returns `n + 1`
  
  the source for add1 is
  add1 x =
    use Nat +
    x + 1
  
  the result of evaluating `(add1 1)` is 2
  
  its signature is: `add1 : Nat -> Nat`

Every dynamic value (the one starting by @) are updated accordingly.

Abilities

Abilities lets you use the same ordinary Unison syntax for programs that do (asynchronous) I/O, stream processing, exception handling, parsing, distributed computation, and lots more...

Hello world!

scratch.u:

greet name = printLine ("Hello " ++ name ++ "!")

program = '(greet "world")

ucm:

.> run program

Hello world!

When saving our scratch.u file, we can see the type of the greet function:

greet : Text -> {IO} ()

which means that the greet function takes a Text as argument, needs the IO ability and return nothing (() or Unit).

The functions that we have seen up to this point are pure (inc and add2). If ucm display their type as Nat → Nat, their real type is Nat → {} Nat, indicating that no abilities were needed.

A function from type a to type b that needs several abilities A1, A2 and A3 will have the type like a → {A1,A2,A3} b

Motivation

There are three main motivations for abilities in Unison:

Make side effects visible in the type signature.
Decouple interface from implementation.
Customize control flow.

Lazyness

As you may have noticed in the hello world example, the '(greet "world") expression was prefixed by a single quote. This is syntax sugar for (_ → (greet "world")) which denotes a function taking () as argument and returning the result of evaluating (greet "world").

scratch.u :

expr = '(1 + 1)
-- is equivalent to 
expr = (_ -> (1 + 1))

-- and can be resumed/evaluated like this 
> expr ()
-- or with syntax sugar 
> !expr

This kind of quoting is often used in conjunction of abilities, as we have seen with the hello world example.

This is because only functions can use abilities:

Unison is a 'purely functional' language. That means that evaluation of terms cannot in itself be effectful. Having to add the ' delay to effectfully-computed values is a consequence of that. Any effectful code needs to pull its punches — it's not causing effects to happen during evaluation, but rather it's evaluating to a function which can then explain to a handler what effects it would like to be performed. We'll see how that handler in turn can only either (a) turn the requested effects into pure computations, ready for evaluation, or (b) pass the buck, by translating them to requests in another ability, yielding another function. If there are abilities like network or disk I/O, then the buck gets passed all the way to the very outside of the program, and into the Unison runtime system, using the IO ability. At no point does a Unison term's evaluation ever directly generate an effect.

the IO ability

IO is a special ability, built in to Unison. It is through IO that effectful Unison programs can actually interact with the outside world — writing to the console, reading from files and sockets, and any other behavior that goes beyond simply evaluating Unison expressions to a result. When you run your program (for example using ucm's run command), operations from the IO ability are handled by the Unison runtime system.

Asking ucm about IO:

.> view IO

  ability base.io.IO where
    getFileSize_ : FilePath ->{base.io.IO} Either Error Nat
    kill_ : ThreadId ->{base.io.IO} Either Error ()
    send_ : Socket -> Bytes ->{base.io.IO} Either Error ()
    bracket_ :
      '{base.io.IO} a -> (a ->{base.io.IO} b) -> (a ->{base.io.IO} c) ->{base.io.IO} Either Error c
    getLine_ : Handle ->{base.io.IO} Either Error Text
    getText_ : Handle ->{base.io.IO} Either Error Text
    getFileTimestamp_ : FilePath ->{base.io.IO} Either Error EpochTime
    closeFile_ : Handle ->{base.io.IO} Either Error ()
    getTemporaryDirectory_ : {base.io.IO} (Either Error FilePath)
    getCurrentDirectory_ : {base.io.IO} (Either Error FilePath)
    renameDirectory_ : FilePath -> FilePath ->{base.io.IO} Either Error ()
    renameFile_ : FilePath -> FilePath ->{base.io.IO} Either Error ()
    receive_ : Socket -> Nat ->{base.io.IO} Either Error (Optional Bytes)
    fileExists_ : FilePath ->{base.io.IO} Either Error Boolean
    isDirectory_ : FilePath ->{base.io.IO} Either Error Boolean
    directoryContents_ : FilePath ->{base.io.IO} Either Error [FilePath]
    listen_ : Socket ->{base.io.IO} Either Error ()
    closeSocket_ : Socket ->{base.io.IO} Either Error ()
    clientSocket_ : HostName -> ServiceName ->{base.io.IO} Either Error Socket
    delay_ : Nat ->{base.io.IO} Either Error ()
    seek_ : Handle -> SeekMode -> Int ->{base.io.IO} Either Error ()
    serverSocket_ : Optional HostName -> ServiceName ->{base.io.IO} Either Error Socket
    accept_ : Socket ->{base.io.IO} Either Error Socket
    setBuffering_ : Handle -> Optional BufferMode ->{base.io.IO} Either Error ()
    openFile_ : FilePath -> Mode ->{base.io.IO} Either Error Handle
    throw : Error ->{base.io.IO} a
    fork_ : '{base.io.IO} a ->{base.io.IO} Either Error ThreadId
    getBuffering_ : Handle ->{base.io.IO} Either Error (Optional BufferMode)
    position_ : Handle ->{base.io.IO} Either Error Int
    setCurrentDirectory_ : FilePath ->{base.io.IO} Either Error ()
    createDirectory_ : FilePath ->{base.io.IO} Either Error ()
    removeDirectory_ : FilePath ->{base.io.IO} Either Error ()
    removeFile_ : FilePath ->{base.io.IO} Either Error ()
    systemTime_ : {base.io.IO} (Either Error EpochTime)
    isFileEOF_ : Handle ->{base.io.IO} Either Error Boolean
    isFileOpen_ : Handle ->{base.io.IO} Either Error Boolean
    isSeekable_ : Handle ->{base.io.IO} Either Error Boolean
    putText_ : Handle -> Text ->{base.io.IO} Either Error ()

Other abilities

Abilities are declared in an abstract way like this:

ability Store v where
  get : v
  put : v -> ()

This declaration introduces a Store ability which contains 2 actions: get and put.

Unison has no builtin mutable state mechanism. So this ability is introducing one.

This declaration does not specify any implementation (it is abstract). One nice thing about this is that we can plug any implementation we need (depending on the use-case) without modifying the code that is using those actions.

In order to be able to use this ability, we have to handle it. In Unison this is done by an Ability handler.

If e is an expression containing action calls and h is an ability handler then handle e with h is the way to get the result of evaluating e.

An ability handler is a function that states how to handle each action we want to use in the handled code (e). A handler for the Store ability will have to take care of Store.get and Store.put individually. But we will delay this and start with a simpler ability.

Abort

One of the most basic ability one can imagine is the Abort ability which is able to cut the execution of a program.

ability Abort where 
  cut : a

Here is a handler for it:

abortHandler returnedValue = cases 
  -- handling the cut action
  {Abort.cut -> continuation} -> returnedValue
  -- Exit case
  {a} -> a

There is 2 branches in our cases statement, the first one is handling our cut action by ignoring the continuation and immediately returning returnedValue.

The first branch starts with the action pattern {Abort.cut → continuation} that matches our only action Abort.cut and specifies what to do when this action is encountered. the continuation binding is holding the rest of the program. Any action pattern can do many different things with it: ignore it, call it, call it several times, record it... In this case, we are simply ignoring it and immediately returning returnedValue (the only argument of our handler).

The second branch {a} → a is the exit branch, every ability handler have to have one. It is taken when all actions calls have been handled.

Let's try it by adding this watch expression:

> handle 
    x = 4
    Abort.cut
    x + 2 
  with 
    abortHandler 0

it evaluates to 0 as intended (our abortHandler was initiated with 0). If we remove the Abort.cut line it evaluates to 6.

So what has happened here?

The first expression was evaluated normally, x was bound to 4.
Then we hit an action that has to be handled, so we defer the control of the execution to our ability handler giving him access to the continuation of the program, the first branch of our handler is taken, the continuation is ignored and the handler first argument (0 in this case) is returned.
The x + 2 expression is never computed.

Store again

Let's take a look at a more interesting handler.

A handler for the Store ability may look like this

storeHandler storedValue = cases
  -- handling the get action
  {Store.get -> cont} ->
    handle cont storedValue with storeHandler storedValue
  -- handling the put action 
  {Store.put v -> cont} ->
    handle cont () with storeHandler v
  -- the exit case
  {a} -> a

In general an action pattern has the following structure:

{A.c p_1 p_2 p_n -> k}

Where A is the name of the ability, c is the name of the action, p_1 through p_n are patterns matching the arguments to the action, and k is a continuation for the program.

Here, our handler has 3 cases, 2 for our get and put actions plus the exit case.

The 1st and 2nd branches are using the handler recursively to handle the evaluation of the rest of the computation.

The handler is initiated with an argument (storedValue ) that we will use to keep some piece of state along handling, this is a very common pattern.

One really dummy example that uses the Store ability:

-- an helper function to update the value of our store
storeUpdate f =
  Store.put (f Store.get)

-- our dummy function that uses a mutable state 
-- in order to count the number of zeros present in a list
countZeros = cases
  -- non empty list case
  head +: tail ->
    -- first we check if the head is zero and incrementing our store value if so
    if (head == 0) then storeUpdate inc else ()
    -- then we recur with the tail of the list
    countZeros tail
  -- empty list case, we are using Store.get to obtain our stored value and return it
  [] -> Store.get

-- we are initiating the storeHandler with the value 0 
-- and handling the countZeros call with it
> handle countZeros [1,0,3,0,1,0]  
  with storeHandler 0 
-- it returns: 3

Let see what happens on the evaluation of this watch expression:

storeHandler 0 is returning a handler function that will be used to handle the countZeros [1,0,3,0,1,0] expression.
[1,0,3,0,1,0] is matching the first branch of the countZeros function, we are binding 1 to head and [0,3,0,1,0] to tail.
We test if head equals 0: this is not the case so the line evaluate to ().
On the next line, we are recurring with tail.
We still match the first branch, binding 0 to head and [3,0,1,0] to tail.
This time head equals 0. So we call storeUpdate with the inc function.
The storeUpdate function is calling Store.get.
Store.get is an action. So the control is passed to our handler.
The first branch of storeHandler is matching the Store.get action.
The continuation of the program has to be called with the value that the action is meant to return, here a Nat, that is the currently stored value (the argument passed to storeHandler initially: 0).
Since the rest of the computation may contains other actions we still have to handle, we use the same handler to do so (wrapping it around our continuation call with an handle expression).
Now we are back in the storeUpdate function, the value that we got with Store.get (0) is incremented by inc and the Store.put action is called with this new value (1).
Again, we are entering our handler, this time matching the second branch.
Like the first branch, we will resume the computation, this time passing () to the continuation since the Store.put is meant to return a value of type Unit (()). This time we will slightly change the handler to capture the new value that we want to store (1).
And it continues, incrementing our store each time a 0 is encountered until the list is empty.
When the list is empty, the second branch of countZeros is taken and we call Store.get a last time to return the result (in this particular case: 3).

Comment démarrer en Scala en 2020 ?

2020-10-26T23:00:00Z

En ce moment, on fait quelques enseignements dans le Big Data et les systèmes distribués, notamment auprès des écoles d'ingénieurs. On nous pose parfois la question : "comment on démarre avec Scala ? ... gratuitement* ?"

(*si vous avez un budget on peut "passer" pour accompagner sur Scala 2, Scala 3, le FP, ZIO ... 😉 c'est notre métier.)

Il y a beaucoup de ressources sur Scala. Cela ne manque pas. Ce qui va être clé, c'est de s'exposer aux concepts clés du langage et de faire des exercices.

Voici quelques liens :

Ce qui va être important c'est de pouvoir tester les concepts directement. Donc il va falloir installer le REPL Scala, voire IntelliJ IDEA et créer un projet pour tester le code.

Cela se passe mieux avec du soutien. Pour ça, je recommande la communauté Scala dans la langue de Molière, que l'on va trouver sur gitter/scala/fr. Il ne faut pas hésiter, il n'y a pas de mauvaises questions !

Pour continuer, il y a les ouvrages suivants (payants) :

Programming in Scala, 3rd Edition : bon livre pour débuter en Scala, incluant la patience de Martin Odersky, le père du langage.
Hands-On-Scala (les autres chapitres) : approche plus pratique sur Scala proposée par Li Haoyi (Databricks, Mill, Ammonite, FastParse).
Functional Programming, Simplified (in Scala) : un pavé proposé par Alvin Alexander proposant une des meilleures vulgarisations sur la programmation fonctionnelle en Scala que nous connaissons.

Crux Database

2020-09-15T22:00:00Z

Crux

Crux is a database developed by Juxt. It has been available as a public alpha since April 2019.

At first glance, it looks a bit like an open sourced Datomic, but without schemas and with a slightly different temporal model.

Bitemporality

While Datomic is indexing datums along a single time axis based on transaction-time (the point in time where data was transacted into the database), Crux uses a bitemporal approach, indexing datums along two axis:

transaction time
valid time

This extra time axis (valid-time) let the user populate the DB with past and future information regardless of the order in which the information arrives, and make corrections to past recordings to build an ever-improving temporal model of a given domain.

This kind of modeling takes into account the fact that our understanding of the past grows along the way. We do not know the exact state of the domain at each moment.

As an example, we can think of a criminal investigation

Crux - Open Time Store

Schemaless

Crux does not enforce any schema for the documents it stores. One reason for this is that data might come from many different places, and may not ultimately be owned by the service using Crux to query the data. This design enables schema-on-write and/or schema-on-read to be achieved outside of the core of Crux, to meet the exact application requirements.

The only requirement for a crux document is to have a :crux.db/id key

Datalog queries

Like Datomic, Crux uses datalog as a query language. In both systems Datalog queries are represented as EDN datastructures, but are not totally compatible.

Datalog is a non turing-complete subset of prolog

Unlike in Prolog,

statements of a Datalog program can be stated in any order.
Datalog queries on finite sets are guaranteed to terminate
Datalog disallows complex terms as arguments of predicates, e.g., p (1, 2) is admissible but not p(f (1), 2). It also is more restrictive about negation and recursion usage. (wiki)

Setup

To begin to play with Crux you only have to clone this project

git clone git@github.com:pbaille/crux-starter.git

If you are not familiar with Clojure you will find some instructions to setup an IDE in the readme file

Transactions

(ns crux-starter.p01_transactions
  (:require [crux.api :as crux]
            [crux-starter.p00_setup :refer [node]]))

Putting data into the database

Crux valid documents are arbitrary nested edn maps.The only requirement is the presence of a :crux.db/id key pointing to either a keyword or a map.

Let's say that we have a clojure map that fulfill this requirement.

(def data1 {:crux.db/id :data1
            :myfield "mydata"})

We can transact it to the database like this:

(crux/submit-tx node
                [[:crux.tx/put data1]])

The simplest way to retrieve it is to use crux/entity:

(crux/entity (crux/db node) :data1)
;;=> {:crux.db/id :data1, :myfield "mydata"}

The crux/db call is returning the current value of our database. If we are interested in retrieving its value at a given time, we can feed it a second argument.

(crux/db node #inst "2000") ;; returns the value of the database as in the beginning of the year 2000

As we can check, our previously trasacted :data1 document does not yet exists in 2000.

(crux/entity (crux/db node #inst "2000") :data1) ;;=> nil

crux/submit-tx can take several transactions.

(crux/submit-tx node
                [[:crux.tx/put {:crux.db/id :data2 :foo {:arbitrary {:nested "map"}}}]
                 [:crux.tx/put {:crux.db/id :data3 :data 3}]])

The :crux.tx/put operation is letting you specify the valid time frame of the given document.

(crux/submit-tx node
                [;; a document that is valid forever starting at the beginning of the year 2019
                 [:crux.tx/put {:crux.db/id :timed1 :value 10}
                  #inst "2019"]

                 ;; a document that is valid between 2017 and 2018
                 [:crux.tx/put {:crux.db/id :timed2 :value 10}
                  #inst "2017"
                  #inst "2018"]])

;; :timed1 is not yet valid in 2000
(crux/entity (crux/db node #inst "2000") :timed1)
;;=> nil

;; but is in 2019
(crux/entity (crux/db node #inst "2019") :timed1)
;;=> {:crux.db/id :timed1, :value 10}

;; timed2 not yet valid in 2000
(crux/entity (crux/db node #inst "2019") :timed2)
;;=> nil

;; but is on june 2017
(crux/entity (crux/db node #inst "2017-06") :timed2)
;;=> {:crux.db/id :timed2, :value 10}

;; but is no longer valid in 2019
(crux/entity (crux/db node #inst "2019") :timed2)
;;=> nil

Deleting (invalidating) documents

;; This form will delete (invalidate) our :timed2 entity  (that is valid in 2017 only) from august to october 2017.
(crux/submit-tx node
                [[:crux.tx/delete :timed2
                  #inst "2017-08"
                  #inst "2017-10"]])

;; still exists in january
(crux/entity (crux/db node #inst "2017-01") :timed2)
;;=> {:crux.db/id :timed2, :value 10}

;; no longer exists in september
(crux/entity (crux/db node #inst "2017-09") :timed2)
;;=> nil

;; still exists in december
(crux/entity (crux/db node #inst "2017-11") :timed2)
;;=> {:crux.db/id :timed2, :value 10}

Like :crux.tx.put, :crux.tx/delete do not have to take valid-time starts and ends.If not the data will be deleted (invalidated) from now.

(crux/submit-tx node
                [[:crux.tx/delete :timed1]])

;; :timed1 is no longer valid
(crux/entity (crux/db node) :timed1)
;;=> nil

;; but is still valid in 2019
(crux/entity (crux/db node #inst "2019") :timed1)
;;=> {:crux.db/id :timed1, :value 10}

Eviction

;; remove all historical versions of a document
(crux/submit-tx node
                [[:crux.tx/evict :one]])

Conditional transactions

One way to issue transaction only if certain condition is met is to use the :crux.tx/match operation. It let you verify the value of a database document against a given value and issue some transactions only if those are equals.

(crux/submit-tx node
                [[:crux.tx/match
                  :data1 ;; we will check this entity against next provided arg
                  {:crux.db/id :data1 :myfield "mydata"} ;; the value we check the corresponding document against
                  ]

                 ;; if the match expression succeed we will transact the following forms
                 [:crux.tx/put
                  {:crux.db/id :data1
                   :myfield "mydata"
                   :foo :bar}]]) ;; <- we had an entry to our document

(crux/entity (crux/db node) :data1)
;;=> {:crux.db/id :data1, :myfield "mydata", :foo :bar}

Like previously seen operations, crux.db/match can take a time at which to issue the matching.

(crux/submit-tx node
                [[:crux.tx/match
                  :data2
                  {:crux.db/id :data3 :data 3}
                  #inst "2019"] ;; the point in time where we do the check

                 ;; since in 2019, :data2 does not still exists, the belowing transaction is not executed
                 [:crux.tx/put
                  {:crux.db/id :data3
                   :never :occurs}]])

(crux/entity (crux/db node) :data3)
;;=> {:crux.db/id :data3, :data 3}

Modelling a simplistic bank account

;; initiating it with 2018 with 20 dollars on it
(crux/submit-tx node
                [[:crux.tx/put
                  {:crux.db/id :bank-account
                   :dollars 20}
                  #inst "2018"]])

;; for chrismass 2018 grandma gave us 20 dollars
(crux/submit-tx node
                [[:crux.tx/put
                  {:crux.db/id :bank-account
                   :dollars 40}
                  #inst "2018-12-25"]])

;; on the january first 2019, we've bought a cookie for 1 dollar
(crux/submit-tx node
                [[:crux.tx/put
                  {:crux.db/id :bank-account
                   :dollars 39}
                  #inst "2019-01"]])

;; in june 2018 we've gt 20 dollars
(crux/entity (crux/db node #inst "2018-06") :bank-account)

;; on the december 28th of 2018, we are at our peak with the amount of 40 dollars
(crux/entity (crux/db node #inst "2018-12-28") :bank-account)

;; sadly grandma is dead before christmass 2019 and we still have 39 dollars
(crux/entity (crux/db node) :bank-account)
;=> {:crux.db/id :bank-account, :dollars 39}

Transaction functions

Transaction functions are user-supplied functions that run on the individual Crux nodes when a transaction is being ingested. They can take any number of parameters, and return normal transaction operations which are then indexed as above. If they return false or throw an exception, the whole transaction will roll back.

Example 1

A transaction function that add (or substract) a given amount on our fancy :bank-account document.

Transaction functions are defined with our old friend crux.tx/put.The given document has to have a :crux.db/fn key pointing to the function code (quoted).

(crux/submit-tx node
                [[:crux.tx/put {:crux.db/id :update-bank-account
                                :crux.db/fn
                                ;; note that the function body is quoted.
                                '(fn [ctx delta]
                                   ;; the first argument (ctx) is holding our node
                                   ;; we can use it as we've done so far
                                   (let [db (crux.api/db ctx) ;; we taking the present value of the database
                                         entity (crux.api/entity db :bank-account)] ;; using it to retrieve our bank-account document
                                     ;; then we are returning a vector of transaction (containing only one in this case)
                                     [[:crux.tx/put (update entity :dollars + delta)]]))}]])

(crux/submit-tx node
                [[:crux.tx/fn :update-bank-account 5]])

(crux/entity (crux/db node) :bank-account)

Exemple 2

A transaction function that can create a new document by merging existing/given ones.

(crux/submit-tx node
                [[:crux.tx/put {:crux.db/id :merge
                                :crux.db/fn
                                '(fn [ctx id & xs]
                                   (let [db (crux.api/db ctx)]
                                     [[:crux.tx/put
                                       (reduce merge
                                               {:crux.db/id id}
                                               (map (fn [e]
                                                      (cond
                                                        (keyword? e) (dissoc (crux.api/entity db e) :crux.db/id)
                                                        (map? e) e))
                                                    xs))]]))}]])

(crux/submit-tx node
                [ ;; putting 2 dummy records into the db
                 [:crux.tx/put {:crux.db/id :m1 :a 1 :b 2}]
                 [:crux.tx/put {:crux.db/id :m2 :a 4 :c 3}]
                 ;; use them to built another dummy record via our freshly defined merge transaction function
                 [:crux.tx/fn :merge :m3 :m1 :m2 {:d 5}]])

(crux/entity (crux/db node) :m3)
;;=> {:crux.db/id :m3, :a 4, :b 2, :c 3, :d 5}

Example 3

A transaction function that let you extend your document with new key (semantically similar to clojure's assoc).

(crux/submit-tx node
                [[:crux.tx/put {:crux.db/id :assoc
                                :crux.db/fn
                                ;; note that the function body is quoted.
                                '(fn [ctx eid & kvs]
                                   (let [db (crux.api/db ctx)
                                         entity (crux.api/entity db eid)]
                                     [[:crux.tx/put (apply assoc entity kvs)]]))}]])

(crux/submit-tx node
                [[:crux.tx/put {:crux.db/id :ivan, :age 40}]])

(crux/submit-tx node
                [[:crux.tx/fn :assoc :ivan :genre :M]])

(crux/entity (crux/db node) :ivan)
;;=> {:crux.db/id :ivan, :age 40, :genre :M}

Speculative transactions

;; with the `crux/with-tx` function, we are creating an enriched database value without persisting anything to the system
(def speculative-db
  (crux/with-tx (crux/db node)
                [[:crux.tx/put {:crux.db/id :speculative-doc1 :value 42}]]))

We can check that the added document does not exist in our real database.

(crux/entity (crux/db node)
             :speculative-doc1)
;=> nil

;; and that it exists in our speculative db
(crux/entity speculative-db
             :speculative-doc1)
;=> {:crux.db/id :speculative-doc1, :value 42}

;; we can issue queries over our speculative db
(crux/q speculative-db
        '{:find [x]
          :where [[x :value 42]]})
;=> #{[:speculative-doc1]}

Queries

(ns crux-starter.p02_queries
  (:require [crux.api :as crux]
            [crux-starter.p00_setup :refer [node]]
            [crux-starter.sugar :refer [puts q]]))

Data

Putting some data to play with in the database:

(puts

  {:id :philippe
   :name "Philippe"
   :genre :M
   :age 70}

  {:id :odette
   :name "Odette"
   :genre :F
   :age 71}

  {:id :jean-pierre
   :name "Jean-Pierre"
   :genre :M
   :age 40
   :mother :odette
   :father :philippe}

  {:id :blandine
   :name "Blandine"
   :genre :F
   :age 43}

  {:id :blandine
   :name "Valerie"
   :genre :F
   :age 35}

  {:id :pierre
   :name "Pierre"
   :genre :M
   :age 20
   :father :jean-pierre
   :mother :blandine}

  {:id :clement
   :name "Clément"
   :genre :M
   :age 19
   :father :jean-pierre
   :mother :blandine}

  {:id :mathilde
   :name "Mathilde"
   :genre :F
   :age 12
   :father :jean-pierre
   :mother :valerie}

  {:id :nicolas
   :name "Nicolas"
   :genre :M
   :age 9
   :father :jean-pierre
   :mother :valerie}

  )

Basics

;; attribute existence
;; find every documents that have a `:father` attribute
(q '{:find [x]
     :where [[x :father]]})
;=> #{[:clement] [:jean-pierre] [:mathilde] [:nicolas] [:pierre]}

;; finds all males
(q '{:find [p]
     :where [[p :genre :M]]})
;;=> #{[:clement] [:jean-pierre] [:nicolas] [:pierre]}

;; find sons of Valerie
(q '{:find [p]
     :where [[p :genre :M]
             [p :mother :valerie]]})
;;=> #{[:nicolas]}

;; names of blandine's children
(q '{:find [n]
     :where [[p :mother :blandine]
             [p :name n]]})
;;=> #{["Pierre"] ["Clément"]}

;; retrieve full entities
(q '{:find [p]
     :where [[p :genre :M]]
     :full-results? true})

Predicates

;; finds all adults
(q '{:find [p]
     :where [[p :age a]
             ;; predicates expressions have to be wrapped in vector literal
             [(>= a 18)]]})

;; arithmetic constraints can take logic variables as arguments
(q '{:find [p q]
     :where [[p :age pa]
             [q :age qa]
             [(> pa qa)]]})

;; regular functions
(q '{:find [p half-age]
     :where [[p :age a]
             ;; we can catch the return value into a var
             [(/ a 2) half-age]]})

;; find couples of persons such that the first is two times older than the second
(q '{:find [p q]
     :where [[p :age pa]
             [q :age qa]
             [(/ pa 2) qa]]})

Logic connectors

;; or
(q '{:find [x]
     :where [(or [x :name "Nicolas"]
                 [x :name "Mathilde"])]})

;; in this simple case we could use set literal
(q '{:find [x]
     :where [[x :name #{"Mathilde" "Nicolas"}]]})

;; nested `or` and `and`
(q '{:find [x age]
     :where [(or (and [x :name "Nicolas"] [x :age age])
                 (and [x :father :jean-pierre]
                      [x :age age]
                      (or [(= age 12)]
                          [(> age 19)])))]})

Rules

Rules let you abstract clauses and create a more readable language for your queries.For instance we will create a parent rule wich describe a parent relationship between its two arguments(parent a b) means that a is a parent of b (either father or mother).

(q '{:find [a b]
     ;; introducing the parent rule
     :rules [[(parent b a) (or [a :mother b] [a :father b])]]
     ;; using it
     :where [(parent a b)]
     })

Rules are also a great way to express traversal relationships. Here we will define an anccestor rule.

(q '{:find [x]
     ;; we define ancestor in terms of parent
     :rules [[(parent p c) (or [c :mother p] [c :father p])]
             ;; ancestors have 2 cases
             [(ancestor a b) (parent a b)] ;; direct parent
             [(ancestor a b) (parent a pa) (ancestor fa b)] ;; transitive parent
             ]

     :where [(ancestor :odette x)]})
;;=> #{[:clement] [:jean-pierre] [:mathilde] [:nicolas] [:pierre]}

Ordering and pagination

(q '{:find [p age]
     :where [[p :age age]]
     :order-by [[age :asc]]})

#_[[:nicolas 9]
   [:mathilde 12]
   [:clement 19]
   [:pierre 20]
   [:blandine 35]
   [:jean-pierre 40]
   [:philippe 70]
   [:odette 71]]

(q '{:find [p age]
     :where [[p :age age]]
     :order-by [[age :asc]]
     :limit 4 ;; limits the number of results to 4
     :offset 2}) ;; starting at index 2

#_[[:clement 19]
   [:pierre 20]
   [:blandine 35]
   [:jean-pierre 40]]

EQL projections

Crux queries support a 'projection' syntax, allowing you to decouple specifying which entities you want from what data you’d like about those entities in your queries. Crux’s support is based on the excellent EDN Query Language (EQL) library.

(puts
  {:crux.db/id :lawyer, :profession/name "Lawyer"}
  {:crux.db/id :doctor, :profession/name "Doctor"}
  {:crux.db/id :u1, :user/name "Ivan", :user/profession :doctor},
  {:crux.db/id :u2, :user/name "Sergei", :user/profession :lawyer}
  {:crux.db/id :u3, :user/name "Petr", :user/profession :doctor})

(q '{:find [(eql/project ?user [:user/name {:user/profession [:profession/name]}])]
     :where [[?user :user/name ?uid]]})

Conclusion

In this article, we've got a brief overview of crux main ideas and API, many things remains to be seen,
like the infrastructure and deployment parts. I hope to be able to cover this in further articles, so stay tuned!

Modifier les variables d'environnements en Scala

2020-09-08T22:00:00Z

C'est parfois nécessaire pour des tests unitaires. Le problème est que sys.env, System et ProcessEnvironment sont immuables. Ce n'est pas grave, on va faire un peu de réflexion 😁

def setEnv(name: String, value: String): Unit = {
  val processEnvClass =
    Class.forName("java.lang.ProcessEnvironment")
  val unmodifiableEnvironmentField =
    processEnvClass.getDeclaredField("theUnmodifiableEnvironment")
  unmodifiableEnvironmentField.setAccessible(true)
  val unmodifiableEnvironment =
    unmodifiableEnvironmentField.get(null)

  val unmodifiableMapClass =
    Class.forName("java.util.Collections$UnmodifiableMap")
  val mField =
    unmodifiableMapClass.getDeclaredField("m")
  mField.setAccessible(true)
  val map =
    mField
      .get(theUnmodifiableEnvironment)
      .asInstanceOf[java.util.Map[String, String]]

  map.put(name, value)
}

Note : ça concerne principalement Scala, car dans ce langage on utilise principalement sys.env pour accéder aux variables d'environnement.

En Java, si on passe par System.getenv (majorité des cas), il n'y a pas de problème non plus. sys.env utilise d'ailleurs par cette méthode. Par contre, si vous utilisez, ProcessBuilder.environment vous ne verrez pas de modification dans les variables d'environnement, car cette méthode procède différemment pour les récupérer.

Photographie par Dan Meyers sur Unsplash.

Glycogen

2020-06-14T22:00:00Z

Motivation

In Clojure(Script), when fast polymorphic functions are needed, we are typically using Protocols.

As an example, we will introduce a protocol for adding things together.

(defprotocol IPlus
  (plus [x y] "add two things together"))

Then we extend this protocol to some types

(extend-protocol IPlus
   clojure.lang.IPersistentVector
   (plus [x y] (into x y))
   clojure.lang.IPersistentMap
   (plus [x y] (merge x y))
   clojure.lang.ISeq
   (plus [x y] (merge x y)))

If you are also targeting ClojureScript, you can use reader conditionals

(extend-protocol IPlus
  #?(:clj  clojure.lang.PersistentVector
     :cljs cljs.core/PersistentVector)
  (plus [x y] (into x y))
  #?(:clj  clojure.lang.IPersistentMap
     :cljs cljs.core/PersistentArrayMap)
  (plus [x y] (merge x y))
  #?(:clj  clojure.lang.ISeq
     :cljs cljs.core/List)
  (plus [x y] (concat x y)))

Those reader conditionals can become a bit noisy when this kind of code is strongly used in a project.

Let's check that everything is working as intended

(is (plus [1 2 3] [4 5 6])
    [1 2 3 4 5 6])

(is (plus {:a 1 :b 2} {:b 22 :c 3})
    {:a 1 :b 22 :c 3})

(is (plus (list 1 2) (list 1 2))
    (list 1 2 1 2))

It seems to work! But in fact, this is not so easy in ClojureScript:

(plus (range 4) (list 1 2)) 
;; this fails, complaining there is no implementation for cljs.core/Range

You may think that I should extend ISeq instead of cljs.core/List? But it does not work, because ClojureScript does not have interfaces like Clojure. To obtain the same thing that we have in Clojure, in ClojureScript we have to write this:

(extend-protocol IPlus
   cljs.core/PersistentVector
   (plus [x y] (into x y))
   ;; duplicated impls to cover all IMap
   cljs.core/PersistentArrayMap
   (plus [x y] (merge x y))
   cljs.core/PersistentHashMap
   (plus [x y] (merge x y))
   cljs.core/PersistentTreeMap
   (plus [x y] (merge x y))
   ;; same here
   cljs.core/List
   (plus [x y] (concat x y))
   cljs.core/Range
   (plus [x y] (concat x y))
   ;; ... many other duplicates for covering ISeq
   ;; complete list of classes actually is:
   ;; ArrayNodeSeq ChunkedCons ChunkedSeq Cons Cycle ES6IteratorSeq
   ;; EmptyList IndexedSeq Iterate KeySeq LazySeq List NodeSeq PersistentArrayMapSeq
   ;; PersistentQueue PersistentQueueSeq PersistentTreeMapSeq RSeq Range RangeChunk Repeat ValSeq
   )

Obviously, this is not really what we want... so i've wrote the Glycogen library

Proposition

If we forget about implementation details, the code defined above could be defined like this:

(defg plus [x y]
      :map (merge x y)
      :vec (into x y)
      :lst (concat x y))

We immediately spot the point here, not bothering with platform specific stuff. The defg macro is part of the glycogen.generics namespace.

So, as you see, the classes of the target platforms (and reader conditionals) have disappeared and the problematic expression works as intended.

(is (plus (range 4) (list 1 2))
    (list 0 1 2 3 1 2))

Of course this is a simple case. There is only one arity and no destructuration patterns (all cases are sharing the same argument vector pattern, this is not always what we want, sometimes one implementation need its own destructuring pattern. We will address these considerations at a later point. For now lets discuss those type-keywords that we are using to indicate the type(s) that each implementation belongs to. (e.g: :map :vec :lst ...)

To add glycogen to your project simply add glycogen {:mvn/version "0.1.1-SNAPSHOT"} to your deps.edn

Hidding host classes

One of the stepping stone on which this library is built upon is a little wrapper around hosting platform's type hierarchies that acts as a compatibility layer and let us forget about it.

It resides in the glycogen.types namespace.

(require '[glycogen.types :as t] 
         '[glycogen.state :as state])

The idea is really simple, there is one type register per target platform consisting of a map of type: keyword -> set of keyword or class-symbol

from clojure you can inspect it like this:

;; clojure's type registry
(t/get-reg)
;;=>
'{ 
   ;; primitives
	 :nil #{nil},
	 :num #{java.lang.Number},
	 :fun #{clojure.lang.Fn},
	 :lst #{clojure.lang.ISeq},
	 :vec #{clojure.lang.IPersistentVector},
	 :key #{clojure.lang.Keyword},
	 :sym #{clojure.lang.Symbol},
	 :str #{java.lang.String},
	 :link #{clojure.lang.MapEntry},
	 :set #{clojure.lang.IPersistentSet},
	 :map #{clojure.lang.PersistentArrayMap clojure.lang.PersistentHashMap},
	
	 ;; aggregates
	 :line #{:lst :vec},
	 :word #{:key :sym :str},
	 :hash #{:set :map},
	 :atom #{:num :fun :key :sym :str :link},
	 :coll #{:lst :vec :set :map},
	 :prim #{:num :fun :lst :vec :key :sym :str :link :nil :set :map}}

To see the clojurescript type registry:

(state/targeting-cljs (t/get-reg))
;;=>
 '{:nil #{nil}
   :num #{number},
   :fun #{function},
   :key #{Keyword},
   :sym #{Symbol},
   :str #{string},
   :link #{MapEntry},
   :set #{PersistentTreeSet PersistentHashSet},
   :map #{ObjMap PersistentHashMap PersistentTreeMap PersistentArrayMap},
   :vec #{MapEntry BlackNode Subvec RedNode PersistentVector},
   :lst #{IndexedSeq LazySeq PersistentTreeMapSeq NodeSeq PersistentArrayMapSeq ES6IteratorSeq ChunkedSeq 
          Cons Iterate RSeq ArrayNodeSeq Cycle ChunkedCons ValSeq Repeat PersistentQueueSeq EmptyList 
          PersistentQueue Range KeySeq List},
   
  :hash #{:set :map},
  :coll #{:lst :vec :set :map},
  :line #{:lst :vec},
  :word #{:key :sym :str},
  :atom #{:num :fun :key :sym :str :link},
  :prim #{:num :fun :lst :vec :key :sym :str :link :nil :set :map}}

Those type registry are certainly not complete but I think that's enough to see the point.

Along with the definitions of those registries, the glycogen.types namespace is defining some handy functions and macros to play with types :

;; basic hierarchy informations

(t/childs :coll)
;; is getting all children of a type =>
'[:lst
 :vec
 :set
 :map
 clojure.lang.ISeq
 clojure.lang.PersistentArrayMap
 clojure.lang.IPersistentSet
 clojure.lang.PersistentHashMap
 clojure.lang.IPersistentVector]

(t/parents :fun)
;; is getting all parents of a type=>
'(:atom :prim)

(t/classes :coll)
;; is getting all classes the type is belonging to =>
'(clojure.lang.ISeq
  clojure.lang.IPersistentVector
  clojure.lang.IPersistentSet
  clojure.lang.PersistentArrayMap
  clojure.lang.PersistentHashMap)

;; set litterals can be used to denotes union types
(t/childs #{:lst :vec})
;; returns all children for types :lst and :vec =>
'(clojure.lang.ISeq clojure.lang.IPersistentVector)

(t/childof :vec :coll) ;=> :vec (indicating success)

(t/parentof #{:str :sym} :sym) ;=> #{:sym :str}

(t/parentof :word #{:str :sym}) ;=> :word

(t/parentof :word #{:str :vec}) ;=> false

;; isa

(t/isa :num 1) ;;=> 1

(t/isa :coll []) ;;=> []

;; glycogen.types/isa is a macro, the below call expands to a fast typecheck :

((clojure.core/fn
  [G__4117]
  (clojure.core/when
    (clojure.core/or
      (clojure.core/seq? G__4117)
      (clojure.core/vector? G__4117)
      (clojure.core/set? G__4117)
      (clojure.core/map? G__4117))
    G__4117))
[])

;; you can use set notation here to

(t/isa #{:sym :line} 'aze) ;=> 'aze
(t/isa #{:sym :line} (list 1 2 3))) ;=> '(1 2 3)

The glycogen.types namespace is Clojure only, so you may wonder about Clojurescript... in fact it is not intended to expose anything at runtime in Clojurescript, it serves only at compile time when a macro is expanded, depending on the targeted platform, the type registry of Clojure or Clojurescript is used.

Usage

Now we've seen how glycogen.types works we will return to our initial intent, which is to be able to define generic functions in a more concise and powerful way.

Let's recap the points in which protocols declarations and implementations could be improved:

Be able to share implementations
Support for variadic arity
Avoiding to write reader conditionals
Type less, grasp the intent faster
Be able to clone an existing generic fonction
Partial implementation

Let's first import the library:

(ns glycogen.demo
  (#?(:clj :require :cljs :require-macros)
   [glycogen.generics :as g]))

Declaration

(g/defg fmap 
        "apply one or several function to something"
        ([this f])
        ([this f & fs]))

Here we are declaring a fmap generic function with a docstring a fixed arity and a variadic one.

Extension

(g/generic+ fmap

  ([x f] ;; arity 2

   ;; variadic arity
   :vec (mapv f x)

   ;; set literal can be used to implement several types at once
   #{:set :map} (into (empty x) (map f x))

   ;; the default case (if x does not implement fmap)
   (f x))



  ([x f & fs] ;; variadic arity

   ;; we have only a default case here
   (reduce fmap x (cons f fs))))

All at once

(g/defg fmap

  "apply one or several function to something"

  ([x f]
   :vec (mapv f x)
   #{:set :map} (into (empty x) (map f x))
   (f x))

  ([x f & fs]
   (reduce fmap x (cons f fs))))

So in this exemple we have addressed several points

variadic arity
code deduplication
hiding target platform details

Let's try fmap:

(is (fmap [1 2 3] inc)
    [2 3 4])

(is (fmap {:a 1 :b 2} (comp vec reverse))
    {1 :a, 2 :b})

;; variadic arity
(is (fmap [1 2 3] inc inc)
    [3 4 5])

One other thing that is I think a little annoying in clojure is that each implementer have to define all arities of the implemented generic. with glycogen's generics it is not mandatory, in the below exemple, the variadic arity has only a default case, it will be the implementation used for any type that implement only the arity 2 (in this case).

Let's add an implementation of fmapfor lists.

(g/generic+ fmap [x f]
  :lst (map f x))

(is (fmap (range 4) inc)
    '(1 2 3 4))

In clojure we would have been forced to give implementation for every arities of fmap. Here it is not the case, we can verify it by trying to use the variadic arity of fmapon a list.

(is (fmap (range 4) inc inc)
    '(2 3 4 5))

We can even only overide the variadic arity if needed:

(g/generic+ fmap [x f & fs]
  :lst
  (do (println "smart variadic fmap")
      (fmap x (apply comp (reverse (cons f fs))))))

(is (fmap (range 4) inc inc)
    '(2 3 4 5)) ;; prints "smart variadic fmap"

Related operations

In addition to def-protocol and extend-protocol, in clojure we have related operations like extend-type, defrecord, reify etc...

`thing`

In clojure and clojurescript we have reify that creates an anonymous class that implements some protocols. Here we can do roughly the same with glycogen.generics/thing.

(let [mything
      ;; we are creating an anonymous class that implement 
      ;; the previously defined generics in a really dummy way
      (g/thing (fmap [x f] [:fmaped x f])
               (plus [x y] [:plused x y]))]
  ;; checks
  (is (plus mything 1)
      [:plused mything 1])
  (is (fmap mything inc)
      [:fmaped mything inc]))

`fork`

One other thing that may be useful sometimes is the ability to stole a generic from somewhere else and build a new one by overriding some parts of the original one (without altering the original one and the code that depends on it). For this we have the glycogen.generics/fork operator.

(g/fork fmap ;; the generic that we are cloning/forking
        tweaked-fmap ;; the name that will hold the copy
        ;; it takes the same body format as defg or generic+
        ;; here we are only overiding the arity 2 implementation for vectors
        [x f]
        :vec (do (println "tweaked fmap") (mapv f x)))

(tweaked-fmap [1 2 3] inc) ;; printing "tweaked fmap"

The tweaked-fmap generic now exists on its own and is completly hermetic to fmap further changes/extensions.

`type+`

There is something similar to extend-type and its name is glycogen.generics/type+

Here we are extending the type :num to our previously defined generics (plus and fmap)

(g/type+ :num
         (fmap [x f] (println "fmaping num") (f x))
         (plus [x y] (+ x y)))

(is (with-out-str
      (is (fmap 1 inc)
          2))
    "fmaping num\n")

(is (plus 1 2)
    3)

`deft`

One thing we are still missing is the ability to introduce new types the way deftype or defrecord do it.

The deft macro is similar to defrecord but let you implement generics.

We will define a :pair type holding two fields car and cdr

Along with defining a new record, the deft macro defines some useful functions to work with your type:

a constructor function (here pair)
a casting generic function (here →pair) that can be implemented by other types in order to cast into the defined type.

(g/deft :pair ;; the type tag
        [car cdr] ;; the fields
        ;; generics implementations
        ;; note that the constructor function is available (pair)
        (plus [_ y] (pair car (if cdr (plus cdr y) y)))
        (fmap [_ f] (pair (f car) (when cdr (fmap cdr f)))))

(defn lst [& xs]
  (reduce (fn [p x] (pair x p))
          nil (reverse xs)))

(is (fmap (plus (lst 1 2 3) (lst 4 5 6))
          inc)
    (lst 2 3 4 5 6 7))

more about `defg`

precedence

The order of implementations matters, the semantics are similar to clojure/cond, the first implementation have priority on the laters.

(g/defg whoami [x]
        :vec "I'm a vector"
        :coll "I'm a collection")

(is (whoami [1 2])
    "I'm a vector")

(is (whoami (list 1 2))
    "I'm a collection")

bindings

As mentioned previously, sharing the binding pattern accross all the implementations of an arity is not always what we want. But in fact you can provides several times the same arity with different binding patterns.

To demonstrate this we will extend the ->pair generic that convert something to a pair (and has been automatically declared by the deft exemple above).

(g/generic+ ->pair 

      ([[car & cdr]] 
       :coll (pair car cdr))

      ([x] 
       :pair x 
       (pair x nil)))

(is (->pair [1 2 3])
    (->pair (list 1 2 3))
    (pair 1 (list 2 3)))

(is (->pair 1)
    (pair 1 nil))

Under the hood

In order for all of this to work we cannot map directly to clojure's protocol, I mean that in fact when defining a polyarity generic several protocols are defined, one for each arity and one for the variadic arity.

Let's take a look at the macro expansion of defg

'(do
   ;; first are doing some var cleaning, if the defined 
   ;; generic already exists we are removing related vars (a common case in dev)
  (do
    (clojure.core/ns-unmap (quote glycogen.article) (quote plus))
    (clojure.core/ns-unmap (quote glycogen.article) (quote p_plus_3))
    (clojure.core/ns-unmap (quote glycogen.article) (quote Iplus_3))
    (clojure.core/ns-unmap (quote glycogen.article) (quote p_plus_2))
    (clojure.core/ns-unmap (quote glycogen.article) (quote Iplus_2)))
   
   ;; for each arity of the defined generic we are defining a protocol
  (do
    ;; the arity 3 is holding our variadic arity
    (clojure.core/defprotocol glycogen.article/Iplus_3 (p_plus_3 [a_5712 a_5713 a_5714]))
    (clojure.core/defprotocol glycogen.article/Iplus_2 (p_plus_2 [a_5715 a_5716])))
   
   ;; we are wrapping all this in a function that will be the user calling interface
  (clojure.core/defn
    plus
    ;; the arity 2 is simply wrapping the arity 2 protocol
    ([a_5715 a_5716] (p_plus_2 a_5715 a_5716))
    ;; the variadic arity wraps the rest argument and uses the arity 3 protocol
    ([a_5712 a_5713 & a_5714] (p_plus_3 a_5712 a_5713 a_5714)))
   
   ;; for each implementation we are defining a var, it can serves several purposes, 
   ;; one is to easily implement copying of generics across namespaces
   ;; one other is to be able to inline some implementations (in some compiler context, no-one wants to see those wierd names in code)
  (do
    (do
      (clojure.core/ns-unmap (quote glycogen.article) (quote plus_2_IMPL_lst))
      (clojure.core/defn plus_2_IMPL_lst ([x y] (concat x y))))
    (do
      (clojure.core/ns-unmap (quote glycogen.article) (quote plus_2_IMPL_vec))
      (clojure.core/defn plus_2_IMPL_vec ([x y] (into x y))))
    (do
      (clojure.core/ns-unmap (quote glycogen.article) (quote plus_2_IMPL_map))
      (clojure.core/defn plus_2_IMPL_map ([x y] (merge x y))))
    
    ;; note that a default case that throw a "missing implementation" 
    ;; error is automatically defined when no default case in given by the user
    (do
      (clojure.core/ns-unmap (quote glycogen.article) (quote plus_2_IMPL_any))
      (clojure.core/defn
        plus_2_IMPL_any
        ([x y]
         (glycogen.prelude/error
           "missing implementation for generic: "
           (quote plus)
           "\npattern:\n"
           (quote [x y])
           "\nwhere:\n"
           {(quote x) x, (quote y) y}))))
    (do
      (clojure.core/ns-unmap (quote glycogen.article) (quote plus_3_IMPL_any))
      (clojure.core/defn plus_3_IMPL_any ([x y ys] (reduce plus (plus x y) ys)))))
   
   ;; then we are actually extending defined protocols (in clojurescript extend-type is used)
  (do
    (clojure.core/extend clojure.lang.ISeq glycogen.article/Iplus_2 {:p_plus_2 plus_2_IMPL_lst})
    (clojure.core/extend clojure.lang.IPersistentVector glycogen.article/Iplus_2 {:p_plus_2 plus_2_IMPL_vec})
    (clojure.core/extend clojure.lang.PersistentArrayMap glycogen.article/Iplus_2 {:p_plus_2 plus_2_IMPL_map})
    (clojure.core/extend clojure.lang.PersistentHashMap glycogen.article/Iplus_2 {:p_plus_2 plus_2_IMPL_map})
    (clojure.core/extend Object glycogen.article/Iplus_2 {:p_plus_2 plus_2_IMPL_any})
    (clojure.core/extend Object glycogen.article/Iplus_3 {:p_plus_3 plus_3_IMPL_any}))
   
   ;; finally we are returning the main function 
  plus)

Further ideas

Generic function should maybe being able to be anonymous and used as lambdas are. For exemple:

(let [f (fg [x] 
            :coll [:coll x] 
            :atom [:atom x]
            [:any x])]
  (is (f {:a 1})
      [:coll {:a 1}])
  (is (f 1)
      [:atom 1]))

But it brings several question to the table

how can we simulate closure behavior? is it even possible?
memory management

SBT pour centraliser et homogénéiser la déclaration de services

2020-06-03T22:00:00Z

Si dans un projet, vous vous retrouvez à gérer plusieurs services, il peut être intéressant de centraliser la configuration (ou du moins la configuration par défaut) de ces services sur des paramètres comme le port d'écoute HTTP, les endpoints d'API Rest ou, pour des applications Kafka, le nom des topics communicants entre les services. L'idée est d'éviter des collisions (comme pour le port d'écoute HTTP) ou de taper à côté (comme pour les topics Kafka) et de s’éviter des heures de debugging sur des erreurs futiles s’étendant à un seul caractère. Si vous avez en plus un moyen à la fois concis et homogène de configurer vos services et mettre en avant leur interdépendance, vous pouvez rapidement analyser la structure du projet.

Dans ce cas, pourquoi ne pas utiliser l'outil de build pour mettre en place cette centralisation. Nous allons voir ça avec SBT.

Quelques mots sur SBT

SBT, le Maven du monde Scala, est un outil qui n'est pas facile à maîtriser. Il a cependant des capacités de personnalisation qui sont assez importantes.

En effet, la gestion d'un projet sous SBT ne se base pas sur un fichier de description (XML, JSON, YAML...), mais sur des fichiers utilisant le langage Scala. Ceci permet d’utiliser toute la capacité du langage pour mettre en place un DSL (Domain Specific Language) et obtenir un style de déclaration de projet adapté à la définition de nos services.

Déclarer des services Kafka Streams

L’idée est d’avoir l’approche la plus déclarative pour décrire nos services. Ce qui veut dire que notre fichier de build doit permettre de comprendre très rapidement quelle est la structure du projet, quels sont les services, comment est-ce qu’ils interagissent entre eux et comment les monitorer.

Pour ça, nous allons créer dans le répertoire project/ le fichier BuildHelper.scala et allons y créer une fonction qui permet de déclarer des sous-modules représentant des services.

Voici la signature de la fonction serviceProject pour déclarer des services Kafka Streams avec une API Rest de monitoring, destinés à composer notre pipeline de traitement.

import sbt._
import sbt.Keys

object BuildHelper {

  def serviceProject(
      serviceName: String,
      port: Int,
      inputStream: Option[String] = None,
      outputStream: Option[String] = None
  ): Project = ???

}

La structure du projet est ainsi plus visible. Avec une section déclarant en un seul lieu les topics disponibles, nous évitons des erreurs de nom ,par exemple , le nom des topics a changé plusieurs fois et qu’on a oublié de propager la modification dans certains services. Nous pouvons aussi utiliser des variables pour mettre en valeur la dépendance en terme de topic entre les services. Sur un autre aspect, les collisions de port d’écoute HTTP sont plus aisés à détecter.

Ainsi, les services sont plus homogènes et leur déclaration est plus simple à écrire et à lire.

import BuildHelper._

lazy val root =
  (project in file("."))
  .aggregate(serviceCommon, serviceSerde, serviceIngest, serviceProcess, serviceExport)

// ---- TOPIC NAMES ----------------

val streams = new {
  val data        = "data-stream"
  val event       = "event-stream"
  val information = "information-stream"
}

// ---- SERVICE DECLARATION ----------------

lazy val serviceIngest =
  serviceProject(
    serviceName  = "service-ingest",
    port         = 10001,
    inputStream  = Some(streams.data),
    outputStream = Some(streams.event)
  )
  .settings(commonSettings)
  .dependsOn(serviceCommon, serviceSerde)

lazy val serviceProcess =
  serviceProject(
    serviceName  = "service-process",
    port         = 10002,
    inputStream  = Some(streams.event),
    outputStream = Some(streams.information)
  )
  .settings(commonSettings)
  .dependsOn(serviceCommon, serviceSerde)

lazy val serviceExport =
  serviceProject(
    serviceName  = "service-export",
    port         = 10003,
    inputStream  = Some(streams.information),
    outputStream = None
  )
  .settings(commonSettings)
  .dependsOn(serviceCommon, serviceSerde)

// ---- ADDITIONAL SUBMODULES ----------------

lazy val serviceCommon =
  (project in file("service-common")) // ...

lazy val serviceSerde =
  (project in file("service-serde")) // ...

// ---- COMMONS ----------------

// settings necessary for the current pipeline
lazy val commonSettings =
  Def.settings(/* ... */)

Ce qui correspond au diagramme suivant.

SBT permet la génération de fichier comme tout bon outil de build et ça vaut pour les fichiers de configuration. En se basant sur la déclaration vue précédemment, on peut générer automatiquement une configuration par défaut. En utilisant un format de fichier de configuration comme HOCON, il est possible de surcharger cette configuration par défaut. Voici un exemple de configuration générée automatiquement à partir de la déclaration vue avant.

service {
  name = "service-ingest"
  http {
    port = 10001
  }
  kafka {
    bootstrapServers  = "localhost:9092"
    schemaRegistryUrl = "localhost:8081"
  }
}
topics {
  inputStream  = "data-stream"
  outputStream = "event-stream"
}

Par contre, contrairement à la génération automatique de code source qui se déclenche lors de l'étape de compilation, la génération automatique de fichier de ressource se déclenche lors du run du service ou à l'étape package.

Pour intégrer cette configuration et éventuellement la surcharger, à supposer que le fichier se trouve dans target/scala-*/resource_managed/main/service-generated/application-generated.conf, votre application.conf ressemblera à

include classpath("service-generated/application-generated.conf")

Implémentation

Nous allons tout d'abord inclure le plugin sbt-native-packager, afin d'avoir un exemple avec un plugin à configurer pour chaque service. On peut aussi faire de même avec d'autres plugins comme sbt-buildinfo.

addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "1.7.2")

Ci-dessous, nous avons l'implémentation de serviceProject. Cette fonction assure différentes tâches :

La déclaration du sous-module
La déclaration du répertoire du sous-module
La déclaration de l'identifiant du sous-module (utilisé pour la navigation entre sous-modules dans le CLI de SBT)
La déclaration du nom du projet
La déclaration de la main class
L'ajout d'une tâche dans la génération automatique des fichiers de ressources pour générer la configuration par défaut du service, en suivant l'approche recommandée dans SBT

  def serviceProject(
      serviceName: String,
      port: Int,
      inputStream: Option[String] = None,
      outputStream: Option[String] = None
  ): Project = {
    val nameParts        = serviceName.split("-")
    val projectId        = nameParts.head + nameParts.tail.map(_.capitalize).mkString
    val packageName      = s"io.univalence.service.${nameParts.last}"
    def serviceMainClass = s"Service${nameParts.last.capitalize}Main"

    Project(projectId, new File(serviceName))
      .enablePlugins(JavaAppPackaging)
      // basic settings required by all services
      // (set anything like scalac options, dependencies, test configuration...)
      .settings(serviceSettings)
      .settings(
        name                 := serviceName,
        mainClass in Compile := Some(s"$packageName.$serviceMainClass")
      )
      .settings(
        // add resource generation task for the default config of the service
        Compile / resourceGenerators += Def.task {
          // get path of the generated file
          val confFile = (Compile / resourceManaged).value / "service-generated" / "application-generated.conf"

          val files =
            generateServiceConfig(
              confFile     = confFile,
              serviceName  = serviceName,
              defaultPort  = port,
              inputStream  = inputStream,
              outputStream = outputStream
            )

          streams.value.log.info(s"generated $files")

          files
        }.taskValue
      )
  }

La génération de la configuration par défaut va se baser sur une fonction qui utilise un template. J'utilise ensuite la fonction IO.write pour écrire dans le fichier. La fonction doit renvoyer un Seq[File].

  def generateServiceConfig(
      confFile: File,
      serviceName: String,
      defaultPort: Int,
      inputStream: Option[String],
      outputStream: Option[String]
  ): Seq[File] = {
    val isParam = inputStream.map(is => s"""inputStream  = "$is"""").getOrElse("")
    val osParam = outputStream.map(os => s"""outputStream = "$os"""").getOrElse("")

    val content =
      s"""service {
       |  name = "$serviceName"
       |  http {
       |    port = $defaultPort
       |  }
       |  kafka {
       |    bootstrapServers  = "localhost:9092"
       |    schemaRegistryUrl = "localhost:8081"
       |  }
       |}
       |topics {
       |  $isParam
       |  $osParam
       |}
       |""".stripMargin

    IO.write(confFile, content)

    Seq(confFile)
  }

Conclusion

SBT permet d’utiliser les capacités du langage Scala pour mettre en place un DSL adapté à la déclaration des services qui composent notre projet. Un tel DSL doit permettre de comprendre rapidement la structure du projet et de détecter les dépendances entre ses composants en les centralisant. L’implémentation d’un tel DSL n’est vraiment compliqué mais nécessite de connaître le fonctionnement de SBT. La documentation de SBT est à ce titre nécessaire et assez bien fournie.

Photographie par Steve Harvey sur Unsplash

Des microservices Kafka Streams avec ZIO et http4s

2020-05-06T22:00:00Z

Kafka Streams propose depuis la version 0.10.0.0 de Kafka un paradigme intéressant pour traiter des données au fil de l'eau. Comme son nom l'indique, il se base déjà sur Kafka qui propose une plateforme de traitement en streaming parmi les plus performantes actuellement (bon, il y a aussi Pulsar). Et puis Kafka Streams propose une API avec des opérations que nous retrouvons fréquemment en programmation fonctionnelle (map, flatMap, reduce...). Enfin, Kafka Streams nous pousse à nous orienter vers une architecture micro-services. Tant de buzzwords :)

Mouep ! Ça ne vous empêchera pas nécessairement d'avoir un réseau de micro-sévices.

Il est en effet important de savoir dans quel état est chaque service, de surveiller leur activité. Une façon de faire est de coller à Kafka Streams un service Web qui expose une API Rest de monitoring.

Que proposent les outils de la programmation fonctionnelle pour faire ça ?

Ici, je vous propose de tester une approche basée sur ZIO et http4s.

Un microservice Kafka Streams

Nous allons nous baser sur un des "hello world" des services de streaming : le découpage de lignes de texte en mots. Nous recevons des lignes de texte depuis un premier topic "text-stream", nous découpons ces lignes en mots et nous émettons ces mots sur un second topic "word-stream".

Le main d'un service Kafka Streams ressemble à peu près à ça.

val inputStream = "text-stream"
val outputStream = "word-stream"

// -- Definition of the topology
val topology: Topology = {
  import org.apache.kafka.streams.scala.ImplicitConversions._
  import org.apache.kafka.streams.scala.Serdes._
  import org.apache.kafka.streams.scala.StreamsBuilder

  val builder = new StreamBuilder()

  builder.stream[String, String](inputStream)
      // our algorithme
      .flatMapValues(line =>
        line.split("[\\s.,;:!?]+").toIterable)  // cut cut cut... 🔪
    .to(outputStream)

  builder.build()
}

// -- Kafka Streams parameters
val properties = {
  import StreamsConfig._
  
  JavaProperties(
      APPLICATION_ID_CONFIG -> "mon-service",
      BOOTSTRAP_SERVERS_CONFIG -> "localhost:9092",
      DEFAULT_KEY_SERDE_CLASS_CONFIG -> Serdes.String().getClass,
      DEFAULT_VALUE_SERDE_CLASS_CONFIG -> Serdes.String().getClass
    )
}

// -- Kafka Streams service
val streams = new KafkaStreams(topology, properties)

streams.start()

sys.ShutdownHookThread { stream.close() }

JavaProperties est une petite astuce pour produire des java.lang.Properties en Scala avec moins de boilerplate 😁

import java.util.Properties

object JavaProperties {
  import scala.jdk.CollectionConverters._ // scala 2.13

  def apply(properties: (String, AnyRef)*): Properties = {
    val prop = new Properties()
    prop.putAll(properties.toMap.asJava)

    prop
  }
}

Pour information, la topologie de notre service ressemble à (lien)

Pour tester ce service, il faudra d'abord créer les topics. Vous pourrez alors lancer le service. Puis vous instancierez un consumer pour récupérer les données depuis le topic "word-stream" et instancierez un producer pour émettre des lignes de texte sur le topic "text-stream". Kafka propose ses propres outils pour ça. Sinon, vous pouvez toujours jeter un œil à Conduktor.

Kafka Streams et ZIO

Peut-on avoir un code plus fonctionnellement pure ?

Ici, nous allons lier l'exécution de notre application avec l'exécution du service Kafka Streams... et plus encore !

En première étape, nous allons encapsuler Kafka Streams avec ZIO, car d'un point de vue de ZIO, Kafka Streams n'est pas purement fonctionnelle.

Voici une classe abstraite qui nous permettra d'arriver à nos fins.

import zio.{RIO, Task, UIO, ZIO}

/**
  * Wrap a mutable dependency into a ZIO context.
  *
  * @param a reference to the mutable dependency
  * @tparam A mutable dependency type
  */
abstract class WrapMutable[A](private val a: A) {

  final protected def executeTotal[B](f: A => B): UIO[B] = UIO(f(a))

  final protected def executeTotalM[R, E, B](
    f: A => ZIO[R, E, B]
  ): ZIO[R, E, B] = f(a)

  final protected def unsafeTotal[B](f: A => B): B = f(a)

  final def execute[B](f: A => B): Task[B] = Task(f(a))

  final def executeM[R, B](f: A => RIO[R, B]): RIO[R, B] = Task(f(a)).flatten

}

Cette classe permet d'encapsuler d'autres classes ou services qui ne sont pas référentiellement transparents (voir 1 et 2 pour plus d'explication sur ce terme). Les appels sont aussi encapsulés dans des instances de ZIO. Ainsi, pour un service myService avec une méthode perform, au lieu de faire myService.perform, je vais faire val zMyService = new WrapMutable(myService) {}; zMyService.execute(_.perform) pour gérer avec ZIO l'appel de la méthode.

Voici une utilisation de WrapMutable dans le cadre Kafka Streams, dans laquelle je lui crée une surcouche ZIO.

import java.util.concurrent.TimeUnit
import org.apache.kafka.streams.{KafkaStreams, TopologyDescription}
import zio.duration.Duration
import zio.{UIO, ZEnv, ZIO}

class ZKafkaStreams(streams: KafkaStreams,
                    stateCheckingDelay: Duration)
    extends WrapMutable[KafkaStreams](streams) {

  /**
    * The main function that launch the service
    */
  def serve: ZIO[Clock, Throwable, Unit] = 
    (cleanup *> start *> waitWhileIsUp).ensuring(close).unit

  // this part execute a check loop that the Kafka Streams is still up
  def waitWhileIsUp:URIO[Clock,Unit] =
    isUp.repeat {
      import zio.Schedule._
      doWhile[Boolean](x => x) >>> fixed(Duration(500, TimeUnit.MILLISECONDS))
    }.unit

  def isUp:UIO[Boolean] = status.map(s => s.isRunning || s == KafkaStreams.State.CREATED)

  //REMAP
  def cleanUp:Task[Unit]              = execute(_.cleanUp())
  def start:Task[Unit]                = execute(_.start)
  def close:UIO[Unit]                 = executeTotal(_.close)
  def status: UIO[KafkaStreams.State] = executeTotal(_.state())

}

L'opérateur *> permet de séquencer des appels (implémenté avec un flatMap). L'exécution du service Kafka Streams est commandé par la méthode serve. Une méthode status est ajoutée à des fins de monitoring comme nous le verrons plus loin.

Il ne reste plus qu'à créer notre application ZIO.

import zio.ZIO

object LineProcessingService extends zio.App {

  val topology: Topology = { /* ... (see above) */ }

  val properties: Properties = { /* ... (see above) */ }

  lazy val zKafkaStream: ZKafkaStreams =
    new ZKafkaStreams(
      streams = new KafkaStreams(topology, properties),
    )

  override def run(args: List[String]): ZIO[zio.ZEnv, Nothing, Int] =
    zKafkaStream.serve
      .as(0)
      .orDie

}

Sur les dernières lignes, j'indique que la sortie nominale de notre application retourne la valeur 0 à l'OS (.as(0)) ou la valeur 1 en cas de problème (.orDie).

OK, j'ai mon service embarqué dans ZIO. Mais je n'ai pas moyen de savoir si celui-ci fonctionne normalement si je suis en dehors de la machine hôte.

Émettre des donnés de monitoring depuis son service

Une fonctionnalité nécessaire dans un service est un endpoint HTTP indiquant si ce service fonctionne. Nous allons utiliser http4s et le lier à ZIO pour envoyer une réponse 200 (OK) ou 503 (SERVICE_UNAVAILABLE) en fonction de l'état de Kafka Streams.

Au moment d'écrire ces lignes, il existe quelques tests et tutos associant ZIO et http4s (un article de Wiem Zien ici, un article là, une petit tour sur Google...). http4s est par défaut associé cats, cats-effect et fs2. Mais, il y a dans ZIO un projet qui lui permet d'exposer une interface cats-effect.

Voici comment est-ce que ça se passe. Tout d'abord, nous codons le service.

import org.http4s._
import org.http4s.dsl.Http4sDsl
import zio.interop.catz._
import zio.Task

object HealthCheckService {
  private val dsl = Http4sDsl[Task]
  import dsl._

  def webService(streams: ZKafkaStreams): HttpRoutes[Task] =
    HttpRoutes.of[Task] {
        case GET -> Root =>
          streams.status.flatMap { st =>
            if (st.isRunning) Ok()
            else ServiceUnavailable()
          }
      }
}

Dans les projets ZIO, il y a une lib d'interopérabilité avec cats. En effet, http4s est basé sur cats, cats-effect et fs2 pour instancier des services. De plus, le projet ZIO-http n'a pas démarrer. Grâce ZIO-interop-cats, l'API ZIO est adapté pour utilisé zio.Task à la place du type IO de cats-effect et qui est conceptuellement proche (l'aspect bifunctor en moins).

Et voici en parallèle, un générateur de service Web avec la variable router à redéfinir pour exposer des endpoints.

import org.http4s.HttpRoutes
import org.http4s.server.blaze.BlazeServerBuilder
import zio.interop.catz._
import zio.interop.catz.implicits._
import zio.{Task, ZEnv, ZIO}

abstract class ZKafkaStreamsWebService(host: String, port: Int) {
  import org.http4s.implicits._

  val router: HttpRoutes[Task]

  final def serve: ZIO[ZEnv, Throwable, Unit] =
    ZIO.runtime[ZEnv]
      .flatMap { implicit rts =>
        BlazeServerBuilder[Task]
          .bindHttp(port, host)
          .withHttpApp(router.orNotFound)
          .serve
          .compile
          .drain
      }

}

En associant le tout, nous avons un service Web pour notre service avec un endpoint de health check.

import com.carrefour.phenix.atp.poc_ks.lib.{ZKafkaStreams, ZKafkaStreamsWebService}
import com.carrefour.phenix.atp.poc_ks.lib.endpoints.{HealthCheckService, ServiceInfoService, TopologyService}
import org.http4s.HttpRoutes
import org.http4s.server.Router
import zio._
import zio.interop.catz._

class LineProcessingWebService(zKafkaStreams: ZKafkaStreams,
                               host: String,
                               port: Int)
    extends ZKafkaStreamsWebService(host, port) {

  override val router: HttpRoutes[Task] =
    Router(
      "/monitoring/healthCheck" -> HealthCheckService.webService(zKafkaStreams)
    )

}

Pour terminer, voici le contenu du code de notre application.

lazy val webService: LineProcessingWebService =
  new LineProcessingWebService(
    zKafkaStreams = zKafkaStream,
    host          = "localhost",
    port          = 8080)

override def run(args: List[String]): ZIO[zio.ZEnv, Nothing, Int] =
  (webService.serve.fork
    *> zKafkaStream.serve)
    .as(0)
    .orDie

Ici .fork permet de lancer le service Web en parallèle, en plaçant son exécution dans un fiber. Un fiber est une sorte de version plus légère et collaborative des threads.

On a donc un service Web qui est lancé en parallèle et le service Kafka Streams sur lequel notre application est synchronisée.

Conclusion

Ici, Kafka Streams fonctionne très bien avec ZIO et http4s. L'ensemble offre un cadre en partie fonctionnellement pure qui favorise la composition des différentes briques de notre application.

Actuellement, de mon côté, la solution est à l'état de POC. En dehors de ce qui est propre à Kafka Streams, il faudrait voir l'ajout d'autres fonctionnalités comme l'ajout d'autres endpoints de monitoring plus sophistiqués et l'intégration avec des outils de monitoring existants, la sécurisation de l'API Rest ou plus simplement voir comment peut se mettre en place des tests unitaires et des tests d'intégration. Mais les premiers résultats obtenus ici sont en ce me concerne déjà très intéressants.

Le code est disponible avec quelques ajouts sur GitHub.

Photo par Kate Townsend sur Unsplash.

Patientons avec les nouveautés de Spark 3.0

2020-04-27T22:00:00Z

On attend Spark 3.0.0 depuis la preview 2 de Noël 2019. Ici vous n'aurez pas la date de release, mais un résumé des principaux changements et nouveautés et connus à ce jour, que l'on pourra attendre de cette nouvelle version majeure de Spark. Je vous invite aussi à voir nos précédents articles sur Spark comme celui-ci sur Spark 2.4 et les autres.

Disclaimer!!! Attention quelques liens sont donnés vers la preview 2 de Spark 3.0. Elle pourrait comporter des bugs et erreurs dans sa documentation.

Compatibilité des versions

Premièrement, sur la compatibilité, Spark 3.0.0 pourra s’exécuter avec :

Java 8 / 11
- Le support de versions antérieures à Java 8 version 8u92 est déprécié.
Scala 2.12
- Spark 3 arrête le support de Scala 2.11, qui est déjà déprécié depuis Spark 2.4.1.
Python 2.7+/3.4+
- Le support des versions de Python 2 et 3 antérieures à la version 3.6 est déprécié.
R 3.1+
- Le support de version antérieure à R 3.4 est déprécié.

Il n'y aura plus de support d'Hadoop 2.6, la version par défaut sera la 2.7.

Principaux changements et nouveautés

Changement dans le module MLlib
- L'API basé sur les RDD ne devrait plus être supporté. En effet, cette API côté MLlib était en mode maintenance depuis Spark 2.0 et devrait être supprimée avec la version 3.0.
Support des fichiers binaires
- La nouvelle version apportera le support de fichiers binaires, comme les images, l'audio ou les vidéos. On pourra donc lire ces fichiers pour récupérer les métadonnées sous forme de DataFrame. Par contre, la réécriture d'un DataFrame vers un fichier binaire de ce type n'est pas possible. Une documentation sur la preview est fournie, avec le ticket JIRA.
L'API DataSource V2 sera changée
- Introduite dans Spark 2.3, l'API change dans Spark 3.0 et offre une meilleure intégration avec les optimiseurs Spark, les sources tierces auront de meilleures performances avec cette version.
Meilleures performances
- Accélération du Catalyst Optimizer grâce à des améliorations des algorithmes, par exemple sur le JIRA, SPARK-25974 et SPARK-27815 parmi d'autres.
- Dynamic Partition Pruning (traité dans cet article plus bas)
Spark Graph ?
- Spark Graph est un nouveau module développé par Neo4J, dont le nom projet de base était "Cypher for Apache Spark" puis "Morpheus". Il apporte le langage Cypher à Spark. Cypher est un langage de requêtage dédié pour les graphes (une sorte de SQL, mais adaptés aux parcours de graphes). Plus d'information dans cette présentation.
- Néanmoins le module ne va probablement pas être disponible pour la release de Spark 3.0 d'après cette discussion.
Utilisation des ressources GPU
- Malgré le support des ressources GPU par YARN et Kubernetes, Spark ne prenait pas en compte les ressources GPU exposées par ces derniers. Avec Spark 3 il sera possible d'allouer les ressources des GPU sur le cluster de manière native, cela fonctionnera avec YARN, Kubernetes et le mode Standalone. Cela pourrait être très utile pour des utilisations comme le Deep Learning. Pour en savoir plus, vous pouvez regarder l'Epic associée SPARK-24615.
Beaucoup de codes dépréciés en 2.x vont être supprimés. 🎉

Pour en savoir plus, vous pouvez aussi consulter les entrées du JIRA de Spark pour voir les autres features et bugfix.

Un point sur le Dynamic Partition Pruning

Vous connaissiez peut-être déjà le Static Partition Pruning, où quand on avait ce genre de jointure :

SELECT t1.foo FROM t1
JOIN t2
	ON t1.partcol = t2.partcol 
	AND t2.partcol = 1

Avec t1 partitionné sur la colonne partcol. À la compilation, Spark va inférer que t1.partcol = 1, va faire son "pruning" et pouvoir choisir les bonnes partitions à scanner. Tout cela parce que le filtre se fait sur les colonnes de partitions.

Or qu'en est-il avec une jointure de ce type ?

SELECT * FROM dim_table 
JOIN fact_table 
	ON (dim_table.partcol = fact_table.somcol) 
WHERE dim_table.othercol > 10.

Ici on a une jointure entre une table de fait fact_table (potentiellement très grande) et une table de dimension dim_table (qui n'est pas forcément partitionnée et petite). Le filtre se fait sur la colonne othercol de la table dim_table qui n'est pas la colonne de jointure.

Spark ne peut savoir qu'au runtime ce qu'il faut filtrer sur la table fact_table avec le résultat du filtre sur dim_table . Si la table de dimension est petite, Spark va probablement faire un Broadcast Hash Join, durant ce processus une HashTable est créée à partir de la table de dimension et le résultat est mis dans une variable de broadcast.

Avant, cette variable de broadcast était diffusée à tous les workers et alors le filtrage se faisait localement sur chaque partition de la table de fait et ainsi on évitait un shuffle.

Maintenant, avec le Dynamic Partition Pruning, on va prendre cette variable de broadcast qui servira de filtre dynamique. On l'utilisera dans la stratégie de scan de la table de fait et on ne sélectionnera que les partitions qui nous intéresse. Donc on évite un shuffle et un scan inutile de partitions.

Au niveau performance, des tests ont été faits par les équipes de Databricks sur le benchmark TPC-DS dont les résultats ont donné :

Pour 1 To de données, pour environ 60% de requêtes. On a une accélération qui va de 2x à 18x plus vite.
Pour 10 To, il y a des accélérations qui vont jusqu'à 100x.
Dans ces requêtes accélérées, ils ont observé que 90% de la donnée était rétirée du scope, d'où le gain de performance.

Vous trouverez ici un talk de Databricks sur le sujet et aussi le ticket JIRA associé à cette feature.

Comment faire pour se préparer ?

Si vous voulez vous préparer à une migration vers la version 3.0, il existe plusieurs guides officiels de migration de Spark 2.4 vers Spark 3.0, que l'ont peut trouver dans la documentation de la preview 2. Vous remarquerez qu'il y a le plus de changements dans Spark SQL.

En Scala, il faut en premier sortir de Scala 2.11 en passant à Spark 2.4.1.

Vous pouvez en suite tester la 3.0.0-preview2 Spark :

En téléchargement direct ici

Ou directement dans votre projet sbt avec :

libraryDependencies += "org.apache.spark" %% "spark-sql" % "3.0.0-preview2"

Conclusion

Voilà pour les principales features que l'ont pourra attendre de Spark 3.0. À ce jour, nous ne connaissons toujours pas de date de release. Mais peut être en saurons-nous plus lors du Spark+AI Summit 2020 qui se déroulera du 22 au 26 Juin et qui, à cause de la situation mondiale actuelle, sera virtuel et gratuit pour tous. https://databricks.com/sparkaisummit/north-america-2020

Photographie par Adrien Delforge sur Unsplash

NE FAITES PAS CETTE ERREUR

2020-03-26T23:00:00Z

Dialogue interne

« Et bim ! Encore une erreur. Que ce soit un code 500, je veux bien. Mais avec le message "Houston. We’ve got a problem.", l’humour c’est bien, mais je ne vais pas aller très loin avec ça. Ma seule solution serait de fouiller dans le code source pour comprendre ce qui s’est passé. Au fait, j’espère que j’y ai les accès ? »

Dans le monde Java et avec d'autres langages, pour gérer les erreurs, on pense souvent au mécanisme des exceptions ou de valeurs particulières comme -1, null ou NaN. Et on y pense d'ailleurs souvent un peu trop. -1 va bien fonctionner tant que vous n’oubliez pas de le gérer et à condition que la réponse nominale de votre fonction est un entier positif. null, il faut penser à le gérer aussi et c'est facile de l'oublier, sinon NullPointerException ne serait pas si courant. NaN se passe bien tant que vous ne cherchez pas à faire de comparaison, car NaN ≠ NaN. Et puis les exceptions... comme dirait Nicolas Rinaudo, les exceptions c'est pire que le goto, sachant que dans le cas des goto, on sait où est-ce que ça atterrit !

Ceci dit, les checked exceptions proposent une idée intéressante car elles doivent apparaître dans la signature des fonctions et donnent des indications sur leur comportement. Mais c’est généralement une écriture qui alourdit le code et ça se termine avec des unchecked exceptions.

La communauté FP propose néanmoins de reprendre cette idée pour mettre en valeur le fait qu’une fonction puisse retourner un résultat exceptionnel. Cela passe par des types comme Option, Either ou IO. Et ces types sont nécessaires, en particulier parce qu’ils sont accompagnés d’un ensemble d’opérations standards qui permettent de conserver un code linéaire (ie. sans boucles ni if explicites). Cependant, ils ne sont pas suffisants, car ils ne donnent aucune indication sur la nature de l’erreur.

Une erreur peut être d'ordre technique, dans la mesure où on a atteint une limite physique (out of memory, timeout, stack overflow...). Elle peut être d'ordre métier, dans le mesure où un contexte sort du comportement attendu par le métier (ie. identifiant de compte invalide, produit non disponible, badge déjà validé...). Mais la façon de gérer une erreur, quelle qu'elle soit, est une décision métier.

Puisque la gestion d'une erreur est une décision métier, au niveau technique on ne devrait pas chercher à émettre une erreur. D'ailleurs, on ne devrait même pas réfléchir au résultat nominal à priori. On devrait en fait qualifier une situation sur le plan métier.

Prenons un exemple simple. Et pour paraphraser François Armand, nous allons prendre l’exemple de la division euclidienne.

Il est en parti vrai d'écrire

def divide(a: Int, b: Int): Int

Seulement, si b vaut 0, à quelle genre de réponse doit-on s’attendre ? On voit rapidement que -1 n’est pas une réponse valide. null n’est pas permis par définition du type Int. On pourrait envoyer une exception... ce qui reviendrait à ajouter du code alourdissant celui existant pour traiter l’exception, si on ne l’oublie pas.

Écrivons maintenant

def divide(a: Int, b: Int): Option[Int]

Cette version indique clairement, que dans certains cas nous n’aurons pas la réponse attendue : None. En plus, le compilateur va nous obliger à gérer le cas où nous obtiendrons None. Ce ne sera pas avec une structure syntaxique lourde (try... catch) mais avec avec des opérations qu’on peut intégrer dans des expressions (map, flatMap, getOrElse...) et le "if" n’est pas nécessaire.

Nous allons maintenant représenter des périodes de temps (où le temps est représenté par un entier pour des raisons de simplification).

case class Period(start: Int, end: Int)

Nous allons éluder le cas où start > end.

Je veux constituer une liste de Period qui ne se chevauchent pas plus par rapport à un certain timing.

Avant de parler de cas nominaux et cas exceptionnels, nous allons d’abord chercher à qualifier les différents contextes. Nous avons donc des périodes qui ne se chevauchent pas, des périodes qui se chevauchent un peu et des périodes qui se chevauchent beaucoup ou complètement.

Je vous propose de représenter quelques cas en utilisant des têtes de chiots pour représenter le temps passé dans les périodes, parce que pourquoi pas !

Voici les cas où il n'y a pas de chevauchement.

# period 1 before period 2
period 1 [🐶🐶🐶]
period 2          [🐶🐶🐶]

# period 1 after period 2
period 1          [🐶🐶🐶]
period 2 [🐶🐶🐶]

Voici les cas avec chevauchement

# period 2 overlaps period 1 by 2 🐶
period 1 [🐶🐶🐶🐶]
period 2    [🐶🐶🐶🐶]

# period 1 overlaps period 2 by 3 🐶
period 1    [🐶🐶🐶🐶]
period 2  [🐶🐶🐶🐶]

# period 1 includes period 2
[🐶🐶🐶🐶🐶]
  [🐶🐶]

# period 1 == period 2
[🐶🐶🐶]
[🐶🐶🐶]

Si on regroupe d'un côté les deux premiers cas (chevauchement partiel) et de l'autre les deux derniers cas (chevauchement total), nous avons au total trois cas possibles.

sealed trait OverlappingPeriodQualification
case class PeriodsDoNotOverlap(  period1: Period, period2: Period)          extends OverlappingPeriodQualification
case class PeriodsPartiallyOverlap(period1: Period, period2: Period, by: Int) extends OverlappingPeriodQualification
case class PeriodsFullyOverlap(    period1: Period, period2: Period)          extends OverlappingPeriodQualification

À partir de là, nous pouvons effectuer la qualification.

def qualify(period1: Period, period2: Period): OverlappingPeriodQualification =
  if ((period1.end <= period2.start) || (period2.end <= period1.start))
    PeriodsDoNotOverlap(period1, period2)
  else if (period1.start >= period2.start) {
    if (period1.end <= period2.end)
      PeriodsFullyOverlap(period1, period2)
    else
      PeriodsPartiallyOverlap(period1, period2, period2.end - period1.start)
  }
  else if (period2.start >= period1.start) {
    if (period2.end <= period1.end)
      PeriodsFullyOverlap(period1, period2)
    else
      PeriodsPartiallyOverlap(period1, period2, period1.end - period2.start)
  }

Une fois la qualification réalisée, on peut passer à l'interprétation des valeurs obtenues. La phase d'interprétation consiste à convertir des valeurs en effets. C'est en quelque sorte la partie présentation. Le code ci-dessous correspond à une interprétation possible des valeurs de OverlappingPeriodQualification.

def interpret(qualification: OverlappingPeriodQualification): Try[Unit] =
  qualification match {
    case PeriodsDoNotOverlap(_, _) => Success(())
    case PeriodsFullyOverlap(p1, p2) => Failure(new Exception("periods overlap"))
    case PeriodsPartiallyOverlap(p1, p2, delta) =>
      if (delta > 2) Failure(new Exception("periods overlap"))
      else Success(())
  }

Il est possible d'ajouter d'autres interpréteurs qui envoient des exceptions, qui permettent de tracer les qualifications, qui effectuent d'autres actions. Le mieux est de faire en sorte que cette phase d'interprétation est lieu le plus tard possible dans le code.

La séparation qualification / interprétation offre une certaine vertu, en particulier, de permettre d'avoir une souplesse pour les tests, pour les modifications du code et de délimiter plus clairement un domaine métier. L'objectif est avant tout de clarifier le code et d'aider le développeur à intervenir plus efficacement sur les applications.

Quoi de neuf dans Kafka 2.4

2020-02-24T23:00:00Z

Si comme moi vous avez raté le train pour la release de Kafka 2.4, voici un petit résumé de quelques fonctionnalités ajoutées et bugfix :)

Consommateurs / Producteurs / Brokers

Une meilleure optimisation niveau réseau

KIP-392 : Allow consumers to fetch from closest replica
Motivation : https://www.confluent.io/blog/multi-region-data-replication/
How-To :
1. Configurer broker.rack et replica.selector.class (tous deux configurations du broker)
2. Configurer client.rack (configuration du consommateur)
3. ???
4. Profit
En mettant ces deux configurations, lorsqu'un consommateur essaye de récupérer des données de la partition leader, la partition regarde s'il y a un rack préféré et si une class selector est renseignée, puis redirige le consommateur vers le replica préféré (de préférence un qui soit proche du consommateur pour avoir le moins de trafic réseau possible, mais cela dépend de la configuration fournie dans replica.selector.class).

Diminution du temps de rebalancing des partitions des consommateurs

KIP-429 : Kafka Consumer Incremental Rebalance Protocol
https://www.confluent.io/blog/incremental-cooperative-rebalancing-in-kafka/
Motivation : Réduire l'effet "stop-the-world"

Le principe de stop-the-world est connu notamment avec le garbage collector : le programme s'arrête complètement afin de ne pas accidentellement rendre des objets inutilisables.

Le même principe s'applique avec le load balancing dans Kafka.

Quelles que soient les raisons amenant à un load balancing des clients Kafka (scaling up/down des clients, perte temporaire d’un broker, rolling upgrade...), les processus s’arrêtent le temps d’équilibrer la charge des partitions. Ce qui pose des soucis au niveau de la performance.

Une solution implémentée par la KIP-429 est donc le protocole incrémental de rebalancing. Celui-ci se repose sur deux idées :

Le rebalancing doit se faire de manière incrémentale, c’est-à-dire qu’il n’y a pas besoin d’avoir un rééquilibrage complet des charges à la fin d’un load balancing. Celui-ci se fait petit à petit, ce qui permet de ne pas "déranger" tous les processus à la fois en les stoppant.
Le rebalancing doit se faire de manière coopérative puisque chaque client de chaque groupe doit pouvoir être en mesure de relâcher des ressources, pour que les autres clients arrivants puissent prendre ces dernières.

Optimisation lorsqu'il n'y a pas de clé et de partitioning spécifiés

KIP-480 : Sticky Partitioner
https://www.confluent.io/blog/apache-kafka-producer-improvements-sticky-partitioner/
Motivation : Remplacer le mécanisme round-robin par défaut lorsque les clés des records sont nulles et qu'il n'y a pas de partitioning spécifié.

Lors de la production des messages dans Kafka, si la clé est "null" et si les messages ne sont pas partitionnés de manière spécifiques via un partitionner, les messages sont normalement distribués en utilisant le “round-robin” : chaque message est envoyé individuellement dans les différentes partitions en suivant un cycle, le but étant que chaque partition reçoit équitablement le même nombre de message. Ceci crée un problème de latence car les batch de messages à envoyer vers Kafka ne contiennent dans ce cas-là qu’un seul message. Conséquence : il y a plus de batch à envoyer. Pour rappel, plus il y a de batch à envoyer, plus la latence est grande, puisque envoyer un batch requiert une requête et une mise en queue.

Le but du KIP-480 est donc de diminuer cette latence en revisitant le "round-robin" appliqué par défaut lorsqu’on se trouve dans cette situation. La stratégie du "sticky partitioner" vise à ce qu’un batch de messages soit envoyé dans une partition dite "sticky". Puis pour le prochain batch de messages, une autre partition est désignée comme "sticky". Dans ce cas, les batchs sont créés avec les options du producteur : linger.ms et batch.size. Ceci a pour effet d’augmenter la taille des batchs et donc d’avoir moins de batchs à envoyer : on diminue la latence. Netflix avait une idée similaire au sticky partitionner qui se basait seulement sur le temps (linger.ms).

Note rappel :

linger.ms : maximum de temps à attendre avant d’envoyer un batch de message
batch.size : maximum de taille que le batch peut avoir avant d’être envoyé dans une partition d’un topic de Kafka

Toujours plus pour se débarasser de Zookeeper

KIP-455 : Create an Administrative API for Replica Reassignment
Motivation : Remplacer l’API de Zookeeper s’occupant de réassigner les partitions répliquées.

L’API de Zookeeper possède plusieurs défauts : des codes d’erreurs non exploitables, un manque de sécurité,... L’API ne réassigne pas non plus les partitions de manière incrémentale, et il n’est pas possible de stopper une opération de réassignation des partitions en cours.

Le but de ce KIP-455 est donc de créer une API Kafka AdminClient permettant ceci, avec plus de sécurité et des codes d’erreurs plus exploitables. Pour cela, deux nouvelles APIs AdminClient ont été créées : alterPartitionAssignments et listPartitionReassignments. La première permet de réassigner les partitions, et la seconde permet de lister les partitions en cours de réassignement. En plus de cela, des RPC ont été ajoutés de manière à stopper le réassignement (AlterPartitionReassignmentsRequest) ou encore obtenir la réponse de cette requête (AlterPartitionReassignmentsResponse), etc.

Avec cette KIP-455, le script kafka-reassing-partitions.sh utilisé pour réassigner les partitions utilise maintenant l’API de l’AdminClient, et l’option zookeeper devient déprécié. Le script kafka-topics.sh permettant de créer/modifier des topics se voit ajouter deux options : addingReplicas et removingReplicas.

Bug fix : KafkaConsummer ne se débarasse plus des données pré-extraites lorsque les partitions sont mises en pauses

https://issues.apache.org/jira/browse/KAFKA-7548

Les consommateurs Kafka ont la possibilité d’être stoppés et redémarrés avec les méthodes .pause() et .resume(). Lorsqu’un client consomme des messages avec la méthode .poll(), il le fait de manière asynchrone et met les messages dans un buffer local au client consommateur.

Ce qui veut dire que la situation suivante peut arriver : un client stoppe la consommation d’une partition d’un topic et ensuite appelle le .poll() de cette partition. Dans ce cas, le .poll() met des données dans le buffer local et, lorsque le client reprend sa consommation, celui-ci refait une requête des données vers la partition en ignorant les données mise dans le buffer local. Ceci a des conséquences sur la performance des clients lorsque ceux-ci effectuent beaucoup de pause/resume. Ce problème est maintenant résolu grâce à KAFKA-7548.

Kafka Connect

Mirror Maker 2.0

KIP-382 : MirrorMaker 2.0

MirrorMaker permet de créer un “miroir” d’un cluster Kafka entier. Sur papier, cela semble être un bon outil pour répliquer un cluster, néanmoins il possède plusieurs défauts. Pour en citer quelques un : les topics miroirs sont créés avec une configuration par défaut, les ACLs (Access Control Lists) ne sont pas répliqués, les messages sont re-partitionnés avec la “DefaultPartitionner”, etc.

MirrorMaker 2.0 se base sur Kafka Connect afin de répliquer le mieux possible un cluster Kafka.

Ajout de headers dans Kafka Connect

KIP-440 : Extend Connect Converter to support headers
Les headers dans Kafka permettent d’enrichir les messages Kafka de metadonnées additionnelles. Par exemple transmettre le schéma ID si le message est en avro. Cette KIP-440 vise à également enrichir le Kafka Connect Converter afin que celui-ci puisse être utilisé en tandem avec les clients producteurs/consommateurs/streams utilisant les headers.

Kafka Streams

Support des join sans clé dans les KTable

KIP-213 : Support non-key joining in KTable

Possibilité de tester rapidement grâce au TopologyTestDriver

KIP-470 : TopologyTestDriver test input and output usability improvements

Misc

Support scala 2.13
Upgrade zookeeper ⇒ 3.5.X

ZIO : Programmation concurrente à la carte

2020-02-23T23:00:00Z

On a déjà parlé plusieurs fois de ZIO sur le blog, (et on va continuer ! 😃).

Au-delà d'être la bibliothèque que l'on attendait pour faire du Functional Programming, ou une façon de faire du Scala sans rentrer dans le polymorphisme ad-hoc ou d'autres concepts fins néanmoins abstraits, ZIO ouvre un nouveau chemin de traverse dans la programmation concurrente.

Le programmation concurrente est l'idée de gérer plusieurs exécutions hétérogènes simultanées de manière collaborative, une façon de faire plus courante dans le monde moderne avec le multi-cœur et les nouvelles architectures. Pour le moment, la boîte à outil de référence pour faire de la programmation concurrente sur la JVM, c'est Akka.

Akka permet de pousser assez loin la programmation concurrente, mais va être parfois assez irritant. D'un côté, on code du Akka, de l'autre du Scala. Puis, quand on a appris d'autres modèles de programmation concurrente que le modèle d'acteur (avec Golang ou Clojure), cela devient légèrement usant !

object AkkaAppp extends App {
  val greeterMain: ActorSystem[GreeterMain.SayHello] = 
    ActorSystem(GreeterMain(), "AkkaHelloWorld")

  greeterMain ! SayHello("Jon")
  // bot : Hello Jon !

  greeterMain ! Bye
}

L'année dernière, on a eu le droit à un peu de magie avant Noël avec l'implémentation du modèle d'acteur au-dessus de ZIO : Basic ZIO actors.

Ainsi on pourrait faire à terme avec ZIO ce que l'on pouvait faire en utilisant Akka. Cela étant dit, ZIO va plus loin sur la base, en particulier on peut faire de la composition en programmation concurrente.

En termes de composition, vous avez quelques types de base : ZIO, Ref, Fiber... Et au-dessus, on va avoir de nombreux outils pour combiner ces différents types. Si vous voulez taper un peu dans la liste, voici le résumé approximatif :

 /**
   * @tparam R ce dont j'ai besoin
   * @tparam E quand cela va mal
   * @tparam A quand tout se passe bien
   */
  trait ZIO[-R, +E, +A] {
    private[zio] def unsafeRun: R => Either[E, A]

    def flatMap[R1 <: R, E1 >: E, B](f0: A => ZIO[R1, E1, B]): ZIO[R1, E1, B]
    def fork: URIO[R, Fiber[E, A]]
  }

  //besoin de rien
  type IO[+E, +A] = ZIO[Any, E, A]

  //tout va bien se passer
  type UIO[+A] = ZIO[Any, Nothing, A]

  //avec R, on peut faire un A
  type URIO[-R, A] = ZIO[R, Nothing, A]

  //pourquoi ?
  type Exit[+E, +A] = Either[Cause[E], A]

  sealed trait Cause[+E]
  case class Fail[+E](value: E)               extends Cause[E]
  case class Die(value: Throwable)            extends Cause[Nothing]
  case class Interrupt(fiberId: (Long, Long)) extends Cause[Nothing]

  trait Fiber[+E, +A] {
    def interrupt: UIO[Exit[E, A]]
    def join: IO[E, A]
  }

  trait Promise[E, A] {
    def await: IO[E, A]
    def complete(io: IO[E, A]): UIO[Boolean]
  }

  trait Queue[-R, +E, A] {
    def isShutdown: UIO[Boolean]
    def offer(a: A): ZIO[R, E, Boolean]
    def take: ZIO[R, E, A]
  }

  trait Ref[A] {
    def get: UIO[A]
    def modify[B](f: A => (B, A)): UIO[B]
  }

  case class Reservation[-R, +E, +A](
    acquire: ZIO[R, E, A], 
    release: Exit[Any, Any] => ZIO[R, Nothing, Any])

  trait ZManaged[-R, +E, +A] {
    def reservation: ZIO[R, E, Reservation[R, E, A]]

    def flatMap[R1 <: R, E1 >: E, B](f0: A => ZManaged[R1, E1, B]): ZManaged[R1, E1, B]
  }

  trait Stream[-R, +E, +A] {
    //1. on "acquire" la stream
    //2. on "pull" les éléments un par un (ZIO[R, Option[E], A])
    //3. si on a un None dans le Option[E], on arrête
    //4. on "release"
    def process: ZManaged[R, Nothing, ZIO[R, Option[E], A]]

    def flatMap[R1 <: R, E1 >: E, B](f0: A => Stream[R1, E1, B]): Stream[R1, E1, B]
  }

  trait Semaphore {
    def available: UIO[Long]
    def withPermits[R, E, A](n: Long)(task: ZIO[R, E, A]): ZIO[R, E, A]
  }

Au-dessus de ces types, on va pouvoir construire le reste des opérateurs pour manipuler les effets (même si on va plutôt "inliner" pour des histoires de performance).

Ces dernières semaines, on a eu quelques articles intéressants sur des cas d'utilisation ou des combinateurs au-dessus de ZIO.

Happy Eyeballs

Happy eyeballs algorithm using ZIO

Happy eyeballs algorithm using ZIO While researching structured concurrency for the article on Project Loom & Fibers, one of the most valuable resource were blogs (1, 2) by Nathaniel J. Smith …

https://blog.softwaremill.com/happy-eyeballs-algorithm-using-zio-120997ba5152?gi=343b946500e4

L'article part d'un code qui a été fait avec Trio (Python), pour voir comment on peut le faire en Scala.

L'idée est de pouvoir mettre dans la course n tâches (dans une List), pour récupérer le premier résultat, sans lancer plus de tâches que nécessaire, en optimisant le temps d'exécution. C'est interruptible, donc les tâches qui ne sont pas finies sont stoppées. Il n'y a pas de limite dans le panache ! 😃

"Suivez les types"

def happyEyeballs[R, E, T](tasks: List[ZIO[R, E, T]], delay: Duration): 
                           ZIO[R with Clock, Option[E], T]

Pour les types R, E et T:

L’algorithme prend une liste de tâches ZIO[R, E, T], donc des tâches qui dépendent d'un R, vont renvoyer plus tard un T si cela se passe bien ou un E si cela se passe mal.
Un délai
Pour renvoyer une seule tâche ZIO[R with Clock, Option[E], T], donc une tâche qui dépend de R et d'une horloge Clock (pour gérer le délai), qui va renvoyer le premier T si cela s'est passé au moins une fois ou Some[E] si cela se passe mal (Le None est pour le cas où la liste de tâche est vide).

L'article d'Adam est très précis et on peut porter quelques petites modifications à la solution proposée. Je suis parti sur une version :

Plus typée : avec un paramètre de type E en plus et en mettant cette histoire de liste vide dans un IO.fail(None). C'est un choix, je trouve que cela paye après (même dans les articles de blog).
Plus documentée : les variables pour les effets que l'on enchaîne ont à la fois un nom et un type (signalFailed, waitOrAlreadyFailed).

def happyEyeballs[R, E, A](tasks: List[ZIO[R, E, A]], delay: Duration): ZIO[R with Clock, Option[E], A] =
    tasks match {
      case Nil         => IO.fail(None)
      case task :: Nil => task.asSomeError
      case task :: otherTasks =>
        Promise.make[Nothing, Unit].flatMap { isFailed =>
          val signalFailed: UIO[Unit]                = isFailed.succeed(Unit).ignore
          val waitOrAlreadyFailed: URIO[Clock, Unit] = isFailed.await.timeout(delay).ignore
          
          task
            .tapError(_ => signalFailed)
            .asSomeError
            .race(waitOrAlreadyFailed *> happyEyeballs(otherTasks, delay))
        }

Ce qui est assez fascinant, c'est comment un algorithme relativement complexe compose avec si peu de lignes de ZIO.

CountDownLatch

Creating a dead simple CountDownLatch with ZIO

Creating a dead simple CountDownLatch with ZIO In this post I’ll explain what a CountDownLatch is, and how ZIO enables you to create concurrency primitives which are efficient, non-blocking and …

https://medium.com/wix-engineering/creating-a-dead-simple-countdownlatch-with-zio-c4212ecf9198

L'article se présente dans le contexte des tests autour de ZIO, où l'on doit attendre plusieurs signaux pour débloquer la barrière, afin de passer à la suite du test. (🤔 Mais pourquoi il n'y a pas juste un ZIO.race ? Le cas d'utilisation doit être plus complexe dans la base de code.)

Voici un "ZIOLatch", pour le reste (timeout, ...), on peut passer par les combinateurs classiques de ZIO !

trait CountDownLatch {
  def countDown: UIO[Unit]
  def await: UIO[Unit]
}

Pour faire l’implémentation, on pourrait faire une coquille autour de l'API Java existante ou utiliser les briques de base de ZIO pour faire le CountDownLatch.

L'article propose cette implémentation :

object CountDownLatch {
  def make(count: Int): UIO[CountDownLatch] = for {
    ready <- Promise.make[Nothing, Unit]
    ref   <- Ref.make(count)
  } yield new CountDownLatch {
    override def countDown: UIO[Unit] =
      ref.updateAndGet(_ - 1).flatMap {
        case 0 => ready.succeed(()).unit
        case _ => ZIO.unit
      }

    override def await: UIO[Unit] = ready.await
  }
}

Je ne suis pas vraiment convaincu. Qu'est-ce qu'il arrive si l'appel à countDown est interrompu au mauvais moment ? C'est-à-dire dans le chat de l’aiguille entre le succès de l'appel à updateAndGet et la suite où pour 0, on va compléter la Promise ready.

On pourrait se dire que si un interrupt se glisse ici, c'est vraiment la faute à pas de chance, jusqu'à que dans d'autres cas :

La prod est bloquée dans un état de stase,
Des philosophes meurent de faim,
Que l'on perde plusieurs 100k€ ...
Ou la vie ? 🙀

Donc on va essayer de tester le truc que l'on vient de créer pour tester du code... #Meta

Testons les tests

Voici la spec du CountDownLatch en utilisant zio-tests

Le scénario basique

def make(n: Int): UIO[CountDownLatch]

testM("basic scenario")(for {
  l <- make(2)
  _ <- l.countDown
  _ <- l.countDown
  _ <- l.await
} yield {
  assertCompletes
})

Donc à la base, on initialise un countDownLatch à 2, on fait 2 countDown. Normalement, on doit pouvoir passer tranquillement.

Le scénario dans le domaine
```
testM("make 0 should be available")({
  for {
    countDownLatch <- make(0)
    r              <- completedOrError(countDownLatch.await, "should be completed")
  } yield r
})
```
Un peu différent, ici on teste que si l'on part de 0, alors on doit pouvoir passer la barrière directement, sinon c'est une erreur. Ce scénario n'est pas prévu pour l’implémentation actuelle, mais ce n'est pas complexe à rajouter.

On vérifie que cela bloque comme attendu

testM("keep the gate closed")(for {
  l  <- make(2)
  _  <- l.countDown
  r1 <- runningOrError(l.await, "shoud be running")
  _  <- l.countDown
  r2 <- completedOrError(l.await, "should be completed")
} yield {
  r1 && r2
})

On perturbe les effets

testM("basic scenario with disturb")(
  checkAllM(Gen.fromIterable(0 to 10))(
    steps =>
      for {
        cdl <- make(2)
        _   <- cdl.countDown
        _   <- Disturb.interruptAfterNSteps(cdl.countDown, steps).orElse(cdl.countDown)
        r   <- completedOrError(cdl.await, "should be completed")
      } yield {
        r
      }
  )
)

Ce test est beaucoup plus complexe. On perturbe la deuxième exécution de .countDown, et si cette exécution est en erreur, on relance un .countDown avant de vérifier si .await est disponible.

Afin de définir ce test, il faut réussir à pouvoir perturber des effets. ZIO est basé sur de la composition de représentations différentes des effets, que l'on peut déstructurer en exécution pas à pas, dans du code (super-)utilisateur.

Sans expliquer jusqu'au bout l'approche, on peut taper dans le code interne de ZIO pour faire une perturbation des effets, qui va arrêter l'exécution après N étapes.

object Disturb {
  def interruptAfterNSteps[R, E, A](effect: ZIO[R, E, A], maxExecutionSteps: Int): ZIO[R, Option[E], A]
}

Et caler ça dans un test avec un peu de property-based-testing :

testM("basic scenario with disturb")(
  checkAllM(Gen.fromIterable(0 to 10))(
    steps =>
      for {
        cdl <- make(2)
        _   <- cdl.countDown
        _   <- Disturb.maxSteps(cdl.countDown, steps).orElse(cdl.countDown)
        r   <- completedOrError(cdl.await, "should be completed")
      } yield {
        r
      }
  )
)

La suite de tests permet de confirmer les 2 "erreurs" (on les a cherchées).

- finish
  + basic scenario
  + keep the gate closed
  - make 0 should be available
  - basic scenario with disturb

Fix de l’implémentation

Un moyen facile pour fixer l'implémentation, c'est de :

Faire une implémentation pour la valeur manquante dans le domaine (make(0)).
Passer en non-interruptible la section du code qui ne doit pas être coupé en deux.

object CountDownLatch {
  def make(count: Int): UIO[CountDownLatch] =
    if (count <= 0)
      UIO(new CountDownLatch {
        override def countDown: UIO[Unit] = ZIO.unit
        override def await: UIO[Unit]     = ZIO.unit
      })
    else
      for {
        ready <- Promise.make[Nothing, Unit]
        ref   <- Ref.make(count)
      } yield new CountDownLatch {
        final override def countDown: UIO[Unit] =
          (ref.updateAndGet(_ - 1) >>= {
            case 0 => ready.succeed(()).ignore
            case _ => ZIO.unit
          }).uninterruptible

        final override def await: UIO[Unit] = ready.await
      }
}

Néanmoins si on reprend le problème à la base, il y a probablement moyen de faire plus simple. La version Java utilise "juste" une AtomicRef pour garder le comptage et fait une "petite" boucle pour l'attente. On peut faire pareil en ZIO, ce qui donne un truc relativement propre.

object CountDownLatchJavaLike {
  def make(count: Int): UIO[CountDownLatch] =
    for {
      ref <- Ref.make(count)
    } yield new CountDownLatch {
      override def countDown: UIO[Unit] = ref.update(_ - 1)
      override def await: UIO[Unit]     = ref.get.doUntil(_ <= 0).unit
    }
}

Les perfs sur le await ne sont pas tops, c'est dommage de lancer un "Schedule" si le countDownLatch est déjà libéré. On pourrait faire un appel direct avant de faire un appel récurrent.

def await: UIO[Unit] = ref.get flatMap {
  x => if(x <= 0) ZIO.unit 
             else ref.get.doUntil(_ <= 0).unit
}
//ou faire un autre combinateur
@inline
def fastDoUntil[R,E,A](e: ZIO[R,E,A])(p: A => Boolean) = 
  e flatMap {
    x => if(p(x)) ZIO.succeed(x)
         else     e.doUntil(p)
  }

def await: UIO[Unit] = fastDoUntil(ref.get)(_ <= 0).unit

Voici les liens vers le code :

Conclusion

ZIO permet de faire beaucoup plus en programmation concurrente et s'il manque des éléments dans le menu, on peut toujours construire par-dessus à la carte.

⚠️ Néanmoins cela nécessite de faire des tests plus poussés en environnement concurrent.

<fiction>Pour le prochain article on regardera pour la conversion de TLA+ (PlusCal) vers ZIO. </fiction>

Quelques liens utiles :

La version depuis java.util.concurrent.CountDownLatch.

import zio.blocking._

object CountDownLatchWrapJava {
  def make(count: Int): UIO[CountDownLatch] =
    for {
      cdl <- WrapImpure.wrapTotal(new java.util.concurrent.CountDownLatch(count))
    } yield {
      new CountDownLatch {
        override def countDown: UIO[Unit] = cdl.execTotal(_.countDown())
        override def await: UIO[Unit]     = cdl.execTotal(_.getCount()).doUntil(_ <= 0L).unit
      }
    }
}

//Ou une version plus technique avec l'aide de Adam Fraser
object CountDownLatchWrapJavaBlock {
  def make(count: Int): URIO[Blocking, CountDownLatch] =
    for {
      blocking <- ZIO.environment[Blocking]
      cdl      <- WrapImpure.wrapTotal(new java.util.concurrent.CountDownLatch(count))
    } yield {
      new CountDownLatch {
        override def countDown: UIO[Unit] = cdl.execTotal(_.countDown())
        override def await: UIO[Unit]     = cdl.execBlockingInterrupt(_.await()).orDie.provide(blocking)
      }
    }
}

//regarde maman, sans Kleisli
final class WrapImpure[B](private val value: B) {
  def exec[C](f: B => C): Task[C]                           = ZIO.effect(f(value))
  def execTotal[C](f: B => C): UIO[C]                       = ZIO.effectTotal(f(value))
  def execBlockingInterrupt[C](f: B => C): RIO[Blocking, C] = effectBlockingInterrupt(f(value))
}

object WrapImpure {
  def wrap[B](b: => B): Task[WrapImpure[B]]     = ZIO.effect(new WrapImpure(b))
  def wrapTotal[B](b: => B): UIO[WrapImpure[B]] = ZIO.effectTotal(new WrapImpure(b))
}

Crédit photo : unsplash / Sunrise Photos

Le feu, la roue, IO

2020-02-03T23:00:00Z

En informatique, il est nécessaire de communiquer avec des services externes ou des utilisateurs pour avoir des applications utiles, ce qui implique dans l'état actuel de l'informatique de gérer le non-déterminisme et la mutabilité. Mais on sait aussi qu'immutabilité et déterminisme font bon ménage pour avoir des applications stables. Tellement stables qu'elles ne pourraient plus s'exécuter et deviendraient donc par essence inutiles ?

Entre ça et le ruban infinie de la machine de Turing, l'informatique n’est en fait plus qu’un immense paradoxe voué à disparaître dans une nébuleuse de logique.

Non ! Pour mettre sur pied des applications qui fonctionnent, il va juste se passer ce que nous faisons depuis toujours en informatique pour qu'elle ait une raison d'exister : des concessions. Par exemple, on peut tricher avec les limites humaines, pour qui un ordinateur fait des calculs instantanés, pour qui la mémoire est tellement volumineuse qu’elle en paraît infinie (même si une mémoire infinie, ce n’est jamais assez 🤡) et affiche sur l'écran des lignes continues. On va aussi jouer à "pas vu, pas pris". Ainsi, on va dire qu'on est immutable, alors qu'en fait le processeur passe son temps à modifier ses registres, ses flags, ses caches... Toutes ces choses qu'on appelle des effets. Mais ça, on ne le voit pas. Alors, on dit qu'on est immutable néanmoins, même avec un calcul méga complexe. L’immutabilité, c’est lorsque la mutabilité ne se voit pas !

Mais il arrive un moment où les effets ça devient tellement gros qu'on ne peut plus les cacher... Gros comme un appel à une base de donnée pour modifier des données et le constater par exemple ou une interaction avec un client Web qui retourne des informations différentes à chaque fois (service météo, forex EUR/USD, les timelines...). Et ça, ces effets, on ne peut pas y échapper si on veut que notre application soit utile.

Malheureusement, avec les effets, ce sont des impuretés qui s'incrustent dans notre code, incluant des bugs connus comme les actions à distance. Et un code impur, ça veut dire du code sur lequel le raisonnement est plus complexe. Il s'ensuit une baisse de la capacité de refactoring, de la lisibilité, de la testabilité... Au moins, la seule chose qui augmente, c'est le temps passé à déboguer.

IO lave plus blanc

Pour retrouver la pureté fonctionnelle de notre code, nous allons mettre en place ~~une hypocrisie~~ une abstraction.

Le seul moyen d'avoir un code isolé des effets, c'est de repousser l'exécution de ces effets. Et pour ça, nous allons retarder cette exécution pour la déclencher à un moment plus opportun. C'est un peu comme dans certaines histoires où on emprisonne un.e bad guy/girl pour le/la sortir lorsqu'il n'y a plus d'autre choix pour sauver une situation 😎.

En programmation fonctionnelle, on fait ça avec une fonction.

Prenons l'expression suivante

List(println("Hello"), println("Hello"))

Son résultat donne

Hello
Hello
res1: List[Unit] = List((), ())

Puisque println est une fonction qui effectue un affichage à l'écran et ne retourne pas de valeur à part () (de type Unit).

Par transparence référentielle (possibilité de remplacer une partie d'une expression par sa valeur), on devrait avoir le même comportement avec le code ci-dessous

val result: Unit = println("Hello")
List(result, result)

Ce qui n'est pas le cas

Hello
res1: List[Unit] = List((), ())

Puisque la variable result ne récupère sa valeur (qui est ()) qu'après que println ait été exécuté. Après quoi, l'utilisation de result retourne (), mais ne ré-appelle pas println. Dans ce cas, notre code initial ne peut subir de refactoring.

Pour retrouver un comportement équivalent avec la possibilité d'utiliser une variable intermédiaire, il faut intégrer l'appel à println dans une fonction. Mais cela implique une petite modification après la construction de la liste. Ce n'est pas bien grave, dans la mesure où nous montrons qu'un effet est présent dans notre expression.

val result: Unit => Unit = () => println("Hello")
List(result, result).map(f => f())

Ce qui donne

Hello
Hello
res1: List[Unit] = List((), ())

Nous pouvons utiliser cette forme avec d'autres effets

def printMessage(message: String): () => Unit = () => println(message)
def readLine(): () => Int = ???
def readFile(filename: String): () => Try[String] = ???
def getUserTimeLine(twitterName: String): () => Try[List[Tweet]] = ???

De la fonction au type

Plutôt que d'utiliser une fonction, qui complique un peu notre écriture, nous allons représenter l'effet en créant un type nommé Effect. Ce type prend en paramètre la fonction que nous avons vu précédemment et la déclenche par un appel à run.

case class Effect[A](run: () => A)
object Effect {
  def pure[A](a: => A): Effect[A] = Effect { () => a }
}

Le type Effect représente donc une opération ou un ensemble d'opérations contenant des effets.

def printMessage(message: String): Effect[Unit] =
  Effect.pure { println(message) }

def readLine(): Effect[Int] =
  Effect { scala.io.StdIn.readLine() }

def readFile(filename: String): Effect[Try[String]] =
  Effect { scala.io.Source.fromFile(filename).mkString }

def getUserTimeLine(twitterName: String): Effect[Try[List[Tweet]]] = ???

Le type Effect est en plus un foncteur et une monade. Il est donc possible pour ce type de construire les méthode map et flatMap, et de les utiliser dans un for-comprehension :

val program: Effect[Unit] =
  for {
    _ <- printMessage("WHAT... Is your name?")
    name <- readLine()
    _ <- printMessage("WHAT... Is your quest?")
    answer <- readLine()
    _ <- printMessage(s"Are you sure, $name?")
  } yield ()

program.run()

Par convention (surtout avec Haskell), Effect est appelé IO. Voici une implémentation "naïve" du type IO.

case class IO[A](run: () => A) {
  def map[B](f: A => B): IO[B] = IO.pure { f(run()) }
  def flatMap[B](f: A => IO[B]): IO[B] = IO.pure { f(run()).run() }
}
object IO {
  def pure[A](a: => A): IO[A] = IO { () => a }
}

Vous aviez un imprévu ?

Maintenant, on peut tout à fait s'attendre à ce qu'un effet ait un comportement imprévu (eg. IOException, Timeout, 404, 500...). Pour représenter ce type de comportement, il y a deux écoles. La première considère qu'il y a déjà un type pour représenter ça, qui est le type Either, et donc on va se retrouver avec IO[Either[E, A]], où E représente le type de la situation exceptionnelle (Throwable, String, List[BusinessError]). Généralement, dans ce cas, on réécrit le type en EitherT[IO, E, A] qui est un monad transformer. Ce qui n'est pas sans poser quelques soucis, en particulier des soucis de performance.

Dans une autre approche, nous pouvons considérer que la situation exceptionnelle est une partie intrinsèque de l'effet et qu'elle ne peut pas en être dissociée. Dans le mesure où un effet peut représenter un accès à une base de données, à une communication avec un service externe, à un traitement impliquant le système d'exploitation, etc., nous avons très souvent des cas où l'effet implique un comportement imprévu. Dans ce cas, il devient nécessaire de remonter cet aspect dans la signature du type.

Un point intéressant, si nous remontons le passé de Scala, nous retrouvons cette argumentation lorsqu'il est question de communication distante en particulier. Et c'est ce qui est aussi inclus dans la notion d'effet.

Ce qui nous donne le type ci-dessous

trait IO[E, A] {
  def run: () => Either[E, A]
}

Nous pouvons retrouver une implémentation équivalente dans ZIO. Cette bibliothèque définit aussi un type IO à deux paramètres. Par contre, il n'y a pas de méthode run dans le type. ZIO fournit déjà un environnement d'exécution représenté par le trait App, à "étendre" en redéfinissant une méthode run pour utiliser votre code incluant des effets. ZIO définit un type Task[A] définit comme IO[Throwable, A], ce qui permet de simplifier la lecture du type.

IO avec ZIO, c'est BIO !

Partons d'un exemple : une fonction qui lit un entier sur l'entrée standard (stdin). Pour cette fonction, nous avons un cas imprévu si l'utilisateur fournit autre chose qu'un entier.

def readInt: Task[Int] = Task { scala.io.StdIn.readInt() }

Voici un exemple de programme ZIO où cette fonction est intégrée.

import zio._
import zio.console._

object ReadIntMain extends App {

  override def run(args: List[String]) =
    program.absorb.fold(
      // in case of failure
      e => { e.printStackTrace(); 1 },
      // in case of success
      _ => 0)

  val program =
    for  {
      _      <- putStrLn("Input an integer:")
      number <- readInt
      _      <- putStrLn(s"value: $number")
    } yield ()

}

Quoiqu'il en soit, dans ce code, les effets sont uniquement exécutés une fois que le résultat de la méthode est récupéré par le main de App. En dehors de ça, les effets sont uniquement encapsulés et représentés dans le type IO.

Ainsi, si nous revenons sur notre exemple initial au tout début de l'article, avec ZIO. Nous avons

val program =
  ZIO.collectAll(
    List(putStrLn("Hello"), putStrLn("Hello"))
  )

Qui donne

Hello
Hello

Par refactoring, on peut écrire le code suivant

val result = putStrLn("Hello")

val program =
  ZIO.collectAll(
    List(result, result)
  )

Qui donne aussi

Hello
Hello

Ce qui respecte le principe de transparence référentielle.

À travers le type IO, les effets deviennent des valeurs manipulables comme tels, qui peuvent être intégrées dans des expressions et craignent d'autant moins le refactoring. Nous pouvons le constater avec la bibliothèque ZIO. Le code devient plus accessible, nous pouvons raisonner simplement dessus et intervenir dessus avec un meilleur niveau de confiance.

DataXDay 2019 - Le retour de l'équipe Univalence

2019-12-18T23:00:00Z

Nous sommes seulement une semaine après le Process Mining Camp 2019 et déjà un autre événement se présente à nous, le DataXDay. Un événement organisé par l'entreprise Xebia et regroupant des dizaines et des dizaines de Data Engineers et Data Scientists tous ayant soif de connaissances et de partages.

Cette fois-ci tous les data ingénieurs d'Univalence ont ainsi pu y participer et l'un d'entre nous a même eu l'occasion de faire un talk, L'incroyable efficacité de l'unification des logs, qui aura très certainement un article qui lui est consacré dans le futur! Sur cette journée de conférence, il y a eu 22 talks centrés autour de la data ayant tous des sujets divers et variés parfois plus dédiés aux data scientists, parfois plus dédiés aux data engineers et parfois alliant les deux.

NB: Tous les talks sont d'ores et déjà présents gratuitement sur Xebia TV ou plus simplement dans la section vidéo du site DataXDay 🎉

Nous allons, dans cet article, vous partager notre expérience et les différents talks auxquels nous avons participé. La conférence ayant deux tracks se déroulant en parallèle, je ne ferais part que des talks auxquels j'ai participé. Ainsi voici la liste des talks que je ne traiterais pas lors de cet article accompagné d'un lien pour les visionner sur Youtube :

DataXDay - De Jupyter à Spark : les étapes de la mise en production du Machine Learning par Pauline Nicolas et Théo Bontempelli

Confident Data Migration: automatic regression testing par Thomas Franquelin

Keynote #1 : La confiance entre les humains et les données

La journée a commencé avec un talk de Caroline Goulard, anciennement journaliste de la donnée qui, maintenant, est CEO à Dataveyes, une entreprise qui, comme elle le dit si bien, tant à vouloir "rendre l'invisible visible".

Lien vers la vidéo: https://www.youtube.com/watch?v=HtYf2brLIXw

D'ailleurs son talk était justement basé sur ce postulat, aujourd'hui nous sommes dans l'air de la donnée et malgré ce fait nous sommes la plupart du temps incapables de voir ce qu'elle représente vraiment. La visualisation de la donnée donne un sens à cette dernière et la rend accessible au plus grand nombre. J'ai d'ailleurs particulièrement apprécié les travaux qu'ils ont effectués notamment en visualisant l'impact sonore des différentes lignes de métro sur Paris. Le résultat étant, de par sa qualité, très impactant pour l'utilisateur. Un autre exemple sur la gestion de l’énergie d'une maison m'a aussi énormément interpellé, notamment grâce à la mise en place de la gamification au sein même du système. Ce dernier aspect rend la présentation globale de notre data plus actifs que jamais. Une idée incroyable, participant à réduire la consommation des personnes de manière ludique.

Somme toute un très bon talk pour commencer la journée (un de mes préférés) même si je regrette un peu qu'il n'eût aucune technologie de cité, afin d'occuper mes dimanches à donner de la vie à de la donnée (Mon petit doigt me dit que l'utilisation de l'API WebGL et d3.js doit être de mise 😉).

Keynote #2 : Database Infrastructure at Instagram Scale

Lien vers la vidéo: https://www.youtube.com/watch?v=b74cU-afJHM

S'ensuit un talk très intéressant pour tout les data ingénieurs, un talk de Michaël Figuière travaillant anciennement chez Instagram et actuellement Data Infrastructure Engineer chez Facebook. Ce dernier a notamment attiré notre attention car Michaël nous partage certaines problématiques qu'une architecture d'une ampleur considérable peut créer. Instagram est très certainement l'application django la plus complexe et avec plusieurs millions de lectures et écritures par seconde elle se doit d'avoir une infrastructure particulièrement tenace.

Ainsi à titre d'exemple, Instagram shutdown très régulièrement des datacenters entiers pour tester l’adaptabilité de l'infrastructure en cas de crises majeures (spoil alert: tout se passe bien!). De plus chaque datacenter est configuré pour gérer un certain nombre de requêtes et pour trouver ce nombre, l’infrastructure surcharge un des datacenters afin de voir sa limite et ainsi de pouvoir quantifier la quantité d'informations qu'il peut traiter. Un autre fait intéressant, vos données Instagram vous suivent dans vos déplacements ainsi si vous décidez de partir en voyage aux États-Unis alors vos données actuellement concentrées dans le cluster Europe vont être déplacées dans le cluster Amérique du Nord pour réduire la latence.

Kafka Streams, profiling, framegraphs, Oh My!

Lien vers la vidéo: https://www.youtube.com/watch?v=DBfmKE42PiY

Nous avons continué notre matinée avec un talk de Xavier Léauté qui est actuellement software engineer chez Confluent. Le but de ce talk, partager certaines astuces pour optimiser et profiler un kafka streams. Ce talk bien qu'étant focus sur kafka est aussi très intéressant pour l'optimisation de n'importe qu'elle programme s’exécutant via la JVM.

Xavier rappelle que le profiling est important pour éviter de rencontrer des problèmes par la suite. Ce monitoring peut se faire via les metrics (Je vous recommande d'ailleurs cette trilogie d'articles sur le monitoring de kafka écrit par Evan Mouzakitis sur le site de DataDog). Cependant, Xavier nous met en garde. Les metrics sont adressés à des problèmes déjà rencontrés auparavant, mais il se peut que vos problèmes seront uniques à votre cas, de plus certains problèmes n’apparaîtrons qu'en production et pas en phase de test et dans ce cas la, il faut creuser plus bas pour détecter les bottlenecks.

L'outil de prédilection pour faire du profiling selon ses préférences est Async Profiler. Il le décrit comme étant l'outil le plus simple et le plus puissant pour faire faire du profilage d'application basé sur la JVM. Ses points positifs ? Il est très léger, s'attache directement à la JVM sans avoir besoin d'argument ou de restart cette dernière et est compatible avec les anciennes versions du JDK.

Deep learning en production vu par un Data Engineer

Lien vers la vidéo: https://www.youtube.com/watch?v=aLowsPZjVew

Rien de mieux qu'un talk sur le deep learning en production pour satisfaire à la fois les Data Scientists et à la fois les Data Engineers présents à l'événement. Cette idée, elle vient de Romain Sagean, un consultant chez Xebia.

Son objectif est très simple, faire part de son expérience personnelle de la mise en place d'un modèle de deep learning dans une chaîne de production et le tout vu par un data ingénieur. L'objectif du projet étant d'acheter des liens sponsorisés Google à moindre de coup pour un total de 10 millions de prédictions par jour et les faire en moins d'une heure.

Dans un tel contexte, il faut faire des choix. Quel modèle utilisé pour notre prédiction? quel framework utilisé pour créer le modèle et prédire?

Dans le cas de Romain et son équipe, ils ont d'abord testé différents modèles de machine learning et sont venu à la conclusion que XGBoost était un choix intéressant car donnant les meilleures prédictions. Mais finalement, ils vont se diriger vers du deep learning car plus de possibilités et de potentiels là où XGBoost atteignait déjà ses limites. Une fois le modèle prêt, il fallait choisir le framework à utiliser: TensorFlow et Keras ce sont immédiatement présenter à eux pour leurs communautés et leurs maturités respectives mais ils ne se sont pas arrêté à eux et ont aussi inclus dans leur choix DL4J et mxnet.

Basé sur des critères propres à leur architecture, TensorFlow l'a emporté, mais impossible de le faire fonctionner en production à cause d'une version de glibc trop vieille au niveau de la production. Plutôt que d'update toute la chaîne de production, le choix le plus raisonnable en matière de temps et de moyens était de sélectionner le deuxième sur la liste DL4J, un framework codé en Java. S’intégrant parfaitement en production, il ne manquait plus qu'à l'optimiser. L'optimisation a été faite de bien des manières et voici quelques-unes des pistes traitées lors du talk: preprocessing, mapper les values par partitions, créer un seul modèle lazy et non un modèle par ligne, set spark.yarn.executor.memoryOverhead, gérer les workspaces DL4J.

How to leverage the Apache Kafka Ecosystem to productionize Machine Learning

Lien vers la vidéo: https://www.youtube.com/watch?v=I4eDowjTZLk

Un talk imaginé par Kai Waehner qui est Technology Evangelist à Confluent qui, dans la même veine que le dernier talk, s'adresse à la fois aux Data Scientist et au Data Engineer. Cependant celui-ci s’intéresse beaucoup plus à la place du machine learning autour d'une architecture Big Data plutôt qu'à la sélection d'un modèle et de son implémentation en production.

Avec la présence de très bon framework de machine learning tels que Keras ou TensorFlow, il est très facile aujourd'hui de faire du machine learning. Mais une tâche beaucoup plus complexe est d'adapter ces frameworks à des cas où des millions d'informations arrivent en temps réel. Dans un cas comme celui-ci, on peut se demander comment entraîner le modèle en continue tout en appliquant le modèle en cours pour prédire des informations. Fortes heureusement pour nous, de grandes entreprises sont déjà passé par là et proposent des solutions pour nous aider dans notre tâche. Kai prend l'exemple de Michelangelo, un framework made in Uber pour mettre en place du Machine Learning "at uber's scale".

La plupart des solutions fonctionnent avec Kafka et Kai nous donne les différentes raisons qui font que Kafka est la solution pour du machine learning en production. Il insiste d'ailleurs sur un point très important, Kafka n'est pas seulement un mécanisme de publication de message mais aussi un lieu de storage scalable et un lieu où on a le pouvoir de prétraiter notre data. De plus il tient aussi à nous rappeler que kafka ne se résume pas au broker que l'ont chéri tant mais fait partie d'un écosystème où l'on retrouve Kafka Streams, Kafka Connect ou encore KSQL (un outil développé pour prétraiter de la data en SQL en production permettant ainsi de réconcilier Data Scientists et Data Engineers). Le fait est qu'aujourd'hui il existe en plus une solution pour faire ingérer un flux de données venant de Kafka directement à TensorFlow ce qui nous permet d’entraîner notre modèle en temps réel. Toutes ses caractéristiques pour ne citer qu'eux rendent Kafka très attrayant justifiant ainsi sa popularité.

Traitement automatique du langage pour le routage d'emails

Lien vers la vidéo: https://www.youtube.com/watch?v=ANrdU6UgtZU

Il y a eu beaucoup de data engineering dans ces derniers talks, il était temps de prendre un peu l'air et rien de mieux que ce talk pour se détacher des technologies du big data afin de s'adonner à un peu de text mining avec l'incroyable librairie Melusine codée en python.

Ce talk nous a été fournis par deux Data Scientists travaillant à Quantmetry, Tom Stringer et Antoine Isnardy. La librairie a pour but de fournir tout les outils nécessaires afin de faire du traitement automatique de mail de A à Z. Elle se décompose en plusieurs modules dont trois principaux :

Un module de preprocessing et de cleaning de mail afin de diviser les différentes parties de ce dernier.
Un module qui résume un mail en extrayant les différents mots jugés importants.
Un module de classification qui utilise les réseaux de neurones récurrents et/ou les réseaux neuronales convolutifs pour classifier les mails vis-à-vis des catégories définies au préalable

Ce talk a notamment été intéressant, car il a soulevé certaines problématiques telles que la transformation d'un produit (Melusine était destinée à être utilisé à la Maif) en un outil open source qui, de ce fait, requiert d'avoir une documentation claire et précise ainsi qu'un code modulable et adaptable pour tous.

L'incroyable efficacité de l'unification des logs !

Lien vers la vidéo: https://www.youtube.com/watch?v=ryFAZZEZbyw

Le talk tant attendu par les univaliens puisque le talker n'est personne d'autre que Jonathan Winandy, le fondateur d'Univalence 😎. Dans ce talk, Jon a décidé de parler de log et de tracing à travers un talk assez déjanté et très bien structuré. D'ailleurs, Jon écrira très certainement un article qui rentrera plus en détail que cette petite introduction.

Le talk part d'une tendance concrète, aujourd'hui nos applications sont de plus en plus complexes et il est de plus en plus dur de créer une histoire retraçant les actions de notre système lui-même composé d'une multitude de micro services. L'histoire est, concrètement, un ou plusieurs fichiers où sont stockés des événements émis par l'application. On peut par exemple, en Java, utiliser l'Apache Logging Services (Log4j 2) pour créer ce système de log.

Malheureusement, les applications sont devenues trop complexes pour que le logging soit efficace, une application a une multitude de micros services et chacun d'entre eux racontent sa propre histoire. Jon nous parle alors du descendant du logging, le tracing et d'une technologie qui met tout le monde d'accord : OpenTelemetry. Le tracing, comparer au logging, a un contexte causal créant une dépendance entre les logs.

Mais encore une fois, ce n'est pas assez. Jon propose d'aller encore plus loin dans le tracing avec un projet : Zoom. Son but étant d'utiliser les outils de monitoring distribué, d'unifier les logs avec la donnée sous forme d'événement, et d'améliorer la prise en compte des lieux de calculs en accentuant sur les lignes de codes utilisés, les commits effectués, la machine qui calcule, etc. Afin d'avoir l'histoire la plus claire possible.

Incremental Data Architecture

Lien vers la vidéo: https://www.youtube.com/watch?v=sew2i7G96a8

On change de salle et on rejoint un talk sur l'incremental data architecture, un talk vraiment très intéressant et très dynamique donné par Walid HAOUARI, Big Data Engineer à Xebia.

Ce talk était bien, vraiment bien. Le sujet abordé était très universel et le choix de passer par un cas concret permet d'associer ce talk aux problématiques que l'on rencontre dans nos différents métiers. Walid a pris le cas d'une stratup fournissant un système d'analyse médicale à un petit village d'Afrique ayant pour but de s’accroître pour obtenir une architecture capable de gérer plusieurs villages entiers. Il explique comment et pourquoi il est préférable d'établir une architecture cible dès le commencement puis de la déstructurer afin d'obtenir des architectures réalisables d'un point de vue économique, temporelles et technologiques. Pour, par la suite, incrémenter cette architecture et tendre vers l'architecture cible.

Il nous met en garde sur le choix que font certaines entreprises de changer complètement d'infrastructure, un choix qui se trouve être la plupart du temps inefficace et périlleux car vous risquer d'écœurer votre équipe qui ne retrouve plus ses marques et qui doit, si cela n'a pas été fait auparavant, monter en compétences pour maîtriser tout les nouveaux outils.

Harnessing the power of Generative Adversarial Networks (GANS) for supervised learning

Lien vers la vidéo: https://www.youtube.com/watch?v=aL7rhJz8mAI

S'en est suit un talk d'Olga Petrova, une Machine Learning DevOps Engineer à Scaleway. Elle a fait le choix de nous parler des Generative Adversarial Networks plus communément appelé GAN notamment très utilisé pour générer des images très réaliste dans le cas d'un face swaping par exemple.

Après une courte introduction sur la différence entre supervised et unsupervised learning. Olga nous a montré des exemples d'applications des GAN. GAN est notamment utilisé pour générer la tête de personne n'existant pas alors que tout porte à croire l'inverse tant le réalisme est au rendez-vous. C'est comme ça que https://thispersondoesnotexist.com/ existe, un projet créé par Nvidia. D'autres projets tout autant ambitieux nous ont été présenté tels que la face frontalization qui consiste à prendre une photo d'une personne ayant un angle de tête quelconque en entrée et de renvoyer sa tête de face en sortie ou encore la super résolution (Un exemple de projet ici) visant à augmenter la résolution d'une image.

Elle nous a aussi fait part de sa libraire de machine learning en python préféré. Alors que tout le monde ne jure que par Tensorflow ou Keras, Olga, quant à elle, ne jure que par PyTorch et était étonnée qu'il ne soit pas mentionner dans les autres talks ce qui à attiser ma curiosité. Fun fact intéressant, ces librairies en accord avec cet article atteignent les limites du langage, à voir ce que le futur nous réserve !

Give meaning to 100 billion analytics events a day, analytics at Teads

Lien vers la vidéo: https://www.youtube.com/watch?v=Up3iaK5fdjw

La journée continue et touche presque à sa fin. Notre avant-dernier talk est produit par Alban Perillat-Merceroz, Software Engineering Master pour Teads. Cette société ne vous dit peut-être rien au premier abord et pourtant, tout le monde a déjà vu leur travail à l'oeuvre. La pub qui s'affiche lorsque vous lisiez vos news le matin pendant le trajet jusqu'au travail, ce sont eux! Et pour pouvoir proposer les meilleures pubs aux différents utilisateurs, Teads est confrontée à plus de 100 milliards d'événements par jour.

Autant d'événements supposent une architecture Big Data solide pouvant engranger un aussi grand nombre de données. Pour résumer très succinctement, voici comment leur architecture se construit. Le browser envoi des événements à savoir : si la personne à cliquer sur la pub, quand la pub à commencer, quand la pub à stopper. Ces événements transitent dans Kafka, sont traités via DataFlow pour ensuite être écrits directement dans BigQuery. Il reste à récupérer les données qui sont encore à ce stade des raw data pour les fournir en tant qu'outils d'analyse et ainsi apporter de la valeur. À ce stade, l'entreprise est passée par plusieurs types d'architecture (Infobright Enterprise Edition) pour finalement entièrement se tourner sur RedShift en tant que datamart.

Cette technologie est assez atypique car jouant sur deux types de services de cloud computing différents créant ainsi une latence lors des transitions entre deux types de technologies. Une question très intéressante a d'ailleurs été posée à la fin de ce talk ouvrant la porte à une solution permettant d'accumuler la totalité de la data, passé de Kafka à Cloud Pub/Sub pour garder une cohérence technologique et rendre le système beaucoup plus pratique. On a tendance à oublier que des "équivalents" Kafka existent tant ce dernier est chéri par tous et il est intéressant de songer aux alternatives qui dans des cas comme celui-ci ou on a une architecture très orienté gcp pourrait être une bonne idée.

The internals of stateful stream processing in Spark Structured Streaming

Lien vers la vidéo: https://www.youtube.com/watch?v=yhSwQ-GqAoA

De par son côté très technique, finir avec un talk de Jacek Laskowski, un grand nom de la communauté Spark, n'est pas gagné. Cependant son côté très enjoué et plein de vie a complètement inversé la tendance et ce qui devait être un talk assez lourd c'est transformé en quelque chose de très plaisant à regarder et à écouter. Ce talk se base sur spark 2.4.3 et se base sur la partie structured streaming.

En réalité, spark ne fait pas exactement du temps réel. Comme l'explique Jacek, spark exécute des minis batchs très très rapidement à la place donnant cette impression de temps réel. Sachant cela, il est facile de comprendre que tout ce qui est faisable avec sparkSQL est faisable en streaming avec le structured streaming. Mais pas que, vous pouvez aussi très bien utiliser la DataSet API et vous ne serez donc pas perdu avec le côté streaming que fournis Spark.

Spark streaming peut être vue comme un équivalent à Kafka Streams ou encore Flink mais Jacek insiste quand même sur une différence majeure. Spark streaming a la possibilité de traiter une centaine de lignes en même temps quand les deux autres solutions ne peuvent en traiter qu'une à chaque fois.

DataXDay pour l'équipe

DataXDay ne se résume pas qu'à de très bons talks, mais aussi et surtout à une organisation faite aux petits oignons. En plus des talks, la qualité des différents repas (le saucisson et la fontaine de chocolat 😵), la bonne humeur de l'équipe de Xebia qui a organisé l'événement (Giulia Bianchi, Loïc Divad, Souhaib Guitoni, Anne Beauchart, Sandra Pietrowska, Sameh Ben Fredj et Elhadi Cherifi) et la qualité des animations (le data lake était génial encore merci pour les tableaux 😉) ont fait de cet événement un événement mémorable pour l'équipe Univalence. Cet événement nous a permis de tous nous retrouver dans la joie et la bonne humeur et il m'a aussi permis de découvrir et/ou me forger un avis sur énormément de différentes technologies du Big Data.

Hâte de vous retrouvez au DataXDay 2020 🚀

Tests with Spark: how to keep our heads above water

2019-12-08T23:00:00Z

Are you drowning in your Spark tests? Are you tired of declaring a Spark session every time? We have the solution for you! With Spark-Test™, write your tests without any difficulties!

Great question, Baby Beaver! Spark-Test is one of the numerous libraries in Spark-Tools, a set of tools designed to make life easier for Spark users. We invite you to discover the other tools over the next few articles we'll be publishing. (Pardon our French! There are already some en français, on Spark-ZIO, a library that combines ZIO and Spark, and on Spark Plumbus proposing some creative solutions here and there.)

Let's discover Spark-Test

Today, we start with the library that is the easiest to learn and to use from the set: Spark-Test. This library provides tools that makes it easier to create tests related to dataframes and/or datasets by making them simpler while providing clear and accurate information through metadata!

Some of your might already be familiar with MrPowers' spark-fast-tests (https://github.com/MrPowers/spark-fast-tests). We decided to tackle testing problems from a different angle, which resulted in a very different conception. Apart from having a different architecture, Spark-Test offers more accurate error reporting. Currently, we're working on improving performance for future updates, which will help greatly accelerate testing.

Caption: (For testing, I mean. For testing!) ou ou... (Just kidding. We all love testing, don't we?)

Setting up

It's easy. You just need to add Spark-Test's dependency in build.sbt, then extends SparkTest in your test file and voilà! For those who are starting to dabble with Scala libraries, here's a skeleton of Spark-Test you can build on.

libraryDependencies += "io.univalence" % "spark-test_2.12" % "0.3"

package io.univalence.sparktest

import org.scalatest.FunSuite

class GettingStartedTest extends FunSuite with SparkTest {

  test("some test") {
    // Start the test here...
  }

}

Now that everything is ready, let's start by creating a dataframe that will serve as an example throughout this article. Spark-Test provides tools that help you to create a dataframe or a dataset quickly for your tests. So we're going to use one of them right now!

You don't need to instantiate a SparkSession. Everything is already set up for you.

val df = dataframe("{a:1, b:true}", "{a:2, b:false}")
/*
| a |   b   |
+---+-------+
| 1 | true  |
| 2 | false |
*/

Let's compare dataframes

Now, let's imagine that we want to compare two dataframes. You should know that we can obtain two types of differences: differences with both schemas and differences with the values.

First, we will implement a solution without using Spark-Test. To do this, we will need to retrieve schemas of the two dataframes, retrieve values, and compare them to see if our dataframes are different or not. This is one of the many possible solutions.

//without using Spark-Test
def isEqual(df1: Dataframe, df2: Dataframe): Unit = {
  if (!df1.schema.equals(df2.schema))
    throw new Exception("schemas are different")
  if (!df1.collect().sameElements(df2.collect()))
    throw new Exception("values are different")
}

test("some test without Spark-Test") {
  val df1 = dataframe("{a:1}")
  val df2 = dataframe("{a:1, c:false}")

  isEqual(df1, df2)
  /*
   * java.lang.Exception:
   * Les schemas sont différents
   */
}

This solution has several problems:

The lack of information provided by our Exception: we are able to know if the equality problem comes from the schema or if it comes from values. But we are unable to know exactly what the problem is, how schemas are different to each other, or which values are different.
The lack of flexibility: you may only want to compare the common columns between the two dataframes. As an example, we're only looking at the column "a" in the dataframe above.

This may seem trivial, since our dataframes do not contain more than two columns and two rows. But imagine two dataframes with thousands of columns and millions of rows...

Now, let's solve this problem using Spark-Test.

test("some test with Spark-Test") {
  val df1 = dataframe("{a:1}")
  val df2 = dataframe("{a:1, c:false}")

  df1.assertEquals(df2)
  /*
   * io.univalence.sparktest.SparkTest$SchemaError: 
   * Field c was not in the original DataFrame.
   */
}

We obtain a nice SchemaError. And that's not all! We also have the reason of this difference and that is what Spark-Test is all about. The error here comes from the column "c' which is not present in the original dataframe.

But, but… I wanted to compare columns in common 😣

Don't panic! Don't panic! Simply use the Spark-Test configuration and specify that you want to ignore the extra columns located in df2.

test("some test with custom configuration") {
  val df1 = dataframe("{a:1}")
  val df2 = dataframe("{a:1, c:false}")

  withConfiguration(failOnMissingExpectedCol = false)({ df1.assertEquals(df2) })
  /*
   * Success
   */
}

Yeaaahh! The test goes off without a hitch. 🤗

Now, let's look at the case where two dataframes have the same schema but are still different. This is due to one or more value errors, i.e. dissonances within the columns themselves.

test("some test with same schema") {
  val df1 = dataframe("{a:1, b:true}",  "{a:2, b:true}", "{a:3, b:true}")
  val df2 = dataframe("{a:1, b:false}", "{a:2, b:true}", "{a:4, b:false}")

  df1.assertEquals(df2)
  /*
   * io.univalence.sparktest.SparkTest$ValueError: 
   * The data set content is different :
   *
   * in value at b, false was not equal to true
   * dataframe({b: true, a: 1})
   * dataframe({b: false, a: 1})
   *
   * in value at b, false was not equal to true
   * in value at a, 4 was not equal to 3
   * dataframe({b: true, a: 3})
   * dataframe({b: false, a: 4})
   */
}

Finally, here it is, the second error: ValueError. This error informs us about the differences between the two dataframes by specifying the error, as well as the lines where the said errors are found in eithers df1 or df2.

The precision given by errors, the flexibility, and ease of use, here are the strengths of Spark-Test. This library provides other features (such as a function to check a predicate in a whole Dataset) that can make your life as a data engineer easier. The cherry on top? Spark-Test is fully open source. It is available here:

https://github.com/univalence/spark-tools/tree/master/spark-test.

We welcome any feedback and of course, we'll be delighted to hear about your use cases! 😁

Les monoïdes ne sont pas une maladie

2019-10-07T22:00:00Z

Provenant de lieux lointains dans l'univers (ce qui est pléonastique, puisque quoi que nous regardions dans l'univers, c'est forcément loin) et traversant l'espace à une vitesse inimaginable, des rayonnements viennent frapper les capteurs d'un satellite artificiel, délogeant sans gêne des électrons suivant leur course probabiliste tranquille autour d'atomes. Ce qui ne va pas sans électriser l'environnement. Par cette excitation locale et des mécanismes plus ou moins similaires, nos rayonnements initiaux sont transformés en quelque chose qu'on peut interpréter sous forme de nombres et transmis par radiocommunication vers une planète bleue (quoique pas trop), tellement petite qu'on la distingue à peine depuis Europe, le satellite de glace de Jupiter. Là sur cette planète, une partie certainement infime de nos émissions radios rebondissent sur un dôme inversé, atteignant un espace réduit, pour à nouveau être converties en signaux électriques et grâce à des procédés complexes terminer leur course écrasés contre un écran d'ordinateur sans pouvoir se plaindre. Tout ça pour vérifier si, par additions ou par multiplications successives lancées séquentiellement ou parallèlement, un rayonnement lointain permet de justifier une découverte astronomique... ou pas.

Cette histoire se voit attribuer de nombreux héros permettant de faire avancer la connaissance humaine. Si nous nous permettons quelques personnifications, il y a certes tous les dispositifs matériels et électroniques qui ont un rôle prépondérant. Mais il faut aussi compter sur les outils mathématiques. Et dans ce cadre extraordinaire, les seuls outils dont j'ai fait référence ici sont pourtant parmi ceux les plus utilisés au quotidien par nous simples développeurs sur des applis de gestions, du tracking d'utilisateurs ou des jeux sans fin qui consistent à aligner des friandises pour pouvoir avancer.

Invasion monoïde

Faire une succession d'additions est une opération courante :

def masseSalariale(remunerationBrutes: List[Double]): Double =
  remunerationBrutes.foldLeft(0.0) {
    case (sousTotal, remunerationBrute) => sousTotal + remunerationBrute }

Faire une succession de multiplications aussi :

def prixFinal(prixInitial: Double, tauxInflation: List[Double]): Double =
  tauxInflation.foldLeft(prixInitial) {
    case (prixActuel, inflation) => prixActuel * (1.0 + inflation) }

Faire autre chose aussi :

val data = Map(
  "Paris" -> 19.0,
  "Marseille" -> 12.0,
  "Paris" -> 8.0,
  "Paris" -> 15.0,
  "Marseille" -> 20.0,
  "Lyon" -> 10.0
)

def priceByCities(data: Map[String, Double]): Map[String, Double] =
  data.foldLeft(Map[String, Double]()) { case (acc, (city, price)) =>
    if (acc.contains(city)) acc.updated(city, acc(city) + price)
    else acc.updated(city, price)
  }

Dans ces exemples, nous avons utilisé à chaque fois, l'opération de foldLeft qui permet d'agréger des valeurs en fonction d'une valeur initiale et d'une opération binaire.

Nous allons justement nous concentrer sur, à la fois :

l'ensemble des valeurs acceptées,
l'opération binaire,
la valeur initiale.

Ces trois éléments forment un tout indissociable. Ce tout est ce que les mathématiciens appellent un monoïde.

Sur le plan physique, les monoïds sont de la même taille que les humains, mais leur peau est sombre et composée d'écailles. Il n'ont qu'un seul œil sur la tête, au niveau de la bouche. Au XXVIIe siècle, ils savent toujours parler. Mais depuis le 57e Segment du Temps, ils n'ont pas de bouche visible et s'en tiennent à un langage de signes pour communiquer... Dr Who... Désolé.

Dans Dr Who, les monoïds sont des êtres qui peuvent être sympas avec les humains. Mais ça n'a pas toujours été le cas.

Sinon, un monoïde est une structure algébrique correspondant à un ensemble (les valeurs) avec un élément neutre (la valeur initiale) et une loi de composition interne associative (l'opération binaire). C'est souvent noté (E, ✻, e), avec E l'ensemble de valeurs, ✻ la loi de composition interne et e l'élément neutre.

Alors, on dit loi de composition, car l'idée de notre opération est de combiner deux éléments de notre ensemble de valeurs (ie. de les composer, d'ailleurs on devrait pouvoir parler d'agréger des valeurs). On dit interne car en combinant ces deux valeurs, notre opération retourne une nouvelle valeur qui fait partie de notre ensemble initial de valeurs (ie. on ne sort pas de cet ensemble).

Pour associative, hé bien... Si nous utilisons plusieurs fois notre opération dans une expression, il est alors possible d'évaluer l'expression quelque soit l'endroit où on commence à l'évaluer. C'est-à-dire qu'avec l'expression a + b + c, je peux très bien commencer par x = a + b et ensuite faire x + c ou commencer par x = b + c et faire a + x après. Au final, on note ça (a + b) + c = a + (b + c). L'ordre d'évaluation des sous-expressions n'a pas d'importance pour un monoïde.

C'est une propriété intéressante, car ça permet de découper une expression en sous-expression et d'évaluer ces sous-expressions en parallèle, puis de récupérer et combiner les résultats de ces évaluations pour obtenir le résultat final... Et comme ça, on vient de réinventer MapReduce !

Voyons ce que ça donne...

Tes monoïdes font du MapReduce en ski !

Voici une liste de stations de ski avec notamment leur localisation et une évaluation sur 5.

Nous avons ci-dessous un extrait d'une liste des stations de ski en France. Bon... Ce n'est pas du big data, hein ! Mais on va faire comme si 😬.

station_name,station_rating,city,postal_code,county,departement,region,latitude,longitudeLus la Jarjatte,5.0,1,Lus-la-Croix-Haute,26620,Die,Drôme,Auvergne-Rhône-Alpes,44.679971,5.7661523
Panticosa,5.0,,,,,,,
Formigal,4.5,,,,,,,
Cerler,4.5,,,,,,,
Baqueira / Beret,4.5,,,,,,,
Val d'Isère,4.4,Val-d'Isère,73150,Albertville,Savoie,Auvergne-Rhône-Alpes,45.4498666,6.9804421
La Grave,4.4,La Grave,05320,Briançon,Hautes-Alpes,Provence-Alpes-Côte d'Azur,45.0455379,6.3068184
La Sambuy,4.4,,,,,,,
Le granier,4.4,Aime-la-Plagne,73210,Albertville,Savoie,Auvergne-Rhône-Alpes,45.60089445,6.62550908591405
Mont-Saxonnex,4.4,Mont-Saxonnex,74130,Bonneville,Haute-Savoie,Auvergne-Rhône-Alpes,46.0508713,6.4792764
Les Karellis,4.3,Montricher-Albanne,73870,Saint-Jean-de-Maurienne,Savoie,Auvergne-Rhône-Alpes,45.215851,6.399584218507
Peisey-Vallandry,4.3,,,,,,,
Le Mourtis,4.3,,,,,,,
Lans en Vercors,4.3,Lans-en-Vercors,38250,Grenoble,Isère,Auvergne-Rhône-Alpes,45.1277768,5.5891386
La Giettaz en Aravis,4.3,La Giettaz,73590,Albertville,Savoie,Auvergne-Rhône-Alpes,45.8827863,6.5334974
Sainte-Anne,4.3,Sainte-Anne,97180,Pointe-à-Pitre,Pointe-à-Pitre,Guadeloupe,16.225685,-61.3859128
Pic du Midi de Bigorre,4.3,Bagnères-de-Bigorre,,Bagnères-de-Bigorre,Hautes-Pyrénées,Occitanie,42.9367764,0.1416107

Cette liste n'est pas complète en terme d'information. Malgré ça, nous allons donner la moyenne des évaluations... tel que le ferait MapReduce ou Spark.

Dans MapReduce, il y a une étape de préparation des données où on part d'un fichier pour le convertir en un ensemble clé/valeur. Notez que l'évaluation est en position 1 dans chaque ligne (en commençant par 0) et que le département est en position 6.

import scala.collection.MapView
import scala.util.Try

def getRatingsByDepartement(lines: Iterable[String]): MapView[String, Iterable[Double]] = {
  // drop CSV header
  val data: Iterable[String] = lines.drop(1)

  val rows: Iterable[Array[String]] =
    data.map { line =>
      // cleaning line and separate fields
      val row: Array[String] = line.trim.split(",")

      // cleansing: if fields are missing, we pad row with empty strings
      row.padTo(7, "")
    }
  
  val deptRatings: Iterable[(String, Double)] =
    // we remove lines with no departement
    rows.filterNot(_(6).isEmpty)
      .map(fields =>
        (fields(6), Try { fields(1).toDouble }.getOrElse(0.0))
      )

  deptRatings
    .groupBy { case (departement, rating) => departement }
    .view.mapValues(row => row.map { case (departement, rating) => rating })
}

La fonction getRatingsByDepartement exécute en fait un shuffle (ie. une redistribution des données) en réalisant un partitionnement utilisant le département comme clé (ce qui n'est pas la meilleure des clés, dans la mesure où la répartition des données dans les différentes partitions sera ici déséquilibrée, puisque par exemple dans les Vosges il n'y a pas beaucoup de stations contrairement à la Haute-Savoie... Mais, bon. Ce n'est comme si on pouvait faire du big data avec l'énumération des stations de ski en France). Le résultat de getRatingsByDepartement est de type MapView[String, Iterable[Double]] — MapView est une "vue" sur une collection de type Map. Ici, à chaque clé correspond une partition des évaluations. Dans le cadre de MapReduce, chaque partition serait déposée dans des nœuds différents du cluster.

Il va maintenant falloir calculer la moyenne. En supposant, qu'on ait à faire à une liste immense, il est plus intéressant de parcourir cette liste en une seule passe qu'en deux. Car pour calculer une moyenne, il faut d'un côté une somme de valeurs et de l'autre leur quantité, avant de diviser ces deux résultats. Ce qui normalement implique deux passes sur notre dataset. Pour le faire en une seule passe, nous allons calculer la somme et la quantité en même temps, en stockant les résultats intermédiaires dans un couple de valeurs (somme, quantité).

Alors, il existe différentes approches pour implémenter ce calcul de moyenne. Pour l'exercice ici, nous allons étudier une solution mettant en avant la notion de monoïde, en se basant sur une typeclasse (un peu à la manière de la bibliothèque Scala Cats).

En Scala, pour déclarer une typeclasse Monoid, il faut déclarer un trait générique, où le paramètre A représente le type qui sera qualifié de monoïde. Ce trait contient deux méthodes empty qui retourne l'élément neutre et combine qui permet de combiner deux éléments de A.

trait Monoid[A] {
  def empty: A
  def combine(a: A, b: A): A
}

object Monoid {
  @inline def apply[A](implicit ev: Monoid[A]): Monoid[A] = ev
}

La méthode apply de l'object Monoid ci-dessus apporte une facilité d'utilisation du trait, qui permet par exemple d'écrire Monoid[Int].empty à la place de implicitly[Monoid[Int]].empty.

Déclarons quelques instances de notre typeclasse Monoid, qui nous servirons pour résoudre notre problème.

// Monoid (Int, +, 0)
implicit val intMonoid: Monoid[Int] = new Monoid[Int] {
  override def empty: Int = 0
  override def combine(a: Int, b: Int): Int = a + b
}

// Monoid (Double, +, 0.0)
implicit val doubleMonoid: Monoid[Double] = new Monoid[Double] {
  override def empty: Double = 0.0
  override def combine(a: Double, b: Double): Double = a + b
}

// turn any tuple (A, B) into Monoid, providing A and B both are Monoid
implicit def tupleMonoid[A: Monoid, B: Monoid]: Monoid[(A, B)] =
  new Monoid[(A, B)] {
    override def empty: (A, B) = (Monoid[A].empty, Monoid[B].empty)

    override def combine(left: (A, B), right: (A, B)): (A, B) =
      (Monoid[A].combine(left._1, right._1),
       Monoid[B].combine(left._2, right._2))
  }

Rajoutons à certaines collections une opération combineAll qui, dans la mesure où les valeurs contenues font parties d'un monoïde, combine toutes les valeurs contenues pour obtenir un unique résultat.

implicit class iterableWithCombineAll[A: Monoid](l: Iterable[A]) {
  def combineAll: A = l.fold(Monoid[A].empty)(Monoid[A].combine)
}

Utilisons notre fonction getRatingsByDepartement avec un fichier pour obtenir un partitionnement des données.

import scala.io.Source

val file = Source.fromFile("/data/geo/stations.csv")
val partitions = getRatingsByDepartement(file.getLines().to(Iterable))

Et maintenant, voici notre code MapReduce :

// phase 1 (Map): get ratings only and associate the value 1 to then
val partitionedRatingWithOne =
  partitions.mapValues(ratings => ratings.map(rating => (rating, 1)))

// phase 2 (Combine): locally sum ratings and 1s for each partition
val partitionedSumRatingsAndCount =
  partitionedRatingWithOne.mapValues(data => data.combineAll)

// phase 3 (Reduce): combine for all partitions the sum of ratings and counts
val (rating, count) =
    partitionedSumRatingsAndCount.values.combineAll

println(rating / count)

Ce qui donne environ 3.45 sur 5 sur notre dataset.

Et c'est ainsi que MapReduce fonctionne, si on inclut la phase Combine : 1/ Map : on transforme chaque élément dans une forme qui facilite les phases suivantes, 2/ Combine : on effectue un Reduce local pour réduire la quantité de données à transférer entre les nœuds du cluster à la phase suivante (c'est une optimisation), 3/ Reduce : on rassemble les résultats intermédiaires pour calculer et retourner le résultat final.

L'optimisation par la phase Combine est rendu possible par le fait que (Int, +, 0) est un monoïde, que (Double, +, 0.0) est un monoïde et qu'à partir de ((Double, Int), (+, +), (0.0, 0)) on a aussi un monoïde. Et comme l'opération combine sur un monoïde est associative, nous savons alors qu'il est possible de diviser notre calcul de la phase Reduce en plein de calculs intermédiaires de la manière qui arrange le plus.

Bien entendu, le code ci-dessus est très simple, alors que ce qui se passe dans une véritable implémentation de MapReduce est bien plus complexe. Mais pour arriver à un véritable MapReduce, ici il faudrait changer l'implémentation du type Iterable et s'intéresser aux méthodes drop, map, filter, groupBy, mapValues et fold. Il faudrait aussi changer la façon de lire un fichier surtout s'il est réparti sur un cluster. Tout ceci est disponible avec les RDD de Spark. Et avec les RDD de Spark, on aurait d'ailleurs une version bien plus simple.

// read and partition a file
val data: RDD[(String, Double)] =
  getRatingsByDepartement(sparkContext.textFile("/data/geo/stations.csv"))

// phase 1 (Map): get ratings only and associate the value 1 to then
val ratingWithOne: RDD[(Double, Int)] =
  data.map { case (departement, rating) => (rating, 1) }

// phase 2 (Reduce): combine for all partitions the sum of ratings and 1s
val (rating, count) =
  ratingWithOne.combineAll

println(rating / count)

// ----
// add combineAll to RDD
implicit class rddWithCombineAll[A: Monoid](l: RDD[A]) {
  def combineAll: A = l.fold(Monoid[A].empty)(Monoid[A].combine)
}

// ----
// data preparation
def getRatingsByDepartement(lines: RDD[String]): RDD[(String, Double)] = {
  val header: String = lines.first()
  val data: RDD[String] = lines.filter(row => row != header)
  val rows: RDD[Array[String]] =
    data.map { line =>
      // cleaning line and separate fields
      val row: Array[String] = line.trim.split(",")
      // cleansing: if fields are missing, we pad row with empty strings
      row.padTo(7, "")
    }
    // we remove lines with no departement
      .filter(row => !row(6).isEmpty)

  rows.map(fields => (
    fields(6), // departement
     Try { fields(1).toDouble }.getOrElse(0.0)) // rating
  )
}

Conclusion

Notre histoire de rayonnements cosmiques transformés en nombres écrasés sur un écran fait apparaître une forme de vie mathématique à part entière : les monoïdes. Ils sont partout et leur prolifération est incontrôlable. Car nous les retrouvons partout : dans les calculs scientifiques, dans les clusters, dans la gestion des règles métiers et même dans les additions de nos enfants. Et le plus saisissant est que nous les utilisons parfois sans nous en rendre compte.

Bien ou mal ? C'est à vous de décider. Mais une chose est sûr, c'est que les monoïdes apportent une aide indéniable.

Le code et les données : https://github.com/univalence/blog-code/tree/master/monoid

La data quality, notre amie pour la vie

2019-09-09T22:00:00Z

Structure

problem → solution → problem of this solution → solution of the problem of this solution

(best struture ever)

La data quality est un sujet qui ne fait pas beaucoup de bruit et à tort ! Si vous demandez à un data scientist ce qui lui prend le plus de temps, vous aimeriez qu'il vous dise que la majorité de son temps est consacrée à comparer des modèles de machine learning pour trouver le plus approprié ou qu'il est en train d'effectuer une tout autre analyse permettant, à l'aide de la data, de comprendre le problème donné. La vérité est tout autre, et ce, très souvent dû à une mauvaise qualité de données.

Dans la réalité qui est la nôtre, ces mêmes personnes vous diront qu'une large partie de leur temps est consacrée au data cleaning et à la data préparation. Selon Amelia Arbisser dans un talk au Spark Summit de 2016, ces deux phases occuperaient plus de 80% du temps d'un ingénieur travaillant avec des données.

L'ennemi public numéro 1 du data scientist

L'un des nombreux problèmes que l'on rencontre aujourd'hui, c'est qu'il y a trop de données inconsistantes et sales : du bruit dans le signal. Cela oblige les ingénieurs à consacrer une très (trop) grande partie de leur temps à la recherche de solutions contournant le problème ou à nettoyer la donnée. Dans certains cas, la donnée est complètement inutilisable et il suffit de se rendre sur un site comme Kaggle pour y trouver des dizaines de datasets incomplets, mais qui semblent pourtant très intéressants au premier abord.

Rien ne vaut un exemple pour appuyer mes propos. Voici un dataset provenant de Kaggle https://www.kaggle.com/datafiniti/womens-shoes-prices. Ce dataset peut être une véritable mine d'or d'information. Imaginons que cette data provienne d'un magasin de chaussures. Cette dernière pourrait servir à savoir la couleur à la mode actuellement, ou même le type de chaussure, ou même la forme et ainsi engranger de meilleures ventes. Cette information est très intéressante pour le commerçant. Alors on décide de s’adonner à la tâche et là... Le drame... 41% des articles n'ont pas la couleur renseignée. Cela fait plus de 13000 articles sur les 33800, que contient le dataset inutilisables. Cela n'est pas une fin en soi, mais on perd beaucoup d'informations. Alors on s'applique, on remarque un champ "feature" avec un JSON à l’intérieur et on essaye de l'exploiter pour y obtenir la couleur. Et mince ! Ici encore, il manque 20% de la donnée, la couleur n'est pas toujours présente on se retrouve avec un code immense, et ce, pour combler un manque de data quality qui peut être évité.

La data quality à travers le Constraint Checking

L’exemple précédent est très basique, le but étant qu'il parle au plus grand nombre. Généralement, la data est absorbée par d'autres systèmes accompagnés d'hypothèses implicites. Par exemple, une telle application va supposer qu'une des colonnes d'un quelconque dataset est d'un type X et qu'elle ne contient pas de valeur nulle. Si ces conditions ne sont pas respectées, l'application risque fortement de planter ou de proposer des résultats erronés. Ce fût le cas pour la NASA avec ses capteurs de radiation installés sur la station spatiale internationale (ISS). Ces capteurs devaient renvoyer 0 lorsqu'il n'y avait pas de radiations. Mais en la réalité, ils renvoyaient des nombres négatifs. Si ces nombres sont directement incorporés dans un réseau de neurones, cela peut provoquer des erreurs dans les prédictions pouvant mener à des conséquences plus ou moins catastrophiques. Heureusement pour nous, Miles Soloman, un étudiant de 17 ans a mis en lumière ce problème de fonctionnement et la NASA a ainsi pu corriger le tir.

Pour éviter ce genre de problème, il faut l'attaquer à la racine avant que la donnée nourrisse les algorithmes de machine learning et autres systèmes. Heureusement pour nous, il existe des bibliothèques et autres outils appliquant la data quality, permettant de rajouter un point de contrôle avant de nourrir ces futurs systèmes. Deequ est l'une d'entre elles et propose beaucoup de fonctionnalités en rapport avec la data quality. Car oui, il n'y a pas qu'une seule façon de faire de la data quality, mais des dizaines et des dizaines de pratiques toutes essayant de répondre à des besoins spécifiques selon le domaine métier envisagé.

Parmi elles se trouvent le constraint checking. Cette pratique consiste à appliquer des matrices aux différentes colonnes pour vérifier qu'elles respectent certaines contraintes. Prenons un dataframe contenant des informations utilisateur et utilisons le constraint checking proposé par Deequ, afin de contrôler la qualité de notre donnée.

case class Profile(id: Long, name: String, age: Int, sexe: String, photo: String)

val rdd = sparkSession.sparkContext.parallelize(Seq(
  Profile(1, "Georgie Hester", 25, "male", "https://randomuser.me/api/portraits/men/11.jpg"),
  Profile(2, "Daisie Farrington", 17,  "other", "https://randomuser.me/api/portraits/women/11.jpg"),
  Profile(3, "Raveena Espinoza", 37, "female", "https://randomuser.me/api/portraits/women/12.jpg"),
  Profile(4, "Donovan Salt", 21, "male", null),
  Profile(5, "Ella-Mai Landry", 49, "female", "https://randomuser.me/api/portraits/women/13.jpg")))

val data = sparkSession.createDataFrame(rdd)

e a self-hosted & open soCe genre de data suppose certaines propriétés. Il faut, par exemple, absolument que l'id soit unique et non null. Mais on peut rajouter énormément de règles pour essayer d'avoir le jeu de données le plus exploitable possible, comme ce qui suit :

val verification = VerificationSuite()
	.onData(data)
	.addCheck(
	  Check(CheckLevel.Error, "unit testing")
	    .hasSize(_ == 5) // 5 éléments dans notre Dataframe
	
	    .isComplete("id") // La colonne "id" n'a pas de Null
	    .isUnique("id") // La colonne "id" n'a pas de doublon
	
	    .isComplete("name") // La colonne "name" n'a pas de Null
	
	    .isPositive("age") // La colonne "age" est définit dans l'ensemble Z+
	    .hasMin("age", _ == 18) // La colonne "age" 

	    // La colonne "sexe" contient que des valeurs présentes dans l'array
	    .isContainedIn("sexe", Array("male", "female", "other"))
	
	    // La colonne "photo" contient au minimum 50% d'URL
	    .containsURL("photo", _ >= 0.5))
	.run()

Une fois la vérification faite, on obtient un objet VerificationResult contenant les résultats de l'analyse. On peut ainsi prendre en considération le cas où au moins une contrainte n'est pas respectée. Dans notre cas, on va juste les afficher en console. Mais l'objectif serait ici de traiter ces cas, soit en n'acceptant pas la source et en annulant alors l'action, soit en les envoyant dans un dataset à part, soit en traitant le dataframe en question à l'aide des informations données par le résultat.

if (verification.status == CheckStatus.Success) {
    // On envoie la data aux services d'après ou en route pour du machine learning 🧠
  } else {
    // On rejete la data, on la clean, on la fixe, on fait globalement ce qu'on veut, hein !

    // On peut récupérer les contraintes qui ont échouer comme suit
    val contraintes = verification.checkResults
      .flatMap { case (_, checkResult) => checkResult.constraintResults }

    val contraintes_ratées = contraintes
      .filter { _.status != ConstraintStatus.Success }
      
    // On affiche les contraintes qui ont empéché une bonne exécution du programme
    contraintes_ratées 
	.foreach { result => println(s"${result.constraint}: ${result.message.get}") }
  }

Dans notre cas, la data étant plutôt propre. On obtient juste l'erreur suivante :

We found errors in the data:

MinimumConstraint(Minimum(age,None)): Value: 17.0 does not meet the constraint requirement!

Et en effet, Daisie n'a pas encore 18 ans !

Comme dit précédemment, le constraint checking est l'une des nombreuses façons de faire de la data quality sur nos jeux de données. Une autre manière, par exemple, serait d'utiliser les annotations fournies par une de nos librairies: Centrifuge.

Centrifuge est très similaire au constraint checking à une différence près : ici, chaque ligne est associée à son lot de contraintes permettant une analyse au cas par cas. Tout dépend du problème qui vous fait face et de ce que vous recherchez. J'ai choisi ici de me concentrer sur Deequ, mais j'aurais bien pu faire écho à d'autres librairies proposant des solutions afin de répondre aux problèmes de qualité de la donnée. Drunken data quality, propose, à titre d’exemple, un service similaire à Deequ.

Un problème de taille

Qu'importe la solution envisagée, la data quality a un problème majeur : il alourdit le processus. Créer un profil résumant votre data ne peut pas être gratuit en matière de calcul et donc en termes de temps. Nombreux sont les outils qui, aujourd'hui, ne peuvent pas être utilisés, car rallongeant le processus d'un temps incommensurablement long à moins d'augmenter notre puissance de calcul et demandant une capacité de stockage parfois bien trop grande en vue de nos jeux de données immenses. Cependant, il existe des moyens de réduire drastiquement son impact. Cela n'est pas pour autant gratuit et généralement, un gain de temps et d'espace signifie obligatoirement une perte d'information.

Nous sommes, par exemple en ce moment même, en train de construire une librairie nommée Parka. Cette dernière applique une technique de data quality nommée delta QA. delta QA compare deux dataframes entre eux et nous informe de leurs différences. L'objectif premier de cette librairie est de faciliter les tests de non-régression en vérifiant que les changements effectués n'affectent pas de manière négative la data. Vous pouvez retrouver une présentation complète de ce qu'est delta QA dans ce talk de Jonathan Winandy à Curry On! 2017.

Pour cette bibliothèque, un de nos objectifs était de rendre le processus léger. Comme dit précédemment, cela implique de devoir faire des compromis. Le compromis de Parka est l'approximation des mesures lorsqu'il s'agit d'engranger une large quantité de données en implémentant des structures approximatives qui sont aujourd'hui, au sein de Parka, au nombre de deux : 1/ l'utilisation de QTree comme structure approximative d'un histogramme et 2/ l'utilisation du count min sketch pour l'énumération des éléments au sein d'une même colonne.

Un autre moyen d'alléger le processus a été de donner à notre profil une structure monoïdale. Sans rentrer dans les détails (je vous invite cependant à regarder du côté des structures algébriques et un article sur le sujet apparaîtra sans doute dans le futur), cela permet de diviser pour mieux régner, c'est-à-dire fragmenter notre donnée, lancer ces fragments en parallèle pour ensuite les rassembler en les combinant et tout ceci grâce à sa loi associative interne.

Cela n'était qu'un avant-goût de cette librairie. Parka aura, tout comme les autres librairies de spark-tools, le droit à son propre article 😋.

Ce qu'il faut retenir

Qu'importe le coût de la data quality, cette dernière ne devrait pas être mise en second plan comme elle est aujourd'hui. Une mauvaise qualité de données coûte énormément aux entreprises et peut-être dans certains cas une perte d'information incorrigible par la suite.

Aujourd'hui, toutes les entreprises ont des problèmes de data quality, et nombreuses sont corrigibles par le biais de techniques déjà existantes. Nous en avons vu certaines aujourd'hui telles que le constraint checking, les annotations ou encore delta QA. Mais il en existe plein d'autres et je vous invite fortement à vous y intéresser de plus près.

Une des façons les plus ludiques de s'y intéresser, c'est de regarder des talks à ce sujet. Voici une liste de talks non exhaustive parlant de data quality:

Anomaly Detection for Data Quality and Metric Shifts at Netflix présenté par Laura Pruitt

Data quality in Spark without the costs présenté par Jonathan Winandy

Data quality as a key factor in Big Data Government strategies présenté par David Bordas & Nacho Alvaro

Transparence référentielle - II : The rise of non-strict evaluation

2019-08-01T22:00:00Z

Ayant précédemment abordé la transparence référentielle, nous nous posions précédemment des questions sur la prédictabilité du code dans un cadre contenant des effets (appel de service, accès aux données du système, variable globale...). Bien évidemment, les effets créent des dépendances fortes avec des éléments externes à l'application, ils ne facilitent pas cette prédictabilité et par conséquent, ils ne facilitent ni la testabilité et ni la maintenabilité d'une application et de ses composantes. Mais les effets sont un mal nécessaire et il faut composer notre code avec ! Alors comment faire ?

En programmation fonctionnelle, dès que quelque chose ne semble a priori pas faisable, on passe par des fonctions et des paramètres. C'est exactement ce qu'on va faire avec les effets afin de retrouver la transparence référentielle.

En gros, nous allons représenter les effets par des fonctions, composer des expressions à partir des ces fonctions-effets et une fois que l'ensemble de l'expression est bâtie, représentant ainsi l'orchestration des effets, on exécute le tout, lançant ainsi les effets que s'ils sont nécessaires.

Exemple

Prenons cet exemple, où on dépose plusieurs fois la même instruction d'affichage dans une liste.

List(println("hello"), println("hello"), println("hello"))
// hello
// hello
// hello
// List[Unit] = List((), (), ())

Chaque println s'affiche immédiatement et retourne la valeur (), qui est la seule valeur possible pour le type Unit, type de sortie de println. Selon le principe de transparence référentielle, il devrait être possible de remplacer les trois println("hello") précédents par une variable représentant cet appel. Sauf que...

val printHello: Unit = println("hello")
// hello
// printHello: Unit = ()

List(printHello, printHello, printHello)
// List[Unit] = List((), (), ())

Contrairement au code précédent, nous n'avons ici qu'un seul hello d'affiché. En effet, à la déclaration de la variable printHello, l'instruction println va d'abord afficher son paramètre avant de retourner (), qui est en fait la véritable valeur contenue dans printHello. Par la suite, l'utilisation de printHello retournera donc () sans chercher à appeler println("hello"). J'ai ici un comportement différent de l'exemple précédent : je ne suis donc pas référentiellement transparent, mais référentiellement opaque.

Pour pallier cette particularité, nous allons "différer" l'évaluation du println en l'encadrant dans un contexte réplicable : c'est-à-dire une fonction.

val printHello: () => Unit = () => println("hello")
// printHello: () => Unit = <function0>

En effet, une fonction va "différer" l'évaluation de son contenu dans la mesure où rien ne se passe dans la fonction jusqu'à ce qu'elle soit appelée. De plus, appeler plusieurs fois la même fonction nous garanti d'exécuter et de réexécuter autant de fois que demandé le même code.

Notre liste précédente devient une liste de fonctions.

val task: List[() => Unit] =
  List(printHello, printHello, printHello)
// task: List[() => Unit] = List(<function0>, <function0>, <function0>)

Et pour retrouver le même comportement qu'avant, il faut appeler les fonctions contenues une à une. Ce qui se fait simplement en utilisant map, ou mieux dans ce cadre : foreach.

task.foreach(t => t()) // or task.foreach(_())
// hello
// hello
// hello

Le fait de pouvoir "différer" une évaluation, qui sera exécutée par la suite au besoin, rentre dans ce qui est appelé l'évaluation non-stricte. Autrement dit, dans ce cadre, l'évaluation d'une expression se fait en respectant les dépendances, mais pas exactement dans l'ordre exprimé dans le code. C'est dans ce sens qu'elle est non-stricte.

Un autre point que nous voyons apparaître ci-dessus : c'est la dichotomie qu'il y a entre une zone de code sans effet (lors de la déclaration de printHello et task) et une zone de code avec effet (lors de l'appel à foreach). Cette dichotomie est une approche classique en programmation fonctionnelle. Mais pas que... Vous la voyez apparaître aussi dans l'architecture hexagonale, séparant des services déterministes et sans états (assimilables à des fonctions pures) du monde extérieur (requête utilisateur, base de données, service tiers, sonde... assimilables à des composants à effet).

Ici la transparence référentielle, nous a permis d'élaborer un moyen de sortir partiellement du dictat de l'approche impérative en différant les effets grâce à des fonctions. Ainsi nous avons pu séparer une zone fonctionnellement pure dans un coin du code et une zone impérative dans un autre, tout en les rendant plus visibles. Cette approche facilite d'autant la lisibilité du code et sa capacité à être refactorable.

Dans un prochain article nous verrons comment améliorer cette première conception avec des fonctions en introduisant un type représentant des effets.

Historisation de données avec Parquet

2019-07-18T22:00:00Z

Nous allons voir aujourd'hui comment il est possible de compresser fortement des données historisées, par exemple une même table pour des dates différentes, donc en principe n'ayant pas un changement conséquent de données au quotidien en utilisant simplement le format de fichier Parquet, assez connu aujourd'hui.

Introduisons tout d'abord le RLE pour Run-Length Encoding (codage par plages si l'OQLF est dans le coin), qui est un algorithme de compression de données sans pertes. Youhou !

Cet algorithme est principalement utilisé pour les documents noirs et blancs comme le fax 👴📠 et pour certains formats de stockage d'images comme le JPEG et BMP.

Run-Length Encoding

Prenons le cas d'une image qui représente une lettre de l'alphabet en noir sur un fond blanc. Nous savons que cette image est en fait composé de pixels, soit noirs, soit blancs. Dans cette image, nous avons beaucoup de pixels blanc successifs suivis d'un nombre plus ou moins important de pixels noirs puis à nouveau de pixels blancs.

Le principe du RLE consiste à dire qu'au lieu de stocker toute l'information qui indique la couleur du pixel, il suffit de stocker seulement le nombre de pixels puis la couleur du pixel.

Supposons que B = pixel blanc et N = pixel noir. Pour pouvoir stocker 10 pixels blancs sans compression, nous devons stocker BBBBBBBBBB. Mais avec RLE, nous pouvons dire 10B (avec "10" étant écrit au format binaire 0x000a), ce qui prend beaucoup moins de place.

Bit-packing

Parquet utilise aussi du bit-packing, une technique pour optimiser le rangement de données. En quelque mots : lorsqu'on déclare une variable, une taille en bits est réservée. Par exemple un int réserve 32 bits en général. Mais si l'entier est déclaré avec une valeur de 1 alors nous n'utilisons que 1 bit sur ces 32 bits et il est possible de ranger d'autres données dans l'espace restant.

What now?

Imaginez maintenant que vous pouvez utiliser ces deux techniques en même temps : cela ferait de vous un grand maître absolu de la compression. N'est-ce pas ?

Dans les faits, cette alliance de techniques a déjà été mis en place par le biais d'un format de fichier assez familier en data engineering : le Parquet. <EOD> (End Of Dream).

Alors que vos rêves de création d'un nouvel algorithme de compression s'évaporent, soudainement, une terrible idée se propage dans votre esprit.

Parquet utilise donc un mélange de RLE et de bit-packing. Nous avons vu que le RLE marche très bien dans le cas où la donnée est similaire sur un nombre assez long de bits. De plus, il faut savoir que Parquet stocke la donnée en colonne ce qui signifie que dans un bloc de données d'un disque dur, on essaie de stocker toute la donnée d'une colonne et non pas d'une ligne.

Imaginons maintenant que nous travaillons au sein d'une entreprise qui souhaite stocker les données d'une table chaque jour — ce qui arrive assez couramment. Et imaginons aussi que nous l'avons fait pendant une semaine pour commencer.

Pour simplifier, supposons que la table ressemble à ça pour le 5 avril 2018 :

id	data	dump_date
idTigrou1	some data	20180405
idTigrou2	some more data	20180405
idTigrou2	data	20180405

Ici, nous avons id qui nous servira de clé primaire de la table Tigrou (si nous ne connaissons pas la clé primaire, c'est beaucoup plus compliqué mais cela ne sera pas traité ici). Nous avons également la date à laquelle nous avons stocké cette table et bien sûr de la donnée.

L'idée que nous avons eu précédemment se dessine de plus en plus clairement :

Pouvons-nous "ranger" la donnée de l'ensemble des tables Tigrou de manière à prendre avantage du format Parquet qui utilise un stockage colonne et des optimisations de compression comme le RLE et le bit-packing pour pouvoir ainsi fortement réduire la taille qu'occupe ces tables tout en pouvant requêter simplement la nouvelle table super compressée résultant de ce rangement ?

Et bien la réponse* est :

(* : Nous aurons besoin d'Impala pour requêter la donnée sans s'arracher les cheveux)

Voyons alors comment faire ça ! Et voyons aussi à la fin des résultats de ce rangement sur des données bien réelles 😇

Reprenons les données des tables Tigrou (seulement sur trois jours pour ne pas avoir à allonger l'exemple).

Tigrou pour le 20180405

+---+----+--------+
|id |data|date    |
+---+----+--------+
|1  |toto|20180405|
|2  |titi|20180405|
|3  |tata|20180405|
+---+----+--------+

Tigrou pour le 20180406


+---+------+--------+
|id |data  |date    |
+---+------+--------+
|1  |tototo|20180406|
|2  |titi  |20180406|
|3  |tatata|20180406|
+---+------+--------+

Tigrou pour le 20180407


+---+--------+--------+
|id |data    |date    |
+---+--------+--------+
|1  |tototo  |20180407|
|2  |titi    |20180407|
|3  |tatatata|20180407|
+---+--------+--------+

Notre but est d'arriver à une table super compressée qui contient la donnée des trois tables.

Nous pouvons commencer par faire l'union de ces trois tables (en utilisant la fonction unionByName expliqué dans cet article)

val dfs: Seq[(String, DataFrame)] = Seq(
      "20180405" -> Seq(("1", "toto"), ("2", "titi"), ("3", "tata")).toDF("id", "data"),
      "20190406" -> Seq(("1", "tototo"), ("2", "titi"), ("3", "tatata")).toDF("id", "data"),
      "20180407" -> Seq(("1", "tototo"), ("2", "titi"), ("3", "tatatata")).toDF("id", "data")
    )

val unionDF: DataFrame = dfs.map(df => df._2.withColumn("date", lit(df._1))).reduce(_ unionByName _)

unionDF.show(false)

Cela donne :

+---+--------+--------+
|id |data    |date    |
+---+--------+--------+
|1  |toto    |20180405|
|2  |titi    |20180405|
|3  |tata    |20180405|
|1  |tototo  |20180406|
|2  |titi    |20180406|
|3  |tatata  |20180406|
|1  |tototo  |20180407|
|2  |titi    |20180407|
|3  |tatatata|20180407|
+---+--------+--------+

Et ensuite nous pouvons grouper la donnée similaire par date :

val dateGroupDF: DataFrame = unionDF.groupBy(cols.map(expr): _*).agg(collect_list("date").as("date"))

dateGroupDF.show(false)

En résultat :

+---+--------+------------------------------+
|id |data    |date                          |
+---+--------+------------------------------+
|3  |tatata  |[20180406]                    |
|3  |tatatata|[20180407]                    |
|3  |tata    |[20180405]                    |
|2  |titi    |[20180405, 20180406, 20180407]|
|1  |tototo  |[20180406, 20180407]          |
|1  |toto    |[20180405]                    |
+---+--------+------------------------------+

Finalement on groupe par id :

val finalDF: DataFrame = dateGroupDF
.groupBy(groupBy.map(expr): _*)
.agg(collect_list(struct(c.columns.filter(x => !groupBy.contains(x)).map(expr): _*)).as("rest"))
.sort(sortBy.map(expr): _*)

finalDF.show(false)

Et on a enfin :

+---+------------------------------------------------------------------+
|id |rest                                                              |
+---+------------------------------------------------------------------+
|1  |[                                                                 |
|   |  [tototo, [20180406, 20180407]],                                 |
|   |  [toto,   [20180405]]                                            |
|   |]                                                                 |
|2  |[                                                                 |
|   |  [titi, [20180405, 20180406, 20180407]]                          |
|   |]                                                                 |                       
|3  |[                                                                 |
|   |  [tatata,   [20180406]],                                         |
|   |  [tatatata, [20180407]],                                         |
|   |  [tata,     [20180405]]                                          |
|   |]                                                                 |
+---+------------------------------------------------------------------+

Le RLE ici se fait entre tototo / toto et tatata, tatatata et tata !

Tout le code est disponible dans spark-tools/plumbus.

Nous verrons dans un prochain article comment créer des vues sur cette table qui permettent d'exploiter les données comme si nous avions les tables de départ.

J'aimerais pour finir vous partager quelques chiffres sur un test rapide fait sur des tables de production faisant ~350Mo en parquet pour un jour. En appliquant ce processus à ces tables pour cinq jours nous passons de 1.8Go à 629Mo ce qui représente un taux de compression de 65% 🥳

Les fichiers en entrée

Le fichier parquet en sortie

Avec du snappy en bonus

Les tests avec Spark : sortir la tête de l'eau

2019-07-08T22:00:00Z

Vous galérez à faire des tests avec Spark ? Vous en avez marre de déclarer une Spark session à chaque fois ? Nous avons la solution pour vous ! Avec Spark-Test™, ~~dites adieu à la saleté~~ faites vos tests sans difficultés !

Eh bien, en voila une question intéressante ! Spark-Test est l'une des nombreuses bibliothèques que contient Spark-Tools, un ensemble d'outils visant à simplifier la vie des utilisateurs de Spark. Ne vous inquiétez pas, vous aurez l'occasion de découvrir les autres outils au fil de nos articles sur ce blog (avec déjà un article sur Spark-ZIO et des articles prémisses à Plumbus ici et là).

À la découverte de Spark-Test

Aujourd'hui, on commence par la bibliothèque qui est la plus facile à prendre en main. Et oui, vous l'aurez compris on va enfin se concentrer sur Spark-Test. Cette bibliothèque fournit des outils qui facilitent l'édition de tests touchant aux dataframes et/ou datasets en les rendant plus simples tout en fournissant des informations claires et précises grâce aux métadonnées!

Spark-Test est un descendant de Spark-Fast-Tests à travers lequel nous avons voulu présenter notre propre vision du problème et proposons ainsi une conception totalement différente. Cette nouvelle conception nous permet, par exemple, d'améliorer le rapport d'erreur. De plus, un chantier est en cours pour améliorer les performances et accélérer fortement les tests.

Le setup de cet outil ? Rien de compliqué. Rajouter la dépendance de Spark-Test dans votre build.sbt, puis un zeste de extends SparkTest et voilà on est parti ! Pour ceux du fond qui viennent d'arriver ne vous inquiétez pas. Voici un squelette potentiel pour débuter avec Spark-Test.


// pour scala 2.11 et 2.12
libraryDependencies += "io.univalence" %% "spark-test" % "0.3"

package io.univalence.sparktest

import org.scalatest.FunSuite

class GettingStartedTest extends FunSuite with SparkTest {

  test("some test") {
    // Commençons nos tests ici...
  }

}

Maintenant que tout est prêt, commençons par créer un dataframe qui va nous servir d'exemple tout au long de cet article. Spark-Test donne des outils qui aident à créer un dataframe ou un dataset rapidement pour nos tests. Alors, on va pas se gêner pour les utiliser !

Pas besoin de SparkSession. Tout est déjà mis en place pour vous.

val df = dataframe("{a:1, b:true}", "{a:2, b:false}")
/*
| a |   b   |
+---+-------+
| 1 | true  |
| 2 | false |
*/

Comparons deux dataframes pour le fun

Maintenant, imaginons que nous voulons comparer deux dataframes. Il faut savoir que deux types de différences peuvent apparaître : une différence dans le schéma et des valeurs différentes.

Dans un premier temps, nous allons implémenter une solution sans utiliser Spark-Test. Pour se faire, nous allons avoir besoin de récupérer le schéma des deux dataframes, récupérer les valeurs, puis les comparer tout ce petit monde pour savoir si oui ou non nos dataframes sont différents. Voici l'une des nombreuses solutions possibles.

//sans utiliser Spark-Test
def isEqual(df1: Dataframe, df2: Dataframe): Unit = {
  if (!df1.schema.equals(df2.schema))
    throw new Exception("Les schemas sont différents")
  if (!df1.collect().sameElements(df2.collect()))
    throw new Exception("Les valeurs sont différentes")
}

test("some test without Spark-Test") {
  val df1 = dataframe("{a:1}")
  val df2 = dataframe("{a:1, c:false}")

  isEqual(df1, df2)
  /*
   * java.lang.Exception:
   * Les schemas sont différents
   */
}

Cette solution comporte plusieurs problèmes :

Le manque d'informations fournies par notre Exception : on peut savoir si le problème d'égalité vient du schéma ou s'il vient des valeurs. Mais on ne peut pas savoir quel est exactement le problème, à savoir en quoi le schéma est différent ou quelles valeurs sont différentes.
Le manque de flexibilité : on peut par exemple ne vouloir comparer que les colonnes communes entre les deux dataframes, par exemple ici uniquement la colonne "a".

Cela peut sembler anodin dans le cas présent, puisque nos dataframes ne contiennent pas plus de deux colonnes et deux lignes. Mais imaginez deux dataframes avec des milliers de colonnes et des millions de lignes...

Maintenant, résolvons ce problème à l'aide de Spark-Test.

test("some test with Spark-Test") {
  val df1 = dataframe("{a:1}")
  val df2 = dataframe("{a:1, c:false}")

  df1.assertEquals(df2)
  /*
   * io.univalence.sparktest.SparkTest$SchemaError: 
   * Field c was not in the original DataFrame.
   */
}

On obtient une superbe erreur de type SchemaError. Mais ce n'est pas tout ! On a aussi le pourquoi du comment et c'est là tout l’intérêt de Spark-Test. L'erreur vient ici de la colonne 'c' qui n'est pas présente dans le dataframe d'origine.

Mais, mais... Je voulais comparer les colonnes en commun moiiii T_T

Pas de panique ! Il suffit d'utiliser la configuration de Spark-Test et de préciser que l'on veut ignorer les colonnes en trop situées dans df2.

test("some test with custom configuration") {
  val df1 = dataframe("{a:1}")
  val df2 = dataframe("{a:1, c:false}")

  withConfiguration(failOnMissingExpectedCol = false)({ df1.assertEquals(df2) })
  /*
   * Success
   */
}

Voilà, le test passe sans accroc :)

Maintenant, penchons-nous dans le cas ou deux dataframes sont différents, tout en ayant des schémas similaires. Cela s'explique par une ou plusieurs erreurs de valeur, c'est-à-dire des dissonances au sein même des colonnes.

test("some test with same schema") {
  val df1 = dataframe("{a:1, b:true}",  "{a:2, b:true}", "{a:3, b:true}")
  val df2 = dataframe("{a:1, b:false}", "{a:2, b:true}", "{a:4, b:false}")

  df1.assertEquals(df2)
  /*
   * io.univalence.sparktest.SparkTest$ValueError: 
   * The data set content is different :
   *
   * in value at b, false was not equal to true
   * dataframe({b: true, a: 1})
   * dataframe({b: false, a: 1})
   *
   * in value at b, false was not equal to true
   * in value at a, 4 was not equal to 3
   * dataframe({b: true, a: 3})
   * dataframe({b: false, a: 4})
   */
}

La voilà enfin la deuxième erreur. La fameuse ValueError. Cette erreur nous renseigne sur les différences rencontrées entre les deux dataframes en précisant l'erreur, ainsi que les lignes où se trouvent les dites erreurs que ce soit dans df1 ou dans df2.

Cette précision dans les erreurs que l'on va rencontrer, la flexibilité et la facilité d'utilisation, c'est ça la force de Spark-Test. Cette bibliothèque fournit d'autres fonctionnalités qui peuvent faciliter votre vie de data engineer. De plus, Spark-Test est Open Source. Il est disponible ici : https://github.com/univalence/spark-tools/tree/master/spark-test.

Le process mining pour tous

2019-07-04T22:00:00Z

Le Process Mining Camp 2019 nous a fait goûter à l'univers du process mining. Dans le dernier article, nous avons pris le parti de nous concentrer sur l’expérience vécue à Eindhoven. Ainsi, nous revenons aujourd'hui pour vous présenter ce qu'est le process mining de manière plus détaillée et concrète. L'objectif étant de vous faire découvrir les bases de ce que nous pensons être un outil très intéressant.

Le process mining peine à se développer en France. Et pourtant, il apporte énormément de visibilité à un process. Dans un monde où la data est devenue reine, le process mining n'a jamais autant eu sa place. Il créé le lien entre l'analyse des processus et la gestion de la data. Chaque process est composé d'actions qui s’enchaînent, formant ainsi une trace ayant un début et une fin. Ces traces sont à la source du process mining, puisque c'est grâce à elles que nous allons pouvoir générer un process model, comme le schéma ci-dessous :

Image tirée du logiciel Disco prise du blog fluxicon

Ceci n'est qu'une simple introduction. Ainsi, si vous vous sentez l’âme d'un explorateur, je vous conseille de vous rendre sur le blog de Fluxicon qui se consacre entièrement sur le process mining, regroupant des interviews d'experts, des cas réels et des techniques utilisées dans le domaine.

Glossaire

Le process mining étant un peu verbeux, voici un glossaire expliquant chaque mot technique :

Event ou event log : un event est une action émise à un temps donné ayant ainsi au moins un timestamp (le moment auquel l'action a été produite), un case ID (l'id du process) et une activity (le type d'action).
End to end process : un process est une suite d’événements liés de manière chronologique entre eux afin de raconter son déroulement dans le temps.
Event data ou logfiles : fichiers constitués d'une multitude d'event généralement stocker dans un tableau où chaque ligne est un event.
Trace ou case : une trace est la suite d'actions décrivant un end to end process.
Process model : représentation systémique d'un end to end process généré grâce au logfiles.
ProM/Disco: logiciels de process mining générant un process model et fournissant des outils d'analyse sur ce dernier. Il en existe une multitude que nous n'avons pas eu le temps de consulter. Une bonne partie d'entre eux peuvent être trouver ici.

De l'event data...

L'action de créer un process model à partir de traces se nomme "play-in". En réalité, il y a trois types de relations entre la data et les process :

les relations play-in, : on créé un modèle depuis des traces existantes
les relations play-out : on simule des traces (end to end process) depuis un modèle existant
les relations replay : on rejoue des traces sur un modèle existant (fait à la main ou généré depuis des traces)

Cependant, généralement lorsqu'on parle de process mining, on se réfère plus aux relations de type play-in et replay. Le but étant d'utiliser un tableau rempli d'event ou log, de générer le process model correspondant puis d'effectuer certaines analyses telles que l'identification de bottleneck (activité bloquante ou surchargée), afin de mieux comprendre le process et de pouvoir l'optimiser.

Dans le cas du process mining, nous ne pouvons pas utiliser n'importe qu'elle type de data. Seul les "event data" sont acceptés et ces derniers composés d'événement respectent aux moins trois propriétés :

Chaque événement doit contenir un case ID, l'ID du process en cours. Ce peut être le numéro d'une commande, le nom d'un étudiant, etc.
Chaque événement doit contenir un timestamp, la date à laquelle l'événement à été effectué.
Chaque événement doit contenir un activity name, l'activité qui a été effectuer à cette date.

Deux autres propriétés sont quant à elles dispensables ainsi :

Chaque événement peut contenir une ressource, la personne qui a effectué l'action (à noter que dans certains cas, la personne effectuant l'action apparaît dans le case ID lui-même).
Chaque événement peut contenir d'autres data complémentaires.

Pour appuyer mes propos, rien ne vaut un exemple. Cet exemple à été fortement inspiré d'un exemple donné dans le cours Coursera à propos du process mining que je vous invite à aller consulter.

order number	action	timestamp	User	product	quantity
1	register	26/06/2019-09.25	John Doe	🚗	2
2	register	26/06/2019-09.34	John Doe	🚀	1
1	check stock	26/06/2019-09.43	Mickael Bae	🚗	2
2	check stock	26/06/2019-09.57	Mickael Bae	🚀	1
2	ship order	26/06/2019-10.02	Sarah Cabo	🚀	1
3	register	26/06/2019-10.12	John Doe	🚀	1

Si l'on reprend l'exemple ci-dessus, une façon de construire notre process serait de voir l'order number comme étant notre case ID, l'action comme étant l'activity, le timestamp comme étant le timestamp, le user comme étant la ressource et le product/quantity comme étant des données supplémentaires (je parle ici de façon de construire notre process car on aurait très bien pu analyser ces logs en prenant les user comme étant notre case ID par exemple). Maintenant que nous avons définit nos différentes colonnes nous sommes prêt à passer à l'étape suivante.

... au Process Model

Avoir l'event data est un bon début, mais cela n'est qu'un début. Une fois notre event data remplit de millier de logs, il faut pouvoir générer le process model lui correspondant. Pour se faire, des algorithmes ont été créés générant ainsi depuis l'event data le process model correspondant. Le plus simple d'entre eux est l'alpha algorithm. Cependant, sa simplicité implique aussi certaines limitations. Nous n'allons pas rentrer dans les détails ici. Si le sujet vous intéresse, le cours Coursera sur le process mining rentre dans les détails. Dans notre cas, nous allons générer notre process model grâce un outil : Disco. Importer un fichier sur Disco est très simple.

L'exemple ci-dessus n'est pas assez complet pour pouvoir créer un véritable process model ainsi prenons un autre jeu de données qui provient du Business Processing Intelligence Challenge 2014, dans lequel les organisateurs donnent plusieurs fichiers à partir desquels les participants doivent y extraire des informations, afin d'avoir une vision globale de la situation. Nous allons nous concentrer pour la découverte du logiciel Disco sur le fichier nommé Incident activity record.

Commençons par l'importer afin de convertir les différents log en un process model :

Il faut préciser le type des colonnes. Dans notre cas, ce n'est pas bien compliquer : l'incident ID est le case ID, DateStamp le timestamp, incidentActivity_Type l'activity, Assignment Group la ressource et les autres données ne sont que des compléments. N'oubliez pas de convertir vos timestamps dans un format qui correspond à votre data. Une fois cela fait, on peut générer notre process model:

Le process model correspondant semble être totalement chaotique. Ceci s'explique surtout par le fait que nous avons de la data issue d'un cas réel. Les process dans la réalité ne sont pas totalement linéaires et nous nous retrouvons souvent avec des activités se produisant que très rarement et donc n'ayant pas une importance primordiale pour nos différentes analyses. Pour y pallier, nous avons plusieurs possibilités. Soit nous filtrons notre process model en prenant par exemple que les traces passant par une activité donnée, soit nous pouvons et c'est ce que nous allons faire ici réduire le nombre d'activités pris en compte. De base, le process model nous montre la totalité des activités. Vous pouvez remarquer que certaines d'entre elles ne sont sollicités qu'une quinzaine de fois sur environ une centaine de milliers de cas. Ce qui est négligeable. On réduit juste le pourcentage à droite de notre process model. Et nous obtenons ainsi le model suivant:

Ce model donne une vision globale du process que nous pouvons par la suite analyser. La phase d'analyse peut se faire à plusieurs niveaux que ce soit au niveau du process model, au niveau de l'onglet statistics, en utilisant des filtres, etc. On peut dans notre cas, à titre d'exemple, regarder la performance de nos activités ou encore analyser la performance de chaque équipe résolvant les différents problèmes. Qu'importe l'analyse, elle doit répondre à des questions posées au préalable et ceci est la résultante d'une compréhension du métier et de ses divers aboutissants.

Conclusion

Le process mining est une technique très puissante et très intéressante lorsqu'un process rentre en jeux. Des outils puissants existent et nous permettent de visualiser nos logs à travers un process model plus ou moins complexe et dans le cas de Disco totalement modulable. Néanmoins, ce dernier n'est pas magique et certains points sont à prendre en considération. Lors d'un talk de Wil van der Aalst au Process Mining Camp 2019, on nous a mis en garde face à la différenciation entre causalité et corrélation. À cela, je rajouterais une vigilance lors de la data préparation et surtout beaucoup de recul lors de l'analyse d'un process puisqu’il est très facile de prendre un bouc émissaire, d'identifier un bottleneck bloquant la fluidité du process sans pour autant prendre en compte les difficultés du terrain.

Process mining camp 2019 - Notre retour d’expérience

2019-06-27T22:00:00Z

Il est mercredi 17h. Nous partons de la Gare Du Nord en direction d'Amsterdam afin d'assister au Process Mining Camp 2019 qui a lieu du 20 au 21 juin à Eindhoven. Tout juste le temps de goûter au kapsalon, une spécialité locale, avant de nous retrouver à cette conférence de deux jours au sein de l'Eindhoven University of Technology et animée par l'entreprise Fluxicon.

La culture du vélo aux Pays-Bas n'a jamais été aussi vraie qu'à Eindhoven 🚲

Le process mining, quésaco?

Process Mining Camp 2019 est une conférence tournant autour du process mining... Le process mining, pour ceux qui ne connaissent pas, a pour vocation d'utiliser la data (sous forme d'event data), afin de créer des modèles composés de processus que l'on va pouvoir par la suite analyser et interpréter. Un event doit au moins contenir les informations suivantes pour être utilisé en process mining : un case ID, un timestamp et une activity. Ceci n'est qu'une brève introduction mais je vous invite à vous renseigner sur le process mining via le cours sur Coursera et le blog de fluxicon tous deux des mines d'or d'information. Un article de blog introduisant le process mining sera aussi bientôt présent sur notre blog alors ouvrez l’œil et le bon 😉 !

Rien de mieux qu'un exemple pour comprendre ce qu'est le process mining. Imaginons un use case qui pour la plupart d'entre nous est assez familier, une issue Github. Une issue peut être vue comme un process puisqu'il "raconte une histoire".

Cet exemple vient de notre projet open source spark-tools. Nous pouvons le traduire en une suite d’événements ayant un début et une fin ainsi :

Le case ID dans ce cas serait #19, soit l'ID de l'issue.
Les activities seraient l'ouverture de l'issue, le ou les commit(s) pour résoudre l'issue et la fermeture de l'issue.
Les timestamps bien qu’imprécis car pas à la seconde prêt dans ce cas serait 19/06/2019, 24/06/2019, 24/06/2019 (2 commits) et 25/06/2019.
Les resources seraient respectivement ahoy-jon, HarissonCheng, HarissonCheng et HarissonCheng (2 commits et une fermeture) c'est-à-dire les personnes qui ont fait l'action.

Voici l'event data que nous obtiendrions suivi de son model process respectif généré par Disco:

Case ID	Activity	Ressource
19	ouverture de l'issue	ahoy-jon
19	commit	HarissonCheng
19	commit	HarissonCheng
19	fermeture de l'issue	HarissonCheng

Nous somme ici témoins d'un exemple d'une simplicité inexistante. Pour comprendre l'importance du process mining il faut s'imaginer avoir des centaines de milliers d'issues toutes entreposées dans un CSV (par exemple), ayant toutes une histoire plus ou moins différente rendant la compréhension générale du process impossible. C'est à ce moment que le process mining devient une valeur ajoutée inestimable puisqu'une fois le process model créer, on peut observer en rejouant les traces le comportement général du processus, analyser les bottleneck, filtrer en bloquant par exemple un des process, regarder le process qui prend le plus de temps à être réalisé, se référer au temps pour détecter une mauvaise gestion du processus à un endroit ou à un autre etc. Valeur prouvée de mainte et mainte fois lors des différents talks que nous avons eus le premier jour.

Le process mining notre ami pour la vie

Nous avons été bien servis la première journée puisque nous avons eu la chance d'assister à pas moins de neuf talks autour du process mining, dont une réalisée par Wil van der Aalst, un acteur majeur dans le domaine, à propos de l'éthique au sein du process mining.

Opening du Process Mining Camp par Anne Rozinat de Fluxicon

Chaque talk nous a présenté un cas d'utilisation du process mining dans des milieux professionnels variés ayant tous des problématiques différentes. Cela nous a permis de nous rendre compte de l'importance du process mining, dès lors que nous avons un processus qui a un début et une fin et qui se fait en plusieurs étapes. Parmi ces talks, trois d'entre eux nous ont particulièrement interpellés.

Boris Nikolov de chez Vanderlande nous a fait part de son expérience à travers l'optimisation de deux chaînes de traitement. Il a ainsi illustré les larges possibilités qu'offrent Disco, l'outil de process mining phare. Il a expliqué comment interpréter ces cas pour en ressortir des conclusions orientées métier. Il nous a montré comment, à partir de l'exploration d'un process model, il valide et optimise les différents processus logistiques, que ce soit au sein d'un aéroport avec le scénario décrivant la durée de vie d'une valise de l'embarquement à l’atterrissage ou d'un entrepôt de colis où le scénario se concentre sur la sélection du colis et son transport jusqu'à sa destination.

Hadi Sotudeh quant à lui a su nous montrer que le process mining pouvait être adapté et toucher à des domaines divers et variés tels qu'un match de foot. Au premier abord, cela semble farfelu d'utiliser le process mining pour analyser un match de foot. Mais avec un peu d'imagination, il est très facile de voir un match de foot comme un process ou chaque action menée par une équipe est une suite d'activités et dont la "ressource" serait le nom du joueur qui effectue l'action. Ce genre de process lui a par exemple permis de répondre à la question suivante : comment cette équipe de foot (l'Iran) joue, en analysant les différents patterns le long du match.

Wil van der Aalst a tenu à clôturer la journée par un talk bienveillant ayant pour but de nous mettre en garde sur le process mining et de nous amener vers de la data "plus verte". Comme bien d'autres domaines liés à la data, le process mining se heurte à des problèmes de confusion entre causalité et corrélation et de vie privé, point majeur aujourd'hui notamment depuis l'arrivée de la RGPD qui a déjà été présenté sur notre blog par Harrison Cheng.

Il est temps de mettre la main à la pâte

La deuxième journée nous a permis de mettre en pratique les concepts vus le jour précédent à travers quatre workshops tous centrés sur Disco, le logiciel créé par Fluxicon. Celui-ci permet à l'aide de logs de mettre en place un process model et d'y simuler les différentes traces.

Les quatre workshops étaient les suivants :

How to improve processes in the digital age?
From ERP system to dataset: How do I prepare a useful event log?
How can I combine process mining with RPA?
What questions can I answer with process mining?

Nous avons fait le choix de nous répartir dans les différents workshops. Pour ma part, je suis allé au premier workshop donné par Rudi Niks, un des ingénieurs de Fluxicon. Durant ce workshop, on nous a montré comment le process mining pouvait être utilisé dans chaque étape du DMAIC (Définir, Mesurer, Analyser, Améliorer/Improve et Contrôler) qui nous a été présenté comme une méthode de résolution de problème qui repose sur les cinq principes cités ci-dessus. À travers un cas concret comportant l'étude d'un process visant à convaincre des personnes de s'inscrire pour une assurance, on a pu parcourir ces étapes et arriver à la conclusion que le process mining est un excellent complément pour comprendre et analyser la complexité d'un process.

La salle du workshop 4 où était présent deux de nos ingénieurs, Harrison Cheng et Philippe Hong

Les bonnes histoires ont une fin

Il est vendredi 14h, nous repartons déjà vers Paris des idées plein la tête. Ce voyage a été très chargé, mais aussi et surtout très bénéfique. Nous avons eu en effet la chance de rencontrer la communauté du process mining, une communauté remplie de bonnes intentions et nous remercions l'équipe de Fluxicon : Anne Rozinat, Christian W. Günther et Rudi Niks pour avoir organisé ces deux journées ainsi que toute les personnes présentes à cette conférence.

Merci ❤🐇

Scala 2.13.0

2019-06-19T22:00:00Z

Continuant progressivement son cheminement vers la version 3 et après ~1500 pull requests, la version 2.13.0 de Scala est sortie il y a quelques jours. Les nouveautés apportées par cette version concerne un refactoring de l'API collection, quelques modifications dans le SDK, de nouvelles possibilités dans le langage et des améliorations du côté du compilateur. Je vous propose de passer en revue les modifications qui m'ont le plus intéressées.

Collection

Le plus gros du travail de Scala 2.13.0 est avant tout le refactoring de l'API collection. L'un des objectifs de cette nouvelle version est une simplification du code : une réduction dans la hiérarchie des types, la conservation des méthodes réellement nécessaires, la création d'un package dédié aux collections parallèles en plus des package mutable et immutable, la disparition de CanBuildFrom... Ces simplifications apportent une meilleure lisibilité du code de l'API et permettent d'obtenir de meilleures performances. Elles ont aussi comme particularité d'apporter plus de cohérence.

Sinon, LazyList est proposé en alternative à Stream. La différence est que cette nouvelle collection conserve en mémoire les résultats déjà calculés. Elle peut donc s'avérer plus performante que Stream.

Côté interopérabilité avec Java, les outils dédiés sont placés dans un package dédié : scala.jdk. Ils inclus en plus l'interopérabilité avec les streams de Java, avec le type Optional et les interfaces fonctionnelles prédéfinies du JDK. Il a beaucoup à dire sur cette nouvelle API collection et cela nécessiterait un article à part entière.

Il faut savoir qu'un backport de cette nouvelle API est proposé pour les versions 2.11 et 2.12 de Scala avec le projet scala-collection-compat. Ce backport inclut des règles de migration Scalafix pour :

soit réécrire le code pour une version compatible avec la 2.13 ou plus, si vous n'avez pas besoin de cross-compilation avec des versions précédentes (ie. compilation sur plusieurs versions de Scala),
soit réécrire le code en conservant une compatibilité avec la version 2.12 et en introduisant une dépendance vers scala-collection-compat.

D'une manière ou d'une autre, la volonté de ceux qui font Scala et son SDK est de vous pousser à abandonner l'ancienne API quelque soit la version de Scala adoptée, afin de migrer vers une API qui paraît plus stable, plus accessible et mieux conçue. Il n'y a néanmoins aucune garantie que la migration se fera sans heurt. Si l'outillage assure une migration minimisant les problèmes à la compilation, des changements en terme de comportement sont probablement à prévoir.

Autres nouveautés

L'utilisation des string interpolator dans le pattern matching, dans le cadre d'une affectation.

val date = "2000-01-01"
val s"$year-$month-$day" = date
// year = 2000 - month = 01 - day = 01

Et avec une structure match...case.

def dateComponentOf(date: String): Option[(Int, Int, Int)] =
  date match {
    case s"$year-$month-$day" => Option((year.toInt, month.toInt, day.toInt))
    case s"$day/$month/$year" => Option((year.toInt, month.toInt, day.toInt))
    case _ => None
  }

Cette fonctionnalité permet de réaliser des analyses de chaîne de caractères simples. Elle est moins puissante que les regexp, mais plus accessible.

Scala propose maintenant dans sont SDK une alternative à la fonctionnalité try-with-resources de Java. scala.util.Using tient ce rôle. Il est applicable à des ressources de type Releasable, ou plus exactement de catégorie Releasable[R], car il s'agit d'une typeclasse. Cerise sur le gâteau, une instance Releasable est applicable à tous les types dérivant de AutoCloseable, par conversion implicite. Ce qui permet d'utiliser Using avec une bonne partie des types ressources du monde Java ! Une différence majeure avec la version Java est le fait que Using est une expression. Comme elle retourne une instance de type Try, on peut l'utiliser dans un for-comprehension. Néanmoins, comprenez que Using est en évaluation stricte (son contenu est exécuté directement lors de son évaluation dans le code). Pour une version non-stricte, tournez-vous vers la fonctionnalité bracket de Monix et de ZIO.

val content1: Try[String] =
  for {
    _ <- Using(new BufferedWriter(new FileWriter(file))) {
      _.write("Hello world")
    }
    c <- Using(new BufferedReader(new FileReader(file))) {
      _.readLine()
    }
  } yield c
println(s"file content 1: $content1") // print file content 1: Success(Hello world)

val content2: Try[String] =
  for {
    _ <- Using(new BufferedWriter(new FileWriter(file))) {
      _.write("Hello world")
    }
    c <- Using(new BufferedReader(new FileReader(file))) { f =>
      f.close() // in a view to have an exception ;)
      f.readLine()
    }
  } yield c
println(s"file content 2: $content2") // file content 2: Failure(java.io.IOException: Stream closed)

L'opération tap peut être ajouté à toute sorte de valeur dans une expression. La fonction retourne la valeur elle-même et s'apparente en ce sens à la fonction identity. Sauf que tap va vous permettre d'introduire des effets de bord dans vos expressions. Son utilisation doit bien entendu être limité au débogage là où il était difficile à introduire auparavan

import scala.util.chaining._

val result1 = "hello".tap(println) + " world" // print hello
val result2 = "hello" + " world"

println(result1 == result2) // print true

Scala 2.13 accepte le caractère "_" comme séparateur numérique. Les valeurs suivantes sont identiques :

100000
100_000
10_00_00

Cette fonctionnalité existe déjà dans Java. Elle permet de faciliter la lecture du code en particulier lorsqu'on doit hard coder des grands nombres.

L'unification partielle est maintenant tout le temps active et l'option -Ypartial-unification est retirée. Cette fonctionnalité permet d'utiliser la forme F[_] dans la déclaration des type — forme très appréciée par les développeur Scala "type level". Vous trouverez plus de détails dans cette section parlant de SI-2712 dans mon article sur Scala 2.12.

Les flèches au format unicode sont dépréciées et c'est une très bonne chose. Une flèche comme → pose problème car elle n'a pas la même priorité que sont équivalent ASCII ->. Elles sont donc pas interchangeables. Ainsi, l'expression 1 -> 2 / 4.0 donne (1, 0.5), alors que 1 → 2 / 4.0 donne une erreur de compilation : value / is not a member of (Int, Int). Il faut ajouter des parenthèses pour obtenir le même résultat 1 → (2 / 4.0). La dépréciation de cette fonctionnalité devrait éviter pas mal de confusions.

L'implicite any2stringadd définit dans Predef et responsable de comportements "inappropriés" dans Scala est déprécié. La syntaxe procédurale (def m() {}) aussi. Il faudra désormais utiliser une signature complète (def m(): Unit = {}). Les litéraux de type symbole ('symb) sont dépréciés pour cette notation Symbol("symb").

Du côté du compilateur

Côtés compilateurs, les optimisations promettent une amélioration des performances de 5 à 10 % à la compilation. Et côté runtime, la nouvelles API collections apporte de meilleurs performances en donnant notamment au compilateur la possibilité de mettre en place plus d'inlining (le fait de replacer des appels de fonctions par leur contenu). Petite aide appréciable : le compilateur vous fera des suggestions en cas de faute de frappe sur des noms d'identifiants.

Au niveau option de compilation, deux nouveaux types d'options seront créés, allégeant ainsi -X et -Y :

-V pour toutes les options permettant d'afficher des informations sur le fonctionnement du compilateur (eg. -Vphases affichage des phases de compilation, -Vdoc affichage des activités de scaladoc).
-W pour toutes les options des gestions des avertissements à la compilation (eg. -Wdead-code avertissement en cas de code inutilisé, -Wunused:imports avertissement en cas d'imports inutilisés).
À ce propos, -Xfatal-warnings va devenir -Werror. Les deux options existent en 2.13. Mais la release note indique que -Werror est recommandée. -deprecation devient -Xlint:deprecation et -Xfuture devient -Xsource:2.14.

Car oui, il y aura une version 2.14 qui devrait sortir mi-2020, peu avant la version 3.

Côté SBT, Scala 2.13 nécessite d'utiliser au minimum SBT 1.2.8 ou 0.13.18. Sinon, ça fonctionne bien avec Maven et Gradle.

Conclusion

Cette nouvelle version de Scala 2 laisse entrevoir un premier lot de modifications dans le langage vers à la fois plus de maturité et de pragmatisme dans la conception du SDK et les choix appliqués dans les fonctionnalités du langage et le compilateur. Mais elle laisse aussi entrevoir plus de fun en rendant le langage et ses fonctionnalités plus accessibles. Il reste à voir comment se passera la migration vers Scala 3 proposé par ceux qui font le langage.

Actuellement, mon regard se tourne vers Spark, sachant que ce framework est aussi connu pour ses temps de latence assez long pour les montées de versions vis-à-vis de Scala et que les mainteneurs de lib abandonnent progressivement Scala 2.11. Néanmoins, un travail est en cours pour intégrer la 2.13.

Release Scala 2.13.0 · scala/scala

Scala 2 compiler and standard library. Scala 2 bugs at https://github.com/scala/bug; Scala 3 at https://github.com/scala/scala3 - Release Scala 2.13.0 · scala/scala

https://github.com/scala/scala/releases/tag/v2.13.0

https://x.com/omervk/status/1138049573799321600

https://x.com/fpmortals/status/1138349705711300608?s=17

Introduction au RGPD (ou GDPR en anglais)

2019-06-13T22:00:00Z

"We've updated our privacy policy". Si vous habitez en Europe, vous n'avez pas pu rater les millions de mails provenant de sites auquels vous avez oublié que vous étiez inscrit. La cause ? Le 25 mai 2018 est entré en vigueur le RGPD, acronyme de "Règlement Général sur la Protection des Données". Cette mesure a forcé les organisations à être conforme avec les différentes règles du RGPD. D'où le flood de mail vous informant que celles-ci ont mis à jour leur politique de confidentialité.

Comme toutes les entreprises centrées sur la data (mais pas uniquement, comme nous le verrons), Univalence se doit d'en savoir plus sur l'application du RGPD et ses conséquences. Mais pourquoi avoir mis en place ce règlement ? En quoi consiste ces règles ? Qui est concerné ? Si vous vous posez ces questions et autres, vous êtes au bon endroit.

C'est parti !

Every breath you take [...] I'll be watching you

Pour bien comprendre d'où vient le RGPD, il faut remonter presque 50 ans en arrière. En 1974, le projet SAFARI (non, pas le navigateur Web) vise à répertorier et identifier chaque individu en France. En bref, les Français commencent à s'inquiéter de cette collecte de données et le font savoir : le projet ne verra jamais le jour. Cependant, cela incite le gouvernement à créer la CNIL (Commission nationale de l'informatique et des libertés) en 1978, dont une des missions était (et reste toujours à ce jour) de protéger les données personnelles. C'est le début de la protection des données personnelles en France. Par la suite, la directive européenne en 1995 ajoute une couche de protection aux états européens en reprenant les principes et concepts Français de protection des données.

Voilà qui devrait suffire à réglementer et protéger nos données à caractère personnel, non ?

Nope

Avec l'apparition d'Internet, l'augmentation de la quantité de données, du e-commerce, de la biométrie, des réseaux sociaux, de l'affaire Snowden et autres joyeuseries technologiques, les risques pour les droits et libertés (données confidentielles, contrôle, censure), la vie privée, ainsi que les risques de manipulations (profilage) ont fortement augmentés.

Face à cette situation, le RGPD a été adopté en 2016 et appliqué en mai 2018.

Yay !

En quoi ça consiste en gros ?

Le RGPD représente une grosse MAJ sur tout ce qui est protection des données. On a principalement :

Un renforcement quantitatif et qualitatif des droits des personnes.
Un enrichissement (ajout, précision) des notions clés (données à caractère personnel, responsable traitement, sous-traitant...).
Un renforcement du pouvoir de sanction des CNIL européennes.
Une nouvelle logique de responsabilité.
Une fixation des règles de traitement des données (collecte, traitement / exploitation, stockage).
...

Hmm c'est bien beau tout ça, mais qu'est-ce qui définit des données à caractère personnel à votre avis ? (Parce que c'est bien là le sujet du problème !) Pouvez-vous me donner un exemple ?

Si vous avez répondu le nom, le prénom, une photo du visage, le numéro client de chez SFR/Bouygues/Free/Orange..., vous avez raison ! Les données à caractère personnel représentent toute information (ou combinaison d'informations) se rapportant à une personne physique identifiée ou identifiable, qu'elle le soit directement (nom, photo, prénom...) ou indirectement (numéro client, numéro téléphone, pseudonyme...). C'est donc tout cela que vise à réglementer le RGPD.

Lorsqu'on parle des traitements de données, ils concernent aussi bien ceux mis en place pour le fonctionnement interne (tout ce qui est RH par exemple) que ceux mis en place pour les activités (information clients, BDD...). Donc ce n'est pas que ceux travaillant dans la data qui sont concernés.

À qui s'adresse le RGPD justement ?

... Non, en fait ce n'est pas vrai :)

Le RGPD s'addresse à tous les organismes (privés ou publics) quels que soient leur taille, qui sont dans l'UE (que le traitement des données ait lieu ou non dans l'UE) ou dont leur activité cible des personnes dans l'UE. En bref, ça concerne beaucoup d'organismes.

Plus haut, nous avons évoqué le responsable de traitement et le sous-traitant. Un organisme peut être soit l'un, soit l'autre. Il est :

Responsable de traitement (dit RT) s'il est responsable du pourquoi et comment du traitement. La question du pourquoi est particulièrement importante car c'est elle qui définit la finalité : elle fait le lien entre les données, le traitement, et les organismes acteurs.
Sous-traitant (dit ST) s'il traite des données personnelles pour le compte d'un RT

De manière générale, c'est sur le RT que repose la responsabilité et le respect des règles.

En pratique (mais pas dans la théorie), il s'agira :

de son dirigeant pour le secteur privé (président, directeur général, PDG...)
du ministre, du maire, du conseil départemental... pour le secteur public.

TL;DR

Big Data signifie big changement pour les données persos.
Le RGPD représente une MAJ de la réglementation des données persos.
Il s'adresse à tous les organismes dans l'UE ou dont leur activité cible des personnes dans l'UE.

Dans un article suivant, nous verrons comment en pratique traiter le RGPD.

Transparence référentielle - I : la perte de la prédictibilité

2019-06-06T22:00:00Z

La transparence référentielle est ce que vous recherchez lorsque vous développez. L'immutabilité ? Le déterminisme ? C'est dépassé ! La transparence référentielle est le spécialiste des problèmes techniques. Elle va vous aider à retrouver le plaisir de coder. Résolution de la dette technique, succès social, réussite dans vos projets. Les résultats sont immédiats.

Dans cette première partie, nous allons voir ce à quoi correspond la transparence référentielle et différents use cases. Puis, nous allons parler de son pire ennemi : les effets.

Définition

Selon Wikipédia, une expression est référentiellement transparente si elle peut être remplacée par sa valeur sans changer le comportement du programme (c'est-à-dire que le programme a les mêmes effets et les mêmes sorties pour les mêmes entrées, quel que soit son contexte d'exécution). À l'inverse, une expression est référentiellement opaque si elle n'est pas référentiellement transparente.

En dehors de l’enthousiasme qu'elle semble susciter, comment cette chimère académique peut-elle avoir le moindre intérêt ?

La transparence + référentielle quand on ne sait pas ce que c'est !

Bien qu'elle n'aide pas forcément tant que ça, cette définition fait apparaître la notion de "comportement" et le fait qu'on ne change pas ce comportement. Ce qui est intéressant, puisque c'est à la base du refactoring (la version anglaise de cette notion est un peu plus parlante). Nous allons voir que les deux termes sont intimement liés et que nous allons trouver dans la transparence référentielle des conditions pour améliorer la lisibilité du code, sa maintenabilité et sa testabilité. Nous avons donc là un concept digne d'être connu par les partisans du software crafting, qui nous amène à nous poser de bonnes questions, tout en faisant (indirectement) la promotion de la programmation fonctionnelle pure.

Use cases

Pour commencer, nous allons partir à l'inverse de la définition vue plus haut : nous avons des valeurs et nous allons les remplacer par des expressions. Voici une expression où une valeur est répétée.

List(42, 42, 42)

Par refactoring, cette expression est équivalente à :

val lifeTheUniverseAndEverythingElse = 42

List(
  lifeTheUniverseAndEverythingElse,
  lifeTheUniverseAndEverythingElse,
  lifeTheUniverseAndEverythingElse)

Nous avons un cas classique où par transparence référentielle, on peut passer par la création d'une constante pour donner un sens à un nombre magique, sans changer le comportement de ces lignes de code.

Nous pouvons faire le même exercice avec un chaînage d'appel de méthode. L'exemple ci-dessous est un cas typique de oneline, c'est-à-dire écrire tout une expression virtuellement en une seule ligne ou en un seul chaînage d'appels. Malheureusement, cette pratique ne facilite pas la lecture du code.

val wordCounts =
  myText
    .split("[\r\n]+")
    .flatMap(line => line.split("\\s+"))
    .groupBy(word => word)
    .mapValues(occurrences => occurrences.size())

Par transparence référentielle, il est possible de refactorer le code ci-dessus en introduisant au choix une variable intermédiaire ou une fonction, à nouveau sans changer de comportement.

def wordsIn(text: String): Array[String] =
  text
    .split("[\r\n]+")
    .flatMap(line => line.split("\\s+"))

val wordCounts =
  wordIn(myText)
    .groupBy(word => word)
    .mapValues(occurrences => occurrences.size())

Le nom ici permet de donner un plus de sens au code, d'en clarifier l'intention.

La notion de "changer de comportement" est plutôt subjectif et va potentiellement varier en fonction du contexte. Au minimum, il va s'agir de s'intéresser uniquement au résultat de ces expressions. Mais si on est sur un projet où l'on doit porter une attention aux performances, alors cette performance perçue fait partie du comportement et il est possible de constater une différence de comportement dans les différentes solutions vues plus haut. Dans ce cas et dans ce cas uniquement les différentes alternatives ne sont pas référentiellement transparentes.

Anti use cases

Voyons d'autres cas moins anecdotiques où la transparence référentielle ne fonctionne pas.

def makeCoffee(flavour: Flavour): Coffee = {
  launchNuke("HAPPY THERMONUCLEAR WAR") // wow such benevolent

  Coffee.of(flavour)
}

Si le principe de transparence référentielle est respecté, on devrait avoir une équivalence entre les deux parties du code ci-dessous.

List(makeCoffee(Expresso), makeCoffee(Expresso), makeCoffee(Expresso))

// vs

val expresso = makeCoffee(Expresso)
List(expresso, expresso, expresso)

Or, les deux parties dans ce code n'ont pas le même comportement. En effet, la première ligne de code envoie trois ogives nucléaires, alors que les deux suivantes en envoient qu'une seule. (Bon. Lancer une tête nucléaire ou trois, en terme de résultat... comment dire ?)

Le Dr Folamour approuve l'opacité référentielle.

Et on retrouve ça dans des fonctions plus innocentes (... en apparence).

def commit(contract: Contract): Contract = {
  LocalDateTime now = LocalDateTime.now()

  contract
    .sign
    .timestamp(now)
}

Deux appels successifs à commit avec le même contrat peut donner des contrats avec un timestamp différent. Ce qui ne facilite pas la mise en place de tests, car il faudrait changer l'heure du système pour pouvoir retrouver un contexte dans lequel la fonction commit a un comportement prédictif.

Comparons aussi cette fonction :

def intSqrt_1(n: Int): Int {
  if (n < 0) throw new IllegalArgumentException()

  // ... do computation here ...

  result
}

Avec celle-ci :

def intSqrt_2(n: Int): Option[Int] =
  if (n < 0) None
  else {
    // ... do computation here ...

    Some(result)
  }

Selon la version de intSqrt utilisée, le résultat de l'expression suivante sera différente.

List(intSqrt(-1), intSqrt(1), intSqrt(-1))

Pour intSqrt_1, on obtient une exception. Pour intSqrt_2, on obtient la liste suivante : List(None, Some(1), None). Libre au développeur par la suite de lancer une exception au premier None rencontré, au second None rencontré ou de filtrer les None et de continuer les traitements.

Quoiqu'il en soit, intSqrt_1 n'est pas référentiellement transparent. La transparence référentielle nécessite d'être dans le cadre d'une expression et de ne traiter qu'avec des valeurs. Or intSqrt_1 ne retourne pas de valeur lorsque le paramètre est négatif et casse le flux de traitement.

Autrement dit, pour pouvoir respecter la transparence référentielle, nous avons besoin de fonctions pures. Une fonction pure est une fonction déterministe (elle retourne la même valeur pour un même paramètre), totale (elle retourne toujours une valeur quelque soit la valeur permise en entrée) et sans effet.

Les trois exemples précédents montre que ce qui ne permet pas d'être référentiellement transparent, c'est cette notion d'effet. Nous allons voir ce dont il s'agit.

Effet

Les effets représentent un concept fondamental en programmation impérative. Dans ce paradigme de programmation, un programme correspond à une composition d'instructions. Une instruction est un élément du programme qui permet de modifier l'état du système ou de constater son état actuel. Le propre d'un effet est ainsi de modifier ou de constater l'état du système.

Un effet crée un couplage fort entre une application ou un service et un service tier, quelque soit sa nature (OS, service externe, IoT...). Et puis, un effet, c'est plutôt invisible. Ce couplage fort et implicite ne facilite pas :

le déterminisme, puisque des valeurs différentes peuvent être retournées pour le même appel (eg. now(), random(), forexService.getRate("USD", "EUR")),
la testabilité, qui a besoin de déterminisme,
le refactoring, par définition avec la transparence référentielle,

Et de par la nature même des effets, le code devient plus difficile à analyser, nous devons passer plus de temps pour comprendre l'étendue de ses actions. Ce qui nécessite plus de concentration, requiert plus d'énergie et réduit le courage des développeurs pour attaquer des problèmes avec le code. La notion de courage étant à la base de l'agilité, les effets ne seraient pas "agiles" ?

Mais les effets sont nécessaires. Dans les applications de la vraie vie, nous avons tous besoin de connaître l'heure et la date actuelle, nous avons tous besoin de stocker et de lire des trucs en base de données, nous avons tous besoin de dialoguer avec un service qui va potentiellement fournir des réponses différentes, même si on lui fournit la même requête. Sans ça, quel utilité donner à notre application ?

XKCD 1312 (CC BY-NC 2.5)

Alors, dans un cadre où les effets sont une nécessité, comment faciliter la testabilité et prédictibilité de notre code ? Comment pouvons-nous mettre en place la transparence référentielle ? C'est ce que nous verrons dans un prochain article.

Photo : https://unsplash.com/photos/B2mq60Ksrsg

Why Referential Transparency matters?

Why Referential Transparency matters? It’s not always obvious to understand what referential transparency is and why it matters. It’s often intertwined with “complex” frameworks, dealing with …

https://sderosiaux.medium.com/why-referential-transparency-matters-7c179424dab5

sbt-dynver : la gestion dynamique des numéros de version

2019-06-04T22:00:00Z

La livraison d'une application est souvent une étape qui met du temps à être automatisée. Et malheureusement les outils existants n'aident pas forcément dans ce sens, à moins de parfaitement les maîtriser. Dans ce cadre, sbt-dynver offre une souplesse et facilité de mise en œuvre en reléguant notamment la gestion du numéro de version... à Git. Et ça change pas mal de chose dans le process de livraison !

Numéro de version

La particularité de sbt-dynver réside dans sa façon de numéroter les versions. Cette numérotation varie en fonction de l'état du code au sein de Git. Tout en restant compatible avec SemVer.

Si au moins un tag sous Git est présent, c'est le dernier tag créé qui préfixera le numéro de version. Il faut utiliser v1.2.3 ou v3.4 comme format de tag ; la lettre v est nécessaire et est automatiquement retirée dans le numéro de version.

Si des commits ont été ajoutés depuis le dernier tag, sbt-dynver ajoutera dans le numéro de version le nombre de commits créés depuis le dernier tag, ainsi que l'ID du dernier commit.

Si des modifications apparaissent, mais n'ont pas été committées, sbt-dynver ajoutera un timestamp.

sbt-dynver intervient sur les settings version in ThisBuild, isSnapshot in ThisBuild et isVersionStable in ThisBuild. Voici un tableau présentant les différents formats.

sbt-dynver donne ainsi plus de précisions sur l'état du projet, même lorsque le produit est livré. Le plugin permet d'indiquer ainsi s'il s'agit d'une version officielle (format <tag>), d'une version en cours de développement comme pour les snapshots/canary releases/nightly builds (format <tag>+<delta>-<last_commit_id>) ou d'une version livrée en urgence sans passer par les process de livraison habituels (formats incluant le <timestamp>). Cette numérotation facilite la mise en place de process de livraison continue.

Livraison

Le process de livraison permis par sbt-dynver est d'ailleurs plus simple. Il permet de se passer de la déclaration du numéro de version dans le fichier build.sbt ou dans le fichier version.sbt, comme le recommande de son côté sbt-release. En fait, il ne faut surtout pas déclarer de version.

Supposons maintenant que vous ayez un serveur d'intégration continue à l'écoute des push sur votre repo Git. Et que le workflow qui se déclenche passe par un sbt publish.

Du coup, pour livrer une version officielle, vous devez faire :

$ git tag v1.2
$ git push --follow-tags

Si vous avez fait git config --global push.followTags true, l'option --follow-tags n'est pas nécessaire.

Le process permis par sbt-dynver diffère du process de livraison à la Maven, dans lequel les divers snapshots ne sont pas différenciés. Il diffère aussi du process proposé par sbt-release dans la mesure où c'est le développeur qui gère les tags de version.

Le plugin sbt-release-early se base sur sbt-dynver pour la gestion des numéros de version. sbt-release-early s'assure en plus que la livraison est faite dans le contexte d'un serveur d'intégration continue et est compatible avec Sonatype OSSRH et JFrog Bintray. C'est intéressant dans un cadre Open Source et permet de livrer souvent, même des versions intermédiaires !

Les onzes commandements de Jon Pretty (2e partie)

2019-05-23T22:00:00Z

Aujourd'hui, suite et fin de l'article sur les onzes librairies présentées lors de Scalar 2019 😇

Caesura

Caesura est une librairie qui vous aide à parser vos CSV en Row puis en collections Scala ou bien directement en case classes, le dernier étant l'intérêt principal de cette librairie. Caesura se basant sur Magnolia, il est possible de parser une ligne de CSV directement dans une case class ayant des membres complexe, à savoir ayant des case classes imbriquées.

Exemple :

case class Address(city: String, zipcode: String)
case class Person(name: String, age: String, gender: String, address: Address)

val csv: String = """toto,10,male,Paris,75002"""
val toto: Person = Csv.parse(csv).as[Person]
println(toto)
//Person(toto,10,male,Address(Paris,75002))

Ici nous décodons une case class complexe mais nous pouvons aussi aller dans l'autre sens et encoder :

val csv: String = Row.from(
      Person("toto","10","male",Address("Paris","75002"))
    ).elems.mkString(",")
//toto,10,male,Paris,75002

Contextual

Contextual permet de définir comment vos String sont lues et d'avoir des retours au compile time sur la validité de vos String.

Exemple :

email"bourriquet@univalence.io" //La string bien crée car c'est bien un email
bin"11111111" //255
txt"""Avengers,
|assemble""" // "Avengers,\nassemble"

Guillotine

Mais c’est une révolte ? — Non, Sire, c’est une révolution !

Grâce à Guillotine vous pourrez enfin exécuter vos commandes shell de manière sympa :

val thanosQuote = sh"echo I am inevitable".exec[String]
//thanosQuote: String = "I am inevitable"

Bien sûr vous pouvez exécuter des commandes plus utiles tels que des

val gitCommit = sh"git commit -m \"yolo\""

et si jamais vous avez des erreurs dans votre commande, avec par exemple des guillemets mal placés, c'est lors du compile-time que vous aurez un retour.

Kaleidoscope

Une des librairies les plus utiles, dixit Jon Pretty, Kaleidoscope exauce vos rêves les plus fous et vous permet de faire du pattern matching sur des expressions régulières.

Exemple sympa :

val email = "tigrou@univalence.io"

val optEmail: Option[String] = email match {
  case r"^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,6}$$" => Some(email)
  case _ => None
}
//optEmail contiendra bien "tigrou@univalence.io"

Bien sûr vous avez aussi la possibilité d'extraire certaines parties de la String que vous matchez avec une expression régulière avec la syntaxe suivante :

val r"^$prefix@([a-z0-9._%+-]+)@$domain@([a-z0-9.-]+)\.$tld@([a-z]{2,6})$$" = "tigrou@univalence.io"

//prefix: String = "tigrou"
//domain: String = "univalence.io"
//tld: String = "io"

Mutatus

Mutatus pour faire des mutations dans le cloud, ici GCP. La librairie propose une API simple pour sérialiser de la donnée vers GCP :

import mutatus._

case class Person(id: String, age: Int, address: Ref[Address])
case class Address(city: String, zipcode: String)

implicit val addressId: Id[Address] = _.id
implicit val personId: Id[Person] = _.id

val address: Address = Address("Forêt des rêves bleus", "12345")
//On sauvegarde address dans GCP Datastore
val addressRef: Ref[Address] = address.save()
//De même pour winnie
val winnie: Ref[Person] = Person("Winnie l'ourson", 93, addressRef).save()
//On peut accéder à l'addresse de winnie
val addressWinnie = winnie.address()

Winnie et son adresse sont maintenant dans votre GCP Datastore.

Vous pouvez aussi récupérer Winnie du Datastore avec :

val winnie = Dao[Person].all()

Le type Ref représente une référence à un datatype qui est stockée autre part, par exemple sur GCP.

Optometry

Optometry est une librairie semblable à Monocle, qui permet de créer des lens avec un syntaxe assez légère.

Créer une Lens est assez simple :

case class Person(name: String, address: Address, age: Int)
case class Address(city: String, zipcode: String)

val nameLens = Lens[Person](_.name)
val person: Person = Person("porcinet", Address("Forêt des rêves bleus", "12345"), 1) 

// nameLens(person) = "porcinet"

Vous pouvez bien sûr aller dans des niveaux plus profonds :

case class Person(name: String, address: Address, age: Int)
case class Address(city: String, zipcode: String)


val getCity = Lens[Person](_.address.city)
// getLines(person()) = "Forêt des rêves bleus"

D'autres opérations intéressantes sont disponibles comme le fait de pouvoir mettre à jour des membres spécifiques d'une case class imbriquée, de combiner des Lens, ...

Conclusion

Certaines librairies telles que Kaleidoscope ou Contextual apportent une vraie valeur ajoutée et vous seront utiles dans la plupart de vos projets.
Néanmoins il est vrai que ces librairies tombent souvent dans l'oubli car ce sont des libraries qui ne sont pas très connues et il s'agit alors de les utiliser si le cas se présente et d'envoyer des idées d'amélioration.

Spark & ZIO : rencontre du 3e type

2019-05-16T22:00:00Z

Zed Aïe Oh

Avec l'arrivée imminente de ZIO 1.0, une grande nouveauté apparaît dans cette bibliothèque : à savoir l'adoption d'un troisième type paramétré pour l'IO. Le type ZIO[R, E, A] fut ainsi créé.

Auparavant, le type utilisé par ZIO pour encapsuler votre code avec effet était tout simplement un IO[E, A] avec :

E → Le type utilisé en cas d'échec, souvent un Throwable ou des erreurs métiers. Mais il peut aussi être Nothing, si votre fonction n'est pas amené à échouer.
A → Le type retourné en cas de succès, avec Nothing indiquant que la fonction ne se finit jamais ou un Unit si la fonction à des effets et ne retourne pas de valeur.

Maintenant nous avons accès à un troisième type paramétré noté R par convention. R représente tout simplement l'environnement / le contexte nécessaire pour pouvoir faire fonctionner le code à effet dans vos fonctions, comme par exemple la connexion à une base de donnée ou la session Web. Cet environnement peut être composé de plusieurs modules, d'une simple configuration ou bien si vous n'avez besoin de rien, dans ce cas vous utiliserez le type Any.

Et Spark dans tout ça... ?

Que se passe-t-il si vous mettez ZIO et Spark dans un grand bol de céréales ? Paf, ça ne fait pas des ChocapicsTM, mais plutôt un ZIO[SparkEnv, E, A] que nous pouvons habilement renommer TaskS[A] pour les fans de Monix 😉.

Mais vous pouvez aussi prendre des Chocapics™️ !

type TaskS[X] = TaskR[SparkEnv, X]
// Avec TaskR[SparkEnv, X] = ZIO[SparkEnv, Throwable, X]

Maintenant que vous détenez le pouvoir de Spark et ZIO dans vos mains, vous pouvez maintenant vous amuser à écrire des for comprehension partout.

L'avantage des for comprehension dans Scala est la facilité de manipulation de tout votre code englobé dans des Task.

Un exemple de programme utilisant ZIO ayant pour environnement Spark :

//Mise en place d'une session Spark
val ss: SparkSession   =
  SparkSession.builder.master("local[*]").getOrCreate()
//SparkZIO est une classe qui étend le trait SparkEnv et qui embarque une session Spark
val sparkEnv: SparkZIO = new SparkZIO(ss)

//Votre programme
val prg: TaskS[(DataFrame, DataFrame)] =
  for {
    //Supposons que totofile contienne de la donnée texte
    df  <- sparkEnv.read.textFile("totofile")
    _   <- Task(df.createTempView("totoview"))
    df2 <- SparkEnv.sql(s"""SELECT * FROM totoview""")
  } yield (df, df2)

//Ici nous donnons à notre programme l'environnement Spark
val liveProgram: IO[Throwable, (DataFrame, DataFrame)] = prg.provide(sparkEnv)

//Un runtime par défaut est fourni par ZIO qui sera utilisé pour exécuter les effets
val runtime: DefaultRuntime = new DefaultRuntime {}
//L'exécution des effets a effectivement lieu ci-dessous. On récupère aussi les retours de ces effets
val resRun: (DataFrame, DataFrame) = runtime.unsafeRun(liveProgram)

//resRun._1 et resRun._2 ont le même contenu

SparkEnv.sql() est un helper qui masque l'accès à l'environnement Spark fourni à ZIO :

def sql(queryString: String): TaskS[DataFrame] =
    ZIO.accessM(_.query.sql(queryString))

ZIO.accessM est LA fonction qui vous permet d'accéder à l'environnement. L'environnement SparkEnv est représenté sous la forme d'un trait Scala. L'inspiration venant principalement du blog post sur cette nouvelle fonctionnalité décrit par John de Goes.

Si vous voulez en savoir plus sur le mariage entre ZIO et Spark, je vous invite à aller voir notre repo git spark-tools qui contient divers outils utiles pour le data engineering. Spark-zio est l'un des projets qui se trouve dans spark-tools et contient notre implémentation. Spark-zio est aussi disponible sous Maven Central (nous utilisons sbt-dynver pour déterminer le numéro de version).

Nous avons choisi de wrapper la méthode sql(sqlText: String): DataFrame de SparkSession, car nous n'avons aucun contrôle sur la requête faite. Elle peut en effet faire des drop tables ou autres actions à effet dans Spark.

Nous avons aussi wrappé toutes les méthodes à effet du type load et write.

En se limitant à cela et en ne se préoccupant pas des méthodes du type .select(), .where() que nous pouvons considérer comme raisonnablement pur, nous obtenons ainsi une bibliothèque beaucoup plus maintenable, sachant qu'il aurait été très coûteux de devoir wrapper toutes les APIs Spark.

Les onzes commandements de Jon Pretty (1re partie)

2019-05-09T22:00:00Z

Suite au retour sur Scalar 2019 que nous avons fait, nous avons promis de vous en dire plus sur les onzes librairies que Jon Pretty avait présenté en vitesse lors de son passage à Scalar.Chose promise, chose due !

Jon Pretty a besoin d'aide pour gérer ses libs. Êtes-vous prêts à l'aider ?

Commençons donc sans plus tarder !

Adversaria

Adversaria permet d'obtenir des informations sur des annotations à l'aide
d'interfaces typeclass et des macros. Il y a actuellement trois
utilisations de cette lib :

obtenir toutes les annotations appliquées à un type en particulier
trouver un paramètre annoté dans une case class
obtenir toutes les annotations associées à un champ d'une case class

Dans les exemples de la page github d'Adversia, on retrouve deux typeclass permettant de faire cela : TypeMetadata et FindMetadata.

Gastronomy (Doc)

Miam ! Cette lib permet de calculer des "hash digests" pour :

des objets simples

import gastronomy._
  val intDigest: Digest = 42.digest[Md5]
  val stringDigest: Digest = "Hello world!".digest[Sha1]

des objets plus compliqués comme des case class

import gastronomy._
  case class Person(name: String, age: Int)
  case class Group(people: List[Person])
  
  val group = Group(List(Person("Bill", 18), Person("Jane", 22)))
  val groupDigest: Digest = group.digest[Sha256]

Actuellement, les hash acceptés sont Md5, SHA1, et SHA256.

Cette lib permet également d'encoder par la suite les digest avec la fonction encode. Les encodages acceptés sont Hex et Base64.

Honeycomb

DSL pour générer du code HTML bien formé (table, tbody, tr, td, div, ...).

En bonus, les erreurs sont affichées lors de la compilation, et non pas au runtime/display !

Mercator

Grâce à l'utilisation des macros, Mercator permet d'automatiquement
construire une "preuve" qu'un type connu peut être utilisé dans un
for-comprehension (List, Option, ...). Il s'agit d'abstraire les types
similaires aux monad sans impacts sur la performance.

Par exemple normalement, il n'est pas possible de faire un for-comprehension avec en paramètre de type F[_] :

// ne compile pas
def increment[F[_]](xs: F[Int]) = for(x <- xs) yield x + 1

car le compilateur ne sait pas si F possède les méthodes map et flatMap , qui sont indispensables dans la construction d'un for-comprehension.

Avec Mercator, on peut instancier automatiquement une instance implicite Monadic[F] pour n'importe quel type F[_] possédant map et flatMap. Cela permet de fournir ces méthodes à l'instance de F[_] :

// compile !
import mercator._
def increment[F[_]: Monadic](xs: F[Int]) = for(x <- xs) yield x + 1

Pyroclastic

Permet de créer des graphes monadiques composables.

Voici un exemple de graphe, correspondant à la préparation de thé et café.

La suite dans un prochain article :)

Apache Kafka VS Apache Pulsar

2019-04-29T22:00:00Z

Le monde des systèmes de messageries de type publish-subscribe a vu plusieurs acteurs émerger comme Apache Kafka, Apache Pulsar, les solutions proposées par Amazon (Kinesis) et Google (PubSub), et autres. Dans cet article, nous allons nous attarder sur les deux projets open-source que sont Apache Kafka et Apache Pulsar. Ces deux systèmes se veulent distribués (donc extensible), fiables, de faible latences dans l'envoi de messages, et autres joyeuseries. Le but n'est pas que de constater les différences, mais également les similarités et équivalences qui existent entre ces deux systèmes. Sans plus tarder, voici donc un tableau faisant la comparaison entre ceux-ci :

Feature	Apache Kafka	Apache Pulsar
Concept général	Publish-subscribe, producer push et consumer pull	Publish-subscribe, producer push et consumer pull
Parallelisme	Topics partitionnés. Un topic possède plusieurs partitions. Une partition représente un ou plusieurs fichiers logs et index.	Topics partitionés. Un topic possède plusieurs partitions représentés par le concept de ledgers et fragments d'Apache BookKeeper.
Architecture	Cluster brokers Kafka + cluster ZooKeeper	Cluster broker Pulsar + cluster BookKeeper + cluster ZookKeeper
Stockage	Système de structure de logs distribués (à l'intérieur du cluster de brokers)	Apache BookKeeper (en dehors du cluster de brokers) Tiered Storage ⇒ stockage vers aws
Geo-Réplication	Kafka MirrorMaker	Présent et géré au niveau des tenants. ,Doc Pulsar
Registre de schémas	Confluent Schema Registry Chaque message est envoyé avec un ID unique représentant un schéma	Approche client ou serveur.
Retention et expiration des messages (TTL)	Possède seulement le concept de rétention. 7 jours de rétention par défaut. Peut également être configuré avec une taille maximale.	Possède les deux. Plus de détails ,ici, dans la partie ,Acknowledgement,.
Acknowledgement	Géré par un topic dédié aux offsets, ,`__consumer_offsets`, .	Géré par les cursors, l'ack est soit cumulatif (à la Kafka), soit par message (ce dernier permet de mieux gérer les erreurs et une utilisation comme un système de queue plus traditionnelle)
Capacité de traitement et latence	Grande capacité de traitement grâce aux techniques de consommation avec zéro copies.	Faible latence.
Consumer	Groupes de consommateurs (Voir l',article s,uivant, sur notre blog pour plus de détail).	3 types de consommations différentes (appelés subscriptions). Possibilité d'avoir plus de consommateurs que de partitions dans une même subscription.
Topics	Constitué de plusieurs partitions répartis sur plusieurs brokers. Multi-tenancy : paramétrage sur les topics pour permettre ou non la consommation/production de données dans les topics + quotas pour contrôler les ressources des brokers utilisées par les clients.	Persistant ou non persistant. Constitué de plusieurs partitions répartis sur plusieurs brokers. Multi-tenancy : Pulsar est conçu pour cela. Les topics sont organisés en namespace, et chaque namespace appartient à un tenant.
Écosystème	Kafka Connect, Kafka Streams	Pulsar IO, Pulsar Functions
Communauté	Très Mature	En croissance
Production indempotente	Exactly Once	Effectively Once, ⇒ Déduplication des messages
Headers des messages	Depuis 2017 dans la 0.11.0 ,KIP-82	Non implémenté pour l'instant (v2.3.1)
Sécurité	Authentification + Chiffrement + Autorisation via SSL + SASL (Kerberos, SCRAM-SHA-256/512)	Authentification + Chiffrement via TLS. Autorisation et authentification avec Athenz ⇒ Concept de "role tokens".

Notes pour l'article :

Effectively once pulsar : https://fr.slideshare.net/merlimat/effectivelyonce-semantics-in-apache-pulsar & https://streaml.io/blog/pulsar-effectively-once

Chaos Testing Pulsar : https://jack-vanlightly.com/blog/2018/10/21/how-to-not-lose-messages-on-an-apache-pulsar-cluster

We can test that by enabling the deduplication feature. When enabled, a broker stores the last sequence number of each producer in a hashtable. When it receives a lower sequence number it knows that it is a duplicate and ignores it. It stores the (producer, sequence number) per topic data in a cursor so that, in a broker fail-over, the new broker can recreate the hashtable. The hashtable is snapshotted periodically so in the event of a broker failure, the latest sequence numbers in the hashtable might be lost. This would create a window of opportunity for duplication in the event of a broker fail-over if the new broker only relied on that snapshot. To avoid that scenario the new Pulsar owner reads the last N entries from the ledger and adds them to the hashtable, thereby covering any gap induced by the fail-over.

Kafka producer idempotent : https://cwiki.apache.org/confluence/display/KAFKA/Idempotent+Producer

Com between pulsar brokers and producer/consumers : https://pulsar.apache.org/docs/en/develop-binary-protocol/

Kafka Headers : https://cwiki.apache.org/confluence/display/KAFKA/KIP-82+-+Add+Record+Headers+-+Typed

Univalence à Devoxx France 2019

2019-04-23T22:00:00Z

Univalence était présente à Devoxx France 2019. Parmi les sujets abordés dans cette édition : Kotlin, Kafka, Kubernetes, Quarkus et GraalVM, du front, du microservice et de la data. Mais aussi de la bienveillance au travail, du télétravail et de l'histoire du Web.

Nous étions nous-mêmes venus pour vous présenter de tout sauf du Java !

Retrouvez ci-dessous les slides de nos deux sessions :

Slides de la session "Avez-vous pris des nouvelles de Scala ?" par François Sarradin

Nous avons aussi coorganisé le BoF du ParisDataEng' avec Sara Himmich de Converteo pour donner un aperçu de l'évolution du meetup et Bachir Aït M'Barek de DataGemme qui nous a fait l'honneur d'une présentation sur le besoin de mieux rapprocher data scientist et data engineer.

Nous souhaitons remercier l'équipe d'organisation de Devoxx France pour leur accueil, la richesse de l'événement et les rencontres.

Retour sur Scalar 2019

2019-04-18T22:00:00Z

Dzień dobry

Scalar est une conférence sur Scala se déroulant à Varsovie, Pologne depuis 2014. Cette année, deux membres de l'équipe ont eu le plaisir de participer à l'édition 2019 qui s'est déroulée sur deux journées, du 5 au 6 avril 2019.

Les deux membres de l'équipe sont :

Harrison Cheng, Data Engineer à Univalence depuis Mars 2019
Philippe Hong, Data Engineer à Univalence depuis Juillet 2017

Sur ces deux journées de conférences, il n'y a eu pas moins de 22 talks de 30 minutes (à l'exception du premier talk de Jon De Goes qui a duré un peu plus longtemps) sur des sujets variant du challenge de construire une architecture d'event sourcing purement fonctionnelle à une présentation de Kotlin pour les développeurs Scala.

Nous allons, dans cet article, survoler différents talks intéressants ayant pris place pendant la conférence.

Jour 1

Scalar s'est déroulé au POLIN Muzeum Historii Żydów Polskich (Musée de l'Histoire des Juifs polonais) non loin de la vieille ville de Varsovie.

Après avoir passé la sécurité, nous sommes accueilli par des membres du staff qui nous dirigent vers la salle de conférence. Scalar étant une conférence n'ayant qu'une seule track, cette salle de conférence a été utilisée pour toute la conférence.

atomically { delete your actors } - John A. De Goes (ft. Wiem Zine Elabadine)

Talk d'ouverture de la conférence, John de Goes accompagné de Wiem Zine présentent une nouvelle fonctionnalité pour ZIO, une librairie permettant de gérer votre code à effet, celle de pouvoir faire des transactions i.e. STM (Software Transactional Memory). Cela permet de résoudre le problème de concurrence en Scala de manière alternative aux autres méthodes (lock, actors,...).
La présentation a pris le parti de raconter une histoire humouristique, celle d'un voleur parvenant à voler des millions avec des exploits informatique basés sur la concurrence, d'un héros qui est le STM et de nous même, supposés devenir des héros grâce à ZIO.

S'ensuit une présentation des fonctionnalités de ZIO STM avec la promesse que faire de la programmation concurrente avec ZIO STM est très accessible.

FS2 - Crash course - Lukasz Byczynski

Cette présentation de 10 minutes nous décrit FS2, une bibliothèque de streaming I/O. FS2 vient de FSS ⇒ Functional Streams for Scala. Lukasz nous décrit le stream comme étant des itérateurs dopés aux stéroïdes.

Comment commencer avec FS2 ?

Devenez familier avec la classe Stream
Essayez les méthodes covary et eval
Jouez avec la classe Pull
Regardez le package concurrent
Utilisez FS2 avec d'autres librairies comme Akka, Monix, etc...

The last frontier and beyond - Valentin Kasas

Nous commenceons ce talk avec les bienfaits de la programmation fonctionnelle, à savoir la possibilité d'abstraire du code afin d'éviter la répétition inutile, de passer moins de temps à chasser des bugs, etc. La programmation fonctionnelle est aussi très utile pour modéliser la donnée et les effets.

Nous utilisons dans tous les projets du même code pour sérialiser de la donnée, lire des fichiers de configuration, pretty print, etc... et tout ce code partage une caractéristique : le code dépend de la structure de la donnée.

Donc si nous pouvons abstraire sur cette structure nous pouvons alors bénéficier des avantages évoqués précedemmment.

Une manière de faire cela est d'utiliser des macros.

Le problème survient lorsque nous devons faire évoluer des ADTs et même si nous pouvons garder des anciennes versions de nos ADTs lorsque nos données évoluent, ce n'est pas très réaliste sur des projets trop larges ou qui évoluent beaucoup.

La solution proposée ici est tout simplement le schéma. Nous pouvons en résumé pourquoi pas nous débarasser de nos ADTs et d'utiliser simplement le concept de schéma pour gérer les évolutions.

Ainsi nous devons constituer notre propre version de schéma et pour cela nous avons besoin de

TODO IN ARTICLE

Scalatest : you're asserting it wrong

Dans ce talk, Jacek Kunicki nous explique comment bien faire ses assert avec la bibliothèque ScalaTest. En effet, il n'est pas bien intéressant d'avoir par exemple true was not false comme retour lorsqu'un test échoue.

Par exemple si on a val option = None:

Il vaut mieux utiliser option should be ('defined)qui renvoit None was not defined plutôt que option.isDefined should be (true) qui renvoit false was not true, ce qui est moins explicite.

Jour 2

Cellular Automata: How to become an artist with a few lines of code

Un talk un peu différent des autres. Maciej Gorywoda nous explique comment coder des automates cellulaires en Scala avec comme exemple le jeu de la vie et la fourmi de langton.

https://github.com/makingthematrix/ca_art

Functional Concurrency in Scala 101

Dans ce talk, Piotr Gawryś nous défini plusieurs concepts de la concurrence en programmation fonctionnelle dans Scala (principalement avec cats-effect, fs2, monix, zio).

Il commence par expliquer comment fonctionne la concurrence en général dans la jvm (définition concurrence et parallélisme, threads dans la jvm, context switch, threads pools, asynchronous boundary, task scheduling), puis enchaîne sur les différentes notions introduites par la programmation fonctionnelle (light asynchronous boundaries dans monix et cats-effects IO, fairness qui est la probabilité que différentes tasks peuvent s'exécuter, les green threads qui sont des threads programmés par la jvm plutot que par l'OS, les fibers qui sont comme des threads plus légers).

Taming your herd of cats

Ce talk est une présentation pour les personnes ne connaissant pas ou peu Cats, une librairie permettant de faire de la programmation fonctionnelle avancée. Différentes parties de la librairie sont présentées avec des exemples d'utilisation accompagnés d'astuces.

L'intérêt de ce type de talk est de faire découvrir en relative douceur des concepts plus poussés en programmation fonctionnelle en montrant ce qu'il est possible de réaliser avec ces concepts.
Un exemple connu est le combineAll pour les monoïdes qui permet de réduire une collection.

11 Little life-enhancing libraries

Jon Pretty nous demande de l'aide, il a trop de bibliothèques à gérer ! Dans ce talk, 11 bibliothèques nous sont présentées allant du parsing CSV au lightweight lens syntax, en passant par de l'inline pattern matching.

Nous traiterons ce talk plus en détail dans un prochain article. Restez à l'écoute :)

Kotlin for Scala developers

Ce qu'il faut retenir de ce talk, c'est que John A. De Goes <3 Kotlin.

Blague à part, ce talk de Jarek Ratajski nous présente Kotlin comme un Java ++ plutôt qu'un Scala - -. Il nous expose les différences entre Scala et Kotlin, les avantages à utiliser Kotlin (immutabilité, décision pragmatique sur l'absence d'obligation de compiler check, compilateur rapide, lambas et tailrec,...) et les limitations (pas de for comprehension, pas de type classes (même s'il y a un idiome spécifique pour des type classes dans la bibliothèque arrow), pattern matching limité...).

Scalar pour l'équipe

Commentaire Philippe : Dans l'ensemble les talks étaient bien présentés et réussi. Il y a eu beaucoup de talks sur le sujet de la concurrence et des acteurs. Les trois talks que j'ai préféré sont :

atomically { delete your actors }
11 Little life-enhancing libraries
The last frontier and beyond

Avec en mention honorable Kotlin for Scala developers qui m'a personnellement donné envie de regarder d'un peu plus près Kotlin.

Commentaire Harrison : Scalar a été ma première conférence sur Scala, et c'était très intéressant. En tant que néophyte dans le domaine de la programmation fonctionnelle, je n'ai pas pu comprendre tout ce qui était expliqué dans les différents talks, mais cela m'a permis de voir les différentes bibliothèques Scala à surveiller et voir jusqu'à quel point vont les experts en Scala. J'ai apprécié le fait qu'il n'y avait qu'une scène et donc ne pas avoir à choisir entre tel ou tel talk.

Un aperçu d'Apache Pulsar

2019-04-09T22:00:00Z

C'est quoi, ça marche comment ?

Un aperçu d’Apache Pulsar

Apache Pulsar est un système distribué open-source dédié à la messagerie et basé sur le modèle “publish-subscribe”. Il a été développé chez Yahoo et mis en production depuis trois ans pour des applications comme Yahoo Mail, Yahoo Finance, Yahoo Sports, Flickr, Sherpa ou encore Gemini Ads. Depuis fin 2016, le projet a été mis en open-source sous la fondation Apache.

Dans cet article, nous allons explorer les différents concepts constituant Pulsar ainsi que son architecture.

Publish-Subscribe (pub-sub) et la triade : producteur, topic et consommateur

Pulsar fait partie des systèmes de messagerie utilisant le modèle du publish-subscribe : la publication et l’abonnement. Ce modèle est composé de trois différents éléments permettant la transmission des messages : les producteurs, les topics et les consommateurs. Les producteurs et les consommateurs, comme leur nom l’indique, sont des applications produisant et consommant des messages. Dans le vide ? Non ! C’est là que le topic intervient. Le topic joue le rôle d’intermédiaire entre les producteurs et les consommateurs et stockent les messages. En résumé, les producteurs publient leur messages dans différents topics et les consommateurs s’abonnent à différents topics pour consommer les messages. Cette indirection permet de découpler les producteurs des consommateurs, ils ne se parlent pas directement.

Topic, namespace, tenant

Le topic est la figure centrale de Pulsar puisque c’est par là que transitent et sont potentiellement stockés tous les messages. Les topics sont comme des stockages structurés pour l’écriture de logs (log-structured storage), où chaque message possède un offset.

Dans Pulsar, les topics ne sont pas indépendants, ni dispersés dans la nature. Un principe que Pulsar prône est d’être multi-tenant (i.e. multi-entité). Pour ce faire, les topics doivent être organisés en tenant et namespace. Pour faire simple, un namespace contient plusieurs topics et un tenant contient plusieurs namespace. Cela permet d’avoir différents niveaux de permissions, réplications, d’expiration de messages et autres, entre les différents namespaces et tenant.

Les topics dans Pulsar peuvent être persistant ou non-persistant. Persistant veut dire ici que les données sont stockées de manière durable dans un disque (ou plusieurs car nous sommes dans le monde distribué).

Pour résumer, les noms des topics sont représentés par une URL de la forme suivante :

{persistent|non-persistent}://tenant/namespace/topic

Subscription mode, multi-topic subscription

Pour s’abonner à un topic, un consommateur ou un groupe de consommateurs peuvent établir un contrat appelé “subscription”. Les “subscription” contiennent des métadonnées et un curseur. C’est ce curseur qui suit l’offset du topic courant pour chaque consommateur.

Il existe trois différents “subscription” dans Pulsar :

Exclusive subscription

Ce mode permet à un seul et uniquement consommateur de s’abonner à un topic.

Shared subscription

Ce mode permet à plusieurs consommateurs de s’abonner à un topic.

Failover subscription

Ce mode permet de définir plusieurs consommateurs pour un topic. Sauf qu’à la différence du shared subscription, il n’y a qu’un seul consommateur abonné au topic. Les autres sont là au cas où le consommateur abonné se déconnecte (d’une manière ou d’une autre).

Cela permet de choisir la meilleure façon de consommer les données. Si l’ordre des données est importante (chaque donnée dépend des données précédentes), on préférera utiliser soit le mode “exclusive”, soit le mode “failover”. Sinon, on utilisera le mode “shared” où l’ordre des messages n’est pas garanti, mais qui permet de consommer plus rapidement avec plus de consommateurs.

Les consommateurs peuvent également s’abonner à différents topics (à la condition que ceux-ci soient dans le même namespace). Il y a deux façons pour le faire :

Établir explicitement la liste des topics à lire.
Définir par regex la liste des topics (ex : persistent://tenant/namespace/topic-*).

Dans ce cas-là, l’ordre des messages consommés n’est pas garanti (comme pour le shared subscription).

Acknowledgement

Dans Pulsar, il est important pour un serveur de savoir si un consommateur a fini de récupérer un message afin de décider s’il peut le supprimer ou pas. Le consommateur doit donc envoyer un “ack” (acknowledgement) permettant de faire savoir au serveur qu’il a bien reçu le message.

Ce “ack” est géré par les curseurs dans les subscriptions et permet à un même message de ne pas être consommé plusieurs fois. Le ack peut être fait de manière cumulative (tous les messages jusqu’à un certain point sont ack) ou individuel (un par un) :

Il permet également de définir les concepts d’expiration de message et rétention de message.

“Mais ce n'est pas la même chose ?”

Non ! Dans Pulsar par défaut, les messages non-ack ont un visa temporaire dans les serveurs et sont supprimés dès qu’ils sont ack. On peut prolonger ce visa lorsqu’ils sont ack en modifiant la rétention du message. À l’opposé, on peut diminuer le temps de ce visa lorsque les messages sont encore non-ack en modifiant l’expiration du message (appelé aussi TTL = Time To Live). Ces deux concepts permettent deux choses :

Garder les données pendant un certain temps même s’ils ont été ack (rétention)
Supprimer les données après un certain temps même s’ils n’ont pas été ack (TTL)

Cela permet également de voir Pulsar comme une queue si les messages ne sont pas gardés après ack, ou comme Apache Kafka où les messages sont persistés un certain temps après leur consommation.

To sync or not to sync

Les producteurs et consommateurs ont la possibilité d’envoyer ou de recevoir les messages de manière synchrone ou asynchrone.

Pour le producteur, un envoi synchrone correspond à une attente de confirmation de réception à chaque envoi de message et, dans le cas échéant, un échec d’envoi du message de la part du producteur. Un envoi asynchrone correspond à l’envoi direct d’un message dans une queue de messages, sans attente de confirmation de la part de Pulsar.

Pour le consommateur, une réception synchrone permet de bloquer l’exécution jusqu’à ce qu’un message arrive. Une réception asynchrone utilise une future value (CompletableFuture en Java par exemple).

Architecture

Maintenant que nous avons vu les différents concepts de Pulsar, regardons comment cela marche en vrai. Un cluster Pulsar est composé de trois principaux éléments :

Des brokers (serveurs) permettant d’acheminer les messages vers les différents consommateurs, communiquer avec la configuration Pulsar pour permettre la coordination de tâches, stocker des messages dans les “bookies” (instances BookKeeper), etc.
Un cluster BookKeeper (bookies) permettant de persister les messages (c’est comme cela que les topics peuvent être persistants !).
Un cluster ZooKeeper pour gérer les métadonnées des brokers et bookies et surveiller la santé de ceux-ci.

Divide ut regnes

Cette architecture en cluster permet d’établir les concepts vu précédemment de sorte que tout soit distribué. En effet, chaque topic a la possibilité d’être divisé en partitions (appelés partitioned topics). Ces partitions (représentant un morceau du topic) sont répartis automatiquement dans les différents broker Pulsar de manière la plus équitable possible (eg. s’il y a trois brokers et cinq partitions, deux brokers auront deux partitions chacun et la dernière partition sera affectée au troisième broker).

Avec le mode partitioned topic, les consommateurs et producteurs atteignent ainsi une plus grande capacité de traitement. Attention, cela est différent du mode shared subscription où la consommation d’un topic est partagée entre plusieurs consommateurs !

Conclusion

Pour conclure, Apache Pulsar est un système de messagerie qui se veut multi-fonction et multi-entité. L’architecture de Pulsar permet d’avoir un système de type publish-subscribe qui peut également prendre la fonction d’un système de type queue avec les bons paramètres. La différenciation de niveau pour les topics (tenant, namespace, topic) permet une séparation d’entité.

Pour continuer sur le thème des systèmes de type publish-subscribe, vous pouvez consulter cet article sur notre blog décrivant Apache Kafka, un système similaire à Apache Pulsar avec néanmoins plusieurs différences au niveau de l’architecture et des concepts.

Si vous voulez en savoir plus sur l’architecture d’Apache Pulsar et notamment à propos de la persistance des données avec Apache BookKeeper, je vous invite à consulter l'article de Jack Vanlightly : "Understanding how ApachePulsar works".

Typeclass derivation : faites éclore vos instances avec Magnolia

2019-04-02T22:00:00Z

Vous faites du Scala ? Vous communiquez des données avec d'autres services (micro-services, big data, NoSQL...) ? Alors, vous aurez besoin de Magnolia.

Le format de donnée utilisé dans ce cadre est un point très sensible et correspond à des décisions qui vont être en partie contraintes par les performances, les frameworks utilisés... Vient alors la sérialisation et la désérialisation entre les données en mémoire et une représentation sous la forme d'une chaîne de caractères avec une syntaxe spécifique pour les formats lisibles (JSON, XML, CSV...) ou sous la forme d'une suite d'octets pour les formats binaires (Avro, Parquet, Protobuf...).

Sérialisation

Lors de cette phase de sérialisation, il y a différentes approches mise en oeuvre. Supposons que nous avons les case classes ci-dessous, représentant des personnes. Nous cherchons ici à convertir ces case classes en JSON.

case class Address(id: String, city: String)
case class Person(id: String, name: String, age: Int, address: Address)

L'approche de sérialisation la plus simple consiste à faire la conversion à la main. On prend chaque champ de Person qu'on insère dans une chaîne de caractères : s"""{"id": "${person.id}", "name": "${person.name}", ...}""". En terme de performance, c'est rapide. Mais, on a une potentielle répétition entre le nom du champ dans Person et son nom dans le JSON. De plus, avec une évolution du modèle, il faut se rappeler qu'il faut aussi modifier le template — ce qui n'est pas très fiable. Et puis, lorsque vous avez 200 champs par exemple dans votre entité, cette solution ne convient plus du tout. Vous avez enfin de quoi passer des heures de déboggage parce que vous avez oublié une , ou un ".

Une seconde approche consiste à utiliser la réflexion pour explorer la structuration de la donnée et d'en déterminer le structuration et l'élaboration du JSON en sortie. Il n'y a plus, dans ce cas, de répétition et l'approche suit naturellement les évolutions du modèle de donnée. Par contre, cette approche est réalisée au runtime et se traduit pas une réduction des performances de votre application, puisque que la phase d'exploration de la structure de donnée est relancée à chaque sérialisation.

Une troisième approche reprend l'approche précédente, seulement, l'exploration de la structure de donnée est faite une seule fois et va se traduire par la génération d'un code spécifique de conversion du modèle mémoire vers le format de sortie. Cette approche n'est coûteuse que lors de l'unique phase d'exploration et de génération de code. Donc en règle générale, dans un cadre statiquement typé, cette approche sera aussi performante voire plus performante que la version manuelle. Et si la phase d'exploration et de génération de code est faite à la compilation, typiquement avec un système de métaprogrammation avec des macros comme en Scala, cette phase ne vous coûtera plus rien au runtime.

Magnolia propose une telle approche.

Magnolia

Magnolia est un framework léger (à peine 1000 lignes) développé initialement par Jon Pretty en Scala. Magnolia permet de réaliser de la dérivation de typeclasse...

Wait! What?...

Nous avons vu la notion de typeclasse dans le précédent article. Il s'agit d'une fonctionnalité permettant de catégoriser différents types de données et de caractériser un comportement commun (ie. des opérations communes / polymorphes). Les typeclasses ne se basent pas sur l'héritage, mais sur la délégation pour se brancher sur l'implémentation qui convient. Pour déclarer une typeclasse, il faut de déclarer un trait générique, puis instancier ce trait pour des types particuliers.

Bien ! Mais si on crée des instances pour tous les types dont nous aurons besoin, on va vite se retrouver à ne faire que ça. On va aussi vite s'apercevoir qu'il y a une certaine répétition... C'est là qu'intervient la dérivation de typeclasse, qui consiste à générer automatiquement des instances pour des typeclasses données.

Cas d'utilisation : vers le JSON et au-delà

Partons de l'ADT ci-dessous (Algebraic Data Type - type de données algébrique - comprenez un ensemble de trait, case class et case object pour former un type composite) pour représenter des documents JSON.

sealed trait JsonValue
case class   JsonNumber(value: Double)                        extends JsonValue
case class   JsonString(value: String)                        extends JsonValue
case class   JsonBoolean(value: Boolean)                      extends JsonValue
case object  JsonNull                                         extends JsonValue
case class   JsonArray(value: List[JsonValue])                extends JsonValue
case class   JsonObject(value: List[(JsonString, JsonValue)]) extends JsonValue

sealed trait JsonValue
case class   JsonNumber(value: Double)                        extends JsonValue
case class   JsonString(value: String)                        extends JsonValue
case class   JsonBoolean(value: Boolean)                      extends JsonValue
case object  JsonNull                                         extends JsonValue
case class   JsonArray(value: List[JsonValue])                extends JsonValue
case class   JsonObject(value: List[JsonField])               extends JsonValue
case class   JsonField(name:String,value:JsonValue)

Ce qui donne le schéma ci-dessous, où un JsonValue est soit un JsonNumber, un JsonString, un JsonNull, un JsonArray ou un JsonObject.

Et pour des soucis de lisibilité, voici une fonction permettant de convertir des JsonValue en chaîne de caractères JSON.

def mkString(jsonValue: JsonValue): String =
  jsonValue match {
    case JsonNull        => "null"
    case JsonString(v)   => "\"" + v + "\""
    case JsonBoolean(v)  => s"$v"
    case JsonNumber(v)   => s"$v"
    case JsonArray(vs)   => vs.map(mkString).mkString("[", ", ", "]")
    case JsonObject(kvs) =>
      kvs
        .map { case (k, v) => s"${mkString(k)}: ${mkString(v)}" }
        .mkString("{", ", ", "}")
  }

Ce qui donne par exemple :

> mkString(JsonArray(JsonNumber(42), JsonString("all work and no play makes jack a dull boy")))
res0: String = [42.0, all work and no play makes jack a dull boy]

Notre objectif est de convertir n'importe quel type A en JsonValue. Nous créons pour cela une typeclasse ToJson.

trait ToJson[A] {
  def toJson(a: A): JsonValue
}

Afin de facilter l'utilisation de ToJson, nous allons associer la méthode d'extension toJson à tous les types A de catégorie ToJson.

implicit class ToJsonOps[A: ToJson](a: A) {
  def toJson: JsonValue = implicitly[ToJson[A]].toJson(a)
}

Ici, implicitly permet de trouver une instance implicite dont le type correspond au type passé en paramètre.

Nous créons à présent des instances de cette typeclasse pour des types de base.

implicit val intToJson:             ToJson[Int]     = a => JsonNumber(a.toDouble)
implicit val doubleToJson:          ToJson[Double]  = a => JsonNumber(a)
implicit val stringToJson:          ToJson[String]  = a => JsonString(a)
implicit val booleanToJson:         ToJson[Boolean] = a => JsonBooolean(a)
implicit def ListToJson[A: ToJson]: ToJson[List[A]] =
  a => JsonArray(a.map(_.toJson))
implicit def mapToJson[A: ToJson]: ToJson[List[(String, A)]] =
  a => JsonObject(a.map { case (k, v) => (JsonString(k), v.toJson) })

Ce qui donne :

> 42.toJson
res0: JsonValue = JsonNumber(42.0)

> "all work and no play makes jack a dull boy".toJson
res1: JsonValue = JsonString(all work and no play makes jack a dull boy)

> mkString(List("a" -> 1, "b" -> 3).toJson)
res2: String = {"a": 1.0, "b": 3.0}

> implicitly[ToJson[Int]].toJson(42)
res3: JsonValue = JsonNumber(42.0)

> 42L.toJson
<console>:19: error: value toJson is not a member of Long

> implicitly[ToJson[Long]].toJson(42L)
<console>:19: error: could not find implicit value for parameter e: ToJson[Long]

(Les deux derniers cas génèrent une erreur puisque nous n'avons pas déclarer d'instance implicite de type ToJson[Long] auparavant.)

Nous allons à présent dériver automatiquement ToJson pour toutes les case classes que nous pouvons créer. C'est là que nous allons utiliser Magnolia.

Magnolia se compose d'une macro et d'un ensemble d'interfaces pour réifier (ie. convertir en objet) les case classes et les sealed traits. Pour utiliser Magnolia, il faut bien évidemment importer le package correspondant et activer les macros (oui, les macros sont en Scala 2 et donc vouées à disparaître (d'où le experimental) ; nous verrons comment est-ce ça se passe pour les futures versions). Il faut ensuite déclarer notre typeclasse de la manière suivante :

import magnolia._
import scala.language.experimental.macros

type Typeclass[A] = ToJson[A]

Nous allons maintenant déclarer une fonction combine qui va permettre de donner un comportement lié à notre typeclasse sur n'importe quel case classe. Ici nous allons chercher à convertir des case classes en objet JSON.

def combine[A](cc: CaseClass[Typeclass, A]): Typeclass[A] =
  a => {
    val paramMap: List[(JsonString, JsonValue)] =
      cc.parameters
        .map(p => JsonString(p.label) -> p.typeclass.toJson(p.dereference(a)))
        .toList

    JsonObject(paramMap)
  }

À chaque fois que vous voyez Typeclass dans le code ci-dessus, il s'agit bien de ToJson derrière. Il est d'ailleurs possible de changer toutes les occurences de Typeclass par ToJson.

Dans notre case classe cc, passée en entrée de combine, nous allons plus particulièrement nous intéresser aux champs (ou paramètres). Pour chaque paramètre de la case classe, nous récupérons le nom du paramètre (p.label) converti en JsonString que nous associons à la valeur de ce paramètre, elle-même convertie en JSON. p.dereference(a) permet de récupérer la valeur associée au paramètre p dans l'instance a. p.typeclass permet de récupérer l'instance de la typeclasse associé au paramètre p. De fait, p.typeclass va retourner soit l'une des valeurs implicites déclarées plus haut si p correspond à un type de base, soit réaliser un appel récursif sur combine si p correspond à une case classe.

Pour rendre combine accessible, nous utilisons la macro gen de Magnolia de la manière suivante :

implicit def typeToJson[A]: Typeclass[A] = macro Magnolia.gen[A]

typeToJson est déclarée en tant que fonction (def). Ce qui permet d'utiliser la notation générique, où A représente n'importe quel type. Le fait de mettre implicit permet d'associer implicitement ToJson à toutes les case classes que nous rencontrons.

Avec les exemples de case classes Person et Address vu au début de l'article, nous obtenons :

> val toto =
  Person(
    id = "p1",
    name = "Toto",
    age = 32,
    address = Address("c1", "Paris"))
toto: Person = Person(p1, Toto, 32, Address(c1, Paris))

> mkString(toto.toJson)
res0: String = {"id": "p1", "name": "Toto", "age": 32.0, "address": {"id": "c1", "city": "Paris"}}

Conclusion

Il existe des alternatives à Magnolia pour réaliser de la dérivation de typeclasse. Il est possible de passer tout d'abord par Shapeless. Shapeless est un framework léger dédié à la programmation générique. Comme il est plus généraliste la dérivation de typeclasse peut se montrer plus verbeuse qu'avec Magnolia. Il est possible aussi de passer directement par les macros. Néanmoins, comme ce système est de plus bas niveau, il sera au mieux plus difficile de faire de la dérivation.

Avec la probable disparition des macros whitebox dans Scala 3 (type de macro intervenant avant la résolution des types), macros utilisées par Magnolia, la nouvelle version de Scala devrait adopter un outillage permettant de réaliser de la dérivation de typeclasse. Cet outillage tournera autour de nouveaux éléments de syntaxe et une partie spécifique dans la bibliothèque du SDK.

Pour terminer, Magnolia est notamment utilisé dans Scio, développé par Spotify. Scio est une API Scala pour Apache Beam et Google Cloud Dataflow. Julien Tournay a présenté une session ce sujet à ScalaIO 2018.

Projet contenant le code de l'article : https://github.com/univalence/blog-code/tree/master/typeclass_derivation

Pourquoi les typeclasses c'est top ?

2019-03-26T23:00:00Z

Le polymorphisme, qui permet à une opération d'être appelée sur des types différents, est l'une des bases de la programmation orientée objet. Et pourtant elle ne lui est pas exclusivement réservée. C'est en effet un terme que nous retrouvons en programmation fonctionnelle à travers la notion de typeclasse.

La notion de typeclasse n'a en effet rien à voir avec les classes et les interfaces de la programmation orientée objet. Mais elle présente certains point communs. Bon, déjà, il y a classe dedans... Mais ça c'était facile !

En fait, les typeclasses permettent de "catégoriser" des types divers et de leur associer une interface ou une API commune. Sauf que dans le cas des typeclasses, les possibilités d'extension et de mise en application sont beaucoup plus étendues que dans le cadre des classes, jusqu'à permettre de mieux s'en sortir dans un cadre legacy aussi fermé soit-il. Ceci est facilité parce que les typeclasses se basent plus sur la délégation que sur l'héritage.

Du classique à l'héritage

Prenons un exemple : j'ai des chiens et des dinosaures représentés par les types Dog et Dinosaur. Je devrais pouvoir utiliser la même opération walk pour voir les chiens et les dinosaures marcher, pour laquelle seul va changer le comportement associé.

En programmation plus ou moins classique, on partirait sur une approche utilisant la réflexion pour connaître le type de l'instance et une structure conditionnelle pour y associer un traitement spécifique.

public String walk(Object animal) {
  if (animal.isInstanceOf[Dog])
    return "Tap tap tap tap tap tap tap tap";
  else if (animal.isInstanceOf[Dinosaur])
    return "Boom boom acka-lacka lacka boom";
  else
    throw new Exception("your animal doesn't walk. HAhaHAha!");
}

(Depuis les années 80, on sait que les dinosaures font ce bruit lorsqu'ils se déplacent !)

Le problème de cette approche est que le développeur doit penser au cas d'erreur. En cas d'oubli, seule l'exécution du programme avec la bonne donnée en entrée permet de rappeler que la gestion du cas exceptionnel est manquant. C'est une situation qui peut apparaître OÙ ELLE VEUT ET C'EST SOUVENT DANS LA PROD...

Il y a d'autres aspects qui sont relativement problématiques ici. Par exemple, ajouter un animal comme le canard, mais oublier de l'ajouter dans walk. Ce qui va se traduire par une exception. De plus, si ce code vient du bibliothèque tierce scellée (ie. les modifications dans cette bibliothèque sont... c'est très compliqué), ajouter le comportement pour le canard... Et bien... on peut pas 😕. Par contre, si je veux ajouter une opération dance pour mes animaux, ce ne sera pas un soucis.

La programmation orientée objet apporte une solution à ce problème en ne permettant pas au développeur de faire n'importe quoi, sauf lorsqu'il l'a clairement exprimé 🤔

trait Animal { /* ... */ }

trait Walking {
  def walk: String
}

case class Dog(name: String) extends Animal with Walking {
  /* ... */
  def walk: String = "Tap tap tap tap tap tap tap tap"
}
case class Dinosaur(name: String) extends Animal with Walking {
  /* ... */
  def walk: String = "Boom boom acka-lacka lacka boom"
}

def walk(walking: Walking): String = walking.walk

Si je veux ajouter le canard, je dois alors étendre Animal et Walking. Ce qui m'oblige à définir la méthode walk pour cet animal. Après quoi, je peux appeler la fonction walk(Walking) pour les canards.

L'approche orientée objet permet clairement de s'éviter des problèmes à la source et d'avoir moins de cas d'erreur à gérer. On gagne en flexibilité sur la mise en place de nouveaux comportements associés à une opération. Mais en contrepartie, on perd en flexibilité sur l'ajout de nouvelles opérations : si le code ci-dessus fait partie d'une bibliothèque scellée, je ne pourrais pas ajouter un comportement dance, sauf à le faire en partant sur la solution précédente ou en utilisant d'autres approches basées sur la réflexion. Autre point : Dog et Dinosaur est toujours associé au mixin Walking quelque soit le contexte. On peut imaginer des contextes dans lequel "Dinosaur étend Walking" n'a aucune utilité, par exemple lorsque le dinosaure dort (somnambule), ou est perturbant, par exemple lorsqu'il est décédé (walking dead).

C'est vraiment perturbant !

Les typeclasses offrent une réponse à ces cas problématiques.

Typeclasse

Les typeclasses permettent de catégoriser des types existant dans des contextes bien précis et d'associer à ces types des opérations communes.

La mise en place de typeclasses au sein de Scala passe par un idiome basé sur la notion de déclaration implicite. Comme le principe n'est pas très connu, nous allons procéder par étape.

Nous déclarons d'abord quelques classes sans les lier directement à une classe ou une interface quelconque.

case class Dog(name: String)
case class Dinosaur(name: String)

Nous déclarons ensuite avec un trait un type paramétré qui va permettre de catégoriser n'importe quel type A, sur lequel nous pourrons appeler la méthode walk. C'est notre typeclasse !

trait Walking[A] {
  def walk(a: A): String
}

Définissons une fonction walk.

def walk[A: Walking](a: A): String =
  implicitly[Walking[A]].walk(a)

Cette fonction se base en entrée sur n'importe quel type A. Néanmoins, dans la signature, nous indiquons que ce type est contraint par le fait qu'il doit être de catégorie Walking (A: Walking). Dans le corps de la fonction, nous indiquons que nous recherchons une instance de Walking déclarée implicitement pour le type A donnée (implicitly[Walking[A]]). Une fois récupérée, nous pourrons appeler la méthode walk dessus.

Nous déclarons à présent des instances implicites de Walking pour Dog et Dinosaur avec un comportement spécifique. Ce sont les instances de la typeclasse.

implicit val dogWalking =
  new Walking[Dog] {
    def walk(d: Dog): String = "Tap tap tap tap tap tap tap tap"
  }
 
implicit val dinosaurWalking =
  new Walking[Dinosaur] {
    def walk(d: Dinosaur): String = "Boom boom acka-lacka lacka boom"
  }

Et donc, à l'utilisation ça donne :

walk(Dog("Rambo"))          // Tap tap tap tap tap tap tap tap
walk(Dinosaur("P'tit Rex")) // Boom boom acka-lacka lacka boom

Si la déclaration d'une instance implicite est manquante, nous avons alors une erreur de compilation.

case class Duck(name: String)

walk(Duck("Donald")) // KO 🙀 - compilation error
// could not find implicit value for evidence parameter of type Walking[Duck]

Pour que le code ci-dessus fonctionne avec Duck, il faut alors déclarer une instance implicite de type Walking[Duck].

Quelques remarques ici :

Dog et Dinosaur sont décorrélés de Walking. Les deux déclarations peuvent se faire dans des espaces de code différents.
Le lien entre Dog et Dinosaur d'un côté avec Walking est concrétisé par les instances implicites (implicit val ...). La déclaration de ces instances peut se faire dans un autre espace de code.

Donc, même si Dog, Dinosaur, Walking et la fonction walk sont dans des bibliothèques scellées, il est toujours possible :

de créer de nouveaux animaux avec le comportement Walking,
d'associer un comportement Dancing pour Dog et Dinosaur,
de ne pas importer le comportement Walking s'il n'est pas nécessaire.

Le tout est vérifié par le compilateur.

Pour terminer

Nous avons vu sans le nommer des exemples de typeclasses à la fin de notre précédent article sur la covariance et la contravariance, avec les notions de Functor et CoFunctor.

C'est en tout cas cette approche qui est employée par des bibliothèques comme Cats ou ScalaZ pour associer à des types un comportement de Functor et de Monad, même à des types déjà définit dans la bibliothèque standard de Scala.

La notion de typeclasse provient du langage Haskell. Contrairement à Scala, les typeclasses ont une syntaxe spécifique dans Haskell. La notion a aussi été adaptée à Kotlin, comme on peut le voir avec la bibliothèque Arrow. Scala 3 devrait proposer une syntaxe spécifique pour les typeclasses, en particulier pour la déclaration des instances.

Nous verrons dans un prochain article l'utilisation des typeclasses avec Magnolia, afin de faciliter la conversion de format de données, en incluant les case class.

Référence

dotty/docs/docs/reference/contextual/derivation.md at 63b4ad7a28c92b32469b6ef997765336bc2274c2 · dotty-staging/dotty

Research platform for new language concepts and compiler technologies for Scala. - dotty/docs/docs/reference/contextual/derivation.md at 63b4ad7a28c92b32469b6ef997765336bc2274c2 · dotty-staging/dotty

https://github.com/dotty-staging/dotty/blob/63b4ad7a28c92b32469b6ef997765336bc2274c2/docs/docs/reference/contextual/derivation.md

Covariance, contravariance et botanique

2019-03-20T23:00:00Z

La notion de variance est une notion souvent énigmatique pour les développeurs. On retrouve cette notion dès lors que nous sommes en présence d'un langage utilisant à la fois du sous-typage et des types paramétrés (ou type générique). Ce qui inclut une bonne partie des langages proposant un style de programmation orienté objet basé sur des classes et parmi eux, les langages qui utilisent les génériques (Java, C#, Scala...).

Si j'ai écrit énigmatique, c'est bien parce qu'à travers la notion de variance nous nous retrouvons parfois avec des erreurs de compilation difficiles à comprendre. Il faudra alors jouer avec T extends U ou ? super T en Java. Et en Scala, ce sera avec les expressions +A, -A, A <: B et A >: B.

Pourtant le choix est relativement simple : sommes-nous en position de producteur / fournisseur de données ou en position de consommateur ? De cette question, vous pourrez déterminer si un paramètre est covariant ou contravariant.

Covariance

La cas le plus souvent rencontré et celui qui est le plus intuitif est la covariance. Ce cas apparaît avec les collections, avec le type Option, mais aussi avec le type IO et les types représentant des fonctions (le type de la sortie d'une fonction est covariant). La covariance s'applique dès qu'il est possible d'utiliser l'analogie avec une boîte, un conteneur, un burrito ou tout ce qui s'apparente à de la production ou à de la fourniture de données.

En exemple, nous allons créer une arborescence représentant des aliments, des fruits et des légumes (classification purement culinaire, tout en s'évitant le cas de la tomate).

trait Aliment {
  def name: String
}
case class Fruit(name: String) extends Aliment
case class Legume(name: String) extends Aliment

val fraise = Fruit("fraise")
val brocoli = Legume("brocoli")

Nous avons maintenant deux gourmands : Mary qui mange plutôt varié et Johnny qui ne mange que des fruits. Représentons les par des fonctions.

def maryMange(l: List[Aliment]): Unit = ()
def johnnyMange(l: List[Fruit]): Unit = ()

Dans ce cas, passer une liste de fruits à ces deux fonctions ne posent pas problème. Le cas de Johnny est trivial. Pour Mary, il n'y a pas d'inconvénient puisque les fruits sont des aliments.

val fruits: List[Fruit] = List(fraise, fraise)

maryMange(fruits)   // OK 😻 - grâce à la covariance, cela compile !
johnnyMange(fruits) // OK 👌 - ça compile !

Par contre :

val aliments: List[Aliment] = List(brocoli, fraise)

maryMange(aliments)   // OK 👌 - ça compile !
johnnyMange(aliments) // NOK 🙀 - erreur de compilation

Nous avons alors une erreur de compilation, puisque Johnny ne peut/veut pas manger n'importe quel aliment.

List[A] est covariant puisque le type de List varie dans le même sens que le type de A. Puisque Fruit est un sous-type de Aliment, alors List[Fruit] est un sous-type de List[Aliment]. Ça fonctionne avec les types Stream[A], Option[A], RDD[A], Parser[A], X => A (uniquement si nous nous intéressons à la variance de A), Either[E, A]...

De manière générale, nous pouvons imaginer un type Producteur[A] sur lequel nous avons une méthode get permettant de récupérer une valeur. Nous allons utiliser le symbole + en prefix de la définition du paramètre de type pour indiquer que le paramètre de type est covariant.

case class Producteur[+A](get: A)

val jardinFraise: Producteur[Fruit] = Producteur(fraise)
val jardinAliment: Producteur[Aliment] = Producteur(brocoli)

def recolte[A](producteur: Producteur[A]): A = producteur.get

recolte[Aliment](jardinFraise)  // OK 😻 - grâce à la covariance, cela compile !
recolte[Aliment](jardinAliment) // OK 👌 - ça compile !

recolte[Fruit](jardinFraise)    // OK 👌 - ça compile !
recolte[Fruit](jardinAliment)   // NOK 🙀 - erreur de compilation

Contravariance

Alors là, accrochez-vous. La contravariance est pour le coup moins intuitif.

Nous avons vu que la covariance apparaît lorsqu'un type générique varie dans le même sens que son type sous-jacent. Et bien, il y a des cas où le type générique varie dans le sens inverse par rapport à son type sous-jacent. Autrement dit, on a bien Fruit qui est sous-type de Aliment, mais DownUnder[Aliment] est un sous-type DownUnder[Fruit], si DownUnder est un tel type.

Cette situation arrive dans un cadre de consommation de données. Par exemple, lorsque vous fournissez des données en entrée d'une fonction, lorsque vous envoyez des messages à Kafka, lorsque vous avez un setter ou lorsque vous exécutez des INSERT dans une base.

Imaginons un type Consommateur[A] qui possède une méthode mange qui absorbe dans élément de type A. Nous allons utiliser le symbole - pour indiquer que le type est contravariant. Nous allons aussi reprendre nos personnages : Mary qui mange plutôt varié et Johnny qui ne mange que des fruits.

case class Consommateur[-A](mange: A => Unit)

val mary = Consommateur[Aliment](mange = aliment => ())
val johnny = Consommateur[Fruit](mange = fruit => ())

Créons une fonction liée au service dans un restaurant.

def serviceRestaurant[A](consommateur: Consommateur[A]): A => Unit =
  a => consommateur.mange(a)

Testons avec Mary :

serviceRestaurant[Fruit](mary)   // OK 😻 - grâce à la contravariance, ça compile !
serviceRestaurant[Aliment](mary) // OK 👌 - ça compile !

Puisque Mary mange toute sorte d'aliments, elle peut aussi manger des fruits.

Par contre, avec Johnny :

serviceRestaurant[Fruit](johnny)   // OK 👌 - ça compile !
serviceRestaurant[Aliment](johnny) // NOK 🙀 - erreur de compilation

Johnny ne mange que des fruits. Du coup, il ne peut pas manger des aliments quelconques tant qu'il n'a pas la garanti qu'il s'agit de fruits.

Ainsi, Fruit a beau être un sous-type de Aliment, Consommateur[Aliment] est vu comme un sous-type de Consommateur[Fruit].

Autres cas d'application

Les notions de covariance et contravariance ne s'appliquent pas seulement aux types. Elles vont aussi s'appliquer aux catégories de types. C'est le cas avec les functors.

En règle générale, quand on imagine la notion de Functor et l'opération map, on l'imagine dans un cadre covariant :

trait Functor[F[_]] {
  def map[A, B](fa: F[A])(f: A => B): F[B]
}

def map[A, B, F[_]: Functor](fa:F[A])(f: A => B): F[B]

Il en existe une version contravariante :

trait CoFunctor[F[_]] {
  def comap[A, B](f: B => A)(fa:F[A]): F[B]
}

def comap[A, B, F[_]: CoFunctor](f: B => A)(fa: F[A]): F[B]

Reprenons le type Consommateur[A].

Imaginons que nous avons un Consommateur[String]. Mais nous avons en entrée des données de type Int. Pour convertir notre Consommateur[String] en Consommateur[Int], il suffit de fournir une fonction qui convertit des Int en String et de l'appliquer à notre Consommateur[String] en utilisant comap.

// create CoFunctor instance for Consommateur
implicit val consommateurCoFunctor =
  new CoFunctor[Consommateur] {
    def comap[A, B](f: B => A)(fa: Consommateur[A]):Consommateur[B] = 
        Consommateur(b => fa.mange(f(b)))
  }

val stringConsommateur: Consommateur[String] = ???

val intConsommateur: Consommateur[Int] =
  comap((i: Int) => i.toString)(stringConsommateur)

Nous retrouvons aussi les notions de covariance et de contravariance dans le cadre de Magnolia. Magnolia est un petit framework permettant d'associer des typeclasses à des case class et des sealed traits.

Shuffle dans Spark, reduceByKey vs groupByKey

2019-03-14T23:00:00Z

Introduction

Lors de mes débuts dans Spark, un collègue m’a dit la chose suivante : "N’utilise pas groupByKey, utilise plutôt reduceByKey". Je lui demande alors pourquoi l’un plutôt que l’autre et il me répond tout simplement : “à cause du shuffle”. Hein ? Shuffle ?

Effectivement, je n’avais encore jamais entendu ce terme dans ma vie, alors qu’il se révèle d’une importance extrême dans le traitement des données en parallèle, surtout si vous voulez avoir une performance élevée dans vos temps de traitement.

Qu’est-ce que le shuffle dans Spark ?

Shuffle (anglais) : remanier, mélanger, battre (des cartes)...

Dans Spark, on parle de shuffle lorsqu’on envoie des données à travers le cluster, d’une machine vers une autre. Par exemple :

On effectue un shuffle de la donnée A et on l'envoie de la machine A vers la machine B. Simple non ?

La chose importante à retenir est que ce transfert de données requiert une connexion réseau entre les machines, et que plus il y aura de machines et de données à transférer, plus il y aura de trafic réseau.

Et donc c’est quoi la différence entre groupByKey et reduceByKey ?

Tout d’abord, rafraîchissons nous la mémoire sur les “resilient distributed dataset”, plus communément appelés RDD. Spark Core travaille avec ces objets, qui sont des collections de records/observations distribuées dans un cluster de machines. Chaque “morceau” de RDD réparti est appelé partition. Dans Spark, chacune des partitions appartient à un exécuteur.

Exemple de construction d’un RDD :

val words =
  List("univalence", "scala", "scala", "univalence", "univalence", "scala")
val wordsRDD = sc.parallelize(words).map(word => (word, 1))

Afin de pouvoir observer la différence entre groupByKey et reduceByKey, essayons de les appliquer au RDD du dessus pour faire un simple word count (occurrence de chaque string d’une liste).

// Code groupByKey
val wordCountGroupByKey = wordsRDD
	.groupByKey() // On groupe chaque paire par leur clé (ici le mot)
	.map((word, list) => (word, list.sum)) // On fait la somme

// Code reducebykey
val wordCountReduceByKey = wordsRDD
	.reduceByKey(_ + _) // On calcule l’occurrence et groupe chaque paire 
			    // par leur clé

Les deux fonctions ont à priori l’air de faire le même travail, bien qu’ils s’appliquent différemment. Pourtant, reduceByKey est en fait plus performant que groupByKey lorsqu’il y a beaucoup de données (et ça c’est utile quand on travaille dans le Big Data).

But why ?

Imaginons que le RDD wordsRDD est réparti en deux partitions.

En réalité, ce qui se passe pour groupByKey, c’est qu’il va d’abord chercher à déplacer les clés identiques dans une même partition (1), afin de pouvoir appliquer le traitement (2) (ici faire la somme pour chaque mot) :

Il y a deux conséquences à cela :

Cela produit un shuffle assez important des données car il doit le faire pour chaque donnée de chaque partition du RDD. Donc, si les partitions ne sont pas sur une même machine, cela provoque un gros trafic réseau.
Si dans notre exemple un mot composait 99% de la liste, groupByKey rassemblera toutes les données ayant comme clé ce mot dans une seule machine, ce qui peut causer des problèmes de mémoire.

Pour reduceByKey, les choses se passent différemment. Il y a d’abord un “pré-traitement” (1) dans chacune des partitions, puis les données sont déplacées selon leur clé (2), pour enfin avoir un traitement final (3) sur les partitions :

On n’évite donc pas le shuffle de données avec reduceByKey. Néanmoins la quantité de données à déplacer est amoindrie par le pré-traitement dans chaque partition. Il en résulte un trafic réseau potentiellement moins important (donc amélioration du temps de traitement) et également moins de risque de problème de mémoire.

Conclusion

Prendre en compte le shuffle lorsque des traitements parallèles sont mis en place, notamment les opérations comme reduceByKey et groupByKey qui en produisent.
Préférer reduceByKey à groupByKey pour avoir une meilleure performance dans le temps de traitement et moins de problèmes de mémoire (en particulier si le nombre moyen d'éléments par clé par partition est élevé).
Si vous voulez aller plus loin il y a combineByKey qui offre encore plus d'options (reduceByKey est implémenté en utilisant combineByKey)

Kafka et les groupes de consommateurs

2019-03-13T23:00:00Z

Kafka est l'un des systèmes orientés messages les plus performants existant actuellement. Il se base sur une approche producteurs-consommateurs communiquant à travers des topics. Afin d'aider à mettre en place diverses stratégies d'ingestion de données, Kafka donne la possibilité de regrouper des consommateurs qui vont se partager les messages de topics auxquels ils ont souscript.

La notion de groupe de consommateurs est apparue avec la version 0.9 de Kafka. D'abord optionnelle, cette fonctionnalité va devenir obligatoire. En effet, il y a dans le code KafkaConsumer ce warning qui apparaît, si vous oubliez de fournir le paramètre group.id :

"Support for using the empty group id by consumers is deprecated and will be removed in the next major release."

Ça vaut le coup d'en savoir plus sur la notion de groupe de consommateurs dans Kafka.

Généralité

Dans Kafka, un groupe représente un ensemble de consommateurs partageant les mêmes offsets, et donc aussi les mêmes partitions et les mêmes topics.

Néanmoins, à un instant donné les différentes partitions d'un topic vont être réparties sur les différents consommateurs du groupe sans qu'il ait d'accès concurrent (ie. il ne peut pas y avoir deux consommateurs du même groupe sur une même partition). Si le groupe contient plus de consommateurs que de partitions, certains consommateurs ne seront pas utilisés.

Un groupe est identifié par un groupId, qui est une simple chaîne de caractères. Il est déclaré au niveau des consommateurs et il est géré au niveau brokers.

On peut utiliser la notion de groupe pour coordonner des consommateurs de différentes manières :

avec des groupes différents pour des consommateurs, pour effectuer des traitements différents sur les données apparaissant au niveau d'un même topic. C'est par exemple le cas dans le cadre des analytics lorsqu'on a besoin de sortir différentes mesures ou différents KPI.
avec un groupe unique pour un ensemble de consommateurs, pour répartir la charge d'ingestion des données entre différents consommateurs. Cette approche permet de scaler un service.

Si vous utilisez la plateforme Confluent, vous verrez l'ensemble des groupes disponibles en cliquant sur "Consumer lag". Sinon, vous pouvez utiliser la commande kafka-consumer-groups avec l'option --list.

$ ./bin/kafka-consumer-groups \
  --bootstrap-server localhost:9092 \
  --list

Ce qui donne, par exemple :

my_group
_confluent-controlcenter-5-1-2-1-command
_confluent-controlcenter-5-1-2-1
group_641bd1a6-c275-42a8-b90b-26f92f25cb38

Vous pouvez aussi utiliser la classe AdminClient dans l'API kafka-client.

import scala.collection.JavaConverters._

val brokers: String             = "localhost:9092"
val config: Map[String, AnyRef] =
  Map(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG -> brokers)
val adminClient: AdminClient    = AdminClient.create(mapAsJavaMap(config))

for (group <- adminClient.listConsumerGroups().all().get().asScala) {
  println(s"${group.groupId()}")
}

adminClient.close()

Création d'un groupe

La création d'un groupe est déclenchée par l'opération poll() au niveau du consommateur. Il faut donc créer un consommateur, le faire souscrire à un topic et tenter une récupération de message pour pouvoir créer un groupe. Si le groupId n'existe pas dans Kafka, il y aura une sélection au niveau des brokers à partir du hashcode du group ID, pour décider du broker qui deviendra le coordinateur du groupe. Le coordinateur est responsable de la gestion du groupe, de ses membres, du suivi de son cycle de vie et d'assigner les partitions.

Par contre, il n'y a pas d'autres possibilités pour créer un groupe, ni en ligne de commande, ni par l'API Kafka, ni par le Control Center de Confluent.

Cycle de vie

Les groupes ont 4 états de fonctionnement possibles :

Empty : le groupe n'a plus de membre associé. Il est éligible à la suppression si aucun commit n'a été fait dans ce groupe. Il s'agit aussi de l'état initial d'un groupe lors de sa création, qui passe alors rapidement à l'état PreparingRebalance, puisque le membre responsable de la création du groupe va par suite demander de rejoindre le groupe.
Stable : le groupe comporte un ou plusieurs membres et il n'y a pas de changement dans sa configuration.
PreparingRebalance : un ou plusieurs membres rejoingnent le groupe ou sont retirés du groupe. Le groupe se prépare à un rééquilibrage des charges.
CompletingRebalance (anciennement AwaitingSync) : le groupe est en attente de l'attribution d'un état de la part du leader du groupe.

En cas de problème rencontré avec un groupe, celui-ci passe alors à l'état Dead. Cet état est aussi atteint si un groupe est vide et si ses anciens membres n'ont pas fait de commit. Cet état apparaît enfin dans le cas où une partition associée au groupe disparait.

Voici le diagramme d'états-transitions que révèle le code source sur les états d'un groupe.

La notion de rééquilibrage ici sous-entend une rerépartition de la charge au sein d'un groupe et donc une rerépartition des partitions. Ce rééquilibrage a lieu lorsqu'un consommateur rejoint le groupe ou lorsqu'il le quitte. Il a aussi pour effet d'incrémenter le numéro generationId, qui représente un numéro de configuration (en terme de membres) du groupe. Ce numéro est très présent lorsqu'on regarde les logs des brokers Kafka.

INFO [GroupCoordinator 0]: Stabilized group my_group generation 2 (__consumer_offsets-14) (kafka.coordinator.group.GroupCoordinator)
INFO [GroupCoordinator 0]: Preparing to rebalance group my_group in state PreparingRebalance with old generation 2 (__consumer_offsets-14) (reason: removing member consumer-2-dc8d50e1-aabc-411d-a91e-aa906ef0b15f on heartbeat expiration) (kafka.coordinator.group.GroupCoordinator)
INFO [GroupCoordinator 0]: Group my_group with generation 3 is now empty (__consumer_offsets-14) (kafka.coordinator.group.GroupCoordinator)
INFO [GroupMetadataManager brokerId=0] Group my_group transitioned to Dead in generation 3 (kafka.coordinator.group.GroupMetadataManager)
INFO [GroupCoordinator 0]: Removed 1 offsets associated with deleted partitions: webclick-0. (kafka.coordinator.group.GroupCoordinator)

Pour pouvoir rester dans un groupe, les membres doivent envoyer un signal de heartbeat au coordinateur (paramètre : heartbeat.interval.ms - 3 secondes par défaut d'après le code source de Kafka). S'il n'y a pas de signal envoyé, le coordinateur va attendre un certain temps (paramètre : session.timeout.ms - 10 secondes par défaut d'après le code source de Kafka). Si un membre n'a toujours rien envoyé malgré ce délai, il est viré du groupe et un rééquilibrage se met en place.

À tout moment, vous pouvez utiliser AdminClient de l'API Kafka, le Control Center (menu "Consumer lag") ou kafka-consumer-groups pour obtenir des informations sur un groupe. Par exemple :

$ ./bin/kafka-consumer-groups \
  --bootstrap-server localhost:9092 \
  --describe --group my_group

Ce qui donne, par exemple :

Consumer group 'my_group' has no active members.

TOPIC           PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG             CONSUMER-ID     HOST            CLIENT-ID
webclick        0          20              50              30              -               -               -
webclick        1          0               30              30              -               -               -

La notion de lag correspond à la différence entre le dernier offset de message traité par le groupe pour une partition donnée et l'offset du message le plus récent. Dans l'exemple ci-dessus, nous voyons qu'il reste pour le groupe my_group 30 messages à traiter sur chaque partition du topic webclick, mais qu'il n'y a aucun consommateur associé au groupe.

Avec l'option --state :

./bin/kafka-consumer-groups \
  --bootstrap-server localhost:9092 \
  --describe --group my_group \
  --state

Nous avons à la fois l'état du groupe (Empty ici), le nombre de membres et la référence du broker qui sert de coordinateur.

Consumer group 'my_group' has no active members.

COORDINATOR (ID)          ASSIGNMENT-STRATEGY       STATE                #MEMBERS
192.168.0.40:9092 (0)                               Empty                0

Suppression d'un groupe

La suppression d'un groupe peut être manuelle, en utilisant à nouveau la commande kafka-consumer-groups.

$ ./bin/kafka-consumer-groups \
  --bootstrap-server localhost:9092 \
  --delete --group my_group

Elle peut se faire avec AdminClient de l'API Kafka. Par contre, le Control Center ne semble pas offrir cette possibilité.

Sinon, la suppression des groupes vides sans commit associé est orchestré par un scheduler interne. Les intervalles de vérification de ce scheduler dépendent du paramètre côté broker offsets.retention.check.interval.ms (par défaut 10 minutes d'après le code source de Kafka).

Doc

Pour plus d'information, vous pouvez aller sur cette page de Confluent qui décrit le fonctionnement des consommateurs et des groupes de consommateurs.

Kafka Consumer for Confluent Platform | Confluent Documentation

An Apache Kafka consumer group is a set of consumers which cooperate to consume data from some topics.

https://docs.confluent.io/platform/current/clients/consumer.html

Spark : Déduplication dans le schéma

2019-03-07T23:00:00Z

Avez-vous déjà vu... un DataFrame Spark ayant deux colonnes ayant le même nom ? Et avez-vous essayé de lancer une requête SQL dessus ?

Il est possible que ça soit le cas si vous utilisez Spark, même de manière sporadique. Lorsque vous faites une jointure entre deux dataframes, vous allez rencontrer rapidement ce cas de figure :

case class Person(id: String, name: String, age: Int)
case class Status(id: String, status: String)

val statusDF: DataFrame = ss.createDataFrame(Seq(Person(id = "id1", name = "toto", age = 13)))
val personDF: DataFrame = ss.createDataFrame(Seq(Status(id = "id1", status = "active")))

val dataframe: DataFrame =
  personDF.join(statusDF, personDF("id") === statusDF("id"))

dataframe.select("id", "name", "status").show()

Lors du select, Spark va vous rappeler gentiment à l'ordre avec l'exception suivante :

org.apache.spark.sql.AnalysisException: Reference 'id' is ambiguous, could be: id, id.;

Mais, vous pouvez aussi avoir la maladresse d'enregistrer un tel DataFrame sur disque (en utilisant le format Parquet, par exemple). Sans le savoir, vous allez vous retrouver avec une colonne illisible. Vous allez du coup être accueillis par une autre exception lors de la lecture :

java.lang.RuntimeException: [id] BINARY was added twice

Alors que faire dans ce cas-là ? Sommes-nous condamnés à maudire la personne qui a osé mettre deux noms de colonne identiques ? 🤬

Vous pouvez vous en sortir avec trois solutions :

Il existe une solution très facile à ce problème, en modifiant le nom de la colonne responsable (ici id) en amont de la jointure :

val statusDFRenamed: DataFrame = statusDF.withColumnRenamed("id", "idStatus")
//ou bien
val personDFRenamed: DataFrame = personDF.withColumnRenamed("id", "idPerson")

Si vous souhaitez travailler directement sur la dataframe en sortie de jointure, vous pouvez utiliser une fonction que nous avons mis dans Plumbus, qui réalise un coalesce entre des colonnes de même nom. Pour réussir à définir cette transformation, on passe par la structure de la requête (Catalyst), afin d'adresser individuellement les colonnes qui ont le même nom (NamedExpression).

def coalesceColWithSameName(df: DataFrame): DataFrame = {
    //pour être sûr que c'est un Project
    val frame: DataFrame = df.select("*")
    //récupération de toutes les expressions : id, name, age, id, status
    val cols: Seq[NamedExpression] = frame.queryExecution.analyzed.asInstanceOf[Project].projectList
    //colonnes en sortie, dans le même ordre, sans les doublons
    val outputCols: Array[String] = frame.columns.distinct

    import org.apache.spark.sql.functions.coalesce
    
    val colMap: Map[String, Column] = {
      val nameExpressionsByName: Map[String, Seq[NamedExpression]] = cols.groupBy(_.name)

      nameExpressionsByName.map({
        //seulement une expression pour ce nom
        case (name, Seq(expr)) => (name, new Column(expr).as(name))
        //plusieurs expressions pour ce nom => fusion avec coalesce
        case (name, nameExpressions) => (name, coalesce(nameExpressions.map(x => new Column(x)): _*).as(name))
      })
    }

    frame.select(outputCols.map(colMap): _*)
  }

Vous pouvez utiliser une autre solution que nous avons aussi ajouté à Plumbus, avec un comportement différent. Ici, les colonnes en doublon vont être renommées séparément avec un suffixe généré automatiquement (_1, _2, _3, ..., _n). Même technique, nous utilisons la structure de la requête pour adresser individuellement les colonnes.

def renameColumnsWithSameName(df: DataFrame): DataFrame = {
    val frame: DataFrame = df.select("*")
    val namedExpressions: Seq[NamedExpression] = frame.queryExecution.analyzed.asInstanceOf[Project].projectList
    val duplicateNames: Set[String] = namedExpressions.map(_.name).groupBy(identity).filter(_._2.size > 1).keys.toSet

    if (duplicateNames.isEmpty) {
      df
    } else {
      type NameCount = Map[String, Int]
      type Res = (NameCount, Seq[Column])

      val zero: Res = (Map.empty, Nil)

      val res = namedExpressions.foldLeft(zero)({
        case ((counts, cols), exp) =>
          if (duplicateNames(exp.name)) {
            val i = counts.getOrElse(exp.name, 0)
            val col = new Column(exp).as(exp.name + "_" + i)

            (counts + (exp.name -> (i + 1)), cols :+ col)
          } else {
            (counts, cols :+ new Column(exp))
          }
      })

      df.select(res._2: _*)
    }

  }

Voici un exemple :

import ss.implicits._

val person: Person = Person(id = "1", name = "toto", age = 13)
val status: Status = Status(id = "1", status = "active")

val df1: Dataset[Person] = ss.createDataset(Seq(person))
val df2: Dataset[Status] = ss.createDataset(Seq(status))

val frame: DataFrame = df1.join(df2, df1("id") === df2("id"))

println("initial DataFrame")
frame.show()

//clean auto1
println("coalesceColWithSameName")
coalesceColWithSameName(frame).show()

//clean auto2
println("renameColWithSameName")
renameColumnsWithSameName(frame).show()

Nous obtenons en sortie :

initial DataFrame
+---+----+---+---+------+
| id|name|age| id|status|
+---+----+---+---+------+
|  1|toto| 13|  1|active|
+---+----+---+---+------+

coalesceColWithSameName
+---+----+---+------+
| id|name|age|status|
+---+----+---+------+
|  1|toto| 13|active|
+---+----+---+------+

renameColWithSameName
+----+----+---+----+------+
|id_0|name|age|id_1|status|
+----+----+---+----+------+
|   1|toto| 13|   1|active|
+----+----+---+----+------+

Conclusion

Nous avons vu comment gérer ces dataframes assez embêtant et nous avons vu trois manières de répondre à ce problème, chacune ayant un niveau de difficulté variable. Évidemment le but de cet article était d'en apprendre plus sur Catalyst et sur les différentes opérations possibles faisable avec celui-ci. Il peut être très bénéfique d'utiliser Catalyst dans le cadre d'opérations manipulant le schéma d'un dataframe en Spark.

Nous avons vu rapidement comment résoudre le problème des doublons de colonnes de manière générique, en allant chercher un peu d'info dans les représentations internes de Spark SQL (ie. avec Catalyst). Ces APIs, assez méconnues, peuvent être très intéressantes si nous devons aller plus loin que la manipulation générique de schéma (avec df.schema).

Notes

lorsque l'on manipule les dataframes :org.apache.spark.sql.AnalysisException: Reference 'id' is ambiguous, could be: id#3, id#7.;
si on sauvegarde en parquet et que l'on relit ça après : Caused by: java.lang.RuntimeException: [id] BINARY was added twice

Solutions :

à la main
avec def coalesceColwithSameName(df: DataFrame):DataFrame
avec def renameColumnsWithSameName(df:DataFrame):DataFrame

Code

import org.apache.spark.sql.catalyst.expressions.NamedExpression
import org.apache.spark.sql.catalyst.plans.logical.Project
import org.apache.spark.sql.{Column, DataFrame, SparkSession}
import org.scalatest.FunSuite

case class Person(id:String,name:String,age:Int)

class TestDuplicateCols extends FunSuite with TestUtils {

  val ss: SparkSession = TestSparkSession.create()

  def coalesceColwithSameName(df: DataFrame):DataFrame = {
    //pour être sûr que c'est un Projet
    val frame = df.select("*")
    //récupération de toutes les expressions : id#3, name#4, age#5,id#7, name#8, age#9
    val cols: Seq[NamedExpression] = frame.queryExecution.analyzed.asInstanceOf[Project].projectList
    //colonnes en sortie
    val outpuCols = frame.columns.distinct

    import org.apache.spark.sql.functions.coalesce
    //
    val colMap: Map[String, Column] = {
      val nameExpressionsByName: Map[String, Seq[NamedExpression]] = cols.groupBy(_.name)

      nameExpressionsByName.map({
        //seulement une expression pour ce nom
        case (name, Seq(expr))       => (name, new Column(expr).as(name))
        //plusieurs expressions pour ce nom => fusion avec coalesce
        case (name, nameExpressions) => (name, coalesce(nameExpressions.map(x => new Column(x)): _*).as(name))
      })
    }
    frame.select(outpuCols.map(colMap):_*)
  }

  def renameColumnsWithSameName(df:DataFrame):DataFrame = {
    val frame = df.select("*")

    val namedExpressions = frame.queryExecution.analyzed.asInstanceOf[Project].projectList

    val duplicateNames: Set[String] = namedExpressions.map(_.name).groupBy(identity).filter(_._2.size > 1).keys.toSet

    if(duplicateNames.isEmpty) df else {

      type NameCount = Map[String,Int]
      type Res = (NameCount,Seq[Column])

      val zero:Res = (Map.empty,Nil)

      val res = namedExpressions.foldLeft(zero)({
        case ((counts,cols),exp) =>
        if(duplicateNames(exp.name)) {
          val i = counts.getOrElse(exp.name,0)
          val col = new Column(exp).as(exp.name + "_" + i)

          (counts + (exp.name  -> (i + 1)),cols :+ col)
        } else {
          (counts, cols :+ new Column(exp))
        }
      })

      df.select(res._2:_*)
    }

  }


  test("toto") {

    import ss.implicits._

    val person = Person(id = "1", name = "toto", age = 13)

    val df1 = ss.createDataset(Seq(person))

    val df2 = df1

    val frame = df1.join(df2, df1("id") === df2("id"))



    //frame.apply("xyz")

    frame.show()

    val plan = frame.select("*").queryExecution.analyzed

    //bug
    //frame.select("id","age","name")

    //work
    frame.select(df1("id"),df1("age"),df1("name")).show()


    //clean auto1
    coalesceColwithSameName(frame).show()

    //clean auto2
    renameColumnsWithSameName(frame).show()
  }

}

Output

+---+----+---+---+----+---+
| id|name|age| id|name|age|
+---+----+---+---+----+---+
|  1|toto| 13|  1|toto| 13|
+---+----+---+---+----+---+

+---+---+----+
| id|age|name|
+---+---+----+
|  1| 13|toto|
+---+---+----+

+---+----+---+
| id|name|age|
+---+----+---+
|  1|toto| 13|
+---+----+---+

+----+------+-----+----+------+-----+
|id_0|name_0|age_0|id_1|name_1|age_1|
+----+------+-----+----+------+-----+
|   1|  toto|   13|   1|  toto|   13|
+----+------+-----+----+------+-----+

Code formaté

import org.apache.spark.sql.catalyst.expressions.NamedExpression
import org.apache.spark.sql.catalyst.plans.logical.Project
import org.apache.spark.sql.{Column, DataFrame, SparkSession}
import org.scalatest.FunSuite

case class Person(id: String, name: String, age: Int)

class TestDuplicateCols extends FunSuite {

  val ss: SparkSession = SparkSession.builder().master("local[*]").getOrCreate()

  def coalesceColwithSameName(df: DataFrame): DataFrame = {
    //pour être sûr que c'est un Project
    val frame = df.select("*")
    //récupération de toutes les expressions : id#3, name#4, age#5,id#7, name#8, age#9
    val cols: Seq[NamedExpression] = frame.queryExecution.analyzed.asInstanceOf[Project].projectList
    //colonnes en sortie
    val outpuCols = frame.columns.distinct

    import org.apache.spark.sql.functions.coalesce
    
    val colMap: Map[String, Column] = {
      val nameExpressionsByName: Map[String, Seq[NamedExpression]] = cols.groupBy(_.name)

      nameExpressionsByName.map({
        //seulement une expression pour ce nom
        case (name, Seq(expr)) => (name, new Column(expr).as(name))
        //plusieurs expressions pour ce nom => fusion avec coalesce
        case (name, nameExpressions) => (name, coalesce(nameExpressions.map(x => new Column(x)): _*).as(name))
      })
    }
    frame.select(outpuCols.map(colMap): _*)
  }

  def renameColumnsWithSameName(df: DataFrame): DataFrame = {
    val frame = df.select("*")

    val namedExpressions = frame.queryExecution.analyzed.asInstanceOf[Project].projectList

    val duplicateNames: Set[String] = namedExpressions.map(_.name).groupBy(identity).filter(_._2.size > 1).keys.toSet

    if (duplicateNames.isEmpty) df else {

      type NameCount = Map[String, Int]
      type Res = (NameCount, Seq[Column])

      val zero: Res = (Map.empty, Nil)

      val res = namedExpressions.foldLeft(zero)({
        case ((counts, cols), exp) =>
          if (duplicateNames(exp.name)) {
            val i = counts.getOrElse(exp.name, 0)
            val col = new Column(exp).as(exp.name + "_" + i)

            (counts + (exp.name -> (i + 1)), cols :+ col)
          } else {
            (counts, cols :+ new Column(exp))
          }
      })

      df.select(res._2: _*)
    }

  }


  test("toto") {

    import ss.implicits._

    val person = Person(id = "1", name = "toto", age = 13)

    val df1 = ss.createDataset(Seq(person))

    val df2 = df1

    val frame = df1.join(df2, df1("id") === df2("id"))

    frame.show()

    val plan = frame.select("*").queryExecution.analyzed

    //bug
    //frame.select("id","age","name")

    //work
    frame.select(df1("id"), df1("age"), df1("name")).show()


    //clean auto1
    coalesceColwithSameName(frame).show()

    //clean auto2
    renameColumnsWithSameName(frame).show()
  }

}

En finir avec les problèmes de case class dans Spark

2019-02-25T23:00:00Z

Dans un précédent article, nous avons vu qu'il est possible d'avoir des fonctions d'ordre supérieur avec des versions anciennes de Spark. Sauf que notre implémentation souffre d'un défaut que nous retrouvons assez souvent dès lors que nous commençons à mélanger case class et dataset. Voyons ensemble comment nous allons y remédier.

Nous allons créer un dataset représentant des familles. Pour cela, créons une case class représentant des personnes.

case class Person(name: String, age: Int)

Créons maintenant notre dataset.

val df =
  ss.createDataset(Seq(
      ("1", Seq(
        Person("John", 32),
        Person("Mary", 31)
      )),
      ("2", Seq(
        Person("Fred", 42),
        Person("Elsa", 40),
        Person("Daryll", 10)
      ))
  )).toDF("id", "family")

+---+--------------------------------------+
|id |family                                |
+---+--------------------------------------+
|1  |[[John, 32], [Mary, 31]]              |
|2  |[[Fred, 42], [Elsa, 40], [Daryll, 10]]|
+---+--------------------------------------+

Formalisons une requête qui ne conserve que les noms des personnes du dataset précédent. Pour cela nous allons utiliser l'une des fonctions d'ordre supérieur que nous avons vu dans l'article précédent sur le sujet.

import Implicits._

df.select(
  $"id",
  $"family".map((p: Person) => p.name).as("family")
)

Nous obtenons alors une exception.

Exception in thread "main" org.apache.spark.SparkException: Failed to execute user defined function($anonfun$4: (array<struct<name:string,age:int>>) => array<string>)
	at org.apache.spark.sql.catalyst.expressions.ScalaUDF.eval(ScalaUDF.scala:1066)
	at org.apache.spark.sql.catalyst.expressions.Alias.eval(namedExpressions.scala:151)
	at org.apache.spark.sql.catalyst.expressions.InterpretedProjection.apply(Projection.scala:50)
	...
Caused by: java.lang.ClassCastException: org.apache.spark.sql.catalyst.expressions.GenericRowWithSchema cannot be cast to xag.Person
	at Example$$anonfun$main$2.apply(TestMain.scala:33)
	at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:234)
	at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:234)
	...

L'exception d'origine indique : java.lang.ClassCastException: org.apache.spark.sql.catalyst.expressions.GenericRowWithSchema cannot be cast to Person. Catalyst est incapable de reconstituer l'entité Person à partir du résultat de la version sérialisée de cette entité contenue dans le dataset.

Pour résoudre cette exception, nous allons utiliser com.twitter.chill.Externalizer. Twitter Chill est une bibliothèque d'extension pour Kryo et Kryo est une bibliothèque de sérialisation Java utilisé par Spark. Externalizer permet de mettre en place une sorte de "boîte" pour sérialiser et désérialiser n'importe quel type, même non sérialisable au sens Java.

Nous allons aussi utiliser une opération permettant d'effectuer un "nettoyage" sur les données rencontrées, en récupérant notamment les types sous-jacent cachés derrière Any, monnaie courante avec Spark. Nous allons utiliser une approche (ou plutôt idiome) typeclass pour associer cette opération à l'ensemble des types utilisés dans les données (en attendant la nouvelle syntaxe sensée arriver avec Scala 3 !). Voici l'interface de cette opération.

// The typeclass with the operation to clean data for Spark
trait CleanFromRow[A] extends Serializable {
  def clean(a: Any): A
}

Ci-dessous, nous retrouvons la classe implicite avec l'opération map, que nous avons définie dans l'article précédent avec un léger refactoring : 1/ on s'assure que l'opération clean s'applique bien au type A donné en entrée, 2/ on s'assure que le "nettoyage" et la sérialisation seront réalisés (serializeAndClean). Le refactoring ne s'applique qu'à l'opération map, mais nous pouvons aussi l'appliquer sur les autres opérations : flatMap et foldLeft.

object Implicits2 {

  implicit class RicherColumn2(column: Column) {

    def map[A : CleanFromRow: TypeTag, B : TypeTag](f: A => B): Column = {
      val f0 = udf[Seq[B], Seq[A]](serializeAndClean(s => s.map(f)))

      f0(column)
    }

  }

  import com.twitter.chill.Externalizer

  private def serializeAndClean[A: CleanFromRow, B](f: Seq[A] => B): Seq[A] => B = {
    val cleaner: Externalizer[A => A] =
      Externalizer(implicitly[CleanFromRow[A]].clean _)
    val fExt: Externalizer[Seq[A] => B] =
      Externalizer(f)

    values =>
      if (values == null) {
        null.asInstanceOf[B]
      } else {
        val fExt0: Seq[A] => B = fExt.get
        val cleaner0: A => A = cleaner.get

        fExt0(values.map(cleaner0))
      }
  }

}

Le comportement de l'opération de "nettoyage" va dépendre du type rencontré. Nous définissons donc ci-dessous différentes instances du type CleanFromRow pour cela (Int, String, Seq...). Nous utilisons aussi Magnolia de Jon Pretty pour associer l'opération clean à des case class. L'avantage de Magnolia, c'est qu'il est récursif. Du coup, ça fonctionne aussi avec des structures imbriquées de différentes profondeurs.

object CleanFromRow {
  import magnolia._
  import scala.reflect.ClassTag
  import language.experimental.macros

  type Typeclass[T] = CleanFromRow[T]

  private def instance[A]: Typeclass[A] =
    new Typeclass[A] {
      override def clean(a: Any): A = a.asInstanceOf[A]
    }

  // Instances to associate clean operation to basic types
  implicit val double: Typeclass[Double] = instance
  implicit val boolean: Typeclass[Boolean] = instance
  implicit val strCFR: Typeclass[String] = instance
  implicit val intCFR: Typeclass[Int] = instance
  implicit val longCFR: Typeclass[Long] = instance
  // add other typeclass instances for basic types...

  // Instance for Option type
  implicit def opt[T: Typeclass: Manifest]: Typeclass[Option[T]] =
    new Typeclass[Option[T]] {
      // this helps to avoid type erasure warning
      private val rc = implicitly[Manifest[T]].runtimeClass

      override def clean(a: Any): Option[T] =
        a match {
          case ox: Option[_]
              if ox.forall(x => rc.isAssignableFrom(x.getClass)) =>
            ox.asInstanceOf[Option[T]]
          case null => None
          case x    => Option(implicitly[Typeclass[T]].clean(x))
        }
    }

  // Instance for Seq type
  implicit def seq[T:Typeclass:Manifest]: Typeclass[Seq[T]] = {
    new Typeclass[Seq[T]] {
      // this helps to avoid type erasure warning
      private val rc = implicitly[Manifest[T]].runtimeClass

      override def clean(a: Any): Seq[T] =
        a match {
          case Nil => Nil
          case xs: Seq[_]
              if xs.forall(x => rc.isAssignableFrom(x.getClass)) =>
            xs.asInstanceOf[Seq[T]]
          case x: Seq[_] => x.map(implicitly[Typeclass[T]].clean)
        }
    }
  }

  // Instance generator for case classes
  def combine[T: ClassTag](ctx: CaseClass[CleanFromRow, T]): Typeclass[T] =
    new Typeclass[T] {
      override def clean(a: Any): T =
        a match {
          case a: T => a
          case r: Row =>
            val values: Seq[Any] =
              r.toSeq
                .zip(ctx.parameters)
                .map {
                  case (rowValue, param) => param.typeclass.clean(rowValue)
                }
            ctx.rawConstruct(values)
        }
    }

  implicit def gen[T]: CleanFromRow[T] = macro Magnolia.gen[T]
}

Reprenons maintenant notre exemple précédent en remplaçant Implicits pour Implicits2.

import Implicits2._

df.select(
  $"id",
  $"family".map((p: Person) => p.name).as("family")
)

+---+--------------------+
|id |family              |
+---+--------------------+
|1  |[John, Mary]        |
|2  |[Fred, Elsa, Daryll]|
+---+--------------------+

C'est le résultat attendu !

Annexe

Suite de

Fonctions d'ordre supérieur dans Spark 2 pour traiter des structures imbriquées

package utils

import com.twitter.chill.MeatLocker
import org.apache.spark.sql.Row

import scala.reflect.ClassTag

trait CleanFromRow[A] extends Serializable {
  def clean(a: Any): A
}

object CleanFromRow {

  private def instance[A]: Typeclass[A] = new Typeclass[A] {
    override def clean(a: Any): A = a.asInstanceOf[A]
  }

  implicit val double:  Typeclass[Double]  = instance
  implicit val boolean: Typeclass[Boolean] = instance
  implicit val strCFR:  Typeclass[String]  = instance
  implicit val intCFR:  Typeclass[Int]     = instance
  implicit val longCFR: Typeclass[Long]    = instance

  implicit def opt[T: Typeclass: Manifest]: Typeclass[Option[T]] =
    new Typeclass[Option[T]] {
      override def clean(a: Any): Option[T] = {
        a match {
          case x: Option[T] => x
          case null => None
          case x    => Option(implicitly[Typeclass[T]].clean(x))
        }
      }
    }

  implicit def seq[T: Typeclass: Manifest]: Typeclass[Seq[T]] =
    new Typeclass[Seq[T]] {
      override def clean(a: Any): Seq[T] = a match {
        case x: Seq[T] => x
        case x: Seq[_] => x.map(implicitly[Typeclass[T]].clean)
      }
    }

  import magnolia._

  import language.experimental.macros

  type Typeclass[T] = CleanFromRow[T]

  def combine[T: ClassTag](ctx: CaseClass[CleanFromRow, T]): CleanFromRow[T] = {
    new CleanFromRow[T] {

      override def clean(a: Any): T = {
        a match {
          case a: T => a
          case r: Row =>
            val values: Seq[Any] =
              r.toSeq
                .zip(ctx.parameters)
                .map({
                  case (rowValue, param) => param.typeclass.clean(rowValue)
                })
            ctx.rawConstruct(values)

        }

      }
    }
  }

  implicit def gen[T]: CleanFromRow[T] = macro Magnolia.gen[T]
}

case class Tata(a:     String, b: Int)
case class Toto(tatas: Seq[Tata])

object UnnestedSpark {

  def tataToX(seq: Seq[Tata]): String = {
    seq.map(_.a).headOption.getOrElse("")
  }

  def cleanF[A: CleanFromRow, B](f: Seq[A] => B): Seq[A] => B = {
    val g: MeatLocker[A => A] =
      com.twitter.chill.MeatLocker(implicitly[CleanFromRow[A]].clean _)
    val mf: MeatLocker[Seq[A] => B] = com.twitter.chill.MeatLocker(f)

    a =>
      {

        if (a == null) {
          null.asInstanceOf[B]
        } else {
          val f0: Seq[A] => B = mf.get
          val g0: A      => A = g.get
          f0(a.map(g0))
        }
      }

  }

  /*def main(args: Array[String]): Unit = {

    val ss = TestSparkSession.create()

    import ss.implicits._

    val df = ss.createDataset(Seq(Toto(Seq(Tata("a", 1))))).toDF()

    import org.apache.spark.sql.functions._

    ss.udf.register("tataToX", cleanF(tataToX))

    df.select(expr("tataToX(tatas)")).show(false)

  }*/

}

ss.udf.register("dmConfToX", cleanF(niveauPack))


def niveauPack(confs: Seq[DmConfiguration]): String = {
    confs.flatMap(_.niveauPack).mkString(", ")
  }

trait Typeclass[T] {
  def clean(a: Any): T
}

object Typeclass {
  implicit def seq[T:Typeclass:Manifest]: Typeclass[Seq[T]] = {
    new Typeclass[Seq[T]] {
      private val rc = implicitly[Manifest[T]].runtimeClass
      override def clean(a: Any): Seq[T] =
        a match {
          case Nil => Nil
          case xs: Seq[_]
              if xs.forall(x => rc.isAssignableFrom(x.getClass)) =>
            xs.asInstanceOf[Seq[T]]
          case x: Seq[_] => x.map(implicitly[Typeclass[T]].clean)
        }
    }
  }

  implicit def opt[T: Typeclass: Manifest]: Typeclass[Option[T]] =
    new Typeclass[Option[T]] {
      private val rc = implicitly[Manifest[T]].runtimeClass
      override def clean(a: Any): Option[T] =
        a match {
          case ox: Option[_]
              if ox.forall(x => rc.isAssignableFrom(x.getClass)) =>
            ox.asInstanceOf[Option[T]]
          case null => None
          case x    => Option(implicitly[Typeclass[T]].clean(x))
        }
    }
}

PKIX path building failed: unable to find valid certification path to requested target... À tes souhaits !

2019-02-20T23:00:00Z

TLS (Transport Layer Security), plus souvent dénommé SSL (Secured Sockets Layer - son prédécesseur déprécié), est l'un des protocoles les plus utilisés sur le Web pour sécuriser les sites et les applications qui le peuplent. TLS repose à la fois sur des algorithmes de cryptographie asymétrique (clé publique et clé privée) et une relation de confiance avec des autorités reconnues à travers le monde, en se basant sur un système de certificats sécurisés.

Cependant, ce modèle ne fonctionne pas lorsque vous êtes enfermé derrière le proxy d'une entreprise, qui ne souhaite pas (à raison ?) que les applications qu'elle développe se mettent à transmettre (par erreur, dans le meilleur des cas !) des informations confidentielles ou qu'elles soient des portes ouvertes pour la plus grande joie des mauvaises intentions du Net 😱

Néanmoins, à l'intérieur de cette entreprise, comme il est nécessaire de sécuriser la communication sur le réseau, il faut passer par TLS. Mais cette fois, l'entreprise va se déclarer elle-même autorité de certificat, en exposant en interne un certificat dit "auto-signé". C'est là que les ennuis commencent !

1/ Vous lancez Maven ou SBT... Et boom ! ça crashe, parce que ça ne passe pas le pare-feu. On vous dit alors de passer par un proxy Maven (Nexus ou Artifactory).

2/ Vous configurez vos outils. Vous retentez... Et boom ! Vous avez une exception à peine compréhensible qui parle de certification, de Sun et de PKIX. On vous dit alors qu'il y a un vague JDK, qui a été correctement configuré avec tous les certificats et qui traine quelque part sur le réseau interne.

3/ Vous récupérez et installez ce JDK. Vous retentez... Et boom ! Vous obtenez la même erreur que la dernière fois. À ce moment là, vous commencez à avoir du mal à faire la distinction entre TLS et la magie. Et vous êtes sur le point de friser la folie 🤯

Reproduction du cas

Commençons par générer un certificat auto-signé que nous allons placer dans un keystore, nommé ici selfsigned.jks.

$ keytool -genkey \
    -alias selfsigned -keyalg RSA \
    -keypass changeit -storepass changeit \
    -keystore tmp/certificate/selfsigned.jks

What is your first and last name?
  [Unknown]:  François Sarradin
What is the name of your organizational unit?
  [Unknown]:
What is the name of your organization?
  [Unknown]:  Univalence
What is the name of your City or Locality?
  [Unknown]:  Paris
What is the name of your State or Province?
  [Unknown]:
What is the two-letter country code for this unit?
  [Unknown]:  fr
Is
  CN=François Sarradin, OU=Unknown, O=Univalence, L=Paris, ST=Unknown, C=fr
correct?
  [no]:  yes

Nous allons utiliser ce keystore pour monter un faux service Web sécurisé. Pour cela nous créons d'abord un contexte SSL, à travers une fonction qui prend en paramètres le chemin vers ce keystore ainsi que le mot de passe associé.

import java.io.FileInputStream
import java.security.KeyStore
import javax.net.ssl.{KeyManagerFactory, SSLContext, TrustManagerFactory}

def createSSLContext(keystorePath: String, password: String): SSLContext = {
    val keyStore = KeyStore.getInstance("JKS")
    keyStore.load(new FileInputStream(keystorePath), password.toCharArray)

    val keyManagerFactory = KeyManagerFactory.getInstance("SunX509")
    keyManagerFactory.init(keyStore, password.toCharArray)
    val keyManagers = keyManagerFactory.getKeyManagers

    val trustManagerFactory = TrustManagerFactory.getInstance("SunX509")
    trustManagerFactory.init(keyStore)
    val trustManagers = trustManagerFactory.getTrustManagers

    val sslContext = SSLContext.getInstance("TLS")
    sslContext.init(keyManagers, trustManagers, null)

    sslContext
  }

Il faut ensuite créer une configuration pour le service Web avec ce contexte.

import com.sun.net.httpserver._

    val httpsConfigurator =
      new HttpsConfigurator(sslContext) { self =>
        override def configure(params: HttpsParameters): Unit = {
          val c = self.getSSLContext
          val engine = c.createSSLEngine
          params.setNeedClientAuth(false)
          params.setCipherSuites(engine.getEnabledCipherSuites)
          params.setProtocols(engine.getEnabledProtocols)
          params.setSSLParameters(c.getDefaultSSLParameters)
        }
      }

Et on lance le service.

import com.sun.net.httpserver._
import java.net.InetSocketAddress

    val server = HttpsServer.create(new InetSocketAddress("0.0.0.0", 9443), 0)
    server.setHttpsConfigurator(httpsConfigurator)
    server.createContext("/", (exchange: HttpExchange) => {
      val content = "Hello"
      val length = content.length
      val raw = content.getBytes

      exchange.sendResponseHeaders(200, length)
      exchange.getResponseBody.write(raw)

      exchange.close()
    })
    server.start()

On va maintenant se créer un client Web.

import java.net.URL

object Main {
  def main(args: Array[String]): Unit = {
    val result = new URL("https://127.0.0.1:9443/").getContent()

    println(result)
  }
}

En lançant le service Web, puis le client, nous obtenons alors l'exception ci-dessous.

Exception in thread "main" javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
	at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259)
	at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1329)
	at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(CertificateMessage.java:1204)
	at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(CertificateMessage.java:1151)
	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
	at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)
	at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178)
	at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
	at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
	at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
	at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
	at java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:567)
	at java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1581)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509)
	at java.base/java.net.URLConnection.getContent(URLConnection.java:749)
	at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getContent(HttpsURLConnectionImpl.java:425)
	at java.base/java.net.URL.getContent(URL.java:1131)
	at io.univalence.test_ssl.Main$.main(Main.scala:7)
	at io.univalence.test_ssl.Main.main(Main.scala)
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:385)
	at java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:290)
	at java.base/sun.security.validator.Validator.validate(Validator.java:264)
	at java.base/sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:321)
	at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:221)
	at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129)
	at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1313)
	... 19 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
	at java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
	at java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
	at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:380)
	... 25 more

Analyse

Voici le message :

Exception in thread "main" javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

L'exception est de type javax.net.ssl.SSLHandshakeException. En effet, elle intervient lors de la période de négociation avec le service Web. C'est à ce moment que sont convenus le protocole utilisé, sa version, l'algorithme de cryptographie utilisé... C'est aussi à ce moment que le service transmet son certificat, permettant ainsi au client d'effectuer les vérifications qui lui semblent nécessaires.

Les certificats utilisés ici sont des certificats à clé publique basé sur la norme X.509. Cette norme repose sur un algorithme permettant de vérifier qu'un certificat est lié à une autorité de certification et "signé" par celle-ci en utilisant sa clé privée. Or, dans notre cas, le certificat envoyé par notre service Web ne repose sur aucune autorité de certification. De plus, le site du service n'est pas reconnu comme autorité de certification par le client Web.

Les certificats reconnus sont stockés dans un keystore. Dès qu'une connexion TLS est mise en place, à travers la classe sun.security.ssl.TrustStoreManager.TrustStoreDescriptor (en Java 11), Java va d'abord rechercher le fichier keystore à travers la propriété javax.net.ssl.trustStore, si elle a été définie. Sinon, Java va vérifier que le fichier $JAVA_HOME/lib/security/jssecacerts existe et de même avec le fichier $JAVA_HOME/lib/security/cacerts. Normalement, ce dernier existe et contient les certificats des autorités reconnues. jssecacerts sert pour des besoins en développement et permet de ne pas "polluer" cacerts.

Ainsi, pour faire fonctionner notre connexion TLS avec notre service Web, nous allons devoir récupérer le certificat de ce service et l'ajouter à l'un des keystores principaux.

Résolution

Si vous avez OpenSSL de disponible, la commande suivante permet de récupérer le certificat associé à notre service Web (vous pouvez d'ailleurs tenter la commande avec google.com:443).

echo -n \
    | openssl s_client -connect 127.0.0.1:9443 \
    | openssl x509 -outform PEM \
    > selfsigned_certificate.pem

Sinon, passez par votre navigateur. Il faut vous rendre sur le site du service et afficher les informations de la page visitée. Si votre navigateur vous le permet, vous pourrez télécharger/exporter le certificat associé.

Importez alors le certificat dans le keystore Java.

$JAVA_HOME/bin/keytool -import \
    -alias selfsigned -file selfsigned_certificate.pem \
    -keystore $JAVA_HOME/lib/security/jssecacerts

Vérifiez que l'import s'est bien passé.

$JAVA_HOME/bin/keytool -list -v \
    -alias selfsigned \
    -keystore $JAVA_HOME/lib/security/jssecacerts

Le certificat du service Web devrait s'afficher.

Pour le JDK8, il vous faudra utiliser $JAVA_HOME/jre/lib/security (attention au jre) comme chemin vers les fichiers keystore gérés par Java. Il existe aussi une procédure dédiée à IntelliJ IDEA décrite sur le site support.

cause-toujours : who can it be now?

2019-02-11T23:00:00Z

Savez-vous ce que vous avez en production ? Lorsque votre application transmet un log, savez-vous depuis quel fichier source provient-il et surtout à quel commit est-il rattaché ?... Si toutefois, vous avez bien pensé à intégrer sous Git les dernières modifications...

Savoir d'où provient un appel dans le code est une nécessité. Savoir à quel commit est rattaché la ligne de code qui a déclenché l'appel est aussi une nécessité. D'une manière générale, plus il y aura d'informations fournies sur le contexte de production d'une ligne de code, plus il sera aisé de comprendre l'intention autour du déclenchement d'un appel et accessoirement de déboguer une application.

Nous sommes en 2019... Malgré ça, nous allons continuer à voir des "patchs" fait main et non versionnés, passer hors des contrôles des serveurs d'intégration continu, pour aller se loger bien au chaud dans vos serveurs de production ou ceux de vos clients 🐛.

L'idée derrière notre projet cause-toujours est de fournir ces informations autour du lieu d'appel (call site en anglais) et de fournir ce contexte manquant lorsqu'un soucis est remonté dans vos équipes.

cause-toujours se base d'abord sur une structure de donnée permettant de conserver un ensemble de méta-données sur le site d'appel. Cette structure est nommée CallSiteInfo.

case class CallSiteInfo(
    enclosingClass: String, // name of the enclosing unit
    file: String, // file for the callsite (relative to the git repo root)
    line: Int, // line number in file
    commit: String, // id of the commit
    buildAt: Long, // time you build at
    status: String, // one of "clean", "modified", "untracked"
    fingerprint: String, // file content hash
    fileContent: Option[String] = None // if the build file is different
)

Des types primitifs sont utilisés ici afin d'assurer la sérialisation de la structure et de faciliter son interprétation par des applications basées sur d'autres langages.

La récupération de ces informations se fait au moment de la compilation du code source. Scala propose en effet un système de macro syntaxique pour ça. Une macro Scala est un morceau de code qui intervient au moment de la compilation, lorsque l'arbre syntaxique (AST - Abstract Syntax Tree) a été formé. Cette macro va permettre d'effectuer des transformations dans l'AST. C'est un peu comme de la génération de code, mais dans laquelle la syntaxe du langage est forcément respectée.

La déclaration d'une macro se fait en utilisant le mot-clé correspondant.

import language.experimental.macros

implicit def callSiteInfo: CallSiteInfo = macro CallSiteMacro.callSiteImpl

Ainsi, à chaque fois que callSiteInfo apparaît dans le code, le compilateur donne la main à la fonction CallSiteMacro.callSiteImpl. Les macros dans Scala restent une fonctionnalité expérimentale. Comme expliqué lors d'un précédent article, dont le sort devrait être fixé avec Scala 3, qui devrait sortir en 2020.

import scala.reflect.macros.blackbox

def callSiteImpl(c: blackbox.Context): c.Expr[CallSiteInfo] = {
  import c._
  import universe._

  // ...

  c.Expr[CallSiteInfo](
    q"""callsite.CallSiteInfo(
  enclosingClass = ${owner.fullName},
  file           = ${pathToRepoRoot(sourceFile)},
  ...
  )""")
}

Le paramètre de type blackbox.Context correspond au contexte au niveau de l'AST dans lequel est appelé la macro. Blackbox signifie ici que la macro agira dans un contexte dans lequel toute résolution de type est complète. La macro retourne une expression de type CallSiteInfo, qui est formalisée par les dernières lignes de la macro en utilisant une quasiquote. Une quasiquote se présente comme une chaîne de caractères contenant du code Scala. Ce code est ensuite converti en AST et intégré dans l'AST de votre application. C'est ainsi qu'il est possible de récupérer la date de compilation du code. À partir de l'API scala.reflect, il est possible d'obtenir le fichier, le numéro de ligne ou le code source dans lequel se fait le site d'appel. Et en utilisant JGit (org.eclipse.jgit), il est aussi possible de récupérer le commit ID ou d'indiquer si le fichier est dans une version conservé sous Git.

On peut ainsi imaginer écrire une fonction de log de la manière suivante :

def log(message: String)(implicit cs: callsite.CallSiteInfo): Unit = {
  println(s"[${cs.commit.take(7)} - ${cs.file}:${cs.line} @${cs.date}] $message")
  cs.fileContent.foreach(println)
}

Il n'y a pas besoin d'importer callsite.CallSiteInfo. Et comme le paramètre cs est implicite, il n'y a pas besoin de le renseigner lors de l'appel à log. Voici un exemple d'utilisation :

import /*...*/.log

object MyMain {
  def main(args: Array[String]): Unit = {
    println("Hello printed")
    log("Hello logged")
  }
}

Si ce code est stocké dans un fichier appelé MyMain.scala et que ce fichier n'a pas été modifié depuis le dernier commit Git, on aura alors l'affichage suivant :

Hello printed
[b834c88 - MyMain.scala:6 @946684800] Hello logged

cause-toujours est utilisé dans le cadre de notre projet Zoom. Zoom permet de centraliser, de réorganiser et de redistribuer des flux de données dans un SI. Ce qui inclut aussi les flux de logs.

cause-toujours est un outil dédié à du code Scala. Une implémentation dans d'autres langages est possible dès lors que ce langage propose un système de macro ou d'injection de code à la compilation et que celui-ci permet de récupérer divers informations au compile time.

cause-toujours est open source. Il est disponible sur GitHub et sur Maven Central.

GitHub : https://github.com/UNIVALENCE/cause-toujours

Maven : https://mvnrepository.com/artifact/io.univalence/cause-toujours

Lancer un job Spark dans un cluster Kubernetes en local

2019-02-06T23:00:00Z

Nous en avons déjà parlé, dans les dernières versions de Spark, Kubernetes peut être utilisé comme un orchestrateur à la place de Yarn ou de Mesos. Kubernetes utilise les images docker, ce qui permet de livrer des conteneurs Docker à la place du traditionnel jar ou paquet natif contenant le job Spark. Aussi le déploiement sur Kubernetes permet d'utiliser les ressources dédiées à Kubernetes, ce qui maximise l'utilisation de ces ressources en limitant la fragmentation entre plusieurs clusters, avec un cluster pour le Big Data, un autre pour le deep learning, ou un autre pour servir les API.

Faire tourner un job Spark sur Kubernetes est aussi un bon moyen d'en apprendre plus sur le fonctionnement de Kubernetes en tant qu'orchestrateur de conteneurs.

La documentation sur le site de Spark introduit en détails le sujet. Je vous propose d'ajouter ici des éléments en complémentaire.

~~Je vous propose de suivre ici~~ ~~le tutoriel~~ ~~proposé sur le site de Spark et d'ajouter des commentaires pertinents au guide déjà existant.~~

En pratique

Toutes les manipulations ont été réalisées sous Ubuntu 18.04.

En se basant sur la documentation fournie par Spark, ainsi que le Dockerfile fourni depuis Spark 2.3, nous allons voir comment lancer un job Spark à l'aide de Kubernetes (et de Docker).

Nous aurons ainsi besoin de :

Spark https://spark.apache.org/downloads.html (pris en version 2.4 ici).
Le code source de Spark https://github.com/apache/spark/releases (toujours en version 2.4.0).
Docker CE (Community Edition) https://docs.d ocker.com/install/linux/docker-ce/ubuntu/ (testé avec docker version 18.09.1).
Java 8 à minima (testé avec le JDK d'Oracle https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html).
kubectl https://kubernetes.io/docs/tasks/tools/install-kubectl/,
minikube https://kubernetes.io/docs/tasks/tools/install-minikube/.
VirtualBox 6.0 https://www.virtualbox.org/wiki/Linux_Downloads.

Après avoir installé tout ce qu'il vous faut, il faut ensuite builder Spark avec Maven en lançant cette commande depuis le dossier contenant le code source de Spark :

./build/mvn -Pkubernetes -DskipTests clean package

Il faut aussi construire l'image Docker depuis Spark avec la commande suivante :

docker build -t spark:latest -f kubernetes/dockerfiles/spark/Dockerfile .

Vous pouvez maintenant lancer un cluster Kubernetes local grâce à minikube :

minikube start --cpus 3 --memory 4096

Il s'agit maintenant de construire l'image Docker de Spark dans le contexte de Kubernetes. En effet, pour pouvoir lancer des images Docker depuis votre cluster Kubernetes local, il est nécessaire de faire ces manipulations suivantes (placez vous à la racine du dossier contenant la distribution de Spark) :

eval $(minikube docker-env)
docker build -t spark:latest -f kubernetes/dockerfiles/spark/Dockerfile .

Récupérez ensuite l'adresse et le port de votre cluster avec :

kubectl cluster-info

Vous pourrez ensuite lancer un job Spark en mode cluster (en remplaçant hostname par l'adresse IP du cluster et port par le port du cluster) en lançant cette commande depuis la racine du dossier contenant Spark (et non pas le dossier contenant le code source de Spark) :

bin/spark-submit \
    --master k8s://https://<hostname>:<port> \
    --deploy-mode cluster \
    --name spark-pi \
    --class org.apache.spark.examples.SparkPi \
    --conf spark.executor.instances=5 \
    --conf spark.kubernetes.container.image=spark:latest \
    local:///path/to/examples.jar

Monitoring & logs

Conclusion

Le guide proposé sur le site de Spark est assez bien expliqué. Mais il passe assez vite sur certains points et ne mentionne pas par exemple le fait qu'il faille aussi builder Spark à partir du code source ou bien qu'il faille créer l'image Docker dans le contexte de Kubernetes.

Fonctions d'ordre supérieur dans Spark 2 pour traiter des structures imbriquées

2019-02-04T23:00:00Z

Nous l'avons annoncé dans un précédent article : Spark 2.4 est arrivé avec tout un lot de fonctions d'ordre supérieur (HOF - Higher Order Function) permettant de manipuler des structures imbriquées (en se limitant aux collections) dans les dataframes. Ce qui est bien pratique pour ce type de colonne, ce qui permet aussi de mieux les appréhender. Néanmoins, cette fonctionnalité est cantonnée à Spark 2.4+ et accessible uniquement dans les requêtes Spark SQL. Or actuellement, bien des datalakes n'ont pas encore migré en version 2.4 et les fournisseurs Hadoop on prem et cloud sont pour le moment limités à la version 2.3. Alors, comment faire ?

L'idée va être d'ajouter de nouvelles opérations au type Column utilisant des UDF (User Defined Function). Nous définissons ci-dessous les fonctions map, flatMap et foldLeft.

import org.apache.spark.sql.Column
import org.apache.spark.sql.functions.udf
import scala.reflect.runtime.universe._

object Implicits {
  
  implicit class RicherColumn(column: Column) {

    /** Transform each element of an array by applying the function g.
      */
    def map[A: TypeTag, B: TypeTag](g: A => B): Column = {
      val f = udf[Seq[B], Seq[A]](s => s.map(g))

      f(column)
    }

    /** Transform each element of an array by applying the function g
      * and using the elements of the resulting array.
      */
    def flatMap[A: TypeTag, B: TypeTag](g: A => Seq[B]): Column = {
      val f = udf[Seq[B], Seq[A]](s => s.flatMap(g))

      f(column)
    }

    /** Aggregate an array to a single value.
      */
    def foldLeft[A: TypeTag, B: TypeTag](init: B)(g: (B, A) => B): Column = {
      val f = udf[B, Seq[A]](s => s.foldLeft(init)(g))

      f(column)
    }
    
  }

}

Voyons à présent comment utiliser ces fonctions. Nous allons pour cela utiliser le dataset ci-dessous.

val df =
  Seq(
    ("abc", Seq("Hello world"),                   Seq(0L, 2L)),
    ("def", Seq("Wild Horses", "Paint It Black"), Seq(1L, 2L))
  ).toDF(
     "id",  "text",                               "timestamps"
  )

+---+-----------------------------+----------+
|id |text                         |timestamps|
+---+-----------------------------+----------+
|abc|[Hello world]                |[0, 2]    |
|def|[Wild Horses, Paint It Black]|[1, 2]    |
+---+-----------------------------+----------+

Utilisons à présent nos fonctions afin de réaliser quelques transformations sur nos données.

import Implicits._

val result =
  df.select(
    $"id",
    // multiply each timestamp by 2
    $"timestamps"
      .map((t: Long) => t * 2)
      .as("map"),
    // get the words in the arrays
    $"text"
      .flatMap((t: String) => t.split(" ").toSeq)
      .as("flatMap"),
    // compute the sum of timestamps
    $"timestamps"
      .foldLeft[Long, Long](0)(_ + _)
      .as("foldLeft")
  )

Ce qui donne :

+---+------+--------------------------------+--------+
|id |map   |flatMap                         |foldLeft|
+---+------+--------------------------------+--------+
|abc|[0, 4]|[Hello, world]                  |2       |
|def|[2, 4]|[Wild, Horses, Paint, It, Black]|3       |
+---+------+--------------------------------+--------+

À titre de comparaison, essayons d'obtenir un résultat équivalent avec Spark 2.4.

SELECT
  id,
  transform(timestamps, t -> t * 2) as transform,
  flatten(transform(text, t -> split(t, " "))) as flatten_transform,
  aggregate(timestamps, bigint(0), (s, v) -> s + v) as aggregate
FROM data

Ce qui donne :

+---+---------+--------------------------------+---------+
|id |transform|flatten_transform               |aggregate|
+---+---------+--------------------------------+---------+
|abc|[0, 4]   |[Hello, world]                  |2        |
|def|[2, 4]   |[Wild, Horses, Paint, It, Black]|3        |
+---+---------+--------------------------------+---------+

En dehors du changement de nom entre nos fonctions et la version 2.4 de Spark 😉 (map et transform, foldLeft et aggregate), nous pouvons remarquer qu'il n'y a pas de fonction équivalente à flatMap. Nous devons pour le coup utiliser une composition entre flatten et transform. Ceci dit, nous avons bien un résultat identique.

Nous avons vu ici quelques fonctions d'ordre supérieur sur dataframe pour les impatients 😉. Comprenez bien sûr que le lot présenté ici peut être complété (filter, take, zip, traverse). Comme il s'agit d'UDF, il n'y a pas d'optimisation possible. Néanmoins, l'avantage de ces fonctions est qu'elles peuvent être utilisées directement dans le code Scala.

Transition C#.Net vers Scala : un sentier abrupt néanmoins franchissable

2019-01-30T23:00:00Z

Après un peu plus de 3 ans d'expérience dans l'environnement .Net, principalement en tant que software engineer C#, j'ai rejoint Univalence en tant que data engineer pour cette fois-ci travailler avec le langage Scala. Scala est un langage que je n'avais jamais manipulé auparavant et dont je ne connaissais pas grand chose.

Je suis donc parti du monde du langage impératif, où je travaillais sur le back-end et le front-end des projets, pour pénétrer le monde du langage fonctionnel afin de manipuler des données. Il me fallait donc une période de transition pour m'adapter à ce tout nouveau langage pour moi, ainsi qu'à son écosystème. C'est cette expérience que je vais traiter dans cet article où je donnerai mes ressentis, les difficultés auxquelles j'ai fait face et comment je les ai surmontées.

Les difficultés rencontrées

1re difficulté : la syntaxe Scala en elle-même !

La syntaxe, aux premiers abords, peut paraître vraiment étrange !

Par exemple : le type se met à la fin de la déclaration de la variable.

En C# :

int i = 10;

En Scala :

val i: Int = 10
// ou
val j = 10

Ici c'est une question d'habitude. On aurait potentiellement le même ressenti en passant à un autre langage que Scala. Mais, c'est vrai que quand on vient du C#, de C, ou de Java, on comprendra plus facilement des écritures comme l'exemple en C#.

Mais en Scala le langage est fortement "sucré". Ce que je veux dire par là, c'est qu'il existe beaucoup de sucres syntaxiques. C'est-à-dire des syntaxes alternatives, plus simples et plus concises, mais qu'il faut apprendre et connaître.

Exemple :

// si on veut multiplier les entiers entre 1 et 10, on peut l'écrire comme ça
(1 to 10).fold(0)(_ * _)
// ou comme ça
(1 to 10).fold(0)((s, v) => s * v)
// ou comme ça
(1 to 10).fold(0) { case (s, v) => s * v }
// ou tout simplement
(1 to 10).product

Par contre, on retrouve les expressions lambda en Scala, ce qui est un avantage quand on en a déjà fait en C#.

De la programmation impérative vers la programmation fonctionnelle

La plus grande difficulté de cette transition est le passage vers la programmation fonctionnelle. En effet, lors de l'apprentissage du langage, on y est confronté rapidement. Il faut presque complètement changer sa façon de penser le code, comme par exemple essayer d'éliminer au maximum les composantes mutables du code (on ne réaffecte plus les variables préalablement déclarées).

Quand on va un peu plus loin en Scala et en programmation fonctionnelle, on rentre beaucoup dans des notions de mathématiques et l'algorithmie y est plus poussée. J'ai trouvé cela assez amusant de voir que certaines notions apprises en mathématiques lors de mes études étaient utilisées en programmation fonctionnelle, alors que lorsque j'étais dans mon ancien poste je ne m'étais jamais dit que j'allais réutiliser ces notions un jour.

L'écosystème

Quand je parle d'écosystème, je parle des outils autour du langage, des bonnes pratiques, etc. En .Net, l'IDE utilisé est Visual Studio, où le plus souvent nous utilisons les mêmes plugins, librairies et la gestion de code source se fait en général avec Team Foundation Server, intégré à Visual Studio dans les dernières versions. Quant à la documentation, elle est très fournie et on y trouve toujours des exemples. Là où je veux en venir, c'est qu'en .Net nous avons quasiment tout au même endroit et il existe beaucoup de standards. Alors qu'en commençant à me mettre à Scala, nous avons plus de choix, déjà pour l'IDE, où on peut utiliser IntelliJ, Eclipse, Visual Studio Code ou même un simple éditeur de texte !

C'est bien là, un autre facteur de difficulté, qui vaut aussi un certain temps d'adaptation. Il a fallu que je m'adapte à :

Git. Car en venant de .Net, il est tout à fait possible de n'avoir jamais fait de Git. J'utilisais surtout Team Foundation Server et dans les projets sur lesquels j'ai été, nous étions sur une base de lock/unlock (lock pessimiste), il y avait aussi moins d'histoire de conflit de merge.
Aux raccourcis d'IntelliJ (l'IDE avec lequel j'ai appris Scala), ce qui implique une réadaptation de mes réflexes.
Chercher des librairies. Là où certaines fonctionnalités existaient peut être déjà en .Net, elles n'existent pas forcément en Scala/Java, ou il n'existe pas de librairies dites standards. En .Net, on pouvait les chercher et les obtenir directement dans Visual Studio avec NuGet, alors que maintenant nous irions plutôt sur Maven Central et chercher la bonne version d'une librairie pour la mettre dans notre build.sbt.
La documentation. en .Net, elle très fournie et détaillé avec des exemples. Mais nous n'avons pas souvent accès au code source. Alors qu'en Scala, nous avons aussi une documentation, mais pas avec autant d'exemple. Il faut parfois explorer le code. Néanmoins, l'avantage c'est que nous pouvons souvent voir ce code source pour comprendre mieux.
Au contexte du data engineering. Avec mon ancien poste je développais surtout des clients lourds/légers (donc qui avait une interface graphique ou seulement une console), une couche d'accès aux données et une couche d'abstraction entre les deux. Autrement dit des applications répondant aux design pattern MVVM ou MVC. Maintenant en Scala, je fais des outils sans suivre ces design pattern et surtout sans DAO.

Pour ces difficultés, ce n'était qu'une question d'habitude. Ce que je conseille pour tous ceux qui veulent se lancer dans Scala et la programmation fonctionnelle, c'est de faire ce cours en ligne sur Coursera donné par Martin Odersky, le créateur du langage.

Si vous avez cette chance de travailler avec des personnes confirmées en Scala, ce qui est mon cas au sein d'Univalence, le pair programming m'a permis de progresser énormément. Avoir des exercices réguliers, a aussi été un bon moyen de progression.

Le ressenti après 6 mois

Au bout de maintenant 6 mois à utiliser Scala, je me sens plus à l'aise par rapport à ce qui a été dit précédemment. Je me suis surpris à utiliser des opérations comme map ou flatMap de moi-même, et surtout à réussir à obtenir le résultat voulu à partir de ces opérations. La pente à gravir est assez difficile quand on vient du monde impératif. Et je pense d'autant plus quand on ne vient pas de Java. Mais c'est toujours surmontable. En tout cas, je comprends mieux les avantages de la programmation fonctionnelle.

Lors de cette montée en compétence, j'ai eu la chance d'être mentorés par nos experts. J'ai pu participer à Scala IO 2018 dont nous avons fait un retour ici. J'ai en tout cas remarqué que la communauté Scala est très humble et que mêmes les grands noms sont "accessibles". Cela a en tout cas été un facteur motivant pour en apprendre plus.

Formattage du code en Scala

2019-01-28T23:00:00Z

Il est important dans un projet de conserver une bonne maîtrise de votre base de code. C'est en tout cas un prérequis pour faciliter la mise en place de nouvelles fonctionnalités dans une application, mais aussi la correction de bugs, le refactoring et enfin de faciliter la transmission de connaissance dans un projet. Un code bien maîtrisé nécessite un code lisible au moins par l'équipe de développement. Outre le fait que les classes, les fonctions et les variables soient bien nommées, qu'il y ait une séparation nette entre aspects techniques et aspects métiers, que le code soit correctement documenté, la façon de formater ce code participe à sa propre lisibilité.

Avec Scala, il existe différents outils permettant de formater automatiquement votre code source. Les IDE et la plupart des éditeurs de code proposent généralement une fonctionnalité de formatage. Le problème dans ce cas est de partager la configuration avec l'équipe. Ce qui vous force à vous restreindre qu'à un seul type d'éditeur et même à avoir les fichiers de configuration de l'éditeur intégré dans votre gestionnaire de version. Ainsi, votre projet se retrouve en dépendance avec l'éditeur de code ! Il vaut mieux éviter cette perspective 🧐. Sinon, il existe dans l'écosystème Scala deux outils reconnus. Il y a Scalariform et son plugin SBT, ainsi que Scalafmt qui a aussi un plugin SBT.

J'ai personnellement une préférence pour Scalafmt. Cet outil propose de décrire la configuration du formatage dans un fichier séparé, nommé .scalafmt.conf. Il est compatible avec Dotty, représentant le futur de Scala. Il possède une documentation assez bien fournie (l'équipe Scalafmt indique toutefois qu'elle n'est pas exhaustive et qu'il faut parfois fouiller dans le code de l'outil 🤓 !) Il y a aussi un plugin disponible pour IntelliJ IDEA, qui se base sur le fichier .scalafmt.conf. Enfin, Scalafmt est aussi intégré dans Metals : un "serveur de langage" assurant une intégration avancées de Scala avec éditeurs de texte sophistiqués comme Atom, VSC, Vim et Emacs.

L'intégration de Scalafmt dans les projet basé sur SBT nécessite de déclarer le plugin associé dans le fichier plugins.sbt :

addSbtPlugin("com.geirsson" % "sbt-scalafmt" % "1.5.1")

Pour que le formatage soit fait avant chaque compilation, il faut ajouter la ligne suivante dans build.sbt :

scalafmtOnCompile in ThisBuild := true

L'équipe Scalafmt déconseille cette fonctionnalité, sans forcément donner plus d'explications. Néanmoins, le formatage du code est une étape qui est coûteuse en temps sur les gros projets. De plus, lors de cette étape, vous pouvez toujours éditer le code source. Vous vous retrouvez alors avec des cas de conflits entre le reformatage fait par Scalafmt et vos modifications. Enfin, vous pouvez avoir des conflits en cas d'import de code par Git (pull, rebase, pull). Ceci dit, avec un IDE comme IntelliJ IDEA et cette option activée, vous pouvez avoir un code régulièrement reformaté sans trop de désagrément — à ce propos, il est recommandé dans sa configuration d’utiliser le formateur d'IntelliJ.

Pour avoir un formatage intéressant, vous pouvez commencer par deux lignes de configuration dans .scalafmt.conf :

align = most
maxColumn = 120

À noter que s'il est parfois considéré comme mal venu de limiter la taille des lignes dans le code, il reste néanmoins plus confortable d'avoir un code pas trop large en règle générale.

La partie alignement est l'une des fonctionnalités sur laquelle il peut y avoir le plus de discussions. La configuration align peut avoir comme valeur none, some ou default, more, most, selon le degré d'alignement que vous souhaitez dans votre code. Les valeurs none, default et some sont celles qui limiteront les surprises lors du reformatage du code et aussi les conflits dans Git. Dans la mesure où le reformatage du code est automatisé au sein de l'équipe de développement et exécuté très régulièrement (avant chaque compilation, avant chaque sauvegarde du fichier, avant chaque push sur un repo central...), vous pouvez envisager les valeurs more et most.

Scalafmt propose plusieurs options pour paramétrer l'alignement des différentes parties de votre code, l'ajout d'espaces, de sauts de ligne et d'autres règles de réécriture. Il permet de mettre en place des règles spécifiques par rapport à des symboles et même par rapport à des symboles dans des contextes particuliers au niveau de l'AST. L'exemple ci-dessous permet de réaliser un alignement par rapport au symbole => uniquement dans le cadre d'un pattern matching avec case et non dans le cadre d'une fonction.

align.tokens = [{code = "=>", owner = "Case"}]

Il est possible aussi d'activer ou de désactiver Scalafmt selon certains critères : soit pour certaines catégories de fichiers (uniquement ceux gérés par Git et/ou correspondant à un certain motif), soit sur des blocs de code en utilisant le commentaire spécial // format:.

// format: off
// this part won't modified by scalafmt
val identity = Array(1, 0, 0,
                     0, 1, 0,
                     0, 0, 1)
// format: on

Scalafmt est un outil pratique pour conserver un code Scala homogène au niveau d'un projet. Aussi, nous vous recommandons de l'intégrer (celui-ci ou tout autre outil équivalent) dans vos projet et de discuter en équipe de la configuration de cet outil.

Amélioration du lead time des chaînes en Spark avec un peu de Monix

2019-01-24T23:00:00Z

Monix

Monix est un framework Scala permettant la gestion des effets grâce à l'abstraction Task, qui peut englober tout ce qui relève du code à effet, comme print ou la lecture de fichier.

Nous utilisons ici la version 3.0.0 (qui est toujours en RC), car c'est la première version de Monix à implémenter les fibers. Tout comme les coroutines, les fibers (ou fibres) sont des petites unités de traitement coopératifs, pouvant s'intégrer au sein d'un Thread.

Expérience sur Monix avec Spark

En lançant deux jobs Spark en parallèle avec Monix dans une même application Spark, nous voulions montrer (dans le cadre d'un audit Univalence) qu'il était possible de réduire significativement la durée totale d'un traitement qui lance plusieurs jobs.

Deux dataframes sont créées et sont mises dans des Task de Monix. En utilisant une for-comprehension, ces deux Task peuvent être utilisées afin de pouvoir montrer qu'il est possible grâce à Monix d'avoir des gains de temps sur les jobs Spark.

Dans l'application, la jointure est mise en mémoire cache afin de pouvoir ensuite lancer deux jobs en parallèle depuis ce cache. Ces deux jobs sont lancés grâce à la méthode start() de Monix, qui permet de lancer Task avec des Fibers.

En ce qui concerne le slow, cette fonction sert juste à ralentir le count car il serait sinon trop rapide.

for{
      df1 <- loadDF1.memoize
      df2 <- loadDF2.memoize

      join = df1.join(df2).repartition(16).cache()

      job1 <- Task(join.slow.count).start
      job2 <- Task(join.slow.count).start

      end <- Task.parZip2(job1.join,job2.join)
} yield end

Voici le DAG des différentes étapes du code donné ci-dessus.

Sur l'image ci-dessous, nous voyons que nous avons bien réussi à lancer deux jobs en parallèle au sein d'une seule instance de SparkContext.

Sur l'image ci-dessous, nous remarquons que même si le premier count n'est pas terminé, le deuxième est déjà lancé.

Au final : le deuxième count est lancé en même temps, avec un temps de mise en œuvre total de 7 minutes, au lieu de 2 * 6.1 minutes (le lancement en concurrence dans ce cas à fait gagner 85% du temps d’exécution sans demander de ressource supplémentaires).

Conclusion

Monix est une librairie vraiment intéressante à combiner avec Spark cependant nous avons aussi trouvé qu'il était impossible d'annuler un job Spark se trouvant dans une fiber que ce soit avec Monix ou ZIO. Quand bien même l'use case d'annuler des jobs Spark en cours n'est pas très commun, il aurait été plus sympathique de pouvoir le faire car c'est normalement une des fonctionnalités majeures lorsque nous utilisons des fibers que ce soit avec Monix ou tout autre librairie similaire.

Parler de programmation fonctionnelle à l'université - retour sur mon intervention à l'Université Paris Nanterre

2019-01-20T23:00:00Z

Je suis intervenu récemment à l'Université Paris Nanterre pour un séminaire de deux heures focalisé sur la programmation fonctionnelle, suite à une proposition d'un enseignant-chercheur. La session était appelée "Ce qu'il faut savoir de la programmation fonctionnelle" et était présentée face à une vingtaine d'étudiants de niveau licence 3 et master 1 et 2 en informatique, ainsi que des enseignants. Mon objectif est alors de sensibiliser un tel public à ce style de programmation, lui expliquer qu'on retrouve ce paradigme de plus en plus dans le projet sous une forme ou sous une autre.

Ceci dit, la difficulté a été pour moi de me mettre à la place d'un étudiant. Vous souvenez vous de cette période où il vous semblait (pour certains) difficile, voire très difficile, de trouver un emploi et de trouver la bonne approche pour vous mettre en valeur ? Vous souvenez vous de cette époque où vous ne saviez pas encore ce qu'est vraiment un projet informatique en entreprise ? Vous souvenez vous surtout de cette époque où vous aviez de toute façon pas d'autres choix que de développer des projets jetables ? C'est-à-dire, qu'entre les cours et les TDs, et les projets à faire pour les autres modules de formation, vous deviez passer du temps, parfois seul, parfois en équipe, sur des projets cherchant généralement à résoudre... un problème technique. Et vous cherchiez alors à faire le juste nécessaire pour obtenir une bonne note, avec pour seule véritable exigence en termes de qualité de code de pouvoir être revu par l'enseignant. Même si on y retrouve cette notion de date limite de livraison, ceci contraste fortement face à des projets en équipe pleinement dédiée qui doit apporter un produit avec une valeur métier, censés durer dans le temps et être repris par d'autres développeurs que vous connaissez ou que vous ne connaîtrez jamais. Ces points, je les avais oubliés. C'est en discutant avec les enseignants qu'ils me sont revenus en mémoire.

En attendant, il fallait donc faire cet effort d'expliquer ce qu'est un projet informatique en entreprise, expliquer les problèmes rencontrés, pour finalement expliquer ce qu'apporte la solution mise en avant.

Plus qu'une simple présentation sur la programmation fonctionnelle, j'ai ainsi cherché à expliquer mon parcours et comment est-ce que j'ai vécu la montée en popularité de la programmation. J'ai montré ensuite comment se déroule un projet informatique en entreprise, comment s'organise une équipe de développement et quelles sont les difficultés qui y sont rencontrées (communication, maintenabilité du code, tentatives de séparation des aspects métiers et techniques...). Et pour terminer, j'ai présenté l'origine de la programmation fonctionnelle, ses apports dans le monde du développement et aussi les difficultés rencontrées avec ce type de paradigme. J'ai alors montré des concepts de la programmation fonctionnelle applicables dans la plupart des langages modernes, donné quelques cas d'usage et déroulé une démonstration à travers une application Web, dans laquelle j'expose clairement l'architecture et dans laquelle j'ai aussi organisé un live coding, passant de données écrites en dur dans le code, à des données provenant d'une base PostgreSQL dans un conteneur Docker, puis de Paris Open Data. Quelque chose me dit que la partie démonstration / live coding avait bien attiré l'attention, au vu du changement de posture dans le public.

Difficile néanmoins d'avoir les avis des étudiants sur la session. Ce sont surtout les enseignants qui m'ont fait leurs retours. Ils ont en tout cas perçu l'intérêt d'intégrer la programmation fonctionnelle dans les cours, mais aussi de voir un peu autrement l'élaboration des projets à donner aux étudiants, grâce à cette démonstration autour de l'application Web.

De cette expérience, il me paraît important de conserver une relation avec les institutions d'enseignement supérieur quel qu'ils soient, dans la mesure où ils sont responsables de la formation des développeurs qui renouvelleront le marché de l'emploi. En partageant, nos points de vue, nous participons à l'amélioration de l'enseignement. Il apparaît aussi qu'une bonne démonstration vaut mieux qu'un long discours ! Ça fonctionne non seulement dans les conférences communautaires, mais aussi auprès de n'importe quel public sensible au code et à ce qu'il apporte.

En tout cas, j'espère bien renouveler l'expérience !

Je tiens à remercier l'Université Paris Nanterre, ainsi que Pascal Poizat et Lom Messan Hillah, tous deux enseignants-chercheurs, pour la mise en place de tels séminaires et pour l'accueil qui m'a été réservé.

Voici les supports qui ont servi lors du séminaire :

Kafka : synthèse

2019-01-07T23:00:00Z

Kafka 0.10

Kafka Streams
Rack awareness

Kafka 0.11

Record headers
Exactly-once semantic

Kafka 1.0

Améliorations diverses

Kafka 2.0

+ ACLs, sécurité

(CEO of DataCumulus, une boite parisienne, fondée en juillet 2018, spécialisé en Kafka + AWS)

Introduction

Alors que dans la plupart des systèmes d'information, la donnée est vue comme un élément sujet au cours du temps à de nombreuses modifications et qu'il faut entreposer sous toutes ses formes (en ajoutant en plus des couches de caches pour des raisons de performances et des couches d'audit pour savoir par qui, quand et comment la donnée a été modifiée) et que les inévitables migrations de ces entrepôts sont perçues comme des projets pharaoniques voire insolubles, il y a des solutions qui vous proposent de sortir de ce carcan et de vous offrir une vision en flux, permettant de fournir une plus grande flexibilité dans les systèmes d'information. Avec nombre d'avantages complétant cette vision, Kafka est de ces solutions.

Depuis sa sortie en 2011 au sein de LinkedIn, Kafka est devenu une plateforme hautement recommandée, voire quasiment incontournable, dans le monde de la data. Open Source via le modèle de la fondation Apache (comme Hadoop, Spark ou Cassandra) et fortement soutenu par Confluent (la société fondée par les créateurs de Kafka), Kafka a déjà des adeptes importants comme Netflix, Uber, Twitter ou Goldman Sachs. Et en Europe, il y a Criteo, ING, Natixis, EDF, etc.

Kafka est librement téléchargeable. Mais ce framework est aussi inclue à des distributions Hadoop. Par exemple, Hortonworks le propose dans son offre DataFlow (HDF). Nous pouvons aussi trouver Kafka en tant que service managé auprès des cloud providers. Cette plateforme est ainsi disponible chez Confluent (avec une plateforme dédiée) et AWS.

Ce qui fait la particularité de Kafka, ce qui le différencie des approches alternatives, c'est que Kafka impose une vision distribuée et hautement disponible, tout en proposant une API bas niveau — ainsi, il est facile de rentrer dans les méandres de la plateforme et de son architecture. Pour paraphraser Confluent, il s'agit d'un gage de performance.

Nous allons dans cet article revenir les différentes utilisations de Kafka, puis nous verrons l'architecture de Kafka et observer assez rapidement son écosystème, tout en nous intéressant aux apports.

Quels sont les usages de Kafka ?

Il y a autour de Kafka plusieurs cas d'utilisation possibles. Son principal usage est lié à sa capacité à transférer de la donnée même si son volume est important, avec un haut niveau de fiabilité entre des services répartis. En se basant sur des flux nommés de données découpés en messages, autour desquels des services peuvent envoyer et d'autres services peuvent se mettre en attentes d'un envoie, en proposant de répartir et répliquer ces flux sur plusieurs machines, Kafka facilite la mise en place de systèmes répartis.

En effet, d'un côté, Kafka assure à la fois une transmission asynchrone des données entre les services. Ainsi, lorsque le développeur crée un service, il n'a pas nécessairement besoin de passer par du temps sur ces aspects. D'un autre côté, Kafka offre une haute disponibilité de son service et des données qu'il gère. Cet aspect possible grâce au mécanisme de répartition / réplication.

Il facilite aussi une vision alternative sur la donnée gérée par une entreprise : une vision unifiée dans laquelle nous accordons une importance à la transmission des événements modifiant les données, plus qu'au stockage d'un état mutable. L'état est ainsi reconstruit à partir de ces événements. Cette approche offre plus de flexibilité sur l'organisation d'une application ou d'un système d'information, avec la capacité conserver explicitement l'historique de la donnée ou de réinterpréter les événements pour en extraire d'autres données ou apporter des corrections.

Néanmoins, malgré les facilités offertes par Kafka, il est nécessaire de garder à l'esprit que nous sommes en présence d'un système réparti et que la conception d'un tel système repose sur un découplage des différents services qui le compose. Autre point, Zookeeper est une dépendance sur laquelle Kafka se base pour gérer son fonctionnement. Déployer Kafka revient donc à déployer deux services et Zookeeper n'est nécessairement le plus simple dans cette catégorie. Enfin, il y a bien évidemment des cas où Kafka sera de trop, en particulier si les volumes sont faibles ou les producteurs ou consommateurs autour de la données sont peu nombreux. Dans ces cas, une simple base de données relationnelle peut suffire.

Dans le détail...

Kafka a été créé par LinkedIn afin de faciliter et unifier la communication et la transmission de données dans le cadre de la transition vers une architecture microservices. Kafka apparaît donc comme un MOM (Message Oriented Middleware) dans ce cadre.

Depuis sa version 0.10, Kafka propose une API de traitement de données en flux, appelée Kafka Streams, et une API d'intégration, appelée Kafka Connect. Ces API facilitent la mise en place de chaîne de traitements, notamment dans le cadre de traitements BigData ou sur des architectures microservices.

Kafka peut aussi être utilisé pour agréger les logs provenant de plusieurs applications, par exemple dans le cadre d'une application microservices. Certains frameworks de log permettent de transmettre les logs directement dans Kafka.

De ces premiers cas d'usage, il est possible de constituer assez simplement des fonctionnalités de type analytics, de système de mise à jour de vues, d'éviction de caches...

Kafka est un framework basé sur le concept de commit-log ou journal de commits. Dans le cadre d'une base de données, un commit correspond à l'étape d'"engagement" des opérations impliquées dans une transaction. Il existe des cas d'utilisation où Kafka est adossé à une base de données, afin de récupérer l'ensemble des modifications sur cette base. Ceci est réalisé dans un but de réplication de la donnée et aussi afin de pouvoir reconstruire la base en cas de panne.

En partant de ce cas d'usage, il est possible de transformer Kafka en base de type event source. Dans ce cadre, ce qui est stocké ce n'est pas l'état de la donnée, mais l'ensemble des événements ayant participé à modifier cette donnée. L'état est alors déduit à partir de cet ensemble d'événements. Kafka n'est pas le meilleur outil pour l'event sourcing. Une base comme Event Store sera plus adaptée. Mais, dans la mesure où il est déjà en place, Kafka permet d'explorer ce paradigme.

Architecture et fonctionnement

Kafka est avant tout une plateforme permettant de transférer des messages, aussi appelés des logs, entre différents processus. Il s'apparente en ce sens à d'autres frameworks comme RabbitMQ ou ZeroMQ, ou des solutions Cloud comme PubSub chez Google et Kinesis chez AWS.

Architecture

Il y a deux points de vue avec Kafka : la vue physique qui concerne l'intégration avec les infrastructures d'un cluster et la vue logique qui concerne l'organisation que fait apparaître la plateforme afin de permettre la transmission de messages.

D'un point de vue physique, de base les instances de Kafka sont réparties dans un cluster. Les instances de Kafka, appelées brokers, sont réparties sur plusieurs machines. Elles permettent à la fois de répartir la charge et de répliquer les messages.

D'un point de vue logique, les messages sont transmis sur des topics nommés. Un topic va être constitué de plusieurs partitions, réparties dans les différents brokers. Au niveau d'un topic, des processus vont jouer le rôle de producteur pour ceux qui envoient des messages et d'autres processus vont jouer le rôle de consommateur pour ceux qui attendent la réception de messages.

Cluster Kafka de trois brokers avec deux topics de deux partitions chacun et un facteur de réplication de trois.

Kafka se base sur Zookeeper pour gérer une partie de son fonctionnement (liste des topics, offset...). Une migration est prévue pour intégrer l'algorithme de consensus Raft afin de rendre Kafka plus indépendant.

Fonctionnement

La connexion à Kafka se fait en créant un producteur ou un consommateur et en passant en paramètre un ensemble de propriétés. Il faut au minimum préciser l'ensemble des brokers qui seront utilisés, ainsi que les outils de sérialisation qui seront utilisés pour la clé et la donnée dans les messages. Les messages apparaissent en effet sous la forme clé-valeur, avec la possibilité d'ajouter une en-tête depuis la version 0.11.

Pour le consommateur, il faut en plus préciser un group ID pour indiquer dans quel groupe se trouve le consommateur. Ce group ID est surtout utilisé lorsque plusieurs consommateurs sont utilisés en parallèle. Si des consommateurs sont dans le même groupe, ils sont en compétition pour consommer les messages. Dans ce cas, si un consommateur récupère un message, les autres consommateurs du groupe auront les message suivants. Si les consommateurs sont dans des groupes séparés, alors ils fonctionnent en parallèle pour consommer les messages. Dans ce cas, si un consommateur d'un groupe récupère un message, les consommateurs des autres groupes pourront aussi récupérer ce même message s'il ne l'ont pas déjà fait.

L'envoi d'un message par un producteur se fait en utilisant la méthode send(). Cette méthode prend en paramètre un ProducerRecord, qui doit préciser au minimum le topic et le contenu du message. Il est possible de spécifier la clé du message, la partition, des en-têtes et un timestamp. Depuis Kafka 0.11, il est possible de regrouper des messages dans des transactions. Dans une transaction, les messages peuvent être destinés à plusieurs partitions d'un même topic et aussi à plusieurs topic. Les transactions sont atomiques et il est possible de les interrompre (comme pour une base de données relationnelle).

Pour qu'un consommateur reçoivent des messages, il faut que celui-ci souscrive à un ou plusieurs topics (il est possible de spécifier ces topics en fournissant une expression régulière). L'attente d'un message se fait avec la méthode poll(), qui retourne un ConsumerRecords représentant l'ensemble des messages récupérés depuis les topics souscrits. Il faut nécessairement indiquer un temps d'attente maximal. Si ce temps est dépassé, poll() retourne une structure vide. Un ConsumerRecords est composé de ConsumerRecord. Dans une telle structure, il est possible de récupérer les informations transmises au niveau du producteur, ainsi que l'offset du message dans une partition donnée.

Fonctionnement d'un topic

Nous avons vu qu'un topic est composé de partitions. Chaque partition est en fait un fichier sur disque. Il est en ajout seulement pour le producteur et en lecture seul pour le consommateur. Chaque message est ajouté à la fin du fichier et se voit attribué un numéro séquentiel appelé offset, indiquant le numéro d'arrivée du message dans la partition.

L'ordre des messages est garanti au niveau d'une partition. Par contre, il n'est pas garanti au niveau d'un topic, si celui-ci contient plusieurs partitions.

Pour résumer

La persistance est donc au cœur de la plateforme, car Kafka se base principalement sur de la gestion de fichiers. Sur ce point, les performances de Kafka sont du coup directement dépendante du matériel utilisé, de la gestion de ce matériel par le hardware et aussi la gestion de ce matériel par l'OS. Il faut aussi savoir que le moindre message transmis sur le réseau est d'abord enregistré sur disque.

La tolérance à la panne est assurée à travers la réplication des partitions entre les brokers. Si une machine tombe en panne, les opérations sont reprises au niveau d'un réplicat, qui devient lead.

Écosystème de Kafka

Il existe tout un écosystème autour de Kafka afin de le spécialiser autour de différents usages (gestion de flux de données, connexion à des services externes, gestion des schémas...). Une partie de cet écosystème est fourni avec la plateforme Confluent. Nous n'aborderons pas cette plateforme ici et nous verrons juste Kafka Streams et Kafka Connect disponibles librement.

Kafka Streams

Kafka Streams est un framework qui permet de faciliter le stream processing. Nous sont ainsi fourni à travers une API des transformations, voire des outils pour remodeler les données gérées par Kafka entre différents topics. Plus précisément en terme d'opération, il est possible de modifier les logs un à un (map), d'ajouter des logs (flatmap), de les filtrer, de regrouper des logs selon une clé donnée (group-by) et même de fusionner des topics (join).

Kafka Connect

Kafka Connect est un framework permettant de transférer des données en flux entre différents systèmes, en se basant sur Kafka. En terme de système, il peut s'agir de SGBDR, de base NoSQL, de récupération de logs, de stockage sur le Cloud, etc.

Confluent fourni un hub contenant différents connecteurs : https://www.confluent.io/hub/.

À propos...

Ensemble Kafka Streams, Kafka Connect et Kafka couvrent ainsi les besoins couverts par des frameworks comme Apache Camel ou Akka Stream et permettent de remplacer les ESB par une plateforme de stream processing et/ou orientée événements... En tout cas, là où les ESB représentent une approche trop lourde et peu flexible, c'est-à-dire dès qu'il s'agit juste de mettre à disposition des flux de données caractérisés. L'avantage qu'apportera Kafka, dès lors que son cas d'usage est respecté, sera de fournir en plus de la performance et de la haute disponibilité.

Conclusion

Kafka et son écosystème présentent ainsi de nombreux avantages pour mettre en place non seulement un bus de messages, mais aussi un outil de transport et transformation de données, en particulier avec des données en flux. Tout ceci est réalisé en bénéficiant des optimisations sous-jacentes à Kafka et aussi d'un système de persistance, de réplication et de partitionnement assurant une haute disponibilité de la plateforme.

Toutes ces particularités font de Kafka un outil à part entière, qui est certes générique, mais qui est capable de supplanter bon nombre d'outils spécialisés autour de la donnée, tant Kafka en plus d'être performant, apporte beaucoup de flexibilité.

Draft 0.1

Kafka est sorti récemment en version 2.1. Cette version inclue un certains nombres de correctifs par rapport à la version 2.0, mais aussi l'intégration de Java 11 et la possibilité de un nouvel algorithme de compression développé par Facebook et plus rapide que GZip pour un taux de compression équivalent : ZStandard.

Cette article est l'occasion de revenir sur les dernières évolutions de Kafka par rapport aux versions encore assez utilisés dans les systèmes d'information actuels : nous allons pour cela partir de Kafka 0.10.

Le versioning dans Kafka

Les numéros de version de Kafka ne suivent pas exactement un schéma classique. Par exemple, les changements entre la 0.10 et la 0.11 sont plus important que les changements apparaissant entre la 0.11 et la 1.0, sachant que la 1.0 est plus une version de stabilisation. Autre exemple, les nouveautés la 2.1 crée un changement qui ne permet pas de revenir aux versions précédentes.

Kafka 0.10

Jusqu'à la version 0.10, Kafka était déjà connu comme un framework de messaging distribué.

Avec la version 0.10, Kafka devient aussi un framework de streaming.

Kafka 0.11

Header

Dans un objectif de s'aligner avec la plupart des protocoles réseaux, comme HTTP ou TCP, ainsi que les systèmes de message, comme JMS ou QPID, la version 0.11 de Kafka permet d'ajouter un en-tête à chaque message. Un message est donc depuis cette version défini :

par un corps, composé d'une clé et d'une valeur ;
par une en-tête, qui est un ensemble clé-valeur.

L'en-tête permet d'ajouter des méta-données aux messages dans différents objectifs, comme le routage automatique des messages entre différents cluster, l'intégration d'informations d'audit comme l'ID client, l'ID cluster où a été produit le message, etc. ou enfin, la mise en place de métriques.

Une en-tête est représentée par l'interface Header. Dans celle-ci, la clé est sous forme d'une chaîne de caractères (String) au format UTF-8 et le contenu sous forme de tableau d'octet (byte[]). Ce qui permet d'y mettre toute sorte de données sérialisées.

Les Header sont rassemblés dans une structure mutable appelé Headers. Il s'agit d'une interface dérivé de Iterable<Header>. C'est cette structure qui rattachée aux Record depuis Kafka 0.11.

Dans Headers, les méthodes les plus intéressantes sont :

add(String key, byte[] value) pour ajouter une métadonnée ;
Iterable<Header> headers(String key) pour retourner toutes les en-têtes dont la clé est key.

Il y a aussi Header lastHeader(String key), qui retourne la "dernière" métadonnée de clé key. Mais il ne semble pas avoir d'explication sur ce qui est entendu par "dernière". Dans l'implémentation actuelle, un java.util.ArrayList est utilisé pour stocker les en-têtes. Dernière dans cette implémentation signifie l'élément avec le plus grand indice. La recherche se fait donc en O(n) en partant du dernier élément.

Exactly once

Il existe typiquement trois sémantiques de livraison de message dans un système répartie :

At-least-once : le système garanti qu'un message sera transmis et qu'il apparaît au moins une fois au niveau d'un consommateur. Ce qui veut dire qu'un message produit pourra être consommé. Ce qui veut aussi dire qu'un message peut être dupliqué.
At-most-once : le système garanti qu'un message ne sera pas dupliqué. Mais il peut ne pas transmettre le message.
Exactly-once : le système garanti qu'un message produit sera transmis et fourni en un seul exemplaire au consommateur.

What's New in Kafka 2.1?

Kafka 2.1 is out! Java 11 on Kafka, Support for ZStandard compression, Intuitive Producer Timeout, Security Changes… Find out what has changed in the latest ...

https://www.youtube.com/watch?time_continue=3&v=lIGFH9TkL2w

La GetSet parisienne qui découvre Kafka

LCC 193 - Interview Apache Kafka avec Florent Ramière

Florent Ramière vient discuter avec Emmanuel d’Apache Kafka, de ses usages, son fonctionnement, son écosystème. Et roule ma poule sur piste noire.

https://lescastcodeurs.com/2018/07/30/lcc-193-interview-apache-kafka-avec-florent-ramiere/

ZIO : mais d'où vient cette stack trace ?

2018-11-21T23:00:00Z

Si vous utilisez ZIO, une librairie Scala permettant de gérer votre code à effet, vous avez sûrement rencontré un jour une erreur de ce type :

scalaz.zio.Errors$UnhandledError: An error was not handled by a fiber: java.io.FileNotFoundException: Philippe (No such file or directory)
	at scalaz.zio.RTS$FiberContext.$anonfun$reportErrors$1(RTS.scala:887)
	at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:12)
	at scalaz.zio.RTS$$anon$1.run(RTS.scala:91)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
Exception in thread "main" scalaz.zio.Errors$UnhandledError: An error was not handled by a fiber: java.io.FileNotFoundException: Philippe (No such file or directory)
	at scalaz.zio.RTS.unsafeRun(RTS.scala:25)
	at scalaz.zio.RTS.unsafeRun$(RTS.scala:21)
	at Toto$.unsafeRun(Titi.scala:5)
	at Toto$.main(Titi.scala:11)
	at Toto.main(Titi.scala)

Process finished with exit code 1

object Toto extends RTS {
  def exceptionIO(filename: String): IO[Exception, Seq[String]] = {
    IO.syncException(Source.fromFile(filename).getLines().toSeq)
  }

  def main(args: Array[String]): Unit = {
    unsafeRun(exceptionIO("Philippe"))
  }
}

Super méga chouette, nous avons une java.io.FileNotFoundException: Philippe mais rien sur l'endroit où se cache le coupable.

Philippe! Je sais où tu te caches!

La doc de ZIO

Si on essaye l'exemple de la documentation:

object Titi extends App {
  override def run(args: List[String]): IO[Nothing, Titi.ExitStatus] = {
    Toto.exceptionIO("Philippe").attempt.map(_.fold(_ => 1, _ => 0)).map(ExitStatus.ExitNow(_))
  }
}

Process finished with exit code 1

On n'est pas plus avancé !

Do It Yourself

On cherche à récupérer la stack trace d'une manière ou d'une autre pour avoir un peu plus d'informations sur la ligne de code qui nous embête.

Pour cela nous allons créer quelques fonctions (accompagnées de leur coulis d'implicit class) qui nous permettent de reporter la stack trace en console :

object Utils {

  implicit class IOOps[E, A](io: IO[E, A]) {
    def peekError(peek: E => IO[Nothing, Unit]): IO[E, A] = {
      io.flip.peek(peek).flip
    }
  }

  implicit class ExceptionOps[E <: Throwable, A](io: IO[E, A]) {
    def printException: IO[Nothing, Option[A]] = {
      io.peekError(x => IO.sync({
        x.printStackTrace()
      })).attempt.map(_.right.toOption)
    }
  }

}

object Toto extends RTS {
  def exceptionIO(filename: String): IO[Exception, Seq[String]] = {
    IO.syncException(Source.fromFile(filename).getLines().toSeq)
  }

  def main(args: Array[String]): Unit = {
    import Utils._
    unsafeRun(exceptionIO("Philippe").printException)
  }
}

java.io.FileNotFoundException: Philippe (No such file or directory)
	at java.io.FileInputStream.open0(Native Method)
	at java.io.FileInputStream.open(FileInputStream.java:195)
	at java.io.FileInputStream.<init>(FileInputStream.java:138)
	at scala.io.Source$.fromFile(Source.scala:90)
	at scala.io.Source$.fromFile(Source.scala:75)
	at scala.io.Source$.fromFile(Source.scala:53)
	at Toto$.$anonfun$exceptionIO$1(Titi.scala:7)
	at scalaz.zio.IO$.$anonfun$syncCatch$1(IO.scala:974)
	at scalaz.zio.RTS$FiberContext.evaluate(RTS.scala:372)
	at scalaz.zio.RTS.unsafeRunSync(RTS.scala:39)
	at scalaz.zio.RTS.unsafeRunSync$(RTS.scala:37)
	at Toto$.unsafeRunSync(Titi.scala:5)
	at scalaz.zio.RTS.unsafeRun(RTS.scala:21)
	at scalaz.zio.RTS.unsafeRun$(RTS.scala:21)
	at Toto$.unsafeRun(Titi.scala:5)
	at Toto$.main(Titi.scala:11)
	at Toto.main(Titi.scala)

Voilà, maintenant nous savons à quelle ligne de code on cherchait Philippe.

Conclusion

ZIO c'est top, néanmoins il manque parfois quelques fonctions pour gérer des cas classiques.

On peut légitimement se poser la question du choix de ZIO par rapport à Cats-Effects quand on fait ce genre de "bêtises", mais nous n'avons pas la place dans cet article pour en discuter ! 😃

ScalaIO 2018 - Le retour de l'équipe Univalence

2018-11-21T23:00:00Z

ScalaIO est une conférence tournant autour du langage Scala, de son écosystème (Akka, Spark, Play...) et aussi autour de tout ce qui touche de près ou de loin à la programmation fonctionnelle, quelque soit le langage (Haskell, OCaml, JavaScript, TypeScript...). La session ScalaIO 2018 a eu lieu entre le 29 et 31 octobre au CPE à Lyon.

Pour l'occasion, l'équipe d'Univalence ont fait le déplacement. Ils reportent ici leurs impressions.

Les keynotes

Nous avons eu droit à trois keynotes :

Towards Scala 3 - A Status Report par Martin Odersky, le deuxième jour en ouverture.
ZIO: Next Generation Effects in Scala par John De Goes, le troisième jour en ouverture.
Future of Scala par Jon Pretty, le troisième jour en fermeture.

Towards Scala 3 - A Status Report par Martin Odersky

Le talk d'Odersky fut en partie une redite de son talk présenté lors de ScalaDays Berlin en mai dernier (disponible sur Youtube) et lors de ScalaDays New York en juin dernier (disponible aussi sur Youtube). Si vous avez loupé ces sessions, sachez qu'avant l'arrivée de Scala 3 prévue pour 2020, il y aura une version 2.13 prévue pour février 2019. L'objectif sera d'orienter le langage vers plus de simplicité et de réduire les puzzlers (comprenez des expressions Scala valides dont le résultat est contrintuitif).

Dans ce qui va arriver :

Une notation pour les types union A | B (par exemple String | Null) et une nouvelle notation pour les types intersection A & B (le mot-clé with disparaîtra progressivement).
Les types de fonction implicite implicit A => B, ce qui va permettre de créer des contextes de traitement.
Une syntaxe pour les enums avec la possibilité de les paramétrer. Par exemple ci-dessous, nous voyons une autre façon d'écrire le type Option.
```
enum Option[+T] {
  case Some(x: T)
  case None

  def isDefined: Boolean = this match {
    case None => false
    case some => true
  }
}
```
Nous pourrons mettre des paramètres dans les traits trait MyTrait(x: String).
La fin de la limite à 22 paramètres pour les fonctions et les tuples : nous pourrons mettre autant de paramètres que nécessaire. Les tuples seront réimplémentés afin d'avoir une vision plus proche des HList de Shapeless ((a, b, c) == (a, (b, (c, ())))).
L'égalité multiversale, c'est-à-dire la possibilité de comparer deux types différents que dans le cas où un implicite basé sur Eq a été déclaré.
Une notation pour les types lambda type T = [X] => F[X] (qui équivaut à type T[X] = F[X]).

Une volonté est marquée de séparer un peu plus Scala de Java. Dans ce cadre, Odersky propose TASTY. TASTY est un format de sérialisation d'AST (Abstract Syntax Tree) typé. Il faut le voir comme un format intermédiaire généré juste après les premières phases de compilation et de type checking. Libre ensuite aux phases suivantes de transcrire le format TASTY vers d'autres formats : Java byte code, Javascript, code machine natif, etc. Le format TASTY peut aussi être utilisé à destination des IDE pour une meilleure intégration du langage.

Si TASTY sera pleinement fonctionnel pour Scala 3 (il est développé dans le cadre de Dotty, qui représente en quelque sorte le futur de Scala), sa mise en place pour Scala 2.x est encore en cours d'étude. La plus grosse difficulté concerne actuellement les macros. Il y a deux types de macros :

Blackbox : ce sont des macros qui interviennent après la phase de type checking. Les informations sur les types sont complètement résolus.
Whitebox : ce sont des macros qui interviennent avant la phase de type checking. Les informations sur les types dans les signatures sont imprécises.

Or les macros whitebox vont disparaître avec Scala 3. Pourtant, plusieurs frameworks Scala dépendent des macros whitebox, comme par exemple SCio (présenté dans l'après-midi même). Odersky recherche actuellement une solution au niveau langage pour pallier la disparition des macros whitebox (😢).

Pour terminer, Odersky nous propose à travers Visual Studio Code une démonstration des nouvelles capacités de Dotty au niveau des types : par exemple la représentation de l'inversion d'un tuple avec de nouvelles fonctionnalités pour transformer les types (pattern matching au niveau du système de type).

type Append[+X <: Tuple, Y] <: Tuple = X match {
  case Unit      => Y *: Unit
  case x1 *: xs1 => x1 *: Append[xs1, Y]
}

type Reverse[+X <: Tuple] <: Tuple = X match {
  case Unit      => Unit
  case x1 *: xs1 => Append[Reverse[xs1], x1]
}

def reverse[T <: Tuple](xs: T): Reverse[T] = ???

def r: (Boolean, String, Int) = reverse((1, "", false))

ZIO: Next Generation Effects in Scala par John De Goes

Pour l'occasion, John De Goes a renommé son talk en "Beautiful Scala". Un talk démarrant par la Genèse revue et corrigée du point de vue du développeur fonctionnel !... Avec quelques trolls au passage :

Sur les outils : "Il y a deux types de programmeurs : ceux qui utilisent les éditeurs de texte et ceux qui utilisent les beaux IDE".
Et surtout sur la programmation objet : lors d'une discussion entre le serpent et ~~l'homme~~ le développeur : "An apple is a plant which has seeds and is the receiver of being-eaten".

Là dessus, John fait une transition à l'ancien testament (toujours revu et corrigé) en présentant les tables de la loi du développeur et ses 10 commandements, tout en parlant de son framework scalaz-zio (ou ZIO).

Une fonction doit être totale, déterministe et sans effet de bord.
Les effets doivent être réifiés. Il faut donc utiliser la notation IO[E, A] de ZIO. IO représente tout processus impliquant possiblement un effet. C'est-à-dire une étape de calcul dans laquelle la modification du système est observable. Dans IO[E, A], A représente le type de la valeur attendu par le processus et E représente le type retourné en cas de problème.
Il ne faut pas bloquer les threads (pour des raisons de performance). C'est tout l'intérêt des fibres qui peuvent être vues comme un thread léger et se retrouvent à la base de ZIO. Les fibres dans ZIO sont notées Fiber[E, A]. Elles permettent d'éviter le callback hell et peuvent être gérées par le GC, même si la fibre contient une boucle infinie.
Des ressources managées. ZIO propose deux opérations bracket et managed qui permettent de gérer des zones de code à la manière de try with resource en Java dans lesquelles les ressources comme les fichiers ou les connexions à un service sont gérées sans que le développeur n'ait besoin de rentrer dans les détails techniques.
Ne pas avoir peur de la concurrence. L'objectif est de mettre en place une abstraction donnant une perception claire de la concurrence. Pour cela, ZIO propose deux opérations : parAll pour récupérer le résultat de toutes les fibres exécuter en même temps et raceAll pour récupérer le résultat de la fibre ayant répondu en premier parmi plusieurs, sachant que les autres fibres sont automatiquement arrêtées (difficilement réalisable sans une réification des différentes tâches des processus comme dans les fibres de ZIO) .
Reposez-vous autant que possible (la paresse est importante). La création de fibres dans ZIO se fait en utilisant l'opération fork. Il est possible alors soit de se mettre en attente de son terme avec join ou de l'interrompre avec l'opération interrupt. Sachant que interrupt agit immédiatement.
Honorer les transactions. ZIO fournit Ref[A] et RefM[A], qui sont des zones mémoires de type STM (Software Transactional Memory), c'est-à-dire avec des transactions (comme dans une base de données). Ces zones mémoires sont mutables, mais les opérations effectuées sur celles-ci sont atomiques. RefM[A] permet en plus de gérer les effets (par exemple, afficher un message à l'écran).
Respecter les promesses. ZIO fournit Promise[E, A]. Ce type représente des variables qui ne peuvent être assignées qu'une seule fois avec une valeur de type A. Cette valeur sera récupérée par une autre fibre, mise en attente de l'assignation. Il est possible aussi de remonter une erreur E à travers cette variable. Promise[E, A] permet de coordonner plusieurs fibres en échangeant des valeurs entre-elles.
Ne pas abandonner. ZIO propose des ordonnanceurs composables avec Schedule[A, B], c'est-à-dire un outil permettant de spécifier la récurrence d'une tâche (en nombre de répétitions et/ou en intervalle de temps entre deux répétitions). Schedule[A, B] consomme des éléments de type A et produit des éléments de type B. On peut ainsi représenter une nouvelle tentative (retry) avec Scheduler[E, A], où E représente le type d'une erreur : une tâche est répétée jusqu'à ce qu'il n'y ait plus d'erreur.
Soyez productif et multipliez la donnée. John De Goes parle à ce moment là d'un type Queue avec back-pressure et aussi d'un nouveau type pour les flux de données Stream[E, A] incluant là aussi la notion d'erreur avec E.

Le talk s'est terminé sur un appel à participer à la montée en compétence des développeurs en programmation fonctionnelle et en particulier avec ZIO.

... Puis, avec l'intervention de l'organisation, John a posé quelques questions en demandant à ceux qui répondent par non (en toute sincérité) de venir sur la scène :

"Savez-vous ce qu'est un Functor ?" Une dizaine de personnes hésitantes se sont alors déplacées sur la scène.
"Connaissez-vous un type de "type" (*, *) -> * ?" Beaucoup de participants se sont regardés. Et petit à petit, les personnes se sont levées pour venir remplir l'estrade. Pendant quelques minutes, un flux continu et pratiquement interminable s'est emparé des escaliers de l'amphi en direction de la scène. Sur un amphi de 500 places bien rempli, il ne restait cette fois qu'une vingtaine de personnes assises. Le reste remplissant comme il le pouvait les rares places restant sur l'estrade. La photo était impressionnante, laissant dans l'embarras un instant l'organisation ! (Si vous vous vous demandez quelle réponse est valide, il faut comprendre que (*, *) -> * (ou aussi * -> * -> *) représente tous les constructeurs de types avec deux paramètres comme Either[A, B], (A, B) ou A => B ; allez voir la notion de higher-kinded type.)

"Qui ne comprend pas la programmation fonctionnelle ?" Le flux pris une marche inverse, remplissant à nouveau les sièges de l'amphi et ne laissant qu'une quarantaine de personnes sur l'estrade. Et pour ces personnes restant sur scène un exemplaire de Functional Programming for Mortals with ScalaZ de Sam Halliday leur était offert !

Future of Scala par Jon Pretty

Alors que SBT domine sur l'ensemble des outils de gestion de build dédié à Scala, d'autres outils du même ordre voient le jour. C'est le cas pour CBT ou Mill. Dans ce talk, Jon Pretty nous présente Fury, qui est aussi un outil de build, avec un logo que Jon nous promet de voir plus souvent.

Si le nom représenterait ce que Jon pense de SBT, la particularité de Fury est

Qu'il s'utilise en ligne de commande (CLI).
Qu'il est rapide. Nous n'avons pas à attendre qu'il se charge comme SBT.
Qu'il propose un reporting semi-graphique (vue tabulaire sur les éléments du projet, vue arborescente et régulièrement mise à jour lors de la construction du projet)
Qu'il est déjà intégré avec d'autres outils, comme Git.

Fury fournit une vision hiérarchique de vos projets. À la base se trouve le workspace, qui comme son nom l'indique est l'espace de travail de Fury. Le workspace représente aussi un ensemble de repo Git. Dans ce workspace, nous allons avoir différents projets. Un projet représente une lib ou une application entière et correspond à un repo Git. Un projet sera ensuite décomposé en module(s) — typiquement core, macro, bench... Aux différents projets, il est possible d'associer des schema. Un schema est une configuration qui permet de compiler un projet sous différentes versions (scala 2.12, scala 2.11, scalaJS...).

Quelques conférences de ScalaIO

Scala Best Practices I Wish Someone'd Told Me About par Nicolas Rinaudo

Nicolas Rinaudo a présenté un talk intitulé "Scala Best Practices I Wish Someone'd Told Me About" (en français). Cette présentation était une occasion unique à vivre. Ce n'est pas tant le contenu qui était exceptionnel. Celui-ci était de bonne qualité et j'ai eu l'occasion d'apprendre de bonnes et de mauvaises pratiques en Scala. Non, ce qui fut exceptionnel, c'était la présence non avertie de Martin Odersky, le créateur de Scala, dans cette session — mettant en émoi le speaker, qui effectivement ne s'y attendait pas.

Je tiens à rappeler que le talk était en français et en mode puzzler, donc interactif. J'ai donc découvert que Martin Odersky comprend bien le français et le parle aussi ! Et sa présence fait écho à ce qu'il avait annoncé dans sa keynote : réduire autant que possible les puzzlers du langage Scala.

Et alors que Nicolas se permettait (tant qu'il pouvait) quelques critiques du langage Scala, l'auditoire a pu assister à des échanges entre le speaker et Martin. Dans les sujets des échanges, les type class, leurs avantages et le fait d'avoir une syntaxe simplifiée dans les futures versions de Scala. Et aussi :

Nicolas : Désolé Martin de faire cette critique 😬, mais je conseille d'éviter d'utiliser le type Try. Préférez le type Either, d'autant qu'avec ce type, il est possible de choisir le type pour les erreurs.
Martin : Je comprends, mais le type Either est une abomination hérité d'Haskell ! Try est un bon type et les exceptions sont une bonne représentation.
Nicolas : 😅
Quelqu'un dans l'auditoire : Oui mais les exceptions pose un problème de performance. Lancer une exception nécessite de réifier toute la pile d'appel !

Les puzzles vus ont été parcourus avec plus de temps que prévu par le speaker, si bien que seule la moitié des slides ont été présentées. Néanmoins, le déplacement valait le coup ! Pour terminer, afin de faire un happy end, Martin a demandé à Nicolas hors séance de refaire le talk en anglais à ScalaDays !

Better, faster, stronger Coder. Improving data processing @Spotify par Julien Tournay

En dehors de ça, nous avons eu aussi des talks assez avancés. Ce fut le cas de l'excellent talk de Greg Pfeil intitulé "Category-parametric Programming", sur la capacité à représenter la théorie des catégories à travers Scala. Ce fut le cas aussi de l'intervention de Julien Tournay de Spotify qui présentait SCio, une API en Scala et programmation fonctionnelle pour Apache Beam et Google Cloud Dataflow. Le talk s'intitulait "Better, faster, stronger Coder. Improving data processing @Spotify". Il présentait les difficultés que posent la sérialisation en Java et le fait que ce soit... pire avec Scala.

Julien nous a alors présenté Magnolia, une solution développée par Jon Pretty pour générer automatiquement des typeclass pour datatype décrits à partir de case class et sealed trait. Magnolia se base sur les macros Scala pour cette génération. Autrement dit, tout se passe à la compilation ! Ce qui permet de décharger la partie runtime, contrairement à la réflexion. Julien utilise donc Magnolia pour enlever de la charge lors des phases de (dé)sérialisation. Il réussi à obtenir ainsi de meilleures performances au niveau de SCio. En aparté, une discussion s'est engagée entre Julien et Martin Odersky : Magnolia se base sur des macros whitebox. Mais les versions futures de Scala verront leur disparition. Les versions futures de Scala représentent donc un risque pour SCio. Ce à quoi Martin promet de réfléchir.

High performance Privacy By Design using Matryoshka and Spark par Olivier Girardot et Wiem Zine Elabidine

Du côté Data, il y avait un certain nombre de talks sur Spark et ainsi que les problématiques du streaming. Notamment Frameless, présenté par Brian Clapper, un framework s'installant au-dessus de Spark et qui utilise Shapeless pour apporter plus de type checking dans le code Spark. Il y avait aussi "7 conseils pour démarrer avec Spark" de Nastasia Saby et quelques retours d'expérience d'Ebiznext sur Spark et Kafka.

Il y avait enfin le talk d'Olivier Girardot et Wiem Zine Elabidine, intitulé "High performance Privacy By Design using Matryoshka and Spark" (sous la bienveillance de John De Goes). Si matryoshka fait référence à ces poupées russes qui s'emboitent les unes dans les autres, il était question ici du framework Scala implémentant les schémas de récursion (recursion schemes), introduit par Erik Meijer et al. dans un article intitulé "Generalized bananas, lenses and barbed wire".

Le contexte présenté par Olivier concerne la mise en place d'une approche privacy by design, inscrit dans la réglementation européenne RGPD sur la protection des données privées et en application depuis le mois de mai de cette année. Dans un cadre BigData / Spark, il est nécessaire d'appliquer cette réglementation, en veillant à ce qu'une stratégie de privacy soit appliquée aux colonnes qui le nécessitent, ce qui inclut l'anonymisation ou la pseudonymisation des données. Pour se faire, Olivier propose tout d'abord d'associer à chaque catégorie de colonnes représentée par un Seq[String] une stratégie spécifique. Il représente alors ça à travers ce type : Map[Seq[String], PrivacyStrategy].

C'est pour mettre en pratique cette structure de données que l'équipe dans laquelle étaient Olivier et Wiem se sont intéressés à Matryoshka. Wiem nous a alors expliqué le principe derrière cette librairie et comment et dans quel cadre elle a été mise en place : la transformation des données intégrant la transformation de schéma en passant par un format pivot SchemaF.

Et Univalence ?

Tout d'abord toute l'équipe Univalence était présente lors de ScalaIO. Un signe nous distinguait à ce moment : des t-shirts et des stickers avec les symboles suivants :

𝜆❤.
(𝜆🐇.❤(🐇🐇))
(𝜆🐇.❤(🐇🐇))

Nous vous laissons avec le mystère que cache ces symboles, mais comprenez qu'ils sont en rapport avec la programmation fonctionnelle et... les lapins !

Notre ressenti sur la conférence était globalement positif. Deux de nos data engineers ont d'ailleurs gagnés le livre de Sam Halliday Functional Programming for Mortals with ScalaZ. Et notre CEO a aussi gagné grâce à Lunatech un mug Star Wars ^^. Néanmoins, pour la plupart d'entre-nous, il y avait à ScalaIO de la matière à discuter certes, mais aussi beaucoup de concepts et de pratiques à découvrir.

Et en tant que speaker, nous avons animé deux sessions :

Le workshop "Dans s'cas là mettons les mains dans le code" avec Jean Helou (de Codamens) et @Jonathan Winandy .
Le short talk "Back to school : des exercices pour monter en compétence en FP" avec @François Sarradin

Ces deux sessions sont destinées aux débutants en Scala et en programmation fonctionnelle. Elles tournent autour de la montée en compétence des novices et du mentoring pour ces sujets.

Car, même si nous avons une expertise en Scala, Spark et en programmation fonctionnelle, la montée en compétence dans ce domaine est un sujet qui nous anime, sachant que devons régulièrement y faire face aussi bien en interne, en particulier pour nos profils juniors, qu'auprès des équipes auprès desquelles nous intervenons ou de la communauté en général.

Autres points

N'oublions pas que ScalaIO est avant tout une conférence basée sur le bénévolat, dont une bonne partie des frais sont principalement payés par les billets achetés et les sponsors. De plus, les membres de l'organisation sont avant tout des développeurs.

Le lieu est assez simple d'accès, situé sur un campus avec le tramway pas trop loin. Néanmoins il faut prévoir un peu de marche sorti du tramway. En ce qui concerne le CPE, pas de problème particulier non plus. Les salles sont biens. Il y a juste eu quelques surprises avec le matériel de projections. Par contre, le réseau mobile Free y est capricieux et il ne fallait pas trop compter sur le Wifi (apparemment, c'était plus un problème d'infra au CPE et indépendant de l'organisation).

Niveau intendance, rien à dire, avec la présence d'un traiteur (proposant des plats frais et la présence de plats végétariens) et d'un stand crêpe. Un effort était fait pour proposer des gobelets solides (du genre qui ne s'écrase pas lorsqu'on appuie dessus) et réutilisables.

Du point de vue stand, les sponsors étaient principalement des sponsors français, mais représentant assez bien la communauté Scala (eBizNext, NeoLynk, Teads, Criteo...). Le sponsor principal, Lunatech, a assuré une bonne animation avec des prix à gagner et une décoration spéciale pour "Helloween".

Enfin, la community party dans un ancien pétrolier réaménagé en lieu de réception fut très appréciable.

Enfin, pour la première fois de son existence, l'organisation a ajouté un jour dédié aux workshops. Nous insistons sur l'aspect première fois, car il y a eu quelques couacs autour de l'organisation de ces workshops. En espérant, que l'année prochaine sera plus favorable sur point.

Conclusion

L'un des avantages de ScalaIO, lorsqu'on s'intéresse à l'écosystème Scala et/ou à la programmation fonctionnelle, c'est de se sentir d'autant moins reclus. Pas de jugement, pas de réelles mauvaises critiques, la communauté a plus envie de faire avancer les sujets et est prête à accompagner et guider ceux qui souhaitent aller de l'avant.

De plus, au travers des talks mais aussi au travers des discussions de "couloir" que vous pouvez avoir, l'état d'esprit de toutes les personnes présentes à ScalaIO (dont nous pouvions compter beaucoup de contributeurs à l'écosystème Scala en France et dans le monde) font que cette conférence est une bonne expérience. Et c'est toujours un peu triste de voir ScalaIO se terminer, néanmoins avec une certaine fierté d'être membre de cette communauté.

Merci à tous ceux qui ont fait ScalaIO 2018 et à l'année prochaine !

Merci @Bernarith Men @Anonymous @François Sarradin et @Jonathan Winandy pour les photos. En ajoutant @Anonymous et @Brahim Boukalit pour leur participation.

Implicit Encoder / SparkSession / Configuration, quelques astuces pour structurer du code Spark

2018-11-20T23:00:00Z

Un post bateau, mais cool !

Parfois on veut refactorer du code avec Spark et on finit assez rapidement par :

soit avoir une SparkSession en implicit :

def superFonction(df: DataFrame)(implicit sparkSession: SparkSession): DataFrame = {
  ???
}

soit se retrouver avec d'autres implicits partout :

def superFonction2(df: DataFrame)(implicit sparkSession: SparkSession,
                                            config: com.typesafe.config.Config): DataFrame = {
  ???
}

soit des erreurs d'implicit quand on réarrange le code :

def groupByKeyRemoveNull[A, K](dataset: Dataset[A])(f: A => Option[K]): Dataset[(K, Seq[A])] = {
      dataset
        .flatMap(x => f(x).map(y => (y, x)))
        .groupByKey(_._1)
        .mapGroups({ case (k, it) => (k, it.map(_._2).toSeq) })
    }

Unable to find encoder for type (K, A). An implicit Encoder[(K, A)] is needed to store (K, A) instances in a Dataset. Primitive types (Int, String, etc) and Product types (case classes) are supported by importing spark.implicits._  Support for serializing other types will be added in future releases.
        .flatMap(x => f(x).map(y => (y, x)))

On va voir quelques astuces pour améliorer tout ça !

1re astuce : SparkSession est un membre de Dataframe/Dataset

On a rarement besoin d'avoir la SparkSession en implicit, elle est disponible sur les dataframes ou datasets en paramètre :

def superFonction(df: DataFrame): DataFrame = {
   val ss = df.sparkSession
   ???
}

2e astuce : Et si on faisait une classe ?

Dans beaucoup de base de code en Scala/Spark, pour passer/injecter les éléments de configuration supplémentaire, on peut être tenté d'utiliser le mécanisme des implicits, si cela revient trop souvent, cela va être plus cohérent d'utiliser une classe à la place.

Au lieu de faire :

object MonJob {
    def superFonction2(df: DataFrame)(implicit config: com.typesafe.config.Config): DataFrame = ???

    def superFonction3(df:DataFrame, i:Int)(implicit config: com.typesafe.config.Config):DataFrame = ???
}

on va avoir :

class MonJob(config: com.typesafe.config.Config) {
    def superFonction2(df: DataFrame): DataFrame = ???

    def superFonction3(df:DataFrame, i:Int):DataFrame = ???
}

2e bis : c'est mieux de typer un peu ses configurations

Les configurations Spark ou HOCON sont des formes de Json peu typé. Pour faciliter la maintenance et rendre le runtime plus robuste, cela peut valoir le coup de passer en mode structuré typé :

case class MonJobConfig(config1: String, config2: Int)

object MonJobConfig {
    def fromConfig(config: com.typesafe.config.Config): Try[MonJobConfig] = ???
}

class MonJob(config: MonJobConfig) {
    def superFonction2(df: DataFrame): DataFrame = ???

    def superFonction3(df: DataFrame; i:Int): DataFrame = ???
}

Aussi cela permet de valider la configuration du programme avant de démarrer les traitements (via MonJobConfig.fromConfig(...) qui renvoit un Try) et aussi de voir clairement quelle partie du programme utilise telle configuration. (alt+F7 sur IntelliJ, find usages)

3e : allo, il manque des encodeurs

Quand vous allez vouloir générifier du code en spark, il va vous manquer des implicits. Contrairement aux erreurs d'implicit classiques qui consistent à importer ss.implicits._, ici il faut récupérer les implicits manquants.

Dans la dernière version d'intelliJ, on peut voir les implicits "Show implicit hints"

IntelliJ est alors assez clair sur ce qui manque. On va ouvrir un troisième groupe d'arguments pour les récupérer (implicit xxx).

Puis rajouter tous les implicits manquant à ce groupe :

Une fois que c'est fini, on peut enlever le mode X-Ray-Implicit d'intelliJ et passer aux tests sur nos fonctions polymorphiques ([A,K]) de plus haut niveau (f: A ⇒ Option[K]) :

Conclusion

On a présenté deux trois astuces pour remettre au carré du code Scala qui utilise Spark, cela suffit à faire du code beaucoup plus propre dans de nombreux cas. Pour les autres cas, il faut souvent passer par la manipulation de schema avec spark, on va laisser ça pour d'autres articles sur le sujet !

Alignement de schémas (union)

2018-11-18T23:00:00Z

Il est parfois nécessaire de prendre des données qui viennent de sources différentes et de les combiner en une seule source. En SQL, pour ça nous utilisons UNION ou UNION ALL.

En Spark, nous pouvons faire de même. Néanmoins, cela ne marche pas toujours comme nous le pensons. L'union en Spark df1.union(df2) a le même comportement qu'en SQL, ce qui peut poser des interrogations lorsque l'on utilise les datasets (le mode "typé-scala" de Spark) : le code compile, mais nous pouvons nous retrouver avec une erreur au runtime (dans le driver) ou pire, avec une erreur silencieuse pour les plus chanceux.

En exemple

Nous allons manipuler des données qui ressemblent à A (avec deux champs b et c).

case class A(b: String, c: Long)

Créons deux Dataset[A].

val ds1 = smallDs(A("1", 2), A("3", 4))

Ici smallDs, qui derrière fait appel à session.sparkContext.parallelize(data, 1).toDS. Un show sur ds1 donne :

+---+---+
|b  |c  |
+---+---+
|1  |2  |
|3  |4  |
+---+---+

Voici le deuxième dataset.

val ds2: Dataset[A] = dfFromJson("{b:'5',c:6, d:7}", "{b:'8',c:9, d:10}").as[A]

+---+---+---+
|b  |c  |d  |
+---+---+---+
|5  |6  |7  |
|8  |9  |10 |
+---+---+---+

Nous pouvons noter déjà que ds2 n'a pas le même schéma que ds1 alors qu'il sont du même type. Si nous demandons à Spark de lire de la donnée et de nous retourner un type A en Scala, il vérifie juste si c'est possible de le faire au moment venu.

Par contre, si nous tentons l'union entre les deux datasets, cela ne va pas passer.

assertDsEqual(ds1.union(ds2), A("1", 2), A("3", 4), A("5", 6), A("8", 9))

Union can only be performed on tables with the same number of columns, but the first table has 2 columns and the second table has 3 columns

Une façon assez simple de régler le problème, dans ce cas spécifique, consiste d'enlever le champ en trop dans ds2.

val ds3: Dataset[A] = ds2.drop("d").as[A]
assertDsEqual(ds1.union(ds3), A("1", 2), A("3", 4), A("5", 6), A("8", 9))

Ça marchera, mais sans que nous n'ayons de véritable garantie sur l'ordre des champs restants.

Par exemple, si on tente ceci :

val ds3: Dataset[A] = ds2.select("c","b").as[A]
assertDsEqual(ds1.union(ds3), A("1", 2), A("3", 4), A("5", 6), A("8", 9))

ça compile, mais on se retrouve avec une erreur dans le driver :

Cannot up cast `c` from string to bigint ...

Néanmoins, si les datasets ont déjà le même nombre de champ, nous pouvons utiliser unionByName (depuis Spark 2.3.0) :

val ds3: Dataset[A] = ds2.drop("d").as[A]
assertDsEqual(ds1.unionByName(ds3), A("1", 2), A("3", 4), A("5", 6), A("8", 9))

Réglons le problème définitivement

Les opérateurs d'union existant sur les datasets ne sont pas suffisants aujourd'hui pour aligner des schémas. Ils nécessitent trop de manipulations manuelles.

En fait, ce que nous souhaitons, c'est une fonction de la forme :

def betterDatasetUnion[A](ds1:Dataset[A],ds2:Dataset[A]):Dataset[A]

Pour cette implémentation, nous allons nous baser sur le schéma de A, qui se récupère assez facilement via un Encoder[A], membre de Dataset[A].

val schema:StructType = ds1.exprEnc.schema

Le schéma nous donne les champs disponibles en utilisant schema.fieldnames. Ce sont en fait les champs de la case classe A.

val fieldnames = schema.fieldnames

Nous pouvons ensuite filtrer les dataframes avec les champs de la case class avant d'utiliser unionByName.

ds1.select(fieldnames).unionByName(ds2.select(fieldnames))

Moyennant quelques détails d'implémentations :

exprEnc est privé, nous utilisons alors un implicit pour le récupérer même s'il est déjà présent dans ds1,
select prend une liste de colonne.

def datasetUnion[A: Encoder](ds1: Dataset[A], ds2: Dataset[A]): Dataset[A] = {
  val exprEnc: Encoder[A] = implicitly[Encoder[A]]
  val name :: names = exprEnc.schema.fieldNames.toList
  ds1.select(name, names:_*).union(ds2.select(name, names:_*)).as[A]
}

Cette fonction nous permet de faire directement datasetUnion(ds1, ds2) sans autres manipulations.

La suite

Malheureusement, cela ne marche pas complètement, dès que nous utilisons des structures complexes, nous avons des erreurs comme celle-ci :

Union can only be performed on tables with the compatible column types. array<struct<b:string,c:bigint,d:bigint>> <> array<struct<b:string,c:bigint>> at the first column of the second table;;

Par exemple, si nous utilisons la case class E ci-dessous :

case class E(as: Seq[A], f: String)

val e1              = E(Seq(A("1", 2)), "3")
val ds1: Dataset[E] = smallDs[E](e1)
val ds2: Dataset[E] = dfFromJson("{as:[{b:'5',c:6, d:7}, {b:'8',c:9, d:10}],f:'11'}").as[E]

val res: Dataset[E] = datasetUnion(ds1, ds2)

Pour aller plus loin, nous pouvons utiliser ce que nous avons fait dans schema-utils, qui permet d'aller beaucoup plus loin et d'aligner une dataframe / dataset sur un schéma existant :

def deepUnion[A:Encoder](ds1:Dataset[A], ds2:Dataset[A]):Dataset[A] = {
  import io.univalence.schemautils.AlignDataframe 
  val schema = implicitly[Encoder[A]].schema 
  AlignDataframe(ds1,schema).union(AlignDataframe(ds2,schema)).as[A]
}

def deepUnion(ds1:Dataset[A], ds2:Dataset[A]):Dataset[A] = {
  import io.univalence.schemautils.AlignDataset 
  AlignDataset(ds1).union(AlignDataset(ds2))
}

(Schema-utils utilise Spark 2.4. Néanmoins, cette manipulation est possible en Spark 1.6 ou en Spark 2.x, la version 2.4 est par contre beaucoup plus efficace.)

Conclusion

Ce genre de problème n'est pas forcément complexe à résoudre, néanmoins cela rend l'utilisation de Spark moins intuitive.

Au Paris Scala User Group de septembre, Raphaël Luta et Choucri Fahed nous avaient fait un retour sur certains des problèmes qu'ils ont rencontrés en utilisant Spark au jour le jour, dont celui que nous venons de voir (union sur les RDD vs Dataset).

En attendant que la vidéo soit disponible sur la chaîne Youtube du user group, les slides de cette session sont disponibles :

Spark Dataset.pdf

https://drive.google.com/file/d/1dAkhMzk5UGzS0AmcyTxI5Fc_dR4PvqvV/view

PSUG #91 - Spark Dataset: je t'aime... moi non plus & Poupées Russes, Thu, Sep 27, 2018, 7:00 PM | Meetup

Bonjour à tou•te•s Pour ce meetup de septembre, Ebiznext nous accueille pour parler de spark avec Raphaël Luta & Choucri Fahed et de recursion schemes avec Valentin Kasas.

https://www.meetup.com/paris-scala-user-group-psug/events/254988502/

Paris Scala User Group

Partagez vos vidéos avec vos amis, vos proches et le monde entier

https://www.youtube.com/channel/UCzRgovSmXzR2exnlWrawesA/featured?cbrd=1&ucbcb=1

Raphaël Luta

https://twitter.com/raphaelluta

Choucri FAHED

https://twitter.com/choucrifahed

Deuxième article : Array ⇒ Denormalized #1

2018-11-13T23:00:00Z

Dans le précédent article, nous avons vu une première approche pour convertir un JSON en CSV avec Spark. Néanmoins, nous nous étions arrêtés aux structures imbriquées, mais en évitant le cas des array. Cette fois, nous allons nous attaquer à ce type de donnée.

Dans cet article, nous verrons progressivement une approche pour retirer les array des structures de données. Puis nous découvrirons un algorithme plus générique, fonctionnant dans les cas où sont présents plusieurs niveaux d'imbrication entre struct et array.

Partons d'un cas simple

Des structures de données contenant des array sont assez courantes. Par exemple :

{
  "firstname": "John",
  "lastname": "Doe",
  "contact": [
    { "type": "email", "value": "jdoe@mycompany.com" },
    { "type": "twitter", "value": "jdoe87" }
  ]
}

Vu de Spark, le document ci-dessus possède la schéma suivant (en se basant sur une description simplifiée en EDN) :

{:firstname string
 :lastname  string
 :contact   [{:type  string
              :value string}]}

Notre objectif consistera à retirer la partie array de contact pour remonter le struct sous-jacent. Pour cela nous allons utiliser la fonction explode de Spark. Cette fonction permet de partir d'une ligne contenant un array et de la découper en autant de ligne qu'il y a d'élément dans le tableau.

En appliquant explode au champ contact, nous obtenons le schéma suivant :

{:firstname string
 :lastname  string
 :contact   {:type  string
             :value string}}

Et en reconstruisant la structure à la façon de notre précédent article, nous avons le CSV suivant :

firstname, lastname, contact_type, contact_value
John,      Doe,      email,        jdoe@mycompany.com
John,      Doe,      twitter       jdoe87

Imbrication array et structure

Partons maintenant du document suivant et cherchons à le désimbriquer :

{
  "firstname": "John",
  "lastname": "Doe",
  "contact": [
    { "type": "email", "value": [{ "id": "jdoe@mycompany.com" }] },
    { "type": "internal", "value": [
        { "id": "jdoe-dev" },
        { "dept": "ops", "id": "jdoe-ops" }
      ] }
  ]
}

Le document ci-dessus possède du point de vue de Spark le schéma suivant :

{:firstname string
 :lastname  string
 :contact   [{:type  string
              :value [{:dept string
                       :id   string}]}]}

Il y a ici deux difficultés : 1/ nous sommes en présence d'un schéma imbriquant structure et tableau à plusieurs niveaux, 2/ le champ value n'a pas exactement la même structure d'une ligne à l'autre dans contact. Pour le second point, le champ dept n'est en effet présent que dans la dernière ligne.

Pour le premier point, il s'agira de détecter récursivement la présence de array et d'y appliquer le même principe vu précédemment (retirer le array et remonter le struct sous-jacent) en se basant sur explode. Pour le second point, Spark aligne automatiquement le schéma pour l'ensemble du document en recherchant un dénominateur commun. C'est ce que nous voyons dans le schéma précédent, où tous les champs value possède le champ dept (par défaut ce champ vaut null).

Voici le schéma de ce document vu par Spark :

{:firstname string
 :lastname  string
 :contact   {:type  string
             :value {:dept string
                     :id   string}}}

Du coup, un df.show(truncate = false) donne :

+---------+--------+-------------------------------+
|firstname|lastname|contact                        |
+---------+--------+-------------------------------+
|John     |Doe     |[email, [, jdoe@mycompany.com]]|
|John     |Doe     |[internal, [, jdoe-dev]]       |
|John     |Doe     |[internal, [ops, jdoe-ops]]    |
+---------+--------+-------------------------------+

Et en convertissant en JSON :

{"firstname":"John","lastname":"Doe","contact":{"type":"email","value":{"id":"jdoe@mycompany.com"}}}
{"firstname":"John","lastname":"Doe","contact":{"type":"internal","value":{"id":"jdoe-dev"}}}
{"firstname":"John","lastname":"Doe","contact":{"type":"internal","value":{"dept":"ops","id":"jdoe-ops"}}}

C'est en partant de cette idée que nous allons généraliser notre approche afin de faire disparaître les array dans un schéma.

Généralisation et algorithme

Pour présenter notre algorithme plus détailler, rentrons cette fois dans un cadre plus complexe avec plusieurs array définit dans le schéma au même niveau. Partons pour cela du schéma suivant :

{:a {:b {:c string
         :d [string]}}
 :e [{:f string
      :g [{:h string}]}]}

En première, nous allons renommer les champs avec des "symboles" différents et constituer une table de symboles. Cette permet d'éviter des cas de collision dans le cas où un même nom de champ se retrouverait dans deux sous-structures différentes. Utiliser des symboles différents permet de décider au dernier moment de la stratégie de gestion des collisions lors de la reconstitution des noms de champ.

{:a :field1
 :b :field2
 :c :field3
 :d :array4
 :e :array5
 :f :field6
 :g :array7
 :h :field8}

En se basant sur l'algorithme vu dans l'article précédent, nous aplatir une première fois les structures. Les arrays ne sont pas modifiés.

select a.b.c as field1,
       a.b.d as array4,
       e     as array5
from $input

{:field3 string
 :array4 [string]
 :array5 [{:f string
           :g [{:h string}]}]}

Nous utilisons ensuite explode_out pour faire disparaître le premier array de la structure. À la différence d'explode, explode_out permet de covserver les lignes où les array sont vides. La fonction met alors null comme valeur.

select                           field3,
        explode_outer(array4) as array4,
                                 array5
from $input

{:field3 string
 :array4 string
 :array5 [{:f string
           :g [{:h string}]}]}

Nous recommençons cette dernière opération jusqu'à ce qu'il n'y ait plus de array au premier niveau de la structure.

select                           field3,
                                 array4,
        explode_outer(array5) as array5
from $input

{:field3 string
 :array4 string
 :array5 {:f string
          :g [{:h string}]}}

Puis, sachant qu'il y a encore une sous-structure, nous recommençons un aplatissement.

select              field3,
                    array4,
        array5.f as field6,
        array5.g as array7
from $input

{:field3 string
 :array4 string
 :field6 string
 :array7 [{:h string}]}

Et la suppression des array du niveau supérieur.

select              field3,
                    array4,
                    field6,
        exlode_outer(array7) as array7
from $input

{:field3 string
 :array4 string
 :field6 string
 :array7 {:h string}}

Et ainsi de suite...

select              field3,
                    array4,
                    field6,
        array7.h as field8
from $input

{:field3 string,
 :array4 string,
 :field6 string,
 :field8 string}

Dès lors qu'il n'y a ni sous-structure ni array, nous arrêtons l'itération.

En utilisant la table de symboles, nous reconstruisons alors la structure.

select struct(struct(field3 as c, array4 as d) as b) as a,
       struct(struct(field6 as f, struct(field8 as h) as g) as e
from $input

{:a {:b {:c string
         :d string}}
 :e {:f string
     :g {:h string}}}

Conclusion

Nous venons de voir de manière détaillée comment l'algorithme derrière notre implémentation FlattenedNested fonctionne.

Dans l'article précédent, nous avons vu comment aplatir un dataframe en forme de JSON (Jsonoid) vers un dataframe en forme de table, mais sans prendre en compte les tableaux. Nous pouvons combiner ces deux techniques pour transférer l'intégralité d'un dataframe vers un système plus traditionnel (SGBD).

Dans les articles suivants, nous allons voir des versions configurables de ces algorithmes, afin d'aligner les structures de donnée entre différents systèmes.

Spark 2.4 : #TheWaitIsOver Tour d'horizon de la nouvelle version

2018-11-07T23:00:00Z

La version 2.4 d'Apache Spark est sortie fin octobre 2018. Cette version intègre de nouvelles fonctionnalités et son lot de correctifs. Ce qui inclut notamment la mise à jour des dépendances (Scala 2.12, Kafka 2.0), un support natif d'Avro, une amélioration du support de Kubernetes, de nouvelles opérations pour gérer les collections et autres types complexes en Spark SQL, une amélioration de l'API data source v2, ainsi que d'autres nouveautés.

Nous allons dans cet article passer en revue les nouveautés de la version 2.4. Nous verrons notamment que ces nouveautés apportent non seulement de meilleures performances, mais qu'elles offrent plus de flexibilités en termes de traitement des données.

Support de Scala 2.12

Spark 2.4 vient déjà avec le support très attendu de Scala 2.12. Cette version de Scala sortie en version stable il y a 2 ans a été mise à jour régulièrement : nous en sommes à la 2.12.7 depuis fin septembre (avec un bug fix spécifique pour Spark 2.4). Pour information, il est prévu que Scala 2.13 sorte prochainement en version stable.

Scala 2.12 inclut une meilleure intégration avec les nouveautés apportées avec Java 8 (correspondance directe entre trait côté Scala et interface côté Java, utilisation des types SAM, utilisation d'invokedynamic pour les lambda expressions), de nouvelles optimisations (inlining, allocations des closures, détection de code mort, suppression plus efficace des (un)boxing...) et pour ceux qui ont fait du typechecking leur ~~chemin de croix~~ cheval de bataille, la correction du bug SI-2712.

Vous trouverez plus de détails sur ces fonctionnalités sur le blog d'Ippon Technologies : partie 1, partie 2 et partie 3.

Spark sur Kubernetes

Depuis la version 2.3, les utilisateurs de Spark ont la possibilité d'utiliser Kubernetes comme orchestrateur, en alternative par rapport à Yarn, Mesos ou en mode standalone.

Le support de Kubernetes dans Spark permet aux développeurs de livrer des images Docker, à la place du traditionnel JAR déployé avec spark-submit. De plus, Kubernetes offre un grand nombre de facilités dans la gestion, l'orchestration et le monitoring d'un cluster, en le comparant avec Yarn. Il permet notamment la mise en place de quota sur les ressources du cluster, la gestion de namespace (pour avoir du multi-tenant sur le même cluster, par exemple), etc.

La version 2.4 de Spark ajoute d'autres possibilités. Tout d'abord, un support de PySpark (pour Python 2.x et 3.x) et un support de SparkR. Des templates de Dockerfile sont mis à disposition pour ces deux langages.

Un mode client est aussi proposé. Il s'agit de faciliter l'exécution d'outils interactifs, comme spark-shell ou les notebooks, depuis un pod géré par un cluster Kubernetes ou depuis une machine cliente hors du cluster Spark.

Support intégré d'Avro

Avro est un format binaire de sérialisation de données très utilisé dans le monde Big Data, avec Hadoop et Spark, mais en particulier avec Kafka pour les données temps réel.

Jusqu'à présent l'intégration d'Avro se faisait en passant par un addon mis à disposition par Databricks. Depuis la version 2.4 de Spark, Avro a été ajouté aux formats supportés par défaut (JSON, Parquet, JDBC, CSV, texte), en améliorant au passage les performances.

En plus de la lecture et l'écriture des données en Avro, deux fonctions sont mises à disposition pour Avro : from_avro et to_avro. Ces fonctions sont les équivalentes de from_jon et to_json. Elles permettent de respectivement lire (désencapsulation) et écrire des données Avro (encapsulation) dans les champs d'un dataframe.

Spark 2.4 supporte une version plus moderne d'Avro, la version 1.8.2. Cette version majeure d'Avro qui est apparue 2 ans après la version 1.7 (début 2016) a ajouté le support des types logiques(*), avec par défaut les décimales, les dates et les timestamps.

(* Il s'agit d'une mécanique similaire à d'autres formats de sérialisation comme EDN avec les tagged elements.)

Support de Kafka 2.0.0

La version du client Kafka est mis à jour et passe de la version 0.10.0.1 à la version 2.0.0.

Le support des nouvelles versions de Kafka permet la gestion des transactions de Kafka dans Spark Streaming [SPARK-25005]. Ce support permet de choisir de lire :

soit les messages non transactionnels et les messages dans les transactions commitées,
soit de lire tous les messages disponibles, même ceux qui sont dans des transactions encore ouvertes ou interrompues.

Cette fonctionnalité est activée dans Spark par la propriété kafka.isolation.level. Les valeurs possibles sont read_committed pour prendre uniquement en compte les données commitées et read_uncommited, qui est la valeur par défaut.

Voici un exemple de code permettant de lire un flux sur un topic Kafka. Nous ne considérons que les offset commités. Pour chaque message récupéré, nous tentons de convertir la valeur en Int.

Il reste néanmoins le support des headers Kafka à intégrer dans Spark. Cette fonctionnalité est en cours de développement [SPARK-23539].

spark
 .readStream
 .format("kafka")
 .option("kafka.bootstrap.servers", brokerAddress)
 .option("kafka.isolation.level", "read_committed")
 // from the beginning of the topic
 .option("startingOffsets", "earliest")
 .option("subscribe", topic)
 .load()
 .selectExpr("CAST(key AS STRING)", "CAST(value AS STRING)")
 .as[(String, String)]
 .flatMap({case (k,v) => Try(v.toInt).toOption})

Opération sur les collections

Une bonne partie des données à traiter à travers Spark transparaissent sous forme de structures imbriquées, incluant des collections (array) et autres types complexes (struct). c'est le cas en particulier dès lors que nous devons traiter des documents JSON, XML, certaines données remontées par Cassandra...

Jusque-là, Spark n'offrait pas de fonctions permettant de traiter le cas des collections. Il était alors nécessaire de passer par des UDF créés à la main pour transformer des colonnes dès lors qu'elles contiennent des listes ou des tables de propriétés, par exemple.

Depuis Spark 2.4, cela n'est plus une nécessité. Cette version fournit tout un ensemble de fonctions au niveau SQL et DataFrame pour gérer les types collection et les types complexes. En plus de faciliter la gestion des collections, ces fonctions sont aussi très performantes.

Enfin, cette fonctionnalité devrait faciliter d'autant plus l'adoption de formats contenant des structures imbriquées (disponibles à travers JSON, Avro, Cassandra...) et réduire très fortement le besoin de passer par des structures en Scala, Java ou Python pour traiter les données dîtes complexes.

Fonction d'ordre supérieur

Parmi ces nouvelles fonctions, nous avons la possibilité de pouvoir utiliser des fonctions dîtes d'ordre supérieur dans les requêtes SQL. Pour faire simple, une fonction d'ordre supérieur est une fonction qui prend en entrée une autre fonction. Ceci permet d'avoir des opérations génériques qui laissent au développeur le soin d'y intégrer un traitement spécifique par composition.

Par exemple, supposons que nous cherchons à incrémenter les entiers du dataset nested_data ci-dessous :

{ key: "a", values: [2,3,4] }
{ key: "b", values: [5,6,7] }

Avec Spark 2.4, nous pouvons écrire notre transformation directement dans la requête SQL en utilisant la fonction d'ordre supérieur transform :

SELECT  key,
        values,
        TRANSFORM(values, value -> value + 1) AS values_plus_one
FROM    nested_data

transform prend en entrée deux paramètres : values qui correspond à la collection à transformer et value → value + 1 qui représente le traitement spécifique à appliquer à chaque élément de la collection.

Avec l'exemple ci-dessous, nous obtenons donc :

{ key: "a", values: [2,3,4], values_plus_one: [3,4,5] }
{ key: "b", values: [5,6,7], values_plus_one: [6,7,8] }

Pour faire la même chose auparavant, il fallait passer par une UDF :

val aPlusOne: Seq[Int] => Seq[Int] =
  values => values.map(value => value + 1)

sparkSession.udf.register("aPlusOne",aPlusOne)

Et pour la requête SQL :

SELECT  key,
        values,
        aPlusOne(values) AS values_plus_one
FROM    nested_data

D'autres opérations d'ordre supérieur sont mises à dispositions :

filter : pour ne conserver que les éléments satisfaisant un prédicat.
aggregate : pour agréger les éléments d'une collection selon une fonction d'agrégation (à la manière de foldLeft en Scala).
zip_with : associe les éléments de deux collections de même indice et applique à ces éléments la fonction passée en paramètre pour les "fusionner".

Un peu plus pour les tableaux et les maps !

Cette version de Spark intègre aussi de nouvelles fonctions au niveau SQL et Dataframe pour la manipulation de tableaux et des maps.

array_union([1,2,3], [4,5,6])          = [1,2,3,4,5,6]
array_except([1,2,3], [4,3,2])         = [1]
flatten([[1,2,3], [4,5], [6]])         = [1,2,3,4,5,6]
array_repeat(2, 3)                     = [2,2,2]
arrays_zip([1,2] as i, ['a','b'] as j) = [{i:1, j:'a'}, {i:2, j:'b'}]
map_entries(map([1, 2], ['x', 'y']))   = [ROW(1, 'x'), ROW(2, 'y')]

La liste complète des fonctions ajoutées dans Spark est dans le ticket JIRA [SPARK-23899].

Data Source API v2

L'API Data Source est tout ce qui permet de lire ou écrire des données à travers Spark sur des systèmes de persistance (base de données, HDFS, Elasticsearch, Kafka...). La version précédente est simple et fonctionne dans la plupart des cas d'utilisation. Mais, elle est aussi fortement couplée avec l'API Spark de niveau supérieur (SparkContext, RDD, DataFrame), ce qui réduit la flexibilité de l'API Data Source en termes d’évolution. Elle ne permet pas non plus de bénéficier d'optimisations au niveau Spark, sachant qu'elle ne remonte pas d'informations du stockage physique comme le partitionnement ou l'organisation des données. Enfin, elle ne permet pas d'ajouter simplement de nouvelles opérations empilables (eg. filtrage, limitation de la quantité de données, échantillonnage...), elle n'offre pas de lecture en colonne et ne supporte le streaming.

Dans sa version actuelle Data source API v2 est avant tout un refactoring de la v1 qui permettra au fur et à mesure de faire évoluer plus rapidement l'API elle-même. Ainsi, la nouvelle API ne se base plus sur des trait Scala, mais sur des interface Java, pour des raisons d'interopérabilité. La nouvelle API s'affranchit de dépendances de l'API Spark et introduit la notion de InternalRow, pour des manipulations propres à l'API Data Source avant de passer au type Row.

Les évolutions de l'API sont à suivre dans le ticket Jira suivant : [SPARK-22386].

Et aussi…

Spark 2.4 inclut en plus :

Des améliorations dans PySpark, notamment en intégrant d'autant plus des UDFs Panda, déjà introduit dans la version 2.3, et aussi à travers la mise en place d'un modèle d'évaluation gloutonne (eager) pour les dataframe pour une meilleure expérience utilisateur dans le cadre par exemple de Jupyter (en utilisant la propriété spark.sql.repl.eagerEval.enabled).
Structured Streaming : les données de chaque micro-batch sont encodées dans un DataFrame et plus seulement dans un RDD.
Image Source : une fonction de lecture des images a été ajoutée dans Spark 2.3. En 2.4, il est possible de charger une image depuis spark.read.
Améliorations dans SQL : optimisations des drivers et amélioration des performances.
Parquet : passage à la version 1.10.0.
Lecteur ORC intégré et passage à la version 1.5.2.
Le Barrier Scheduling (qui fera à lui seul l'objet d'un autre article de blog, expliquant l'intérêt de cette fonctionnalité et son fonctionnement).

Conclusion

En mettant beaucoup de composants à jour (Avro, Kafka, Scala), les gains en performance et l'amélioration du support des types complexes. Cette version est définitivement à déployer très rapidement sur les clusters.

Certaines de ces fonctionnalités changent vraiment la donne et peuvent grandement améliorer les projets sur Spark.

Néanmoins, cette version est encore un peu jeune. Il convient de ne déployer que certains projets sur cette version en mettant à jour progressivement les autres projets dès que la 2.4.1 sera sortie.

JSON ⇒ CSV en Spark - Première approche

2018-05-10T22:00:00Z

Dans quelle mesure est-il possible de convertir une structure imbriquée (nested structure) pour obtenir une structure non-imbriquée (unnested structure) ? Cette question revient généralement lorsque nous essayons par exemple de convertir des données JSON en CSV. C'est un sujet qui peut se présenter dans le cadre de Spark.

Par exemple, nous pouvons avoir ce JSON représentant un employé :

{
  id: "ac23",
  person: {
    firstname: "John",
    lastname: "Doe",
  },
  job: "data engineer"
}

Son équivalent en CSV pourrait être :

id,   person_firstname, person_lastname, job
ac23, John,             Doe,             data engineer

Nous utilisons ici une simple concaténation des noms des champs permettant d'accès à un sous-niveau.

Si nous utilisons des Dataframe Spark, nous allons devoir en étudier la structure (le schéma) pour établir la conversion nécessaire. La particularité d'une structure imbriquée est que son schéma apparaît sous la forme d'un arbre. Pour retrouver le nom des champs, sachant que les valeurs se trouvent au niveau des feuilles, nous devrons donc effectuer un parcours en profondeur pour constitué le nom des champs de la structure non-imbriquée.

Par exemple, la structure ci-dessous :

* a
| * b
| | * d
| | | * e
| | | * f
| | * g
* h

Peut donner les champs suivant :

a_b_d_e, a_b_d_f, a_b_g, h

Si nous utilisons _ pour joindre le nom des champs.

Voici le code permettant de parcourir la structure imbriquée :

def walk(structure: StructType,
         prefix: Vector[String] = Vector.empty): Seq[Vector[String]] =
  for {
    field <- structure.fields
    fieldPath <- field.dataType match {
      case subStruct: StructType => walk(subStruct, prefix :+ field.name)
      case _: ArrayType          => Nil
      case _                     => List(prefix :+ field.name)
    }
  } yield fieldPath

À noter, que dans cette version, nous nous intéressons qu'aux StructType (équivalent Dataframe des objets JSON) et nous supprimons les ArrayType.

La conversion de structure imbriquée en structure non-imbriquée est faite donc en appelant notre fonction walk sur le schéma du Dataframe récupéré. Les différents noms de champ sont joints par un . pour le parcours dans le JSON et par un _ pour obtenir leur équivalent en nom de colonne CSV.

import org.apache.spark.sql.functions.expr

for {
  fieldPath <- walk(schema)
} yield {
  val fieldref: Column = expr(fieldPath.names.mkString("."))
  val name: String     = fieldPath.names.mkString("_")

  fieldref.as(name)
}

Nous avons vu ici une approche permettant de convertir une structure imbriquée (de type JSON) en structure non-imbriqué (de type CSV). Une simple analyse structurelle permet de réaliser cette conversion. Néanmoins, nous ne traitons pas ici de certains aspect comme la gestion des array et nous laissons Catalyst inférer le DataType. Ces points seront traités dans un autre article.

Cet article se base sur le code donné dans ce repo :

schema-utils/src/main/scala/io/univalence/schemautils/JsonoidToTable.scala at master · univalence/schema-utils

Experiences avec Spark sur les schémas. Contribute to univalence/schema-utils development by creating an account on GitHub.

https://github.com/UNIVALENCE/schema-utils/blob/master/src/main/scala/io/univalence/schemautils/JsonoidToTable.scala

Blog d'Univalence

Focus sur le Z-Ordering et le Liquid Clustering avec Delta Lake

Z-Ordering

Data-skipping

Compaction

Illustration

OK, mais comment cela fonctionne à partir de 2 colonnes ?

Comparaison

Quand l’utiliser ?

Pour aller plus loin

Liquid Clustering

Courbe de Hilbert

Comparaison

Incremental Clustering

Quand l’utiliser ?

Pour aller plus loin

Conclusion

Créer ou modifier un tableau croisé dynamique à partir de ses données Spark avec Apache POI

Configuration

Comment créer un fichier Excel à partir de mes données Spark ?

Comment faire pour créer un tableau croisé dynamique avec Apache POI ?

Comment faire pour modifier un fichier Excel déjà existant avec mes données ?

Conclusion

Retour sur ScalaIO 2024

Les talks

Keynote d’ouverture - Une autre introduction aux GADTs de Xavier Van de Woestyne :

Songwriting in Scala - Creating a DSL for writing Music with ADT's de Paul Matthews, la présentation Rock ! :

Scala 3 Compiler Academy Journey de Anatolii Kmetiuk

Et plein d’autres présentations !

Le reste, comment c’était ?

Double jointures dans Kafka Streams

Intention

Jointure KTable-KTable

Pouvons nous faire mieux ?

Encore mieux ??

Scala côté frontend grâce à Laminar

Pourquoi ScalaJS ?

L’écosystème de ScalaJS

Créer votre site internet avec Laminar

Implémentation d’un générateur de nombre aléatoire

Les tradeoffs

Conclusion

Comment la génération de code de zio-spark fonctionne

Introduction

La méthode naïve

La génération de code

Le plugin SBT

Scalameta à la rescousse

Du code custom dans du code généré

Créer nos propres fonctions

Éditer manuellement des fonctions existantes

Insérer du code custom dans la génération

Conclusion

Introduction a zio-spark

Introduction

Installation

Avantages liés à ZIO

Planification des jobs

Gestions des erreurs

Parallélisation des jobs

Qu’est-ce que zio-spark apporte en plus ?

Une API plus plaisante et safe

Une intégration pensée pour ZIO

Conclusion

Configurer RouterOS comme client WireGuard

Pré-requis

Obtenir une configuration cliente

Configurer WireGuard dans RouterOS

Avec Winbox

Ajouter l’interface WireGuard dans RouterOS

Ajouter le Peerdans RouterOS

Ajouter l’adresse dans RouterOS

Avec la console

Ajouter l’interface WireGuard dans RouterOS

Ajouter le Peerdans RouterOS

Ajouter l’adresse dans RouterOS

Configurer RouterOS comme client OpenVPN

Pré-requis

Configuration requise du serveur OpenVPN

Obtenir un fichier client.ovpn

Ajouter le `Peer`dans RouterOS

Ajouter le `Peer`dans RouterOS

Obtenir un fichier `client.ovpn`

Niveau 1 : `Join`