derived_analytic_model

사용

# SQL-based derived analytic model
view: view_name {
  derived_analytic_model: {
    publish_as_db_analytic_model: yes | no
    sql: analytic_model_definition ;;
  }
}

# LookML-based derived analytic model
view: view_name {
  derived_analytic_model: {
    publish_as_db_analytic_model: yes | no
    model_source: explore_name {
      fields: [field_1, field_2, ...]
      join: +joined_view_name {
        foreign_key: field_name
      }
    }
  }
}
계층 구조
view
derived_analytic_model
기본값
없음

특별 규칙
분석 모델은 BigQuery 및 Snowflake 연결에서만 지원됩니다.

정의

BigQuery 및 Snowflake 연결의 경우 derived_analytic_model 매개변수는 Looker에서 관리하는 데이터베이스 내 분석 모델 (BigQuery 그래프 또는 Snowflake의 시맨틱 뷰)을 정의합니다.

파생 테이블과 달리 Looker 관리 분석 모델 객체는 데이터베이스 내에 데이터를 유지하지 않으며 증분 방식으로 새로고침되지 않습니다. 대신 데이터베이스에서 직접 관계와 측정값을 정의하는 시맨틱 모델을 나타냅니다.

Looker는 두 가지 유형의 파생 분석 모델을 지원합니다.

  • SQL 기반 파생 분석 모델: SQL 데이터 정의 언어 (DDL) 문을 사용하여 분석 모델을 정의합니다. Looker는 지정한 SQL 문을 실행하여 데이터베이스 내에 분석 모델을 생성합니다.
  • LookML 기반 파생 분석 모델: 기존 LookML Explore를 참조하여 분석 모델을 정의합니다. Looker는 Explore 토폴로지, 조인, 측정기준, 측정을 데이터베이스 네이티브 분석 모델 DDL 문으로 자동 변환하고 데이터베이스에서 모델을 생성하고 관리합니다.

SQL 기반 파생 분석 모델

SQL 기반 파생 분석 모델에서 Looker는 derived_analytic_model LookML 매개변수의 정의에 지정한 적절한 SQL 데이터 정의 언어 (DDL) 문을 실행하여 데이터베이스 내에 분석 모델을 생성합니다. derived_analytic_model 매개변수에서 정의하는 SQL 구문은 데이터베이스에서 지원해야 합니다.

SQL 기반 분석 모델을 정의하려면 derived_analytic_model 매개변수의 다음 하위 매개변수 중 하나를 사용하세요.

또한 sql 하위 매개변수로 분석 뷰를 정의하는 경우 derived_analytic_model 매개변수의 publish_as_db_analytic_model 하위 매개변수를 사용하여 Looker 외부에서 쿼리할 수 있는 안정적인 분석 모델을 만들 수 있습니다.

derived_analytic_model 매개변수 내에서 분석 모델을 정의한 후 분석 모델에 매핑되는 LookML 측정기준과 측정값을 정의할 수 있습니다. 자세한 내용은 SQL 기반 파생 분석 모델 예시 섹션을 참고하세요.

sql

분석 모델의 정의에 대한 SQL만 제공하고 Looker에서 분석 모델 생성을 관리하도록 하려면 sql 매개변수를 사용합니다. sql 하위 매개변수를 사용하는 경우 CREATE 또는 CREATE OR REPLACE 문을 포함하지 마세요. Looker가 데이터베이스 측에서 분석 모델을 생성하는 DDL 문을 자동으로 생성하기 때문입니다.

sql 매개변수를 사용하여 데이터베이스에서 분석 모델을 만드는 예는 sql로 파생 분석 모델 만들기를 참고하세요.

sql_create

sql_create 매개변수를 사용하여 분석 모델을 만드는 전체 SQL 문을 정의합니다. sql_create 매개변수를 사용하는 경우 CREATE OR REPLACE 문 (또는 해당 언어에서 CREATE OR REPLACE을 지원하지 않는 경우 CREATE 문)을 포함해야 합니다.

sql_create 하위 매개변수를 사용할 때는 다음 사항에 유의하세요.

  • BigQuery 연결의 경우 CREATE OR REPLACE 문을 사용하여 분석 모델을 만듭니다.
  • ${SQL_TABLE_NAME}을 사용하여 생성되는 분석 모델의 계산된 이름을 대체합니다. 이렇게 하면 SQL 문에 LookML view 매개변수에 제공한 분석 모델 이름이 올바르게 포함됩니다.

sql_create 매개변수를 사용하여 데이터베이스에서 분석 모델을 만드는 예는 sql_create로 파생 분석 모델 만들기를 참고하세요.

create_process

분석 모델을 정의하기 위해 순차적인 SQL 문을 여러 개 정의해야 하는 경우 create_process 매개변수를 사용합니다. create_process 매개변수에서 sql_step 하위 매개변수를 사용하여 개별 SQL 문을 지정합니다. 데이터베이스는 sql_step 문을 한 번에 하나씩 지정한 순서대로 실행합니다. Looker는 래퍼 없이 sql_step 하위 매개변수의 SQL 문을 정의된 대로 실행합니다. 즉, CREATE OR REPLACE 문이 있는 단계를 포함해야 합니다 (또는 언어에서 CREATE OR REPLACE을 지원하지 않는 경우 CREATE 문).

create_process 매개변수를 사용하여 데이터베이스에서 분석 모델을 만드는 예는 create_process로 파생 분석 모델 만들기를 참고하세요.

publish_as_db_analytic_model

sql 매개변수로 생성된 파생 분석 모델의 경우 publish_as_db_analytic_model: yes로 파생 분석 모델을 정의하여 Looker 외부에서 쿼리할 수 있는 안정적인 분석 모델을 만들도록 Looker에 요청할 수 있습니다.

파생 분석 모델의 LookML이 publish_as_db_analytic_model: yes로 프로덕션에 배포된 후 다음 Looker 재생기 주기에서 안정적인 분석 모델이 게시 (생성)됩니다.

publish_as_db_analytic_model: yes를 지정하면 Looker 재생성기가 데이터베이스에 분석 모델을 두 개 만듭니다. 하나는 내부 이름이 있고 다른 하나는 안정적인 이름이 있습니다. 그렇지 않으면 재생성기는 내부 이름을 사용하여 데이터베이스에 분석 모델을 하나만 만듭니다.

Looker 외부에서 안정적인 분석 모델을 쿼리할 수 있도록 안정적인 분석 모델의 이름을 가져오는 방법에 관한 자세한 내용은 안정적인 분석 모델 액세스 섹션을 참고하세요.

SQL 기반 분석 뷰를 기반으로 LookML 측정기준 및 측정값 만들기

분석 모델을 정의한 후 동일한 뷰 파일에서 분석 모델을 기반으로 하는 LookML 측정기준과 측정값을 정의할 수 있습니다.

분석 모델을 정의하고 분석 모델의 요소를 참조하는 데 사용할 올바른 문법에 대한 자세한 내용은 언어 문서를 참고하세요. 예를 들어 BigQuery 그래프 항목에서 LookML 측정기준을 만들려면 범위를 지정할 때 밑줄을 사용하여 요소를 구분해야 합니다. 예를 들어 BigQuery 그래프의 경우 이 LookML 측정기준은 Stores 노드 테이블의 location_id 속성을 기반으로 합니다.

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

하지만 Snowflake 시맨틱 뷰를 기반으로 하는 LookML 측정기준을 만들려면 측정항목 또는 측정기준의 정규화되지 않은 이름을 사용해야 합니다.

SQL 기반 파생 분석 모델 예시

다음 섹션에서는 derived_analytic_model의 다양한 하위 매개변수를 사용하여 분석 뷰를 만드는 예를 보여줍니다.

sql로 파생 분석 모델 만들기

다음은 derived_analytic_model의 sql 하위 매개변수를 사용하여 BigQuery 데이터베이스의 SQL 기반 분석 모델을 정의하는 LookML 뷰 파일의 예입니다. Looker는 sql 매개변수에 제공된 SQL DDL 명령어를 실행하여 데이터베이스 내에 분석 모델을 만듭니다.

