Google BigQuery: Der endgültige Leitfaden

Kapitel 1. Was ist Google BigQuery?

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Datenverarbeitungsarchitekturen

Google BigQuery ist ein serverloses, hochgradig skalierbares Data Warehouse, das mit einer integrierten Abfrage-Engine ausgestattet ist. Die Abfrage-Engine ist in der Lage, SQL-Abfragen auf Terabytes von Daten in wenigen Sekunden und Petabytes in nur wenigen Minuten auszuführen. Du erhältst diese Leistung, ohne eine Infrastruktur verwalten zu müssen und ohne Indizes zu erstellen oder neu zu erstellen.

BigQuery hat Legionen von Fans. Paul Lamere, ein Spotify-Ingenieur, war begeistert, dass er endlich darüber sprechen konnte, wie sein Team BigQuery nutzt, um große Datenmengen schnell zu analysieren: "Googles BigQuery ist *da bomb*", twitterte er im Februar 2016. "Ich kann mit 2,2 Milliarden 'Dingen' beginnen und in < 1 Minute bis auf 20.000 herunterrechnen/zusammenfassen. Der Umfang und die Geschwindigkeit sind nur zwei bemerkenswerte Eigenschaften von BigQuery. Die Einfachheit der serverlosen Ad-hoc-Abfragen eröffnet neue Arbeitsweisen, da die Infrastruktur nicht mehr verwaltet werden muss.

Unternehmen setzen zunehmend auf datengestützte Entscheidungsfindung und fördern eine offene Kultur, in der die Daten nicht in den Abteilungen isoliert werden. Indem BigQuery die technologischen Mittel bereitstellt, um einen kulturellen Wandel hin zu Agilität und Offenheit zu bewirken, trägt es wesentlich dazu bei, das Innovationstempo zu erhöhen. So berichtete Twitter kürzlich in seinem Blog, dass das Unternehmen die Datenanalyse mit BigQuery demokratisieren konnte, indem es einige seiner am häufigsten verwendeten Tabellen Twitter-Mitarbeitern aus verschiedenen Teams zur Verfügung stellte (Technik, Finanzen und Marketing wurden genannt).

Für die Alpega Group, ein weltweit tätiges Unternehmen für Logistiksoftware, waren die erhöhte Innovation und Agilität, die BigQuery bietet, entscheidend. Von einer Situation, in der Echtzeit-Analysen unmöglich waren, konnte das Unternehmen nun schnelle, kundenorientierte Analysen nahezu in Echtzeit bereitstellen. Da die Alpega Group keine Cluster und keine Infrastruktur vorhalten muss, kann sich das kleine technische Team nun auf die Softwareentwicklung und die Datenverarbeitung konzentrieren. "Das war ein echter Augenöffner für uns", sagt der leitende Architekt des Unternehmens, Aart Verbeke. "In einer herkömmlichen Umgebung müssten wir jeden einzelnen Baustein installieren, einrichten, bereitstellen und hosten. Hier verbinden wir uns einfach mit einer Oberfläche und nutzen sie nach Bedarf."

Stell dir vor, du betreibst eine Kette von Ausrüstungsverleihern. Du berechnest den Kunden die Dauer der Miete, daher enthalten deine Aufzeichnungen die folgenden Angaben, die es dir ermöglichen, dem Kunden eine korrekte Rechnung zu stellen:

1. Wo der Gegenstand gemietet wurde

2. Als es gemietet wurde

3. Wo der Artikel zurückgegeben wurde

4. Als es zurückgegeben wurde

Vielleicht zeichnest du die Transaktion in einer Datenbank auf, wenn ein Kunde einen Artikel zurückgibt.¹

Anhand dieses Datensatzes möchtest du herausfinden, wie viele "Einweg"-Verleihungen in den letzten 10 Jahren jeden Monat stattgefunden haben. Vielleicht denkst du darüber nach, einen Aufpreis für die Rückgabe in einem anderen Laden zu erheben, und möchtest herausfinden, welcher Anteil der Ausleihen davon betroffen wäre. Gehen wir davon aus, dass du die Antwort auf solche Fragen häufig wissen willst - es ist wichtig für dich, solche Ad-hoc-Fragen beantworten zu können, weil du dazu neigst, datengestützte Entscheidungen zu treffen.

Welche Art von Systemarchitektur könntest du verwenden? Gehen wir einige der Optionen durch.

Relationales Datenbankmanagementsystem

Wenn du die Transaktionen aufzeichnest, speicherst du sie wahrscheinlich in einer relationalen, online Transaktionsverarbeitung (OLTP) Datenbank wie MySQL oder PostgreSQL. Einer der wichtigsten Vorteile solcher Datenbanken ist, dass sie Abfragen mit der Structured Query Language (SQL) unterstützen - deine Mitarbeiter müssen keine Hochsprachen wie Java oder Python verwenden, um aufkommende Fragen zu beantworten. Stattdessen ist es möglich, eine Abfrage wie die folgende zu schreiben, die an den Datenbankserver übermittelt werden kann:

SELECT 
  EXTRACT(YEAR FROM starttime) AS year,
  EXTRACT(MONTH FROM starttime) AS month,
  COUNT(starttime) AS number_one_way
FROM
  mydb.return_transactions
WHERE
  start_station_name != end_station_name
GROUP BY year, month
ORDER BY year ASC, month ASC

Ignoriere die Details der Syntax für den Moment; wir behandeln SQL-Abfragen später in diesem Buch. Konzentrieren wir uns stattdessen darauf, was uns dies über die Vor- und Nachteile einer OLTP-Datenbank sagt.

Beachte zunächst, dass SQL mehr kann als nur die Rohdaten in den Datenbankspalten abzurufen - die vorangegangene Abfrage analysiert den Zeitstempel und extrahiert daraus Jahr und Monat. Sie kann auch aggregieren (die Anzahl der Zeilen zählen), filtern (Mietverträge finden, bei denen der Anfangs- und Endpunkt unterschiedlich sind), gruppieren (nach Jahr und Monat) und sortieren. Ein wichtiger Vorteil von SQL ist, dass wir angeben können, was wir wollen, und die Datenbanksoftware den optimalen Weg zur Ausführung der Abfrage findet.

Leider sind Abfragen wie diese für eine OLTP-Datenbank ziemlich ineffizient. OLTP-Datenbanken sind auf Datenkonsistenz ausgerichtet. Das bedeutet, dass du aus der Datenbank lesen kannst, auch wenn gleichzeitig Daten in sie geschrieben werden. Dies wird durch sorgfältiges Sperren erreicht, um die Datenintegrität zu gewährleisten. Damit die Filterung auf station_name effizient zu sein, müsstest du einen Index für die Spalte mit dem Bahnhofsnamen erstellen. Wenn der Bahnhofsname indiziert ist, dann und nur dann macht die Datenbank spezielle Eingriffe in die Speicherung, um die Suchfunktion zu optimieren. Wenn der Bahnhofsname nicht indiziert ist, wird das Filtern ziemlich langsam sein. Selbst wenn der Bahnhofsname ein Index ist, wird diese spezielle Abfrage wegen der Aggregation, Gruppierung und Ordnung ziemlich langsam sein. OLTP-Datenbanken sind nicht für diese Art von Ad-hoc-Abfrage ausgelegt.² Ad-hoc-Abfrage, bei der der gesamte Datensatz durchlaufen werden muss.

MapReduce Framework

Da OLTP-Datenbanken für Ad-hoc-Abfragen und Abfragen, die eine Durchquerung des gesamten Datensatzes erfordern, schlecht geeignet sind, werden spezielle Analysen, die eine solche Durchquerung erfordern, in Hochsprachen wie Java oder Python programmiert. Im Jahr 2003 stellten Jeff Dean und Sanjay Ghemawat fest, dass sie und ihre Kollegen bei Google Hunderte dieser Spezialberechnungen implementierten, um große Mengen an Rohdaten zu verarbeiten. Als Reaktion auf diese Komplexität entwarfen sie eine Abstraktion, mit der diese Berechnungen in zwei Schritten ausgedrückt werden konnten: eine Map-Funktion, die ein Schlüssel/Wert-Paar verarbeitete, um eine Reihe von Schlüssel/Wert-Zwischenpaaren zu erzeugen, und eine Reduce-Funktion, die alle Zwischenwerte zusammenführte, die mit demselben Zwischenschlüssel verbunden waren.³ Dieses Paradigma, bekannt als MapReduce, wurde sehr einflussreich und führte zur Entwicklung von Apache Hadoop.

