{"id":10474,"date":"2026-09-19T18:10:00","date_gmt":"2026-09-19T16:10:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10474"},"modified":"2026-09-09T17:10:04","modified_gmt":"2026-09-09T15:10:04","slug":"koszty-bigquery-przy-eksporcie-ga4-ktore-tabele-i-kolumny-czyta-zapytanie","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/digital-analytics-pl\/koszty-bigquery-przy-eksporcie-ga4-ktore-tabele-i-kolumny-czyta-zapytanie\/","title":{"rendered":"Koszty BigQuery przy eksporcie GA4: kt\u00f3re tabele i kolumny czyta zapytanie oraz bezp\u0142atny dry run"},"content":{"rendered":"

Eksport GA4 rozlicza si\u0119 po bajtach, a liczba bajt\u00f3w nie ma z odpowiedzi\u0105 prawie nic wsp\u00f3lnego. Zapytanie zwracaj\u0105ce czterdzie\u015bci wierszy i zapytanie zwracaj\u0105ce cztery miliony mog\u0105 odczyta\u0107 dok\u0142adnie tyle samo – bo rozlicza si\u0119 to, co trzeba by\u0142o po drodze otworzy\u0107, a nie to, co na ko\u0144cu wr\u00f3ci\u0142o.<\/p>\n

Rozstrzygaj\u0105 dwa szczeg\u00f3\u0142y: ile tabel dziennych trzeba otworzy\u0107 i ile kolumn w nich odczyta\u0107. Jedno i drugie jest przes\u0105dzone, zanim powstanie cho\u0107 jeden wiersz, i jedno i drugie da si\u0119 wcze\u015bniej odczyta\u0107.<\/p>\n

\n\"Dziewi\u0119\u0107dziesi\u0105t
Ten sam miesi\u0105c, te same wiersze, ten sam wynik. Inaczej zapisany jest tylko filtr.<\/figcaption><\/figure>\n

P\u0142aci si\u0119 za czytanie, nie za zwracanie<\/h2>\n

Najdro\u017csze nieporozumienie w tym obszarze nazywa si\u0119 LIMIT<\/code>. Ograniczenie dzia\u0142a po odczytaniu danych; przycina zbi\u00f3r wynik\u00f3w i nie zmienia kosztu o nic. To samo dotyczy ORDER BY<\/code> i wszystkiego innego, co dzieje si\u0119, gdy wiersze ju\u017c s\u0105.<\/p>\n

Tym samym nawyk przegl\u0105dania przez SELECT * ... LIMIT 10<\/code> – rozs\u0105dny w niemal ka\u017cdej innej bazie – jest najdro\u017cszym sposobem obejrzenia eksportu GA4. Dziesi\u0119\u0107 wierszy z ka\u017cdej kolumny po ka\u017cdej tabeli wieloznacznika to pe\u0142ny przebieg z ma\u0142ym okienkiem na ko\u0144cu.<\/p>\n

Dlaczego event_date niczego nie przycina<\/h2>\n

Tabele dzienne adresuje si\u0119 wieloznacznikiem, a _TABLE_SUFFIX<\/code> to ta cz\u0119\u015b\u0107 nazwy tabeli, kt\u00f3ra po nim nast\u0119puje. Filtrowanie po nim wybiera tabele, a wyb\u00f3r nast\u0119puje przed czytaniem – reszty maszyna po prostu nigdy nie otwiera.<\/p>\n

event_date<\/code> wygl\u0105da, jakby robi\u0142o to samo, a robi co\u015b przeciwnego. Jest kolumn\u0105 w ka\u017cdej tabeli; \u017ceby stwierdzi\u0107, czy tabela zawiera pasuj\u0105ce wiersze, trzeba j\u0105 otworzy\u0107 i t\u0119 kolumn\u0119 odczyta\u0107. Filtr dzia\u0142a poprawnie, wynik jest identyczny, a rachunek obejmuje ca\u0142y wieloznacznik.<\/p>\n

# przycina: sufiks jest częścią nazwy\nWHERE _TABLE_SUFFIX BETWEEN '20260801' AND '20260831'\n\n# nie przycina: kolumna leży wewnątrz tabel\nWHERE event_date BETWEEN '20260801' AND '20260831'\n\n# oba zwracają te same wiersze<\/code><\/pre>\n
Ta sama logika t\u0142umaczy, dlaczego wieloznacznik trafia r\u00f3wnie\u017c events_intraday_*<\/code> i dlaczego filtr sufiksu je wyklucza: intraday_<\/code> sortuje si\u0119 za ka\u017cd\u0105 o\u015bmiocyfrow\u0105 dat\u0105, wi\u0119c zakres ko\u0144cz\u0105cy si\u0119 dat\u0105 zostawia je na zewn\u0105trz. To skutek uboczny, kt\u00f3ry warto zna\u0107, a nie na nim polega\u0107 – bie\u017c\u0105cy dzie\u0144 odpytuje si\u0119 z tabeli intraday celowo i osobno.<\/p>\n
Kolumny to druga d\u017awignia<\/h2>\n
Wewn\u0105trz tabel, kt\u00f3re faktycznie zostaj\u0105 otwarte, kosztem jest suma wymienionych kolumn. Tu zaczyna mie\u0107 znaczenie budowa eksportu: event_params<\/code> to jedna zagnie\u017cd\u017cona kolumna, w kt\u00f3rej le\u017cy ka\u017cdy parametr ka\u017cdego zdarzenia, a zapytanie wyci\u0105gaj\u0105ce z niej pojedynczy parametr czyta ca\u0142\u0105 kolumn\u0119.<\/p>\n
Odczytanie z tej tablicy samego page_location<\/code> nie jest mo\u017cliwe. Nie przemawia to przeciw jej u\u017cyciu – przemawia za wymienianiem kolumn wprost zamiast si\u0119gania po SELECT *<\/code>, bo naprawd\u0119 du\u017ce kolumny to dok\u0142adnie te, kt\u00f3rych nikt nie potrzebuje: user_properties<\/code>, items<\/code>, collected_traffic_source<\/code> oraz struktury urz\u0105dzenia i geolokalizacji.<\/p>\n
Co faktycznie zmienia ka\u017cde dzia\u0142anie<\/h2>\n\n\n\n\n\n\n\n\n\n\n
Dzia\u0142anie<\/th>\nWp\u0142yw na odczytane bajty<\/th>\n<\/tr>\n<\/thead>\n
_TABLE_SUFFIX<\/code> zamiast event_date<\/code><\/td>\nz ka\u017cdej tabeli zbioru do tych z zakresu<\/td>\n<\/tr>\n
wymienianie kolumn zamiast SELECT *<\/code><\/td>\nproporcjonalnie – cz\u0119sto najwi\u0119ksza pojedyncza oszcz\u0119dno\u015b\u0107<\/td>\n<\/tr>\n
LIMIT 100<\/code><\/td>\n\u017caden<\/td>\n<\/tr>\n
filtr po parametrze zdarzenia<\/td>\n\u017caden – event_params<\/code> i tak czyta si\u0119 w ca\u0142o\u015bci<\/td>\n<\/tr>\n
filtr po event_name<\/code><\/td>\nzale\u017cy od klastrowania tabel – powie to przebieg pr\u00f3bny<\/td>\n<\/tr>\n
w\u0105ska tabela zapisywana raz dziennie<\/td>\nu\u0142amek, trwale, dla ka\u017cdego kolejnego zapytania<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Wiersz o klastrowaniu celowo pozostaje tu bez odpowiedzi. To, czy filtr po event_name<\/code> oszcz\u0119dza bajty, zale\u017cy od zbioru, a snucie domys\u0142\u00f3w jest zb\u0119dne, gdy dok\u0142adna odpowied\u017a le\u017cy o jedno naci\u015bni\u0119cie klawisza dalej.<\/p>\n
Przebieg pr\u00f3bny jest darmowy i dok\u0142adny<\/h2>\n
BigQuery wylicza oszacowanie bajt\u00f3w z metadanych tabel, nie wykonuj\u0105c niczego – jest wi\u0119c darmowe i dok\u0142adne. Edytor pokazuje je w rogu przed wys\u0142aniem zapytania; w wierszu polece\u0144 to samo dost\u0119pne jest jako prze\u0142\u0105cznik.<\/p>\n
bq query --use_legacy_sql=false --dry_run 'SELECT ...'\n\nQuery successfully validated.\nAssuming the tables are not modified,\nthis query will process 41 203 847 552 bytes of data.<\/code><\/pre>\n
Czterdzie\u015bci jeden gigabajt\u00f3w to liczba, o kt\u00f3rej da si\u0119 zdecydowa\u0107. Uruchomienie zapytania najpierw i dowiedzenie si\u0119 potem to ta sama informacja w gorszym momencie, a mi\u0119dzy tymi nawykami le\u017cy jeden wiersz przed instrukcj\u0105.<\/p>\n
Co si\u0119 powtarza, nale\u017cy do w\u0105skiej tabeli<\/h2>\n
Ostatnia d\u017awignia jest budowlana, a nie j\u0119zykowa. Analiza uruchamiana ka\u017cdego ranka na dziewi\u0119\u0107dziesi\u0119ciu dniach czyta na nowo osiemdziesi\u0105t dziewi\u0119\u0107 dni, kt\u00f3re od wczoraj si\u0119 nie zmieni\u0142y.<\/p>\n
Zaplanowane zapytanie zapisuj\u0105ce raz dziennie tych kilka faktycznie u\u017cywanych p\u00f3l do w\u0142asnej tabeli zamienia to w: odczyta\u0107 jeden dzie\u0144, a potem odpytywa\u0107 co\u015b ma\u0142ego. Dzienny przebieg kosztuje tyle, ile kosztuje jeden dzie\u0144; wszystko dalsze kosztuje u\u0142amek dotychczasowego. To ta sama sztuczka co widok zmaterializowany i op\u0142aca si\u0119, gdy tylko zapytanie zosta\u0142o uruchomione r\u0119cznie trzy razy.<\/p>\n
\n
\u0179r\u00f3d\u0142a<\/h2>\n