Google PDE: Przechowywanie danych, jeziora danych i formaty plików — 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

Przechowywanie danych w Google Cloud obejmuje surową pamięć masową obiektów, uporządkowane jeziora danych i formaty zoptymalizowane pod kątem analityki. Budowa niezawodnych, zarządzanych i wydajnych jezior danych wymaga starannego doboru klas pamięci masowej, ustawień bucketów, lokalizacji, formatów plików, układu tabel i cyklu życia. Ta sekcja szczegółowo omawia kompromisy projektowe, tryby awarii, których należy unikać, oraz wzorce, które sprawdzają się w przypadku BigQuery, Spark i potoków strumieniowych działających na dużą skalę.

Podstawy Cloud Storage: klasy, buckety, spójność i cykl życia

Cloud Storage to trwała i wysoce dostępna podstawa dla surowych i uporządkowanych plików.

• Klasy pamięci masowej

  • Standard (gorąca): częsty dostęp, najniższe opóźnienie. Brak minimalnego okresu przechowywania.
  • Nearline (chłodna): rzadki dostęp (~miesięcznie). Minimum 30 dni; obowiązują opłaty za odczyt.
  • Coldline (zimniejsza): rzadki dostęp (~kwartalnie). Minimum 90 dni; wyższe opłaty za odczyt.
  • Archive (najzimniejsza): długoterminowa retencja (~rocznie). Minimum 365 dni; najwyższe opłaty za odczyt.
  • Autoclass może automatycznie przenosić dane między klasami; należy zweryfikować, czy opłaty za wczesne usunięcie i wzorce dostępu nie zniwelują oszczędności.

• Lokalizacje i replikacja bucketów

  • Region: najlepszy dla lokalności danych i zgodności w ramach jednego obszaru geograficznego.
  • Dual-region: dwa sparowane regiony z automatyczną replikacją; replikacja turbo szybko zatwierdza repliki z RPO mierzonym w minutach; idealne dla DR o niskim RPO.
  • Multi-region: rozproszony geograficznie na jednym kontynencie dla szerokiej dostępności, dystrybucji treści i analityki obejmującej duży obszar.
  • Wybierz lokalizacje, aby spełnić wymogi dotyczące rezydencji danych i zminimalizować egress/opóźnienia w dostępie do zasobów obliczeniowych (Dataproc, Dataflow, tabele zewnętrzne BigQuery).

• Spójność i semantyka

  • Cloud Storage zapewnia silną globalną spójność typu read-after-write, read-after-metadata-update i list-after-write.
  • Zapisy obiektów są atomowe i niezmienne; „zmiana nazwy” to wzorzec kopiuj+usuń. Projektuj operacje kopiowania jako idempotentne i weryfikuj sumy kontrolne, aby zapobiec częściowym migracjom.

• Wzorce dostępu i wydajność

  • Równoległe przesyłanie złożone (parallel composite uploads) i przesyłanie wznawialne (resumable uploads) poprawiają przepustowość dla dużych plików.
  • Odczyty zakresowe (range reads) umożliwiają wydajny odczyt stopek kolumnowych i odczyty selektywne.
  • Unikaj wielu małych plików (<8 MB), które zwiększają narzut związany z metadanymi/listowaniem; grupuj lub kompaktuj je w większe obiekty.
  • GZIP nie jest podzielny (splittable) dla odczytów rozproszonych; preferuj formaty Parquet/ORC/Avro+Snappy dla skalowalnego przetwarzania.

• Cykl życia, retencja i wersjonowanie

  • Polityki retencji na poziomie bucketu i blokady obiektów (oparte na zdarzeniach lub tymczasowe) wymuszają niezmienność w celu zapewnienia zgodności i ograniczenia przypadkowych usunięć.
  • Wersjonowanie obiektów przechowuje poprzednie generacje; przydatne do odzyskiwania danych po nadpisaniu/usunięciu. Monitoruj wzrost kosztów przechowywania.
  • Reguły cyklu życia automatyzują przenoszenie i usuwanie danych. Przykład (JSON) przenoszący starsze dane do zimniejszej klasy i usuwający je po roku:

