Cuando «también queremos ver los datos de la competencia en nuestro dashboard» llega al equipo de datos
Las fuentes internas son estables. Controlamos el esquema, los cambios se anuncian mediante notas de versión y, aun si fallan, existen procedimientos de reprocesamiento. Sin embargo, en el momento en que la dirección y los equipos de negocio solicitan «también queremos ver los precios de la competencia, las reseñas y los datos de mercado en el mismo dashboard», surge el problema de conectar al pipeline fuentes que están fuera de nuestro control.
No somos propietarios del esquema de la web externa. Los sitios objetivo cambian la estructura de sus pantallas sin previo aviso y las políticas de bloqueo se endurecen con frecuencia. Si la recolección de ayer queda vacía, hoy aparece un hueco en el dashboard, y los datos recibidos en Excel no pueden integrarse en un DAG. Este artículo aborda cómo integrar la recolección de datos web externos en pipelines internos de DW·data lake — es decir, el método de integración. La premisa es una: externalizar la propia recolección y que el equipo de datos se concentre en la carga, el modelado y el uso. Para tratar la web externa como un «sistema fuente bien gestionado», esa fuente debe establecer un contrato en el lenguaje del equipo de datos.
1. En qué se diferencian los datos web externos de las fuentes internas
Antes de conectarlos, hay que entender qué los hace distintos para poder diseñar la integración. En las tablas internas, los cambios de columna están dentro de nuestro procedimiento de lanzamiento, mientras que en la web externa el sitio fuente cambia lo que quiere. Un campo que existía ayer puede desaparecer hoy, y un mismo «precio» puede llegar mezclado como 12.900 wones y 12900. Además, las actualizaciones no son transacciones, sino procesos periódicos que se ejecutan en ciclos establecidos; por eso, el calendario del DAG y el SLA de frescura del dashboard deben alinearse con dicho ciclo.
La diferencia más peligrosa está en el modo de fallo. Cuando un trabajo interno falla, lanza una excepción y se detiene, pero el peor caso de un crawler externo es acumular valores vacíos fingiendo que tuvo éxito aunque se rompió. Si la estructura del sitio cambia y el selector deja de coincidir, el trabajo termina correctamente, pero los registros son 0 o están llenos de valores faltantes. Una validación que solo revise el volumen no puede detectarlo y, como las pantallas web pasadas no pueden recopilarse de nuevo, ese hueco es permanente. Por eso, la integración de datos externos no termina con «solo cargar»: la validación posterior a la carga forma parte del mismo conjunto.
2. Patrones de integración según el formato de entrega — no hay una única respuesta, se adapta a la especificación
La forma de conectar la recolección externa al pipeline depende del formato de entrega. Hay tres grandes opciones, y ninguna es más correcta que las demás: se elige la que encaje con la especificación del pipeline del equipo de datos.
| Patrón | Disparador del DAG | Cuándo es adecuado | Puntos a acordar |
|---|---|---|---|
| Sondeo de API | Calendario+sensor | El equipo de datos controla cuándo obtener los datos | Cursor incremental·paginación·autenticación |
| Carga directa a DB·S3 | Sensor de llegada | Gran volumen, evitar la carga del sondeo | Marcador de finalización·especificación de tabla/prefijo |
| Recepción de archivos | Sensor de archivos | Baja frecuencia, transición de Excel→pipeline | Nombre de archivo·ruta·esquema de hoja |
En el modelo de sondeo de API, los datos recopilados se proporcionan mediante una API y el DAG consulta únicamente los incrementos posteriores a la última marca de agua para cargarlos en la zona de aterrizaje. El punto clave es que el equipo de datos controla el cursor incremental para no volver a recibir intervalos ya recibidos. En el modelo de carga directa a DB·S3, el lado de recolección carga directamente en el DW·lake y el DAG solo detecta la llegada y ejecuta el procesamiento posterior. Aquí se acuerdan previamente reglas de marcadores de finalización (manifest·_SUCCESS) para evitar consumir datos que han llegado solo a medias. El modelo de recepción de archivos analiza y carga archivos normalizados que caen en una ubicación estándar, y es adecuado para el período de transición en el que una operación centrada en Excel se traslada a un pipeline.
Los tres patrones parten de que nosotros (el lado de recolección) y el equipo de datos alineamos primero la especificación de la interfaz. Se acuerdan la forma de respuesta de la API·la tabla DB/el prefijo S3·las reglas de archivo conforme al pipeline del equipo de datos, y se determina de forma inversa el formato de entrega a partir de esa especificación. Este acuerdo solo es posible si los formatos de entrega incluyen no solo Excel, sino también API·carga directa·entrega en S3.
3. Zona de aterrizaje — un mecanismo de amortiguación para que los niveles inferiores no se rompan aunque cambie la fuente externa
Si los datos externos se introducen directamente en la capa de modelado, el día que cambie la fuente se romperán por completo los niveles inferiores (dbt·dashboard). La zona de aterrizaje es el mecanismo de amortiguación, y allí se tratan tres aspectos.
Primero, la conservación del original raw. Se conserva una copia intacta de lo recibido tal cual está (texto original de respuesta de API, archivo original). Esto permite volver a analizar desde el original sin tener que recopilar de nuevo si la lógica de parsing era errónea o si más adelante se necesita otro campo. Dado que las pantallas web pasadas no pueden recuperarse, esta conservación del original es una red de seguridad de facto.
Segundo, el versionado de esquemas. El estándar con el que trabajamos junto al equipo de datos es el siguiente. Los cambios de esquema se notifican con antelación y tienen un período de deprecación; durante ese tiempo se proporcionan en paralelo las versiones antigua y nueva para que los niveles inferiores puedan migrar a su propio ritmo. Por ejemplo, se sigue entregando price_daily.v1 mientras también se ofrece v2, que incorpora la columna currency; el dbt inferior cambia la referencia cuando está preparado y, tras terminar la deprecación, se retira v1. De este modo, «la fuente se rediseñó ayer y hoy murió el dashboard» pasa a ser «operación en paralelo hasta el próximo trimestre, con migración dentro de ese plazo». Como la responsabilidad del cambio y el período de amortiguación están en el contrato, el equipo de datos no es llamado de improviso a apagar incendios.
Tercero, se trata el backfill como un procedimiento estándar. Cuando la recolección quedó vacía varios días o se deben completar nuevos campos también para períodos pasados, nosotros volvemos a recopilar especificando el período y las condiciones, y tras recargar en la zona de aterrizaje el DAG vuelve a modelar solo ese intervalo. La premisa es diseñarlo de forma idempotente mediante sustitución de particiones·claves de upsert, para que no se acumulen duplicados aunque se introduzca de nuevo el mismo período. Como la ventana de recolección está de nuestro lado, el equipo de datos solo necesita indicar «qué período se debe repetir».
4. Validación posterior a la carga — detectar valores faltantes silenciosos dentro del DAG
Los «valores faltantes silenciosos» de la sección 1 solo pueden detectarse mediante validación posterior a la carga. Se coloca una puerta DQ antes de publish para impedir que los datos que no la superen sean promovidos a los niveles inferiores. En vez de que los datos rotos lleguen hasta el dashboard, se detienen en la zona de aterrizaje y se genera una alerta. La puerta suele revisar cuatro cosas: que el número de registros no haya caído bruscamente por debajo del límite inferior esperado (valores faltantes silenciosos), que la tasa de valores faltantes en campos obligatorios esté por debajo del umbral (recolección parcial), que no existan flags de anomalías de parsing (reorganización estructural) y que la hora de recolección esté dentro del SLA de freshness (frescura).
Para que el equipo de datos no tenga que crear las reglas DQ desde cero, entregamos junto con los datos metadatos para validación. Incluyen la hora de recolección (freshness), las condiciones de recolección (qué términos de búsqueda·categorías·rangos), la URL fuente (linaje·auditoría), el número de registros (caídas bruscas frente a lo esperado) y flags de valores faltantes/anomalías. La monitorización no se coloca solo en el crawler, sino tanto en la fuente (recolección) como en el pipeline (carga). Si se detecta una anomalía o retraso en la recolección, avisamos al canal del equipo de datos (Slack·webhook) y compartimos también el tiempo estimado de recuperación, para poder responder «por qué está vacío y cuándo se completará».
5. Catálogo·linaje — responder a «¿de dónde salió este número?»
Cuando los datos externos llegan al dashboard, tarde o temprano en una auditoría o reunión ejecutiva surgirá la pregunta: «¿cuál es la fuente de este precio de la competencia?». Para responder, los metadatos de origen·frecuencia deben estar registrados en el catálogo y el linaje. Para que puedan usarse directamente en ese registro, proporcionamos el dominio/URL de la fuente, la frecuencia de recolección, las condiciones de recolección (alcance objetivo), la versión actual del esquema y el hecho de que esta fuente es operada de forma externalizada. Se superpone con los metadatos de validación, pero añade elementos desde la perspectiva del catálogo.
Si estos metadatos se completan al registrar el dataset, en el gráfico de linaje se pueden rastrear hacia atrás las métricas del dashboard hasta la URL fuente. Un estado en el que «¿de dónde salió este número?» se responde con unos pocos clics — eso es haber incorporado los datos externos a la gobernanza al mismo nivel que las fuentes internas. Aquí convergen los motivos para alinear esquema·backfill·metadatos con el equipo de datos. La fuente externa debe entregarse en un formato que pueda registrarse formalmente en el catálogo; así se convierte en un «sistema fuente gestionado».
Por último, está la frescura. La recolección externa es un proceso periódico que se ejecuta en un ciclo establecido, por lo que el SLA del dashboard también debe definirse de acuerdo con ese ciclo. Si el proceso se ejecuta una vez al día, el dashboard debe diseñarse como un «indicador actualizado diariamente», y conviene indicar explícitamente la hora de recolección del lote mediante textos como «a las ○:○○». Así la operación no se desalineará. Es más seguro para el equipo de datos y los equipos de negocio comunicar la frescura no como «cuán reciente es», sino como «a partir de qué momento del lote».
Lo que esta integración deja al equipo de datos
El punto central de integrar la recolección web externa en un pipeline es colocar una fuente incontrolable detrás de una interfaz controlable. Si el esquema se encapsula mediante un contrato de versiones, los fallos mediante una puerta DQ, el origen mediante metadatos de catálogo y el reprocesamiento mediante un procedimiento estándar de backfill, los datos externos pueden tratarse como fuentes internas.
La última decisión es quién asume la operación continua detrás de esa interfaz — respuesta a bloqueos, seguimiento de rediseños de sitios, monitorización de recolección y reparación. Si el equipo de datos asume esto, el personal que opera los DAG terminará desgastado por el mantenimiento de la recolección externa. Nosotros asumimos por una tarifa mensual fija el desarrollo·mantenimiento·respuesta a bloqueos·monitorización de recolección, y entregamos al equipo de datos una fuente con contrato de esquema·metadatos de validación·metadatos de catálogo. Al pasar por recolección→depuración→análisis de IA y entregar datos estructurados listos para cargar, en lugar de raw, también se reduce la carga de organización de la zona de aterrizaje.
La conclusión es una. Externalizar la recolección·mantenimiento web externo para tratarlo como un sistema fuente bien gestionado, y que el equipo de datos se concentre en la carga·modelado·uso. De hecho, operamos de forma externalizada un monitoreo en línea masivo de un organismo regulador como pipeline periódico, y las demandas de gran escala·multidepartamentales también se centralizan en una sola ventanilla mediante este método.
Artículos recomendados
- Hasta que los datos de crawling se convierten en una decisión
- 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 recolección de datos para terminar con las inversiones duplicadas
Empiece ahora mismo
Si nos indica qué especificación tiene su pipeline actual — si se trata de orquestación con Airflow, un data lake en S3 o carga directa a un DW — diseñaremos junto a usted, empezando por la interfaz, cómo conectar la recolección web externa a esa especificación. Alineamos el contrato de esquema·los metadatos de validación·los metadatos de catálogo en el lenguaje del equipo de datos.
