Federacja danych bez ETL z BigQuery do AlloyDB

1. Przegląd

W części 1 udało nam się przekształcić chaotyczne, nieuporządkowane pliki PDF w czyste, inteligentne i uporządkowane tabele w BigQuery za pomocą Knowledge Catalog i DataScan. Teraz mamy solidną hurtownię danych.

Jeśli potrzebujesz szybkiego przypomnienia, w części 1 tego laboratorium zajęliśmy się przypadkiem użycia fikcyjnej sieci franczyzowej Frozen Yogurt i przekształciliśmy 400 jej nieustrukturyzowanych plików PDF – zawierających tekst, tabele i obrazy – w czysto ustrukturyzowane tabele BigQuery z automatycznie wywnioskowanymi relacjami między nimi za pomocą BigQuery Knowledge Catalog i Dataplex.

Co utworzysz

W tej sesji skonfigurujemy AlloyDB for PostgreSQL i zrobimy coś magicznego: sfederujemy dane BigQuery bezpośrednio w AlloyDB. Oznacza to, że nasza aplikacja transakcyjna może w czasie rzeczywistym wysyłać zapytania do danych z magazynu bez kopiowania ani duplikowania żadnych informacji.

Na tym etapie deweloper musi zadać sobie to pytanie:

„Jeśli dane są już w BigQuery, po co w to wszystko mieszać AlloyDB? Dlaczego aplikacja nie wykonuje po prostu instrukcji SELECT bezpośrednio w BigQuery?”

Oto powody:

Dzięki Lakehouse Federation możesz używać silnika zapytań AlloyDB do obsługi transakcyjnych i analitycznych zbiorów zadań aplikacji w tym samym interfejsie. Możesz też zmaterializować lub zaimportować te dane do AlloyDB, aby uzyskać do nich szybszy dostęp i używać ich w aplikacjach. Dzięki temu możesz korzystać z AlloyDB AI i silnika kolumnowego.

Możesz używać AlloyDB jako transakcyjnej bazy danych, a także przechowywać duże ilości danych w BigQuery lub BigLake. Aplikacje zwykle integrują się niezależnie z każdym z tych systemów, aby uzyskiwać dostęp do danych w różnych usługach Google Cloud. Federacja Lakehouse dla AlloyDB umożliwia korzystanie z obsługi zapytań sfederowanych w AlloyDB zaimplementowanej jako zewnętrzny moduł danych w celu uzyskiwania dostępu do danych BigQuery i AlloyDB za pomocą interfejsu SQL w AlloyDB.

Zamiast tworzyć podatny na uszkodzenia potok ETL do wykonywania zapytań na danych BigQuery z AlloyDB, użyjemy zapytań sfederowanych. AlloyDB będzie działać jako ujednolicony punkt końcowy, który w razie potrzeby będzie płynnie łączyć się z BigQuery.

Zacznijmy tworzyć.

1a3f48f6d70b16ad.png

Czego się nauczysz

  • Jak skonfigurować klaster, instancję i sieć AlloyDB jednym kliknięciem
  • Konfigurowanie rozszerzenia na potrzeby federacji
  • Jak skonfigurować federację z BigQuery do AlloyDB
  • Wypróbuj

Wymagania

  • przeglądarka, np. Chrome lub Firefox;
  • Projekt Google Cloud z włączonymi płatnościami.
  • Podstawowa znajomość SQL.

2. Zanim zaczniesz

Utwórz projekt

  1. W konsoli Google Cloud na stronie wyboru projektu wybierz lub utwórz projekt Google Cloud.
  2. Sprawdź, czy w projekcie Cloud włączone są płatności. Dowiedz się, jak sprawdzić, czy w projekcie włączone są płatności.
  1. Będziesz używać Cloud Shell, czyli środowiska wiersza poleceń działającego w Google Cloud. U góry konsoli Google Cloud kliknij Aktywuj Cloud Shell.

Obraz przycisku aktywowania Cloud Shell

  1. Po połączeniu z Cloud Shell sprawdź, czy uwierzytelnianie zostało już przeprowadzone, a projekt jest już ustawiony na Twój identyfikator projektu, używając tego polecenia:
gcloud auth list
  1. Aby potwierdzić, że polecenie gcloud zna Twój projekt, uruchom w Cloud Shell to polecenie:
gcloud config list project
  1. Jeśli chcesz się uwierzytelnić
gcloud auth login
  1. Jeśli projekt nie jest ustawiony, użyj tego polecenia, aby go ustawić:
export PROJECT_ID=<YOUR_PROJECT_ID>
gcloud config set project <YOUR_PROJECT_ID>
  1. Włącz wymagane interfejsy API: aby włączyć wszystkie wymagane interfejsy API, uruchom to polecenie:
gcloud services enable alloydb.googleapis.com

Pułapki i rozwiązywanie problemów

Syndrom „projektu widma”

Uruchomiono polecenie gcloud config set project, ale w interfejsie konsoli wyświetla się inny projekt. Sprawdź identyfikator projektu w menu w lewym górnym rogu.

Bariera rozliczeniowa

Projekt został włączony, ale zapomniano o koncie rozliczeniowym. AlloyDB to mechanizm o wysokiej wydajności, który nie uruchomi się, jeśli „zbiornik paliwa” (płatności) jest pusty.

Opóźnienie propagacji interfejsu API

Kliknięto „Włącz interfejsy API”, ale w wierszu poleceń nadal widnieje znak Service Not Enabled. Odczekaj 60 sekund. Chmura potrzebuje chwili, aby aktywować swoje neurony.

Limit Quags

Jeśli korzystasz z nowego konta próbnego, możesz osiągnąć regionalny limit instancji AlloyDB. Jeśli us-central1 się nie powiedzie, spróbuj us-east1.

3. Szybkie podsumowanie danych z części 1

W tej sekcji musisz się upewnić, że dane strukturalne wyodrębnione z nieustrukturyzowanych plików PDF są dostępne w BigQuery. Jeśli nie udało Ci się obejrzeć części 1 lub nie masz konta rozliczeniowego, możesz wykonać te czynności:

Otwórz konsolę Google Cloud na osobistym koncie Gmail i kliknij przycisk Aktywuj Cloud Shell w prawym górnym rogu konsoli:

91567e2f55467574.png

Następnie wykonaj czynności opisane w sekcji poniżej dotyczącej braku konta płatniczego:

Teraz, gdy mamy już dane w BigQuery, przejdźmy do następnych kroków.

4. Konfigurowanie klastra, instancji i sieci AlloyDB

Dostępna jest internetowa aplikacja szybkiego startu, która pomoże Ci skonfigurować klaster AlloyDB, instancję i inne zależności. Aby skonfigurować go jednym kliknięciem, wykonaj czynności 2–4 w tym module:

https://codelabs.developers.google.com/quick-alloydb-setup

Gdy klaster zostanie utworzony, otwórz stronę Przegląd klastra i skopiuj z niej szczegóły konta usługi.

7cd9d04e06c826d8.png

5. Konfigurowanie uprawnień

Przyznaj temu kontu usługi uprawnienia BigQuery

  1. Otwórz kolejno Administracja > Uprawnienia.
  2. Kliknij Przyznaj dostęp.
  3. Wklej adres konta usługi AlloyDB w polu Nowe podmioty zabezpieczeń.
  4. Przypisz te role:
  • Wyświetlający dane BigQuery (roles/bigquery.dataViewer): umożliwia odczytywanie danych.
  • Użytkownik BigQuery (roles/bigquery.user): umożliwia uruchamianie zapytań.
  • (Opcjonalnie, ale zalecane) Użytkownik sesji odczytu BigQuery (roles/bigquery.readSessionUser): optymalizuje odczytywanie dużych zbiorów danych za pomocą interfejsu Storage Read API.

6. Łączenie z AlloyDB i włączanie rozszerzenia BigQuery

Teraz połączymy się z nową instancją AlloyDB, aby skonfigurować rozszerzenie federacji. W tym celu użyjemy AlloyDB Studio.

  1. Na stronie Przegląd klastra (konsola AlloyDB) kliknij AlloyDB Studio.

1dd78902dc2b4f39.png

  1. Połącz się z bazą danych, używając nazwy użytkownika i hasła skonfigurowanych podczas szybkiej konfiguracji AlloyDB.
  2. Po nawiązaniu połączenia na karcie Edytor zapytań po prawej stronie wpisz te instrukcje i URUCHOM je kolejno:
CREATE EXTENSION IF NOT EXISTS  bigquery_fdw;

CREATE SERVER bigquery_server FOREIGN DATA WRAPPER bigquery_fdw;

CREATE USER MAPPING FOR postgres SERVER bigquery_server;
  1. Po wykonaniu tych czynności przejdź do panelu eksploratora po lewej stronie i przewiń w dół do tabel BigQuery:

efe4f8be930824aa.png

  1. Kliknij 3 kropki i wybierz „Połącz tabelę BigQuery”.
  2. W otwartym okienku Connect BigQuery Table (Połącz tabelę BigQuery) wybierz project_id i nazwę zbioru danych BigQuery (utworzonego w części 1), z którego chcesz wysyłać zapytania o dane w bazie danych AlloyDB.

1cc345197b0fbddf.png

  1. Aby połączyć wszystkie dane z AlloyDB, wybierz każdą tabelę po kolei. Dzięki temu możemy sprawdzić typy kolumn i upewnić się, że są obsługiwane w AlloyDB.

Jeśli chcesz to zrobić za pomocą SQL zamiast metody „wskaż i kliknij”:

CREATE FOREIGN TABLE <<TABLE_NAME>> (
      "cas_number" VARCHAR, "ingredient_name" VARCHAR, "max_moisture_percentage" DOUBLE PRECISION, "ph_range" VARCHAR, "purity_percentage" DOUBLE PRECISION, "shelf_life_months" BIGINT, "specific_gravity_range" VARCHAR
    ) SERVER "bigquery_server" OPTIONS (
      project '<<PROJECT_ID>>',
      dataset 'froyo_data',
      table '<<BQ_TABLE_NAME>>'
    );

Magia!!!

Właśnie utworzyliśmy „tabele obce” w AlloyDB. Wyglądają i działają jak zwykłe tabele PostgreSQL, ale nie przechowują żadnych danych. Gdy wysyłasz zapytanie, AlloyDB natychmiast przekazuje je do BigQuery, pobiera wyniki i zwraca je do Ciebie.

7. Testowanie federacji w AlloyDB

Sprawdźmy, czy możemy wykonywać zapytania dotyczące naszego obszernego zbioru danych analitycznych BigQuery bezpośrednio z transakcyjnej bazy danych PostgreSQL.

W AlloyDB Studio uruchom zapytanie, aby dowiedzieć się, jakie alergeny zawiera „Midnight Swirl” (to samo pytanie, które zadaliśmy w części 1, ale tym razem zadane z poziomu AlloyDB):

SELECT
    p.product_name,
    i.ingredient_name,
    a.allergen_name
FROM
    consistsof c
INNER JOIN product p
    ON c.product_id = p.product_id
INNER JOIN ingredient i
    ON c.ingredient_id = i.ingredient_name
LEFT OUTER JOIN containsallergen a
    ON i.ingredient_id = a.ingredient_id
WHERE
    UPPER(p.product_name) LIKE '%MIDNIGHT%SWIRL%'
    AND a.allergen_name IS NOT NULL;

Boom. Powinny pojawić się dokładnie te same wyniki co w BigQuery.

7d0be18295c5dfbd.png

8. Czyszczenie danych

Po ukończeniu tego laboratorium nie zapomnij usunąć klastra i instancji AlloyDB.

Powinien on zwalniać miejsce w klastrze wraz z jego instancjami.

9. Gratulujemy utworzenia ujednoliconej warstwy danych

Zastanów się, co właśnie osiągnęliśmy:

  1. Nasza aplikacja transakcyjna (działająca na AlloyDB) może obsługiwać szybkie, równoczesne sesje użytkowników.
  2. Gdy potrzebuje obszernych danych analitycznych lub kontekstu historycznego (np. szczegółów dostawcy lub złożonych map składników), wysyła zapytanie do schematu danych froyo_dataschema w BigQuery.
  3. Zero ETL. Żadne potoki danych nie ulegają awarii. Brak niesynchronizowanych baz danych. Przechowujemy dane tylko raz (w BQ) i przetwarzamy je tam, gdzie są potrzebne.

Teraz, gdy nasza baza danych – zarówno analitycznych, jak i transakcyjnych – jest solidna i wzajemnie połączona, możemy przejść do przyjemniejszej części.

W części 3 utworzymy aplikację z wieloma agentami, która będzie działać w tej architekturze i zarządzać działalnością firmy Froyo.