[AWS DEA] 문제로 공부하기 16 - Redshift SUPER 타입 + PartiQL

AWS DEA-C01 Amazon Redshift SUPER 타입 PartiQL 중첩 JSON 쿼리

중첩 JSON + 기존 테이블 무결성 유지 — Redshift SUPER 타입 + PartiQL이 정답인 이유

AWS DEA-C01 시험에 자주 나오는 Redshift 데이터 타입 문제입니다. 중첩 JSON 데이터를 기존 Redshift 테이블 구조를 변경하지 않고 쿼리하려면 SUPER 데이터 타입으로 로드 후 PartiQL로 쿼리하는 방법이 최적입니다. Redshift Spectrum(SQL 한계), Glue 평면화(스키마 변경), Glue Studio 노트북(고가용성 부재)이 탈락하는 이유를 비교 정리합니다.

📋 문제

한 ISP에서는 최근 고객 상호 작용 데이터를 중첩 JSON 형식으로 저장하기 시작했다. 회사는 이 데이터와 Amazon Redshift 데이터 웨어하우스의 추가 데이터를 결합하여 고객 상호 작용을 개선하려고 한다.

회사는 매일 여러 번 데이터에 대한 쿼리를 실행할 예정이다. 기존 Redshift 테이블의 무결성을 유지해야 하며, 솔루션은 가용성이 높아야 한다.

다음 중 이러한 요구 사항을 충족하는 솔루션은 무엇인가?

✅ 핵심 요구사항 분석

• 🔀
  중첩 JSON + 기존 Redshift 데이터 결합 쿼리
  두 데이터 소스를 함께 분석해야 하므로 Redshift 내에서 통합 가능해야 함
• 🛡️
  기존 Redshift 테이블 무결성 유지 (핵심 조건)
  스키마 변경·열 추가·평면화 등 기존 테이블 구조를 수정하면 안 됨
• 📅
  매일 여러 번 쿼리 — 빈번한 접근
  비용 효율적이고 빠른 쿼리 응답이 필요, 매번 변환 파이프라인 실행은 비효율
• 🏗️
  고가용성
  단일 노트북·단일 Lambda처럼 이중화가 없는 솔루션은 부적합

🔑 핵심 개념 — Redshift SUPER 타입과 PartiQL

🧩 SUPER 데이터 타입

Redshift 테이블의 열에 중첩된 JSON/반정형 데이터를 네이티브로 저장하는 타입입니다. JSON 객체, 배열, 스칼라 값을 모두 하나의 열에 담을 수 있으며, 스키마 변경 없이 기존 테이블에 SUPER 열만 추가하면 됩니다. 기존 열과 SUPER 열을 같은 테이블에서 함께 사용할 수 있습니다.

🔍 PartiQL

중첩된 데이터를 SQL처럼 쿼리하는 언어입니다. 표준 SQL의 FROM·WHERE·SELECT 구문을 그대로 사용하면서 JSON의 중첩 구조를 점(.)과 배열 인덱스([])로 탐색합니다. Redshift는 PartiQL을 SUPER 열에 네이티브로 지원합니다.

📋 중첩 JSON 데이터 예시 + PartiQL 쿼리

-- SUPER 열에 저장되는 중첩 JSON 데이터 예시 { "customer_id": 12345, "interactions": [ { "type": "call", "duration_sec": 180, "resolved": true }, { "type": "chat", "duration_sec": 60, "resolved": false } ], "contact_info": { "region": "ap-northeast-2" } } -- PartiQL로 중첩 데이터 쿼리 SELECT c.customer_id, i.type, i.duration_sec FROM customer_interactions c, c.interactions i WHERE i.resolved = false;

✅ 핵심: SUPER 열은 기존 Redshift 테이블에 새 열로 추가하는 것이므로 기존 열과 기존 쿼리는 전혀 영향받지 않습니다. 테이블 무결성이 완벽하게 유지됩니다.

