Databricks optimise son « Lakehouse » pour les analystes

Databricks mise sur l’optimisation des traitements SQL

« Le moteur Spark permet de couvrir tous les besoins fonctionnels, mais il lui manquait des éléments, soit de performance, soit d’optimisation pour répondre à certains besoins avancés », indique Nicolas Maillard, directeur Field Engineering Central & SEMEA chez Databricks.

« Spark 3.0 apporte des nouveautés comme le contrôle adaptatif du plan d’exécution qui permet de rééquilibrer ou de redistribuer les données à mi-chemin du calcul. Auparavant, il le faisait au début et à la fin du calcul », assure-t-il. Il supporte également les opérations Delete, Update et Merge, typique des jobs SQL et une meilleure compatibilité avec le standard ANSI. Delta lake 7,0 apporte un meilleur support de Hive tandis que le runtime Databricks 7.0 (la version commerciale qui combine un data lake et delta lake) apporte des connecteurs vers Azure Synapse (anciennement SQL Data Warehouse).

Or Databricks a présenté il y a quelques mois sa vision du Lakehouse, un paradigme selon lequel un data lake associé à un Delta Lake peut faciliter les cas d’usage BI, analytique et de machine learning depuis une seule plateforme. C’est ce que la licorne appelait jusqu’alors la « unify data analytics platform ».

« Il nous manquait un élément entre Spark et Delta Lake pour prendre avantage de l’ensemble de la compréhension de la donnée telle qu’elle est stockée et de la couche de calcul et de ses différentes API type SQL, Python, R ou Graph », déclare Nicolas Maillard. « Il y a avait de l’attente pour obtenir des performances de haut niveau sur des données extrêmement simples et structurées ».

Traditionnellement, le langage SQL est associé à la pratique de la BI et de l’analytique. Seulement, les volumes de données à traiter ont explosé et les entreprises veulent les combiner avec des algorithmes. Pour cette raison, l’éditeur a développé Delta Engine, un moteur de requêtes pour optimiser différents workloads comme des transformations de données, des jointures, des opérations de lecture et d’écriture depuis Spark SQL. Typiquement, les utilisateurs font habituellement appel à Spark SQL, un composant bien maîtrisé par Databricks, mais certains lui préfère Hive ou Presto.

Les particularités du Delta Engine : un moteur dans un moteur

Delta Engine, qui a demandé deux ans et demi de développement doit offrir des performances huit fois supérieures par rapport à l’ancien moteur d’exécution des requêtes. Toutefois, Nicolas Maillard précise que ce chiffre est donné à titre indicatif, puisque aucun benchmark indépendant n’a été réalisé à l’heure où nous écrivons ces lignes.

Dans le runtime Databricks, le Delta Engine se place au-dessus de Delta Lake et fait le lien avec la couche de visualisation des données (ou de réception des résultats). Celui-ci prend en entrée des requêtes SQL, des DataFrames Spark (l’équivalent des tables dans une base de données relationnelle, mais optimisées) et des DataFrames Koalas (une version optimisée de Panda pour Spark). Pour accélérer les requêtes, Delta engine comprend un composant afin d’optimiser les requêtes, un moteur nommé Native Execution Engine et une couche de mise en cache.

C’est ce Native Execution Engine qui a demandé le plus de travail à Databricks. L’optimisation des calculs est non plus limitée par la vitesse de stockage (merci les SSD NVMe et la fibre optique), mais par la fréquence des processeurs qui n’a pas énormément bougé depuis cinq ans. En revanche, le parallélisme offert par les CPU a considérablement évolué. Les processeurs x86 offrent depuis longtemps des jeux d’instructions supplémentaires SIMD (instruction unique, données multiples) MMX/SSE et AVX (Advance Vector Extensions). La norme AVX-512 introduite en 2013 double les performances d’AVX2 en la matière.

Photon (le véritable nom de ce moteur d’exécution) a été architecturé pour tirer le meilleur parti de la vectorisation pour gérer les instructions et les données en parallèle. Selon Reynold Xin, chief architect et fondateur de Databricks, cela a demandé de revoir la manière dont les données sont traitées par les instructions d’accès en mémoire. Cela passe notamment par la réduction de la taille des boucles de code, quitte à en multiplier le nombre.