Obwohl das Hadoop-Ökosystem mit einer Bibliothek begann, die in erster Linie in Java entwickelt wurde, werden benutzerdefinierte Analysen auf Hadoop-Clustern heute in der Regel mit Apache Spark durchgeführt. Spark-Programme können in Python oder Scala geschrieben werden, aber zu den Fähigkeiten von Spark gehört auch die Möglichkeit, Ad-hoc-SQL-Abfragen auf verteilten Datensätzen auszuführen.

Um die Anzahl der Einwegmieten zu ermitteln, könntest du also die folgende Datenpipeline einrichten:

1. Exportiere regelmäßig Transaktionen in kommagetrennte Textdateien (CSV) im Hadoop Distributed File System (HDFS).

2. Schreibe für die Ad-hoc-Analyse ein Spark-Programm, das Folgendes tut:

   1. Lädt die Daten aus den Textdateien in einen "Datenrahmen".

   2. Führt eine SQL-Abfrage aus, die der Abfrage im vorherigen Abschnitt ähnelt, mit dem Unterschied, dass der Tabellenname durch den Namen des Datenrahmens ersetzt wird

   3. Exportiert die Ergebnismenge zurück in eine Textdatei

3. Führe das Spark-Programm auf einem Hadoop-Cluster aus.

Obwohl diese Architektur scheinbar einfach ist, bringt sie ein paar versteckte Kosten mit sich. Das Speichern der Daten im HDFS setzt voraus, dass der Cluster groß genug ist. Eine unterschätzte Tatsache bei der MapReduce-Architektur ist, dass die Rechenknoten in der Regel auf Daten zugreifen müssen, die nur ihnen gehören. Das HDFS muss daher auf die Rechenknoten des Clusters verteilt werden. Da sowohl die Datenmengen als auch der Analysebedarf unabhängig voneinander stark ansteigen, kommt es häufig vor, dass Cluster unter- oder überprovisioniert sind.⁴ Die Notwendigkeit, Spark-Programme auf einem Hadoop-Cluster auszuführen, bedeutet also, dass dein Unternehmen Experte für die Verwaltung, Überwachung und Bereitstellung von Hadoop-Clustern werden muss. Das gehört vielleicht nicht zu deinem Kerngeschäft.

BigQuery: Eine serverlose, verteilte SQL-Engine

Was wäre, wenn du SQL-Abfragen wie in einem relationalen Datenbankmanagementsystem (RDBMS) ausführen könntest, eine effiziente und verteilte Durchquerung des gesamten Datensatzes wie bei MapReduce erhältst und keine Infrastruktur verwalten müsstest? Das ist die dritte Option, und sie macht BigQuery so magisch. BigQuery ist serverlos und du kannst Abfragen ausführen, ohne dass du eine Infrastruktur verwalten musst. Damit kannst du Analysen durchführen, die Aggregationen über den gesamten Datensatz in Sekunden bis Minuten verarbeiten.

Glaube aber nicht an unser Wort. Probiere es gleich aus. Navigiere zu https://console.cloud.google.com/bigquery (logge dich bei Google Cloud Platform ein und wähle dein Projekt aus, falls nötig), kopiere die folgende Abfrage und füge sie in das Fenster ein,⁵ und klicke dann auf die Schaltfläche "Abfrage ausführen":

SELECT 
  EXTRACT(YEAR FROM starttime) AS year,
  EXTRACT(MONTH FROM starttime) AS month,
  COUNT(starttime) AS number_one_way
FROM
  `bigquery-public-data.new_york_citibike.citibike_trips`
WHERE
  start_station_name != end_station_name
GROUP BY year, month
ORDER BY year ASC, month ASC

Als wir sie ausführten, meldete die BigQuery-Benutzeroberfläche (UI), dass die Abfrage 2,51 GB verarbeitete und uns das Ergebnis in etwa 2,7 Sekunden lieferte, wie in Abbildung 1-1 dargestellt.

Abbildung 1-1. Ausführen einer Abfrage zur Berechnung der Anzahl der Einwegmieten in der BigQuery Web UI

Bei den vermieteten Geräten handelt es sich um Fahrräder. Die vorangegangene Abfrage summiert die Einweg-Fahrradvermietungen in New York Monat für Monat über den gesamten Datensatz hinweg. Der Datensatz selbst ist ein öffentlicher Datensatz (d.h. jeder kann die darin enthaltenen Daten abfragen), der von der Stadt New York im Rahmen ihrer Open City Initiative veröffentlicht wurde. Aus dieser Abfrage erfahren wir, dass es im Juli 2013 815.324 Einweg-Citibike-Vermietungen in New York City gab.

Beachte dabei ein paar Dinge. Zum einen konntest du eine Abfrage gegen einen Datensatz durchführen, der bereits in BigQuery vorhanden war. Der Eigentümer des Projekts, in dem die Daten gespeichert sind, musste dir nur den⁶ "View"-Zugriff auf diesen Datensatz zu geben. Du musstest weder einen Cluster einrichten noch dich bei einem anmelden. Stattdessen hast du einfach eine Abfrage an den Dienst gestellt und deine Ergebnisse erhalten. Die Abfrage selbst wurde in SQL:2011 geschrieben, sodass die Syntax Datenanalysten überall vertraut ist. Obwohl wir mit Gigabytes an Daten demonstriert haben, skaliert der Dienst auch dann gut, wenn er Terabytes bis Petabytes an Daten aggregiert. Diese Skalierbarkeit ist möglich, weil der Dienst die Abfrageverarbeitung fast sofort auf Tausende von Workern verteilt.

Arbeiten mit BigQuery

BigQuery ist ein Data Warehouse, was ein gewisses Maß an Zentralisierung und Allgegenwärtigkeit impliziert. Die Abfrage, die wir im vorherigen Abschnitt gezeigt haben, wurde auf einen einzelnen Datensatz angewendet. Die Vorteile von BigQuery werden jedoch noch deutlicher, wenn wir Datensätze aus völlig unterschiedlichen Quellen zusammenführen oder wenn wir Daten abfragen, die außerhalb von BigQuery gespeichert sind.

Einblicke über Datensätze hinweg gewinnen

Die Fahrradverleihdaten stammen aus New York City. Wie wäre es, wenn du sie mit den Wetterdaten der US National Oceanic and Atmospheric Administration (NOAA) vergleichst, um herauszufinden, ob es an regnerischen Tagen weniger Fahrradverleihs gibt?⁷

-- Are there fewer bicycle rentals on rainy days?
WITH bicycle_rentals AS (
  SELECT
    COUNT(starttime) as num_trips,
    EXTRACT(DATE from starttime) as trip_date
 FROM `bigquery-public-data.new_york_citibike.citibike_trips`
 GROUP BY trip_date
),

rainy_days AS
(
SELECT
  date,
  (MAX(prcp) > 5) AS rainy
FROM (
  SELECT
    wx.date AS date,
    IF (wx.element = 'PRCP', wx.value/10, NULL) AS prcp
  FROM
    `bigquery-public-data.ghcn_d.ghcnd_2016` AS wx
  WHERE
    wx.id = 'USW00094728'
)
GROUP BY
 date
)

SELECT
  ROUND(AVG(bk.num_trips)) AS num_trips,
  wx.rainy
FROM bicycle_rentals AS bk
JOIN rainy_days AS wx
ON wx.date = bk.trip_date
GROUP BY wx.rainy

Ignoriere die spezielle Syntax der Abfrage. Beachte nur, dass wir in den fettgedruckten Zeilen den Fahrradverleih-Datensatz mit einem Wetterdatensatz verbinden, der aus einer ganz anderen Quelle stammt. Wenn du die Abfrage durchführst, stellt sich heraus, dass die New Yorker tatsächlich Weicheier sind - sie fahren fast 20 % weniger mit dem Fahrrad, wenn es regnet:⁸

Row num_trips  rainy  
 1  39107.0    false  
 2  32052.0    true

Was bedeutet die Möglichkeit, Daten gemeinsam zu nutzen und abzufragen, im Unternehmenskontext? Verschiedene Abteilungen deines Unternehmens können ihre Datensätze in BigQuery speichern und die Daten ganz einfach mit anderen Abteilungen des Unternehmens und sogar mit Partnerorganisationen teilen. Der serverlose Charakter von BigQuery bietet die technischen Mittel, um Abteilungssilos aufzubrechen und die Zusammenarbeit zu optimieren.

