Procedimientos recomendados y flujos de trabajo de CI/CD recomendados en Databricks

CI/CD (integración continua y entrega continua) se ha convertido en una piedra angular de la ingeniería y el análisis de datos modernos, ya que garantiza que los cambios de código se integren, prueben e implementen de forma rápida y confiable. Databricks reconoce que puede tener diversos requisitos de CI/CD conformados por sus preferencias organizativas, flujos de trabajo existentes y entornos de tecnología específicos, y proporciona un marco flexible que admite varias opciones de CI/CD.

En esta página se describen los procedimientos recomendados para ayudarle a diseñar y crear canalizaciones de CI/CD sólidas y personalizadas que se adapten a sus necesidades y restricciones únicas. Al aprovechar estas conclusiones, puede acelerar las iniciativas de análisis e ingeniería de datos, mejorar la calidad del código y reducir el riesgo de errores de implementación.

Principios básicos de CI/CD

Las canalizaciones de CI/CD eficaces comparten principios fundamentales independientemente de los detalles de la implementación. Los siguientes procedimientos recomendados universales se aplican en las preferencias organizativas, los flujos de trabajo de desarrollador y los entornos en la nube, y garantizan la coherencia en diversas implementaciones, ya sea que su equipo priorice el desarrollo basado en notebooks o los flujos de trabajo de infraestructura como código. Adopte estos principios como barreras de protección a la vez que adapte los detalles a la pila y los procesos tecnológicos de su organización.

• Controle todo con versiones
  • Almacene cuadernos, scripts, definiciones de infraestructura (IaC) y configuraciones de trabajo en Git.
  • Use estrategias de bifurcación, como Gitflow, que están alineadas con los entornos de implementación de desarrollo, almacenamiento provisional y producción estándar.
• Automatización de pruebas
  • Implemente pruebas unitarias para lógica de negocios mediante bibliotecas, como pytest para Python y ScalaTest para Scala .
  • Valide la funcionalidad de cuadernos y flujos de trabajo con herramientas, como la validación del conjunto de la CLI de Databricks.
  • Use pruebas de integración para flujos de trabajo y canalizaciones de datos, como Spark DataFrames.
• Emplear infraestructura como código (IaC)
  • Defina clústeres, trabajos y configuraciones de área de trabajo con Databricks Asset Bundles YAML o Terraform.
  • Parametrizar en lugar de codificar la configuración específica del entorno, como el tamaño del clúster y los secretos.
• Aislar entornos
  • Mantenga áreas de trabajo independientes para el desarrollo, el almacenamiento provisional y la producción.
  • Use el Registro de modelos de MLflow para el control de versiones de modelos entre entornos.
• Elija herramientas que coincidan con el ecosistema de la nube:
  • Azure: Azure DevOps y Databricks Asset Bundles o Terraform.
  • AWS: Acciones de GitHub y Conjuntos de recursos de Databricks o Terraform.
  • GCP: Cloud Build y Databricks Asset Bundles o Terraform.
• Supervisión y automatización de reversiones
  • Realice un seguimiento de las tasas de éxito de implementación, el rendimiento del trabajo y la cobertura de pruebas.
  • Implemente mecanismos de reversión automatizados para implementaciones con errores.
• Unificar la administración de recursos
  • Use Conjuntos de recursos de Databricks para implementar código, trabajos e infraestructura como una sola unidad. Evite la gestión aislada de cuadernos, bibliotecas y flujos de trabajo.

Note

Databricks recomienda la federación de identidades de tareas para la autenticación de CI/CD. La federación de identidades de carga de trabajo elimina la necesidad de secretos de Databricks, lo que hace que sea la forma más segura de autenticar los flujos automatizados en Databricks. Consulte Activar la federación de identidades de trabajo en CI/CD.

Conjuntos de recursos de Databricks para CI/CD

Los conjuntos de recursos de Databricks ofrecen un enfoque eficaz y unificado para administrar código, flujos de trabajo e infraestructura dentro del ecosistema de Databricks y se recomiendan para las canalizaciones de CI/CD. Al agrupar estos elementos en una sola unidad definida por YAML, los paquetes simplifican la implementación y garantizan la coherencia entre entornos. Sin embargo, para los usuarios acostumbrados a los flujos de trabajo tradicionales de CI/CD, la adopción de paquetes puede requerir un cambio de mentalidad.

