Blog JSystems - uwalniamy wiedzę!

Szukaj
Infografika porównująca BigQuery i Snowflake: model obliczeniowy, chmura, rozliczenie, skalowanie i administracja
BigQuery i Snowflake w pigułce. Obie to chmurowe hurtownie danych, w których pytasz zwykłym SQL - ale filozofia pracy jest wyraźnie inna. Poniżej rozkładamy te różnice na czynniki pierwsze.

Jeśli szukasz chmurowej hurtowni danych, prędzej czy później staniesz przed pytaniem: BigQuery czy Snowflake? Obie nazwy słychać w tym samym zdaniu, obie robią pozornie to samo - trzymają ogromne ilości danych i pozwalają je analizować zwykłym SQL. A jednak różnią się w sposobie, który realnie wpływa na rachunek i na to, jak się z nimi pracuje. W tym artykule przeprowadzimy Cię przez te różnice bez marketingu: pokażemy, jak każde z nich liczy zapytanie, ile kosztuje i kiedy wybrać które - a wszystko na prawdziwych zrzutach z obu konsol.

To samo, a jednak inne

Zanim wypunktujemy różnice, warto zobaczyć, jak wiele te dwa narzędzia łączy - bo to tłumaczy, czemu tak często są zestawiane. Oba są chmurowymi hurtowniami danych. Hurtownia danych (po angielsku data warehouse) to szczególny rodzaj bazy zaprojektowany nie do obsługi aplikacji, lecz do analizy: liczenia sum, średnich, trendów i raportów na wielkich zbiorach. Fachowo mówi się o pracy w trybie OLAP (przetwarzanie analityczne) w odróżnieniu od zwykłych baz transakcyjnych.

Poza tym oba są kolumnowe (trzymają dane kolumnami, nie wierszami, więc zapytanie czyta z dysku tylko te kolumny, o które pyta), oba rozmawiają standardowym SQL i oba rozdzielają składowanie danych od mocy obliczeniowej - dane leżą tanio w jednym miejscu, a liczenie odbywa się osobno i skaluje niezależnie. Jeśli chcesz najpierw poznać każde z nich z osobna, opisaliśmy je w osobnych przewodnikach: czym jest BigQuery i jak działa hurtownia danych w chmurze oraz prosty przewodnik po Snowflake. Szerszy obraz całej układanki - hurtownie, jeziora danych i strumienie - znajdziesz w tekście o współczesnych rozwiązaniach Big Data.

Skoro tyle je łączy, gdzie tkwi różnica? Cała reszta artykułu to odpowiedź na to pytanie. Zaczniemy od najważniejszego - od tego, skąd biorą moc obliczeniową do liczenia Twoich zapytań.

Model obliczeniowy: bezserwerowy kontra hurtownie wirtualne

To jest sedno całego porównania i różnica, z której wynika większość pozostałych. Chodzi o to, skąd bierze się moc, która przelicza Twoje zapytanie.

BigQuery jest bezserwerowy (po angielsku serverless). Nie ma tam nic, co włączasz. Piszesz zapytanie, klikasz Uruchom, a Google sam - na czas jego wykonania - dokłada moc z tysięcy maszyn i zwalnia ją, gdy skończysz. Te jednostki mocy nazywają się slotami, ale nie musisz o nich myśleć: przydzielane są automatycznie, w tle. Nie ma czego rozmiarować ani wyłączać.

Snowflake idzie inną drogą - daje Ci hurtownie wirtualne (po angielsku virtual warehouses). Hurtownia wirtualna to klaster obliczeniowy, który sam włączasz i któremu sam nadajesz rozmiar - od najmniejszego X-Small, przez Small, Medium, aż po wielkie rozmiary. Większy klaster liczy szybciej, ale zużywa więcej mocy na godzinę. Na liście hurtowni widać to od razu: każda ma swój rozmiar i status (uśpiona albo uruchomiona):

Snowflake Konsola Snowflake: lista hurtowni wirtualnych z kolumnami rozmiar (X-Small) i status (uśpiona)
Lista hurtowni wirtualnych w konsoli Snowflake (Snowsight). Zwróć uwagę na kolumnę Size - to Ty decydujesz, jak dużą moc uruchamiasz. W BigQuery takiej listy nie ma, bo nie ma czym zarządzać.

