derived_analytic_model

Nutzung

view: view_name {
  derived_analytic_model: {
    sql: analytic_model_definition ;;
  }
}
Hierarchie
view
derived_analytic_model
Standardwert
Keine

Besondere Regeln
Analysemodelle werden nur für BigQuery- und Snowflake-Verbindungen unterstützt.

Definition

Für BigQuery- und Snowflake-Verbindungen definiert der derived_analytic_model Parameter ein In-Database-Analysemodell (ein BigQuery-Diagramm oder eine semantische Ansicht in Snowflake), das von Looker verwaltet wird. In diesem Fall generiert Looker das Analysemodell in Ihrer Datenbank, indem die entsprechenden SQL-DDL-Anweisungen (Data Definition Language, Datendefinitionssprache) ausgeführt werden, die Sie in der Definition des derived_analytic_model LookML-Parameters angeben. Die SQL-Syntax, die Sie im Parameter derived_analytic_model definieren, muss von Ihrer Datenbank unterstützt werden.

Im Gegensatz zu abgeleiteten Tabellen werden in von Looker verwalteten Analysemodellobjekten keine Daten in der Datenbank gespeichert und sie werden nicht inkrementell aktualisiert. Stattdessen stellen sie semantische Modelle dar, die Beziehungen und Messwerte direkt in der Datenbank definieren.

Verwenden Sie einen der folgenden Unterparameter des Parameters derived_analytic_model, um ein Analysemodell zu definieren:

Wenn Sie Ihre Analyseansicht mit dem sql Unterparameter definieren, können Sie außerdem den publish_as_db_analytic_model Unterparameter des derived_analytic_model Parameters verwenden, um ein stabiles Analysemodell zu erstellen, das außerhalb von Looker abgefragt werden kann.

Nachdem Sie das Analysemodell im Parameter derived_analytic_model definiert haben, können Sie LookML-Dimensionen und -Messwerte definieren, die Ihrem Analysemodell zugeordnet sind. Beispiele finden Sie im Abschnitt Beispiele.

sql

Verwenden Sie den Parameter sql, wenn Sie nur den SQL-Code für die Definition des Analysemodells angeben und die Erstellung des Analysemodells von Looker verwalten lassen möchten. Wenn Sie den sql Unterparameter verwenden, fügen Sie keine CREATE oder eine CREATE OR REPLACE Anweisung ein, da Looker die DDL-Anweisung automatisch generiert, um das Analysemodell auf Datenbankseite zu erstellen.

Ein Beispiel für die Verwendung des Parameters sql zum Erstellen eines Analysemodells in Ihrer Datenbank finden Sie unter Abgeleitetes Analysemodell mit sql erstellen.

sql_create

Verwenden Sie den Parameter sql_create, um eine vollständige SQL-Anweisung zum Erstellen eines Analysemodells zu definieren. Wenn Sie den sql_create Parameter verwenden, müssen Sie eine CREATE OR REPLACE Anweisung (oder eine CREATE Anweisung, wenn Ihr Dialekt CREATE OR REPLACE nicht unterstützt) einfügen.

Beachten Sie Folgendes, wenn Sie den Unterparameter sql_create verwenden:

  • Verwenden Sie für BigQuery-Verbindungen eine CREATE OR REPLACE-Anweisung, um das Analysemodell zu erstellen.
  • Verwenden Sie ${SQL_TABLE_NAME}, um den berechneten Namen des zu erstellenden Analysemodells zu ersetzen. So wird sichergestellt, dass die SQL-Anweisung den Namen des Analysemodells korrekt enthält, den Sie im LookML-Parameter view angeben.

Ein Beispiel für die Verwendung des Parameters zum Erstellen eines Analysemodells in Ihrer Datenbank finden Sie unter Abgeleitetes Analysemodell mit sql_create erstellen.sql_create

create_process

Verwenden Sie den Parameter create_process, wenn Sie mehrere sequenzielle SQL-Anweisungen definieren müssen, um das Analysemodell zu definieren. Verwenden Sie unter dem Parameter create_process den Unterparameter sql_step, um die einzelnen SQL-Anweisungen anzugeben. Ihre Datenbank führt die sql_step-Anweisungen nacheinander in der von Ihnen angegebenen Reihenfolge aus. Looker gibt die SQL-Anweisungen in den sql_step Unterparametern ohne Wrapper aus. Das bedeutet, dass Sie einen Schritt mit einer CREATE OR REPLACE-Anweisung (oder einer CREATE-Anweisung, wenn Ihr Dialekt CREATE OR REPLACE nicht unterstützt) einfügen müssen.

