Excel pada przy 2 mln wierszy – ile kosztuje to samo w BigQuery?

Klasyczny scenariusz: firma zbiera dane sprzedażowe od kilku lat. Eksporty z systemu ERP lądują w Excelu co miesiąc. Ktoś próbuje połączyć dwa lata danych w jeden plik – i plik przestaje się otwierać. Albo otwiera się po dziesięciu minutach, a każda formuła VLOOKUP łącząca transakcje z katalogiem produktów działa przez kwadrans i zwraca błąd pamięci.

W tym artykule liczę to konkretnie. Dwa pliki, realne rozmiary, jedno sensowne pytanie biznesowe – i dokładna kalkulacja ile zapłacisz za tę samą analizę w BigQuery. Odpowiedź będzie zaskakująca.

Scenariusz: dwa pliki, jedno pytanie

Firma dystrybucyjna. Dwa źródła danych:

Pytanie biznesowe: Które kategorie produktów wygenerowały największy przychód w każdym miesiącu 2025 roku, z podziałem na kanał sprzedaży (sklep własny / sieć partnerska / e-commerce)?

Brzmi jak standardowe zadanie analityczne. Spróbujmy je zrobić w Excelu.

Dlaczego Excel nie da rady

Oficjalny limit Excela to 1 048 576 wierszy w jednym arkuszu. Plik z 2,3 miliona transakcji w ogóle się nie otworzy – Excel przerwie ładowanie po osiągnięciu limitu i wczyta tylko część danych, bez ostrzeżenia, że reszta zniknęła. Analiza na obciętych danych da błędne wyniki.

Co zrobić? Podzielić na dwa pliki po ~1,15 mln wierszy. Teraz problem z VLOOKUP:

• VLOOKUP wyszukujący kategorię produktu po ID w 1,15 mln wierszach to ponad miliard operacji porównania. Na nowoczesnym laptopie zajmie 15–40 minut. Przy każdej edycji arkusza przelicza się od nowa.
• Tabela przestawna na 1,15 mln wierszach potrafi się zawiesić lub zająć kilka minut ładowania.
• Wyniki z dwóch plików trzeba jeszcze ręcznie scalić – czyli dodatkowy krok z kolejnym VLOOKUP lub kopiowaniem.

I to wszystko dla połowy danych. Gdybyś miał trzy lata transakcji, nie możesz ich w ogóle przeanalizować razem w Excelu – chyba że kupisz serwer SQL. A to koszt licencji, utrzymania i administratora bazy danych.

Wgranie danych do BigQuery

Szczegółowy tutorial wgrywania jest w artykule Jak wgrać dane do BigQuery. Skrót dla tego case'u:

1. Google Cloud Console → BigQuery → Utwórz zestaw danych dystrybucja (lokalizacja: EU)
2. Utwórz tabelę zamowienia → Źródło: Upload → plik zamowienia_2024_2025.csv → Schemat: Automatyczne wykrywanie → Utwórz
3. Utwórz tabelę produkty → to samo dla produkty.csv

Łączny czas dla obu plików: 3–5 minut. Plik 280 MB ładuje się do BigQuery w około 2 minuty.

Zapytanie SQL – to samo co VLOOKUP + pivot

Odpowiednik VLOOKUP (złączenie transakcji z katalogiem) plus tabela przestawna (grupowanie po miesiącu, kategorii i kanale) to jedno zapytanie SQL:

SELECT
  FORMAT_DATE('%Y-%m', z.data_zamowienia)  AS miesiac,
  p.kategoria,
  z.kanal_sprzedazy,
  SUM(z.wartosc_netto)                     AS przychod_netto,
  COUNT(DISTINCT z.id_klienta)             AS liczba_klientow,
  COUNT(*)                                 AS liczba_zamowien
FROM `moj-projekt.dystrybucja.zamowienia` z
JOIN `moj-projekt.dystrybucja.produkty`   p ON z.id_produktu = p.id_produktu
WHERE z.data_zamowienia BETWEEN '2025-01-01' AND '2025-12-31'
GROUP BY miesiac, p.kategoria, z.kanal_sprzedazy
ORDER BY miesiac, przychod_netto DESC;

Czas wykonania na 2,3 mln wierszy: 2–4 sekundy. Wynik to gotowa tabela, którą możesz podłączyć do Data Studio jako źródło danych i zbudować na niej dashboard.

