En el món ideal d'un enginyer, l'arquitectura és sempre bonica. En el món real de sistemes d'alta escala, has de fer compromisos. trade-off between Write Speed and Read Speed. Però en el nostre cas, treballant amb petabytes de dades a AWS, aquest compromís no va colpejar la nostra velocitat. . wallet Hem construït un sistema que escriu dades perfectament, però cada vegada que es llegeix de l'arxiu, es va cremar a través del pressupost de la manera més dolorosa possible. Després de tot, llegir petabytes d'AWS costa diners per a la transferència de dades, els comptes de sol·licituds i les recuperacions de classe d'emmagatzematge... Molts diners! Aquesta és la història de com l’hem optimitzat per fer-ho més eficient i rendible! Part 0: Com vam acabar gastant 100.000 dòlars en tarifes d'AWS! Història real: fa uns mesos, un dels nostres arquitectes de solucions volia treure una mostra d'exportació d'un lloc web rar i amb baix trànsit per demostrar el producte a un client potencial. Com que les dades d'aquest lloc "raro" es van dispersar a milions d'arxius juntament amb llocs d'alt trànsit, el sistema va intentar restaurar gairebé la meitat de tot el nostre emmagatzematge històric per trobar aquestes poques pàgines. Aquest error finalment ens va costar molt. $100,000 in AWS fees! Ara, vaig corregir el bug de l'API immediatament (i vaig afegir límits estrictes), però la vulnerabilitat arquitectònica va romandre. Us deixem la història de les dades brillants Arquitectura: com vaig arrossegar el sistema a la trampa de l'emmagatzematge "baix" i com vaig sortir utilitzant un . Arxiu web Rearrange Pipeline Arxiu web Arxiu web Part 1: El llegat de la “escrit-primera” Quan vaig començar a treballar en l'Arxiu Web, el sistema ja estava ingerint un enorme flux de dades: milions de sol·licituds per minut, desenes de terabytes per dia. Es va basar en l'estratègia més duradora per a sistemes d'alt rendiment: Append-only Log. 
 
 
 
 
 Les dades (HTML, JSON) són tamponades. Una vegada que el buffer arriba a ~300 MB, es “segella” en un arxiu TAR. L'arxiu es desplaça a l'S3. Després de 3 dies, els arxius es traslladen a S3 Glacier Deep Archive. Per a la fase d'ingestió, aquest disseny va ser perfecte.L'emmagatzematge de dades en l'Arxiu Profund costa cèntims, i el rendiment d'escriptura és pràcticament il·limitat. El problema: que el preu nuance L'arquitectura va funcionar perfectament per escriure... fins que els clients van venir a demanar dades històriques. 
 
 
 The System Writes by Time: Un arxiu de 12:00 PM conté una barreja de cnn.com, google.com i shop.xyz. El sistema llegeix per domini: El client demana: "Doneu-me totes les pàgines de cnn.com per a l'últim any". Aquí està l'error que va inspirar aquest article. Com molts enginyers, estic acostumat a pensar en Però m’he oblidat de la . latency, IOPS, and throughput AWS Glacier billing model Vaig pensar: “Bé, la recuperació d’uns pocs milers d’arxius és lenta (48 hores), però no és tan cara”. AWS cobra no només per la crida d'API, sinó per la ($ per GB recuperat) The Reality: volume of data restored L’efecte del “byte d’or” Imagineu-vos que un client sol·licita 1.000 pàgines d'un únic domini.Perquè la lògica d'escriptura era cronològica, aquestes pàgines es poden distribuir a través de 1.000 arxius TAR diferents. Per donar al client aquests 50 MB de dades útils, es produeix un desastre: 
 
 
 
 
 El sistema ha de desencadenar una restauració per a 1.000 arxius. Això treu 300 GB de dades de la “congeladora” (1.000 arxius × 300 MB). AWS ens factura per restaurar 300 GB. Extracto els 50 MB necessaris i llenço els altres 299,95 GB . Estàvem pagant per restaurar terabytes d'escombraries només per extreure grans d'or. Un problema que s’ha convertit en un forat negre. Data Locality Part 2: Corregir l'error: La reorganització del gasoducte No vaig poder canviar ràpidament el mètode d'ingestió -el flux d'entrada és massa paral·lel i massiu per ordenar "en el vol" (encara que estic treballant en això), i necessitava una solució que funcionés per a les dades ja arxivades, també. Per tant, he dissenyat el , un procés de fons que “defragmenta” l’arxiu. Rearrange Pipeline Aquest és un procés ETL (Extract, Transform, Load) asíncron, amb diversos components clau: 
 
 
 
 
 
 
  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 resultat Aquest canvi va alterar radicalment l'economia del producte: 
 
 
 
 Precisió de punt: ara, quan un client demana cnn.com, el sistema només restaura les dades on cnn.com viu. Eficiència: Depenent de la granularitat de la sol·licitud (introduir domini versus URLs específiques a través de regex), vaig aconseguir una reducció del 10% al 80% en la recuperació de "dades de deixalles" (que és directament proporcional al cost). Noves capacitats: Més enllà d'estalviar diners en els residus, això va desbloquejar casos d'ús de negocis completament nous. Atès que la recuperació de dades històriques ja no és agonitzantment cara, ara podem permetre'ns extreure conjunts de dades massius per a la formació de models d'IA, dur a terme investigacions de mercat a llarg termini i construir bases de coneixement per a sistemes d'IA d'agent per raonar (pensem en motors de cerca especialitzats). Estem contractant Bright Data està escalant l'Arxiu Web encara més. 
 
 
 
 
 
 Sistemes distribuïts d’alt rendiment, Enginyeria de dades a gran escala. Construir conductes fiables sota la càrrega del món real, Empenyent Node.js als seus límits absoluts, Resoldre problemes que no apareixen en els llibres de text. Llavors m’agradaria parlar. Estem contractant enginyers Node.js forts per ajudar a construir la propera generació de l'Arxiu Web. Tenir experiència en enginyeria de dades i ETL és molt avantatjós. . Càritas@brightdata.com Càritas@brightdata.com Càritas@brightdata.com Arriben més actualitzacions a mesura que continuo escalant l'arxiu, i a mesura que continuo trobant noves i creatives maneres de trencar-lo!

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ó d'un arxiu web Petabyte-Scale

About Author

COMENTARIS

Etiquetes penjant

AQUEST ARTICLE VA SER PRESENTAT A

Related Stories

The Jewel Robbery at the Grand Metropolitan

Startups of The Year: Meet the Education Industry

Meet Catchpoint: HackerNoon Company of the Week

Startups of The Year: Meet the Cybersecurity Industry

The Jewel Robbery at the Grand Metropolitan

Startups of The Year: Meet the Education Industry

Meet Catchpoint: HackerNoon Company of the Week

Startups of The Year: Meet the Cybersecurity Industry

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps