Delta Sharing : Databricks fait sien le partage open source de données

Delta Sharing : Delta Lake s’ouvre aux partages de données

« Toutes les entreprises aujourd’hui ont besoin de partager de l’information en interne, que ce soit entre départements ou entre filiales », expose Nicolas Maillard, Senior Director field Engineering Central & SEMEA chez Databricks auprès du MagIT. « Pratiquement toutes les organisations ont également des partenaires data : elles projettent et consomment de la donnée à l’externe. Dès lors, le fait de simplifier ce partage entre tous les consommateurs et les producteurs de données devient un élément critique », ajoute-t-il.

« Le fait de simplifier ce partage entre tous les consommateurs et les producteurs de données devient un élément critique. »

Il existe déjà plusieurs solutions pour favoriser ce partage, que ce soit par le biais de connecteurs en provenance de bases de données ou la transmission de fichier via des serveurs FTP, mais Databricks considère qu’elles ne répondent pas aux besoins actuels des sociétés. « Depuis un certain nombre d’années, on cherche les zones de partage, mais les entreprises ont besoin d’exposer ces informations beaucoup plus rapidement sans avoir à répliquer, recréer des jeux de données tout en maintenant des critères de sécurité », justifie Nicolas Maillard.

Delta Sharing est pensé comme un protocole REST de partage de données en temps réel et « sécurisé ». Il est destiné à la transmission de gros fichiers entre un fournisseur et un récipient, mais offre la possibilité de cloisonner l’accès à une partie d’un dataset hébergé dans le cloud.

Dans le principe, il s’agit de soumettre des tables ou des vues de tables Delta Lake au format Parquet hébergées dans un lac de données, le fournisseur, à une autorité de gestion des permissions avant de les communiquer à des clients, les récipients : Spark, Pandas, Tableau, etc. L’autorité prend la forme d’un serveur (Delta Sharing Server) placé entre le data lake et le client (un moteur de traitement, un outil BI, etc.) qui supporte le protocole via un connecteur. Les fournisseurs peuvent créer des tables et des groupes de tables à partager.

Les usagers, eux, effectuent des requêtes de lecture, par exemple avec Pandas qui autorise l’interrogation des fichiers en SQL, R, Python et Scala. Les API internes hébergées sur le serveur s’appuient sur des Tokens Bearer (Oauth 2.0, une implémentation spécifique de Json WEB Tokens ou JWT) pour authentifier les utilisateurs et leurs droits d’accès. Si la requête est acceptée, le serveur autorise l’accès au lot de tables, d’une table ou de subsets désignés par le fournisseur vers le client par le biais d’un lien HTTPS à durée de vie limitée.

Un succès conditionné par l’adoption… et l’implémentation

Nicolas Maillard assure que Delta Sharing offre une « indépendance face aux technologies des fournisseurs » du fait de son caractère open source. Or le protocole disponible en version 0.1.0 ne permet d’orchestrer ce partage de données qu’à partir de Delta Lake hébergé sur Amazon S3. Databricks prévoit de l’étendre à Azure Data Lake Storage et Google Cloud Storage. Les données doivent être au format Parquet et découlent de tables Delta Lake.

À terme, le protocole supportera d’autres technologies capables d’interpréter Parquet, par exemple Hive ou Presto, selon Nicolas Maillard. « C’est une réunion de standards open source existants et de nouvelles propositions de standards libres de la part de Databricks », précise-t-il. En revanche, les clients capables de requêter les tables sont pour l’instant peu nombreux.

Auprès de nos confrères de SearchDataManagement, [Propriété de Techtarget, également propriétaire du MagIT], David Menninger, analyste chez Vantana Research, considère Delta Sharing comme une proposition pertinente. « À mesure que les données migrent hors des centres de données et vivent dans une variété de sources de données basées sur le cloud, un protocole ouvert pour le partage des données s’avère très utile », déclare-t-il.

« La valeur réelle de Delta Sharing sera déterminée par le nombre de fournisseurs qui accepteront de le prendre en charge ».

Si l’analyste estime que Databricks a su attirer les bons partenaires technologiques, il assure que « la valeur réelle de Delta Sharing sera déterminée par le nombre de fournisseurs qui accepteront de le prendre en charge ».

Lors d’une démonstration, Matei Zaharia, cofondateur et CTO de Databricks, a dévoilé des connecteurs en bêta pour Tableau et Power BI. De son côté, Ali Ghodsi a indiqué que Microsoft (Azure Purview, Power BI), Google (BigQuery, Looker), Tableau, AWS via AWS Data Exchange, et Startbust seront parmi les premiers à intégrer le protocole. Des outils comme AtScale, Collibra, Dremio, Immuta, Privacera et Qlik pourraient également servir à interroger les données.

