Replikacja danych do BigQuery - przewodnik po procesach ETL

›

Replikacja danych do BigQuery – Jedyny przewodnik po procesach ETL i ELT w GCP jakiego potrzebujesz

Co to jest BigQuery?

BigQuery to nowoczesny, bezserwerowy kombajn analityczny łączący cechy hurtowni danych, narzędzia do tworzenia modeli Machine Learning, zapytań i procedur SQL, automatyzacji przepływów danych oraz zasilania Twoich narzędzi typu Business Intelligence.

Co najfajniejsze, każdy z was może z niego skorzystać bez żadnych opłat licencyjnych. Samo narzędzie nie tylko świetnie nadaje się dla małych biznesów ale przede wszystkim ogromnych korporacji.

Aby cieszyć się jednak w pełni z jego zalet i móc przeprowadzać nasze zadania analityczne na danych, musimy w pierwszej kolejności skonfigurować procesy replikacji z naszych oryginalnych źródeł danych do tabel i zbiorów danych w naszej hurtowni.

W praktyce wygląda to tak, że nawet małe firmy nierzadko swoje dane przechowują w różnych źródłach. I nie byłoby z tym nic złego gdyby nie fakt, że są to na tyle różne struktury i typy danych, że nie istnieje jedno rozwiązanie, którego moglibyśmy z sukcesem i małymi kosztami użyć do tworzenia procesów ETL.

Ten przewodnik powstał po to abyś nie musiał się więcej zastanawiać jakiego konkretnie narzędzia dostępnego w GCP powinieneś użyć aby móc replikować dane do hurtowni uwzględniając koszt jego utrzymania, poziom trudności implementacji oraz czas potrzebny na jego wdrożenie.

Co to jest proces ETL?

Proces ETL (z angielskiego Extract, Transform and Load) jest to proces polegający na pobraniu danych ze źródła, transformacji i załadowaniu ich do celu, jakim jest w naszym przypadku hurtownia danych.

Proces ELT (Extract, Load, Transform) różni się tym, że transformację robimy już po załadowaniu naszych danych do hurtowni danych.

Odwrotny proces ETL polegać będzie natomiast na przekazaniu danych z hurtowni danych z powrotem do źródła (np. po uprzednim wzbogaceniu ich innymi danymi lub wynikami modeli analitycznych).

Batch Processing vs Streaming czyli różne rodzaje procesów ETL do BigQuery

Procesy replikacyjne do BigQuery mogą przybrać dwie formy – strumieniowania (tzw. streaming) danych oraz przetwarzania wsadowego (tzw. batch processing).

Strumieniowanie danych polega na ciągłym przekazywaniu zmian w Twoim źródle danych i odzwierciedleniu ich w hurtowni danych BigQuery.

Przetwarzanie wsadowe dla odmiany uruchomi się automatycznie o określonej porze i nadpisze bądź doda nowe dane do Twoich tabel.

Zaletą strumieniowania jest to, że masz praktycznie ciągły dostęp do tych samych danych, które są w tabelach źródłowych, wadą natomiast jest fakt, że musisz za taki proces więcej zapłacić w GCP.

Ponieważ przetwarzanie wsadowe jest darmowe idealnie się nada w sytuacjach kiedy możesz je zaplanować na jakąś konkretną godzinę tak aby Twoi menedżerowie mieli zawsze dostęp do danych podsumowujących np. wczorajszy dzień.

Rodzaje źródeł danych

Do hurtowni danych możemy utworzyć procesy replikacyjne z wielu różnych rodzajów źródeł. Aby dobrze zrozumieć, jakiej technologii będziemy używać do utworzenia procesu ETL najpierw przybliżę wam rodzaje najpopularniejszych źródeł danych oraz ich charakterystykę.

Relacyjne Bazy Danych

Relacyjne bazy danych (ang. relational databases) to rodzaj baz danych, w których dane są przechowywane w postaci tabel. Tabele są podzielone na kolumny, które reprezentują różne typy danych, takie jak liczby, tekst lub daty. Każdy wiersz tabeli reprezentuje pojedynczy rekord danych.

Relacyjne bazy danych są obecnie najczęściej używanym typem baz danych w biznesie. Są używane do przechowywania danych w takich aplikacjach jak systemy ERP, CRM, e-commerce i analityka danych. Nierzadko będą również główną bazą danych w Twoim biznesie odpowiadającą za zasilanie waszych aplikacji i serwisów biznesowych.

