Saltar al contenido
Lakehouse LabLakehouse LabPreparación Databricks Data Engineer
Módulo 22 · Lección

Arquitectura del pipeline

Contenido abierto

Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.

Lección 1 de 5

Arquitectura del pipeline

El proyecto de producción parte de contratos y NFR: fuentes, claves, latencia, calidad, seguridad, recuperación y consumidores antes de elegir objetos del pipeline.

Duración
30 min aprox.
Objetivo
El proyecto de producción parte de contratos y NFR: fuentes, claves, latencia, calidad, seguridad, recuperación y consumidores antes de elegir objetos del pipeline.
Siguiente paso
Continuar con la siguiente lección
Ver detalles del módulo

Proyecto de pipeline declarativo

Construye una cadena declarativa con calidad, CDC, orquestación y operación documentada.

Al terminar podrás
  • Entregar datasets incrementales fiables
  • Probar dependencias y reglas
  • Operar fallos y backfills
Ver fuentes y revisión

Metadatos editoriales

Última revisión
21 jul 2026
Nivel
Professional
Ruta relacionada
pipelines
Dominios blueprint
Production pipelines
Estado
Revisión editorial interna
Fuentes principales
Best practices for Spark Declarative Pipelines · Databricks · AUTO CDC APIs · Databricks
Reportar un error
01
Modelo mental

Arquitectura del pipeline

El proyecto de producción parte de contratos y NFR: fuentes, claves, latencia, calidad, seguridad, recuperación y consumidores antes de elegir objetos del pipeline.

Mostrar prerrequisitos
Dificultad
Professional
Prerrequisitos
m21
Reportar un error en esta lección

Pedidos append y clientes CDC tienen naturalezas distintas: los primeros encajan en streaming tables; los segundos en AUTO CDC. Gold necesita métricas consistentes con updates de ambas fuentes y puede ser una materialized view. El diseño identifica owners y fronteras bronze/silver/gold con nombres gobernados.

Los NFR se convierten en decisiones comprobables: p95 de frescura, umbral de errores, RTO, retención y presupuesto. Un diagrama sin criterios de aceptación no permite saber si el pipeline está terminado ni qué hacer ante un fallo.

Modelo mental

Un pipeline de producción comienza con contratos y requisitos no funcionales, no con decoradores. Para cada fuente se documentan owner, formato, claves, secuencia, frecuencia, volumen, retención, evolución y semántica de delete. Para cada consumidor se definen grain, frescura, completitud, historia, permisos y tolerancia a cambios. Los NFR convierten esas relaciones en decisiones: RPO/RTO determinan checkpoints y bronze; SLA determina trigger y capacidad; privacidad determina catálogo y columnas; coste limita refresh y retención. Solo entonces se eligen streaming tables, materialized views, AUTO CDC, expectations y Jobs. El diagrama incluye fronteras de commit y recuperación, no solo flechas. Una matriz de riesgos cubre datos tardíos, snapshots parciales, schema drift, dependencia caída y backfill. El proyecto final demuestra por qué cada objeto existe y qué ocurriría si se reemplazara por una alternativa.

Requisito funcional

Comportamiento que el producto debe ofrecer, como aplicar deletes, conservar historia o publicar una métrica con grain definido.

Determina la semántica correcta del modelo y permite probar si los datos responden preguntas esperadas.
Requisito no funcional

Propiedad operativa cuantificada, como latencia, disponibilidad, recuperación, seguridad, escalabilidad o coste bajo condiciones específicas.

Convierte arquitectura en compromisos medibles y evita considerar suficiente que una consulta produzca filas.
Frontera de commit

Punto durable y atómico después del cual una etapa considera su resultado publicado y permite avanzar a dependientes.

Hace explícita la recuperación y evita exponer resultados parciales durante fallos o reintentos.
YAMLContrato mínimo del proyecto
domain: commerce
sources:
  orders:
    semantics: append
    key: order_id
    freshness_p95_minutes: 10
  customers:
    semantics: cdc
    key: customer_id
    sequence: source_lsn
targets:
  silver_orders: main.silver.orders
  current_customers: main.silver.customers_current
  daily_sales: main.gold.daily_customer_sales
rto_minutes: 60
owner: commerce-data

Añade consumidores, clasificación, reconciliaciones y consultas de evidencia concretas en la entrega final.

Puntos clave

  • Cada fuente declara semántica append, CDC o snapshot.
  • Cada target declara clave, consumidor, SLO y estrategia de rebuild.
  • Dependencias externas, clasificación de datos y PII se identifican antes de desplegar.

Evita

  • Elegir todos los targets como streaming tables sin considerar updates y resultado completo.
  • Diseñar la capa gold antes de acordar claves y semántica de las fuentes.

Recuerdo activo

¿Qué dato del feed de clientes es imprescindible además de `customer_id`?

Borrador privado · solo en este navegador
5 lecciones pendientes

Fuente revisada · vista externa

Databricks Free Declarative Pipelines

Databricks Free Declarative Pipelines · commit a515370

docs/3-2-building-bronze-sql.md

Lectura en GitHub

Este notebook se abre desde su fuente revisada

El repositorio no permite republicar su contenido dentro de Lakehouse Lab. Conservamos la misma experiencia lateral, la ruta exacta y el commit auditado, y dejamos la lectura en GitHub para respetar la autoría.

Autor
andkret
Licencia
No verificada
Formato
project
Ver notebook en GitHub