Unity Catalog, Bundles y CI/CD

Objetivo: desplegar exactamente el mismo pipeline Lakeflow en DEV, UAT y PROD, cambiando únicamente la configuración del entorno.

1. ¿Qué problema resolvemos?

Imagina que tenemos un pipeline que transforma tickets de Bronze a Silver y Gold.

Queremos utilizar el mismo código Python en tres entornos sin duplicarlo.

Git Repository

Python + YAML · Una única versión del código

Databricks Bundle

Define pipelines y entornos

DEV

dev_catalog

UAT

uat_catalog

PROD

prod_catalog

En este esquema, cada entorno puede tener su propio workspace y catálogo de Unity Catalog.

Regla fundamental: el código de negocio es el mismo; lo que cambia es la configuración.

2. ¿Qué es un Databricks Asset Bundle?

Actualmente Databricks lo denomina Declarative Automation Bundle (antes Databricks Asset Bundle).

Es una manera de describir mediante YAML los recursos que queremos desplegar: pipelines, jobs, configuración, archivos y otros recursos de Databricks. Databricks on AWS

Nuestro repositorio tendrá esta estructura:

lakeflow-project/
├── databricks.yml
├── resources/
│   └── tickets.pipeline.yml
└── src/
    └── tickets.py

Tres archivos. Vamos a verlos.

3. Archivo 1: lógica de negocio

src/tickets.py

from pyspark import pipelines as dp
from pyspark.sql import functions as F

@dp.table(name="silver_tickets")
def silver_tickets():
    return (
        spark.readStream.table("bronze_tickets")
        .filter("amount > 0")
    )

@dp.materialized_view(name="gold_sales")
def gold_sales():
    return (
        spark.read.table("silver_tickets")
        .groupBy("pharmacy_id")
        .agg(F.sum("amount").alias("total"))
    )

Este archivo no contiene ninguna referencia a DEV, UAT o PROD.

Suponemos que bronze_tickets ya existe en el catálogo y esquema correspondiente.

4. Archivo 2: definición del pipeline

resources/tickets.pipeline.yml

resources:
  pipelines:
    tickets:
      name: tickets-${bundle.target}

      catalog: ${var.catalog}
      schema: demo_lakeflow

      serverless: true
      continuous: false

      libraries:
        - file:
            path: ../src/tickets.py

Aquí definimos:

• Dónde publicaremos las tablas: catalog y schema.

• Qué compute usaremos: serverless.

• Cómo ejecutaremos el pipeline: continuous: false indica modo Triggered.

• Qué código ejecutará: tickets.py.

La ruta ../src/tickets.py es relativa al archivo YAML.

El recurso pipelines y estas opciones están documentados en la referencia oficial de bundles para Azure Databricks. Microsoft Learn

5. Archivo 3: configuración DEV, UAT y PROD

databricks.yml

bundle:
  name: learning-lakeflow

include:
  - resources/*.yml

variables:
  catalog:
    description: Unity Catalog de destino

targets:
  dev:
    default: true
    mode: development
    workspace:
      profile: databricks-dev
    variables:
      catalog: dev_catalog

  uat:
    mode: production
    workspace:
      profile: databricks-uat
    variables:
      catalog: uat_catalog

  prod:
    mode: production
    workspace:
      profile: databricks-prod
    variables:
      catalog: prod_catalog

Los nombres de los catálogos y perfiles son ejemplos. Los perfiles deben existir previamente en la configuración de autenticación de Databricks CLI.

Fíjate en mode: production para UAT: es intencionado. Queremos que UAT se comporte como un despliegue estable, no como un entorno de desarrollo personal.

6. Desplegar desde terminal

Primero validamos:

databricks bundle validate -t dev

Después desplegamos:

databricks bundle deploy -t dev

Y ejecutamos el pipeline:

databricks bundle run -t dev tickets

El mismo código para UAT:

databricks bundle validate -t uat
databricks bundle deploy -t uat
databricks bundle run -t uat tickets

Y para PROD:

databricks bundle validate -t prod
databricks bundle deploy -t prod

En PROD normalmente dejaríamos que un Job programado ejecute el pipeline, en lugar de lanzarlo manualmente desde la terminal.

Diferencia importante: deploy actualiza la definición del recurso en Databricks; run ejecuta el recurso desplegado. No son la misma operación. Databricks on AWS

7. Simula la promoción entre entornos

8. ¿Cómo encaja Unity Catalog?

Unity Catalog determina dónde están los datos y quién puede acceder a ellos.

No basta con que el bundle declare un catálogo. La identidad que ejecuta el pipeline necesita permisos adecuados.

Por ejemplo:

GRANT USE CATALOG
ON CATALOG dev_catalog
TO `data-engineers`;

GRANT USE SCHEMA, CREATE TABLE
ON SCHEMA dev_catalog.demo_lakeflow
TO `data-engineers`;

Estos permisos son ilustrativos. Además, el pipeline necesitará permisos de lectura sobre las tablas fuente y otros privilegios según su operación.

En producción utilizaría un Service Principal para desplegar y ejecutar, con privilegios mínimos y una identidad controlada. Databricks

9. ¿Cómo sería un CI/CD completo?

Para un equipo que utiliza Azure DevOps, estos pasos se podrían automatizar con Azure Pipelines.

Mi recomendación: utilizar el mismo commit en los tres entornos. Así garantizamos que lo probado en UAT es exactamente el código que desplegamos en PROD.

Y recuerda: hacer rollback del código no revierte automáticamente los datos Delta ya procesados. Es algo que deberíamos contemplar en el procedimiento de recuperación.

10. Mini ejercicio

Qué debes recordar:

• Unity Catalog gestiona los datos, su organización y permisos.

• Declarative Automation Bundles describe los recursos y su configuración como código.

• CI/CD valida, despliega y promociona versiones entre entornos.

• Un mismo código, distintas configuraciones es la base de una plataforma de datos escalable.

Nos quedan 4 lecciones: observabilidad, arquitectura completa, CDC vs CDF e incremental refresh, y comparación con dbt.