Google PCA: Przechowywanie danych, bazy danych i architektura analityczna — Przewodnik do nauki

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Przegląd

Projektowanie przechowywania danych, baz danych i analityki w Google Cloud wymaga dopasowania wzorców obciążeń do usług przy jednoczesnym planowaniu trwałości, dostępności, kontroli dostępu, kosztów i odporności operacyjnej. Ta sekcja obejmuje przechowywanie obiektów i zarządzanie cyklem życia; operacyjne bazy danych i pamięci podręczne; hurtownie i przetwarzanie analityczne; architektury pozyskiwania danych; oraz praktyki w zakresie zarządzania, ochrony i wydajności. Wskazuje na wybory projektowe, uzasadnienie operacyjne oraz typowe tryby awarii i kompromisy.

Architektura Przechowywania i Obiektów

Projektowanie bucketów Cloud Storage

Lokalizacja: wybierz region dla obciążeń wrażliwych na opóźnienia i koszty; dual-region dla ciągłości biznesowej z przewidywalnym przełączaniem awaryjnym (failover); multi-region dla globalnego dostępu do odczytu. Dual-region oferuje opcjonalną replikację turbo dla niskiego RPO objętego umową SLA; w przeciwnym razie replikacja jest asynchroniczna.
Przestrzeń nazw i separacja: używaj oddzielnych bucketów dla domen danych, środowisk i poziomów wrażliwości. Stosuj jednolity dostęp na poziomie bucketa (uniform bucket-level access) i zapobieganie dostępowi publicznemu, aby zapewnić spójne uprawnienia.
Klasy pamięci masowej: Standard dla danych gorących (hot); Nearline dla danych rzadko używanych (co miesiąc); Coldline dla dostępu kwartalnego; Archive dla długoterminowego przechowywania. Autoclass może automatycznie optymalizować umieszczanie w klasach przy minimalnym nakładzie pracy operacyjnej.
Zasady cyklu życia: automatyzuj przenoszenie i usuwanie według wieku, klasy pamięci masowej lub prefiksu obiektu. Przykład usunięcia obiektów starszych niż 90 dni: { “rule”: [ { “action”: {“type”: “Delete”}, “condition”: {“age”: 90} } ] } Zastosuj za pomocą: gsutil lifecycle set lifecycle.json gs://my-bucket
Zatrzymywanie i blokady prawne (legal holds): skonfiguruj zasady przechowywania dla bucketa i opcjonalnie zablokuj je, aby zapobiec ich skróceniu (zgodność z przepisami). Blokady oparte na zdarzeniach (event-based holds) i wersjonowanie obiektów umożliwiają odzyskiwanie po przypadkowym usunięciu lub nadpisaniu.
Replikacja: wybierz dual-region dla semantyki spójności synchronicznej na poziomie API z replikacją w tle między dwoma regionami; użyj replikacji między bucketami (dla kopii między projektami lub lokalizacjami), aby spełnić specjalistyczne wymagania RPO/RTO lub rozdziału obowiązków.

Tryby awarii i kompromisy

Niedopasowanie klasy zawyża koszty i opóźnienia. Autoclass redukuje ten problem, ale dodaje narzut związany z zarządzaniem każdym obiektem.
Blokada przechowywania (retention lock) jest nieodwracalna; testuj zasady w środowisku nieprodukcyjnym.
Replikacja poprawia trwałość, ale może zwiększyć opóźnienie zapisu i koszty; projektuj ścieżki odczytu/zapisu dla docelowych lokalizacji.

Wzorce

Data lake: strefy surowe (raw) i przetworzone (curated) w Cloud Storage; zarządzanie za pomocą Dataplex; schematy eksternalizowane w Data Catalog.
Archiwizacja: klasa Archive z blokadą przechowywania (retention lock) dla zapewnienia zgodności, z zewnętrznymi tabelami BigQuery lub przywracaniem na żądanie do rzadkich analiz.
Lakehouse: użyj BigLake do zunifikowania dostępu do Cloud Storage i BigQuery ze spójnymi zabezpieczeniami.