예시에서 다음 사항에 유의하세요.

  • sql 하위 매개변수에는 분석 모델 자체의 정의만 포함됩니다. CREATE 문은 없습니다. sql를 사용하면 Looker가 분석 모델의 CREATE 명령어를 자동으로 처리하기 때문입니다.
  • 분석 모델은 publish_as_db_analytic_model: yes로 정의되므로 Looker는 Looker 외부에서 쿼리할 수 있는 안정적인 분석 모델을 만듭니다.
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 ;; 
  }
}

create_process로 파생 분석 모델 만들기

다음은 derived_analytic_model의 create_process 하위 매개변수를 사용하여 BigQuery 데이터베이스의 SQL 기반 분석 모델을 정의하는 LookML 뷰 파일의 예입니다. 이 예에서는 분석 모델을 정의하기 위해 순차적인 SQL 문을 여러 개 정의해야 합니다. 첫 번째 단계에서는 분석 모델이 이미 있는 경우 삭제하고 두 번째 단계에서는 분석 모델을 만듭니다.

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 ;;
  }
  
  ...
}

sql_create로 파생 분석 모델 만들기

다음은 derived_analytic_model의 sql_create 하위 매개변수를 사용하여 BigQuery 데이터베이스의 SQL 기반 분석 모델을 정의하는 LookML 뷰 파일의 예입니다. 이 예시에서 sql_create 매개변수는 분석 모델을 한 단계로 만들기 위해 실행할 전체 CREATE OR REPLACE 문을 정의합니다.

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 ;;
  }

  ...

}

안정적인 분석 모델에 액세스

sql 하위 매개변수를 사용하여 파생 분석 모델을 만들고 derived_analytic_model 매개변수 아래에 publish_as_db_analytic_model: yes 문을 포함한 경우, 파생 분석 모델의 LookML이 publish_as_db_analytic_model: yes을 사용하여 프로덕션에 배포된 후 다음 Looker 재생성기 주기에서 Looker가 안정적인 분석 모델을 게시 (생성)합니다.

안정적인 분석 모델이 게시되면 안정적인 이름을 사용하여 직접 쿼리할 수 있습니다. 분석 모델의 안정적인 이름을 가져오는 방법에는 두 가지가 있습니다.

PDT 세부정보 모달

관리자 또는 see_pdts 권한이 있는 사용자는 다음 단계에 따라 Looker의 관리 섹션에 있는 영구 파생 테이블 페이지를 사용하여 분석 모델의 안정적인 분석 모델 이름을 가져올 수 있습니다.

  1. 관리 메뉴가 아직 표시되지 않은 경우 Looker 기본 메뉴 아이콘 을 클릭하고 관리를 선택합니다. (Looker 기본 메뉴의 탐색 또는 개발 섹션에 있는 경우 뒤로 화살표를 클릭해야 관리 메뉴가 표시될 수 있습니다.)
  2. 관리자 메뉴에서 영구 파생 테이블을 선택합니다.
  3. 영구 파생 테이블 페이지에서 분석 모델의 이름을 검색합니다.
  4. 분석 모델의 점 3개 메뉴를 클릭한 다음 PDT 세부정보를 선택합니다.
  5. PDT 세부정보 모달에서 안정적인 이름 필드를 찾습니다.

안정적인 분석 모델을 직접 쿼리하려면 모델 이름 앞에 스크래치 스키마 이름을 추가합니다. 예를 들어 스크래치 스키마 이름이 tmp인 경우 다음과 같은 명령어로 안정적인 분석 모델을 쿼리할 수 있습니다.

SELECT * from tmp.PA_bq_analytic_model_sales_semantic_view

Explore의 SQL 탭

