Arquitecturas de datos: cómo establecer prioridad de fuentes cuando el pipeline consume APIs heterogéneas
Arquitecturas de datos: cómo establecer prioridad de fuentes cuando el pipeline consume APIs heterogéneas
El pipeline funciona. Los datos llegan. Y aun así, el equipo de análisis se queja de que los resultados no reflejan lo que está pasando. La causa casi nunca está en el modelo analítico. Está aguas arriba: en cómo el pipeline trata todas las fuentes como si fueran iguales cuando no lo son.
Cuando un sistema consume APIs heterogéneas —distintos proveedores, distintos ritmos de actualización, distintos volúmenes, distintas fiabilidades— tratar cada fuente con el mismo peso destruye la calidad del dato agregado. Un artículo publicado hace seis horas no vale lo mismo que uno publicado hace seis minutos si el caso de uso es monitorización en tiempo casi real. Una fuente que devuelve el 80 % de las menciones relevantes no debería competir en igualdad de condiciones con otra que aporta el 5 %.
Establecer prioridad de fuentes no es un problema de negocio. Es un problema de arquitectura. Y tiene soluciones concretas.
Por qué el tratamiento uniforme de fuentes rompe la señal
La mayoría de los pipelines de ingesta nacen con una lógica igualitaria: cada fuente tiene su conector, cada conector escribe en la misma cola, el consumidor procesa en orden de llegada. Es simple. Escala bien al principio. Y genera deuda técnica severa en cuanto el número de fuentes crece.
El problema central es que las APIs externas no son homogéneas en tres dimensiones clave:
- Frescura: no todas actualizan con la misma frecuencia. Hay fuentes con ciclos de minutos y fuentes con ciclos de horas.
- Densidad de señal: el ratio entre menciones relevantes y ruido varía drásticamente entre fuentes. Una fuente puede tener una tasa de relevancia del 60 %; otra, del 8 %.
- Fiabilidad estructural: algunas APIs mantienen contratos estables durante meses; otras cambian esquemas o introducen campos nulos sin previo aviso.
Si el pipeline no diferencia, el consumidor aguas abajo recibe un flujo donde el dato crítico compite con ruido de baja frescura. El análisis resultante promedia señal con basura.
El modelo de prioridad por capas
Una aproximación práctica es definir un modelo de capas antes de diseñar el conector de cada fuente. Tres capas son suficientes para la mayoría de los casos:
Capa 1 — Fuentes primarias: alta frescura, alta densidad de señal, contrato estable. Son las fuentes que deben llegar siempre al pipeline, con la menor latencia posible. Si hay restricción de presupuesto de llamadas (modelo pay-as-you-go), estas fuentes consumen el primer bloque.
Capa 2 — Fuentes de contraste: frescura media, señal moderada. Añaden cobertura geográfica, temática o lingüística que las fuentes primarias no cubren. Se procesan en paralelo, pero con una cola de menor prioridad. Pueden tolerar latencias de hasta varios minutos sin romper el caso de uso.
Capa 3 — Fuentes complementarias: baja frescura, alta especialización. Aportan contexto histórico o nichos específicos. Se procesan en batch diferido. Nunca bloquean el flujo principal.
Este modelo no requiere infraestructura nueva. Se implementa con configuración en el orquestador (Airflow, Prefect, cualquier scheduler) y con colas diferenciadas en el broker de mensajes (Kafka, RabbitMQ).
Cómo calcular el peso de cada fuente
Asignar una fuente a una capa no puede ser una decisión subjetiva. Necesita métricas operativas. Un esquema funcional usa tres indicadores:
peso_fuente = (tasa_relevancia × 0.5) + (frescura_norm × 0.3) + (estabilidad_contrato × 0.2)
- tasa_relevancia: porcentaje de registros que superan el filtro de señal útil (definido por el caso de uso).
- frescura_norm: tiempo medio entre actualización de la fuente y llegada al pipeline, normalizado entre 0 y 1 (1 = más fresco).
- estabilidad_contrato: inverso de la tasa de cambios de esquema en los últimos 90 días. Una fuente que cambia el esquema cada semana puntúa bajo.
Con estos pesos calculados, se actualiza la asignación de capas en cada ciclo de revisión —mensual, o tras cualquier cambio mayor de proveedor. No es un proceso estático.
Dead-letter queues y fuentes que degradan en silencio
Uno de los riesgos más frecuentes en pipelines con múltiples APIs externas es la degradación silenciosa: una fuente de capa 1 empieza a devolver respuestas con campos clave vacíos, o su latencia de actualización pasa de minutos a horas, sin que ningún error explícito lo señale.
El pipeline no falla. Simplemente, la señal se degrada.
La solución no es solo monitorizar errores HTTP. Es instrumentar el pipeline con métricas de calidad de dato en tiempo de ingesta:
- Tasa de registros con campos obligatorios presentes.
- Distribución de timestamps de publicación (si la mayoría son de hace más de dos horas, la fuente ha degradado su frescura).
- Comparativa de volumen respecto a la media de las últimas 24 horas.
Cuando una fuente de capa 1 cae por debajo de un umbral en cualquiera de estas métricas, el pipeline la reclasifica automáticamente a capa 2 y activa una alerta. Las fuentes de capa 2 absorben la diferencia. Esto evita que el análisis final llegue al equipo de negocio con una degradación invisible.
En plataformas como FeedScale, donde el dato proviene del universo público de Internet a través de Text and Data Mining, esta reclasificación dinámica es especialmente relevante: el comportamiento de las fuentes públicas no es estable, y el pipeline necesita responder sin intervención manual.
Presupuesto de llamadas y prioridad: la conexión que se ignora
En modelos de consumo pay-as-you-go, la prioridad de fuentes tiene una consecuencia directa sobre el coste operativo. Si el presupuesto de llamadas se agota en fuentes de capa 2 o 3, el pipeline puede llegar al final del periodo sin haber cubierto las fuentes primarias que generan el 80 % del valor.
La solución es reservar cuotas por capa en el gestor de llamadas. Un esquema conservador:
| Capa | Cuota de llamadas |
|---|---|
| Primarias | 60 % |
| Contraste | 30 % |
| Complementarias | 10 % |
Estos porcentajes se revisan cuando cambia el catálogo de fuentes o el caso de uso. No son universales, son un punto de partida.
Empieza por medir antes de reorganizar
Antes de refactorizar el pipeline, la primera acción es auditar las fuentes actuales con los tres indicadores descritos. Es frecuente descubrir que una fuente que el equipo considera "primaria" tiene una tasa de relevancia inferior al 15 %, o que una fuente de capa 2 lleva meses siendo más fresca que la fuente principal.
Los datos del propio pipeline son el mejor argumento para priorizar la refactorización. Y la prioridad de fuentes es uno de los pocos cambios de arquitectura que puede mejorar la calidad del análisis sin añadir un solo proveedor nuevo.