Límites y preguntas 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.

Límites de tamaño de archivo y repositorio

Azure Databricks no impone un límite sobre el tamaño de un repositorio. Pero:

• Las ramas de trabajo están limitadas a 500 megabytes (MB).
• 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.

Databricks recomienda que en un repositorio:

• El número total de todos los archivos no supere los 10 000.
• El número total de blocs de cuadernos no supere los 5000.

Para cualquier operación de Git, el uso de memoria está limitado a 2 GB y las escrituras en disco están limitadas a 4 GB. Como el límite es por cada operación, se producirá un error si intenta clonar un repositorio de Git con un tamaño actual 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 su repo supera estos límites, puede recibir un mensaje de error. También puede recibir un error de tiempo de espera cuando clone el repositorio, pero la operación podría completarse en segundo plano.

Para trabajar con un repositorio que supera los límites de tamaño, pruebe la desprotección dispersa.

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

Número máximo de carpetas de Git por área de trabajo

Puede tener un máximo de 2 000 carpetas de Git por área de trabajo. Si necesita más, póngase en contacto con el soporte técnico de Databricks.

Compatibilidad con monorrepositorios

Databricks recomienda no crear carpetas de Git respaldadas por monorepos, donde un monorepo es un repositorio Git de gran tamaño y de una sola organización con muchos miles de archivos en muchos proyectos.

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 obtener más información sobre cómo integrar carpetas de Git con un servidor Git local, lea Servidor proxy de Git para carpetas de Git.

Para integrarse con Bitbucket Server, GitHub Enterprise Server o una instancia de suscripción autoadministrada de GitLab que no sea accesible desde Internet, póngase en contacto con su representante 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 recursos admitidos, lea Administración de recursos de archivos en carpetas de Git de Databricks.

¿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 solo funciona para archivos de los que Git aún no ha realizado el seguimiento. Si agrega un archivo del que Git ya hace el seguimiento a un archivo .gitignore, Git continúa haciendo el seguimiento del archivo.

¿Puedo crear carpetas de nivel superior que no sean carpetas de usuario?

Sí, los administradores pueden crear carpetas de nivel superior en un solo nivel. Las carpetas de Git no admiten niveles de carpetas adicionales.

¿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 actualmente una limitación porque los archivos fuente de cuaderno de Azure Databricks no almacenan la información del panel del cuaderno.

Si desea 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. Si desea conservar los datos del grafo (puntos de datos), debe confirmar el cuaderno con salidas.

Para obtener más información sobre la consignación de .ipynbsalidas de cuaderno, consulte Permitir la consignación de .ipynbsalidas de cuaderno .

¿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.

Si una biblioteca está instalada en un clúster y una biblioteca con el mismo nombre se incluye en una carpeta dentro de un repositorio, ¿qué biblioteca se importa?

Se importa la biblioteca del repositorio. Para obtener más información sobre la precedencia de biblioteca en Python, consulte prioridad de la biblioteca de Python.

¿Puedo extraer la versión más reciente de un repositorio de Git antes de ejecutar un trabajo sin depender de una herramienta de orquestación externa?

No. Normalmente, puede integrar esta operación como una confirmación previa en el servidor de Git de forma que cada envío de cambios a una rama (main/prod) actualice el repositorio de producción.

¿Puedo exportar un repositorio?

Puede exportar cuadernos, carpetas o un repositorio completo. No puedes exportar archivos que no son de cuaderno. Si exportas un repositorio completo, no se incluyen los archivos que no son de cuaderno. Para exportar, usa el comando workspace export en la CLI de Databricks o usa la API del área de trabajo.

Seguridad, autenticación y tokens

Problema con una directiva de acceso condicional (CAP) para Microsoft Entra ID (anteriormente Azure Active Directory)

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 permitidos con tokens de Azure AD

Si usa Azure Active Directory (AAD) 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 SSH?

No, solo HTTPS.

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 Azure DevOps se encuentra en un inquilino de Microsoft Entra ID diferente de Azure Databricks, es necesario 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 afectan 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 MLflow en un repo?

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.

En las carpetas de Git, puede llamar a mlflow.set_experiment("/path/to/experiment") para un experimento de MLflow de cualquier tipo y ejecutar el registro, pero ese experimento y las ejecuciones asociadas no se comprobarán en el control de código fuente.

Experimentos de MLflow de área de trabajo

No se pueden crear experimentos de MLflow de área de trabajo en una carpeta Git de Databricks (carpeta Git). Si varios usuarios utilizan carpetas de Git independientes para colaborar en el mismo código de ML, registre las ejecuciones de MLflow en un experimento de MLflow creado en una carpeta de área de trabajo normal.

Experimentos de MLflow de cuaderno

Puede crear experimentos de cuaderno 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. Para más información, vea Creación de experimentos de cuadernos.

Evitar la pérdida de datos en experimentos de MLflow

Los experimentos de Notebook MLflow creados mediante Flujos de trabajo de Databricks 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 flujos de trabajo 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 accede 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, haga clic en el icono del "experimento" en el panel de la derecha (lo que también llama a la API mlflow.get_experiment_by_name()) y podrá 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 los repositorios o, si cambia el nombre de un cuaderno, haga clic en el icono del "experimento" en el panel lateral derecho inmediatamente después del cambio de nombre.

¿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 mientras 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 Git inicia la versión más reciente de notebook A, pero notebook Zaún no se ha actualizado, el comando del cuaderno A %run podría iniciar la versión más antigua de notebook Z. Durante la operación de Git, los estados del cuaderno no son predecibles y el trabajo podría producir un error o ejecutar notebook A y notebook Z desde diferentes confirmaciones.

Para evitar esta situación, use trabajos basados en Git (donde el origen es un proveedor de Git y no una ruta de acceso del área de trabajo). Para más información, vea Uso de código fuente controlado por versiones en un trabajo de Azure Databricks.

Recursos

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