Google PDE: 데이터 엔지니어링 아키텍처 및 설계 — 학습 가이드

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

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

개요

Google Cloud에서의 데이터 엔지니어링 아키텍처 및 설계는 도메인 경계, 처리 패턴, 서비스 기능을 균형 있게 조정하여 안정적이고 확장 가능하며 비용 효율적인 데이터 플랫폼을 제공합니다. 효과적인 설계는 스토리지, 컴퓨팅, 오케스트레이션, 서빙을 독립적으로 확장할 수 있도록 만들고, 도메인 간 상호 운용을 위해 계약을 코드화하며, 측정 가능한 서비스 수준 목표(SLO)를 통해 조기에 리스크를 검증합니다. 이 섹션에서는 표준적인 아키텍처 스타일(데이터 메시, 레이크, 웨어하우스, 레이크하우스, 운영 스토어), 처리 모드(배치, 마이크로 배치, 스트리밍, 이벤트 기반, 람다), 그리고 확장성, 지연 시간, 가용성, 일관성, 비용 간의 트레이드오프를 요약합니다. 또한 지역 및 멀티 클라우드 배치, 스키마 진화, 엔드투엔드 데이터 수명 주기, 워크로드 기반 서비스 선택, Google Cloud에 특화된 리스크 기반 검증 방식에 대해서도 다룹니다.

아키텍처 패러다임 및 처리 패턴

• 데이터 메시, 도메인, 데이터 제품:
  • 도메인 팀이 명확한 소유권, SLO, 액세스 정책, 문서를 갖춘 “데이터 제품"을 게시할 수 있도록 지원합니다. Dataplex를 사용하여 도메인을 정의하고, 메타데이터를 거버넌스하며, BigQuery와 Cloud Storage 전반에 일관된 정책을 적용합니다. 제품은 Pub/Sub 스키마와 BigQuery 테이블 스키마를 통해 계약이 강제되는 BigQuery 데이터 세트, Pub/Sub 토픽 또는 Cloud Storage 경로를 노출할 수 있습니다.
• 데이터 레이크:
  • 수명 주기 및 버전 관리가 적용된 Cloud Storage의 원시(raw), 개방형 형식(Parquet/Avro) 스토리지입니다. 이기종 워크로드(Dataproc의 Spark, Dataflow, Presto/Trino)와 멀티 클라우드 이식성에 적합합니다. 트레이드오프: 객체 스토어의 최종적 일관성(eventual consistency) 의미 체계. 멱등성(idempotency)과 메타데이터 기반 중복 제거를 고려하여 설계해야 합니다.
• 데이터 웨어하우스:
  • BigQuery에서 큐레이션되고 거버넌스가 적용된 분석 환경입니다. ANSI SQL, 스토리지/컴퓨팅 분리, 세분화된 보안에 최적화되어 있습니다. 트레이드오프: 스트리밍 삽입은 쿼리 시점에 짧은 데이터 비신선도(staleness)를 보일 수 있습니다. 엄격한 신선도 SLA를 위해서는 배치 로드나 버퍼링된 쿼리를 사용한 삽입을 선호합니다.
• 레이크하우스:
  • 개방형 데이터 레이크 스토리지와 웨어하우스 기능을 결합합니다. Google Cloud에서는 Cloud Storage에 Parquet/Avro를 저장하고, 경제성을 위해 BigQuery 외부 테이블을, 성능과 거버넌스를 위해 BigQuery 관리형 테이블을 사용합니다. Dataflow 또는 Dataproc은 파티셔닝/클러스터링 전략을 사용하여 ACID와 유사한 병합(merge) 의미 체계를 유지합니다.
• 운영 스토어 아키텍처:
  • 애플리케이션을 지원하는 짧은 지연 시간의 트랜잭션 또는 키-값 스토어입니다. 전통적인 OLTP에는 Cloud SQL을, 수평적 확장이 가능한 전역 일관성 SQL에는 Cloud Spanner를, 매우 높은 처리량의 와이드 컬럼 액세스 패턴에는 Bigtable을 선택합니다. 운영 스토어와 분석 시스템을 분리하고, CDC(Datastream)를 사용하여 변경 사항을 캡처하여 Pub/Sub, Cloud Storage 또는 BigQuery로 전송합니다.

처리 패턴 및 사용 시기:

• 배치: 주기적이고 대규모의 변환 작업(예: 야간 피처 생성). 도구: Dataflow 배치, Dataproc. 실패 모드: 장기 실행 작업 시간 초과, 스큐(skew). 오토스케일링 및 재파티셔닝으로 완화합니다.
• 마이크로 배치: 신선도와 안정성, 비용의 균형을 맞추기 위한 작고 빈번한 배치(예: 매분). BigQuery에서는 예약된 쿼리나 고정 윈도우를 사용하는 Dataflow를 사용합니다.
• 스트리밍: 무한 데이터에 대한 밀리초에서 초 단위의 지연 시간. Pub/Sub + Dataflow를 사용합니다. 이벤트 시간 윈도우와 워터마크로 지연/순서가 맞지 않는 이벤트를 처리하고, 중복을 방지하기 위해 멱등성을 보장합니다.
• 이벤트 기반: 변경 사항(GCS finalize, Pub/Sub 메시지)에 의해 트리거됩니다. 상태 비저장(stateless) 반응에는 Cloud Functions 또는 Cloud Run을, 상태 저장(stateful) 처리에는 Dataflow를 사용합니다. 트레이드오프: 이벤트당 비용 대 처리량.
• 람다 패턴: 정확성과 재처리를 위해 스트리밍 경로와 배치 경로를 모두 유지합니다. 복잡성이 두 배가 되므로, 불변 로그(Pub/Sub에서 Cloud Storage로 아카이빙)에서 모든 것을 재실행할 수 있는 카파(Kappa)와 같은 단순화 방식을 고려합니다.

지연 데이터 처리를 위한 간단한 Dataflow 스트리밍 구성 예시:

events
  .apply(Window.into(FixedWindows.of(Duration.standardMinutes(5)))
    .withAllowedLateness(Duration.standardMinutes(10))
    .accumulatingFiredPanes());

도메인 소유권, 데이터 제품, 계약

• 소유권 및 SLO:
  • 각 도메인 팀은 가용성, 지연 시간, 데이터 품질 SLO를 포함하여 자체 데이터 제품을 정의하고 운영합니다. Dataplex 카탈로그를 통해 SLO를 게시하고 Cloud Monitoring SLI(예: 정시 파티션 완료율)로 모니터링합니다.
• 계약 및 상호 운용성:
  • Pub/Sub Schema Registry(Avro/Proto)와 BigQuery 테이블 스키마를 사용하여 스키마를 강제합니다. CSV 수집의 경우, Dataflow에서 유효성을 검사하고 형식이 잘못된 행은 분류를 위해 데드-레터(dead-letter) 테이블로 라우팅합니다. 여러 엔진이 동일한 데이터를 읽어야 할 경우, Cloud Storage의 개방형 형식과 BigQuery 외부 테이블을 사용하여 상호 운용합니다.
• 스키마 진화:
  • 하위 호환성을 유지하는 변경을 선호합니다: nullable 컬럼 추가, Avro/Proto에서 optional 필드 추가, 지원 중단 기간 없이 이름 변경/삭제 방지. 버전이 지정된 계약과 지원 중단 일정을 통해 변경 사항을 전달합니다.
  • BigQuery 예시 (하위 호환성을 유지하는 컬럼 추가):

ALTER TABLE sales.orders
ADD COLUMN coupon_code STRING;

• 소비자 영향:
  • 스키마의 시맨틱 버저닝을 유지하고, 마이그레이션 중에는 v1과 v2를 모두 게시합니다. 스트리밍의 경우, 버전이 지정된 토픽으로 라우팅하거나 스키마 버전 필드를 포함합니다. BigQuery에서 승인된 뷰(authorized view)를 제공하여 물리적 변경으로부터 소비자를 격리합니다.
