1. Introduction
MRS CDL est un service de synchronisation de données en temps réel lancé par FusionInsight MRS. Il vise à capturer et transmettre en temps réel les informations sur les événements des bases de données OLTP traditionnelles aux produits Big Data. Ce document présentera en détail l'architecture globale et les technologies clés de CDL.
2 Le concept de CDL
MRS CDL (Change Data Loader) est un service de synchronisation de données CDC basé sur Kafka Connect, qui peut capturer des données provenant de diverses sources de données OLTP, telles qu'Oracle, MySQL, PostgreSQL, etc., puis les transmettre au stockage cible, qui peut stocker des données volumineuses telles que HDFS, OBS ou le lac de données en temps réel Hudi, etc.
2.1 Qu'est-ce que le CDC ?
CDC (Change Data Capture) est un modèle de conception qui traite davantage les données modifiées en surveillant les changements de données (ajout, modification, suppression, etc.), et est généralement utilisé dans les entrepôts de données et certaines applications étroitement liées aux bases de données, telles que la synchronisation des données. , sauvegarde, audit, ETL, etc.
La technologie CDC existe depuis quelques années et a été utilisée pour capturer les changements dans les données d'application il y a plus de deux décennies. La technologie CDC peut synchroniser les messages avec les entrepôts de données correspondants de manière rapide et efficace, et n'a pratiquement aucun impact sur les applications de production actuelles. De nos jours, l'application des mégadonnées devient de plus en plus courante et l'ancienne technologie de CDC a été relancée.C'est une nouvelle mission de la technologie CDC de se connecter aux scénarios de mégadonnées.
À l'heure actuelle, il existe de nombreux produits matures CDC vers Big Data dans l'industrie, tels que Oracle GoldenGate (pour Kafka), Ali/Canal, Linkedin/Databus, Debezium/Debezium, etc.
2.2 Scénarios pris en charge par CDL
MRS CDL absorbe l'expérience réussie des produits matures ci-dessus, utilise Oracle LogMinner et Debezium open source pour capturer les événements CDC, et déploie des tâches à l'aide des cadres à haute concurrence, haut débit et haute fiabilité de Kafka et Kafka Connect.
Lorsque les produits CDC existants sont connectés à des scénarios de Big Data, ils choisissent essentiellement de synchroniser les données avec la file d'attente de messages Kafka. Sur cette base, MRS CDL offre en outre la possibilité d'entrer directement dans le lac et peut se connecter directement à MRS HDFS et Huawei OBS, ainsi qu'à MRS Hudi, ClickHouse, etc., pour résoudre le problème du dernier kilomètre de données.
| Scènes | la source de données | stockage cible |
|---|---|---|
| Analyse en temps réel des lacs de données | Oracle | Huawei OBS, MRS HDFS, MRS Hudi, MRS ClickHouse, MRS Hive |
| Analyse en temps réel des lacs de données | MySQL | Huawei OBS, MRS HDFS, MRS Hudi, MRS ClickHouse, MRS Hive |
| Analyse en temps réel des lacs de données | PostgreSQLName | Huawei OBS, MRS HDFS, MRS Hudi, MRS ClickHouse, MRS Hive |
Tableau 1 Scénarios pris en charge par MRS CDL
3 Architecture de CDL
En tant que système CDC, la capacité d'extraire des données de la cible source et de les transférer vers le stockage cible est une capacité de base. Sur cette base, la flexibilité, les hautes performances, la haute fiabilité, l'évolutivité, la réentrance et la sécurité sont les orientations que MRS CDL se concentre sur. , par conséquent, les principes de conception de base de CDL sont les suivants :
- L'architecture du système doit satisfaire aux principes d'évolutivité, permettant l'ajout de nouveaux magasins de données source et cible sans compromettre la fonctionnalité du système existant.
- La conception de l'architecture doit respecter la séparation de l'orientation commerciale entre les différents rôles
- Réduisez la complexité et les dépendances lorsque cela est raisonnable, et minimisez les risques d'architecture, de sécurité et de résilience.
- Il doit répondre aux besoins des clients en matière de plug-in et fournir des fonctionnalités de plug-in générales, rendant le système flexible, facile à utiliser et configurable.
- Sécurité de l'entreprise pour éviter les débordements horizontaux et les fuites d'informations.
3.1 Schéma d'architecture/présentation des rôles
Figure 1 Architecture CDL
MRS CDL comprend deux rôles : Service CDL et Connecteur CDL. Leurs fonctions respectives sont les suivantes :
- Service CDL : responsable de la gestion et de la planification des tâches, fournit une interface API unifiée et surveille l'état de santé de l'ensemble du service CDL.
- Connecteur CDL : il s'agit essentiellement du processus Worker de Kafka Connect, responsable de l'exécution de tâches réelles. Sur la base de la haute fiabilité, de la haute disponibilité et de l'évolutivité de Kafka Connect, un mécanisme de pulsation est ajouté pour aider le service CDL à effectuer la surveillance de l'état du cluster. .
3.2 Pourquoi choisir Kafka ?
Nous avons comparé Apache Kafka avec diverses autres options telles que Flume et Nifi, comme indiqué dans le tableau ci-dessous :
| Buse | Nifi | Kafka |
|---|---|---|
| avantage | Architecture d'agent basée sur la configuration ; Intercepteurs ; Modèles source, canal, récepteur | Il existe de nombreux processeurs prêts à l'emploi ; mécanisme de contre-pression ; gérer des messages de taille arbitraire ; prendre en charge l'agent MiNifi pour collecter des données ; prendre en charge le flux de données de la couche périphérique |
| défaut | Il existe des scénarios de perte de données ; pas de sauvegarde des données ; limite de taille des données ; pas de mécanisme de contre-pression | Pas de réplication de données ; tolérance aux pannes fragile ; pas de prise en charge de la commande de messages ; mauvaise évolutivité |
Tableau 1 Comparaison des cadres
Pour les systèmes CDC, Kafka a suffisamment d'avantages pour soutenir notre choix. Dans le même temps, l'architecture de Kafka Connect s'intègre parfaitement au système CDC :
- Parallélisme - Pour une tâche de réplication de données, il est possible d'augmenter le débit en le divisant en plusieurs sous-tâches et en les exécutant en parallèle.
- Préservation de l'ordre - Le mécanisme de partition de Kafka peut garantir que les données d'une partition sont strictement ordonnées, ce qui nous aide à atteindre l'intégrité des données.
- Évolutif - Kafka Connect exécute des connecteurs répartis sur le cluster.
- Facilité d'utilisation - L'interface de Kafka est abstraite pour améliorer la facilité d'utilisation.
- Équilibrage - Kafka Connect détecte automatiquement les défaillances et rééquilibre la planification sur les processus restants en fonction de leurs charges respectives.
- Gestion du cycle de vie – Fournit des fonctionnalités complètes de gestion du cycle de vie du connecteur.
4 technologies clés de MRS CDL
Figure 2 Technologies clés du CDL
4.1 Tâche CDL
MRS CDL résume l'activité au niveau supérieur et définit un processus métier complet en introduisant le concept de travail CDL. Dans un Job, l'utilisateur peut sélectionner la source de données et le type de stockage cible, et peut filtrer les tables de données à copier.
Sur la base de la structure du travail, MRS CDL fournit un mécanisme d'exécution des travaux CDL. Au moment de l'exécution, les événements CDC sont capturés à partir du stockage des données source vers Kafka à l'aide du connecteur source Kafka Connect combiné à la technologie de réplication des journaux, puis les données sont extraites de Kafka à l'aide de Kafka Connect. Sink Connector , qui envoie le résultat final au magasin cible après avoir appliqué diverses règles de transformation.
Fournit un mécanisme pour définir les transformations de mappage au niveau de la table et de la colonne et peut spécifier des règles de transformation pendant le processus de définition des tâches CDL.
4.2 Comparaison des données
MRS CDL fournit une tâche spéciale pour la comparaison de la cohérence des données. Les utilisateurs peuvent sélectionner les schémas de magasin de données source et cible, et sélectionner diverses paires de comparaison à partir des schémas source et cible pour la comparaison des données afin de s'assurer que les données sont cohérentes dans les magasins de données source et cible.
Figure 3 Vue abstraite de la comparaison des données
MRS CDL fournit une API Rest dédiée pour exécuter des travaux de comparaison de données et offre les fonctionnalités suivantes :
- Fournit une variété d'algorithmes de comparaison de données, tels que des algorithmes de hachage de ligne, des comparaisons de colonne de clé non primaire, etc.
- Fournit une interface de requête spéciale, qui peut interroger le rapport de synchronisation et afficher les détails d'exécution de la tâche de comparaison en cours.
- Fournit des scripts de réparation basés sur le stockage source et cible en temps réel pour réparer les données désynchronisées en un seul clic.
Voici le processus d'exécution de la tâche de comparaison de données :
Figure 4 Processus d'exécution et d'affichage de la tâche de comparaison de données
4.3 Connecteurs sources
MRS CDL crée divers connecteurs source via le SDK Kafka Connect qui capturent les événements CDC à partir de diverses sources de données et les transmettent à Kafka. CDL fournit des API Rest spécialisées pour gérer le cycle de vie de ces connecteurs de source de données.
4.3.1 Connecteur source Oracle
Le connecteur source Oracle utilise l'interface Log Miner fournie par Oracle RDBMS pour capturer les événements DDL et DML à partir de la base de données Oracle.
Figure 5 Diagramme schématique des données de saisie de Log Miner
Lors du traitement des événements DML, CDL peut également fournir une assistance si des colonnes BOLB/CLOB existent dans la table. Pour le traitement des colonnes BOLB, les points clés sont traités comme suit :
- Lorsqu'une opération d'insertion/mise à jour se produit, une série d'opérations LOB_WRITE est déclenchée.
- LOB_WRITE est utilisé pour charger le fichier dans un champ BLOB.
- Chaque LOB_WRITE ne peut écrire que 1 Ko de données.
- Pour un fichier image de 1 Go, nous allons trier les données binaires dans les 1 million d'opérations LOB_WRITE et les fusionner en un seul objet. Nous allons stocker cet objet dans Huawei OBS, et enfin donner l'emplacement de l'objet dans OBS dans le message écrit à Kafka.
Pour la capture des événements DDL, nous créons des sessions séparées pour en garder une trace. Les instructions DDL actuellement prises en charge sont les suivantes :
| Non | Déclaration DDL | Exemple |
|---|---|---|
| 1 | CRÉER UN TABLEAU | CREATE TABLE TEST (EMPID INT PRIMARY KEY, ENAME VARCHAR2(10)) |
| 2 | ALTER TABLE ... ADD (<nom> <type de données>) | MODIFIER TABLE TEST AJOUTER (NUMÉRO DE SALAIRE) |
| 3 | MODIFIER LA TABLE... COLONNE ABAISSANTE... | ALTER TABLE TEST DROP (SALAIRE) |
| 4 | MODIFIER TABLE ... MODIFIER (<colonne> ... | MODIFIER TABLE TEST MODIFIER SALAIRE INT |
| 5 | MODIFIER... RENOMMER... | ALTER TABLE TEST RENOMMER EN CLIENT |
| 6 | LAISSEZ TOMBER ... | TEST DE TABLE DE CHUTE |
| 7 | CRÉER UN INDEX UNIQUE... | CRÉER UN INDEX UNIQUE TESTINDEX ON TEST (EMPID, ENAME) |
| 8 | SUPPRIMER L'INDEX … | Supprimer l'index existant |
Tableau 2 Instructions DDL prises en charge
4.3.2 Connecteur source MYSQL
Le fichier journal binaire (Bin Log) de MYSQL enregistre toutes les opérations soumises à la base de données de manière séquentielle, y compris les modifications apportées à la structure de la table et les modifications apportées aux données de la table. MYSQL Source Connector génère des événements CDC en lisant les fichiers Bin Log et les soumet aux sujets Kafka.
Les principaux scénarios fonctionnels supportés par le Connecteur Source MYSQL sont :
- Capturez les événements DML et prenez en charge le traitement parallèle des événements DML capturés pour améliorer les performances globales
- Prise en charge du filtrage des tables
- Prise en charge de la relation de mappage entre la table de configuration et le sujet
- Afin d'assurer l'ordre absolu des événements CDC, nous exigeons généralement qu'une table corresponde à une seule partition. Cependant, le connecteur source MYSQL offre toujours la possibilité d'écrire plusieurs partitions pour répondre à certains scénarios qui nécessitent de sacrifier l'ordre des messages pour améliorer les performances.
- Offre la possibilité de redémarrer des tâches en fonction du fichier Bin Log spécifié, de l'emplacement spécifié ou du GTID pour garantir que les données ne sont pas perdues dans des scénarios anormaux
- Prise en charge de plusieurs types de données complexes
- Prise en charge de la capture d'événements DDL
4.3.3 Connecteur source PostgreSQL
La fonctionnalité de décodage logique de PostgreSQL nous permet d'analyser les événements de modification validés dans le journal des transactions, ce qui nécessite un plug-in de sortie pour traiter ces modifications. Le connecteur source PostgreSQL utilise le plugin pgoutput pour ce faire. Le plugin pgoutput est un plugin de décodage logique standard fourni par PostgreSQL 10+ sans installer de dépendances supplémentaires.
Les fonctions du connecteur source PostgreSQL et du connecteur source MYSQL sont fondamentalement les mêmes, à l'exception des différences dans certains types de données.
4.4 Connecteurs d'évier
MRS fournit une variété de connecteurs de récepteur, qui peuvent extraire des données de Kafka et les pousser vers différents stockages cibles. Les connecteurs de récepteur actuellement pris en charge sont :
- Connecteur d'évier HDFS
- Connecteur d'évier OBS
- Connecteur d'évier Hudi
- Connecteur d'évier ClickHouse
- Connecteur Hive Sink Parmi eux, le connecteur Hudi Sink et le connecteur ClickHouse Sink prennent également en charge la planification et l'exécution via les applications Flink/Spark.
4.5 Filtrage des tableaux
Lorsque nous voulons capturer les modifications de plusieurs tables en même temps dans un travail CDL, nous pouvons utiliser des caractères génériques (expressions régulières) au lieu des noms de table, c'est-à-dire que les événements CDC des tables dont les noms satisfont aux règles peuvent être capturés à le même temps. Une table supplémentaire est capturée lorsqu'un caractère générique (expression régulière) ne peut pas correspondre exactement à la cible. À cette fin, CDL fournit un filtrage de table pour faciliter les scénarios de correspondance approximative avec caractères génériques. Actuellement, CDL prend en charge les méthodes de filtrage de liste blanche et de liste noire.
4.6 Format de données unifié
MRS CDL utilise un format de message unifié pour différents types de sources de données, tels qu'Oracle, MYSQL et PostgreSQL, et les stocke dans Kafka. Les consommateurs principaux n'ont besoin d'analyser qu'un seul format de données pour le traitement et la transmission ultérieurs des données, évitant ainsi le besoin de divers formats de données Problèmes qui entraînent une augmentation des coûts de développement back-end.
4.7 Navigation dans le journal au niveau des tâches
Dans des circonstances normales, un connecteur CDL exécutera plusieurs threads de tâche pour capturer les événements CDC.Lorsque l'une des tâches échoue, il est difficile d'extraire des informations de journal très pertinentes à partir des journaux massifs pour une analyse plus approfondie.
Afin de résoudre les problèmes ci-dessus, CDL standardise l'impression du journal du connecteur CDL et fournit une API REST dédiée, grâce à laquelle les utilisateurs peuvent obtenir le fichier journal du connecteur ou de la tâche spécifié en un seul clic. Vous pouvez même spécifier des heures de début et de fin pour affiner davantage les requêtes de journal.
4.8 Surveillance
MRS CDL fournit une API REST pour interroger les informations métriques de tous les composants de base du service CDL, y compris le niveau de service, le niveau de rôle, le niveau d'instance et le niveau de tâche.
4.9 Traitement des erreurs d'application
Dans le processus d'exploitation de l'entreprise, il arrive souvent que certains messages ne puissent pas être envoyés à la source de données cible. Nous appelons ce type de message un enregistrement d'erreur. Dans CDL, il existe de nombreux scénarios pour les enregistrements d'erreur, tels que :
- Le corps du message dans la rubrique ne correspond pas à la méthode de sérialisation spécifique, ce qui entraîne un échec de lecture normale
- Le nom de table stocké dans le message n'existe pas dans le stockage cible, le message ne peut donc pas être envoyé à la cible
Afin de traiter ce type de problème, CDL définit une sorte de "file d'attente de lettres mortes", qui est spécialement utilisée pour stocker les enregistrements d'erreurs qui se produisent pendant le fonctionnement. Essentiellement, la "file d'attente de lettres mortes" est une rubrique spécifique créée par le connecteur Sink. Lorsqu'il y a un enregistrement d'erreur, le connecteur Sink l'enverra à la "file d'attente de lettres mortes" pour le stockage.
Dans le même temps, CDL fournit une API REST permettant aux utilisateurs d'interroger ces enregistrements d'erreurs à tout moment pour une analyse plus approfondie, et fournit une API Rest qui permet aux utilisateurs de modifier et de renvoyer ces enregistrements d'erreurs.
Chapitre 6 Gestion des erreurs d'application CDL
5 Performances
CDL utilise plusieurs optimisations de performances pour améliorer le débit :
- Nous profitons de la fonctionnalité de parallélisation des tâches fournie par Kafka Connect, où Connect peut diviser un travail en plusieurs tâches pour répliquer les données en parallèle, comme suit :
Figure 7 simultanéité des tâches
- Utilisez les threads Executor pour exécuter des tâches en parallèle. En raison des limites des technologies de réplication de données telles que Log Miner et Bin Log, notre connecteur source ne peut capturer que séquentiellement les événements CDC. Par conséquent, afin d'améliorer les performances, nous mettons en cache ces événements CDC dans le d'abord la file d'attente de la mémoire, puis utilisez les threads Executor pour les traiter en parallèle. Ces threads liront d'abord les données de la file d'attente interne, puis les traiteront et les transmettront à Kafka.
Figure 8 Concurrence de thread d'exécuteur
6 Résumé
MRS CDL est une pièce importante du puzzle dans le scénario de saisie de données en temps réel dans le lac. Nous devons encore étendre et améliorer les scénarios tels que la cohérence des données, la facilité d'utilisation, l'interconnexion multi-composants et l'amélioration des performances. afin de créer une meilleure valeur pour les clients à l'avenir. .
Cet article est publié par HUAWEI CLOUD .