구체화된 refresh의 증분 views
이 문서에서는 구체화된 views대한 증분 새로 고침에 대한 의미 체계 및 요구 사항을 간략하게 설명하고 증분 refresh지원하는 SQL 작업, 키워드 및 절을 식별합니다. 여기에는 증분 새로 고침과 전체 새로 고침 간의 차이점에 대한 설명이 포함되며 구체화된 views 및 스트리밍 tables중에서 선택하기 위한 권장 사항이 포함되어 있습니다.
서버리스 파이프라인을 사용하여 물질화된 views의 업데이트를 실행할 때, 많은 쿼리를 증분적으로 새로 고칠 수 있습니다. 증분 새로 고침은 구체화된 뷰를 정의하는 데 사용되는 데이터 원본의 변경 내용을 검색하고 결과를 증분 방식으로 계산하여 컴퓨팅 비용을 절감합니다.
증분 refresh 서버리스 파이프라인이 필요합니다.
구체화된 refresh에 대한 증분 views는 서버리스 파이프라인이 필요합니다.
Databricks SQL에 정의된 구체화된 Refresh에 대한 views 작업은 항상 서버리스 파이프라인을 사용해 실행됩니다.
Delta Live views 파이프라인을 사용하여 정의된 구체화된 Tables에 대해, 서버리스를 사용하기 위해 해당 파이프라인을 구성해야 합니다. 서버리스 Delta Live 파이프라인
구체화된 refresh에 대한 views 의미 체계는 무엇인가요?
구체화된 views는 일괄 쿼리와 동등한 결과를 보장합니다. 예를 들어 다음 집계 쿼리를 고려합니다.
SELECT account_id,
COUNT(txn_id) txn_count,
SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id
Azure Databricks 제품을 사용하여 이 쿼리를 실행하면 결과가 일괄 처리 의미 체계를 사용하여 계산되어 원본 transactions_table의 모든 레코드를 집계합니다. 즉, 모든 원본 데이터가 한 번의 작업으로 검색되고 집계됩니다.
참고 항목
일부 Azure Databricks 제품은 마지막 쿼리가 실행된 후 데이터 원본이 변경되지 않은 경우 세션 내에서 또는 세션 간에 결과를 자동으로 캐시합니다. 자동 캐싱 동작은 구체화된 views과 다릅니다.
다음 예제에서는 이 일괄 처리 쿼리를 구체화된 뷰로 바꿉니다.
CREATE OR REPLACE MATERIALIZED VIEW transation_summary AS
SELECT account_id,
COUNT(txn_id) txn_count,
SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id
구체화된 뷰를 refresh할 경우, 계산된 결과는 배치 쿼리 의미 체계와 동일합니다. 이 쿼리는 증분 방식으로 새로 고칠 수 있는 구체화된 뷰의 예입니다. 즉, refresh 작업은 결과를 계산하기 위해 원본 transactions_table 새 데이터 또는 변경된 데이터만 처리하는 데 최선의 노력을 기울입니다.
구체화된 views를 위한 데이터 소스 고려 사항
데이터 원본에 대해 물리적 views뷰를 정의할 수 있지만 모든 데이터 원본이 다 물리적 뷰에 적합하지는 않습니다. 다음 주의 사항 및 권장 사항을 고려합니다.
Important
구체화된 views은 지원되는 작업의 결과를 증분적으로 refresh기 위해 최선을 다합니다. 데이터 원본의 일부 변경 내용에는 전체 refresh필요합니다.
구체화된 뷰를 정의하는 쿼리가 증분 views를 지원하는 경우에도, 구체화된 refresh의 모든 데이터 원본은 전체 refresh 의미 체계에 강력해야 합니다.
- 비용이 많이 드는 전체 where 쿼리에 대해 refresh을(를) 사용하는 대신, 스트리밍 tables를 사용하여 정확히 한 번 처리를 보장합니다. 예를 들어 매우 큰 tables가 포함됩니다.
- 레코드를 한 번만 처리해야 하는 경우 데이터 원본에 대해 구체화된 뷰를 정의하지 마세요. 대신 스트리밍 tables사용합니다. 예를 들면 다음과 같습니다.
- 데이터 기록을 유지하지 않는 데이터 원본(예: Kafka)입니다.
- 자동 로더를 사용하여 클라우드 개체 스토리지에서 데이터를 수집하는 쿼리와 같은 수집 작업
- 처리 후 데이터를 삭제하거나 보관할 계획이지만 다운스트림 where의 정보를 유지해야 하는 데이터 원본 tables. 예를 들어, 특정 임계값보다 오래된 레코드를 삭제하려는 경우, 날짜로 분할된 tablewhere.
- 모든 데이터 원본이 증분 새로 고침을 지원하는 것은 아닙니다. 다음 데이터 원본은 점진적인 refresh을 지원합니다.
- Unity tables 관리되는 Catalog 및 Delta Lake에서 지원되는 외부 tables 포함하여 델타 tables.
- 구체화된 views.
-
tables 작업의 대상, 스트리밍
APPLY CHANGES INTO을 포함하여.
- 일부 증분 refresh 작업은 쿼리된 데이터 원본에서 행 추적을 사용하도록 설정해야 합니다. Delta Lake 기능 중 행 추적은 구체화된 tables, 스트리밍 views, Unity tables가 관리하는 Catalog를 포함하는 Delta tables에서만 지원됩니다. 참조하세요 델타 tables행 추적 사용.
구체화된 Optimizeviews
최상의 성능을 get 위해 Databricks는 구체화된 모든 뷰 원본 tables다음 기능을 사용하도록 설정하는 것이 좋습니다.
구체화된 Refresh에 대한 views 형식
구체화된 형태의 views의 갱신은 전체 갱신 또는 점진적 갱신입니다. 모든 작업에 대해 증분 refresh의 결과와 전체 refresh의 결과는 동일합니다. Azure Databricks는 비용 분석을 실행하여 데이터 원본을 변경하려면 전체 refresh필요한지 확인합니다.
어떤 refresh 유형의 update이 사용되었는지 알아보려면 update의 유형을 확인하십시오.
전체 refresh
완전한 refresh는 원본에서 사용할 수 있는 모든 데이터를 다시 처리하여 구체화된 뷰의 결과를 덮어씁니다. 구체화된 모든 views 데이터 원본이 변경된 방식에 따라 지정된 update완전히 새로 고칠 수 있습니다.
필요에 따라 refresh을(를) 완전히 강제로 적용할 수 있습니다. Databricks SQL을 사용하여 정의된 구체화된 views 경우 다음 구문을 사용합니다.
REFRESH MATERIALIZED VIEW mv_name FULL
Delta Live views 파이프라인에 정의된 구체화된 Tables의 경우, 선택한 데이터 세트에 대해 또는 파이프라인 내의 모든 데이터 세트에 대해 전체 refresh를 실행하도록 선택할 수 있습니다. 파이프라인 refresh 의미 체계참조하세요.
Important
데이터 원본 refresh에 대해 전체 where가 실행될 때, 데이터 보존 임계값 또는 수동 삭제로 인해 제거된 레코드는 계산 결과에 반영되지 않습니다. 데이터가 더 이상 원본에 남아 있지 않으면 이전 데이터를 복구하지 못할 수 있습니다.
참고 항목
필요에 따라 table 속성 table을(를) pipelines.reset.allowed로 설정하여 false의 전체 새로 고침 기능을 비활성화할 수 있습니다.
증분 refresh
증분 refresh은 마지막 refresh 이후 기본 데이터의 변경 사항을 처리한 후, 해당 데이터를 table에 추가합니다. 기본 tables 및 포함된 작업에 따라, 구체화된 views의 특정 유형만을 증분 방식으로 새로 고칠 수 있습니다.
서버리스 파이프라인을 사용하여 업데이트된 구체화된 views만 증분 refresh을 사용할 수 있습니다. 서버리스 파이프라인을 사용하지 않는 구체화된 views는 항상 완전히 새로 고침됩니다.
SQL 웨어하우스 또는 서버리스 Delta Live views 파이프라인을 사용하여 구체화된 Tables이 생성되면, 쿼리가 지원되는 경우 자동으로 증분 새로 고침이 이루어집니다. 쿼리에 증분 refresh에 대한 지원되지 않는 식이 포함된 경우 전체 refresh이 수행되어 추가 비용이 발생할 수 있습니다.
구체화된 뷰 증분에 대한 지원 refresh
다음 table은 SQL 키워드 또는 절에 의한 증분 refresh에 대한 지원 목록입니다.
Important
일부 키워드 및 절은 쿼리된 데이터 원본에서 행 추적을 사용하도록 설정해야 합니다. 참조하세요 델타 tables행 추적 사용.
이러한 키워드와 구문은 다음 table에서 별표(*)로 표시됩니다.
| SQL 키워드(keyword) 또는 절 | 증분 refresh 지원 |
|---|---|
SELECT 식* |
예, 결정적 기본 제공 함수 및 변경할 수 없는 UDF(사용자 정의 함수)를 포함한 식이 지원됩니다. |
GROUP BY |
예 |
WITH |
예, 일반적인 table 표현식이 지원됩니다. |
UNION ALL* |
예 |
FROM |
지원되는 기본 tables 델타 tables, 구체화된 views및 스트리밍 tables포함됩니다. |
WHERE, HAVING* |
필터 절(예: WHERE 및 HAVING)이 지원됩니다. |
INNER JOIN* |
예 |
LEFT OUTER JOIN* |
예 |
FULL OUTER JOIN* |
예 |
RIGHT OUTER JOIN* |
예 |
OVER |
예.
PARTITION_BY 함수의 증분화에는 columnswindow 지정해야 합니다. |
QUALIFY |
예 |
EXPECTATIONS |
아니요. 구체화된 views는 예상값을 사용하여 항상 완전히 갱신됩니다. |
참고 항목
비결정적 함수(예: CURRENT_TIMESTAMP)는 지원되지 않습니다.
refresh의 update 형식 확인
구체화된 뷰 새로 고침의 성능을 optimize하기 위해, Azure Databricks는 select에 사용되는 기술을 refresh하기 위해 비용 모델을 사용합니다. 다음 table 이러한 기술에 대해 설명합니다.
| 기법 | 점진적인 refresh? | 설명 |
|---|---|---|
FULL_RECOMPUTE |
아니요 | 구체화된 뷰가 완전히 다시 계산되었습니다. |
NO_OP |
해당 없음 | 기본 table 변경 내용이 검색되지 않아 구체화된 뷰가 업데이트되지 않았습니다. |
ROW_BASED 또는 PARTITION_OVERWRITE |
예 | 구체화된 뷰는 지정된 기술을 사용하여 증분 방식으로 새로 고쳐집니다. |
사용된 기술을 결정하려면 Delta Live Tables 이벤트 로그에 where가 event_type일 때 planning_information을 쿼리하십시오.
SELECT
timestamp,
message
FROM
event_log(TABLE(<fully-qualified-table-name>))
WHERE
event_type = 'planning_information'
ORDER BY
timestamp desc;
<fully-qualified-table-name>을(를) catalog 및 schema가 포함된 구체화된 뷰의 정규화된 이름으로 바꿉니다.