Optimalizace datových sad a ukládání do mezipaměti

Výsledky dotazů na řídicí panely AI/BI ukládají do mezipaměti, aby se zlepšily doby načítání. Tato stránka vysvětluje, jak fungují optimalizace ukládání řídicích panelů do mezipaměti a datových sad, když řídicí panely používají výsledky uložené v mezipaměti a kdy znovu spouštět dotazy na SQL Warehouse.

Výkonnost dotazů

V historii dotazů pracovního prostoru můžete zkontrolovat dotazy a jejich výkon. V historii dotazů se zobrazují dotazy SQL prováděné pomocí služby SQL Warehouse. Klikněte na Historie dotazů na bočním panelu pro zobrazení historie dotazů Viz historie dotazů.

U datových sad řídicích panelů azure Databricks používá optimalizace výkonu v závislosti na velikosti výsledku datové sady. Informace o prahových hodnotách výkonu datové sady najdete v tématu Prahové hodnoty výkonu datové sady.

Optimalizace datových sad

Řídicí panely se optimalizují tak, že provádějí operace filtrování a agregace řízené filtry nebo nastavením vizualizace přímo v prohlížeči, pokud je to možné. Tyto optimalizace výkonu mají následující omezení:

Velikost datové sady	Chování zpracování
Malé (≤ 100 tisíc řádků a ≤ 100 MB)	Pokud chcete dosáhnout optimální rychlosti řídicího panelu, filtrování a agregace se spustí v prohlížeči po počátečním načtení datové sady. Vzhledem k tomu, že se tyto operace zpracovávají místně, samy o sobě se vyhýbají další interakci s datovým skladem a nezobrazují se v historii dotazů.
Velké (> 100 tisíc řádků nebo > 100 MB)	Filtrování a agregace se zpracovávají na back-endovém serveru místo v prohlížeči. Počáteční dotaz datové sady je zabalený v klauzuli SQL WITH a výsledný dotaz se zobrazí v historii dotazů.
Kombinované dotazy (velké datové sady)	U vizualizačních dotazů odesílaných do back-endu se samostatné dotazy vizualizace na stejnou datovou sadu, které sdílejí stejné GROUP BY klauzule a predikáty filtrů, zkombinují do jednoho dotazu pro zpracování. V tomto případě se uživatelům může zobrazit kombinovaný dotaz v historii dotazů, který načte výsledky pro více vizualizací nebo filtrů.

Poznámka:

Parametry nahrazují hodnoty přímo do dotazu za běhu, takže tyto operace se vždy zobrazují v historii dotazů.

Poznámka:

Stažení zkrácené tabulky spustí dotaz. Když se v tabulce zobrazí zkrácené výsledky, protože datová sada přesahuje 100 000 řádků, stahování dat jako csv spustí dotaz na SQL Warehouse. Tento dotaz se zobrazí v historii dotazů.

Ukládání do mezipaměti a aktuálnost dat

Řídicí panely udržují 24hodinovou mezipaměť výsledků pro optimalizaci počáteční doby načítání, která funguje na základě nejlepšího možného úsilí. To znamená, že zatímco se systém vždy pokouší použít historické výsledky dotazu propojené s přihlašovacími údaji řídicího panelu ke zvýšení výkonu, existují některé případy, kdy se výsledky uložené v mezipaměti nedají vytvářet ani udržovat. Data uložená v mezipaměti nemají žádný konkrétní limit paměti ani pevný počet dotazů.

Pokud chcete zkrátit dobu načítání, řídicí panely nejprve zkontrolují mezipaměť řídicího panelu. Pokud nejsou k dispozici žádné výsledky mezipaměti, zkontrolují obecnou mezipaměť výsledků dotazu. I když mezipaměť řídicího panelu může vrátit zastaralé výsledky po dobu až 24 hodin, mezipaměť výsledků dotazu nikdy nevrací zastaralá data. Když se podkladová data změní, všechny položky mezipaměti výsledků dotazu se zneplatní.

Poznámka:

Obsluha výsledků z mezipaměti řídicího panelu nespustí SQL Warehouse. Když řídicí panel vrací výsledky z mezipaměti, Azure Databricks čte z mezipaměti, aniž by spouštěl dotaz, takže podkladový SQL warehouse nemusí běžet. Sklad se spustí jenom v případech, kdy řídicí panel spustí dotaz, který mezipaměť nemůže obsluhovat.

U řídicích panelů s více stránkami platí následující:

• Při úpravě pracovní verze řídicího panelu se načtou a uloží do mezipaměti všechny datové sady.
• Když čtenáři otevřou publikovaný řídicí panel, spustí se a ukládají se do mezipaměti jenom datové sady, které podporují aktivní stránku.
• Pokud je nastavený plán, aktualizují se všechny datové sady podle plánu a tyto výsledky se ukládají do mezipaměti.

Následující tabulka vysvětluje, jak se ukládání do mezipaměti liší podle stavu a přihlašovacích údajů řídicího panelu:

Typ řídicího panelu	Typ ukládání do mezipaměti
Řídicí panel publikovaný s oprávněními pro sdílení dat	Sdílená mezipaměť. Všichni diváci vidí stejné výsledky.
Koncept řídicího panelu nebo řídicího panelu publikovaného s individuálními oprávněními k datům	Mezipaměť pro jednotlivé uživatele. Diváci vidí výsledky na základě svých oprávnění k datům.

Řídicí panely automaticky používají výsledky dotazu uložené v mezipaměti, pokud podkladová data zůstanou po posledním dotazu nezměněná nebo pokud se výsledky načetly před méně než 24 hodinami. Pokud na řídicím panelu existují zastaralé výsledky a použijí se parametry, dotazy se znovu spustí, pokud se v posledních 24 hodinách nepoužívaly stejné parametry. Podobně platí, že použití filtrů u datových sad přesahujících 100 000 řádků vyzve dotazy k opětovnému spuštění, pokud se v posledních 24 hodinách nepoužívaly stejné filtry.

Aktuální funkce časového razítka a zneplatnění mezipaměti

Použití current_timestamp() nebo podobných funkcí v dotazu SQL nezneplatní mezipaměť řídicího panelu. Tyto funkce však zneplatní mezipaměť výsledků dotazu, která kontroluje dotaz SQL a aktivuje aktualizaci mezipaměti.

Naplánované dotazy

Přidání plánu na řídicí panel publikovaný s oprávněními ke sdíleným datům může výrazně urychlit počáteční proces načítání pro všechny prohlížeče řídicích panelů.

Pro každou naplánovanou aktualizaci řídicího panelu dojde k následujícímu:

• Veškerá logika SQL, která definuje datové sady, se spouští v určeném časovém intervalu.
• Výsledky naplňují mezipaměť výsledků dotazu a pomáhají zlepšit čas počátečního načtení řídicího panelu.