Limitações dos conectores do GitHub

Esta página contém informações sobre limitações conhecidas do conector GitHub gerido no Lakeflow Connect.

Limitações gerais

• Quando você executa um pipeline agendado, os alertas não são acionados imediatamente. Em vez disso, eles são acionados quando a próxima atualização é executada.
• Quando uma tabela de origem é excluída, a tabela de destino não é excluída automaticamente. Você deve excluir a tabela de destino manualmente. Este comportamento não é consistente com o comportamento dos Spark Declarative Pipelines no Lakeflow.
• Durante os períodos de manutenção de origem, 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 para múltiplos destinos é somente através da API.
• Opcionalmente, você pode renomear uma tabela ingerida. Se você renomear uma tabela em seu pipeline, ela se tornará um pipeline somente de API e você não poderá mais editar o pipeline na interface do usuário.
• Se você selecionar uma coluna depois que um pipeline já tiver iniciado, o conector não preencherá automaticamente os dados da nova coluna. Para ingerir dados históricos, execute manualmente uma atualização completa na tabela.
• O Databricks não pode ingerir duas ou mais tabelas com o mesmo nome no mesmo pipeline, mesmo que elas venham de esquemas de origem diferentes.
• O sistema de origem assume que as colunas do cursor estão aumentando monotonicamente.
• O conector ingere dados brutos sem transformações. Use Pipelines Declarativos Spark a jusante nos pipelines Lakeflow para transformações.

Eliminações não suportadas

O conector do GitHub não suporta a busca de eliminações, com exceção de repo_contents. Isto é uma limitação da API do GitHub.

A repo_contents tabela capta eliminações de ficheiros. Quando um ficheiro é removido do repositório de origem, o conector remove a linha correspondente da tabela (eliminação forçada). Ver Conteúdos do Repositório.

Apoio incremental limitado

A maioria das tabelas não suporta atualizações incrementais porque a API do GitHub não fornece uma forma de filtrar registos com base num cursor. Estas tabelas são totalmente atualizadas a cada atualização do pipeline. Para uma lista de tabelas e os seus padrões de atualização, veja Dados suportados.

Orientação de desempenho para grandes organizações

Tabelas apenas por lote, como pull_requests, pull_request_commits, e pull_request_reviews podem conter milhões de registos em grandes organizações. Como estas tabelas são integralmente atualizadas em cada execução do pipeline, o custo de ingestão varia em função da dimensão da organização e da frequência de execução do pipeline.

Para reduzir o volume por execução:

• Utilize a seleção de colunas para limitar as colunas importadas nestas tabelas.
• Utilize uma frequência de execução mais baixa nos pipelines que incluam tabelas com grande volume de dados.
• Restringa a ingestão a repositórios específicos para tabelas com âmbito de repositório, como pull_requests. Isto não reduz o volume para pull_request_commits ou pull_request_reviews, que ignoram a seleção do repositório. Veja Seleção do repositório.

Seleção de repositórios

Por defeito, o conector ingere dados de todos os repositórios da organização. Para restringir a ingestão a repositórios específicos, defina a repository_id_selections opção de conector. Ver Opções de Conectores.

A seleção de repositórios aplica-se apenas a tabelas com âmbito de repositório. Não tem efeito nas seguintes tabelas organizacionais e aninhadas, que são sempre ingeridas na totalidade mesmo quando repository_id_selections estão definidas:

• audit_logs
• teams
• org_members
• team_members
• deployment_statuses
• pull_request_commits
• pull_request_reviews

Conteúdos do repositório

A repo_contents tabela ingere todas as entradas da árvore de cada repositório, incluindo ficheiros, diretórios, submódulos e ligações simbólicas. Apenas as entradas do ficheiro (blob) preenchem a content coluna. Diretórios (tree) e submódulos (commit) são ingeridos apenas como linhas de metadados com uma coluna nula content . Aplicam-se as seguintes limitações:

• Apenas ramo predefinido: O conector ingere o ramo predefinido de cada repositório, registado na branch_name coluna. Selecionar ou ingerir múltiplos ramos por repositório não é suportado.
• Limite de tamanho do ficheiro: Ficheiros superiores a 100 MB não são obtidos. O conector ainda importa a linha de metadados do ficheiro (path, sha, size_bytes), mas a coluna content é null.
• Ficheiros binários: Para ficheiros binários, a content coluna é null e is_binary é true. Apenas o conteúdo dos ficheiros de texto é preenchido em content.

Para mais informações, consulte Conteúdos do repositório (repo_contentstabela).

Dados suportados

Tabelas com atualizações incrementais

As tabelas seguintes suportam atualizações incrementais:

• repositories
• audit_logs: Apenas para contas de organização. O GitHub mantém eventos de registo de auditoria organizacional por até 180 dias. O conector não pode ingerir eventos anteriores a esta janela de retenção. No plano gratuito, o histórico dos registos github.com de auditoria está limitado a 90 dias.
• repo_contents: Ingere entradas da árvore do repositório e o conteúdo dos ficheiros. São suportadas atualizações e eliminações incrementais. Ver Conteúdos do Repositório.
• commits
• issues
• issue_comments
• pull_request_review_comments

Tabelas apenas com atualizações em lote

As tabelas seguintes são totalmente atualizadas em cada atualização do pipeline (não incremental):

• branches
• collaborators
• deployments
• deployment_statuses
• discussions
• labels
• milestones
• org_members
• pull_request_commits
• pull_request_reviews
• pull_requests
• releases
• tags
• team_members
• teams
• workflows