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.

1. #DevoxxFR
SPARK-ADABRA : COMMENT
CONSTRUIRE UN DATALAKE !
1

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

7. #DevoxxFR
Business Intelligence
&
BigData
7

8. #DevoxxFR
L’évolution de la BI
8

9. #DevoxxFR
Maturité des
solutions BigData
Naissance du
concept de BI Début de
l’informatisation
Normalisation
Emergence de la BI
“traditionnelle”
Infocentres dédiés
Remise en
question
9

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

11. #DevoxxFR 11

12. #DevoxxFR
Datawarehouse vs Datalake
12

13. #DevoxxFR
Qu’est-ce ?
13

14. #DevoxxFR 14
Pipeline d’alimentation du lac
Collecte Nettoyage & Calculs Stockage
Exploitation
Visualisation
Exploration

15. #DevoxxFR
Data & Metadata
15

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

17. #DevoxxFR 17
Caractéristiques des encodages :
● Binaire
● Imbriqué
● Avec schéma
● En Colonne
Encodage

18. #DevoxxFR 18
Encodage
CSV/TSV Json XML ORC Avro Parquet
Binary X X X
Nested X X X X
Schema X X X X
Columnar X X

19. #DevoxxFR
Imbriqué ?
19
€
€
€
€
€

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.

21. #DevoxxFR
Technologies
21

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)

27. #DevoxxFR 27
JDBC / ODBC
Impala-shell
HUE
Impala (incubating)

28. #DevoxxFR
Apache Impala - Requêter des types complexes
28
€
€
€
€
€

29. #DevoxxFR
Apache Impala - Requêter des types complexes
29
SELECT * -- cmd.*, lc.*
FROM commandes cmd,
cmd.lignesCommande lc
WHERE cmd.idCommande = 'CMD1' AND lc.prix > 50;
€
€
€

30. #DevoxxFR
Elasticsearch / Kibana
30

31. #DevoxxFR
HDFS
31
Système de fichier distribué orienté Big
Data.
Stockage à très haute densité.
Colocalisation des traitements avec la
donnée.

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.

34. #DevoxxFR
Persistance
34
L’ensemble des données
doit être accessible comme
une structure de donnée
persistante.
Pas de mises à jour directe
Pas de datasets incomplets
Pas de mutations ...

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.

36. #DevoxxFR
Structure d’un Job
36
DS1
DS2
...
cogroup
staging
modeling
projection
G
S
H O
Le Job va être divisé en plusieurs
étapes, pour traiter les
problématiques séparément.

37. #DevoxxFR
Structure d’un Job
37
DS1
DS2
...
cogroup
staging
modeling
projection
G
S
H O
grouper la donnée
redonner la structure naturelle
unifier / enrichir

38. #DevoxxFR
LIVE CODING
38

39. #DevoxxFR
Cogroup
39
from (left:RDD[(K,A)],right:RDD[(K,B)])
○ join : RDD[(K,( A , B ))]
○ leftJoin : RDD[(K,( A ,Option[B]))]
○ outerJoin : RDD[(K,(Option[A],Option[B]))]
○ cogroup : RDD[(K,( Seq[A], Seq[B]))]
from (rdd:RDD[(K,A)])
○ groupBy : RDD[(K, Seq[A])]
1ère règle du BigData, on utilise le `cogroup` !

40. #DevoxxFR
Cogroup
40
LoC : 15
Durée : 11h
(bloquant)
LoC : 5k
Durée : 30min
(non-bloquant)
CHECKPOINT on DISK

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.

44. #DevoxxFR
Mapping Datamart
44
Un datamart ne se base pas sur l’intégralité du
modèle métier. Celui-ci est :
● mis à plat,
● filtré,
● aggrégé.

45. #DevoxxFR
Datamart Big Data
45
● Dashboards industrialisés
● Self-Service BI
● Applications sur mesure

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)

50. #DevoxxFR
Annotations
50
Les annotations remontent dans les structures
manipulées et sont ensuite requêtables :

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.

52. #DevoxxFR
Differential QA
52
K | Data K | Result
f
K | Result’
f’
p
p
K | M
K | M’
Δ ☰
Synthèse de
quelques lignes

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)

54. #DevoxxFR
Conclusion
54

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