Ein Beispiel für die Verwendung des Parameters create_process zum Erstellen eines Analysemodells in Ihrer Datenbank finden Sie unter Abgeleitetes Analysemodell mit create_process erstellen.

publish_as_db_analytic_model

Für abgeleitete Analysemodelle, die mit dem sql-Parameter erstellt wurden, können Sie Ihr abgeleitetes Analysemodell mit publish_as_db_analytic_model: yes definieren, um Looker aufzufordern, ein stabiles Analysemodell zu erstellen, das außerhalb von Looker abgefragt werden kann.

Das stabile Analysemodell wird im nächsten Zyklus des Looker-Regenerators veröffentlicht (erstellt), nachdem die LookML des abgeleiteten Analysemodells mit publish_as_db_analytic_model: yes in der Produktion bereitgestellt wurde.

Informationen zum Abrufen des Namens des stabilen Analysemodells, damit Sie es außerhalb von Looker abfragen können, finden Sie im Abschnitt Auf das stabile Analysemodell zugreifen.

LookML-Dimensionen und ‑Messwerte basierend auf Ihrer Analyseansicht erstellen

Nachdem Sie Ihr Analysemodell definiert haben, können Sie in derselben Ansichtsdatei LookML-Dimensionen und ‑Messwerte definieren, die auf dem Analysemodell basieren.

Informationen zur richtigen Syntax für die Definition Ihres Analysemodells und zum Verweisen auf Elemente in Ihrem Analysemodell finden Sie in der Dokumentation zu Ihrem Dialekt. Wenn Sie beispielsweise eine LookML-Dimension aus einer BigQuery-Diagrammentität erstellen möchten, müssen Sie beim Scoping Unterstriche verwenden, um Elemente zu trennen. Für BigQuery-Diagramme basiert diese LookML-Dimension beispielsweise auf dem Attribut location_id in der Knotentabelle Stores:

  dimension: location_id {
    type: number
    sql: Stores_location_id ;;
  }

Wenn Sie jedoch eine LookML-Dimension erstellen möchten, die auf einer semantischen Ansicht von Snowflake basiert, müssen Sie den nicht qualifizierten Namen eines Messwerts oder einer Dimension verwenden.

Beispiele

In den folgenden Abschnitten finden Sie Beispiele für das Erstellen einer Analyseansicht mit den verschiedenen Unterparametern von derived_analytic_model:

Abgeleitetes Analysemodell mit sql erstellen

Im Folgenden finden Sie eine Beispiel-LookML-Ansichtsdatei, die ein SQL-basiertes Analysemodell für eine BigQuery-Datenbank mit dem Unterparameter sql von derived_analytic_model definiert. Looker erstellt das Analysemodell in der Datenbank, indem die SQL-DDL-Befehle ausgeführt werden, die im Parameter sql angegeben sind.

Beachten Sie im Beispiel Folgendes:

  • Der Unterparameter sql enthält nur die Definition des Analysemodells selbst. Es gibt keine CREATE-Anweisung, da Looker mit sql die CREATE-Befehle für das Analysemodell automatisch verarbeitet.
  • Das Analysemodell wird mit publish_as_db_analytic_model: yes definiert. Looker erstellt also ein stabiles Analysemodell, das außerhalb von Looker abgefragt werden kann.
