AWS를 이용한 데이터 엔지니어링(9) - QuickSight

10-1. QuickSight 소개

왜 쓰는걸까?

기존에는 회사 데이터베이스(Redshift 등)에 있는 데이터를 차트로 보여주려면,
백엔드 개발자가 API를 만들고 프론트엔드 개발자가 React나 Vue로 차트 라이브러리를 붙여서 대시보드 웹 페이지를 일일이 개발해야 했다.

하지만 QuickSight 같은 BI(Business Intelligence) 툴을 쓰면 코딩 한 줄 없이,
드래그 앤 드롭만으로 화려한 대시보드를 만들어서 타팀에 공유할 수 있다.

게다가 Serverless구조라서 트래픽이 몰려도 우리가 서버를 늘릴 필요 없이 AWS가 알아서 처리해 준다.

QuickSight

• 비지니스 인텔리전스 (BI) 서비스
• Severless
• 다양한 차트 지원
• 데이터 시각화, 대시보드, ad-hoc 분석 등
• 과금 구조
  • Standard / Enterprise + 사용자 역할별 + 추가 기능

 

기본 개념

1. Data Source

• Redshift 클러스터의 주소와 비밀번호를 입력해서 파이프라인을 꽂는 단계
• Redshift, Aurora, Athena, File (S3, On-premise)

2. Dataset

• 필요한 테이블들을 조인 하거나 필터링해서 분석에 쓸만큰만 정제해둔 데이터 꾸러미
• Data Source에서 추출한 데이터로 생성

3. Analysis

• BI 시각화를 구성하고 편집

4. Visual and Insight

• Analysis 화면을 구성하는 요소
• Chart, Table 등 여러 시각화

5. Dashboard

• Analysis에서 편집 완료하고 Publish(배포)를 누르면 만들어지는 완성본
• Analysis의 read-only version
• 공유하기 위한 목적

 

SPICE vs Direct Query

• SPICE (스파이스) = 초고속 인메모리 캐시 (Cache)
  • QuickSight 안에 있는 자체 초고속 메모리 엔진
    Redshift의 데이터를 미리 퍼와서 QuickSight 안에 복사해 둔다
    (마치 전역 상태 관리 저장소에 데이터를 담아두는 것과 같음)
  • 장점: 사용자가 대시보드를 볼 때 Redshift까지 안 가고 SPICE에서 바로 꺼내주므로 반응 속도가 0.1초 단위로 빠르고
     Redshift에 부하도 전혀 안 준다
  • 단점: 미리 퍼온 데이터라서 과거 데이터. 최신 데이터를 보려면 "매일 새벽 2시에 데이터 퍼오기" 처럼 스케줄링을 걸어줘야 한다.

 

• Direct Query (직접 쿼리) = 매번 새로고침 할 때마다 백엔드에 API 요청
  • 사용자가 대시보드에 접속하거나 필터를 바꿀 때마다 Redshift로 직접 무거운 쿼리가 날아간다.
  • 장점: 1초 전의 최신 데이터도 바로 볼 수 있다. (실시간성)
  • 단점: Redshift가 힘들어하고(부하 발생), 대시보드 로딩이 느리며, 쿼리를 날릴 때마다 비용이 든다.

 

	SPICE (Super-fast, Parallel, In-memory Calculation Engine)	Direct Query
데이터 저장 방식	내부 인메모리 저장소에 데이터를 사전에 적재함	실시간으로 데이터 소스에 직접 쿼리함
장점	빠른 응답 속도, 부하 없음, 비용 예측 가능	실시간 데이터 제공, 저장 공간이 별도로 필요없음
단점	주기적인 데이터 Refresh 필요함, 용량 제한 있음	속도가 느릴 수 있고 데이터 소스에 부하 발생 가능
비용	SPICE 저장 용량에 따른 요금 발생	쿼리 실행 시 데이터 소스 비용 발생