ETL, EL, und ELT

Die herkömmliche Art, mit Data Warehouses zu arbeiten, beginnt mit einem Extraktions-, Transformations- und Ladeprozess (ETL), bei dem Rohdaten aus ihrer Quelle extrahiert, transformiert und dann in das Data Warehouse geladen werden. BigQuery verfügt über ein natives, hocheffizientes Format für die spaltenbasierte Speicherung⁹ das ETL zu einer attraktiven Methode macht. Die Datenpipeline, die in der Regel in Apache Beam oder Apache Spark geschrieben wird, extrahiert die notwendigen Teile aus den Rohdaten (entweder Streaming-Daten oder Batch-Dateien), wandelt die extrahierten Daten um, um sie zu bereinigen oder zu aggregieren, und lädt sie dann in BigQuery, wie in Abbildung 1-2 dargestellt.

Abbildung 1-2. Die Referenzarchitektur für ETL in BigQuery verwendet Apache Beam-Pipelines, die auf Cloud Dataflow ausgeführt werden, und kann sowohl Streaming- als auch Batch-Daten mit demselben Code verarbeiten

Auch wenn es üblich ist, eine ETL-Pipeline in Apache Beam oder Apache Spark zu erstellen, ist es auch möglich, eine ETL-Pipeline nur in BigQuery zu implementieren. Da BigQuery Rechenleistung und Speicherung trennt, ist es möglich, BigQuery-SQL-Abfragen gegen CSV- (oder JSON- oder Avro-) Dateien auszuführen, die auf Google Cloud Storage gespeichert sind; diese Fähigkeit wird als federated Querying bezeichnet. Du kannst die Vorteile von federated queries nutzen, um die Daten mithilfe von SQL-Abfragen gegen in Google Cloud Storage gespeicherte Daten zu extrahieren, die Daten innerhalb dieser SQL-Abfragen umzuwandeln und die Ergebnisse dann in einer nativen BigQuery-Tabelle zu materialisieren.

Wenn eine Umwandlung nicht notwendig ist, kann BigQuery Standardformate wie CSV, JSON oder Avro direkt in die native Speicherung einlesen - ein EL-Workflow (Extract and Load), wenn du so willst. Der Grund dafür, die Daten in das Data Warehouse zu laden, ist, dass die Daten in der nativen Speicherung die effizienteste Abfrageleistung bieten.

Wir empfehlen dir dringend, wenn möglich einen EL-Workflow zu entwerfen und nur dann auf einen ETL-Workflow umzusteigen, wenn Umwandlungen erforderlich sind. Wenn möglich, führe diese Umwandlungen in SQL durch und behalte die gesamte ETL-Pipeline in BigQuery. Wenn es schwierig ist, die Transformationen nur in SQL zu implementieren, oder wenn die Pipeline Daten in BigQuery streamen muss, sobald sie ankommen, solltest du eine Apache Beam-Pipeline erstellen und sie mit Cloud Dataflow serverlos ausführen lassen. Ein weiterer Vorteil der Implementierung von ETL-Pipelines in Beam/Dataflow ist, dass sich solche Pipelines besser in Continuous Integration (CI) und Unit Testing-Systeme integrieren lassen, da es sich um programmatischen Code handelt.

Neben den ETL- und EL-Workflows ermöglicht BigQuery auch einen Extract, Load, and Transform (ELT) Workflow. Die Idee dahinter ist, die Rohdaten zu extrahieren und zu laden, wie sie sind, und sich auf BigQuery-Ansichten zu verlassen, um die Daten im laufenden Betrieb zu transformieren. Ein ELT-Workflow ist besonders nützlich, wenn sich das Schema der Rohdaten ändert. Du könntest zum Beispiel noch Untersuchungen durchführen, um festzustellen, ob ein bestimmter Zeitstempel für die lokale Zeitzone korrigiert werden muss. Der ELT-Workflow ist nützlich für das Prototyping und ermöglicht es einer Organisation, erste Erkenntnisse aus den Daten zu gewinnen, ohne zu früh potenziell unumkehrbare Entscheidungen treffen zu müssen.

Die Buchstabensuppe kann verwirrend sein, deshalb haben wir eine kurze Zusammenfassung in Tabelle 1-1 vorbereitet.

Tabelle 1-1. Zusammenfassung der Arbeitsabläufe, Beispielarchitekturen und der Szenarien, in denen sie eingesetzt werden können

Arbeitsablauf	Architektur	Wann du es benutzen würdest
EL	Extrahiere Daten aus Dateien in der Google Cloud Speicherung. Lade sie in die native Speicherung von BigQuery. Du kannst dies über Cloud Composer, Cloud Functions oder geplante Abfragen auslösen.	Batch-Laden von historischen Daten. Geplantes regelmäßiges Laden von Logdateien (z. B. einmal pro Tag).
ETL	Extrahiere Daten aus Pub/Sub, Google Cloud Storage, Cloud Spanner, Cloud SQL, etc. Transformiere die Daten mit Cloud Dataflow. Lass die Dataflow-Pipeline in BigQuery schreiben	Wenn die Rohdaten vor dem Laden in BigQuery einer Qualitätskontrolle, Transformation oder Anreicherung unterzogen werden müssen. Wenn das Laden der Daten kontinuierlich erfolgen muss, d.h. wenn der Anwendungsfall Streaming erfordert. Wenn du dich in Systeme zur kontinuierlichen Integration/kontinuierlichen Bereitstellung (CI/CD) integrieren und Unit-Tests für alle Komponenten durchführen möchtest.
ELT	Extrahiere Daten aus Dateien in der Google Cloud Speicherung. Speichere Daten in BigQuery im Rohdatenformat. Transformiere die Daten im Handumdrehen mit BigQuery-Ansichten.	Experimentelle Datensätze, bei denen du noch nicht sicher bist, welche Art von Umwandlung erforderlich ist, um die Daten nutzbar zu machen. Jeder Produktionsdatensatz, bei dem die Transformation in SQL ausgedrückt werden kann.

Die Arbeitsabläufe in Tabelle 1-1 sind in der Reihenfolge, die wir normalerweise empfehlen.

Leistungsstarke Analysen

Die Vorteile eines Warehouse ergeben sich aus den Arten von Analysen, die du mit den darin enthaltenen Daten durchführen kannst. Da BigQuery eine SQL-Engine ist, kannst du eine Vielzahl von Business Intelligence (BI)-Tools wie Tableau, Looker und Google Data Studio verwenden, um aussagekräftige Analysen, Visualisierungen und Berichte über die in BigQuery gespeicherten Daten zu erstellen. Wenn du in der BigQuery-Web-UI auf die Schaltfläche "Explore in Data Studio" klickst, kannst du zum Beispiel unter schnell eine Visualisierung erstellen, die zeigt, wie sich unsere Einweg-Fahrradmieten nach Monaten unterscheiden (siehe Abbildung 1-3).

BigQuery bietet umfassende Unterstützung für SQL:2011, einschließlich Unterstützung für Arrays und komplexe Joins. Insbesondere die Unterstützung für Arrays macht es möglich, hierarchische Daten (wie JSON-Datensätze) in BigQuery zu speichern, ohne dass die verschachtelten und wiederholten Felder abgeflacht werden müssen. Neben der Unterstützung für SQL:2011 verfügt BigQuery über einige Erweiterungen, die es über den Kernbereich der Data-Warehouse-Anwendungsfälle hinaus nützlich machen. Eine dieser Erweiterungen ist die Unterstützung einer Vielzahl von räumlichen Funktionen, die ortsbezogene Abfragen ermöglichen, einschließlich der Möglichkeit, zwei Tabellen anhand von Entfernungs- oder Überschneidungskriterien zu verknüpfen.¹⁰ BigQuery ist daher eine leistungsstarke Engine zur Durchführung von deskriptiven Analysen.

Abbildung 1-3. Visualisierung in Data Studio, wie Einwegmieten nach Monat variieren; fast 15% aller Einwegmieten in New York finden im September statt

