Data-Warehouse-Schemata folgen in der Regel einem Stern- oder Schneeflockenschema, bei dem eine zentrale “Faktentabelle”, die Ereignisse enthält, von Satellitentabellen, den “Dimensionen”, umgeben ist, die beschreibende Attribute in Bezug auf die Faktentabelle enthalten. Die Faktentabellen sind denormalisiert, die Dimensionstabellen normalisiert. Das Sternschema unterstützt analytische Abfragen in einem Data Warehouse und ermöglicht einfachere Abfragen, da die Anzahl der Verknüpfungen begrenzt ist, schnellere Aggregationen und eine bessere Abfrageleistung.
Dies steht im Gegensatz zu einem Online-Transaktionsverarbeitungssystem (OLTP), bei dem das Schema stark normalisiert ist und viele Verknüpfungen durchgeführt werden, um die Ergebnisse zu erhalten. Die meisten analytischen Abfragen in einem Data Warehouse erfordern immer noch eine JOIN-Operation, um Faktdaten mit Dimensionsattributen oder mit einer anderen Faktentabelle zu kombinieren.
Schauen wir uns an, wie Joins in BigQuery funktionieren. BigQuery unterstützt ANSI-SQL-Join-Typen. JOIN-Operationen werden an zwei Elementen auf der Grundlage von Join-Bedingungen und Join-Typ durchgeführt. Elemente in der JOIN-Operation können BigQuery-Tabellen, Unterabfragen, WITH-Anweisungen oder ARRAYs (eine geordnete Liste mit null oder mehr Werten desselben Datentyps) sein.
BigQuery unterstützt die folgenden Verknüpfungstypen:
Optimierung von Join-Mustern
Broadcast-Joins
Wenn eine große Tabelle mit einer kleinen Tabelle verbunden wird, erstellt BigQuery einen Broadcast-Join, bei dem die kleine Tabelle an jeden Slot gesendet wird, der die große Tabelle verarbeitet.
Auch wenn der SQL-Abfrageoptimierer bestimmen kann, welche Tabelle auf welcher Seite der Verknüpfung stehen soll, wird empfohlen, die verknüpften Tabellen in der richtigen Reihenfolge anzuordnen. Am besten ist es, die größte Tabelle an die erste Stelle zu setzen, gefolgt von der kleinsten und dann in abnehmender Größe.
Hash-Joins
Bei der Verknüpfung zweier großer Tabellen verwendet BigQuery Hash- und Shuffle-Operationen, um die linke und die rechte Tabelle so zu mischen, dass die übereinstimmenden Schlüssel im selben Slot landen, um eine lokale Verknüpfung durchzuführen. Dies ist ein teurer Vorgang, da die Daten verschoben werden müssen.
In einigen Fällen kann das Clustering Hash-Joins beschleunigen.
Self-Joins
Bei einem Self-Join wird eine Tabelle mit sich selbst verbunden. Dies ist typischerweise ein SQL-Anti-Muster, das bei großen Tabellen eine teure Operation sein kann und möglicherweise erfordert, dass Daten in mehr als einem Durchgang abgerufen werden.
Es wird empfohlen, Self-Joins zu vermeiden und stattdessen analytische (Fenster-)Funktionen zu verwenden, um die von der Abfrage erzeugten Bytes zu reduzieren.
Cross-Joins
Cross-Joins sind ein SQL-Anti-Pattern und können zu erheblichen Leistungsproblemen führen, da sie größere Ausgabedaten als Eingaben erzeugen und in manchen Fällen Abfragen nie abgeschlossen werden können.
Um Leistungsprobleme mit Cross-Joins zu vermeiden, verwenden Sie Aggregatfunktionen, um die Daten vorab zu aggregieren, oder verwenden Sie analytische Funktionen, die in der Regel leistungsfähiger sind als ein Cross-Join.
Skewed Joins
Datenschieflage kann auftreten, wenn die Daten in der Tabelle in ungleich große Partitionen unterteilt sind. Bei der Verknüpfung großer Tabellen, die ein Shuffling der Daten erfordern, kann die Schräglage zu einem extremen Ungleichgewicht der zwischen den Slots gesendeten Datenmenge führen. Um Leistungsprobleme im Zusammenhang mit schiefen Joins (oder unausgewogenen Joins) zu vermeiden, filtern Sie die Daten aus der Tabelle so früh wie möglich vor oder teilen Sie die Abfrage in zwei oder mehr Abfragen auf, falls möglich.