SQL-Schnittstelle öffnen

Mit der semantischen Modellierungsebene LookML von Looker können Datenanalysten Dimensionen, Summen, Berechnungen und Datenbeziehungen in einer SQL-Datenbank definieren. LookML-Modelle bieten Codewiederverwendbarkeit und Git-Integration. Mit einem gut strukturierten LookML-Modell können Nutzer ihre eigenen explorativen Datenanalysen und Berichte erstellen.

Das LookML-Modell ist die Grundlage aller Daten, die von Looker angefordert werden, unabhängig davon, ob die Anfrage über die Looker-Explore-Oberfläche in der Looker-Benutzeroberfläche, eine eingebettete Visualisierung in Ihrem Unternehmensportal oder einer anderen Drittanbieteranwendung oder eine benutzerdefinierte Anwendung erfolgt, die mit der Looker API entwickelt wurde. Die Open SQL-Schnittstelle bietet allen Drittanbieteranwendungen, die Java Database Connectivity (JDBC) unterstützen, Zugriff auf die LookML-Modelle. Anwendungen können eine Verbindung zu einem LookML-Modell herstellen, als wäre es eine Datenbank. So können Nutzer die Arbeit ihrer Datenanalysten im LookML-Modell nutzen und dabei die Tools verwenden, mit denen sie am besten vertraut sind.

So werden LookML-Projektelemente über die Open SQL-Schnittstelle angezeigt

Um zu verstehen, wie die Open SQL-Schnittstelle die Elemente eines LookML-Projekts darstellt, ist es wichtig zu wissen, wie LookML-Projekte strukturiert sind.

Ein LookML-Projekt ist eine Sammlung von Dateien, die die Objekte, Datenbankverbindungen und Benutzeroberflächenelemente beschreiben, die zum Ausführen von SQL-Abfragen in Looker verwendet werden. Weitere Informationen finden Sie unter LookML-Begriffe und ‑Konzepte. Die folgenden LookML-Projektkonzepte beziehen sich auf die Open SQL-Schnittstelle:

  • In einem LookML-Modell werden eine Datenbankverbindung und ein oder mehrere Explores angegeben. Die Open SQL-Schnittstelle stellt Modelle als Datenbankschemata dar.
  • Ein Explore ist eine logische Gruppierung einer oder mehrerer Ansichten und der Join-Beziehungen zwischen diesen Ansichten. Die Open SQL-Schnittstelle stellt Explores als Datenbanktabellen dar.
  • Eine Ansicht definiert eine Sammlung von Feldern (Dimensionen und Messwerte). Eine Ansicht basiert in der Regel auf einer Tabelle in Ihrer Datenbank oder einer abgeleiteten Tabelle. Ansichten können die Spalten aus der zugrunde liegenden Datenbanktabelle sowie alle benutzerdefinierten Dimensionen oder Messwerte enthalten, die Ihre Endnutzer benötigen. Die Open SQL-Schnittstelle gibt die Kombination aus einem Ansichtsnamen und einem Feldnamen als Datenbankspaltennamen aus. Die Dimension id in der Ansicht order_items wird beispielsweise von der Open SQL-Schnittstelle als Datenbankspalte namens order_items.id angezeigt.

In einem Looker-Explore können Join-Beziehungen zwischen mehreren Datenansichten definiert werden. Da eine Ansicht ein Feld mit demselben Namen wie ein Feld in einer anderen Ansicht haben kann, enthält die Open SQL-Schnittstelle sowohl den Namen der Ansicht als auch den Namen des Felds, wenn auf eine Spalte verwiesen wird. Verwenden Sie daher dieses Format, um bei Abfragen an die Open SQL-Schnittstelle auf einen Spaltennamen zu verweisen:

`<view_name>.<field_name>`

Angenommen, es gibt ein Explore namens order_items, das eine Ansicht namens customer mit einer Ansicht namens product zusammenführt. Beide Ansichten haben die Dimension id. In diesem Fall würden Sie die beiden id-Felder jeweils als `customer.id` und `product.id` bezeichnen. Wenn Sie den voll qualifizierten Namen auch mit dem Explore-Namen verwenden möchten, müssen Sie die beiden Felder `order_items`.`customer.id` und `order_items`.`product.id` nennen. Weitere Informationen dazu, wo Sie die Graviszeichen bei der Bezugnahme auf Datenbank-IDs verwenden, finden Sie unter Graviszeichen um Datenbank-IDs herum verwenden.

Open SQL-Schnittstelle einrichten

So verwenden Sie die Open SQL-Schnittstelle:

  1. Prüfen Sie, ob die Anforderungen erfüllt sind.
  2. Laden Sie die JDBC-Treiberdatei der Open SQL Interface herunter.

Diese Schritte werden in den folgenden Abschnitten beschrieben.

Voraussetzungen

Für die Verwendung der Open SQL-Schnittstelle sind die folgenden Komponenten erforderlich:

JDBC-Treiber für Open SQL Interface herunterladen

Der JDBC-Treiber für die Looker Open SQL Interface heißt avatica-<release_number>-looker.jar. Laden Sie die neueste Version von GitHub unter https://github.com/looker-open-source/calcite-avatica/releases herunter.

Der JDBC-Treiber erwartet das folgende URL-Format:

jdbc:looker:url=https://Looker instance URL

Beispiel:

jdbc:looker:url=https://myInstance.cloud.looker.com

Die JDBC-Treiberklasse ist:

org.apache.calcite.avatica.remote.looker.LookerDriver

Bei der Open SQL-Schnittstelle authentifizieren

Die Open SQL-Schnittstelle unterstützt drei Authentifizierungsmethoden:

OAuth

JDBC-Clients, die OAuth unterstützen, können so konfiguriert werden, dass sie den OAuth-Server einer Looker-Instanz verwenden. So konfigurieren Sie die OAuth-Authentifizierung:

  1. Verwenden Sie die API Explorer-Erweiterung, um den JDBC-OAuth-Client bei Ihrer Looker-Instanz zu registrieren, damit die Looker-Instanz OAuth-Anfragen erkennen kann. Eine Anleitung dazu finden Sie unter OAuth-Clientanwendung registrieren.
  2. Melden Sie sich mit OAuth in Looker an, um ein Zugriffstoken anzufordern. Ein Beispiel findest du unter Nutzer mit OAuth anmelden.
  3. Verwenden Sie ein Properties-Objekt, um die OAuth-Anmeldedaten beim Öffnen der JDBC-Verbindung zur Open SQL-Schnittstelle zu übergeben.

Im folgenden Beispiel wird DriverManager#getConnection(<String>, <Properties>`) verwendet:

String access_token = getAccessToken() //uses the Looker OAuth flow to get a token
String URL = "jdbc:looker:url=https://myInstance.cloud.looker.com"
Properties info = new Properties( );
info.put("token", access_token);
Connection conn = DriverManager.getConnection(URL, info);

Zugriffstoken mit API-Schlüsseln generieren

Anstatt den standardmäßigen OAuth-Ablauf zum Generieren eines Zugriffstokens zu verwenden, können Sie mithilfe der Looker API ein Zugriffstoken generieren, das an den JDBC-Treiber der Open SQL Interface übergeben werden kann. Gehen Sie dazu so vor:

  1. Generieren Sie API-Schlüssel für Ihren Looker-Nutzer wie auf der Seite Verwaltungseinstellungen – Nutzer beschrieben.

  2. Verwenden Sie den login API-Endpunkt für Ihre Looker-Instanz. Die Antwort enthält ein Zugriffstoken im Format Authorization: token <access_token>. Im Folgenden finden Sie ein Beispiel für den curl-Befehl, mit dem Sie diese Anfrage stellen können:

      curl -k -d "client_id=<client_id>&client_secret=<client_secret>" https://<looker_host>/login\

  3. Übergeben Sie den <access_token>-Wert der Antwort als Token im Properties-Objekt, um die OAuth-Anmeldedaten beim Öffnen der JDBC-Verbindung zur Open SQL-Schnittstelle zu übergeben.

