🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Quick Sight의 다중 데이터셋 관계는 테이블을 미리 하나로 합치지 않고 토픽에서 논리적 관계를 정의해 필요한 시점에만 내부 조인을 수행함으로써, 데이터의 고유 세분성을 보존하고 분석 모델의 재사용성과 관리 효율을 높이는 기능이다.

📌 핵심 요약

• 기존의 단일 데이터셋 방식은 분석 전에 여러 테이블을 넓고 비정규화된 형태로 결합해야 했기 때문에 조인 구조를 미리 결정해야 했고, 서로 다른 세분성의 측정값이 중복되거나 분석 목적별 데이터셋이 늘어나는 문제가 있었다.
• 다중 데이터셋 관계에서는 판매, 고객, 제품과 같은 개별 데이터셋을 그대로 유지하고 Quick Sight 토픽 안에서 연결 키를 지정하며, 시각화·계산 필드·필터·자연어 질문에 필요한 데이터셋만 실행 시점에 결합한다.
• 물리 계층은 하나의 데이터셋 내부에서 조인·유니온·SQL·변환을 수행하는 영역이고, 논리 계층은 여러 데이터셋을 토픽에서 관계로 연결하는 영역이므로 각 로직의 성격에 따라 배치 위치를 구분해야 한다.
• 권장 출발점은 하나의 팩트 데이터셋을 중심으로 차원 데이터셋을 직접 연결하는 스타 스키마이며, 깨끗한 대리 키, 일치하는 자료형, 참조 무결성, 호환 가능한 세분성을 확보해야 한다.
• 다중 데이터셋 방식은 여러 팩트 테이블, 다양한 분석 질문, 자연어 탐색에 적합하지만 현재 관계가 내부 조인으로 동작하므로 외부 조인이 필요하거나 테이블 수가 적은 단순 분석에서는 사전 결합 데이터셋이 더 적절할 수 있다.

🧩 주요 포인트

1. 기존의 단일 데이터셋 방식은 분석 전에 여러 테이블을 넓고 비정규화된 형태로 결합해야 했기 때문에 조인 구조를 미리 결정해야 했고, 서로 다른 세분성의 측정값이 중복되거나 분석 목적별 데이터셋이 늘어나는 문제가 있었다.
2. 다중 데이터셋 관계에서는 판매, 고객, 제품과 같은 개별 데이터셋을 그대로 유지하고 Quick Sight 토픽 안에서 연결 키를 지정하며, 시각화·계산 필드·필터·자연어 질문에 필요한 데이터셋만 실행 시점에 결합한다.
3. 물리 계층은 하나의 데이터셋 내부에서 조인·유니온·SQL·변환을 수행하는 영역이고, 논리 계층은 여러 데이터셋을 토픽에서 관계로 연결하는 영역이므로 각 로직의 성격에 따라 배치 위치를 구분해야 한다.
4. 권장 출발점은 하나의 팩트 데이터셋을 중심으로 차원 데이터셋을 직접 연결하는 스타 스키마이며, 깨끗한 대리 키, 일치하는 자료형, 참조 무결성, 호환 가능한 세분성을 확보해야 한다.
5. 다중 데이터셋 방식은 여러 팩트 테이블, 다양한 분석 질문, 자연어 탐색에 적합하지만 현재 관계가 내부 조인으로 동작하므로 외부 조인이 필요하거나 테이블 수가 적은 단순 분석에서는 사전 결합 데이터셋이 더 적절할 수 있다.

🧠 상세 정리

1. 기존 사전 결합 방식의 구조적 비용

비즈니스 분석에 필요한 정보는 보통 하나의 테이블에 모여 있지 않고, 판매 거래와 고객 특성, 제품 속성, 반품, 예측, 운영 지표처럼 여러 위치와 서로 다른 세분성에 나뉘어 있다. 기존 Quick Sight의 단일 데이터셋 방식에서는 분석을 시작하기 전에 이 테이블들을 넓고 비정규화된 데이터셋으로 미리 결합해야 했다. 이 방식은 동작하지만 실제 질문을 모두 알기 전에 조인 형태를 결정하게 만들고, 관련 로직을 사용자 지정 SQL이나 데이터베이스 뷰로 밀어 넣는 부담을 낳는다. 또한 일대다 관계에서 상위 세분성의 측정값이 하위 행마다 반복되어 합계가 부풀 수 있으며, 보고 목적이 달라질 때마다 별도의 평면 데이터셋을 만들게 되어 유지관리 대상이 계속 증가한다.

2. 다중 데이터셋 관계와 실행 시점 조인

