Gmail コネクタの制限事項

このページでは、Databricks Lakeflow Connectを使ってGmailからデータを取り込む際の制限事項や注意点を記載しています。

備考

ベータ版

この機能はベータ版です。ワークスペース管理者は、 プレビュー ページからこの機能へのアクセスを制御できます。Databricksのプレビューを管理するを参照してください。

一般的なSaaSコネクタの制限事項

このセクションの制限事項は、Lakeflowコネクト のすべてのSaaS コネクタに適用されます。

• スケジュールされたパイプラインをランしても、アラートはすぐにTriggerしません。代わりに、次のアップデートがTriggerされます。
• ソーステーブルを削除しても、宛先テーブルは自動的に削除されません。宛先テーブルは手動で削除する必要があります。この動作は、Lakeflow上のSpark宣言型パイプラインの動作と一致しません。
• ソースのメンテナンス期間中は、Databricks がデータにアクセスできない場合があります。
• ソーステーブル名が既存の宛先テーブル名と競合する場合、パイプラインの更新は失敗します。
• マルチ送信先パイプラインのサポートは API 限定です。
• オプションで、取り込むテーブルの名前を変更できます。パイプライン内のテーブルの名前を変更すると、そのテーブルは API 専用パイプラインになり、UI でパイプラインを編集できなくなります。
• パイプラインがすでに起動した後に列を選択した場合、コネクタはその新しい列のデータを自動的にバックフィルしません。ヒストリカルデータを取り込むには、テーブルで完全更新を手動でランします。
• Databricksでは、異なるソーススキーマからのテーブルであっても、同じパイプライン内で同じ名前のテーブルを2つ以上取り込むことはできません。
• ソースシステムは、カーソル列が単調に増加することを前提としています。
• このコネクタは、変換を行わずに生データを取り込みます。変換には、LakeFlow Pipelines 上のダウンストリームの Spark 宣言型パイプラインを使用してください。

コネクタ固有の

このセクションに記載されている制限事項は、Gmailコネクタに特有のものです。

• profile、labels、labels_details、drafts、filtersテーブルはフル更新のみです。パイプラインの実行ごとに完全に再取り込みされ、インセクティブ同期はされません。
• messages テーブルと message_labels テーブルのみが、historyId カーソルをキーとする Gmail History API を使用して増分同期されます。
• messages テーブルと message_labels テーブルは SCD タイプ 2 の履歴追跡をサポートしていません。これらのテーブルに対して SCD タイプ 2 を構成すると、パイプラインの検証が失敗します。
• Gmail が保存された historyId を期限切れにした場合（カーソルが Gmail の保持期間よりも古いため、History API が 404 を返す）、コネクタは自動的に影響を受けるテーブルの完全更新にフォールバックします。
• Gmail は、限られた期間（通常は約 7 日間）の履歴を保持します。Databricksでは、少なくとも7日に1回はパイプラインを実行するようにスケジュールすることを推奨しています。パイプラインの実行頻度が低い場合、保存された historyId が期限切れになり、messages と message_labels の完全更新が強制される可能性があります。
• 各接続で 1 つのメールボックスを取り込みます。複数のメールボックスを取り込むには、メールボックスごとに個別の接続とパイプラインを作成してください。メールボックスの値は、すべての行に mailbox 列としてスタンプされます。
• messages payload MIME構造は、最大8レベルのネストまでマテリアライズされます。より深くネストされた部分は、構造体の列には展開されません。
• このコネクタは読み取り専用であり、gmail.readonly スコープが必要です。ソースのメールボックスを変更することはありません。