Una tarea puede funcionar con diez objetivos y perder fiabilidad al pasar a miles. La clasificación de fallos y deduplicación, los límites de tasa y la concurrencia, la reanudación, los fallos de salida, las comprobaciones de consistencia y unas pocas métricas se vuelven esenciales a escala.
Un script de recopilación puede funcionar bien con diez objetivos y empezar a perder tasa de éxito al ampliarse a miles. Se añaden reintentos, se cambian proxies y se ajusta la concurrencia, pero los problemas siguen reapareciendo. Al investigar más, el bloqueo suele no estar en la lógica de análisis, sino en varias capas de ingeniería que faltan. A pequeña escala, estos problemas pueden no aparecer nunca.
Clasifica primero los fallos para que los reintentos tengan sentido
En la recopilación siempre habrá fallos. Lo importante es clasificarlos: las fluctuaciones de red y los reinicios de conexión pueden reintentarse de inmediato; una limitación temporal de tasa requiere esperar y reintentar con backoff; si un cambio en la estructura de la página hace que el análisis devuelva resultados vacíos, ni diez mil reintentos servirán, así que hay que registrarlo y generar una alerta; si el objetivo no existe, basta con marcar la tarea como completada; si un entorno o una salida de red no arranca, se cambia por otro y se reintenta.
Reintentar todo sin distinción es uno de los errores más comunes. Oculta dentro de bucles problemas que requieren intervención humana y, al mismo tiempo, desperdicia cuotas y capacidad de salida. También hace falta backoff: el intervalo entre reintentos debe aumentar; de lo contrario, un lote de tareas volverá a golpear el objetivo en la misma ventana temporal y agravará la limitación.
Los reintentos llevan directamente a la deduplicación. Una tarea puede ejecutarse varias veces por culpa de los reintentos, así que cada tarea necesita un identificador único y estable —por ejemplo, el valor obtenido tras normalizar la URL— y las escrituras deben ser idempotentes según ese identificador. Si no, cuantos más reintentos haya, más datos sucios se generan.
La limitación de tasa y la concurrencia son cosas distintas
Aumentar la concurrencia no garantiza mayor rendimiento. Hay tres restricciones actuando a la vez: cuánto puede soportar el sitio objetivo antes de activar limitaciones y reducir el rendimiento total, la memoria y CPU de la máquina local, y si un entorno o una sesión puede ejecutar varias tareas simultáneamente.
Un enfoque más estable es empezar con poca concurrencia y aumentar la carga gradualmente, observando juntos la tasa de éxito y el tiempo de respuesta para localizar el punto en el que el rendimiento empeora claramente. La limitación de tasa es otra cuestión: controla el ritmo de acceso a un mismo objetivo y no equivale a la concurrencia global. Si un lote reparte tareas entre varios sitios, cada sitio necesita su propio ritmo.
La reanudación depende de un estado persistente
En una tarea que dura varias horas, una interrupción es normal; volver a empezar desde cero suele ser demasiado costoso. La condición es persistir el estado: pendiente, en ejecución, completada, además del número de reintentos, la próxima hora válida de ejecución y el tipo de error. Al iniciar el proceso, la cola debe restaurarse desde el almacenamiento, no reconstruirse desde memoria.
Mantener la cola solo en memoria es una implementación muy común que parece funcionar. En cuanto el proceso cae, se pierden todas las tareas en espera y las cuentas dejan de cuadrar.
Trata por separado los fallos de proxies y salidas de red
Que el objetivo bloquee una salida, que un proxy se desconecte o que un nodo regional cambie de comportamiento son hechos constantes a escala. No son excepciones raras, sino parte de la operación normal. Trata las salidas como recursos sustituibles: cuando una tarea falla, determina primero si el objetivo está limitando la tasa o si la salida no está disponible; aplica backoff en el primer caso y cambia de salida antes de reintentar en el segundo. También conviene registrar la tasa de fallos de cada salida y retirar los grupos que se degraden claramente.
A la inversa, si todas las tareas comparten una sola salida, una tarea puede romper la ruta y afectar a todas las demás. Después, para diagnosticarlo, habrá que reconstruir desde los registros cuál fue la tarea que provocó el problema.
Comprobación de consistencia de datos
Que el proceso termine no significa que los datos sean correctos. Después de guardarlos hay que poder responder varias preguntas: ¿coincide el número de tareas completadas con el número de filas almacenadas?, ¿qué porcentaje de resultados de análisis está vacío?, ¿ha aumentado de forma anómala la tasa de campos críticos ausentes?, ¿cuántas filas duplicadas hay?
Estas comprobaciones no tienen que ser complejas. Basta con revisar muestras por lote, pero alguien debe mirar los resultados. A gran escala, los datos incorrectos pueden ser más problemáticos que no tener datos.
Qué métricas vigilar
No hace falta acumular métricas. Bastan unas pocas que reflejen el estado del sistema.
- Tasa de éxito y distribución de tipos de fallo, para ver qué errores están aumentando
- Longitud de la cola y tiempo medio de espera; un atasco que crece de forma sostenida indica un desajuste entre entrada y capacidad de proceso
- Número de entornos activos y procesos relacionados; un crecimiento sostenido en una sola dirección suele indicar fugas en la liberación de recursos
- Producción por unidad de tiempo, para detectar si la limitación de tasa está frenando el rendimiento
- Tasa de fallos de las salidas, para decidir si conviene sustituir un grupo de nodos
Si cualquiera de estas métricas mantiene una tendencia unidireccional durante mucho tiempo, revisa primero la liberación de recursos y la lógica de reintentos.
Separa la capa de entorno
Al considerar todos estos puntos juntos aparece la misma conclusión: la capa de entorno debe gestionarse por separado de los scripts. El agrupamiento de entornos exige una planificación centralizada en lugar de tener entornos dispersos por cada script; la liberación de recursos necesita un estado consultable en vez de depender de que cada script se recupere por sí solo; reintentar con otro entorno o con otra salida solo funciona si los entornos pueden programarse de forma independiente.
El script debe ocuparse de la lógica; la capa de entorno, de los recursos y la identidad. En una arquitectura de este tipo, PurpleMark cubre esa capa ofreciendo recursos de entorno que pueden crearse por lotes, vincularse a salidas de red independientes y consultarse por estado.
Límites de cumplimiento
Poder escalar no significa que se pueda recopilar cualquier dato de cualquier forma. Respeta las reglas robots y los términos de servicio del sitio objetivo, no recopiles información personal, no eludas medidas técnicas de protección y controla la frecuencia de solicitudes para no afectar al funcionamiento normal del servicio. La estabilidad es una cuestión técnica; si la recopilación está permitida es otra. Ambas condiciones deben cumplirse.
