À propos du ciblage Iceberg

Vous pouvez répliquer depuis n'importe quelle source de réplication CDC prise en charge vers une table d' Apache Iceberg s à l'aide du moteur de réplication CDC pour Iceberg. Ce moteur écrit les fichiers de données Iceberg au format Parquet, contenant les données répliquées, dans les tables Iceberg. Il valide ensuite ces fichiers en les enregistrant dans le catalogue Iceberg.

Le moteur de réplication CDC pour Iceberg prend également en charge les scénarios dans lesquels vous avez besoin d'un accès direct aux fichiers de données Parquet bruts. Le moteur peut écrire ces fichiers dans n'importe quel système de fichiers souhaité, y compris une option de système de fichiers local, ce qui permet des modèles de consommation de données flexibles allant au-delà des requêtes traditionnelles sur les tables Iceberg.

Apache Iceberg Architecture - API du catalogue et du système de fichiers Iceberg

Deux composants fondamentaux définissent une destination Iceberg : le catalogue Iceberg et le système de fichiers Iceberg.

Processus de réplication

Lors de la réplication vers Iceberg, le processus suit les étapes suivantes :
  1. Création de fichiers de données - Le moteur écrit les fichiers de données Iceberg dans le système de fichiers configuré.
  2. Enregistrement dans le catalogue - Le moteur valide ces fichiers en les enregistrant dans le catalogue Iceberg à l'aide de l'API Java Apache Iceberg.

Cette approche en deux phases garantit des validations atomiques et maintient la cohérence des données tout au long du processus de réplication.

Flexibilité de mise en œuvre

Le projet Apache Iceberg fournit plusieurs implémentations pour l'interface du catalogue Iceberg et l'interface du système de fichiers Iceberg. Vous pouvez spécifier les implémentations de catalogue et de système de fichiers à utiliser pour vos tables Iceberg en fonction de leur infrastructure et de leurs exigences.

Prise en charge intégrée du catalogue

Le moteur de réplication CDC pour Iceberg inclut une prise en charge native des implémentations suivantes du catalogue Iceberg :
  • Hadoop Catalogue Iceberg (API Java HadoopCatalogIceberg)
  • Hive Catalogue Iceberg (API Java HiveCatalogIceberg) - Utilisé par watsonx.data

Prise en charge intégrée du système de fichiers

