4 Die Leistung des Objektspeichers für eine Query Engine bestimmt, wie schnell Analysten Antworten erhalten. Moderne verteilte SQL-Query-Engines lesen Daten direkt aus dem Objektspeicher in offenen Dateiformaten wie Parquet und ORC, meist organisiert durch ein offenes Tabellenformat. Sie haben keinen eigenen Speicher, hinter dem sie sich verstecken könnten – jede Abfrage hängt davon ab, wie schnell der Objektspeicher Daten an Dutzende oder Hunderte Worker gleichzeitig liefern kann. Ein gut abgestimmter Query-Cluster auf langsamem Speicher ist ein langsamer Cluster. Dieser Artikel erklärt, wie verteilte Query Engines aus Objektspeicher lesen, welche Speicherkennzahlen wichtig sind, wie Speicher und Netzwerk für eine Query-Bereitstellung dimensioniert werden und wie Dateilayout und Caching die Leistung beeinflussen. Er gilt für jede Engine, die Rechenleistung und Speicher trennt und über die S3-API liest. Die übergreifende Architektur beschreibt unsere Übersicht zum Betrieb eines Data Lakehouse auf On-Premises-Objektspeicher. Wie eine verteilte Query Engine aus Objektspeicher liest Wenn eine Abfrage läuft, geht eine typische Engine so vor: Sie plant die Abfrage anhand der Tabellenmetadaten aus einem Katalog und der Manifest-Dateien des Tabellenformats. Sie schließt Partitionen und Dateien aus, die keine passenden Zeilen enthalten können, anhand der in den Metadaten gespeicherten Statistiken. Sie teilt die verbleibenden Dateien in Arbeitseinheiten auf und weist sie den Workern zu. Jeder Worker sendet parallel S3-GET-Anfragen, oft Range-Reads bestimmter Spalten-Chunks. Die Ergebnisse werden durch den Cluster zum Koordinator zurückgestreamt. Daraus folgen zwei Dinge. Erstens kann eine einzige Abfrage Tausende kleiner Range-Reads gleichzeitig auslösen, sodass die Verarbeitung von Anfragen ebenso wichtig ist wie die reine Bandbreite. Zweitens erfolgen Metadatenzugriffe (Katalogabfragen, Manifest-Listen, Dateilisten), bevor überhaupt Daten fließen – langsame Metadatenoperationen erhöhen also die Latenz jeder Abfrage. Die entscheidenden Speicherkennzahlen Aggregierter Lesedurchsatz Bei großen Scans liegt die Grenze darin, wie viele Gigabyte pro Sekunde der Objektspeicher allen Workern zusammen liefern kann. Eine nützliche Faustregel: Schätzen Sie den Durchsatz, den jeder Worker bei CPU-gebundener Dekomprimierung und Filterung verarbeiten kann, multiplizieren Sie ihn mit der Zahl der Worker und stellen Sie sicher, dass Speichercluster und Netzwerk diesen Wert mit Reserve liefern können. Anfragen pro Sekunde und Latenz kleiner Lesezugriffe Spaltenorientierte Formate begünstigen Range-Reads von wenigen Megabyte oder weniger. Eine Abfrage über Tausende Dateien kann Zehntausende GET-Anfragen auslösen. Speicher, der große sequenzielle Lesevorgänge gut bewältigt, aber mit hohen Anfrageraten kämpft, bremst Abfragen aus. Fragen Sie nach Leistungswerten bei realistischen Objekt- und Range-Größen, nicht nur bei großen sequenziellen Übertragungen. Time to First Byte Interaktive Dashboards führen viele kurze Abfragen aus. Für sie ist die Zeit zwischen Anfrage und erstem Byte wichtiger als der Spitzendurchsatz. Eine niedrige und gleichmäßige Latenz bis zum ersten Byte hält kurze Abfragen schnell. Listen- und Metadatenoperationen Ältere Tabellenlayouts sind darauf angewiesen, Verzeichnisse zu listen, um Dateien zu finden. Moderne Tabellenformate verringern das, indem sie Dateien in Manifests verfolgen, doch Kataloge und Engines senden weiterhin HEAD- und LIST-Aufrufe. Speicher mit langsamen Listen bei großen Objektzahlen schafft einen versteckten Engpass. Konsistenz Engines erwarten, dass Leser einen abgeschlossenen Schreibvorgang sofort sehen. Starke Read-after-Write-Konsistenz im Objektspeicher vermeidet fehlgeschlagene Abfragen und veraltete Ergebnisse, besonders wenn Datenaufnahme und Abfragen gleichzeitig laufen. Speicher und Netzwerk dimensionieren Gehen Sie vom Workload aus, nicht von der Kapazität: Parallelität: wie viele Abfragen zu Spitzenzeiten gleichzeitig laufen und wie viele Worker jede nutzt. Scan-Volumen: wie viele Daten eine typische schwere Abfrage nach dem Pruning liest. Ziel-Antwortzeit: was Analysten und Dashboards erwarten. Schätzen Sie daraus den benötigten Lesedurchsatz. Prüfen Sie dann drei Stellen, an denen sich die Leitung verengen kann: Speicherknoten: Jeder Knoten liefert einen bestimmten Durchsatz, begrenzt durch Laufwerke, CPU und Netzwerkschnittstellen. Skalieren Sie horizontal, bis die Summe das Ziel übersteigt. Netzwerk-Fabric: Die Verbindungen zwischen Rechen- und Speicherebene, einschließlich Spine- oder Top-of-Rack-Uplinks, müssen die gesamte Summe tragen. Überbuchte Verbindungen sind eine häufige versteckte Obergrenze. Lastverteilung: Anfragen sollten sich gleichmäßig auf die Speicherendpunkte verteilen. Kapazitätsplanung bleibt wichtig, doch bei Analyse-Clustern bestimmt meist die Leistung die Knotenzahl, bevor es die Kapazität tut. Dateilayout: der größte Hebel in Ihrer Hand Speichergeschwindigkeit kann ein schlechtes Dateilayout nicht retten. Das wirksamste Tuning findet meist in der Tabelle statt, nicht in der Hardware. Dateigröße: Sehr kleine Dateien vervielfachen Anfragen und Metadaten-Overhead. Viele Teams streben bei großen Tabellen Dateien von einigen Hundert Megabyte an und führen regelmäßig eine Compaction durch, um kleine Dateien aus Streaming-Ingestion zusammenzuführen. Partitionierung: Partitionieren Sie nach Spalten, nach denen Abfragen filtern, etwa nach Datum, aber vermeiden Sie so feine Partitionen, dass jede nur wenige winzige Dateien enthält. Sortierung und Clustering: Werden Daten innerhalb der Dateien nach häufigen Filterspalten sortiert, werden die Min- und Max-Statistiken selektiver, sodass mehr Dateien und Row Groups übersprungen werden. Größe von Row Groups und Pages: Sinnvolle Standardwerte funktionieren für die meisten Workloads; sehr kleine Row Groups erhöhen die Zahl der Anfragen. Komprimierung: Moderne Codecs tauschen CPU gegen weniger gelesene Daten. Auf schnellem Speicher kann leichtere Komprimierung schneller sein, in begrenzten Netzwerken kann stärkere Komprimierung gewinnen. Offene Tabellenformate helfen, indem sie Statistiken auf Dateiebene verfolgen und Compaction sowie Wartung unterstützen, ohne ganze Tabellen neu zu schreiben. Caching Die meisten Query Engines unterstützen eine Form von Caching, und das verändert die Anforderungen an den Speicher: Metadaten-Caching hält Katalog- und Manifest-Informationen im Arbeitsspeicher und reduziert wiederholte Metadatenzugriffe. Daten-Caching auf lokalen SSDs der Worker hält häufig gelesene Dateisegmente nahe an der Rechenleistung. Häufig genutzte Dashboards lesen womöglich überwiegend aus dem Cache, während Ad-hoc-Abfragen weiterhin auf den Objektspeicher zugreifen. Ergebnis-Caching auf BI- oder Engine-Ebene vermeidet die erneute Ausführung identischer Abfragen. Caching verringert die Last auf dem Objektspeicher, macht hohen Durchsatz aber nicht überflüssig. Kalte Scans, neue Daten und Cache-Misses nach Neustarts treffen den Speicher direkt. On-Premises vs. Objektspeicher in der Public Cloud In der Public Cloud lesen Query-Cluster aus einem gemeinsam genutzten Dienst, dessen Anfragelimits pro Präfix und Netzwerkpfade Sie nicht kontrollieren, und Datentransfers zwischen Regionen oder aus der Cloud heraus verursachen zusätzliche Kosten. On-Premises kontrollieren Sie das Netzwerk zwischen Rechen- und Speicherebene und können es auf den benötigten Durchsatz auslegen – sind aber für die richtige Dimensionierung verantwortlich. Viele Organisationen mit großen, gleichmäßigen Analyse-Workloads wählen On-Premises-Objektspeicher wegen planbarer Kosten und Leistung und halten sensible Daten an einem bekannten Ort. Vor der Festlegung testen Synthetische Benchmarks bilden echte Abfragemuster selten ab. Ein praktischer Testplan: Eine repräsentative Kopie einer echten Tabelle mit realistischen Dateigrößen und realistischer Partitionierung laden. Die tatsächlichen schweren Abfragen und Dashboard-Abfragen bei erwarteter Parallelität ausführen. End-to-End-Abfragezeiten, Speicherdurchsatz, Anfrageraten und Latenzperzentile messen. Mit deaktiviertem Caching wiederholen, um das reine Speicherverhalten zu sehen. Speicherknoten oder Worker hinzufügen und prüfen, ob die Leistung annähernd linear skaliert. Achten Sie auch auf Fehler und Wiederholungen. Drosselungsantworten oder Timeouts unter Last sind frühe Anzeichen dafür, dass Speicher oder Netzwerk der Engpass sind. Häufige Engpässe und wie man sie erkennt Worker warten untätig auf I/O: Speicherdurchsatz oder Anfrageverarbeitung sind die Grenze. Hohe CPU-Last auf den Workern, Speicher wenig ausgelastet: Die Rechenleistung ist die Grenze; fügen Sie Worker hinzu oder verringern Sie den Dekomprimierungsaufwand. Langsame Planung, bevor Daten fließen: Metadaten- oder Katalogoperationen sind langsam, oder Tabellen haben zu viele kleine Dateien. Der Durchsatz stagniert trotz zusätzlicher Knoten: Suchen Sie nach einer überbuchten Netzwerkverbindung oder ungleichmäßiger Lastverteilung. Die Leistung lässt mit der Zeit nach: Kleine Dateien sammeln sich an; planen Sie eine Compaction ein. Checkliste: Objektspeicher für eine verteilte Query Engine Aggregierter Lesedurchsatz, ausgelegt auf Spitzenparallelität mit Reserve. Hohe Anfrageraten und niedrige Latenz für kleine Range-Reads. Schnelle Listen- und HEAD-Operationen bei großen Objektzahlen. Starke Read-after-Write-Konsistenz. Nicht überbuchtes Netzwerk zwischen Rechen- und Speicherebene. Gleichmäßige Lastverteilung über die Speicherendpunkte. Gesunde Dateigrößen, Partitionierung und regelmäßige Compaction. Metadaten- und Daten-Caching auf den Workern konfiguriert. Tests mit echten Abfragen bei realer Parallelität vor dem Produktivbetrieb. Zusammenfassung Eine verteilte Query Engine ist nur so schnell wie der Speicher, aus dem sie liest. Der Speicher muss hohen aggregierten Durchsatz liefern, große Mengen kleiner Anfragen mit niedriger Latenz bewältigen und Metadatenaufrufe schnell beantworten – über ein Netzwerk, das nicht zum Engpass wird. Dateilayout und Caching erledigen den Rest. Stimmen diese Punkte, kann On-Premises-Objektspeicher interaktive Analytik im Petabyte-Bereich liefern. Die vollständige Architektur finden Sie unter Betrieb eines Data Lakehouse auf On-Premises-Objektspeicher, zur Verlagerung vorhandener Daten siehe Migration von HDFS auf Objektspeicher. Häufig gestellte Fragen Welche Speicherleistung braucht eine SQL-Query-Engine? Genug aggregierten Lesedurchsatz für die Spitzenparallelität, hohe Anfrageraten für kleine Range-Reads, niedrige Latenz bis zum ersten Byte und schnelle Metadatenoperationen. Die genauen Werte hängen von der Zahl der Worker und den Abfragemustern ab. Ist für Analyseabfragen Durchsatz oder Latenz wichtiger? Beides. Große Scans hängen vom Durchsatz ab, interaktive Dashboards von Latenz und Anfrageverarbeitung. Die meisten Bereitstellungen brauchen beides. Schaden kleine Dateien der Abfrageleistung auf Objektspeicher? Ja. Kleine Dateien vervielfachen Anfragen und Metadaten-Overhead. Regelmäßige Compaction zu größeren Dateien ist eine der wirksamsten Optimierungen. Macht Caching schnellen Objektspeicher überflüssig? Nein. Caching hilft bei wiederholten Abfragen, doch kalte Scans, neue Daten und Cache-Misses lesen weiterhin aus dem Objektspeicher. Kann On-Premises-Objektspeicher bei Analytik mit der Public Cloud mithalten? Ja, wenn Speicherknoten und Netzwerk auf den Workload ausgelegt sind. On-Premises bietet zudem planbare Kosten und Kontrolle über den Speicherort der Daten.
