Die Self-Service-Daten-Roadmap

Kapitel 15. Abfrageoptimierungsdienst

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

Jetzt sind wir bereit, die Erkenntnisse in der Produktion zu nutzen. Die Datennutzer haben die Geschäftslogik geschrieben, um Erkenntnisse in Form von Dashboards, ML-Modellen usw. zu generieren. Die Datenumwandlungslogik wird entweder in Form von SQL-Abfragen oder Big-Data-Programmiermodellen (wie Apache Spark, Beam usw.) geschrieben, die in Python, Java, Scala usw. implementiert sind. In diesem Kapitel geht es um die Optimierung der Abfragen und Big-Data-Programme.

Der Unterschied zwischen guten und schlechten Abfragen ist beträchtlich. In der Praxis ist es zum Beispiel nicht ungewöhnlich, dass eine Produktionsabfrage über 4 Stunden läuft, während sie nach der Optimierung in weniger als 10 Minuten ausgeführt werden könnte. Langlaufende Abfragen, die wiederholt ausgeführt werden, sind Kandidaten für ein Tuning.

Datennutzer sind keine Ingenieure, was zu mehreren Problemen bei der Abfrageoptimierung führt. Erstens haben Query Engines wie Hadoop, Spark und Presto eine Fülle von Reglern. Für die meisten Datennutzer ist es nicht einfach zu verstehen, welche Regler eingestellt werden müssen und welche Auswirkungen sie haben. Es gibt keine Patentrezepte - die optimalen Reglerwerte für eine Abfrage variieren je nach Datenmodell, Abfragetyp, Clustergröße, gleichzeitiger Abfragelast und so weiter. In Anbetracht des Umfangs ...