limitations du connecteur GitHub

Cette page contient des informations sur les limitations connues du connecteur de GitHub managé dans Lakeflow Connect.

Limitations générales

• Lorsque vous exécutez un pipeline planifié, les alertes ne se déclenchent pas immédiatement. Au lieu de cela, elles se déclenchent lorsque la prochaine mise à jour s’exécute.
• Lorsqu’une table source est supprimée, la table de destination n’est pas automatiquement supprimée. Vous devez supprimer manuellement la table de destination. Ce comportement n’est pas cohérent avec le comportement de Spark Declarative Pipelines sur Lakeflow.
• Pendant les périodes de maintenance source, Databricks peut ne pas être en mesure d’accéder à vos données.
• Si un nom de table source est en conflit avec un nom de table de destination existant, la mise à jour du pipeline échoue.
• Le support du pipeline multi-destination est disponible uniquement via l'API.
• Vous pouvez éventuellement renommer une table que vous ingérez. Si vous renommez une table dans votre pipeline, elle devient un pipeline API uniquement et vous ne pouvez plus modifier le pipeline dans l’interface utilisateur.
• Si vous sélectionnez une colonne après le démarrage d’un pipeline, le connecteur ne reremplit pas automatiquement les données de la nouvelle colonne. Pour ingérer des données historiques, exécutez manuellement une actualisation complète sur la table.
• Databricks ne peut pas ingérer deux tables ou plus portant le même nom dans le même pipeline, même si elles proviennent de schémas sources différents.
• Le système source suppose que les colonnes de curseur augmentent de façon monotonique.
• Le connecteur ingère des données brutes sans transformations. Utiliser des pipelines Spark Declarative Pipelines en aval sur les pipelines Lakeflow pour les transformations.

Suppressions non prises en charge

Le connecteur GitHub ne prend pas en charge la récupération des suppressions, à l’exception de repo_contents. Il s’agit d’une limitation de l’API GitHub.

La repo_contents table capture les suppressions de fichiers. Lorsqu’un fichier est supprimé du référentiel source, le connecteur supprime la ligne correspondante de la table (suppression en dur). Consultez le contenu du référentiel.

Prise en charge incrémentielle limitée

La plupart des tables ne prennent pas en charge les mises à jour incrémentielles, car l'API GitHub ne permet pas de filtrer les enregistrements en fonction d'un curseur. Ces tables sont entièrement actualisées sur chaque mise à jour de pipeline. Pour obtenir la liste des tables et leurs modèles de mise à jour, consultez Les données prises en charge.

Conseils sur les performances pour les grandes organisations

Les tables telles que commits, pull_requestset issues peuvent contenir des millions d’enregistrements dans de grandes organisations. Étant donné que ces tables sont entièrement réactualisées à chaque exécution du pipeline, les coûts d’ingestion augmentent en fonction de la taille de l’organisation et de la fréquence du pipeline.

Pour réduire le volume par exécution :

• Utilisez la sélection de colonnes pour limiter les colonnes ingérées pour ces tables.
• Utilisez une fréquence de pipeline inférieure pour les pipelines qui incluent des tables à volume élevé.

Contenu d’un dépôt

La repo_contents table ingère toutes les entrées dans l’arborescence de chaque référentiel, y compris les fichiers, les répertoires, les sous-modules et les liens symboliques. Seules les entrées de fichier (blob) remplissent la content colonne. Les répertoires (tree) et les sous-modules (commit) sont ingérés en tant que lignes de métadonnées uniquement avec une colonne Null content . Les limites suivantes s'appliquent :

• Branche par défaut uniquement : le connecteur ingère la branche par défaut de chaque référentiel, enregistrée dans la branch_name colonne. La sélection ou l’ingestion de plusieurs branches par référentiel n’est pas prise en charge.
• Limite de taille de fichier : les fichiers de plus de 100 Mo ne sont pas récupérés. Le connecteur ingère toujours la ligne de métadonnées du fichier (path, sha, size_bytes), mais la colonne content est null.
• Fichiers binaires : pour les fichiers binaires, la content colonne est null et is_binary est true. Seul le contenu du fichier texte est renseigné dans content.

Pour plus d’informations, consultez Le contenu du référentiel (repo_contents table).

Données compatibles

Tables avec mises à jour incrémentielles

Les tableaux suivants prennent en charge les mises à jour incrémentielles :

• repositories
• audit_logs : uniquement pour les comptes d’organisation. Sur github.com un plan gratuit, l’historique des journaux d’audit est limité à 90 jours.
• repo_contents: ingère les entrées de l’arborescence du référentiel et le contenu du fichier. Les mises à jour et suppressions incrémentielles sont prises en charge. Consultez le contenu du référentiel.

Tables avec mises à jour par lots uniquement

Les tableaux suivants sont entièrement actualisés sur chaque mise à jour de pipeline (non incrémentielle) :

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