Google PDE: 데이터 스토리지, 레이크 및 파일 형식 — 학습 가이드

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

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

개요

Google Cloud의 데이터 스토리지는 원시 객체 스토리지, 큐레이션된 데이터 레이크, 분석에 최적화된 형식을 아우릅니다. 신뢰할 수 있고, 거버넌스가 적용되며, 성능이 뛰어난 레이크를 구축하려면 스토리지 클래스, 버킷 설정, 위치, 파일 형식, 테이블 레이아웃 및 수명 주기를 신중하게 선택해야 합니다. 이 섹션에서는 설계상의 장단점, 피해야 할 장애 모드, 그리고 대규모 BigQuery, Spark, 스트리밍 파이프라인과 부합하는 패턴에 대해 자세히 설명합니다.

Cloud Storage 기본: 클래스, 버킷, 일관성 및 수명 주기

Cloud Storage는 원시 파일과 큐레이션된 파일을 위한 내구성 있고 가용성이 높은 기반입니다.

• 스토리지 클래스

  • Standard (핫): 빈번한 액세스, 가장 낮은 지연 시간. 최소 스토리지 기간 없음.
  • Nearline (쿨): 드문 액세스(월 1회 정도). 최소 30일; 검색 수수료 적용.
  • Coldline (콜드): 드문 액세스(분기 1회 정도). 최소 90일; 더 높은 검색 수수료.
  • Archive (콜디스트): 장기 보관(연 1회 정도). 최소 365일; 가장 높은 검색 수수료.
  • Autoclass는 클래스 간에 자동으로 전환할 수 있습니다. 조기 삭제 수수료와 액세스 패턴이 비용 절감 효과를 저해하지 않는지 확인해야 합니다.

• 버킷 위치 및 복제

  • 리전: 단일 지역 내에서 데이터 지역성 및 규정 준수에 가장 적합합니다.
  • 이중 리전: 자동 복제가 이루어지는 두 개의 쌍으로 된 리전; 터보 복제는 분 단위로 측정되는 RPO로 복제본을 신속하게 커밋합니다. 낮은 RPO의 DR에 이상적입니다.
  • 다중 리전: 넓은 가용성, 콘텐츠 배포 및 넓은 지역에 걸친 분석을 위해 대륙 내에 지리적으로 분산됩니다.
  • 데이터 상주 법률을 충족하고 컴퓨팅(Dataproc, Dataflow, BigQuery 외부 테이블)으로의 이그레스/지연 시간을 최소화하기 위해 위치를 선택하십시오.

• 일관성 및 시맨틱

  • Cloud Storage는 강력한 전역적 쓰기 후 읽기, 메타데이터 업데이트 후 읽기, 쓰기 후 목록 조회 일관성을 제공합니다.
  • 객체 쓰기는 원자적이며 불변입니다. “이름 변경"은 복사 후 삭제 패턴입니다. 멱등성 복사를 위해 설계하고 체크섬을 확인하여 부분적인 마이그레이션을 방지하십시오.

• 액세스 패턴 및 성능

  • 병렬 복합 업로드와 재개 가능한 업로드는 대용량 파일의 처리량을 향상시킵니다.
  • 범위 읽기는 효율적인 열 형식 푸터 및 선택적 읽기를 가능하게 합니다.
  • 메타데이터/목록 조회 오버헤드를 증가시키는 작은 파일(<8 MB)이 많은 경우를 피하고, 배치 처리하거나 더 큰 객체로 압축하십시오.
  • GZIP은 분산 읽기를 위해 분할할 수 없습니다. 확장 가능한 처리를 위해 Parquet/ORC/Avro+Snappy를 선호하십시오.