Le précédent moteur d’exécution basé sur une architecture JVM (le projet Tungsten) devait régler le problème, mais apparemment le langage C++ s’avère plus adapté pour gérer des calculs parallèles avec les CPU de dernières générations. L’autre composante, de Tungsten, c’est l’encodage UTF-8 des données. Bien que moins gourmand en mémoire, ce standard pèse sur les ressources de calcul (à cause de l’encodage à longueur variable des caractères) et n’est pas totalement optimisé pour les données encodées en ASCII, la norme utilisée aux États-Unis.

Photon doit accélérer le traitement des STRING en réalisant une détection de la présence de caractère ASCII via des instructions AVX. Suivant le résultat, le moteur lance une version à longueur fixe de sa fonction String, sinon il applique le processus classique dédié aux caractères encodés en UTF-8. De la sorte, le traitement des expressions régulières serait quatre fois plus rapide, selon Reynold Xin.

Pour l’instant disponible en préversion privée, Databricks compte améliorer la portée du Delta Engine pour accélérer les plans de calcul. « Initialement, l’intérêt de Delta Engine est de répondre à un élément où nous n’étions pas encore complètement performants, sur la partie Spark SQL. Nous voulions avoir une stabilité des temps de réponse pour lier la partie Data Lake, que nous gérons bien avec Spark – avec la partie Datawarehousing dont on couvrait l’ensemble des fonctionnalités avec Spark SQL – mais sans répondre à toutes les attentes classiques [liées aux traitements de requêtes] », précise Nicolas Maillard.

Une couche de visualisation de données « simple »

De fait, ces optimisations permettent à Databricks de s’adapter davantage aux besoins des data analysts, une population qu’il ne ciblait pas particulièrement auparavant. En ce sens, l’éditeur a annoncé l’acquisition de Redash pour un montant inconnu. Ce projet open source offre une couche de création de tableaux de bord et de visualisations « simples » qui sera intégrée dans le « Lakehouse » pour obtenir un « accès rapide aux informations ».

L’éditeur promet qu’il n’y a plus besoin de transférer les données vers d’autres systèmes pour leur exploration ou leur analyse. Redash prend en charge originellement une vaste gamme de bases de données SQL, mais s’est également ouvert aux requêtes NoSQL et à la particularité du format Parquet. L’outil repose sur une philosophie proche de celle de Databricks puisqu’il intègre un éditeur de requêtes fort, ressemblant aux notebooks intégrés dans l’interface dans la plateforme de data science.

« Il y un an et demi, nous permettions aux équipes de data science et de data engineering de travailler ensemble de manière efficace et performante. […] En discutant avec nos clients, nous avons noté l’importance de la notion de “Data Teams”, d’équipes qui comprennent des consommateurs de données structurées comme des analystes. Notre objectif, c’est de simplifier le travail de l’ensemble de l’équipe Data, dans laquelle l’analyste a toute sa place », vante Nicolas Maillard.

« L’acquisition de Redash […] est une décision intelligente, car Databricks devait largement s’appuyer sur des partenaires tels que Qlik pour la visualisation des données. »

Comme à son habitude, Databricks conservera la dimension open source de Redash dans le but de faire grossir la communauté.

« L’acquisition de Redash par Databrick est une décision intelligente, car Databricks devait largement s’appuyer sur des partenaires tels que Qlik pour la visualisation des données », déclare Mike Gualtieri, analyste chez Forrester.

Pour autant, Databricks ne veut pas faire une croix sur ses partenaires BI comme Microsoft Power BI ou Tableau. « Il n’est pas question de nous priver de l’intégration avec les solutions des acteurs BI. Nous avons des connecteurs JDBC, mais également natifs, par exemple dans le nouveau SDK de Tableau et nous ferons de même avec Power BI », assure le directeur Field Engineering français.

« Les partenaires data visualization de Databricks seront toujours importants, mais l’intégration de Redash devrait réduire la complexité des cycles de vente de Databricks, pour les clients qui souhaitent visualiser des données sans adopter l’ensemble [d’une plateforme] BI », estime Mike Gualtieri.

Pour rappel, Shell, Zalando, Upply, H&M ou encore Electrolux sont quelques-uns des clients européens à avoir adopté la plateforme de data science.

Les propos de Mike Gualtieri ont été recueillis par Mike Labbe, journaliste pour SearchEntrepriseAI [Propriété de TechTarget, également propriétaire du MagIT].