Campagne : les requêtes en briques de données sont parfois très lentes
Cet article décrit comment atténuer le délai d’expiration des requêtes de workflow longues à l’aide de Databricks FDA.
Description description
Un client utilise un FDA Databricks pour les requêtes de workflow et leurs requêtes sont par intermittence très lentes et échouent en raison d’un délai d’expiration d’une heure (en raison de l’expiration du jeton OAuth après 1 heure). Les logs de workflow ont affiché les messages suivants :
Erreur ODBC ODB-240000 : [ Simba] [ Hardy] (115) La connexion a échoué avec une erreur : une réponse d’erreur Non autorisé/Interdit a été renvoyée, mais aucun message de jeton expiré n’a été reçu SQLState : 08S01
and
Erreur ODBC ODB-240000 : le jeton d’authentification a expiré. L’utilisateur doit s’authentifier à nouveau. SQLState : 08001
Résolution resolution
L’expiration elle-même n’est pas contrôlée par les paramètres du workflow Campaign ou le fichier de configuration serverConf.xml . Dans cette configuration, ACC se connecte à Databricks par le biais du pilote ODBC Simba à l’aide d’OAuth sur nmsaccountName. Les informations d’identification/le secret d’application de longue durée peuvent être valides jusqu’en 2031, mais le jeton d’accès émis pour une connexion ODBC peut toujours avoir une durée de vie beaucoup plus courte, généralement de 60 minutes.
Options de réduction :
- L’administrateur de Databricks peut consulter l’application/intégration OAuth utilisée par Adobe Campaign et augmenter la durée de vie du jeton d’accès, par exemple en mettant à jour la politique d’accès au jeton OAuth de Databricks telle que access_token_ttl_in_minutes. Cette opération doit être effectuée par l’administrateur du client ou des banques de données et doit respecter sa politique de sécurité, car les jetons d’accès de plus longue durée augmentent l’exposition en cas de fuite.
- Après avoir modifié la stratégie de jeton, attendez le temps de propagation du côté des briques de données et testez-les à nouveau avec une nouvelle connexion ACC/ODBC. Les connexions existantes ouvertes peuvent continuer à utiliser le jeton précédent émis avant le changement de politique.
- Sur le plan opérationnel, divisez ou optimisez les requêtes de workflow ACC de sorte que chaque instruction SQL DBX individuelle se termine bien en dessous de la durée de vie du jeton. Il s’agit de l’atténuation la plus sûre et la plus recommandée, car elle traite également l’exécution Lente/Mise en file d’attente intermittente du DBX au lieu de seulement étendre la fenêtre d’échec.
- Du côté des briques de données, vérifiez l’historique des requêtes de l’entrepôt de données SQL pour les exécutions lentes et réglez le chemin de l’entrepôt de données/requête : temps de mise en file d’attente, simultanéité, mise à l’échelle/max des clusters, démarrages à froid, plan de requête, statistiques/mise en page de table et volume de données pour les prédicats/jointures.
- Si le client a besoin d’instructions SQL DBX pouvant légitimement s’exécuter plus longtemps que la durée de vie du jeton d’accès OAuth, il doit confirmer avec Databricks/Simba si le mode OAuth utilisé par le pilote ODBC prend en charge l’actualisation du jeton pour les instructions ouvertes/à exécution longue dans leur configuration. Dans le cas contraire, il peut être nécessaire d’augmenter la durée de vie du jeton ou d’utiliser un autre mode d’authentification pris en charge.
La solution pratique à court terme consiste donc à augmenter la durée de vie du jeton d’accès OAuth des briques de données pour l’intégration ACC, tandis que le correctif à long terme consiste à réduire le temps d’exécution des requêtes DBX/la mise en file d’attente afin que les workflows ne dépendent pas des jetons survivant aux appels SQL de très longue durée.