Campaign: trasferimenti di dati lenti da Adobe Campaign a database (DBX)
Questo articolo descrive un problema di prestazioni in cui i trasferimenti di dati da Adobe Campaign a Databrick sono significativamente più lenti del previsto. Questo comportamento si verifica quando Campaign non può utilizzare il meccanismo di caricamento in blocco e utilizza piuttosto una strategia di inserimento riga per riga più lenta.
Descrizione description
In alcuni flussi di lavoro di Adobe Campaign, i dati scritti nei database possono essere estremamente lenti, anche quando altri percorsi di trasferimento del database funzionano normalmente.
I sintomi tipici includono:
- I trasferimenti da Adobe Campaign o da origini dati federate a database richiedono molto più tempo del previsto.
- Flussi di dati inversi o alternativi possono comunque funzionare normalmente.
- Il problema è riproducibile in più flussi di lavoro o ambienti.
- I registri di flusso di lavoro o di audit contengono un avviso simile al seguente:
Impossibile trovare l’account di archiviazione utilizzato per il caricamento in blocco. Utilizzo della strategia predefinita per il caricamento in blocco
Questo avviso indica che Campaign non è riuscito a trovare la configurazione dell’archiviazione collegata necessaria per il percorso di caricamento in blocco. Di conseguenza, il connettore torna a un metodo di inserimento riga per riga predefinito su ODBC.
Risoluzione resolution
La lentezza nelle prestazioni di trasferimento dei dati osservata durante la scrittura di dati da Adobe Campaign a Databricks è una conseguenza diretta del fatto che l’account esterno Databricks non dispone di un account di archiviazione cloud collegato (Azure Blob o AWS S3) configurato.
Causa principale
Quando Campaign scrive i dati nelle banche dati, tenta di utilizzare un percorso di caricamento in blocco che si basa su un account di archiviazione cloud collegato come area di gestione temporanea intermedia. Il processo è progettato come segue:
- Campaign serializza i dati in uscita come file CSV compressi.
- Campaign carica questi file nell’account di archiviazione cloud collegato (Azure Blob o S3).
- Campaign rilascia il comando DATABRICKS COPY INTO, che indica ai Databricks di acquisire i file di staging direttamente dall’archiviazione cloud.
- I database leggono i file in parallelo alla velocità nativa.
Se non è configurato alcun account di archiviazione collegato, Campaign non può utilizzare questo percorso di caricamento in blocco. Il sistema registra il seguente avviso:
Impossibile trovare l’account di archiviazione utilizzato per il caricamento in blocco. Utilizzo della strategia predefinita per il caricamento in blocco
Questo avviso è visibile nel registro di audit del flusso di lavoro. Dopo questo avviso, Campaign torna all’invio di singole istruzioni INSERT a livello di riga tramite la connessione ODBC. Ogni riga richiede un round trip di rete separato al data warehouse SQL di Databricks, con conseguente riduzione delle prestazioni in modo lineare con il volume dei dati.
Questo comportamento di fallback non è una modalità rallentata, ma non è adatto per volumi di dati su scala di produzione. Esiste solo come meccanismo di ultima istanza.
Pertanto, l’aggiunta di un account di archiviazione collegato (Azure Blob o AWS S3) all’account esterno Databricks risolverà questo problema di prestazioni. Con un account di archiviazione configurato, Campaign utilizzerà il percorso di caricamento in blocco COPY INTO, che è il meccanismo di acquisizione dei dati consigliato dai database.