Po wejściu w konkretną hurtownię widać wszystkie pokrętła, którymi w Snowflake sterujesz: rozmiar, liczbę klastrów, a przede wszystkim automatyczne wyłączanie po bezczynności (auto-suspend) oraz automatyczne wznawianie przy pierwszym zapytaniu (auto-resume). To ważny szczegół kosztowy - o nim za chwilę.

Snowflake Szczegóły hurtowni Snowflake: rozmiar X-Small, auto-suspend po 5 minutach, auto-resume włączone, liczba klastrów
Szczegóły hurtowni w Snowflake. Rozmiar X-Small, wyłączanie po 5 minutach bezczynności, wznawianie automatyczne - to wszystko elementy, którymi w BigQuery nie musisz się zajmować, bo tam moc pojawia się i znika sama.

A gdy zakładasz nową hurtownię, jej rozmiar wybierasz wprost z listy - od X-Small po 4X-Large. To jedyne miejsce w całym porównaniu, w którym sam decydujesz o wielkości mocy obliczeniowej:

Snowflake Dialog nowej hurtowni w Snowflake z rozwiniętą listą rozmiarów: X-Small, Small, Medium, Large, X-Large, 2X-Large, 3X-Large, 4X-Large
Zakładanie hurtowni w Snowflake. Rozmiar wybierasz z listy - od X-Small po 4X-Large. Większy liczy szybciej, ale zużywa proporcjonalnie więcej kredytów. W BigQuery takiego wyboru nie ma, bo moc dobiera się sama.

Najlepiej widać tę różnicę, gdy prześledzisz drogę jednego zapytania w obu narzędziach. U góry BigQuery: zapytanie po prostu dostaje moc w locie. U dołu Snowflake: hurtownia najpierw wstaje, liczy, a po chwili bezczynności sama się wyłącza:

Animacja: droga zapytania w BigQuery (bezserwerowo, sloty w locie) i w Snowflake (hurtownia wstaje, liczy, auto-suspend)
Ta sama praca, inne podejście do mocy. BigQuery przydziela ją niewidzialnie na czas zapytania. Snowflake daje Ci nad nią kontrolę - w zamian za odrobinę zarządzania.

Którą filozofię wolisz, to w dużej mierze kwestia tego, czy cenisz sobie zero zachodu (BigQuery), czy pełną kontrolę nad mocą i jej kosztem (Snowflake). Ta kontrola daje Snowflake jeszcze jedną, sztandarową zaletę - opisujemy ją zaraz.

Izolacja obciążeń: wiele hurtowni na tych samych danych

Skoro w Snowflake sam tworzysz hurtownie, możesz mieć ich kilka naraz - i każda pracuje niezależnie na tych samych danych. To rozwiązuje bolączkę zwykłych baz, w których ciężki import albo ktoś liczący gigantyczny raport potrafi spowolnić wszystkich pozostałych. Fachowo mówi się o izolacji obciążeń (po angielsku workload isolation): różne rodzaje pracy nie wchodzą sobie w drogę, bo liczą je osobne klastry.

Infografika: trzy hurtownie wirtualne Snowflake (analitycy, ładowanie danych, pulpity BI) czytają niezależnie te same wspólne dane
W Snowflake każdy zespół może dostać własną hurtownię o dobranym rozmiarze. Wszystkie czytają te same tabele, ale nie rywalizują o moc - import nie spowalnia raportów, a raporty nie spowalniają importu.

W praktyce wygląda to tak: zespół analityków dostaje swoją hurtownię, nocne ładowanie danych - swoją, a pulpity BI - jeszcze inną. Każda ma osobny rozmiar i osobny rachunek, więc od razu widać, kto ile mocy zużywa. BigQuery osiąga podobny efekt inną drogą: jest bezserwerowy, więc nie tworzysz osobnych hurtowni - Google sam skaluje moc pod równoległe zapytania, a gdy potrzebujesz gwarancji wydajności dla konkretnego zespołu, wydzielasz mu pulę slotów przez rezerwacje. Cel ten sam, mechanika inna.

