Synchroniser ApsaraDB RDS for MySQL vers ApsaraDB for ClickHouse avec zero-ETL - ApsaraDB for ClickHouse

Présentation

Les entreprises gèrent souvent des données opérationnelles réparties sur différents systèmes.

Le processus ETL (Extract, Transform, Load) consolide les données provenant des systèmes métier en amont dans un entrepôt de données à des fins d'analyse.

Les workflows ETL traditionnels présentent les défis suivants :

Coûts élevés en ressources : Différentes sources de données nécessitent souvent des outils ETL distincts, et la construction de ces pipelines engendre des coûts supplémentaires.
Complexité système accrue : La maintenance des outils ETL augmente la complexité opérationnelle et détourne l'attention du développement des applications.
Latence des données : Les mises à jour par lots périodiques, courantes dans les processus ETL, peuvent retarder l'analyse dans les scénarios en quasi temps réel.

Pour résoudre ces problèmes, Alibaba Cloud propose une fonctionnalité zero-ETL qui construit automatiquement des pipelines de données entre les systèmes de traitement transactionnel en ligne (OLTP) et les entrepôts de données analytiques en ligne (OLAP). Elle extrait, transforme et charge les données automatiquement, offrant une solution tout-en-un qui intègre le traitement des transactions à l'analyse des données, vous permettant ainsi de vous concentrer sur l'analyse.

Avantages

Facilité d'utilisation : Sélectionnez la source de données et l'instance de destination, et le système crée automatiquement un pipeline de données en temps réel. Inutile de construire ou de maintenir des pipelines ETL complexes, ce qui vous permet de vous concentrer sur le développement d'applications.
Gratuité : Le pipeline zero-ETL est gratuit. Vous pouvez analyser les données en amont dans l'entrepôt de données sans frais supplémentaires.
Agrégation multisource : Synchronisez les données de plusieurs instances vers une seule instance ApsaraDB for ClickHouse en temps réel pour construire une vue analytique complète.

Remarque
Si vous synchronisez les données de plusieurs instances vers une seule instance ApsaraDB for ClickHouse, les objets de synchronisation dans différentes tâches ne doivent pas se chevaucher.

Pipeline pris en charge

ApsaraDB RDS for MySQL vers ApsaraDB for ClickHouse

Facturation

Le pipeline de synchronisation zero-ETL est gratuit.

Prérequis

Le cluster ApsaraDB for ClickHouse et l'instance RDS for MySQL se trouvent dans la même région.
Créez des comptes de base de données pour l'instance source ApsaraDB RDS for MySQL et la base de données de destination. Pour plus d'informations, consultez les rubriques Créer un compte pour une instance ApsaraDB RDS for MySQL et Créer un compte pour un cluster ApsaraDB for ClickHouse.

Limites

