Data+AI Summit 2020 – sois Zen dans ton lakehouse

Si tu as loupé la news, la semaine précédente a eu lieu le tant attendu, Data+AI Summit Europe, connu jusque là sous Spark+AI Summit. Comme l’année précédente, on a eu la chance d’y participer. Les organisateurs devraient publier les talks sous peu mais si tu ne peux plus attendre, voici un court résumé de ce qui s’y est passé du point de vue du data engineering.

TL;DR
Si tu te poses des questions sur le titre, il est là pour résumer les 2 annonces majeures pour les data engineers. Premièrement, Apache Spark va devenir plus Pythonique grâce au projet appelé Zen. Deuxièmement, il va probablement tourner sur une architecture du type lakehouse. Si tu veux en connaître les détails, tu en trouveras un peu plus bas 👇

Data architectures

Data mesh

Lakehouse n’était pas la seule architecture présentée lors du Summit. Il y en avait une autre, aussi bien connue que lakehouse, le data mesh. L’approche a été présentée par Zalando dans “Data Mesh in Practice: How Europe’s Leading Online Platform for Fashion Goes Beyond the Data Lake”. Au tout début du talk, Max Schultze a listé tous les points de douleur liés à la gestion centralisée de la donnée, utilisée précédemment chez Zalando:

  • absence de responsabilité – personne n’était propriétaire de la donnée
  • qualité de la donnée – un peu lié au point précédent car vu l’absence d’un propriétaire de la donnée identifié, les données devaient être gérées par une équipe centralisée, pas forcément habile à les optimiser de point de vue business
  • goulot d’étranglement – l’équipe centrale responsable du data lake était au centre de toutes les demandes et avec le temps, elle est devenue le point de contention pour l’agilité des projets 

Ensuite, Dr. Arif Wider de ThoughtWorks a expliqué comment l’approche data mesh peut résoudre ces problèmes pour contenter chacun des acteurs présentés ci-dessous: 

Le premier changement concerne l’évolution de la perception de la donnée. Elle n’est plus un “dataset” mais bien un produit géré par une équipe. Et l’équipe est là non seulement pour maintenir le produit mais aussi pour le faire connaître auprès d’autres équipes.

Le second point est lié au Domain-Driven Architecture appliqué à la donnée. L’équipe responsable de dataset a la meilleure connaissance pour répondre à des questions clients et fournir une bonne qualité de produit.

Et finalement, le concept de Data Infrastructure as a Platform. C’est la base technique de toute la plateforme et doit être agnostique. Cela veut dire que chaque équipe “domaine” devrait être indépendante et pouvoir  l’utiliser sans aucun problème, aussi bien pour les pipelines batch/streaming, comme pour les scénarios de ML ou data analytics. “Sans aucun problème” est une expression clé ici car il garantit qu’un nouveau point de contention ne sera pas créé.

Lakehouse

Passons maintenant au Lakehouse. Pour commencer, Databricks, la société qui évangélise beaucoup sur ce pattern, a identifié et partagé 10 problèmes liés au data lakes: 

Pour résoudre ces problèmes, Databricks propose une solution, le Delta Lake ! Le souci de fiabilité  peut être adressé avec les garanties ACID de traitement. La performance des requêtes peut être optimisée avec le mécanisme d’index. Pour la gouvernance, une approche classique de contrôle par table, colonne ou ligne avec ACL et RBAC. Et pour terminer, la qualité de données peut être garantie avec la fonctionnalité de schema management (ex. merge schema feature of Delta Lake) et avec l’aide d’un framework de data validation (ex. Great Expectations).

Lakehouse classifie aussi les données en 3 « âges »,  BronzeSilverGold, où la partie la plus à gauche correspond aux données brutes et celle la plus à droite, aux données exposées aux clients. Le slide ci-dessous résume assez bien le concept:

L’image est aussi une bonne occasion d’introduire un nouveau membre de la famille de service managé Databricks, SQL Analytics qui adresse la problématique de data visualization, jusque là possible uniquement via des notebooks. A l’occasion de sa présentation, Reynold Xin, un des fondateurs de Databricks et un des premiers contributeurs à Apache Spark, a expliqué quelques optimisations implémentées dans le protocole BI (voir l’image ci-dessous) et le moteur d’exécution:

  • Photon Engine – un moteur de requêtage vectorisé, écrit en C++ et garantissant jusqu’à 10x les performances d’Apache Spark exécuté sur une JVM 
  • SQL Endpoint scaling – les requêtes arrivent à un SQL Endpoint qui est capable de créer les ressources de calcul à la demande et les éteindre juste après. 
  • Short query optimisées – si la requête peut récupérer les résultats en quelques secondes, elle va les récupérer tout de suite sans faire des aller-retours comme présenté sur le slide ci-dessous qui s’applique le cas échéant:

Apache Spark – team unite et Project Zen

Dès ses débuts Apache Spark était fortement associé à Scala. Cependant, le temps a changé bien des choses. Selon les analyses partagées par Databricks, le nombre des notebooks utilisant Scala a décru de 92% à 12% tandis que le nombre de  notebooks Python a crû de 5% à 47% !

Malgré cela, PySpark a toujours un peu de retard par rapport au Scala Spark. Une des initiatives visant à réduire cet écart est le Projet Zen partagé lors de la keynote de mercredi par Reynold Xin. Le but ? Transformer PySpark en un projet plus Pythonique à travers des axes suivants:

  • faciliter le développement sur des IDEs et notebooks en se basant sur les type hints pour une auto-complétion plus efficace  
  • améliorer la documentation 
  • améliorer la gestion d’erreurs – on n’aura bientôt plus besoin de scroller par les stack traces de Java pour trouver l’erreur de Python
  • API UDF plus Pythonique – plus besoin de décorer les UDFs avec les types. Le nouveau mode va se baser sur le type hints.

Une présentation plus détaillée a été partagée par Hyukjin Kwon dans son talk intitulé “Project Zen: Improving Apache Spark for Python Users”.

Apache Spark – internals et tips

Malgré le renommage de conférence de Spark+AI Summit au Data+AI Summit, elle a gardé son côté Spark-esque et les speakers ont partagé beaucoup de choses intéressantes liées à ce framework. Dans le premier talk de cette catégorie, “What is New with Apache Spark Performance Monitoring in Spark 3.0”, Luca Canali a présenté comment utiliser différents composants pour surveiller les applications Apache Spark. En dehors de Spark UI, on peut les surveiller avec le code à travers des fonctionnalités telles que Spark listeners, les métriques, en incluant celles des executors, et finalement les plugins. Si tu es en panne d’inspiration, tu peux jeter un coup d’oeil sur les repositories partagés par Luca, notamment https://github.com/cerndb/SparkPlugins, https://github.com/cerndb/spark-dashboard ou https://github.com/LucaCanali/sparkMeasure 

A part la partie de monitoring, on a aussi suivi la présentation d’Itai Yaffe et Roi Teveth. Dans leur talk intitulé “Migrating Airflow-based Apache Spark Jobs to Kubernetes – the Native Way”, ils ont partagé comment réduire la facture EMR de 30%, et en même temps fournir du challenge technique à l’équipe avec la migration des jobs Spark vers Kubernetes (EKS). Si tu cherches donc d’autres alternatives pour faire des économies en plus des Spot Instances ou Reserved Instance, n’hésite pas à regarder le talk et inclure l’EKS dans l’analyse!

Et pour terminer, on a assisté aux 2 talks de Facebook sur les JOINs in Apache Spark. Dans le premier, Suganthi Dewakar et Guanzhong Xu ont expliqué comment gérer le data skew dans les joins. A la fin de leur talk, “Skew Mitigation For Facebook PetabyteScale Joins”, ils ont partagé des solutions suivantes:

  1. Diviser le JOIN en 2 requêtes, une avec la clé “skewée”, l’autre pour le reste – le résultat des 2 jobs était collecté avec une UNION mais malgré cela, l’approche nécessitait un double scan des données, un pour détecter le skew, un pour exécuter les requêtes 
  2. Utiliser l’adaptive framework de Apache Spark 2 – grâce à cette approche un double scan de dataset a été éliminé mais la solution n’était pas satisfaisante parce qu’elle introduisait des shuffle, même quand ce n’était pas nécessaire.
  3. Extension de l’Adaptive Query Execution skew join management a permis de fournir la solution parfaite

