Google PDE: Architektura i projektowanie inżynierii danych — 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

Architektura i projektowanie inżynierii danych w Google Cloud równoważy granice domen, wzorce przetwarzania i możliwości usług w celu dostarczania niezawodnych, skalowalnych i efektywnych kosztowo platform danych. Efektywne projekty zapewniają niezależną skalowalność przechowywania, obliczeń, orkiestracji i serwowania; kodyfikują kontrakty, aby domeny mogły współdziałać; oraz wcześnie weryfikują ryzyka za pomocą mierzalnych celów poziomu usług (SLO). Ta sekcja podsumowuje kanoniczne style architektoniczne (data mesh, jezioro danych, hurtownia danych, lakehouse, operacyjne magazyny danych), tryby przetwarzania (wsadowe, mikro-wsadowe, strumieniowe, sterowane zdarzeniami, lambda) oraz kompromisy między skalowalnością, opóźnieniami, dostępnością, spójnością i kosztem. Obejmuje również rozmieszczenie regionalne i wielochmurowe, ewolucję schematu, cykl życia danych end-to-end, dobór usług na podstawie obciążenia oraz praktyki walidacji oparte na ryzyku, dostosowane do Google Cloud.

Paradygmaty architektoniczne i wzorce przetwarzania

• Data mesh, domeny i produkty danych:
  • Umożliwienie zespołom domenowym publikowania „produktów danych” z jasno zdefiniowaną własnością, SLO, politykami dostępu i dokumentacją. Użyj Dataplex do definiowania domen, zarządzania metadanymi i stosowania spójnych polityk w BigQuery i Cloud Storage. Produkty mogą udostępniać zbiory danych BigQuery, tematy Pub/Sub lub ścieżki Cloud Storage z kontraktami egzekwowanymi przez schematy Pub/Sub i schematy tabel BigQuery.
• Jezioro danych (data lake):
  • Przechowywanie surowych danych w otwartych formatach (Parquet/Avro) w Cloud Storage z zarządzaniem cyklem życia i wersjonowaniem. Odpowiednie dla heterogenicznych obciążeń (Spark w Dataproc, Dataflow, Presto/Trino) i przenośności wielochmurowej. Kompromis: semantyka spójności ostatecznej (eventual consistency) w magazynach obiektów; projektuj z myślą o idempotentności i deduplikacji opartej na metadanych.
• Hurtownia danych (data warehouse):
  • Zarządzana i nadzorowana analityka w BigQuery. Zoptymalizowana pod kątem ANSI SQL, separacji warstwy przechowywania i obliczeniowej oraz szczegółowych zabezpieczeń. Kompromisy: wstawianie strumieniowe wykazuje krótkotrwałą nieaktualność danych w czasie zapytania; w przypadku rygorystycznych umów SLA dotyczących świeżości danych preferuj ładowanie wsadowe lub wstawianie za pomocą buforowanych zapytań.
• Lakehouse:
  • Połączenie otwartego magazynu danych typu data lake z możliwościami hurtowni danych. W Google Cloud przechowuj dane Parquet/Avro w Cloud Storage; używaj tabel zewnętrznych BigQuery dla oszczędności, a zarządzanych tabel BigQuery dla wydajności i nadzoru. Dataflow lub Dataproc utrzymuje semantykę łączenia podobną do ACID dzięki strategiom partycjonowania/klastrowania.
• Architektura operacyjnych magazynów danych:
  • Transakcyjne lub klucz-wartość magazyny danych o niskim opóźnieniu, wspierające aplikacje. Wybierz Cloud SQL dla tradycyjnych systemów OLTP, Cloud Spanner dla globalnie spójnego SQL ze skalowaniem horyzontalnym, a Bigtable dla wzorców dostępu o bardzo wysokiej przepustowości do szerokich kolumn. Oddzielaj magazyny operacyjne od analitycznych; używaj CDC (Datastream) do przechwytywania zmian do Pub/Sub, Cloud Storage lub BigQuery.

Wzorce przetwarzania i kiedy ich używać:

• Wsadowe (batch): Okresowe, wielkoskalowe transformacje (np. nocne generowanie cech). Narzędzia: Dataflow w trybie wsadowym, Dataproc. Tryby awarii: przekroczenia limitu czasu długo działających zadań, nierównomierne rozłożenie danych (skew); ograniczaj ryzyko za pomocą automatycznego skalowania i ponownego partycjonowania.
• Mikro-wsadowe (micro-batch): Małe, częste partie danych (np. co minutę) w celu zrównoważenia świeżości danych ze stabilnością i kosztem. W BigQuery używaj zaplanowanych zapytań lub Dataflow ze stałymi oknami czasowymi.
• Strumieniowe (streaming): Opóźnienia rzędu milisekund do sekund dla nieograniczonych danych. Używaj Pub/Sub + Dataflow. Obsługuj opóźnione lub nieuporządkowane zdarzenia za pomocą okien czasu zdarzenia i znaków wodnych (watermarks); zapewnij idempotentność, aby zapobiec duplikatom.
• Sterowane zdarzeniami (event-driven): Wyzwalane przez zmiany (finalizacja obiektu w GCS, wiadomości Pub/Sub). Używaj Cloud Functions lub Cloud Run do bezstanowych reakcji, a Dataflow do przetwarzania stanowego. Kompromis: koszty per zdarzenie vs. przepustowość.
• Wzorzec Lambda: Utrzymywanie zarówno ścieżki strumieniowej, jak i wsadowej w celu zapewnienia dokładności i możliwości ponownego przetwarzania. Złożoność podwaja się; rozważ uproszczenie w stylu Kappa, gdzie wszystko można odtworzyć z niezmiennego logu (archiwizacja z Pub/Sub do Cloud Storage).

Krótki przykład konfiguracji strumieniowania w Dataflow dla opóźnionych danych:

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

Własność domen, produkty danych i kontrakty

• Własność i SLO:
  • Każdy zespół domenowy definiuje i zarządza swoimi produktami danych, określając dla nich SLO dotyczące dostępności, opóźnień i jakości danych. Publikuj SLO za pośrednictwem katalogów Dataplex i monitoruj za pomocą wskaźników SLI w Cloud Monitoring (np. kompletność partycji na czas).
• Kontrakty i interoperacyjność:
  • Wymuszaj schematy za pomocą Pub/Sub Schema Registry (Avro/Proto) i schematów tabel BigQuery. W przypadku pozyskiwania danych CSV, waliduj je w Dataflow i przekierowuj niepoprawnie sformatowane wiersze do tabeli martwych listów (dead-letter) w celu analizy. Zapewnij interoperacyjność z otwartymi formatami w Cloud Storage i tabelami zewnętrznymi BigQuery, gdy wiele silników musi odczytywać te same dane.
• Ewolucja schematu:
  • Preferuj zmiany wstecznie kompatybilne: dodawanie kolumn dopuszczających wartość null, dodawanie opcjonalnych pól w Avro/Proto, unikanie zmiany nazw/usuwania bez okresów przejściowych (deprecation windows). Komunikuj zmiany za pomocą wersjonowanych kontraktów i harmonogramów wycofywania.
  • Przykład w BigQuery (dodanie wstecznie kompatybilnej kolumny):

ALTER TABLE sales.orders
ADD COLUMN coupon_code STRING;

• Wpływ na konsumentów:
  • Utrzymuj wersjonowanie semantyczne schematów; publikuj zarówno v1, jak i v2 podczas migracji. W przypadku strumieniowania, kieruj dane do wersjonowanych tematów lub dołącz pole z wersją schematu. Udostępniaj autoryzowane widoki w BigQuery, aby izolować konsumentów od zmian fizycznych.
• Zarządzanie i pochodzenie danych (lineage):
  • Używaj Dataplex i Data Catalog do zarządzania metadanymi, tagami (np. PII) i pochodzeniem danych (lineage). Stosuj zabezpieczenia na poziomie wierszy i kolumn w BigQuery. W celu zapobiegania utracie danych (DLP), zintegruj Cloud DLP w procesie pozyskiwania (np. transformacje w Cloud Run lub Dataflow), aby tokenizować lub redagować pola wrażliwe przed ich zapisaniem.

Kompromisy niefunkcjonalne i topologia wdrożenia

• Skalowalność:
  • BigQuery skaluje się elastycznie na potrzeby analityki; Bigtable skaluje się liniowo wraz z liczbą węzłów, ale wymaga starannego projektowania kluczy wierszy (row-key), np. z użyciem haszowanych lub rotacyjnych prefiksów, aby uniknąć hotspottingu. Autoskalowanie Dataflow reaguje na zaległości (backlogs); projektuj z uwzględnieniem przeciwciśnienia (backpressure), wykorzystując kontrolę przepływu (flow control) w Pub/Sub.
• Opóźnienia (Latency):
  • Strumieniowanie do BigQuery oferuje wstawianie danych z niskim opóźnieniem, ale zapytania mogą wykazywać niewielki lag; projektuj zapytania z buforem świeżości danych lub oknami czasowymi opartymi na znakach wodnych (watermarks). Aby uzyskać odczyty poniżej 100 ms na dużą skalę, wstępnie obliczaj dane i serwuj je z Bigtable lub Memorystore.
• Dostępność i spójność:
  • Cloud Spanner zapewnia silnie spójny, globalnie rozproszony SQL. Bigtable oferuje wysoką dostępność z ostateczną spójnością (eventual consistency) między klastrami. Dostępność BigQuery jest regionalna lub wieloregionalna; materializuj krytyczne zbiory danych w lokalizacji wieloregionalnej (multi-region), aby zapewnić odporność.
• Koszt:
  • Optymalizuj BigQuery za pomocą partycjonowania i klastrowania, aby zmniejszyć ilość skanowanych bajtów. W przypadku małych plików przesyłanych przez łącza o ograniczonej przepustowości, grupuj je w partie (batch) lub pakiety (bundle), aby zredukować narzut RPC. Używaj BigQuery BI Engine do buforowanych, interaktywnych dashboardów, gdy jest to uzasadnione.
• Architektura regionalna, wieloregionalna, hybrydowa i multi-cloud:
  • Architektura regionalna zmniejsza opóźnienia i koszty; przechowywanie wieloregionalne (np. BigQuery US/EU multi-region, Cloud Storage dual-/multi-region) zwiększa trwałość i opcje lokalizacji danych. Na potrzeby odtwarzania po awarii (DR), zdefiniuj RPO/RTO i replikuj krytyczne zbiory danych. W scenariuszach hybrydowych używaj Datastream do CDC (Change Data Capture) oraz Transfer Appliances lub Storage Transfer Service do migracji masowych. W przypadku multi-cloud, standaryzuj na otwartych formatach w Cloud Storage i używaj przenośnych rozwiązań obliczeniowych (Apache Beam/Dataflow, Spark na Dataproc), pamiętając o kosztach wyjścia danych (egress) i narzucie operacyjnym.

Warstwy, cykl życia i dobór usług

• Podział na warstwy:
  • Przechowywanie: Cloud Storage dla danych surowych/brązowych (raw/bronze) i archiwalnych; BigQuery dla przygotowanej analityki (curated/serving); Bigtable dla dostępu klucz-wartość o niskim opóźnieniu; Spanner/Cloud SQL dla OLTP.
  • Przetwarzanie: Dataflow dla bezserwerowego przetwarzania strumieniowego/wsadowego; Dataproc dla ekosystemów Spark/Hadoop; BigQuery dla ELT wewnątrz hurtowni; Cloud Run/Functions dla mikrousług opartych na zdarzeniach.
  • Orkiestracja: Cloud Composer (Airflow) lub Workflows dla grafów DAG i choreografii API; Scheduler dla wyzwalaczy w stylu cron.
  • Serwowanie: Bigtable lub Spanner dla odczytów online; BigQuery dla BI; Looker/BI Engine dla paneli (dashboardów); Memorystore dla buforowania (caching).