Operacyjne bazy danych i buforowanie

Cloud SQL

Wysoka dostępność: regionalne HA z synchroniczną replikacją do instancji zapasowej (standby); automatyczne przełączanie awaryjne (failover) zwykle w ciągu od kilku sekund do kilku minut. Punkt końcowy instancji pozostaje ten sam, minimalizując zmiany w aplikacji.
Repliki do odczytu: wewnątrzregionalne lub międzyregionalne, asynchroniczne; dobre do skalowania odczytu i odtwarzania po awarii (DR). Monitoruj opóźnienie replikacji (lag); nieaktualne odczyty mogą wpływać na poprawność danych.
Kopie zapasowe i PITR: zaplanowane kopie zapasowe oraz odzyskiwanie do punktu w czasie (point-in-time recovery) przy użyciu dzienników transakcji (zazwyczaj do 7 dni wstecz, w zależności od silnika). Regularnie testuj przywracanie.
Łączność prywatna: prywatny adres IP przez VPC peering zmniejsza ekspozycję na zagrożenia i opóźnienia; planuj zakresy adresów IP, aby uniknąć ich nakładania się.
Migracja: Database Migration Service wspiera migracje z minimalnym czasem przestoju z systemów on-premise lub innych chmur; w przypadku połączeń o dużej przepustowości preferuj Dedicated lub Partner Interconnect zamiast VPN, aby zmniejszyć utratę pakietów i opóźnienia.

Kompromisy i tryby awarii

Przełączenia awaryjne HA resetują połączenia; aplikacje muszą ponawiać próby z mechanizmem backoff. Okna konserwacyjne mogą na krótko obniżyć wydajność.
Długotrwałe transakcje zwiększają opóźnienie replikacji i czas odzyskiwania PITR.
Nadmiarowa przestrzeń dyskowa to tanie ubezpieczenie; niedostateczna liczba IOPS powoduje ukryte awarie pod szczytowym obciążeniem.

Cloud Spanner

Globalna skala i spójność: silnie spójne odczyty/zapisy między regionami przy użyciu TrueTime i zatwierdzania dwufazowego (two-phase commit). Wybierz opcję regionalną dla najniższego opóźnienia zapisu; wieloregionalną dla wyższej dostępności i globalnych odczytów.
Transakcje: spójność zewnętrzna (external consistency) i pełna zgodność z ACID dla wierszy i tabel; transakcje tylko do odczytu skalują się na replikach.
Projekt schematu: wybieraj klucze główne, które unikają hotspotów; używaj tabel z przeplotem (interleaved tables) dla lokalności danych; uwzględnij wzmocnienie zapisu (write amplification) i zachowanie przy uzupełnianiu danych (backfill) dla indeksów wtórnych.
Regionalność: lokalizacja regionu wiodącego (leader region) wpływa na opóźnienie zapisu; konfiguracja wieloregionalna dodaje koszty kworum i opóźnienie zatwierdzenia (commit latency).

Kompromisy

Opóźnienie zapisu rośnie wraz z rozproszeniem geograficznym; unikaj konfiguracji wieloregionalnej, chyba że uzasadniają to wymagania dotyczące dostępności i globalnej dystrybucji.
Koszt bazowy jest wyższy niż w przypadku jednowęzłowych baz danych na maszynach wirtualnych; planowanie pojemności musi być zgodne z celami SLO i przewidywanym wzrostem.

Firestore, Bigtable, Memorystore i ich wybór

