limitações do conector GitHub

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

Limitações gerais

• Quando você executa um pipeline agendado, os alertas não são disparados imediatamente. Em vez disso, eles são disparados quando a próxima atualização é executada.
• Quando uma tabela de origem é excluída, a tabela de destino não é excluída automaticamente. Você precisa excluir a tabela de destino manualmente. Este comportamento não é consistente com o comportamento de Pipelines Declarativos do Spark no Lakeflow.
• Durante os períodos de manutenção, o Databricks pode não conseguir acessar seus dados.
• Se o nome da tabela de origem entrar em conflito com um nome de tabela de destino existente, o fluxo falhará.
• O suporte a pipeline de vários destinos é somente para API.
• Opcionalmente, você pode renomear uma tabela que ingerir. 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 sido iniciado, o conector não fará o backfill de dados automaticamente para a 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 pressupõe que as colunas de cursor estão aumentando monotonicamente.
• O conector ingere dados brutos sem transformações. Use Pipelines Declarativos do Spark em pipelines do Lakeflow para transformações.

Não há suporte para exclusões

O conector do GitHub não oferece suporte à recuperação de exclusões, com exceção de repo_contents. Essa é uma limitação da API GitHub.

A tabela repo_contents registra exclusões de arquivos. Quando um arquivo é removido do repositório de origem, o conector remove a linha correspondente da tabela (exclusão rígida). Consulte o conteúdo do Repositório.

Suporte incremental limitado

A maioria das tabelas não dá suporte a atualizações incrementais porque a API GitHub não fornece uma maneira de filtrar registros com base em um cursor. Essas tabelas são totalmente atualizadas em cada atualização de pipeline. Para obter uma lista de tabelas e seus padrões de atualização, consulte os dados com suporte.

Diretrizes de desempenho para grandes organizações

Tabelas apenas em lote, como pull_requests, pull_request_commits, e pull_request_reviews podem conter milhões de registros em grandes organizações. Como essas tabelas são totalmente atualizadas a cada execução do pipeline, o custo de ingestão escala de acordo com o tamanho da organização e a frequência do pipeline.

Para reduzir o volume por execução:

• Use a seleção de coluna para limitar as colunas ingeridas para essas tabelas.
• Use uma frequência de pipeline mais baixa para pipelines que incluam tabelas de alto volume.
• Restringa a ingestão a repositórios específicos para tabelas com escopo de repositório, como pull_requests. Isso não reduz o volume para pull_request_commits ou pull_request_reviews, que ignoram a seleção do repositório. Veja Seleção de repositório.

Seleção de repositórios

Por padrão, 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. Consulte as opções do Conector.

A seleção de repositório se aplica apenas a tabelas com escopo de repositório. Não tem efeito sobre as seguintes tabelas organizacionadas 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údo do repositório

A repo_contents tabela ingere todas as entradas na árvore de cada repositório, incluindo arquivos, diretórios, submódulos e links simbólicos. Somente entradas de arquivo (blob) preenchem a content coluna. Diretórios (tree) e submódulos (commit) são ingeridos como linhas somente de metadados com uma coluna nula content . As seguintes limitações se aplicam:

• Apenas a ramificação padrão: o conector importa a ramificação padrão de cada repositório, registrada na coluna branch_name. Não há suporte à seleção ou ingestão de várias ramificações por repositório.
• Limite de tamanho do arquivo: arquivos maiores que 100 MB não são buscados. O conector ainda ingere a linha de metadados do arquivo (path, sha, size_bytes), mas a coluna content é null.
• Arquivos binários: para arquivos binários, a content coluna é null e is_binary é true. Somente o conteúdo de arquivos de texto é preenchido em content.

Para obter mais informações, consulte o conteúdo do Repositório (repo_contents tabela).

Dados com suporte

Tabelas com atualizações incrementais

As tabelas a seguir dão suporte a atualizações incrementais:

• repositories
• audit_logs: Somente para contas da organização. O GitHub mantém eventos do log de auditoria da organização por até 180 dias. O conector não pode ingerir eventos anteriores a essa janela de retenção. No github.com plano gratuito, o histórico dos logs de auditoria é limitado a 90 dias.
• repo_contents: ingere entradas de árvore de repositório e conteúdo de arquivo. Há suporte para atualizações incrementais e exclusões. Consulte o conteúdo do Repositório.
• commits
• issues
• issue_comments
• pull_request_review_comments

Tabelas apenas com atualizações em lote

As tabelas a seguir são totalmente atualizadas a 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