Type	Description
Limites relatives à ApsaraDB RDS for MySQL	Les tables sans clé primaire ne peuvent pas être synchronisées. L'opération RENAME TABLE n'est pas prise en charge. Si vous synchronisez les données au niveau de la table et devez modifier des objets, tels que le mappage des noms de tables ou de colonnes, une seule tâche de synchronisation de données prend en charge un maximum de 1 000 tables. Si vous dépassez cette limite, une erreur est signalée après l'envoi de la tâche. Dans ce cas, répartissez les tables sur plusieurs tâches ou configurez une tâche pour synchroniser la base de données entière. Journaux binaires : ApsaraDB RDS for MySQL active la journalisation binaire par défaut. Assurez-vous que le paramètre binlog_row_image est défini sur full. Sinon, la prévérification échoue et la tâche de synchronisation ne peut pas démarrer. Pour obtenir des instructions, consultez la rubrique Configurer les paramètres de l'instance. Important Si votre instance source est une base de données MySQL autogérée, activez la journalisation binaire et définissez binlog_format sur row et binlog_row_image sur full. Si votre base de données MySQL autogérée est un cluster à double principal (où les deux nœuds agissent comme principal et secondaire), activez le paramètre log_slave_updates afin que DTS puisse capturer tous les événements du journal binaire. Pour obtenir des instructions, consultez la rubrique Créer un compte et configurer la journalisation binaire pour une base de données MySQL autogérée. Les journaux binaires locaux d'une instance ApsaraDB RDS for MySQL doivent être conservés pendant au moins trois jours (sept jours sont recommandés). Pour une base de données MySQL autogérée, conservez les journaux binaires locaux pendant au moins sept jours. Sinon, DTS pourrait ne pas réussir à récupérer les journaux binaires, ce qui entraînerait l'échec de la tâche. Dans des cas extrêmes, cela peut provoquer une incohérence ou une perte de données. Les problèmes causés par des périodes de rétention des journaux binaires inférieures à celles requises par DTS ne sont pas couverts par le SLA de DTS. Remarque Pour configurer la retention period des journaux binaires locaux sur une instance ApsaraDB RDS for MySQL, consultez la rubrique Supprimer automatiquement les journaux locaux. N'exécutez pas d'opérations DDL modifiant les schémas de base de données ou de tables pendant la synchronisation du schéma ou la synchronisation complète des données. Sinon, la tâche de synchronisation échouera. Remarque Pendant la synchronisation complète, DTS interroge la base de données source. Cela crée des verrous de métadonnées qui peuvent bloquer les opérations DDL sur la base de données source. Les données générées par des modifications qui n'écrivent pas dans les journaux binaires, telles que les données restaurées à partir de sauvegardes physiques ou créées par des opérations en cascade, ne sont pas synchronisées vers la base de données de destination. Remarque Si cela se produit, retirez la base de données ou la table concernée des objets de synchronisation, puis ajoutez-la à nouveau. Vous ne pouvez le faire que si votre activité le permet. Pour plus d'informations, consultez la rubrique Modifier les objets de synchronisation. Si votre base de données source est MySQL 8.0.23 ou version ultérieure et contient des colonnes cachées invisibles, DTS pourrait ne pas lire ces colonnes. Cela peut entraîner une perte de données. Remarque Exécutez la commande `ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;` pour rendre la colonne cachée visible. Pour plus d'informations, consultez la documentation Invisible Columns. Si votre instance ApsaraDB RDS for MySQL a Always-Encrypted activé, la synchronisation complète des données n'est pas prise en charge. Remarque Les instances ApsaraDB RDS for MySQL avec Transparent Data Encryption (TDE) activé prennent en charge la synchronisation du schéma, la synchronisation complète des données et la synchronisation incrémentielle des données. Les instances ApsaraDB RDS for MySQL en lecture seule qui n'enregistrent pas les journaux de transactions, telles que les instances ApsaraDB RDS for MySQL 5.6 en lecture seule, ne sont pas prises en charge en tant que bases de données sources. La fonctionnalité zero-ETL exécute périodiquement la commande `CREATE DATABASE IF NOT EXISTS test` sur la base de données source pour avancer le décalage du journal binaire.
Autres limites	Les données de type heure dans ApsaraDB for ClickHouse ont des limites de plage. Si les données horaires dans RDS MySQL sont en dehors de cette plage, l'heure synchronisée vers ApsaraDB for ClickHouse sera incorrecte. Pour plus d'informations sur les limites de plage, consultez la rubrique Informations sur l'heure.

Remarques d'utilisation

Remarques sur la création de pipelines zero-ETL

Si le nombre de liens zero-ETL pour un cluster ApsaraDB for ClickHouse atteint la limite, vous ne pouvez pas créer de nouveaux liens. Utilisez DTS pour créer un lien de synchronisation ou supprimez les liens zero-ETL inutilisés. Les limites sont les suivantes :
- Le nombre maximal de liens dans un cluster Enterprise Edition est calculé à l'aide de la formule [Limite inférieure de CCU du cluster / 8] en arrondissant le résultat à l'entier supérieur. Par exemple, si un cluster a une limite inférieure de CCU de 22 et une limite supérieure de CCU de 36, le calcul utilise la limite inférieure de 22. Le résultat est 22 / 8 = 2.75, qui est arrondi à 3. Cela signifie que vous pouvez créer un maximum de 3 liens zero-ETL.
- Nombre maximal de liens pour un cluster Community Edition : [Nombre total de cœurs du cluster / 8]. Le résultat est arrondi à l'entier supérieur. Par exemple, pour un cluster avec deux nœuds de 8 cœurs et 32 Go, le nombre total de cœurs CPU est 8*2=16. Le nombre maximal de liens est calculé comme suit : 16/8=2. Cela signifie que vous pouvez créer un maximum de 2 liens zero-ETL.
Remarques sur les tâches de synchronisation
- Si les instructions DDL de l'instance source RDS MySQL ne suivent pas la syntaxe MySQL standard, la tâche de synchronisation peut échouer ou des données peuvent être perdues.
- Le nombre de bases de données à synchroniser ne dépasse pas la limite d'ApsaraDB for ClickHouse, qui est de 256.
- Les noms des bases de données, des tables et des colonnes à synchroniser respectent les conventions de nommage d'ApsaraDB for ClickHouse. Pour plus d'informations sur les conventions, consultez la rubrique Conventions de nommage des objets.
- Si vous synchronisez une ou plusieurs tables au lieu de la base de données entière, n'utilisez pas d'outils tels que pt-online-schema-change pour effectuer des opérations DDL en ligne sur les objets de synchronisation dans la base de données source. Sinon, la synchronisation échouera.
- Avant de synchroniser les données, évaluez les performances des bases de données source et de destination. Nous vous recommandons d'effectuer la synchronisation des données pendant les heures creuses. Sinon, la synchronisation initiale complète des données consommera des ressources de lecture et d'écriture des bases de données source et de destination, ce qui peut augmenter leur charge.
- Pendant la phase de synchronisation du schéma, la fonctionnalité zero-ETL ajoute les champs _sign, _is_deleted et _version aux tables de destination.
- Si la destination est un cluster ApsaraDB for ClickHouse Community-Compatible Edition, l'intégration transparente crée une table locale et une table distribuée pour la destination.
  - Le nom de la table distribuée est identique au nom de la table source.
  - Le nom d'une table locale est <distributed_table_name> + _local.

Mappages des types de données

Étant donné que MySQL et les clusters ApsaraDB for ClickHouse prennent en charge différents types de données, un mappage un-à-un n'est pas possible. Lorsque DTS effectue la synchronisation initiale du schéma, il mappe les types de données en fonction des types pris en charge par la base de données de destination. Pour plus d'informations, consultez la rubrique Mappages des types de données pour la synchronisation initiale du schéma.

Préparatifs

Créez un rôle lié au service et accordez les autorisations requises à un utilisateur RAM.

Créez le rôle lié au service AliyunServiceRoleForClickHouseZeroETL.

Remarque
Le système crée automatiquement le rôle lié au service AliyunServiceRoleForClickHouseZeroETL. Si une boîte de dialogue vous invite à créer ce rôle manuellement lors de la configuration, vous pouvez l'ignorer.
Accordez des autorisations à un utilisateur RAM.

Un utilisateur RAM nécessite les trois autorisations suivantes pour créer un pipeline zero-ETL. Pour savoir comment accorder des autorisations à un utilisateur RAM, consultez la rubrique Gérer les autorisations des utilisateurs RAM.
- Autorisation pour l'instance source ApsaraDB RDS for MySQL : AliyunRDSFullAccess
- Autorisation pour le cluster de destination ApsaraDB for ClickHouse : AliyunClickHouseFullAccess
- Autorisation pour DTS : Le code suivant fournit le script de stratégie personnalisée pour DTS. Pour savoir comment créer une stratégie personnalisée, consultez la rubrique Créer une stratégie d'autorisation personnalisée.
```
{
    "Version": "1",
    "Statement": [
        {
            "Action": "dts:*",
            "Resource": "*",
            "Effect": "Allow"
        },
        {
            "Action": "ram:PassRole",
            "Resource": "*",
            "Effect": "Allow",
            "Condition": {
                "StringEquals": {
                    "acs:Service": "dts.aliyuncs.com"
                }
            }
        }
    ]
}
```

Synchroniser les données

Étape 1 : Accéder à la page Zero-ETL

Connectez-vous à la console ApsaraDB for ClickHouse. Dans le coin supérieur gauche, sélectionnez la région où se trouve votre cluster de destination.
Sur la page Clusters, sélectionnez Clusters of Community-compatible Edition, puis cliquez sur l'ID du cluster cible.
Dans le volet de navigation de gauche, cliquez sur Zero-ETL.

Étape 2 : Créer et démarrer la tâche zero-ETL****

Cliquez sur Create Zero-ETL Task pour ouvrir la page Create Zero-ETL Task.

Saisissez le Task Name et effectuez les configurations suivantes.

Configurez les bases de données source et de destination.

Configurez les bases de données source et de destination avec les paramètres suivants, puis cliquez sur Test Connectivity and Proceed.

Base de données source

Parameter	Description
Database Type	Seule l'option ApsaraDB RDS for MySQL est prise en charge.
Access Method	Seule l'option Alibaba Cloud instance est prise en charge.
Instance Region	Sélectionnez la région de l'instance source.
RDS Instance ID	L'ID de l'instance ApsaraDB RDS for MySQL.
Database Account	Le compte de base de données de l'instance ApsaraDB RDS for MySQL.
Database Account	Le mot de passe du compte de base de données de l'instance ApsaraDB RDS for MySQL.
Encryption	Sélectionnez Non-encrypted ou SSL-encrypted selon vos besoins. Si vous sélectionnez SSL-encrypted, vous devez d'abord activer le chiffrement SSL pour l'instance RDS MySQL. Pour plus d'informations, consultez la rubrique Utiliser un certificat cloud pour activer rapidement le chiffrement SSL.

Base de données de destination

Parameter	Description
Database Type	ClickHouse
Access Method	Seule l'option Alibaba Cloud instance est prise en charge.
Instance Region	La région du cluster de destination.
Cluster ID	L'ID du cluster de destination.
Cluster Type	Le type de cluster. Valeurs valides : Community-Compatible Edition et Enterprise Edition.
Database Account	Le compte de base de données du cluster de destination.
Database Password	Le mot de passe du compte de base de données du cluster de destination.

Configurez zero-ETL.

Dans la zone Source Objects, sélectionnez les objets à synchroniser, puis cliquez sur pour les déplacer vers la zone Selected Objects. Cliquez sur Next: Configure Database and Table Fields.
Configurez les champs de base de données et de table.

Sur la page Configure Zero-ETL, configurez le Type, la Primary Key Column, la Sort Key, la Distribution Key et la Partition Key de la table à synchroniser dans la base de données de destination.
Remarque
- Par défaut, la page affiche les informations sur les tables non définies. Vous pouvez apporter des modifications après avoir défini le Definition Status sur All.
- La Primary Key Column et la Sort Key peuvent être des clés composites. Cela signifie que vous pouvez sélectionner plusieurs champs dans les listes déroulantes correspondantes pour la Primary Key Column ou la Sort Key. Vous devez sélectionner une ou plusieurs colonnes dans la Primary Key Column pour les utiliser comme Partition Key. Vous ne pouvez sélectionner qu'un seul champ pour la Distribution Key. Pour plus d'informations sur la colonne de clé primaire, la clé de tri et la clé de partition, consultez la rubrique CREATE TABLE.
- La Partition Key est facultative, mais elle ne peut pas être un champ nullable. Sinon, la tâche de synchronisation échouera.
Enregistrez la tâche.

Après avoir configuré les champs de la table de la base de données, cliquez sur Next: Save Task Settings and Precheck.

Remarque
Après cette opération, la tâche est enregistrée, que la prévérification réussisse ou non.
Prévéifiez et démarrez la tâche.

Lorsque le Success Rate est de 100 %, cliquez sur Start pour démarrer la tâche Zero-ETL.

Sur la page Zero-ETL, vous pouvez consulter l'ID/Name, la Source/Destination et le Status de la tâche Zero-ETL cible.

Si la prévérification échoue, ajustez les bases de données source et de destination en fonction des informations d'échec. Ensuite, recherchez la tâche sur la page Zero-ETL, modifiez-la et relancez la prévérification. Une fois la prévérification réussie, vous pouvez démarrer la tâche.

Surveiller les tâches zero-ETL

Vous pouvez surveiller les tâches zero-ETL à l'aide des méthodes suivantes. Configurez des alertes ou des abonnements aux événements pour recevoir des mises à jour rapides sur l'état des tâches. Si une tâche devient anormale, utilisez la surveillance active pour résoudre le problème.

Monitoring method	Benefit	Limitation	Actions
Active monitoring	Fournit une vue complète de l'état de la tâche, y compris les performances de synchronisation, les détails et les journaux.	Ne vous notifie pas activement lorsqu'une tâche zero-ETL devient anormale.	Surveiller une tâche dans la console ApsaraDB for ClickHouse
Alert monitoring	CloudMonitor envoie automatiquement des notifications d'alerte basées sur les règles d'alerte, vous aidant à identifier et traiter rapidement les données de surveillance anormales.	Surveille uniquement la latence de synchronisation (en millisecondes) des tâches zero-ETL.	Surveiller la latence de synchronisation à l'aide des alertes CloudMonitor
Event subscription	Lorsqu'un événement système pour une tâche zero-ETL répond aux conditions d'alerte, CloudMonitor envoie automatiquement une notification d'alerte, vous tenant informé des échecs et des récupérations de tâches.	Surveille uniquement l'échec et la récupération des tâches zero-ETL.	S'abonner aux événements de tâche zero-ETL dans CloudMonitor

Surveiller dans la console

Connectez-vous à la console ApsaraDB for ClickHouse. Dans le coin supérieur gauche, sélectionnez la région où se trouve votre cluster de destination.
Sur la page Clusters, sélectionnez Clusters of Community-compatible Edition, puis cliquez sur l'ID du cluster cible.
Dans le volet de navigation de gauche, cliquez sur Zero-ETL.
Cliquez sur Task Details dans la colonne Actions de la tâche cible.

Sur la page des détails de la tâche, vous pouvez afficher des informations complètes et surveiller la tâche.

Alertes de latence CloudMonitor

Créez des règles d'alerte dans CloudMonitor pour surveiller la latence zero-ETL. Lorsqu'une métrique répond aux conditions d'alerte, CloudMonitor envoie automatiquement une notification d'alerte.

Étape 1 : Créer une alerte de latence zero-ETL

Pour savoir comment créer une alerte de latence zero-ETL, consultez la rubrique Utiliser la console CloudMonitor. Lors de la création de l'alerte, assurez-vous de définir les paramètres suivants.

Parameter	Description
Product	Sélectionnez Clickhouse - ZeroETL Latency.
Metric	Sélectionnez Synchronization Latency.

Étape 2 : Afficher la latence du cluster

Connectez-vous à CloudMonitor.
Dans la liste Clickhouse - ZeroETL Latency, cliquez sur Monitoring Charts dans la colonne Actions du cluster cible pour afficher la latence de synchronisation du cluster.

Abonnement aux événements CloudMonitor

Pour surveiller la récupération et l'échec des tâches zero-ETL et recevoir des notifications en temps opportun, abonnez-vous aux événements pertinents.

Pour savoir comment s'abonner aux événements Zero-ETL, consultez la rubrique Gérer les abonnements aux événements. Lors de la création d'une politique d'abonnement, assurez-vous de définir les paramètres suivants.

Event	Parameter	Description
Zero-ETL task failure	Subscription type	Select System Event.
	Product	Select ApsaraDB for ClickHouse.
	Event type	Select Abnormal.
	Event name	Select ZeroETL task abnormal.
Zero-ETL task recovery	Subscription type	Select System Event.
	Product	Select ApsaraDB for ClickHouse.
	Event type	Select Restore.
	Event name	Select ZeroETLTaskRestore.

FAQ

Q : Après avoir utilisé Zero-ETL pour synchroniser les données vers ApsaraDB for ClickHouse, pourquoi le volume de données dans la base de données de destination est-il supérieur à celui de la base de données source ?

Cause : Lorsque vous effectuez une opération UPDATE ou DELETE sur la source, ApsaraDB for ClickHouse écrit une nouvelle ligne et utilise les champs _sign, _is_deleted et _version pour marquer ces opérations. Par conséquent, la base de données de destination contient plus de lignes que la base de données source.

Solution : Lors de l'interrogation, utilisez les conditions _sign ou _is_deleted pour filtrer les données supprimées en fonction de la version. Ajoutez également FINAL après le nom de la table pour dédupliquer les enregistrements. Pour plus d'informations sur les identifiants de champ, consultez la rubrique Informations sur les champs.

Q : Après avoir utilisé Zero-ETL pour synchroniser les données vers ApsaraDB for ClickHouse, pourquoi une table locale apparaît-elle dans la base de données de destination ?

Si la destination est un cluster ApsaraDB for ClickHouse Community-Compatible Edition, l'intégration transparente crée une table locale et une table distribuée pour la destination.

Le nom de la table distribuée est identique au nom de la table source.
Le nom d'une table locale est <distributed_table_name> + _local.