Matt Garman ayant défloré la quasi-totalité des annonces hier (allant jusqu'au rythme d'une annonce de fonctionnalité toutes les 24 secondes dans un sprint de 10' en fin de keynote), le what's new est un peu plus vide ce matin.
Mais c'est l'occasion de prendre un peu de recul et de jeter un oeil aux nombreuses sessions (toutes mise en vidéo sur le compte Youtube @awsevents). Et hier, le thème était clairement : comment aller vers l'IA ? En préparant vos data.
Approche sémantique : S3 Vectors et Valkey
Les données vectorielles permettent aux LLMs de faire des rapprochements sémantiques entre une question, ou une conversation, et des documents (textes, images, vidéos) de votre base documentaire.
Jusqu'ici, pour utiliser ces données, il fallait utiliser une base de données dédiées, comme OpenSearch ou PostgreSQL avec pgvectors. Toute ça coûte un peu cher..
Sorti en pré-version en cours d'année, S3 Vectors est maintenant un service AWS pleinement supporté, avec un gain de performance notable. Il est maintenant directement intégré avec Bedrock Knowledge base.
Les agents IA peuvent donc désormais rechercher facilement des documents encodés sous forme de vecteurs.
Néanmoins, les agents coûtant également cher et, dans la pratique, répondront assez souvent aux mêmes questions. De la même manière que votre appli web peut utiliser un side-cache au niveau de la BDD pour éviter de trop la solliciter, vous pouvez désormais utiliser un cache sémantique avec Valkey
Pour savoir comment ça fonctionne, je vous partage ci-dessous une conférence à ce sujet que j'ai trouvée passionnante : "Optimize gen AI apps with semantic caching in Amazon ElastiCache (DAT451)".
Approche tabulaire : S3 Tables et Apache Iceberg
Dans de nombreuses entreprises, le défi reste encore de pouvoir mobiliser toute la donnée structurée pour de la BI ou du Machine Learning.
Tous les services d'analytics AWS sont désormais alignés pour supporter les tables Apache Iceberg dans sa version v3 (Redshift, qui pouvait seulement les lire, peut maintenant les écrire).
Côté Athena : il y a de nombreuses évolutions !
- certaines sont quasi-invisibles pour nous, mais permettent des gains de performance (et de coût) considérables : l'indexation des colonnes dans les fichiers Parquet, le fait de pousser de plus en plus de prédicats au niveau stockage (et donc éviter de récupérer et traiter en mémoire de la donnée inutile pour la requête en cours).
- d'autres sont de petits trucs pratiques : depuis juin, il n'y a plus besoin de gérer l'emplacement S3 d'arrivée du résultat de vos requêtes Athena.
Parmi les évolutions qu'il me semble important de noter : l'arrivée des vues matérialisées dans Glue !!!
Rafraichies sur événement ou de façon planifiées, ces vues vont vous permettre de mettre en place des pipelines complexes avec des étapes intermédiaires matérialisées, tout en SQL, sans avoir à gérer la mise à jour des données.
Ce talk détaille l'ensemble des évolutions sur Redshift et Athena
Et l'infra sous-jacente ? S3 !
Une des questions que je me suis posées il y a quelques temps était : quelles sont les performances maximales que je peux tirer de S3 ? Si vous prenez une lambda en python et que vous faite un basique GetObject, vous aurez 70-100Mbps par secondes. Mais on peut aller beaucoup plus vite.
Dans ce talk Ian Mc Garry, directeur du développement logiciel sur S3, montre comment vous pouvez aller chercher une performance quasi-illimitée grâce à l'AWS Common Runtime: ça parle de "ListParts", de "Range GET" côté client, et côté back, de préfixes, de directory buckets / One-Zone et de session durable (s3:CreateSession) pour gagner du temps sur l'authentification de chaque requête.
Si vous souhaitez savoir comment fonctionne l'infra S3, je vous conseille deux conférences très riches :
- Tout d'abord l'innovation talk d'Andy Warfield, VP Storage d'AWS qui donne un aperçu des évolutions de l'infra sous-jacente au service
- Ensuite, celui de Carl Summers qui explique comment S3 gère ses logs
Top comments (0)