Limitazioni dei connettori Gmail

Questa pagina elenca limitazioni e considerazioni per l'assorbimento di dati da Gmail utilizzando Databricks Lakeflow Connect.

Limitazioni generali del connettore SaaS

Le limitazioni in questa sezione si applicano a tutti i connettori SaaS in Lakeflow Connect.

• Durante l'esecuzione di una pipeline pianificata, gli avvisi non vengono attivati immediatamente. Attivano invece quando viene eseguito l'aggiornamento successivo.
• Quando viene eliminata una tabella di origine, la tabella di destinazione non viene eliminata automaticamente. È necessario eliminare manualmente la tabella di destinazione. Questo comportamento non è coerente con il comportamento delle pipeline dichiarative Spark in Lakeflow.
• Durante i periodi di manutenzione di origine, Databricks potrebbe non essere in grado di accedere ai dati.
• Se un nome di tabella di origine è in conflitto con un nome di tabella di destinazione esistente, l'aggiornamento della pipeline non riesce.
• Il supporto per pipeline a più destinazioni è solo tramite API.
• Puoi opzionalmente rinominare una tabella che ingerisci. Se rinomini una tabella nel tuo pipeline, diventa un pipeline esclusivamente API e non puoi più modificare il pipeline nell'interfaccia utente.
• Se selezioni una colonna dopo che una pipeline è già iniziata, il connettore non ricarica automaticamente i dati per la nuova colonna. Per inserire dati cronologici, eseguire manualmente un aggiornamento completo nella tabella.
• Databricks non può inserire due o più tabelle con lo stesso nome nella stessa pipeline, anche se provengono da schemi di origine diversi.
• Il sistema di origine presuppone che le colonne del cursore aumentino in modo monotonico.
• Il connettore inserisce dati non elaborati senza trasformazioni. Utilizza le pipeline dichiarative Spark a valle nelle pipeline Lakeflow per eseguire trasformazioni.

Specifico del connettore

Le limitazioni in questa sezione sono specifiche per il connettore Gmail.

• Le profiletabelle , labels, labels_details, drafts, e filters sono solo a aggiornamento completo. Vengono riassorbiti completamente ad ogni esecuzione della pipeline e non si sincronizzano in modo incrementale.
• Solo le messages tabelle e message_labels si sincronizzano in modo incrementale, usando l'API Cronologia di Gmail inserita su un historyId cursore.
• Le messages tabelle e message_labels non supportano il tracciamento della cronologia SCD Tipo 2; configurare SCD Tipo 2 per queste tabelle causa il guasto della validazione della pipeline.
• Se Gmail scade la memoria historyId memorizzata (l'API Storia restituisce un 404 perché il cursore è più vecchio della finestra di conservazione di Gmail), il connettore torna automaticamente a un aggiornamento completo della tabella interessata.
• Gmail conserva la cronologia per una finestra limitata, tipicamente di circa sette giorni. Databricks raccomanda di programmare la pipeline per eseguirla almeno una volta ogni sette giorni. Se la pipeline viene eseguita meno frequentemente, la memoria memorizzata historyId può scadere e costringere a un aggiornamento completo di messages e message_labels.
• Ogni connessione assume una singola cassetta postale. Per ingerire più di una cassetta postale, crea una connessione e una pipeline separate per ogni cassetta postale. Il valore della cassetta postale viene stampato come mailbox colonna su ogni riga.
• La messagespayload struttura MIME si materializza fino a 8 livelli di nidificazione. Le parti annidate più in profondità non vengono espanse in colonne di struct.
• Il connettore è di sola lettura e richiede il gmail.readonly telescopio. Non modifica la cassetta di posta sorgente.