El pipeline que funcionaba perfectamente hasta ayer está vacío esta mañana
Si se trata de una fuente interna, esto no suele ocurrir. Para cambiar un esquema se coordina previamente, antes de eliminar una columna se avisa y, si surge un problema, hay una persona responsable. Pero las fuentes que provienen de la web externa, como precios de competidores, reseñas y datos de mercado, son diferentes.
Un día, el sitio objetivo rehace la sección de reseñas con React, mueve la ubicación donde muestra los precios u oculta elementos que antes se veían al iniciar sesión. Sin previo aviso. En ese momento, un parser que funcionaba bien hasta ayer devuelve valores vacíos, el modelo de dbt los deja pasar tal cual y los datos de ayer quedan como huecos en el dashboard. El equipo de negocio pregunta: «¿Por qué los datos no cuadran?», y el equipo de datos corrige el parser de madrugada.
Este artículo organiza, desde la perspectiva de los contratos de datos (Data Contract), por qué esta situación se repite y cómo diseñar responsabilidades partiendo de que las roturas ocurrirán.
Por qué la web se rompe continuamente
Un contrato de datos es un acuerdo explícito entre la fuente y el consumidor que establece: «Estos datos se proporcionan con esta forma, significado y frecuencia». No es una simple definición de esquema; es también un acuerdo que incluye quién hace qué y cuándo si se produce un cambio.
En los sistemas internos, este contrato funciona como una norma organizativa. Si el equipo de la fuente quiere cambiar un esquema, debe notificarlo; antes de eliminar una columna, debe establecer un período de deprecación; y cuando algo se rompe, existe una persona responsable dentro del organigrama. Lo esencial es que la fuente es una parte dispuesta a colaborar. Es posible dialogar, coordinar calendarios y exigir responsabilidades.
La dificultad de los datos web externos reside en que esta premisa deja de ser válida. El sitio objetivo no es parte de nuestro contrato. No tiene en cuenta las circunstancias de nuestro pipeline, no nos notificará cambios y tampoco podemos solicitar un rollback. Además, las páginas web no se crearon originalmente como entradas para pipelines. Como se trata de interpretar inversamente como datos una interfaz diseñada para personas, las siguientes características desestabilizan el contrato.
- Rediseños sin previo aviso: las renovaciones de marketing y los cambios de framework pueden modificar de un día para otro la estructura del DOM y el método de renderizado (SSR→CSR).
- Pruebas A/B y pantallas según condiciones: la misma URL devuelve pantallas diferentes en cada acceso, y los elementos visibles cambian según la región, el inicio de sesión, el nivel de membresía o el dispositivo. Si no se registra también bajo qué condiciones se visualizaron los datos, el significado del valor de un mismo campo puede cambiar silenciosamente.
- Datos faltantes parciales debido a antibots y bloqueos: cuando se activa un bloqueo, CAPTCHA o límite de tasa, no dejan de llegar todos los datos, sino que faltan solo algunos. Los datos «reducidos pero aparentemente normales» hacen que los procesos descendentes calculen agregaciones erróneas silenciosamente.
El punto común es que la premisa de las fuentes internas —que el esquema es estable— no se cumple en la web externa. Por ello, el contrato de datos para la web externa no debe tratar sobre «no se romperá», sino sobre quién será responsable de detectar, corregir y recopilar de nuevo los datos cuando se rompa.
Por qué un pequeño rediseño se convierte en un problema para toda la organización
Un pequeño rediseño de un sitio se propaga hacia los procesos descendentes. Cuando las reglas de parsing y el DOM real dejan de coincidir, los campos faltan o los valores se transforman en la fase de recopilación; si esto pasa sin filtrarse en la tabla de carga, llega a las transformaciones de dbt y genera una propagación silenciosa de NULL y agregaciones incorrectas, lo que finalmente deriva en huecos en los dashboards y decisiones equivocadas.
Hay dos factores que amplían el radio de impacto. El primero es el fallo silencioso. Es preferible que el parsing lance una excepción y se detenga. Lo peligroso es cuando devuelve cadenas vacías o NULL como si fueran valores normales y los procesos descendentes los dejan pasar: el pipeline está en verde, pero las cifras son incorrectas. El segundo es definir un contrato de campos demasiado amplio. Si los modelos descendentes y los dashboards hacen referencia directa a todos los campos recopilados, basta con que el sitio cambie un solo elemento para que se vean afectados todos los resultados que dependen de él.
Diseño de amortiguación — evitar que los procesos descendentes colapsen aunque algo se rompa
No es posible eliminar la inestabilidad de la web externa. En su lugar, se introduce una capa de amortiguación para impedir que esa inestabilidad se propague hacia los procesos descendentes.
Conservación de raw. Conservamos por separado los originales recopilados (snapshots HTML, respuestas originales, imágenes previas al OCR, etc.) y los resultados del parsing. Si se descubre que el parsing era incorrecto y se conserva el original, es posible recuperar datos históricos mediante un nuevo parsing sin necesidad de recopilar de nuevo. Si se descartan los originales, un bug de parsing se convierte inmediatamente en una pérdida permanente de datos. La conservación de raw es la base común para la recopilación de nuevo, la auditoría y el linaje.
Minimización del contrato de campos. Se reducen a lo esencial los campos de los que dependen los procesos descendentes y que se incluyen en el contrato. Los elementos secundarios que el sitio modifica con frecuencia no se incluyen en el contrato y se conservan únicamente en raw. Los campos clave contratados se validan en cuanto a tipo, obligatoriedad y rango de valores, y no se dejan fluir hacia los procesos descendentes si incumplen las reglas. Cuanto más limitado sea el contrato, menor será también el radio de impacto de un rediseño.
Detección de cambios. Si solo se comprueba si el parsing lanzó una excepción, se pasan por alto los fallos silenciosos. Por eso se supervisa la forma de los propios resultados. Se verifica si el número de registros cambió drásticamente respecto a lo habitual, si la tasa de valores faltantes en campos clave aumentó de repente o si la distribución de valores se sale del rango normal (por ejemplo, precios de 0 o anormalmente altos), y se avisa al canal del equipo de datos si se detecta al menos una de estas señales. El objetivo es detectar primero los rediseños mediante cambios en la forma de los datos, antes de que los descubra una persona.
Sobre esta amortiguación, así es como trabajamos con los equipos de datos. El esquema se define inicialmente junto con el equipo de datos. Se acuerda qué campos serán contratos clave y se alinean el tipo, la aceptación de nulos y el significado de cada campo; después, los procesos descendentes de dbt y los dashboards hacen referencia a ese contrato. Incluso cuando es necesario realizar cambios, no sustituimos unilateralmente el esquema. Notificamos el cambio con antelación, establecemos un período de deprecación y proporcionamos en paralelo las versiones anterior y nueva durante ese período para dar tiempo a los procesos descendentes a migrar; solo entonces retiramos la versión anterior. De esta forma, aunque el sitio cambie, los procesos descendentes pueden migrar dentro de una ventana anunciada y el rediseño no se convierte directamente en un hueco en el dashboard.
Diseño de responsabilidades partiendo de que las roturas ocurrirán
La amortiguación técnica por sí sola no es suficiente. Lo que realmente paraliza el trabajo es una situación en la que el contrato no indica quién debe corregir algo cuando se rompe. Por ello, un contrato de datos debe incluir, además del esquema, los propietarios de la detección, la corrección y la recopilación de nuevo.
| Propiedad | Qué debe especificarse en el contrato |
|---|---|
| Detección | Quién opera las señales de anomalía, a qué canal se notifica y cuál es el tiempo objetivo de recuperación. El responsable de la detección no es el consumidor, sino quien opera la recopilación |
| Corrección | Quién es responsable de reparar las reglas cuando el parser se rompe debido a un rediseño del sitio. Si está externalizado, el proveedor |
| Recopilación de nuevo(backfill) | Si existe un procedimiento estándar para rellenar los huecos del período afectado |
Asignar la responsabilidad de la corrección al proveedor es el valor esencial de la externalización. Evita que el personal que opera los DAG del equipo de datos tenga que asumir el mantenimiento continuo, como la respuesta a bloqueos, el seguimiento de cambios en sitios y la reparación de parsers, permitiendo que el equipo de datos se concentre en la carga, el modelado y el uso de los datos.
La recopilación de nuevo se trata como un procedimiento estándar, no como una excepción. Se rellenan los datos indicando período y condiciones, pero partiendo de cargas idempotentes para evitar que se acumulen duplicados incluso si se carga varias veces con la misma clave, y se completan con precisión solo los intervalos afectados mediante marcas de agua y cursores incrementales. Junto con ello, se entregan metadatos utilizables inmediatamente para validación posterior a la carga (DQ), auditoría y linaje. La hora de recopilación y las condiciones de recopilación (región, inicio de sesión) sirven como base para interpretar el significado de los valores; la URL de origen y la frecuencia de recopilación se utilizan para registrar el catálogo y el linaje; y el número de registros y las señales de valores faltantes/anomalías se incorporan a las puertas de validación automática. Además, se deja un marcador de finalización (manifest/_SUCCESS) para que los procesos descendentes puedan determinar que la carga terminó completamente, evitando que la orquestación ejecute transformaciones sobre cargas parciales. Solo así es posible responder, durante una auditoría, a la pregunta: «¿De dónde salió esta cifra?».
En resumen, el contrato de datos para la web externa no es la promesa de que «no se romperá», sino el acuerdo sobre quién será responsable de detectar, corregir y recopilar de nuevo los datos cuando se rompa, y hasta cuándo se recuperará. Esta propiedad debe estar escrita en el contrato para que las fuentes web externas puedan tratarse internamente como sistemas de fuentes bien gestionados.
Resumen
La razón fundamental por la que los datos web externos se rompen continuamente es que, a diferencia de las fuentes internas, la fuente no es una parte colaboradora del contrato. Los rediseños sin previo aviso, las pruebas A/B y las pantallas según condiciones destruyen la premisa de estabilidad del esquema. Por ello, el contrato de datos para la web externa no debe ser «no se romperá», sino un contrato que especifique los propietarios de la detección, la corrección y la recopilación de nuevo partiendo de que se romperá.
Hashscraper trabaja con los equipos de datos de esta manera. Definimos juntos el esquema, gestionamos los cambios mediante notificación previa y versiones en paralelo, tratamos la recopilación de nuevo mediante procedimientos estándar basados en cargas idempotentes y marcas de agua, y entregamos conjuntamente metadatos utilizables de inmediato para catálogo, linaje y DQ, además de marcadores de finalización. El desarrollo, el mantenimiento, la respuesta a bloqueos y la supervisión de la recopilación están incluidos en la externalización mediante tarifa mensual, para que el personal que opera los DAG no se desgaste con el mantenimiento de recopilaciones externas. También contamos con experiencia operando de forma externalizada pipelines regulares para la monitorización online a gran escala de un organismo regulador.
Externalizar la recopilación y el mantenimiento de la web externa para tratarlos como sistemas de fuentes bien gestionados, y permitir que el equipo de datos se concentre en la carga, el modelado y el uso de los datos: este es el camino realista para incorporar de forma estable datos externos a los dashboards en la era de los rediseños de sitios.
Artículos recomendados
- Desde que los datos de crawling se convierten en decisiones
- Datos recibidos en Excel vs datos vistos en un dashboard — lo que cambia el formato de entrega
- Empresas donde cada departamento hace crawling por separado — gobernanza corporativa de recopilación de datos para acabar con la inversión duplicada
Empiece ahora mismo
Revisaremos juntos qué contrato necesita la fuente web externa conectada actualmente a su pipeline para evitar que un solo rediseño deje vacío su dashboard. Diseñamos el proceso adaptado al pipeline de su equipo de datos, desde la definición del esquema hasta la notificación de cambios, la responsabilidad de recopilación de nuevo y las especificaciones de entrega.
