En el mundo ideal de un ingeniero, la arquitectura es siempre hermosa. En el mundo real de los sistemas a gran escala, tienes que hacer compromisos. trade-off between Write Speed and Read Speed. Normalmente, usted sacrifica uno por el otro, pero en nuestro caso, trabajando con petabytes de datos en AWS, este compromiso no golpeó nuestra velocidad. . wallet Hemos construido un sistema que escribió datos perfectamente, pero cada vez que se leía desde el archivo, se quemaba a través del presupuesto de la manera más dolorosa posible.Después de todo, leer petabytes de AWS cuesta dinero para la transferencia de datos, las cuentas de solicitudes y las recuperaciones de clase de almacenamiento... ¡mucho dinero! Esta es la historia de cómo lo optimizamos para que sea más eficiente y rentable! Parte 0: ¡Cómo terminamos gastando $ 100.000 en tarifas de AWS! Historia verdadera: hace unos meses, uno de nuestros arquitectos de soluciones quería sacar una muestra de exportación de un sitio web raro y con poco tráfico para demostrar el producto a un cliente potencial. Debido a que los datos para este sitio "raro" se dispersaron a través de millones de archivos junto con sitios de alto tráfico, el sistema intentó restaurar casi la mitad de nuestro almacenamiento histórico completo para encontrar esas pocas páginas. Un error que finalmente nos costó la vida $100,000 in AWS fees! Ahora, corregí el error de API de inmediato (y añadió límites estrictos), pero la vulnerabilidad arquitectónica permaneció. Déjame contarle la historia de los datos brillantes Arquitectura: cómo llegué al sistema a la trampa del almacenamiento “barato” y cómo salí usando un . Archivo web Rearrange Pipeline Archivo web Archivo web Parte 1: El legado de “Escribir primero” Cuando empecé a trabajar en el Web Archive, el sistema ya estaba ingiriendo un enorme flujo de datos: millones de solicitudes por minuto, decenas de terabytes por día. Se basó en la estrategia más duradera para los sistemas de alto rendimiento: Append-only Log. 
 
 
 
 
 Los datos (HTML y JSON) están almacenados. Una vez que el buffer alcanza ~300 MB, es “sealado” en un archivo TAR. El archivo se desvía a S3. Después de 3 días, los archivos se mueven a S3 Glacier Deep Archive. Para la fase de ingestión, este diseño fue perfecto. almacenar datos en el Archivo Profundo cuesta centavos, y el rendimiento de escritura es prácticamente ilimitado. El problema: esa tonalidad de precio La arquitectura funcionó perfectamente para la escritura... hasta que los clientes vinieron pidiendo datos históricos. 
 
 
 The System Writes by Time: Un archivo de 12:00 PM contiene una mezcla de cnn.com, google.com y shop.xyz. El sistema lee por dominio: El cliente le pide: "Dame todas las páginas de cnn.com para el último año". Aquí está el error que inspiró este artículo. Como muchos ingenieros, estoy acostumbrado a pensar en Pero yo olvidé el . latency, IOPS, and throughput AWS Glacier billing model Pensé: “Bueno, recuperar unos pocos miles de archivos es lento (48 horas), pero no es tan caro”. AWS cobra no solo por la llamada de la API, sino por la ($ por GB recuperado) The Reality: volume of data restored El efecto del “byte de oro” Imagínese que un cliente solicita 1.000 páginas de un único dominio. Debido a que la lógica de escritura era cronológica, estas páginas se pueden distribuir a través de 1.000 diferentes archivos TAR. Para dar al cliente estos 50 MB de datos útiles, se produce un desastre: 
 
 
 
 
 El sistema debe activar una restauración para 1000 archivos. Se extraen 300 GB de datos del “congelador” (1000 archivos × 300 MB). AWS nos cobra por restaurar 300 GB. Se extraen los 50 MB necesarios y se eliminan los otros 299,95 GB. Estábamos pagando para restaurar terabytes de basura sólo para extraer granos de oro. Un problema que se ha convertido en un agujero negro. Data Locality Parte 2: Corregir el error: La reorganización del gasoducto No pude cambiar rápidamente el método de ingestión – el flujo de entrada es demasiado paralelo y masivo para ordenar “en el vuelo” (aunque estoy trabajando en eso), y necesitaba una solución que funcionara para los datos ya archivados, también. Por lo tanto, he diseñado el , un proceso de fondo que “defragmenta” el archivo. Rearrange Pipeline Este es un proceso ETL (Extract, Transform, Load) asíncrono, con varios componentes críticos: 
 
 
 
 
 
 
  It makes no sense to sort data that clients aren’t asking for. Thus, I direct all new data into the pipeline, as well as data that clients have specifically asked to restore. We overpay for the retrieval the first time, but it never happens a second time. Selection: 
 
  Multiple workers download unsorted files in parallel and organize buffers by domain. Since the system is asynchronous, I don’t worry about the incoming stream overloading memory. The workers handle the load at their own pace. Shuffling (Grouping): 
 
 
  I write the sorted files back to S3 under a new prefix (to distinguish sorted files from raw ones). Rewriting: 
 
 
 Before:   →  2024/05/05/random_id_ts.tar [cnn, google, zara, cnn] After:   →  2024/05/05/cnn/random_id_ts.tar [cnn, cnn, cnn...]  
 
 
  In Snowflake, the metadata table is append-only. Doing   or   is prohibitively expensive. Metadata Swap: MERGE INTO UPDATE 
 
 The Solution: I found it was far more efficient to take all records for a specific day, write them to a separate table using a JOIN, delete the original day’s records, and insert the entire day back with the modified records. I managed to process   in just a few hours on a 4X-Large Snowflake warehouse. 300+ days and 160+ billion UPDATE operations El resultado Este cambio cambió radicalmente la economía del producto: 
 
 
 
 Precisión de punto: Ahora, cuando un cliente solicita cnn.com, el sistema solo restaura los datos en los que vive cnn.com. Eficiencia: Dependiendo de la granularidad de la solicitud (introducir dominios vs. URLs específicas a través de regex), logré una reducción de 10% a 80% en la recuperación de “datos de basura” (que es directamente proporcional al coste). Nuevas capacidades: Más allá de ahorrar dinero en los desechos, esto desbloqueó casos completamente nuevos de uso empresarial. Debido a que la recuperación de datos históricos ya no es agonizante, ahora podemos permitirnos extraer conjuntos de datos masivos para la formación de modelos de IA, llevar a cabo investigaciones de mercado a largo plazo y construir bases de conocimiento para sistemas de IA de agentes para razonar (pensemos en motores de búsqueda especializados). Estamos contratando Bright Data está escalando el Archivo Web aún más. 
 
 
 
 
 
 sistemas distribuidos de alto rendimiento, Ingeniería de datos a gran escala. Construir tuberías fiables bajo una carga real, Pushing Node.js a sus límites absolutos, Resolver problemas que no aparecen en los libros de texto. Entonces me encantaría hablar. Estamos contratando ingenieros Node.js fuertes para ayudar a construir la próxima generación del Archivo Web. Tener experiencia en ingeniería de datos y ETL es altamente ventajoso. . VADIMR@brightdata.com VADIMR@brightdata.com VADIMR@brightdata.com ¡Más actualizaciones llegan a medida que sigo escalando el archivo - y a medida que sigo encontrando nuevas y creativas maneras de romperlo!

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

This writer has a vested interest be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

Creación de un archivo web a escala de petabytes

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps