Construyendo un archivo Web a escala de petabytes

En el mundo ideal de un ingeniero, la arquitectura siempre es hermosa. En el mundo real de los sistemas a gran escala, hay que hacer compromisos. Uno de los problemas fundamentales que un ingeniero debe considerar desde el principio es el vicioso compromiso entre la Velocidad de Escritura y la Velocidad de Lectura.

Normalmente, sacrificas una por la otra. Pero en nuestro caso, trabajando con petabytes de datos en AWS, este compromiso no afectó nuestra velocidad–afectó nuestra cartera.

Construimos un sistema que escribía datos perfectamente, pero cada vez que leía del archivo, consumía el presupuesto de la manera más dolorosa imaginable. Después de todo, leer petabytes de AWS cuesta dinero por transferencia de datos, recuento de solicitudes y recuperaciones de clase de almacenamiento... ¡Mucho dinero!

¡Esta es la historia de cómo lo optimizamos para hacerlo más eficiente y rentable!

Parte 0: ¡Cómo Acabamos Gastando $100,000 en Tarifas de AWS!

Historia real: hace unos meses, uno de nuestros arquitectos de soluciones quería extraer una muestra de exportación de un sitio web raro, de poco tráfico para demostrar el producto a un cliente potencial. Debido a un error en la API, no se aplicó el límite de seguridad en el recuento de archivos.

Como los datos de este sitio "raro" estaban dispersos entre millones de archivos junto con sitios de alto tráfico, el sistema intentó restaurar casi la mitad de todo nuestro almacenamiento histórico para encontrar esas pocas páginas.

Ese error honesto terminó costándonos casi $100,000 en tarifas de AWS!

Ahora, arreglé el error de la API inmediatamente (y agregué límites estrictos), pero la vulnerabilidad arquitectónica permaneció. Era una bomba de tiempo...

Déjame contarte la historia de la arquitectura del Archivo Web de Bright Data: cómo llevé el sistema a la trampa del almacenamiento "barato" y cómo salí usando un Pipeline de Reorganización.

Parte 1: El Legado "Escribir Primero"

Cuando comencé a trabajar en el Archivo Web, el sistema ya estaba ingiriendo un flujo masivo de datos: millones de solicitudes por minuto, decenas de terabytes por día. La arquitectura fundamental se construyó con un objetivo principal: capturar todo sin pérdida de datos.

Se basaba en la estrategia más duradera para sistemas de alto rendimiento: Registro de solo anexar.

1. Los datos (HTML, JSON) se almacenan en búfer.
2. Una vez que el búfer alcanza ~300 MB, se "sella" en un archivo TAR.
3. El archivo vuela a S3.
4. Después de 3 días, los archivos se mueven a S3 Glacier Deep Archive.

Para la fase de ingestión, este diseño era impecable. Almacenar datos en Deep Archive cuesta centavos, y el rendimiento de escritura es prácticamente ilimitado.

El Problema: Ese Matiz de Precios

La arquitectura funcionaba perfectamente para escribir... hasta que los clientes vinieron pidiendo datos históricos. Ahí es cuando me enfrenté a una contradicción fundamental:

• El Sistema Escribe por Tiempo: Un archivo de las 12:00 contiene una mezcla de cnn.com, google.com y shop.xyz.
• El Sistema Lee por Dominio: El cliente pregunta: "Dame todas las páginas de cnn.com del último año."

Aquí radica el error que inspiró este artículo. Como muchos ingenieros, estoy acostumbrado a pensar en latencia, IOPS y rendimiento. Pero pasé por alto el modelo de facturación de AWS Glacier.

Pensé: "Bueno, recuperar unos miles de archivos es lento (48 horas), pero no es tan caro".

La Realidad: AWS cobra no solo por la llamada a la API, sino por el volumen de datos restaurados ($ por GB recuperado).

El Efecto "Byte Dorado"

Imagina que un cliente solicita 1.000 páginas de un solo dominio. Como la lógica de escritura era cronológica, estas páginas pueden estar dispersas en 1.000 archivos TAR diferentes.

Para dar al cliente estos 50 MB de datos útiles, ocurre un desastre:

1. El sistema tiene que activar una Restauración para 1.000 archivos.
2. Levanta 300 GB de datos del "congelador" (1.000 archivos × 300 MB).
3. AWS nos factura por restaurar 300 GB.
4. Extraigo los 50 MB requeridos y desecho los otros 299,95 GB 🤯.

Estábamos pagando por restaurar terabytes de basura solo para extraer granos de oro. Era un clásico problema de Localidad de Datos que se convirtió en un agujero negro financiero.

Parte 2: Corrigiendo el Error: El Pipeline de Reorganización

No podía cambiar rápidamente el método de ingestión–el flujo entrante es demasiado paralelo y masivo para ordenarlo "al vuelo" (aunque estoy trabajando en eso), y necesitaba una solución que funcionara también para datos ya archivados.

Así que diseñé el Pipeline de Reorganización, un proceso en segundo plano que "desfragmenta" el archivo.

Este es un proceso ETL asíncrono (Extraer, Transformar, Cargar), con varios componentes críticos:

1. Selección: No tiene sentido ordenar datos que los clientes no están solicitando. Por lo tanto, dirijo todos los datos nuevos al pipeline, así como los datos que los clientes han pedido específicamente restaurar. Pagamos de más por la recuperación la primera vez, pero nunca sucede una segunda vez.

   \

2. Barajado (Agrupación): Múltiples trabajadores descargan archivos no ordenados en paralelo y organizan búferes por dominio. Como el sistema es asíncrono, no me preocupo de que el flujo entrante sobrecargue la memoria. Los trabajadores manejan la carga a su propio ritmo.

   \

3. Reescritura: Escribo los archivos ordenados de vuelta a S3 bajo un nuevo prefijo (para distinguir archivos ordenados de los brutos).

• Antes: 2024/05/05/random_id_ts.tar → [cnn, google, zara, cnn]
• Después: 2024/05/05/cnn/random_id_ts.tar → [cnn, cnn, cnn...]

1. Intercambio de Metadatos: En Snowflake, la tabla de metadatos es de solo anexar. Hacer MERGE INTO o UPDATE es prohibitivamente caro.

• La Solución: Descubrí que era mucho más eficiente tomar todos los registros de un día específico, escribirlos en una tabla separada usando un JOIN, eliminar los registros del día original e insertar todo el día de vuelta con los registros modificados. Logré procesar más de 300 días y más de 160 mil millones de operaciones UPDATE en solo unas horas en un almacén Snowflake 4X-Large.

El Resultado

Este cambio alteró radicalmente la economía del producto:

• Precisión Exacta: Ahora, cuando un cliente solicita cnn.com, el sistema restaura solo los datos donde vive cnn.com.
• Eficiencia: Dependiendo de la granularidad de la solicitud (dominio completo vs. URLs específicas mediante regex), logré una reducción del 10% al 80% en la recuperación de "datos basura" (lo cual es directamente proporcional al costo).
• Nuevas Capacidades: Más allá de solo ahorrar dinero en volcados, esto desbloqueó casos de uso empresariales completamente nuevos. Como recuperar datos históricos ya no es agonizantemente caro, ahora podemos permitirnos extraer conjuntos de datos masivos para entrenar modelos de IA, realizar investigaciones de mercado a largo plazo y construir bases de conocimiento para que los sistemas de IA agénticos razonen (piensa en motores de búsqueda especializados). Lo que antes era una misión suicida financiera ahora es una operación estándar.

Estamos Contratando

Bright Data está escalando aún más el Archivo Web. Si disfrutas:

• Sistemas distribuidos de alto rendimiento,
• Ingeniería de datos a escala masiva,
• Construir pipelines confiables bajo carga del mundo real,
• Llevar Node.js a sus límites absolutos,
• Resolver problemas que no aparecen en los libros de texto...

Entonces me encantaría hablar contigo.

Estamos contratando ingenieros fuertes de Node.js para ayudar a construir la próxima generación del Archivo Web. Tener experiencia en ingeniería de datos y ETL es altamente ventajoso. No dudes en enviar tu CV a [email protected].

Más actualizaciones vendrán mientras continúo escalando el archivo, ¡y mientras sigo encontrando formas nuevas y creativas de romperlo!

\