Google PDE: Analityka BigQuery i inżynieria hurtowni 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

BigQuery to bezserwerowa, kolumnowa hurtownia analityczna MPP, która oddziela warstwę przechowywania danych od warstwy obliczeniowej, zapewniając niemal nieskończoną skalowalność, zgodność z ANSI SQL oraz zintegrowane zarządzanie (governance). Inżynieria hurtowni danych w BigQuery polega na równoważeniu projektowania schematu (partycjonowanie, klastrowanie, denormalizacja vs normalizacja, zagnieżdżone rekordy), wzorców pozyskiwania danych (ładowanie wsadowe, strumieniowanie, Storage Write API) oraz zarządzania obciążeniem (edycje on-demand vs oparte na pojemności i rezerwacje). Solidne zabezpieczenia (autoryzowane widoki, polityki na poziomie wierszy/kolumn, tagi polityk) współistnieją z narzędziami do kontroli kosztów i wydajności, aby minimalizować liczbę skanowanych bajtów i zmniejszać opóźnienia. Ta sekcja omawia kluczowe aspekty projektowania, operacji i trybów awarii, które należy przewidzieć w środowisku produkcyjnym.

Przechowywanie i semantyka: zbiory danych, tabele, widoki i dostęp do data lake

• Zbiory danych (datasets), tabele, widoki:

  • Zbiory danych określają zakres dla IAM i zarządzania. Utrzymuj osobne zbiory danych dla każdego klienta (per-tenant) w celu izolacji i przejrzystości rozliczeń.
  • Standardowe tabele przechowują dane natywnie; partycje i klastry zarządzają układem danych i ich przycinaniem (pruning).
  • Widoki hermetyzują logikę SQL bez przechowywania danych. Autoryzowane widoki pozwalają właścicielowi widoku udostępniać ograniczone podzbiory danych innym projektom lub klientom, ukrywając jednocześnie tabele źródłowe.
  • Widoki zmaterializowane (MVs) utrwalają wstępnie obliczone wyniki i odświeżają się automatycznie. Mechanizm przepisywania zapytań (query rewrite) wykorzystuje widoki zmaterializowane w sposób przezroczysty, gdy są one kompatybilne; niekompatybilne predykaty lub funkcje omijają je.
  • Tabele zewnętrzne odwołują się do danych w Cloud Storage, Google Drive lub Google Sheets. Pozwalają uniknąć pozyskiwania danych, ale oferują wygodę kosztem przepustowości i wsparcia dla funkcji. W przypadku powtarzalnych analiz, ładuj dane do tabel natywnych.

• Partycjonowanie, klastrowanie i zagnieżdżone rekordy:

  • Partycjonuj według czasu pozyskania danych, kolumny typu DATE/TIMESTAMP/DATETIME lub zakresu liczb całkowitych, aby przycinać skany. Używaj filtrów WHERE na kolumnie partycjonującej lub dekoratorów, takich jak _PARTITIONDATE, aby umożliwić przycinanie.
  • Klastruj według kolumn o wysokiej kardynalności, często filtrowanych lub używanych w złączeniach (do 8 kolumn). BigQuery automatycznie przeklastrowuje dane; powtarzające się małe operacje DML mogą tymczasowo pogorszyć jakość klastrowania.
  • Zagnieżdżone i powtarzalne rekordy (STRUCT, ARRAY) modelują relacje jeden-do-wielu bez narzutu związanego ze złączeniami. Używaj UNNEST z rozwagą; wielokrotne użycie UNNEST na dużych tablicach może prowadzić do gwałtownego wzrostu liczby wierszy (fan out).

• Denormalizacja vs normalizacja:

  • Denormalizuj atrybuty wymiarów do tabel faktów, aby zminimalizować liczbę złączeń i wykorzystać skanowanie kolumnowe; jest to idealne rozwiązanie dla analiz z przewagą operacji odczytu.
  • Normalizuj, gdy wzmożenie zapisu (write amplification), gorące punkty aktualizacji (update hotspots) lub samozłączenia (self-joins) powodują rywalizację o zasoby lub złożoność (na przykład, oddzielenie tabel pacjentów i wizyt, aby uniknąć eksplozji liczby wierszy przy samozłączeniach). Rozważ podejście hybrydowe: znormalizowane encje podstawowe z szerokimi, zdenormalizowanymi faktami lub zagnieżdżonymi elementami podrzędnymi.

