Puedes leer sin crear un espacio. Créalo solo cuando quieras guardar.
Guardar progresoLecció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.
30 min aprox.
01Modelo mentalArquitectura 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.
+
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.
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.
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-dataAñade consumidores, clasificación, reconciliaciones y consultas de evidencia concretas en la entrega final.
¿Qué dato del feed de clientes es imprescindible además de `customer_id`?
Profundiza
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.
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.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.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.Resumen
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.