Eine weitere BigQuery-Erweiterung zu Standard-SQL unterstützt die Erstellung von Machine-Learning-Modellen und die Durchführung von Batch-Vorhersagen. Wir gehen in Kapitel 9 ausführlich auf die maschinellen Lernfähigkeiten von BigQuery ein, aber das Wichtigste ist, dass du ein BigQuery-Modell trainieren und Vorhersagen machen kannst, ohne jemals Daten aus BigQuery exportieren zu müssen. Die Vorteile für die Sicherheit und die Datenlokalisierung sind enorm. BigQuery ist also ein Data Warehouse, das nicht nur deskriptive Analysen, sondern auch prädiktive Analysen unterstützt.

Ein Warehouse bedeutet auch, dass es verschiedene Arten von Daten speichern kann. BigQuery kann in der Tat viele Datentypen speichern: numerische und textuelle Spalten, aber auch Geodaten und hierarchische Daten. Auch wenn du in BigQuery flattened Daten speichern kannst, musst du das nicht - Schemas können reichhaltig und ziemlich anspruchsvoll sein. Die Kombination aus ortsbezogenen Abfragen, hierarchischen Daten und maschinellem Lernen macht BigQuery zu einer leistungsstarken Lösung, die über herkömmliches Data Warehousing und Business Intelligence hinausgeht.

BigQuery unterstützt sowohl den Ingest von Batch-Daten als auch von Streaming-Daten. Du kannst Daten über eine REST-API direkt in BigQuery streamen. Wenn du die Daten umwandeln möchtest, z. B. durch Hinzufügen von zeitlich begrenzten Berechnungen, verwendest du häufig Apache Beam Pipelines, die vom Cloud Dataflow Service ausgeführt werden. Auch wenn die Daten in BigQuery gestreamt werden, kannst du sie abfragen. Eine gemeinsame Abfrageinfrastruktur sowohl für historische (Batch-) Daten als auch für aktuelle (Streaming-) Daten ist extrem leistungsstark und vereinfacht viele Arbeitsabläufe.

Einfachheit der Verwaltung

Ein Teil der Überlegungen, die hinter BigQuery stehen, besteht darin, die Nutzer dazu zu ermutigen, sich auf die Erkenntnisse und nicht auf die Infrastruktur zu konzentrieren. Wenn du Daten in BigQuery einspeicherst, musst du dir keine Gedanken über die verschiedenen Arten der Speicherung oder ihre relativen Geschwindigkeits- und Kostenvorteile machen; die Speicherung wird vollständig verwaltet. Derzeit sinken die Kosten für die Speicherung automatisch auf ein niedrigeres Niveau, wenn eine Tabelle 90 Tage lang nicht aktualisiert wird.¹¹

Wir haben bereits unter darüber gesprochen, dass eine Indizierung nicht notwendig ist. Deine SQL-Abfragen können nach jeder Spalte im Datensatz filtern, und BigQuery kümmert sich um die notwendige Abfrageplanung und -optimierung. In den meisten Fällen empfehlen wir dir, deine Abfragen so zu schreiben, dass sie klar und lesbar sind, und dich darauf zu verlassen, dass BigQuery eine gute Optimierungsstrategie wählt. In diesem Buch sprechen wir über Leistungstuning, aber Leistungstuning in BigQuery besteht hauptsächlich aus klarem Denken und der richtigen Wahl der SQL-Funktionen. Du musst dich nicht um Datenbankverwaltungsaufgaben wie Replikation, Defragmentierung oder Disaster Recovery kümmern; all das übernimmt der BigQuery-Dienst für dich.

Die Abfragen werden automatisch auf Tausende von Rechnern skaliert und parallel ausgeführt. Um diese massive Parallelisierung zu ermöglichen, musst du nichts Besonderes tun. Die Maschinen selbst werden transparent für die verschiedenen Phasen deines Auftrags bereitgestellt; du musst diese Maschinen in keiner Weise einrichten.

Da keine Infrastruktur eingerichtet werden muss, gibt es weniger Probleme mit der Sicherheit. Die Daten in BigQuery werden automatisch verschlüsselt, sowohl im Ruhezustand als auch bei der Übertragung. BigQuery kümmert sich um die Sicherheitsaspekte bei der Unterstützung von mandantenfähigen Abfragen und bietet Isolierung zwischen Aufträgen. Deine Datensätze können mit Google Cloud Identity and Access Management (IAM) freigegeben werden, und es ist möglich, die Datensätze (und die Tabellen und Ansichten darin) so zu organisieren, dass sie unterschiedlichen Sicherheitsanforderungen entsprechen, egal ob du Offenheit, Überprüfbarkeit oder Vertraulichkeit brauchst.

Bei anderen Systemen nimmt die Bereitstellung der Infrastruktur für Zuverlässigkeit, Elastizität, Sicherheit und Leistung oft viel Zeit in Anspruch. Da diese Aufgaben der Datenbankverwaltung mit BigQuery auf ein Minimum reduziert werden, haben Unternehmen, die BigQuery einsetzen, mehr Zeit, um sich auf die Gewinnung von Erkenntnissen aus ihren Daten zu konzentrieren.

Wie BigQuery entstanden ist

Ende 2010 zog der Standortleiter des Google-Büros in Seattle mehrere Ingenieure (einer von ihnen ist der Autor dieses Buches) von ihren Projekten ab und gab ihnen einen Auftrag: einen Datenmarktplatz zu bauen. Wir versuchten, den besten Weg zu finden, um einen tragfähigen Marktplatz zu entwickeln. Das Hauptproblem war die Größe der Daten, denn wir wollten nicht nur einen Download-Link anbieten. Ein Datenmarktplatz ist nicht realisierbar, wenn die Leute Terabytes an Daten herunterladen müssen, um damit arbeiten zu können. Wie würdet ihr einen Datenmarktplatz aufbauen, ohne dass die Nutzer/innen die Datensätze zunächst auf ihre eigenen Rechner herunterladen müssen?

Hier kommt ein Prinzip ins Spiel, das von Jim Gray, dem Datenbankpionier, bekannt gemacht wurde. Wenn du "Big Data" hast, so Gray, "willst du die Daten zu den Berechnungen verlagern und nicht die Daten zu den Berechnungen". Gray führt weiter aus:

Das andere wichtige Problem ist, dass es bei immer größeren Datensätzen nicht mehr möglich ist, sie einfach per FTP oder Grep zu übertragen. Ein Petabyte an Daten lässt sich nur schwer per FTP übertragen! Irgendwann brauchst du also Indizes und einen parallelen Datenzugriff, und dabei können dir Datenbanken helfen. Bei der Datenanalyse besteht eine Möglichkeit darin, die Daten zu dir zu bringen, aber die andere Möglichkeit ist, deine Abfrage zu den Daten zu bringen. Du kannst entweder deine Fragen oder die Daten verschieben. Oft stellt sich heraus, dass es effizienter ist, die Fragen zu verschieben als die Daten.¹²

Im Falle des von uns aufgebauten Datenmarktplatzes müssten die Nutzer die Datensätze nicht auf ihre eigenen Rechner herunterladen, wenn wir es ihnen ermöglichen würden, ihre Berechnungen mit den Daten durchzuführen. Wir bräuchten keinen Download-Link bereitzustellen, weil die Nutzer/innen an ihren Daten arbeiten könnten, ohne sie bewegen zu müssen.¹³

Wir, die Googler, die mit dem Aufbau eines Datenmarktplatzes beauftragt waren, beschlossen, dieses Projekt zu verschieben und uns auf den Aufbau einer Rechenmaschine und eines Speichersystems in der Cloud zu konzentrieren. Nachdem wir sichergestellt hatten, dass die Nutzerinnen und Nutzer etwas mit den Daten anfangen konnten, fügten wir weitere Funktionen für den Datenmarktplatz hinzu.

In welcher Sprache sollten die Nutzer ihre Berechnungen schreiben, wenn sie die Daten in die Cloud bringen? Wir haben uns für SQL entschieden, weil es drei wichtige Eigenschaften hat. Erstens ist SQL eine vielseitige Sprache, die es einer großen Anzahl von Menschen, nicht nur Entwicklern, ermöglicht, Fragen zu stellen und Probleme mit ihren Daten zu lösen. Diese Benutzerfreundlichkeit war für uns sehr wichtig. Zweitens ist SQL "relational vollständig", was bedeutet, dass jede Berechnung mit den Daten mit SQL durchgeführt werden kann. SQL ist nicht nur einfach und leicht zugänglich. Es ist auch sehr leistungsfähig. Schließlich, und das ist sehr wichtig für die Wahl einer Cloud-Computation-Sprache, ist SQL in einem wichtigen Punkt nicht "Turing-vollständig": Es bricht immer ab.¹⁴ Da SQL immer abbricht, kann man Berechnungen in der Cloud durchführen, ohne befürchten zu müssen, dass jemand eine Endlosschleife schreibt und die gesamte Rechenleistung im Rechenzentrum für sich beansprucht.