Ale ile to kosztuje? Policzmy.

Koszt 1: przechowywanie danych

BigQuery przechowuje dane w formacie kolumnowym z kompresją. Plik CSV 280 MB po załadowaniu do BigQuery zajmuje realnie około 90–130 MB – kolumnowa kompresja jest bardzo skuteczna na powtarzalnych danych transakcyjnych.

Przyjmijmy 120 MB = 0,12 GB dla tabeli zamówień, plus ~0,5 MB dla produktów. Łącznie: ~0,12 GB.

Nawet gdybyś zebrał 5 lat danych zamiast 2 – przy podobnej strukturze tabela waży nadal 300 MB. Daleko od limitu 10 GB.

Koszt 2: wykonanie zapytania

BigQuery nalicza opłaty za ilość danych przetworzonych przez zapytanie – konkretnie za kolumny, które SQL musi przeskanować. To kluczowa różnica względem tradycyjnych baz danych: płacisz za wiersze × kolumny, nie za czas CPU.

Nasze zapytanie używa 5 kolumn z tabeli zamówień: data_zamowienia, id_produktu, wartosc_netto, kanal_sprzedazy, id_klienta. Tabela produktów jest mała – pomijamy jej koszt.

Ale poczekaj – zanim w ogóle zapłacisz ten ułamek grosza, musisz przekroczyć darmowy limit 1 TB zapytań miesięcznie. Ile razy możesz uruchomić nasze zapytanie zanim osiągniesz próg płatności?

1 000 000 MB ÷ 86 MB = 11 627 razy

Ponad jedenaście tysięcy uruchomień tego zapytania miesięcznie za darmo. Jeśli analityk odpytuje te dane 5 razy dziennie, przez ponad 6 lat nie przekroczy darmowego limitu.

Jak sprawdzić koszt zanim uruchomisz zapytanie

Nie musisz liczyć ręcznie przy każdym zapytaniu. Edytor BigQuery w konsoli Google Cloud pokazuje szacowany rozmiar przetwarzanych danych na bieżąco – w prawym górnym rogu okna edytora, zanim klikniesz „Uruchom".

Przykładowo: gdy wpiszesz nasze zapytanie, pojawi się komunikat „To zapytanie przetworzy 86 MB". Koszt możesz wyliczyć w głowie: megabajty podziel przez milion (to daje TB), a wynik pomnóż przez 25 zł. Dla 86 MB: 86 / 1 000 000 × 25 = niecałe 0,01 grosza.

Realny rachunek za miesiąc codziennej pracy

Przyjmijmy realistyczny scenariusz: zespół analityczny uruchamia 5 różnych zapytań dziennie – różne warianty pytania o sprzedaż, marżę, klientów. Każde przetwarza średnio 100 MB (nieco więcej niż nasze przykładowe).

Tak – pięć zapytań analitycznych dziennie przez cały miesiąc na 2,3 miliona wierszy kosztuje zero złotych.

Kiedy w ogóle zaczyna się płacić?

Żeby przekroczyć darmowy limit 1 TB zapytań przy zapytaniach przetwarzających 100 MB, musisz uruchomić ponad 10 000 zapytań miesięcznie. To 333 zapytań dziennie. W praktyce oznacza to jedno z trzech:

• Bardzo duży zespół analityczny – kilkanaście osób, każda uruchamia setki zapytań dziennie
• Źle napisane zapytania – SELECT * na tabelach z dziesiątkami kolumn zwielokrotnia skanowane dane. Nasze 5 kolumn to ~86 MB; SELECT * z 40 kolumns to ~700 MB za to samo zapytanie
• Bardzo duże tabele – kilkadziesiąt GB bez partycjonowania. Jeden SELECT * na 50 GB tabeli to już 50 GB skanowania i koszt ok. 1,25 zł za jedno zapytanie

Dla typowej firmy dystrybucyjnej z 2–3 latami danych transakcyjnych i kilkuosobowym zespołem analitycznym rachunek BigQuery przez pierwszy rok często wynosi dosłownie zero złotych. Pierwsze koszty pojawiają się gdy dane urosną do kilkudziesięciu GB i zaczniesz skanować je bez partycjonowania. A to osobny temat.