Jak obniżyć koszty BigQuery używając Qlik Sense?

Czym jest BigQuery?

BigQuery jako sprawne narzędzie do przechowywania olbrzymich ilości danych i procesowania zapytań w mgnieniu oka zdobywa coraz większą popularność. Szybkość osiągana jest dzięki wykonywaniu zapytania podzielonego na paczki, równolegle na wielu kopiach tych samych danych (zarządzanych całkowicie przez BigQuery).

Dane przechowywane są w chmurze w jednym z kilkunastu dostępnych regionów chmury Google na świecie. Już niedługo jednak, być może gdy czytasz ten tekst już to nastąpiło, powstaje nowy region chmury Google – w Polsce. Pozwoli to zapewne polskim firmom z większym zaufaniem powierzać swoje dane chmurze Google.

Różnica między BigQuery a Qlik Sense

Szybkość BigQuery uzyskiwana jest dzięki równoległemu przetwarzaniu tych samych danych w wielu miejscach na raz, dzięki przechowywaniu ich kopii i z użyciem algorytmu map-reduce. Szybkość Qlik Sense uzyskiwana jest dzięki przetwarzaniu danych w RAM, pamięci operacyjnej serwera w połączeniu z opatentowanym mechanizmem kompresji danych i asocjacji tabel w modelu danych.

Przedstawione poniżej porównanie to subiektywna ocena na podstawie doświadczeń własnych i klientów.

	BigQuery	Qlik Sense
Struktura danych	Potrafi przechowywać dane zagnieżdżone (w formie hierarchii, tabela w tabeli, tak jak zbudowane są strony internetowe: nagłówek i kolejne podtytuły z treścią), co wymusza konieczność przekształcania do tabel prostych (funkcja unnest).	Przechowuje dane w formie tabel prostych. Po wczytaniu do aplikacji analitycznej dane zostają połączone w jeden spójny model danych. Odpowiednikiem struktury nagłówek-pozycja są dwie tabele skojarzone numerem nagłówka.
Wizualizacja danych	Utworzenie wizualizacji na danych wymaga zewnętrznych narzędzi.	Wizualizacja w ramach narzędzia Qlik Sense.
Sposób pracy	Analiza wyników zapytań SQL - tabele, wskaźniki. Brak możliwości łatwego filtrowania danych.	Możliwość stworzenia przyjaznej końcowemu użytkownikowi aplikacji. Pełna swoboda w predefiniowaniu filtrów oraz tworzeniu zaawansowanych skryptów ETL.
Kiedy stosować	Rzadki i szybki dostęp do każdego miejsca w naszym data lake. Wszystkie dane dostępne z polecenia SQL.	Częsty i szybki dostęp do wybranego zakresu danych. Wskazany zakres danych odświeżany według harmonogramu. Nowe zakresy danych dodawane na żądanie.
Wolumen danych	Praktycznie nieograniczony.	Możliwość skalowania do wielkości przekraczających miliardy rekordów.
Koszty	Zmienne. Opłaty zależne od: przechowywania, przetwarzania (za każde zapytanie) oraz przesyłania danych.	Stałe. Koszty utrzymania serwera Qlik.

Ile kosztuje BigQuery?

Przechowywanie małych ilości danych w BigQuery jest relatywnie tanie, jednak należy pamiętać iż koszty wzrastają proporcjonalnie do wzrostu ich wielkości. Przetwarzanie, które odbywa się przy każdym zapytaniu, choćby najprostszym – jak policzenie liczby wierszy – wiąże się z opłatami. Przy pojedynczych zapytaniach nie są to kwoty zawrotne, jednak łatwo stracić rachubę w czasie pracy z danymi, gdy mamy potrzebę swobodnego odpytywania bazy w poszukiwaniu odpowiedzi na nasze pytania. Praca analityka to eksperymenty i różne ścieżki analityczne, które często dopiero po serii niepowodzeń prowadzą do wyniku.