• 거버넌스 및 리니지:
  • 메타데이터, 태그(예: PII), 리니지를 위해 Dataplex와 Data Catalog를 사용합니다. BigQuery에서 행 및 열 수준 보안을 적용합니다. 데이터 손실 방지를 위해, 수집 단계(예: Cloud Run 또는 Dataflow 변환)에서 Cloud DLP를 통합하여 저장 전에 민감한 필드를 토큰화하거나 익명 처리합니다.

비기능적 트레이드오프와 배포 토폴로지

• 확장성:
  • BigQuery는 분석을 위해 탄력적으로 확장됩니다. Bigtable은 노드 수에 따라 선형적으로 확장되지만 핫스팟(hotspotting)을 방지하기 위해 해시 또는 순환 접두사와 같은 신중한 row-key 설계가 필요합니다. Dataflow 자동 확장은 백로그에 대응합니다. Pub/Sub 흐름 제어를 활용하여 역압(backpressure)에 대비하여 설계해야 합니다.
• 지연 시간:
  • BigQuery로 스트리밍하면 삽입 지연 시간은 짧지만 쿼리 시 약간의 지연이 발생할 수 있습니다. 최신 상태 버퍼(freshness buffer) 또는 워터마크 기반 윈도우를 사용하여 쿼리를 설계하십시오. 대규모 환경에서 100ms 미만의 읽기 속도가 필요하다면, 데이터를 미리 계산하여 Bigtable 또는 Memorystore에서 제공하십시오.
• 가용성 및 일관성:
  • Cloud Spanner는 강력한 일관성을 제공하는 전역 분산 SQL 데이터베이스입니다. Bigtable은 클러스터 간 최종적 일관성(eventual consistency)을 갖춘 고가용성을 제공합니다. BigQuery 가용성은 리전 또는 멀티 리전 단위입니다. 복원력(resilience)을 위해 중요한 데이터 세트는 멀티 리전에 구체화(materialize)하십시오.
• 비용:
  • 파티셔닝과 클러스터링으로 BigQuery를 최적화하여 스캔되는 바이트를 줄이십시오. 네트워크가 제한된 링크를 통해 작은 파일을 전송하는 경우, 배치 또는 번들로 묶어 RPC 오버헤드를 줄이십시오. 적절한 경우, 캐시된 대화형 대시보드를 위해 BigQuery BI Engine을 사용하십시오.
• 리전, 멀티 리전, 하이브리드, 멀티 클라우드:
  • 리전 설계는 지연 시간과 비용을 줄입니다. 멀티 리전 스토리지(예: BigQuery 미국/유럽 멀티 리전, Cloud Storage 이중/다중 리전)는 내구성과 지역성(locality) 옵션을 높입니다. DR(재해 복구)을 위해 RPO/RTO를 정의하고 중요한 데이터 세트를 복제하십시오. 하이브리드 시나리오에서는 CDC(변경 데이터 캡처)를 위해 Datastream을, 대량 마이그레이션을 위해 Transfer Appliances 또는 Storage Transfer Service를 사용하십시오. 멀티 클라우드의 경우, Cloud Storage에서 개방형 포맷으로 표준화하고 이식 가능한 컴퓨팅(Apache Beam/Dataflow, Spark on Dataproc)을 사용하되, 이그레스(egress) 및 운영 오버헤드를 인지해야 합니다.

계층화, 수명 주기 및 서비스 선택

• 계층 분리:
  • 스토리지: 원시/브론즈 및 아카이브용 Cloud Storage, 정제/서빙 분석용 BigQuery, 낮은 지연 시간의 키 액세스용 Bigtable, OLTP용 Spanner/Cloud SQL.
  • 컴퓨팅: 서버리스 스트리밍/배치용 Dataflow, Spark/Hadoop 생태계용 Dataproc, 웨어하우스 내 ELT용 BigQuery, 이벤트 마이크로서비스용 Cloud Run/Functions.
  • 오케스트레이션: DAG 및 API 코레오그래피용 Cloud Composer (Airflow) 또는 Workflows, cron과 유사한 트리거용 Scheduler.
  • 서빙: 온라인 읽기용 Bigtable 또는 Spanner, BI용 BigQuery, 대시보드용 Looker/BI Engine, 캐싱용 Memorystore.
