Na czym to polega w sklepie
Każde odświeżenie dashboardu w Lookerze skanuje rok eventów od zera? Materialized view przechowuje gotowy wynik - dzień × kanał × zamówienia × przychód - i odświeża go przy zmianie danych źródłowych. Analityk łączy się do MV, nie do surowego events_*.
Przykład ze sklepu internetowego
Sklep DTC z codziennym raportem zarządczym - MV z deduplikowanymi purchase per dzień i kanale jako jedyne źródło dla wykresów revenue i orders w Looker Studio:
CREATE MATERIALIZED VIEW `project.mart.daily_ecommerce_kpi`
PARTITION BY event_date
AS
SELECT
event_date,
session_default_channel_group AS channel,
COUNT(DISTINCT transaction_id) AS orders,
SUM(purchase_revenue) AS revenue
FROM `project.mart.purchases_deduped`
GROUP BY 1, 2;Co zrobić po stronie biznesu
- Ustaw alert: spadek orders >30% dzień do dnia w MV - wczesny sygnał awarii tagów checkout.
- Łańcuch: scheduled query buduje
purchases_deduped, MV agreguje KPI - czytelny podział odpowiedzialności. - Złożony UNNEST items często wymaga tabeli pośredniej - MV na gotowym mart, nie na surowym eksporcie.
W skrócie
Jedna warstwa mart oszczędza czas i pieniądze całemu zespołowi growth. Bez niej każdy raport w Lookerze skanuje rok eventów - wolno, drogo i frustrująco przy poniedziałkowym statusie.