Limitations du connecteur GitHub

info

Bêta

Cette fonctionnalité est en Bêta. Les administrateurs du Workspace peuvent contrôler l'accès à cette fonctionnalité à partir de la page Previews . Consultez Gérer les aperçus Databricks.

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

Limitations générales

• Lorsque vous exécutez un pipeline planifié, les alertes ne se Trigger pas immédiatement. Au lieu de cela, ils Trigger lors de l’exécution de la prochaine mise à jour.
• Lorsqu’une table source est supprimée, la table de destination n’est pas automatiquement supprimée. Vous devez supprimer la table de destination manuellement. Ce comportement n'est pas cohérent avec le comportement de Spark Declarative Pipelines sur Lakeflow.
• Pendant les périodes de maintenance de la source, Databricks pourrait ne pas être en mesure d'accéder à vos données.
• Si un nom de table source entre en conflit avec un nom de table de destination existant, la mise à jour du pipeline échoue.
• La prise en charge des pipelines multi-destination est uniquement via l'API.
• Vous pouvez éventuellement renommer une table que vous ingérez. Si vous renommez une table dans votre pipeline, il 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 qu'un pipeline a déjà start, le connecteur ne renseigne pas automatiquement les données historiques pour la nouvelle colonne. Pour ingérer des données historiques, exécutez manuellement un refresh complet 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 du curseur augmentent de façon monotone.
• Le connecteur ingère des données brutes sans transformations. Utilisez les Spark Declarative Pipelines en aval sur les Lakeflow Pipelines 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 table repo_contents capture les suppressions de fichiers. Lorsqu'un fichier est supprimé du repository source, le connecteur supprime la ligne correspondante de la table (suppression définitive). Voir Contenu du repository.

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 fournit aucun moyen de filtrer les enregistrements en fonction d’un curseur. Ces tables sont entièrement actualisées à chaque mise à jour du pipeline. Pour obtenir la liste des tables et de leurs modèles de mise à jour, voir Données prises en charge.

Conseils sur les performances pour les grandes organisations

Des tables telles que commits, pull_requests et issues peuvent contenir des millions d’enregistrements dans les grandes organisations. Parce que ces tables sont entièrement actualisées à chaque exécution du pipeline, le coût d'ingestion évolue 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 plus faible pour les pipelines qui incluent des tables à volume élevé.

Contenu du repository

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

• Default Branch only : Le connecteur ingère la branch par default de chaque repository, enregistrée dans la colonne branch_name. La sélection ou l'ingestion de plusieurs branches par repository n'est pas prise en charge.
• Limite de la taille du 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 trueest. Seul le contenu des fichiers texte est renseigné dans content.

Pour plus d'informations, consultez le contenu du repository (table repo_contents).

Données prises en charge

Tables avec mises à jour incrémentielles

Les tables suivantes prennent en charge les mises à jour incrémentielles :

• repositories
• audit_logs: comptes d'organisation uniquement. Sur le plan gratuit github.com, l'historique des audit Logs est limité à 90 jours.
• repo_contents: Ingère les entrées d'arborescence de repository et le contenu des fichiers. Les mises à jour et suppressions incrémentielles sont prises en charge. Consultez les contenus du repository.

Tables avec des mises à jour par batch uniquement

Les tables suivantes sont entièrement actualisées à chaque mise à jour de pipeline (non incé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