Amazon Redshift는 패치 198부터 새 Python UDF 생성을 더 이상 지원하지 않습니다. 기존 Python UDF는 2026년 6월 30일까지 계속 작동합니다. 자세한 내용은 [블로그 게시물](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)을 참조하세요.
# SUPER 데이터 형식과 구체화된 뷰
Amazon Redshift에서는 구체화된 뷰를 사용하여 SUPER 데이터 형식에 대해 실행되는 쿼리의 성능과 유연성을 향상시킬 수 있습니다. SUPER 데이터 유형으로 기본 테이블의 열 슈퍼 세트를 구체화된 뷰에 저장할 수 있으므로 기본 테이블을 조인하지 않고도 구체화된 뷰를 직접 쿼리하는 것이 가능합니다. 다음 섹션에서는 Amazon Redshift에서 SUPER 데이터 유형을 사용하여 구체화된 뷰를 생성하고 사용하는 방법을 보여 줍니다.
Amazon Redshift는 SUPER 데이터 형식 열과 PartiQL 쿼리를 통합하는 구체화된 뷰를 지원합니다. 구체화된 뷰는 증분적으로 새로 고칠 수 있지만 Amazon Redshift는 마지막 새로 고침 작업 이후 기본 테이블에서 변경된 데이터만 업데이트합니다. 이러한 선택적 업데이트 방식은 전체 재계산에 비해 새로 고침 프로세스의 효율성을 높여줍니다. 구체화된 뷰에 대한 자세한 내용은 [Amazon Redshift의 구체화된 뷰](materialized-view-overview.md) 섹션을 참조하세요.
## PartiQL 쿼리 가속화
구체화된 뷰를 사용하여 SUPER 열에서 계층적 데이터를 탐색 및/또는 중첩 해제하는 PartiQL 쿼리를 가속화할 수 있습니다. 하나 이상의 구체화된 뷰를 생성하여 SUPER 값을 여러 열로 나누고 Amazon Redshift 분석 쿼리의 열 형식 구조를 활용함으로써 중첩 데이터를 추출하고 정규화할 수 있습니다. 정규화 수준은 SUPER 데이터를 기존의 열 형식 데이터로 변환하는 데 얼마나 많은 노력을 기울이는지에 따라 다릅니다.
다음 항목에서는 복잡한 데이터를 더 작은 열로 구분 또는 분할하고 분할된 데이터로 스칼라 열을 생성하여 성능을 개선하는 예를 보여줍니다.
**Topics**
+ [PartiQL 쿼리 가속화](#r_accelerate_mv)
+ [구체화된 뷰를 사용하여 반정형 데이터를 SUPER 열로 분할](r_shred_super.md)
+ [나뉜 데이터에서 Amazon Redshift 스칼라 열 생성](r_create_scalar.md)
# 구체화된 뷰를 사용하여 반정형 데이터를 SUPER 열로 분할
Amazon Redshift에서는 구체화된 뷰를 사용하여 SUPER 열로 데이터를 분할함으로써 쿼리 성능을 개선할 수 있습니다. 파쇄는 반정형 JSON 또는 XML 등 복잡한 데이터 유형을 더 작고 평평한 열로 세분화하는 프로세스를 말합니다. SUPER 열은 파쇄된 데이터를 빠르게 스캔하는 데 최적화된 특수한 형태의 열 스토리지입니다.
다음 섹션에서는 Amazon Redshift에서 구체화된 뷰를 사용하여 SUPER 열로 데이터를 파쇄하는 단계와 고려 사항을 설명합니다.
다음 예제에서는 결과 열이 여전히 SUPER 데이터 형식인 중첩 데이터를 나누는 구체화된 뷰를 보여줍니다.
```
SELECT c.c_name, o.o_orderstatus
FROM customer_orders_lineitem c, c.c_orders o;
```
다음 예제에서는 나뉜 데이터에서 기존의 Amazon Redshift 스칼라 열을 생성하는 구체화된 뷰를 보여줍니다.
```
SELECT c.c_name, c.c_orders[0].o_totalprice
FROM customer_orders_lineitem c;
```
단일 구체화된 뷰 super\$1mv를 생성하여 두 쿼리를 모두 가속화할 수 있습니다.
첫 번째 쿼리에 응답하려면 속성 o\$1orderstatus를 구체화해야 합니다. 중첩 탐색이나 중첩 해제를 포함하지 않기 때문에 속성 c\$1name을 생략할 수 있습니다. 구체화된 뷰에 customer\$1orders\$1lineitem의 속성 c\$1custkey를 포함해야 구체화된 뷰와 기본 테이블을 조인할 수 있습니다.
두 번째 쿼리에 응답하려면 속성 o\$1totalprice 및 c\$1orders의 배열 인덱스 o\$1idx도 구체화해야 합니다. 따라서 c\$1orders의 인덱스 0에 액세스할 수 있습니다.
```
CREATE MATERIALIZED VIEW super_mv distkey(c_custkey) sortkey(c_custkey) AS (
SELECT c_custkey, o.o_orderstatus, o.o_totalprice, o_idx
FROM customer_orders_lineitem c, c.c_orders o AT o_idx
);
```
구체화된 뷰 super\$1mv의 속성 o\$1orderstatus 및 o\$1totalprice는 SUPER입니다.
구체화된 뷰 super\$1mv는 기본 테이블 customer\$1orders\$1lineitem이 변경되면 점진적으로 새로 고쳐집니다.
```
REFRESH MATERIALIZED VIEW super_mv;
INFO: Materialized view super_mv was incrementally updated successfully.
```
첫 번째 PartiQL 쿼리를 일반 SQL 쿼리로 다시 작성하려면 다음과 같이 customer\$1orders\$1lineitem을 super\$1mv와 조인합니다.
```
SELECT c.c_name, v.o_orderstatus
FROM customer_orders_lineitem c
JOIN super_mv v ON c.c_custkey = v.c_custkey;
```
마찬가지로 두 번째 PartiQL 쿼리를 다시 작성할 수 있습니다. 다음 예에서는 o\$1idx = 0에 대한 필터를 사용합니다.
```
SELECT c.c_name, v.o_totalprice
FROM customer_orders_lineitem c
JOIN super_mv v ON c.c_custkey = v.c_custkey
WHERE v.o_idx = 0;
```
CREATE MATERIALIZED VIEW 명령에서 c\$1custkey를 배포 키로 지정하고 super\$1mv에 대한 정렬 키로 지정합니다. Amazon Redshift는 c\$1custkey가 customer\$1orders\$1lineitem의 배포 키이자 정렬 키라고 가정하고 효율적인 병합 조인을 수행합니다. 그렇지 않은 경우 다음과 같이 c\$1custkey를 customer\$1orders\$1lineitem의 정렬 키와 배포 키로 지정할 수 있습니다.
```
ALTER TABLE customer_orders_lineitem
ALTER DISTKEY c_custkey, ALTER SORTKEY (c_custkey);
```
EXPLAIN 문을 사용하여 Amazon Redshift가 재작성된 쿼리에 대해 병합 조인을 수행하는지 확인합니다.
```
EXPLAIN
SELECT c.c_name, v.o_orderstatus
FROM customer_orders_lineitem c JOIN super_mv v ON c.c_custkey = v.c_custkey;
QUERY PLAN
------------------------------------------------------------------------------------------------------
XN Merge Join DS_DIST_NONE (cost=0.00..34701.82 rows=1470776 width=27)
Merge Cond: ("outer".c_custkey = "inner".c_custkey)
-> XN Seq Scan on mv_tbl__super_mv__0 derived_table2 (cost=0.00..14999.86 rows=1499986 width=13)
-> XN Seq Scan on customer_orders_lineitem c (cost=0.00..999.96 rows=99996 width=30)
(4 rows)
```
# 나뉜 데이터에서 Amazon Redshift 스칼라 열 생성
SUPER에 저장된 스키마 없는 데이터는 Amazon Redshift의 성능에 영향을 미칠 수 있습니다. 예를 들어 범위 제한 스캔은 영역 맵을 효과적으로 사용할 수 없으므로 술어를 필터링하거나 조건을 조인합니다. 사용자와 BI 도구는 구체화된 뷰를 데이터의 기존 표현으로 사용하고 분석 쿼리의 성능을 높일 수 있습니다.
다음 쿼리는 구체화된 뷰 `super_mv`를 스캔하고 `o_orderstatus`를 필터링합니다.
```
SELECT c.c_name, v.o_totalprice
FROM customer_orders_lineitem c
JOIN super_mv v ON c.c_custkey = v.c_custkey
WHERE v.o_orderstatus = 'F';
```
`stl_scan`을 검사하여 Amazon Redshift가 `o_orderstatus`에 대한 범위 제한 스캔에서 영역 맵을 효과적으로 사용할 수 없는지 확인합니다.
```
SELECT slice, is_rrscan FROM stl_scan
WHERE query = pg_last_query_id() AND perm_table_name LIKE '%super_mv%';
slice | is_rrscan
-------+-----------
0 | f
1 | f
5 | f
4 | f
2 | f
3 | f
(6 rows)
```
다음 예에서는 구체화된 뷰 `super_mv`를 조정하여 나뉜 데이터에서 스칼라 열을 생성합니다. 이 경우 Amazon Redshift는 SUPER에서 VARCHAR로 `o_orderstatus`를 캐스팅합니다. 또한 `super_mv`의 정렬 키로 `o_orderstatus`를 지정합니다.
```
CREATE MATERIALIZED VIEW super_mv distkey(c_custkey) sortkey(c_custkey, o_orderstatus) AS (
SELECT c_custkey, o.o_orderstatus::VARCHAR AS o_orderstatus, o.o_totalprice, o_idx
FROM customer_orders_lineitem c, c.c_orders o AT o_idx
);
```
쿼리를 다시 실행한 후 Amazon Redshift가 이제 영역 맵을 사용할 수 있는지 확인합니다.
```
SELECT v.o_totalprice
FROM super_mv v
WHERE v.o_orderstatus = 'F';
```
이제 범위 제한 스캔이 다음과 같이 영역 맵을 사용하는지 확인할 수 있습니다.
```
SELECT slice, is_rrscan FROM stl_scan
WHERE query = pg_last_query_id() AND perm_table_name LIKE '%super_mv%';
slice | is_rrscan
-------+-----------
0 | t
1 | t
2 | t
3 | t
4 | t
5 | t
(6 rows)
```