La hype de la big data est en berne, surtout avec la surexposition médiatique sur l’AI.
Cependant, elle reste nécessaire pour que l’AI soit pleinement exploitée.
Ce qui amène aux choix sur ces technologies permettant de lancer ces traitements extrêmement gourmands.
Aujourd’hui, nous avons à disposition pléthore de produit :

  • Hadoop MapReduce,
  • Pig,
  • Hive,
  • Spark,
  • Flink et j’en passe.

 

Pas facile de se retrouver dans cette jungle d’outils et frameworks.
Dans cette optique, j’ai donc fait une petite visite au second Spark Summit organisé par Databricks en Europe (pour l’année 2017). Ce dernier avait lieu à Dublin entre le 23 et 25 octobre 2017.
Il se trouve que chez Younited-Credit nous utilisons Apache Spark depuis plus d’1an et demi, et il est d’autant primordial de suivre les dernières nouveautés sur cet outil et se garder l’opportunité de mettre en question son utilisation.

 

Spark C’est quoi ?
Mais d’abord qu’est ce que Spark , où est sa place dans l’horizon big data?
Apache Spark a été créé en 2009 par Matei Zaharia.
C’est un moteur Big Data qui peut fonctionner standalone ou au-dessus de divers stockages distribués.

 

Spark est un moteur multiparadigme, il peut être utilisé aussi bien comme ETL en mode batch ou streaming temps réel. Il est aussi utilisable dans l’élaboration de modèle Machine learning et dans la « représentation « de données en graph (les fameux modèles ayant permis le traitement de données des panama paper).

 

Il fonctionne avec de nombreux langages :

 

 

 

Best Practices
Cette convention était donc riche en retours d’expériences de grands acteurs de l’industrie de la data et riche aussi de sessions plus techniques présentées par les ingénieurs de Databricks.
Notamment des best practices pour tirer au mieux des performances du moteur Spark.
Sans rentrer dans les détails techniques, on apprend que le streaming s’améliore sensiblement sur la facilité à récupérer les lates data avec de nombreux choix dans la gestion d’intégration avec l’existant.  J’entends souvent dire en matière de gestion de data temps réel qu’il ne serait pas forcément grave de rater de la donnée.
Cependant en fonction des processus de décision, cela peut être catastrophique de se retrouver qu’avec la moitié des informations, si la donnée a été ratée au moment de sa génération.
On notera aussi quelque best practices sur l’utilisation du partitioning et l’utilisation des schémas en Spark SQL.

Partitioning
Big Data ou pas, le meilleur moyen de réduire la volumétrie de donnée lu. Et tout simplement de la partitionner(divisier/saucissonner). Une des pratiques les plus simples avec spark est parfois en fonction du poids de la donnée de cibler directement la zone qui nous intéresse.

df = spark.read.json(“/employee.json”)
df.write.partitionBy(year(hiredDate)).parquet(“/myEmployee.parquet”)

Imaginons donc que la société fictive créée ait eu un tel besoin de recrutement que chaque partition fait approximativement 2Go. Cela commence à être costaud.
Une des astuces consiste donc à lire directement la bonne partition/répertoire afin de sélectionner l’année qui m’intéresse.

df = spark.read.parquet(“/myEmployee.parquet/hiredDate=2017/”)

 

Schema-On-Read
Même si on associe souvent l’utilisation de schema less ou schema on read avec la Big Data (4V), ces traitements pour être les plus efficaces possible ont tout de même besoin d’un minimum de  « formatage »  pour être sensiblement efficace.
Ainsi, imaginons un storage continuellement alimenté en fichier au format json issu d’une appli tierce :
Ces fichiers auraient un format connu du type :

Spark est capable de faire de l’inférence de type et de lire ces fichiers sans en connaitre le schéma (d’où le schema on read).

df = spark.read.json(“/employee.json”)
df.show()

En retour :

name salary
Michael 3000
Andy 4500
Justin 3500
Berta 4000

Mais cela se fait au détriment de la performance, cela n’est pas visible pour un petit fichier.
En revanche, cela devient un sérieux problème pour des fichiers volumineux.
Et une des astuces est effectivement de se préparer un petit schéma stocké à l’avance ou le créer à la volée.

mySchema = StructType()\
.add(“name”,StringType(),True)\
.add(“salary”,LongType(),True,None)

df = spark.read.json(“/employee.json”,mySchema)
df.show()

Il est aussi important d’apprendre via ces différentes sessions de l’existence de trick disponible uniquement dans le moteur Databricks et malheureusement impossible à utiliser sur la version Apache Spark disponible en ligne.
Typiquement, il existe le Databricks runtime (actuellement la version 3 sur Amazon ) disponible.
Une utilisation purement transparente pour l’utilisateur mais qui est optimise l’interconnexion entre le storage et Spark. Entre-autre :

  • Latence point à point avec des temps d’accès très faible (DBIO),
  • Gestion de la sécurité (DBES).

Ce qui à priori ne peut pas être approché dans une installation on premise ou cloud maison type S3/Spark.
Retour d’XP

Les autres petites friandises étaient les retours d’expériences :

Azure Databricks
D’ailleurs je poursuis sur la plateforme Databricks qui était jusqu’à présent uniquement disponible sur AWS. Apache Spark est actuellement disponible uniquement via HDInsight.
Et il se trouve que Databricks annonce le 17 novembre 2017, l’existence en preview uniquement d’une version nommée Azure Databricks.

Ainsi, jusqu’à présent seul les blobs , data lake store et azure SQL Datawarehouse permettaient une bonne intégration avec Apache Spark sans artifice.
Il est également maintenant beaucoup plus facile de s’intégrer avec toutes les stacks Real time d’Azure (event hub).

Je vous invite à suivre les annonces des prochains mois. Plus que jamais Microsoft est un acteur open source cloud aussi fourni que Google Cloud et AWS.

Une réflexion sur “ Spark Summit 2017 ”

Laisser un commentaire

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