Google PDE: Ład danych, bezpieczeństwo, niezawodność i zarządzanie kosztami — Przewodnik do nauki

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

Część Google Professional Data Engineer — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Google, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Ta sekcja podsumowuje wzorce projektowe i praktyki operacyjne dotyczące ładu danych, bezpieczeństwa, niezawodności i operacji kosztowych w Google Cloud. Skupia się na usługach BigQuery, Cloud Storage, Dataflow, Dataplex i usługach pomocniczych. Nacisk kładziony jest na zasadę najmniejszych uprawnień, zarządzanie kluczami szyfrowania, metadane i klasyfikację, dostęp oparty na politykach, dowody zgodności, obserwowalność z użytecznymi celami SLO oraz kontrolę kosztów. Uwzględniono kompromisy, tryby awarii i praktyczne konfiguracje, aby umożliwić tworzenie bezpiecznych, audytowalnych i wydajnych platform danych.

Tożsamość, dostęp i ład organizacyjny

IAM, konta usług, impersonacja, tożsamość obciążeń, zasada najmniejszych uprawnień
- Granice tożsamości
  - Użytkownicy i grupy za pośrednictwem Cloud Identity lub Google Workspace
  - Konta usług dla obciążeń; przypisuj role o wąskim zakresie na najniższym praktycznym poziomie zasobu (np. zbiór danych zamiast projektu)
- Zasada najmniejszych uprawnień
  - Preferuj role predefiniowane nad rolami podstawowymi; dla BigQuery używaj ról takich jak bigquery.dataViewer na zbiorach danych zamiast roli viewer na poziomie projektu
  - Nadawaj uprawnienia grupom; zarządzaj członkostwem w IdP, a nie uprawnieniami IAM per użytkownik
  - Podział obowiązków: oddzielne role do zarządzania kluczami, dostępu do danych i administracji
- Impersonacja i Workload Identity Federation
  - Używaj impersonacji konta usługi (rola roles/iam.serviceAccountTokenCreator), aby systemy CI/CD lub automatyzacja nigdy nie przechowywały długoterminowych kluczy
  - Używaj Workload Identity Federation z OIDC/SAML, aby umożliwić zewnętrznym tożsamościom uzyskiwanie krótkoterminowych tokenów bez plików kluczy kont usług
- Tryby awarii i środki zaradcze
  - Nadmierne role na poziomie projektu prowadzą do ruchu bocznego (lateral movement); audytuj za pomocą Cloud Asset Inventory
  - Utracone klucze prywatne kont usług: zablokuj tworzenie kluczy; użyj ograniczeń polityki organizacji, aby zablokować pobieranie kluczy; dokonaj rotacji w przypadku znalezienia
Ład organizacyjny w Dataplex, Data Catalog, metadane biznesowe, pochodzenie danych (lineage)
- Dataplex dostarcza jeziora (lakes), strefy (zones) i zasoby (assets), aby zunifikować ład organizacyjny nad BigQuery i Cloud Storage za pomocą scentralizowanych polityk
- Data Catalog przechowuje słownik biznesowy, szablony tagów i metadane techniczne; dołączaj metadane biznesowe (właściciel, klasa PII, RTO/RPO) za pomocą tagów
- Pochodzenie danych (lineage) przechwytuje relacje typu upstream/downstream; używaj integracji pochodzenia danych Dataplex z Dataflow, Dataproc i BigQuery, aby śledzić wpływ i zakres zgodności
- Kompromisy
  - Scentralizowany ład organizacyjny generuje początkowy narzut, ale zmniejsza długoterminowe ryzyko i przyspiesza audyty
Tagi polityk, klasyfikacja, dostęp na poziomie wiersza, maskowanie kolumn
- Klasyfikacja
  - Zdefiniuj taksonomię (np. publiczne, wewnętrzne, poufne, zastrzeżone) w tagach polityk Data Catalog
  - Dołączaj tagi polityk do kolumn BigQuery; powiąż IAM z tagami, aby dostęp podążał za klasyfikacją we wszystkich tabelach
- Maskowanie kolumn
  - Używaj polityk maskowania danych BigQuery do haszowania lub zerowania wrażliwych kolumn dla nieuprzywilejowanych czytelników
  - Przykład:
    - ALTER TABLE fin.payments ALTER COLUMN card_number SET POLICY TAGS (‘pii.restricted’);
- Dostęp na poziomie wiersza
  - Używaj polityk dostępu do wierszy, aby filtrować rekordy według atrybutów, takich jak tenant_id lub region
  - Przykład:
    - CREATE ROW ACCESS POLICY tenant_filter ON sales.orders GRANT TO (“group:analysts@acme.com”) FILTER USING (tenant_id = “acme”);
- Tryby awarii
  - Brak przyznania uprawnień IAM dla tagów polityk kontom usług używanym przez potoki (pipelines) powoduje błędy zapytań; w razie potrzeby dołącz rolę policy tag viewer/accessor dla agentów usług
  - Polityki na poziomie wierszy mogą pogarszać wydajność, jeśli istnieje wiele wysoce selektywnych predykatów per użytkownik; preferuj gruboziarniste zbiory danych per najemca (dataset-per-tenant), gdy wymagana jest ścisła izolacja
Wykrywanie i deidentyfikacja danych wrażliwych
- Używaj Sensitive Data Protection do ciągłego skanowania Cloud Storage i BigQuery; twórz konfiguracje wykrywania (discovery configs) per jezioro/strefa za pomocą szablonów
- Stosuj transformacje deidentyfikacyjne: tokenizację, szyfrowanie deterministyczne dla możliwości łączenia (joinability) lub maskowanie
- Przechowuj klucze transformacji w Cloud KMS; klucze reidentyfikacyjne trzymaj oddzielnie z zastosowaniem podwójnej kontroli
- Kompromisy
  - Szyfrowanie deterministyczne umożliwia operacje join, ale może prowadzić do wycieku informacji o częstotliwości; w razie potrzeby dodaj szyfrowanie z zachowaniem formatu lub bucketing
  - Próbkowanie (sampling) zmniejsza koszt skanów w poszukiwaniu danych, ale może pominąć PII o niskiej częstotliwości występowania

Operacje związane z bezpieczeństwem i zgodnością

Szyfrowanie, Cloud KMS, CMEK i obsługa sekretów
- Szyfrowanie danych w spoczynku (at-rest) i w transporcie (in-transit) jest domyślne; włącz CMEK, gdy wymagana jest kontrola nad kluczami ze względów regulacyjnych (BigQuery, GCS, Pub/Sub, Dataflow)
- Zarządzanie kluczami
  - Umieszczaj klucze w tym samym regionie co dane; nadaj agentowi usługi (np. BigQuery Service Agent) rolę roles/cloudkms.cryptoKeyEncrypterDecrypter
  - Regularnie rotuj klucze; monitoruj klucze wyłączone lub zaplanowane do zniszczenia
- Scenariusze awarii
  - Wyłączenie klucza CMEK lub odebranie uprawnień agentowi usługi uniemożliwia ładowanie danych, wykonywanie zapytań i eksportowanie; skonfiguruj alerty o zmianach stanu klucza
  - Użycie kluczy między regionami jest niedozwolone; dopasuj lokalizacje, aby uniknąć błędów tworzenia zadań
- Sekrety
  - Używaj Secret Manager do przechowywania danych uwierzytelniających do baz danych i tokenów API; nadawaj dostęp przez IAM i przeprowadzaj audyt za pomocą logów Secret Manager
  - Nigdy nie osadzaj sekretów w kodzie, kontenerach ani notatnikach; montuj sekrety poprzez dostęp w czasie wykonania; preferuj uwierzytelnianie bazodanowe IAM tam, gdzie jest ono wspierane
Logi audytowe, przegląd dostępu, dowody zgodności i retencja
- Włącz logi dostępu do danych (Data Access logs) w całej organizacji dla BigQuery, GCS, Pub/Sub; eksportuj je do dedykowanego projektu do logowania z uprawnieniami tylko do zapisu i z włączonym CMEK
- Twórz zagregowane ujścia logów (sinks) do BigQuery (analityka) i Cloud Storage (długoterminowe, niezmienne archiwum z blokadą retencji zasobnika)
- Używaj Cloud Asset Inventory i Policy Analyzer do okresowego przeglądu dostępu i wykrywania dryfu konfiguracji
- Retencja
  - Ustaw retencję logów zgodnie z wymaganiami zgodności; używaj wersjonowania obiektów i polityk retencji w GCS
  - W BigQuery ustaw domyślny czas wygaśnięcia tabeli i polegaj na migawkach tabel/podróżach w czasie (time travel) do krótkoterminowego przywracania; archiwizuj krytyczne zbiory danych w oddzielnych projektach
- Dowody zgodności
  - Utrzymuj mapowanie kontroli za pomocą tagów Dataplex (np. „SOX-C2: Dowód w projekcie X, ujście Y”), automatyzuj eksporty i uruchamiaj zaplanowane zapytania w celu generowania poświadczeń

Niezawodność, obserwowalność, jakość i zarządzanie kosztami

Wymiary jakości danych, frameworki walidacji i reagowanie na incydenty
- Wymiary: dokładność, kompletność, spójność, aktualność, poprawność, unikalność, integralność
- Implementuj walidacje na etapie pozyskiwania i transformacji
  - Zestawy reguł Dataplex Data Quality dla tabel BigQuery i zasobów GCS
  - Great Expectations lub Deequ w Dataflow/Dataproc do sprawdzania schematu i zawartości
- Przekierowuj błędy do tabel lub bucketów typu dead-letter z bogatym kontekstem błędu; unikaj utraty danych poprzez kwarantannę niepoprawnych rekordów
- Reagowanie na incydenty
  - Zdefiniuj poziomy ważności (severities), właścicieli, kanały komunikacji, plany wycofywania zmian (rollback) i macierz RACI
  - Automatyzuj runbooki do uzupełniania danych (backfill) i ponownego przetwarzania wiadomości z dead-letter; wykonuj snapshoty tabel, których dotyczy problem, przed podjęciem działań naprawczych
Cloud Monitoring, logowanie, alerty, budżety błędów i wskaźniki SLO
- Udostępniaj metryki: backlog Dataflow, wykorzystanie slotów BigQuery, opóźnienie zapytań, opóźnienia/błędy GCS, niepotwierdzone wiadomości (unacked messages) w Pub/Sub
- SLO (Service Level Objectives)
  - Przykład: „99,9% zdarzeń strumieniowych dostępnych w BigQuery w ciągu 5 minut w okresie 30 dni”
  - Śledź tempo zużycia budżetu błędów (burn rate) i wysyłaj powiadomienia (page) przy szybkim zużyciu; twórz zgłoszenia (ticket) przy wolnym zużyciu
- Metryki i alerty oparte na logach
  - Twórz metryki oparte na logach dla nieudanych zadań BigQuery, wyników DLP, błędów kluczy KMS
  - Używaj zaawansowanych filtrów logów do alertowania o dołączaniu danych do konkretnych tabel lub anomaliach w dostępie
Alokacja kosztów, budżety, kontrola zapytań, cykl życia przechowywania i planowanie pojemności
- Alokacja i budżety
  - Używaj etykiet (labels) i tagów dla wszystkich zadań, zbiorów danych, bucketów i rezerwacji; eksportuj dane rozliczeniowe do BigQuery i twórz budżety z powiadomieniami Pub/Sub
- Kontrola kosztów w BigQuery
  - Używaj partycjonowania i klastrowania, aby zmniejszyć ilość skanowanych bajtów
  - Ustawiaj maximumBytesBilled dla zadań zapytań; przykład konfiguracji klienta/zadania:
    - “jobConfiguration”: { “query”: { “maximumBytesBilled”: “1073741824” } }
  - Rezerwuj sloty za pomocą BigQuery Reservations dla przewidywalnych obciążeń; oddzielaj zadania interaktywne od wsadowych (batch) za pomocą przypisań (assignments)