Als nächstes mussten wir eine SQL-Engine auswählen. Google verfügte über eine Reihe interner SQL-Engines, die Daten verarbeiten konnten, darunter auch einige, die sehr beliebt waren. Die fortschrittlichste Engine hieß Dremel; sie wurde bei Google intensiv genutzt und konnte Logs im Umfang von Terabytes in Sekundenschnelle verarbeiten. Dremel überzeugte die Leute schnell davon, eigene MapReduce-Pipelines zu bauen, um ihre Daten zu befragen.

Dremel wurde 2006 von dem Ingenieur Andrey Gubarev entwickelt, der es leid war, auf die Fertigstellung von MapReduces zu warten. In der akademischen Literatur wurden Spaltenspeicher immer beliebter und er entwickelte schnell ein Format für die Speicherung von Spalten(Abbildung 1-4), das mit den Protokollpuffern (Protobufs) umgehen konnte, die bei Google allgegenwärtig sind.

Abbildung 1-4. Spaltenspeicher können die Datenmenge reduzieren, die von Abfragen gelesen wird, die alle Zeilen, aber nicht alle Spalten verarbeiten

Obwohl sich Spaltenspeicher generell gut für Analysen eignen, sind sie für die Logs-Analyse bei Google besonders nützlich, weil viele Teams über eine Art Protobuf arbeiten, die Hunderttausende von Spalten hat. Hätte Andrey einen typischen datensatzorientierten Speicher verwendet, hätten die Nutzerinnen und Nutzer die Dateien Zeile für Zeile lesen müssen und damit eine riesige Menge an Daten in Form von Feldern eingelesen, die sie ohnehin wieder verwerfen würden. Indem er die Daten spaltenweise speicherte, sorgte Andrey dafür, dass ein Benutzer, der nur einige wenige der Tausenden von Feldern in den Protobufs benötigte, nur einen kleinen Bruchteil der gesamten Datenmenge lesen musste. Das war einer der Gründe, warum Dremel in der Lage war, Protokolle im Umfang von Terabytes in Sekundenschnelle zu verarbeiten.

Der andere Grund, warum Dremel die Daten so schnell verarbeiten konnte, war, dass die Abfrage-Engine verteilte Datenverarbeitung nutzte. Dremel skalierte auf Tausende von Arbeitern, indem es die Berechnung als Baum strukturierte, wobei die Filter an den Blättern und die Aggregation an der Wurzel stattfand.

Im Jahr 2010 scannte Google mit Dremel täglich Petabytes an Daten, und viele Mitarbeiter des Unternehmens nutzten es in der einen oder anderen Form. Es war das perfekte Werkzeug für unser neu entstehendes Datenmarktplatz-Team.

Als das Team Dremel produktiver machte, ein Speichersystem hinzufügte, es selbstoptimierend machte und es externen Nutzern zugänglich machte, erkannte das Team, dass eine Cloud-Version von Dremel vielleicht noch interessanter war als ihre ursprüngliche Aufgabe. Das Team benannte sich in "BigQuery" um, in Anlehnung an die Namenskonvention für "Bigtable", die NoSQL-Datenbank von Google.

Bei Google wird Dremel verwendet, um Dateien abzufragen, die auf Colossus, Googles Dateispeicher für Daten, liegen. BigQuery fügte ein Speichersystem hinzu, das eine Tabellenabstraktion und nicht nur eine Dateiabstraktion bot. Dieses Speichersystem war der Schlüssel dazu, dass BigQuery einfach zu bedienen und immer schnell war, denn es ermöglichte wichtige Funktionen wie ACID-Transaktionen (Atomicity, Consistency, Isolation, Durability) und automatische Optimierung und bedeutete, dass die Nutzer keine Dateien verwalten mussten.

Anfangs behielt BigQuery seine Dremel-Wurzeln bei und konzentrierte sich auf das Scannen von Logs. Als jedoch immer mehr Kunden Data Warehousing und komplexere Abfragen durchführen wollten, fügte BigQuery verbesserte Unterstützung für Joins und erweiterte SQL-Funktionen wie analytische Funktionen hinzu. Im Jahr 2016 führte Google die Unterstützung für Standard-SQL in BigQuery ein, so dass die Nutzer/innen Abfragen mit standardkonformem SQL statt mit dem umständlichen ursprünglichen "DremelSQL"-Dialekt durchführen konnten.

BigQuery hat nicht als Data Warehouse angefangen, aber es hat sich im Laufe der Jahre zu einem entwickelt. Diese Entwicklung hat gute und schlechte Seiten. Positiv ist, dass BigQuery entwickelt wurde, um Probleme zu lösen, die Menschen mit ihren Daten haben, auch wenn sie nicht in Data-Warehousing-Modelle passen. Auf diese Weise ist BigQuery mehr als nur ein Data Warehouse. Allerdings fehlten bis vor Kurzem einige Data-Warehousing-Funktionen, die die Menschen erwarten, wie eine Data Definition Language (DDL; z. B. CREATE-Anweisungen) und eine Data Manipulation Language (DML; z. B. INSERT-Anweisungen). BigQuery hat sich daher auf einen doppelten Weg konzentriert: erstens, indem es differenzierte Funktionen hinzufügt, die Google in einer einzigartigen Position anbietet, und zweitens, indem es ein großes Data Warehouse in der Cloud wird.

Was macht BigQuery möglich?

Aus architektonischer Sicht unterscheidet sich BigQuery grundlegend von On-Premises Data Warehouses wie Teradata oder Vertica sowie von Cloud Data Warehouses wie Redshift und Microsoft Azure Data Warehouse. BigQuery ist das erste Data Warehouse, das eine Scale-Out-Lösung ist, d.h. die einzige Grenze für Geschwindigkeit und Skalierung ist die Menge der Hardware im Rechenzentrum.

Dieser Abschnitt beschreibt einige der Komponenten, die BigQuery erfolgreich und einzigartig machen.

Trennung von Datenverarbeitung und Speicherung

In vielen Data Warehouses befinden sich die Rechenleistung und die Speicherung auf derselben physischen Hardware. Diese Kolokation bedeutet, dass du für mehr Speicherung auch mehr Rechenleistung benötigst. Oder um mehr Rechenleistung hinzuzufügen, musst du auch mehr Speicherkapazität kaufen.

Wären die Datenbedürfnisse aller ähnlich, wäre das kein Problem; es gäbe einen einheitlichen goldenen Schnitt von Rechenleistung und Speicherung, an den sich alle halten würden. Aber in der Praxis stellt der eine oder andere Faktor eine Einschränkung dar. Manche Data Warehouses sind durch die Rechenkapazität begrenzt, so dass sie zu Spitzenzeiten langsamer werden. Bei anderen Data Warehouses ist die Speicherkapazität begrenzt, so dass die Verantwortlichen herausfinden müssen, welche Daten sie wegwerfen müssen.

Wenn du die Berechnung von der Speicherung trennst, wie es bei BigQuery der Fall ist, bedeutet das, dass du nie Daten wegwerfen musst, es sei denn, du brauchst sie nicht mehr. Das hört sich vielleicht nicht nach einer großen Sache an, aber der Zugriff auf vollständige Daten ist ungemein mächtig. Wenn du beschließt, etwas anders zu berechnen, kannst du auf die Rohdaten zurückgreifen und sie erneut abfragen. Das wäre nicht möglich, wenn du die Quelldaten aus Platzgründen verworfen hättest. Du möchtest vielleicht herausfinden, warum ein bestimmter Gesamtwert ein seltsames Verhalten zeigt. Das wäre nicht möglich, wenn du die Daten gelöscht hättest, die zur Aggregation beigetragen haben.

Die Skalierung der Rechenleistung ist ebenso leistungsstark. BigQuery-Ressourcen werden in Form von "Slots" bezeichnet, die grob gesagt etwa der Hälfte eines CPU-Kerns entsprechen (wir behandeln Slots ausführlich in Kapitel 6). BigQuery verwendet Slots als Abstraktion, um anzugeben, wie viele physische Rechenressourcen verfügbar sind. Abfragen laufen zu langsam? Füge einfach mehr Slots hinzu. Mehr Leute wollen Berichte erstellen? Füge mehr Slots hinzu. Willst du deine Ausgaben senken? Verringere deine Slots.

