AWS a annoncé l’ajout de la possibilité d’interroger directement des données Apache Iceberg et Apache Parquet stockées dans un lac de données, parallèlement aux données opérationnelles au sein d’Amazon Aurora PostgreSQL. Cette nouvelle capacité permet aux applications de combiner les enregistrements récents et historiques dans une seule requête en utilisant la syntaxe PostgreSQL et les outils existants, sans copier les données dans la base de données au moyen de pipelines ETL.
Qu’est-ce qui a changé concrètement ?
La fonctionnalité repose sur le moteur DuckDB intégré directement à Aurora PostgreSQL. Ainsi, une seule requête peut lire les données opérationnelles, y compris les écritures non validées, et lire des tables Iceberg ou des fichiers Parquet depuis Amazon S3. AWS Glue Data Catalog, Amazon S3 et S3 Tables sont également pris en charge, tout comme les catalogues compatibles avec Iceberg REST Catalog via le mécanisme de federation dans Glue.
L’utilisateur doit créer un cluster Aurora PostgreSQL, lui associer un rôle IAM incluant la fonctionnalité AuroraAnalytics, puis activer l’extension aurora_analytics. Il peut ensuite créer des foreign tables faisant référence aux données externes, ou utiliser IMPORT FOREIGN SCHEMA pour créer automatiquement plusieurs tables en déduisant le schéma des données à partir des métadonnées.
Pourquoi cette annonce est-elle importante ?
Les applications qui combinent des transactions récentes dans Aurora et des enregistrements historiques dans S3 devaient généralement copier les données au moyen du reverse ETL, ce qui ajoutait des opérations de synchronisation, des coûts opérationnels et une complexité d’ingénierie. Désormais, cette intégration peut être réalisée pendant l’exécution de la requête elle-même. Cela est utile pour les tableaux de bord qui nécessitent un contexte historique, les applications qui associent une transaction à un enregistrement antérieur et les systèmes qui traitent des données réparties entre une base opérationnelle et un lac de données.
Ce point revêt une importance supplémentaire dans les applications qui utilisent des agents d’intelligence artificielle, car il est difficile de prévoir à l’avance chaque ensemble de données dont l’agent pourrait avoir besoin et de le copier dans une base opérationnelle. L’accès direct permet d’élargir l’étendue des données disponibles sans créer une copie pour chaque cas d’utilisation.
Performances et options d’accès
Aurora applique des optimisations telles que le transfert des filtres vers la source de données et la réduction du nombre de colonnes lues, et met temporairement en cache les données fréquemment utilisées au sein de l’instance Aurora. Le comportement de chaque requête peut être examiné au moyen de la fonction aurora_analytics_stat_statements(), qui affiche notamment le nombre de lignes examinées, le volume de données lues depuis S3 et le nombre de fois où le cache a été utilisé.
Les requêtes sont disponibles sur les différentes instances Aurora au sein du cluster, y compris l’instance d’écriture et les réplicas dédiés à la lecture, ce qui permet d’affecter les opérations d’analyse lourdes à des instances distinctes de la charge opérationnelle. Pour les cas nécessitant des temps de réponse de l’ordre de la milliseconde, les données peuvent être matérialisées dans une table Aurora native au moyen de CREATE TABLE AS SELECT, INSERT INTO ... SELECT ou MERGE INTO. Les opérations d’écriture résultant de la matérialisation sont exécutées sur l’instance d’écriture.
Disponibilité et coût
Cette capacité prend en charge Aurora PostgreSQL 17 à partir de la version 17.11, et la version 18 à partir de la version 18.6. Elle est disponible dans toutes les régions AWS commerciales et les régions AWS GovCloud (US), sans frais supplémentaires pour la fonctionnalité elle-même. Le coût reste lié à l’augmentation de la capacité de calcul Aurora consommée par les requêtes, ainsi qu’aux frais de requêtes Amazon S3 pour la lecture des fichiers du lac de données.
Lecture de certi.news : le changement fondamental ne consiste pas à ajouter un nouveau format de stockage, mais à réduire la distance entre la base de données opérationnelle et le lac de données. Cela ne supprime toutefois pas les considérations liées à la conception des charges de travail : l’interrogation directe convient à un accès flexible aux données, tandis que la matérialisation reste nécessaire lorsque des temps de réponse extrêmement faibles constituent une priorité. De même, la consommation de capacité de calcul Aurora et les requêtes S3 resteront des facteurs à mesurer en fonction du modèle de requête et du volume de données.