Límites y referencias de carpetas de Git de Databricks

En las secciones siguientes se especifican límites para las carpetas de Git de Databricks y la integración de Git. Para obtener información general, consulte Límites de recursos.

Vaya a:

• Límites de archivos y repositorios
• Configuración

Para obtener información sobre los tipos de recursos de Databricks admitidos en carpetas de Git, consulte ¿Qué tipos de recursos son compatibles con las carpetas de Git?.

Límites de archivos y repositorios

Azure Databricks no aplica un límite en el tamaño del repositorio. Pero:

• Las ramas de trabajo están limitadas a 1 GB.
• No puede ver los archivos de más de 10 MB en la interfaz de usuario de Azure Databricks.
• Los archivos de área de trabajo individuales tienen límites de tamaño independientes. Consulte limitaciones de .
• Las ramas locales pueden permanecer en la carpeta Git asociada durante un máximo de 30 días después de eliminar la rama remota. Para quitar completamente una rama local, elimine el repositorio.

Databricks recomienda mantener el número total de recursos y archivos del área de trabajo inferiores a 20 000.

Cada operación de Git está limitada a 2 GB de memoria y 4 GB de escritura de disco. Dado que se aplican límites por operación, se produce un error en la clonación de un repositorio de 5 GB, pero la clonación de un repositorio de 3 GB y la adición posterior de 2 GB se realiza correctamente.

Si el repositorio supera estos límites, es posible que reciba un error o un tiempo de espera durante la clonación, aunque es posible que la operación siga completando en segundo plano.

Para trabajar con repositorios más grandes, pruebe la extracción dispersa o los comandos de la línea de comandos de Git.

Para escribir archivos temporales que no se conservan después del apagado del clúster, use $TEMPDIR. Esto evita exceder los límites de tamaño de las ramas y ofrece un mejor rendimiento que escribir en el directorio de trabajo (CWD) del sistema de archivos del área de trabajo. Consulte ¿Dónde debo escribir archivos temporales en Azure Databricks?.

Recuperación de archivos eliminados

La capacidad de recuperación de archivos varía según la acción. Algunas acciones permiten la recuperación a través de la carpeta Papelera , mientras que otras no. Los archivos previamente confirmados e insertados en una rama remota se pueden restaurar mediante el historial de confirmaciones de Git del repositorio remoto:

Acción	¿Se puede recuperar el archivo?
Eliminación de un archivo con el explorador del área de trabajo	Sí, desde la carpeta Papelera
Descartar un nuevo archivo con el cuadro de diálogo de carpeta de Git	Sí, desde la carpeta Papelera
Descartar un archivo modificado con el cuadro de diálogo de carpeta de Git	No, el archivo se ha ido
reset (duro) para modificaciones de archivos no confirmadas	No, las modificaciones de archivos han desaparecido
reset (duro) para archivos no confirmados y recién creados	No, las modificaciones de archivos han desaparecido
Cambio de ramas con el cuadro de diálogo de carpeta de Git	Sí, desde el repositorio de Git remoto
Otras operaciones de Git, como confirmación o inserción, desde el cuadro de diálogo de carpeta de Git	Sí, desde el repositorio de Git remoto
PATCH operaciones de actualización /repos/id desde repos API	Sí, desde el repositorio de Git remoto

Compatibilidad con monorrepositorios

Databricks recomienda no crear carpetas de Git respaldadas por monorepos—repositorios de Git grandes y de una sola organización con miles de archivos en muchos proyectos.

Configuración

En esta sección se tratan las preguntas generales sobre el almacenamiento de carpetas de Git, la compatibilidad con el servidor y la configuración general.

Almacenamiento de contenido del repositorio

Azure Databricks clona temporalmente el contenido del repositorio en el disco del plano de control. La base de datos del plano de control almacena archivos de cuaderno como los del área de trabajo principal. Los archivos que no son de cuaderno se almacenan en disco durante un máximo de 30 días.

Servidores Git locales y autohospedados

Las carpetas de Git de Databricks admiten GitHub Enterprise, Bitbucket Server, Azure DevOps Server y GitLab Autoadministrado si el servidor es accesible a Internet. Consulte Servidor proxy de Git para carpetas de Git para la integración local.

Para integrarse con un servidor de Bitbucket, GitHub Enterprise Server o una instancia autoadministrada de GitLab que no sea accesible desde Internet, póngase en contacto con el equipo de la cuenta de Azure Databricks.

Tipos de activos admitidos

Para más información sobre los tipos de artefacto admitidos, consulte ¿Qué tipos de recursos son compatibles con las carpetas de Git?.

¿Las carpetas de Git admiten archivos .gitignore?

Sí. Para evitar que Git realice un seguimiento de un archivo, agregue el nombre de archivo (incluida la extensión) a un .gitignore archivo. Cree uno o use un archivo existente clonado desde el repositorio remoto.

.gitignore funciona solo para archivos sin seguimiento. Agregar un archivo de seguimiento ya a .gitignore no impide que Git lo realice.

Compatibilidad con submódulos de Git

Las carpetas de Git estándar no admiten submódulos de Git, pero las carpetas de Git con acceso a la CLI de Git pueden usarlas. Consulte Uso de comandos de la CLI de Git (Beta).

¿Admite Azure Data Factory (ADF) carpetas de Git?

Sí.

Administración de origen

En esta sección se tratan las bifurcaciones, la combinación y cómo las carpetas de Git controlan cuadernos y dependencias.

Paneles de control de notebooks y cambios de rama

Los cuadernos en formato fuente de Azure Databricks no almacenan información del cuadro de mando.

Para conservar los paneles, cambie el formato del cuaderno a .ipynb (formato Jupyter), que admite definiciones de panel y visualización de forma predeterminada. Para conservar los datos de visualización, confirme el cuaderno con salidas.

Consulte Gestionar las confirmaciones de salida del notebook IPYNB.

¿Las carpetas de Git admiten la combinación de ramas?

Sí. También puede crear una solicitud de incorporación de cambios y combinarlos mediante el proveedor de Git.

Eliminación de ramas

Para eliminar una rama, debe trabajar en el proveedor de Git.

Precedencia de dependencias de Python

Las bibliotecas de Python de una carpeta de Git tienen prioridad sobre las bibliotecas almacenadas en otro lugar. Por ejemplo, si una biblioteca está instalada en el proceso de Databricks y existe una biblioteca con el mismo nombre en una carpeta git, se importa la biblioteca de carpetas de Git. Consulte Precedencia de la biblioteca de Python.

Seguridad, autenticación y tokens

En esta sección se tratan los problemas de cifrado, almacenamiento de tokens y autenticación con proveedores de Git.

Problema con una directiva de acceso condicional (CAP) para Microsoft Entra ID

Es posible que reciba un error de "acceso denegado" al clonar un repositorio si:

• El área de trabajo de Azure Databricks utiliza Azure DevOps con la autenticación de ID de Microsoft Entra.
• Ha habilitado una directiva de acceso condicional en Azure DevOps y una directiva de acceso condicional de ID de Microsoft Entra.

Para resolverlo, agregue una exclusión a la directiva de acceso condicional (CAP) para las direcciones IP o los usuarios de Azure Databricks.

Para más información, consulte Directivas de acceso condicional.

Lista de permitidos con tokens de Id. de Microsoft Entra

Si usa el identificador de Entra de Microsoft para autenticarse con Azure DevOps, la lista de permitidos predeterminada restringe las direcciones URL de Git a:

• dev.azure.com
• visualstudio.com

Para obtener más información, consulte Permitir listas para restringir el uso del repositorio remoto.

Cifrado de carpetas de Git

Azure Databricks cifra el contenido de la carpeta git mediante una clave predeterminada. Las claves administradas por el cliente solo se admiten para cifrar las credenciales de Git.

Acceso y almacenamiento de tokens de GitHub

• El plano de control de Azure Databricks almacena tokens de autenticación. Los empleados solo pueden acceder a ellos a través de credenciales temporales auditadas.
• Azure Databricks registra la creación y eliminación de tokens, pero no el uso. El registro de operaciones de Git permite auditar el uso de tokens por parte de la aplicación de Azure Databricks.
• GitHub Enterprise audita el uso de tokens. Otros servicios de Git también pueden ofrecer auditoría de servidor.

¿Las carpetas de Git admiten la firma GPG de commits?

No.

