IA + Apache Iceberg : Plus ça change, plus c’est la même chose

Le data lakehouse et l’IA représentent deux changements titanesques auxquels nous sommes confrontés. Avec eux, on peut avoir l’impression que tout change sous nos pieds, et franchement, c’est parce que c’est effectivement le cas. Nous avons Iceberg, nous avons les agents LLM, et tout est vraiment sur le point de changer. Mais comme c’est souvent le cas avec ces expressions idiomatiques, nous ne devrions pas les prendre au pied de la lettre. Certaines choses ne vont pas changer : les atomes restent des atomes, et fondamentalement, les données et de nombreux défis qui les entourent restent les mêmes. Cela dit, je ne peux pas vraiment penser à des choses qui ne changent pas, alors je vous laisse méditer sur ce point.

Mon objectif pour cette modeste présentation est d’essayer de vous aider à naviguer entre ce qui change et ce qui ne change pas dans le monde des données.

Qui suis-je ?

Avant d’aller trop loin, permettez-moi de me présenter. Je m’appelle Charles Jardine, je suis l’un des ingénieurs fondateurs et VP d’ingénierie chez airbyte. Je travaille comme ingénieur logiciel dans le domaine des données depuis plus d’une décennie, et dans chaque emploi que j’ai occupé, j’ai dû reconstruire les mêmes pipelines ELT encore et encore. Ma mission personnelle est donc de construire des outils ELT pour que la prochaine génération d’ingénieurs logiciels n’ait plus à penser à l’EL, tout comme je n’ai pas à passer beaucoup de temps à penser au code assembleur. Je ne pense pas que les ingénieurs logiciels devraient passer beaucoup de temps à réfléchir à l’EL. Fondamentalement, j’adore ce domaine. Je me sens très chanceux d’être au cœur de cette révolution de l’IA et des données, et il y a une histoire fascinante à raconter alors que cette histoire se déroule.

Une collision historique

En parlant d’histoire, je pense que l’image de collision entre l’IA et Iceberg est en fait un peu trompeuse. Car au lieu d’être l’une des grandes tragédies du début du 20e siècle comme l’a été le Titanic, je pense que cette collision sera l’un des événements déterminants du 21e siècle.

Pour le reste de cette présentation, nous allons explorer ce qui change et ce qui ne change pas dans le monde des données.

Ce qui ne change pas : ELT reste supérieur à ETL

Commençons par un point simple : l’ELT demeure un meilleur paradigme dans le monde de l’IA que l’ETL. Airbyte a longtemps prêché cela, donc rien de nouveau ici, mais la forme des charges de travail d’IA ne fait que renforcer ce paradigme. La bonne nouvelle est qu’Iceberg a rendu beaucoup plus facile de suivre ce paradigme, et c’est toujours agréable quand faire la bonne chose devient aussi la chose la plus simple.

Pour rappel, ETL est en quelque sorte le paradigme original pour le mouvement des données dans un monde où le disque était limité et pas très bon marché. Extraire des données puis les transformer en vol avant de les charger dans la destination finale avait beaucoup de sens. Une fois que le disque est devenu essentiellement gratuit, l’ELT est devenu particulièrement plus important, surtout à l’apogée de la stack de données moderne.

L’idée est que vous extrayez vos données et les modifiez aussi peu que possible avant de les charger dans votre entrepôt de données ou data lake. Après avoir stocké une copie brute de vos données, vous procédez ensuite aux transformations. Pourquoi voudriez-vous faire cela ? Il s’avère que l’extraction de données est en réalité très coûteuse, et il y a plusieurs facteurs derrière ce coût :

1. Le simple déplacement des octets et le paiement du réseau et du calcul peuvent vraiment s’additionner, vous voulez donc vous mettre dans une position où vous pouvez découpler l’extraction et le chargement (que vous voulez vraiment faire une seule fois) de la transformation (sur laquelle vous pourriez vouloir itérer au fil du temps).

2. La plupart des sources de données sont plus lentes que votre entrepôt de données ou votre data lake. Prenons un exemple : si vous essayez d’extraire toutes vos données d’une plateforme d’e-mailing, ce sera plus lent que si vous avez déjà ces données mises en cache dans votre data lake ou entrepôt de données, prêtes à être interrogées. Ajoutez à cela des limitations de taux et soudainement, obtenir ces données de votre API à un moment donné devient assez difficile.

3. Enfin, si la disponibilité des données est importante pour vous, la meilleure façon de la garantir est de stocker ces données près de l’endroit où vous allez réellement les utiliser.

