Google PDE: BigQuery 분석 및 웨어하우스 엔지니어링 — 학습 가이드

By Laurynas Brazys · 21 August 2026 · #google #PDE #certification #exam-prep #study-guide

다음의 일부입니다: Google Professional Data Engineer — 학습 가이드. 검증된 답안으로 연습하기: Google 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

BigQuery는 스토리지와 컴퓨팅을 분리하여 거의 무한한 확장성, ANSI SQL, 통합된 거버넌스를 제공하는 서버리스, 컬럼 기반, MPP(대규모 병렬 처리) 분석 웨어하우스입니다. BigQuery에서의 웨어하우스 엔지니어링은 스키마 설계(파티셔닝, 클러스터링, 비정규화 vs 정규화, 중첩 레코드), 수집 패턴(배치 로드, 스트리밍, Storage Write API), 워크로드 관리(주문형 vs 용량 기반 에디션 및 예약) 간의 균형을 맞추는 것입니다. 강력한 보안(승인된 뷰, 행/열 수준 정책, 정책 태그)은 비용 제어 및 성능 도구와 공존하여 스캔되는 바이트를 최소화하고 지연 시간을 줄입니다. 이 섹션에서는 프로덕션 환경에서 예측해야 하는 핵심 설계, 운영, 장애 모드를 다룹니다.

스토리지 및 시맨틱: 데이터세트, 테이블, 뷰, 레이크 액세스

• 데이터세트, 테이블, 뷰:

  • 데이터세트는 IAM 및 거버넌스의 범위를 지정합니다. 격리 및 명확한 결제를 위해 테넌트별 데이터세트를 유지하세요.
  • 표준 테이블은 데이터를 네이티브 형식으로 저장하며, 파티션과 클러스터링이 레이아웃과 프루닝(pruning)을 제어합니다.
  • 뷰는 데이터를 저장하지 않고 SQL 로직을 캡슐화합니다. 승인된 뷰를 사용하면 뷰 소유자가 기본 테이블을 숨기면서 다른 프로젝트나 테넌트에 제한된 하위 집합을 노출할 수 있습니다.
  • 구체화된 뷰(MV)는 사전 계산된 결과를 유지하고 자동으로 새로고침됩니다. 쿼리 재작성은 호환될 경우 MV를 투명하게 사용하며, 호환되지 않는 조건자나 함수는 MV를 우회합니다.
  • 외부 테이블은 Cloud Storage, Google Drive 또는 Google Sheets의 데이터를 참조합니다. 수집을 피하는 대신 편의성을 위해 처리량과 함수 지원을 절충합니다. 반복적인 분석을 위해서는 네이티브 테이블로 수집하세요.

• 파티셔닝, 클러스터링, 중첩 레코드:

  • 수집 시간, DATE/TIMESTAMP/DATETIME 또는 정수 범위로 파티셔닝하여 스캔을 프루닝하세요. 파티션 열에 WHERE 필터를 사용하거나 _PARTITIONDATE와 같은 데코레이터를 사용하여 프루닝을 활성화하세요.
  • 카디널리티가 높고 자주 필터링되거나 조인되는 열(최대 8개)을 기준으로 클러스터링하세요. BigQuery는 자동으로 리클러스터링합니다. 반복적인 소규모 DML은 일시적으로 클러스터링 품질을 저하시킬 수 있습니다.
  • 중첩 및 반복 레코드(STRUCT, ARRAY)는 조인 오버헤드 없이 일대다 관계를 모델링합니다. UNNEST는 신중하게 사용하세요. 큰 배열에 대한 반복적인 UNNEST는 급격한 팬아웃(fan-out)을 유발할 수 있습니다.

• 비정규화 vs 정규화:

  • 조인을 최소화하고 컬럼 기반 스캔을 활용하기 위해 차원 속성을 팩트 테이블로 비정규화하세요. 이는 읽기 중심의 분석에 이상적입니다.
  • 쓰기 증폭, 업데이트 핫스팟 또는 셀프 조인이 경합이나 복잡성을 유발할 때 정규화하세요(예: 셀프 조인 폭증을 피하기 위해 마스터 환자 테이블과 방문 테이블 분리). 하이브리드 방식을 고려하세요: 정규화된 핵심 엔터티와 넓고 비정규화된 팩트 또는 중첩된 자식 구조.

• 구체화된 뷰: 설계 고려사항

  • 파티셔닝된 기본 테이블에 대한 안정적이고 증분적인 집계에 가장 적합합니다. MV 새로고침은 비동기식입니다. 다운스트림 사용자는 데이터 비최신성(staleness) 기간을 허용하거나 대체 방안으로 기본 테이블을 쿼리해야 합니다.
  • 증분 새로고침을 위해 파티션 열로 필터링하고 그룹화하세요. 비결정적 함수, 지원되지 않는 조인 또는 UDF는 MV가 쿼리 재작성 대상에서 제외되게 할 수 있습니다.

• 연합 쿼리, BigLake, 푸시다운:

  • 연합 쿼리는 SQL을 사용하여 외부 시스템(예: Cloud SQL)을 직접 읽습니다. 가벼운 조인이나 일회성 탐색에는 편리하지만, 지연 시간이 더 길고 할당량이 더 엄격합니다. 대규모 분석을 위해서는 BigQuery로 추출하세요.
  • BigLake 테이블은 Cloud Storage 또는 개방형 테이블 형식(예: Parquet)의 데이터에 대한 열 및 행 수준 제어를 통해 레이크와 웨어하우스 거버넌스를 통합합니다. 조건자 및 프로젝션 푸시다운은 다운로드되는 바이트를 줄여줍니다. 그러나 대규모 스캔의 경우 최대 성능을 위해 여전히 네이티브 테이블로 수집하는 것이 유리합니다.

• 와일드카드 테이블 및 레거시 샤드:

  • 와일드카드 쿼리는 날짜 샤딩 테이블을 위한 레거시 패턴입니다. 네이티브 파티셔닝을 선호하지만, 필요할 때는 SELECT ... FROM bigquery-public-data.noaa_gsod.gsod* WHERE _TABLE_SUFFIX >= '2010'와 같이 사용합니다.

쿼리 최적화 및 워크로드 관리

• 파티션 프루닝 및 클러스터링:

  • 콜드 파티션을 스캔하지 않으려면 항상 파티션 열을 기준으로 필터링하세요. BETWEEN을 좁은 범위와 함께 사용하세요.
  • 클러스터링 키는 선택도(selectivity)에 따라 정렬하세요. 앞쪽 키는 빈번한 필터 및 조인과 일치해야 합니다. 카디널리티가 매우 낮은 열에 대한 클러스터링은 피하세요.

• 쿼리 계획 최적화:

  • EXPLAIN 및 실행 세부 정보를 사용하여 스큐된 조인, 대규모 셔플 또는 프루닝되지 않은 스캔을 찾으세요.
  • SELECT 목록과 서브쿼리를 사용하여 초기에 열을 줄이세요. BigQuery는 컬럼 기반이므로 사용되지 않는 열을 효율적으로 제거합니다.
  • 대용량 데이터의 속도/비용 트레이드오프를 위해 근사 집계(예: APPROX_QUANTILES)를 선호하세요.
  • 수집 소스에서 이벤트가 반복될 수 있는 경우 윈도우 함수를 사용하여 중복을 제거하세요:
    • SELECT * EXCEPT(rn) FROM (SELECT t.*, ROW_NUMBER() OVER (PARTITION BY unique_id ORDER BY event_ts DESC) rn FROM my_table t) WHERE rn = 1;

• 조인 및 비정규화:

  • 셔플을 줄이기 위해 조인 키를 클러스터 키로 함께 배치하세요. 극심한 스큐에는 블룸 필터나 사전 집계가 도움이 될 수 있습니다.
  • 핫 조인을 피하기 위해 작고 느리게 변하는 차원(dimension)은 팩트(fact)로 비정규화하세요. 업데이트가 잦은 매우 넓은 차원의 경우, 정규화하고 클러스터 키와 구체화된 조인(materialized join)에 의존하세요.

• 워크로드 관리, 슬롯, 에디션 및 자동 확장:

  • 주문형(On-demand): BigQuery는 쿼리당 컴퓨팅을 탄력적으로 확장하며, 스캔된 TB당 비용을 지불합니다. 청구되는 최대 바이트 및 파티션 프루닝으로 비용을 제어하세요.
  • BigQuery 에디션(Standard, Enterprise, Enterprise Plus)을 사용하는 용량 기반 모델은 슬롯 예약을 사용합니다. 기준 약정을 구매하고, 예약을 생성하며, 프로젝트나 폴더를 할당하세요. 자동 확장은 피크 시간에 슬롯을 추가하고 수요가 감소하면 해제할 수 있습니다. ETL과 BI 간의 간섭을 방지하기 위해 별도의 예약을 사용하세요.
  • 작업 우선순위: 짧은 지연 시간을 위한 대화형(interactive, 기본값), 백필 및 예약된 쿼리를 위한 배치(batch). 배치 작업은 예약이나 서비스에 유휴 용량이 생길 때까지 대기열에 있다가 일반 비용으로 실행됩니다.

• 동시성 및 할당량:

  • 중요한 워크로드를 격리하기 위해 예약 및 할당을 사용하세요. 혼합된 테넌트의 경우, 맞춤형 동시성 한도가 있는 별도의 예약이나 프로젝트에 배치하세요.
  • 기여도 분석을 위해 작업에 라벨을 지정하세요. 슬롯 사용률 및 대기열 지연을 모니터링하기 위해 INFORMATION_SCHEMA.JOBS 및 Cloud Monitoring 메트릭을 확인하세요.

