Automatisation, optimisation, gouvernance : les chantiers de Starburst

Une meilleure gouvernance

En effet, Starburst a introduit un mécanisme de traçabilité des données afin de suivre les transformations de données depuis la source connectée à Galaxy jusqu’à leur mise à disposition en tant que produit de données. De même, dans son data catalog, une fonctionnalité de « profiling » permet d’obtenir des informations statistiques sur les vues et les tables (type de données, nombre de valeurs uniques, valeurs minimum et maximum, présence de Null, etc.). Cette observation des données est complétée par un moteur de règles. Il est par ailleurs possible de masquer des colonnes et exclure des lignes suivant le profil des utilisateurs.

Cela va de pair avec un système de gestion de rôle et des accès (RBAC/ABAC). Pour compléter le tout, l’éditeur est en train de développer un système automatisé de classification de données. Celui-ci s’appuie sur des classifieurs pouvant agir dans des catalogues, des schémas, des tables et des vues matérialisées. Ils sont chargés de « scanner » les colonnes et de proposer des étiquettes correspondantes. L’objectif ? Détecter des informations personnelles identifiables (PII) comme des IBAN, des adresses personnelles, des numéros de sécurité sociale, etc. Dans cette préversion publique, l’outil est davantage adapté aux besoins des entreprises américaines.

En ce qui concerne les performances de Galaxy, Starburst poursuit les efforts de compression, de nettoyage automatisé des données et de gestion de la rétention, moyennant la collecte de statistiques sur les données. Sur ce volet, l’éditeur prévoit d’améliorer l’exécution des jobs SQL et des mises à jour incrémentales des vues matérialisées, à l’instar de ce que propose dbt Labs, au premier semestre 2024.

Optimiser les ingestions et les transformations de données

Oui, comme ses concurrents, Starburst entend simplifier l’ingestion de données en presque temps réel. Il a lancé en préversion privée un connecteur vers des topics Apache Kafka compatibles avec la version open source du framework ou la distribution commerciale de Confluent.

L’ingestion en continu et la gouvernance automatisée des données sont deux caractéristiques phares, selon Donald Farmer, analyste et fondateur de ThreeHive Strategy, auprès d’une publication sœur du MagIT. « La capacité de charger un lac de données en quasi-temps réel à l’aide de Kafka est une demande très courante de nos jours, même si elle ne concerne pas tous les cas d’usage. Starburst se devait de répondre à cette demande ».

Ce système extrait les données des topics au format JSON, fait correspondre les identifiants contenus dans le fichier source à des colonnes dans des tables Apache Iceberg, tandis que les métadonnées sont envoyées vers le métastore de Starburst basé sur Apache Hive. Plus tard, l’éditeur prévoit de prendre en charge l’ingestion de fichiers, tout comme il entend faciliter le partage des produits de données.

« De manière générale, avec les tables Iceberg, nous avons notre métastore et nous pouvons nous connecter aux métastore des clients, par exemple, un Hive ou AWS Glue », relate Victor Coustenoble, Solutions Architect Senior Manager SEMEA chez Starburst. « Nous sommes également en train de développer un métastore “pur” Apache Iceberg pour Starburst Enterprise ».

Outre ces optimisations, l’éditeur a dévoilé en septembre dernier PyStarburst, une librairie permettant d’implémenter des DataFrames Python. Les utilisateurs les plus avancés de Starburst Galaxy ont donc une deuxième méthode, en sus du langage SQL, pour effectuer des transformations de données. D’autres outils permettent de manipuler les données gérées avec Starburst en Python. Deux d’entre eux sont liés directement à Trino, Ibis et trino-python-client. Il est aussi possible de passer par dbt, Apache Superset ou encore Querybook, suivant les besoins. PyStarburst est en réalité une intégration spécifique d’Ibis, un outil compatible avec près d’une vingtaine de moteurs de base de données, dont PostgreSQL, BigQuery, Clickhouse ou encore MySQL.

Avec la préversion publique de « Text to SQL » et de « SQL to Text », il s’agit à l’inverse de simplifier l’accès à la plateforme de fédération de requêtes par un plus grand nombre d’utilisateurs. Comme bon nombre d’acteurs sur le marché, Starburst exploite les modèles d’IA générative pour générer ou expliquer des requêtes SQL.

« D’autres entreprises proposent également des solutions d’analyse de données qui mettent l’accent sur le traitement en temps réel, l’intégration de l’intelligence artificielle et les services basés sur le cloud », déclare Donald Farmer. « Par rapport à ses concurrents, l’argument de vente unique de Starburst tient au fait que son architecture est fondée sur Trino, un projet open source, ce qui peut attirer les organisations qui recherchent plus de flexibilité et moins de dépendance à l’égard d’un fournisseur ».

Starburst multiplie les couches de cache

Si l’adjonction de l’IA générative peut paraître anecdotique pour les usagers avancés, les améliorations de Warp Speed, le système d’indexation et de mise en cache automatique de Starburst, le sont moins.

« Les data engineers doivent adopter divers outils et techniques pour rationaliser les processus d’interrogation des données », expliquent les porte-parole de l’éditeur, dans un billet de blog. « La mise au point d’une stratégie de cache flexible est un élément essentiel de l’exécution et de la performance des requêtes, permettant aux organisations de fournir rapidement des réponses aux requêtes, grâce à une consommation partagée des ressources ».

Pour ce faire, l’éditeur a présenté le 6 février 2024 des fonctionnalités de mise en cache de résultats et de sous-partie de requêtes.

Warp Speed a d’abord été pensé pour automatiser la mise en cache des données les plus utilisées dans les étapes de filtrage multidimensionnel. Si cela permet d’accélérer les traitements, ce n’est pas forcément la technique la plus adaptée pour optimiser des scénarios où les mêmes requêtes sont rejouées régulièrement – par exemple lorsque des dizaines voire des centaines de collaborateurs consultent des rapports de manière hebdomadaire ou mensuelle.

En disponibilité générale dans Galaxy, la couche « Result Caching » doit permettre de stocker temporairement les résultats des requêtes lancées récemment (24 heures maximum), sans avoir à refaire les calculs, et de « décharger les requêtes redondantes du cluster ».

« Le cache de résultats est un système de stockage à accès rapide stocké dans la mémoire de l’écosystème Galaxy », résument les porte-parole. « Cela permet aux utilisateurs de partager efficacement les résultats des requêtes, en particulier lorsque plusieurs utilisateurs accèdent au même tableau de bord ». Cela est potentiellement utile pour les entreprises qui exploiteront l’intégration récente avec Amazon QuickSight, la solution de BI, d’AWS.

Cette zone de cache des résultats s’intègre aux clusters présents dans une région cloud spécifique. Il s’agit d’une fonctionnalité particulièrement répandue dans les data warehouses du marché, dont ceux de Snowflake, Oracle, Amazon Athena ou RedShift.

C’est une logique similaire que l’éditeur applique aux sous-requêtes, en préversion privée. « Les sous-requêtes apparaissent souvent plusieurs fois dans une même requête et dans plusieurs requêtes différentes », expliquent les porte-parole de Starburst. « Il est généralement difficile d’optimiser manuellement ces schémas ».

Une capacité de Warp Speed identifie automatiquement les sous-requêtes identiques qui sont répétées et met ces éléments partiels en cache.

Techniquement, « Galaxy stocke les résultats des sous-requêtes communes en mémoire aux étapes sources du plan de requête pour une réutilisation ultérieure », relate la documentation.

Cette mise en cache concerne en premier lieu les blocs de données qui « n’ont pas été modifiés dans l’intervalle », précise-t-elle. En revanche, « tout élément de données nouveau ou modifié est traité à partir de zéro et recombiné avec ce qui a été mis en cache précédemment ». Cela doit garantir « à 100 % » la cohérence des résultats.

Outre l’optimisation des requêtes et la fluidité des usages, cette mise en cache doit permettre de réduire les coûts d’exécution. Un sujet d’importance pour les entreprises qui migrent de plus en plus vers le cloud.