Dans le 2e talk, “Spark SQL Join Improvement at Facebook”, Cheng Su a présenté l’effort consacré à l’amélioration de l’opération de JOIN dans la version Open Source d’Apache Spark. Parmi les changements déjà prêts, une amélioration de la stratégie de shuffle join qui à partir de la version 3.1 du framework devrait utiliser le code généré à la volée, ce qui améliorerait les performances de 30% et minimiserait l’utilisation de CPU! Concernant les modifications “en cours”, l’utilisation de Bloom filter pour réduire la taille de données scannées dans le plus grand dataset impliqué dans le JOIN. Cette fonctionnalité est actuellement en cours de discussion avec les membres de la communauté.

Delta Lake – focus sur le MERGE

Si tu attendais des détails techniques sur Delta Lake cette année, tu ne devrais pas être déçu! A part la présentation de Lakehouse, les ingénieurs de Databricks et membres de la communauté Open Source ont partagé quelques informations bien croquantes par rapport au Delta Lake. 

Pour commencer, lors du Meetup tenu après les présentations de mercredi, Jacek Laskowski a partagé sa découverte à propos de l’exécution de l’opération de MERGE. Grâce à ce retour on peut apprendre que l’opération fait 2 passes sur les données source et pour l’optimiser, il faut explicitement cacher le Dataset. Cependant, cela peut évoluer suite à la discussion sur le mailing list de Delta Lake.

Les détails techniques sur l’opération de MERGE ont ensuite été précisés par  Justin Breese, le solution architect de chez Databricks, dans le talk “Delta Lake: Optimizing Merge”. Pour la faire court, l’opération de MERGE se résumer à les 3 stages ci-dessous:

Dans son talk, Justin a aussi partagé quelques tips intéressants sur l’optimisation du MERGE, tels que:

  • l’utilisation de partition pruning – pour l’instant cela doit être explicitement implémenté dans les filtres sur les colonnes utilisées dans le partitionnement et/ou Z-Ordering
  • définir le spark.databricks.delta.optimize.maxFileSize à 32MB pour les workloads write-intensive et à 1GB (le défaut) pour les read-intensive.
  • supprimer le cache (unpersist) quand le DataFrame n’est plus utilisé pour libérer les ressources 
  • penser à utiliser des workers plus petits – selon la comparaison présentée dans le talk, l’opération de MERGE exécutée sur un cluster composé de nodes 2xlarge s’est exécutée plus rapidement que quand elle était exécuté sur une cluster composé de nodes 16xlarge 
  • utiliser des préfixes correctement pour les objets écrits sur object storage pour éviter la contention 

Et le “Optimize merge…” n’était pas le seul talk donné par Justin. Il a aussi accompagné son collègue de chez Databricks, Nick Karpov, dans  “Delta: Building Merge on Read”. L’idée du talk était de présenter 2 façons d’utiliser le MERGE. Le premier, appelé MERGE on write, est celui que tu as découvert plus haut, à l’écriture, où les données mergées sont écrites dans le job. Le 2e mode, appelé MERGE on read, propose une approche différente résumé sur le slide ci-dessous:

L’idée? Cela ressemble beaucoup à l’architecture Lambda. D’un côté les données fraîches sont ajoutées dans la table appendOnly. Elle est ensuite utilisée avec les données plus anciennes, stockées dans materialized view, et retournées à travers une vue commune (table view) représentant le join des 2 tables. Les données d’appendOnly sont progressivement déplacées dans materialized view. Pourquoi cette approche? Elle s’est avérée d’être beaucoup plus efficace pour un scénario où le dataset était complètement réécrit presque à chaque fois à cause des conditions présentées ci-dessous:

Cependant, MERGE n’est pas la seule opération disponible sur Delta Lake. Une autre a attiré notre attention. Il s’agit de l’option mergeSchema que Mate Gulyas et Shasidhar Eranti , les deux de Databricks, ont utilisé dans le talk “Designing and Implementing a Real-time Data Lake with Dynamically Changing Schema”. Si au quotidien tu travailles en streaming avec les données semi-structurées, n’hésite pas à voir comment ils ont utilisé cette option pour la gestion de schémas dans un environnement très dynamique. Les mots-clés: “mergeSchema” et “metadata store”.

Comme tu peux le constater, malgré son caractère virtuel, l’événement n’a rien perdu de sa magie! Et pour dire qu’on vient de présenter une petite partie liée uniquement au data engineering! Si tu veux en découvrir un peu plus, soit patient et vérifie de temps en temps si un nouveau playlist Data+AI Summit 2020 Europe n’est pas ajouté sur le channel YouTube de Databricks 🎬

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


Ce formulaire est protégé par Google Recaptcha