Da BigQuery ein mandantenfähiges System ist, das große Pools von Hardwareressourcen verwaltet, ist es in der Lage, die Slots pro Abfrage oder pro Nutzer zu verteilen. Es ist möglich, Hardware für dein Projekt oder deine Organisation zu reservieren, oder du kannst deine Abfragen im gemeinsamen On-Demand-Pool laufen lassen. Durch diese gemeinsame Nutzung von Ressourcen kann BigQuery sehr große Mengen an Rechenleistung für deine Abfragen bereitstellen. Wenn du mehr Rechenleistung benötigst, als im On-Demand-Pool verfügbar ist, kannst du über die BigQuery-Reservierungs-API mehr davon kaufen.

Einige BigQuery-Kunden haben Reservierungen in Höhe von Zehntausenden von Slots, was bedeutet, dass diese Abfragen, wenn sie jeweils nur eine Abfrage ausführen, Zehntausende von CPU-Kernen auf einmal verbrauchen können. Mit einigen vernünftigen Annahmen über die Anzahl der CPU-Zyklen pro verarbeiteter Zeile ist es ziemlich einfach zu erkennen, dass diese Instanzen Milliarden oder sogar Billionen von Zeilen pro Sekunde verarbeiten können.

In BigQuery gibt es einige Kunden, die Petabytes an Daten haben, aber nur eine relativ kleine Menge davon täglich nutzen. Andere Kunden speichern nur ein paar Gigabyte an Daten, führen aber komplexe Abfragen durch, die Tausende von CPUs beanspruchen. Es gibt keine Einheitslösung, die für alle Anwendungsfälle funktioniert. Glücklicherweise ermöglicht die Trennung von Rechenleistung und Speicherung, dass BigQuery eine breite Palette von Kundenbedürfnissen abdecken kann.

Speicherung und Netzwerkinfrastruktur

BigQuery unterscheidet sich von anderen Cloud-Data-Warehouses dadurch, dass die Abfragen hauptsächlich von rotierenden Festplatten in einem verteilten Dateisystem bedient werden. Die meisten konkurrierenden Systeme müssen Daten in den Rechenknoten zwischenspeichern, um eine gute Leistung zu erzielen. BigQuery hingegen verlässt sich auf zwei einzigartige Systeme von Google, das Colossus File System und das Jupiter-Netzwerk, um sicherzustellen, dass die Daten schnell abgefragt werden können, unabhängig davon, wo sie sich im Compute-Cluster befinden.

Googles Jupiter Networking Fabric basiert auf einer Netzwerkkonfiguration, bei der kleinere (und damit billigere) Switches so angeordnet sind, dass sie die Leistung erbringen, für die sonst ein viel größerer logischer Switch erforderlich wäre. Diese Topologie von Switches, zusammen mit einem zentralisierten Software-Stack und kundenspezifischer Hard- und Software, ermöglicht eine Bandbreite von einem Petabit innerhalb eines Rechenzentrums. Das entspricht 100.000 Servern, die mit 10 Gbit/s kommunizieren, und bedeutet, dass BigQuery ohne die Notwendigkeit einer gemeinsamen Rechen- und Speicheranlage arbeiten kann. Wenn sich die Rechner, auf denen die Festplatten gehostet werden, am anderen Ende des Rechenzentrums befinden als die Rechner, auf denen die Berechnungen ausgeführt werden, läuft die Berechnung genauso schnell, wie wenn sich die beiden Rechner im selben Rack befinden würden.

Die schnelle Netzwerkstruktur ist in zweierlei Hinsicht nützlich: zum Einlesen von Daten von einer Festplatte und zum Umschalten zwischen Abfragephasen. Wie bereits erwähnt, ermöglicht die Trennung von Berechnung und Speicherung in BigQuery jedem Rechner im Rechenzentrum, Daten von jeder Festplatte einzulesen. Das setzt allerdings voraus, dass die erforderlichen Eingabedaten für die Abfragen mit sehr hoher Geschwindigkeit über das Netzwerk gelesen werden. Die Einzelheiten von Shuffle werden in Kapitel 6 beschrieben, aber es reicht schon zu wissen, dass komplexe verteilte Abfragen in der Regel das Verschieben großer Datenmengen zwischen den Rechnern in Zwischenschritten erfordern. Ohne ein schnelles Netzwerk zwischen den Rechnern, die die Arbeit erledigen, würde Shuffle zu einem Flaschenhals werden, der die Abfragen erheblich verlangsamt.

Die Netzwerkinfrastruktur bietet mehr als nur Geschwindigkeit: Sie ermöglicht auch eine dynamische Bereitstellung von Bandbreite. Die Google-Rechenzentren sind über ein Backbone-Netzwerk namens B4 verbunden, das softwaredefiniert ist, um den verschiedenen Nutzern elastisch Bandbreite zuzuweisen und eine zuverlässige Servicequalität für Vorgänge mit hoher Priorität zu gewährleisten. Dies ist entscheidend für die Durchführung leistungsstarker, gleichzeitiger Abfragen.

Ein schnelles Netzwerk reicht jedoch nicht aus, wenn das Festplattensubsystem langsam ist oder nicht über genügend Kapazität verfügt. Um interaktive Abfragen zu unterstützen, müssen die Daten schnell genug von den Festplatten gelesen werden, damit sie die verfügbare Netzwerkbandbreite sättigen können. Googles verteiltes Dateisystem heißt Colossus und kann Hunderttausende von Festplatten koordinieren, indem es alte, kalte Daten ständig neu ausbalanciert und neu geschriebene Daten gleichmäßig auf die Festplatten verteilt.¹⁵ Das bedeutet, dass der effektive Durchsatz bei mehreren zehn Terabyte pro Sekunde liegt. Durch die Kombination dieses effektiven Durchsatzes mit effizienten Datenformaten und einer effizienten Speicherung ermöglicht BigQuery die Abfrage von Tabellen im Petabyte-Bereich in wenigen Minuten.

Verwaltete Speicherung

Das Speichersystem von BigQuery basiert auf der Idee, dass bei einer strukturierten Speicherung die Tabelle und nicht die Datei die geeignete Abstraktion ist. Einige andere Cloud-basierte und Open-Source-Datenverarbeitungssysteme stellen den Nutzern das Konzept der Datei zur Verfügung, so dass die Nutzer für die Verwaltung der Dateigrößen und die Sicherstellung der Konsistenz des Schemas verantwortlich sind. Auch wenn es möglich ist, Dateien mit einer angemessenen Größe für einen statischen Datenspeicher zu erstellen, ist es bekanntermaßen schwierig, optimale Dateigrößen für Daten beizubehalten, die sich im Laufe der Zeit ändern. Ähnlich schwierig ist es, ein konsistentes Schema aufrechtzuerhalten, wenn du eine große Anzahl von Dateien mit selbstbeschreibenden Schemata hast (z. B. Avro oder Parquet) - normalerweise führt jedes Software-Update der Systeme, die diese Dateien produzieren, zu Änderungen am Schema. BigQuery stellt sicher, dass alle Daten in einer Tabelle ein einheitliches Schema haben, und erzwingt einen geeigneten Migrationspfad für historische Daten. Indem BigQuery die zugrundeliegenden Datenformate und Dateigrößen vom Nutzer abstrahiert, kann es eine nahtlose Erfahrung bieten, so dass die Abfragen immer schnell sind.

Es gibt einen weiteren Vorteil, wenn BigQuery seine eigene Speicherung verwaltet: BigQuery kann auf eine Weise schneller werden, die für den Endnutzer transparent ist. Zum Beispiel können Verbesserungen bei den Speicherformaten automatisch auf die Nutzerdaten angewendet werden. Auch Verbesserungen der Speicherinfrastruktur sind sofort verfügbar. Da BigQuery die gesamte Speicherung verwaltet, müssen sich die Nutzer/innen nicht um die Sicherung oder Replikation kümmern. Alles, von Upgrades und Replikation bis hin zu Sicherung und Wiederherstellung, wird transparent und automatisch vom Speicherverwaltungssystem erledigt.

