U idealnom svijetu inženjera, arhitektura je uvijek lijepa.U stvarnom svijetu velikih sustava, morate napraviti kompromise. trade-off between Write Speed and Read Speed. Ali u našem slučaju, rad s petabajtima podataka u AWS-u, ovaj kompromis nije pogodio našu brzinu – pogodio je brzinu. . wallet Izgradili smo sustav koji savršeno piše podatke, ali svaki put kada se čita iz arhiva, on je izgorio kroz proračun na najbolji način koji se može zamisliti. Ovo je priča o tome kako smo ga optimizirali kako bismo ga učinili učinkovitijim i troškovno učinkovitijim! Dio 0: Kako smo na kraju potrošili 100.000 dolara na AWS pristojbe! Istinita priča: prije nekoliko mjeseci, jedan od naših arhitekata rješenja želio je izvesti uzorak s rijetke web stranice s niskim prometom kako bi predstavio proizvod potencijalnom klijentu. Budući da su podaci za ovu "redku" stranicu raspršeni po milijunima arhiva uz mjesta s velikim prometom, sustav je pokušao vratiti gotovo polovicu našeg cijelog povijesnog skladišta kako bi pronašao te nekoliko stranica. Ta iskrena pogreška nas je na kraju koštala $100,000 in AWS fees! Sada sam odmah popravio API bug (i dodao stroge granice), ali arhitektonska ranjivost je ostala. Dozvolite mi da vam ispričam priču o svijetlim podacima arhitektura: kako sam vozio sustav u zamku "jeftinog" skladištenja i kako sam se popeo pomoću . WEB Arhiva Rearrange Pipeline WEB Arhiva WEB Arhiva 1. dio: Naslijeđe „Pisati prvo“ Kada sam počeo raditi na Web Arhivu, sustav je već unio ogroman protok podataka: milijune zahtjeva po minuti, desetke terabajta dnevno. Oslanjao se na najtrajniju strategiju za sustave visokog protoka: Append-only Log. 
 
 
 
 
 Podaci (HTML, JSON) su bufferirani. Nakon što buffer dosegne ~300 MB, on je "zaplenjen" u TAR arhivu. Arhiva leti na S3. Nakon 3 dana, datoteke se premještaju u S3 Glacier Deep Archive. Za fazu unosa, ovaj dizajn je bio besprijekoran. skladištenje podataka u Deep Archive košta novčiće, a prohodnost pisanja je gotovo neograničena. Problem: Ta cijena nijansa Arhitektura je savršeno funkcionirala za pisanje... sve dok klijenti nisu došli tražiti povijesne podatke. 
 
 
 The System Writes by Time: Arhiv od 12:00 sati sadrži mješavinu cnn.com, google.com i shop.xyz. Sustav čita po domeni: Klijent traži: "Dajte mi sve stranice iz cnn.com za posljednju godinu." Evo greške koja je inspirirala ovaj članak. kao i mnogi inženjeri, navikao sam razmišljati o Ali, zaboravio sam na . latency, IOPS, and throughput AWS Glacier billing model Mislila sam: "Pa, preuzimanje nekoliko tisuća arhiva je sporo (48 sati), ali to nije tako skupo." AWS ne naplaćuje samo za API poziv, već i za ($ po GB prikupljen) The Reality: volume of data restored Učinak “zlatnog bajta” Zamislite da klijent traži 1000 stranica iz jednog domena.Budući da je logika pisanja bila kronološka, te stranice mogu biti raspršene preko 1000 različitih TAR arhiva. Da biste klijentu dali ovih 50 MB korisnih podataka, događa se katastrofa: 
 
 
 
 
 Sustav mora pokrenuti obnovu za 1000 arhiva. Iz “zamrzivača” izlazi 300 GB podataka (1000 arhiva × 300 MB). AWS nas naplaćuje za vraćanje 300 GB. Izvadim potrebnih 50 MB i bacim preostalih 299,95 GB . Plaćali smo da vratimo terabajte smeća samo da bismo izvukli zrna zlata. Problem koji se pretvorio u financijsku crnu rupu Data Locality 2. dio: Ispravljanje pogreške: Preuređenje plinovoda Nisam mogao brzo promijeniti metodu unosa – dolazni tok je previše paralelan i masivan da bi se mogao sortirati "na putu" (iako radim na tome), a trebalo mi je i rješenje koje je funkcioniralo za već arhivirane podatke. Dakle, ja sam dizajnirao , proces u pozadini koji "defragmentira" arhiv. Rearrange Pipeline To je asincroni ETL (Extract, Transform, Load) proces, s nekoliko kritičnih ključnih komponenti: 
 
 
 
 
 
 
  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 Rezultati Ova promjena radikalno je promijenila ekonomiju proizvoda: 
 
 
 
 Preciznost točke: Sada, kada klijent zatraži cnn.com, sustav vraća samo podatke u kojima cnn.com živi. Učinkovitost: Ovisno o granularnosti zahtjeva (uvedenje domene u odnosu na specifične URL-ove putem regexa), postigao sam smanjenje od 10% do 80% u preuzimanju podataka o smeću (što je izravno proporcionalno troškovima). Budući da preuzimanje povijesnih podataka više nije agonizirajuće skupo, sada možemo priuštiti ekstrakciju masivnih skupova podataka za obuku AI modela, provođenje dugoročnih istraživanja tržišta i izgradnju baze znanja za agencijske AI sustave za razmatranje (mislite specijalizirane pretraživače). Mi smo najam Bright Data širi web arhiv još više. ako vam se sviđa: 
 
 
 
 
 
 distribuirani sustavi visoke učinkovitosti, inženjering podataka u velikim razmjerima, Izgradnja pouzdanih plinovoda pod stvarnim opterećenjem, Pushing Node.js do svojih apsolutnih granica, Rješavanje problema koji se ne pojavljuju u nastavnim knjigama Tada bih volio razgovarati. Mi zapošljavamo snažne Node.js inženjere kako bismo pomogli izgraditi sljedeću generaciju Web Arhiva. Imati iskustvo u inženjeringu podataka i ETL-u vrlo je povoljno. . brightdata@brightdata.com brightdata@brightdata.com brightdata@brightdata.com Više ažuriranja dolazi dok nastavljam razmjenjivati arhiv - i dok nastavljam pronalaziti nove i kreativne načine da ga razbijem!

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.

Izgradnja Petabyte-Scale web arhiva

About Author

KOMENTARI

VIJESI OZNAKE

OVAJ ČLANAK JE PREDSTAVLJEN U

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps