Hito Professional

El proyecto final comienza con decisiones, no productos. Define volumen, latencia, freshness, calidad, retención, RPO/RTO, consumidores, clasificación, regiones y presupuesto. Después asigna cada requisito a una capacidad: Auto Loader/Lakeflow Connect para ingesta, pipelines declarativos para transformación, Jobs para orquestación, Unity Catalog para gobierno y system tables para operación.

Documenta alternativas rechazadas y condiciones de cambio. Una arquitectura Professional no es la que usa más servicios, sino la que minimiza estados y responsabilidades ambiguas. Cada tabla, checkpoint, job, policy y alerta tiene owner; cada SLO tiene una señal medible y un runbook. Mapea además evidencias a los dominios del blueprint sin convertirlo en memorización.

product: commerce-orders
owners:
  product: commerce-analytics
  platform: data-platform
slos:
  freshness_minutes: 15
  completeness_percent: 99.95
  p95_pipeline_minutes: 12
recovery:
  rpo_minutes: 15
  rto_minutes: 60
governance:
  classification: confidential
  regions: [eu-west, us-east]
finops:
  monthly_budget_eur: 18000

La ingesta incremental conserva progreso mediante checkpoint o estado del conector; bronze retiene hechos crudos suficientes para replay; silver aplica contratos, deduplicación y CDC; gold sirve modelos de consumo. Cada escritura usa una clave de negocio y semántica de retry conocida. Los datos tardíos, deletes y cambios de esquema tienen una política explícita, no un comportamiento accidental.

Prueba replay y backfill antes de producción. Un pipeline vivo y un backfill no deben competir por el mismo rango sin coordinación. Usa `MERGE` o la API actual `AUTO CDC` —`APPLY CHANGES` en código legado— según la herramienta y orden de secuencia, conserva cuarentena para incumplimientos y reconcilia conteos/importe entre capas. Versiona cambios incompatibles del contrato.

MERGE INTO prod.silver.orders AS target
USING staging.orders_cdc AS source
ON target.order_id = source.order_id
WHEN MATCHED AND source.op = 'DELETE' THEN DELETE
WHEN MATCHED AND source.sequence_ts > target.sequence_ts THEN UPDATE SET *
WHEN NOT MATCHED AND source.op <> 'DELETE' THEN INSERT *;

La observabilidad se diseña en capas: freshness y completitud del producto, calidad de registros, estado/duración/retries del pipeline, perfiles de consulta y coste. Expectations pueden fallar, descartar o registrar según severidad; event logs de pipelines explican updates y calidad; system tables agregan jobs, queries, billing, audit y lineage.

Una alerta debe ser accionable: incluye umbral, ventana, owner, contexto y enlace al runbook. Evita alert fatigue agrupando síntomas del mismo fallo. En recuperación, valida downstream y no sólo el run. Usa lineage para impacto, audit para actor/cambio y Query Profile/Spark UI para rendimiento. Ensaya RTO con game days.

CREATE OR REPLACE VIEW ops.slo.orders_freshness AS
SELECT
  MAX(processed_at) AS last_processed_at,
  TIMESTAMPDIFF(MINUTE, MAX(processed_at), current_timestamp()) AS freshness_minutes,
  CASE
    WHEN TIMESTAMPDIFF(MINUTE, MAX(processed_at), current_timestamp()) <= 15
      THEN 'OK'
    ELSE 'BREACH'
  END AS slo_state
FROM prod.silver.orders;

Cada job ejecuta como service principal con privilegios mínimos; CI despliega con otra identidad. Unity Catalog aporta grupos, grants, governed tags, ABAC, masks y audit. Clasifica antes de compartir y restringe workspaces/locations. Los secretos se referencian desde scopes o mecanismos administrados, nunca desde notebooks, tags o YAML versionado.

El coste se atribuye mediante tags/policies y `system.billing.usage`; compara coste por millón de pedidos y por SLO cumplido. Serverless reduce gestión, pero no elimina consultas ineficientes. Predictive optimization, Photon y liquid clustering se habilitan donde el workload lo justifica y se validan con perfiles. El presupuesto incluye reintentos, backfills, egress y sharing/federation.

SELECT
  usage_date,
  custom_tags['data_product'] AS data_product,
  billing_origin_product,
  sku_name,
  SUM(usage_quantity) AS usage_quantity
FROM system.billing.usage
WHERE usage_date >= current_date() - INTERVAL 30 DAYS
  AND custom_tags['data_product'] = 'commerce-orders'
GROUP BY usage_date, custom_tags['data_product'],
         billing_origin_product, sku_name
ORDER BY usage_date DESC;

Las preguntas originales del simulacro deben ejercitar escenarios, no recordar frases. Lee primero la restricción dominante —SLA, recovery, mínimo privilegio, compatibilidad o coste— y después compara opciones. Descarta respuestas irreversibles, manuales o que eliminan estado sin diagnóstico. Cuando dos alternativas son técnicamente posibles, elige la que satisface requisitos con menor operación y mejor evidencia.

Tras cada intento, agrupa errores por dominio y por tipo de razonamiento: confundir mitigación con solución, escalar antes de diagnosticar, ignorar idempotencia o ampliar permisos. Vuelve a los módulos y reproduce la decisión en un lab. El 80 % interno sólo señala preparación; no es nota oficial ni garantiza el examen. No uses dumps ni preguntas reales.

attempt: professional-02
score_percent: 78
weak_domains:
  - performance_diagnosis
  - unity_catalog_abac
reasoning_errors:
  - "escalé antes de localizar el stage crítico"
  - "confundí SELECT con la cadena USE CATALOG/USE SCHEMA"
next_actions:
  - module: 23
    evidence: "comparar max/mediana por task en un join sesgado"
  - module: 30
    evidence: "probar allow, mask y deny con tres identidades"