Por ejemplo, los desarrolladores de Java se usan para compilar JAR con Maven o Gradle, ejecutar pruebas unitarias con JUnit e integrar estos pasos en canalizaciones de CI/CD. Del mismo modo, los desarrolladores de Python suelen empaquetar código en ruedas y probar con pytest, mientras que los desarrolladores de SQL se centran en la validación de consultas y la administración de cuadernos. Con las agrupaciones, estos flujos de trabajo convergen en un formato más estructurado y prescriptivo, lo que hace hincapié en la agrupación de código e infraestructura para una implementación sin problemas.

En las secciones siguientes se explora cómo los desarrolladores pueden adaptar sus flujos de trabajo para aprovechar los conjuntos de forma eficaz.

Para empezar rápidamente a trabajar con conjuntos de recursos de Databricks, pruebe un tutorial: Desarrollar un trabajo con conjuntos de recursos de Databricks o Desarrollar canalizaciones declarativas de Spark de Lakeflow con conjuntos de recursos de Databricks.

Recomendaciones de control de código fuente de CI/CD

La primera opción que los desarrolladores deben realizar al implementar CI/CD es cómo almacenar y versionar archivos de origen. Las agrupaciones permiten contener fácilmente todo ( código fuente, artefactos de compilación y archivos de configuración) y localizarlos en el mismo repositorio de código fuente, pero otra opción es separar los archivos de configuración de agrupación de archivos relacionados con el código. La elección depende del flujo de trabajo del equipo, la complejidad del proyecto y los requisitos de CI/CD, pero Databricks recomienda lo siguiente:

• Para proyectos pequeños o para un acoplamiento fuerte entre el código y la configuración, use un único repositorio tanto para el código como para la configuración del paquete, y así simplificar los flujos de trabajo.
• Para equipos más grandes o ciclos de versión independientes, use repositorios independientes para la configuración de paquetes y código, pero establezca canalizaciones de CI/CD claras que garantizan la compatibilidad entre versiones.

Independientemente de si decide buscar o separar los archivos relacionados con el código de los archivos de configuración de agrupación, use siempre artefactos con versiones, como hashes de confirmación de Git, al cargar en Databricks o en almacenamiento externo para garantizar la rastreabilidad y las funcionalidades de reversión.

Repositorio único para código y configuración

En este enfoque, tanto el código fuente como los archivos de configuración de agrupación se almacenan en el mismo repositorio. Esto simplifica los flujos de trabajo y garantiza cambios atómicos.

Pros	Cons
Todas las configuraciones relacionadas de artefactos, código y YAML se versionan juntas, lo que reduce la sobrecarga de coordinación. Una única solicitud de incorporación de cambios puede actualizar el archivo de compilación compilado y su configuración de agrupación correspondiente. La tubería de CI/CD puede compilar, probar, validar e implementar desde un solo repositorio.	Con el tiempo, el repositorio puede estar sobredimensionado tanto con archivos de código como de configuración. Los cambios de código y de paquete requieren una versión coordinada.

Ejemplo: código de Python en un paquete

En este ejemplo se incluyen archivos de Python y archivos de agrupación en un repositorio:

databricks-dab-repo/
├── databricks.yml               # Bundle definition
├── resources/
│   ├── workflows/
│   │   ├── my_pipeline.yml      # YAML pipeline def
│   │   └── my_pipeline_job.yml  # YAML job def that runs pipeline
│   ├── clusters/
│   │   ├── dev_cluster.yml      # development cluster def
│   │   └── prod_cluster.yml     # production def
├── src/
│   ├── my_pipeline.ipynb       # pipeline notebook
│   └── mypython.py              # Additional Python
└── README.md

Repositorios independientes para el código y la configuración

En este enfoque, el código fuente reside en un repositorio, mientras que los archivos de configuración de agrupación se mantienen en otro. Esta opción es ideal para equipos o proyectos más grandes en los que los grupos independientes controlan el desarrollo de aplicaciones y la administración de flujos de trabajo de Databricks.

Pros	Cons
Los equipos que trabajan en el desarrollo de código pueden centrarse en su repositorio mientras el equipo de ingeniería de datos administra las configuraciones de agrupación. Permite actualizaciones de versiones independientes y control de versiones en el código compilado, como JAR, y configuraciones de agrupación sin acoplarlos. Cada repositorio es más pequeño y fácil de administrar.	Requiere coordinación adicional entre repositorios durante la implementación. Debe asegurarse de que se hace referencia a la versión correcta de las dependencias, como la versión JAR, en el repositorio de paquetes.

Ejemplo: proyecto y agrupación de Java

En este ejemplo, un proyecto de Java y sus archivos están en un repositorio y los archivos de agrupación están en otro repositorio.

Repositorio 1: archivos java

El primer repositorio contiene todos los archivos relacionados con Java:

java-app-repo/
├── pom.xml                  # Maven build configuration
├── src/
│   ├── main/
│   │   ├── java/            # Java source code
│   │   │   └── com/
│   │   │       └── mycompany/
│   │   │           └── app/
│   │   │               └── App.java
│   │   └── resources/       # Application resources
│   └── test/
│       ├── java/            # Unit tests for Java code
│       │   └── com/
│       │       └── mycompany/
│       │           └── app/
│       │               └── AppTest.java
│       └── resources/       # Test-specific resources
├── target/                  # Compiled JARs and classes
└── README.md

• Los desarrolladores escriben código de aplicación en src/main/java o src/main/scala.
• Las pruebas unitarias se almacenan en src/test/java o src/test/scala.
• En una solicitud de incorporación de cambios o confirmación, canalizaciones de CI/CD:
  • Compile el código en un archivo JAR, por ejemplo, target/my-app-1.0.jar.
  • Cargue el archivo JAR en un volumen del Catálogo Unity de Databricks. Consulte carga de JAR.

Repositorio 2: Archivos de paquete

Un segundo repositorio contiene solo los archivos de configuración de agrupación:

databricks-dab-repo/
├── databricks.yml               # Bundle definition
├── resources/
│   ├── jobs/
│   │   ├── my_java_job.yml  # YAML job dev
│   │   └── my_other_job.yml # Additional job definitions
│   ├── clusters/
│   │   ├── dev_cluster.yml  # development cluster def
│   │   └── prod_cluster.yml # production def
└── README.md

• La configuración de agrupación databricks.yml y las definiciones de trabajo se mantienen de forma independiente.

• El databricks.yml hace referencia al artefacto JAR cargado, por ejemplo:

  - jar: /Volumes/artifacts/my-app-${{ GIT_SHA }}.)jar
  

Flujo de trabajo de CI/CD recomendado

Independientemente de si está localizando o separando los archivos de código de los archivos de configuración de agrupación, un flujo de trabajo recomendado sería el siguiente:

1. Compilar y probar el código

   • Se activa en una solicitud de incorporación de cambios o una confirmación en la rama principal.
   • Compile código y ejecute pruebas unitarias.
   • Genera un archivo con versiones, por ejemplo, my-app-1.0.jar.

2. Cargue y almacene el archivo compilado, como un archivo JAR, en un volumen de catálogo de Unity de Databricks.

   • Almacene el archivo compilado en un volumen del catálogo de Unity de Databricks o en un repositorio de artefactos como AWS S3 o Azure Blob Storage.
   • Use un esquema de control de versiones asociado a hashes de confirmación de Git o control de versiones semánticos, por ejemplo, dbfs:/mnt/artifacts/my-app-${{ github.sha }}.jar.

3. Valida el paquete

   • Ejecute databricks bundle validate para asegurarse de que la databricks.yml configuración es correcta.
   • Este paso garantiza que las configuraciones incorrectas, por ejemplo, las bibliotecas que faltan, se detectan al principio.

4. Desplegar el paquete

   • Usar databricks bundle deploy para desplegar el paquete en un entorno de ensayo o producción.
   • Consulte la biblioteca compilada cargada en databricks.yml. Para obtener información sobre cómo hacer referencia a bibliotecas, consulte Dependencias de la biblioteca de Conjuntos de recursos de Databricks.

CI/CD para el aprendizaje automático

Los proyectos de aprendizaje automático presentan desafíos únicos de CI/CD en comparación con el desarrollo de software tradicional. Al implementar CI/CD para proyectos de ML, es probable que tenga que tener en cuenta lo siguiente:

• Coordinación con varios equipos: los científicos de datos, los ingenieros y los equipos de MLOps suelen usar diferentes herramientas y flujos de trabajo. Databricks unifica estos procesos con MLflow para el seguimiento de experimentos, el uso compartido de Delta para la gobernanza de datos y los conjuntos de recursos de Databricks para infraestructura como código.
• Control de versiones de datos y modelos: las canalizaciones de ML requieren seguimiento no solo de código, sino también de esquemas de datos de entrenamiento, distribuciones de características y artefactos de modelo. Databricks Delta Lake proporciona transacciones ACID y viajes de tiempo para el control de versiones de datos, mientras que el Registro de modelos de MLflow controla el linaje del modelo.
• Reproducibilidad entre entornos: los modelos de ML dependen de combinaciones específicas de datos, código e infraestructura. Los conjuntos de recursos de Databricks garantizan la implementación atómica de estos componentes en entornos de desarrollo, ensayo y producción con definiciones de YAML.
• Reentrenamiento continuo y supervisión: los modelos se degradan debido al desfase de datos. Los trabajos de Lakeflow permiten canalizaciones de reentrenamiento automatizadas, mientras que MLflow se integra con Prometheus y Databricks Data Quality Monitoring para el seguimiento del rendimiento.

Pilas de MLOps para CI/CD de ML

Databricks aborda la complejidad de CI/CD de ML a través de MLOps Stacks, un marco de trabajo de nivel de producción que combina conjuntos de recursos de Databricks, flujos de trabajo de CI/CD preconfigurados y plantillas de proyecto modulares de ML. Estas pilas aplican procedimientos recomendados a la vez que permiten flexibilidad para la colaboración de varios equipos en los roles de ingeniería de datos, ciencia de datos y MLOps.

Team	Responsibilities	Ejemplo de componentes del paquete	Artefactos de ejemplo
Ingenieros de datos	Construir canalizaciones ETL, garantizar la calidad de los datos	Canalizaciones declarativas de Spark de Lakeflow en YAML, políticas de clúster	etl_pipeline.yml, feature_store_job.yml
Científicos de datos	Desarrollo de lógica de entrenamiento de modelos, validación de métricas	Proyectos de MLflow, flujos de trabajo basados en cuadernos	train_model.yml, batch_inference_job.yml
Ingenieros de MLOps	Orquestación de implementaciones, supervisión de canalizaciones	Variables de entorno, paneles de supervisión	databricks.yml, lakehouse_monitoring.yml

La colaboración de CI/CD de ML podría ser similar a la siguiente:

• Los ingenieros de datos realizan los cambios de canalización de ETL en un paquete, lo que desencadena la validación automatizada de esquemas y una implementación de ensayo.
• Los científicos de datos envían código de ML, que ejecutan pruebas unitarias e implementan en un área de trabajo de ensayo para las pruebas de integración.
• Los ingenieros de MLOps revisan las métricas de validación y promueven modelos examinados a producción mediante el Registro de MLflow.

Para obtener más información sobre la implementación, consulte:

• Paquete de mlOps Stacks: guía paso a paso para la inicialización e implementación de paquetes.
• Repositorio de GitHub de MLOps Stacks: plantillas preconfiguradas para entrenamiento, inferencia y CI/CD.

Al alinear equipos con paquetes estandarizados y pilas de MLOps, las organizaciones pueden simplificar la colaboración al tiempo que mantienen la auditabilidad en todo el ciclo de vida del aprendizaje automático.

CI/CD para desarrolladores de SQL

Los desarrolladores de SQL que usan Databricks SQL para administrar tablas de streaming y vistas materializadas pueden aprovechar la integración de Git y las canalizaciones de CI/CD para simplificar sus flujos de trabajo y mantener canalizaciones de alta calidad. Con la introducción de la compatibilidad de Git con las consultas, los desarrolladores de SQL pueden centrarse en escribir consultas al tiempo que aprovechan Git para controlar las versiones de sus .sql archivos, lo que permite la colaboración y automatización sin necesidad de conocimientos profundos sobre la infraestructura. Además, el editor de SQL permite la colaboración en tiempo real y se integra sin problemas con los flujos de trabajo de Git.