• 수명 주기, 보관 및 버전 관리

  • 버킷 수준 보관 정책 및 객체 보류(이벤트 기반 또는 임시)는 규정 준수를 위해 불변성을 강제하고 우발적인 삭제를 줄입니다.
  • 객체 버전 관리는 이전 세대를 보관합니다. 덮어쓰기/삭제로부터 복구하는 데 유용합니다. 스토리지 비용 증가를 모니터링하십시오.
  • 수명 주기 규칙은 전환 및 삭제를 자동화합니다. 예시(JSON)는 오래된 데이터를 더 차가운 스토리지로 이동하고 1년 후에 삭제합니다: { “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 30}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }
  • 장애 모드: 너무 공격적으로 전환할 경우 조기 삭제 요금이 부과될 수 있습니다. 보관 잠금은 단축할 수 없습니다. 압축 없는 버전 관리는 비용을 증가시킬 수 있습니다.

• 전송 및 마이그레이션

  • 온프레미스 또는 다른 클라우드에서 병렬화되고 체크포인트가 있는 이동을 위해 Storage Transfer Service를 사용하십시오. 오프라인 페타바이트 데이터에는 Transfer Appliance를 사용하십시오.
  • 경합 상태를 방지하기 위해 CRC32C/MD5 및 생성 일치 전제 조건으로 무결성을 검증하십시오.
  • gsutil/gcloud storage를 -m(병렬) 옵션 및 체크섬과 함께 사용하는 것을 선호하십시오. 대용량 인그레스를 위해 SFTP 병목 현상을 피하십시오.

BigLake와 Dataplex를 사용한 통합 레이크 거버넌스

BigLake와 Dataplex는 파일과 테이블 전반에 걸쳐 보안 및 거버넌스를 표준화합니다.

• BigLake

  • Cloud Storage 데이터를 행 액세스 정책 및 열 수준 정책 태그를 포함한 균일하고 세분화된 액세스 제어를 갖춘 BigQuery 관리 테이블(외부)로 노출합니다.
  • Parquet/ORC에 대한 열 프루닝 및 술어 푸시다운을 활성화하여 BigQuery, Dataproc의 Spark, Dataflow와 같은 엔진으로의 스캔 바이트 및 이그레스를 줄입니다.
  • Cloud Logging을 통한 중앙 집중식 감사 및 중앙 정책 시행을 가능하게 합니다. 레이크 파일과 웨어하우스 테이블을 위한 단일 제어 평면입니다.

• Dataplex

  • 데이터를 레이크, 영역(raw, curated, trusted), 애셋(버킷, 데이터세트)으로 구성하고 메타데이터, 리니지, 데이터 품질 규칙을 관리합니다.
  • 민감한 열에 대한 정책 태그와 통합되며 레이크/영역/애셋 범위에서 IAM을 통해 최소 권한을 지원합니다.
  • 여러 팀 환경에서 “정리되지 않은 데이터 저장소"를 피하기 위해 표준화된 이름 지정, 파티셔닝 및 스키마 관리를 권장합니다.

• 거버넌스 패턴

  • 테넌트별 데이터세트 및 영역별 버킷 패턴을 구현하십시오. 테넌트 간 데이터 유출을 피하십시오.
  • PII에 대해 행 액세스 정책 및 열 정책 태그를 사용하십시오. 승인된 ID에만 API 액세스를 제한하십시오.
  • Cloud Logging으로 액세스를 감사하고, 필터링된 로그를 실시간 모니터링을 위해 Pub/Sub으로 라우팅하십시오.

파일 형식, 압축 및 쿼리 동작

올바른 형식을 선택하는 것은 비용과 성능에 결정적인 영향을 미칩니다.

• 컬럼 기반 형식 (Parquet, ORC)

  • 장점: 컬럼 프루닝(column pruning), 조건자 푸시다운(predicate pushdown), 컬럼별 인코딩 및 압축, 통계, 분할 가능한 파일.
  • 단점: 쓰기 시 더 높은 CPU 사용량, 스키마 진화(schema evolution)는 신중하게 관리해야 함 (예: 컬럼 추가는 안전, 타입 변경은 위험).
  • 압축: 속도를 위해서는 Snappy, 지원되는 경우 더 나은 압축률을 위해서는 ZSTD를 사용합니다. 상호 운용성 제약 조건이 없는 한 컬럼 기반 형식에는 GZIP 사용을 피하세요.