• Widoki zmaterializowane: uwagi projektowe

  • Najlepsze dla stabilnych, przyrostowych agregacji na partycjonowanych tabelach bazowych. Odświeżanie widoków zmaterializowanych jest asynchroniczne; użytkownicy końcowi powinni tolerować okna nieaktualności danych lub w ostateczności odpytywać tabele bazowe.
  • Filtruj i grupuj według kolumny partycjonującej, aby umożliwić odświeżanie przyrostowe. Funkcje niedeterministyczne, nieobsługiwane złączenia lub UDF mogą uniemożliwić wykorzystanie widoków zmaterializowanych przez mechanizm przepisywania zapytań.

• Zapytania federacyjne, BigLake i pushdown:

  • Zapytania federacyjne odczytują dane bezpośrednio z systemów zewnętrznych (np. Cloud SQL) za pomocą SQL. Są wygodne do lekkich złączeń lub jednorazowych eksploracji, ale mają większe opóźnienia i bardziej rygorystyczne limity (quotas); w przypadku intensywnych analiz wyodrębnij dane do BigQuery.
  • Tabele BigLake unifikują zarządzanie (governance) danymi w data lake i hurtowni dzięki kontroli na poziomie kolumn i wierszy nad danymi w Cloud Storage lub w otwartych formatach tabel (takich jak Parquet). Przenoszenie predykatów i projekcji w dół (predicate and projection pushdown) zmniejsza ilość pobieranych bajtów; duże skany nadal faworyzują ładowanie danych do tabel natywnych w celu uzyskania maksymalnej wydajności.

• Tabele z symbolami wieloznacznymi i przestarzałe partycjonowanie (sharding):

  • Zapytania z użyciem symboli wieloznacznych (wildcard) to przestarzały wzorzec dla tabel partycjonowanych według daty (date-sharded). Preferuj natywne partycjonowanie, ale gdy jest to konieczne: SELECT … FROM bigquery-public-data.noaa_gsod.gsod* WHERE _TABLE_SUFFIX >= ‘2010’.

Optymalizacja zapytań i zarządzanie obciążeniem

• Przycinanie partycji (partition pruning) i klastrowanie:

  • Zawsze filtruj po kolumnie partycjonującej, aby unikać skanowania zimnych partycji. Używaj BETWEEN z wąskimi zakresami.
  • Uporządkuj klucze klastrujące według selektywności; wcześniejsze klucze powinny odpowiadać częstym filtrom i złączeniom. Unikaj klastrowania na kolumnach o bardzo niskiej kardynalności.

• Optymalizacja planu zapytania:

  • Używaj EXPLAIN i szczegółów wykonania, aby znaleźć niesymetryczne złączenia (skewed joins), duże przetasowania danych (shuffles) lub nieprzycięte skany.
  • Redukuj liczbę kolumn na wczesnym etapie za pomocą list SELECT i podzapytań; BigQuery jest bazą kolumnową i efektywnie odrzuca nieużywane kolumny.
  • Preferuj agregacje przybliżone (np. APPROX_QUANTILES) dla kompromisu między szybkością a kosztem przy dużych zbiorach danych.

  • Stosuj deduplikację za pomocą funkcji okienkowych, gdy źródła danych mogą powtarzać zdarzenia:

undefined

• Złączenia (joins) i denormalizacja:

  • Umieszczaj klucze złączeń w tej samej lokalizacji co klucze klastrujące, aby zredukować przetasowania (shuffle). Filtry Blooma lub preagregacja mogą pomóc w przypadku ekstremalnej asymetrii danych (skew).
  • Denormalizuj małe, wolno zmieniające się wymiary do tabel faktów, aby unikać gorących złączeń (hot joins). W przypadku bardzo szerokich wymiarów z częstymi aktualizacjami, normalizuj je i polegaj na kluczach klastrujących oraz zmaterializowanych złączeniach.

• Zarządzanie obciążeniem, sloty, edycje i autoskalowanie:

  • On-demand: BigQuery elastycznie skaluje zasoby obliczeniowe dla każdego zapytania; płacisz za każdy przeskanowany TB. Kontroluj koszty za pomocą ustawienia maksymalnej liczby rozliczanych bajtów i przycinania partycji.
  • Model oparty na pojemności z edycjami BigQuery (Standard, Enterprise, Enterprise Plus) wykorzystuje rezerwacje slotów. Wykup bazowe zobowiązania (commitments), twórz rezerwacje i przypisuj do nich projekty lub foldery. Autoskalowanie może dodawać sloty w okresach szczytowego obciążenia i zwalniać je, gdy zapotrzebowanie spada; używaj oddzielnych rezerwacji dla procesów ETL i BI, aby zapobiec wzajemnym zakłóceniom.
  • Priorytet zadań: interaktywny (domyślny) dla niskich opóźnień; wsadowy (batch) dla uzupełniania danych (backfills) i zaplanowanych zapytań. Zadania wsadowe są kolejkowane do momentu, aż w rezerwacji lub usłudze pojawią się wolne zasoby, a następnie uruchamiane po normalnym koszcie.

• Współbieżność i limity (quotas):

  • Używaj rezerwacji i przypisań, aby izolować krytyczne obciążenia. W przypadku środowisk z wieloma najemcami (mixed tenants), umieszczaj ich w oddzielnych rezerwacjach lub projektach z dostosowanymi limitami współbieżności.
  • Etykietuj zadania w celu atrybucji; monitoruj wykorzystanie slotów i opóźnienia w kolejkowaniu za pomocą widoku INFORMATION_SCHEMA.JOBS i metryk Cloud Monitoring.

• Pamięć podręczna BI i aktualność danych:

  • Pamięć podręczna wyników zapytań (query results cache) poprawia opóźnienia i obniża koszty dla identycznych zapytań; wyłącz ją w klientach wymagających aktualności danych poniżej godziny. Niektóre narzędzia BI buforują dane niezależnie — wyłącz buforowanie raportów, aby wyświetlać najnowsze wyniki.

Pozyskiwanie danych (ingestion), federacja i odzyskiwanie

• Zadania ładowania (load jobs):

  • Wsadowe ładowanie danych z Cloud Storage (preferowane formaty Avro/Parquet) jest niezawodne i efektywne kosztowo. Jawnie określaj schemat i kodowanie; niedopasowane kodowanie plików CSV jest częstą przyczyną rozbieżności co do bajta.
  • Używaj dekoratorów partycji lub ładuj dane do tabel partycjonowanych, aby unikać operacji MERGE. W przypadku dużych ładowań, zrównoleglaj proces według partycji.

• Przesyłanie strumieniowe i Storage Write API:

  • Starsza metoda przesyłania strumieniowego (legacy streaming inserts) jest prosta, ale ma bardziej rygorystyczne limity i może wykazywać spójność ostateczną (eventual consistency) przez kilka sekund; funkcja time travel na bardzo świeżych danych może mieć opóźnienia.
  • Storage Write API to zalecana ścieżka dla zapisów o wysokiej przepustowości i niskim opóźnieniu, z lepszą kontrolą deduplikacji. Używaj idempotencji (przesunięć w strumieniu - stream offsets), aby zapobiegać duplikatom.
  • Architektura aplikacji powinna tolerować zdarzenia w locie (in-flight): opóźniaj zapytania interaktywne o oczekiwany czas dostępności danych (np. 2x zaobserwowane opóźnienie) lub używaj znaków wodnych (watermarks) na partycjach opartych na czasie pozyskania danych.

• Dataflow i projektowanie kolejek niedoręczonych wiadomości (dead-letter):

  • W przypadku plików CSV od partnerów zawierających nieprawidłowo sformatowane wiersze, użyj Dataflow do parsowania i walidacji, zapisuj poprawne rekordy do BigQuery za pomocą Storage Write API, a błędy kieruj do tabeli niedoręczonych wiadomości (dead-letter table) w celu analizy.
  • Podczas odczytu z BigQuery na dużą skalę, preferuj odczyty oparte na zapytaniach (fromQuery), aby wybrać tylko niezbędne pola i zredukować przetasowania (shuffle).

• Zaplanowane zapytania i transformacje:

  • Używaj zaplanowanych zapytań do transformacji ELT, przyrostowych agregacji (rollups) i konserwacji tabel. Preferuj zapis do partycjonowanych i klastrowanych tabel docelowych. Zaplanowane zapytania domyślnie mają priorytet wsadowy (batch) i integrują się z rezerwacjami.

• Powiadomienia i obserwowalność:

  • Eksportuj logi audytowe BigQuery za pomocą ujścia logów (log sink) do Pub/Sub, aby wyzwalać alerty dotyczące konkretnych zadań wstawiania danych do tabeli:
    • Przykład filtra:

undefined

