Contexte et nouveauté
Amazon Aurora PostgreSQL, service de base de données relationnelle managé compatible PostgreSQL, a annoncé la capacité de requêter directement des jeux de données stockés au format Apache Iceberg et Apache Parquet dans un data lake. Cette évolution élimine la nécessité d’étapes intermédiaires de chargement ou de transformation, permettant aux applications PostgreSQL existantes d’accéder aux fichiers S3 sans modification du code client.
Architecture de l’intégration
Le moteur Aurora exploite le connecteur natif d’AWS qui traduit les requêtes SQL en opérations de lecture sur les métadonnées Iceberg et les blocs de colonnes Parquet. Iceberg fournit un catalogue de versions et de partitions, tandis que Parquet stocke les colonnes de façon compressée et orientée colonne. Aurora interroge le catalogue Iceberg pour identifier les fichiers pertinents, puis applique un push‑down de filtres afin de ne lire que les colonnes et les rangées nécessaires. Le processus s’appuie sur les autorisations IAM du rôle associé à la base de données, garantissant que les accès aux buckets S3 restent contrôlés.
Impacts sur les charges de travail
Cette fonctionnalité simplifie les pipelines d’analyse où les données brutes résident déjà dans le data lake. Les analystes peuvent exécuter des requêtes analytiques classiques (SELECT, JOIN, AGGREGATE) directement depuis leurs outils PostgreSQL habituels, comme pgAdmin ou des bibliothèques Python, sans recourir à des moteurs séparés tels que Athena ou Redshift Spectrum. Le modèle de facturation reste celui d’Aurora, ce qui peut réduire les coûts opérationnels lorsqu’une même charge de travail combine transactions OLTP et analyses ad‑hoc. De plus, la prise en charge native évite la duplication de données, limitant ainsi les risques de divergence entre le data lake et les tables matérialisées.
Limites et bonnes pratiques
Le support actuel se limite à la lecture ; les opérations d’écriture ou de mise à jour des tables Iceberg via Aurora ne sont pas encore disponibles. Les performances dépendent fortement de la localisation des fichiers S3, de la taille des blocs Parquet et du degré de partitionnement Iceberg. Un partitionnement inadéquat peut entraîner des scans de fichiers complets, augmentant la latence. Il est recommandé d’utiliser des partitions basées sur les colonnes fréquemment filtrées et de configurer le stockage S3 en mode « Intelligent‑Tiering » pour optimiser les coûts d’accès. Enfin, la compatibilité est assurée avec les versions PostgreSQL prises en charge par Aurora au moment de la mise à jour ; les clients doivent vérifier la version du moteur avant de déployer des requêtes complexes.
