Ingestion de Data Lake, quelques bonnes pratiques

La création d’un Data Lake demande de la rigueur et de l’expérience. Voici plusieurs bonnes pratiques autour de l’ingestion des données en batch et en flux continu que nous recommandons et mettons en place lorsque nous accompagnons nos clients.

Objectifs

Un Data Lake en production représente beaucoup de jobs, souvent trop peu d’ingénieurs et une énorme quantité de travail. Il y a donc un besoin de :

• Améliorer la productivité
  Écrire de nouveaux traitements et de nouvelles fonctionnalités doit être agréable et les résultats doivent s’obtenir rapidement.
• Faciliter la maintenance
  Il doit être simple de mettre à jour un job déjà en cours d’exécution quand une nouvelle fonctionnalité doit être ajoutée.
• Facilité d’exploitation
  Le job doit être stable et prédictif, personne ne souhaite être réveillé la nuit pour un job qui rencontre des problèmes.

Pattern et principes

Afin d’améliorer la productivité, il faut faciliter la collaboration entre les équipes. Cela implique la mise en pratique de patterns favorisant le développement de code réutilisable, partageable entre les équipes, ainsi que la conception de briques élémentaires sur lesquelles on pourra construire des systèmes plus complexes. Ces briques sont soit des API dans une approche Web-Service, soit des bibliothèques de programmation conçues collaborativement.

Ces patterns doivent bien sûr être en phase avec les décisions stratégiques, mais doivent aussi :

• Être dictés par des cas d’usage réels et concrets
• Ne pas être limités à une seule et unique technologie
• Ne pas se baser sur une liste figée de composants qualifiés

Le Big Data est en constante évolution. Le traitement batch est très différent aujourd’hui, comparé à il y a 5 ans, et est actuellement en lente maturation. À l’inverse, le traitement streaming est en pleine transformation et concentre la majeure partie de l’innovation. Pour ces raisons, les architectures Big Data doivent évoluer dans le temps.

Découpler l’ingestion de donnée

L’ingestion de données doit être indépendante des systèmes de traitement. Par exemple :

• Une chaîne d’ingestion repose sur NiFi ou sur une application Spark
• Elle alimente un entrepôt Hive
• Les traitement sont écrits sous forme de requêtes HQL (Hive) ou bien en Spark.

Gérer l’incident

Les jobs doivent être développés avec une couverture de tests unitaires et d’intégration maximale. Cependant, le risque qu’un workflow échoue n’est jamais nul. Le débogage en production n’est pas chose aisée. La cause primaire (root cause) peut venir d’un changement de la donnée, d’une condition dans un code qui n’a jamais été qualifié ni observé, ou d’une modification du cluster.

Analyser la root cause nécessite des capacités cruciales. D’une part, l’intervenant doit être en capacité d’effectuer très rapidement des requêtes ad hoc ou analytiques sur le dataset d’entrée, intermédiaire ou final. Si le workflow fonctionnait la veille, il faut alors être en capacité de le rejouer sur ces données afin de pouvoir discriminer les données ou inversement l’infrastructure.

Schéma gouvernance

Voici quelques exemples de questions soulevées par le partage de schémas :

• Que signifie votre donnée ?
• Peut-elle être jointe avec une autre (“FrankenData”) ?
• Quels sont les attributs en commun entre deux jeux de données ?
• L’évolution du schéma entraîne-t-il des disruptions ?

Sélection d’un format commun

Il est important de communiquer avec un format commun. Il est tout à fait acceptable d’avoir plusieurs formats pour le même jeu de données, par simplicité ou pour des besoins de performances, mais il est nécessaire de pouvoir se reposer sur un format que tout le monde comprend. Les rares exceptions sont dues à des volumétries très fortes qui imposent la sélection d’une unique instance du jeu de données dans le format le plus optimisé possible.

Dans le monde de la donnée, les deux formats d’échange les plus communs sont Avro et Protocol Buffer. Dans l’écosystème Big Data, les formats de stockage les plus communs et compatibles avec les contraintes d’un format d’échange sont Avro, SequenceFile et JSON.

Avro est le format le plus plébiscité et offre les fonctionnalités suivantes :

