limitaciones del conector de GitHub

Esta página contiene información sobre las limitaciones conocidas del conector de GitHub administrado en Lakeflow Connect.

Limitaciones generales

• Al ejecutar una canalización programada, las alertas no se desencadenan inmediatamente. En su lugar, se desencadenan cuando se ejecuta la siguiente actualización.
• Cuando se elimina una tabla de origen, la tabla de destino no se elimina automáticamente. Debe eliminar manualmente la tabla de destino. Este comportamiento no es coherente con las canalizaciones declarativas de Spark en el comportamiento de Lakeflow.
• Durante los períodos de mantenimiento de origen, Es posible que Databricks no pueda acceder a los datos.
• Si un nombre de tabla de origen entra en conflicto con un nombre de tabla de destino existente, se produce un error en la actualización de la canalización.
• La compatibilidad con la canalización de varios destinos es solo API.
• Opcionalmente, puede cambiar el nombre de una tabla que ingiere. Si cambia el nombre de una tabla de la canalización, se convierte en una canalización solo de API y ya no puede editar la canalización en la interfaz de usuario.
• Si selecciona una columna después de que ya se haya iniciado una canalización, el conector no rellena automáticamente los datos de la nueva columna. Para ingerir datos históricos, ejecute manualmente una actualización completa en la tabla.
• Databricks no puede ingerir dos o más tablas con el mismo nombre en la misma canalización, incluso si proceden de esquemas de origen diferentes.
• El sistema de origen supone que las columnas de cursor están aumentando de forma monotónica.
• El conector ingiere datos sin procesar sin transformaciones. Utiliza pipelines declarativos de Spark en las pipelines de Lakeflow para las transformaciones.

Eliminaciones no admitidas

El conector de GitHub no admite la recuperación de eliminaciones, con la excepción de repo_contents. Se trata de una limitación de api de GitHub.

La repo_contents tabla captura eliminaciones de archivos. Cuando se quita un archivo del repositorio de origen, el conector quita la fila correspondiente de la tabla (eliminación permanente). Consulte Contenido del repositorio.

Compatibilidad incremental limitada

La mayoría de las tablas no admiten actualizaciones incrementales porque la API de GitHub no proporciona una manera de filtrar los registros en función de un cursor. Estas tablas se actualizan completamente en cada actualización de canalización. Para obtener una lista de tablas y sus patrones de actualización, consulte Datos admitidos.

Guía de rendimiento para organizaciones de gran tamaño

Tablas solo por lotes como pull_requests, pull_request_commits, y pull_request_reviews pueden contener millones de registros en grandes organizaciones. Dado que estas tablas se actualizan por completo en cada ejecución de la canalización, el coste de ingesta aumenta en función del tamaño de la organización y de la frecuencia de ejecución de la canalización.

Para reducir el volumen por ejecución:

• Use la selección de columnas para limitar las columnas ingeridas para estas tablas.
• Utilice una frecuencia de ejecución menor para las canalizaciones que incluyan tablas con un gran volumen de datos.
• Restringir la ingestión a repositorios específicos para tablas de ámbito de repositorio como pull_requests. Esto no reduce el volumen de pull_request_commits ni pull_request_reviews, que ignoran la selección del repositorio. Consulte la selección de repositorio.

Selección de repositorio

Por defecto, el conector ingiere datos de todos los repositorios de la organización. Para restringir la ingestión a repositorios específicos, establece la repository_id_selections opción de conector. Consulte Opciones del conector.

La selección de repositorios solo se aplica a tablas de ámbito de repositorio. No tiene efecto en las siguientes tablas anidadas y de ámbito organizativo, que siempre se incorporan por completo incluso cuando se establece repository_id_selections:

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

Contenidos del repositorio

La repo_contents tabla ingiere todas las entradas del árbol de cada repositorio, incluidos archivos, directorios, submódulos y vínculos simbólicos. Solo las entradas de archivo (blob) rellenan la content columna. Los directorios (tree) y los submódulos (commit) se ingieren como filas de solo metadatos con una columna null content . Se presentan las siguientes limitaciones:

• Solo rama predeterminada: el conector ingiere la rama predeterminada de cada repositorio, registrada en la branch_name columna. No se admite la selección o ingesta de varias ramas por repositorio.
• Límite de tamaño de archivo: no se capturan los archivos de más de 100 MB. El conector sigue ingeriendo la fila de metadatos del archivo (path, sha, size_bytes), pero la content columna es null.
• Archivos binarios: para los archivos binarios, la content columna es null y is_binary es true. Solo se cargan en content los contenidos de archivos de texto.

Para obtener más información, vea Contenido del repositorio (repo_contents tabla).

Datos compatibles

Tablas con actualizaciones incrementales

Las tablas siguientes admiten actualizaciones incrementales:

• repositories
• audit_logs: Solo cuentas de organizaciones. GitHub retiene los eventos de registro de auditoría de la organización durante un máximo de 180 días. El conector no puede ingerir eventos anteriores a esta ventana de retención. En github.com el plan gratuito, el historial de registros de auditoría está limitado a 90 días.
• repo_contents: ingiere entradas de árbol de repositorio y contenido del archivo. Se admiten actualizaciones y eliminaciones incrementales. Consulte Contenido del repositorio.
• commits
• issues
• issue_comments
• pull_request_review_comments

Solo tablas con actualizaciones por lotes

Las siguientes tablas se actualizan por completo en cada actualización de la pipeline (sin actualización 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