- Cykl życia przechowywania danych
  - GCS: reguły cyklu życia (lifecycle rules) do przenoszenia danych do chłodniejszych klas pamięci (colder storage) lub usuwania po N dniach; włącz wersjonowanie obiektów (object versioning), gdy wymagane jest wycofywanie zmian
  - Przykład (w skrócie): Usuwaj nieaktualne wersje po 30 dniach; ustaw politykę retencji (retention policy) na 365 dni dla stref zgodności (compliance zones)
  - BigQuery: domyślny czas wygaśnięcia tabeli (default table expiration) dla tymczasowych zbiorów danych; wykonuj snapshoty przed wprowadzeniem destrukcyjnych zmian
- Planowanie pojemności
  - Dataflow: ustaw maksymalną liczbę workerów (max workers) i autoskalowanie; dobierz odpowiednie typy maszyn (right-sizing); partycjonuj dane wejściowe (shard inputs), aby uniknąć gorących kluczy (hot keys)
  - Pub/Sub: weryfikuj limity (quotas) publikowania/konsumowania oraz retencję wiadomości
  - Sieć: uwzględnij ruch wychodzący (egress), przesyłanie danych między regionami i dostęp do usług prywatnych (private service access) dla baz danych
Odzyskiwanie po awarii (disaster recovery), kopie zapasowe, odporność wieloregionalna i runbooki
- Klasyfikuj usługi według RTO/RPO; wybieraj odpowiednio wzorce cold/warm/hot
- Kopie zapasowe
  - BigQuery: regularne snapshoty tabel; eksport do GCS w celu przechowywania poza platformą, jeśli jest to wymagane
  - GCS: buckety dual-region lub multi-region dla zapewnienia trwałości (durability); włącz blokadę bucketa (bucket lock) dla zgodności z WORM
  - Bazy danych: zarządzane kopie zapasowe w Cloud SQL i Bigtable; testuj odtwarzanie
- Wieloregionalność
  - Utrzymuj zasoby obliczeniowe (compute) i pamięć masową (storage) w tym samym regionie wielofunkcyjnym (multi-region), aby zminimalizować ruch wychodzący (egress) i opóźnienia; unikaj zależności międzykontynentalnych, chyba że jest to wymagane
- Runbooki
  - Dokumentuj procedury przełączania awaryjnego (failover), odzyskiwania kluczy, postępowania w przypadku incydentów z KMS, odtwarzania danych z eksportów (rehydration) i ponownego przypisywania rezerwacji BigQuery
  - Testuj DR poprzez symulacje (game days); mierz czas odzyskiwania (time-to-recover) i aktualizuj wskaźniki SLO

Praktyczny scenariusz problemowy

Firma NovaRetail Analytics współpracuje z wieloma markami, aby codziennie pozyskiwać pliki CSV z danymi transakcyjnymi do współdzielonej platformy analitycznej. Pliki trafiają do docelowego bucketa w Cloud Storage i czasami zawierają nieprawidłowo sformatowane wiersze. Platforma musi egzekwować zasadę najmniejszych uprawnień (least privilege), aby każdy klient miał dostęp tylko do swoich danych, wykrywać pola wrażliwe i dostarczać natychmiastowe alerty, gdy wiersze są dołączane do określonej tabeli audytowej. Firma potrzebuje również kontroli kosztów i planu odzyskiwania danych.

Podejście:

Izoluj najemców (tenants) i egzekwuj zasadę najmniejszych uprawnień
- Utwórz dedykowany zbiór danych (dataset) BigQuery dla każdego klienta (np. client_a_analytics). Nadaj grupie danego klienta tylko odpowiednie role dla zbioru danych (bigquery.dataViewer, bigquery.jobUser) i ogranicz użycie BigQuery API do zatwierdzonych użytkowników za pomocą IAM i, w stosownych przypadkach, VPC-SC.
- Uzasadnienie: Zastosowanie jednego zbioru danych na najemcę ogranicza promień rażenia (blast radius) i upraszcza złożoność polityk na poziomie wierszy. Ograniczenie uprawnień na poziomie zbioru danych domyślnie zapobiega dostępowi między najemcami.
Zarządzaj schematem, klasyfikacją i maskowaniem
- Zdefiniuj taksonomię tagów polityk (policy tag taxonomy) w Data Catalog (public, internal, confidential, restricted) oraz szablony tagów dla właściciela, opiekuna danych (data steward) i RTO/RPO. Dołącz tagi polityk do wrażliwych kolumn (email, card_suffix) w zbiorze danych każdego klienta. Zastosuj polityki maskowania BigQuery, aby ograniczyć widok dla ról bez odpowiednich uprawnień.
- Przykład: ALTER TABLE client_a_analytics.orders ALTER COLUMN email SET POLICY TAGS ('restricted.pii').
- Uzasadnienie: Scentralizowane tagi zapewniają jednolitą kontrolę nad wszystkimi tabelami; maskowanie zapewnia domyślne bezpieczeństwo odczytu bez duplikowania danych.
Wykrywaj dane osobowe (PII) i w razie potrzeby wymuszaj deidentyfikację
- Skonfiguruj wykrywanie (discovery) w Sensitive Data Protection do skanowania docelowego bucketa i wyselekcjonowanych tabel BigQuery. Użyj szablonu inspekcji (inspection template) dla typowych danych PII oraz szablonu deidentyfikacji (de-identification template) do deterministycznej tokenizacji adresów e-mail na potrzeby złączeń (join).
- Uzasadnienie: Zautomatyzowane wykrywanie redukuje błędy manualne; deterministyczna tokenizacja równoważy prywatność z wymaganiami analitycznymi dotyczącymi złączeń.
Zabezpiecz potok za pomocą kont serwisowych, personifikacji i kluczy CMEK
- Użyj konta serwisowego Dataflow tylko z niezbędnymi rolami: storage.objectViewer dla docelowego bucketa, bigquery.dataEditor dla docelowych zbiorów danych oraz dostęp do tagów polityk, jeśli jest to wymagane. Użyj kluczy CMEK dla zbiorów danych klientów i nadaj agentom serwisowym BigQuery i Dataflow rolę CryptoKey Encrypter/Decrypter.
- Uzasadnienie: Wąsko zdefiniowane role w połączeniu z CMEK spełniają wymagania zasady najmniejszych uprawnień i kontroli nad kluczami. Dostęp agentów serwisowych do kluczy zapobiega awariom zadań.
Zbuduj odporny proces pozyskiwania danych z kwarantanną błędów
- Uruchom zadanie wsadowe (batch) Dataflow, które odczytuje pliki CSV, waliduje schemat i zapisuje prawidłowe wiersze do partycjonowanych tabel BigQuery. Przekieruj nieprawidłowe wiersze do tabeli dead-letter w BigQuery ze szczegółami błędu (nazwa pliku, linia, przyczyna).
- Uzasadnienie: Wyjścia boczne (side outputs) zachowują błędne dane do analizy, nie blokując przetwarzania poprawnych danych; partycjonowane tabele zmniejszają koszty skanowania i przyspieszają zapytania.
Twórz pochodzenie danych (lineage) i metadane biznesowe
- Zarejestruj docelowy bucket i zbiory danych jako zasoby (assets) Dataplex w jeziorze danych (lake). Włącz zbieranie pochodzenia danych dla zadania Dataflow i oznacz wyselekcjonowane tabele metadanymi biznesowymi (właściciel danych, wrażliwość, retencja).
- Uzasadnienie: Scentralizowane zarządzanie (governance) umożliwia analizę wpływu, gotowość do audytu i standaryzację opieki nad danymi.
Monitoruj, alertuj i audytuj
- Włącz logi audytowe Admin i Data Access, eksportowane z użyciem CMEK do centralnego projektu logowania oraz do BigQuery w celach analitycznych. Dodaj alert oparty na logach dla nowych wierszy dołączanych do tabeli audytowej, używając zaawansowanego filtra dla zadań wstawiania (insert) w BigQuery; wyeksportuj ten sink do Pub/Sub, aby narzędzie monitorujące mogło go przetworzyć.
- Uzasadnienie: Logi są dowodem odpornym na manipulacje; precyzyjne alerty powiadamiają tylko o wymaganej tabeli, redukując szum informacyjny.
Wprowadź mechanizmy kontroli kosztów i zabezpieczenia zapytań (query guardrails)
- Wymagaj, aby zadania zapytań ustawiały maximumBytesBilled i wykorzystywały klastrowanie dla kolumn o wysokiej kardynalności (np. order_id). Zastosuj budżety i ustaw etykiety