Największymi dostawcami systemów zarządzania relacyjnymi bazami danych (RDBMS) są:

Relacyjne bazy danych charakteryzują się następującymi cechami:

Ja opiszę jak optymalnie tworzyć procesy ETL z:

Dokumentowe Bazy Danych

Nierelacyjne (dokumentowe) bazy danych to rodzaj baz danych, w których dane są przechowywane w postaci dokumentów. Dokumenty są podobne do obiektów w językach programowania obiektowego, takich jak Java czy C++. Mogą zawierać różne typy danych, takie jak liczby, tekst, daty i inne.

W biznesie najczęściej spotykanymi dostawcami systemów zarządzania dokumentowymi bazami danych (NoSQL) są:

Dokumentowe bazy danych charakteryzują się następującymi cechami:

Nierelacyjne bazy danych są często używane w aplikacjach, które wymagają szybkiego i elastycznego przetwarzania danych. Są również popularnym wyborem do aplikacji, które przetwarzają duże ilości danych, takich jak aplikacje internetowe i mobilne.

Interfejsy API

Interfejs programowania aplikacji (API) to zestaw reguł i protokołów, które umożliwiają aplikacjom komunikowanie się ze sobą. API określają, jak aplikacje mogą wysyłać żądania do innych aplikacji i jak otrzymywać odpowiedzi.

API są powszechnie używane w aplikacjach internetowych i mobilnych. Na przykład, gdy przeglądasz produkt w sklepie internetowym, API jest używane do wysłania żądania do serwera sklepu internetowego. Serwer sklepu internetowego odpowiada na żądanie, zwracając informacje o produkcie, takie jak cena, opis i zdjęcia.

API są również używane w aplikacjach biznesowych. Na przykład, gdy firma wykorzystuje system CRM do zarządzania relacjami z klientami, API są używane do przesyłania danych między systemem CRM a innymi systemami firmy, takimi jak system księgowy lub system magazynowy.

Oto kilka kluczowych cech interfejsów API:

API w analityce pełni bardzo ważną rolę gdyż pozwala nam po uprzednim uwierzytelnieniu replikować dane do naszej hurtowni danych BigQuery co powoduje, że znacznie zwiększamy możliwości analityczne naszego biznesu.

Pliki płaskie i arkusze kalkulacyjne

Poza bazami danych, do Twojej hurtowni danych BigQuery możesz zautomatyzować ładowanie plików płaskich bądź danych z arkuszy kalkulacyjnych. W poniższej sekcji wypisze formaty plików, które obecnie obsługiwane są natywnie przez Google BigQuery.

Pliki AVRO, ORC oraz Parquet

Plik te to najoptymalniejsza forma do przechowywania i wymiany danych w BIgQuery. Są kompaktowe i wydajne, dzięki czemu są idealne do przechowywania dużych zbiorów danych.

Są oparte na schematach, które definiują strukturę danych. Schemat może być określony w pliku tekstowym lub wewnątrz pliku. Schemat pozwala na łatwe odczytanie i zapisanie danych z tego typu plików.

Poniżej zebrałem kilka najważniejszych cech tych plików

Kompaktowa struktura - dzięki czemu zajmują mniej miejsca na dysku.
Wydajność - dzięki czemu mogą szybko być odczytywane i zapisywane.
Schematyczność - umożliwia to łatwe odczytanie i zapisanie danych z pliku AVRO.
Współpraca: Pliki AVRO są popularnym wyborem do wymiany danych między różnymi systemami i aplikacjami.

Plik JSONL

Plik JSONL to format danych tekstowych, który jest używany do przechowywania list obiektów JSON. Pliki JSONL są podobne do plików JSON, ale zamiast jednego obiektu JSON na linię, każdy obiekt JSON jest oddzielony nowym wierszem.

Pliki JSONL są często używane w aplikacjach, które przetwarzają duże ilości danych, takich jak analityka danych, maszynowe uczenie i big data. Są również popularnym wyborem do wymiany danych między różnymi systemami i aplikacjami.

Oto kilka kluczowych cech plików JSONL:

Kompaktowa struktura: Pliki JSONL są kompaktowe, dzięki czemu zajmują mniej miejsca na dysku.
Wydajność: Pliki JSONL są wydajne, dzięki czemu mogą szybko być odczytywane i zapisywane.
Łatwość odczytu: Pliki JSONL są łatwe do odczytania, ponieważ każdy obiekt JSON znajduje się na osobnej linii.
Współpraca: Pliki JSONL są popularnym wyborem do wymiany danych między różnymi systemami i aplikacjami.

Poniżej znajduje się przykład pliku JSONL:

				
					{ 
  "name": "Janek Kowalski",
  "age": 30,
  "city": "Warszawa"
}
{
  "name": "Janina Kowalska", 
  "age": 25,
  "city": "Poznań"
}

W tym przykładzie każdy obiekt JSON zawiera trzy pola: imię, wiek i miasto.

Pliki CSV

Plik CSV (ang. Comma-Separated Values) to format danych tekstowych, który jest używany do przechowywania danych tabelarycznych. Pliki CSV są często używane do wymiany danych między różnymi systemami i aplikacjami, takimi jak arkusze kalkulacyjne, bazy danych i aplikacje analityczne.

Plik CSV jest podzielony na wiersze i kolumny. Każdy wiersz zawiera jeden rekord danych, a każda kolumna zawiera jeden element danych. Dane w każdej kolumnie są rozdzielone przecinkami.

Oto przykład pliku CSV (rozdzielanego przecinkami)

				
					name,age,city
John Doe,30,London
Jane Doe,25,New York

W tym przykładzie plik zawiera dwa rekordy danych. Pierwszy rekord zawiera imię „John Doe”, wiek 30 i miasto „London”. Drugi rekord zawiera imię „Jane Doe”, wiek 25 i miasto „New York”.

Pliki CSV są łatwe do odczytania i zapisania. Mogą być odczytywane za pomocą wielu różnych narzędzi, w tym arkuszy kalkulacyjnych, edytorów tekstu i aplikacji analitycznych.

Oto kilka kluczowych cech plików CSV:

Kompaktowa struktura: Pliki CSV są kompaktowe, dzięki czemu zajmują mniej miejsca na dysku.
Wydajność: Pliki CSV są wydajne, dzięki czemu mogą szybko być odczytywane i zapisywane.
Łatwość odczytu: Pliki CSV są łatwe do odczytania, ponieważ dane są podzielone na wiersze i kolumny.
Współpraca: Pliki CSV są popularnym wyborem do wymiany danych między różnymi systemami i aplikacjami.

Źródła danych Google

Jako, że źródła danych Google mają w większości bardzo uproszczony proces replikacji do hurtowni danych BigQuery stworzę z tego oddzielną kategorię i pokażę Ci jak w prosty sposób bardzo szybko zacząć replikować dane do BigQuery z Google Analytics, Google Ads, Google Campaign Manager, Google Ads Manager, Google Play, Google Merchant Center, Youtube, Firebase czy Google Ads 360.

Osobiście uważam, że możliwość ładowania danych z najpopularniejszych programów Google, z których korzystacie na co dzień czyni BigQuery fenomenalnym narzędziem szczególnie dla działów marketingu, promocji i sprzedaży, które korzystają z nich na co dzień.

Inni dostawcy chmury obliczeniowej

Ostatnimi dwoma typami źródeł danych, które opiszemy w naszym poradniku będą popularne źródła dwóch głównych dostawców rozwiązań chmury obliczeniowej.

Opiszę jakiej technologii użyć aby w prosty sposób stworzyć proces ETL z Amazon S3 oraz Azure Blob Storage.

Technologie, których można użyć do replikacji

W ciągu ostatnich kilku lat Google Cloud znacznie zwiększył ilośc techhnologii natywnych umożliwiających tworzenie procesów replikacyjnych. Jeszcze kilka lat temu zmuszeni byliśmy używać zaledwie trzech technologii natywnych. Dzisiaj lista jest dość długa, a większość technologii jest usprawniania na bieżąco. To pozwala optymalizować czas potrzebny na wdrożenie jak i również zmniejszyć koszt utrzymania.

Poniżej wylistowałem funkcjonalności Google Cloud, którymi możecie posłużyć się do tworzenia procesów replikacyjnych do BigQuery. Ta lista nie jest pełna, ale zapewniam was, że w większości przypadków, zakładając używanie natywnych technologii Google Cloud, będziecie sięgać właśnie po którąś z technologii znajdującej się na poniższej liście.

DataStream
DataFusion
DataFlow
DataPrep
Cloud Composer
Cloud RUN
Cloud Functions
BigQuery Data Transfer
Cloud Storage Data Transfer

Stworzyłem również macierz ukazującą, których z tych technologii możecie użyć w zależności od źródła przetrzymywania waszych danych.

Jak widzicie są na tej liście narzędzia, które w teorii pomogą wam stworzyć proces ETL z każdego źródła. Pisze tutaj o Cloud Composer oraz Cloud RUN. Należy jednak dodać, że nie są to technologie przeznaczone do ich tworzenia a technologie, które mogą pomóc je przeprowadzić i zautomatyzować.

Dla przykładu, Cloud Composer jest narzędziem do orkiestracji tasków i sam w sobie nie jest w stanie pobierać i ładować danych, natomiast w bardziej skomplikowanym przepływie danych może być jego “mózgiem”, i zarządzać innymi technologiami, które będą brały udział w tym procesie, co finalnie stworzy proces bardziej przejrzystym i zorganizowanym.

Wybierając odpowiednią technologię powinniśmy wziąć pod uwagę kilka dodatkowych czynników.

Wspomniane wyżej technologie są mocno oparte na programowaniu.
W innych scenariuszach zbawienne będą rozwiązania, które możemy “wyklikać” z interaktywnego GUI bez znajomości Pythona, JavaScript czy GO, i których utrzymanie będzie mniej pracochłonne.

Opiszmy więc dokładniej każdą z powyższych technologii zaznaczając plusy i minusy z jej korzystania.

DataStream

DataStream jest natywnym narzędziem Google Cloud umożliwiającym replikowanie danych z relacyjnych baz danych SQL od najpopularniejszych dostawców takich jak MySQL, PostgreSQL, Oracle, Cloud SQL czy AlloyDB.

Jest oparty na technologii CDC (Change Data Capture), która odzwierciedla wszystkie operacje typu DML (Data Manipulation Language) w Twojej bazie danych.
Dla przykładu, jeśli w Twoim źródle została przeprowadzona operacja UPDATE na konkretnym wierszu – Datastream odzwierciedla ją w Twojej hurtowni danych.
Takie podejście gwarantuje, że zawsze operujesz na świeżych danych.

DataStream jest również prosty w konfiguracji. Jedyne czego będziesz potrzebować to przygotowanie Twojej bazy danych do możliwości konfiguracji procesów CDC.

Proces konfiguracji różni się trochę w zależności od typu bazy danych oraz dostawcy.

W większości przypadków trzeba utworzyć slot publikacyjny lub replikacyjny (PostgreSQL) i/lub włączyć odpowiednie flagi na bazie i umożliwić czytanie plików z logami (MySQL). Prerekwizytów jest trochę więcej a pełną ich listę w zależności od źródła, które chcecie replikować znajdziecie w oficjalnej dokumentacji Google.

Po zakończeniu konfiguracji bazy danych tworzymy profile źródła danych, celu oraz streamu.

Ostatnim krokiem zostaje utworzenie i włączenie naszego procesu strumieniowania.

Ogromnym plusem replikacji danych za pomocą DataStream jest to, że wszystko możemy wyklikać w intuicyjnym GUI co czyni go świetnym narzędziem dla osób bez doświadczenia. Dodatkowym jego atutem jest jego szybkość oraz możliwość selekcji tabel i kolumn, które chcemy replikować oraz częstotliwości odświeżania naszych danych.

Poniżej znajduje się przykładowy scenariusz utworzenia takiego procesu replikacyjnego z bazy danych typu PostgreSQL za pomocą DataStream.

DataStream to świetne narzędzie replikacyjne. Szczególnie jeśli zależy Ci na elastycznym i stabilnym rozwiązaniu gwarantującym dostęp do danych rzeczywistych z Twoich relacyjnych baz danych.

Dodatkowo, jest to narzędzie elastyczne i proste w konfiguracji. W przypadku większej skali działalności można skonfigurować i zarządzać swoimi strumieniami danych za pomocą oprogramowania IaC jak chociażby Terraform.

Obecnie jego największym minusem jest brak wsparcia dla MS SQL, bazy danych która jest mimo wszystko dość często spotykana, szczególnie na rynku polskim

Jeśli staniesz przed wyzwaniem stworzenia procesu ETL z relacyjnej bazy danych typu SQL zawsze bierz tą technologię jako priorytet gdyż została ona stworzona głównie do tego.

DataFusion

DataFusion to natywna dla Google Cloud usługa integracji danych, która oferuje wizualny interfejs typu „wskaż i kliknij” do wdrażania procesów ETL, eksploracji, transformacji danych oraz zarządzania metadanymi.

Zawiera szeroką bibliotekę wstępnie skonfigurowanych konektorów i transformacji oraz integruje się natywnie z usługami Google Cloud co powoduje, że w pewnych scenariuszach biznesowych może być idealnym narzędziem do tworzenia procesów ETL.

Data Fusion jest również narzędziem transformacyjnym. Zawiera moduł o nazwie “Wrangler”, umożliwiający eksplorację Twoich danych oraz bardzo rozbudowane możliwości transformacyjne.

DataFusion oferuje gotowe moduły zarówno do przetwarzania wsadowego jak i w strumieniowania. Posiada również możliwość tworzenia wewnętrznej biblioteki niestandardowych połączeń i transformacji dzięki wykorzystania API.

Poniżej przedstawiam przykładowy proces replikacji danych do Google BigQuery:

DataFusion z punktu widzenia funkcjonalnego i technologicznego jest naprawdę użytecznym narzędziem. Ma wiele potencjalnych scenariuszy zastosowań i gotową bibliotekę konektorów gotowych do użycia od ręki.

Jedną z wad DataFusion jest fakt, iż nie jest to narzędzie bezserwerowe, i będziemy musieli liczyć się z ciągłą opłatą miesięczną za włączoną instancję. W najmniejszym przypadku za wersję deweloperską zapłacimy ok 1000 złotych miesięcznie. Jest ona jednak ograniczona do dwóch użytkowników i posiada mniej możliwości niż wersja Enterprise, której cena osiąga 12000 złotych za miesiąc.

Dodać należy, że jest to tylko koszt związany z instancją. Do tego musimy doliczyć koszt związany z przetwarzaniem naszych danych za pomocą Dataproc oraz kosztami strumieniowania danych.

DataFusion nie będzie więc optymalnym narzędziem, jeśli wasze potrzeby replikacyjne są niewielkie i zakładacie scenariusz, w którym transformację danych robicie już bezpośrednio w hurtowni danych . Jego prawdziwa potęga zdaje się być zauważalna dopiero przy większych organizacjach z wielkimi potrzebami replikacyjnymi.

Cloud Composer

Cloud Composer jest w pełni zarządzaną usługą umożliwiającą orkiestrację zadań i procesów w chmurze Google. I jeśli powyższe zdanie Ci nic nie mówi najprawdopodobniej nie będziesz mógł z niego skorzystać bez pomocy doświadczonego inżyniera danych z dobrą znajomością języka Python oraz Apache Airflow, na bazie którego Cloud Composer został stworzony.

Przy pomocy Cloud Composera stworzysz, zaplanujesz i będziesz mógł monitorować orkiestrację wielu zadań i procesów, które będą uruchamiane jeden po drugim tworząc mniej lub bardziej skomplikowany przepływ danych (lub zupełnie inny proces nie związany z przepływem danych).

Co należy zaznaczyć Composer sam w sobie nie jest narzędziem ELT stworzonym do transformacji, przetwarzania czy przekazywania danych. Jest to narzędzie, które będzie zarządzać i koordynować zadaniami, które finalnie będą odbywać się przy pomocy innych technologii tutaj wymienionych jak DataFlow, DataFusion, BigQuery czy DataProc.

Pomimo to, Cloud Composer jest bardzo przydatnym narzędziem w codziennej pracy inżyniera danych. Szczególnie dobrze się sprawdzi w bardziej skomplikowanych, wielostopniowych procesach ETL. Przydatny będzie w monitorowaniu wszystkich zadań, alarmowaniu błędów i statusów oraz zarządzaniu tymi procesami od A do Z.

Cloud Composer ma jednak również kilka wad. Jedną z nich jest fakt, że lwia część pracy jaką musimy wykonać aby z niego skorzystać opiera się na programowaniu. W organizacjach z filozofią low-code czy no-code nie będzie postrzegany pozytywnie. Nie pomaga również fakt, że jesteśmy ograniczeni do języka programowania jakim jest Python. Dodatkowo posiada dość stromą krzywą uczenia.

Zadania w Cloud Composer są oparte na filozofii DAG (Directed Acyclical Graph). Oznacza to, że orkiestracja idzie zawsze w jednym kierunku, i nie może być pętlą co niestety uniemożliwia bądź komplikuje egzekucję pewnych scenariuszy.

DataFlow

DataFlow jest bezserwerową, szybką i efektywną kosztowo usługą umożliwiającą tworzenie i zarządzanie ogromnymi przepływami danych w Twoim środowisku Google Cloud. DataFlow umożliwi Ci tworzenie procesów ELT i ETL zarówno opartych na strumieniowaniu danych jak i przetwarzaniu wsadowym.

DataFlow jest oparty na bibliotekach Apache Beam, oprogramowaniu typu open-source. Podobnie jak DataFusion ma dostępne kilkadziesiąt szablonów gotowych do natychmiastowego zastosowania w konkretnym przypadku biznesowym. Jeśli szablon nie spełnia naszych potrzeb możemy przerobić kod i dostosować go według naszych upodobań.

DataFlow działa bezserwerowo i skaluje się automatycznie. Będzie to szczególnie pomocne jeśli dane, które procesujemy osiągają nieregularny wolumen w wyniku losowego zdarzenia (np. Uruchomienie nowej funkcjonalności w grze, która spowoduje ogromny ruch w krótkim czasie i znacznie zwiększy rozmiar danych, które potrzebujemy przeprocesować).

Ogromną zaletą DataFlow jest jego bezserwerowa architektura oraz rozdzielanie zadań związanych z procesowaniem danych oraz przechowywaniem danych na dwie optymalne kosztowo technologie GCP (computing i storage), co pozwala lepiej zarządzać kosztami naszego procesu ETL.

Wadą DataFlow może być fakt, że użytkownik bez wiedzy programistycznej i znajomości bibliotek Apache Beam będzie ograniczony do gotowych szablonów, co może utrudnić mu stworzenie bardziej zaawansowanego procesu ETL bądź przepływu danych bez pomocy ekspertów.

DataPrep

DataPrep to narzędzie oryginalnie stworzone przez firmę Trifacta, a później wykupione przez Google i dodane jako jedna z technologii Google Cloud w module analitycznym.

DataPrep jest fenomenalnym narzędziem transformacyjnym. Posiada dosłownie setki gotowych funkcji transformacyjnych gotowych do zastosowania bez użycia nawet linijki kodu SQL.

DataPrep działa na pograniczu inżynieryjno-analitycznym. Oprogramowanie umożliwia również szybką eksplorację samplowanych danych, co pomaga lepiej nam je zrozumieć oraz odkryć potencjalne odchylenia lub problemy z ich jakością.

Proces transformacyjny DataPrep będzie składać się z wielu mniejszych procedur (tutaj nazywanych przepisem – “Recipe”). Całość procesu mamy możliwość wizualizować co czyni go szczególnie prostym w zrozumieniu i wykryciu ewentualnych luk i niedociągnięć.

Choć DataPrep jest urządzeniem, które świetnie nadawać się będzie przede wszystkim do eksploracji oraz transformacji naszych danych, można za pomocą niego również utworzyć procesy ETL do BigQuery.

Jedną z największych zalet DataPrep jest fakt, że jest to narzędzie przyjazne użytkownikom nie posiadającym umiejętności programistycznych co powoduje, że większość naszych zadań możemy wyklikać myszką.

DataPrep może być też częścią większego procesu przepływu danych ponieważ łatwo integruje się z pozostałymi technologiami Google Cloud.

Pomimo, że DataPrep ma wiele zalet, jego największą wadą wydaje się być jego obecna cena.

Większość funkcji, które faktycznie pomogłyby nam zoptymalizować i utworzyć orkiestrację serii procesów ETL nie są dostępne w wersji Starter.

Paradoksem może być, że jego stosunek wartości do ceny wydaje się najbardziej optymalny dla bardzo małych biznesów typu sklepy e-commerce, czy start-upu, który do wszystkich zadań analitycznych zatrudnia jedną osobę.

W takim scenariuszu zapłata 100$ za wersję Starter dla firmy, która nie posiada kompetencji programistycznych i ma skromną ilość źródeł danych DataPrep może okazać się idealnym wyborem.

Cloud RUN i Cloud Functions

Cloud RUN to usługa do bezserwerowego uruchamiania kodu. I choć nie jest to narzędzia dedykowane do procesów ETL jest wiele scenariuszy, w których będzie do tego się idealnie nadawać.

Narzędzie te będzie świetnie nadawać się do tworzenia mikroserwisów ELT. Fenomenalnie sprawdzi się w scenariuszu kiedy chcemy pobrać dane z API, FTP czy małej bazy danych, i załadować je do naszej hurtowni danych BigQuery metodą przetwarzania wsadowego o określonej porze.

Jest to też narzędzie bardzo elastyczne. W przeciwieństwie np. do Cloud Composera, obsłuży nasz kod napisany w wielu językach programowania takich jak : Go, Python, Java, Node.js, .NET, i Ruby.

Główną zaletą Cloud Run jest jego prostota, bezserwerowe działanie i niski koszt utrzymania.

Do wad możemy zaliczyć fakt, że nie stworzymy procesu replikacyjnego bez umiejętności programistycznych. Aby zaplanować automatyczne uruchamianie procesu ELT stworzonego przy pomocy Cloud RUN będziemy potrzebowali skorzystać z innych funkcji GCP takich jak, Cloud Scheduler, Cloud Workflows, Container Registry czy wspomniany wcześniej Eventarc co powoduje, że ta metoda nie będzie łatwo dostępna dla początkujących użytkowników GCP.

Dodatkowo zarówno funkcje jak i Cloud RUN mają wiele limitów, co powoduje, że nie będzie to dobry wybór przy dużo większej skali potrzeb.

Więcej o tym jak działa Cloud RUN możesz dowiedzieć się z poniższego filmiku:

Big Query Data Transfer Service

Funkcjonalność natywna hurtowni danych Google BigQuery pozwalająca na bezpośrednie tworzenie procesów ELT do hurtowni danych BigQuery.

Jej ogromną zaletą jest to, że wyklikać ją może każdy bezpośrednio z interfejsu BigQuery a dane dostępne będą dla nas w kilka chwil.

Możemy za jej pomocą tworzyć procesy ELT naszych danych z wszystkich najpopularniejszych usług Google:

Google Merchant Center

Google Play

Search Ads 360

YouTube Channel

YouTube Content Owner

Google Analytics 4

Firebase

BigQuery DTS umożliwi nam również transfer danych od innych dostawców chmury, takich jak Amazon S3 czy Azure Blob Storage. Za jego pomocą stworzymy również proces migracyjny z Teradaty lub Amazon Redshift.

Jest to fenomenalne narzędzie, dzięki którym bardzo szybko i bezkosztowo utworzymy procesy ELT do hurtowni danych BigQuery bez żadnej wiedzy programistycznej.

Jedyną znaną mi wadą tej usługi jest ograniczona liczba źródeł danych. W każdym innym przypadku kiedy potrzebujemy szybko analizować dane z naszych narzędzi Google powinniśmy użyć właśnie tego narzędzia.

Poniżej znajduje się przykładowy szkic prezentujący proces ELT z Google Ads do BigQuery za pomocą BigQUery data transfer service:

Cloud Storage Data Transfer

Storage Data Transfer jest usługą umożliwiającą przenoszenie danych z zasobów przechowywanych w Google Cloud Storage. I co prawda transfer tych danych sam w sobie trudno nazwać procesem ELT, to wspomagając się innymi usługami GCP, które pomogą nam umieszczać pliki w naszym folderze możemy cały proces ładowania danych do naszych tabel w pełni zautomatyzować.

Zaletą SDT jest jego prostota w konfiguracji. Transfer danych tworzymy bezpośrednio w naszej hurtowni danych.

Transferować możemy dane z plików CSV,JSON,AVRO,ORC,PARQUET oraz THRIFT.
Dane możemy dodać do istniejącej już tabeli ( metodologią APPEND ) lub nadpisać jej całą zawartość ( metodologia MIRROR ). Tabela musi być uprzednio utworzona jeśli konfigurujemy proces transferu przy pomocy interfejsu GUI.

Dodatkowo, przy użyciu wyzwalacza, możemy skonfigurować automatyczne uruchamianie naszego transferu danych. Przykładowo po dodaniu pliku do folderu spełniającego pewne wymogi transfer danych do BigQuery uruchomi się automatycznie. Dzięki temu przepływ naszych danych będzie płynny a my zawsze będziemy mieć dostęp do najświeższych danych w BigQuery tak szybko jak się pojawią w naszym zasobniku.

Podsumowanie

Jest wiele możliwości replikacji naszych danych do hurtowni. Powyższy przewodnik opisuje pokrótce tylko technologie natywne Google Cloud.

Pamiętajmy jednak, że skorzystać możemy również z wielu konektorów umożliwiających prosty i intuicyjny sposób replikacji danych bez żadnej wiedzy programistycznej. Kilka z nich jest dostępnych bezpośrednio w marketplace GCP.

Przewagą tzw. “konektorów” jest prostota użycia i szybkość implementacji. Minusem jest cena, która będzie niejednokrotnie kilkukrotnie wyższa niż uruchomienie go za pomocą narzędzi dedykowanych w GCP.

Dla przykładu, konektor będzie świetnym rozwiązaniem gdy chcemy stworzyć proces replikacji naszego systemu CRM (jak Hubspot czy SalesForce), gdzie tabele źródłowe, schemat danych oraz metodologia zapisu danych w źródle są na tyle skomplikowane, że pisanie własnego skryptu i utrzymywanie go byłoby nieproporcjonalnie kosztowne i czasochłonne w porównaniu do użycia tzw. “pułkowego rozwiązania” jakim jest Stitch czy FiveTran.

Biorąc pod uwagę finalny wybór technologii, powinniśmy wziąć wiele czynników. Poniżej spisałem kilka z nich:

Horyzont Czasowy Implementacji - Planujesz stworzyć profesjonalny i optymalny kosztowo stack analityczny na lata czy tworzysz coś na szybko aby przetestować jak to działa w praktyce?
Kompetencje Zespołu - Posiadasz zespół doświadczonych inżynierów danych i analityków znających Pythona, SQL, Javę? Czy nie posiadasz kompetencji inżynieryjnych a do tej pory robiłeś analitykę w Google Sheets i raczej chciałbyś wszystko wyklikać myszką?
Budżet - Dysponujesz budżetem, który pozwoli Ci na przeprowadzenie profesjonalnego wdrożenia zakładając dobre praktyki testowania, wersjonowania, monitorowania błędów oraz utrzymywania infrastruktury czy masz ograniczony budżet i ewentualne błędy i dziury w procesach będziesz łatać w momencie ich powstawania?
Ilość i różnorodność źródeł danych - Posiadasz kilka źródeł danych różnych typów czy planujesz replikować dane z dziesiątek instancji jednego typu (np. 20 fizycznych instancji MySQL).
ETL czy ELT - Ja osobiście zalecam ukłon w stronę ELT i pozostawienie transformacji w kolejnych warstwach hurtowni danych przy pomocy DataForm. Ale wiem że Ty z różnych powodów możesz być zmuszony do tworzenia procesu mniej optymalną metodą ETL.
Świeżość danych - Chcesz mieć możliwość analizy najświeższych danych, czy wystarczy Ci stan “na wczoraj”?

Lista pytań będzie dłuższa, a prawda jest taka, że w praktyce rzadko będziemy mieć do czynienia z takim samym scenariuszem biznesowym.

W Bigglo stworzyliśmy setki procesów replikacyjnych wykorzystując nie tylko narzędzia natywnej chmury obliczeniowej GCP ale również płatne konektory od innych dostawców.

Jeśli po przeczytaniu tego poradnika nadal masz wątpliwości jaki scenariusz wybrać dla siebie – umów się na darmową konsultację z naszym ekspertem, który pomoże wybrać dla Ciebie idealną ścieżkę replikacji Twoich danych.

BigQuery
Procesy ETL
Replikacja Danych
DataStream
DataFusion
DataFlow
DataPrep
Cloud Composer
Cloud RUN
Cloud Functions
BigQuery Data Transfer
Cloud Storage Data Transfer

Arkady Zagdan

Analityk z 15 letnim doświadczeniem w branżach usługowych, e-commerce oraz SaaS. W Bigglo odpowiedzialny za strategię i wizję produktów typu Business Intelligence.