Storage Engine – jeho role při optimalizaci dotazů DAX v LuckyTemplates

V tomto tutoriálu se podíváme na druhý motor uvnitř analytických služeb – modul úložiště.

Diskutovali jsme o motoru nejvyšší úrovně, v minulém tutoriálu. Když uživatelé pochopí, jak oba tyto motory fungují, je snazší optimalizovat a zlepšit výkon vašich dotazů DAX.

Hlavním účelem úložiště je pracovat přímo s databází.

Modul vzorce nemá přímý přístup k databázi, takže za tímto účelem normálně prochází modulem úložiště.

Úložný modul je k dispozici ve dvou typech – režim importu a DirectQuery . Oba typy můžete kombinovat a porovnávat ve stejném datovém modelu a vytvořit tak složený model.

Obsah

• Práce s režimem importu v modulu úložiště
• Práce s DirectQuery v Storage Engine
• Práce s kompozitními modely
• Další kritické body o Storage Engine
• Práce na složitých dotazech
• Závěr

Práce s režimem importu v modulu úložiště

Nejprve si promluvme o režimu importu. To je také běžněji známé jako Vertipaq, ale také se nazývá xVelocity nebo sloupcová databáze v paměti.

Existují čtyři důležité věci, které je třeba pochopit, jak režim importu funguje.

Nejprve Vertipaq vytvoří kopii dat přímo ze zdroje dat a uloží je do paměti RAM v komprimovaném formátu .

Za druhé, data zpracovaná v režimu importu jsou založena na poslední operaci obnovení . To znamená, že pokud jste naposledy obnovovali svá data minulý týden, pak data, se kterými pracujete, jsou stále stejná data z minulého týdne. To je zvláště důležité, pokud používáte složené nastavení, kde jedna tabulka je v režimu importu a druhá tabulka je v režimu DirectQuery.

Řekněme, že máte tabulku Produkty, která byla aktualizována minulý týden, v režimu importu. Pokud jde o tabulku Prodej, rozhodli jste se ji kursovat prostřednictvím DirectQuery kvůli její velikosti. Předpokládejme také, že sestavu vytváříte na základě obou tabulek, do kterých přidáváte sloupec Značka a vytváříte míru celkového prodeje nad stejnou tabulkou Prodej. Chcete také vizualizovat částku prodeje na základě značky.

Nejprve byste museli obnovit data pocházející z režimu importu, protože byste mohli skončit s čerstvými a aktualizovanými daty z DirectQuery a zastaralými daty z Vertipaq. Na vaší matici a vaší vizualizaci tak zůstane několik prázdných řádků.

Další věc, kterou potřebujete vědět o Vertipaq je, že pouze základní operace jako , , nebo jsou nativně dostupné . To znamená, že pokud jsou v plánu dotazů zahrnuty další komplikovanější operace, úložný modul by musel zavolat modul vzorců, aby tuto část kódu vyřešil.

A konečně, storage engine je vysoce optimalizovaná databáze díky sloupcové struktuře Vertipaq . To znamená, že všechna data se ukládají sloupec po sloupci, nikoli řádek po řádku. Díky této struktuře bude Vertipaq vždy rychlejší než připojení DirectQuery, i když vytvoříte indexy ve svém relačním datovém modelu.

Práce s DirectQuery v Storage Engine

Další možností, kterou máme v rámci analytických služeb LuckyTemplates, je DirectQuery. Pokud používáte připojení DirectQuery, analytické služby fungují pouze jako průchozí pro dotazy, které odesílá modul vzorců.

Řekněme, že napíšete dotaz. Stroj vzorců vygeneruje plán dotazů. Poté předá dotaz do úložiště, již přeložený do rodného jazyka databáze. Většinu času tyto dotazy přicházejí v SQL.

Pokud dotaz používá DirectQuery, očekávejte, že bude neustále aktuální. Není třeba se starat o to, kdy jste naposledy obnovili data.

Proces optimalizace kódu DAX a datového modelu bude také záviset na tom, jak byla vytvořena relační databáze. Pokud máte ve sloupcích indexy, budou vaše dotazy vždy optimalizovány. Pokud však vaše databáze není optimalizována z hlediska vytváření sestav pomocí analytických služeb nebo LuckyTemplates, můžete čelit několika problémům s výkonem. Při vytváření svých databází pro vývoj sestav buďte tedy záměrní.

Práce s kompozitními modely

Třetí možností je vytvořit složený model, abyste mohli mít jednu tabulku v režimu importu a další tabulku v DirectQuery.