• 데이터 수명 주기:
  • 수집: 스트림용 Pub/Sub, 파일용 Storage Transfer 또는 gsutil, SaaS용 Data Transfer Service. 객체 버전 관리를 사용하여 불변의 원시 데이터를 검증, 중복 제거하고 Cloud Storage에 저장합니다.
  • 처리: Dataflow 또는 BigQuery를 사용하여 원시 데이터를 실버(정제, 정형화)로, 그리고 골드(비즈니스용 마트)로 변환합니다.
  • 서빙: 분석을 위해 BigQuery 뷰/테이블을 게시하고, API용으로 피처 또는 예측을 Bigtable에 사전 계산합니다.
  • 보존 및 아카이브: Cloud Storage 수명 주기 규칙을 적용하여 Coldline/Archive 등급으로 전환하고, 보존을 위해 파티션 만료 기능이 있는 BigQuery 시간 파티셔닝을 사용합니다. 필요한 경우 CMEK를 활성화하고 데이터 무단 반출 방지를 위해 VPC Service Controls를 사용합니다.
• 워크로드 특성에 따른 서비스 선택:
  • 넓은 행과 낮은 지연 시간을 갖는 높은 처리량의 시계열 데이터: Bigtable.
  • ANSI SQL을 사용하는 강력한 일관성의 글로벌 OLTP: Cloud Spanner.
  • 보통 규모의 전통적인 관계형 트랜잭션: Cloud SQL.
  • ANSI SQL 및 스토리지/컴퓨팅 분리를 사용하는 페타바이트 규모 분석: BigQuery.
  • 실시간 수집 및 처리: Pub/Sub + Dataflow.
  • 배치 Spark/Hadoop 또는 라이브러리별 도구: Dataproc.

간단한 BigQuery 파티셔닝 예시:

CREATE TABLE ops.events
PARTITION BY DATE(event_ts)
CLUSTER BY device_id AS
SELECT * FROM staging.events_clean;

실용적인 문제 시나리오

Contoso Mobility는 글로벌 전동 스쿠터 플릿을 운영하며, 주행 원격 측정 및 결제를 위한 실시간 수집, 처리, 저장 및 분석이 필요합니다. 분당 수백만 개의 이벤트, 초 단위 미만의 사기 탐지 규칙, 최신 대시보드, 개인정보 보호 제어, 복원력 있는 다중 리전 운영을 지원해야 합니다.

접근 방식:

1. Cloud Pub/Sub으로 이벤트 수집 시스템을 구축합니다.

• 근거: Pub/Sub은 단일 글로벌 엔드포인트, 내구성 있는 버퍼링, 폭증하는 기기 트래픽에 대한 수평 확장을 제공합니다. 1시간 윈도우 내에서 기기 내 순서를 보장하기 위해 스쿠터별 순서 지정 키를 사용합니다.

2. Cloud Dataflow (Apache Beam)로 스트리밍 처리를 구현합니다.

• 근거: Dataflow 자동 확장은 트래픽 급증을 처리하며 멱등성 키와 결합 시 정확히 한 번 전송되는 싱크를 제공합니다. 이벤트 시간 윈도우와 워터마크를 사용하여 지연되거나 순서가 맞지 않는 원격 측정 데이터를 처리합니다. 정제된 스트림으로의 주 출력과 데드 레터 레코드를 위한 부가 출력을 내보냅니다.
• 구성:

.withAllowedLateness(Duration.standardMinutes(15))
.discardingFiredPanes();

3. 원시 데이터와 정제된 데이터를 각각 Cloud Storage와 BigQuery에 영구 저장합니다.

• 근거: 재처리 및 감사를 위해 원시(브론즈) Avro 파일을 이중 리전 Cloud Storage 버킷에 저장합니다. 정제된(실버) 스트림을 분석을 위해 BigQuery 파티션된 테이블에 쓰고, 효율적인 단일 항목 조회를 위해 scooter_id에 클러스터링을 적용합니다. 일시적인 스트리밍 데이터의 비최신성을 피하기 위해 대시보드 쿼리에 작은 최신성 버퍼를 적용합니다.

