Tallk présenté à Devoxx avec Bachir Ait M'Barek : https://www.linkedin.com/in/baitmbarek
C’est la révolution dans la BI, les zones tampon FTP laissent la place aux systèmes de fichier distribués, le SQL s'exécute sur Hadoop, les dashboard en HTML5 remplacent les clients lourds, mais ne peut-on pas rationaliser un peu l’approche ?
Comment s’y prendre pour transformer une chaine BI en datalake ?
Cette université fera le tour de l’ingénierie des données en mode BigData. Au travers d’une présentation détaillée des concepts, de retour d’expériences et d’un cas pratique, nous allons découvrir :
les technologies et l’architecture, avec Spark, Kafka, Elasticsearch, Impala et Mesos,
et les méthodes associées : cycle de développement avec Hadoop, tests unitaires, jointures, gestion de la qualité de donnée, recette en mode Big Data et gestion des métadonnées.
2. #DevoxxFR
Introduction
Sujet : BI Big Data de bout en bout
Objectifs :
● Comprendre la nature de la BI et du Big Data
● Cartographier l’espace technologique
● Utiliser Spark pour créer un premier Datalake
● Approcher différentes méthodes de travail
2
3. #DevoxxFR
Jonathan Winandy
@Ahoy-Jon
Ingénieur Data :
● Création de DataLake,
● Audit/Coaching,
● Formation Spark/Scala/Kafka.
Fondateur d’Univalence (BI / Big Data)
Co-fondateur de CYM (Maintenance Prédictive)
et Valwin (Données de santé)
A propos de nous
3
UNIVALENCE
Data made simple!
4. #DevoxxFR
Bachir Aït M’Barek
Ingénieur Data :
● Création de DataLake,
● Expert BI BigData.
Datastage, SQL, Java, JS, Scala, Spark, ElasticSearch, Impala,
MongoDB, Kafka
A propos de nous
4
5. #DevoxxFR
A propos de nous
5
Travail sur la (re)création du Datalake Audience
de Solocal.
En 18 mois, on a réussi à :
● Remapper complètement un DWH (+400 champs)
● Améliorer le Lead Time d’un reporting clé de 40j à J+1
● Améliorer le Lead Time de l’intégration de données
journalières de 4h à 20 minutes
● Décommissionner les chaînes BI existantes
6. #DevoxxFR
Plan
● BI & Big Data
● Data & metadata
● Technologies
● Collecte / Staging
● DWH (Big Data) avec Spark
● Datamart (Big Data) / Reporting
● Techniques avancées
6
10. #DevoxxFR
Le Big Data comme (nouvelle) solution aux
problématiques BI
Attentes fortes des DSI :
● Remplacer ses systèmes verticaux
● Gagner en performances
● Mettre fin aux “datamarts en silo”
● Maîtrise du budget
Attentes fortes des métiers :
● Se poser des questions plus larges
● Exploiter des données délaissées
● Améliorer ciblage et % de conversion
● Créer de nouvelles offres
● Identifier risques et opportunités
10
16. #DevoxxFR 16
La plupart des données sont soit en :
● CSV (ou forme proche),
● JSON (ou forme proche)
sans plus d’importance, alors que les données
manipulées sont traitée :
● par plusieurs programmes,
● et par plusieurs intermédiaires,
● pour de nombreuses années.
Encodage
20. #DevoxxFR
Metadata : Data Breadcrumbs
20
Données issues des données et de leurs traitements :
● Les schémas,
● L’emplacement des datasets,
● La provenance,
● Le rejeu d’un job,
● ...
La collecte et la réutilisation de la métadonnée permet de
raisonner sur le cycle de vie de la data.
22. #DevoxxFR 22
● Agent de message distribué
● Basé sur le concept de commit log
● Tolérant à la panne
● Il permet :
○ A des nouveaux programmes de consommer de
d’anciens messages.
○ de garantir que tous les messages qui concernent une
même entité (clé) se retrouvent au même endroit.
Apache Kafka
23. #DevoxxFR
Apache Kafka
23
Découplage fort à tous les niveaux. Les
producteurs et les consommateurs n’ont
pas besoin :
● de se connaître,
● d’être là en même temps.
Le modèle est simple :
● chaque topic est une séquence de partitions
● chaque partition est une séquence de messages
24. #DevoxxFR 24
● Moteur de calcul distribué
● Multi paradigmes :
○ Fonctionnel
○ Relationnel
○ Graphe
● Compatible avec beaucoup de sources de données
● En mémoire
● Optimisations très avancées des requêtes relationnelles
Apache Spark
25. #DevoxxFR 25
Apache Spark
Le programme ne tourne pas sur le cluster de
calcul, ce qui permet de piloter à distance les
calculs distribués, par exemple dans une
application de tableau de bord.
Spark permet à plusieurs paradigmes d’être composé
entre eux. On peut par exemple faire du
SQL -> Scala/Python -> ML -> SQL !
26. #DevoxxFR
● Moteur de requêtage interactif.
● Ne se base pas sur MR
● Nombreux DataTypes, dont les nested types
● Jointures entre tables possibles
● Indexation impossible mais Partitionnement possible
● Peut bénéficier du cache HDFS
● Query Optimizer peut s’appuyer notamment sur table stats
26
Impala (incubating)
32. #DevoxxFR
Collect / Staging
32
La donnée en mouvement,
il faut la canaliser !
Grâce au technologie du BigData, nous
sommes passé d’une collecte de données
transiente à des zones d’assemblage
persistantes.
33. #DevoxxFR
Cinématique
33
Avec Kafka, on peut gérer
explicitement la cinématique
des données en temps réel.
Avec Hadoop, on va accumuler
toutes les données et émincer à
la lecture.
35. #DevoxxFR
DWH Big Data
35
Le DWH Big Data est transient !
Il est reconstruit au besoin à partir de la zone
d’assemblage.
Les jobs sont en capacité de tout reconstruire.
41. #DevoxxFR
(Inlined) Staging
41
Dans la staging, on redonne la structure
naturelle à la Data :
● renormalisation
● décodage nombres/dates/embarqués
● enrichissement technique
Le but est d’obtenir la donnée, telle que l’on
aurait dû l’avoir !
42. #DevoxxFR
Test unitaire / cas isolé
42
L’idéal pour les tests est d’avoir une boucle de
rétroaction ultra rapide. La méthode :
1. Isolation d’un cas (cogroup + prédicat),
2. Sérialisation dans le repo du projet,
3. Chargement du cas dans un test,
4. Reproduction du bug,
5. Correction !
6. On recommence !
43. #DevoxxFR
Business rules
43
A partir du modèle d’assemblage, on crée le
modèle métier. Les étapes :
1. ajout des règle métier,
2. unification,
3. enrichissement,
4. mise en contexte.
46. #DevoxxFR
Techniques avancées
46
Voici quelques techniques avancées qui font la différence :
● Gestion de la qualité de donnée intégrée
● Recette incrémentale automatique
● Catalogue, ordonnancement, continuous
delivery à l’aide des métadonnées
47. #DevoxxFR
Annotations
47
La qualité de données est mise en place dans
un seconde temps. Hors les bugs dans les
pipelines sont très souvent des bugs de Data.
Notre solution est de calculer la qualité de la
data dans le job !
48. #DevoxxFR
Annotations
48
En programmation standard, une fonction f retourne :
● soit f(x),
● soit une erreur.
En data, ce n’est pas assez pragmatique, on doit pouvoir
émettre des avertissements, c’est à dire que pour f, on a :
● soit f(x)
● soit f(x) et des avertissements,
● soit une erreur et des avertissements.
49. #DevoxxFR
Annotations
49
Result compose fonctionnellement et
permet de définir un DSL :
case class Result[T](
value: Option[T],
annotations: Seq[Annotation])
case class Annotation(
msgCode: String,
sourceData: Seq[String],
ids: Seq[EntityId])
case class EntityId(
idType: String,
idValue: String)
case class HCommand(name: String,
status: String, commandId: Int)
val commandId: Result[Int] =
commands.extractUniqueF(_.commandId)
val name: Result[String] = data.name.notEmpty
val status: Result[String] =
data.status.inEnum(Seq("DONE","IN_PROGRESS"))
HCommand.build(name = name,
status = status,
commandId = commandId)
51. #DevoxxFR
Differential QA
51
La recette incrémentale automatique permet
de vérifier que la mise à jour d’un job ne fait
pas évoluer la data de manière anormale.
Cela permet de vérifier rapidement que des
KPI ne vont pas être impactée par la nouvelle
version.
53. #DevoxxFR
Metadata avancée
53
Un moyen pour améliorer fortement un Datalake,
c’est de gérer la métadata explicitement.
L’accès unifié à la métadonnée permet de créer des
jobs qui ont des niveaux différents d’abstraction.
Level 0 Commit Logging / Event Sourcing
Level 1 Name resolving
Level 2 Triggered exec (schema capture, deltaQA, …)
Level 3 Scheduling (replay, coherence, ...)
Level 4 “code as data” (=> continuous delivery)
55. #DevoxxFR
Ressources
55
● Code source de la présentation :
https://github.com/baitmbarek/spark-adabra
● Centrifuge, Data quality for Spark :
https://github.com/univalence/centrifuge