Chcesz opanować Snowflake od strony praktycznej - hurtownie, izolację obciążeń, wydajność i koszty? Szkolenie Przetwarzanie danych z użyciem Snowflake prowadzi przez to na realnych danych i ma terminy gwarantowane.

A jeśli bliżej Ci do świata Google, Szkolenie Google BigQuery - podstawy pokazuje BigQuery od zera - konsolę, zapytania i panowanie nad kosztami.

Zapytania i wyniki: prawie identycznie

Tu obie hurtownie są zaskakująco podobne, bo obie rozmawiają zwykłym SQL. Napiszmy to samo zapytanie w jednym i drugim - policzmy, ilu klientów przypada na każdy segment rynku w przykładowym zbiorze danych. Zapytanie jest dokładnie takie, jakie napisałbyś w dowolnej innej bazie:

SELECT c_mktsegment AS segment,
       COUNT(*) AS customers,
       ROUND(AVG(c_acctbal), 2) AS avg_balance
FROM snowflake_sample_data.tpch_sf1.customer
GROUP BY c_mktsegment
ORDER BY customers DESC;

W Snowflake wpisujesz je do arkusza, wybierasz hurtownię, która ma je policzyć, i klikasz Uruchom. Wynik pojawia się pod spodem jako tabela - tutaj w ułamku sekundy, mimo że zbiór ma 150 tysięcy wierszy:

Snowflake Arkusz Snowflake z zapytaniem SQL i tabelą wyników: segmenty rynku, liczba klientów i średni balans
Arkusz w konsoli Snowflake. U góry zapytanie i wybór hurtowni (COMPUTE_WH, rozmiar X-Small), poniżej gotowa tabela wyników. Zapytanie policzyło się w 121 milisekund.

W BigQuery ta sama historia wygląda niemal tak samo: edytor z zapytaniem, przycisk Uruchom, tabela wyników pod spodem. Nie ma tu jednak wyboru hurtowni, bo moc dokłada się sama:

BigQuery Konsola BigQuery z zapytaniem SQL i tabelą wyników najpopularniejszych imion
Konsola BigQuery przy pracy nad innym przykładem. Ten sam schemat: edytor u góry, wynik pod spodem - tyle że bez wskazywania, skąd wziąć moc obliczeniową.

Oba narzędzia potrafią też od razu zamienić tabelę wyników w wykres, bez wychodzenia z konsoli. W Snowflake wystarczy przełączyć zakładkę na wykres i wskazać, co ma być na osiach:

Snowflake Snowflake: wynik zapytania pokazany jako wykres słupkowy liczby klientów w segmentach, z panelem konfiguracji osi
Wynik jako wykres słupkowy w Snowflake. Po lewej konfiguracja osi, po prawej gotowy wykres. BigQuery ma dokładnie taką samą możliwość w swojej zakładce wizualizacji.

Wniosek z tej sekcji jest prosty: od strony pisania zapytań przesiadka z jednego na drugie jest niemal bezbolesna. Kto zna SQL, ruszy w obu od pierwszej minuty. Różnice, które naprawdę bolą lub cieszą, siedzą gdzie indziej - w tym, co dzieje się pod maską i na rachunku.

Co pod maską: jak liczą Twoje zapytanie

Oba narzędzia biorą Twoje jedno zapytanie i tną je na drobne zadania liczone równolegle na wielu maszynach - stąd ich prędkość na wielkich zbiorach. Oba pozwalają też podejrzeć, jak zapytanie faktycznie się policzyło. To bardzo pomaga, gdy coś działa wolno albo kosztuje więcej, niż powinno.

W BigQuery służy do tego graf wykonania (po angielsku execution graph): pokazuje, skąd zapytanie wzięło dane i ile rekordów przeszło przez kolejne etapy przetwarzania.

BigQuery Graf wykonania zapytania w BigQuery: źródło danych, kolejne etapy przetwarzania i liczba przetworzonych rekordów
Graf wykonania w BigQuery. Widać, jak zapytanie przeszło od źródła danych przez kolejne etapy aż do wyniku i gdzie zeszło najwięcej pracy.

Snowflake ma swój odpowiednik - profil zapytania (po angielsku query profile). To drzewo operatorów: odczyt tabeli, agregacja, sortowanie, wynik. Do tego panel z najbardziej kosztownymi krokami, czasem wykonania i liczbą przeczytanych partycji danych:

Snowflake Profil zapytania w Snowflake: drzewo operatorów (odczyt tabeli, agregacja, sortowanie, wynik) i statystyki wykonania
Profil zapytania w Snowflake. Drzewo pokazuje kolejne operacje: odczyt tabeli (TableScan) na 150 tysiącach wierszy, agregację, sortowanie i wynik. Po prawej najkosztowniejsze kroki i statystyki.

Oba widoki mówią o tym samym: gdzie zeszła praca i za co realnie zapłacisz. Zajrzenie tutaj to najlepszy pierwszy krok, gdy chcesz przyspieszyć zapytanie albo obniżyć jego koszt - a jak liczony jest ten koszt, różni się między narzędziami zasadniczo.

Ile to kosztuje: za dane kontra za czas

To najważniejsza różnica praktyczna i najczęstsze źródło niespodzianek na rachunku. Modele rozliczeń są zbudowane wokół dwóch zupełnie różnych rzeczy.

Infografika modeli cen: BigQuery płacisz za przeskanowane dane, Snowflake za czas pracy hurtowni w kredytach
Dwa różne modele płacenia. To do nich sprowadza się większość decyzji o kosztach - i to je najłatwiej źle oszacować.

BigQuery liczy koszt od ilości danych, które przeskanowało zapytanie - nie od czasu ani liczby zapytań. Co ważne, konsola mówi Ci to z góry, jeszcze przed uruchomieniem, więc nigdy nie liczysz w ciemno:

BigQuery Edytor BigQuery z komunikatem, ile danych przetworzy zapytanie po uruchomieniu - szacunek kosztu przed startem
BigQuery pokazuje szacunek przeskanowanych danych, zanim klikniesz Uruchom. Ponieważ dane leżą kolumnami, płacisz tylko za te kolumny, o które faktycznie pytasz.

Snowflake liczy koszt od czasu pracy włączonej hurtowni, wyrażonego w kredytach (wewnętrznej jednostce rozliczeniowej Snowflake). Liczy się każda sekunda, gdy hurtownia jest uruchomiona, z minimalnym naliczeniem 60 sekund przy każdym wznowieniu. Większy rozmiar klastra liczy szybciej, ale zjada proporcjonalnie więcej kredytów na godzinę. Dlatego tak ważny jest wspomniany auto-suspend: hurtownia, która sama się wyłącza po bezczynności, nie spala kredytów za nic.

Skąd biorą się niespodzianki na rachunku.

W BigQuery zdradliwe jest SELECT * - każe przeczytać wszystkie kolumny, także te niepotrzebne, a płacisz właśnie za przeczytane dane. W Snowflake zdradliwa jest zapomniana, wciąż włączona hurtownia - albo zbyt duży klaster do prostych zapytań. W obu przypadkach lekarstwo jest tanie: wybieraj konkretne kolumny zamiast gwiazdki i pilnuj, żeby moc wyłączała się, gdy nie pracuje.

Która hurtownia wyjdzie taniej, zależy więc od charakteru pracy. Przy nieregularnych, rzadkich analizach zwykle wygrywa BigQuery - płacisz tylko za to, co realnie przeskanujesz, i nic, gdy nie pytasz. Przy stałym, przewidywalnym obciążeniu, gdzie moc jest wykorzystywana w pełni przez większość dnia, dobrze zestrojony Snowflake bywa tańszy i daje lepszą kontrolę nad wydatkiem.

Chcesz poznać BigQuery od podstaw i od początku panować nad kosztami zapytań? Szkolenie Google BigQuery - podstawy prowadzi przez konsolę, zapytania i model rozliczeń krok po kroku na realnych danych.

Po stronie Snowflake koszty i wydajność przećwiczysz na Szkolenie Przetwarzanie danych z użyciem Snowflake, które ma terminy gwarantowane.

Na jakiej chmurze to działa

Tu różnica jest krótka do opisania, ale dla wielu firm decydująca. BigQuery działa wyłącznie w chmurze Google (Google Cloud). To zaleta, jeśli Twoje dane i narzędzia już tam są - na przykład Google Ads, Google Analytics czy Looker - bo wszystko siedzi blisko siebie. To wada, jeśli reszta Twojej firmy stoi na innej chmurze.