Firestore: dokumentowa baza danych dla backendów mobilnych/webowych; silna spójność dla pojedynczych dokumentów; szczegółowe zabezpieczenia; automatyczne indeksowanie. Uważaj na rywalizację (contention) przy często aktualizowanych dokumentach; używaj rozproszonych liczników i zapisów wsadowych.
Bigtable: szerokokolumnowa baza danych o skali petabajtów, ultra-niskich opóźnieniach, dla danych szeregów czasowych i IoT; projektuj klucze wierszy tak, aby unikać hotspotów (np. przez haszowanie lub salting); skaluj przez węzły i klastry; routing wieloklastrowy dla dostępności. Replikacja jest asynchroniczna; silna spójność jest zapewniona na poziomie klastra.
Memorystore for Redis: pamięć podręczna w pamięci RAM (in-memory cache); poziom Basic to pojedyncza instancja (bez HA); poziom Standard zapewnia replikę i automatyczne przełączanie awaryjne (możliwe krótkie rozłączenia). Traktuj jako pamięć podręczną, a nie źródło prawdy; funkcje trwałości (persistence) zmniejszają ulotność danych, ale nie zastępują kopii zapasowych bazy danych.

Wybór w oparciu o obciążenie

Relacyjna z joinami/ACID i umiarkowaną skalą: Cloud SQL.
Globalna relacyjna ze skalowaniem horyzontalnym i spójnością zewnętrzną: Cloud Spanner.
Wysokoprzepustowe szeregi czasowe/telemetria lub bardzo duże zbiory klucz-wartość: Bigtable.
Modele dokumentowe zorientowane na aplikacje z zapytaniami hierarchicznymi: Firestore.
Efemeryczna akceleracja i ograniczanie szybkości (rate limiting): Memorystore.

Analityka, pozyskiwanie i przetwarzanie danych

BigQuery

Zbiory danych (Datasets): logiczne granice bezpieczeństwa i rozliczeń; przyjmij konwencje nazewnictwa według domeny i etapu cyklu życia.
Partycjonowanie: według czasu pozyskania lub oparte na kolumnie do filtrowania czasowego; również partycjonowanie według zakresu liczb całkowitych. Użyj partycjonowania według jednostki czasu dla event_ts, aby ograniczyć skanowanie danych (prune scans).
Klastrowanie: do czterech kolumn w celu wspólnego umieszczania powiązanych danych w pamięci masowej; poprawia wydajność i koszt zapytań selektywnych.
Rezerwacje: zarządzaj dedykowanymi slotami poprzez rezerwacje i przydziały; używaj slotów elastycznych (flex slots) do eksperymentów o nagłym wzroście obciążenia; izoluj krytyczne obciążenia, aby uniknąć głodzenia zasobów (starvation).
Kontrola dostępu: IAM na poziomie projektu i zbioru danych; kontrola na poziomie tabeli/kolumny za pomocą zasad na poziomie wiersza (row-level policies) i tagów zasad (policy tags); udostępniaj przygotowane dane za pomocą autoryzowanych widoków i procedur.

Przydatny przykład:

undefined

Kompromisy i tryby awarii

Złe partycjonowanie prowadzi do pełnego skanowania tabel i niekontrolowanego wzrostu kosztów.
Klastrowanie pomaga tylko wtedy, gdy filtry lub złączenia (joins) obejmują klastrowane kolumny; częste przetasowania mogą zmniejszyć korzyści.
Niedostateczna alokacja slotów powoduje kolejkowanie zadań; nadmierna alokacja podnosi koszty. Monitoruj wykorzystanie slotów i spilled shuffle.

Pozyskiwanie i przetwarzanie danych

Pub/Sub: globalne, trwałe dostarczanie co najmniej raz (at-least-once); klucze porządkujące (ordering keys) wymuszają porządek dla danego klucza z kompromisami w zakresie przepustowości. Projektuj idempotentnych konsumentów.
Dataflow: zunifikowane przetwarzanie wsadowe i strumieniowe z automatycznym skalowaniem, przetwarzanie stanowe typu exactly-once, okienkowanie (windowing) i wyzwalacze (triggers); Streaming Engine odciąża zarządzanie stanem. Używaj tematów dead-letter i źródeł z możliwością ponownego odtworzenia.
Dataproc: zarządzany Spark/Hadoop dla istniejącego kodu i ekosystemów; klastry efemeryczne lub z automatycznym skalowaniem; używaj dla bibliotek ML lub gdy przenoszenie kodu jest kosztowne.

