Campaign: le query del database sono molto lente a intermittenza
Questo articolo descrive come mitigare il timeout su query di flussi di lavoro lunghi utilizzando Databricks FDA.
Descrizione description
Un cliente utilizza un’FDA di Databricks per le query del flusso di lavoro e le query sono a intermittenza molto lente e non riescono a causa del limite di timeout di 1 ora (a causa della scadenza del token OAuth dopo 1 ora). I registri del flusso di lavoro mostravano messaggi:
Errore ODB-240000 ODBC: [ Simba] [ Hardy] (115) Connessione non riuscita con errore: Risposta di errore non autorizzata/non consentita restituita, ma nessun messaggio token scaduto ricevuto SQLState: 08S01
e
Errore ODB-240000 ODBC: token di autenticazione scaduto. L’utente deve autenticare di nuovo. SQLState: 08001
Risoluzione resolution
La scadenza stessa non è controllata dalle impostazioni del flusso di lavoro di Campaign o dal file di configurazione serverConf.xml. In questa configurazione ACC si connette ai database tramite il driver ODBC Simba utilizzando OAuth in nmsaccountName. Il segreto credenziali/app di lunga durata può essere valido fino al 2031, ma il token di accesso rilasciato per una connessione ODBC può avere una durata molto più breve, di solito 60 minuti.
Opzioni di mitigazione:
- L’amministratore dei database può rivedere l’integrazione/app OAuth utilizzata da Adobe Campaign e aumentare il TTL del token di accesso, ad esempio aggiornando i criteri di accesso al token OAuth di Databricks, come access_token_ttl_in_minutes. Questa operazione deve essere eseguita dall’amministratore del cliente/database e deve rispettare i criteri di sicurezza, in quanto i token di accesso di durata maggiore aumentano l’esposizione in caso di perdite.
- Dopo aver modificato il criterio del token, consenti il tempo di propagazione sul lato Database e verifica di nuovo con una nuova connessione ACC/ODBC. Le connessioni aperte esistenti possono continuare a utilizzare il token precedente emesso prima della modifica del criterio.
- A livello operativo, suddivide o ottimizza le query del flusso di lavoro ACC in modo che ogni singola istruzione SQL DBX venga completata ben al di sotto della durata del token. Si tratta della mitigazione più sicura e preferita, in quanto riguarda anche l’esecuzione intermittente lenta/in coda di DBX anziché solo l’estensione della finestra di errore.
- Sul lato Database, verificare la cronologia delle query di SQL warehouse per individuare le esecuzioni lente e ottimizzare il percorso di warehouse/query: tempo di accodamento, concorrenza, scalabilità/max cluster, avvii freddi, piano di query, statistiche di tabella/layout e volume di dati per i predicati/join.
- Se il cliente richiede istruzioni SQL DBX che possono essere eseguite legittimamente per un periodo di tempo superiore alla durata del token di accesso OAuth, deve confermare con Databricks/Simba se la modalità OAuth utilizzata dal driver ODBC supporta l’aggiornamento dei token per le istruzioni aperte/a esecuzione prolungata nella propria configurazione. In caso contrario, potrebbe essere necessario aumentare il TTL del token o utilizzare un’altra modalità di autenticazione supportata.
Pertanto, la mitigazione pratica a breve termine consiste nell’aumentare il TTL del token di accesso OAuth Databricks per l’integrazione ACC, mentre la correzione a lungo termine consiste nel ridurre il runtime/coda delle query DBX in modo che i flussi di lavoro non dipendano da token che sopravvivono a chiamate SQL con esecuzione molto prolungata.