Entrevista de ingeniería de datos: ¿Cómo diseñar SLOs de calidad de datos para un pipeline crítico?

Planteamiento y contexto aplicable

Un conjunto de datos diario de fact_order_settlements procesa aproximadamente 10 millones de eventos de órdenes provenientes de 12 sistemas fuente. Finanzas inicia su cierre a las 07:00 UTC. El orquestador actualmente solo informa si los jobs finalizaron, por lo que una ejecución en verde aún puede publicar una partición tardía, omitir una fuente, duplicar una versión de orden o discrepar con los totales de origen.

Diseñe los SLOs de calidad de datos y los controles que los aplican. Los sistemas fuente proporcionan un manifiesto de control que contiene el recuento de registros y el monto bruto por fuente, moneda y fecha contable. Los eventos crudos permanecen reproducibles durante 30 días, las correcciones pueden llegar durante 24 horas y dos consumidores tienen necesidades diferentes: finanzas requiere datos certificados, mientras que los analistas pueden utilizar una vista preliminar claramente señalizada.

Cubra SLIs, objetivos, ubicación de reglas, compuertas de despliegue, ownership, enrutamiento de alertas, acciones basadas en presupuesto de error, recuperación de incidentes y validación del despliegue. Los 10 millones de eventos, las 12 fuentes, los plazos, la retención y los objetivos propuestos son suposiciones para la entrevista. Los objetivos de producción requieren acuerdo con el consumidor y mediciones históricas. Esta es una pregunta de data porque su núcleo es un contrato de calidad operable para un producto de datos. El trabajo comienza antes de un incidente y continúa a través de la certificación y la revisión de políticas.

Qué evalúa el entrevistador

Primero, ¿puede el candidato traducir "datos de alta calidad" en resultados observables para el consumidor? La frescura, completitud, validez, consistencia, precisión y unicidad describen diferentes modos de falla. Un único puntaje de calidad combinado puede ocultar un duplicado de tolerancia cero detrás de varias comprobaciones aprobadas.

Segundo, ¿puede el candidato elegir un denominador confiable? Comparar el recuento de filas de hoy con el de ayer detecta grandes anomalías, pero no puede demostrar la completitud. Un manifiesto de origen, un rango de offsets de log de cambios o un ledger controlado de forma independiente proporcionan evidencia más sólida de lo que debió haber llegado.

Tercero, ¿puede el candidato separar la especificación de un SLI de su implementación? "Finanzas recibe datos certificados antes del cierre" expresa el resultado. Medir el tiempo de finalización de un programador es una implementación que pasa por alto fallas de publicación, catálogo, permisos y lectura downstream. Las respuestas sólidas miden cerca del límite del consumidor y documentan los puntos ciegos.

Cuarto, ¿cada falla provoca una acción predeterminada? Un invariante estricto necesita un bloqueo de publicación o cuarentena. Una advertencia necesita un responsable y una ruta de revisión. Una alerta vía page debe representar un impacto urgente para el consumidor. "Alertar sobre cada regla fallida" traslada el trabajo de diseño al ingeniero de guardia y genera ruido.

Finalmente, ¿puede el candidato hacer ejecutable la asignación de responsabilidades? Los productores, ingenieros de plataforma, propietarios de conjuntos de datos y finanzas pueden compartir la responsabilidad, pero cada regla, incidente y aprobación aún necesita un único responsable directo y una ruta de escalamiento.

Preguntas clarificatorias antes de responder

