EXPLAIN CREATE MATERIALIZED VIEW

적용 대상:확인 표시 예 Databricks SQL 확인 표시 예 Databricks Runtime 17.3 이상

물질화된 뷰에 대한 쿼리가 점진적으로 새로고침될 수 있는지 보고합니다. EXPLAIN CREATE MATERIALIZED VIEW 구체화된 뷰를 만들거나 비용이 많이 드는 새로고침을 실행하기 전에 증분화 적격성을 확인하기 위해 문장을 먼저 붙이세요.

구체화된 뷰 증분화에 대한 자세한 내용은 구체화된 뷰에 대한 증분 새로 고침을 참조하세요.

어떤 보고가 있나요 EXPLAIN

EXPLAIN CREATE MATERIALIZED VIEW 쿼리가 구조적으로 점진적 갱고침 대상인지 확인합니다. 출력 섹션은 Incremental Update Eligibility 두 가지 결과 중 하나를 보고합니다:

  • The Materialized View can be incrementally refreshed: 쿼리 패턴은 점진적 갱신을 지원합니다.
  • The Materialized View cannot be incrementally refreshed: 쿼리는 구조적으로 점진적 갱정 대상이 아닙니다. 그리고 FULL 새로고침 정책 하에서 AUTO 물질화된 뷰는 전체 재계산을 사용합니다. 또는 아래에서는 INCREMENTALINCREMENTAL STRICT점진적 새로고침이 불가능하므로 실패 CREATE 합니다. 이 섹션에는 Detailed Incrementalization Info 점진화를 방지하는 요인이 나열되어 있습니다.

구조적 적격성은 점진적 갱신이 반드시 실행된다는 보장은 아닙니다. 기본 AUTO 갱신 정책 하에서는 비용 모델이 런타임에 최종 결정을 내리며, 자격 있는 물질화된 뷰에 대해 완전한 재계산을 선택할 수 있습니다. 자세한 내용은 자격 및 실행 시 동작을 참조하세요.

EXPLAIN를 사용하는 경우

EXPLAIN CREATE MATERIALIZED VIEW를 실행합니다.

  • 새로운 물질화된 뷰를 배포하기 전에, 쿼리 패턴이 점진적 새로고침을 지원하는지 확인하세요.
  • 디버깅할 때 느린 새로고침을 하여 물질화된 뷰가 적합한지 확인하세요. 만약 그렇지 않다면, 쿼리를 다시 작성하세요.
  • 쿼리를 다시 작성한 후에는 새 버전이 적합한지 확인하세요.
  • dbt나 다른 도구에서 마이그레이션할 때, 변환된 쿼리가 점진적 새로고침의 혜택을 받는지 검증하는 것이 중요합니다.

문법

EXPLAIN [CREATE MATERIALIZED VIEW query]

매개 변수

  • 쿼리

    구체화된 뷰를 만드는 SQL 쿼리입니다. 질문을 앞에 두세요 EXPLAIN .

    비고

    CREATE MATERIALIZED VIEW Lakeflow 파이프라인의 쿼리는 업데이트 없이는 EXPLAIN 작동하지 않을 수 있습니다. 다음은 그 예입니다.

    • 쿼리에서 Expectations(CONSTRAINT...EXPECT 절)를 제거해야 합니다.
    • 원본 데이터 세트는 파이프라인의 컨텍스트에서 실행할 때 필요하지 않은 카탈로그, 스키마 또는 기타 경로로 한정되어야 할 수 있습니다.

예시

다음 예시들은 자격 있는 쿼리와 점진적으로 새로고침할 수 없는 두 쿼리의 출력을 보여줍니다.

점진적 갱도 자격이 있습니다

필터, 투영, 집계를 델타 레이크 테이블에 적용하는 쿼리는 다음과 같습니다:

EXPLAIN CREATE MATERIALIZED VIEW sales_summary AS
SELECT region, SUM(revenue) AS total_revenue, COUNT(*) AS order_count
FROM catalog.schema.orders
WHERE order_date >= '2024-01-01'
GROUP BY region;

== Incremental Update Eligibility ==
The Materialized View can be incrementally refreshed.

== Detailed Incrementalization Info ==
No issues detected.

자격 미가: 용도 LIMIT

를 사용하는 LIMIT 쿼리는 증가 가능하지 않은데, 이는 한계 연산자가 증분적으로 유지될 수 없기 때문입니다:

EXPLAIN CREATE MATERIALIZED VIEW top_customers AS
SELECT customer_id, total_spend
FROM catalog.schema.customer_summary
ORDER BY total_spend DESC
LIMIT 100;

== Incremental Update Eligibility ==
The Materialized View cannot be incrementally refreshed.

== Detailed Incrementalization Info ==
- OPERATOR_NOT_INCREMENTALIZABLE: Operators GlobalLimit, LocalLimit are not incrementalizable. Consider rewriting the query to avoid using them.

자격 미가: 델타 호수 비출처

CSV 파일과 같은 델타 호수 소스에서 읽는 쿼리는 증분이 불가능합니다:

EXPLAIN CREATE MATERIALIZED VIEW external_data AS
SELECT * FROM csv.`/path/to/files/`;

== Incremental Update Eligibility ==
The Materialized View cannot be incrementally refreshed.

== Detailed Incrementalization Info ==
- INPUT_NOT_IN_DELTA: Tables are not in Delta format. Consider converting them to Delta tables.

적합성 및 실행 시 동작

EXPLAIN 쿼리 구조가 점진적 갱신을 지원하는지 보고합니다. 옵티마이저가 런타임에 무엇을 하는지 예측하지 않습니다. 기본 REFRESH POLICY AUTO판값 하에서는 비용 모델이 최종 결정을 내리며, 예를 들어 연산자 중첩이나 현재 데이터 볼륨이 전체 재계산을 더 효율적으로 만든다고 추정할 때, 적격 물질화된 뷰에도 완전한 재계산을 선택할 수 있습니다. 전체 리프레시 정책 목록은 리프레시 정책을 참조하세요.

만약 자격이 있는 물질화된 뷰가 에 대해 일관되게 완전한 재계산 AUTO을 사용한다면, 다음과 같은 결과가 가능합니다:

  • 비용 기반 선택보다 점진적 갱신을 선호하도록 설정 REFRESH POLICY INCREMENTAL 했습니다. 문법에 대해서는 POLICY 절을 참조하세요REFRESH.
  • 파이프라인 이벤트 로그에서 이벤트 로그 INCREMENTAL_PLAN_REJECTED_BY_COST_MODEL 를 확인하여 비용 모델이 왜 증분 계획을 거부했는지 이해하세요. 자세한 내용은 파이프라인 이벤트 로그 와 CostModelRejectionSubType파이프라인 이벤트 로그 스키마의 값을 참조하세요.

일반적인 비용 모델 거부 이유는 다음과 같습니다:

  • EXCESSIVE_OPERATOR_NESTING: 쿼리 정의는 복잡하며 여러 연산자 중첩 단계를 포함하고 있는데, 비용 모델은 이를 점분 처리에 위험하다고 간주합니다.
  • CHANGESET_SIZE_THRESHOLD_EXCEEDED 그리고 TABLE_SIZE_THRESHOLD_EXCEEDED: 비용 모델은 현재 데이터 볼륨에 대해 완전한 재계산이 더 저렴하다고 추정합니다.

비용 모델 거부가 물질화된 관점이 점진화될 수 없다는 뜻은 아닙니다. 이는 최적화 담당자가 선택하지 않았다는 뜻입니다. 설정은 REFRESH POLICY INCREMENTAL 그 선택을 무시하는 데 도움이 되는 방법입니다.

  • Last updated on