Kompromisy między przetwarzaniem wsadowym a strumieniowym

Przetwarzanie strumieniowe zmniejsza opóźnienia i wspiera działanie w czasie rzeczywistym, ale zwiększa złożoność (stan, znaki wodne, opóźnione dane) i bieżące koszty.
Przetwarzanie wsadowe upraszcza zapewnienie poprawności i kontrolę kosztów; jest akceptowalne, gdy umowy SLA dopuszczają opóźnienia.
Wzorce hybrydowe: zapisuj surowe zdarzenia w Cloud Storage, przesyłaj strumieniowo zagregowane wskaźniki KPI do BigQuery i uruchamiaj nocne, wsadowe ponowne obliczenia w celu zapewnienia dokładności.

Wzorce hurtowni danych

Hurtownia danych (Warehouse): BigQuery jako system analityczny; zmaterializowane widoki i zaplanowane zapytania do obsługi systemów BI.
Lakehouse: zarządzaj danymi w Cloud Storage w otwartych formatach; udostępniaj je przez BigLake do BigQuery z zachowaniem spójnych zabezpieczeń.

Zarządzanie, ochrona i wydajność

Zarządzanie danymi i bezpieczeństwo

Metadane i pochodzenie danych (lineage): używaj Data Catalog do przechowywania metadanych technicznych i biznesowych; włącz przechwytywanie pochodzenia danych z Dataflow, BigQuery i Dataproc, aby śledzić zależności.
Jakość: egzekwuj reguły za pomocą Dataplex data quality i orkiestruj kontrole w Composer lub Dataform; przenoś nieprawidłowe rekordy do kwarantanny.
Granice dostępu: używaj VPC Service Controls wokół BigQuery i Cloud Storage, aby zmniejszyć ryzyko eksfiltracji danych; IAM Conditions do dostępu kontekstowego; CMEK do kontroli kryptograficznej; policy tags do ograniczeń na poziomie kolumn.
Retencja: dostosuj retencję bucketów Cloud Storage, funkcję time travel dla tabel BigQuery (konfigurowalna do 7 dni) oraz wygasanie zbiorów danych/tabel do wymogów prawnych.

Kopie zapasowe, PITR i ochrona przed usunięciem

Waliduj kopie zapasowe: okresowo przywracaj kopie zapasowe Cloud SQL i Spanner do izolowanych środowisk i uruchamiaj sumy kontrolne oraz walidacje na poziomie aplikacji.
Bigtable: włącz PITR, aby móc odzyskać dane do określonego punktu w czasie w ramach skonfigurowanej retencji; testuj przywracanie na poziomie tabeli lub klastra.
Spanner: używaj kopii zapasowych do odtwarzania po awarii (disaster recovery); wykorzystuj odczyty nieaktualnych danych (stale reads) w ramach retencji wersji do zapytań audytowych.
Cloud Storage: włącz wersjonowanie obiektów i blokadę retencji bucketu (bucket retention lock), aby chronić przed przypadkowym usunięciem; replikuj do osobnego projektu w celu izolacji od błędów operatora.
BigQuery: używaj funkcji time travel i snapshotów tabel; unikaj usuwania produkcyjnych zbiorów danych, wprowadzając wymóg zatwierdzeń i ochronę przed usunięciem na poziomie zbioru danych.

Wydajność danych i kontrola kosztów