undefined

• Tryby awarii: opłaty za wczesne usunięcie, jeśli przenosisz dane zbyt agresywnie; blokad retencji nie można skrócić; wersjonowanie bez kompaktowania może zwiększyć koszty.

• Transfery i migracja

  • Użyj Storage Transfer Service do zrównoleglonych, zapisujących punkty kontrolne transferów z on-premise lub innych chmur; Transfer Appliance dla petabajtów danych offline.
  • Weryfikuj integralność za pomocą CRC32C/MD5 i warunków wstępnych generation-match, aby zapobiec sytuacjom wyścigu (race conditions).
  • Preferuj gsutil/gcloud storage z opcją -m (równolegle) i sumami kontrolnymi; unikaj wąskich gardeł SFTP przy dużym wolumenie danych przychodzących.

Ujednolicone zarządzanie jeziorem danych za pomocą BigLake i Dataplex

BigLake i Dataplex standaryzują bezpieczeństwo i zarządzanie (governance) plikami i tabelami.

• BigLake

  • Udostępnia dane z Cloud Storage jako tabele zarządzane przez BigQuery (zewnętrzne) z jednolitą, precyzyjną kontrolą dostępu, w tym politykami dostępu na poziomie wiersza i tagami polityk na poziomie kolumn.
  • Umożliwia eliminację kolumn (column pruning) i przenoszenie predykatów (predicate pushdown) dla formatów Parquet/ORC, redukując liczbę skanowanych bajtów i egress do silników takich jak BigQuery, Spark w Dataproc i Dataflow.
  • Centralizuje audyt poprzez Cloud Logging i centralne egzekwowanie polityk; pojedyncza płaszczyzna sterowania dla plików w jeziorze danych i tabel w hurtowni.

• Dataplex

  • Organizuje dane w jeziora (lakes), strefy (surowe, uporządkowane, zaufane) i zasoby (assets: buckety, zbiory danych); zarządza metadanymi, pochodzeniem danych (lineage) i regułami jakości danych.
  • Integruje się z tagami polityk dla wrażliwych kolumn i wspiera zasadę najmniejszych uprawnień (least privilege) poprzez IAM na poziomach jeziora/strefy/zasobu.
  • Zachęca do standaryzacji nazewnictwa, partycjonowania i zarządzania schematami w środowiskach wielozespołowych, aby uniknąć bałaganu („szuflad ze śmieciami”).

• Wzorce zarządzania (governance)

  • Implementuj wzorce „zbiór danych na klienta” (dataset-per-tenant) i „bucket na strefę” (bucket-per-zone); unikaj przenikania danych między klientami.
  • Używaj polityk dostępu na poziomie wiersza i tagów polityk na poziomie kolumn dla danych PII. Ogranicz dostęp do API do zatwierdzonych tożsamości.
  • Przeprowadzaj audyt dostępu za pomocą Cloud Logging; przekierowuj przefiltrowane logi do Pub/Sub w celu monitorowania w czasie rzeczywistym.

Formaty plików, kompresja i zachowanie zapytań

Wybór odpowiedniego formatu ma bezpośredni wpływ na koszty i wydajność.

• Formaty kolumnowe (Parquet, ORC)

  • Zalety: eliminacja kolumn (column pruning), przenoszenie predykatów (predicate pushdown), kodowanie i kompresja dla każdej kolumny, statystyki i podzielne pliki.
  • Wady: większe zużycie CPU podczas zapisu; ewolucja schematu musi być zarządzana ostrożnie (np. dodawanie kolumn jest bezpieczne; zmiany typów są ryzykowne).
  • Kompresja: Snappy dla szybkości, ZSTD dla lepszego współczynnika kompresji tam, gdzie jest obsługiwany. Unikaj GZIP dla formatów kolumnowych, chyba że wymagają tego ograniczenia interoperacyjności.

• Wierszowy format Avro

  • Zalety: ewolucja schematu z silnym typowaniem, kompresja na poziomie bloku, podzielność; doskonały dla stref docelowych (landing zones) dla danych strumieniowych i wymiany danych.
  • Wady: mniej wydajny przy skanowaniu na potrzeby analityki niż formaty kolumnowe; konwertuj do Parquet/ORC w strefach przetworzonych (curated zones).

• CSV i JSON (półustrukturyzowane)

  • CSV: czytelny dla człowieka, najmniejszy narzut przy prostych wartościach; brak schematu, typów i spójności w obsłudze znaków specjalnych (escape); kosztowny w parsowaniu na dużą skalę.
  • JSON: samoopisujący się i elastyczny; format JSON rozdzielany znakami nowej linii (newline-delimited) jest wymagany do skalowalnych odczytów rozproszonych; rozwlekły i wymagający dużej mocy CPU do parsowania.
  • W miarę możliwości zapisuj surowe dane w CSV/JSON, a następnie waliduj je i konwertuj do formatu Avro/Parquet na potrzeby analityki.

• Tabele zewnętrzne BigQuery i tabele BigLake

  • Tabele zewnętrzne w formacie Parquet/ORC korzystają z predicate pushdown i column pruning; tabele CSV/JSON zazwyczaj nie, co prowadzi do większej liczby skanowanych bajtów.
  • Skompresowane tabele zewnętrzne CSV (GZIP) nie mogą być dzielone między workery; należy spodziewać się wolniejszych odczytów.
  • Przykład: tworzenie tabeli BigLake w formacie Parquet z partycjami w stylu Hive: 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’] );

Układ, partycjonowanie, inżynieria wydajności, rezydencja i migracja

• Układ i partycjonowanie obiektów

  • Stosuj ścieżki w stylu Hive dla kluczy partycjonowania i klastrowania: gs://bucket/dataset/table/date=YYYY-MM-DD/hour=HH/region=us/part-00001.parquet
  • Utrzymuj rozmiary pojedynczych plików w zakresie 128–1024 MB, aby zrównoważyć paralelizm i narzut zadań. Unikaj milionów plików na partycję.
  • Łagodź problemy z małymi plikami poprzez:
    • Grupowanie (batching) przesyłania po stronie klienta.
    • Używanie zadań kompakcji w Dataflow/Spark do łączenia małych plików poza godzinami szczytu.
    • Archiwizowanie oryginalnych małych plików i udostępnianie do analizy tylko skompaktowanych danych.

• Partycjonowanie i klastrowanie w BigQuery

  • Partycjonuj według czasu pozyskania (ingestion time) lub kolumny filtrującej o wysokiej kardynalności (np. event_date). Unikaj nadmiernego partycjonowania (np. co minutę), które prowadzi do eksplozji metadanych.
  • Klastruj według często filtrowanych/sortowanych wymiarów (do czterech). Klastrowanie zwiększa lokalność danych i zmniejsza liczbę skanowanych bajtów.
  • Preferuj natywne tabele BigQuery do intensywnej analizy interaktywnej; używaj BigLake/tabel zewnętrznych do zarządzanego dostępu do data lake, współdzielenia między silnikami i izolacji kosztów.

• Implikacje dla wydajności zapytań

  • Formaty kolumnowe znacząco redukują koszty skanowania zewnętrznego; tabele zewnętrzne CSV/JSON często wymagają skanowania całych plików.
  • Gwarancje spójności eliminują potrzebę sztucznych opóźnień przy odczytach z Cloud Storage, ale systemy podrzędne (np. wstawianie strumieniowe do BigQuery) mogą wykazywać krótkie opóźnienie w widoczności danych — projektuj z uwzględnieniem znaków wodnych (watermarks) lub opóźnień odczytu tam, gdzie jest to potrzebne.