Když použijete dvě tabulky z různých zdrojů, modul vzorců odešle jeden požadavek do Vertipaq a další požadavek do zdroje dat DirectQuery. V obou případech analytické služby také načtou datovou mezipaměť z Vertipaq a DirectQuery. Motor formule pak použije JOIN,nebo jakoukoli iteraci v obou mezipaměti dat před poskytnutím výsledků koncovému uživateli.

Řekněme tedy, že se ve své zprávě snažíte vizualizovat objem prodeje podle značky produktu. Motor vzorce odešle požadavek společnosti Vertipaq, kde načte produkt, značku a produktový klíč. Poté se z DirectQuery pokusí načíst prodej, čistou cenu, prodejní množství a prodejní produktový klíč.

Jakmile má dvě datové mezipaměti založené na produktovém klíči, spojí dvě datové mezipaměti a vypočítá celkovou částku prodeje. Výsledky pak představí koncovému uživateli.

Další kritické body o Storage Engine

Nyní, když jsme probrali jeho různé typy, existuje několik dalších kritických faktorů, které potřebujete vědět o úložišti, aby vám pomohly optimalizovat vaše dotazy DAX.

Jak jsem již zmínil dříve, úložný modul poskytuje datovou mezipaměť zpět do vzorce ve formě nekomprimované datové mezipaměti. Když jste v režimu importu, požadavek, který je během procesu odeslán zpět do Vertipaq, je proveden v jazyce xmSQL.

Jazyk xmSQL je trochu podobný SQL, ale není úplně stejný. O xmSWL budeme hovořit podrobně, když mluvíme o plánech dotazů v jiném tutoriálu.

Je také důležité pamatovat na to, že úložiště využívá všechna jádra dostupná ve vašem CPU. Možnost používat více jader je výhodná v případě, že máte v datovém modelu více segmentů.

Řekněme, že máte tabulku v LuckyTemplates s 12 miliony řádků. Tato tabulka bude poté rozdělena na 12 segmentů, protože v Power Pivot i LuckyTemplates se každý segment vejde na 1 milion řádků. To je na rozdíl od analytických služeb obecně, kde jeden segment pojme 8 milionů řádků.

Pokud tedy mám v CPU šest jader, všech šest jader bude skenovat prvních šest z 12 segmentů současně. Jakmile budou hotovi, přejdou na dalších šest segmentů.

Ale pokud pracuji s analytickými službami, kde výchozí segment obsahuje 8 milionů řádků, použijí se pouze dvě z mých šesti jader – jeden segment zpracuje 8 milionů řádků, zatímco druhý zpracuje 4 miliony.

Práce na složitých dotazech

Již dříve jsem zmínil, že režim importu podporuje pouze základní operace jako MIN, MAX, SUM, COUNT a GROUPBY. Co se tedy stane, když budete pracovat na složitějších dotazech?

Řekněme, že se rozhodnete použít příkaz IF v kontextu řádku nebo vnořenou iteraci jako SUMX nad tabulkami Products a Sales.

V tomto případě nebude modul úložiště schopen vyřešit dotaz sám. Poté zavolá vzorec vzorců, který začne řešit složitý výpočet řádek po řádku uvnitř úložiště. Někteří si mohou myslet, že je to příznivý scénář, kdy oba motory spolupracují – ale to je daleko od pravdy.

Vidíte, když k tomu dojde, mezipaměť dat vytvořená modulem úložiště nelze uložit do mezipaměti v případě, že v tomto konkrétním dotazu je callbackdataID. Pokud tedy aktualizujete vizuál, stejný výpočet bude muset provést jak modul vzorců, tak modul úložiště, i když jste před několika sekundami provedli stejný dotaz. To povede ke zpoždění výkonu a špatné uživatelské zkušenosti.

Všimněte si také, že modul úložiště neví, zda byly dotazy provedeny pomocí jazyka DAX nebo MDX. Jak jsme již zmínili dříve, úkolem vzorce je převést dotazy do správného jazyka před předáním plánu dotazů.

Nakonec modul vzorce odesílá dotazy do úložiště jeden po druhém. To znamená, že mít více segmentů je skutečně lepší, takže celková doba skenování v rámci Vertipaq může být zkrácena, přičemž je skenováno více segmentů současně.

Závěr

Pochopení spletitých prvků úložiště skutečně pomáhá při optimalizaci vašich dotazů DAX, zejména pokud používáte DAX Studio. Pokud jste také prošli výukovým programem vysvětlujícím modul vzorců, můžete se lépe rozhodovat, jak vytvářet výkonnější dotazy.

Přestože motor formule slouží jako motor nejvyšší úrovně, není pochyb o tom, že nemůže fungovat tak dobře, jak by mohl, pokud oba motory nemaximalizujeme.

Vše nejlepší,