Límites y preguntas más frecuentes sobre la integración de Git con carpetas de Git de Databricks

Las carpetas de Git de Databricks y la integración de Git tienen límites especificados en las secciones siguientes. Para información general, consulte Límites de Databricks.

Vaya a:

• Límites de archivos y repositorios
• Preguntas más frecuentes: Configuración de carpetas de Git

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 de un repositorio. Pero:

• Las ramas de trabajo están limitadas a 1 gigabyte (GB).
• Los archivos de más de 10 MB no se pueden ver en la interfaz de usuario de Azure Databricks.
• Los archivos de área de trabajo individuales están sujetos a un límite de tamaño independiente. Para más información, lea Limitaciones.
• La versión local de una rama puede permanecer presente en la carpeta Git asociada durante hasta 30 días después de eliminar la rama remota. Para quitar completamente una rama local en una carpeta de Git, elimine el repositorio.

Databricks recomienda que en un repositorio:

• El número total de recursos y archivos del área de trabajo no supera los 20 000.

Para cualquier operación de Git, el uso de memoria se limita a 2 GB y las escrituras de disco se limitan a 4 GB. Dado que el límite es por operación, obtendrá un error si intenta clonar un repositorio de Git con un tamaño de 5 GB. Pero si clona un repositorio de Git con un tamaño de 3 GB en una operación y, después, le agrega 2 GB más adelante, la siguiente operación de extracción se realizará correctamente.

Si el repositorio supera estos límites, es posible que reciba un mensaje de error. También puede recibir un error de tiempo de espera al clonar el repositorio, aunque la operación todavía se complete en segundo plano.

Para trabajar con un repositorio que exceda los límites de tamaño, pruebe sparse checkout.

Si debe escribir archivos temporales que no quiera conservar después de apagar el clúster, escribiendo los archivos temporales en $TEMPDIR se evita superar los límites de tamaño de rama y se obtiene un mejor rendimiento que al escribir en un directorio de trabajo (CWD) en el sistema de archivos del área de trabajo. Para más información, consulte ¿Dónde debo escribir archivos temporales en Azure Databricks?.

Recuperación de archivos eliminados de carpetas de Git en el área de trabajo

Las acciones del área de trabajo en las carpetas de Git varían en la capacidad de recuperación de archivos. 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 para el repositorio de Git remoto. En esta tabla se describe el comportamiento y la capacidad de recuperación de cada acción:

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. Un monorepo es un gran repositorio Git de una sola organización con miles de archivos a lo largo de muchos proyectos.

Preguntas más frecuentes: Configuración de carpetas de Git

¿Dónde se almacena el contenido del repositorio de Azure Databricks?

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

¿Las carpetas de Git admiten servidores Git locales o autohospedados?

Las carpetas de Git de Databricks admiten GitHub Enterprise, Bitbucket Server, Azure DevOps Server y la integración autoadministrada de GitLab, si el servidor es accesible a Internet. Para más información sobre la integración de carpetas de Git con un servidor git local, lea Servidor proxy de Git para carpetas de Git.

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

¿Qué tipos de recursos de Databricks son compatibles con las carpetas de Git?

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í. Si agrega un archivo al repositorio y no quiere que Git realice su seguimiento, cree un archivo .gitignore o use uno clonado desde el repositorio remoto y agregue el nombre de archivo, incluida la extensión.

.gitignore funciona solo para los archivos que Git aún no ha realizado el seguimiento. Si agrega un archivo que ya ha realizado un seguimiento de Git a un .gitignore archivo, Git sigue realizando el seguimiento del archivo.

¿Las carpetas de Git admiten submódulos de Git?

No. Puede clonar un repositorio que contenga submódulos de Git, pero el submódulo no se clona.

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

Sí.

Administración de origen

¿Por qué los paneles del cuaderno desaparecen cuando extraigo del repositorio una rama distinta o incorporo cambios a esta?

Esto es una limitación porque los cuadernos de formato de origen de Azure Databricks no almacenan información del panel del notebook.

Para conservar los paneles en el repositorio de Git, cambie el formato del cuaderno a .ipynb (el formato del cuaderno de Jupyter Notebook). De forma predeterminada, .ipynb admite definiciones de panel y visualización. Para conservar los datos de visualización, debe confirmar el cuaderno con resultados.

Para obtener información sobre cómo confirmar .ipynb las salidas de los cuadernos, consulte Gestionar las confirmaciones de salidas de cuadernos 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.

¿Puedo eliminar una rama de un repositorio de Azure Databricks?

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

¿Cuál es el orden de precedencia cuando las dependencias de Python se incluyen en las carpetas de Git?

Las bibliotecas de Python almacenadas en una carpeta de Git tienen prioridad sobre las bibliotecas almacenadas en otro lugar. Por ejemplo, si una biblioteca está instalada en Databricks, y una biblioteca con el mismo nombre está incluida en una carpeta de Git, se importa la biblioteca de la carpeta Git. Para obtener más información sobre la precedencia de biblioteca en Python, consulte prioridad de la biblioteca de Python.

Seguridad, autenticación y tokens

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

Al intentar clonar un repositorio, es posible que reciba un mensaje de error "acceso denegado" cuando:

• Azure Databricks está configurado para usar Azure DevOps con la autenticación de Microsoft Entra ID.
• Ha habilitado una directiva de acceso condicional en Azure DevOps y una directiva de acceso condicional de Microsoft Entra ID.

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

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

Lista de autorizados con tokens de Microsoft Entra ID

Si usa el identificador de Microsoft Entra 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.

¿El contenido de las carpetas de Git de Azure Databricks está cifrada?

Azure Databricks cifra el contenido de las carpetas de Git de Azure Databricks mediante una clave predeterminada. No se admite el cifrado mediante claves administradas por el cliente, excepto al cifrar las credenciales de Git.

¿Cómo y dónde se almacenan los tokens de GitHub en Azure Databricks? ¿Quién tendría acceso desde Azure Databricks?

• Los tokens de autenticación se almacenan en el plano de control de Azure Databricks, y un empleado de Azure Databricks solo puede obtener acceso mediante una credencial temporal auditada.
• Azure Databricks registra la creación y eliminación de estos tokens, pero no su uso. Azure Databricks tiene un registro que rastrea las operaciones de Git que puede utilizarse para auditar el uso de los tokens por parte de la aplicación Azure Databricks.
• La empresa GitHub audita el uso de tokens. Otros servicios de Git también pueden tener auditoría de servidor de Git.

¿Las carpetas de Git admiten la firma gpG de confirmaciones?

No.

¿Las carpetas de Git admiten operaciones de Git mediante SSH?

No, solo se admite el HTTPS protocolo.

Error al conectar Azure Databricks a un repositorio de Azure DevOps en un inquilino diferente

Al intentar conectarse a DevOps en un inquilino independiente, es posible que reciba el mensaje Unable to parse credentials from Azure Active Directory account. Si el proyecto de Azure DevOps está en una entidad de Microsoft Entra ID diferente de Azure Databricks, debe usar un token de acceso de Azure DevOps. Consulte Conexión a Azure DevOps mediante un token de DevOps.

CI/CD y MLOps

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 de un cuaderno. En este caso, las carpetas de Git de Databricks deben sobrescribir el cuaderno existente para importar los cambios. git commit y push o la creación de una nueva rama no afecta al código fuente del cuaderno, por lo que el estado del cuaderno se conserva en estas operaciones.

Importante

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

¿Puedo crear un experimento de MLflow en una carpeta git?

Hay dos tipos de experimentos de MLflow: de área de trabajo y de cuaderno. Para obtener detalles sobre los dos tipos de experimentos de MLflow, vea Organización de ejecuciones de entrenamiento con experimentos de MLflow.

• Experimentos de espacio de trabajo: no se pueden crear experimentos de MLflow de espacio de trabajo en carpetas de Git. En su lugar, registre las ejecuciones de MLflow en un experimento de MLflow creado en una carpeta habitual del área de trabajo. Si varios usuarios utilizan carpetas de Git independientes para colaborar en el mismo código, registren las ejecuciones de MLflow en un experimento de MLflow creado en una carpeta de espacio de trabajo compartido.

• Experimentos de cuadernos: puede crear experimentos de cuadernos en una carpeta de Git de Databricks. Si registra el cuaderno en el control de código fuente como un archivo .ipynb, puede registrar ejecuciones de MLflow en un experimento de MLflow creado y asociado automáticamente. Sin embargo, el experimento y las ejecuciones asociadas no están consignados en el control de código fuente. Para más información, consulte Creación de experimentos de cuadernos.

Evitar la pérdida de datos en experimentos de MLflow

Los experimentos de cuadernos de MLflow creados usando trabajos de Lakeflow con código fuente en un repositorio remoto se almacenan en una ubicación de almacenamiento temporal. Estos experimentos se conservan inicialmente después de la ejecución del flujo de trabajo, pero corren el riesgo de eliminarlos más adelante durante la eliminación programada de archivos en el almacenamiento temporal. Databricks recomienda usar experimentos de MLflow del área de trabajo con trabajos y orígenes de Git remotos.

Advertencia

Cada vez que cambie a una rama que no contenga el cuaderno, corre el riesgo de perder los datos del experimento de MLflow asociados. Esta pérdida se convierte en permanente si no se 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, cambie el nombre del cuaderno al nombre original, abra el cuaderno y haga clic en en el panel derecho, que desencadena una llamada a la mlflow.get_experiment_by_name() función. Cuando la función regresa, puede ver el experimento recuperado y las ejecuciones. Después de 30 días, los experimentos huérfanos de MLflow se purgarán para cumplir las directivas de cumplimiento del RGPD.

Para evitar esta situación, Databricks recomienda no cambiar el nombre de los cuadernos en un repositorio. Si cambia el nombre de un cuaderno, haga clic en el icono "experimento" en el panel derecho inmediatamente después de cambiar el nombre del cuaderno.

¿Qué ocurre si un trabajo de cuaderno se ejecuta en un área de trabajo mientras hay una operación de Git en curso?

En cualquier momento en que una operación de Git esté en curso, es posible que algunos cuadernos del repositorio se hayan actualizado mientras que otros no. Esto puede provocar un comportamiento impredecible.

Por ejemplo, suponga notebook A llamadas notebook Zusando un %run comando. Si un trabajo que se ejecuta durante una operación de Git inicia la versión más reciente de notebook A, pero notebook Z aún no se ha actualizado, el %run comando de notebook A podría iniciar la versión anterior de notebook Z. Durante la operación de Git, los estados del cuaderno no son predecibles y el trabajo podría producir errores o ejecutarse notebook A y notebook Z desde confirmaciones diferentes.

Para evitar esta situación, configure las tareas de trabajo para que usen el proveedor de Git como origen y no como ruta de acceso del área de trabajo. Para más información, 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?.