• Cykl życia danych:
  • Pozyskiwanie (Ingest): Pub/Sub dla strumieni; Storage Transfer lub gsutil dla plików; Data Transfer Service dla SaaS. Walidacja, deduplikacja i zapisywanie niezmiennych surowych danych w Cloud Storage z włączonym wersjonowaniem obiektów.
  • Przetwarzanie (Process): Użycie Dataflow lub BigQuery do transformacji danych surowych (raw) do srebrnych (silver - oczyszczonych, ujednoliconych), a następnie do złotych (gold - marty danych gotowe do użycia biznesowego).
  • Serwowanie (Serve): Publikowanie widoków/tabel BigQuery do celów analitycznych; wstępne obliczanie cech (features) lub predykcji i zapisywanie ich w Bigtable dla API.
  • Przechowywanie i archiwizacja (Retain and archive): Stosowanie reguł cyklu życia (lifecycle rules) w Cloud Storage do przenoszenia danych do warstw Coldline/Archive; używanie partycjonowania czasowego w BigQuery z wygasaniem partycji w celu retencji. Włączanie CMEK tam, gdzie jest to wymagane, oraz VPC Service Controls w celu ochrony przed eksfiltracją danych.
• Dobór usług na podstawie charakterystyki obciążenia:
  • Szeregi czasowe o wysokiej przepustowości z szerokimi wierszami i niskim opóźnieniem: Bigtable.
  • Globalny OLTP o silnej spójności (strongly consistent) z ANSI SQL: Cloud Spanner.
  • Tradycyjne transakcje relacyjne o umiarkowanej skali: Cloud SQL.
  • Analityka na petabajtową skalę z ANSI SQL i rozdzieleniem warstwy przechowywania i przetwarzania: BigQuery.
  • Pozyskiwanie i przetwarzanie w czasie rzeczywistym: Pub/Sub + Dataflow.
  • Przetwarzanie wsadowe w Spark/Hadoop lub narzędzia specyficzne dla bibliotek: Dataproc.

Krótki przykład partycjonowania w BigQuery:

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

Praktyczny scenariusz problemowy

Firma Contoso Mobility zarządza globalną flotą e-hulajnóg i potrzebuje pozyskiwania, przetwarzania, przechowywania i analityki w czasie rzeczywistym dla telemetrii przejazdów i rozliczeń. Musi obsługiwać miliony zdarzeń na minutę, reguły antyfraudowe działające w czasie poniżej sekundy, aktualne panele kontrolne, zapewniać kontrolę prywatności i odporne na awarie działanie w wielu regionach.

Podejście:

1. Ustanowienie pozyskiwania zdarzeń za pomocą Cloud Pub/Sub.

• Uzasadnienie: Pub/Sub zapewnia pojedynczy globalny punkt końcowy, trwałe buforowanie i skalowalność horyzontalną dla nieregularnego ruchu z urządzeń. Użycie kluczy porządkujących (ordered keys) per hulajnoga pozwala zachować kolejność zdarzeń wewnątrz urządzenia w oknach 1-godzinnych.

2. Implementacja przetwarzania strumieniowego za pomocą Cloud Dataflow (Apache Beam).

• Uzasadnienie: Autoskalowanie Dataflow obsługuje skoki ruchu i oferuje ujścia (sinks) z semantyką ’exactly-once’ w połączeniu z kluczami idempotentnymi. Użycie okien czasowych opartych na czasie zdarzenia (event-time windows) i znaków wodnych (watermarks) pozwala obsługiwać opóźnioną lub nieuporządkowaną telemetrię. Generowanie głównego strumienia wyjściowego z danymi przygotowanymi (curated) i bocznego wyjścia (side output) dla rekordów nienadających się do przetworzenia (dead-letter).
• Konfiguracja:

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

3. Utrwalanie danych surowych i przygotowanych odpowiednio w Cloud Storage i BigQuery.

• Uzasadnienie: Zapisywanie surowych (bronze) plików Avro w zasobniku (bucket) Cloud Storage typu dual-region w celu ponownego odtwarzania i audytu. Zapisywanie przygotowanych (silver) strumieni do partycjonowanych tabel BigQuery w celach analitycznych, z klastrowaniem po scooter_id dla wydajnych zapytań punktowych. Zastosowanie małego bufora świeżości (freshness buffer) w zapytaniach do paneli kontrolnych, aby uniknąć chwilowej nieaktualności danych strumieniowych.