API-Schlüssel

Sie können auch API-Schlüssel anstelle eines Nutzernamens und Passworts verwenden, um sich zu authentifizieren. API-Schlüssel gelten als weniger sicher als OAuth und sind möglicherweise nur während der Vorabversion der Open SQL-Schnittstelle verfügbar. Informationen zum Erstellen von API-Schlüsseln für Ihre Looker-Instanz finden Sie unter API-Schlüssel.

Verwenden Sie den Teil Client-ID des Looker API-Schlüssels als Nutzernamen. Verwenden Sie den Teil Client Secret für das Passwort.

Abfragen mit der Open SQL-Schnittstelle ausführen

Beachten Sie die folgenden Richtlinien, wenn Sie Abfragen mit der Open SQL-Schnittstelle ausführen:

  • Die Open SQL-Schnittstelle akzeptiert SQL-Abfragen, die der GoogleSQL-Syntax entsprechen.
  • Für die Open SQL-Schnittstelle müssen Modell-, Explore- und Feld-IDs in Graviszeichen (`) gesetzt werden. Weitere Informationen und Beispiele finden Sie unter Backticks um Datenbank-IDs setzen.
  • Die Open SQL-Schnittstelle unterstützt die meisten BigQuery-Operatoren.
  • Bei der Open SQL-Oberfläche müssen Sie alle LookML-Messwerte, die in einer Abfrage enthalten sind, angeben. Dazu müssen Sie die Messwerte (einschließlich Backticks) in die spezielle Funktion AGGREGATE() einschließen. Weitere Informationen finden Sie im Abschnitt LookML-Messwerte mit AGGREGATE() angeben.

SQL-Einschränkungen

Beachten Sie die folgenden SQL-Einschränkungen beim Senden von Abfragen an die Open SQL-Schnittstelle:

Backticks um Datenbank-IDs verwenden

Wenn Sie Abfragen an die Open SQL-Schnittstelle senden, setzen Sie Schema-, Tabellen- und Spalten-IDs in Backticks. So geben Sie Datenbankelemente mit Backticks und Looker-Begriffen an:

  • Schema: `<model_name>`
  • table: `<explore_name>`

  • Spalte: `<view_name>.<field_name>`

Hier ein Beispiel für ein SELECT-Anweisungsformat mit diesen Elementen:

SELECT `view.field`
  FROM `model`.`explore`
  LIMIT 10;

LookML-Messwerte mit AGGREGATE() angeben

Datenbanktabellen enthalten in der Regel nur Dimensionen, also Daten, die ein einzelnes Attribut einer Zeile in der Tabelle beschreiben. In LookML-Projekten können jedoch sowohl Dimensionen als auch Messwerte definiert werden. Ein Messwert ist eine Zusammenfassung von Daten aus mehreren Zeilen, z. B. SUM, AVG, MIN oder MAX. Andere Messwerttypen werden ebenfalls unterstützt. Eine vollständige Liste der unterstützten LookML-Messwerttypen finden Sie auf der Seite Messwerttypen.

Bei der Open SQL-Oberfläche müssen Sie alle LookML-Messwerte, die in einer Abfrage enthalten sind, angeben. Dazu müssen Sie die Messwerte (einschließlich Backticks) in die spezielle Funktion AGGREGATE() einschließen. So können Sie beispielsweise das Maß Anzahl aus der Ansicht Bestellungen angeben:

AGGREGATE(`orders.count`)

LookML-Messwerte müssen in die AGGREGATE()-Funktion eingeschlossen werden, unabhängig davon, ob sie sich in einer SELECT-, HAVING- oder ORDER BY-Klausel befinden.

Wenn Sie nicht sicher sind, ob ein Feld ein LookML-Maß ist, können Sie mit der Methode DatabaseMetaData.getColumns auf die Metadaten für das LookML-Projekt zugreifen. In der Spalte IS_GENERATEDCOLUMN wird für alle LookML-Messwerte YES und für LookML-Dimensionen NO angezeigt. Weitere Informationen finden Sie im Abschnitt Auf Datenbankmetadaten zugreifen.

Nur-Filter-Felder und Parameter mit JSON_OBJECT angeben

Die Open SQL-Schnittstelle unterstützt Parameter und Nur-Filter-Felder.

Wenn Sie Abfragen mit der Open SQL Interface ausführen, können Sie der Abfrage Parameter und nur-Filterfelder hinzufügen, indem Sie einen JSON_OBJECT-Konstruktoraufruf mit dem folgenden Format einfügen:

JSON_OBJECT(
    '<view>.<parameter name>', '<parameter value>',
    '<view>.<filter name>', '<Looker filter expression>'
)

Das JSON-Objekt kann null oder mehr Filter-Schlüssel/Wert-Paare und null oder mehr Parameter-Schlüssel/Wert-Paare enthalten.

  • Der Schlüssel im Konstruktor von JSON_OBJECT muss der Name eines Nur-Filter-Felds oder -Parameters sein.
  • Bei Nur-Filter-Feldern muss der Wert für jeden Schlüssel ein Looker-Stringfilterausdruck sein.
  • Bei Parametern muss der Wert für jeden Schlüssel ein einfacher Wert sein, der in der parameter-Definition definiert ist.

In den folgenden Abschnitten finden Sie Beispiele für die Verwendung von Parametern und Nur-Filter-Feldern mit der Open SQL-Schnittstelle.

Beispiel für einen Parameter

Beispiel für die Verwendung einer parameter mit Open SQL Interface: Die Ansicht customers hat in Looker einen Parameter, der so definiert ist:

parameter: segment {
  type: string
  allowed_value: {
    label: "Small (less than 500)"
    value: "small_customers"
  }
  allowed_value: {
    label: "Larger (greater than 10,000)"
    value: "large_customers"
  }
  allowed_value: {
    label: "Medium customers (Between 500 and 10,000)"
    value: "medium_customers"
  }
}

Sie könnten diese Abfrage an die Open SQL Interface senden, um den Parameterwert segment von medium_customers auf die Abfrage anzuwenden:

SELECT `customers.segment_size`,
  AGGREGATE(`orders.total_amount`)
FROM `ecommerce`.`orders`(JSON_OBJECT(
    'customers.segment', 'medium_customers'
))
GROUP BY `customers.state`, `customers.city`
HAVING AGGREGATE(`orders.count`) > 10
ORDER BY 3 DESC LIMIT 5;

Die Open SQL-Benutzeroberfläche übergibt diesen Parameterwert an die Abfrage in Looker. Looker wendet den Wert medium_customers auf alle Felder im Explore an, die für die Verwendung des Parameters segment konfiguriert sind. Informationen zur Funktionsweise von Parametern in Looker finden Sie in der parameter-Dokumentation.

Beispiel für ein Nur-Filter-Feld

Sie können ein filter-Feld mit der Open SQL-Schnittstelle verwenden. Angenommen, eine products-Ansicht hat eine Dimension und ein Nur-Filter-Feld, das in Looker so definiert ist:

filter: brand_select {
  type: string
  }

dimension: brand_comparitor {
  sql:
    CASE
      WHEN {% condition brand_select %} ${products.brand_name} {% endcondition %}
      THEN ${products.brand_name}
      ELSE "All Other Brands"
    END ;;
    }

Sie können den brand_select-Filter mit der Open SQL-Schnittstelle verwenden, indem Sie eine Abfrage wie die folgende senden:

SELECT `products.brand_comparator`, `products.number_of_brands`,
  AGGREGATE(`products.total_revenue`)
FROM `ecommerce`.`orders`(JSON_OBJECT(
    'products.brand_select', '%Santa Cruz%'
))
GROUP BY `products.brand_comparator`
ORDER BY 3 DESC LIMIT 5;

In der Open SQL-Schnittstelle wird der Looker-Stringfilterausdruck %Santa Cruz% auf die Abfrage in Looker angewendet. Informationen zur Funktionsweise von Nur-Filter-Feldern in Looker finden Sie in der filter-Dokumentation.

always_filter- oder conditionally_filter-Werte in einer WHERE- oder HAVING-Klausel angeben

Die Open SQL-Schnittstelle kann ein Explore unterstützen, das entweder always_filter oder conditionally_filter enthält, aber nicht beides.

Wenn Sie Ihr LookML-Explore mit always_filter oder conditionally_filter definiert haben, müssen Sie Werte für die Filterfelder in Ihrer SQL-Abfrage an die Open SQL-Schnittstelle übergeben:

  • Wenn in der Filterdefinition eine oder mehrere Dimensionen angegeben sind, müssen Sie in Ihrer SQL-Abfrage für jede der Filterdimensionen eine WHERE-Klausel angeben.
  • Wenn in der Filterdefinition ein oder mehrere Messwerte angegeben sind, müssen Sie in Ihrer SQL-Abfrage für jeden der Filtermesswerte eine HAVING-Klausel angeben.

Angenommen, Sie haben in einem faa-Modell ein LookML-Explore flights mit einem always_filter-Parameter definiert, in dem die Dimensionen country und aircraft_category sowie der Messwert count angegeben sind: 

explore: flights {
  view_name: flights
  always_filter: {
    filters: [country : "Peru" , aircraft_category : "Airplane", count : ">1"]
  }
}

In Ihrer Abfrage an die Open SQL-Schnittstelle müssen Sie eine WHERE-Klausel verwenden, um Werte für die Filterdimensionen und eine HAVING-Klausel, um einen Wert für den Messwertfilter an Ihr LookML-Modell zu übergeben. Hier ein Beispiel:

SELECT
    `flights.make`
FROM
    `faa`.`flights`
      WHERE `flights.country` = 'Ecuador' AND `flights.aircraft_category` = 'Airplane'
      GROUP BY
          1
      HAVING `flights.count` > 2) 
LIMIT 5

Wenn Sie keine Filterwerte für alle im Parameter always_filter angegebenen Dimensionen und Messwerte übergeben, gibt die Abfrage einen Fehler zurück. Dasselbe gilt für Dimensionen und Messwerte, die in einem conditionally_filter-Parameter angegeben sind. Der Unterschied besteht darin, dass Sie einen conditionally_filter-Parameter mit einem untergeordneten unless-Parameter definieren können, z. B. so:

explore: flights {
  view_name: flights
  conditionally_filter: {
    filters: [country : "Peru" , aircraft_category : "Airplane"]
    unless: [count]
  }
}

In diesem Fall müssen Sie für jede der Dimensionen und Messwerte, die im Unterparameter filters von conditionally_filter angegeben sind, einen Filterwert übergeben, es sei denn, Sie geben stattdessen einen Filter für ein Feld im Unterparameter unless an. Weitere Informationen zur Verwendung des Unterparameters unless finden Sie auf der Dokumentationsseite zu conditionally_filter.

Beispielsweise wäre eine der folgenden Abfragen an die Open SQL-Schnittstelle zulässig. Die erste Abfrage enthält Filterwerte für die Felder, die im Unterparameter filters angegeben sind, und die zweite Abfrage einen Filterwert für das Feld, das im Unterparameter unless angegeben ist:

SELECT
    `flights.make`
FROM
    `faa`.`flights`
      WHERE `flights.country` = 'Ecuador' AND `flights.aircraft_category` = 'Airplane'
      
LIMIT 5

SELECT
    `flights.make`
FROM
    `faa`.`flights`
      GROUP BY
          1
      HAVING `flights.count` > 2

Beispiel

Hier ist eine Beispielabfrage, in der sowohl Dimensionen als auch Messwerte verwendet werden. Mit dieser Abfrage werden die Dimensionen Bundesland und Ort aus der Ansicht Kunden und der Messwert Gesamtbetrag aus der Ansicht Bestellungen abgerufen. Beide Ansichten werden im explorativen Datenanalysetool Bestellungen im Modell E-Commerce zusammengeführt. Für Städte mit mehr als 10 Bestellungen werden in dieser Abfrageantwort die fünf Städte mit der höchsten Bestellmenge angezeigt:

SELECT `customers.state`, `customers.city`,
  AGGREGATE(`orders.total_amount`)
FROM `ecommerce`.`orders`
GROUP BY `customers.state`, `customers.city`
HAVING AGGREGATE(`orders.count`) > 10
ORDER BY 3 DESC LIMIT 5;

Auf Datenbankmetadaten zugreifen

Die Open SQL-Schnittstelle unterstützt einen Teil der standardmäßigen JDBC-DatabaseMetaData-Schnittstelle, mit der Informationen zur zugrunde liegenden Datenbank abgerufen werden. Mit den folgenden Methoden der DatabaseMetaData-Schnittstelle können Sie Informationen zu Ihrem LookML-Modell abrufen:

DatabaseMetadata.getSchemas

In der folgenden Tabelle wird beschrieben, wie ein LookML-Modell in der Antwort der DatabaseMetadata.getSchemas-Schnittstellenmethode mit den Standarddatenbankstrukturen in Beziehung steht.

getSchemas Antwortspalte Beschreibung
TABLE_SCHEM Name des LookML-Modells
TABLE_CATALOG (null)

DatabaseMetadata.getTables

In der folgenden Tabelle wird beschrieben, wie ein LookML-Modell in der Antwort der DatabaseMetaData.getTables-Schnittstellenmethode mit den Datenbankstrukturen in Beziehung steht. Die Antwort enthält sowohl standardmäßige JDBC-Metadaten als auch Looker-spezifische Metadaten:

getTables-Antwortspalte Beschreibung
JDBC-Standardmetadaten
TABLE_CAT (null)
TABLE_SCHEM Name des LookML-Modells
TABLE_NAME Name der LookML-Analyse
TABLE_TYPE Gibt immer den Wert TABLE_TYPE zurück
Looker-spezifische Metadaten
DESCRIPTION Beschreibung
LABEL Label für explorative Datenanalysen
TAGS Tags

DatabaseMetadata.getColumns

In der folgenden Tabelle wird beschrieben, wie ein LookML-Modell in der Antwort der DatabaseMetaData.getColumns-Schnittstellenmethode mit den Datenbankstrukturen in Beziehung steht. Die Antwort enthält standardmäßige JDBC-Metadaten sowie Looker-spezifische Metadaten:

getColumns Antwortspalte Beschreibung
JDBC-Standardmetadaten
TABLE_CAT (null)
TABLE_SCHEM Name des LookML-Modells
TABLE_NAME Name des LookML-Explores
COLUMN_NAME LookML-Feldname im Format `<view_name>.<field_name>`. Beispiel: `orders.amount`.
DATA_TYPE Der java.sql.Types-Code der Spalte. Looker-yesno-Felder haben beispielsweise den SQL-Typcode 16 (BOOLEAN).
ORDINAL_POSITION Die 1-basierte Ordinalzahl des Felds im Explore (Dimensionen und Messwerte werden alphabetisch nach Ansichts- und dann nach Feldnamen sortiert)
IS_NULLABLE Gibt immer den Wert YES zurück
IS_GENERATEDCOLUMN YES für Messwerte, NO für Dimensionen
Looker-spezifische Metadaten
DIMENSION_GROUP Name der Dimensionsgruppe, wenn das Feld zu einer Dimensionsgruppe gehört. Wenn das Feld nicht zu einer Dimensionsgruppe gehört, ist der Wert „null“.
DRILL_FIELDS Liste der Aufschlüsselungsfelder, die für die Dimension oder den Messwert festgelegt wurden, falls vorhanden
FIELD_ALIAS Alias für das Feld, falls vorhanden
FIELD_CATEGORY Ob das Feld dimension oder measure ist
FIELD_DESCRIPTION Feld description
FIELD_GROUP_VARIANT Wenn das Feld unter einem Gruppenlabel angezeigt wird, wird in FIELD_GROUP_VARIANT der kürzere Name des Felds angegeben, der unter dem Gruppenlabel angezeigt wird.
FIELD_LABEL Feld label
FIELD_NAME Name der Dimension oder des Messwerts
HIDDEN Gibt an, ob das Feld in der Feldauswahl in Explores ausgeblendet (TRUE) oder sichtbar (FALSE) ist.
LOOKER_TYPE LookML-Feldtyp für die Dimension oder den Messwert
REQUIRES_REFRESH_ON_SORT Gibt an, ob die SQL-Abfrage aktualisiert werden muss, um die Werte des Felds neu zu sortieren (TRUE), oder ob die Werte des Felds neu sortiert werden können, ohne dass die SQL-Abfrage aktualisiert werden muss (FALSE).
SORTABLE Gibt an, ob das Feld sortiert werden kann (TRUE) oder nicht (FALSE).
TAGS Feld tags
USE_STRICT_VALUE_FORMAT Ob für das Feld das strenge Format (TRUE) verwendet wird oder nicht (FALSE)
VALUE_FORMAT String für das Wertformat des Felds
VIEW_LABEL Label für das Feld anzeigen
VIEW_NAME Name der Ansicht, in der das Feld im LookML-Projekt definiert ist

Open SQL Interface-Abfragen in der Looker-Benutzeroberfläche identifizieren

Looker-Administratoren können über die Looker-Benutzeroberfläche ermitteln, welche Abfragen von der Open SQL-Schnittstelle stammen:

  • Auf der Seite Abfragen haben Abfragen aus der Open SQL-Schnittstelle den Wert „SQL-Schnittstelle“ für Quelle. Der Wert Nutzer enthält den Namen des Looker-Nutzers, der die Abfrage ausgeführt hat. Sie können auf die Schaltfläche Details für eine Abfrage klicken, um weitere Informationen zu dieser Abfrage aufzurufen. Klicken Sie im Dialogfeld Details auf SQL-Schnittstellenabfrage, um die SQL-Abfrage aufzurufen, die von der Open SQL-Schnittstelle an Looker gesendet wurde.

  • Im explorativen Analysetool Systemaktivitätsverlauf haben Abfragen aus der Open SQL-Schnittstelle den Wert „sql_interface“ für die Quelle. Im Wert User Email (Nutzer-E-Mail-Adresse) wird die E-Mail-Adresse des Looker-Nutzers angezeigt, der die Abfrage ausgeführt hat. Sie können direkt zum explorativen Datenbestand Verlauf wechseln, der nach „sql_interface“ gefiltert ist. Fügen Sie dazu die Adresse Ihrer Looker-Instanz an den Anfang dieser URL ein:

    https://Looker instance URL/explore/system__activity/history?fields=history.source,history.completed_date&f[history.source]=%22sql_interface%22

Repository für Drittanbieterabhängigkeiten

Über den folgenden Link erhalten Sie Zugriff auf das von Google gehostete Repository für Drittanbieterabhängigkeiten, die vom Looker JDBC-Treiber verwendet werden:

https://third-party-mirror.googlesource.com/looker_sql_interface/+/refs/heads/master/third_party/