Ein wesentlicher Vorteil der Arbeit mit strukturierter Speicherung auf der Abstraktionsebene einer Tabelle (statt einer Datei) und der für den Endbenutzer transparenten Speicherverwaltung dieser Tabellen ist, dass BigQuery mit Tabellen datenbankähnliche Funktionen wie DML unterstützen kann. Du kannst eine Abfrage starten, die Zeilen in einer Tabelle aktualisiert oder löscht, und es BigQuery überlassen, den besten Weg zu finden, um die Speicherung dieser Informationen zu ändern. BigQuery-Operationen sind ACID, das heißt, alle Abfragen werden vollständig oder gar nicht übertragen. Du kannst sicher sein, dass deine Abfragen niemals den Zwischenstand einer anderen Abfrage sehen und dass Abfragen, die nach Abschluss einer anderen Abfrage gestartet werden, niemals alte Daten sehen. Du hast die Möglichkeit, die Speicherung durch die Angabe von Direktiven, die die Speicherung der Daten steuern, feinabzustimmen, aber diese arbeiten auf der Abstraktionsebene von Tabellen, nicht von Dateien. Es ist zum Beispiel möglich, die Partitionierung und das Clustering von Tabellen zu steuern (wir behandeln diese Funktionen ausführlich in Kapitel 7) und dadurch die Leistung zu verbessern und/oder die Kosten für Abfragen auf diese Tabellen zu senken.

Die verwaltete Speicherung ist stark typisiert, was bedeutet, dass die Daten beim Eintritt in das System validiert werden. Da BigQuery die Speicherung verwaltet und es den Nutzern erlaubt, nur über seine APIs mit dieser Speicherung zu interagieren, kann es sich darauf verlassen, dass die zugrunde liegenden Daten nicht außerhalb von BigQuery geändert werden. So kann BigQuery garantieren, dass beim Lesen der Daten in der von ihm verwalteten Speicherung kein Validierungsfehler auftritt. Diese Garantie impliziert auch ein verbindliches Schema, das nützlich ist, wenn du herausfinden willst, wie du deine Tabellen abfragen kannst. Das Vorhandensein eines maßgeblichen Schemas verbessert nicht nur die Abfrageleistung, sondern hilft auch dabei, die Daten zu verstehen, denn ein BigQuery-Schema enthält nicht nur Typinformationen, sondern auch Anmerkungen und Tabellenbeschreibungen darüber, wie die Felder verwendet werden können.

Ein Nachteil der verwalteten Speicherung ist, dass es schwieriger ist, mit anderen Frameworks direkt auf die Daten zuzugreifen und sie zu verarbeiten. Wären die Daten zum Beispiel auf der Abstraktionsebene von Dateien verfügbar gewesen, hättest du einen Hadoop-Auftrag direkt über einen BigQuery-Datensatz laufen lassen können. BigQuery löst dieses Problem, indem es eine strukturierte parallele API zum Lesen der Daten bereitstellt. Mit dieser API kannst du mit voller Geschwindigkeit aus Spark- oder Hadoop-Aufträgen lesen, aber sie bietet auch zusätzliche Funktionen wie Projektion, Filterung und dynamisches Rebalancing.

Integration mit Google Cloud Platform

Google Cloud folgt dem Prinzip der "Trennung der Zuständigkeiten", bei dem eine kleine Anzahl von qualitativ hochwertigen, stark fokussierten Produkten eng miteinander integriert sind. Deshalb ist es wichtig, die gesamte Google Cloud Platform (GCP) zu betrachten, wenn du BigQuery mit anderen Datenbankprodukten vergleichst.

Eine Reihe von verschiedenen GCP-Produkten erweitert den Nutzen von BigQuery oder macht es einfacher zu verstehen, wie BigQuery verwendet wird. Wir gehen in diesem Buch auf viele dieser verwandten Produkte im Detail ein, aber es lohnt sich, die allgemeine Trennung der Zuständigkeiten zu kennen:

• Die Überwachungs- und Audit-Protokolle von Stackdriver bieten Möglichkeiten, die Nutzung von BigQuery in deinem Unternehmen zu verstehen. Im März 2020 wurde Stackdriver in Cloud Logging und Cloud Monitoring umbenannt.

• Cloud Dataproc bietet die Möglichkeit, BigQuery-Tabellen mit Apache Spark-Programmen zu lesen, zu verarbeiten und zu beschreiben. Dadurch kann BigQuery als Speicherschicht für einen Hadoop-basierten Data Lake dienen. In der Google Cloud ist die Grenze zwischen Data Warehouse und Data Lake fließend.

• Mit föderierten Abfragen kann BigQuery Daten abfragen, die in Google Cloud Storage, Cloud SQL (einer relationalen Datenbank), Bigtable (einer NoSQL-Datenbank), Spanner (einer verteilten Datenbank) oder Google Drive (das Tabellenkalkulationen bietet) gespeichert sind. Dank der föderierten Abfragen kann BigQuery als Verarbeitungsmaschine für einen Data Lake fungieren, dessen Speicherung auf Cloud Storage erfolgt.

• DieGoogle Cloud Data Loss Prevention API hilft dir bei der Verwaltung sensibler Daten und bietet die Möglichkeit, personenbezogene Daten (PII) aus deinen Tabellen zu entfernen oder zu maskieren.

• Andere APIs für maschinelles Lernen erweitern die Möglichkeiten für Daten in BigQuery. So kann die Cloud Natural Language API zum Beispiel Personen, Orte, Stimmungen und mehr in Freiformtexten (z. B. in Kundenrezensionen) identifizieren, die in einer Tabellenspalte gespeichert sind.

• Mit AutoML Tables und AutoML Text kannst du leistungsstarke benutzerdefinierte Modelle für maschinelles Lernen aus Daten erstellen, die in BigQuery-Tabellen gespeichert sind.

• Der Cloud Data Catalog bietet die Möglichkeit, Daten in deinem Unternehmen zu entdecken.

• Du kannst Cloud Pub/Sub verwenden, um Streaming-Daten aufzunehmen, und Cloud Dataflow, um sie zu transformieren und in BigQuery zu laden. Du kannst Cloud Dataflow auch zur Durchführung von Streaming-Abfragen verwenden. Natürlich kannst du die Streaming-Daten auch interaktiv in BigQuery selbst abfragen.¹⁶

• Data Studio bietet Diagramme und Dashboards, die von Daten in BigQuery gesteuert werden. Looker bietet eine unternehmensweite Business Intelligence (BI)-Datenplattform mit einer semantischen Schicht. Tools von Drittanbietern wie Tableau unterstützen ebenfalls BigQuery als Backend.

• Die Cloud AI Platform bietet die Möglichkeit, anspruchsvolle maschinelle Lernprogramme aus Daten in BigQuery zu trainieren. Sie bietet außerdem die Möglichkeit, die Hyperparameter von BigQuery ML-Modellen zu optimieren und sie für Online-Vorhersagen einzusetzen.

• Mit dem Zeitplannungsprogramm und den Cloud-Funktionen kannst du BigQuery-Abfragen als Teil eines größeren Workflows planen oder auslösen.

• Cloud Data Fusion bietet Drag-and-Drop-Tools und Konnektoren zur Datenintegration. Cloud Dataflow bietet die Möglichkeit, zustandsorientierte ETL-Pipelines zu erstellen.

• Cloud Composer ermöglicht die Orchestrierung von BigQuery-Aufträgen zusammen mit Aufgaben, die in Cloud Dataflow oder anderen Verarbeitungsframeworks ausgeführt werden müssen, egal ob in der Google Cloud oder on-premises in einer Hybrid-Cloud-Konfiguration.

Zusammengenommen haben BigQuery und das GCP-Ökosystem Funktionen, die mehrere andere Datenbankprodukte von anderen Cloud-Anbietern umfassen; du kannst sie als Analytics Warehouse, aber auch als ELT-System, Data Lake (Abfragen über Dateien) oder als BI-Quelle nutzen. Der Rest dieses Buches zeichnet ein breites Bild davon, wie du BigQuery in all seinen Aspekten nutzen kannst.

Sicherheit und Compliance

Die Integration mit GCP geht über die reine Interoperabilität mit anderen Produkten hinaus. Die übergreifenden Funktionen der Plattform sorgen für einheitliche Sicherheit und Compliance.

