Optimalisatie en caching van gegevenssets

AI/BI-dashboards zijn waardevolle hulpprogramma's voor gegevensanalyse en besluitvorming, en efficiënte laadtijden kunnen de gebruikerservaring aanzienlijk verbeteren. In dit artikel wordt uitgelegd hoe caching en gegevenssetoptimalisaties dashboards efficiënter en efficiënter maken.

Queryprestaties

U kunt query's en hun prestaties inspecteren in de querygeschiedenis van de werkruimte. In de querygeschiedenis ziet u SQL-query's die worden uitgevoerd met behulp van SQL Warehouses. Klik op Querygeschiedenis in de zijbalk om de querygeschiedenis weer te geven. Bekijk de querygeschiedenis.

Voor dashboardgegevenssets past Azure Databricks prestatieoptimalisaties toe, afhankelijk van de resultaatgrootte van de gegevensset.

Optimalisaties van gegevenssets

AI/BI-dashboardgegevenssets bevatten de volgende prestatieoptimalisaties:

• Als de resultaatgrootte van de gegevensset klein is (kleiner dan of gelijk aan 100.000 rijen of 100 MB, afhankelijk van wat kleiner is), wordt het resultaat van de gegevensset naar de client gehaald en worden visualisatiespecifieke filters en aggregatie uitgevoerd in de browser. Het filteren en samenvoegen van gegevens voor kleine gegevenssets is zeer snel en zorgt ervoor dat uw gegevensset klein is, zodat u de dashboardprestaties kunt optimaliseren. Met kleine gegevenssets wordt alleen de gegevenssetquery weergegeven in de querygeschiedenis.
• Als de resultaatgrootte van de gegevensset groot is (groter dan 100.000 rijen of 100 MB), wordt de querytekst van de gegevensset verpakt in een SQL-component WITH en wordt de visualisatiespecifieke filtering en aggregatie uitgevoerd in een query op de back-end in plaats van in de browser. Bij grote gegevenssets wordt de visualisatiequery weergegeven in de querygeschiedenis.
• Voor visualisatiequery's die naar de back-end worden verzonden, worden afzonderlijke visualisatiequery's voor dezelfde gegevensset die dezelfde GROUP BY componenten delen en filterpredicaten gecombineerd tot één query voor verwerking. In dit geval zien gebruikers mogelijk één gecombineerde query in de querygeschiedenis die resultaten voor meerdere visualisaties ophaalt.

Cache en nieuwheid van gegevens

Dashboards onderhouden een resultatencache van 24 uur om de initiële laadtijden te optimaliseren, op basis van best effort. Dit betekent dat hoewel het systeem altijd probeert historische queryresultaten te gebruiken die zijn gekoppeld aan dashboardreferenties om de prestaties te verbeteren, er enkele gevallen zijn waarin resultaten in de cache niet kunnen worden gemaakt of onderhouden.

In de volgende tabel wordt uitgelegd hoe caching verschilt per dashboardstatus en referenties:

Type dashboard	Cachetype
Gepubliceerd dashboard met ingesloten referenties	Gedeelde cache. Alle kijkers zien dezelfde resultaten.
Conceptdashboard of gepubliceerd dashboard zonder ingesloten referenties	Per gebruikerscache. Kijkers zien resultaten op basis van hun gegevensmachtigingen.

Dashboards gebruiken automatisch queryresultaten in de cache als de onderliggende gegevens ongewijzigd blijven na de laatste query of als de resultaten minder dan 24 uur geleden zijn opgehaald. Als er verouderde resultaten bestaan en parameters worden toegepast op het dashboard, worden query's opnieuw uitgevoerd, tenzij dezelfde parameters zijn gebruikt in de afgelopen 24 uur. Op dezelfde manier vraagt het toepassen van filters op gegevenssets die meer dan 100.000 rijen bevatten, query's om opnieuw uit te worden uitgevoerd, tenzij dezelfde filters eerder zijn toegepast in de afgelopen 24 uur.

Geplande query's

Het toevoegen van een planning aan een gepubliceerd dashboard met ingesloten referenties kan het eerste laadproces voor alle dashboardviewers aanzienlijk versnellen.

Voor elke geplande dashboardupdate vindt het volgende plaats:

• Alle SQL-logica die gegevenssets definieert, wordt uitgevoerd op het aangewezen tijdsinterval.
• Resultaten vullen de cache voor queryresultaten en helpen bij het verbeteren van de laadtijd van het dashboard.