Arquitectura Lakeflow de producción

Objetivo: diseñar una arquitectura Bronze → Silver → Gold que sea incremental, recuperable, observable y fácil de desplegar en varios países.

1. Nuestra arquitectura de referencia

Separar ingesta y transformación es una recomendación oficial de Databricks: permite que un error en Silver no detenga la llegada de nuevos datos a Bronze. Databricks on AWS

2. Las decisiones técnicas más importantes

Esta sería mi arquitectura inicial, no una regla universal. Las Streaming Tables, MVs y flows tienen comportamientos diferentes, por lo que cada dataset debe clasificarse según cómo cambian sus datos. Databricks on Google Cloud

3. Código: tres piezas, una arquitectura

Bronze: conservar los eventos originales

@dp.table(name="bronze_tickets")
def bronze_tickets():
    return (
        spark.readStream
        .format("kafka")
        # Conexión segura a Event Hubs...
        .load()
        .select(
            "key", "value", "headers",
            "topic", "partition",
            "offset", "timestamp"
        )
    )

Este código esquemático presupone la configuración de conexión de la lección 5, con permisos, secretos y headers habilitados.

Silver: transformar los datos

@dp.table(name="silver_tickets")
@dp.expect_or_drop(
    "valid_pharmacy",
    "pharmacy_id IS NOT NULL"
)
def silver_tickets():
    return (
        spark.readStream.table(
            "bronze_deserialized_tickets"
        )
        .select(
            "ticket_id",
            "pharmacy_id",
            "amount",
            "event_time"
        )
    )

Aquí asumimos que ya hemos deserializado Avro y conservamos los importes negativos porque podrían representar devoluciones.

Gold: KPI de ventas diarias

@dp.materialized_view(name="gold_daily_sales")
def gold_daily_sales():
    return (
        spark.read.table("silver_tickets")
        .groupBy(
            "pharmacy_id",
            F.to_date("event_time").alias("day")
        )
        .agg(
            F.sum("amount").alias("sales")
        )
    )

La agregación declarativa permite que Lakeflow utilice incremental refresh cuando la consulta y sus fuentes lo admiten. Databricks on Google Cloud

Importante: los nombres de tabla de estos fragmentos son conceptuales. Al separarlos en pipelines, configuraríamos los nombres de catálogo/esquema para que cada consumidor leyera las tablas publicadas por el pipeline anterior.

4. ¿Un pipeline o varios?

Aquí hay una decisión arquitectónica importante.

Para vuestra plataforma elegiría varios pipelines agrupados por responsabilidad y dominio, evitando tanto un pipeline gigante como decenas de pipelines innecesariamente pequeños.

Una separación física no elimina la necesidad de orquestar las dependencias entre pipelines. Para eso utilizaríamos Lakeflow Jobs.

5. Ejemplo: orquestación en producción

No siempre haría esperar Bronze a Gold: si las transformaciones fallan frecuentemente o tienen un SLA diferente, desacoplaría también su programación.

6. Cinco reglas que aplicaría en producción

• Nunca perder el raw: conservar payload, headers y metadatos Kafka en Bronze.

• Reprocesar desde Delta: reconstruir Silver desde Bronze, no desde Event Hubs si el histórico ya ha expirado.

• No confundir eventos con entidades: append-only para eventos; AUTO CDC cuando haya cambios de estado identificables.

• Diseñar Gold para correcciones: los KPIs históricos deben reflejar cambios anteriores, no solo nuevas inserciones.

• Medir cada capa: freshness, errores, calidad, throughput y costes.

El cuarto punto nos lleva directamente a la lección 16: si mañana se corrige un ticket de agosto, ¿cómo actualizamos únicamente los KPIs afectados?

7. Mini ejercicio de arquitectura

Qué debes recordar: no existe un único tipo de tabla o pipeline ideal para todas las capas. La arquitectura correcta depende de cómo cambian los datos, del SLA, de los requisitos de recuperación y de cómo consumen la información los equipos de negocio.