Przed każdym zapytaniem BigQuery szacuje ile bajtów czy gigabajtów danych przetworzy. Liczba przetworzonych bajtów ściśle wiąże się z poniesioną opłatą. Generalnie liczba ta zależy od liczby rekordów w tabeli oraz ilości przetwarzanych kolumn. Co ciekawe, ilość przetworzonych danych nie odnosi się do wyniku, tylko do zbioru danych przeskanowanych w celu zwrócenia wyniku. Gdy na przykład na tabeli z miliardem rekordów wykonamy zapytanie z filtrem, które zwróci nam tysiąc wierszy, opłata zostanie pobrana za przetworzenie miliarda rekordów.

Przykładowe zapytanie na miliardzie wierszy bez filtra, przetworzy tyle samo GB co zapytanie z filtrem – 39.3 GB.

Zapytanie z filtrem procesuje tyle samo GB (39.3 GB) co zapytanie pełne. Skanowana jest cała tabela z miliardem wierszy.

Po co używać BigQuery?

BigQuery oferuje przechowywanie danych w tabelach partycjonowanych (partitioned table). Ma to szczególne zastosowanie w branży gamingowej lub innych, gdzie zbierane są dzienne logi. Dzięki temu podczas przetwarzania zapytania BigQuery nie musi skanować całej tabeli, tylko jej partycję. Partycje takie najczęściej tworzone są per dzień – tak się właśnie dzieje dla danych z gier mobilnych (logi zachowań graczy) lub logów systemowych. Mamy również możliwość tworzenia partycji według własnych wytycznych. Podział według dnia jest jednak najczęstszy, bo praktyczny – nasze morze danych powiększa się regularnie z upływem każdego dnia.

W zapytaniu BigQuery możemy precyzyjnie wskazać z których dni-partycji SQL ma czerpać informacje. Co jednak, jeżeli nie wiemy, którego dnia nastąpiło poszukiwane przez nas zdarzenie i musimy przeskanować cały zasób? Jest to spore ograniczenie, co nie zawsze satysfakcjonuje analityków.

Dodatkowe joiny na tabelach, czasami nawet na tej samej tabeli, by doczytać dane do odpowiednich kalkulacji dalej rozmnażają ilość przetworzonych danych. Gdy takie zapytania wykonujemy wielokrotnie podczas jednej sesji, za każdym razem dla choćby nieznacznie innego filtru, koszty zaczynają rosnąć.

Jak obniżyć koszty BigQuery?

Czasem koszty BigQuery wymykają się spod kontroli. Niektórzy z naszych klientów boleśnie odczuli to na własnej skórze. Nie chcieli jednak rezygnować ze swobody eksploracji własnych danych ani przed każdym naciśnięciem guzika “Run” liczyć koszty na kalkulatorze. Klienci szukający narzędzia BI do obsługi BigQuery rozważali różne opcje rynkowe, jednak tylko jedna z nich rozwiązywała problem kosztów zapytań.

Rozwiązaniem na stresy związane z kosztami BigQuery jest zaprzęgnięcie do pracy Qlik Sense. Poniżej przedstawimy sposoby podłączenia się z Qlik Sense do BigQuery i wykonywania zapytań oraz wskażemy sposób najbardziej optymalny kosztowo.

Rozwiązania

1. Zapytania na żywo (Direct Discovery).

Qlik Sense może podłączyć się na żywo do naszej bazy BigQuery. Jest to tak zwany tryb Direct Discovery. W taki sam sposób, czyli na żywo, będzie z BigQuery łączyć się Tableau czy PowerBI. W każdym z narzędzi, dzięki sprawności BigQuery pozwoli to na szybkie działanie dashboardów.

Nie jest to dobre rozwiązanie, bo tak naprawdę niewiele zmienia. Podłączenie do BigQuery na żywo to najgorszy sposób dla każdego narzędzia BI, wtedy bowiem w ogóle nie kontrolujemy kosztów zapytań. BigQuery szacuje ilość przetworzonych megabajtów i nas o niej uprzedza, ale pokazuje tą informację tylko we własnej konsoli, nie w dashboardzie innego narzędzia. A pamiętajmy, że każdy ruch, zmiana wymiaru grupowania danych lub nałożenie filtru powoduje ponowne zapytanie na całym zbiorze danych…