Unikaj gorących kluczy (hot keys): dystrybuuj klucze wierszy Bigtable (prefiksy haszujące), wybieraj klucze główne Spanner, które losowo rozdzielają wybory lidera (leadership elections), sharduj liczniki w Firestore.
Indeksy: utrzymuj niezbędne indeksy SQL i NoSQL; w BigQuery klastruj według popularnych filtrów; w Cloud SQL monitoruj wolne zapytania i regularnie wykonuj operacje vacuum/analyze w Postgres.
Planowanie pojemności: ustal poziom bazowy za pomocą testów obciążeniowych; zdefiniuj SLO i budżety błędów; monitoruj wykorzystanie slotów BigQuery, opóźnienia CPU/read-modify-write w Bigtable, CPU/IOPS w Cloud SQL oraz zaległości (backlog) w Pub/Sub.
Kontrola kosztów: używaj zobowiązań na sloty (slot commitments) w BigQuery dla stałych obciążeń, Autoclass dla Cloud Storage, kompaktuj tabele Bigtable i dostrajaj filtry Blooma, wygaszaj stare partycje i zbiory danych oraz wdrażaj budżety i alerty dla poszczególnych zespołów.

Praktyczny scenariusz problemowy

Grupa Acme Retail potrzebuje zunifikowanej platformy analitycznej o niskim opóźnieniu do analizy strumieni kliknięć (clickstream) i zamówień. Wymagania: wskaźniki KPI w czasie rzeczywistym w ciągu 10 sekund, analiza historyczna danych z pięciu lat za pomocą SQL, cele odzyskiwania danych poniżej godziny (sub-hour recovery objectives), ścisła rezydencja danych w USA oraz zapobieganie przypadkowej utracie danych.

Przechowuj surowe zdarzenia i zaimplementuj trwałe pozyskiwanie danych

Utwórz buckety Cloud Storage w dwóch regionach (dual-region) us-central1/us-east1 dla stref surowych (raw) i przetworzonych (curated); włącz Autoclass i wersjonowanie obiektów dla danych surowych.
Uzasadnienie: konfiguracja dual-region spełnia wymogi trwałości i rezydencji; wersjonowanie chroni przed nieudanym uzupełnianiem danych (backfills); Autoclass automatycznie optymalizuje koszty przechowywania.

Niezawodnie przesyłaj strumieniowo zdarzenia za pomocą Pub/Sub i Dataflow

Publikuj zdarzenia clickstream i zamówień w tematach Pub/Sub z kluczami porządkującymi (ordering keys) per user_id; zaimplementuj potok strumieniowy Dataflow do walidacji, deduplikacji, wzbogacania i rozgałęziania danych wyjściowych do BigQuery (gorące KPI) i Cloud Storage (parquet w strefie curated).
Uzasadnienie: Pub/Sub zapewnia globalne, trwałe dostarczanie co najmniej raz (at-least-once); Dataflow oferuje stan “dokładnie raz” (exactly-once) i automatyczne skalowanie; rozgałęzianie utrzymuje wzorzec lakehouse na potrzeby ponownego przetwarzania.

Udostępniaj funkcje czasu rzeczywistego w Bigtable i Redis

Zapisuj podzbiór wzbogaconych zdarzeń do Bigtable z kluczem wiersza w formacie salted user_id#timestamp; użyj Memorystore for Redis jako pamięci podręcznej (front cache) dla najnowszych sesji.
Uzasadnienie: Bigtable zapewnia zapisy o niskim opóźnieniu i wysokiej przepustowości dla danych szeregów czasowych; salting zapobiega hotspotom; Redis redukuje opóźnienia krańcowe (tail latency) dla personalizacji na żywo.

Przechowuj dane i optymalizuj zapytania w BigQuery

Utwórz zbiory danych partycjonowane według event_date i klastrowane według user_id, channel. Użyj zmaterializowanych widoków (materialized views) dla wskaźników KPI i zaplanowanych kompaktowań dla ładowania małych plików; wykup bazową rezerwację slotów z małym buforem elastycznych slotów (flex slots) na nagłe wzrosty obciążenia.
Uzasadnienie: partycjonowanie i klastrowanie ograniczają skanowanie danych (prune scans) i redukują koszty; zmaterializowane widoki przyspieszają działanie dashboardów; rezerwacje ograniczają koszty i chronią krytyczne obciążenia przed kolejkowaniem.

