Inženiera ideālajā pasaulē arhitektūra vienmēr ir skaista. reālajā pasaulē liela mēroga sistēmās jums ir jādara kompromisi. trade-off between Write Speed and Read Speed. Bet mūsu gadījumā, strādājot ar petabītiem datu AWS, šis kompromiss nesasniedza mūsu ātrumu – tas sasniedza ātrumu. . wallet Mēs izveidojām sistēmu, kas perfekti rakstīja datus, bet katru reizi, kad tas lasīja no arhīva, tas sadedzināja budžetu visvairāk sāpīgā veidā, ko var iedomāties. Šis ir stāsts par to, kā mēs to optimizējām, lai padarītu to efektīvāku un rentablāku! 0 daļa: Kā mēs beidzot iztērējām 100 000 ASV dolāru AWS maksu! Īstais stāsts: pirms dažiem mēnešiem viens no mūsu risinājumu arhitektiem gribēja iegūt paraugu eksportu no reti sastopamas, zema satiksmes satura tīmekļa vietnes, lai demonstrētu produktu potenciālajam klientam. Tā kā dati par šo "reto" vietni tika izkaisīti miljoniem arhīvu kopā ar augstas satiksmes vietnēm, sistēma mēģināja atjaunot gandrīz pusi no visas mūsu vēsturiskās glabāšanas, lai atrastu šīs dažas lapas. Šī godīgā kļūda galu galā izmaksāja mums $100,000 in AWS fees! Tagad es nekavējoties laboja API kļūdu (un pievienoja stingrus ierobežojumus), bet arhitektūras ievainojamība palika. Ļaujiet man pastāstīt jums par Bright Data stāstu arhitektūra: kā es vadīju sistēmu “lētas” uzglabāšanas slazdā un kā es izkāpu, izmantojot . WEB arhīvs Rearrange Pipeline WEB arhīvs WEB arhīvs 1. daļa: “Rakstīt pirmais” mantojums Kad es sāku strādāt pie tīmekļa arhīva, sistēma jau uzņem milzīgu datu plūsmu: miljoniem pieprasījumu minūtē, desmitiem terabaitu dienā. Tā balstījās uz ilgtspējīgāko stratēģiju augstas caurlaidības sistēmām: Append-only Log. 
 
 
 
 
 Dati (HTML, JSON) ir buferēti. Kad buferis sasniedz ~300 MB, tas tiek “piezīmēts” TAR arhīvā. Arhīvs lido uz S3. Pēc 3 dienām faili tiek pārnesti uz S3 Glacier Deep Archive. Datu glabāšana dziļā arhīvā maksā centus, un rakstīšanas caurlaidība ir gandrīz neierobežota. Problēma: šī cenu nianse Arhitektūra darbojās perfekti rakstīšanai ... līdz brīdim, kad klienti nāca lūgt vēsturiskos datus. 
 
 
 Sistēma raksta pēc laika: arhīvs no 12:00 PM satur cnn.com, google.com un shop.xyz maisījumu. Sistēma lasa pēc domēna: Klients lūdz: "Dodiet man visas lapas no cnn.com par pēdējo gadu." Šeit ir kļūda, kas iedvesmoja šo rakstu. tāpat kā daudzi inženieri, es esmu pieradis domāt par Bet es aizmirsu par . latency, IOPS, and throughput AWS Glacier billing model Es domāju: “Labi, atgūt dažus tūkstošus arhīvu ir lēns (48 stundas), bet tas nav tik dārgi.” AWS iekasē ne tikai par API zvanu, bet arī par ($ par katru GB atgūtā) The Reality: volume of data restored “Zelta bajta” efekts Iedomājieties, ka klients pieprasa 1000 lapas no viena domēna.Tā kā rakstīšanas loģika bija hronoloģiska, šīs lapas var izplatīties 1000 dažādos TAR arhīvos. Lai sniegtu klientam šos 50 MB noderīgu datu, notiek katastrofa: 
 
 
 
 
 Sistēmai ir jāizdara atjaunošana 1000 arhīviem. Tas izņem 300 GB datu no “iesaldētāja” (1000 arhīvu × 300 MB). AWS rēķina mums par 300 GB atjaunošanu. Es izvilku nepieciešamos 50 MB un izmetu pārējos 299,95 GB . Mēs maksājām, lai atjaunotu terabaitus atkritumu tikai, lai iegūtu zelta graudus. Problēma, kas pārvēršas finanšu melnajā caurumā. Data Locality 2. daļa: Kļūdas novēršana: cauruļvada pārkārtošana Es nevarēju ātri mainīt uzņemšanas metodi - ienākošā plūsma ir pārāk paralēla un masīva, lai to sakārtotu "uz plūsmas" (lai gan es strādāju pie tā), un man vajadzēja risinājumu, kas arī darbotos jau arhivētiem datiem. Tāpēc es izstrādāju , fonu process, kas “defragmentē” arhīvu. Rearrange Pipeline Tas ir asimetrisks ETL (Extract, Transform, Load) process ar vairākiem kritiskiem pamata komponentiem: 
 
 
 
 
 
 
  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 Rezultāts Šīs izmaiņas radikāli mainīja produkta ekonomiku: 
 
 
 
 Tagad, kad klients lūdz cnn.com, sistēma atjauno tikai datus, kur cnn.com dzīvo. Efektivitāte: Atkarībā no pieprasījuma lieluma (domēna ievadīšana salīdzinājumā ar konkrētiem URL, izmantojot regex), es sasniedzu 10% līdz 80% samazinājumu “atkritumu datu” atgūšanā (kas ir tieši proporcionāls izmaksām). Jaunas iespējas: Ne tikai ietaupot naudu uz atkritumiem, tas atbloķēja pilnīgi jaunus biznesa lietojumu gadījumus.Tā kā vēsturisko datu atgūšana vairs nav briesmīgi dārga, mēs tagad varam atļauties iegūt milzīgus datu kopumus, lai apmācītu AI modeļus, veiktu ilgtermiņa tirgus izpēti un izveidotu zināšanu bāzes aģentu AI sistēmām, lai pārdomātu (domājiet par specializētām meklētājprogrammām). Mēs iznomājam Bright Data vēl vairāk paplašina tīmekļa arhīvu.Ja jums patīk: 
 
 
 
 
 
 augstas veiktspējas izplatītās sistēmas, Datu inženierija masveida mērogā, Uzticamu cauruļvadu izveide reālās pasaules slodzes apstākļos, Nospiediet Node.js līdz absolūtām robežām, Problēmu risināšana, kas neparādās mācību grāmatās Tad es gribētu runāt. Mēs pieņemam darbā spēcīgus Node.js inženierus, lai palīdzētu veidot nākamās paaudzes tīmekļa arhīvu. Datu inženierijas un ETL pieredze ir ļoti izdevīga. . vadimr@brightdata.com vadimr@brightdata.com vadimr@brightdata.com Vairāk atjauninājumu nāk, jo es turpinu mērogot arhīvu - un kā es turpinu atrast jaunus un radošus veidus, kā to izjaukt!

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.

Izveidot Petabyte mēroga tīmekļa arhīvu

About Author

KOMENTĀRI

PAKARINĀT TAGUS

ŠIS RAKSTS TIKS PĀRSTRĀDĀTS

Related Stories

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps