Campaign : transferts de données lents d’Adobe Campaign vers les briques de données (DBX)
Cet article décrit un problème de performances en raison duquel les transferts de données d’Adobe Campaign vers les briques de données sont considérablement plus lents que prévu. Le comportement se produit lorsque Campaign ne peut pas utiliser son mécanisme de chargement en masse et retourne à une stratégie d’insertion ligne par ligne plus lente.
Description description
Dans certains workflows Adobe Campaign, les données écrites dans les briques de données peuvent être extrêmement lentes, même lorsque d’autres chemins de transfert de base de données fonctionnent normalement.
Les symptômes typiques incluent :
- Les transferts d’Adobe Campaign ou de sources de données fédérées vers des briques de données prennent beaucoup plus de temps que prévu.
- Les flux de données inverses ou alternatifs peuvent toujours fonctionner normalement.
- Le problème est reproductible dans plusieurs workflows ou environnements.
- Les logs de workflow ou d’audit contiennent un avertissement similaire à :
Le compte de stockage utilisé pour le chargement en bloc est introuvable. Utilisation de la stratégie de chargement en masse par défaut
Cet avertissement indique que Campaign n’a pas pu trouver la configuration de stockage liée requise pour le chemin de chargement en masse. Par conséquent, le connecteur revient à une méthode d’insertion ligne par ligne par défaut sur ODBC.
Résolution resolution
La lenteur des performances de transfert de données observée lors de l’écriture de données d’Adobe Campaign vers Databricks est une conséquence directe de l’absence de configuration d’un compte de stockage dans le cloud lié au compte externe Databricks (Azure Blob ou AWS S3).
Cause première
Lorsque Campaign écrit des données dans des briques de données, il tente d’utiliser un chemin de chargement en masse qui repose sur un compte de stockage dans le cloud lié comme zone de transit intermédiaire. Le processus est conçu comme suit :
- Campaign sérialise les données sortantes sous forme de fichiers CSV compressés.
- Campaign télécharge ces fichiers sur le compte d’espace de stockage lié (Azure Blob ou S3).
- Campaign émet une commande Databricks COPY INTO, demandant à Databricks d’ingérer les fichiers intermédiaires directement depuis l’espace de stockage dans le cloud.
- Les briques de données lisent les fichiers en parallèle à une vitesse native.
Lorsqu’aucun compte de stockage lié n’est configuré, Campaign ne peut pas utiliser ce chemin de chargement en masse. Le système consigne l’avertissement suivant :
Le compte de stockage utilisé pour le chargement en bloc est introuvable. Utilisation de la stratégie de chargement en masse par défaut
Cet avertissement s’affiche dans le journal d’audit du workflow. Après cet avertissement, Campaign revient à envoyer des instructions INSERT individuelles au niveau des lignes sur la connexion ODBC. Chaque ligne nécessite un aller-retour réseau distinct vers l’entrepôt SQL Databricks, ce qui entraîne une dégradation linéaire des performances en fonction du volume de données.
Ce comportement de secours n’est pas un « mode plus lent » dégradé ; il n’est pas adapté aux volumes de données à l’échelle de la production. Il n’existe qu’en dernier recours.
Ainsi, l’ajout d’un compte de stockage lié (Azure Blob ou AWS S3) au compte externe Databricks résout ce problème de performances. Une fois le compte de stockage configuré, Campaign utilisera le chemin de chargement en masse COPY INTO, qui est le mécanisme d’ingestion de données recommandé par Databricks.