Infografika: BigQuery działa tylko na Google Cloud, Snowflake na Amazon AWS, Microsoft Azure i Google Cloud
Snowflake jest niezależny od dostawcy chmury - ten sam produkt działa na Amazon AWS, Microsoft Azure albo Google Cloud. BigQuery jest związany z Google.

Snowflake działa na wszystkich trzech dużych chmurach: Amazon AWS, Microsoft Azure oraz Google Cloud. Wybierasz jedną przy zakładaniu konta, a ten sam Snowflake wygląda i działa na każdej tak samo. Dla firm, które nie chcą przywiązywać się do jednego dostawcy (albo już stoją na AWS lub Azure), to jeden z głównych argumentów za Snowflake. Przy okazji Snowflake ma też własny rynek danych (marketplace), przez który organizacje udostępniają i kupują gotowe zbiory - to obszar, w którym idzie o krok dalej niż klasyczna hurtownia.

Wizualizacja i ekosystem

Hurtownia to dopiero połowa drogi - dane trzeba jeszcze pokazać. Tu oba narzędzia grają podobnie: wynik z jednego i drugiego podłączysz do popularnych narzędzi analitycznych i pulpitów. BigQuery ma naturalne, ścisłe połączenie z ekosystemem Google (darmowe Looker Studio, Arkusze, a dalej Vertex AI do uczenia maszynowego). Snowflake stawia na niezależność i integruje się z całym rynkiem - od narzędzi do wizualizacji po własne środowisko Snowpark do przetwarzania danych w Pythonie.

W jedno i drugie świetnie wpina się Power BI - jeśli interesuje Cię właśnie budowanie czytelnych pulpitów na danych z hurtowni, zajrzyj do naszego przewodnika czym jest Power BI, Power Query i DAX. To w praktyce najczęstszy dalszy krok po tym, jak dane wylądują w BigQuery albo w Snowflake.

Porównanie cecha po cesze

Zbierzmy najważniejsze różnice w jednym miejscu. Tam, gdzie oba wiersze brzmią podobnie, diabeł tkwi w szczegółach opisanych wyżej:

Tabela porównawcza BigQuery i Snowflake: model obliczeniowy, chmura, rozliczenie, skalowanie, język, składowanie, administracja, ekosystem
BigQuery kontra Snowflake, cecha po cesze. Pełny opis każdej pozycji znajdziesz w sekcjach powyżej.

Kiedy BigQuery, a kiedy Snowflake

Nie ma tu lepszego i gorszego - jest lepiej dopasowany do Twojej sytuacji. Poniższa ściągawka podsumowuje, w którą stronę zwykle warto się skłonić:

Infografika decyzyjna: kiedy wybrać BigQuery, a kiedy Snowflake
Skrót decyzji. Żadna z tych list nie jest sztywną regułą - to punkty, które najczęściej przeważają szalę na jedną albo drugą stronę.

Wybierz BigQuery, jeśli

  • Jesteś już w Google Cloud albo korzystasz z Google Ads i Analytics
  • Chcesz zero administracji i najszybszy start
  • Masz zapytania nieregularne, ad-hoc, o zmiennym natężeniu
  • Zależy Ci na tym, by płacić wyłącznie za to, co realnie przeskanujesz

Wybierz Snowflake, jeśli

  • Chcesz niezależności od jednej chmury lub stoisz na AWS albo Azure
  • Potrzebujesz izolacji obciążeń - wiele zespołów, przewidywalna wydajność
  • Masz stałe, ciężkie i przewidywalne obciążenie
  • Zależy Ci na pełnej kontroli nad rozmiarem i kosztem mocy oraz na współdzieleniu danych między firmami
Najprostsza podpowiedź na start.

Jeśli wahasz się, od czego zacząć naukę - zacznij od tego, gdzie już masz dane. Siedzisz w Google? Otwórz darmowy sandbox BigQuery. Stoisz na AWS lub Azure, albo chcesz poczuć ideę hurtowni wirtualnych? Załóż 30-dniowe darmowe konto próbne Snowflake. W obu i tak ćwiczysz ten sam SQL, więc żadna godzina nie jest zmarnowana.