Le déplacement des données reste difficile

Ce qui n’a pas changé, c’est que déplacer de grandes quantités de données reste difficile, tant en termes de temps que de coût. Une fois que vous déplacez les données, vous ne voulez jamais vraiment les déplacer à nouveau. Et comme les données continuent de grossir, ce paradigme ne fera que se renforcer.

C’est un problème qu’il est facile de négliger, alors permettez-moi de vous présenter un exemple simple : supposons que vous ayez créé une table de base de données et utilisé un entier comme clé primaire. Vous n’auriez probablement pas dû faire cela. Une fois que la table dépasse environ 4 milliards d’enregistrements, l’entier va déborder et vous devrez migrer votre colonne de clé primaire vers un bigint ou un UUID.

Si vous avez déjà dû gérer une telle migration, vous savez à quel point cela peut être douloureux. Généralement, vous ne remarquez le problème que lorsque vous avez déjà épuisé l’espace des entiers, et donc la table est déjà en panne. Ensuite, la migration prend beaucoup de temps à s’exécuter car elle s’exécute sur quatre milliards d’enregistrements et peut avoir des effets négatifs sur les performances du reste de votre base de données.

Soyons honnêtes, les données dont nous parlons ici ne sont même pas si volumineuses – elles tiennent encore toutes sur un seul disque. Une fois que vous commencez à penser aux systèmes distribués, ce problème s’aggrave encore davantage.

Dans le monde du Big Data, tout ce qui vous oblige à réécrire toutes vos données est une mauvaise option. Iceberg change fondamentalement ce paradigme en séparant le stockage et en vous permettant d’interroger les données dans un schéma logique sans avoir à modifier les données sous-jacentes. Cela élimine le besoin de migrations de schéma coûteuses et garantit que les données peuvent évoluer sans perturbation. Vous arrivez ainsi à un point où vous ne devez déplacer les données qu’une seule fois, puis plus jamais.

Ce qui change : les données non structurées et les fichiers

Changeons maintenant de perspective. Commençons par ce qui change réellement.

Premièrement, les données non structurées et les fichiers n’étaient pas vraiment un élément courant des charges de travail de la plupart des équipes de données à l’apogée de la stack de données moderne. Maintenant, avec l’IA, tout le monde traite ces fichiers et les alimente aux LLM (Large Language Models) parce que les LLM peuvent faire des choses assez intéressantes avec les PDF et les fichiers multimédias.

Ce qui change ici, c’est que l’outil de stockage dont vous avez besoin doit être vraiment bon pour stocker des fichiers. Les entrepôts de données ont eu tendance à avoir un support assez limité pour cela, et bien qu’ils rattrapent leur retard, l’interaction reste assez maladroite. Iceberg, en revanche, est nativement axé sur les fichiers et vous permet de stocker des médias et des données structurées ensemble d’une manière logique, plutôt que de forcer une séparation artificielle.

Ce qui ne change pas : l’importance de l’accès aux données

Ce qui ne change pas, c’est que même si nous parlons de fichiers au lieu d’enregistrements, ces données ne sont utiles que si votre opération de données y a réellement accès. Il s’avère que nous allons continuer à faire cette extraction et ce chargement pendant longtemps encore. Ce n’est pas près de disparaître.

Ce qui est nouveau avec toutes ces données non structurées, c’est que les gens veulent faire beaucoup plus de transformations, et dans ce monde, SQL n’est pas vraiment le choix pour beaucoup de ces transformations. Et ces transformations évoluent incroyablement rapidement : il y a beaucoup de conversions de média en texte, de média en vecteurs, et l’état de l’art dans ce domaine change énormément.

Ce qui ne change pas, c’est que vous devriez extraire vos données et les charger dans votre entrepôt de données sous leur forme brute avant de faire tout type de transformation. En fait, cette focalisation sur les transformations pousse ce paradigme encore plus loin, car à mesure que l’état de l’art change, vous allez devoir refaire ces transformations. Quelle que soit la représentation vectorielle que vous avez d’un document maintenant, elle sera différente dans six mois, et six mois après cela. Vous ne voudrez pas avoir à extraire à nouveau toutes ces données de la source pour faire cette transformation. Vous voudrez avoir une copie mise en cache dans votre data lake, et Iceberg est une très bonne option pour cela.

Les agents LLM comme consommateurs de données

Un autre changement significatif est la prévalence croissante des LLM et des agents IA en tant que consommateurs de vos données, à la place des humains.