• 행 기반 Avro

  • 장점: 강력한 타이핑을 통한 스키마 진화, 블록 수준 압축, 분할 가능, 스트리밍 랜딩 존(landing zone) 및 데이터 교환에 탁월함.
  • 단점: 분석 시 컬럼 기반 형식보다 스캔 효율성이 낮음. 큐레이션된 영역(curated zone)에서는 Parquet/ORC로 변환하세요.

• CSV 및 JSON (반정형)

  • CSV: 사람이 읽을 수 있고, 값이 단순할 때 오버헤드가 가장 작음. 스키마, 타입, 이스케이프(escape) 일관성이 부족하며, 대규모로 파싱하는 데 비용이 많이 듦.
  • JSON: 자체 설명적(self-describing)이고 유연함. 확장 가능한 분산 읽기를 위해서는 줄 바꿈으로 구분된 JSON(newline-delimited JSON)이 필요함. 장황하고 파싱 시 CPU 사용량이 많음.
  • 권장 사항: 가능하면 원시 CSV/JSON을 먼저 랜딩한 후, 유효성을 검사하고 분석을 위해 Avro/Parquet으로 변환하세요.

• BigQuery 외부 테이블 및 BigLake 테이블

  • Parquet/ORC 외부 테이블은 푸시다운 및 컬럼 프루닝의 이점을 활용하지만, CSV/JSON은 일반적으로 그렇지 않아 스캔되는 바이트가 더 많아집니다.
  • 압축된 CSV(GZIP) 외부 테이블은 워커(worker) 간에 분할할 수 없으므로 읽기 속도가 느려질 수 있습니다.
  • 예시: Hive 스타일 파티션을 사용하여 Parquet BigLake 테이블 생성: CREATE EXTERNAL TABLE lake.sales WITH CONNECTION us.biglake_conn OPTIONS ( format = ‘PARQUET’, hive_partitioning_mode = ‘AUTO’, hive_partitioning_source_uri_prefix = ‘gs://corp-raw/sales/’, uris = [‘gs://corp-raw/sales/date=/region=/part-*.parquet’] );

레이아웃, 파티셔닝, 성능 엔지니어링, 상주 위치 및 마이그레이션

• 객체 레이아웃 및 파티셔닝

  • 파티션 및 클러스터링 키에 Hive 스타일 경로를 채택합니다: gs://bucket/dataset/table/date=YYYY-MM-DD/hour=HH/region=us/part-00001.parquet
  • 균형 잡힌 병렬 처리와 태스크 오버헤드를 위해 개별 파일 크기를 128–1024MB 범위로 유지합니다. 파티션당 수백만 개의 파일이 생기지 않도록 방지합니다.
  • 다음과 같은 방법으로 작은 파일 문제를 완화합니다:
    • 클라이언트 측에서 업로드를 일괄 처리합니다.
    • 피크 시간이 아닐 때 Dataflow/Spark 압축 작업을 사용하여 작은 파일을 병합합니다.
    • 원본 소규모 파일을 보관하고 압축된 데이터만 분석에 노출합니다.

• BigQuery 파티셔닝 및 클러스터링

  • 수집 시간 또는 카디널리티가 높은 필터 열(예: event_date)을 기준으로 파티션을 나눕니다. 메타데이터를 폭증시키는 과도한 파티셔닝(예: 분 단위)은 피합니다.
  • 자주 필터링/정렬되는 차원(최대 4개)을 기준으로 클러스터링합니다. 클러스터링은 데이터 지역성을 높이고 스캔되는 바이트를 줄입니다.
  • 대규모 대화형 분석에는 네이티브 BigQuery 테이블을 선호하고, 거버넌스가 적용된 레이크 액세스, 교차 엔진 공유, 비용 분리를 위해서는 BigLake/외부 테이블을 사용합니다.

• 쿼리 성능에 미치는 영향

  • 열 형식은 외부 스캔 비용을 실질적으로 줄입니다. CSV/JSON 외부 테이블은 종종 전체 파일 스캔이 필요합니다.
  • 일관성 보장으로 Cloud Storage 읽기 시 인위적인 지연이 필요 없지만, 다운스트림 시스템(예: BigQuery 스트리밍 삽입)은 짧은 데이터 가시성 지연을 보일 수 있습니다. 필요한 경우 워터마크 또는 읽기 지연을 사용하여 설계해야 합니다.

• 상주 위치, 내구성 및 복구

  • 상주 위치 제약 조건을 충족하도록 버킷/데이터 세트 위치를 선택하고, 컴퓨팅을 동일 위치에 배치하여 이그레스 및 지연 시간을 단축합니다.
  • 낮은 RPO를 위해 터보 복제가 포함된 이중 리전을 사용하고, 인적 오류 및 랜섬웨어로부터의 복구 가능성을 위해 버전 관리 및 보관 정책을 사용합니다.
  • DR을 위해 버킷 복제를 사용하여 버킷을 별도의 프로젝트/리전으로 복제하고 별도의 IAM 경계로 보호합니다.

• 안전한 마이그레이션 및 검증

  • 다단계 계획을 세웁니다: 시드(대량 전송), 증분 동기화(mtime/윈도우 복사), 전환(읽기 전용 소스), 전환 후 검증.
  • 체크섬, 개수, 총 바이트, 샘플 디코딩으로 검증합니다. 테이블 형식 데이터의 경우 행 수와 해시 집계를 비교합니다:

undefined

• 병렬 복사 중 덮어쓰기를 방지하기 위해 사전 조건(ifGenerationMatch)을 사용합니다. 버전 관리 또는 보존된 소스를 사용하여 롤백 기간을 유지합니다.
• 마이그레이션 후 새 액세스 프로필에 따라 수명 주기 및 Autoclass를 활성화하고, 검증이 통과될 때까지 보관 잠금 활성화를 피합니다.

실제 문제 시나리오

Acme Retail은 물류 파트너로부터 지역 Cloud Storage 버킷으로 매일 CSV 파일을 받습니다. 파일에는 가끔 형식이 잘못된 행이 포함되어 있습니다. Acme는 데이터를 저장, 검증하고, 분석에 적합한 형식으로 변환한 후, 거의 실시간 대시보드를 위해 BigQuery에 로드해야 하며, 동시에 잘못된 행은 검사를 위해 보관하고 거버넌스를 적용해야 합니다.

접근 방식:

1. Dataplex에서 원시 데이터 저장 및 거버넌스 적용

   • gs://acme-raw/logistics/에 매핑된 원시 영역(raw zone) 애셋으로 Dataplex 레이크를 생성합니다.
   • 근거: 중앙 집중식 거버넌스, 메타데이터 및 리니지. 영역 수준에서 IAM을 적용하고 민감한 필드에 정책 태그를 지정하여 다운스트림에서 적용합니다.

2. 수명 주기 및 보관 정책 적용

   • acme-raw에 30일 버킷 보관 정책을 적용하고 객체 버전 관리를 활성화합니다.
   • 근거: 파트너의 실수로 인한 덮어쓰기/삭제로부터 보호합니다. 짧은 보관 기간은 비용과 복구 가능성의 균형을 맞춥니다. 버전 관리는 잘못된 전송의 롤백을 용이하게 합니다.

3. Dataflow 배치 파이프라인으로 검증 및 수집

   • 객체 완료 알림 시 매일 Dataflow 작업을 트리거합니다. 스키마 및 레코드별 검증으로 CSV를 읽고, 유효한 레코드는 BigQuery 스테이징(event_date로 파티셔닝)에 쓰고, 파싱/검증 오류는 데드 레터 BigQuery 테이블로 라우팅합니다.
   • 근거: Dataflow는 확장 가능한 병렬 파싱과 강력한 데드 레터 처리를 제공하여 분석가가 잘못된 행을 검사할 수 있도록 합니다. 이는 이기종 CSV 품질에 대한 모범 사례를 반영합니다.

4. 큐레이션된 영역에서 Parquet으로 압축 및 변환

   • 동일한 파이프라인이 검증된 데이터를 gs://acme-curated/logistics/date=YYYY-MM-DD/ 경로에 약 256–512MB 크기의 Parquet 파일로 씁니다.
   • 근거: Parquet은 BigQuery 및 Spark에서 열 프루닝 및 조건자 푸시다운을 가능하게 하여 스캔되는 바이트를 줄이고 지연 시간을 개선합니다. 압축은 파트너의 전송 패턴으로 인한 작은 파일 오버헤드를 완화합니다.

5. BigLake를 통해 거버넌스가 적용된 분석 노출

   • 큐레이션된 Parquet 경로 위에 Hive 자동 파티셔닝을 사용하여 BigLake 외부 테이블을 생성하고, 파트너별 필터를 위해 열 수준 정책 태그 및 행 액세스 정책을 적용합니다.
   • 근거: 중앙 집중식 감사를 통해 BigQuery 및 Spark 전반에 걸쳐 균일하고 세분화된 액세스를 제공합니다. 파티션 프루닝은 날짜 필터에 대한 스캔 비용을 줄입니다.

6. 중요한 집계를 네이티브 BigQuery에 로드

   • 사용량이 많은 대시보드를 위해, 큐레이션된 Parquet 외부 테이블에서 최근 N일간의 데이터를 네이티브 클러스터링, 파티셔닝된 테이블로 수집하는 예약된 BigQuery 작업을 실행합니다.
   • 근거: 네이티브 스토리지는 동시성이 높은 BI를 가속화하는 반면, 외부 BigLake 테이블은 더 넓은 액세스를 위한 거버넌스가 적용된 기록 시스템(system-of-record)으로 유지됩니다.

7. Cloud Logging 및 Pub/Sub으로 모니터링 및 알림

   • Dataflow 및 BigQuery 로드 작업 결과를 Pub/Sub으로 필터링하는 로그 싱크를 생성하고, 모니터링 도구와 통합하여 실패 또는 비정상 행 비율 증가 시 즉시 알림을 받습니다.
   • 근거: 폴링 없이 대상 테이블별 운영 가시성을 확보하고 SRE 관행을 지원합니다.

8. 스토리지 클래스 및 상주 위치 최적화

   • 큐레이션된 Parquet을 14일간 Standard에 보관하고, 수명 주기 규칙을 통해 30일 후 Coldline으로 전환합니다. 원시 버킷과 큐레이션된 버킷 모두 이그레스를 피하기 위해 BigQuery 데이터 세트와 동일한 리전에 저장합니다.
   • 근거: 핫 리드 성능과 비용의 균형을 맞춥니다. 동일 위치 배치는 규정 준수를 유지하고 지연 시간 및 이그레스 요금을 최소화합니다.

9. 엔드투엔드 품질 검증

   • 각 실행 후 스테이징, 큐레이션된 외부 테이블, 네이티브 BigQuery 테이블 간의 개수 및 해시 집계를 비교하고, 이상 징후를 격리합니다.
   • 근거: 스키마 드리프트 또는 수집 회귀를 조기에 감지합니다. 암호화 또는 지문 해시는 전체 재스캔 없이 가벼운 보증을 제공합니다.

이 설계는 데드 레터 분석을 통한 복원력 있는 수집, 효율적인 쿼리를 위한 분석 준비된 Parquet, Dataplex 및 BigLake를 통한 중앙 집중식 거버넌스, 비용 최적화된 수명 주기 정책을 제공하며, 동시에 최소 권한 액세스 및 감사 가능한 운영 원칙을 준수합니다.

← 데이터 엔지니어링 아키텍처 및 설계 · 모든 도메인 · BigQuery 분석 및 웨어하우스 엔지니어링 →

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

Google 찾아보기 →