[#16] 스프린트 DA 트랙 25주차 위클리 페이퍼(데이터 웨어하우스의 특징, BigQuery 성능 최적화)

위클리 페이퍼는 현재 훈련받고 있는 코드잇 스프린트 데이터 애널리스트 트랙에서 매주마다 훈련생 스스로 프로그래밍 언어, 데이터분석, 통계, 머신러닝 등 특정 주제에 대하여 심화 학습을 할 수 있도록 제출하는 과제입니다.

(매주 2~3가지 주제를 스스로 알아보고 학습하여 관련된 내용을 정리하여 후에 취업 활동 간에 경험할 수 있는 기술 면접을 대비함.)

---

24주차에 이어 이번 25주차를 마지막으로 마지막 위클리 페이퍼의 내용을 소개하겠습니다.

 

 

이번 16번째 마지막 위클리 페이퍼 주제는

1. On-premise, Cloud, Serverless 데이터 웨어하우스의 특징에 대해 각각 설명해주세요.

---

2. BigQuery에서 쿼리 성능을 최적화할 수 있는 방법에 대해 설명해주세요.

---

1. On-premise, Cloud, Serverless 데이터 웨어하우스의 특징에 대해 각각 설명해주세요.

---

On-Premise 데이터 웨어하우스

데이터 웨어하우스를 온프레미스(On-Premise) 방식으로 구축하면, 모든 하드웨어와 소프트웨어를 기업 내부에서 직접 소유하고 관리합니다. 초기 단계에서 물리적 서버, 스토리지, 네트워크 장비를 구매해야 하며, 전산실과 같은 인프라 환경도 갖춰야 합니다.
이 방식의 가장 큰 장점은 데이터와 시스템에 대한 완전한 통제권을 기업이 유지할 수 있다는 점입니다. 특히, 데이터 보안과 규제 준수 측면에서 민감한 산업(예: 금융, 의료)에서 선호됩니다.
하지만, 단점도 존재합니다. 초기 구축 비용이 높고, 하드웨어 및 소프트웨어 업그레이드와 유지보수를 위한 추가 비용이 지속적으로 발생합니다. 또한, 시스템 확장에는 시간이 오래 걸리며, 운영 효율성을 유지하려면 전문적인 IT 팀이 필요합니다.

---

Cloud 데이터 웨어하우스

클라우드 기반 데이터 웨어하우스는 클라우드 서비스 제공업체(AWS, Google Cloud, Azure 등)가 관리하는 플랫폼 위에 구축됩니다. 사용자는 별도의 하드웨어를 구매할 필요 없이, 인터넷을 통해 서비스를 이용하며, 사용량에 따라 요금을 지불합니다.
이 방식의 가장 큰 장점은 확장성과 유연성입니다. 기업이 데이터 양이나 분석 요구사항에 따라 시스템을 실시간으로 확장하거나 축소할 수 있어, 초기 투자 비용이 낮고, 예측 가능한 운영비를 유지할 수 있습니다.
또한, 클라우드는 전 세계적으로 접근 가능하며, 복잡한 설정 없이 다양한 분석 도구와 통합이 쉽습니다. 그러나 데이터 전송 속도가 중요한 환경에서는 네트워크 대역폭 제한이 문제가 될 수 있으며, 데이터가 클라우드 제공업체의 인프라에 의존하므로 데이터 주권에 민감한 기업은 우려를 가질 수 있습니다.

---

Serverless 데이터 웨어하우스

서버리스(Serverless) 데이터 웨어하우스는 클라우드 기반의 한 형태로, 인프라 관리를 전적으로 클라우드 제공업체에 맡깁니다. 사용자는 데이터 저장, 처리, 분석 작업에만 집중할 수 있습니다.
서버리스의 가장 큰 특징은 자동 확장성입니다. 사용량이 적을 때는 리소스가 최소화되고, 사용량이 많아질 때는 필요에 따라 시스템이 자동으로 확장됩니다. 사용한 만큼만 비용을 지불하므로, 트래픽이 변동이 큰 환경에 적합합니다.
또한, 설정이 간단하고 빠르게 실행 가능하므로, 분석 프로젝트를 빠르게 시작하려는 기업에 유리합니다.
다만, 서버리스 환경은 대규모 데이터 처리나 지속적인 고성능 요구가 있는 경우 비용이 급격히 증가할 가능성이 있습니다. 또한 특정 클라우드 제공업체의 플랫폼에 종속될 위험이 있어, 벤더 종속성(lock-in) 문제가 발생할 수 있습니다.

---

2. BigQuery에서 쿼리 성능을 최적화할 수 있는 방법에 대해 설명해주세요.

---

1. 불필요한 데이터 스캔 줄이기

BigQuery는 스캔한 데이터의 양에 따라 비용이 발생하므로, 필요한 데이터만 조회하도록 쿼리를 설계하는 것이 중요합니다.

• SELECT 구문에서 필요한 컬럼만 명시하기
  SELECT * 대신 필요한 컬럼만 선택하면 불필요한 데이터 스캔을 방지할 수 있습니다.
• 파티션 및 클러스터링 활용
  날짜 기반 파티션을 활용하면 필요한 데이터 범위만 스캔하므로 성능이 크게 향상됩니다. 클러스터링은 특정 키에 따라 데이터를 정렬하여 쿼리 효율을 높입니다.

예시:

SELECT user_id, event_type
FROM `project.dataset.table`
WHERE event_date BETWEEN '2023-01-01' AND '2023-01-31';

 

2. 테이블 구조 최적화

테이블 구조를 효율적으로 설계하면 쿼리 속도와 비용이 모두 개선됩니다.

• 중복된 데이터 제거
  중복 데이터를 정규화하거나 별도의 요약 테이블을 만들어 반복적으로 조회되는 데이터를 미리 계산해 저장합니다.
• 스키마 설계 최적화
  데이터 유형과 크기를 적절히 선택하고, 빈번히 사용되지 않는 데이터를 분리하여 테이블을 단순화합니다.

3. 조인 및 하위 쿼리 최소화

조인 연산은 BigQuery에서 비용이 많이 들 수 있으므로, 가능하면 이를 줄이거나 단순화하는 것이 좋습니다.

• 필요한 데이터만 조인
  필터 조건을 조인 전에 적용하여 쿼리 비용을 줄입니다.
• WITH 구문 사용
  중복 계산을 줄이기 위해 공통 테이블 표현식(CTE)을 활용합니다.

예시:

WITH filtered_table AS (
  SELECT user_id, event_type
  FROM `project.dataset.table`
  WHERE event_date = '2023-01-01'
)
SELECT COUNT(*)
FROM filtered_table;

 

4. 쿼리 실행 계획 이해하기

BigQuery는 실행 계획(Execution Plan)을 통해 쿼리의 성능 병목을 파악할 수 있습니다.

• Query Plan 보기
  쿼리 실행 후 EXPLAIN 기능을 통해 작업 단계, 데이터 스캔량, 병목 현상을 확인합니다.
• 쿼리 최적화 테스트
  실행 계획에서 비효율적으로 보이는 작업을 재구성하여 테스트합니다.

5. 자주 사용하는 데이터 캐싱

BigQuery에서는 반복적으로 실행되는 쿼리에 대해 쿼리 결과를 캐싱하여 성능을 향상시킬 수 있습니다.

• 캐시된 결과 재사용
  동일한 쿼리가 실행되면 BigQuery는 이전 결과를 재사용하여 성능을 높입니다. 이를 활용하려면 데이터가 자주 변경되지 않는 환경에서 적합합니다.

6. 사용자 정의 함수와 UDF 최소화

UDF(User Defined Function)를 사용하면 편리하지만, 실행 속도가 느려질 수 있습니다. 가능하면 내장 함수나 SQL 기능을 활용해 쿼리를 작성하는 것이 좋습니다.

7. 최적화된 데이터 로드 방식 사용

데이터를 BigQuery에 업로드할 때 최적화된 방식을 사용하는 것도 중요합니다.

• Columnar Storage를 유지하기 위해 데이터 형식을 Parquet 또는 Avro로 변환한 후 업로드합니다.
• 적절한 데이터 배치 크기(최대 100MB~1GB)를 유지하여 효율적인 읽기/쓰기 성능을 보장합니다.

---