SQL-Schnittstelle öffnen

Mit der semantischen Modellierungsebene LookML von Looker kann eine Fachkraft für Datenanalyse Dimensionen, Zusammenfassungen, Berechnungen und Datenbeziehungen in einer SQL-Datenbank definieren. LookML-Modelle bieten Code-Wiederverwendbarkeit und Git-Integration. Mit einem gut strukturierten LookML-Modell können Nutzer ihre eigenen Self-Service-Datenexplorationen und ‑berichte erstellen.

Das LookML-Modell ist die Grundlage aller Daten, die von Looker angefordert werden. Dabei spielt es keine Rolle, ob die Anfrage über die Looker-Oberfläche „Entdecken“ in der Looker-Benutzeroberfläche, über eine eingebettete Visualisierung in Ihrem Unternehmensportal oder einer anderen Drittanbieteranwendung oder über eine benutzerdefinierte Anwendung erfolgt, die mit der Looker-API entwickelt wurde. Die Open SQL-Schnittstelle bietet Zugriff auf die LookML-Modelle für jede Drittanbieteranwendung, die Java Database Connectivity (JDBC) unterstützt. Anwendungen können eine Verbindung zu einem LookML-Modell herstellen, als wäre es eine Datenbank. So können Nutzer alle Vorteile der Arbeit nutzen, die ihre Datenanalysten im LookML-Modell geleistet haben, und dabei die Tools verwenden, mit denen sie am besten vertraut sind.

So werden LookML-Projektelemente über die Open SQL Interface dargestellt

Wenn Sie verstehen möchten, wie das Open SQL Interface die Elemente eines LookML-Projekts darstellt, ist es wichtig, die Struktur von LookML-Projekten zu kennen.

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 Interface:

  • In einem LookML-Modell werden eine Datenbankverbindung und ein oder mehrere Explores angegeben. Über die Open SQL-Schnittstelle werden Modelle als Datenbankschemas verfügbar gemacht.
  • Ein Explore ist eine logische Gruppierung einer oder mehrerer Ansichten und der Join-Beziehungen zwischen diesen Ansichten. Über die Open SQL-Schnittstelle werden Explores als Datenbanktabellen angezeigt.
  • 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. Über die Open SQL-Schnittstelle wird die Kombination aus einem Ansichtsnamen und einem Feldnamen als Datenbankspaltenname angezeigt. Die Dimension id in der Ansicht order_items wird beispielsweise von der Open SQL Interface als Datenbankspalte mit dem Namen order_items.id angezeigt.

In einem Looker-Explore können Join-Beziehungen zwischen mehreren Ansichten definiert werden. Da es möglich ist, dass eine Ansicht ein Feld mit demselben Namen wie ein Feld in einer anderen Ansicht enthält, enthält die Open SQL-Schnittstelle sowohl den Ansichtsnamen als auch den Feldnamen, wenn auf eine Spalte verwiesen wird. Verwenden Sie daher dieses Format, um beim Senden von Anfragen an die Open SQL-Schnittstelle auf einen Spaltennamen zu verweisen:

`<view_name>.<field_name>`

Wenn es beispielsweise ein Explore namens order_items gibt, in dem eine Ansicht namens customer mit einer Ansicht namens product verknüpft wird und beide Ansichten eine Dimension id haben, würden Sie auf die beiden id-Felder als `customer.id` bzw. `product.id` verweisen. Wenn Sie den vollständig qualifizierten Namen auch mit dem Explore-Namen verwenden möchten, verweisen Sie auf die beiden Felder als `order_items`.`customer.id` und `order_items`.`product.id`. Weitere Informationen dazu, wo die Graviszeichen platziert werden müssen, wenn auf Datenbankkennzeichnungen verwiesen wird, finden Sie unter Graviszeichen um Datenbankkennzeichnungen 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 für die Open SQL-Schnittstelle herunter.

In den folgenden Abschnitten werden diese Schritte beschrieben.

Voraussetzungen

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

  • Die Drittanbieteranwendung, die Sie verwenden möchten (z. B. Tableau, ThoughtSpot oder eine benutzerdefinierte Anwendung), muss eine Verbindung zu Ihrer Looker-Instanz herstellen können. Die Open SQL-Schnittstelle kann mit vom Kunden gehosteten Looker-Instanzen verwendet werden, sofern die Looker-Instanz so vernetzt ist, dass die Drittanbieteranwendung auf die Looker-Instanz zugreifen kann.
  • Ein LookML-Projekt, in dem Daten aus einer Google BigQuery-Verbindung verwendet werden. Das LookML-Projekt muss eine Model-Datei mit einem Google BigQuery-Verbindungs-Parameter connection enthalten.
  • Eine Looker-Nutzerrolle, die die Berechtigung explore für das LookML-Modell enthält, auf das Sie mit der Open SQL Interface zugreifen möchten.

Open SQL Interface-JDBC-Treiber herunterladen

Der JDBC-Treiber für die Looker Open SQL Interface heißt avatica-<release_number>-looker.jar. Laden Sie die aktuelle 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

Authentifizierung bei der Open SQL-Schnittstelle

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 finden Sie unter OAuth-Clientanwendung registrieren.
  2. Melden Sie sich mit OAuth in Looker an, um ein Zugriffstoken anzufordern. Ein Beispiel finden Sie unter Nutzeranmeldung mit OAuth durchführen.
  3. Verwenden Sie ein Properties-Objekt, um die OAuth-Anmeldedaten beim Öffnen der JDBC-Verbindung zur Open SQL Interface zu übergeben.

