Start-Checkliste für BigQuery

Einführung

Diese Start-Checkliste für BigQuery enthält empfohlene Aktivitäten, die Sie vor dem Start einer kommerziellen Anwendung, die Google BigQuery nutzt, ausführen sollten. Sie umfasst nur auf BigQuery bezogene Aktivitäten. In der allgemeinen Start-Checkliste für die Google Cloud Platform finden Sie Aktivitäten, die für alle Dienste ausgeführt werden sollten.

Die Start-Checkliste für BigQuery richtet sich an Entwickler, die Erfahrung im Umgang mit BigQuery haben. Wenn Sie BigQuery das erste Mal verwenden, erfahren Sie in dieser Anleitung nicht, wie damit gearbeitet wird.

Die Checkliste ist in die folgenden Abschnitte unterteilt:

  • Architekturgestaltung und Entwicklung
  • Sanfter Start
  • Endgültiger Start

Die Abschnitte werden in der Reihenfolge vorgestellt, in der Sie den Start Ihrer Anwendung vorbereiten sollten. Sie sollten also mit der Checkliste für Architekturgestaltung und Entwicklung beginnen, da sie Aktivitäten enthält, die Sie zu Beginn des Entwicklungszyklus Ihrer Anwendung durchführen sollten. Die Checkliste für den sanften Start wiederum beinhaltet Aktivitäten, die kurz vor dem Start der Anwendung empfohlen werden. Der genaue zeitliche Ablauf der Checklistenaktivitäten und die Dauer hängen jedoch von Ihrem Zeitrahmen für die Anwendungsentwicklung ab.

Checkliste für Architekturgestaltung und Entwicklung

Diese Checkliste sollten Sie am Anfang der Anwendungsentwicklung abarbeiten. Sie können Aktivitäten aus den einzelnen Gruppen parallel ausführen. Die Aktivitäten mit Bezug zur Softwarearchitektur sollten Sie jedoch so früh wie möglich beginnen, da sie länger dauern.

Aktivität
Community/Gruppen/Foren
❑  
Holen Sie sich auf Stack Overflow Unterstützung bei der Google BigQuery-Community. Hier finden Sie viele hilfreiche Informationen und praktische Tipps.
❑  
Abonnieren Sie die Gruppe Google BigQuery – Announce.
Schemadesign
❑  
Entwerfen Sie das Schema auf Grundlage des Bedarfs der Abfrage dieses Schemas. BigQuery unterstützt verschachtelte und wiederkehrende Felder (Typ: RECORD), sodass 1:n-Beziehungen in einer denormalisierten Tabelle möglich sind. Nutzen Sie diese Felder, wenn es erforderlich ist, behalten Sie jedoch eine Strategie für den Zugriff auf solche Felder bei. Erstellen Sie gegebenenfalls logische Ansichten für eine häufige Aufhebung der Verschachtelung wiederkehrender Felder. Schätzen Sie die Abfragekosten.
❑  
Das Abfragen von wiederkehrenden Feldern wird nach ein bis zwei Verschachtelungsebenen zunehmend schwieriger. Achten Sie also darauf, dass die Tiefe der Verschachtelung Ihren Anforderungen entspricht.
❑  
Verknüpfungen in BigQuery sind zwar leistungsfähig, doch kann die Leistung einiger Abfragen durch Denormalisierung verbessert werden. Überlegen Sie sich, an welchen Stellen in Ihrem Datenmodell Verknüpfbarkeit wichtig ist.
❑  
Mit BigQuery können Tabellen über DML angehängt oder aktualisiert werden. DML ist für Aktualisierungs-, Lösch- und Einfügevorgänge im Bulk geeigneter als für die Änderung einzelner Zeilen. Stellen Sie sicher, dass Ihre Aktualisierungsmuster mit einem OLAP-System konsistent sind.
❑  
Im Gegensatz zu einem herkömmlichen RDBMS gibt es keine Primär-/Sekundärschlüssel oder Zeilen-ID-Schlüssel. Falls unbedingt erforderlich, legen Sie eine Spalte im Tabellenschema für diesen Zweck fest.
Datenvolumen schätzen
❑  
Berechnen Sie die Datenmenge, die anfangs hochgeladen werden muss, um eine Ausgangsbasis zu erhalten.
❑  
Berechnen Sie die Datenmenge, die inkrementell hochgeladen wird, und mit welcher Geschwindigkeit dies erfolgt (stündlich/täglich/wöchentlich).
❑  
Berechnen Sie die Datenmenge, die über eine Ablaufzeit verfügt (sofern vorhanden), und wie häufig Daten ablaufen.
Abfrageverarbeitung schätzen
❑  
Ermitteln Sie, welche Arten von Abfragen täglich an BigQuery-Datasets ausgeführt werden. Stackdriver-Monitoring stellt nützliche Diagnosen zu Ressourcennutzung, parallelen Abfragen und Dataset-Größen bereit.
❑  
Legen Sie eine Strategie für die Tabellenpartitionierung/-fragmentierung fest. Wenn zum Beispiel Abfragen, die während des Tages ausgeführt werden, für Daten relevant sind, die während des Tages gesammelt werden, erstellen Sie eine Tabelle pro Tag. Um Daten über mehrere Tage hinweg zusammenzufassen, führen Sie Abfragen mithilfe der Tabellenplatzhalter oder der \_PARTITIONTIME-Pseudospalte aus.
❑  
Berechnen Sie die Datenmenge (Anzahl von Abfragen x verarbeitete Daten pro Abfrage), die täglich von BigQuery verarbeitet wird. Beachten Sie, dass BigQuery die Verarbeitung einzelner Spalten (nicht die gesamte Zeile) in Rechnung stellt. Berücksichtigen Sie dies bei Ihrer Berechnung. Beachten Sie zudem, dass die Spalte, auf die in Abfragen verwiesen wird, einen vollständigen Scan der Spalte aufruft.
Kontingentverwaltung
❑  
Verschaffen Sie sich Kenntnis über die standardmäßigen Kontingente bei BigQuery.
❑  
Führen Sie eine Kontingent-Analyse in den folgenden Bereichen durch (sofern zutreffend):
  • Die Anzahl der Ladejobs pro Tag, die zum Laden von Daten in BigQuery erforderlich sind.
  • Die Anzahl der Ladejobs pro Tabelle pro Tag in BigQuery.
  • Bei Verwendung einer Streaming-API die Anzahl der Streamings von Insert-Anweisungen, die Zeilengröße von Einfügungen, maximale Zeilen pro Sekunde, maximale Zeilen pro Anfrage sowie weitere Streaming-API-spezifische Parameter.
  • Die Anzahl von Abfragen, die von Ihrer Anwendung an BigQuery gesendet werden.
  • Die Anzahl von gleichzeitigen Sitzungen, die für das gleichzeitige Ausführen von Abfragen verwendet werden.
  • Die Anzahl von Exportjobs, die täglich zum Extrahieren von Daten von BigQuery ausgeführt werden.
  • Auch für die API zum Aufrufen von BigQuery-Vorgängen bestehen Raten- und Tageslimits. Weitere Informationen finden Sie unter API-Ratenlimits.