영구 파생 테이블 관리 페이지에 액세스할 수 없는 경우 분석 모델의 탐색 분석 쿼리 데이터 섹션에 있는 SQL 탭에 포함된 정보에서 안정적인 이름을 확인할 수 있습니다. 분석 모델의 안정적인 이름을 가져오려면 다음 단계를 따르세요.

  1. 분석 모델 뷰의 Explore를 엽니다.

  2. Explore의 필드 선택 도구에서 측정기준 또는 측정값을 선택합니다.

  3. 데이터 섹션의 SQL 탭을 클릭합니다.

  4. SQL 탭에서 다음 SQL 문 중 하나를 찾습니다.

    • BigQuery 그래프:
      • CREATE PROPERTY GRAPH
      • SELECT ... FROM GRAPH_EXPAND('PROPERTY_GRAPH_NAME')
    • Snowflake 시맨틱 뷰의 경우:
      • CREATE SEMANTIC VIEW
      • SELECT ... FROM SEMANTIC_VIEW_NAME

  5. 안정적인 이름은 Looker가 스크래치 스키마에 만드는 뷰로, SQL 탭에 표시된 실제 난독화된 테이블을 가리킵니다. 분석 뷰의 안정적인 이름을 가져오려면 SQL 문에서 다음 정보를 입력하세요.

    SCRATCH_SCHEMA_NAME.CONNECTION_REGISTRATION_KEY_MODEL_NAME_VIEW_NAME
    • SCRATCH_SCHEMA_NAME: 스크래치 스키마 이름은 CREATE 또는 SELECT 문구 뒤에 오는 문자열의 시작 부분으로, '.' 앞에 있습니다.
    • CONNECTION_REGISTRATION_KEY: 연결 등록 키는 두 글자이며 데이터베이스 언어에 따라 CREATE 또는 SELECT 문에 있는 테이블 이름의 달러 기호 또는 첫 번째 밑줄 뒤에 옵니다.
    • MODEL_NAME: LookML 모델의 이름입니다.
    • VIEW_NAME: 분석 모델이 정의된 뷰의 이름입니다.

예를 들어 BigQuery 연결에 대한 탐색 분석 쿼리의 SQL 탭에 표시되는 텍스트는 다음과 같습니다. 분석 모델은 sales_analytic_model라는 뷰에 정의되어 있으며 LookML 모델의 이름은 thelook입니다. 이 경우 Looker에서 이미 분석 모델을 만들었으므로 CREATE 문이 없습니다. 하지만 SELECT ... FROM GRAPH_EXPAND 문에는 테이블 이름 정보가 포함되어 있습니다.

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

분석 모델의 안정적인 이름을 도출하는 데 필요한 값은 다음과 같습니다.

  • SCRATCH_SCHEMA_NAME은 looker-test-db.looker_scratch입니다.
  • CONNECTION_REGISTRATION_KEY은 J7입니다.
  • MODEL_NAME은 thelook입니다.
  • VIEW_NAME은 sales_analytic_model입니다.

따라서 분석 모델의 안정적인 이름은 다음과 같습니다.

looker-test-db.looker_scratch.J7_thelook_sales_analytic_model

분석 모델의 안정적인 이름을 알면 분석 모델을 직접 쿼리할 수 있습니다.

LookML 기반 파생 분석 모델

LookML 기반 파생 분석 모델을 사용하면 데이터베이스별 SQL DDL 문을 작성할 필요 없이 기존 LookML 탐색에서 직접 데이터베이스 내 분석 모델 (예: BigQuery 그래프 또는 Snowflake 시맨틱 뷰)을 정의할 수 있습니다.

다음 매개변수를 사용하여 LookML 기반 파생 분석 모델을 정의합니다.

  • model_source
    • fields (model_source 하위 매개변수)
    • join (model_source의 하위 매개변수, 조인 자체에 하위 매개변수가 있음)
  • publish_as_db_analytic_model (이 매개변수는 LookML 기반 및 SQL 기반 파생 분석 모델 모두에 적용됨)

LookML 기반 파생 분석 모델을 만들려면 model_source 매개변수를 사용하여 데이터 토폴로지를 정의하는 소스 Explore를 가리킵니다. 그러면 Looker가 LookML 뷰, 조인, 측정기준, 측정값을 데이터베이스 네이티브 분석 모델 DDL 문으로 자동 변환합니다.

  • 노드 / 테이블: 소스 Explore의 각 LookML 뷰는 BigQuery 그래프의 노드 테이블 또는 Snowflake 시맨틱 뷰의 테이블이 됩니다.
  • 에지 / 관계: 소스 Explore에서 foreign_key 매개변수로 정의된 각 조인은 BigQuery 그래프의 에지 테이블 또는 Snowflake 시맨틱 뷰의 관계가 됩니다.
  • 속성 / 측정기준 및 측정항목: 소스 뷰의 LookML 측정기준 및 측정값이 BigQuery 그래프의 노드 속성 또는 Snowflake 시맨틱 뷰의 측정기준 및 측정항목이 됩니다.

LookML 기반 파생 분석 모델 뷰를 기반으로 하는 Explore를 쿼리하면 Looker가 데이터베이스 스크래치 스키마에 분석 모델을 만들기 위해 데이터베이스 DDL을 생성하고 실행한 다음 생성된 분석 모델에 대해 쿼리를 실행합니다. 분석 모델이 생성되면 Looker는 LookML 정의가 수정될 때까지 후속 쿼리가 기존 모델을 직접 참조하도록 모델을 유지합니다.

model_source

model_source 매개변수는 분석 모델의 토폴로지 및 관계 소스로 사용되는 LookML Explore의 이름을 지정합니다.

view: sales_analytic_model {
  derived_analytic_model: {
    model_source: order_items {
      fields: [order_items.id, orders.id, orders.status, users.name]
    }
  }
}

소스 Explore에 포함된 뷰에는 기본 키 측정기준에 primary_key: yes를 사용하여 정의된 기본 키가 있어야 합니다.

model_source은 다음 하위 매개변수를 허용합니다.

매개변수 설명
fields 선택사항입니다. 분석 모델로 내보낼 소스 Explore의 허용 목록 또는 차단 목록을 지정합니다.
join (또는 joins) 선택사항입니다. 분석 모델을 위해 소스 Explore의 조인을 정의하거나 구체화합니다.

fields

기본적으로 소스 Explore의 뷰에서 사용 가능한 모든 필드가 분석 모델로 내보내집니다 (소스 Explore 자체가 fields 매개변수로 정의된 경우 소스 Explore의 일부 필드를 사용하지 못할 수 있음). model_source 내에서 fields 하위 매개변수를 사용하여 내보낼 필드의 하위 집합을 지정하거나 표준 LookML 목록 문법을 사용하여 특정 필드를 제외할 수 있습니다.

  view: sales_analytic_model {
    derived_analytic_model: {
      model_source: order_items {
        fields: [
          order_items.id,
          order_items.price,
          orders.id,
          orders.status,
          users.name
        ]
      }
    }
  }

join

model_source 내의 join 매개변수를 사용하면 소스 Explore에 이미 지정된 조인에 상세검색을 추가할 수 있습니다. 상세검색을 추가하면 소스 Explore 정의를 변경하지 않고 분석 모델에만 범위가 지정된 조정을 할 수 있습니다.

model_source 아래의 join 매개변수에서 + 개선 표시기가 있는 소스 Explore의 조인 이름을 지정합니다. 예를 들면 join: +view_name입니다. 그런 다음 join 하위 매개변수를 사용하여 분석 모델에서 필요한 대로 소스 Explore의 조인을 상세검색합니다. 예시는 2단계를 참고하세요.

model_source 내의 join 매개변수는 결합 개선사항만 사용합니다. 소스 Explore에 아직 없는 새 조인을 분석 모델에 추가할 수 없습니다.

model_source 내의 join 매개변수는 다음 하위 매개변수를 지원합니다.

하위 매개변수 설명
foreign_key 분석 모델의 관계를 설정하는 외래 키 열 또는 측정기준을 지정합니다. foreign_key 매개변수가 포함된 예시는 1단계의 예시를 참고하세요.
relationship 조인 카디널리티 (many_to_one, one_to_one, one_to_many 또는 many_to_many)를 정의합니다.