¿Qué significa "listo" para finanzas? Si el cierre requiere datos certificados a las 07:00, mida cuándo finanzas puede consultar la versión certificada, no cuándo termina la última transformación. Si una vista previa es útil, publíquela bajo un estado y contrato separados.
¿Qué evidencia independiente define la completitud y corrección? Un manifiesto de origen permite la conciliación de recuentos y montos. Sin él, use offsets, snapshots de origen o totales de ledger y etiquete las comprobaciones estadísticas de volumen como detección de anomalías en lugar de prueba.
¿Cuál es la clave de negocio y el modelo de actualización? La unicidad puede aplicar a (source_id, order_id, version), mientras que el estado de negocio más reciente puede requerir una versión ganadora por orden. Las correcciones tardías modifican tanto la verificación como el ciclo de vida de la certificación.
¿Qué fallas pueden degradarse y cuáles deben bloquearse? Claves faltantes, versiones duplicadas o discrepancias en el ledger pueden corromper el cierre y deben bloquear la certificación. Un atributo de marketing opcional puede ponerse en cuarentena mientras los campos financieros certificados continúan.
¿Cuántos eventos de calidad existen en la ventana del SLO? Un pipeline diario tiene muy pocas observaciones para un objetivo mensual significativo del 99.9%. Un objetivo móvil de 60 días hábiles, como 59 certificaciones oportunas, tiene una granularidad comprensible.
¿Quién puede autorizar una excepción a una compuerta fallida? Una excepción necesita un aprobador, consumidores afectados, tiempo de expiración, motivo y registro de auditoría. El ingeniero de guardia no debe redefinir silenciosamente un contrato financiero durante un incidente.
¿Qué recuperación es posible? La reproducción de 30 días de datos crudos permite reconstrucciones deterministas. Si el historial de origen es mutable o incompleto, los requisitos de recuperación y evidencia deben cambiar.

Marco de respuesta de 30 segundos

"Comenzaría a partir de la decisión de finanzas, para luego definir SLIs separados para frescura certificada, conciliación de manifiestos, completitud de claves de negocio, validez y unicidad. Mediría la tabla certificada en el límite con el consumidor y mantendría los invariantes financieros de tolerancia cero separados de la puntualidad presupuestada.

Las comprobaciones de esquema se ejecutan antes del despliegue, las de filas en la ingesta, las de negocio tras la transformación y la conciliación de extremo a extremo bloquea o habilita la certificación. Finanzas lee únicamente una vista certificada y versionada; los analistas pueden optar por una vista preliminar etiquetada. Cada regla tiene una acción, un responsable y un runbook. Probaría el contrato en canary sobre una fuente, compararía las detecciones con incidentes conocidos, calibraría las falsas alarmas, ensayaría la reproducción de datos y dejaría que una política acordada de presupuesto de error modifique las prioridades de ingeniería cuando el objetivo de frescura se agote."

Análisis detallado paso a paso

Paso 1: Definir el producto de datos y los resultados para el consumidor

Redacte un contrato para el conjunto de datos de liquidación certificado, no un catálogo de cada verificación posible. Especifique la versión del conjunto de datos, la fecha contable, los consumidores, el propietario, el plazo límite de certificación, la política de corrección y la evidencia retenida para auditoría. Los dos modos de consumo deben ser explícitos:

preliminary: disponible temprano, puede contener fuentes declaradas como tardías, nunca se utiliza para el cierre financiero;
certified: inmutable para la versión indicada, con todas las compuertas estrictas aprobadas, con un ID de manifiesto y de resultado de calidad;
superseded: reemplazado por una versión de corrección mientras la evidencia anterior sigue siendo localizable.

Este modelo de estados evita que un estado de orquestación en verde se convierta en una garantía comercial accidental. Finanzas consulta únicamente certified; los consumidores exploratorios pueden sacrificar certeza por frescura sin debilitar el contrato de finanzas.

Paso 2: Escribir cada SLI como eventos satisfactorios sobre eventos elegibles

Utilice resultados visibles para el consumidor y una unidad definida. Para el escenario planteado, un SLI inicial de frescura es:

text

freshness_sli =
  business-day partitions certified and queryable by 06:30 UTC
  / eligible business-day partitions

starting_slo = at least 59 good partitions in a rolling 60-business-day window

El umbral deja un margen de 30 minutos antes del cierre financiero y una certificación tardía en la ventana de ejemplo. Ambos valores son suposiciones a negociar con finanzas y a validar con el historial. Mida a partir de una consulta del consumidor o un estado de catálogo que confirme que la versión es legible; la marca de tiempo de finalización del programador es solo una señal de diagnóstico.

