Wie Looker SQL generiert

Wenn Sie mit SQL vertraut sind, möchten Sie wahrscheinlich wissen, wie Looker SQL generiert. Im Grunde ist Looker ein Tool, das SQL-Abfragen generiert und an eine Datenbankverbindung sendet. Looker formuliert SQL-Abfragen auf der Grundlage eines LookML-Projekts, das die Beziehung zwischen Tabellen und Spalten in der Datenbank beschreibt. Wenn Sie wissen, wie Looker Abfragen generiert, werden Sie auch besser verstehen, wie Ihr LookML-Code in effiziente SQL-Abfragen umgewandelt wird.

Jeder LookML-Parameter steuert einen Aspekt der SQL-Generierung in Looker, indem er die Struktur, den Inhalt oder das Verhalten der Abfrage ändert. Auf dieser Seite wird beschrieben, wie SQL in Looker generiert wird. Es werden jedoch nicht alle LookML-Elemente im Detail behandelt. Die Dokumentationsseite LookML-Kurzübersicht ist ein guter Ausgangspunkt für Informationen zu LookML-Parametern.

Abfrage ansehen

In einem gespeicherten Look oder einem Explore können Sie im Bereich Daten auf dem Tab SQL sehen, was Looker an die Datenbank sendet, um die Daten abzurufen. Sie können auch die Links In SQL Runner öffnen und In SQL Runner erklären unten auf dem Tab SQL verwenden, um Ihre Abfrage in SQL Runner anzuzeigen oder den Erläuterungsplan der Datenbank für die Abfrage anzuzeigen.

Weitere Informationen zu SQL Runner finden Sie auf der Dokumentationsseite SQL Runner-Grundlagen. Weitere Informationen zum Optimieren einer Abfrage mit SQL Runner finden Sie im Communitybeitrag How to Optimize SQL with EXPLAIN.

Kanonische Form einer Looker-Abfrage

Die SQL-Abfragen von Looker haben immer die folgende Form.

SELECT
   <dimension>, <dimension>, ...
   <measure>, <measure>, ...
FROM <explore>
LEFT JOIN <view> ON ...
LEFT JOIN <view> ON ...
WHERE (<dimension_filter_expression>) AND (<dimension_filter_expression>) AND ...
GROUP BY <dimension>, <dimension>, <dimension>, ...
HAVING <measure_filter_expression> AND <measure_filter_expression> AND ...
ORDER BY <dimension> | <measure>
LIMIT <limit>

Im LookML-Projekt werden alle Dimensionen, Messwerte, Explores und Ansichten definiert, auf die in der SQL-Abfrage verwiesen wird. Filterausdrücke werden in Looker vom Benutzer angegeben, um Ad-hoc-Abfragen zu gestalten. Filterausdrücke können auch direkt in LookML deklariert und auf alle Abfragen angewendet werden.

Grundlegende Komponenten einer Looker-Abfrage

Alle Looker-Abfragen werden durch diese grundlegenden Parameter dargestellt, die auf ein LookML-Projekt angewendet werden, wie in der vorherigen Beispielabfrage dargestellt.

Looker verwendet die folgenden Parameter, um eine vollständige SQL-Abfrage zu generieren:

  • model: der Name des zu verwendenden LookML-Modells, der die Zieldatenbank angibt
  • explore: Der Name des zu abfragenden explorativen Datenanalysetools, der die SQL-Klausel FROM ausfüllt
  • Felder: die Parameter dimension und measure, die in die Abfrage aufgenommen werden sollen und mit denen die SQL-SELECT-Klausel ausgefüllt wird
  • filter: Looker-Filterausdrücke, die auf null oder mehrere Felder angewendet werden, die die SQL-Klauseln WHERE und HAVING füllen
  • Sortierreihenfolge: das Feld, nach dem sortiert werden soll, und die Sortierreihenfolge, die die SQL-ORDER BY-Klausel füllt

Diese Parameter sind genau die Elemente, die ein Nutzer beim Erstellen einer Abfrage auf der Looker-Seite Explore angibt. Dieselben Elemente werden in allen Modi zum Ausführen von Abfragen mit Looker angezeigt, z. B. im generierten SQL, in der URL, die die Abfrage darstellt, und in der Looker-API.

Was ist mit den Ansichten, die durch die LEFT JOIN-Klauseln angegeben werden? JOIN-Klauseln werden basierend auf der Struktur des LookML-Modells ausgefüllt, in dem festgelegt ist, wie Ansichten mit Explores zusammengeführt werden. Beim Erstellen von SQL-Abfragen werden in Looker JOIN-Klauseln nur bei Bedarf eingefügt. Wenn Nutzer in Looker eine Abfrage erstellen, müssen sie nicht angeben, wie Tabellen zusammengeführt werden, da diese Informationen im Modell codiert sind. Dies ist einer der größten Vorteile von Looker für Geschäftsnutzer.

Eine Beispielabfrage und das resultierende SQL

Lassen Sie uns eine Abfrage in Looker erstellen, um zu zeigen, wie die Abfrage nach dem vorherigen Muster generiert wird. Angenommen, Sie haben einen E-Commerce-Shop mit einer Datenbank mit zwei Tabellen, orders und users, um Nutzer und Bestellungen zu verfolgen.

orders
id INT
created_at DATETIME
users_id INT
status VARCHAR(255)
traffic_source VARCHAR(15)
users
id INT
email VARCHAR(255)
first_name VARCHAR(255)
last_name VARCHAR(255)
created_at DATETIME
zip INT
country VARCHAR(255)
state VARCHAR(255)
city VARCHAR(255)
age INT
traffic_source VARCHAR(15)

Lassen Sie uns die Anzahl der Aufträge (ORDERS-Anzahl) in einem Looker-Explore nach Bundesstaat (NUTZER Bundesstaat) gruppiert und nach dem Erstellungsdatum des Auftrags (ORDERS Created Date) gefiltert finden.

In einer Datentabelle für explorative Datenanalysen wird die Anzahl der Bestellungen nach Nutzerstatus für Bestellungen angezeigt, die in den letzten 30 Tagen aufgegeben wurden.

Wenn Sie die SQL-Abfrage sehen möchten, die von Looker generiert und ausgeführt wird, klicken Sie im Bereich Daten auf den Tab SQL.

SELECT COALESCE(users.state, ' ') AS "_g1",
   users.state AS 'users.state',
   COUNT(DISTINCT orders.id) AS 'orders.count'
FROM orders
LEFT JOIN users ON orders.user_id = users.id

WHERE
  orders.created_at BETWEEN (CONVERT_TZ(DATE_ADD(CURDATE(), INTERVAL -29 day), 'America/Los_Angeles', 'UTC',)) AND (CONVERT_TZ(DATE_ADD(DATE_ADD(DATE_ADD(CURDATE(), INTERVAL -29 day), INTERVAL 30 day), INTERVAL -1 second), 'America/Los_Angeles', 'UTC'))
GROUP BY 1
ORDER BY COUNT(DISTINCT orders.id) DESC
LIMIT 500

Beachten Sie die Ähnlichkeit mit der Formel für kanonische Suchanfragen. Der Looker SQL-Code weist einige Merkmale von maschinengeneriertem Code auf (z. B. COALESCE(users.state,'') AS "_g1"), entspricht aber immer der Formel.

Experimentieren Sie mit mehr Abfragen in Looker, um sich selbst zu beweisen, dass die Abfragestruktur immer gleich ist.

Raw-SQL im SQL-Runner von Looker ausführen

Looker bietet die Funktion SQL Runner, mit der Sie beliebige SQL-Abfragen auf die in Looker eingerichteten Datenbankverbindungen ausführen können.

Da jede von Looker generierte Abfrage zu einem vollständigen, funktionsfähigen SQL-Befehl führt, können Sie die Abfrage mit SQL Runner untersuchen oder damit experimentieren.

Für die Ausführung in SQL Runner generierte SQL-Abfragen liefern dasselbe Ergebnis. Wenn der SQL-Code Fehler enthält, hebt SQL Runner die Position des ersten Fehlers im SQL-Befehl hervor und gibt die Position des Fehlers in der Fehlermeldung an.

Suchanfragenkomponenten in der erweiterten URL untersuchen

Nachdem Sie eine Abfrage in Looker ausgeführt haben, können Sie die erweiterte URL prüfen, um die grundlegenden Komponenten einer Looker-Abfrage zu sehen. Wählen Sie zuerst im Zahnradmenü des Explores die Option Freigeben aus, um das Menü URLs teilen zu öffnen.

Die erweiterte URL enthält genügend Informationen, um die Suchanfrage neu zu erstellen. Dieses Beispiel für eine erweiterte URL enthält die folgenden Informationen:

https://<Looker instance URL>.cloud.looker.com/explore/e_thelook/events?fields=users.state,users.count
&f[users.created_year]=2020&sorts=users.count+desc&limit=500
Modell e_thelook
analysieren events
Felder, die abgefragt und angezeigt werden sollen fields=users.state,users.count
Feld und Reihenfolge sortieren sorts=users.count+desc
Filterfelder und -werte f[users.created_year]=2020

So werden JOINs in Looker strukturiert

In der vorherigen Beispielabfrage sehen Sie, dass das Explore orders im FROM-Hauptteil und die verknüpften Ansichten in den LEFT JOIN-Klauseln angezeigt werden. Looker-Joins können auf viele verschiedene Arten geschrieben werden. Dies wird auf der Seite Mit Joins in LookML arbeiten ausführlicher erläutert.

SQL-Blöcke geben benutzerdefinierte SQL-Klauseln an

Nicht alle Elemente einer Looker-Abfrage sind maschinengeneriert. Irgendwann muss das Datenmodell bestimmte Details für Looker bereitstellen, damit es auf die zugrunde liegenden Tabellen zugreifen und abgeleitete Werte berechnen kann. In LookML sind SQL-Blöcke SQL-Code-Snippets, die vom Datenmodellierer bereitgestellt werden und mit denen in Looker vollständige SQL-Ausdrücke erstellt werden.

Der gängigste SQL-Blockparameter ist sql. Er wird in Dimensions- und Messwertdefinitionen verwendet. Mit dem Parameter sql wird eine SQL-Klausel angegeben, um auf eine zugrunde liegende Spalte zu verweisen oder eine Aggregatfunktion auszuführen. Im Allgemeinen erwarten alle LookML-Parameter, die mit sql_ beginnen, irgendeine Art von SQL-Ausdruck. Beispiele: sql_always_where, sql_on und sql_table_name. Weitere Informationen zu den einzelnen Parametern finden Sie in der LookML-Referenz.

Beispiele für SQL-Blöcke für Dimensionen und Messwerte

Das folgende Codebeispiel enthält einige Beispiele für SQL-Blöcke für Dimensionen und Messwerte. Der LookML-Substitutionsoperator ($) kann bewirken, dass diese sql-Deklarationen fälschlicherweise nicht wie SQL wirken. Doch nach einer Substitution ist die daraus resultierende Zeichenfolge reines SQL, das Looker in die SELECT-Klausel der Abfrage einfügt.

dimension: id {
  primary_key: yes
  sql: ${TABLE}.id ;;  # Specify the primary key, id
}
measure: average_cost {
  type: average
  value_format: "0.00"
  sql: ${cost} ;;      # Specify the field that you want to average
                       # The field 'cost' is declared elsewhere
}
dimension: name {
  sql: CONCAT(${first_name}, ' ', ${last_name}) ;;
}
dimension: days_in_inventory {
  type: number
  sql: DATEDIFF(${sold_date}, ${created_date}) ;;
}

Wie in den letzten beiden Dimensionen in diesem Beispiel gezeigt, können SQL-Blöcke Funktionen verwenden, die von der zugrunde liegenden Datenbank unterstützt werden (wie die MySQL-Funktionen CONCAT und DATEDIFF in diesem Fall). Der in SQL-Blöcken verwendete Code muss mit dem von der Datenbank verwendeten SQL-Dialekt übereinstimmen.

Beispiel für einen SQL-Block für abgeleitete Tabellen

Abgeleitete Tabellen verwenden ebenfalls einen SQL-Block, um die Abfrage zur Ableitung der Tabelle anzugeben. Hier ein Beispiel für eine SQL-basierte abgeleitete Tabelle:

view: user_order_facts {
  derived_table: {
    sql:
      SELECT
        user_id
        , COUNT(*) as lifetime_orders
      FROM orders
      GROUP BY 1 ;;
  }

  # later, dimension declarations reference the derived column(s)…
  dimension: lifetime_orders {
    type: number
  }
}

Beispiel für einen SQL-Block zum Filtern eines Explores

Mit den LookML-Parametern sql_always_where und sql_always_having können Sie die für eine Abfrage verfügbaren Daten einschränken, indem Sie einen SQL-Block in die WHERE- oder HAVING-Klauseln von SQL einfügen. In diesem Beispiel wird der LookML-Substitutionsoperator ${view_name.SQL_TABLE_NAME} verwendet, um auf eine abgeleitete Tabelle zu verweisen:

explore: trips {
  view_label: "Long Trips"
  # This will ensure that we only see trips that are longer than average!
  sql_always_where: ${trips.trip_duration}>=(SELECT tripduration FROM ${average_trip_duration.SQL_TABLE_NAME});;
}