Trzy błędy agregacji danych w systemach BI

# Dlaczego systemy BI kłamią: trzy fatalne błędy agregacji danych

Metryki w narzędziach BI często pokazują iluzoryczną precyzję. W praktyce, gdy dane przechodzą od surowych transakcji do preagregowanych hurtowni, pojawiają się systemowe zniekształcenia — czasem na dziesiątki procent. To nie błąd, lecz architekturalny kompromis prędkości kosztem wiarygodności. Rozłożymy na czynniki pierwsze trzy kluczowe matematyczne pułapki, które czynią analizę niebezpieczną dla podejmowania decyzji.

Błąd pierwszy: uśrednianie średnich — matematyczna katastrofa

Średni rachunek, średni czas przetwarzania wniosku, średni koszt zamówienia — wszystkie te wskaźniki nie są addytywne. Nie można ich po prostu uśredniać na podstawie już uśrednionych wartości. Klasyczny przykład: system BI bierze średnie rachunki po sklepach za styczeń, luty i marzec, sumuje je i dzieli przez trzy, by uzyskać kwartalny wskaźnik. Formuła wygląda tak:

SELECT 
    region_name,
    EXTRACT(QUARTER FROM year_month) AS quarter,
    AVG(avg_receipt_amount) AS total_average_check
FROM dwh.store_monthly_aggregated
WHERE EXTRACT(QUARTER FROM year_month) = 1
GROUP BY region_name, EXTRACT(QUARTER FROM year_month);

Problem polega na tym, że A/B + C/D ≠ (A+B)/(C+D). Hipermarket z 10 000 rachunków dziennie ma taki sam ciężar w obliczeniach jak kiosk z 50 rachunkami. Miesiąc z pikowymi sprzedażami zrównuje się z „martwym". W rzeczywistych danych prowadzi to do odchyleń od -6% do +7%. W handlu detalicznym, gdzie każdy procent wzrostu średniego rachunku to miliony rubli, takie zniekształcenia są niedopuszczalne. Najgorsze, gdy przypadkowe zrównanie mianowników daje poprawny wynik — wtedy błąd utrwala się w DWH jako „prawidłowy".

Błąd drugi: count distinct przy zmianie kontekstu filtrowania

Liczenie unikalnych obiektów — klientów, rachunków, towarów — rozpada się przy zmianie poziomu szczegółowości. Wyobraź sobie trzy transakcje:

• Rachunek №101 | Bakalia
• Rachunek №101 | Napoje
• Rachunek №102 | Napoje

Rzeczywista liczba unikalnych rachunków — 2. Ale jeśli dane są preagregowane po kategoriach:

• Bakalia: 1 rachunek (№101)
• Napoje: 2 rachunki (№101, №102)

To przy zwijaniu hierarchii w Power BI lub silniku SQL DAX wykona prostą sumę: 1 + 2 = 3. Unikalność stracona. System podwoił rachunek №101. Ten błąd natychmiast zniekształca średni rachunek, konwersję, LTV — wszystko, co zależy od liczby unikalnych encji. Użytkownik nawet nie podejrzewa, że zmienił perspektywę — i dostał fałszywe cyfry.

Błąd trzeci: póładdtywne wskaźniki i sztywne kalendarze

Stany magazynowe, salda kont, liczba aktywnych użytkowników — to metryki snapshot. Można je sumować po przestrzeni (sklepach, regionach), ale nie po czasie. Aby to obejść, programiści używają funkcji typu LASTNONBLANK w DAX lub NonEmpty w MDX:

Balance na konets perioda = 
CALCULATE (SUM('Inventory'[Balance]),
    LASTNONBLANK ('Calendar'[Date], 
        CALCULATE(SUM('Inventory'[Balance]))
    ))

To tworzy trzy problemy:

• Wydajność: silnik przegląda wszystkie daty w hierarchii przy każdej zmianie filtra. Na dużych wolumenach — zawieszanie się.
• Awaryjne sytuacje: jeśli 30-go kasa nie przekazała danych z powodu awarii, system pokaże zerowy stan na 31-go. Towar „znika" na setki tysięcy rubli.
• Złożoność kodu: użytkownik musi być programistą. Przy kilku biznesowych kalendarzach formuły stają się nieczytelne i kruche.

Co ważne

• Agregacja zabija precyzję. Wstępne kompresowanie danych dla prędkości — to kompromis, który często jest nieświadomie przyjmowany bez zrozumienia konsekwencji.
• Nieaddatywne metryki wymagają surowych danych. Jakiekolwiek uśrednianie, mediana, licznik unikalnych — muszą być obliczane na bieżąco po pełnym zbiorze.
• Metryki snapshot nie znoszą sztywnych granic czasowych. System musi elastycznie szukać aktualnej wartości, a nie ślepo trzymać się kalendarza.
• Użytkownik BI nie powinien pisać DAX/MDX. Architektura powinna ukrywać złożoność, a nie zrzucać ją na analityka.
• Nowe platformy rezygnują z preagregacji. Dynamiczne łączenie surowych źródeł na bieżąco — to jedyna droga do matematycznie precyzyjnej analityki.

Zmiana paradygmatu: analityka bez kompromisów

Klasyczne systemy BI zbudowane są na iluzji: możemy zaranee obliczyć wszystko, czego potrzebuje biznes. W rzeczywistości — biznes ciągle zmienia pytania. Zamiast pisać protezy na DAX, nowoczesne platformy pracują z surowymi danymi bezpośrednio. Na przykład, obliczanie wskaźnika „Zaopatrzenie w towar” — stosunek stanów do sprzedaży — może łączyć dwa różne źródła: miliardy wierszy stanów i miliardy wierszy rachunków. Zamiast tworzenia sztywnej hurtowni w DWH, system dynamicznie łączy źródła przy każdym kliknięciu użytkownika, przeliczając metrykę matematycznie dokładnie. Rdzeń sam określa korytarze czasowe, szuka aktualnych stanów i wczytuje do pamięci tylko niezbędne dane. To nie „szybciej", to „dokładniej". Kiedy menedżerowie banku po raz pierwszy zobaczyli rzeczywisty czas przetwarzania wniosków — bez zniekształceń od uśredniania średnich — zaczęli zadawać właściwe pytania. Sieć handlowa nie chce już tracić sensu dla limitu 5 milionów wierszy. Analityka powinna być plikiem RAW, a nie JPEG. Tylko tak można zachować detale i możliwość edycji wniosków. Technologie na to pozwalają — pozostaje przebudować architekturę myślenia.

— Editorial Team