fr.wedoany.com Rapport : pgEdge, fournisseur de PostgreSQL distribué, lance la version bêta de ColdFront, une architecture de stratification des données à chaud et à froid native de PostgreSQL, conçue pour migrer automatiquement les données plus anciennes vers le stockage objet Apache Iceberg, tout en faisant de PostgreSQL la seule base de données avec laquelle les applications doivent interagir.
Depuis des années, les entreprises maintiennent généralement séparés les systèmes de traitement transactionnel (OLTP) et analytique (OLAP), même si cela implique de déplacer les données entre les deux. L'essor des agents autonomes et des applications d'IA, qui exigent un accès immédiat aux données et génèrent d'importants volumes de données opérationnelles, a mis en évidence le coût et la complexité de la maintenance de systèmes indépendants. Le secteur a rapidement réagi : les fournisseurs d'entrepôts de données et de bases de données proposent diverses méthodes pour briser les silos de données. Ces dernières semaines, Databricks a lancé LTAP, EDB a dévoilé l'analyse convergente, et fin 2023, Snowflake a publié pg_lake, offrant différentes voies pour intégrer les charges de travail transactionnelles, analytiques et d'IA.
ColdFront de pgEdge adopte une stratification des données à chaud et à froid, où « chaud » et « froid » désignent respectivement les données récentes et plus anciennes. Selon Phillip Merrick, cofondateur de pgEdge, les requêtes sur les données récentes continuent de s'exécuter sur PostgreSQL, tandis que les demandes concernant les enregistrements plus anciens sont traitées de manière transparente via le moteur d'analyse embarqué DuckDB, permettant aux applications d'utiliser le même SQL sans introduire de pipeline ETL, de chemin de requête séparé ou de modification d'application. Les enregistrements plus anciens stockés dans Iceberg peuvent également être mis à jour via PostgreSQL, réalisant ce que Merrick appelle une « couche froide accessible en écriture ».
Ashish Chaturvedi, responsable exécutif de la recherche chez HFS Research, indique que ColdFront considère Iceberg uniquement comme une couche de stockage transparente derrière PostgreSQL, déplaçant automatiquement les données plus anciennes hors de la base de données tout en permettant aux applications d'utiliser les mêmes tables et le même SQL. En comparaison, LTAP de Databricks connecte les applications opérationnelles au lakehouse, EDB utilise PostgreSQL comme source de données opérationnelles et expose les données via Iceberg, tandis que pg_lake de Snowflake écrit directement les données PostgreSQL dans Iceberg, permettant à PostgreSQL et Snowflake d'interroger les mêmes données.
Amit Chandak, responsable principal de l'analyse chez le cabinet de conseil IT Kanerika, souligne que les entreprises doivent conserver les données opérationnelles historiques générées par les applications d'IA à des fins d'audit et de conformité réglementaire. Par conséquent, la possibilité de corriger, supprimer ou modifier des enregistrements après leur déplacement vers un stockage moins coûteux est cruciale pour respecter les lois sur la protection des données et la vie privée. Chaturvedi explique que ColdFront simplifie ce processus : « Dans la plupart des systèmes de stratification, les données froides sont en lecture seule ; une demande de suppression GDPR nécessite une restauration, une suppression et une réarchivage, ce qui prend une demi-journée. ColdFront permet de mettre à jour et de supprimer des lignes de données archivées avec une seule instruction SQL. » Igor Ikonnikov, chercheur consultant chez Info-Tech Research Group, note que les entreprises des secteurs financier, de la santé et gouvernemental souhaitent conserver les données opérationnelles sensibles sur une infrastructure contrôlée par le client, tout en conservant la capacité de modifier l'historique. L'architecture de ColdFront est particulièrement importante à cet égard.
Ikonnikov souligne que toutes les solutions dépendent de DuckDB : « ColdFront utilise DuckDB pour exécuter des requêtes sur les données Iceberg, pg_lake de Snowflake achemine les requêtes Iceberg via pgduck_server, et Lakebase de Databricks repose également en interne sur DuckDB. DuckDB devient de facto le moteur d'analyse embarqué de la nouvelle génération d'architectures PostgreSQL-Iceberg. » Cette dépendance présente un risque concentré : si DuckDB est confronté à des changements de licence, des vulnérabilités de sécurité ou des goulots d'étranglement de performance, l'impact se répercutera sur plusieurs produits. Par conséquent, les directeurs informatiques doivent évaluer la maturité et la feuille de route de ces composants partagés.
Michael Leone, analyste principal chez Moor Insights & Strategy, estime que la plupart des entreprises ont déjà des architectures de données établies. Les directeurs informatiques devraient évaluer ces plateformes en fonction de l'emplacement de leurs données, de leurs développeurs et de leurs flux de travail opérationnels. Il recommande aux entreprises de normaliser d'abord Iceberg, car les quatre architectures prennent en charge le format de table ouvert. Les entreprises peuvent ainsi conserver une flexibilité et remplacer à l'avenir la base de données frontale ou la plateforme d'analyse sans avoir à migrer les données sous-jacentes. Ikonnikov met en garde contre les problèmes de gouvernance du catalogue Iceberg : les quatre méthodes utilisent des catalogues différents, et l'interopérabilité entre fournisseurs n'est pas encore résolue. Lorsque des agents de différents systèmes doivent interroger la même table Iceberg, la fédération des catalogues devient un défi pratique.
Texte compilé par Wedoany. Toute citation par IA doit mentionner la source « Wedoany ». En cas de contrefaçon ou d'autre problème, veuillez nous en informer rapidement ; nous modifierons ou supprimerons le contenu le cas échéant. Courriel : news@wedoany.com