Concernant la sécurité offerte par Delta Sharing, celle-ci est dépendante des implémentations par les entreprises et les partenaires technologies de Databricks. Les ingénieurs de Databricks proposent plusieurs méthodes de sécurisation du serveur, mais recommandent l’utilisation d’EC2 et du IAM AWS dans la forme actuelle du protocole. Par exemple, il est possible de ne pas utiliser les tokens Bearer, mais toutes les requêtes seront acceptées et il est fortement recommandé de déployer le serveur derrière un proxy sécurisé « comme celui de NGINX », précise la documentation présente dans le dépôt GitHub.

Unity Catalog, un data catalog unifié pour Databricks

Dans cette même volonté de favoriser la gouvernance et le partage de la donnée, Databricks a présenté Unity Catalog. Cette fonctionnalité propriétaire est disponible en préversion pour les clients de Databricks Cloud. Elle doit fournir un contrôle centralisé en récupérant les métadonnées issues des datasets présents dans les différents espaces de travail, les clouds et les régions cloud Delta Lake, mais aussi MLFlow.

Là encore, l’éditeur entend fournir une gestion « fine » des accès, un data lineage et donc une ligne d’audit au sein de son data lake, peu importe si les données sont structurées ou non.

Pour cela, Databricks y a consacré un éditeur avec lequel les équipes data manipulent des expressions standards ANSI SQL GRANT, pour autoriser l’utilisation de jeux de données par un usager ou une équipe spécifique et sélectionner des colonnes à afficher ou à masquer. L’expression ADD ATTRIBUTE sert, elle, à définir des labels sur certaines colonnes ou lignes, par exemple pour identifier des données personnelles.

Une UI permet de documenter les jeux de données, de visualiser les requêtes les plus fréquentes, les attributions aux propriétaires et aux utilisateurs d’une table (entre autres), les schémas appliqués ou encore le volume de données. En outre, Unity Catalog implémente le protocole Delta Sharing. « Si j’associe ce data catalog avec Delta Sharing, non seulement je peux partager en temps réel les données, mais aussi définir la manière dont elles seront vues, suivant les attributs appliqués », déclare Nicolas Maillard.

Pour autant, Unity Catalog n’a pas vocation à remplacer les data catalogs des éditeurs spécialisés. « Nous avions besoin de fournir pour toutes les données contenues dans Databricks une visibilité multicloud et multitechnologie de premier niveau », assure le responsable français. « Ensuite, il s’agit de partager cette visibilité à d’autres outils de gouvernance tout en évitant la prolifération des data catalogs interconnectés, amoncelés pour combler les limites des uns et des autres. Les partenaires comme Collibra ou Hive peuvent s’appuyer sur cette base pour mieux comprendre les dépendances, notamment celles liées à Apache Spark, et fournir des capacités supplémentaires », ajoute-t-il. 

Delta live Tables, une abstraction d’ETL

Mais avant de les partager et de les gouverner, il faut s’assurer de transmettre des données propres et cohérentes dans le lac. Le Delta Lake a vocation à accueillir et exécuter les projets de machine learning. Or Databricks a constaté que la gestion des pipelines ETL représente encore et toujours un défi pour ses clients.

Pour y répondre, il mise sur Delta Live Table, un service cloud propriétaire inclus dans sa plateforme. « Il s’agit d’un ETL déclaratif en SQL ou en Python. Delta live Table demande aux data engineers à quoi doit ressembler une donnée valable et c’est son travail d’exécuter les jobs en temps réel, à intervalles réguliers ou non, en fonction des impératifs de SLA : qualité, fraîcheur de la donnée, etc. Il doit vérifier que la donnée est cohérente, que les transformations se sont bien exécutées, etc. », affirme Nicolas Maillard.

Databricks s’appuie sur une analyse sémantique des expressions SQL ou Python pour détecter des dépendances entre les différentes étapes d’extraction, de chargement et de transformation des données. Par ailleurs, Data Live Tables permet de mettre en place des règles de détection des erreurs (échec, alertes, quarantaines, abandons) afin de tester et d’analyser, de redémarrer automatiquement les jobs.

Selon Nicolas Maillard, cela participe aux capacités de lignage dans la plateforme Databricks. Cette vision automatisée de l’ETL se rapproche des offres d’acteurs comme Stich ou Fivetran. Sauf que Delta Live Tables « n’existe que lorsque la donnée réside quelque part dans un objet de stockage de type S3 ou avec des connecteurs Big Data type Kafka. Nous n’empruntons pas la même logique des ETL capables de se connecter à des sources tierces tels Fivetran ou Stich ». Sur le papier, cela le rapproche donc de services comme AWS Glue et dans une moindre mesure Azure Data Factory. Databricks avait déjà Auto Loader pour les données brutes.