La mise en miroir des données PostgreSQL sur Snowflake est désormais disponible pour le CDC moderne

Snowflake a annoncé la disponibilité générale de la mise en miroir des données PostgreSQL, une nouvelle fonctionnalité conçue pour simplifier le processus de réplication des données à partir d'instances PostgreSQL vers Snowflake. Cette avancée vise à résoudre un défi courant rencontré par les clients cherchant à intégrer leurs données PostgreSQL avec les capacités analytiques de Snowflake.

Comment fonctionne la mise en miroir des données

La mise en miroir des données réplique des tables et des schémas spécifiés d'une instance Snowflake PostgreSQL vers une base de données Snowflake cible. La configuration peut être facilement gérée via l'interface utilisateur de Snowflake PostgreSQL, des commandes SQL, ou via Snowflake CoPilot. Contrairement aux solutions de réplication traditionnelles, la mise en miroir des données est intégrée directement dans PostgreSQL et Snowflake, utilisant le stockage objet comme intermédiaire sans nécessiter de composants supplémentaires. Cette méthode garantit un transfert de données sécurisé, fiable et performant tout en maintenant un historique des modifications interrogeable.

À la base, PostgreSQL pousse des instantanés et de petits lots d'enregistrements de modifications pour chaque table dans les journaux de modifications Apache Iceberg™ stockés dans le stockage objet, facilités par une extension snowflake_cdc. Snowflake utilise ensuite une tâche serverless périodique pour appliquer ces modifications aux tables Snowflake régulières ou gérées par Snowflake Iceberg. Pour un accès immédiat aux données les plus récentes, une vue $live est disponible, qui combine les tables mises en miroir avec les modifications en attente pour offrir une faible latence, quelle que soit la fréquence de la tâche d'application. L'ensemble du pipeline est conçu pour un fonctionnement continu, avec une récupération automatique après échec, une réplication transparente des modifications de schéma, une intégrité transactionnelle pour prévenir les échecs partiels et une gestion de pipeline de bout en bout.

Amélioration de la fiabilité et de la résilience

L'un des principaux objectifs de la mise en miroir des données est de construire des pipelines hautement résilients en minimisant la complexité du système et les dépendances. En éliminant les services de réplication intermédiaires, les modifications sont poussées directement de PostgreSQL vers le stockage objet, réduisant les points de défaillance potentiels et évitant les problèmes tels que le remplissage du disque sur la base de données source.

La mise en miroir des données garantit la cohérence transactionnelle en validant toutes les modifications ou aucune, empêchant les états intermédiaires difficiles à récupérer. Un "meta log" suit les opérations de haut niveau, coordonnant les modifications de schéma et d'autres mises à jour critiques. Des mécanismes de récupération automatique sont en place pour gérer les slots de réplication invalidés ou supprimés, garantissant que le système peut ré-instantaner les tables et redémarrer la coordination via le meta log, transformant les échecs catastrophiques en augmentations de latence momentanées sans intervention de l'opérateur. L'ensemble du pipeline est géré par Snowflake, avec une surveillance continue et des stratégies d'atténuation proactive.

Optimisation des coûts et de la latence

La mise en miroir des données est conçue pour réduire les coûts opérationnels et la latence associés à la réplication des données. Elle n'entraîne de coûts que pour l'application des modifications à l'aide de l'infrastructure de calcul serverless de Snowflake et du stockage temporaire. Le système utilise une livraison exactement une fois pour les lignes, optimisant le processus d'application en évitant les analyses en double. Les tâches serverless dans Snowflake sont facturées à la seconde, rendant l'application des modifications, en particulier les mises à jour et les suppressions, plus rentable.

Pour équilibrer latence et coût, la mise en miroir des données offre une application différée avec des vues live. Cela permet d'appliquer les modifications par lots plus importants et plus rentables tout en offrant un accès aux données à faible latence via des vues $live. Ces vues combinent les modifications non appliquées avec les tables cibles au moment de la requête, offrant une flexibilité. Bien que les lots de modifications soient poussés depuis PostgreSQL toutes les 15 secondes et mis à jour dans Snowflake toutes les 30 secondes, les vues $live fournissent un accès aux données quasi en temps réel. Le système prend également en charge les instantanés à haut débit et les flux de modifications, capables de gérer plus d'un million de lignes par seconde lors des instantanés et de maintenir plus de 100 000 modifications de lignes par seconde sous forte charge.

Cohérence transactionnelle entre les systèmes

La préservation de la cohérence transactionnelle est un principe fondamental de la mise en miroir des données. Les lots de modifications poussés depuis PostgreSQL représentent des séquences ordonnées de transactions, chaque fin de lot marquant une limite transactionnelle. Ces lots sont mis à disposition de Snowflake dans une seule transaction côté PostgreSQL, et Snowflake les applique dans ses propres transactions uniques. Cela garantit que les tables cibles dans Snowflake respectent les limites de transaction d'écriture de PostgreSQL, maintenant à la fois la cohérence interne (par exemple, pas de clés dupliquées) et la cohérence inter-tables (par exemple, les clés étrangères sont respectées), conduisant à des résultats précis lors de la jointure de tables mises en miroir.

Développements futurs

Snowflake a également fait allusion à des capacités futures, notant que la technologie de mise en miroir est en cours de développement pour la mise en miroir de Snowflake vers PostgreSQL, ce qui permettra un échange de données bidirectionnel complet. Cette fonctionnalité à venir promet d'améliorer encore les possibilités d'intégration des données au sein de l'écosystème Snowflake.