Fundament obu narzędzi jest wspólny i znasz go już z tego artykułu: dane w chmurze plus zwykłe zapytanie SQL, bez własnego serwera po Twojej stronie. Różni je to, skąd biorą moc i za co każą płacić - a to, którą wybrać, wynika wprost z tego, jak i gdzie pracujesz.

Rozumiesz już, czym różnią się obie chmurowe hurtownie - czas zamienić to w praktyczną umiejętność.

Na praktycznych szkoleniach JSystems przećwiczysz to na żywych danych - jedno prowadzi przez BigQuery, drugie przez Snowflake:

Szkolenie Google BigQuery - podstawy -->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR.

★★★★★ Średnia ocena naszych szkoleń w Google: 5/5

Szkolenie Przetwarzanie danych z użyciem Snowflake -->

To szkolenie może być dofinansowane dla Ciebie z KFS lub BUR. To szkolenie ma terminy gwarantowane.

★★★★★ Średnia ocena naszych szkoleń w Google: 5/5

Najczęściej zadawane pytania

Czym różni się BigQuery od Snowflake w jednym zdaniu?
Obie to chmurowe hurtownie danych, w których pytasz zwykłym SQL, ale BigQuery jest bezserwerowy i sam dokłada moc obliczeniową (płacisz za ilość przeskanowanych danych), a w Snowflake sam włączasz hurtownię wirtualną o wybranym rozmiarze i płacisz za czas jej pracy. Do tego BigQuery działa tylko w chmurze Google, a Snowflake na Amazon AWS, Microsoft Azure albo Google Cloud.
Co jest tańsze - BigQuery czy Snowflake?
To zależy od charakteru pracy, bo modele rozliczeń są różne. BigQuery liczy koszt od ilości danych przeczytanych przez zapytanie, więc świetnie pasuje do nieregularnych, rzadkich analiz - płacisz tylko za to, co realnie przeskanujesz. Snowflake liczy koszt od czasu pracy włączonej hurtowni, więc opłaca się przy stałym, przewidywalnym obciążeniu, gdzie moc jest wykorzystywana w pełni. Przy nierównym obciążeniu tańszy bywa BigQuery, przy ciągłym - dobrze zestrojony Snowflake.
Czy Snowflake działa na Google Cloud?
Tak. Snowflake działa na trzech chmurach: Amazon AWS, Microsoft Azure oraz Google Cloud. Wybierasz jedną z nich przy zakładaniu konta, a ten sam Snowflake wygląda i działa na każdej tak samo. BigQuery jest natomiast dostępny wyłącznie w chmurze Google.
Czy muszę zarządzać serwerami w BigQuery albo Snowflake?
Nie stawiasz ani nie administrujesz żadnym serwerem w żadnym z nich. BigQuery jest w pełni bezserwerowy - nie ma czego włączać, moc pojawia się sama na czas zapytania. W Snowflake zarządzasz jedynie hurtowniami wirtualnymi: wybierasz ich rozmiar oraz ustawiasz automatyczne wyłączanie po bezczynności. To minimalna administracja, a nie utrzymywanie infrastruktury.
Czy w obu piszę zwykłym SQL?
Tak. W obu narzędziach pytasz standardowym SQL - piszesz SELECT, WHERE, GROUP BY i JOIN dokładnie tak samo jak w innych bazach. Różnice sprowadzają się do kilku funkcji własnych i drobiazgów składni, ale fundament jest wspólny, więc znając SQL ruszasz w każdym z nich od razu.
Które wybrać na początek nauki?
Oba mają darmowy próg wejścia, więc warto dotknąć obu. BigQuery ma tryb sandbox bez karty płatniczej i darmowy limit zapytań co miesiąc, co czyni go najszybszym startem, zwłaszcza jeśli korzystasz już z Google. Snowflake daje 30-dniowe darmowe konto próbne z pulą kredytów, na którym doświadczysz kluczowej dla niego idei hurtowni wirtualnych. Do nauki samego SQL i myślenia analitycznego jedno i drugie sprawdzi się równie dobrze.

Komentarze (0)

Musisz być zalogowany by móc dodać komentarz. Zaloguj się przez Google

Brak komentarzy...