Podłączenia na żywo z Qlik daje pewne ograniczenia wykorzystania błyskotliwości Qlik i jego silnika. Qlik Sense jest narzędziem in-memory i najwięcej korzyści uzyskujemy wczytując wcześniej potrzebne dane na serwer Qlik. Wtedy Qlik ma natychmiastowy dostęp do wszystkich rekordów i może wykonywać na nich dowolne operacje równie szybko jak BigQuery.

2. Zapytania na żądanie (Dynamic Views).

W skrócie: pobieramy z całego zbioru danych informacje zagregowane, wykonując zapytanie do BigQuery tylko raz na jakiś czas (według własnych potrzeb). Te dane swobodnie analizujemy w Qlik Sense nie ponosząc żadnych dodatkowych kosztów bieżących zapytań. “Dynamic View” to osadzona w dashboardzie tabela, która jest na żywo podłączona do źródła danych. Po zawężeniu selekcji (terminologia Qlik do nakładania filtrów) możemy taką tabelę ze szczegółami odświeżyć. Działa to świetnie we wszystkich narzędziach, gdzie nie płacimy za każde zapytanie. W BigQuery nie będzie to jednak najbardziej optymalny sposób, gdyż nawet jeżeli stosujemy zawężające filtry, nadal płacimy za skanowanie całej bazy.

Dynamic Views to nic innego, jak osadzony w dashboardzie obiekt wizualizacyjny (wykres, tabela) z innej aplikacji, zbudowanej w tzw. technice ODAG Qlik Sense (on-deman app generation – więcej o tym rozwiązaniu w naszym webinarze “Qlik Sense i Big Data”.

3. Po prostu dane w Qlik Sense. Zero stresu.

Rozwiązanie idealne i dostępne już tylko w Qlik Sense (w porównaniu z Tableau lub PowerBI). Jest to najczęstszy wybór klientów Qlik. Jest to najpowszechniej używany sposób analizy danych w Qlik Sense. Dane są pobierane do Qlik według harmonogramu i odkładane w jego własnym repozytorium – bezpośrednio w aplikacjach analitycznych lub w warstwie pośredniej – zoptymalizowanych plikach tabel w formacie *.QVD. Sposób ten pozwala również na przyrostowe wczytywanie danych na serwer Qlik. W połączeniu z, na przykład, tabelami logów, gdzie dla każdego dnia BigQuery tworzy nową tabelę, jest to rozwiązanie idealne. Taką tabelę dla danego dnia możemy pobierać nawet kilka razy dziennie nadpisując jej wersję lokalnie w Qlik i odkładając obok tabel-partycji poprzednich dni.

Teraz uzyskujemy pełną swobodę i zero stresu. Możemy dowolnie kalkulować miary, zestawiać je według dowolnych wymiarów. Nakładać filtry, cofać się, uruchamiać testowe i często niepotrzebne zapytania aż w końcu dojdziemy do poszukiwanej odpowiedzi. Całkowicie bez niespodziewanych kosztów.

Jest to sposób najczęściej wybierany przez naszych klientów. Jednocześnie dostępny tylko w Qlik Sense. Inne narzędzia Business Intelligence mogą również pobierać wstępnie pewne zakresy danych i pozwalać na lokalną analizę ale działają wydajnie przy bardzo ograniczonych wolumenach danych. Qlik poradzi sobie swobodnie z setkami milionów, jak widać na załączonym wideo.

Wprawdzie tracimy w ten sposób podłączenie do bazy na żywo, ale praktyka pokazuje, że prawie nigdy go tak naprawdę nie potrzebujemy. Najczęściej wystarcza odświeżenie danych raz lub kilka razy dziennie. Ma to czasami nawet dodatkową zaletę. Gdy o 9:30 spostrzeżemy w danych coś, czym chcemy się podzielić z innymi i uruchamiamy prezentację o 9:50, dane pokazują już coś innego… i jesteśmy postawieni w sytuacji, delikatnie mówiąc, zakłopotania.