Tabsdata veut moderniser l’ingestion de données

Une équipe de vétérans de l’IT

À l’origine du projet, un duo de vétérans de l’IT. Arvind Prabhakar est le fondateur de StreamSets (racheté par Software AG, puis IBM) et ancien de Sun Microsystems de Yahoo, d’Informatica et de Cloudera. Il est secondé par son partenaire de toujours, Alejandro Abdelnur dit « Tucu ». L’ancien de Sun et Yahoo se présente comme l’un des premiers contributeurs d’Hadoop. Il était ingénieur logiciel chez Streamsets (et avant cela Cloudera). Il est l’actuel directeur technique de Tabsdata.

Arvind Prabhakar (à gauche) et Alejandro Abdelnur (à droite), les cofondateurs de Tabsdata.

Streamsets est un outil d’orchestration de pipelines de données ETL propulsés par deux moteurs. L’ingestion s’appuie sur la JVM, tandis que les transformations sont effectuées à l’aide d’Apache Spark. L’objectif à sa création était de remplacer les plateformes historiques telles Oracle GoldenGate ou IBM Infosphere. Ce n’est pas celui de Tabsdata.

« J’ai lancé Tabsdata en tirant les leçons des dix dernières années passées à construire et faire évoluer StreamSets », résume Arvind Prabhakar, cofondateur et CEO de Tabsdata. « Nous avons voulu repenser l’approche, repartir de la base, et résoudre les problèmes structurels que les pipelines n’arrivent tout simplement pas à maîtriser ».

Tabsdata, elle, entend proposer un moyen de transformer les ensembles de données en produits, publiés et consommés selon le modèle bien connu des systèmes Pub/Sub. Mais au lieu de messages, ce sont des tables entières – versionnées, traçables, historisées – qui sont diffusées.

À titre de comparaison, StreamSets a plutôt été pensé pour gérer les charges de travail de migration vers le cloud et de Change Data Capture.

« Les pipelines, c’est bien. Mais à force d’empiler les traitements, les validations, les copies et les jointures, l’on perd de vue l’essentiel : la donnée. Pas sa forme, pas son format, mais sa réalité métier », lance le CEO de Tabsdata.

Son constat est le suivant : les architectures traditionnelles ont échoué à fournir une solution durable à la fragmentation des sources, à l’évolution constante des schémas, à l’opacité des responsabilités et à l’inefficacité globale du transfert de données. Les pipelines ne permettent ni traçabilité, ni gouvernance, ni transparence. Pire : ils imposent aux data scientists de reconstituer, a posteriori, une réalité déjà modélisée ailleurs.

« Ce que nous essayons de faire, c’est d’éviter que chaque data scientist passe 80 % de son temps à comprendre ce que la donnée aurait dû être, le tout dans une situation qui empire face au volume et la diversité des sources », prétend-il.

Réunir producteurs et consommateurs de données

Au cœur de l’approche de Tabsdata, une idée partagée par d’autres éditeurs, dont Confluent : permettre aux propriétaires de données de publier des tables comme des événements, que d’autres services peuvent ensuite consommer en s’y abonnant. Chaque table publiée devient un contrat de données. Elle est versionnée, horodatée, historisée. Chaque modification est enregistrée, chaque transformation traçable. Pas besoin d’outils tiers pour la qualité ou la gouvernance. Tout est intégré nativement.

« Imaginez une équipe commerciale qui met à disposition ses prévisions hebdomadaires. Aujourd’hui, cela passe souvent par un fichier Excel envoyé à la finance. Pourquoi ne pas industrialiser cette logique ? », interroge Arvind Prabhakar.

Côté technique, le système repose sur une infrastructure open source (sous licence Apache) couplé à des extensions propriétaires brevetées. Il s’adresse aux ingénieurs de données familiers avec Python, se déploie en local, sur Kubernetes ou dans le cloud, et se facture non pas au volume, mais à la capacité – au nombre de cœurs sollicité pour effectuer les traitements.

Dans sa documentation, Tabsdata est présenté comme « un serveur de préproduction entre des systèmes de stockage ». Il peut être accédé depuis une interface en ligne de commandes (CLI) ou une interface utilisateur.

Au cœur de Tabsdata, trois types de fonctions Python. Il y a d’abord les « publishers » pour lire les données issues de systèmes externes sources et les écrire « dans une ou plusieurs tables Tabsdata ».

Au besoin, il est possible de faire appel à des « transformers », qui appliquent des transformations de données à une ou plusieurs tables Tabsdata. Ils servent à préparer les données pour les consommateurs des données (les applications ou les utilisateurs).

Les « Suscribers » lisent les données depuis les tables Tabsdata avant de les écrire dans le système externe cible.

Des déclencheurs automatisent la mise à jour des tables (par exemple à chaque nouvelle entrée dans le système source).

Cela permet de détecter automatiquement les différences entre deux ensembles de données. Le changement (ajout, suppression, modification) devient lui-même un événement. Tabsdata peut donc gérer nativement flux CDC (Change Data Capture).

Les tables Tabsdata organisées en lignes et en colonnes ne peuvent pas être enregistrées dans les systèmes sources ou cibles directement. Il faut les exporter sous forme de fichiers CSV, JSONL, NDJSON ou Parquet.

Ce qui peut s’apparenter à des produits de données au sein de Tabsdata se nomme des « collections ». Elles rassemblent un groupe de tables et les fonctions Python écrivant dans ces tables. Elles sont attribuées à une entité ou à un domaine métier.

« Nous avons choisi un modèle déclaratif. Chaque action est explicite. Pas de magie noire, pas de code imperméable. Tout le monde peut lire, comprendre et maintenir le système », vante le dirigeant.

Cette simplicité déclarative permettrait d’automatiser la mise à jour des jeux de données interdépendants, sans recourir à des orchestrateurs.

Cette approche, inspirée du shift left dans le développement logiciel, déplace les responsabilités vers l’amont : les producteurs de données deviennent les garants de leur qualité et de leur intégration. Fini les zones grises, les doublons, les conflits de version ou les responsabilités diluées promet la jeune pousse. Et, visuellement, l’interface de Tabsdata ressemble à celle de GitLab ou de GitHub.

En réalité, plusieurs acteurs du marché partagent cette ambition. Tabsdata s’inscrit dans la mouvance data-as-code décrite par Dremio.

Chaque table, immuable, peut faire l’objet, en quelque sorte, de « fork » de transformation.

Dans cette optique, Tabsdata devient le garant de la traçabilité. Le centre de collaboration pour les producteurs et consommateurs de données dans une organisation Data Mesh. Il faudrait donc l’adopter à large échelle pour en bénéficier véritablement.

« Nous ne parlons pas d’optimisation incrémentale, mais de changement de paradigme. Ce n’est pas facile à vendre, mais c’est nécessaire », considère le CEO de Tabsdata.

Tabsdata 1.1 est disponible

Le mécanisme réclame également de copier les données dans un système tiers, alors que les éditeurs de solutions tels que Databricks, Snowflake entendent unifier cette approche.

Tabsdata ne cherche pas à remplacer ces solutions. Son système ne copierait que la quantité de données nécessaires à la création d’un produit de données. Sans oublier les versions et les métadonnées associées.

D’ailleurs, la startup considère que les entrepôts ou les lacs de données sont inadaptés au rôle de hub central pour toute l’entreprise, à cause de leur coût, de leur rigidité et de leur manque de contrôle fin sur la gouvernance. « Ces plateformes sont utiles, mais elles ont leurs limites. Notre solution permet d’éviter les transferts massifs de données. Vous n’avez plus besoin de copier un million d’enregistrements pour en extraire douze », souligne Arvind Prabhakar.

Pour l’heure, plusieurs essais sont en cours dans des secteurs gourmands en données : technologie, assurance, cartes de crédit. Une question revient souvent lorsqu’on présente une nouvelle architecture de données : « Et avec quelles applications cela fonctionne-t-il ? ». Dès la conception, l’objectif a été de s’intégrer à la grande diversité des bases de données utilisées en entreprise, qu’elles soient relationnelles, orientées documents, sur site ou dans le cloud.

« Nous savons que les données vivent dans des environnements hétérogènes. MySQL, Postgres, Oracle, SQL Server, MongoDB, mais aussi les files Kafka, les buckets S3, les API REST ou les systèmes log… sans oublier les applications SaaS comme Salesforce. Tout cela fait partie du quotidien », explique le fondateur. « Notre système ne remplace pas ces bases. Il s’y connecte, les lit, les versionne, les transforme, et les republie ».

Ce modèle d’extraction permet une compatibilité avec toutes les bases de données classiques, tant que les logs de transaction sont accessibles. En cas contraire, d’autres méthodes comme le polling ou la comparaison différentielle entre les snapshots sont utilisées. « Ce que nous voulons éviter, c’est de vous forcer à installer un agent ou une passerelle propriétaire sur chaque source de données », assure le dirigeant de Tabsdata. « Nous préférons travailler à partir de connecteurs simples, configurables en Python, que l’on peut exécuter sur n’importe quelle infrastructure ».

Par ailleurs, Tabsdata permet aussi aux équipes métiers de publier directement leurs données, même si elles ne résident pas dans une base. « Si le service commercial travaille sur Excel, eh bien, qu’il publie un fichier CSV. C’est une table. » Cette ouverture fait de Tabsdata une brique transverse, utilisable en parallèle des systèmes existants.

Constituée en mai 2024, Tabsdata a levé ses premiers fonds en juillet 2024 (7 millions de dollars), essentiellement auprès d’anciens membres du conseil de StreamSets, tout particulièrement le fonds LOD Ventures dirigé par Pete Sancini. Après une bêta publique, le produit a été lancé en disponibilité générale au début du mois d’août.

Le cœur du système est open source, mais les fonctionnalités avancées – comme la traçabilité fine ou les mécanismes de contrôle de version – sont encapsulées dans des modules propriétaires.

« Nous avons choisi la discrétion pendant nos premiers mois pour construire notre portefeuille de brevets. Une fois notre technologie exposée, nous devions pouvoir la défendre ainsi que notre technologie, contre des fournisseurs aux poches bien remplies qui pourraient facilement nous attaquer », avance Arvind Prabhakar. « Car une fois le concept compris et le code rendu public, il devient très facile de le discréditer ou de le déconsidérer par rapport au positionnement sur le marché ».