Die schnellste Hardware und die fortschrittlichste Software nützen dir wenig, wenn du ihnen deine Daten nicht anvertrauen kannst. Das Sicherheitsmodell von BigQuery ist eng mit dem Rest von GCP verzahnt, so dass es möglich ist, einen ganzheitlichen Blick auf deine Datensicherheit zu werfen. BigQuery nutzt das IAM-Zugriffskontrollsystem von Google, um einzelnen Nutzern oder Nutzergruppen bestimmte Berechtigungen zuzuweisen. BigQuery ist außerdem eng mit den Google Virtual Private Cloud (VPC)-Richtlinien verknüpft, die Nutzer/innen davor schützen können, von außerhalb deines Unternehmens auf Daten zuzugreifen oder diese an Dritte zu exportieren. Sowohl die IAM- als auch die VPC-Kontrollen sind so konzipiert, dass sie mit allen Google Cloud-Produkten funktionieren, sodass du dir keine Sorgen machen musst, dass bestimmte Produkte eine Sicherheitslücke schaffen.

BigQuery ist in jeder Region verfügbar, in der Google Cloud vertreten ist, sodass du die Daten an dem Ort deiner Wahl verarbeiten kannst. Zum jetzigen Zeitpunkt verfügt Google Cloud über mehr als zwei Dutzend Rechenzentren auf der ganzen Welt, und es werden laufend neue eröffnet. Wenn du geschäftliche Gründe hast, deine Daten in Australien oder Deutschland zu speichern, ist das auch möglich. Erstelle einfach deinen Datensatz mit dem australischen oder deutschen Regionalcode, und alle deine Abfragen werden innerhalb dieser Region durchgeführt.

Einige Unternehmen haben sogar noch strengere Anforderungen an den Datenstandort, die über den Ort der Speicherung und Verarbeitung der Daten hinausgehen. Sie wollen insbesondere sicherstellen, dass ihre Daten nicht kopiert werden oder auf andere Weise ihre physische Region verlassen können. GCP verfügt über physische Regionskontrollen, die produktübergreifend gelten. Du kannst eine Richtlinie "VPC Service Controls" erstellen, die die Datenbewegung außerhalb einer ausgewählten Region verbietet. Wenn du diese Kontrollen aktiviert hast, können die Nutzer/innen keine Daten in andere Regionen kopieren oder in Google Cloud Storage-Buckets in einer anderen Region exportieren.

Zusammenfassung

BigQuery ist ein hochgradig skalierbares Data Warehouse, das schnelle SQL-Analysen über große Datenmengen auf serverlose Weise ermöglicht. Obwohl die Nutzer/innen die Skalierbarkeit und Geschwindigkeit von BigQuery zu schätzen wissen, schätzen die Führungskräfte von Unternehmen oft die transformativen Vorteile, die sich aus der Möglichkeit ergeben, Ad-hoc-Abfragen auf serverlose Weise durchzuführen und so die datengestützte Entscheidungsfindung für alle Bereiche des Unternehmens zu öffnen.

Um Daten in BigQuery einzulesen, kannst du eine EL-Pipeline (für das regelmäßige Laden von Logdateien), eine ETL-Pipeline (für die Anreicherung oder Qualitätskontrolle von Daten) oder eine ELT-Pipeline (für die Erkundung) verwenden.

BigQuery wurde für Datenanalysen (OLAP) entwickelt und bietet vollständige Unterstützung für SQL:2011. BigQuery kann seine Skalierbarkeit und Geschwindigkeit erreichen, weil es auf innovativen technischen Ideen wie der Verwendung von spaltenförmiger Speicherung, der Unterstützung von verschachtelten und wiederholten Feldern und der Trennung von Berechnung und Speicherung beruht, über die Google weitere Publikationen veröffentlicht hat. BigQuery ist Teil des GCP-Ökosystems von Big-Data-Analytics-Tools und lässt sich sowohl in die Infrastruktur (wie Sicherheit, Überwachung und Protokollierung) als auch in die Datenverarbeitung und das maschinelle Lernen (wie Streaming, Cloud DLP und AutoML) der Plattform integrieren.

¹ In Wirklichkeit musst du mit der Aufzeichnung schon zu dem Zeitpunkt beginnen, an dem die Kunden die Ausrüstung ausleihen, damit du weißt, ob die Kunden sich mit der Ausrüstung aus dem Staub gemacht haben. Aber es ist noch zu früh in diesem Buch, um sich darüber Gedanken zu machen!

² In diesem Buch verwenden wir den Begriff "Ad-hoc-Abfrage", um eine Abfrage zu bezeichnen, die ohne vorherige Vorbereitung der Datenbank mit Hilfe von Funktionen wie Indizes geschrieben wird.

³ Jeffrey Dean und Sanjay Ghemawat, "MapReduce: Simplified Data Processing on Large Clusters", OSDI '04: Sixth Symposium on Operating Systems Design and Implementation, San Francisco, CA (2004), S. 137-150. Verfügbar unter https://research.google.com/archive/mapreduce-osdi04.pdf.

⁴ Auf der Google Cloud Platform löst Cloud Dataproc (das verwaltete Hadoop-Angebot) dieses Problem auf eine andere Weise. Aufgrund der hohen Bandbreite, die in den Google-Rechenzentren zur Verfügung steht, können Cloud Dataproc-Cluster auftragsspezifisch sein - die Daten werden auf Google Cloud Storage gespeichert und bei Bedarf über die Leitung gelesen. Das ist nur möglich, wenn die Bandbreiten hoch genug sind, um den Festplattengeschwindigkeiten nahe zu kommen. Probiere das nicht zu Hause aus.

⁵ Um dir das Kopieren und Einfügen zu erleichtern, findest du alle Code- und Abfragesnippets in diesem Buch (einschließlich der Abfrage im Beispiel) im GitHub-Repository für dieses Buch.

⁶ Nicht speziell du. Dies ist ein öffentlicher Datensatz, und der Eigentümer des Datensatzes hat allen authentifizierten Nutzern diese Erlaubnis erteilt. Du kannst mit deinen Daten weniger freizügig umgehen und den Datensatz nur mit Personen innerhalb deines Bereichs oder deines Teams teilen.

⁷ Dieser Code kann aus dem GitHub-Repository des Buches heruntergeladen werden.

⁸ Bedenke, dass beide Autoren in Seattle leben, wo es 150 Tage im Jahr regnet.

⁹ Weitere Informationen über das Format der spaltenweisen Speicherung findest du in "Wie BigQuery entstanden ist".

¹⁰ Zum Beispiel, um Conversion-Metriken zu berechnen, die auf der Entfernung basieren, die ein Kunde zurücklegen muss, um ein Produkt zu kaufen.

¹¹ Wir gehen davon aus, dass alle Preisangaben zum Zeitpunkt des Verfassens dieses Buches korrekt sind, aber bitte sieh dir die entsprechenden Richtlinien und Preislisten an, da sie sich ändern können.

¹² Jim Gray über eScience: A Transformed Scientific Method", aus The Fourth Paradigm: Data-Intensive Scientific Discovery, ed. Tony Hey, Stewart Tansley, and Kristin Tolle (Microsoft, 2009), xiv. Verfügbar unter https://oreil.ly/M6zMN.

¹³ Heute bietet BigQuery die Möglichkeit, Tabellen und Ergebnisse in die Google Cloud Speicherung zu exportieren, also haben wir den Download-Link doch gebaut! Aber BigQuery ist nicht nur ein Download-Link - die meisten Anwendungen von BigQuery beziehen sich auf die Daten vor Ort.

¹⁴ SQL hat zwar ein RECURSIVE-Schlüsselwort, aber wie viele SQL-Engines unterstützt BigQuery dieses nicht. Stattdessen bietet BigQuery bessere Möglichkeiten, mit hierarchischen Daten umzugehen, indem es Arrays und Verschachtelungen unterstützt.

¹⁵ Mehr über Colossus erfährst du unter http://www.pdsw.org/pdsw-discs17/slides/PDSW-DISCS-Google-Keynote.pdf und https://www.wired.com/2012/07/google-colossus/.

¹⁶ Die Trennung der Zuständigkeiten besteht darin, dass Cloud Dataflow besser für die laufende, routinemäßige Verarbeitung geeignet ist, während BigQuery besser für die interaktive Ad-hoc-Verarbeitung geeignet ist. Sowohl Cloud Dataflow als auch BigQuery können sowohl Batch- als auch Streaming-Daten verarbeiten, und es ist möglich, SQL-Abfragen in Cloud Dataflow auszuführen.