Spark-adabra, Comment Construire un DATALAKE ! (Devoxx 2017)
3 j'aime1,296 vues
Le document présente un guide sur la construction d'un datalake utilisant des technologies de big data et de business intelligence, notamment Spark. Les intervenants partagent des expériences pratiques et des résultats concrets de projets, en se concentrant sur la collecte, le stockage, et l'exploitation des données. Il aborde également les défis liés à l'intégration des données, la gestion des métadonnées et l'amélioration de la qualité des données.
![#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` !](https://image.slidesharecdn.com/devoxx2017-170424145724/85/Spark-adabra-Comment-Construire-un-DATALAKE-Devoxx-2017-39-320.jpg)
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)](https://image.slidesharecdn.com/devoxx2017-170424145724/85/Spark-adabra-Comment-Construire-un-DATALAKE-Devoxx-2017-49-320.jpg)
Spark-adabra, Comment Construire un DATALAKE ! (Devoxx 2017)
- 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
- 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
- 14. #DevoxxFR 14 Pipeline d’alimentation du lac Collecte Nettoyage & Calculs Stockage Exploitation Visualisation Exploration
- 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
- 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)
- 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; € € €
- 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
- 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)
- 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