Einschränkungen des Gmail-Connectors

Diese Seite listet Einschränkungen und Überlegungen zur Erfassung von Daten aus Gmail mit Databricks Lakeflow Connect auf.

Allgemeine SaaS-Connectorbeschränkungen

Die Einschränkungen in diesem Abschnitt gelten für alle SaaS-Connectors in Lakeflow Connect.

• Wenn Sie eine geplante Pipeline ausführen, werden Warnungen nicht sofort ausgelöst. Stattdessen werden sie ausgelöst, wenn das nächste Update ausgeführt wird.
• Wenn eine Quelltabelle gelöscht wird, wird die Zieltabelle nicht automatisch gelöscht. Sie müssen die Zieltabelle manuell löschen. Dieses Verhalten entspricht nicht dem Verhalten von Spark Declarative Pipelines on Lakeflow.
• Während der Quellwartungszeiträume können Databricks möglicherweise nicht auf Ihre Daten zugreifen.
• Wenn ein Quelltabellenname mit einem vorhandenen Zieltabellennamen in Konflikt steht, schlägt die Pipelineaktualisierung fehl.
• Die Unterstützung für Multi-Destination-Pipelines erfolgt ausschließlich über die API.
• Sie können nach Belieben eine Tabelle umbenennen, die Sie importieren. Wenn Sie eine Tabelle in Ihrer Pipeline umbenennen, wird sie zu einer nur API-Pipeline, und Sie können die Pipeline nicht mehr in der Benutzeroberfläche bearbeiten.
• Wenn Sie eine Spalte auswählen, nachdem eine Pipeline bereits gestartet wurde, füllt der Verbinder die Daten für die neue Spalte nicht automatisch aus. Um historische Daten zu erfassen, führen Sie manuell eine vollständige Aktualisierung der Tabelle aus.
• Databricks können nicht zwei oder mehr Tabellen mit demselben Namen in derselben Pipeline aufnehmen, auch wenn sie aus verschiedenen Quellschemas stammen.
• Das Quellsystem geht davon aus, dass die Cursorspalten monoton steigen.
• Der Connector erfasst rohe Daten ohne Transformationen. Verwenden Sie downstream Spark Declarative Pipelines auf Lakeflow-Pipelines für Transformationen.

Verbinderspezifisch

Die Einschränkungen in diesem Abschnitt gelten speziell für den Gmail-Connector.

• Die , labels, labels_details, , draftsund filters Tabellen profilesind ausschließlich bei vollständiger Aktualisierung. Sie werden bei jedem Pipeline-Lauf vollständig erneut eingetragen und synchronisieren sich nicht inkrementiell.
• Nur die und message_labels Tabellen messages synchronisieren sich inkrementiell, wobei die Gmail History API auf einem historyId Cursor gesetzt wird.
• Die und message_labels Tabellen messages unterstützen keine SCD Type 2 History Tracking; die Konfiguration von SCD Type 2 für diese Tabellen führt dazu, dass die Pipeline-Validierung fehlschlägt.
• Wenn Gmail das gespeicherte historyId Fenster abläuft (die History API gibt ein 404-Formular zurück, da der Cursor älter ist als das Speicherfenster von Gmail), fällt der Connector automatisch auf eine vollständige Aktualisierung der betroffenen Tabelle zurück.
• Gmail speichert die Geschichte für ein begrenztes Zeitfenster, typischerweise etwa sieben Tage. Databricks empfiehlt, die Pipeline mindestens alle sieben Tage auszuführen. Wenn die Pipeline seltener läuft, kann das gespeicherte historyId Schiff ablaufen und eine vollständige Aktualisierung von messages und message_labelserzwingen.
• Jede Verbindung nimmt einen einzelnen Briefkasten auf. Um mehr als ein Postfach zu empfangen, erstellen Sie pro Postfach eine separate Verbindung und eine Pipeline. Der Briefkastenwert ist in jeder Reihe als Spalte mailbox gestempelt.
• Die MIME-Struktur messagespayload wird auf bis zu 8 Ebenen des Verschachtelns materialisiert. Tiefer verschachtelte Teile werden nicht zu Struktursäulen erweitert.
• Der Stecker ist schreibgeschützt und benötigt das Scope gmail.readonly . Es ändert das Quellpostfach nicht.