derived_analytic_model

Nutzung

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

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

Definition

Bei BigQuery- und Snowflake-Verbindungen wird mit dem Parameter derived_analytic_model ein In-Database-Analysemodell (ein BigQuery-Diagramm oder eine semantische Ansicht in Snowflake) definiert, 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 LookML-Parameters derived_analytic_model 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 Unterparameter sql definieren, können Sie außerdem mit dem Unterparameter publish_as_db_analytic_model des Parameters derived_analytic_model ein stabiles Analysemodell 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 werden. 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 Unterparameter sql verwenden, dürfen Sie keine CREATE- oder CREATE OR REPLACE-Anweisung einfügen, da Looker die DDL-Anweisung zum Erstellen des Analysemodells auf der Datenbankseite automatisch generiert.

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

sql_create

Mit dem Parameter sql_create können Sie eine vollständige SQL-Anweisung zum Erstellen eines Analysemodells definieren. Wenn Sie den Parameter sql_create 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 bei der Verwendung des Unterparameters sql_create Folgendes:

  • 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 einzufügen. So wird sichergestellt, dass die SQL-Anweisung den Namen des Analysemodells, den Sie im LookML-Parameter view angeben, korrekt enthält.

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

create_process

Verwenden Sie den Parameter create_process, wenn Sie mehrere aufeinanderfolgende SQL-Anweisungen zum Definieren des Analysemodells definieren müssen. 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, wie Sie sie definieren. 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 für Ihre Datenbank finden Sie unter Abgeleitetes Analysemodell mit create_process erstellen.

publish_as_db_analytic_model

Für abgeleitete Analysemodelle, die mit dem Parameter sql erstellt werden, können Sie Ihr abgeleitetes Analysemodell mit publish_as_db_analytic_model: yes definieren, damit Looker ein stabiles Analysemodell erstellt, 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 Produktionsumgebung bereitgestellt wurde.

Im Abschnitt Auf das stabile Analysemodell zugreifen finden Sie Informationen dazu, wie Sie den Namen des stabilen Analysemodells abrufen können, damit Sie das Modell außerhalb von Looker abfragen können.

LookML-Dimensionen und ‑Measures auf Grundlage 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 zum Definieren Ihres Analysemodells und zum Verweisen auf Elemente in Ihrem Analysemodell finden Sie in der Dokumentation Ihres Dialekts. Wenn Sie beispielsweise eine LookML-Dimension aus einer BigQuery Graph-Entität erstellen möchten, müssen Sie Unterstriche verwenden, um Elemente beim Festlegen des Bereichs zu trennen. Für BigQuery Graph 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 Snowflake-Ansicht 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 sehen Sie ein Beispiel für eine LookML-Ansichtsdatei, in der ein SQL-basiertes Analysemodell für eine BigQuery-Datenbank mit dem Unterparameter sql von derived_analytic_model definiert wird. Looker erstellt das Analysemodell in der Datenbank, indem die im Parameter sql angegebenen SQL-DDL-Befehle ausgeführt werden.

Beachten Sie im Beispiel Folgendes:

  • Der Unterparameter sql enthält nur die Definition des Analysemodells selbst. Es gibt keine CREATE-Anweisung, da 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 sehen Sie ein Beispiel für eine LookML-Ansichtsdatei, in der ein SQL-basiertes Analysemodell für eine BigQuery-Datenbank mithilfe des Unterparameters create_process von derived_analytic_model definiert wird. In diesem Beispiel müssen Sie mehrere aufeinanderfolgende 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 sehen Sie ein Beispiel für eine LookML-Ansichtsdatei, in der ein SQL-basiertes Analysemodell für eine BigQuery-Datenbank mit dem Unterparameter sql_create von derived_analytic_model definiert wird. 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 Unterparameter sql erstellt und die Anweisung publish_as_db_analytic_model: yes unter dem Parameter derived_analytic_model eingefügt haben, wird das stabile Analysemodell 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 Produktionsumgebung bereitgestellt wurde.

Wenn das stabile Analysemodell veröffentlicht wird, können Sie es direkt über seinen stabilen Namen abfragen. Sie können den stabilen Namen anhand der Informationen ermitteln, die auf dem Tab SQL im Bereich Daten einer Explore-Abfrage des Analysemodells enthalten sind. So rufen Sie den stabilen Namen für ein Analysemodell ab:

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

  2. Wählen Sie im Explore beliebige 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 Graph:
      • CREATE PROPERTY GRAPH
      • SELECT ... FROM GRAPH_EXPAND('PROPERTY_GRAPH_NAME')
    • Für semantische Ansichten in 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. Geben Sie die folgenden Informationen aus der SQL-Anweisung ein, um den stabilen Namen für die Analyseansicht zu erhalten:

    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 CREATE- oder SELECT-Anweisung, vor dem „.“.
    • CONNECTION_REGISTRATION_KEY: Der Schlüssel für die Verbindungsregistrierung besteht aus zwei Zeichen. Je nach Datenbankdialekt folgt er entweder einem Dollarzeichen oder dem ersten Unterstrich im Tabellennamen in der CREATE- oder SELECT-Anweisung.
    • 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 mit dem Namen sales_analytic_model definiert und der Name des LookML-Modells ist thelook. In diesem Fall hat Looker das Analysemodell bereits erstellt, sodass es keine CREATE-Anweisung gibt. Die SELECT ... FROM GRAPH_EXPAND-Anweisung 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

Folgende Werte sind erforderlich, 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 daher:

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 Überlegungen und Einschränkungen:

  • Datentypen:Für Analysemodelle werden nur die folgenden Datentypen für Dimensionen und Messwerte unterstützt:

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

  • Messungen:

    • Basismesswerte müssen vordefiniert sein:Basismesswerte müssen im zugrunde liegenden analytischen Datenbankmodell vordefiniert sein. In Looker kann kein neuer Basismesswert definiert werden, 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 Berechnungen ohne Aggregation durchführen, bei denen vordefinierte Basismesswerte aus dem Analysemodell verwendet werden. Wenn Sie ein Measure erstellen, das auf anderen Measures basiert, können Sie das neue Measure nicht als aggregierten Measure-Typ 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) ;;
}

  • Joins:Ein Explore, dessen Basisansicht auf einem Analysemodell basiert, darf keine Joins 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 Joins:Funktionen, die auf impliziten Joins basieren, werden für Analysemodelle nicht unterstützt. Beispiele für Funktionen, die auf impliziten Joins basieren, sind benutzerdefinierte Kalender und Felder, die mit type: location, type: distance oder type: zipcode definiert sind.

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