LookML 기반 파생 분석 모델 설정

LookML 기반 파생 분석 모델을 설정하려면 다음 단계를 따르세요.

  1. foreign_key 조인을 사용하여 기본 뷰와 소스 Explore 정의
  2. 파생 분석 모델 뷰 만들기
  3. 분석 모델 뷰에서 LookML 측정기준 및 측정값 정의
  4. 분석 모델 뷰를 위한 Explore 만들기
  5. Looker에서 분석 모델 쿼리

1단계: foreign_key 조인을 사용하여 기본 뷰와 소스 Explore 정의

먼저 기본 뷰 (예: order_items, orders, users)가 기본 키로 정의되어 있는지 확인합니다.

다음으로 뷰 간의 관계를 지정하는 LookML 모델 파일에서 Explore를 정의합니다. 데이터베이스 내 분석 모델 내에서 관계를 빌드하려면 소스 Explore의 각 조인에 foreign_key 매개변수가 있어야 합니다.

explore: order_items {
  fields: [ALL_FIELDS*]

  join: orders {
    relationship: many_to_one
    foreign_key: order_id
  }

  join: users {
    relationship: many_to_one
    foreign_key: orders.user_id
  }
}

2단계: 파생 분석 모델 뷰 만들기

새 뷰 파일 (예: sales_analytic_model.view.lkml)을 만들고 소스 Explore를 가리키는 model_source 매개변수가 있는 derived_analytic_model 블록을 추가합니다.

view: sales_analytic_model {
  derived_analytic_model: {
    model_source: order_items {
      # Optional: Use fields to restrict the properties exported to the analytic model
      # fields: [order_items.id, orders.id, orders.status, users.name]

      # Optional: Use join refinements to refine the relationships from the source Explore
      # join: +orders {
      #   foreign_key: order_id
      # }
      # join: +users {
      #   foreign_key: orders.user_id
      # }
    }
  }
  ...

3단계: 분석 모델 뷰에서 LookML 측정기준 및 측정값 정의

동일한 분석 모델 뷰 파일에서 생성된 분석 모델의 속성에 매핑되는 측정기준, 측정기준 그룹, 측정값을 정의하여 Looker Explore에서 쿼리할 수 있도록 합니다.

${TABLE}.<view_name>_<field_name> (또는 ${TABLE}.<property_name>)를 사용하여 기본 모델의 참조 필드:

  # Dimensions
  dimension: order_items_id {
    type: number
    sql: ${TABLE}.order_items_id ;;
  }

  dimension: orders_id {
    type: number
    sql: ${TABLE}.orders_id ;;
  }

  dimension: orders_status {
    type: string
    sql: ${TABLE}.orders_status ;;
  }

  dimension_group: orders_created {
    type: time
    timeframes: [raw, time, date, week, month, quarter, year]
    sql: ${TABLE}.orders_created_at ;;
  }

  dimension: users_name {
    type: string
    sql: ${TABLE}.users_name ;;
  }

  dimension_group: users_created {
    type: time
    timeframes: [raw, time, date, week, month, quarter, year]
    sql: ${TABLE}.users_created_at ;;
  }

  # Measures
  measure: count_users {
    type: number
    sql: ${TABLE}.users_count_users ;;
  }

  measure: count_orders {
    type: number
    sql: ${TABLE}.orders_count_orders ;;
  }

  measure: total_order_amount {
    type: number
    sql: ${TABLE}.orders_total_order_amount ;;
  }

  measure: total_order_item_amount {
    type: number
    sql: ${TABLE}.order_items_total_order_item_amount ;;
  }
}

4단계: 분석 모델 뷰의 Explore 만들기

모델 파일 (예: sales.model.lkml)에서 뷰 이름을 사용하여 분석 모델 뷰의 Explore를 만듭니다.

explore: sales_analytic_model {}

분석 모델 뷰를 기반으로 하는 Explore에는 조인이 포함될 수 없습니다. 관계가 분석 모델 자체 내에서 내부적으로 정의되기 때문입니다.

5단계: Looker에서 분석 모델 쿼리