Para flujos de trabajo centrados en SQL:

• Archivos SQL de control de versiones

  • Almacene archivos .sql en repositorios de Git mediante carpetas de Git de Databricks o proveedores de Git externos, por ejemplo, GitHub, Azure DevOps.
  • Use ramas (por ejemplo, desarrollo, ensayo, producción) para administrar cambios específicos del entorno.

• Integre archivos .sql en canalizaciones de CI/CD para automatizar la implementación:

  • Valide los cambios de sintaxis y esquema durante las solicitudes de incorporación de cambios.
  • Implemente archivos .sql en flujos de trabajo o trabajos de SQL de Databricks.

• Definición de parámetros para el aislamiento del entorno

  • Use variables en .sql archivos para hacer referencia dinámicamente a recursos específicos del entorno, como rutas de acceso de datos o nombres de tabla:

    CREATE OR REFRESH STREAMING TABLE ${env}_sales_ingest AS SELECT * FROM read_files('s3://${env}-sales-data')
    

• Programar y supervisar actualizaciones

  • Use tareas SQL en un trabajo de Databricks para programar actualizaciones en tablas y vistas materializadas (REFRESH MATERIALIZED VIEW view_name).
  • Supervise el historial de actualizaciones mediante tablas del sistema.

Un flujo de trabajo podría ser:

1. Desarrollo: escriba y pruebe los scripts .sql localmente o en el editor de SQL de Databricks y, a continuación, confírmelos en una rama de Git.
2. Validar: durante una solicitud de incorporación de cambios, valide la sintaxis y la compatibilidad de esquemas mediante comprobaciones automatizadas de CI.
3. Implementación: tras la combinación, implemente los scripts de .sql en el entorno de destino mediante canalizaciones de CI/CD, por ejemplo, Acciones de GitHub o Azure Pipelines.
4. Supervisión: Utilice paneles y alertas de Databricks para seguir el rendimiento de las consultas y la recencia de los datos.

CI/CD para desarrolladores de paneles

Databricks admite la integración de paneles en flujos de trabajo de CI/CD mediante Databricks Asset Bundles. Esta funcionalidad permite a los desarrolladores de paneles:

• Paneles de control de versiones, que garantizan la auditabilidad y simplifican la colaboración entre equipos.
• Automatice las implementaciones de paneles junto con trabajos y canalizaciones entre entornos, para la alineación de un extremo a otro.
• Reduzca los errores manuales y asegúrese de que las actualizaciones se aplican de forma coherente en todos los entornos.
• Mantenga flujos de trabajo de análisis de alta calidad al tiempo que se adhieren a los procedimientos recomendados de CI/CD.

Para paneles en CI/CD:

• Use el databricks bundle generate comando para exportar paneles existentes como archivos JSON y generar la configuración de YAML que la incluye en la agrupación:

  resources:
    dashboards:
      sales_dashboard:
        display_name: 'Sales Dashboard'
        file_path: ./dashboards/sales_dashboard.lvdash.json
        warehouse_id: ${var.warehouse_id}
  

• Almacene estos .lvdash.json archivos en repositorios de Git para realizar un seguimiento de los cambios y colaborar de forma eficaz.

• Implemente paneles automáticamente en canalizaciones de CI/CD con databricks bundle deploy. Por ejemplo, el paso de las Acciones de GitHub para la implementación:

  name: Deploy Dashboard
    run: databricks bundle deploy --target=prod
  env:
    DATABRICKS_TOKEN: ${{ secrets.DATABRICKS_TOKEN }}
  

• Use variables, por ejemplo ${var.warehouse_id}, para parametrizar configuraciones como almacenes de SQL o orígenes de datos, lo que garantiza una implementación sin problemas en entornos de desarrollo, ensayo y producción.

• Use la bundle generate --watch opción para sincronizar continuamente los archivos JSON del panel local con los cambios realizados en la interfaz de usuario de Databricks. Si se producen discrepancias, use el indicador --force durante la implementación para reemplazar los paneles remotos con las versiones locales.

Para obtener información sobre los paneles de los conjuntos, consulte recurso de panel. Para obtener más información sobre los comandos de agrupación, consulte grupobundle de comandos.