• BI 캐싱 및 최신성:

  • 쿼리 결과 캐시는 동일한 쿼리의 지연 시간/비용을 개선합니다. 1시간 미만의 최신성이 필요한 클라이언트에서는 비활성화하세요. 일부 BI 도구는 데이터를 독립적으로 캐시하므로, 최신 결과를 표시하려면 보고서 캐싱을 비활성화하세요.

수집, 연합 및 복구

• 로드 작업:

  • Cloud Storage에서의 배치 로드(Avro/Parquet 선호)는 안정적이고 비용 효율적입니다. 스키마와 인코딩을 명시적으로 설정하세요. 일치하지 않는 CSV 인코딩은 바이트 단위 불일치의 일반적인 원인입니다.
  • 병합을 피하려면 파티션 데코레이터나 파티션된 테이블로 로드하세요. 대규모 로드의 경우 파티션별로 병렬화하세요.

• 스트리밍 수집 및 Storage Write API:

  • 레거시 스트리밍 삽입은 간단하지만 할당량이 더 엄격하고 몇 초간 최종적 일관성을 보일 수 있습니다. 매우 최근 데이터에 대한 시간 여행(time travel)은 지연될 수 있습니다.
  • Storage Write API는 처리량이 높고 지연 시간이 짧은 쓰기를 위한 권장 경로이며, 더 나은 중복 제거 제어 기능을 제공합니다. 멱등성(스트림 오프셋)을 사용하여 중복을 방지하세요.
  • 애플리케이션 설계는 처리 중인(in-flight) 이벤트를 허용해야 합니다. 예상 가용 시간(예: 관찰된 지연 시간의 2배)만큼 대화형 쿼리를 지연시키거나 수집 시간 파티션에 워터마크를 사용하세요.

• Dataflow 및 데드-레터 설계:

  • 형식이 잘못된 행이 포함된 파트너 제공 CSV의 경우, Dataflow를 사용하여 파싱 및 유효성 검사를 수행하고, 유효한 레코드는 Storage Write API를 통해 BigQuery에 쓰고, 오류는 검사를 위해 데드-레터 테이블로 라우팅하세요.
  • 대규모로 BigQuery를 읽을 때는 쿼리 기반 읽기(fromQuery)를 선호하여 필요한 필드만 선택하고 셔플을 줄이세요.

• 예약된 쿼리 및 변환:

  • ELT 변환, 증분 롤업 및 테이블 유지 관리를 위해 예약된 쿼리를 사용하세요. 파티션되고 클러스터링된 대상에 쓰는 것을 선호합니다. 예약된 쿼리는 기본적으로 배치 우선순위를 가지며 예약과 통합됩니다.

• 알림 및 관찰 가능성:

  • 특정 테이블 삽입 작업에 대한 알림을 트리거하려면 로그 싱크를 사용하여 BigQuery 감사 로그를 Pub/Sub으로 내보내세요:
    • 필터 예시: resource.type=“bigquery_resource” AND protoPayload.methodName=“jobservice.jobCompleted” AND jsonPayload.jobChange.job.jobConfiguration.load.destinationTable.tableId=“target_table”
  • Cloud Logging 감사 로그와 INFORMATION_SCHEMA 뷰를 사용하여 사용 패턴을 파악하고 거버넌스를 시행하세요.

• 시간 여행, 스냅샷 및 클론:

  • 시간 여행(Time travel)을 사용하면 이전 타임스탬프(기본 7일)의 테이블을 쿼리할 수 있습니다. 과거 상태를 읽으려면 FOR SYSTEM_TIME AS OF를 사용하세요.
  • 테이블 스냅샷은 copy-on-write 방식으로 특정 시점의 뷰를 캡처합니다. 일관된 백필이나 복구에 사용하세요. 테이블 클론은 개발 또는 what-if 분석을 위해 거의 즉각적인 메타데이터 복사본을 제공하며, 데이터가 달라지기 전까지는 최소한의 스토리지만 사용합니다.
  • 복구 선택 사항:
    • 작은 실수: 시간 여행을 사용하여 쿼리하고 INSERT…SELECT로 복원합니다.
    • 대규모 복원: 스냅샷 또는 클론에서 생성한 후 교체합니다.
  • 보존 정책을 적용하기 위해 테이블 및 파티션 만료를 설정하세요. 보존 기간이 시간 여행 요구 사항과 일치하는지 확인하세요.

• 연합 소스:

  • 가벼운 조인에는 Cloud SQL 연합을 사용하세요. 지속적인 분석이나 대규모 스캔의 경우, 네이티브 테이블로 추출-로드하는 작업을 예약하세요.
  • Cloud Storage의 Parquet/ORC 위에 있는 BigLake 테이블은 정책 태그를 적용하고 필터 및 열 프로젝션을 푸시다운할 수 있습니다. 하지만 네이티브 스토리지보다 지연 시간이 더 길 것으로 예상됩니다.

← 데이터 스토리지 · 모든 도메인 · Dataflow 및 Apache Beam을 사용한 스트림 처리 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Google 찾아보기 →