Ce qui ne change pas, cependant, c’est que pour que l’agent utilise correctement ces données, elles doivent être présentes, correctes et accompagnées de toutes leurs métadonnées. Cela inclut des éléments comme les permissions, la lignée et toute documentation pertinente.

En interne chez airbyte, nous appelons cela le principe de l’ingénieur junior IA : tout comme lorsque vous intégrez un ingénieur junior dans votre équipe, il aura beaucoup plus facile si vous avez une documentation décente et des conventions très claires. Il en va de même lorsque vous intégrez une IA dans votre base de code ou vos données. Si vous avez la bonne documentation et les bonnes conventions, elle peut s’intégrer beaucoup plus rapidement et faire un bien meilleur travail.

Fondamentalement, les agents, bien qu’ils semblent magiques, ne peuvent pas magiquement travailler avec des données cassées et non documentées.

Les agents peuvent toujours être à l’écoute, ils n’ont pas besoin de dormir comme les humains. Ainsi, alors que les consommateurs humains pensent naturellement aux données en termes de lots (puisque nous ne vérifions les choses que de temps en temps), l’agent peut vraiment bénéficier de données à faible latence. Cela ne signifie pas que le traitement par lots va disparaître – les mêmes économies qui ont prévalu pour ce type de traitement au cours de la dernière décennie continueront à s’appliquer.

Enfin, les agents vont être responsables de beaucoup plus d’analyses et, dans le cadre de ce travail, ils devront construire eux-mêmes des pipelines de données. Ce qui ne change pas ici, c’est que pour ce faire, l’agent doit travailler à partir du même ensemble de données canonique à chaque fois.

Une architecture pour l’ère de l’IA

Voici un aperçu de ce à quoi je pense que cela devrait ressembler : vous extrayez des données de tous vos silos de données pour créer, disons, une table client. Vous extrayez donc des données de votre base de données d’application, de Clearbit, de Salesforce, etc.

Ces données doivent être soigneusement organisées, car la façon dont vous encodez et construisez sont des choix très spécifiques à votre entreprise, qu’il sera très difficile pour un LLM de faire pour vous. Vous pouvez certainement utiliser un LLM pour vous aider sur certains travaux de base ou faire des suggestions. Après avoir construit ces tables métier fondamentales, des analyses ultérieures peuvent être exécutées sur celles-ci.

Dans cet exemple, j’ai les agents qui arrivent et nous leur posons diverses questions, et ils s’appuient sur ces tables métier fondamentales, puis construisent leurs propres ensembles de données éphémères par-dessus pour répondre aux questions.

L’élément clé ici est que tous ces agents peuvent être fiables car ils travaillent tous à partir de la même ontologie partagée, de sorte qu’ils sont à la fois comparables entre eux et devraient être reproductibles.

Pourquoi les data lakes restent essentiels

J’entends des gens demander si, avec les agents, nous avons même besoin de data lakes, ou si tout serait éphémère. La réponse est que le data lake est en fait encore plus important dans ce monde.

Imaginez un monde sans ces tables métier : l’agent va essayer de prendre ces données brutes, les joindre pour créer une notion de client, puis utiliser ces données pour répondre à votre question. Il pourrait avoir de la chance et assembler ces données pour créer une notion raisonnable de client (j’en douterais, mais pour les besoins de l’argument, disons qu’il fait un travail correct).

Le vrai problème est que la prochaine question que vous posez, un autre agent va devoir construire sa propre notion de client. Vous allez donc vous retrouver avec « client prime » dans l’exemple que j’ai sur la diapositive. L’agent se voit poser deux questions différentes, mais vous pouvez imaginer simplement poser la même question à différents agents. La probabilité qu’ils arrivent à la même notion de client est incroyablement faible.

À ce moment-là, aucune de vos analyses ne sera comparable entre elles et vous perdrez la reproductibilité, ce qui rendra cette analyse franchement pire qu’inutile. Pour tirer de la valeur de ces ensembles de données éphémères, ils doivent être construits sur des tables métier bien définies. Sinon, nous serons dans un monde où les agents ne peuvent même pas s’accorder sur ce qu’est un client.

Conclusion

Sur la base de tout cela, j’espère vous avoir convaincu que le data lake joue un rôle central dans l’IA. Je pense que le résumé de cette conversation est que tout change, qu’Iceberg était un bon changement de paradigme avant l’IA et un encore meilleur après.

Sur ce, allez-y, utilisez ces outils et faites l’histoire avec eux. Merci !

Featured image by Derek Oyen on Unsplash