Wie unterscheiden sich Partitionierung und Clustering in einem Cloud-Warehouse, und wie wählst du sie aus?

Partitionierung teilt eine Tabelle in physisch getrennte Stücke, meist nach Datum, sodass eine gefilterte Query ganze Partitionen wegschneidet und weniger scannt. Clustering sortiert die Daten im Storage nach ausgewählten Spalten, damit die Engine Blöcke auf diesen Prädikaten überspringen kann. Partitionier auf der Spalte, die in fast jeder WHERE-Klausel steht, typischerweise das Event-Datum; clustere auf den Spalten mit hoher Kardinalität, nach denen als Nächstes gefiltert oder gejoint wird.

Partitionierung ist grob und physisch: nach Tag aufteilen, und eine auf letzte Woche gefilterte Query liest sieben Partitionen statt der ganzen Tabelle. Clustering ist feingranulare Sortierung innerhalb der Daten, sodass die Engine Blöcke anhand der Min- und Max-Werte überspringen kann, die sie pro Block speichert. Meine Regel: partitionieren auf dem, was in fast jeder Query steht, also fast immer ein Event- oder Ingestion-Datum, dann clustern auf den nächsten ein oder zwei Prädikaten, etwa Customer-ID oder Land. Der Fehler, den ich mehr als einmal aufgeräumt habe, ist Überpartitionierung. Jemand hat nach Customer-ID partitioniert, landete bei vierzigtausend Partitionen von wenigen Kilobyte, und allein die Query-Planung wurde langsamer als der Scan, den sie vermeiden sollte. Die andere Gewohnheit, die ich behalte: prüfen statt vertrauen. In BigQuery schaue ich mit einem Dry Run auf die verarbeiteten Bytes vorher und nachher, denn wenn die Schätzung nicht sinkt, greift das Pruning nicht, meist weil der Filter die Partitionsspalte in eine Funktion packt.