Looker에서 새 Explore (예: Sales Analytic Model)을 열고 측정기준과 측정값을 선택한 후 쿼리를 실행합니다.

생성된 SQL을 검사하려면 다음 단계를 따르세요.

  1. 데이터 패널에서 SQL 탭을 클릭합니다.
  2. SQL 탭에서는 Looker에서 생성하는 데이터베이스별 DDL 문 (예: BigQuery 그래프의 경우 NODE TABLES 및 EDGE TABLES이 있는 CREATE PROPERTY GRAPH ...)과 분석 모델에 대해 실행되는 쿼리 (예: FROM GRAPH_EXPAND(...) AS sales_analytic_model)를 볼 수 있습니다.
  3. 쿼리가 실행되면 Looker는 데이터베이스 스크래치 스키마에 분석 모델을 유지합니다. 후속 쿼리는 지속된 모델을 재사용하므로 LookML 정의가 변경될 때까지 DDL 재실행을 방지합니다.

LookML 기반 파생 분석 모델 고려사항

LookML 기반 파생 분석 모델을 정의할 때는 다음 고려사항에 유의하세요.

  • 기본 키: 소스 Explore의 모든 뷰에는 primary_key: yes를 사용하여 정의된 기본 키 측정기준이 있어야 합니다.
  • 비순환 토폴로지: 소스 Explore의 조인으로 정의된 관계는 엄격한 비순환 트리 구조를 형성해야 합니다. 순환 관계는 지원되지 않습니다.
  • 소스 뷰 요구사항: 소스 Explore에 포함된 뷰는 안정적인 이름이 있는 표준 데이터베이스 테이블 또는 영구 파생 테이블 (PDT)이어야 합니다. 다른 분석 모델을 기반으로 하는 임시 (비영구) 파생 테이블 및 뷰는 소스로 사용할 수 없습니다.
  • Explore 매개변수: 분석 모델 생성 중에 소스 Explore의 동적 런타임 필터링 매개변수 (sql_always_where, always_filter, access_filter)와 sql_always_join가 무시됩니다.

고려사항

인 데이터베이스 분석 모델을 사용할 때는 다음 고려사항과 제한사항에 유의하세요.

  • 데이터 유형: 분석 모델에서는 측정기준 및 측정값에 다음 데이터 유형만 지원됩니다.

    • 측정기준 및 측정값에 지원됨:
      • string
      • number
      • date
      • yesno
    • 측정기준에만 지원됩니다.
      • time
      • date_time

  • 측정:

    • 기본 측정값이 사전 정의되어야 함: 기본 측정값은 기본 데이터베이스 분석 모델에 사전 정의되어야 합니다. Looker는 분석 모델의 측정기준에 집계 (예: type: sum 또는 type: count)를 실행하여 새 기본 측정값을 정의할 수 없습니다.

    • 다른 측정값을 기반으로 하는 측정값 지원: LookML 측정값의 sql 파라미터를 사용하여 분석 모델의 사전 정의된 기본 측정값을 사용하는 비집계 계산을 실행할 수 있습니다. 다른 측정값을 기반으로 하는 측정값을 만들 때 새 측정값을 sum 또는 count과 같은 집계 측정값 유형으로 정의할 수 없습니다. 새 측정항목을 string, number, date, yesno과 같은 비집계 측정항목 유형으로 정의해야 합니다. 아래 예시를 참조하세요.

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

  • 조인: 분석 모델을 기반으로 하는 기본 뷰가 있는 Explore에는 조인이 포함될 수 없습니다. 마찬가지로 분석 모델을 기반으로 하는 뷰는 표준 LookML 기본 뷰가 있는 Explore에 조인할 수 없습니다.

  • 암시적 조인: 암시적 조인을 사용하는 기능은 분석 모델에서 지원되지 않습니다. 암시적 조인을 사용하는 기능의 예로는 맞춤 캘린더와 type: location, type: distance 또는 type: zipcode로 정의된 필드가 있습니다.

  • 분석 모델에서 지원되지 않는 기능은 다음과 같습니다.