Proces EL natomiast to proces, w którym tylko wyodrębniamy dane i ładujemy w tej samej formie, w której zastaniemy je w naszym źródle.
Procesy ETL 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 w BigQuery w całości.
Ponieważ przetwarzanie wsadowe w BigQuery 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ń.
Do hurtowni danych BigQuery 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 (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:
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.
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.
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.
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:
Poniżej znajduje się przykład pliku JSONL:
W tym przykładzie każdy obiekt JSON zawiera trzy pola: imię, wiek i miasto.
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)
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:
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.
W ciągu ostatnich kilku lat Google Cloud znacznie usprawnił procesy ELT do BigQuery. 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 procesów ETL do BigQuery.
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.
Stworzyłem również macierz ukazującą, których z tych technologii możecie użyć aby przeprowadzić proces replikacyjny waszych danych do BigQuery.
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 tworzenia procesów ETL 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ę do przeprowadzenia naszego procesu replikacyjnego do BigQuery musimy wziąć pod uwagę kilka dodatkowych czynników.
I o ile wspomniane wyżej technologie są mocno oparte na programowaniu.
W innych scenariuszach zbawienne będą rozwiązania dedykowane do tworzenia procesów ETL do BigQuery, 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 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 BigQuery.
Takie podejście gwarantuje, że zawsze operujesz na świeżych danych.
DataStream jest również prosty w konfiguracji. Jedyne czego będziesz potrzebować do skutecznego przeprowadzenia procesu replikacyjnego 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.
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 procesu replikacyjnego z bazy danych typu PostgreSQL do hurtowni danych BigQuery 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 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.
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 do BigQuery.
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 BigQuery. Jego prawdziwa potęga zdaje się być zauważalna dopiero przy większych organizacjach z wielkimi potrzebami replikacyjnymi.
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 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 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 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.
Więcej o tym jak działa Cloud RUN możesz dowiedzieć się z poniższego filmiku:
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:
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:
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 w BigQuery 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.
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, której chcemy użyć do naszych procesów ETL powinniśmy wziąć wiele czynników. Poniżej spisałem kilka z nich:
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 ETL do hurtowni danych BigQuery wykorzystując nie tylko narzędzia natywnej chmury obliczeniowej GCP ale również płatne konektory od innych dostawców.
