re:Invent : que retenir ? (Jour 1 - data[base|lake|for AI] et assistant de code)

Re:Invent, Jour 1 : c'est fini ! Au menu du jour, données, bases de données, et utilisation des données pour l'IA !

Bases de données

Il y a un mois, AWS annonçait la couleur avec Aurora PostgreSQL Limitless Database, une base de données avec un stockage partitionné : certaines tables (les tables de référence sont copiées sur tous les noeuds du cluster, les tables standard sur un unique noeud et des tables partitionnées ont une fraction de leur données sur chaque noeud, avec la possibilité de positionner sur le même noeud des données liées par une jointure). Cette base est facturée l'usage (par "ACU", comme Aurora).

Aujourd'hui, c'est DSQL (pour Distributed SQL) qui est annoncée, une base serverless multi-régions avec un fonctionnement actif-actif (on peut écrire dans toutes les régions de façon concurrente, et une écriture passée dans une région est immédiatement lisible dans toutes les régions). Grâce à un système d'horloges atomiques coordonnées (et de la fibre à basse latence), AWS repousse les limites des transactions "ACID".

Pas de miracle cependant, la capacité à scaler sur une architecture distribuée nécessite des compromis : si on regarde la documentation de DSQL, on voit

• qu'il n'est pas possible d'obtenir un verrou de transaction (transaction lock), mais qu'on a au mieux de l'optimistic locking : les équipes de développement devront mettre en place un mécanisme de gestion des conflits (par ex. faire du retry au cas où la base indique que la donnée sous-jacente à un update a déjà été modifiée par un autre client)
• qu'une fois qu'une table possède des données, on peut créer uniquement des index asynchrones
• qu'il n'y a pas la possibilité de faire des contraintes de type clé étrangère, ni de vues, ni de séquences (mais qui utilise encore des séquences en 2024 ? #UUID)

Lac de données

Les lacs de données permettent de stocker, sans déclaration préalable de schéma, des données non-structurées, semi-structurées (ex. documents) ou structurées (tables), dans un même stockage, S3. Ce mode de fonctionnement permet de découpler le stockage du calcul et d'utiliser le même stockage pour des usages différents (Data Science, reporting/BI, interrogation par une application).

Pour requêter, il est nécessaire de parcourir les données pour en inférer le schéma, et pour le faire efficacement (sans parcourir toutes les données), découvrir la manière dont les données sont partitionnées (par ex. toutes les données d'un jour sont dans un même "dossier"). Pour les données tabulaires, un leader open source se dégage pour cette description de métadonnées, Apache Iceberg.

Hier, AWS a annoncé :

• S3 Tables, un stockage compatible avec l'API S3 qui offrent de très hautes performances pour les données tabulaires stockées dans une table Apache Iceberg. Ce stockage effectue en autonomie des opérations auparavant nécessaires pour augmenter la performance et réduire le coût, comme la compaction des données (rassembler N fichiers dans un seul)
• Des métadonnées S3 requêtables. Cette évolution résout un grand défaut du stockage S3 : la recherche. Auparavant il était nécessaire de lancer des inventaires (qui ne permettaient même pas de recenser les tags).

Les entrepôts de données permettent de stocker la donnée de façon plus adaptée aux usages de BI (fortement consommateurs de "group by" et de fonctions d'agrégation sur un nombre limité de colonnes).

Alors lac ou entrepôt ? Les deux, mais de façon transparente pour le consommateur ! L'an dernier déjà, la tendance était à l'unification de l'expérience utilisateur autour de la data, avec l'annonce d'intégrations "zero-ETL".

• SageMaker Lakehouse permet de requêter indifférement des données dans des datalakes basés sur S3 ou dans un entrepôt Redshift (ou bientôt SnowFlake, ou BiQUery..). De façon transparente pour l'utilisateur, tant au niveau du stockage sous-jacent que des permissions, qui sont gérées de façon unifiée.

Cette idée d'unification et de simplification de l'offre d'outils est également au coeur de la création de SageMaker Unified Studio. Est-ce "yet another UI for SageMaker" après la création de Studio il y a seulement un an ? Difficile d'en dire plus car même la documentation produit n'est pas encore en ligne à l'heure où je clos ce post (mais travaillant sur un sujet MLOps je vais sans doute jouer avec la preview dans les prochains jours)

IA Générative

Ca se bouscule côté IA générative avec :

• Une famille de LLM (Large Language Models), Nova, successeurs d'Amazon Titan et annoncés comme de performance équivalentes ou meilleures que leurs concurrents pour un prix quatre fois inférieur.
• BedRock Multi-Agent collaboration, un service managé pour coordonner des agents IA dans la réalisation d'une tâche. J'avais été extrêmement impressionné par l'exemple multi-agents publié sur le blog d'AlterWay en février dernier (oui, ça paraît 10 ans dans le monde de l'IA). Mais à l'époque il fallait prendre un framework balbutiant et tout faire soi-même. Ici, quelques clics (ou lignes de code Terraform) vous permettront de mettre ça en place.
• BedRock Automated Reasoning Checks va vous permettre de garantir que votre LLM ne va pas seulement aligner des mots les uns derrières les autres, avec son lot d'hallucinations, mais au contraire donner une information de qualité conforme par ex. à une fiche technique. La semaine dernière, j'assistais à une conférence de Véolia où ils montraient comment un LLM assistait la conduite d'usine en allant trouver de l'information dans la documentation technique. Jusqu'ici, l'information devait toujours être vérifiée par le lecteur... et demain ?

Assistants à base d'IA

Q for Developers se voit doter d'une série de fonctionnalités supplémentaires :

• Ecrire la documentation, faire des code reviews ou écrire des tests sur une application existante
• voire.. prendre en charge des tickets / tâches de dev si vous utilisez GitLab. C'était déjà possible avec CodeCatalyst depuis presque un an (cf. l'excellente présentation de mon camarade poitevin Laurent Delhomme) mais voir arriver ça sur une plateforme populaire comme GitLab sera un game changer.

Concernant les assistants métier, Amazon Q for Business annonce deux évolutions notables

• la possibilité d'accéder directement à vos bases et lacs de données, permettant à l'IA, pour répondre à une question, de consulter non seulement une base documentaire, mais également des analytics (par ex. si vous faites un dashboard QuickSight par client).
• la possibilité pour les éditeurs de logiciel de permettre aux agents IA de leurs clients d'indexer les données qui leur appartiennent dans le SaaS de l'éditeur, ou à l'inverse de permettre aux clients de partager leurs sources de données avec l'agent IA qu'eux-mêmes auront développé avec Q.

That's all, folks!

A demain pour la suite!