view: MyWarehouseOrdersView {
  derived_analytic_model: {
    publish_as_db_analytic_model: yes

    # Defining the analytic model
    
    sql:
      NODE TABLES (
        Customers
        KEY(customer_id)
        PROPERTIES(
          country_code,
          concat(first_name, ' ', last_name) AS name,
          age,
          MEASURE(AVG(age)) AS AvgAge 
        ),
      Orders
        KEY(order_id)
        PROPERTIES (
          customer_id,
          employee_id,
          date,
          discount,
          MEASURE(AVG(discount)) AS AvgDiscount
        )

      EDGE TABLES (
        -- Relationship: Orders -> Customers
        looker_test.orders AS orders_to_users
          KEY(id)
          SOURCE KEY (order_id) REFERENCES orders (order_id)
          DESTINATION KEY (customer_id) REFERENCES Customers (customer_id)
          NO PROPERTIES
      ) ;;
  }

  # Mapping dimensions/measures to the dimensions/measures
  # provided by the analytic model

  dimension: customer_id {
    type: number
    sql: Customers_customer_id ;;
  }

  dimension: customer_age {
    type: number
    sql: Customers_age ;;
  }

  measure: orders_avg_discount {
    type: number
    sql: Orders_AvgDiscount ;; 
  }
}

Abgeleitetes Analysemodell mit create_process erstellen

Im Folgenden finden Sie eine Beispiel-LookML-Ansichtsdatei, die ein SQL-basiertes Analysemodell für eine BigQuery-Datenbank mit dem Unterparameter create_process von derived_analytic_model definiert. In diesem Beispiel müssen Sie mehrere sequenzielle SQL-Anweisungen definieren, um das Analysemodell zu definieren. Im ersten Schritt wird das Analysemodell gelöscht, falls es bereits vorhanden ist, und im zweiten Schritt wird es erstellt.

view: university_statistics {
  derived_analytic_model: {
    create_process: {
      sql_step: 
        DROP PROPERTY GRAPH IF EXISTS ${SQL_TABLE_NAME} ;;
      sql_step: 
        CREATE PROPERTY GRAPH ${SQL_TABLE_NAME}
         NODE TABLES (
          university.College
            KEY(college_id)
            PROPERTIES(college_id, college_name),
          university.Department
            KEY(dept_id)
            PROPERTIES(dept_id, dept_name, college_id,
              budget OPTIONS(description="Department budget in USD"),
              MEASURE(SUM(budget)) AS total_budget),
          university.Course
            KEY(course_id)
            PROPERTIES(
              course_id,
              course_name,
              credits,
              dept_id,
              MEASURE(AVG(credits)) AS avg_credits,
              MEASURE(SUM(credits)) AS total_credits,
              MEASURE(COUNT(course_id)) AS course_count)
        )
        EDGE TABLES (
          university.Department AS CollegeDept
            SOURCE KEY (college_id) REFERENCES College (college_id)
            DESTINATION KEY (dept_id) REFERENCES Department (dept_id),
          university.Course AS DeptCourse
            SOURCE KEY (dept_id) REFERENCES Department (dept_id)
            DESTINATION KEY (course_id) REFERENCES Course (course_id)
        );;
    }
  }

  # Mapping dimensions/measures to the dimensions/measures
  # provided by the analytic model

  dimension: college_id {
    type: number
    sql: College_college_id ;;
  }

  dimension: course_name {
    type: string
    sql: Course_course_name ;;
  }
  
  ...
}

Abgeleitetes Analysemodell mit sql_create erstellen

Im Folgenden finden Sie eine Beispiel-LookML-Ansichtsdatei, die ein SQL-basiertes Analysemodell für eine BigQuery-Datenbank mit dem Unterparameter sql_create von derived_analytic_model definiert. In diesem Beispiel definiert der Parameter sql_create die vollständige CREATE OR REPLACE-Anweisung, die ausgeführt werden soll, um das Analysemodell in einem einzigen Schritt zu erstellen.

view: MyWarehouseOrdersView {
  derived_analytic_model: {
    sql_create:
      CREATE OR REPLACE PROPERTY GRAPH ${SQL_TABLE_NAME}
        NODE TABLES(
          accounting.Loan AS Loan
            KEY(loanId)
            LABEL Loan PROPERTIES(
              loanId,
              loanAmount,
              balance,
              createTime,
              interestRate,
              accountId,
              balance + 100 AS derived_balance,
              CASE WHEN balance > 1000 THEN "High" ELSE "Low" END AS risk_level,
              CONCAT("ID-", CAST(loanId AS STRING)) AS full_id,
              DATE(2024, 1, 1) AS fixed_date,
              MEASURE(AVG(interestRate)) AS avg_interest_rate
            ),
          accounting.AccountView AS Account
            KEY(accountId)
            LABEL Account PROPERTIES(
              accountId,
              createTime,
              isBlocked,
              accountType,
              amount,
              ownerId,
              MEASURE(MIN(createTime)) AS oldest_account_create_time,
              MEASURE(MAX(createTime)) AS newest_account_create_time,
              MEASURE(AVG(amount)) AS avg_account_amount,
              MEASURE(SUM(amount)) AS total_account_amount,
              MEASURE(COUNT(DISTINCT accountType)) AS account_type_count
            ),
          accounting.PersonMV AS Person
            KEY(personId)
            LABEL Person PROPERTIES(
              personId,
              personName,
              age,
              age_tier,
              MEASURE(AVG(age)) AS avg_age,
              MEASURE(COUNT(DISTINCT age_tier)) AS age_tier_count
            )
        )
        EDGE TABLES(
          accounting.Loan AS Account_Repay_Loan
            KEY(loanId)
            SOURCE KEY(loanId) REFERENCES Loan(loanId)
            DESTINATION KEY(accountId) REFERENCES Account(accountId)
            LABEL Repay NO PROPERTIES,
          accounting.Account AS Person_Own_Account
            KEY(accountId)
            SOURCE KEY(accountId) REFERENCES Account(accountId)
            DESTINATION KEY(ownerId) REFERENCES Person(personId)
            LABEL Own NO PROPERTIES
        );;
  }

  # Mapping dimensions/measures to the dimensions/measures
  # provided by the analytic model

  dimension: loan_id {
    type: number
    sql: Loan_loanId ;;
  }

  dimension: account_ID {
    type: number
    sql: Account_accountID ;;
  }

  ...

}

Auf das stabile Analysemodell zugreifen

Wenn Sie Ihr abgeleitetes Analysemodell mit dem sql-Unterparameter erstellt und die Anweisung publish_as_db_analytic_model: yes unter dem Parameter derived_analytic_model eingefügt haben, veröffentlicht (erstellt) Looker das stabile Analysemodell im nächsten Zyklus des Looker-Regenerators, nachdem die LookML des abgeleiteten Analysemodells mit in der Produktion bereitgestellt wurde publish_as_db_analytic_model: yes.

Wenn das stabile Analysemodell veröffentlicht wurde, können Sie es direkt mit seinem stabilen Namen abfragen. Es gibt zwei Möglichkeiten, den stabilen Namen für ein Analysemodell zu erhalten:

Modal „Details zu persistenten abgeleiteten Tabellen“

Wenn Sie Administrator oder Nutzer mit der see_pdts Berechtigung sind, können Sie so den stabilen Namen des Analysemodells für ein Analysemodell auf der Seite Persistente abgeleitete Tabellen im Bereich Admin von Looker abrufen:

  1. Klicken Sie auf das Symbol für das Hauptmenü von Looker und wählen Sie Admin aus, falls das Menü Admin noch nicht angezeigt wird. Wenn Sie sich im Bereich Explore oder Entwickeln des Hauptmenüs von Looker befinden, müssen Sie möglicherweise auf den Zurückpfeil klicken, um das Menü Admin zu sehen.
  2. Wählen Sie im Menü Admin die Option Persistente abgeleitete Tabellen aus.
  3. Suchen Sie auf der Seite Persistente abgeleitete Tabellen nach dem Namen Ihres Analysemodells.
  4. Klicken Sie auf das Dreipunkt-Menü für Ihr Analysemodell und wählen Sie dann Details zu persistenten abgeleiteten Tabellen aus.
  5. Suchen Sie im Modal Details zu persistenten abgeleiteten Tabellen nach dem Feld Stabiler Name.

Wenn Sie das stabile Analysemodell direkt abfragen möchten, fügen Sie den Namen des Scratch-Schemas vor dem Modellnamen hinzu. Wenn der Name des Scratch-Schemas beispielsweise tmp ist, können Sie das stabile Analysemodell mit einem Befehl wie diesem abfragen:

SELECT * from tmp.PA_bq_analytic_model_sales_semantic_view

SQL-Tab eines Explores

Wenn Sie keinen Zugriff auf die Admin-Seite Persistente abgeleitete Tabellen haben, können Sie den stabilen Namen aus den Informationen auf dem Tab SQL im Bereich Daten einer Explore-Abfrage des Analysemodells ermitteln. So rufen Sie den stabilen Namen für ein Analysemodell ab:

  1. Öffnen Sie den Explore für die Ansicht Ihres Analysemodells.

  2. Wählen Sie im Explore Dimensionen oder Messwerte aus der Feldauswahl aus.

  3. Klicken Sie im Bereich Daten auf den Tab SQL.

  4. Suchen Sie auf dem Tab SQL nach einer der folgenden SQL-Anweisungen:

    • Für BigQuery-Diagramme:
      • CREATE PROPERTY GRAPH
      • SELECT ... FROM GRAPH_EXPAND('PROPERTY_GRAPH_NAME')
    • Für semantische Ansichten von Snowflake:
      • CREATE SEMANTIC VIEW
      • SELECT ... FROM SEMANTIC_VIEW_NAME

  5. Der stabile Name ist eine Ansicht, die Looker im Scratch-Schema erstellt und die auf die tatsächliche verschleierte Tabelle auf dem Tab „SQL“ verweist. Um den stabilen Namen für die Analyseansicht zu erhalten, geben Sie die folgenden Informationen aus der SQL-Anweisung ein:

    SCRATCH_SCHEMA_NAME.CONNECTION_REGISTRATION_KEY_MODEL_NAME_VIEW_NAME
    • SCRATCH_SCHEMA_NAME: Der Name des Scratch-Schemas ist der Anfang des Strings nach der Anweisung CREATE oder SELECT, vor dem „.“.
    • CONNECTION_REGISTRATION_KEY: Der Registrierungsschlüssel der Verbindung besteht aus zwei Zeichen. Je nach Datenbankdialekt folgt er entweder einem Dollarzeichen oder dem ersten Unterstrich im Tabellennamen in der Anweisung CREATE oder SELECT.
    • MODEL_NAME: Der Name des LookML-Modells.
    • VIEW_NAME: Der Name der Ansicht, in der das Analysemodell definiert ist.

Hier sehen Sie beispielsweise den Text auf dem Tab SQL einer Explore-Abfrage für eine BigQuery-Verbindung. Das Analysemodell ist in der Ansicht sales_analytic_model definiert und der Name des LookML-Modells ist thelook. In diesem Fall hat Looker das Analysemodell bereits erstellt. Es gibt also keine CREATE-Anweisung. Die Anweisung SELECT ... FROM GRAPH_EXPAND enthält jedoch die Informationen zum Tabellennamen:

-- use existing sales_analytic_model in `looker-test-db.looker_scratch.LG_J7LSZ1778710001008_sales_analytic_model`
SELECT
    sales_analytic_model.orders_id  AS sales_analytic_model_orders_id,
    AGG(sales_analytic_model.orders_count_orders ) AS sales_analytic_model_count_orders
FROM GRAPH_EXPAND("looker-test-db.looker_scratch.LG_J7LSZ1778710001008_sales_analytic_model") AS sales_analytic_model
GROUP BY
    1
ORDER BY
    2 DESC
LIMIT 500

Hier sind die Werte, die Sie benötigen, um den stabilen Namen des Analysemodells abzuleiten:

  • SCRATCH_SCHEMA_NAME ist looker-test-db.looker_scratch
  • CONNECTION_REGISTRATION_KEY ist J7
  • MODEL_NAME ist thelook
  • VIEW_NAME ist sales_analytic_model

Der stabile Name für das Analysemodell lautet also:

looker-test-db.looker_scratch.J7_thelook_sales_analytic_model

Sobald Sie den stabilen Namen des Analysemodells haben, können Sie das Analysemodell direkt abfragen.

Wichtige Punkte

Beachten Sie bei der Verwendung von In-Database-Analysemodellen die folgenden Punkte und Einschränkungen:

  • Datentypen:Für Dimensionen und Messwerte werden mit Analysemodellen nur die folgenden Datentypen unterstützt:

    • Unterstützt für Dimensionen und Messwerte:
      • string
      • number
      • date
      • yesno
    • Nur für Dimensionen unterstützt:
      • time
      • date_time

  • Messwerte :

    • Basismesswerte müssen vordefiniert sein:Basismesswerte müssen im zugrunde liegenden Datenbankanalysemodell vordefiniert sein. Looker kann keinen neuen Basismesswert definieren, indem eine Aggregation (z. B. type: sum oder type: count) für eine Dimension aus einem Analysemodell ausgeführt wird.

    • Messwerte, die auf anderen Messwerten basieren, werden unterstützt:Mit dem Parameter sql eines LookML-Messwerts können Sie nicht aggregierte Berechnungen ausführen, bei denen vordefinierte Basismesswerte aus dem Analysemodell verwendet werden. Wenn Sie einen Messwert erstellen, der auf anderen Messwerten basiert, können Sie den neuen Messwert nicht als aggregierten Messwerttyp wie sum oder count definieren. Sie müssen den neuen Messwert als nicht aggregierten Messwerttyp definieren, z. B. string, number, date oder yesno. Sehen Sie sich folgendes Beispiel an:

      measure: average_order_amount {
  type: number
  sql: ROUND(${total_order_amount} / NULLIF(${count_orders}, 0), 2) ;;
}

  • Verknüpfungen:Ein Explore, dessen Basisansicht auf einem Analysemodell basiert, darf keine Verknüpfungen enthalten. Ebenso kann eine Ansicht, die auf einem Analysemodell basiert, nicht mit einem Explore verknüpft werden, das eine standardmäßige LookML-Basisansicht hat.

  • Implizite Verknüpfungen:Funktionen, die auf impliziten Verknüpfungen basieren, werden für Analysemodelle nicht unterstützt. Beispiele für Funktionen, die auf impliziten Verknüpfungen basieren, sind benutzerdefinierte Kalender und Felder, die mit type: location, type: distance oder type: zipcode definiert sind.

  • Die folgenden Funktionen werden mit Analysemodellen nicht unterstützt: