{"id":8824,"date":"2026-08-15T11:12:00","date_gmt":"2026-08-15T09:12:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=8822"},"modified":"2026-08-13T14:29:55","modified_gmt":"2026-08-13T12:29:55","slug":"optymalizacja-kosztow-bigquery-ga4-surowy-eksport","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/digital-analytics-pl\/optymalizacja-kosztow-bigquery-ga4-surowy-eksport\/","title":{"rendered":"Optymalizacja koszt\u00f3w BigQuery w GA4: Jak przesta\u0107 przepala\u0107 bud\u017cet na surowym eksporcie"},"content":{"rendered":"\r\n
Optymalizacja koszt\u00f3w BigQuery w GA4: Jak przesta\u0107 przepala\u0107 bud\u017cet na surowym eksporcie<\/h2>\r\n\r\n\r\n\r\n
Praca z natywnym eksportem zdarze\u0144 Google Analytics 4 (GA4) w Google Cloud BigQuery zapewnia nieograniczon\u0105 elastyczno\u015b\u0107 analityczn\u0105. Jednak nieoptymalne zapytania kierowane bezpo\u015brednio do surowych tabel potrafi\u0105 b\u0142yskawicznie wygenerowa\u0107 ogromne koszty infrastrukturowe. Poniewa\u017c model rozliczeniowy BigQuery opiera si\u0119 na ilo\u015bci danych przetworzonych podczas wykonywania zapytania, zrozumienie kolumnowej architektury przechowywania danych stanowi absolutn\u0105 podstaw\u0119 profesjonalnej in\u017cynierii danych.<\/p>\r\n\r\n\r\n\r\n
1. Architektoniczna pu\u0142apka zapyta\u0144 SELECT * na tabelach events_*<\/h2>\r\n\r\n\r\n\r\n
BigQuery oddziela wykonywanie zapyta\u0144 od przechowywania danych: Dremel to rozproszony silnik zapyta\u0144, a same dane zapisywane s\u0105 w kolumnowym formacie Capacitor. W tradycyjnych bazach wierszowych odczyt rekordu oznacza pobranie ca\u0142ej wierszowej struktury. W bazie kolumnowej ka\u017cda kolumna jest zapisywana niezale\u017cnie w rozproszonych blokach pami\u0119ci. Koszt zapytania zale\u017cy zatem wy\u0142\u0105cznie od ca\u0142kowitego rozmiaru bajt\u00f3w tych kolumn, kt\u00f3re zosta\u0142y wprost wskazane w instrukcji SQL.<\/p>\r\n\r\n\r\n\r\n
Wykonanie og\u00f3lnego zapytania SELECT * FROM `project.analytics_12345.events_*`<\/code> zmusza silnik do przeskanowania absolutnie wszystkich kolumn we wszystkich dost\u0119pnych shardach \u2013 wliczaj\u0105c w to ogromne, zagnie\u017cd\u017cone tablice RECORD, takie jak event_params<\/code>, user_properties<\/code> czy items<\/code>. Jedna taka kwerenda obejmuj\u0105ca kilkumiesi\u0119czn\u0105 histori\u0119 potrafi przeskanowa\u0107 terabajty danych, generuj\u0105c znaczne straty finansowe.<\/p>\r\n\r\n\r\n\r\n\n\nKa\u017cdy stopie\u0144 zmniejsza to, co zapytanie musi przeczyta\u0107: najpierw okno czasu i kolumny, potem sam\u0105 tabel\u0119 surow\u0105, kt\u00f3rej panel ju\u017c w og\u00f3le nie dotyka.<\/figcaption>\n<\/figure>\n\n
2. Partycjonowanie po datach i filtrowanie przez sufiksy tabel<\/h2>\r\n\r\n\r\n\r\n
GA4 eksportuje dane w formie dziennych tabel shardowanych o strukturze events_YYYYMMDD<\/code>. Podstawowym mechanizmem redukcji skanowanych bajt\u00f3w jest rygorystyczne partycjonowanie z wykorzystaniem pseudokolumny _TABLE_SUFFIX<\/code>. Brak tego filtra sprawia, \u017ce silnik odczytuje ca\u0142\u0105 dost\u0119pn\u0105 histori\u0119 zbioru przed zastosowaniem jakichkolwiek warunk\u00f3w WHERE.<\/p>\r\n\r\n\r\n\r\n
-- KOSZTOWNE (Skanuje ca\u0142\u0105 histori\u0119 zbioru danych):\r\nSELECT event_name, user_pseudo_id \r\nFROM `project.analytics_12345.events_*`\r\nWHERE event_name = 'purchase';\r\n\r\n-- ZOPTYMALIZOWANE (Ogranicza scan do 7-dniowego okna):\r\nSELECT event_name, user_pseudo_id \r\nFROM `project.analytics_12345.events_*`\r\nWHERE _TABLE_SUFFIX BETWEEN '20260801' AND '20260807'\r\n AND event_name = 'purchase';<\/code><\/pre>\r\n\r\n\r\n\r\n
3. Klastrowanie po event_name oraz user_pseudo_id<\/h2>\r\n\r\n\r\n\r\n
O ile partycjonowanie oddziela dane na poziomie pojedynczych tabel dziennych, o tyle klastrowanie fizycznie porz\u0105dkuje bloki pami\u0119ci wewn\u0105trz nich na podstawie okre\u015blonych kolumn. Gdy procesy analityczne regularnie filtruj\u0105 zbi\u00f3r po nazwach zdarze\u0144 lub identyfikatorach u\u017cytkownik\u00f3w, wdro\u017cenie klastrowania na tabelach stagingowych znacz\u0105co ogranicza zu\u017cycie zasob\u00f3w.<\/p>\r\n\r\n\r\n\r\n
Przy zapytaniu uwzgl\u0119dniaj\u0105cym kolumn\u0119 klastrowan\u0105 BigQuery automatycznie pomija nieistotne bloki pami\u0119ci (tzw. block pruning). W analityce internetowej najwy\u017csz\u0105 efektywno\u015b\u0107 osi\u0105ga si\u0119 poprzez klastrowanie wed\u0142ug kardynalno\u015bci \u2013 rozpoczynaj\u0105c od event_name<\/code>, a ko\u0144cz\u0105c na user_pseudo_id<\/code>.<\/p>\r\n\r\n\r\n\r\n
Bezpo\u015brednie pod\u0142\u0105czanie narz\u0119dzi BI czy system\u00f3w raportowych do surowych, zagnie\u017cd\u017conych tabel GA4 jest b\u0142\u0119dem architektonicznym. Z\u0142otym standardem jest wdro\u017cenie procesu ETL (Extract, Transform, Load) z u\u017cyciem przyrostowych zapyta\u0144 harmonogramowanych (Scheduled Queries)<\/strong>. Codzienne przetwarzanie wy\u0142\u0105cznie danych z minionej doby i zapisywanie ich do p\u0142askiej, sklastrowanej tabeli agregacyjnej redukuje koszty ci\u0105g\u0142ego raportowania nawet o 95%.<\/p>\r\n\r\n\r\n\r\n
-- Konfiguracja jednorazowa: utworzenie tabeli docelowej (uruchamiane raz)\r\nCREATE TABLE IF NOT EXISTS `project.analytics_12345.daily_user_metrics`\r\n(\r\n event_date DATE,\r\n event_name STRING,\r\n user_pseudo_id STRING,\r\n total_events INT64,\r\n sessions INT64\r\n)\r\nPARTITION BY event_date\r\nCLUSTER BY event_name, user_pseudo_id;\r\n\r\n-- Dzienna kwerenda przyrostowa (w\u0142a\u015bciwe zadanie harmonogramowane)\r\nDELETE FROM `project.analytics_12345.daily_user_metrics`\r\nWHERE event_date = DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY);\r\n\r\nINSERT INTO `project.analytics_12345.daily_user_metrics`\r\nSELECT\r\n PARSE_DATE('%Y%m%d', event_date) AS event_date,\r\n event_name,\r\n user_pseudo_id,\r\n COUNT(1) AS total_events,\r\n COUNT(DISTINCT (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id')) AS sessions\r\nFROM `project.analytics_12345.events_*`\r\nWHERE _TABLE_SUFFIX = FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY))\r\nGROUP BY 1, 2, 3;<\/code><\/pre>\r\n\r\n\r\n\r\n
Podsumowanie<\/h2>\r\n\r\n\r\n\r\n
Efektywna kosztowo architektura GA4 w BigQuery opiera si\u0119 na trzech filarach: wyeliminowaniu zapyta\u0144 z symbolem wieloznacznym SELECT *, \u015bcis\u0142ej kontroli skanowanego zakresu dat przez _TABLE_SUFFIX<\/code> oraz przeniesieniu obci\u0105\u017ce\u0144 raportowych na p\u0142askie, sklastrowane tabele po\u015brednie zasilane przez nocne procesy przyrostowe.<\/p>\r\n\n\n
![\"Trzy](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/hand-bqkosten-pl.png\")
\n