❑  
Wenn das Kontingent unzureichend ist, beantragen Sie eine Anpassung des Kontingents über das Google for Work Support Center.
Kostenanalyse
❑  
Berechnen Sie anhand des geschätzten Datenvolumens und der voraussichtlichen Abfrageverarbeitung die Kosten für die Speicherung und Verarbeitung in BigQuery. Verwenden Sie hierfür die Preisübersicht für BigQuery und/oder den Preisrechner.
❑  
Berücksichtigen Sie die folgenden Empfehlungen zur Kostenoptimierung:
  • Wählen Sie nur relevante Spalten für Ihre Abfragen aus. Beachten Sie, dass BigQuery einen vollständigen Scan an der ausgewählten Spalte ausführt (und in Rechnung stellt), unabhängig von den Filtern in der Where-Klausel.
  • Partitionieren/fragmentieren Sie die Tabellen in kleinere Einheiten, um die Verarbeitungskosten zu optimieren. Es gilt oft, einen Kompromiss zwischen Optimierung und Leistung zu finden. Wenn Sie zu viele kleine Tabellen haben, besteht für das Laden jeder Tabelle, auf die in der Abfrage verwiesen wird, ein fester Verarbeitungsaufwand. Dies könnte sich auf die Leistung auswirken.
  • Testen Sie die Abfragen an kleineren Partitionen der Tabelle statt an einer großen Tabelle.
  • Prüfen Sie bei Verwendung der API die Abfragen auf Syntax und rufen Sie Datenverarbeitungsstatistiken mithilfe des Flags dryRun ab.
  • Löschen Sie ältere Tabellen, wenn diese für Abfragen nicht mehr erforderlich sind, oder nutzen Sie die Ablaufzeit für Tabellen.
Sicherheit
❑  
Lesen Sie die IAM-Richtlinien für BigQuery, um sicherzustellen, dass die richtigen Berechtigungen für den Dataset-Zugriff und die Jobausführung erteilt wurden. Beachten Sie folgende Punkte:
  • Überprüfen Sie die BigQuery-Berechtigungen für Projektmitglieder, um sicherzustellen, dass die Sicherheitsrichtlinien befolgt werden. Mit der Rolle bigquery.User können Nutzer Jobs in Ihrem Projekt ausführen. Mit der Rolle dataset.Viewer erhalten sie Leserechte für alle Tabellen in einem bestimmten Dataset. Die Rollen dataset.Editor und dataset.Owner sollten nur gewährt werden, wenn Nutzer Tabellen oder Datensätze ändern müssen.
  • Wenn bestimmte Datasets für Teammitglieder freigegeben werden müssen, verwenden Sie stattdessen die Funktion zum Freigeben von Datasets oder erteilen Sie explizite IAM-Rollen.
  • Wenn Sie präzisere Sicherheitsfunktionen für den Zugriff benötigen, verwenden Sie Autorisierte Ansichten.