🔍 4가지 솔루션 요건 충족 비교

🔭

A. Redshift Spectrum + SQL

중첩 JSON ⚠️ 복잡한 변환

테이블 무결성 ✅ 유지

고가용성 ✅ Redshift HA

PartiQL ❌ 표준 SQL만

⚠️ 중첩 JSON 쿼리 복잡 — 부적합

⭐

B. SUPER 타입 + PartiQL

중첩 JSON ✅ 네이티브 저장

테이블 무결성 ✅ 완벽 유지

고가용성 ✅ Redshift HA

PartiQL ✅ 네이티브 지원

✅ 모든 요건 충족 — 정답

🔧

C. Glue 평면화 + 별도 열

중첩 JSON ⚠️ 변환 후 저장

테이블 무결성 ❌ 스키마 변경

기존 쿼리 ❌ 영향 가능

PartiQL ❌ 불필요 (평면화)

❌ 테이블 무결성 훼손

📓

D. Glue Studio 노트북

두 데이터 결합 ❌ 별도 분석

고가용성 ❌ 노트북 이중화 없음

언로드 비용 ❌ 추가 발생

매일 다수 쿼리 ❌ 비효율

❌ 고가용성 미충족 + 비효율

⚠️ A vs B 핵심 차이: Redshift Spectrum(A)도 S3의 JSON 데이터를 Redshift와 결합할 수 있지만, 표준 SQL로 중첩 JSON을 쿼리하려면 복잡한 데이터 변환이 필요합니다. SUPER 타입(B)은 중첩 구조 그대로 저장하고 PartiQL로 직접 탐색하므로 변환이 불필요합니다.

📝 선택지 해설

각 항목을 클릭하면 해설이 펼쳐집니다.

A

❌ S3에 데이터 저장 + Redshift Spectrum으로 결합 + SQL 쿼리

Spectrum은 S3 데이터 쿼리 가능 — 그러나 표준 SQL로 중첩 JSON 쿼리는 복잡한 변환 필요

💡 Redshift Spectrum은 S3에 저장된 데이터를 직접 쿼리하고 Redshift 내 데이터와 결합하는 강력한 기능입니다. 그러나 표준 SQL로 중첩된 JSON 구조를 쿼리하려면 JSON_EXTRACT_PATH_TEXT 같은 함수를 사용하는 복잡한 변환 로직이 필요합니다. 중첩 깊이가 깊어질수록 쿼리가 매우 복잡해지며, 매일 여러 번 실행하기에 적합하지 않습니다. 더 나은 선택은 중첩 데이터를 자연스럽게 탐색할 수 있는 PartiQL을 사용하는 것입니다.

B

✅ 데이터를 SUPER 열로 Redshift에 로드 + PartiQL로 중첩 데이터 쿼리

중첩 JSON 네이티브 저장 + 기존 테이블 무결성 완벽 유지 + Redshift 고가용성 + PartiQL 직접 탐색

💡 정답. 네 가지 요건을 모두 충족합니다. ① 중첩 JSON 저장: SUPER 데이터 타입은 중첩 JSON 구조를 그대로 Redshift 열에 저장합니다. ② 기존 테이블 무결성 유지: 기존 테이블에 SUPER 열을 추가하는 것이므로 기존 열·스키마·쿼리에 전혀 영향을 주지 않습니다. ③ 효율적 쿼리: PartiQL은 SUPER 열의 중첩 구조를 직접 탐색하여 복잡한 변환 없이 매일 여러 번 빠르게 쿼리할 수 있습니다. ④ 고가용성: Amazon Redshift는 자체적으로 고가용성을 제공합니다.

C

❌ Glue로 데이터를 표 형식으로 평면화 → 별도 열로 Redshift에 로드 + PartiQL

스키마 변경으로 기존 테이블 무결성 훼손 — 기존 쿼리·애플리케이션에 부정적 영향

💡 AWS Glue로 중첩 JSON을 평면화(Flatten)하여 개별 열로 분리하면 데이터를 쿼리하기 쉬워지는 장점이 있습니다. 그러나 이 방식은 Redshift 테이블에 새 열을 추가하거나 테이블 구조를 변경해야 합니다. 기존 스키마를 사용하는 쿼리와 애플리케이션이 영향을 받을 수 있어 "기존 테이블 무결성 유지" 요건을 충족하지 못합니다. 또한 이미 데이터가 평면화된 상태이므로 PartiQL을 사용할 필요도 없어 구성이 모순됩니다.

D

❌ S3 → Redshift 언로드 + Glue Studio 노트북으로 탐색 + SQL 쿼리

두 데이터 집합 결합 불가 + Glue Studio 노트북 이중화 없어 고가용성 미충족

💡 두 가지 치명적 문제가 있습니다. 첫째, Redshift 데이터를 S3로 언로드한 후 Glue Studio에서 분석하면 Redshift에 있는 기존 데이터와 고객 상호 작용 데이터를 함께 효율적으로 쿼리할 수 없습니다. 두 데이터가 별도 환경에서 분리 분석됩니다. 둘째, Glue Studio 노트북은 고가용성(HA)을 제공하지 않습니다. 노트북은 이중화 구성이 없어 장애 시 서비스가 중단될 수 있습니다. 매일 여러 번 안정적으로 쿼리해야 하는 요건에도 맞지 않습니다.

정답 및 핵심 정리 (클릭)

정답: B — SUPER 데이터 타입 + PartiQL

이 문제의 구분 포인트는 두 가지입니다. ① 중첩 JSON 쿼리 방법: 표준 SQL(A)은 변환 복잡, PartiQL(B)은 네이티브 탐색. ② 테이블 무결성: Glue 평면화(C)는 스키마 변경, SUPER 열 추가(B)는 기존 구조 보존.

# SUPER 타입 + PartiQL 사용 패턴 -- 1. 기존 테이블에 SUPER 열 추가 (기존 열 영향 없음) ALTER TABLE customer_data ADD COLUMN interactions SUPER; -- 2. 중첩 JSON 데이터 로드 (COPY 명령) COPY customer_data (customer_id, interactions) FROM 's3://bucket/interactions.json' FORMAT JSON 'auto'; -- 3. PartiQL로 중첩 데이터 + 기존 데이터 결합 쿼리 SELECT c.customer_id, c.name, -- 기존 열 i.type, -- SUPER 열 내 중첩 데이터 i.duration_sec FROM customer_data c, c.interactions i WHERE i.resolved = false AND c.region = 'ap-northeast-2'; # 요건 충족 요약 중첩 JSON 쿼리 → SUPER 타입 네이티브 저장 + PartiQL ✅ 기존 테이블 무결성 → 기존 열·스키마 변경 없음 ✅ 고가용성 → Amazon Redshift 자체 HA ✅ 빈번한 쿼리 → 변환 없이 직접 쿼리 ✅

📊 선택지 비교 요약

선택지	방식	중첩 JSON 쿼리	테이블 무결성	고가용성	결론
A	Spectrum + SQL	⚠️ 변환 복잡	✅ 유지	✅ Redshift HA	탈락
B ⭐	SUPER + PartiQL	✅ 네이티브	✅ 완벽 유지	✅ Redshift HA	정답
C	Glue 평면화	평면화 후 일반 열	❌ 스키마 변경	✅ Redshift HA	탈락
D	Glue Studio 노트북	SQL 분리 분석	무관	❌ 노트북 이중화 없음	탈락

#AWS_DEA-C01 #AmazonRedshift #SUPER데이터타입 #PartiQL #중첩JSON쿼리 #RedshiftSpectrum #AWSGlue #Glue Studio노트북 #테이블무결성 #반정형데이터 #고가용성 #AWS자격증 #AWS데이터엔지니어