Zarządzaj dostępem i zapobiegaj eksfiltracji

Zastosuj uprawnienia IAM na poziomie zbioru danych dla grup analityków; użyj policy tags do ograniczenia dostępu do kolumn z danymi PII oraz autoryzowanych widoków (authorized views) dla dostawców. Wymuś stosowanie VPC Service Controls wokół BigQuery i Cloud Storage; użyj CMEK dla zbiorów danych podlegających regulacjom.
Uzasadnienie: zasada najmniejszych uprawnień (least-privilege) na poziomie zbioru danych i kolumn; VPC SC zmniejsza ryzyko eksfiltracji danych; CMEK spełnia wymogi kontroli kryptograficznej.

Zaimplementuj kopie zapasowe, PITR i testy przywracania

Włącz PITR w Bigtable na 7–14 dni; twórz cotygodniowe kopie zapasowe Spanner lub Cloud SQL dla transakcyjnych magazynów zamówień; codziennie twórz snapshoty krytycznych tabel BigQuery i polegaj na funkcji time travel w przypadku pomyłek. Przeprowadzaj kwartalne ćwiczenia przywracania danych do izolowanego projektu.
Uzasadnienie: warstwowe opcje odzyskiwania danych radzą sobie z błędami logicznymi i awariami; regularne ćwiczenia walidują RPO/RTO i procedury (runbooks).

Kontroluj retencję i cykl życia danych

Zastosuj regułę cyklu życia (lifecycle rule) do usuwania surowych obiektów po 30 dniach, a przetworzonych po pięciu latach; zablokuj politykę retencji na poziomie bucketu, która spełnia wymogi zgodności. Ustaw domyślne wygasanie dla zbiorów danych/tabel BigQuery w przypadku danych tymczasowych.
Uzasadnienie: automatyczne egzekwowanie zasad zmniejsza ryzyko operacyjne; blokada retencji zapobiega przypadkowemu lub nieautoryzowanemu osłabieniu polityki.

Monitoruj wydajność i koszty oraz ograniczaj hotspoty

Śledź wykorzystanie slotów BigQuery, liczbę skanowanych bajtów i współbieżność zapytań BI; monitoruj użycie CPU i opóźnienie operacji read-modify-write w Bigtable; ustaw alerty na zaległości (backlog) w Pub/Sub. Jeśli pojawią się hotspoty związane z user_id, zwiększ szerokość saltingu i uzupełnij klucze za pomocą Dataflow.
Uzasadnienie: ciągła telemetria pozwala wcześnie wykrywać wąskie gardła; proaktywne zmiany w strategii kluczy pozwalają utrzymać SLO bez konieczności całkowitej zmiany architektury.

Zapewnij prywatną łączność i izolację

Dla zależności hybrydowych użyj Partner lub Dedicated Interconnect z Cloud Router; upewnij się, że zakresy adresów IP się nie pokrywają; użyj Private Service Connect dla punktów końcowych usług zarządzanych.
Uzasadnienie: prywatne ścieżki redukują opóźnienia i utratę pakietów; przejrzyste planowanie adresacji IP i PSC wymuszają izolację i przewidywalny routing.

Operacjonalizuj niezawodność

Włącz potoki Dataflow w trybie canary oraz widoki BigQuery w trybie blue/green; wymuszaj ewolucję schematu poprzez zatwierdzenia w Data Catalog; zintegruj kolejki niedostarczonych wiadomości (dead-letter queues) z procesem reagowania na incydenty.
Uzasadnienie: kontrolowane wdrożenia (controlled rollouts) ograniczają promień rażenia (blast radius); zarządzane zmiany schematu utrzymują jakość danych; DLQ zapewniają, że żadne dane nie zostaną utracone podczas incydentów.

← Moc obliczeniowa · Wszystkie domeny · Sieci →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →