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.

Vaya a:

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

Límites de archivos y repositorios

Azure Databricks no impone un límite sobre 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.

Databricks recomienda que en un repositorio:

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

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.

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:

Action	¿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 ha desaparecido
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 (Confirmar e insertar, etc.) 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

Los archivos eliminados de una carpeta de Git a través de operaciones de Git desde la interfaz de usuario del área de trabajo se pueden recuperar del historial de ramas remotas mediante la línea de comandos de Git (u otras herramientas de Git) si esos archivos se han confirmado e insertado previamente en el repositorio remoto. Las acciones del área de trabajo varían en la capacidad de recuperación de archivos. Algunas acciones permiten la recuperación a través de la papelera, mientras que otras no. Los archivos previamente confirmados e insertados en una rama remota se pueden restaurar a través del historial de confirmaciones de Git. En la tabla siguiente se describe el comportamiento y la capacidad de recuperación de cada acción:

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.

Tipos de recursos admitidos en carpetas de Git

Solo algunas carpetas Git admiten determinados tipos de recursos de Azure Databricks. Un tipo de recurso admitido se puede serializar, controlar la versión e insertarse en el repositorio de Git de respaldo.

Actualmente, los tipos de recursos admitidos son:

Tipo de recurso	Detalles
Archivo	Los archivos son datos serializados y pueden incluir cualquier cosa, desde bibliotecas a archivos binarios pasando por código o imágenes. Para obtener más información, consulte ¿Qué son los archivos del área de trabajo?
Cuaderno	Los cuadernos son específicamente los formatos de archivo de cuaderno que admite Databricks. Los cuadernos se consideran un tipo de recurso de Azure Databricks distinto de los archivos porque no están serializados. Las carpetas de Git determinan un cuaderno por la extensión de archivo (como .ipynb) o por extensiones de archivo combinadas con un marcador especial en el contenido del archivo (por ejemplo, un # Databricks notebook source comentario al principio de los archivos de .py origen).
Carpeta	Una carpeta es una estructura específica de Azure Databricks que representa información serializada sobre una agrupación lógica de archivos en Git. Como era de esperar, el usuario experimenta esto como una "carpeta" al ver una carpeta Git de Azure Databricks o acceder a ella con la CLI de Azure Databricks.

Los tipos de recursos de Azure Databricks que actualmente no se admiten en carpetas Git incluyen lo siguiente:

• Consultas DBSQL
• Alertas
• Paneles (incluidos los paneles heredados)
• Experimentos
• Espacios de Genie

Al trabajar con los recursos en Git, observe las siguientes limitaciones en la nomenclatura de archivos:

• Una carpeta no puede contener un cuaderno con el mismo nombre que otro cuaderno, archivo o carpeta en el mismo repositorio de Git, incluso si la extensión de archivo difiere. (En el caso de los cuadernos de formato de origen, la extensión es .py para Python, .scala para Scala, .sql para SQL y .r para R. En el caso de los cuadernos con formato IPYNB, la extensión es .ipynb). Por ejemplo, no puede usar un cuaderno con formato de origen llamado test1.py y un cuaderno IPYNB llamado test1 en la misma carpeta de Git porque el archivo del cuaderno Python con formato de origen (test1.py) se serializará como test1 y se producirá un conflicto.
• El carácter / no es compatible en los nombres de archivo. Por ejemplo, no puede tener un archivo denominado i/o.py en la carpeta Git.

Si intenta realizar operaciones Git en archivos que tienen nombres con estos patrones, obtendrá un mensaje de "Error al obtener el estado de Git". Si recibe este error inesperadamente, revise los nombres de archivo de los recursos en su repositorio de Git. Si encuentra archivos con nombres que tengan estos patrones conflictivos, cámbieles el nombre e intente de nuevo la operación.

Nota:

Puede mover los recursos no admitidos existentes a una carpeta Git, pero no puede volver a confirmar los cambios en estos recursos en el repositorio. No se pueden crear recursos no admitidos en una carpeta Git.

Formatos de cuaderno

Databricks considera dos tipos de formatos de cuaderno de alto nivel, específicos de Databricks: "source" e "ipynb". Cuando un usuario confirma un cuaderno en el formato "source", la plataforma de Azure Databricks confirma un archivo plano con un sufijo de idioma, como .py, .sql, .scalao .r. Un cuaderno con formato "source" solo contiene código fuente y no contiene salidas, como las visualizaciones y las pantallas de tabla, que son los resultados de ejecutar el cuaderno.

Sin embargo, el formato “ipynb” tiene salidas asociadas y esos artefactos se insertan automáticamente en el repositorio de Git que respalda la carpeta de Git al insertar el cuaderno .ipynb que los generó. Si desea confirmar salidas junto con el código, use el formato del cuaderno "ipynb" y configure la configuración para permitir que un usuario confirme las salidas generadas. Como resultado, “ipynb” también admite una mejor experiencia de visualización en Databricks para cuadernos insertados en repositorios de Git remotos a través de carpetas Git.

Formato source del cuaderno	Detalles
source	Puede ser cualquier archivo de código con un sufijo de archivo estándar que señale el lenguaje de código, como .py, .scala, .r y .sql. Los cuadernos “lsource” se tratan como archivos de texto y no incluirán ninguna salida asociada al confirmarse en un repositorio de Git.
ipynb	Los archivos “ipynb” terminan con .ipynb y pueden, si están configurados, insertar salidas (como visualizaciones) desde la carpeta de Git de Databricks al repositorio de Git de respaldo. Un cuaderno .ipnynb puede contener código en cualquier lenguaje admitido por los cuadernos de Databricks (a pesar de la parte py de .ipynb).

Si quiere que las salidas se vuelvan a insertar en el repositorio después de ejecutar un cuaderno, use un cuaderno .ipynb (Jupyter). Si solo desea ejecutar el cuaderno y administrarlo en Git, use un formato “source”, como .py.

Para más información sobre los formatos de cuaderno admitidos, consulte Exportación e importación de cuadernos de Databricks.

Nota:

¿Qué son las “salidas”?

Las salidas son los resultados de ejecutar un cuaderno en la plataforma de Databricks, incluidas las visualizaciones y las pantallas de tabla.

¿Cómo se indica el formato que usa un cuaderno, aparte de la extensión de archivo?

En la parte superior de un cuaderno administrado por Databricks, normalmente hay un comentario de una sola línea que indica el formato. Por ejemplo, para un cuaderno “source” .py, verá una línea similar a la siguiente:

# Databricks notebook source

Para archivos .ipynb, el sufijo de archivo se usa para indicar que es el formato del cuaderno “ipynb”.

Cuadernos de IPYNB en carpetas Git de Databricks

La compatibilidad con cuadernos de Jupyter Notebook (archivos .ipynb) está disponible en carpetas Git. Puede clonar repositorios con .ipynb cuadernos, trabajar con ellos en Azure Databricks y, a continuación, confirmarlos e insertarlos como .ipynb cuadernos. Los metadatos, como el panel del cuaderno, se conservan. Los administradores pueden controlar si las salidas se pueden confirmar o no.

Permitir confirmar la salida del cuaderno .ipynb

De forma predeterminada, la configuración de administrador de carpetas Git no permite confirmar la salida del cuaderno .ipynb. Los administradores de áreas de trabajo pueden cambiar esta configuración:

1. Vaya a Configuración de administración > Área de trabajo.

2. En Carpetas Git > Permitir que las carpetas Git exportan salidas IPYNB, seleccione Permitir: se pueden activar las salidas IPYNB en.

   

Importante

Cuando se incluyen salidas, las configuraciones de visualización y panel se conservan con el formato de archivo .ipynb.

Controlar commits de artefactos de salida del cuaderno IPYNB

Al confirmar un archivo .ipynb, Databricks crea un archivo de configuración que le permite controlar cómo confirma las salidas: .databricks/commit_outputs.

1. Si tiene un archivo de cuaderno .ipynb, pero no tiene ningún archivo de configuración en el repositorio, abra el modal Estado del Git.

2. En el cuadro de diálogo notificación, haga clic en Crear archivo commit_outputs.

   

También puede generar archivos de configuración desde el menú Archivo. El menú Archivo tiene un control que permite actualizar automáticamente el archivo de configuración para especificar la inclusión o exclusión de salidas de un cuaderno específico.

1. En el menú Archivo, seleccione Commit de salidas de cuadernos.

   

2. En el cuadro de diálogo, confirme su elección para hacer "commit" en las salidas del cuaderno.

   

Conversión de un cuaderno de origen en IPYNB

Puede convertir un cuaderno de origen existente en una carpeta de Git en un cuaderno IPYNB a través de la interfaz de usuario de Azure Databricks.

1. Abra un cuaderno de código fuente en el área de trabajo.

2. Seleccione Archivo en el menú del área de trabajo y, a continuación, seleccione Cambiar formato de cuaderno [origen]. Si el cuaderno ya está en formato IPYNB, [source] será [ipynb] en el elemento de menú.

   

3. En el cuadro de diálogo modal, seleccione "Formato de cuaderno Jupyter (.ipynb)" y haga clic en Cambiar.

   

También puede:

• Cree nuevos .ipynb cuadernos.
• Ver diferencias como diferencias de código (cambios de código en celdas) o sin formato (los cambios de código se presentan como sintaxis JSON, que incluye salidas de cuaderno como metadatos).

Para obtener información sobre los tipos de cuadernos admitidos en Azure Databricks, lea Exportación e importación de cuadernos de Databricks.

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 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 Tipos de recursos admitidos en 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 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

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 trabajos 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 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 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 obtener 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?.