Limitações do conector do Gmail

Esta página lista limitações e considerações para a ingestão de dados do Gmail usando o Databricks Lakeflow Connect.

info

Beta

Esse recurso está em Beta. Os administradores do workspace podem controlar o acesso a esse recurso na página Pré-visualizações . Consulte Gerenciar prévias do Databricks.

Limitações gerais do conector SaaS

As limitações nesta seção aplicam-se a todos os conectores SaaS no Lakeflow Connect.

• Quando você executa um pipeline agendado, os alertas não Trigger imediatamente. Em vez disso, eles fazem Trigger quando ocorre a execução da próxima atualização.
• Quando uma tabela de origem é excluída, a tabela de destino não é excluída automaticamente. Você deve excluir a tabela de destino manualmente. Esse comportamento não é consistente com o comportamento do Spark Declarative Pipelines no Lakeflow.
• Durante períodos de manutenção da fonte, o Databricks pode não conseguir acessar seus dados.
• Se um nome de tabela de origem entrar em conflito com um nome de tabela de destino existente, a atualização do pipeline falhará.
• O suporte a pipeline de vários destinos é apenas via API.
• Opcionalmente, você pode renomear uma tabela que você ingere. Se você renomear uma tabela em seu pipeline, ele se tornará um pipeline somente de API e você não poderá mais editar o pipeline na IU.
• Se você selecionar uma coluna após o início de um pipeline, o conector não preencherá automaticamente os dados da nova coluna. Para ingerir data histórica, execute manualmente um refresh completo na tabela.
• O Databricks não consegue ingerir duas ou mais tabelas com o mesmo nome no mesmo pipeline, mesmo que elas provenham de esquemas de origem diferentes.
• O sistema de origem pressupõe que as colunas de cursor são monotonicamente crescentes.
• O conector ingere dados brutos sem transformações. Use Spark Declarative Pipelines downstream em LakeFlow Pipelines para transformações.

Específico do conector

As limitações nesta seção são específicas para o conector do Gmail.

• As tabelas profile, labels, labels_details, drafts e filters são apenas para refresh completo. Eles são reingeridos na íntegra a cada execução do pipeline e não são sincronizados incrementalmente.
• Apenas as tabelas messages e message_labels são sincronizadas incrementalmente, usando a API de história do Gmail baseada em um cursor historyId.
• As tabelas messages e message_labels não suportam o acompanhamento de histórico do SCD tipo 2; configurar o SCD tipo 2 para essas tabelas faz com que a validação do pipeline falhe.
• Se o Gmail expirar o historyId armazenado (a API de história retorna um 404 porque o cursor é mais antigo que a janela de retenção do Gmail), o conector automaticamente recorre a um refresh completo da tabela afetada.
• O Gmail retém o histórico por um período limitado, geralmente cerca de sete dias. A Databricks recomenda agendar a execução do pipeline pelo menos uma vez a cada sete dias. Se o pipeline for executado com menos frequência, o historyId armazenado pode expirar e forçar um full refresh de messages e message_labels.
• Cada conexão ingere uma única caixa de correio. Para ingerir mais de uma caixa de correio, crie uma conexão e um pipeline separados por caixa de correio. O valor da caixa de correio é marcado como uma coluna mailbox em cada linha.
• A estrutura MIME messages payload é materializada em até 8 níveis de aninhamento. As partes aninhadas mais profundamente não são expandidas em colunas da estrutura.
• O conector é somente leitura e requer o escopo gmail.readonly. Isso não modifica a caixa de correio de origem.