• Używaj logów audytowych Cloud Logging i widoków INFORMATION_SCHEMA, aby odkrywać wzorce użycia i egzekwować zasady ładu korporacyjnego (governance).

• Podróż w czasie (time travel), migawki (snapshots) i klony (clones):

  • Podróż w czasie (time travel) pozwala na odpytywanie tabeli według stanu na określony moment w przeszłości (domyślnie 7 dni). Użyj FOR SYSTEM_TIME AS OF, aby odczytać historyczne stany.
  • Migawki tabel (table snapshots) przechwytują widok na dany moment w czasie z mechanizmem copy-on-write; używaj ich do spójnego uzupełniania danych lub odzyskiwania. Klony tabel (table clones) zapewniają niemal natychmiastowe kopie metadanych do celów deweloperskich lub analiz “what-if”, z minimalnym zużyciem pamięci masowej aż do momentu rozbieżności.
  • Opcje odzyskiwania:
    • Małe błędy: odpytaj dane za pomocą podróży w czasie i przywróć je za pomocą INSERT...SELECT.
    • Duże przywracanie: utwórz tabelę z migawki lub klonu, a następnie zamień je miejscami.
  • Ustaw wygasanie tabel i partycji, aby wymusić retencję; zweryfikuj, czy okres retencji jest zgodny z potrzebami funkcji podróży w czasie.

• Źródła sfederowane:

  • Używaj federacji z Cloud SQL do lekkich złączeń; w przypadku ciągłej analityki lub dużych skanów, zaplanuj proces ekstrakcji i ładowania (extract-load) do natywnych tabel.
  • Tabele BigLake oparte na plikach Parquet/ORC w Cloud Storage mogą wymuszać tagi zasad (policy tags) oraz delegować filtrowanie i projekcję kolumn (push down); mimo to należy spodziewać się wyższych opóźnień niż w przypadku natywnej pamięci masowej.

Bezpieczeństwo, nadzór i kontrola kosztów

• IAM i zasada najmniejszych uprawnień:

  • Nadawaj role na poziomie zbioru danych (BigQuery Data Viewer, Data Editor) minimalnie, tylko zatwierdzonym użytkownikom; ogranicz dostęp do API do kont usług i wyselekcjonowanych grup.
  • Segreguj klientów i środowiska według zbiorów danych i projektów w celu izolacji. Przypisuj rezerwacje na projekt lub folder, aby zapobiec problemowi „hałaśliwych sąsiadów” (noisy neighbors).

• Autoryzowane widoki i bezpieczeństwo na poziomie wiersza:

  • Autoryzowane widoki udostępniają tylko wybrane kolumny/wiersze projektom zewnętrznym, podczas gdy projekt widoku zachowuje dostęp do tabeli. Utrzymuj widok i źródło w tym samym zbiorze danych lub użyj autoryzacji na poziomie zbioru danych dla projektu docelowego.
  • Bezpieczeństwo na poziomie wiersza z politykami dostępu do wierszy filtruje wiersze dla każdego użytkownika lub grupy w czasie zapytania; połącz je z autoryzowanymi widokami, aby uzyskać warstwową kontrolę.

• Bezpieczeństwo na poziomie kolumny i tagi polityk:

  • Używaj tagów polityk z Data Catalog do ochrony wrażliwych kolumn i włączania maskowania danych. Przypisuj dostęp do tagów (a nie do tabel), aby zachować zgodność z klasyfikacją danych. W przypadku dostępu dla partnerów, maskuj lub odmawiaj dostępu do kolumn z danymi osobowymi (PII) za pomocą tagów.

• BigQuery ML i analityka wewnątrz hurtowni:

  • Trenuj i udostępniaj modele bezpośrednio w BigQuery (na przykład regresja liniowa/logistyczna, XGBoost, K-means, szeregi czasowe) za pomocą

undefined

i

undefined

. Przechowuj cechy w tabelach partycjonowanych i używaj zaplanowanego ponownego trenowania.

• Modele zdalne pozwalają na wywoływanie modeli z Vertex AI lub zewnętrznych punktów końcowych z poziomu SQL w celu oceny (scoring) w ramach sfederowanego nadzoru. Buforuj wyniki w tabelach, aby amortyzować opóźnienia przy powtarzających się zapytaniach.

• Kontrola kosztów i rozwiązywanie problemów z wydajnością:

  • Zmniejsz liczbę skanowanych bajtów:
    • Partycjonuj i klastruj; zawsze filtruj po tych kluczach.
    • Używaj SELECT tylko dla potrzebnych kolumn; unikaj SELECT *.
    • W stosownych przypadkach używaj zmaterializowanych widoków i buforowania wyników.
    • Ustaw maximum_bytes_billed, aby ograniczyć koszty.
  • Rozwiązuj problemy z wydajnością:
    • Sprawdzaj szczegóły wykonania zadania pod kątem nierównomiernego rozkładu danych (skew), nieprzyciętych partycji lub gorących punktów w operacji shuffle. Zmień klucze złączeń lub dokonaj preagregacji, aby zredukować shuffle.
    • Weryfikuj przepisywanie zapytań z użyciem MV; upewnij się, że predykaty i funkcje deterministyczne są kompatybilne.
    • W przypadku pulpitów nawigacyjnych, na których brakuje świeżych danych strumieniowych, uwzględnij opóźnienie spójności lub wyłącz buforowanie po stronie klienta.
  • Wgląd w nadzór: przeprowadzaj audyt za pomocą Cloud Logging, INFORMATION_SCHEMA i szczegółowych etykiet zadań, aby realizować obciążenia zwrotne (chargeback) i identyfikować wartości odstające.

Praktyczny scenariusz problemu

NovaCare Health prowadzi regionalną platformę telemedyczną. Projekt oparty na jednej tabeli patient_and_visit sprawdzał się w fazie pilotażowej, ale przy 100-krotnym wzroście skali raporty przekraczają limit czasu, pojawiają się duplikaty z operacji upsert w strumieniowaniu, a partnerzy wymagają ścisłej izolacji danych.

Podejście:

1. Przeprojektowanie schematu i układu

   • Utwórz znormalizowane tabele podstawowe: patients(patient_id, demographics, updated_at) i visits(visit_id, patient_id, visit_ts, metrics, updated_at).
   • Ustaw visits jako tabelę partycjonowaną według DATE(visit_ts) i klastrowaną według patient_id oraz visit_id. Małe wymiary referencyjne pozostaw zdenormalizowane w tabeli visits, aby przyspieszyć działanie pulpitów nawigacyjnych.
   • Uzasadnienie: Normalizacja pozwala uniknąć kosztownych self-joinów i ciężkich aktualizacji wierszy w jednej, mocno obciążonej tabeli. Partycjonowanie przycina skanowanie danych historycznych; klastrowanie współlokuje złączenia i filtry po patient_id, redukując operację shuffle.

2. Pozyskiwanie danych za pomocą Storage Write API i wymuszanie idempotentności

   • Użyj potoku Dataflow do parsowania przychodzących zdarzeń, ich walidacji i zapisu do nazwanych strumieni w Storage Write API z idempotentnymi offsetami.
   • Przekierowuj niepoprawnie sformatowane zdarzenia do tabeli BigQuery typu dead-letter w celu analizy.
   • Uzasadnienie: Storage Write API zapewnia wyższą przepustowość, niższe opóźnienia i lepsze gwarancje deduplikacji niż starsze metody strumieniowania. Mechanizm dead-lettering pozwala zachować wgląd w problemy z jakością danych od partnerów.

3. Projektowanie z myślą o świeżości i deduplikacji w zapytaniach

   • W przypadku analityki interaktywnej, dodaj krótki znak wodny (watermark) (np. 2× obserwowanej dostępności) przed odpytaniem najnowszej partycji; lub filtruj po _PARTITIONDATE, gdzie partition_date <= CURRENT_DATE(), aby wykluczyć wiersze w trakcie przetwarzania.
   • Użyj ROW_NUMBER() OVER (PARTITION BY visit_id ORDER BY event_ts DESC) = 1 w widokach, które muszą tolerować ponowienia na wcześniejszych etapach.
   • Uzasadnienie: Strumieniowanie jest ostatecznie spójne przez krótki czas. Watermarking i deduplikacja oparta na oknach chronią pulpity nawigacyjne przed przejściowymi lukami i duplikatami.

4. Przyspieszanie popularnych agregacji za pomocą zmaterializowanych widoków

   • Utwórz zmaterializowane widoki (MV) wyrównane do partycji nad tabelą visits dla dziennych wskaźników KPI grupowanych według DATE(visit_ts) i kohort pacjentów. Upewnij się, że predykaty są kompatybilne z mechanizmem przepisywania zapytań.
   • Uzasadnienie: MV redukują opóźnienia i liczbę skanowanych bajtów dla cyklicznych raportów; BigQuery w sposób przezroczysty przepisuje zapytania, aby korzystały z MV.

5. Wymuszanie izolacji dzierżawców i szczegółowych zabezpieczeń

   • Umieść każdego partnera w dedykowanym zbiorze danych. Nadaj grupom partnerskim role na poziomie zbioru danych z najmniejszymi uprawnieniami.
   • Publikuj autoryzowane widoki dla współdzielonych, międzypartnerskich benchmarków bez ujawniania surowych tabel.
   • Zastosuj tagi polityk do kolumn z danymi osobowymi (PII) i dodaj polityki dostępu do wierszy w tabeli visits, aby ograniczyć dostęp według partner_id na potrzeby wewnętrznej analityki wielodostępowej (multi-tenant).
   • Uzasadnienie: Segmentacja typu „zbiór danych na dzierżawcę” w połączeniu z autoryzowanymi widokami i tagami polityk wymusza zasadę najmniejszych uprawnień, jednocześnie umożliwiając kontrolowane udostępnianie.

6. Zarządzanie obciążeniami za pomocą edycji, rezerwacji i autoskalowania

   • Zakup moc obliczeniową w ramach edycji BigQuery i utwórz dwie rezerwacje: etl (ujścia Dataflow, zaplanowane transformacje) i bi (zapytania ad hoc/raportowanie). Przypisz odpowiednio projekty i włącz autoskalowanie, aby absorbować szczyty obciążenia.
   • Planuj zapytania ELT jako zadania wsadowe (batch) z jasnymi umowami SLA; ustaw maximum_bytes_billed dla projektów interaktywnych.
   • Uzasadnienie: Oddzielne rezerwacje zapobiegają „głodzeniu” systemów BI przez procesy ETL. Autoskalowanie obsługuje obciążenia szczytowe bez nadmiarowego alokowania zasobów.

7. Nadzorowanie kosztów i obserwowanie użycia

   • Wymagaj filtrów na visit_ts; odrzucaj zapytania SELECT * we współdzielonych widokach. Użyj INFORMATION_SCHEMA.JOBS, aby wykrywać nieskrócone skanowania i złączenia z nierównomiernym rozkładem danych (skewed joins).
   • Eksportuj logi audytowe BigQuery do Pub/Sub za pomocą ujścia logów (log sink) przefiltrowanego do zadań insert na tabeli visits, aby wyzwalać alerty monitorujące nieoczekiwane wzrosty.
   • Uzasadnienie: Przycinanie bajtów (byte-pruning) i projekcja kolumn kontrolują koszty; logi audytowe ujawniają wzorce dostępu i anomalie w czasie zbliżonym do rzeczywistego.

8. Planowanie odzyskiwania i uzupełniania danych

   • Włącz domyślne polityki wygasania tabel, które są zgodne z wymogami zgodności i potrzebami funkcji time travel. W przypadku dużych edycji, utwórz migawkę, uruchom zmiany i w razie potrzeby szybko je wycofaj. Używaj klonów tabel do analiz typu „co-jeśli” w środowiskach deweloperskich/testowych bez duplikowania danych.
   • Uzasadnienie: Migawki i klony zapewniają szybkie i wydajne pod względem miejsca siatki bezpieczeństwa; funkcja time travel obejmuje małe przywracania naprawcze.

9. Integracja ML wewnątrz hurtowni

   • Przechowuj przygotowane cechy (engineered features) w tabelach partycjonowanych i trenuj modele klasyfikacyjne BigQuery ML do oceny ryzyka ponownej hospitalizacji. Dla modeli zewnętrznych hostowanych na Vertex AI, utwórz modele zdalne i buforuj predykcje w tabeli klastrowanej, aby uzyskać złączenia o niskim opóźnieniu.
   • Uzasadnienie: Utrzymywanie ML blisko danych redukuje ich przemieszczanie i złożoność nadzoru; buforowanie zdalnej inferencji amortyzuje opóźnienia i koszty.

Dzięki temu projektowi NovaCare osiąga przewidywalną wydajność przy 100-krotnym obciążeniu, silną izolację dzierżawców i kontrolowane koszty, zachowując jednocześnie analitykę o niskim opóźnieniu i odtwarzalne mechanizmy odzyskiwania danych.

← Przechowywanie danych · Wszystkie domeny · Przetwarzanie strumieniowe z Dataflow i Apache Beam →

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

Przeglądaj Google →