VertiPaq engine a optimalizace velikosti modelu
Cíle kapitoly
- Pochopit, jak VertiPaq ukládá data — column store princip
- Znát kompresní algoritmy: Dictionary Encoding, Value Encoding, Run Length Encoding
- Rozumět rozdílu mezi Storage Engine a Formula Engine
- Vybrat správné datové typy pro minimální velikost
- Identifikovat a řešit problémy s kardinalitou a zbytečnými sloupci
VertiPaq Column Store — architektura
VertiPaq není tradiční řádkový storage (jako SQL Server). Je to column store — data se ukládají po sloupcích, nikoli po řádcích.
Výhody column store pro BI
- Lepší komprese: Podobné hodnoty jsou vedle sebe → lepší komprese
- Rychlejší agregace: SUM(Cost) čte jen sloupec Cost
- Menší paměť: Typicky 5-10x menší než row store
Kompresní algoritmy v VertiPaq
Dictionary Encoding
Nejčastější komprese pro text. Místo "Europe" se uloží index 1.
Kardinalita — klíčový faktor
| Sloupec | Kardinalita | Komprese |
|---|---|---|
| Region | 3 | 95%+ |
| CustomerID | 1 000 000 | 60-70% |
| GUID | 10 000 000 | Bez komprese |
Run Length Encoding (RLE)
Velmi efektivní pro seřazená data. Místo [1,1,1,1,2,2,3,3,3] se zapíše [(1,4x), (2,2x), (3,3x)].
Storage Engine vs. Formula Engine
Storage Engine (SE)
- Čte data z VertiPaq, dekomprimuje, filtruje segmenty
- Vícevláknový — zpracovává paralelně
- Velmi rychlý — miliony řádků za sekundu
Formula Engine (FE)
- Interpretuje DAX, volá SE
- Jednovláknový — úzké hrdlo!
- Pomalejší — desítky tisíc řádků za sekundu
Praktické důsledky
- SUM() je rychlé — SE vrátí agregát, FE jen sečte
- SUMX() je pomalé — iteruje přes řádky (FE jednotlivě volá SE v každé iteraci)
- Filtr v CALCULATE → SE se podílí, pokud je jednoduchý
Vliv datových typů na velikost modelu
Výběr správného typu šetří obrovské procento paměti. Zde je průvodce:
| Typ | Velikost | Kdy je ideální | Kdy NIKDY |
|---|---|---|---|
| Whole Number | 8 bajtů (Int64) | Počty, ID — VertiPaq zkrátí bitový rozsah přes Value Encoding | Velké ID, GUID |
| Fixed Decimal | 8 bajtů | Ceny, procenta | Agregace (vyrovnávací chyby) |
| Decimal Number | 8 bajtů (IEEE 754 double) | Ceny, procenta s desetinnými místy | Normální finanční data — stejná přesnost jako Fixed Decimal |
| Text | Variabilní (Dictionary) | Slova, jména | GUID jako text |
| Date/Time | 4 bajty (datum), 8 (datetime) | Normální data | Textové řetězce místo datumů |
| Boolean | 1 bajt | Ano/Ne příznaky | Textové "Y"/"N" |
Největší nepřítelé modelu
Problem: GUID má 128 bitů (16 bajtů). Každá hodnota je unikátní → Dictionary Encoding prakticky nefunguje.
Řešení: Používejte Whole Number (integer) pro ID namísto GUID. Pokud musíte mít GUID, skryjte ho (hid property) nebo ho úplně odstraňte, pokud se nepoužívá v DAXu.
Příklad: ProductKey je uložen jako "PROD_001" místo 1.
Dopady: Text se komprimuje hůře, obsazuje více místa (Dictionary je větší).
Řešení: Používejte Integer klíče, text vraťte v lookup tabulkách.
Příklad: Sloupec "FullDescription" (1 milión unikátních hodnot) se nikdy nepoužívá v DAXu.
Řešení: Odstraňte ho nebo ho skryjte z modelu (Hide = True). Power BI stále umožňuje odkazovat se na něj v Power Query, ale nebude součástí modelu.
Praktické optimalizace — Vertipaq Analyzer
Vertipaq Analyzer — nástroj
Doplněk do Excel/Power BI Desktop, který čte model a ukazuje, kde se paměť marní.
VertiPaq Analyzer je zabudován přímo do DAX Studio. Otevřete Power BI Desktop → External Tools → DAX Studio → záložka VertiPaq Analyzer.
Stáhněte z sqlbi.com/tools/vertipaq-analyzer (autoři: SQLBI / Daniele Perilli). Připojte Excel soubor přes XMLA endpoint k vašemu modelu.
Sloupce seřazené po paměti. Vidíte kardinalitu, typ komprese, zda je skrytý.
Co hledat v Vertipaq Analyzeru
- Sloupce s vysokou paměť a vysokou kardinalitou: Hledejte kandidáty na odstranění
- Text sloupce s hodnotami jako čísla: Změňte na Integer
- GUID sloupce: Odstraňte, pokud není kritické
- Sloupce s "no compression" (0% komprese): Téměř určitě je to GUID nebo vysoce kardinální sloupec
Identifikace problémů — Checklist
- Spusťte Vertipaq Analyzer
- Najděte top 10 sloupců po paměti
- Zjistěte jejich kardinalitu a typ
- Pokud je kardinalita > 50% počtu řádků, zvažte odstranění
- Storage Engine čte moc dat
- Možné příčiny: Filtr tabulka s vysokou kardinalitou, chybějící agregace
- Řešení: Přidejte Aggregations nebo lepší kardinalitu