Was ist Big Data?

Die im technischen Umfeld meistzitierte Definition stammt vom NIST, dem US-amerikanischen Normungsinstitut. In seinem Interoperabilitätsrahmen von 2019 beschreibt es Big Data als umfangreiche Datenbestände, die vor allem durch Volumen, Vielfalt, Geschwindigkeit oder Veränderlichkeit gekennzeichnet sind und eine skalierbare Architektur für effizientes Speichern, Verarbeiten und Auswerten erfordern.

Entscheidend ist der zweite Teil. Big Data ist mehr als „viele Daten“: Größe, Tempo oder Formatmix zwingen zu einem anderen Werkzeug. Eine Tabellenkalkulation oder eine Datenbank auf einem einzelnen Server reicht dann nicht mehr, und die Arbeit wird auf viele Rechner verteilt.

Die vier Merkmale lassen sich an Beispielen zeigen. Volumen: die Logdateien eines großen Webservers mit Millionen Zeilen am Tag. Geschwindigkeit: die Klicks in einem Onlineshop, die verarbeitet werden müssen, während sie entstehen. Vielfalt: Tabellen neben Texten, Bildern oder Maschinenprotokollen. Veränderlichkeit: Daten, deren Bedeutung oder Rhythmus sich mit der Zeit verschiebt, etwa der Traffic einer Website vor und nach einem Google-Update.

Das technische Prinzip heißt Verteilen. Statt eines immer stärkeren Servers beschreibt das NIST das Big-Data-Paradigma als Verteilung von Datensystemen auf horizontal gekoppelte, unabhängige Ressourcen: viele gewöhnliche Rechner, von denen jeder einen Teil speichert und verarbeitet. Wachsen die Daten, kommen Rechner hinzu.

Darauf bauen zwei typische Arbeitsweisen auf. Bei der Stapelverarbeitung werden Daten gesammelt und in Abständen ausgewertet, etwa einmal am Tag. Bei der Stromverarbeitung werden sie ausgewertet, sobald sie eintreffen, sodass sich in Sekunden reagieren lässt. Cloud-Data-Warehouses wie BigQuery erlauben SQL-Abfragen über riesige Tabellen, ohne dass man die Rechner dahinter selbst verwalten muss.

Wer im Marketing oder in der Suchmaschinenoptimierung arbeitet, hat meist nur indirekt mit Big Data zu tun: Die Daten aus der Search Console, aus Google Analytics oder aus Serverlogs kommen bereits von einem Werkzeug zusammengefasst an. Und jede Zusammenfassung lässt etwas weg.

Die Search Console ist das deutlichste Beispiel. Google erklärt, dass ihre Leistungsdaten zwei Grenzen haben. Die eine ist der Datenschutz: Suchanfragen, die in zwei bis drei Monaten nicht von mehr als ein paar Dutzend Nutzern gestellt wurden, werden anonymisiert und erscheinen nicht in den Tabellen, zählen aber in den Summen des Diagramms mit. Die andere ist die Zeilenzahl: Die Oberfläche exportiert nach Googles Angabe von 2022 höchstens 1.000 Zeilen, die API laut ihrer aktuellen Dokumentation höchstens 50.000 Zeilen pro Tag und Suchtyp. Seit Februar 2023 liefert der Massenexport nach BigQuery alle Daten ohne diese Zeilengrenze. Auch dort bleibt der Wortlaut der anonymisierten Suchanfragen verborgen: Ihre Zeilen tragen is_anonymized_query = true und ein leeres Feld query.

Google veranschaulicht das in seinem Blog an einem Rechenbeispiel: Die aufgeschlüsselten Suchanfragen ergeben 450 Klicks, die Summe im Diagramm aber 550, weil sie auch die Klicks der anonymisierten Suchanfragen enthält. Wer die Zeilen der Tabelle oder der API addiert, kommt deshalb nie auf die Summe.

Für die KI-Suche ist der Maßstab noch größer. Sprachmodelle werden mit Textsammlungen trainiert, die sich nur mit Big-Data-Verfahren handhaben lassen, und KI-Suchsysteme stützen sich auf Indizes, die einen großen Teil des Webs abdecken. Was eine Website veröffentlicht, wird Teil dieser Daten, nach derselben Logik aus Volumen, Geschwindigkeit und Vielfalt.

• Die Frage formulieren, bevor Daten gesammelt werden; Volumen ohne konkrete Frage erzeugt nur mehr Speicherbedarf.
• Die Grenzen jeder Quelle kennen: Stichproben, Anonymisierung, Zeilenlimits und Verzögerungen bei endgültigen Daten.
• Bei großen Websites den Massenexport der Search Console nach BigQuery statt der API nutzen, wenn alle Zeilen gebraucht werden.
• Summen und Aufschlüsselungen getrennt speichern und eine Zeilensumme nie mit einer Gesamtzahl vergleichen, ohne zu wissen, was fehlt.
• Festhalten, von wann die Daten stammen und in welchem Zustand sie sind, etwa vorläufig oder endgültig.
• Personenbezogene Daten von Anfang an nach DSGVO behandeln, nicht erst nachträglich.

• Die Zeilen der Search Console nach Suchanfrage addieren und erwarten, dass sie die Gesamtklicks ergeben.
• Menge mit Erkenntnis verwechseln: Mehr Daten beantworten eine schlecht gestellte Frage nicht von selbst.
• Vorläufige und endgültige Daten in derselben Zeitreihe mischen.
• Eine Big-Data-Infrastruktur für eine Datenmenge aufbauen, die in eine Tabellenkalkulation passt.
• Personenbezogene Daten „auf Vorrat“ speichern, ohne Zweck und Rechtsgrundlage.