Le réseau social professionnel LinkedIn a décidé de livrer son outil de gestion de données OpenHouse en open source. La filiale de Microsoft entend simplifier le travail des ingénieurs logiciels et des équipes d'infrastructure de données associées afion de réduire le temps de déploiement de produits ou d'applications. Compatible avec les entrepôts de données open source, OpenHouse constitue un plan de contrôle comprenant un catalogue « déclaratif » et une suite de services de données. Contrairement aux concepts de data lakes, qui stockent les données en format natif, et de data warehouses, qui stockent des données structurées (souvent en format SQL), le data lakehouse est une architecture de données qui offre à la fois des capacités de stockage et d'analyse. « Les utilisateurs peuvent définir des tables, leurs schémas et les métadonnées associées de manière transparente et déclarative dans le catalogue. OpenHouse réconcilie l'état observé des tables avec l'état souhaité en orchestrant divers services de données », a écrit LinkedIn en décrivant l'offre sur GitHub. 

L'idée fondamentale du produit 

Mais pourquoi développer un outil de gestion big data pour les entrepôts de données ? Selon l'ingénieur Sumedh Sakdeo, tout a commencé quand LinkedIn a opté pour des entrepôts de données open source pour ses besoins internes plutôt que pour des entrepôts de données dans le cloud, car les premiers « permettent une plus grande évolutivité et une plus grande flexibilité ». Cependant, M. Sakdeo fait remarquer que malgré l'adoption d'un entrepôt de données open source, LinkedIn a eu pas mal de problèmes à résoudre pour parvenir à offrir une expérience managée à ses utilisateurs finaux. Contrairement à l'idée que l'on se fait généralement des offres gérées pour les bases de données ou les plateformes de données, dans le cas du réseau social, les utilisateurs finaux étaient ses équipes de données internes, et la gestion devait être assurée par l'équipe d'ingénierie des produits.  

« L'absence d'une expérience gérée signifie souvent que nos utilisateurs finaux doivent faire face à des problèmes d'infrastructure de bas niveau, comme la gestion de la disposition optimale des fichiers sur le stockage, l'expiration des données sur la base du TTL pour éviter d'épuiser les quotas, la réplication des données à travers les zones géographiques et la gestion des autorisations au niveau des fichiers », a expliqué M. Sakdeo. « De plus, les équipes d'infrastructure de données de LinkedIn n'auraient eu que peu de contrôle sur le système qu'elles devaient exploiter, ce qui rendrait plus difficile la régulation d'une gouvernance et d'une optimisation adéquates », a ajouté M. Sakdeo. C'est ainsi qu'est né OpenHouse : l’outil résout ces problèmes en évitant des tâches supplémentaires de gestion des données dans un lakehouse open source. Selon LinkedIn, l'entreprise a mis en œuvre plus de 3 500 tables OpenHouse gérées en production, desservant plus de 550 utilisateurs actifs quotidiens et répondant à un large éventail de cas d’usage. « OpenHouse a notamment rationalisé le délai de mise sur le marché de l'implémentation dbt de LinkedIn sur les tables gérées, en le réduisant de plus de 6 mois », a poursuivi M. Sakdeo, ajoutant que l'intégration des systèmes de mise sur le marché de LinkedIn à OpenHouse a permis de réduire de 50 % la charge de travail de l'utilisateur final associée au partage des données. 

Fonctionnement d'OpenHouse 

« Au cœur de ce plan de contrôle pour la gestion des tables, se trouve un catalogue accompagné d'un service de table RESTful capable d’offrir un provisionnement de table sécurisé et évolutif et une gestion déclarative des métadonnées », a déclaré M. Sakdeo. « En outre, le plan de contrôle englobe les services de données qui peuvent être personnalisés pour orchestrer de manière transparente les tâches de maintenance des tables », a ajouté l'ingénieur logiciel principal. Selon LinkedIn, le service de catalogue facilite la création, la récupération, la mise à jour et la suppression d'une table OpenHouse. « Il est intégré de manière transparente à Apache Spark afin que les utilisateurs finaux puissent utiliser la syntaxe standard du moteur, les requêtes SQL et l'API DataFrame pour exécuter ces opérations », a indiqué LinkedIn dans un communiqué. La syntaxe standard prise en charge comprend, sans s'y limiter, les éléments suivants : SHOW DATABASE, SHOW TABLES, CREATE TABLE, ALTER TABLE, SELECT FROM, INSERT INTO et DROP TABLE. En outre, le service de catalogue permettra aux utilisateurs d'établir des politiques de rétention sur les tables OpenHouse partitionnées dans le temps. 

« Grâce à ces règles configurées, les services de données identifient et suppriment automatiquement les partitions plus anciennes que le seuil spécifié. Les utilisateurs finaux peuvent également utiliser une syntaxe SQL étendue adaptée à OpenHouse », a précisé M. Sakdeo, ajoutant que le service permet également aux utilisateurs de partager les tables OpenHouse. OpenHouse prend en charge les formats de table Apache Iceberg, Hudi et Delta. Concernant le stockage, l’outil prend en charge une interface Hadoop Filesystem, compatible avec HDFS et les stockages blob qui la prennent en charge. « Les interfaces de stockage peuvent être augmentées pour se connecter aux API natives des stockages blob », a souligné LinkedIn. En ce qui concerne la prise en charge des bases de données, OpenHouse utilise une base de données MySQL pour stocker les pointeurs de métadonnées des tables Iceberg sur le stockage. « Le choix de base de données est enfichable. OpenHouse utilise le framework Spring Data JPA pour permettre l'intégration avec divers systèmes de base de données », a encore indiqué M. Sakdeo. OpenHouse offre aussi des fonctionnalités d'observabilité et de gouvernance, entre autres choses.