Aufbau eines Web-Archivs im Petabyte-Maßstab

In der idealen Welt eines Ingenieurs ist die Architektur immer schön. In der realen Welt von Hochskalensystemen muss man Kompromisse eingehen. Eines der grundlegenden Probleme, über das ein Ingenieur von Anfang an nachdenken muss, ist der heimtückische Kompromiss zwischen Schreibgeschwindigkeit und Lesegeschwindigkeit.

Normalerweise opfert man das eine für das andere. Aber in unserem Fall, bei der Arbeit mit Petabytes an Daten in AWS, traf dieser Kompromiss nicht unsere Geschwindigkeit – er traf unser Portemonnaie.

Wir haben ein System gebaut, das Daten perfekt schrieb, aber jedes Mal, wenn es aus dem Archiv las, verbrannte es das Budget auf die schmerzhafteste vorstellbare Weise. Schließlich kostet das Lesen von Petabytes aus AWS Geld für Datenübertragung, Anfragezählungen und Speicherklassenabrufe... Eine Menge Geld!

Dies ist die Geschichte, wie wir es optimiert haben, um es effizienter und kostengünstiger zu machen!

Teil 0: Wie wir am Ende 100.000 $ für AWS-Gebühren ausgegeben haben!

Wahre Geschichte: Vor einigen Monaten wollte einer unserer Lösungsarchitekten einen Beispielexport von einer seltenen, wenig besuchten Website ziehen, um das Produkt einem potenziellen Kunden zu demonstrieren. Aufgrund eines Fehlers in der API wurde das Sicherheitslimit für die Dateianzahl nicht angewendet.

Da die Daten für diese "seltene" Website über Millionen von Archiven neben stark frequentierten Websites verstreut waren, versuchte das System, fast die Hälfte unseres gesamten historischen Speichers wiederherzustellen, um diese wenigen Seiten zu finden.

Dieser ehrliche Fehler kostete uns am Ende fast 100.000 $ an AWS-Gebühren!

Ich habe den API-Fehler sofort behoben (und strenge Limits hinzugefügt), aber die architektonische Schwachstelle blieb bestehen. Es war eine tickende Zeitbombe...

Lassen Sie mich Ihnen die Geschichte der Bright Data Web Archive Architektur erzählen: wie ich das System in die Falle des "billigen" Speichers getrieben habe und wie ich mit einer Rearrange Pipeline wieder herausgekommen bin.

Teil 1: Das "Write-First" Erbe

Als ich anfing, am Web Archive zu arbeiten, nahm das System bereits einen massiven Datenstrom auf: Millionen von Anfragen pro Minute, Dutzende von Terabytes pro Tag. Die grundlegende Architektur wurde mit einem Hauptziel gebaut: alles ohne Datenverlust zu erfassen.

Es stützte sich auf die haltbarste Strategie für Hochdurchsatzsysteme: Append-only Log.

1. Daten (HTML, JSON) werden gepuffert.
2. Sobald der Puffer ~300 MB erreicht, wird er in ein TAR-Archiv "versiegelt".
3. Das Archiv fliegt zu S3.
4. Nach 3 Tagen werden die Dateien in S3 Glacier Deep Archive verschoben.

Für die Aufnahmephase war dieses Design makellos. Die Speicherung von Daten im Deep Archive kostet Pfennige, und der Schreibdurchsatz ist praktisch unbegrenzt.

Das Problem: Diese Preisgestaltungsnuance

Die Architektur funktionierte perfekt für das Schreiben... bis Kunden nach historischen Daten fragten. Da stand ich vor einem grundlegenden Widerspruch:

• Das System schreibt nach Zeit: Ein Archiv von 12:00 Uhr enthält eine Mischung aus cnn.com, google.com und shop.xyz.
• Das System liest nach Domain: Der Kunde fragt: "Gib mir alle Seiten von cnn.com für das letzte Jahr."

Hier liegt der Fehler, der diesen Artikel inspiriert hat. Wie viele Ingenieure bin ich es gewohnt, über Latenz, IOPS und Durchsatz nachzudenken. Aber ich habe das AWS Glacier Abrechnungsmodell übersehen.

Ich dachte: "Nun, das Abrufen einiger tausend Archive ist langsam (48 Stunden), aber es ist nicht so teuer."

Die Realität: AWS berechnet nicht nur für den API-Aufruf, sondern auch für das Volumen der wiederhergestellten Daten ($ pro abgerufenem GB).

Der "Goldenes Byte" Effekt

Stellen Sie sich vor, ein Kunde fordert 1.000 Seiten von einer einzigen Domain an. Da die Schreiblogik chronologisch war, können diese Seiten über 1.000 verschiedene TAR-Archive verteilt sein.

Um dem Kunden diese 50 MB nützlicher Daten zu geben, geschieht eine Katastrophe:

1. Das System muss eine Wiederherstellung für 1.000 Archive auslösen.
2. Es hebt 300 GB Daten aus dem "Gefrierschrank" (1.000 Archive × 300 MB).
3. AWS stellt uns die Wiederherstellung von 300 GB in Rechnung.
4. Ich extrahiere die benötigten 50 MB und werfe die anderen 299,95 GB weg 🤯.

Wir zahlten für die Wiederherstellung von Terabytes an Müll, nur um Goldkörner zu extrahieren. Es war ein klassisches Datenlokalitäts-Problem, das sich in ein finanzielles schwarzes Loch verwandelte.

Teil 2: Den Fehler beheben: Die Rearrange Pipeline

Ich konnte die Aufnahmemethode nicht schnell ändern – der eingehende Strom ist zu parallel und massiv, um "on the fly" zu sortieren (obwohl ich daran arbeite), und ich brauchte eine Lösung, die auch für bereits archivierte Daten funktioniert.

Also entwarf ich die Rearrange Pipeline, einen Hintergrundprozess, der das Archiv "defragmentiert".

Dies ist ein asynchroner ETL-Prozess (Extract, Transform, Load) mit mehreren kritischen Kernkomponenten:

1. Auswahl: Es macht keinen Sinn, Daten zu sortieren, nach denen Kunden nicht fragen. Daher leite ich alle neuen Daten in die Pipeline, sowie Daten, die Kunden speziell zur Wiederherstellung angefordert haben. Wir zahlen beim ersten Mal zu viel für den Abruf, aber es passiert kein zweites Mal.

   \

2. Shuffling (Gruppierung): Mehrere Worker laden unsortierte Dateien parallel herunter und organisieren Puffer nach Domain. Da das System asynchron ist, mache ich mir keine Sorgen, dass der eingehende Strom den Speicher überlastet. Die Worker bewältigen die Last in ihrem eigenen Tempo.

   \

3. Neuschreiben: Ich schreibe die sortierten Dateien unter einem neuen Präfix zurück zu S3 (um sortierte Dateien von Rohdateien zu unterscheiden).

• Vorher: 2024/05/05/random_id_ts.tar → [cnn, google, zara, cnn]
• Nachher: 2024/05/05/cnn/random_id_ts.tar → [cnn, cnn, cnn...]

1. Metadata-Austausch: In Snowflake ist die Metadatentabelle nur zum Anhängen. MERGE INTO oder UPDATE durchzuführen ist unerschwinglich teuer.

• Die Lösung: Ich fand heraus, dass es viel effizienter war, alle Datensätze für einen bestimmten Tag zu nehmen, sie mit einem JOIN in eine separate Tabelle zu schreiben, die ursprünglichen Tagesdatensätze zu löschen und den gesamten Tag mit den modifizierten Datensätzen wieder einzufügen. Ich schaffte es, 300+ Tage und 160+ Milliarden UPDATE-Operationen in nur wenigen Stunden auf einem 4X-Large Snowflake-Warehouse zu verarbeiten.

Das Ergebnis

Diese Änderung veränderte die Wirtschaftlichkeit des Produkts radikal:

• Punktgenaue Genauigkeit: Wenn ein Kunde jetzt nach cnn.com fragt, stellt das System nur die Daten wieder her, in denen cnn.com lebt.
• Effizienz: Je nach Granularität der Anfrage (gesamte Domain vs. spezifische URLs über Regex) erreichte ich eine 10% bis 80% Reduzierung beim Abruf von "Müll-Daten" (was direkt proportional zu den Kosten ist).
• Neue Fähigkeiten: Über das bloße Sparen von Geld bei Dumps hinaus erschloss dies völlig neue Geschäftsanwendungsfälle. Da das Abrufen historischer Daten nicht mehr qualvoll teuer ist, können wir es uns jetzt leisten, massive Datensätze für das Training von KI-Modellen zu extrahieren, langfristige Marktforschung durchzuführen und Wissensdatenbanken für agentische KI-Systeme aufzubauen, über die sie nachdenken können (denken Sie an spezialisierte Suchmaschinen). Was zuvor eine finanzielle Selbstmordmission war, ist jetzt ein Standardvorgang.

Wir stellen ein

Bright Data skaliert das Web Archive noch weiter. Wenn Sie Folgendes genießen:

• Hochdurchsatz-verteilte Systeme,
• Datenengineering in massivem Maßstab,
• Aufbau zuverlässiger Pipelines unter realer Belastung,
• Node.js an seine absoluten Grenzen bringen,
• Probleme lösen, die nicht in Lehrbüchern erscheinen...

Dann würde ich gerne mit Ihnen sprechen.

Wir stellen starke Node.js-Ingenieure ein, um die nächste Generation des Web Archive aufzubauen. Erfahrung im Datenengineering und ETL ist sehr vorteilhaft. Senden Sie Ihren Lebenslauf gerne an vadimr@brightdata.com.

Weitere Updates kommen, während ich das Archiv weiter skaliere – und während ich weiterhin neue und kreative Wege finde, es zu brechen!

\