S3 Tables, un nouveau format de bucket, permet d’utiliser des requêtes SQL pour modifier et sélectionner des archives de bases de données au format Iceberg.
Les responsables de bases de données auront beaucoup, beaucoup moins de scripts à écrire. Il existe désormais une troisième option de « formatage » d’un bucket S3 dans le service de stockage objet éponyme d’AWS : S3 Tables.
En substance, il s’agit de pouvoir stocker sur S3 des fichiers au format Apache Iceberg – qui correspondent à l’extraction au format texte compressé du contenu d’une base de données SQL – et de pouvoir continuer à accéder à ce contenu à l’aide de requêtes SQL. Comme s’il s’agissait d’un service de stockage en mode bloc hors de prix. Alors qu’en réalité S3 est un stockage en mode objet, peu cher et cantonné aux archives.
Les deux autres formatages d’un bucket S3 sont le mode normal, où les données sont répliquées sur deux autres sites, et le mode Directories, moins cher, où elles ne le sont pas.
Lire et écrire les archives comme si elles étaient des bases SQL
« L’usage est celui d’une base de données dont on n’a plus besoin en production, mais que l’on doit tout de même conserver sous la main. Parce que, régulièrement, tous les mois, tous les trimestres, tous les ans, on a besoin de mettre à jour ces données dans le cadre d’un rapport d’activité », contextualise Sébastien Stormacq, porte-parole technique d’AWS pour les solutions développeur, lors de l’événement AWS re:Invent 2024 qui se tient cette semaine à Las Vegas et qui a été le théâtre de plusieurs annonces concernant S3.
« La bonne pratique est de sortir ces données de la base SQL où leur coût de stockage est trop élevé. On peut les extraire dans un fichier au format Open source Iceberg, qui reste interrogeable par des requêtes SQL. Et, à partir du moment où il s’agit d’un fichier, il devient possible de le stocker sur une bucket S3 [équivalent d’un volume de fichiers dans la nomenclature du stockage objet, N.D.R.] qui, elle, coûte très peu cher », poursuit l’interlocuteur du MagIT.
« Tout cela existait déjà. Le bucket S3 rempli de fichiers au format Iceberg est ce que l’on appelle un Datalake. Si une application dispose d’un pilote Iceberg, elle peut sans problème consulter les contenus de ces fichiers avec des requêtes SQL – notre service de base de données Aurora et également notre service d’analytique QuickSight, par exemple, savent le faire directement. Pour les applications tierces, nous avons un service Data Glue qui présente le fichier Iceberg stocké en S3 comme une table SQL enregistrée sous forme de colonnes de données. Le problème est de modifier ces contenus. »
« Le formatage S3 Tables évite toute cette usine à gaz. Il s’occupe tout seul de recréer un fichier compacté à chaque modification par requête SQL. »
Sébastien StormacqPorte-parole technique d’AWS pour les solutions développeur
« Sur un stockage en mode bloc, il est simple de remplacer un bloc de données par un autre, mis à jour. Mais en S3, on ne remplace jamais les données. Le système les efface du fichier et ajoute à celui-ci les données mises à jour. Rapidement, on se retrouve avec des fichiers Iceberg qui sont remplis de trous et d’ajouts. Comme les ajouts ne sont pas compressés, cela finit par occuper beaucoup de place et par coûter de nouveau cher en stockage. »
« Pour parer à cela, l’administrateur des données doit créer des scripts qui sortent les fichiers de S3, qui les recompressent proprement, qui effacent l’ancienne version d’un fichier et qui stockent sur S3 sa nouvelle version. C’est très compliqué. Le formatage S3 Tables évite toute cette usine à gaz. Il s’occupe tout seul de recréer un fichier compacté à chaque modification par requête SQL », dit enfin Sébastien Stormacq.
Rendre aussi les métadonnées interrogeables en SQL
Mais si S3 Tables s’arrêtait à ces fonctionnalités, il serait incomplet. Chaque fichier Iceberg extrait d’une base de données est considéré comme une base de données à part entière.
« Lorsqu’on a par exemple des fichiers Iceberg qui ont été successivement créés, il n’est pas possible de sélectionner ensemble tous les fichiers enregistrés à partir d’une certaine date avec des requêtes SQL. Il faut là encore écrire des scripts qui parlent à l’API S3 pour retrouver les fichiers correspondant à la requête et les regrouper en un seul fichier, lequel sera interrogeable en SQL. C’est de nouveau compliqué », explique Sébastien Stormacq.
« Les métadonnées de S3 offrent de grandes possibilités de cataloguer les données. C’est utile, [...] que ce soit pour dresser des rapports, comme pour sélectionner uniquement certaines informations à donner à une IA. »
Sébastien StormacqPorte-parole technique d’AWS pour les solutions développeur
Ce problème est résolu par une nouvelle fonction de S3 appelée S3 Metadata. Elle consiste à présenter toutes les métadonnées enregistrées par S3 (date de création, etc.) sous forme de données SQL interrogeables directement.
« Les métadonnées de S3 offrent de grandes possibilités de cataloguer les données. C’est utile, quel que soit le flux de travail, que ce soit pour dresser des rapports, comme pour sélectionner uniquement certaines informations à donner à une IA. Mais encore faut-il que ces applications, écrites avec des requêtes SQL parce qu’elles sont historiques dans une entreprise par exemple, sachent relire ces métadonnées. C’est ce que nous faisons avec S3 Metadata », dit Sébastien Stormacq.
Une extension qui n’existe pas encore, mais dont Sébastien Stormacq spécule qu’elle pourrait arriver, serait que S3 Metadata transforme les relations entre données telles qu’elles sont enregistrées dans une base comme RedShift ou DynamoDB en métadonnées S3.
« L’API pour le faire existe désormais, donc ce serait un développement raisonnable de notre part », suggère-t-il. « Il faudrait même que les utilisateurs puissent s’en servir pour enrichir les fichiers Iceberg de métadonnées métier. Typiquement pour étiqueter les informations sensibles en amont d’un traitement par une IA, pour savoir quel salarié a le droit d’accéder à quelles données, etc. ».
Vérifier l’intégrité des données téléchargées
Une troisième nouveauté liée à S3 est celle de l’intégration des codes de parité (checksums) dans le SDK du système de stockage.
« Les développeurs d’applications qui téléchargent des données vers notre cloud vont pouvoir calculer un code de parité à la source pour vérifier que le transfert s’est bien déroulé. »
Sébastien StormacqPorte-parole technique d’AWS pour les solutions développeur
« Les codes de parité servent à vérifier qu’une copie des données est bien identique à l’original. Ils fonctionnent depuis toujours entre les différentes régions d’AWS, mais pas entre le site d’un utilisateur et notre cloud. Donner accès à cette fonction dans le SDK de S3 signifie que les développeurs d’applications qui téléchargent des données vers notre cloud vont pouvoir calculer un code de parité à la source pour vérifier que le transfert s’est bien déroulé », résume Sébastien Stormacq.
En l’occurrence, le code de parité calculé à la source est intégré aux métadonnées de l’objet. À la destination, le serveur S3 recalcule un code de parité selon les données qu’il a reçues et le compare avec le code de parité envoyé par la source.
Manifestement, ce dispositif fonctionne aussi lorsqu’une application transfère une grosse quantité de données par petits bouts. Le code de parité est calculé sur la totalité des données envoyées et reçues.
L’accès à ces fonctions de développement est gratuit.