4. Serwowanie zapytań operacyjnych i weryfikacji antyfraudowych z Cloud Bigtable.

• Uzasadnienie: Ewaluacja reguł w czasie poniżej 100 ms wymaga losowego dostępu o niskim opóźnieniu. Wstępne obliczanie agregatów (np. liczba przejazdów na urządzenie w 5-minutowym oknie) w Dataflow i zapisywanie ich do Bigtable przy użyciu klucza wiersza z haszowanym prefiksem (np. h(prefix)+device_id+window_start), aby uniknąć hotspottingu i zrównoleglić odczyty na wielu tabletach.

5. Zarządzanie transakcyjnymi rozliczeniami w Cloud Spanner.

• Uzasadnienie: Rozliczenia wymagają globalnie spójnego SQL, silnej spójności (strong consistency) i wysokiej dostępności. Użycie instancji wiodącej (leader) w głównej lokalizacji geograficznej z replikami tylko do odczytu w regionach wtórnych w celu zmniejszenia opóźnień odczytu dla portali klientów.

6. Wymuszanie ładu danych (governance) za pomocą Dataplex, Data Catalog i Cloud DLP.

• Uzasadnienie: Klasyfikacja pól PII, tagowanie zbiorów danych i stosowanie zabezpieczeń na poziomie kolumn w BigQuery. Integracja Cloud DLP w potoku Dataflow w celu tokenizacji wrażliwych atrybutów przed ich zapisaniem. Domeny Dataplex odzwierciedlają własność organizacyjną; każda domena publikuje udokumentowane produkty danych z określonymi SLO.

7. Orkiestracja i operacje za pomocą Cloud Composer i Cloud Monitoring.

• Uzasadnienie: Composer koordynuje wsadowe uzupełnianie danych (backfills), kompakcje i materializację cech ML. Monitoring obserwuje wskaźniki SLI end-to-end: zaległości (backlog) w Pub/Sub, opóźnienie znaku wodnego (watermark lag) w Dataflow, kompletność partycji w BigQuery i opóźnienia końcowe (tail latencies) w Bigtable. Alerty w przypadku naruszenia SLO; autoskalowanie Dataflow na podstawie wzrostu zaległości.

8. Optymalizacja kosztów i cyklu życia za pomocą partycjonowania i warstw przechowywania (tiering).

• Uzasadnienie: Tabele BigQuery są partycjonowane po event_ts z 90-dniową retencją i klastrowane po scooter_id. Cloud Storage używa reguł cyklu życia do przenoszenia surowych danych do warstwy Coldline po 30 dniach i Archive po 180 dniach. Zaplanowane zadania BigQuery kompaktują małe pliki z mikro-wsadów w większe obiekty parquet, aby zmniejszyć narzut związany z liczbą plików dla zadań Spark w dalszej części potoku.

9. Walidacja ryzyka i odporności na awarie.

• Uzasadnienie: Przeprowadzenie testów obciążeniowych przy 2-krotności oczekiwanego szczytu w celu walidacji limitów (quotas) Pub/Sub i autoskalowania Dataflow. Przeprowadzenie ćwiczenia przełączania awaryjnego (failover) regionu: wieloregionalne zbiory danych BigQuery i zasobniki dual-region utrzymują dostępność; wieloregionalna instancja Spanner utrzymuje RPO=0 i skonfigurowane RTO poprzez automatyczne przełączanie awaryjne. Użycie Infrastructure as Code (Terraform) z walidacją polityk w celu wymuszenia stosowania CMEK i VPC Service Controls.

Ta architektura czysto rozdziela zadania: Pub/Sub buforuje dane wejściowe, Dataflow je przetwarza, Cloud Storage i BigQuery przechowują i serwują analitykę, Bigtable przyspiesza odczyty operacyjne, a Spanner gwarantuje spójne transakcje. Równoważy skalowalność i opóźnienia, jednocześnie kontrolując koszty poprzez partycjonowanie, klastrowanie, polityki cyklu życia i autoskalowanie, a także wdraża ład danych i niezawodność poprzez udokumentowane produkty danych, kontrakty i ciągłą walidację.

Wszystkie domeny · Przechowywanie danych →

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

Przeglądaj Google →