- Aus der Erfahrung eines frühen BigQuery-Engineers lag der Engpass vieler Organisationen eher in der Art der Datennutzung und in der Kostenstruktur als in der Datengröße
- Bei BigQuery-Kunden und im Branchenfeedback waren die meisten Data Warehouses unter 1 TB groß, und selbst bei intensiv nutzenden Kunden lag der Median weit unter 100 GB
- Die Trennung von Storage und Compute in der Cloud hat die gespeicherte Datenmenge stark erhöht, doch der Bedarf an Analyse-Compute wächst nicht im gleichen Verhältnis, weil Analysen vor allem aktuelle Daten und Aggregate betreffen
- Bei BigQuery verarbeiteten 90 % der Abfragen von Kunden mit mehr als 1.000 US-Dollar Jahresausgaben weniger als 100 MB; selbst Kunden mit riesigen Datensätzen führten große Abfragen nicht häufig aus
- Alte Daten können wegen Regulierung, Rechtsstreitigkeiten, Bedeutungsverlust und spezieller Verarbeitungslogik zu Schulden werden; man sollte prüfen, ob Aggregieren, Löschen oder Zusammenfassen besser ist als das Aufbewahren der Rohdaten
Der Unterschied zwischen Big-Data-Angst und den tatsächlichen Engpässen
- Seit mehr als zehn Jahren wiederholt sich die Botschaft, dass es wegen der Datengröße schwierig sei, aus Daten umsetzbare Erkenntnisse zu gewinnen
- Darauf folgte die Empfehlung, neue Technologie für massive Skalierung zu kaufen; doch auch nach dem Kauf neuer Tools und der Migration von Legacy-Systemen tun sich viele Organisationen weiterhin schwer damit, ihre Daten zu verstehen
- Die Lage im Jahr 2023 unterscheidet sich von der Zeit, als die Big-Data-Warnungen begannen
- Die vorhergesagte Datenumwälzung ist nicht eingetreten
- Die Datenmengen sind zwar etwas gewachsen, die Hardware aber noch schneller
- Anbieter stellen weiterhin Skalierbarkeit in den Vordergrund, doch Praktiker beginnen zu hinterfragen, wie das mit ihren realen Problemen zusammenhängt
Kundendatengrößen aus der BigQuery-Erfahrung
- Der Autor, einer der Gründungsingenieure von Google BigQuery, demonstrierte in öffentlichen Präsentationen die Fähigkeit zur Verarbeitung großer Datenmengen, indem er eine 1-PB-Abfrage ausführte
- Später debugte er Probleme von BigQuery-Kunden, schrieb zwei Bücher mit und war ab 2018 als Product Manager für Kundengespräche und die Analyse von Produktmetriken zuständig
- Die überraschendste Beobachtung war, dass die meisten „BigQuery“-Nutzer in Wirklichkeit keine Big Data hatten
- Selbst Kunden mit großen Datenmengen hatten viele Workloads, die nur einen kleinen Teil des gesamten Datensatzes nutzten
- Beim Start von BigQuery wirkte die hohe Verarbeitungsgeschwindigkeit wie Science-Fiction, doch später holten auch traditionellere Verarbeitungsansätze auf
- Die Grafiken im Artikel sind keine exakten Zahlen, sondern handgezeichnete Skizzen aus der Erinnerung; wichtig ist nicht der genaue Wert, sondern die Form der Verteilung
- Die Grundlage bilden Abfragelogs, Postmortems von Deals, Benchmark-Ergebnisse, Support-Tickets, Kundengespräche, Service-Logs, öffentliche Blogposts und Intuition
Die meisten Organisationen haben gar nicht so viele Daten
- Verkaufsfolien mit „Big Data kommt“ vermittelten die Botschaft, dass bald alle von Daten überwältigt würden; doch auch zehn Jahre später ist diese Zukunft nicht eingetreten
- Betrachtet man die Größe von BigQuery-Kunden, lag die insgesamt gespeicherte Datenmenge bei der großen Mehrheit unter 1 TB
- Es gab zwar Kunden mit Hunderten PB an Daten, aber die Größen folgten einer schnell abfallenden Potenzgesetz-Verteilung
- Es gab Tausende Kunden, die weniger als 10 US-Dollar pro Monat für Storage zahlten, was etwa 0,5 TB entspricht
- Selbst unter Kunden, die den Dienst intensiv nutzten, lag die mediane Speichermenge deutlich unter 100 GB
- Auch in Gesprächen mit Branchenanalysten wie Gartner und Forrester kam das Feedback, dass die meisten Data Warehouses von Unternehmen kleiner als 1 TB seien
- Nach Branchengefühl lag eine angemessene Größe für ein Data Warehouse bei etwa 100 GB
- Das BigQuery-Team machte diese Größenordnung zu einem zentralen Fokus seiner Benchmark-Bemühungen
- Ein Investor untersuchte seine Portfoliounternehmen; selbst bei Tech-Unternehmen, bei denen relativ große Datenmengen wahrscheinlich sind, hatte das größte B2B-Unternehmen etwa 1 TB und das größte B2C-Unternehmen etwa 10 TB, während die meisten deutlich kleiner waren
- Auch Beispiele mittelgroßer Unternehmen zeigen, dass Daten nicht leicht riesig werden
- Selbst wenn 1.000 Kunden täglich je eine Bestellung und 100 Line Items erzeugen, liegen die Tagesdaten unter 1 MB; nach drei Jahren sind es etwa 1 GB
- Selbst mit 1 Million Leads und Dutzenden Kampagnen in einer Marketingdatenbank ist die Lead-Tabelle kleiner als 1 GB, und das Kampagnen-Tracking dürfte nur einige GB umfassen
- Selbst als SingleStore von 2020 bis 2022 ein schnell wachsendes Series-E-Unicorn war, kamen Financial Warehouse, Kundendaten, Marketingkampagnen-Tracking und Service-Logs zusammen nur auf einige GB
Die Illusion durch die Trennung von Storage und Compute
- Moderne Cloud-Datenplattformen setzen alle auf die Trennung von Storage und Compute, sodass Kunden nicht an einen einzelnen Formfaktor gebunden sind
- Diese Veränderung ist in der Datenarchitektur der letzten 20 Jahre möglicherweise wichtiger als Scale-out
- Statt schwer zu verwaltender Shared-Nothing-Architekturen ermöglicht eine Shared-Disk-Architektur, Storage und Compute unabhängig voneinander zu vergrößern
- Skalierbarer und ausreichend schneller Object Storage wie S3 und GCS lockert die Designbeschränkungen von Datenbanken
- In der Praxis wächst die Datengröße viel schneller als die Compute-Größe
- Daten entstehen im Lauf der Zeit; selbst in einem statischen Geschäft wächst die Speichermenge im Zeitverlauf linear
- Analysen beziehen sich meist auf aktuelle Daten, sodass der Compute-Bedarf nicht wie die Speichermenge wachsen muss
- Alte Daten ändern sich nicht; sie immer wieder zu scannen ist nahezu Verschwendung, und wichtige Antworten lassen sich als Aggregate erstellen
- Bei Kunden, die von On-Premises in die Cloud mit Trennung von Storage und Compute wechselten, nahm die Speichermenge oft stark zu, während sich der Compute-Bedarf kaum veränderte
- Ein großer Retail-Kunde von BigQuery hatte On-Premises ein Data Warehouse von etwa 100 TB, das nach der Cloud-Migration auf 30 PB anwuchs
- Die Speichermenge stieg um das 300-Fache, aber die Compute-Kosten stiegen nicht im gleichen Verhältnis, und das Unternehmen gab keine Milliarden Dollar für Analysen aus
- Diese Architektur zeigt, dass bei der Nutzung skalierbarer Object Stores viel weniger Compute als erwartet ausreichen kann und verteilte Verarbeitung möglicherweise gar nicht nötig ist
Reale Query-Workloads sind viel kleiner als die Gesamtdaten
- Die Datenmenge, die Analyse-Workloads verarbeiten, ist wahrscheinlich kleiner, als man intuitiv annimmt
- Dashboards werden häufig aus aggregierten Daten erstellt
- Nutzer betrachten vor allem die Daten der letzten Stunde, des letzten Tages oder der letzten Woche
- Kleine Tabellen werden häufiger abgefragt, riesige Tabellen selektiver
- Bei einer Analyse der Abfragen von BigQuery-Kunden mit mehr als 1.000 US-Dollar Jahresausgaben verarbeiteten 90 % der Abfragen weniger als 100 MB
- Die Analyse wurde auf mehrere Arten aufgeteilt, damit die Abfragemenge einzelner Kunden die Ergebnisse nicht verzerrt
- Reine Metadatenabfragen, die keine Daten lesen, wurden ausgeschlossen
- Abfragen im GB-Bereich tauchten erst in hohen Perzentilen auf, Abfragen im TB-Bereich waren sehr selten
- Selbst Kunden mit riesigen Datenmengen fragten riesige Daten kaum ab
- Wenn sie große Abfragen ausführten, dann meist zur Berichtserstellung; Performance hatte dabei keine Priorität
- Ein großes Social-Media-Unternehmen führte am Wochenende sehr große Abfragen für den Executive-Report am Montag aus, doch das war nur ein winziger Teil von Hunderttausenden Abfragen unter der Woche
- Moderne Analysedatenbanken nutzen mehrere Techniken, um die tatsächlich gelesenen Daten zu reduzieren
- Column Projection liest nur die benötigten Felder
- Partition Pruning liest nur einen engen Datumsbereich
- Segment-Eliminierung durch Clustering oder automatisches Micro-Partitioning nutzt Datenlokalität
- Berechnung auf komprimierten Daten, Projection und Predicate Pushdown reduzieren ebenfalls das I/O zum Abfragezeitpunkt
- Weniger I/O verringert die benötigte Rechenmenge und senkt Kosten und Latenz
- Verwandtes Material: Kosten von Cloud Data Warehouses senken
- Verwandtes Material: Performance-Engpässe in Data Warehouses diagnostizieren
Datenverarbeitungskosten üben Druck aus, kleiner abzufragen
- Dass Scale-out eine schnelle Verarbeitung ermöglicht, bedeutet nicht, dass die Verarbeitung billig ist
- Wenn man 1.000 Nodes einsetzt, um ein Ergebnis zu erhalten, können die Kosten sehr hoch werden
- Die 1-PB-Abfrage, die in der BigQuery-Demo ausgeführt wurde, kostete zum Listenpreis 5.000 US-Dollar
- Solche Ineffizienzen sind Teil der Big Data Tax, die Teams belastet, die nicht im PB-Maßstab arbeiten
- Der finanzielle Anreiz, die verarbeitete Datenmenge zu reduzieren, gilt auch ohne Abrechnungsmodell nach gescannten Bytes
- Ob BigQuery-Scan-Kosten oder Leerlaufkosten einer Snowflake-Instanz: große Cloud Data Warehouses können die Rechnung in die Höhe treiben
- Kleinere Abfragen ermöglichen kleinere Instanzen, die Abfragen werden schneller, und mehr parallele Ausführung wird möglich
Die meisten Daten werden kaum abgefragt
- Ein großer Anteil der verarbeiteten Daten sind aktuelle Daten von unter 24 Stunden
- Nach etwa einer Woche ist die Wahrscheinlichkeit, dass Daten abgefragt werden, ungefähr 20-mal niedriger als bei den Daten des jüngsten Tages
- Nach einem Monat bleiben Daten im Allgemeinen unverändert liegen und werden nur noch bei seltenen Report-Läufen abgefragt
- Die Altersverteilung gespeicherter Daten ist deutlich flacher als das Zugriffsmuster
- Viele Daten werden zwar schnell verworfen, aber viele Daten werden auch fortlaufend am Ende von Tabellen angehängt
- Selbst wenn die Daten des letzten Jahres nur 30 % der Gesamtdaten ausmachen, können sie 99 % der Datenzugriffe ausmachen
- Selbst wenn die Daten des letzten Monats nur 5 % der Gesamtdaten ausmachen, können sie 80 % der Datenzugriffe ausmachen
- Wenn Daten im Lauf der Zeit zur Ruhe kommen, wird das tatsächliche Working Set handhabbarer als erwartet
- Selbst bei einer 1-PB-Tabelle mit zehn Jahren Daten kann es sein, dass in der Praxis nur die Daten des aktuellen Tages häufig genutzt werden
- Die Daten des aktuellen Tages können komprimiert unter 50 GB liegen
Die Grenze der Einzelmaschine verschiebt sich ständig
- Wenn man Big Data als „passt nicht auf eine einzelne Maschine“ definiert, sinkt die Zahl der entsprechenden Workloads jedes Jahr
- Als 2004 das Google-MapReduce-Paper geschrieben wurde, passten typische Daten-Workloads häufig nicht auf eine einzelne Allzweckmaschine
- Als AWS 2006 EC2 startete, boten die Instanzen nur einen einzelnen Core und 2 GB RAM; viele Workloads passten nicht auf diese Maschine
- Heute nutzen Standardinstanzen bei AWS auf Basis physischer Server 64 Cores und 256 GB RAM
- Der RAM ist um zweistellige Faktoren größer als bei den frühen EC2-Instanzen von 2006
- Wer mehr für Memory-optimized Instances zahlt, kann den RAM nochmals um zweistellige Faktoren erhöhen
- Es stellt sich die Frage, wie viele Workloads wirklich mehr als 24 TB RAM oder 445 CPU-Cores brauchen
- In der Cloud steigen die Kosten großer VMs annähernd linear mit der Rechenleistung
- Eine VM, die einen ganzen Server nutzt, ist nur achtmal so teuer wie eine VM, die 1/8 des Servers nutzt
- Eine Performance ähnlich dem Benchmark mit 3.000 parallelen Nodes aus dem ursprünglichen Dremel-Paper lässt sich heute vermutlich auf einem einzelnen Node erreichen
Daten können Schulden statt Vermögenswerte sein
- Eine weitere Definition von Big Data ist: „ein Zustand, in dem es billiger ist, Daten weiter aufzubewahren, als zu entscheiden, was weggeworfen werden soll“
- Die Data Lakes vieler Organisationen sind eher riesige Sümpfe, die nicht deshalb gewachsen sind, weil sie gebraucht werden, sondern weil niemand sie gelöscht hat
- Man weiß nicht, was darin enthalten ist
- Man weiß nicht, ob Aufräumen sicher wäre
- Die Kosten der Datenaufbewahrung gehen über die physischen Kosten für gespeicherte Bytes hinaus
- Regulierungen wie GDPR und CCPA verlangen, die Nutzung bestimmter Daten nachzuverfolgen
- Manche Daten müssen innerhalb bestimmter Fristen gelöscht werden
- Wenn Telefonnummern zu lange in Parquet-Dateien eines Data Lakes verbleiben, kann das rechtliche Anforderungen verletzen
- Alte Daten können einer Organisation auch in Rechtsstreitigkeiten schaden
- So wie viele Organisationen die Aufbewahrungsdauer von E-Mails begrenzen, um potenzielle Haftung zu reduzieren, können auch Daten im Data Warehouse zu belastenden Beweisen werden
- Wenn Logs von vor fünf Jahren einen Sicherheitsbug im Code oder eine verfehlte SLA zeigen, kann längere Aufbewahrung die rechtliche Exponierung verlängern
- Auch Daten können wie Code durch Bit Rot an Bedeutung verlieren
- Menschen können vergessen, was ein spezielles Feld genau bedeutete
- Frühere Datenbugs können aus dem Gedächtnis verschwinden
- Zum Beispiel könnten für einen kurzen Zeitraum alle customer ids auf null gesetzt worden sein, oder eine riesige Betrugstransaktion könnte die Ergebnisse im dritten Quartal 2017 besser erscheinen lassen haben, als sie tatsächlich waren
- Die Business-Logik zum Abrufen alter Zeiträume kann immer komplexer werden, etwa: „vor 2019 revenue, 2019–2021 revenue_usd, ab 2022 revenue_usd_audited“
Prüfen, ob man zu den Big-Data-1 % gehört
- Big Data existiert tatsächlich, aber die meisten Menschen müssen sich vielleicht nicht darum sorgen
- Um zu entscheiden, ob man ein Big Data One-Percenter ist, kann man folgende Fragen stellen
- Erzeugt man wirklich enorme Datenmengen?
- Wenn ja, muss man dann wirklich enorme Datenmengen auf einmal verwenden?
- Wenn ja, sind sie wirklich so groß, dass sie nicht auf eine einzelne Maschine passen?
- Wenn ja, ist man dann nicht einfach nur jemand, der Daten hortet?
- Wenn ja, wäre es dann nicht besser, sie zusammenzufassen?
- Wenn auch nur eine dieser Fragen mit „Nein“ beantwortet wird, kommt man möglicherweise für eine neue Generation von Daten-Tools infrage, die zur tatsächlich vorhandenen Datengröße passt
- Als verwandtes Beispiel werden moderne BigQuery-Alternativen genannt
- Organisationen sollten sich nicht von einer Datengröße einschüchtern lassen, die sie vielleicht irgendwann haben könnten, sondern Tools und Aufbewahrungsrichtlinien an der tatsächlich vorhandenen Datengröße und den realen Abfragemustern ausrichten
1 Kommentare
Hacker-News-Kommentare
Eine Fangfrage, die wir bei einem früheren Arbeitgeber gern stellten, wenn wir Data Scientists einstellten, lautete: „Welche Stack/Architektur würdest du bauen, wenn die Anforderung lautet, dass es bis zu 6 TiB Daten gibt?“
Wenn dann großspurig von BigQuery, Hadoop und Ähnlichem die Rede war und man nach Hardware-/Software-/Lizenzkosten fragte, kamen oft Schätzungen von mehreren Zehntausend Dollar pro Jahr heraus.
Am Ende bestand, wer verstand, dass 6 TiB eine Datenmenge sind, die sechs Personen im Raum auf ihre Smartphones verteilt speichern könnten; dass eine Enterprise-HDD für 199 Dollar genügt, oder drei davon für Redundanz; und dass man das Ganze als CSV mehrfach in den Speicher laden und sogar mit
awk-Skripten verarbeiten könnte.Auch ich kann leicht in den Fehler verfallen, dass alles wie ein Nagel aussieht, wenn man einen Hammer gelernt hat. Aber im Recruiting war es ein Ausschlusskriterium, kein Größengefühl für „echtes Big Data“ zu haben.
Statt aus so einer Antwort zu schließen, dass jemand alles übermäßig auslegt, ist es treffender, davon auszugehen, dass er in einer künstlichen Situation, in der der Interviewer in der überlegenen Position ist, in eine Fangfrage gelaufen ist.
Kürzlich hatte ich ein technisches Interview mit einem Interviewer mit ähnlicher Seniorität und Erfahrung, habe die Antwort vermasselt, und der Interviewer reagierte auf meine schlechte Antwort wertend. Wären die Rollen vertauscht gewesen, hätte ich ihn mit einem Thema, in dem ich mich besser auskenne, genauso in Verlegenheit bringen können.
Als Interviewer sollte man besonders darauf achten, die überlegene Position nicht zu missbrauchen. Das schadet auch dem Unternehmen und ist auch für die Person vor einem nichts Gutes.
„Beratungsservice: Du kommst mit deinem Big-Data-Problem zu mir, ich sage dir: ‚Dein Datensatz passt in den RAM‘, und du zahlst mir 10.000 Dollar dafür, dass du 500.000 Dollar sparst.“
Vor ein paar Jahren zeigte mir ein Director ein von der IT gebautes System mit Hadoop, API-Gateway, mehreren Entwicklern und Kosten von mehreren Hunderttausend Dollar pro Jahr. Als ich sagte, dass man es beim aktuellen Umfang und beim absehbaren künftigen Umfang auch problemlos mit einem USB-Laufwerk an seinem Laptop und ein paar Python-Skripten betreiben könnte, war er sehr gereizt, und danach durfte ich nie wieder an diesem Projekt mitwirken.
Ich sehe das als Teil eines im Unternehmen verbreiteten Kreislaufs aus Angeberei. Die Struktur lässt nicht zu, zuzugeben: „Wir machen hier etwas Einfaches.“
awk, und selbst wenn doch: 6 TB bei jeder Query ohne Partitionierung oder spaltenorientierte Speicherung mit einer einzelnen CPU durchzuscannen, ist immer langsam.Für solche Zwecke war BigQuery meistens in Ordnung. Die Konsolenoberfläche reicht für Ad-hoc-Analysen, und viele Tools wie Metabase oder Tableau lassen sich ebenfalls anbinden.
Wenn man richtig partitioniert, sind die Kosten auch nicht überzogen, und falls es zum Problem wird, kann man Rollup-Tabellen hinzufügen.
.parquet-Dateien werden völlig unterschätzt, und viele kennen dieses Format immer noch nicht.Anders als CSV bewahrt es Datentypen, ist zehnmal kleiner als CSV, sodass aus 6 TB 600 GB werden, und das Lesen ist 50-mal schneller. Außerdem ist es ein offener Standard der Apache Foundation.
Man kann nicht so leicht hineinschauen wie bei CSV, aber dieser Kompromiss lohnt sich. Überall dort, wo CSV zum Download angeboten wird, würde ich mir wünschen, dass auch
.parquetmit angeboten wird.Insgesamt stimme ich vielen Teilen des Artikels zu, aber es gibt ein paar Einschränkungen. Erstens ist MongoDB als Referenzpunkt ungeeignet. Ich habe noch nie etwas gesehen, was MongoDB tut und PostgreSQL nicht besser könnte; Big-Data-Lösungen sind nicht NoSQL/MongoDB, sondern meist spaltenorientierte Datenbanken, MapReduce, Cassandra und Ähnliches.
Zweitens muss man Erfolg einplanen. 95 % der Unternehmen werden keine Unicorns, aber wenn man auf die übrigen 5 % zielt, kommt man ohne Vorbereitung nicht dorthin. Der Grund, warum man schon bei 5 Kunden mit Blick auf Skalierbarkeit entwirft, ist, dass man den Moment exponentiellen Wachstums nutzen will, wenn er kommt.
Die zentrale Lehre stimmt aber. Die meisten Daten sind nicht groß, und selbst Daten über jeden Menschen auf der Welt passen in ein 100-Dollar-Chromebook. Die meisten Daten werden selten abgerufen und die Queries sind klein; der erste Schritt bei Big-Data-Arbeiten besteht oft darin, Terabytes auf die tatsächlich benötigten Größenordnungen von GB, MB, manchmal KB zu reduzieren. Durch Regulierung steigen auch die Datenkosten.
Die Leute planen nicht nur, sie implementieren es meist auch gleich. Wenn man die nächsten drei Monate plant, kann man viel agiler und produktiver sein. Wenn man nicht ausführt, kann man kein Unicorn werden.
Es wirkt wie eine Kombination aus Second-System-Syndrom und Survivorship Bias. Die Leute, die das Chaos eines guten MVP aufgeräumt haben, beschweren sich: „Das hätten wir damals machen sollen.“ Aber die Unternehmen, die im Voraus geplant und entworfen hatten, haben nicht überlebt und sind daher gar nicht Gegenstand der Beschwerden.
Dem Rest stimme ich fast vollständig zu, aber dieser Teil wirkte falsch, daher konnte ich ihn nicht einfach übergehen.
Die Runway eines Startups ist begrenzt, und wenn Engineers Geld für Dinge ausgeben, die sich erst in Jahren auszahlen, erhöht das die Wahrscheinlichkeit, dass man scheitert, bevor dieser Zeitpunkt erreicht ist.
Dass ein Produkt eine so starke Traktion bekommt, entsteht normalerweise durch einen Zusammeneffekt aus vorhandener Nutzerbasis und Bedarf. Selbst wenn man beim Wachstum beim Hinzufügen neuer Nutzer ins Straucheln gerät, ist es unwahrscheinlich, dass die bestehenden Nutzer zum alten Produkt zurückkehren oder woandershin wechseln.
Beim früheren Twitter gehörte es zum Alltag, jeden Tag den Fail Whale zu sehen, aber die meisten gingen nicht weg, und es kam auch nicht zu einer Massenabwanderung zu besser skalierenden Alternativen. Produkte, die ein solches exponentielles Wachstum erleben, sind an sich selten, und währenddessen mit Skalierung zu kämpfen und schlechtere Verfügbarkeit zu haben, ist üblich. Ich frage mich, welche exponentiell wachsenden Produkte tatsächlich daran gescheitert sind, dass sie nicht skalieren konnten.
Als „Big Data“ im Trend lag, war ich Forscher am Large Hadron Collider. Für uns war es ein sinnvoller Use Case, sämtliche Daten zu analysieren, und in der frequentistischen Statistik gilt: je mehr Daten, desto besser.
Aber selbst mit einem weltweiten Supercomputer-Netzwerk stellten wir fest, dass schneller lokaler Speicher besser war, als auf das Ende riesiger Jobs zu warten. Am Ende reduzierte jeder Doktorand die relevanten Daten auf genau 1–5 TB, ohne viel Analyseflexibilität einzubüßen.
Es scheint hier so etwas wie ein Gesetz der Bequemlichkeit zu geben, vergleichbar mit Amdahls Skalierungsgesetz.
Das scheint weniger mit Mathematik als mit menschlichen Grenzen zu tun zu haben. Die Flexibilität, die wir nutzen können, hat eine klare Obergrenze. Das könnte sich ändern, wenn es einfachere Wege gäbe, neue Arten von Analysen auszuführen, aber vermutlich wächst es eher logarithmisch mit der Zahl der Dinge, die man tun möchte.
Menschen sind sehr gut darin, bequeme Wege zu finden, Dinge jedes Jahr ein wenig besser zu machen, aber jede Idee braucht eine Mindestzeit zur Umsetzung.
Wenn ich mich richtig erinnere, war die Warteschlange für diese Anlage so lang wie oder länger als die Zeit, die es gebraucht hätte, den Job auf billiger Hardware laufen zu lassen, und massiv parallele Verarbeitungssysteme wie Beowulf gingen aus solchen Bemühungen hervor.
Die Größe der gespeicherten Datenbanken und der Berechnungen zu reduzieren, ist eine hervorragende Möglichkeit, die monatliche Rechnung des Kunden zu minimieren.
Meiner Erfahrung nach wachsen Daten weiterhin exponentiell, die Informationsmenge aber nicht.
Im Finanzbereich kann man, wenn man will, problemlos 100 Millionen Datenpunkte pro Tag und Zeitreihe bekommen und mit Tausenden von Zeitreihen arbeiten. Aber diese Abtastrate und die Zahl der Zeitreihen sind in der Regel zu 99,99 % redundant. Denn die Eigenwerte fallen ungefähr nach zehn Dimensionen, manchmal deutlich früher, nahezu auf null.
Es gibt kaum einen Grund, Petabytes an Tick-Daten zu speichern, die man nie abfragen wird. In vielen Fällen ist es viel sinnvoller, bereits bei der Erfassung eine drastische, verlustbehaftete Dimensionsreduktion vorzunehmen, nur die ersten paar Hauptkomponenten und Ausreißer zu speichern und die Stabilität der Eigenwerte zu überwachen, um zu sehen, ob zuvor vernachlässigbare neue Faktoren wichtig werden.
Dadurch werden die Datensätze viel kleiner und handhabbarer, und weil man sie tatsächlich nutzen kann, liefern sie oft sogar mehr Erkenntnisse.
Es klingt interessant, ist für mich aber ein völlig neues Thema.
Das Lustige an „Big Data“ war, dass es auf Softwareebene perverse Anreize gab, selbst die grundlegendsten und offensichtlichsten Optimierungen zu vermeiden. Denn hohe Hardwareanforderungen bewiesen, wie großartig man war.
Zum Beispiel: Wenn man sagte: „Chef, statt den gesamten Datensatz zu berechnen, können wir eine Stichprobe lesen und die Durchschnittswerte für diesen Bericht auf einem Laptop berechnen“, verstand der Chef das als: „Was soll Stichprobe heißen? Was willst du mit diesem Mathematiker-/Ingenieursgeschwätz andeuten? Du willst doch nicht sagen, dass ich Millionen von Dollar verschwendet habe?“
Die Sales-Übertreibung und das Rauschen rund um Big Data sowie der Protz-Wettbewerb darum, wessen Daten groß genug seien, waren eine Zeit lang ziemlich extrem.
Lange Zeit war es sehr schwierig, auf einer einzelnen Maschine mehr als 64 GB Arbeitsspeicher zu bekommen, und wenn es eine harte Obergrenze gibt, steigt die Implementierungskomplexität schnell stark an.
Ein Prozess, der nur deshalb, weil die Daten ein wenig größer werden, in 1 von 50 Fällen fehlschlägt, ist extrem destruktiv. Teams betreiben Dutzende solcher regelmäßigen Cron-Jobs, und wenn jeder davon häufig kaputtgeht, verbringt man den On-Call-Dienst nur noch damit, Teile herauszuschneiden.
Hadoop und MapReduce waren nicht extrem effizient, aber richtig eingesetzt waren sie in Ordnung, und zuverlässig zu laufen war viel wichtiger. Besser jedenfalls als bit-optimierter C++-Code, dem niemand vertraut oder den niemand warten kann und der jeden Donnerstag mit einem seltsamen Segmentation Fault stirbt.
Heute würde man einfach Snowflake verwenden, aber damals waren das vernünftige Werkzeuge.
Dieser Beitrag ist nicht ganz korrekt. Ursprünglich wurde Big Data über drei Dimensionen definiert: Volumen, Geschwindigkeit und Vielfalt
Das Volumen ist im Großen und Ganzen gelöst, und auch die Geschwindigkeit ist gelöst, aber teuer. Vielfalt ist noch nicht gelöst
Big Data bedeutet heute weniger „uns fehlt Speicherplatz oder Rechenleistung“, sondern eher „uns fehlt die kognitive Fähigkeit, das zu integrieren und zu verstehen“
Die zugehörigen Vorträge kann ich ebenfalls sehr empfehlen. Die meisten sind auf YouTube
[1] https://www.youtube.com/watch?v=KRcecxdGxvQ
[2] https://amturing.acm.org/award_winners/stonebraker_1172121.c...
In jedem Flugzeug steckt ein Radarsystem, und darin befinden sich acht 16-Drive-RAID-0-SSD-Speichereinheiten mit je 20 TiB. Normalerweise füllen wir das RAID nicht komplett, sodass pro Tag etwa 176 TiB anfallen; bei sieben Flügen in zwei Wochen sind das 1,2 PiB pro Einsatz und rund 7,2 PiB pro Jahr
Der Grund, warum wir zwischen Flügen einen Tag Pause brauchen, ist, dass wir die Daten per Glasfaser auf einen Speicherserver herunterladen müssen, den wir mehr oder weniger in eine Ecke eines Hangars neben dem Vorfeld geschoben haben. Danach replizieren wir sie zur Sicherheit auf einen zweiten Server, und nach Ende der Mission schicken wir alles zur Zentrale, wo es gespeichert und verarbeitet wird
Diese Daten sind wertvoll, aber nicht im Bereich „mehrere Milliarden Dollar“. Sie werden für Rohstoffgewinnung, Kartierung, Umwelt- und geodätische Forschung genutzt, und wir bewahren seit 2008 jedes Byte auf. Denn wenn neue Algorithmen erscheinen, können wir alte Daten nach neuen Standards erneut verarbeiten
Die Dateien werden in Einheiten von 800 GiB bis 2 TiB auf GPU-Verarbeitungsserver gestreamt und lassen sich nicht komprimieren. Der größte Teil dessen, was wir einfangen, die kosmische Mikrowellenhintergrundstrahlung, ist nämlich ziemlich zufällig. Eine Zeit lang dachte ich fälschlicherweise, wir könnten mit Tape unsere Infrastruktur halbieren, aber die Tape-Kapazität scheint so berechnet zu werden, als würde man gigabytegroße Textdateien speichern, die nur aus Nullen bestehen
GPUs sind langsam, CPUs sind langsam, PCIe-Busse sind langsam, RAM ist langsam, und meine Tippgeschwindigkeit ist auch langsam. Alles muss immer schneller werden
Alles ist zu langsam, zu schwierig und zu klein. Festplatten sind zu klein, und das Linux-Kernel-Tuning sowie die Einrichtung schneller, stabiler Netzwerke zu den Verarbeitungclustern sind zu schwierig. Selbst Kernel-/Paket-Updates, die eigentlich nur interne Abläufe ändern, machen Systeme auf Arten kaputt, die anscheinend nur uns treffen
Die Standardeinstellungen leben in der Illusion, RAM sei knapp, und sparen deshalb Speicher bei Netzwerkoperationen. Aber wenn ein Fileserver 0,5 TB RAM hat, möchte ich, dass er alles davon nutzt, um Netzwerk und Dateisystem schnell zu machen. Am Ende muss man sechs Stunden lang die Dokumentation zum Netzwerk-Stack lesen und die I/O auf ein Maß bringen, das 2024 dem gesunden Menschenverstand entspricht
Wahrscheinlich kenne ich
sysctl.confbesser als fast jeder andere Mensch auf der ErdeVerteilte persistente Objektspeicher, die sich selbst als Big-Data-tauglich bezeichnen, brechen unter unserer Workload entweder komplett zusammen oder kosten Hunderte Millionen Dollar. Wenn man sagt, dass die Objektgröße ungefähr 1 TB beträgt, hören die Vertriebsleute für verteilte Dateisysteme auf zu antworten. Ein Vendor hat nach dem Lesen der Anforderungen sogar an seinen Ansprechpartner für Kunden aus Nachrichtendiensten weiterverwiesen. Ich bin nicht die NSA und habe auch kein NSA-Budget
Manchmal liest irgendein MBA oder PMP in Bloomberg einen Cloud-Artikel, sieht die Kosten für unser On-Premises-Rechenzentrum und fragt nach einem Umzug zu AWS oder Azure; wenn man dann die Zahlen für Geld und Zeit zeigt, sieht er aus, als müsse er sich übergeben, und wechselt das Thema
Außerdem springen alle Vendoren auf den AI-/Cloud-Hype auf und stellen die Produktlinien ein, die zu uns passen. Jetzt müssen wir mit Hedgefonds, die Kundendaten ausschlachten wollen, um Werbung auszuspielen, und mit AI-Startups um GPUs konkurrieren
Uns fehlen Speicherplatz und Rechenleistung, und der Speicherplatz und die Rechenleistung, die wir haben, sind zu langsam. DPU/IPU sind interessant, stoßen aber sofort an Grenzen, sobald Objekte größer werden als SQL-Datenbankabfragen oder komprimierte Streaming-Video-Schnipsel
Früher habe ich bei einem Unternehmen gearbeitet, das täglich 20 GB Analysedaten erzeugte; das war wahrscheinlich der größte Datenbestand, mit dem ich je zu tun haben werde
Als Junior-Projekt schrieb ich eine Datenverarbeitung für Batch- und Echtzeit-Aggregationen und speicherte die Ergebnisse in Parquet-Blobs auf Azure
Mein Chef war klug genug, regelmäßig Stakeholder-Meetings anzusetzen, um zu besprechen, was aufbewahrt und was verworfen werden sollte, und dank guter Algorithmen konnten wir die Daten auf etwa 200 MB pro Tag komprimieren
Die letzten zwei Monate landeten im SQL Server, die letzten zwei Jahre wurden weiter aggregiert und auf einen anderen Server gelegt, und das ganze Unternehmen konnte sie mit Excel in vertretbarer Zeit abfragen. Die ursprünglichen Big-Data-Rohdaten verrotten in einem Tape-Archiv, falls man sie irgendwann einmal braucht
Mein Chef war ein schlechter Manager, aber er verstand Daten; rückblickend hat er vieles richtig gemacht, und ich habe viel gelernt
Über viele Jahre habe ich Overengineering bei „großen“ Datentools und Pipelines gesehen. In vielen Use Cases liegen Data Warehouses und Data Lakes im Bereich von GB oder einstelligen TB, sodass man das mit DuckDB auf einer ordentlichen EC2-Instanz deutlich vereinfachen kann
Meiner Erfahrung nach erhält man so Ergebnisse, bevor andere Systeme überhaupt mit der Ausführung der Abfrage beginnen. Ich meine dich, Athena
Heute denke ich, dass man viele Abfragen sogar im Browser ausführen kann, und habe mithilfe von DuckDB WASM(https://github.com/duckdb/duckdb-wasm) und perspective.js(https://github.com/finos/perspective) https://sql-workbench.com/ gebaut
Dieser Hype-Zyklus scheint am Ende das „Plateau des Todes“ erreicht zu haben. In dieser extrem hypegetriebenen Branche ist das kein seltenes Ende
AI nutzt ebenfalls alle Daten und hängt magische neuronale Netze daran, um herauszufinden, was sie bedeuten
Persönlich denke ich, dass der wichtigste Antrieb hinter Big Data das Ego der Firmengründer war. Natürlich würde unser Unternehmen explosionsartig wachsen und weltweit erfolgreich werden, also müsse man entsprechend skalierbar entwerfen
Es ist tragisch, solche Fehler zu machen, obwohl eine einzige SQLite-DB völlig ausreichen würde, bis das Produkt Series C erreicht. Die gesamte Energie sollte noch auf das Produkt konzentriert werden, nicht auf Skalierung
Hadoop entstand inspiriert von dem, was es bei Google gab, und wurde bei Unternehmen weltweit beliebt, die Daten günstiger und besser verarbeiten wollten als mit Oracle
Spark entstand als Lösung für die Komplexität von Hive/Pig usw.; als Unternehmen verlässliche Datenpipelines aufbauen konnten, wurde es möglich, darauf AI aufzusetzen
Datenmodelle, die aus absichtlichen menschlichen Handlungen wie Link-Klicks, dem Senden von Nachrichten oder Käufen entstehen, sind im Allgemeinen klein. Denn die Zahl der Menschen und die Zahl absichtlicher Ereignisse, die Menschen pro Sekunde erzeugen können, sind begrenzt
Von Maschinen erzeugte Datenmodelle können dagegen bei Geschwindigkeit und Volumen um mehrere Größenordnungen größer sein, und der Größe des Datenmodells sind keine Grenzen gesetzt. Solche Daten sind oft die interessantesten und am wenigsten genutzten Daten, weil sie viele Fakten über die Welt zugänglich machen, die sich mit absichtlichen menschlichen Datenmodellen nicht gewinnen lassen