Un DSL (Domain Specific Language) comme Pivot de votre Data Quality

Un DSL pour décrire la qualité de données !

Voici un article qui introduira progressivement une initiative Novagen :

Comment piloter sa qualité de données dans un datalake avec Spark.

Première étape : comprendre et apprécier ce qu’un DSL apporte dans la description des sources de données et dès l’application des règles de cohérence.

Un DSL, qu’est-ce que c’est ?

DSL signifie Domain Specific Language. Autrement dit il s’agit, en informatique, d’un ensemble restreint de vocabulaire et de règles de grammaire qui permet de répondre à un besoin précis de description ou d’organisation de l’information.

JSON ou XML seuls ne sont pas des DSL en soi. Ce sont des formalismes de structuration de langage, mais ils n’apportent pas spécialement de cohérence et de contrôle dans les informations saisies.

A partir de ces quelques éléments de langages ‘rudimentaires’, nous allons être capables de décrire de manière formelle une configuration, un ensemble d’informations structurées.
Un exemple parlant est celui dela librairie kotlinx.html (https://github.com/Kotlin/kotlinx.html ) qui repose de manière quasi masquée sur la puissance d’un langage typé (kotlin en l’occurrence) pour concevoir du code HTML.

On peut observer la clarté évidente de l’écriture qui ne limite pas la capacité à introduire des éléments dynamiques.

Il est possible de créer des DSLs avec différents langages. cela est possible en python, en Groovy et surtout en Scala, qui offre le plus de possibilité d’expressivité. Pour des raisons qui débordent de cet article, nous avons retenu Kotlin dans notre projet.

Les qualités intrinsèques d’un DSL :

Il structure la saisie des informations en garantissant la correction du contenu.
Si on prend notre exemple de la page HTML, on pourrait la truffer de balises incongrues, enchevêtrées, qui complexifierait le débogage….. Autant introduire dès la saisie une assistance qui simplifie l’écriture en même temps qu’elle la valide.
Un bon DSL doit rester lisible, dédié à la thématique traitée, et en cela doit limiter l’usage de structures complexes de code: notre but est de le mettre entre les mains de non-spécialistes du code, ou bien de soulager la charge d’écriture de l’information. Notre DSL doit être SIMPLE, CONCIS, LISIBLE ! aussi proche que possible du langage naturel.

Des avantages collatéraux très appréciables :

puisqu’on associe un langage de programmation à notre DSL, on bénéficie également de :

Factorisation : plutôt que de procéder par copier-coller, on peut réutiliser à l’envi des portions de déclarations,
Versatilité : outre le côté déclaratif, on peut ajouter des fonctions de cohérence, de bonnes pratiques (par exemple calculer le nombre d’imbrication de notre arbre HTML) ou encore multiplier les déclinaisons de sortie (HTML, JSON, …)

Notre sujet : créer un DSL pour décrire une source de données !

Pourquoi coder la qualité ?

A travailler sur les plateformes Data de nombreux clients, Novagen constate que les équipes de Data Scientists et Data Ingénieurs perdent un temps et une énergie très conséquents par manque de qualité des données.

Pour remédier à cela il faut :

⇒ Encourager la progression de la qualité des données en mobilisant les responsables : corriger dès la source les informations qui n’ont pas le niveau requis,
⇒ Rejouer continuellement la mesure de qualité des données,
⇒ Factoriser les déclarations, encourager la réutilisation des descriptions de données.

… certes, il existe des ateliers graphiques de description des flux et de gestion de la qualité. Mais, entre autres inconvénients, ils sont affaires de spécialistes, ils sont coûteux, et ils induisent une stack technique qui n’est pas nativement en ligne avec les technologies utilisées au coeur des Datalakes.
En revanche, en adoptant une approche centrée sur le code on a toute latitude pour réutiliser ces informations pour de multiples usages en s’appuyant sur les forces de Apache Spark et des technologies Clouds(AWS | Azure | GCP | OpenShift | …)

De là a germé l’idée qu’on pouvait décrire tous les jeux de données de manière centralisée. Utiliser à cet effet un DSL nous apportera les différents bénéfices exprimés ci-dessus.

Dans l’approche présentée ici, nous associons une source de données ( SourceDetail ) à un Processus de gestion de la qualité (un FSimpleProcess) . Cette source possède quelques attributs descriptifs ( nom, nom de la table à créer par Spark, chemin d’accès), des options Spark de chargement, ainsi qu’une liste descriptive des champs ou colonnes constitutives (FieldDeclaration). Au niveau de ces colonnes on applique différentes contraintes (ConstraintDeclaration).
En voici un exemple :

Quelques considérations sur cet exemple :

Nous limitons drastiquement les erreurs de saisie(Bien que nous puissions aller encore plus loin dans la limitation des valeurs libres.)
Les informations sont lisibles, compréhensibles,
On peut se projeter sur une réutilisation de l’objet SourceDetail : il pourra être impliqué dans différents processus.

La boîte à outil de Kotlin pour créer un DSL

Parmi les instructions du langage dédiée au DSL, on peut mettre en avant :

la notation infix qui, dans le cas particulier de méthodes à un argument, soulage l’écriture de parenthèses,
la méthode apply qui retourne l’objet appelant (un peu comme un return this) après la série d’instructions. On peut chaîner différents blocs d’instruction de manière fluide
les fonctions d’ordres supérieur, c’est à dire dont les arguments peuvent être d’autres fonctions,
Ou encore, la possibilité de sortir des parenthèses le dernier argument d’une fonction, si et seulement si il s’agit d’une lambda (Passing a lambda to the last parameter)

Mis en oeuvre dans la déclaration de la classe FSimpleProcess, ceci nous donne :

Cette déclaration est très simple, mais on peut identifier au passage une méthode validate, non appelée pour l’instant, qui nous permet d’ajouter un ensemble de fonctions complémentaires qui vont au delà de l’aide à la saisie (vérifier qu’il n’y a pas de doublons dans les champs déclarés, valider qu’une contrainte minimale n’est pas supérieure à une contrainte maximale….).

ET MAINTENANT ?

Nous avons montré qu’on pouvait mettre au point un DSL pour structurer et normaliser l’information de manière sûre et élégante.
Cette information sera notre pivot pour la suite :

nous pouvons la sérialiser et la désérialiser, par exemple pour intégrer ces définitions dans un référentiel (Systèmes de Fichier ou toute base de données – orientée document-)
Nous pouvons générer une documentation HTML parfaitement à jour.

Pour ces deux premiers points nous développons une classe Utilitaire dédiée. (à l’intérieur de laquelle on invoque le DSL pour produire du HTML)

Et surtout, nous allons développer tout notre processus de qualité sur la base de ce catalogue :

A SUIVRE…
Quelques liens utiles