Daten vor BigQuery vorverarbeiten
❑  
Ziehen Sie eine Vorverarbeitung der Daten vor dem Laden der Daten in BigQuery in Betracht, um die Kosten und Leistung zu optimieren. Sie können zum Beispiel Folgendes unternehmen:
  • Vorverarbeiten Sie unnötige Typisierungen und Berechnungen.
  • Verknüpfen Sie vorab häufig auftretende Verknüpfungen (Joins).
  • Fassen Sie vorab Messwerte und häufig ausgeführte Analysen zusammen.
❑  
Führen Sie mithilfe von BigQuery, Google Cloud Dataflow, Google Cloud Dataproc oder ETL-Tools eine Vorverarbeitung (Transformieren, Denormalisieren usw.) der Daten durch.
❑  
Ziehen Sie mehrere verschiedene Versionen desselben Datasets in Betracht, das für unterschiedliche Abfragetypen unterschiedlich strukturiert wird.
❑  
Da DML-Anweisungen pro Tabelle ein Tageslimit haben, sollten Aktualisierungen/Löschungen von Tabellen stapelweise erfolgen.
Abfragen abstimmen und testen
❑  
Testen Sie die Abfragen am erwarteten Datenvolumen und stimmen Sie sie entsprechend den folgenden Prinzipien ab:
  • Lassen Sie unnötige Spalten aus der Select-Klausel aus, um Kosten zu reduzieren und die Leistung zu verbessern.
  • Nutzen Sie im Kontext von verschachtelten Abfragen effektiv die Where-Klauseln, um Daten in den inneren Abfragen herauszufiltern, sodass die äußeren Abfragen weniger Daten zu verarbeiten haben.
  • Vereinfachen Sie soweit wie möglich nach innen, verwenden Sie dabei WHERE-Klauseln (sofern möglich).
  • Verschieben Sie gewichtige Filter, wie z. B. regexp, an das Ende.
  • Vermeiden Sie eine Gruppierung auf Strings, wenn die ursprünglichen entsprechenden Daten verfügbar sind: Verwenden Sie Zeitstempel statt Strings.
  • Versuchen Sie, ORDER BY und LIMIT in den äußeren Abfragen zu verwenden. Vermeiden Sie ORDER BY so gut wie möglich in den inneren Abfragen.
  • Beachten Sie, dass die Verwendung von GROUP BY bei verzerrten (großen) Gruppen langfristig zu erhöhter Latenz führen kann. Filtern Sie diese heraus, um die Abfrageleistung zu verbessern.
  • Ziehen Sie die Verwendung von IF/CASE oder analytischen SQL-Funktionen statt Selbstverknüpfungen (Self-Joins) in Betracht, da sie im Vergleich zu Selbstverknüpfungen einen geringeren Verarbeitungsaufwand haben.
Datenvisualisierung
❑  
BigQuery ist ein Tool zum Abfragen von Daten in großen Datasets. Zum Zweck der Datenvisualisierung besteht eine starke Anbindung an Drittanbietertools:
  • Google Data Studio
  • Produktivitätstools für den Einsatz im Büro wie Google Tabellen und Microsoft Excel.
  • Kommerzielle Tools wie Tableau, BIME, Informatica.
  • Open-Source-Alternativen wie redash.

Checkliste für den sanften Start

Vor dem kommerziellen Start Ihrer Anwendung sollten Sie anhand der Checkliste für den sanften Start testen, ob alles für die Einführung bereit ist.

Aktivität
❑  
Wenn Sie zum Laden von Daten eine Streaming-API verwenden, simulieren Sie einen Ladetest, um sicherzustellen, dass die Daten ohne Kontingentverletzung geladen werden.
❑  
Wenn Sie zum Laden von Daten Batch-Jobs verwenden, simulieren Sie einen Ladetest, um sicherzustellen, dass die Daten innerhalb einer angemessenen Zeit und ohne Kontingentverletzung in BigQuery geladen werden.
❑  
Überprüfen Sie Ihr Kostenmodell anhand der tatsächlichen Kosten. Bestätigen Sie, dass sich die operativen Kosten innerhalb des Budgets bewegen. Passen Sie Ihr Kostenmodell an. Der Google Cloud Platform-Preisrechner liefert zwar brauchbare Schätzungen, aber erst beim Ladetest stellt sich heraus, wie viele Daten während eines Tages tatsächlich verarbeitet werden.

Checkliste für den endgültigen Start

Arbeiten Sie die Checkliste für den endgültigen Start kurz vor dem Start bzw. während des Starts ab.

Aktivität
❑  
Wenn Sie die Checkliste bis zu diesem Punkt abgearbeitet haben, ist Ihnen ein erfolgreicher Start Ihrer Anwendung in Google BigQuery sicher. Das wars! Wir empfehlen außerdem, unter Start-Checkliste für die Google Cloud Platform die Checkliste für den endgültigen Start durchzugehen.
Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...