¿Las carpetas de Git admiten SSH?

No. Las carpetas de Git solo admiten HTTPS.

Errores entre entidades de Azure DevOps

Al conectarse a DevOps en un inquilino independiente, es posible que vea Unable to parse credentials from Azure Active Directory account. Si el proyecto de Azure DevOps está en un inquilino de Azure Entra ID diferente al de Azure Databricks, use un token de acceso de Azure DevOps. Consulte Conexión a un repositorio de Azure DevOps mediante un token.

CI/CD y MLOps

En esta sección se explica cómo afectan las operaciones de Git al estado del cuaderno, los experimentos de MLflow y la ejecución de trabajos.

Los cambios entrantes borran el estado del cuaderno

Las operaciones de Git que modifican el código fuente del cuaderno provocan la pérdida del estado del cuaderno, incluidas las salidas de celda, los comentarios, el historial de versiones y los widgets. Por ejemplo, git pull puede cambiar el código fuente del cuaderno, lo que requiere carpetas de Git de Databricks para sobrescribir el cuaderno existente. Las operaciones como git commit, pusho la creación de una nueva rama no afectan al código fuente y conservan el estado del cuaderno.

Importante

Los experimentos de MLflow no funcionan en carpetas de Git con DBR 14.x o versiones anteriores.

Experimentos de MLflow en carpetas de Git

Hay dos tipos de experimentos de MLflow: de área de trabajo y de cuaderno. Consulte Organización de ejecuciones de entrenamiento con experimentos de MLflow.

• Experimentos de espacio de trabajo: no se pueden crear experimentos de MLflow en carpetas de Git. Log MLflow se ejecuta en un experimento creado en una carpeta de área de trabajo normal. Para la colaboración multiusuario, use una carpeta de área de trabajo compartida.

• Experimentos de cuadernos: puede crear experimentos de cuadernos en una carpeta de Git de Databricks. Si comprueba el cuaderno en el control de código fuente como un .ipynb archivo, MLflow ejecuta el registro en un experimento creado automáticamente. El control de código fuente no comprueba el experimento ni sus ejecuciones. Consulte Creación de un experimento de cuaderno.

Evitar la pérdida de datos en experimentos de MLflow

Los experimentos de MLflow creados a partir de cuadernos, utilizando trabajos de Lakeflow con código fuente en un repositorio remoto, se almacenan en almacenamiento temporal. Estos experimentos se conservan inicialmente después de la ejecución del flujo de trabajo, pero pueden eliminarse durante la limpieza programada. Databricks recomienda usar experimentos de MLflow del área de trabajo con trabajos y orígenes de Git remotos.

Advertencia

Cambiar a una rama que no contenga el cuaderno implica el riesgo de perder los datos del experimento de MLflow asociados. Esta pérdida se convierte en permanente si no tiene acceso a la rama anterior en un plazo de 30 días.

Para recuperar los datos del experimento que faltan antes de la expiración de 30 días, restaure el nombre del cuaderno original, abra el cuaderno y haga clic en en el panel derecho. Esto desencadena mlflow.get_experiment_by_name() y recupera el experimento y las ejecuciones. Después de 30 días, Azure Databricks purga experimentos huérfanos de MLflow para cumplir con el RGPD.

Para evitar la pérdida de datos, evite cambiar el nombre de los cuadernos en un repositorio. Si cambia el nombre de un cuaderno, haga clic inmediatamente en el icono del experimento en el panel derecho.

Ejecución de trabajos durante las operaciones de Git

Durante una operación de Git, es posible que algunos cuadernos se actualicen mientras que otros aún no lo hacen, lo que provoca un comportamiento imprevisible.

Por ejemplo, si notebook A llama a notebook Z mediante %run y un trabajo se inicia durante una operación de Git, el trabajo podría ejecutar la versión más reciente notebook A con una versión anterior notebook Z. Es posible que el trabajo produzca un error o ejecute cuadernos de confirmaciones diferentes.

Para evitar esto, configure las tareas de trabajo para que usen el proveedor de Git como origen en lugar de una ruta de acceso del área de trabajo. Consulte Uso de Git con trabajos.

Recursos

Para más información sobre los archivos de área de trabajo de Databricks, vea ¿Qué son los archivos de área de trabajo?.