• Rezydencja, trwałość i odtwarzanie

  • Wybieraj lokalizacje bucketów/zbiorów danych, aby spełnić ograniczenia dotyczące rezydencji; stosuj kolokację zasobów obliczeniowych, aby zmniejszyć ruch wychodzący (egress) i opóźnienia.
  • Używaj konfiguracji dual-region z replikacją turbo dla niskiego RPO; wersjonowanie oraz polityki retencji dla możliwości odtworzenia po błędzie ludzkim i ataku ransomware.
  • Dla celów DR (Disaster Recovery) replikuj buckety do osobnego projektu/regionu za pomocą replikacji bucketów i chroń je oddzielnymi granicami IAM.

• Bezpieczna migracja i walidacja

  • Planuj wielofazowo: zasilenie (transfer masowy), synchronizacja przyrostowa (kopiowanie na podstawie mtime/okien czasowych), przełączenie (źródło w trybie tylko do odczytu) i walidacja po przełączeniu.
  • Waliduj za pomocą sum kontrolnych, liczebności, sum bajtów i przykładowego dekodowania. Dla danych tabelarycznych porównaj liczbę wierszy i agregaty haszujące:

undefined

• Używaj warunków wstępnych (preconditions, np. ifGenerationMatch), aby zapobiegać nadpisywaniu podczas kopiowania równoległego. Zachowaj okno na wycofanie zmian (rollback) za pomocą wersjonowania lub zachowanego źródła.
• Po migracji włącz cykl życia (lifecycle) i Autoclass zgodnie z nowym profilem dostępu; unikaj włączania blokady retencji (retention lock) do czasu pomyślnego zakończenia walidacji.

Praktyczny scenariusz problemowy

Firma Acme Retail otrzymuje codzienne zrzuty plików CSV od partnera logistycznego do regionalnego bucketa Cloud Storage. Pliki czasami zawierają niepoprawnie sformatowane wiersze. Acme musi umieścić dane, zwalidować je, przekonwertować do formatu gotowego do analizy i załadować do BigQuery dla pulpitów nawigacyjnych działających w czasie zbliżonym do rzeczywistego, jednocześnie zachowując błędne wiersze do inspekcji i egzekwując ład danych (governance).

Podejście:

1. Umieszczanie i zarządzanie surowymi danymi w Dataplex

   • Utwórz Dataplex lake z zasobem strefy surowej (raw zone) zmapowanym na gs://acme-raw/logistics/.
   • Uzasadnienie: Scentralizowany ład danych, metadane i pochodzenie danych (lineage). Wymuszaj polityki IAM na poziomie strefy i oznaczaj wrażliwe pola tagami polityk (policy tags) do egzekwowania w systemach podrzędnych.

2. Wymuszanie cyklu życia i retencji

   • Zastosuj politykę retencji bucketa na 30 dni i włącz wersjonowanie obiektów w acme-raw.
   • Uzasadnienie: Chroni przed przypadkowym nadpisaniem/usunięciem przez partnera; krótka retencja równoważy koszt i możliwość odtworzenia danych. Wersjonowanie ułatwia wycofanie błędnych dostaw.

3. Walidacja i pozyskiwanie za pomocą potoku wsadowego Dataflow

   • Uruchamiaj codzienne zadanie Dataflow na podstawie powiadomień o finalizacji obiektu. Odczytuj pliki CSV ze schematem i walidacją per rekord; zapisuj poprawne rekordy do przejściowej tabeli BigQuery (staging) (partycjonowanej według event_date) i przekierowuj błędy parsowania/walidacji do tabeli BigQuery na odrzucone komunikaty (dead-letter).
   • Uzasadnienie: Dataflow zapewnia skalowalne, równoległe parsowanie i solidną obsługę odrzuconych rekordów, dzięki czemu analitycy mogą je sprawdzać. Odzwierciedla to najlepsze praktyki dla niejednorodnej jakości plików CSV.

4. Kompakcja i konwersja do formatu Parquet w strefie przetworzonej (curated zone)

   • Ten sam potok zapisuje zwalidowane dane do gs://acme-curated/logistics/date=YYYY-MM-DD/ jako pliki Parquet o rozmiarze ~256–512 MB.
   • Uzasadnienie: Parquet umożliwia przycinanie kolumn (column pruning) i wpychanie predykatów (predicate pushdown) w BigQuery i Spark, zmniejszając liczbę skanowanych bajtów i poprawiając opóźnienia; kompakcja łagodzi narzut związany z małymi plikami wynikający ze sposobu dostarczania danych przez partnera.

5. Udostępnianie zarządzanych danych analitycznych przez BigLake

   • Utwórz tabelę zewnętrzną BigLake nad ścieżką z przetworzonymi plikami Parquet z automatycznym partycjonowaniem w stylu Hive; zastosuj tagi polityk na poziomie kolumn i polityki dostępu na poziomie wierszy dla filtrów specyficznych dla partnera.
   • Uzasadnienie: Jednolity, szczegółowy dostęp w BigQuery i Spark ze scentralizowanym audytem. Przycinanie partycji (partition pruning) zmniejsza koszty skanowania przy filtrowaniu po dacie.

6. Ładowanie krytycznych agregatów do natywnej tabeli BigQuery

   • Dla intensywnie używanych pulpitów nawigacyjnych uruchamiaj zaplanowane zadanie BigQuery, które pozyskuje dane z ostatnich N dni z zewnętrznej tabeli Parquet do natywnej, klastrowanej i partycjonowanej tabeli.
   • Uzasadnienie: Natywna pamięć masowa przyspiesza działanie BI o wysokiej współbieżności, podczas gdy zewnętrzna tabela BigLake pozostaje zarządzanym systemem źródłowym (system-of-record) dla szerszego dostępu.

7. Monitorowanie i alertowanie za pomocą Cloud Logging i Pub/Sub

   • Utwórz ujście logów (log sink) filtrujące wyniki zadań Dataflow i ładowania do BigQuery do Pub/Sub; zintegruj z narzędziem monitorującym, aby otrzymywać natychmiastowe alerty o awariach lub podwyższonym wskaźniku błędnych wierszy.
   • Uzasadnienie: Ukierunkowana, operacyjna widoczność na poziomie tabeli bez odpytywania (polling); wspiera praktyki SRE.

8. Optymalizacja klasy pamięci masowej i rezydencji

   • Przechowuj przetworzone pliki Parquet w klasie Standard przez 14 dni, a po 30 dniach przenieś do Coldline za pomocą reguły cyklu życia; przechowuj zarówno surowe, jak i przetworzone buckety w tym samym regionie co zbiory danych BigQuery, aby unikać opłat za ruch wychodzący (egress).
   • Uzasadnienie: Równoważy wydajność odczytu gorących danych z kosztem. Kolokacja zapewnia zgodność z regulacjami oraz minimalizuje opóźnienia i opłaty za egress.

9. Walidacja jakości end-to-end

   • Po każdym uruchomieniu porównuj liczebności i agregaty haszujące między tabelą przejściową, zewnętrzną tabelą przetworzoną a natywną tabelą BigQuery; poddawaj anomalie kwarantannie.
   • Uzasadnienie: Wczesne wykrywanie dryfu schematu lub regresji w procesie pozyskiwania; hasze kryptograficzne lub typu fingerprint zapewniają lekkie zapewnienie jakości bez pełnych ponownych skanów.

Ten projekt zapewnia odporne pozyskiwanie danych z analizą odrzuconych rekordów, gotowy do analizy format Parquet dla wydajnych zapytań, scentralizowany ład danych przez Dataplex i BigLake oraz zoptymalizowane kosztowo polityki cyklu życia, wszystko to przy zachowaniu dostępu zgodnego z zasadą najmniejszych uprawnień i audytowalnych operacji.

← Architektura i projektowanie inżynierii danych · Wszystkie domeny · Analityka BigQuery i inżynieria hurtowni danych →

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

Przeglądaj Google →