Tři chyby agregace dat v BI-systémech

# Proč BI systémy lhají: tři fatální chyby agregace dat

Metriky v BI nástrojích často ukazují iluzorní přesnost. V praxi, jakmile data přejdou od surových transakcí k předagregovaným datovým martům, vznikají systémové zkreslení – někdy o desítky procent. To není bug, ale architektonický kompromis rychlosti proti věrohodnosti. Rozložíme tři klíčové matematické pasti, které dělají analýzu nebezpečnou pro rozhodování.

Chyba první: průměrování průměrů – matematická katastrofa

Průměrný nákup, průměrná doba zpracování žádosti, průměrná cena objednávky – všechny tyto ukazatele nejsou aditivní. Nelze je jednoduše průměrovat z již průměrovaných hodnot. Klasický příklad: BI systém vezme průměrné nákupy podle obchodů za leden, únor a březen, sečte je a vydělí třemi, aby získal čtvrtletní ukazatel. Formule vypadá takto:

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);

Problém je v tom, že A/B + C/D ≠ (A+B)/(C+D). Hypermarket s 10 000 nákupy denně dostane stejnou váhu v výpočtu jako stánek s 50 nákupy. Měsíc s vrcholovými prodeji se vyrovná „mrtvému“. V reálných datech to vede k odchylkám od -6 % do +7 %. V maloobchodu, kde každý procentuální růst průměrného nákupu znamená miliony rublů, jsou taková zkreslení nepřípustná. Nejhorší je, když shoda jmenovatelů náhodně dá správný výsledek – tehdy se chyba upevní v DWH jako „správná".

Chyba druhá: count distinct při změně kontextu filtrování

Počítání unikátních objektů – zákazníků, nákupů, zboží – se rozpadne při změně úrovně detailu. Představte si tři transakce:

• Nákup №101 | Potraviny
• Nákup №101 | Nápoje
• Nákup №102 | Nápoje

Reálný počet unikátních nákupů – 2. Ale pokud jsou data předem agregována podle kategorií:

• Potraviny: 1 nákup (№101)
• Nápoje: 2 nákupy (№101, №102)

Pak při sbalení hierarchie v Power BI nebo SQL enginu DAX provede jednoduché sčítání: 1 + 2 = 3. Unikátnost je ztracena. Systém zdvojnásobil nákup №101. Tato chyba okamžitě zkreslí průměrný nákup, konverzi, LTV – vše, co závisí na počtu unikátních entit. Uživatel ani netuší, že změnil úhel pohledu – a dostal falešná čísla.

Chyba třetí: poloaditivní ukazatele a tuhé kalendáře

Zásoby na skladech, salda účtů, počet aktivních uživatelů – to jsou snapshot metriky. Lze je sečíst podle prostoru (obchodům, regionům), ale ne podle času. Aby to obešli, vývojáři používají funkce typu LASTNONBLANK v DAX nebo NonEmpty v MDX:

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

To vytváří tři problémy:

• Výkon: engine prochází všechny datumy v hierarchii při každé změně filtru. Na velkých objemech – zasekávání.
• Životní selhání: pokud 30. dne kasa neposkytla data kvůli poruše, systém ukáže nulový zůstatek na 31. Zboží „zmizelo“ na stovky tisíc rublů.
• Složitost kódu: uživatel musí být vývojář. Při několika obchodních kalendářích se formule stávají nečitelnými a křehkými.

Co je důležité

• Agregace zabíjí přesnost. Předem komprimovaná data kvůli rychlosti – to je kompromis, který se často přijímá nevedomky bez pochopení důsledků.
• Neaditivní metriky vyžadují surová data. Jakékoli průměrování, medián, unikátní počítadlo – musí se počítat za letu z úplného datasetu.
• Snapshot metriky nesnáší tuhé časové hranice. Systém musí flexibilně hledat aktuální hodnotu, ne slepě následovat kalendář.
• Uživatel BI nemusí psát DAX/MDX. Architektura musí skrývat složitost, ne přehazovat ji na analytika.
• Nové platformy se vzdávají předagregací. Dynamické propojení surových zdrojů za letu – jediná cesta k matematicky přesné analytice.

Změna paradigmatu: analýza bez kompromisů

Klasické BI systémy jsou postaveny na iluzi: můžeme předem spočítat vše, co business potřebuje. V realitě – business neustále mění otázky. Místo psaní záplat v DAX moderní platformy pracují se surovými daty přímo. Například výpočet ukazatele „Zajištěnost zbožím" – poměr zůstatků k prodejům – může kombinovat dva různé zdroje: miliardy řádků zůstatků a miliardy řádků nákupů. Místo tvorby tuhého datového martu v DWH systém dynamicky propojuje zdroje při každém kliku uživatele a přepočítává metriku matematicky přesně. Jádro samo určuje časové koridory, hledá aktuální zůstatky a načte do paměti jen nutná data. To není „rychlejší", to je „správnější". Když manažeři banky poprvé viděli reálnou dobu zpracování žádostí – bez zkreslení z průměrování průměrů – začali klást správné otázky. Maloobchodní síť už nechce ztrácet smysl kvůli limitu 5 milionů řádků. Analýza má být RAW soubor, ne JPEG. Teprve tak lze zachovat detaily a možnost upravovat závěry. Technologie to umožňují – zbývá přestavět architekturu myšlení.

— Editorial Team