4. Cloud Bigtable에서 운영 조회 및 사기 탐지를 처리합니다.

• 근거: 100ms 미만의 규칙 평가에는 낮은 지연 시간의 랜덤 액세스가 필요합니다. Dataflow에서 집계(예: 5분 윈도우당 기기별 주행 횟수)를 사전 계산하고, 핫스팟을 방지하고 태블릿 간 읽기를 병렬화하기 위해 해시 접두사 행 키(예: h(prefix)+device_id+window_start)를 사용하여 Bigtable에 씁니다.

5. Cloud Spanner에서 트랜잭션 기반 결제를 관리합니다.

• 근거: 결제에는 전역적으로 일관된 SQL, 강력한 일관성, 고가용성이 필요합니다. 고객 포털의 읽기 지연 시간을 줄이기 위해 주요 지역에 리더를 두고 보조 리전에 읽기 전용 복제본을 사용합니다.

6. Dataplex, Data Catalog, Cloud DLP로 거버넌스를 적용합니다.

• 근거: PII 필드를 분류하고, 데이터 세트에 태그를 지정하며, BigQuery에서 열 수준 보안을 적용합니다. Dataflow 파이프라인에 Cloud DLP를 통합하여 저장 전에 민감한 속성을 토큰화합니다. Dataplex 도메인은 조직의 소유권을 반영하며, 각 도메인은 SLO가 포함된 문서화된 데이터 제품을 게시합니다.

7. Cloud Composer와 Cloud Monitoring으로 오케스트레이션 및 운영을 수행합니다.

• 근거: Composer는 배치 백필, 압축, ML 피처 구체화를 조정합니다. Monitoring은 Pub/Sub 백로그, Dataflow 워터마크 지연, BigQuery 파티션 완전성, Bigtable 테일 지연 시간과 같은 엔드투엔드 SLI를 관찰합니다. SLO 위반 시 알림을 보내고, 백로그 증가에 따라 Dataflow를 자동 확장합니다.

8. 파티셔닝과 등급 지정을 통해 비용 및 수명 주기를 최적화합니다.

• 근거: BigQuery 테이블은 event_ts로 파티셔닝되고 90일 보관 정책이 적용되며, scooter_id로 클러스터링됩니다. Cloud Storage는 수명 주기 규칙을 사용하여 30일 후 원시 데이터를 Coldline으로, 180일 후 Archive로 전환합니다. 예약된 BigQuery 작업은 작은 마이크로 배치 파일을 더 큰 parquet 객체로 압축하여 다운스트림 Spark 작업의 파일 수 오버헤드를 줄입니다.

9. 위험 및 복원력을 검증합니다.

• 근거: 예상 최고치의 2배로 부하 테스트를 수행하여 Pub/Sub 할당량 및 Dataflow 자동 확장을 검증합니다. 리전 장애 조치 훈련을 수행합니다: BigQuery 다중 리전 데이터 세트와 이중 리전 버킷은 가용성을 유지하며, Spanner의 다중 리전 인스턴스는 자동 장애 조치를 통해 RPO=0 및 구성된 RTO를 유지합니다. 정책 검증 기능이 있는 코드형 인프라(Terraform)를 사용하여 CMEK 및 VPC Service Controls를 강제 적용합니다.

이 아키텍처는 역할을 명확하게 분리합니다: Pub/Sub은 수집을 버퍼링하고, Dataflow는 계산하며, Cloud Storage와 BigQuery는 분석 데이터를 저장하고 서빙하며, Bigtable은 운영 읽기를 가속화하고, Spanner는 일관된 트랜잭션을 보장합니다. 파티셔닝, 클러스터링, 수명 주기 정책, 자동 확장을 통해 비용을 제어하면서 확장성과 지연 시간의 균형을 맞추고, 문서화된 데이터 제품, 계약 및 지속적인 검증을 통해 거버넌스와 안정성을 내장합니다.

모든 도메인 · 데이터 스토리지 →

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

Google 찾아보기 →