다중 데이터셋 관계는 모든 테이블을 사전에 평면화하는 대신, 각 테이블을 독립적인 Quick Sight 데이터셋으로 유지하고 토픽 안에서 데이터셋 간의 논리적 관계를 선언하도록 한다. 사용자가 여러 데이터셋의 필드를 포함한 시각화, 계산 필드, 필터 또는 자연어 질문을 만들면 Quick Sight가 그 요청에 필요한 테이블만 선택해 실행 시점에 결합한다. 관계를 한 번 정의하면 다양한 분석에서 같은 토픽을 재사용할 수 있고, 각 데이터셋은 원래의 세분성과 독립적인 변환·권한·비즈니스 로직을 유지할 수 있다. 데이터 변동성에 맞춰 테이블별로 시간별·일별·월별 갱신 주기를 운영할 수 있으며, 행 수준 보안 규칙도 실행 시점 조인 과정에서 적용되어 데이터셋을 가로지르는 접근 정책을 일관되게 유지한다.

3. 물리 계층과 논리 계층의 역할 분담

이 기능의 구조는 데이터셋 내부의 물리 계층과 토픽 내부의 논리 계층으로 나뉜다. 물리 계층에서는 물리 테이블을 조인하거나 유니온하고, SQL과 변환을 적용해 하나의 평면 결과를 만들므로 같은 세분성을 공유하고 항상 함께 사용되는 테이블을 묶는 데 적합하다. 논리 계층에서는 하나의 Quick Sight 데이터셋이 하나의 논리 테이블처럼 동작하며, 서로 다른 데이터셋은 합쳐진 상태로 저장되지 않고 토픽에 정의된 키 관계를 통해 필요할 때만 연결된다. 따라서 데이터셋 생성, 토픽 구성, 관계 열 지정, 다중 데이터셋 분석 또는 자연어 질의의 순서로 모델을 사용할 수 있으며, 현재 릴리스의 관계는 내부 조인 방식이어서 양쪽 데이터셋에 일치하는 키가 존재하는 행만 결과에 포함된다는 제약을 고려해야 한다.

4. 차원 모델링의 기본 구성과 스키마 유형

팩트 테이블은 매출, 수량, 비용처럼 특정 세분성에서 측정되는 정량 데이터를 담으며 일반적으로 열은 비교적 적고 행은 많은 형태를 가진다. 차원 테이블은 고객명, 제품 범주, 매장 위치처럼 팩트에 맥락을 제공하는 설명 속성을 담고, 대체로 열이 많고 행이 적다. 하나의 팩트를 여러 차원이 직접 둘러싸는 스타 스키마는 단순하고 빠른 질의에 적합한 기본 권장안이며, 큰 차원의 중복을 줄이기 위해 차원을 정규화하면 스노플레이크 스키마가 된다. 여러 팩트 테이블이 공통 차원을 공유하는 갤럭시 또는 컨스텔레이션 스키마는 판매와 반품처럼 서로 다른 업무 과정을 함께 분석할 때 사용되며, 고정 깊이·가변 깊이·자기 참조·병렬 구조의 차원 계층도 모델 설계 시 별도로 구분해야 한다.

5. 스타 스키마와 논리적 데이터셋 설계

다중 데이터셋 모델의 권장 출발점은 중앙의 팩트 데이터셋을 허브로 두고 차원 데이터셋을 바깥쪽에 직접 연결하는 스타 스키마다. 이 구조는 관계 경로를 단순하게 유지해 조인 복잡성을 줄이고 질의 성능을 높이는 데 유리하다. 각 데이터셋은 고객, 제품, 주문과 같이 하나의 명확한 비즈니스 개념을 표현해야 하며, 가능한 경우 여러 단계로 이어지는 스노플레이크 차원 체인은 하나의 차원 데이터셋 안에서 미리 결합하는 것이 좋다. 데이터셋에는 안정적인 대리 키를 포함하고, 필드 설명과 동의어, 의미 유형을 보강해야 하며, 처음부터 모든 테이블을 연결하기보다 하나의 팩트와 핵심 차원으로 시작한 뒤 검증된 필요에 따라 데이터셋을 점진적으로 추가해야 한다.

6. 조인 키와 세분성의 일관성

관계 키에는 가능하면 정수형 대리 키를 사용해야 조인 처리와 저장 공간 측면에서 효율적이며, 연결되는 양쪽 열의 자료형도 반드시 일치시켜야 한다. 현재 관계가 내부 조인이므로 키 열의 널 값은 서로 일치하지 않으며 결과에서 제외될 수 있어, 관계를 정의하기 전에 널 값을 제거하거나 데이터 품질을 정비해야 한다. 팩트 테이블의 모든 외래 키가 해당 차원에 존재하는지 확인해 참조 무결성을 검증하는 것도 중요하다. 동일한 팩트와 연결되는 데이터셋은 호환 가능한 세분성으로 조인할 수 있어야 하고, 차원이 팩트보다 거친 수준이라면 팩트를 그 수준에 맞춰 집계해야 하며, 여러 팩트가 차원을 공유할 때는 공통 차원의 세분성이 모든 팩트에서 하나의 일관된 의미를 가져야 한다.

7. 자연어 정확도와 다중 팩트 관리

다중 데이터셋 토픽은 자연어 기반 분석에도 사용되므로 기술적으로 관계만 연결하는 것만으로는 충분하지 않고, 사용자가 이해할 수 있는 의미 정보가 필요하다. 각 필드에는 비즈니스 의미를 설명하는 문구를 추가하고, 매출을 판매액·수입·총액과 연결하는 것처럼 실제 질문에 쓰일 수 있는 동의어를 지정하며, 도시·통화·날짜 등의 의미 유형도 설정해야 한다. 업무 규칙은 사용자 지정 지침으로 명시하고 사용자가 볼 필요가 없는 내부용 또는 기술용 열은 제외하면 자연어 질의의 정확도를 높일 수 있다. 여러 팩트 테이블을 연결할 때는 공유 차원의 정합성을 확인하고 불필요한 관계를 만들지 않아야 하며, 팩트를 가로지르는 계산은 집계 결과가 의도대로 나오는지 별도로 시험하고 데이터셋·관계 다이어그램과 명명 규칙을 유지해야 한다.

8. 다중 데이터셋과 사전 결합 방식의 선택 기준

모든 분석에 다중 데이터셋 관계가 필요한 것은 아니며, 테이블이 다섯 개 미만이고 팩트가 하나인 단순 분석이라면 기존의 사전 결합 데이터셋이 더 간단할 수 있다. 반대로 여러 분석가가 서로 다른 팩트 테이블을 대상으로 다양한 질문을 하거나, 자연어와 대화형 탐색을 사용하려는 경우에는 데이터셋과 토픽의 의미 정보를 보강한 다중 데이터셋 모델이 적합하다. 외부 조인이 필요한 상황은 현재 내부 조인만 지원하는 관계 모델보다 단일 사전 결합 데이터셋을 선택해야 하며, 역할이 다른 동일 차원은 역할별 데이터셋으로 분리해 관계를 구성할 수 있다. 후속 내용에서는 스타·스노플레이크·갤럭시 스키마를 실제 테이블 구조와 SQL 예제로 다루고, 서로 다른 세분성의 다중 팩트와 역할 수행 차원을 설명하는 한편 순환 조인, 재귀 계층, 가변 깊이 계층처럼 기본 지원이 제한된 패턴의 우회 방법을 제시한다.

🧾 핵심 주장 / 시사점

• 다중 데이터셋 관계의 핵심 가치는 조인을 없애는 것이 아니라, 조인 결정을 데이터 준비 단계에서 실제 분석 요청이 발생하는 시점으로 이동시키는 데 있다.
• 정확한 분석 결과를 위해서는 관계 수를 늘리는 것보다 키의 참조 무결성과 데이터셋 간 세분성의 일관성을 먼저 확보해야 하며, 특히 여러 팩트를 연결하는 계산은 집계 검증이 필수다.
• 사전 결합과 실행 시점 관계는 상호 배타적인 선택이 아니라 계층별로 함께 사용할 수 있으며, 항상 함께 쓰이고 같은 세분성을 가진 테이블은 데이터셋 내부에서 결합하고 독립적으로 관리할 비즈니스 개념은 토픽에서 관계로 연결하는 방식이 적절하다.

✅ 액션 아이템

• Quick Sight 토픽에서 개별 데이터셋을 유지한 채 연결 키를 정의하고, 실행 시점에 필요한 데이터셋만 조인해 재사용 가능한 모델 구조로 전환한다.
• 권장 스타 스키마 기준으로 대리 키·자료형 일치·참조 무결성·세분성 호환성을 확인해 다중 데이터셋 관계의 논리 정의 신뢰도를 점검한다.
• 내부조인 제약이 드러나는 외부조인 필요 시점과 단순·소규모 분석 구간을 선별해 사전 결합 데이터셋을 병행 적용 범위로 분기한다.

❓ 열린 질문

• 다중 데이터셋 관계의 내부조인 동작이 자연어 탐색 질문에서 결과 누락을 유발하지 않도록 어느 지표로 조인 적합성을 판단할 것인가?
• 세분성이 다른 측정값이 섞일 때 논리 레이어 결합에서 중복 산출이 생기는지를 어떤 방식으로 조기에 감지할 것인가?
• 물리 계층(집계·변환·조인)과 논리 계층(주제 내 관계)을 어느 기준으로 분리하면 성능과 관리 효율의 균형이 가장 안정적인가?