À partir de Trino, une branche du projet Presto de Facebook, Starburst entend proposer un méta data warehouse capable de fédérer des données depuis un maximum de systèmes sources.
Membre de la mouvance « Modern Data Stack », Starburst n’est pourtant pas né de la dernière pluie.
Fondée en 2017, la startup a été créée par des anciens de Facebook et de Teradata sur la base d’une technologie née en 2012 dans les locaux du géant des réseaux sociaux : Presto.
À l’origine, Presto doit régler un problème que l’écosystème Hadoop n’avait pas su résoudre : l’accélération de requêtes SQL sur de vastes quantités de données. En l’occurrence, le data warehouse Hive de Facebook représentait un volume de 300 pétaoctets de données. Pour rappel, Apache Hive est l’entrepôt de données intégré de Hadoop. Presto est donc un moteur de requêtes SQL distribué, in-memory, massivement parallèle, consacré à la rapidité d’accès des données à un coût modéré pour des fins analytiques (OLAP). Il a été mis sur pied par quatre ingénieurs : Eric Hwang, David Philips, Martin Traverso et Dain Sundstrom.
Après sa disponibilité en open source en 2013, il a connu une vaste adoption au sein de Netflix, Uber, Airbnb ou Groupon.
La communauté et les créateurs originaux ont étendu les capacités de connexions afin de pouvoir requêter des données structurées et semi-structurées dans des buckets S3, des lacs (Hadoop), des SGBD relationnels (MySQL, PostgreSQL), NoSQL (Cassandra, MongoDB), des data warehouses ou encore des bases de données orientées événements comme Apache Kafka.
Teradata s’intéresse aussi de très près au projet. Contributeur régulier, le spécialiste du datawarehousing propose dès 2015 un support commercial de cette technologie, en partie menée par les anciennes équipes d’Hadapt, une startup cofondée et dirigée par Justin Borgman, rachetée par Teradata en juillet 2014.
À la fin de l’année 2017, Teradata soutient la création d’un spin-off en charge du support commercial de Presto : Starburst. Cette startup est, dès 2017, présidée et dirigée par Justin Borgman. Il est alors considéré comme le fondateur de l’entreprise.
C’est là que l’histoire de Presto prend une tournure complexe. En janvier 2019, Starburst et les créateurs du projet Presto annoncent la naissance de Presto Software Foundation. Facebook est invité à rejoindre la fondation, mais refuse.
Qu’à cela ne tienne, la variante de Presto lancée en 2018 s’appelle désormais PrestoSQL au sein de la Presto Software Foundation.
En septembre 2019, Facebook annonce la création, avec le soutien d’Uber, de HPE, ou encore d’Alibaba, de la Presto Foundation. Facebook renomme Presto en PrestoDB et confie le projet à la fondation Linux.
En désaccord avec la politique de Facebook (Meta), les créateurs du projet ont tous rejoint Starburst. En décembre 2020, comme le géant des réseaux sociaux a réussi à conserver la marque Presto et l’a confié à la Fondation Linux, Starburst renomme PrestoSQL en Trino. La Presto Software Foundation s’adapte à la situation : l’on parle désormais de la Trino Software Foundation. PrestoDB redevient Presto.
Dans les grandes lignes, l’architecture des deux projets demeure similaire : Trino et Presto sont des moteurs de traitements distribués massivement parallèles à travers plusieurs serveurs. Elle est au cœur de l’offre de Starburst.
« C’est une alternative à l’entrepôt de données traditionnel. »
Justin BorgmanCofondateur et président, Starburst
« C’est une alternative à l’entrepôt de données traditionnel », résume Justin Borgman. « Les clients ont stocké leurs données dans différents espaces de stockage sur site ou dans le cloud et ils utilisent notre moteur pour requêter les données. Il permet également de fédérer des requêtes entre différentes sources ».
Dans cette optique, l’éditeur n’a pas vocation à remplacer les systèmes en place, mais à se positionner comme une couche de fédération capable d’interroger des données dans des systèmes hétérogènes, de les transformer, puis de pousser les résultats vers des systèmes cibles, comme un lac ou un entrepôt de données. Pour s’assurer de l’interopérabilité de la plateforme, l’éditeur s’appuie sur le stockage objet et des formats de fichiers ouverts comme Iceberg, Parquet, ORC et Avro.
Les usages les plus courants de Trino et de sa variante commerciale Starburst Enterprise ? L’accélération de requêtes SQL ad hoc et des processus BI.
« Nous avons commencé par des cas d’usage liés à la BI, le reporting et à l’exécution de requêtes SQL ad hoc », indique Justin Borgman. « Plus récemment, les entreprises ont adopté [Trino et Starburst] pour exécuter des charges de travail de type ETL. Nous remplaçons Apache Spark dans certains cas ».
Toutefois, l’éditeur a bien conscience qu’il n’a pas les fonctionnalités d’orchestration des transformations d’un DBT ou d’un autre outil du genre. « Parfois, les clients utilisent conjointement DBT et Starburst. Le premier sert à concevoir les flux de transformation. Le second sert à les exécuter », illustre le CEO.
Comment fonctionne Trino ?
Pour comprendre ce positionnement, il faut expliquer dans les grandes lignes comment fonctionnent Trino et Presto.
Un cluster Trino abrite deux types de serveur : un coordinateur et plusieurs workers. L’interface SQL de Trino est connectée au coordinateur via API REST, lui-même connecté aux workers pour accéder aux sources de données (une cinquantaine actuellement). Ces accès sont configurés dans des catalogues correspondant aux sources. Comme son nom l’indique, le coordinateur conserve la trace des activités sur chacun des workers et orchestre l’exécution des requêtes.
« Le coordinateur crée un modèle logique d’une requête comportant une série d’étapes, qui est ensuite traduit en une série de tâches connectées s’exécutant sur un cluster de workers Trino », lit-on dans la documentation. La même phrase décrit le fonctionnement du coordinateur de Presto.
L’utilisateur soumet une requête SQL à une interface, soit celle de Trino, soit depuis son outil BI, si ce dernier est connecté au cluster Trino. Le coordinateur vérifie l’exactitude de la requête et les droits d’accès de l’utilisateur, puis crée ce fameux modèle logique.
En clair, le coordinateur de Trino et de ses distributions commerciales Starburst joue le rôle d’optimiseur de requêtes. « En règle générale, nous allons confier le filtrage de base des données au système sous-jacent, de sorte que nous ne traitons pas tout avec notre moteur. Nous ne récupérons que ce dont nous avons besoin, puis nous effectuons des jointures en mémoire », explique Justin Borgman.
Le coordinateur planifie une tâche qu’il transmet donc aux bons workers, dont le rôle est d’extraire les données en provenance des connecteurs. Les données sont traitées en mémoire suivant la série d’étapes déterminée par le coordinateur, puis les résultats sont renvoyés à l’utilisateur.
Depuis 2018, les porteurs de Trino assurent avoir différencié le moteur de Presto en ajoutant une fonction de tolérance aux pannes pour les traitements de données en batch. En clair, le système ne s’écroule pas quand il vient à manquer de mémoire vive pour charger les données.
Les « différenciateurs » de Starburst
L’éditeur développe une fonctionnalité supplémentaire : Warp Speed. Développée originellement par Varada (rachetée par Starburst en juin 2022), cette technologie doit offrir des capacités d’indexation et de mise en cache automatiques et optimisées pour des disques SSD à l’aide d’un format colonnaire propriétaire. Le système doit automatiquement créer des index optimaux suivant la tâche à effectuer. Warp Speed requiert d’installer Starburst Enterprise sur une distribution Kubernetes d’un des trois géants du cloud, d’utiliser des SSD NVME et de configurer les connecteurs pour Hive, Iceberg et Delta Lake, les trois formats de tables et de métadonnées compatibles.
Ces deux capacités permettraient d’effectuer des analyses et d’obtenir des accès 7 à 10 fois plus rapidement.
De surcroît, la société a imaginé un système hybride nommé Stargate. Il s’agit d’un connecteur JDBC qui permet de lier des clusters Starburst Enterprise de la même version via un catalogue en lecture seule. Cela permet d’établir des connexions multicloud et hybride où l’un des clusters pilote les autres.
Historiquement, Starburst Enterprise est une offre self-managed, disponible sur site et dans le cloud. Depuis 2021, l’éditeur mise sur sa plateforme SaaS : Starburst Galaxy. Par ce moyen, il tente de se forger une identité au-delà de l’accélération de requêtes.
« Les métiers doivent pouvoir accéder facilement [aux produits de données], savoir d’où proviennent les données et accéder à leurs outils BI. »
Justin BorgmanCofondateur et président, Starburst
Ainsi, il a récemment introduit un moyen de produire et de servir des « produits de données » dans un catalogue, à savoir des vues qui concatènent les informations présentes dans des systèmes hétérogènes. L’outil permet d’obtenir un data lineage des traitements ainsi que d’appliquer les grands principes du data mesh, en produisant des analyses spécifiques aux domaines. « Nous essayons de rendre ces produits de données simples d’utilisation. Les métiers doivent pouvoir y accéder facilement, savoir d’où proviennent les données et – en un clic depuis notre plateforme – accéder à leurs outils BI. Nous travaillons étroitement avec Microsoft Power Bi, ThoughSpot, Looker ou encore Tableau », avance Justin Borgman.
Sous le capot, ces produits de données sont de manière générale des vues matérialisées stockées au format Parquet dans un data lake.
Starburst assure avoir mis en place l’ensemble des règles de gouvernance, de sécurité et de chiffrement pour compléter ce tableau.
Cette capacité à effectuer de la fédération de requêtes, de réunir des produits de données dans un catalogue, puis de les transmettre vers d’autres outils de transformation ou de visualisation n’est pas spécifique à Starburst. Des acteurs comme Databricks, Snowflake, Dremio, AWS ou encore Google Cloud s’inscrivent dans cette lignée. « Ce qui nous rend différents, c’est que la technologie que nous supportons est née chez Facebook », considère Justin Borgman. « Dès le départ, il fallait qu’elle prenne en charge des traitements SQL à très large échelle ».
Même si le CEO a parfois du mal à bien faire comprendre le positionnement de sa « plateforme analytique, capable d’interroger des données peu importe où elles résident », Starburst se différencie par son approche décentralisée. Outre le fait que ce soit très utile pour certaines entreprises internationales, cela permettrait également d’empêcher la captivité des données.
« Avec certains acteurs, une fois que vous adoptez leurs solutions, vos données sont verrouillées. Avec Starburst, nous donnons aux clients la clé qui leur permet de déverrouiller les données et de décider de l’endroit où elles seront conservées », vante Justin Borgman.
En février 2023, Starburst a également annoncé un partenariat avec Dell pour exécuter sa plateforme sur des serveurs Dell PowerEdge et les appliances de stockage Dell Elastic Cloud Storage. L’architecture de référence a été présentée en mars dernier. Cette offre portée par l’équipementier permettra aux clients des deux entreprises de gagner en performance sur site. C’est surtout une opportunité pour les clients qui souhaiteraient décommissionner leurs clusters Hadoop, mais qui pour des raisons de confidentialité ne peuvent pas déployer leur plateforme de traitement de données sur le cloud. Justin Borgman le rappelle, Starburst a réussi à se faire un nom auprès des grandes banques américaines et commence à faire la même chose en Europe.
À la fin du mois de mars, Starburst comptait 600 employés, dont 150 en Europe. L’entreprise a levé plus de 400 millions de dollars, compte « quelques centaines de clients », dont plus de 75 utilisent déjà les fonctionnalités de produits de données de Starburst Galaxy.