Le moteur de réplication CDC pour Iceberg inclut une prise en charge native des implémentations suivantes du système de fichiers Iceberg :
  • Hadoop Systèmes de fichiers (Iceberg's HadoopFileIO)
  • S3 Systèmes de fichiers (Iceberg's S3FileIO) - Utilisés par watsonx.data
  • Système de fichiers local (Iceberg's FileIO)

Implémentations personnalisées de catalogues et de systèmes de fichiers

Pour les environnements qui nécessitent des solutions d'intégration personnalisées, vous pouvez implémenter des bibliothèques propriétaires de catalogues et de systèmes de fichiers afin d'étendre les capacités natives de la plateforme. Cette extensibilité garantit que le moteur de réplication CDC pour Iceberg peut s'intégrer à diverses configurations d'infrastructure.

Configuration requise

Les propriétés des catalogues et des systèmes de fichiers varient selon l'environnement et la configuration, comme défini par l'API Java Apache Iceberg pour chaque implémentation. Le moteur de réplication CDC pour Iceberg prend en charge deux méthodes de configuration :
  • Fichier de propriétés - Fournissez un fichier de propriétés pour configurer l'accès au catalogue et au système de fichiers de votre environnement spécifique.
  • Implémentation de sortie - Implémentez une sortie personnalisée qui récupère ces propriétés de manière dynamique.
Important : le catalogue et le système de fichiers sélectionnés, configurés avec les propriétés fournies, doivent pouvoir effectuer leurs opérations sur le catalogue et le système de fichiers ciblés indépendamment du CDC. Un outil de validation est fourni pour confirmer cette exigence avant le début de la réplication.

Moteur de réplication CDC pour l'interaction Iceberg

Mappage et transformation de tables

Le moteur Iceberg Target Engine mappe les tables source et cible, vous permettant ainsi de définir la relation entre elles. Les principales fonctionnalités de mappage des touches comprennent :
  • Expressions dérivées du CDC - Mappez les colonnes source aux champs cibles à l'aide de transformations. Par exemple, vous pouvez mapper le champ de contrôle du &TIMESTAMP journal d'une opération à une colonne appelée « timestamp » (horodatage)
  • Conversion des types de données - Vous pouvez modifier les types de données des colonnes source sur la cible pendant le mappage.
  • Manipulation des valeurs : appliquez des opérations mathématiques, des concaténations et d'autres transformations aux valeurs des colonnes.

Découverte de schéma

Lors du mappage initial des tables pour un abonnement, le moteur de réplication CDC pour Iceberg utilise l'API du catalogue Iceberg pour obtenir les informations relatives à l'espace de noms, les définitions des tables et les définitions du schéma des tables Iceberg. Tous les types de données de spécification Iceberg version 2 sont pris en charge pour le mappage. Par exemple, les données LOB (Large Object) provenant d'une source peuvent être mappées au type de données binaires dans la table Iceberg cible.

Processus d'écriture des données

Lorsqu'il exécute un abonnement en mode miroir, audit ou application adaptative, le moteur de réplication CDC pour Iceberg utilise un processus d'écriture en continu efficace :
  1. Génération de fichiers Parquet - Le moteur écrit les données dans des fichiers au format Parquet à l'aide de l'API Parquet Writer d' Apache Iceberg.
  2. Traitement par micro-lots : le moteur écrit en continu par micro-lots afin de produire des fichiers complets à la destination du système de fichiers via l'API du système de fichiers Iceberg.
  3. Architecture de streaming - Le moteur n'écrit pas les fichiers sur le disque local ni ne les met en cache dans la mémoire avant leur transmission

Cette approche de streaming permet la création de fichiers volumineux à la destination du système de fichiers tout en utilisant en continu la bande passante réseau disponible, évitant ainsi la mise en cache locale.

Agrégation de super-transactions

Pour générer des fichiers de données volumineux (généralement souhaités pour optimiser les performances d'Iceberg), le moteur CDC Iceberg peut regrouper les transactions sources individuelles en « super-transactions », où les effets de plusieurs petites transactions peuvent être appliqués comme une seule transaction. Le moteur respecte les limites des transactions, ne s'engageant qu'aux limites des transactions afin de garantir l'application atomique des modifications à chaque table.

Lorsqu'une super-transaction est effectuée sur une table Iceberg, le moteur peut générer plusieurs fichiers de données Iceberg volumineux. La liste complète des fichiers et leur ordre d'application est fournie à l'API Java Iceberg, garantissant ainsi que tous les fichiers sont inclus dans une seule opération de validation atomique.

Fonctionnement en mode miroir

Lorsque vous utilisez le mappage miroir qui effectue des suppressions dans une table Iceberg, le moteur crée un ou plusieurs fichiers de suppression distincts contenant des suppressions d'égalité, comme spécifié dans la norme Apache Iceberg. Le tableau obtenu ne contient aucune ligne correspondant aux critères de suppression dans les ensembles de résultats SELECT. Le moteur applique ensuite les mises à jour sous forme d'opération upsert (suppression de la ligne existante suivie de l'insertion de la ligne mise à jour). Inclure une définition clé pour les mappages miroir afin de permettre à la logique d'agrégation de faire correspondre les suppressions aux lignes déjà insérées dans le cadre de la super-transaction.

Fonctionnement en mode audit

Lorsque vous utilisez le mappage d'audit, le moteur ne crée pas de fichiers de données supprimées. Au lieu de cela, il inclut les suppressions sous forme de lignes insérées dans le fichier de données d'insertion Iceberg, dans leur ordre relatif correct, avec indication du type d'opération de suppression. Le journal du moteur est mis à jour sous la forme d'une ligne supprimée suivie d'une ligne insérée. Les mappages d'audit créent des fichiers Parquet destinés à être utilisés en dehors du contexte Iceberg, en utilisant fréquemment l'option du système de fichiers local pour des écritures performantes sur des disques locaux ou montés.

Optimisation des performances

Le moteur de réplication CDC pour Iceberg offre des propriétés de stockage de données permettant d'ajuster les performances en fonction de vos besoins spécifiques.
  • Ajustez le nombre de générateurs d'images qui créent les données du champ Parquet.
  • Configurez la taille des fichiers de données à agréger.
  • Contrôlez la fréquence des commits effectués dans le catalogue Iceberg.
  • Définissez le nombre d'écrivains de fichiers parallèles pour une table donnée pendant les opérations de rafraîchissement.

Garantie de livraison des données

Le moteur de réplication CDC pour Iceberg garantit la livraison des données en enregistrant toutes les transactions sources confirmées à l'aide d'un signet CDC. Cette méthode écrit toutes les opérations de la source vers la cible après une panne (due à des problèmes réseau, des défaillances environnementales ou d'autres perturbations). Au redémarrage, l'abonnement revient à la dernière transaction entièrement validée et applique les données à partir de ce point.

Iceberg étant un format de table ouverte, les transactions sont atomiques uniquement au niveau de la table. Lorsqu'une modification de la base de données source affecte plusieurs tables, chaque table est validée individuellement. Le moteur de réplication CDC pour Iceberg génère d'abord tous les fichiers de données, puis procède à leur validation séquentielle dans un délai optimisé et court. Si une panne survient pendant la période de validation, l'abonnement réessaie l'intégralité de la transaction lorsqu'il redémarre. Pour les implémentations de logique métier non idempotentes, vous pouvez effectuer une déduplication ou exécuter le mode d'application adaptatif à partir du CDC afin de supprimer les doublons de la transaction interrompue.

Mise en œuvre technique

Le moteur de réplication CDC pour Iceberg utilise l'API Java Apache Iceberg pour appliquer les données, conformément à la spécification Version 2 de Apache Iceberg. Pour obtenir la documentation complète sur l'API, consultez l'API Java Iceberg.