Hier ein Beispiel mit DriverManager#getConnection(<String>, <Properties>`):

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 die folgenden Schritte ausführen, um mit der Looker API ein Zugriffstoken zu generieren, das an den Open SQL Interface-JDBC-Treiber übergeben werden kann:

  1. Generieren Sie API-Schlüssel für Ihren Looker-Nutzer, wie auf der Seite Admin settings - Users (Administratoreinstellungen – 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>. Das folgende Beispiel zeigt den curl-Befehl, den Sie für diese Anfrage verwenden 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 Interface zu übergeben.

API-Schlüssel

Sie können API-Schlüssel auch anstelle eines Nutzernamens und Passworts zur Authentifizierung verwenden. API-Schlüssel gelten als weniger sicher als OAuth und sind möglicherweise nur während der Vorschau 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 des Looker API-Schlüssels, der die Client-ID enthält, als Nutzernamen. Verwenden Sie den Teil Clientschlüssel 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 sind Graviszeichen (`) um Modell-, Explore- und Feldkennungen erforderlich. Weitere Informationen und Beispiele finden Sie unter Backticks um Datenbankkennzeichnungen verwenden.
  • Die Open SQL-Schnittstelle unterstützt die meisten BigQuery-Operatoren.
  • Bei der Open SQL-Schnittstelle müssen Sie alle LookML-Messwerte, die in einer Abfrage enthalten sind, kennzeichnen, indem Sie den Messwert (einschließlich der 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:

  • Die Open SQL-Schnittstelle unterstützt nur SELECT-Abfragen. Die Open SQL-Schnittstelle unterstützt keine UPDATE- und DELETE-Anweisungen sowie keine anderen Anweisungen der Datendefinitionssprache (DDL), Datenbearbeitungssprache (DML) oder Datenkontrollsprache (DCL).
  • Die Open SQL-Schnittstelle unterstützt den Operator JOIN nicht.
    • Sie können keine Abfrage mit dem Operator JOIN an die Open SQL-Schnittstelle senden, um Joins innerhalb desselben oder zwischen zwei verschiedenen Explores zu erstellen.
    • Wenn Sie einen Join zwischen zwei Tabellen in Ihrer Datenbank erstellen möchten, können Sie dies im LookML-Modell tun, indem Sie Joins für eine oder mehrere Ansichten in einer Explore-Definition in einer Modelldatei in Ihrem LookML-Projekt erstellen.
  • Die Open SQL-Schnittstelle unterstützt keine Fensterfunktionsaufrufe.
  • Die Open SQL-Schnittstelle unterstützt keine Unterabfragen.
  • Die Open SQL-Schnittstelle unterstützt keine Zeitzonenkonvertierung. Die Datums- und Uhrzeitangaben im LookML-Modell haben den Typ DATETIME in der Zeitzone, die in Ihren Einstellungen definiert ist (Nutzerzeitzone, Anwendungszeitzone oder Datenbankzeitzone).
  • Das Open SQL Interface unterstützt die BigQuery-Datentypen geography, JSON und time nicht.

Backticks um Datenbankkennungen verwenden

Wenn Sie Anfragen an die Open SQL-Schnittstelle senden, verwenden Sie Backticks für Schema-, Tabellen- und Spalten-IDs. So geben Sie Datenbankelemente mit Backticks und Looker-Begriffen an:

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

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

Hier ist ein Beispiel für das Format einer SELECT-Anweisung 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 Aggregation von Daten über mehrere Zeilen hinweg, z. B. SUM, AVG, MIN oder MAX. Auch andere Arten von Measures werden unterstützt. Eine vollständige Liste der unterstützten LookML-Measure-Typen finden Sie auf der Seite Measure-Typen.

Bei der Open SQL-Schnittstelle müssen Sie alle LookML-Messwerte, die in einer Abfrage enthalten sind, kennzeichnen, indem Sie den Messwert (einschließlich der Backticks) in die spezielle Funktion AGGREGATE() einschließen. So können Sie beispielsweise die Messung count aus der Ansicht orders angeben:

AGGREGATE(`orders.count`)

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

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

Nur-Filter-Felder und Parameter mit JSON_OBJECT angeben

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

Wenn Sie Abfragen mit der Open SQL Interface ausführen, können Sie Parameter und Felder, die nur zum Filtern verwendet werden, auf die Abfrage anwenden, 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 JSON_OBJECT-Konstruktor 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.
  • Für Parameter 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 Interface.

Beispiel für Parameter

Ein Beispiel für die Verwendung von parameter mit der Open SQL-Schnittstelle: Wenn für die Ansicht customers ein Parameter in Looker so definiert wäre:

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önnen diese Anfrage an die Open SQL Interface senden, um den segment-Parameterwert medium_customers auf die Anfrage 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;

Über die Open SQL-Schnittstelle wird dieser Parameterwert an die Abfrage in Looker übergeben. Looker wendet den medium_customers-Wert auf alle Felder im Explore an, die für die Verwendung des segment-Parameters konfiguriert sind. Informationen zur Funktionsweise von Parametern in Looker finden Sie in der Dokumentation zu parameter.

Beispiel für ein Nur-Filter-Feld

Sie können ein filter-Feld mit der Open SQL-Schnittstelle verwenden. Wenn für eine products-Ansicht beispielsweise eine Dimension und ein Nur-Filter-Feld in Looker so definiert sind:

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 Filter brand_select 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;

Open SQL Interface wendet den Looker-Stringfilterausdruck %Santa Cruz% auf die Abfrage in Looker an. Informationen zur Funktionsweise von Nur-Filter-Feldern in Looker finden Sie in der filter-Dokumentation.

Geben Sie always_filter- oder conditionally_filter-Werte in einer WHERE- oder HAVING-Klausel an.

Die Open SQL-Schnittstelle kann ein Explore mit always_filter oder conditionally_filter unterstützen, 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 für jede der Filterdimensionen eine WHERE-Klausel in Ihre SQL-Abfrage einfügen.
  • Wenn in der Filterdefinition ein oder mehrere Messwerte angegeben sind, müssen Sie für jeden der Filtermesswerte eine HAVING-Klausel in Ihre SQL-Abfrage einfügen.

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

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

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

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 die einzelnen Dimensionen und Messwerte angeben, die im Parameter always_filter angegeben sind, wird bei der Abfrage ein Fehler zurückgegeben. Das Gleiche gilt für Dimensionen und Messwerte, die in einem conditionally_filter-Parameter angegeben sind. Sie können jedoch einen conditionally_filter-Parameter mit einem unless-Unterparameter definieren, 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.

Die folgenden Abfragen an die Open SQL-Schnittstelle wären beispielsweise zulässig. Die erste Abfrage liefert Filterwerte für die Felder, die im Unterparameter filters angegeben sind, und die zweite Abfrage liefert 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 sehen Sie ein Beispiel für eine Abfrage mit Dimensionen und Messwerten. Mit dieser Abfrage werden die Dimensionen Bundesstaat und Stadt aus der Ansicht Kunden und der Messwert Gesamtbetrag aus der Ansicht Bestellungen abgerufen. Beide Ansichten werden im Modell ecommerce in den Explore-Bereich orders eingefügt. Für die Städte mit mehr als 10 Bestellungen werden in dieser Antwort die fünf Städte mit dem höchsten Bestellbetrag 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 eine Teilmenge der standardmäßigen JDBC-DatabaseMetaData-Schnittstelle, die zum Abrufen von Informationen zur zugrunde liegenden Datenbank verwendet wird. Mit den folgenden Methoden der DatabaseMetaData-Schnittstelle können Sie Informationen zu Ihrem LookML-Modell abrufen:

Die SQL-Schnittstelle gibt nur Ergebnisse für Modelle, Explores und Felder zurück, auf die Sie Zugriff haben.

DatabaseMetadata.getSchemas

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

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

DatabaseMetadata.getTables

In der folgenden Tabelle wird beschrieben, wie ein LookML-Modell mit den Datenbankstrukturen in der Antwort der Schnittstellenmethode DatabaseMetaData.getTables zusammenhängt. Die Antwort enthält standardmäßige JDBC-Metadaten sowie 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.
REMARKS (null)
TYPE_CAT (null)
TYPE_SCHEM (null)
TYPE_NAME String, der den Tabellentyp darstellt. Mögliche Typen sind TABLE, VIEW, SYSTEM TABLE, GLOBAL TEMPORARY, LOCAL TEMPORARY, ALIAS und SYNONYM.
SELF_REFERENCING_COL_NAME (null)
REF_GENERATION (null)
Looker-spezifische Metadaten
DESCRIPTION Beschreibung
LABEL Label ansehen
TAGS Tags ansehen
CONDITIONALLY_FILTER_UNLESS Die Liste der Felder im Unterparameter unless des Parameters conditionally_filter von Explore. Wenn im Unterparameter unless keine Felder angegeben sind oder für den Explore kein conditionally_filter-Parameter definiert ist, ist dieser Wert „null“.

DatabaseMetadata.getColumns

In der folgenden Tabelle wird beschrieben, wie ein LookML-Modell mit den Datenbankstrukturen in der Antwort der Schnittstellenmethode DatabaseMetaData.getColumns zusammenhängt. 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-Felder vom Typ yesno haben beispielsweise den SQL-Typcode 16 (BOOLEAN).
TYPE_NAME String, der den Datentyp der Spalte darstellt. Bei einem benutzerdefinierten Typ (User-Defined Type, UDT) ist der Typname voll qualifiziert.
COLUMN_SIZE Ganzzahl, die die maximale Anzahl von Zeichen oder Byte angibt, die in der Spalte gespeichert werden können.
BUFFER_LENGTH (null)
DECIMAL_DIGITS Ganzzahl, die die Skalierung der Daten darstellt: die Anzahl der Ziffern rechts vom Dezimalkomma für anwendbare Datentypen oder die Anzahl der Nachkommastellen. Für Datentypen, für die DECIMAL_DIGITS nicht zutrifft, wird „Null“ zurückgegeben.
NUM_PREC_RADIX Ganzzahl, die die Basis oder Radix (in der Regel 10 oder 2) für die Daten darstellt.
NULLABLE

Ganzzahl, die angibt, ob Nullwerte zulässig sind:

  • 0: columnNoNulls – lässt möglicherweise keine NULL-Werte zu
  • 1: columnNullable – NULL-Werte sind definitiv zulässig.
  • 2: columnNullableUnknown – Nullwerte zulässig (Status unbekannt)
REMARKS (null)
COLUMN_DEF (null)
SQL_DATA_TYPE (null)
SQL_DATETIME_SUB (null)
CHAR_OCTET_LENGTH Für Zeichendatentypen eine Ganzzahl, die die maximale Anzahl von Byte in der Spalte darstellt.
ORDINAL_POSITION Die 1-basierte Ordnungszahl des Felds im Explore (Dimensionen und Messwerte werden alphabetisch nach Ansichtsname und dann nach Feldname sortiert)
IS_NULLABLE Gibt immer den Wert YES zurück.
SCOPE_CATALOG (null)
SCOPE_SCHEMA (null)
SCOPE_TABLE (null)
SOURCE_DATA_TYPE (null)
IS_AUTOINCREMENT (null)
IS_GENERATEDCOLUMN YES für Ergebnisse, NO für Dimensionen
Looker-spezifische Metadaten
DIMENSION_GROUP Name der Dimensionsgruppe, wenn das Feld Teil einer Dimensionsgruppe ist. Wenn das Feld nicht Teil einer Dimensionsgruppe ist, ist dieser Wert null.
DRILL_FIELDS Liste der Drilldown-Felder, die für die Dimension oder den Messwert festgelegt sind (falls vorhanden)
FIELD_ALIAS Alias für das Feld, falls vorhanden
FIELD_CATEGORY Ob das Feld ein dimension oder ein measure ist
FIELD_DESCRIPTION Feld description
FIELD_GROUP_VARIANT Wenn das Feld unter einer Gruppenbezeichnung angezeigt wird, gibt FIELD_GROUP_VARIANT den kürzeren Namen des Felds an, der unter der Gruppenbezeichnung angezeigt wird.
FIELD_LABEL Feld label
FIELD_NAME Name der Dimension oder des Messwerts
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 eine Aktualisierung der SQL-Abfrage erforderlich ist (FALSE).
SORTABLE Gibt an, ob das Feld sortiert werden kann (TRUE) oder nicht (FALSE).
TAGS Feld tags
USE_STRICT_VALUE_FORMAT Gibt an, ob für das Feld das strikte Wertformat (TRUE) verwendet wird oder nicht (FALSE).
VALUE_FORMAT Wertformat-String für das Feld
VIEW_LABEL Label anzeigen für das Feld
VIEW_NAME Name der Ansicht, in der das Feld im LookML-Projekt definiert ist
HIDDEN Gibt an, ob das Feld im Field Picker in Explores ausgeblendet (TRUE) oder sichtbar (FALSE) ist.
ALWAYS_FILTER Der Standardwert für den Parameter always_filter, der für das Feld festgelegt ist. Wenn das Feld nicht Teil eines always_filter-Parameters ist, ist dieser Wert null.
CONDITIONALLY_FILTER Der Standardwert für den Parameter conditionally_filter, der für das Feld festgelegt ist. Wenn das Feld nicht Teil eines conditionally_filter-Parameters ist, ist dieser Wert null.

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

Looker-Administratoren können in der Looker-Benutzeroberfläche ermitteln, welche Abfragen von der Open SQL Interface stammen:

  • Auf der Seite Abfragen haben Abfragen über die Open SQL Interface den Quellwert „SQL Interface“. Der Wert User enthält den Namen des Looker-Nutzers, der die Abfrage ausgeführt hat. Wenn Sie bei einer Abfrage auf die Schaltfläche Details klicken, werden zusätzliche Informationen zur Abfrage angezeigt. Im Dialogfeld Details können Sie auf SQL Interface query (SQL-Schnittstellenabfrage) klicken, um die SQL-Abfrage zu sehen, die über die Open SQL Interface an Looker gesendet wurde.

  • Im System Activity History Explore haben Abfragen über die Open SQL Interface den Source-Wert „sql_interface“. Im Wert User Email (E-Mail-Adresse des Nutzers) wird die E-Mail-Adresse des Looker-Nutzers angezeigt, der die Abfrage ausgeführt hat. Sie können direkt zum Verlauf-Explore mit dem Filter „sql_interface“ wechseln, indem Sie die Adresse Ihrer Looker-Instanz am Anfang dieser URL einfügen:

    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 können Sie auf das von Google gehostete Repository für Drittanbieterabhängigkeiten zugreifen, die vom Looker JDBC-Treiber verwendet werden:

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