• Structure de données riches et flexibles.
• Format compacte, rapide et binaire.
• Fichier avec un espace conteneur pour le stockage de données persistentes.
• Auto-décrit
• Evolution des schémas en douceur, résolution et détection de conflit
• Reflect Datum Reader pour la génération depuis des classes Java de schémas et de protocoles
• Flexible et adapté à des jeux de données en batch et des messages en streaming

Avro est un format de fichier adapté à l’échange d’information. Il peut être complété par une copie dans un format adapté à certains framework comme l’ORC qui atteint une plus forte compression et de meilleures performances dans Hive.

Le format doit être utilisable à la fois dans les architectures Batch et Stream.

Partage du schéma

Le schéma ne s’arrête pas au Data Lake et doit être accessible et partagé par tous les acteurs. Les données structurées doivent être associées à un schéma présent dans un registre officiel. Un espace doit centraliser la gestion des schémas en vue de leur stockage, de leur consultation et de leur mise à disposition dans le Data Lake.

Le schéma peut porter des informations complémentaires par exemple pour faciliter le mapping vers JSON ou une base de données.

L’utilisation de base de données qui n’imposent pas un schéma strict ne signifie pas qu’un schéma ne s’applique pas aux données. Par exemple, l’essentiel des données stockées dans ElasticSearch ou HBase est de nature structurée.

La publication du schéma et l’inter-convertibilité entre Avro et JSON permet à plusieurs populations de parler le même API. Ainsi, le data modeler parle des mêmes champs que le data engineer et le développeur frontend. Tout le monde parle une même langue ce qui améliore la communication au sein de l’entreprise.

Dans les dernières distributions HDP et HDF, Hortonworks Schema Registry fournit un référentiel partagé de schémas qui permet aux applications d’interagir de manière flexible les unes avec les autres afin de sauvegarder ou de récupérer des schémas pour les données auxquelles elles ont besoin d’accéder. Disposer d’un registre de schémas commun fournit une gouvernance de données de bout en bout en fournissant un schéma réutilisable, en définissant des relations entre les schémas et en permettant aux fournisseurs de données et aux consommateurs d’évoluer à une vitesse différente.

Évolution des schémas

Les changements appliqués aux schémas doivent être propagés en continu. Avro supporte les évolutions backward et forward. Grâce à la compatibilité backward, un nouveau schéma peut être appliqué pour lire les données créées à l’aide des schémas précédents. Grâce à la compatibilité forward, un schéma plus ancien peut être appliqué pour lire des données créées à l’aide de schémas plus récents. Il est utile lorsque le schéma évolue. Les applications peuvent ne pas être mises à jour immédiatement et doivent toujours lire des données dans un nouveau schéma sans tirer le bénéfice de nouvelles fonctionnalités.

Le support d’Avro pour l’évolution de schémas implique que les consommateurs ne sont pas impactés par une évolution et peuvent continuer à consommer les données. En cas d’évolution non résolue, la chaîne d’ingestion doit être interrompue et une solution manuelle mise en place.

Le processus d’ingestion doit être générique et s’appuyer sur la définition des schémas. Cela implique que les évolutions de schéma sont automatiquement propagées à l’ingestion.

Publications et notifications

L’ingestion est un ensemble de processus coordonnés et séquencés. Un système de notification est nécessaire pour informer d’autres applications de la publication de données dans le Data Lake (HDFS, Hive, HBase, …) et pour enclencher d’autres actions.

Par exemple, une application consommatrice émet une requête demandant une donnée avec un certain statut, la date d’aujourd’hui, et reçoit une notification dès que la donnée est mise à disposition.

L’ordonnancement des applications gagne alors en flexibilité et en réactivité. Le traitement est déclenché une fois la donnée qualifiée et consommable, et ne nécessite pas l’ordonnancement de procédures de reprise en cas de retard dans la phase d’ingestion.

L’ensemble des flux, des consommateurs et des éditeurs constitue une cartographie des flux d’échange et renforce la traçabilité.

Conclusion

Cet article n’a pas vocation d’être une liste exhaustive de bonnes pratiques mais couvre néanmoins de nombreux aspects. Parmi les sujets traités, citons la gestion d’incident, la sélection d’un format commun, le partage et les évolutions de schéma ou encore la publication des données ingérées.