Aufbau eines hoch skalierbaren Kostenoptimierungsdienstes

Industrie

Technologie

Analytische Plattform Finanzen Genomforschung GPU Große Daten Hohe Leistung IoT SQream DB Telekommunikation Werbetechnik

Einführung

NashTech unterstützte SQream bei der Entwicklung eines hochsicheren, leistungsfähigen und erweiterbaren Compiler-Frontend-Dienstes, der alle Abfragen erfolgreich optimierte und die Kosten für die Ausführung einer Abfrage um 60 % reduzierte.

SQream bietet eine Analyseplattform zur Minimierung der Total Time to Insight (TTTI) für zeitkritische Daten, sowohl vor Ort als auch in der Cloud. Die GPU-gestützte Plattform wurde für Daten im Tera- bis Petascale-Bereich entwickelt und ermöglicht es Unternehmen, ihre wachsenden Daten schnell zu erfassen und zu analysieren – und so einen umfassenden Einblick in die Kundenerfahrung, die betriebliche Effizienz und bisher unerreichte Geschäftseinblicke zu erhalten.

Auswirkungen

Entwicklung eines kostenbasierten Optimierers für die bestehende Datenbank-Engine und Integration mit einem branchenüblichen SQL-Parser.
Senken Sie die Kosten für die Ausführung einer Abfrage um 60 %, indem Sie den besten Plan auf der Grundlage der SQream-Darstellung der Daten auswählen.

Herausforderungen

SQreamDB ist eine verteilte Datenbank und es ist recht komplex, die Kosten der Abfrageausführung zu modellieren.
Bedarf an einem branchenüblichen SQL-Parser/Validator, der erweitert werden kann, um mit der Konkurrenz Schritt zu halten.
Die Backend-Engine muss Abfragen über große Datenmengen effizient ausführen.
Eine bestimmte komplexe SQL kann viele Abfragepläne generieren, so dass die Kostenberechnung jedes einzelnen Abfrageplans teuer ist, daher sollte ein Gleichgewicht zwischen den Abfragekosten und den Kosten für die Auswahl des besten Plans bestehen.

Näherung

SQream DB verfügt über einen regelbasierten Abfrageoptimierer, aber es ist unmöglich, die Abfrage korrekt zu optimieren, ohne die Daten, die Schiefe der Daten, die Arbeitslasten und die Vielfalt der Daten zu berücksichtigen. Der regelbasierte Optimierer wendet verschiedene Regeln an, um die Abfrage zu optimieren. Um alle Pläne abzudecken, werden also mehr Regeln benötigt, was zu vielen komplexen Regeln führt, und wir müssen Hinweise hinzufügen, damit diese Regeln funktionieren. Dennoch kann die erforderliche Abfrageeffizienz bei komplexen Abfragen nicht erreicht werden. Die Idee der kostenbasierten Optimierung sieht also lukrativ aus, ist aber in verteilten Datenbanken ein schwer zu lösendes Problem. Da der Bedarf dringend war, haben wir uns für Calcite entschieden, das über zahlreiche integrierte Regeln verfügt, sowie für einen kostenbasierten Planer namens Volcano. Wir wollten möglichst viele Funktionen von Volcano nutzen, um einen kostenbasierten Optimierer für SQream DB entwickeln zu können. Calcite bietet Ihnen ein Framework, mit dem Sie Ihre eigenen Regeln erstellen können. Das Framework ist in hohem Maße anpassbar, um alle unsere Anforderungen zu erfüllen.

Lösung

Die wichtigsten Ziele für uns waren:

Integration von Apache Calcite als Frontend zur Optimierung von Abfrageausführungsplänen.
Passen Sie Apache Calcite an, um die Abfragepläne zu erstellen, die SQream unter Berücksichtigung der zugrunde liegenden Speicherstruktur verstehen kann.
Ein sich weiterentwickelnder Parser, der problemlos neue SQL-Typen, Anweisungen und Operatoren unterstützen kann.
Benutzerdefinierte Optimierungsregeln auf der Grundlage von Geschäftslogik, z. B. Merge-Sortierung bei verteilten sortierten Daten.

Um diese Ziele zu erreichen, wurde die folgende High-Level-Architektur vorgeschlagen, um einen hochgradig skalierbaren Kostenoptimierungsdienst aufzubauen, wie im folgenden Diagramm beschrieben. Um diese Ziele zu erreichen, wurde die folgende High-Level-Architektur vorgeschlagen, um einen hochgradig skalierbaren Kostenoptimierungsdienst aufzubauen, wie im folgenden Diagramm beschrieben.

01 Parsing

Der gesamte Prozess beginnt mit dem Parsing. Um von der Datenbankmaschine verstanden zu werden, muss eine Abfrage zunächst mit einem SQL-Parser geparst werden, der aus einer Zeichenkette die syntaktische Struktur in Form eines Parse-Baums abzuleiten versucht. Sie verwendet eine Reihe von Syntaxregeln, die so genannte Sprachgrammatik, die festlegt, wie eine SQL-Abfrage aussehen muss, damit sie als gültig und für die Abfragemaschine akzeptabel angesehen wird.

Eine Regel für das Parsen von SQL SELECT-Anweisungen könnte zum Beispiel so aussehen:
wählen:

<SELECT> ausdruckListe
[<FROM> table]
[<WHERE> condition]
[<GROUP> <BY> groupingList]
[<HAVING> condition]

Sie besagt, dass eine SELECT-Anweisung mit dem Schlüsselwort SELECT beginnen muss, gefolgt von einer Liste von Feldern und/oder Ausdrücken, die ausgewählt werden sollen (es kann auch nur einer sein), und optional einer oder allen der folgenden: eine FROM-Klausel, die die Datenquelle angibt, aus der ausgewählt werden soll (d. h. eine Tabelle oder eine Unterabfrage); eine WHERE-Klausel, die ausgewählte Zeilen auf der Grundlage einer booleschen Bedingung filtert; eine GROUP BY-Klausel, die Zeilen auf der Grundlage einiger Schlüssel zusammenfasst; und eine HAVING-Klausel, die einige Gruppen herausfiltert, wenn eine Bedingung nicht erfüllt ist.

02 Validierung

Zweck der Validierung ist es, die semantische Korrektheit der Abfrage zu prüfen, d.h. ob eine von einem Benutzer geschriebene Abfrage sinnvoll ist oder nicht. Die Validierung stellt sicher, dass jedes in der Abfrage genannte Objekt existiert und jede angegebene Operation ausgeführt werden kann. Ist dies nicht der Fall, wird der Vorgang mit einer erklärenden Fehlermeldung abgebrochen.

Ein weiterer wichtiger Zweck der Validierung besteht darin, korrekt zu erkennen, auf welches Objekt (Feld, Tabelle, Funktion) sich ein in der Abfrage genannter Bezeichner tatsächlich bezieht, und jedem Feld, jeder Zeile oder jedem Ausdruck, der darin vorkommt, den richtigen Datentyp zuzuweisen.

Wie wir also die Validierungen durchführen:

Für Validierungen erstellen wir unser Schema mit Hilfe der AbstractSchema-Klasse und erweitern die AbstractSchema-Klasse von Apache Calcite, um unser Schema zu definieren. Und validieren Sie die Abfrage
Sobald die Validierung bestanden ist, erhalten wir SqlNode (SqlNode ist ein SQL-Parse-Baum. Es kann ein Operator, ein Literal, ein Bezeichner usw. sein.
Sobald wir den SqlNode erhalten haben, ist der nächste Schritt, unsere Abfrage als Baumstruktur zu generieren, da wir wissen, dass jede Abfrage als Baum dargestellt wird

03 Regionale Algebra

Die relationale Algebra befasst sich mit abstrakten Transformationen über Datenmengen, wie z. B..

Umwandlung in einen relationalen Baum:

AST (Abstract Syntax Tree) ist für die Optimierung von Abfragen nicht geeignet, da die Semantik seiner Knoten zu kompliziert ist. Es ist viel bequemer, die Abfrageoptimierung an einem Baum von relationalen Operatoren durchzuführen, die durch die RelNode-Unterklassen definiert sind, wie Scan, Project, Filter, Join usw. Wir verwenden SqlToRelConverter, eine weitere monströse Klasse von Apache Calcite, um den ursprünglichen AST in einen relationalen Baum zu konvertieren.

04 Optimierung von Abfragen

Die Abfrageoptimierung ist ein Prozess, bei dem die ursprüngliche Abfrage gemäß einer Reihe von Regeln in eine andere, gleichwertige Abfrage umgewandelt wird, die schneller ausgeführt werden kann und/oder weniger Rechenressourcen für ihre Ausführung benötigt.

Die Optimierung ist ein Prozess der Umwandlung eines Beziehungsbaums in einen anderen Beziehungsbaum. Sie können die regelbasierte Optimierung mit heuristischen oder kostenbasierten Planern, HepPlanner bzw. VolcanoPlanner, durchführen. Sie können den Baum auch manuell umschreiben, ohne eine Regel aufzustellen. Apache Calcite verfügt über mehrere leistungsstarke Rewriting-Werkzeuge, wie RelDecorrelator und RelFieldTrimme.

Ergebnisse

Verbesserung der DB-Leistung um mindestens 30 % für alle Abfragen durch die Bereitstellung stark optimierter Ausführungspläne. Bei komplexen Abfragen betrug die Optimierung mehr als 300 %, da CBO alle redundanten und sich wiederholenden Operationen aus der SQL-Datei entfernte.
Reduzierung der gesamten Erstellungs- und Bereitstellungszeit um mehr als 50 % durch die Trennung dieser Bereiche von der DB-Engine
Ermöglichte die Integration in das Scala-Ökosystem durch das Schreiben von Sbt-Tasks und Plugins. Dadurch konnten sie Tools und Frameworks nutzen, um eine hohe Gleichzeitigkeit und Fehlertoleranz zu erreichen.

Das Ergebnis war ein hochsicherer, leistungsfähiger und erweiterbarer Compiler-Frontend-Dienst, der alle Abfragen erfolgreich optimierte und den entsprechenden physischen Baum generierte.

“Ich möchte mich bei NashTech für ihren großartigen Beitrag zum Aufbau des CBO für SQream bedanken, der es uns ermöglicht hat, Calcit erfolgreich in unser System zu integrieren.”

Gill Cohen – SQream-Projektleiter