비동기 구체화된 뷰 FAQ
이 문서는 비동기 구체화된 뷰를 사용할 때 자주 발생하는 질문과 문제 해결 방법을 정리합니다. 한 문장으로 정의하면, 비동기 구체화된 뷰는 기본 테이블 데이터를 기반으로 필요할 때 또는 일정에 따라 새로 고치는 사전 계산 결과 집합이며, 쿼리를 투명하게 재작성하여 가속하는 데 사용할 수 있습니다.
빠른 탐색
문제는 사용 단계에 따라 두 범주로 나누었으며, 부록에는 원인 참조 표를 제공합니다.
| 시나리오 범주 | 다루는 문제 | 키워드 |
|---|---|---|
| 생성 및 새로 고침 | 생성 오류, 새로 고침 전략, 스키마 변경, 리소스 사용량 | BUILD, REFRESH, workload_group |
| 쿼리 및 투명 재작성 | 구체화된 뷰 적용 여부, 미적용 원인, 사용 불가 상태 | explain, MaterializedViewRewrite, grace_period |
| 부록 | 투명 재작성 실패 원인 표, 파티션 생성 실패 원인 표 | 요약 참조 표 |
일반적인 문제를 빠르게 찾아보려면 다음 목록을 확인하세요.
- 파티션 구체화된 뷰를 생성할 때
Unable to find a suitable base table for partitioning오류가 발생하면 Q12와 부록 2를 참조하세요. - 생성 문에서
Syntax error가 보고되면 Q13을 참조하세요. - 새로 고침에 성공했지만 구체화된 뷰에 데이터가 없으면 Q14를 참조하세요.
- 파티션 구체화된 뷰가 매번 전체 새로 고침을 수행하면 Q15를 참조하세요.
- 투명 재작성이 적용되지 않으면 쿼리 및 투명 재작성 Q1/Q2와 부록 1을 참조하세요.
생성 및 새로 고침
Q1: 구체화된 뷰는 새로 고칠 파티션을 어떻게 결정하나요?
Doris는 내부적으로 구체화된 뷰와 기본 테이블 간의 파티션 매핑을 계산하고, 마지막으로 성공한 새로 고침에 사용된 기본 테이블 파티션의 버전을 기록합니다. 다음 새로 고침에서는 현재 버전과 비교하여 파티션을 새로 고쳐야 하는지 결정합니다.
예시: 구체화된 뷰 mv1은 기본 테이블 t1과 t2에서 생성되며, t1을 기준으로 파티션이 구성됩니다. 파티션 p202003(mv1에 속함)이 파티션 p20200301과 p20200302(t1에 속함)에 대응한다고 가정합니다.
p202003을 새로 고친 후에는p20200301,p20200302및 테이블t2의 현재 버전을 기록합니다.- 다음 새로 고침 시
p20200301,p20200302또는t2의 버전이 변경되었다면p202003을 새로 고쳐야 합니다.
업무 요건에 따른 제외: 업무 관점에서 t2의 변경이 mv1의 새로 고침을 트리거하지 않아야 한다면, 구체화된 뷰 속성 excluded_trigger_tables로 이를 설정할 수 있습니다.
Q2: 구체화된 뷰가 리소스를 너무 많이 사용하여 다른 워크로드에 영향을 주면 어떻게 하나요?
구체화된 뷰 속성으로 workload_group을 지정하여 구체화된 뷰 새로 고침 작업의 리소스 사용량을 제어할 수 있습니다.
주의 사항: 메모리 설정이 너무 작고 단일 파티션 새로 고침에 그보다 많은 메모리가 필요하면 새로 고침 작업이 실패합니다. 업무 요구 사항에 맞게 설정을 조정하세요.
Q3: 기존 구체화된 뷰를 기반으로 새 구체화된 뷰를 생성할 수 있나요?
예. Doris 2.1.3부터 지원됩니다.
참고: 각 구체화된 뷰의 새로 고침 로직은 독립적입니다. 예를 들어 mv2가 mv1을 기반으로 생성되고, mv1이 t1을 기반으로 생성된 경우, mv2를 새로 고칠 때는 mv1과 t1 간의 데이터가 동기화되어 있는지 고려하지 않습니다.
Q4: Doris는 어떤 외부 테이블에서 구체화된 뷰를 지원하나요?
Doris가 지원하는 모든 외부 테이블을 사용하여 구체화된 뷰를 생성할 수 있습니다. 다만 현재 파티션 새로 고침은 Hive에서만 지원됩니다. 다른 유형은 향후 릴리스에서 지원될 예정입니다.
Q5: 구체화된 뷰가 Hive 데이터와 일치하는 것처럼 보이지만 실제로는 일치하지 않습니다
구체화된 뷰는 Catalog를 통해 조회한 결과와 데이터가 일치한다는 것만 보장할 수 있습니다.
Catalog에는 일부 메타데이터와 데이터 캐시가 있으므로, 구체화된 뷰를 Hive 데이터와 일치시키려면 Refresh Catalog 등의 방법으로 Catalog의 데이터가 Hive의 데이터와 일치하도록 해야 합니다.
Q6: 구체화된 뷰는 Schema Change를 지원하나요?
수정은 지원되지 않습니다. 구체화된 뷰의 열 속성은 뷰를 정의하는 SQL에서 추론되며, 현재 사용자가 명시적으로 수정하는 기능은 지원되지 않습니다.
Q7: 구체화된 뷰에서 사용하는 기본 테이블에 Schema Change를 수행할 수 있나요?
예. 다만 수정 후에는 다음과 같은 상태 변경이 발생합니다.
- 이 기본 테이블을 사용하는 모든 구체화된 뷰의 상태가
NORMAL에서SCHEMA_CHANGE로 변경됩니다. SCHEMA_CHANGE상태에서는 구체화된 뷰를 투명 재작성에 사용할 수 없지만, 구체화된 뷰를 직접 쿼리하는 것은 여전히 가능합니다.- 구체화된 뷰의 다음 새로 고침 작업이 성공하면 상태가
SCHEMA_CHANGE에서NORMAL로 돌아갑니다.
Q8: Unique Key 모델의 테이블로 구체화된 뷰를 생성할 수 있나요?
예. 구체화된 뷰는 기본 테이블의 데이터 모델에 제한을 두지 않지만, 구체화된 뷰 자체는 Duplicate Key 모델만 사용할 수 있습니다.
Q9: 구체화된 뷰에도 인덱스를 생성할 수 있나요?
예.
Q10: 구체화된 뷰를 새로 고칠 때 테이블이 잠기나요?
새로 고침 프로세스는 아주 짧은 단계에서만 테이블을 잠그며, 테이블 잠금을 계속 유지하지는 않습니다. 잠금 시간은 데이터를 적재할 때의 잠금 시간과 대략 비슷합니다.
Q11: 구체화된 뷰는 준실시간 시나리오에 적합한가요?
적합하지 않은 편입니다. 구체화된 뷰의 최소 새로 고침 단위는 파티션이므로 데이터가 많으면 상당한 리소스를 사용하며, 데이터 최신성도 충분하지 않습니다. 대신 동기 구체화된 뷰나 다른 방법을 권장합니다.
Q12: 파티션 구체화된 뷰 생성 시 오류
오류 메시지:
Unable to find a suitable base table for partitioning
원인 분석:
일반적으로 구체화된 뷰의 SQL 정의와 선택한 파티션 열로는 파티션 증분 갱신을 수행할 수 없어, 파티션 구체화된 뷰를 생성할 때 오류가 발생합니다.
- 구체화된 뷰에서 파티션 증분 갱신을 수행하려면 관련 요구 사항을 충족해야 합니다. 자세한 내용은 구체화된 뷰 새로 고침 모드를 참조하세요.
- 최신 버전에서는 파티션 생성 실패의 구체적인 원인을 보고할 수 있습니다. 원인과 설명을 요약한 내용은 부록 2를 참조하세요.
예시:
아래의 두 기본 테이블은 orders(파티션 있음)와 lineitem(파티션 없음)입니다.
CREATE TABLE IF NOT EXISTS orders (
o_orderkey INTEGER NOT NULL,
o_custkey INTEGER NOT NULL,
o_orderstatus CHAR(1) NOT NULL,
o_totalprice DECIMALV3(15, 2) NOT NULL,
o_orderdate DATE NOT NULL,
o_orderpriority CHAR(15) NOT NULL,
o_clerk CHAR(15) NOT NULL,
o_shippriority INTEGER NOT NULL,
O_COMMENT VARCHAR(79) NOT NULL
) DUPLICATE KEY(o_orderkey, o_custkey) PARTITION BY RANGE(o_orderdate) (
FROM
('2024-05-01') TO ('2024-06-30') INTERVAL 1 DAY
) DISTRIBUTED BY HASH(o_orderkey) BUCKETS 3;
CREATE TABLE IF NOT EXISTS lineitem (
l_orderkey INTEGER NOT NULL,
l_partkey INTEGER NOT NULL,
l_suppkey INTEGER NOT NULL,
l_linenumber INTEGER NOT NULL,
l_quantity DECIMALV3(15, 2) NOT NULL,
l_extendedprice DECIMALV3(15, 2) NOT NULL,
l_discount DECIMALV3(15, 2) NOT NULL,
l_tax DECIMALV3(15, 2) NOT NULL,
l_returnflag CHAR(1) NOT NULL,
l_linestatus CHAR(1) NOT NULL,
l_shipdate DATE NOT NULL,
l_commitdate DATE NOT NULL,
l_receiptdate DATE NOT NULL,
l_shipinstruct CHAR(25) NOT NULL,
l_shipmode CHAR(10) NOT NULL,
l_comment VARCHAR(44) NOT NULL
) DUPLICATE KEY(
l_orderkey, l_partkey, l_suppkey,
l_linenumber
) DISTRIBUTED BY HASH(l_orderkey) BUCKETS 3;
구체화된 뷰는 다음과 같이 정의됩니다. 파티션 열로 orders.o_orderdate를 선택하면 파티션 증분 갱신이 지원되지만, lineitem.l_shipdate를 사용하면 증분 갱신을 수행할 수 없습니다.
CREATE MATERIALIZED VIEW mv_1
BUILD IMMEDIATE
REFRESH AUTO ON MANUAL
partition by(o_orderdate)
DISTRIBUTED BY RANDOM BUCKETS 2
AS
SELECT
l_linestatus,
sum(
l_extendedprice * (1 - l_discount)
) AS revenue,
o_orderdate,
o_shippriority
FROM
orders
LEFT JOIN lineitem ON l_orderkey = o_orderkey
WHERE
o_orderdate <= DATE '2024-06-30'
AND o_orderdate >= DATE '2024-05-01'
GROUP BY
l_linestatus,
o_orderdate,
o_shippriority;
lineitem.l_shipdate를 파티션 열로 선택할 수 없는 이유:
lineitem.l_shipdate는 기본 테이블의 파티션 열이 아닙니다. 실제로lineitem테이블에는 파티션 열이 설정되어 있지 않습니다.lineitem.l_shipdate는null값을 생성하는 쪽에 있는 열입니다(outer join연산 기준).
Q13: 구체화된 뷰 생성 시 구문 오류
오류 메시지:
ERROR 1105 (HY000): errCode = 2, detailMessage = Syntax error in line 1:
BUILD IMMEDIATE REFRESH AUTO ON MANUAL
가능한 원인:
-
비동기 구체화된 뷰 구문은 새 옵티마이저에서만 지원됩니다. 새 옵티마이저를 사용 중인지 확인하세요.
SET enable_nereids_planner = true; -
구체화된 뷰를 생성하는 문에 키워드 오타가 있거나 뷰를 정의하는 SQL에 구문 오류가 있습니다. 구체화된 뷰를 정의하는 SQL과 생성 문이 올바른지 확인하세요.
Q14: 새로 고침에 성공했지만 구체화된 뷰에 여전히 데이터가 없습니다
구체화된 뷰가 데이터를 갱신해야 하는지 판단하려면 기본 테이블 또는 해당 파티션의 버전 정보를 가져올 수 있어야 합니다.
현재 버전 정보 가져오기를 지원하지 않는 데이터 레이크(예: JDBC Catalog)의 경우, 새로 고침 과정에서 구체화된 뷰를 갱신할 필요가 없는 것으로 처리합니다. 따라서 이러한 구체화된 뷰를 생성하거나 새로 고칠 때는 complete를 지정하고 auto는 사용하지 않아야 합니다.
데이터 레이크에 대한 구체화된 뷰 지원 현황은 데이터 레이크 지원을 참조하세요.
Q15: 파티션 구체화된 뷰가 매번 전체 새로 고침을 수행하는 이유는 무엇인가요?
구체화된 뷰의 파티션 증분 새로 고침은 기본 테이블 파티션의 버전 정보에 의존합니다. 구체화된 뷰 파티션에 대응하는 기본 테이블 파티션 데이터가 마지막 새로 고침 이후 변경되었다면 해당 파티션만 새로 고칩니다.
가능한 원인:
구체화된 뷰를 정의하는 SQL에서 파티션 추적 대상이 아닌 테이블의 데이터가 변경되어, 새로 고칠 파티션을 판단할 수 없으므로 전체 새로 고침만 가능합니다.
예시:
이 구체화된 뷰는 o_orderdate 파티션을 추적하며, 이 파티션은 orders 테이블에 속합니다. 그러나 lineitem 또는 partsupp 데이터가 변경되면 구체화된 뷰는 갱신할 파티션을 판단할 수 없어 전체 새로 고침만 수행할 수 있습니다.
CREATE MATERIALIZED VIEW partition_mv
BUILD IMMEDIATE
REFRESH AUTO
ON SCHEDULE EVERY 1 DAY STARTS '2024-12-01 20:30:00'
PARTITION BY (DATE_TRUNC(o_orderdate, 'MONTH'))
DISTRIBUTED BY HASH (l_orderkey) BUCKETS 2
PROPERTIES
("replication_num" = "3")
AS
SELECT
o_orderdate,
l_orderkey,
l_partkey
FROM
orders
LEFT JOIN lineitem ON l_orderkey = o_orderkey
LEFT JOIN partsupp ON ps_partkey = l_partkey
and l_suppkey = ps_suppkey;
문제 해결 단계:
-
목표: 구체화된 뷰가 추적하는 기본 테이블과 파티션 열을 확인합니다.
-
명령:
SELECT *
FROM mv_infos('database'='db_name')
WHERE Name = 'partition_mv' \G -
설명: 결과에서
MvPartitionInfo.partitionType이FOLLOW_BASE_TABLE이면 구체화된 뷰의 파티션이 기본 테이블의 파티션을 따른다는 의미입니다.relatedCol이o_orderdate이면 이 열을 기준으로 파티션을 구성한다는 의미입니다.Id: 1752809156450
Name: partition_mv
JobName: inner_mtmv_1752809156450
State: NORMAL
SchemaChangeDetail:
RefreshState: SUCCESS
RefreshInfo: BUILD IMMEDIATE REFRESH AUTO ON SCHEDULE EVERY 1 DAY STARTS "2024-12-01 20:30:00"
QuerySql: SELECT
`internal`.`doc_db`.`orders`.`o_orderdate`,
`internal`.`doc_db`.`lineitem`.`l_orderkey`,
`internal`.`doc_db`.`lineitem`.`l_partkey`
FROM
`internal`.`doc_db`.`orders`
LEFT JOIN `internal`.`doc_db`.`lineitem` ON `internal`.`doc_db`.`lineitem`.`l_orderkey` = `internal`.`doc_db`.`orders`.`o_orderkey`
LEFT JOIN `internal`.`doc_db`.`partsupp` ON `internal`.`doc_db`.`partsupp`.`ps_partkey` = `internal`.`doc_db`.`lineitem`.`l_partkey`
and `internal`.`doc_db`.`lineitem`.`l_suppkey` = `internal`.`doc_db`.`partsupp`.`ps_suppkey`
MvPartitionInfo: MTMVPartitionInfo{partitionType=EXPR, relatedTable=orders, relatedCol='o_orderdate', partitionCol='o_orderdate'}
SyncWithBaseTables: 1
해결 방법:
lineitem 또는 partsupp 테이블의 데이터 변경이 구체화된 뷰에 영향을 주지 않는다면, excluded_trigger_tables 속성을 설정하여 이러한 테이블의 변경으로 트리거되는 전체 새로 고침을 제외할 수 있습니다.
ALTER MATERIALIZED VIEW partition_mv set("excluded_trigger_tables"="lineitem,partsupp");
쿼리 및 투명 재작성
Q1: 쿼리에 구체화된 뷰가 적용되는지 확인하는 방법
explain query_sql을 사용하여 구체화된 뷰 적용 상태의 요약을 확인할 수 있습니다.
구체화된 뷰 예시:
CREATE MATERIALIZED VIEW mv11
BUILD IMMEDIATE REFRESH AUTO ON MANUAL
partition by(l_shipdate)
DISTRIBUTED BY HASH(l_orderkey) BUCKETS 10
AS
SELECT l_shipdate, l_orderkey, O_ORDERDATE, count(*)
FROM lineitem
LEFT OUTER JOIN orders on l_orderkey = o_orderkey
GROUP BY l_shipdate, l_orderkey, O_ORDERDATE;
explain 실행:
explain
SELECT l_shipdate, l_orderkey, O_ORDERDATE, count(*)
FROM lineitem
LEFT OUTER JOIN orders on l_orderkey = o_orderkey
GROUP BY l_shipdate, l_orderkey, O_ORDERDATE;
결과 해석:
구체화된 뷰 적용 정보는 실행 계획의 마지막 부분에 있습니다. 주요 필드의 의미는 다음과 같습니다.
| 필드 | 의미 |
|---|---|
MaterializedViewRewriteSuccessAndChose | 투명 재작성에 성공하고 CBO가 최종적으로 사용하도록 선택한 구체화된 뷰 이름 목록 |
MaterializedViewRewriteSuccessButNotChose | 투명 재작성에 성공했지만 CBO가 선택하지 않은 구체화된 뷰 이름 목록(실행 계획에서 사용하지 않음) |
MaterializedViewRewriteFail | 투명 재작성에 실패한 구체화된 뷰와 원인 요약 목록 |
MaterializedView 관련 정보가 explain 끝부분에 나타나지 않는다면 구체화된 뷰가 사용 불가 상태이므로 투명 재작성에 참여할 수 없습니다. 구체화된 뷰가 사용 불가 상태가 되는 상황은 사용 및 실습 - 구체화된 뷰 상태 확인을 참조하세요.
출력 예시:
| MaterializedView |
| MaterializedViewRewriteSuccessAndChose: |
| internal#regression_test_nereids_rules_p0_mv#mv11, |
| |
| MaterializedViewRewriteSuccessButNotChose: |
| |
| MaterializedViewRewriteFail: |
+------------------------------------------------------------------------------------+
Q2: 구체화된 뷰가 적용되지 않는 이유는 무엇인가요?
먼저 Q1에 따라 구체화된 뷰가 적용되었는지 확인하세요.
explain
your_query_sql;
적용되지 않는 가능한 이유:
- Doris 2.1.3 이전 버전에서는 구체화된 뷰의 투명 재작성 기능이 기본적으로 비활성화되어 있습니다. 투명 재작성이 작동하려면 해당 스위치를 켜야 합니다. 구체적인 스위치는 비동기 구체화된 뷰 관련 스위치를 참조하세요.
- 구체화된 뷰가 사용 불가 상태일 수 있습니다. 구체화된 뷰의 생성 상태를 확인하려면 구체화된 뷰 상태 확인을 참조하세요.
- 앞의 두 항목을 확인한 후에도 적용되지 않는다면, 구체화된 뷰를 정의하는 SQL과 쿼리 SQL이 현재 투명 재작성 기능의 지원 범위를 벗어났을 수 있습니다. 자세한 내용은 구체화된 뷰 투명 재작성 기능을 참조하세요.
- 적용 실패에 대한 자세한 요약 정보와 설명은 부록 1을 참조하세요.
아래의 두 예시는 일반적인 투명 재작성 실패 시나리오를 보여 줍니다.
사례 1: 조인 순서 불일치로 인한 재작성 실패
구체화된 뷰 생성:
CREATE MATERIALIZED VIEW mv11
BUILD IMMEDIATE REFRESH AUTO ON MANUAL
partition by(l_shipdate)
DISTRIBUTED BY HASH(l_orderkey) BUCKETS 10
PROPERTIES ('replication_num' = '1')
AS
SELECT l_shipdate, l_orderkey, O_ORDERDATE, count(*)
FROM lineitem
LEFT OUTER JOIN orders on l_orderkey = o_orderkey
GROUP BY l_shipdate, l_orderkey, O_ORDERDATE;
쿼리 실행:
explain
SELECT l_shipdate, l_linestatus, O_ORDERDATE, count(*)
FROM orders
LEFT OUTER JOIN lineitem on l_orderkey = o_orderkey
GROUP BY l_shipdate, l_linestatus, O_ORDERDATE;
Explain 출력:
| MaterializedView |
| MaterializedViewRewriteSuccessAndChose: |
| |
| MaterializedViewRewriteSuccessButNotChose: |
| |
| MaterializedViewRewriteFail: |
| Name: internal#doc_test#mv11 |
| FailSummary: View struct info is invalid, The graph logic between query and view is not consistent |
MaterializedViewRewriteFail에는 실패 요약 The graph logic between query and view is not consistent가 포함되어 있습니다. 이는 쿼리와 구체화된 뷰의 조인 로직이 일치하지 않는다는 의미입니다. 즉, 조인 유형이나 조인되는 테이블이 다릅니다. 이 예시에서는 쿼리와 구체화된 뷰의 테이블 조인 순서가 일치하지 않아 이 오류가 보고됩니다. 전체 요약 설명은 부록 1을 참조하세요.
사례 2: 구체화된 뷰가 쿼리의 차원을 포함하지 않음
쿼리 실행:
explain
SELECT l_shipdate, l_linestatus, O_ORDERDATE, count(*)
FROM lineitem
LEFT OUTER JOIN orders on l_orderkey = o_orderkey
GROUP BY l_shipdate, l_linestatus, O_ORDERDATE;
Explain 출력:
| MaterializedView |
| MaterializedViewRewriteSuccessAndChose: |
| |
| MaterializedViewRewriteSuccessButNotChose: |
| |
| MaterializedViewRewriteFail: |
| Name: internal#doc_test#mv11 |
| FailSummary: View struct info is invalid, View dimensions doesn't not cover the query dimensions |
실패 요약 View dimensions doesn't not cover the query dimensions는 쿼리의 group by 열을 구체화된 뷰의 group by 열에서 얻을 수 없어 이 오류가 보고되었음을 의미합니다.
Q3: 어떤 상황에서 구체화된 뷰의 상태가 변경되어 사용 불가 상태가 되나요?
"사용 불가"란 구체화된 뷰를 투명 재작성에 사용할 수 없다는 의미이며, 구체화된 뷰 자체는 여전히 직접 쿼리할 수 있습니다.
| 구체화된 뷰 유형 | 사용 불가 상태를 유발하는 이벤트 | 영향 범위 |
|---|---|---|
| 전체 구체화된 뷰 | 기본 테이블 데이터 변경 / 기본 테이블 스키마 변경 | 구체화된 뷰 전체를 사용할 수 없음 |
| 파티션 구체화된 뷰 | 기본 테이블 데이터 변경 | 해당 파티션을 사용할 수 없음 |
| 파티션 구체화된 뷰 | 기본 테이블 스키마 변경 | 구체화된 뷰 전체를 사용할 수 없음 |
현재는 새로 고침 실패도 구체화된 뷰를 사용 불가 상태로 만듭니다. 향후에는 새로 고침에 실패해도 기존 구체화된 뷰를 투명 재작성에 계속 사용할 수 있도록 개선될 예정입니다.
Q4: 구체화된 뷰를 직접 쿼리해도 데이터가 반환되지 않습니다
가능한 원인:
- 구체화된 뷰가 생성 중입니다.
- 구체화된 뷰 생성이 실패했습니다.
구체화된 뷰 상태를 조회하여 확인할 수 있습니다. 자세한 내용은 구체화된 뷰 상태 확인을 참조하세요.
Q5: 기본 테이블 데이터가 변경되었지만 구체화된 뷰를 아직 새로 고치지 않았다면 투명 재작성은 어떻게 동작하나요?
비동기 구체화된 뷰의 데이터는 기본 테이블에 비해 일정한 지연이 있습니다. 투명 재작성 동작은 기본 테이블 유형과 grace_period 임계값에 따라 달라집니다.
1. 내부 테이블 및 데이터 변경을 감지할 수 있는 외부 테이블(예: Hive):
grace_period는 구체화된 뷰의 데이터가 기본 테이블 데이터와 일치하지 않아도 되는 최대 허용 시간입니다.
grace_period 설정 | 재작성 동작 |
|---|---|
0 | 구체화된 뷰와 기본 테이블 데이터가 완전히 일치해야 투명 재작성에 사용할 수 있습니다. 데이터 변경을 감지할 수 없는 외부 테이블(Hive 이외)의 경우, 데이터가 최신 상태인지와 관계없이 구체화된 뷰를 투명 재작성에 사용할 수 있습니다(데이터가 일치하지 않을 수 있음) |
10(초) | 구체화된 뷰와 기본 테이블 데이터 간에 최대 10초의 지연을 허용합니다. 지연이 10초 이내이면 구체화된 뷰를 투명 재작성에 계속 사용할 수 있습니다 |
2. 파티션 구체화된 뷰에서 일부 파티션이 유효하지 않은 경우:
- 쿼리가 유효하지 않은 파티션의 데이터를 사용하지 않는 경우: 구체화된 뷰를 계속 사용할 수 있습니다.
- 쿼리가 유효하지 않은 파티션의 데이터를 사용하더라도 데이터 최신성 지연이
grace_period이내인 경우: 구체화된 뷰를 계속 사용할 수 있습니다. - 데이터 최신성 지연이
grace_period를 초과하는 경우: 원본 테이블과 구체화된 뷰를 결합하여 쿼리를 처리할 수 있습니다. 이를 위해서는 union 재작성 스위치enable_materialized_view_union_rewrite를 활성화해야 합니다. 이 스위치는 2.1.5 버전부터 기본적으로 활성화되어 있습니다.
부록
부록 1: 투명 재작성 실패 요약 정보
| 요약 정보 | 설명 |
|---|---|
| View struct info is invalid | 구체화된 뷰의 구조 정보가 유효하지 않습니다. 현재 지원되는 재작성 SQL 패턴은 쿼리와 구체화된 뷰가 모두 조인인 경우, 쿼리가 집계이며 구체화된 뷰에는 조인이 없어도 되는 경우입니다. 각 투명 재작성 규칙은 특정 SQL 패턴을 처리하며, 요구 사항과 일치하지 않는 규칙이 적용되면 이 오류를 보고하므로 투명 재작성 과정에서 대부분 이 문제가 표시됩니다. 일반적으로 투명 재작성 실패의 주된 원인은 아닙니다 |
| Materialized view rule exec fail | 투명 재작성 규칙을 실행하는 중 예외가 발생했습니다. Explain memo plan query_sql을 사용하여 구체적인 예외 스택을 확인하세요 |
| Match mode is invalid | 쿼리와 구체화된 뷰의 테이블 수가 일치하지 않습니다. 현재는 재작성을 지원하지 않습니다 |
| Query to view table mapping is null | 쿼리와 구체화된 뷰 간의 테이블 매핑 생성에 실패했습니다 |
| queryToViewTableMappings are over the limit and be intercepted | 쿼리에 자체 조인된 테이블이 너무 많아 투명 재작성의 탐색 공간이 지나치게 커지므로 투명 재작성이 중단됩니다 |
| Query to view slot mapping is null | 쿼리 테이블과 구체화된 뷰 테이블 간의 슬롯 매핑 생성에 실패했습니다 |
| The graph logic between query and view is not consistent | 쿼리와 구체화된 뷰의 조인 유형이 다르거나 조인되는 테이블이 다릅니다 |
| Predicate compensate fail | 일반적으로 쿼리 조건의 범위가 구체화된 뷰의 범위를 벗어납니다. 예를 들어 쿼리 조건은 a > 10이지만 구체화된 뷰의 조건은 a > 15인 경우입니다 |
| Rewrite compensate predicate by view fail | 조건자 보정에 실패했습니다. 일반적으로 쿼리에 구체화된 뷰보다 많은 조건이 있어 보정이 필요하지만, 해당 조건에 사용된 열이 구체화된 뷰의 select 절에 없는 경우입니다 |
| Calc invalid partitions fail | 파티션 구체화된 뷰에서 쿼리가 사용하는 파티션의 유효성을 계산하는 데 실패했습니다 |
| mv can not offer any partition for query | 쿼리가 구체화된 뷰의 유효하지 않은 파티션만 사용합니다. show partitions from mv_name을 사용하여 파티션의 SyncWithBaseTables 필드가 true인지 확인하세요. false이면 해당 파티션을 수동으로 새로 고치세요. 구체화된 뷰와 쿼리 데이터 간에 일정한 지연을 허용할 수 있다면 구체화된 뷰의 grace_period 속성(초 단위)을 설정하세요 |
| Add filter to base table fail when union rewrite | 쿼리가 구체화된 뷰의 유효하지 않은 파티션을 사용했으며, 구체화된 뷰와 원본 테이블을 union all로 결합하려는 시도가 실패했습니다 |
| RewrittenPlan output logical properties is different with target group | 재작성이 완료되었지만 구체화된 뷰의 출력이 원래 쿼리와 일치하지 않습니다 |
| Rewrite expressions by view in join fail | 조인 재작성 중 쿼리에 사용된 필드나 표현식이 구체화된 뷰에 없습니다 |
| Rewrite expressions by view in scan fail | 단일 테이블 재작성 중 쿼리에 사용된 필드나 표현식이 구체화된 뷰에 없습니다 |
| Split view to top plan and agg fail, view doesn't not contain aggregate | 집계를 재작성할 때 구체화된 뷰에 집계가 없습니다 |
| Split query to top plan and agg fail | 집계를 재작성할 때 쿼리에 집계가 없습니다 |
| rewritten expression contains aggregate functions when group equals aggregate rewrite | 쿼리와 구체화된 뷰의 group by 절이 같을 때 재작성된 표현식에 집계 함수가 포함되어 있습니다 |
| Can not rewrite expression when no roll up | 쿼리와 구체화된 뷰의 group by 절이 같을 때 표현식 재작성에 실패했습니다 |
| Query function roll up fail | 집계 재작성 중 집계 함수 롤업에 실패했습니다 |
| View dimensions do not cover the query dimensions | 쿼리의 group by 절이 구체화된 뷰의 group by 절에 없는 차원을 사용합니다 |
| View dimensions don't not cover the query dimensions in bottom agg | 쿼리의 group by 절이 구체화된 뷰의 group by 절에 없는 차원을 사용합니다 |
| View dimensions do not cover the query group set dimensions | 쿼리의 group sets가 구체화된 뷰의 group by 절에 없는 차원을 사용합니다 |
| The only one of query or view is scalar aggregate and can not rewrite expression meanwhile | 쿼리에는 group by가 있지만 구체화된 뷰에는 없습니다 |
| Both query and view have group sets, or query doesn't have but view has, not supported | 쿼리와 구체화된 뷰 모두에 group sets가 있거나, 쿼리에는 group sets가 없지만 구체화된 뷰에는 있습니다. 이 경우 투명 재작성이 지원되지 않습니다 |
부록 2: 비동기 구체화된 뷰 파티션 생성 실패 원인
파티션 구체화된 뷰의 새로 고침 원리는 파티션 증분 갱신입니다.
- 1단계: 구체화된 뷰의 파티션 열을 기본 테이블의 파티션에 매핑할 수 있는지 계산합니다.
- 2단계: 구체적인 매핑 관계, 즉 파티션이 1:1인지 1:n인지 계산합니다.
| 요약 정보 | 설명 |
|---|---|
| partition column can not be found in the SQL select column | 구체화된 뷰 정의에서 partition by 뒤에 사용하는 열은 구체화된 뷰를 정의하는 SQL의 select 절에 있어야 합니다 |
| can't not find valid partition track column, because %s | 적합한 파티션 열을 찾지 못했습니다. 구체적인 이유는 because 뒤에 표시됩니다 |
| partition track doesn't support mark join | 구체화된 뷰의 파티션 열이 참조하는 열은 mark join 입력 테이블의 파티션 열이며, 이는 지원되지 않습니다 |
| partition column is in un supported join null generate side | 구체화된 뷰의 파티션 열이 참조하는 열은 조인에서 null을 생성하는 쪽에 있습니다. 예를 들어 left join의 오른쪽에 있는 경우입니다 |
| relation should be LogicalCatalogRelation | 구체화된 뷰가 참조하는 파티션 기본 테이블의 스캔 유형은 LogicalCatalogRelation이어야 합니다. 다른 유형은 지원되지 않습니다 |
| self join doesn't support partition update | 자체 조인 SQL을 사용한 구체화된 뷰 생성은 아직 지원되지 않습니다 |
| partition track already has a related base table column | 현재 구체화된 뷰의 파티션 열은 기본 테이블 하나의 파티션 열만 참조할 수 있습니다 |
| relation base table is not MTMVRelatedTableIf | 구체화된 뷰가 참조하는 파티션 기본 테이블이 MTMVRelatedTableIf를 상속하지 않습니다. 이 인터페이스는 테이블의 파티션 구성 가능 여부를 나타냅니다 |
| The related base table is not partition table | 구체화된 뷰에서 사용하는 기본 테이블이 파티션 테이블이 아닙니다 |
| The related base table partition column doesn't contain the mv partition | 구체화된 뷰의 partition by 뒤에서 참조하는 열이 파티션 기본 테이블에 없습니다 |
| group by sets is empty, doesn't contain the target partition | 구체화된 뷰를 정의하는 SQL이 집계를 사용하지만 group by가 비어 있습니다 |
| window partition sets don't contain the target partition | 윈도우 함수를 사용하지만 구체화된 뷰가 참조하는 파티션 열이 partition by 절에 없습니다 |
| Unsupported plan operate in track partition | 구체화된 뷰를 정의하는 SQL이 order by와 같이 지원되지 않는 연산을 사용합니다 |
| context partition column should be slot from column | 윈도우 함수를 사용하며, 구체화된 뷰가 partition by 절에서 참조하는 파티션 열이 단순 열이 아니라 표현식입니다 |
| partition expressions use more than one slot reference | group by 또는 partition by 뒤의 파티션 열이 단순 열이 아니라 여러 열을 포함하는 표현식입니다. 예를 들어 group by partition_col + other_col인 경우입니다 |
| column to check using invalid implicit expression | 구체화된 뷰의 파티션 열에는 date_trunc만 사용할 수 있습니다. 파티션 열의 표현식은 date_trunc 및 이와 유사한 표현식으로 제한됩니다 |
| partition column time unit level should be greater than SQL select column | 구체화된 뷰의 date_trunc 시간 단위(partition by 뒤)가 구체화된 뷰를 정의하는 SQL의 select 절에 있는 시간 단위보다 작습니다. 예를 들어 구체화된 뷰가 partition by(date_trunc(col, 'day'))를 사용하지만, 구체화된 뷰를 정의하는 SQL의 select 뒤에는 date_trunc(col, 'month')가 있는 경우입니다 |