Asigne a las demás dimensiones sus propios criterios de éxito:

Completitud: cada manifiesto de origen esperado está presente; el recuento de registros y la cobertura de claves críticas concilian.
Unicidad: cero tuplas de (source_id, order_id, version) duplicadas en una partición certificada.
Validez: existen las claves requeridas y los campos controlados por contrato utilizan tipos, dominios y rangos permitidos.
Consistencia: los recuentos y montos concilian por fuente, moneda y fecha contable antes de la agregación.
Puntualidad de corrección: las correcciones aceptadas se convierten en una versión recién certificada dentro de una ventana acordada.

La precisión es más difícil de inferir a partir de la estructura interna. Un monto válido y único aún puede ser incorrecto. Los totales controlados por la fuente, la conciliación contra ledger, la revisión de negocio por muestreo y las comprobaciones de resultados downstream proporcionan evidencia más sólida que una regla de formato.

Paso 3: Elegir deliberadamente invariantes estrictos, SLOs y diagnósticos

Tres clases mantienen las acciones comprensibles:

Invariantes estrictos: cualquier infracción bloquea la certificación, como claves de negocio faltantes, versiones duplicadas o totales financieros no conciliados.
Objetivos presupuestados: los incumplimientos ocasionales se toleran dentro de una política escrita, como el plazo de certificación o el tiempo de respuesta ante correcciones.
Diagnósticos: señales que ayudan a la investigación pero no definen el éxito para el consumidor, como una variación de volumen del 20% interdiaria.

No convierta los requisitos estrictos de corrección en "filas defectuosas permitidas" meramente para encajar en una fórmula de presupuesto de error. Una sola orden de alto valor duplicada puede ser más crítica que miles de nulos opcionales inofensivos. Mantenga separados cada objetivo y su consecuencia; un puntaje general en un dashboard puede resumir tendencias, pero no puede anular una regla de bloqueo.

Paso 4: Colocar las comprobaciones en el límite útil más temprano

Ejecute pruebas de compatibilidad de esquemas y ejemplos de contratos en el CI del productor y de la transformación. En la ingesta, valide la capacidad de parseo, los campos obligatorios del sobre (envelope), la identidad de la fuente, la continuidad de offsets y la idempotencia; ponga en cuarentena los registros defectuosos identificables con códigos de motivo. Tras la transformación, verifique claves de negocio, relaciones referenciales, selección de versiones, reglas de conversión de moneda y cortes a nivel de fuente. En la publicación, realice la conciliación de manifiestos y ledger y verifique que la versión certificada exacta sea consultable.

No es necesario ejecutar la misma regla en todas partes. Una prueba unitaria de no nulidad con cinco fixtures valida rutas de código, pero dice poco sobre una fuente en producción. Una agregación en producción puede detectar una falla, pero puede llegar demasiado tarde para proteger a los consumidores intermedios. Coloque una comprobación de prevención económica antes del cambio, una comprobación operativa en el punto de entrada de los datos y una comprobación de extremo a extremo donde se consume la promesa.

Lo siguiente es un pseudo-YAML ilustrativo y neutral respecto a herramientas, en lugar de un esquema específico de un producto:

yaml

dataset: finance.fact_order_settlements
owner: finance-data
consumer: daily-close
certification_deadline_utc: "06:30"
rules:
  - name: required_business_key
    dimension: completeness
    scope: row
    pass_ratio: 1.0
    action: block_and_quarantine
  - name: unique_order_version
    dimension: uniqueness
    scope: [source_id, order_id, version]
    pass_ratio: 1.0
    action: block_certification
  - name: source_manifest_reconciliation
    dimension: consistency
    scope: [source_id, currency, business_date]
    pass_ratio: 1.0
    action: block_certification_and_page_owner

Paso 5: Utilizar conciliación independiente y segmentar el resultado

Cruce mediante join los agregados recibidos con todas las filas esperadas del manifiesto, incluidas las fuentes que no entregaron nada. Un left join únicamente desde los datos recibidos hace invisible a una fuente ausente. Compare recuentos y montos en su moneda original antes de cualquier conversión con pérdida de precisión. Registre juntos el ID del manifiesto, el watermark de la fuente, la versión de la transformación, el snapshot de la tabla y los resultados de las reglas.

Segmente las fallas por fuente, región, moneda, tipo de evento y etapa del pipeline. Una tasa de aprobación global del 99.99% puede ocultar una interrupción total de una fuente de bajo volumen. Por el contrario, una fuente retrasada conocida no debería generar alertas idénticas de guardia desde ingesta, transformación y publicación. Enrute la alerta al primer límite roto con capacidad de acción y suprima las alertas derivadas preservando el diagnóstico.

Las bandas históricas son útiles para detectar anomalías de volumen, pero la estacionalidad, promociones y fuentes recién lanzadas pueden desplazarlas legítimamente. Considere una anomalía como evidencia a investigar hasta que un total de control independiente confirme la pérdida.

Paso 6: Hacer ejecutables las compuertas, las excepciones y la asignación de responsabilidades

Cada regla debe declarar severidad, acción, responsable directo, responsable de respaldo, destino de escalamiento, runbook y tiempo máximo de acuse de recibo. Una división práctica es:

falla de esquema o manifiesto de origen: el productor es responsable de la corrección; el responsable de ingesta contiene el impacto;
falla de transporte, deduplicación u orquestación: la plataforma de datos es responsable de la recuperación;
falla de transformación semántica o conciliación: el propietario del conjunto de datos es responsable del diagnóstico y la reconstrucción;
discrepancia en la definición de negocio: el data steward de finanzas decide sobre el contrato, mediante una revisión de cambios auditable.

Una excepción genera una nueva versión explícitamente degradada o mantiene el conjunto de datos como preliminar. En ella se registra quién la aprobó, por qué el negocio acepta el riesgo, qué consumidores se ven afectados y cuándo expira la excepción. Nunca sobrescriba un resultado fallido ni apunte silenciosamente el alias certificado a una partición no verificada.

Paso 7: Definir una política de presupuesto de error que cambie decisiones

Para el SLO de frescura del ejemplo, una partición tardía representa el presupuesto móvil de 60 días hábiles. Monitoree el consumo y la tasa de consumo (burn rate). Un solo día tardío consume todo el presupuesto; una partición financiera certificada incorrecta activa la política de incidentes independientemente del presupuesto de frescura restante.

Acuerde las acciones antes de un incumplimiento. Cuando un pronóstico de burn rate indique que el único incumplimiento permitido está en riesgo, revise la causa principal y valide la capacidad de recuperación. Al agotarse el presupuesto, congele los cambios riesgosos en el pipeline, priorice el trabajo de confiabilidad y exija un criterio de salida aprobado por el responsable. Esta política convierte el SLO en una herramienta de toma de decisiones. Un dashboard sin consecuencias es solo un reporte.

Revise el SLI cuando las detecciones no se correlacionen con incidentes para los consumidores o las alertas tengan baja precisión. Acerque la medición a finanzas, agregue segmentaciones faltantes o relaje un diagnóstico ruidoso. No flexibilice un invariante estricto para silenciar ruido operativo; corrija la implementación o el enrutamiento.

Paso 8: Hacer despliegues canary, ensayar la recuperación y demostrar la cobertura

Evalúe las reglas en modo shadow sin compuertas de bloqueo sobre una fuente y una ventana histórica representativa de 14 a 30 días. Inyecte fallas controladas: omita una fuente, duplique una versión de orden, rompa un esquema, retrase la publicación y altere un monto manteniendo el recuento de filas. Verifique que la regla esperada, el responsable y el runbook se activen una sola vez.

Luego, aplique compuertas a una fuente de bajo riesgo, expanda según la criticidad de las fuentes y, finalmente, proteja la certificación. Los criterios de aceptación incluyen cobertura de detección para fallas inyectadas, ninguna partición certificada incorrecta, tasa de falsas alarmas acotada, evidencia legible por el consumidor, reproducción determinista a partir de eventos crudos y recuperación antes del plazo límite de finanzas. Mida el costo computacional de las reglas y examine solo las particiones modificadas donde la corrección lo permita; un sistema de calidad que habitualmente pierde su propio plazo socava el pipeline.

Tras el despliegue, revise los incidentes que los consumidores detectaron manualmente y las alertas que no generaron impacto. Esos dos conjuntos revelan falta de cobertura y baja precisión. Gestione las versiones de los cambios de contrato junto con el modelo de datos, exija revisión de productores y consumidores, y conserve el conjunto exacto de reglas utilizado para cada certificación.

Respuesta de ejemplo de alta calidad

"Definiría el servicio desde la perspectiva de finanzas: una partición de liquidación específica está certificada, consultable, conciliada y disponible antes del cierre. Un DAG finalizado es solo un diagnóstico, por lo que sondearía la versión publicada y conservaría su manifiesto, snapshot, versión de código y resultado de calidad.

Para la frescura, podría proponer 59 particiones certificadas antes de las 06:30 en una ventana móvil de 60 días hábiles, calibrándolo luego con finanzas y el desempeño histórico. La corrección tiene compuertas estrictas independientes. Todo manifiesto de origen debe llegar; los recuentos y montos en moneda original deben conciliar por fuente y fecha contable; las claves de negocio requeridas deben estar completas; y (source_id, order_id, version) debe ser único. Nunca promediaría esto en un puntaje compuesto que permita pasar una falla bloqueante.

Las comprobaciones se ejecutan en varios límites. CI detecta casos incompatibles de esquema y transformación. La ingesta verifica sobres, offsets e idempotencia y pone en cuarentena fallas identificables. La transformación verifica reglas semánticas y referenciales. La publicación realiza la conciliación independiente y confirma que la versión exacta sea consultable. Finanzas recibe únicamente el alias certificado; los analistas pueden utilizar una vista preliminar que incluye el estado de las fuentes y de la calidad.

Cada regla fallida se asigna a una acción y a un responsable. Un productor atiende un contrato de origen roto, el equipo de plataforma gestiona el transporte y el propietario del conjunto de datos se encarga de la transformación y la certificación. Una excepción tiene un tiempo límite, es visible para los consumidores y es aprobada por el data steward de finanzas. Una partición certificada incorrecta se considera un incidente, incluso si queda presupuesto de frescura.

Evaluaría las reglas en shadow sobre particiones históricas, inyectaría fallas de fuentes faltantes, claves duplicadas, esquemas rotos, retrasos y montos erróneos con igual recuento de filas, para luego aplicar compuertas a una fuente. Solo expandiría el alcance cuando la detección, enrutamiento, reproducción, tasa de falsas alertas y tiempo de ejecución de las reglas cumplan con los criterios de aceptación. Si se consume el único día de retraso permitido, la política acordada reasigna capacidad del desarrollo de features hacia confiabilidad hasta cumplir los criterios de salida."

Errores comunes

Monitorear solo el éxito del job → Un job completado puede publicar datos incompletos o ilegibles → Mida el objeto certificado en el límite del consumidor.
Usar el recuento de filas de ayer como prueba de completitud → Cambios legítimos de demanda y pérdidas silenciosas de fuentes se ven similares → Concilie contra manifiestos, offsets, snapshots u otro total controlado.
Colapsar todas las comprobaciones en un solo puntaje → Muchas reglas opcionales aprobadas pueden enmascarar un invariante financiero roto → Asigne a cada dimensión crítica su propio umbral y acción.
Establecer 99.9% sobre un evento diario al mes → El denominador no puede expresar esa precisión → Elija una ventana y unidad con granularidad significativa.
Asignar un presupuesto de error a cada fila defectuosa → El recuento de filas ignora el valor comercial y la integridad estricta → Mantenga los invariantes de tolerancia cero fuera de la puntualidad presupuestada.
Alertar vía page ante cada regla fallida → La falla de una fuente crea una cascada de alertas no accionables → Envíe alerta vía page al primer límite asignado y suprima las derivadas downstream.
Permitir que el ingeniero de guardia autorice excepciones silenciosamente → Los consumidores no pueden evaluar el riesgo y la evidencia de auditoría desaparece → Utilice una excepción aprobada, con expiración y visible para el consumidor.
Probar solo el camino feliz (happy path) → El equipo descubre que la recuperación es no determinista durante el cierre → Inyecte fallas representativas y ensaye la reproducción antes de imponer compuertas.
Agregar escaneos completos y costosos de tablas a cada ejecución → Las comprobaciones de calidad consumen el margen de frescura que intentan proteger → Utilice comprobaciones incrementales combinadas con conciliaciones completas periódicas donde sea seguro.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Qué pasa si las fuentes no pueden proporcionar manifiestos?

Clasifique los sustitutos según su nivel de independencia. Snapshots de origen, rangos de números de secuencia de logs de base de datos, offsets de brokers, inventarios de archivos con checksums y un ledger producido por separado son más sólidos que el recuento de filas de la tabla destino. Utilice bandas históricas para detectar anomalías, aclare que no pueden demostrar la completitud e incorpore la entrega de manifiestos o totales de control en el contrato del productor para fuentes críticas.

Pregunta de seguimiento 2: ¿Qué pasa si finanzas exige cero particiones tardías para siempre?

Un objetivo implícito del 100% no deja mecanismos para priorizar el trabajo de confiabilidad y puede ser operativamente indefendible. Cuantifique la redundancia, el tiempo de reproducción, las dependencias de fuentes y el costo requerido para acercarse a dicha exigencia. Mantenga la corrección financiera como compuerta estricta, proponga un objetivo de frescura medible junto con una meta aspiracional más estricta, y obtenga un acuerdo explícito entre negocio, ingeniería y operaciones sobre la política de respuesta.

Pregunta de seguimiento 3: ¿Cómo maneja una corrección después de que una partición fue certificada?

Cree una nueva versión de certificación inmutable, vincúlela a la versión anterior y al manifiesto de corrección, vuelva a ejecutar todas las reglas de conciliación afectadas y mueva de forma atómica el alias certificado solo tras la aprobación. Conserve la evidencia anterior para auditoría. Mida el tiempo de corrección por separado, ya que el SLI original de frescura no describe con qué rapidez se reparan los errores conocidos.

Pregunta de seguimiento 4: ¿Cómo previene la fatiga por alertas en cientos de conjuntos de datos?

Clasifique los conjuntos de datos por nivel de impacto en el consumidor, exija un responsable directo antes de emitir pages y alerte vía page únicamente ante amenazas accionables al SLO o fallas de compuertas estrictas. Agrupe fallas de reglas relacionadas bajo la dependencia rota más temprana, enrute advertencias a colas de revisión y compare periódicamente las alertas emitidas con los incidentes reales del consumidor. Retire o rediseñe las reglas con precisión persistentemente baja.

Pregunta de seguimiento 5: ¿Qué cambia en un pipeline de streaming?

Reemplace la oportunidad de certificación diaria por ventanas de tiempo de eventos o minutos para el consumidor. Defina la frescura desde el tiempo de evento hasta el estado consultable, la completitud a partir de watermarks cerrados u offsets de origen, y el comportamiento de corrección para eventos tardíos. Utilice alertas basadas en burn rate en ventanas cortas y largas, manteniendo invariantes estrictos por registro o por clave que deban poner los datos en cuarentena de inmediato.

Pregunta de seguimiento 6: ¿Cómo evaluaría una herramienta de calidad de datos?

Comience evaluando el ajuste con el contrato en lugar del recuento de funcionalidades. Verifique reglas a nivel de fila y de agregación, unicidad de claves compuestas, ejecución incremental, evidencia de registros fallidos, resultados versionados, compuertas de orquestación, metadatos de ownership, APIs, enrutamiento de alertas y costo a escala de producción. Ejecute la suite de fallas inyectadas en cada candidata; un dashboard atractivo no compensa la falta de conciliación de extremo a extremo ni una compuerta de despliegue no ejecutable.