Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
KI-/BI-Dashboards sind wertvolle Datenanalyse- und Entscheidungsfindungstools, und effiziente Ladezeiten können das Benutzererlebnis erheblich verbessern. In diesem Artikel wird erläutert, wie Cache- und Datasetoptimierungen Dashboards leistungsfähiger und effizienter gestalten.
Abfrageleistung
Sie können Abfragen und deren Leistung im Abfrageverlauf des Arbeitsbereichs untersuchen. Im Abfrageverlauf werden die mit SQL-Warehouses ausgeführten SQL-Abfragen angezeigt. Klicken Sie auf 
Abfrageverlauf in der Randleiste, um den Abfrageverlauf anzuzeigen. Weitere Informationen finden Sie unter Abfrageverlauf.
Bei Dashboard-Datasets wendet Azure Databricks Leistungsoptimierungen abhängig von der Ergebnisgröße des Datasets an. Informationen zu Schwellenwerten für die Datasetleistung finden Sie unter Schwellenwerte für die Datasetleistung.
Datasetoptimierungen
Ihre Dashboards optimieren die Geschwindigkeit, indem Sie Filter- und Aggregationsvorgänge ausführen, gesteuert durch Filter oder Visualisierungseinstellungen, direkt in Ihrem Browser, wenn möglich. Diese Leistungsoptimierungen weisen die folgenden Grenzwerte auf:
| Datasetgröße | Verarbeitungsverhalten |
|---|---|
| Klein (≤ 100K Zeilen und ≤ 100 MB) | Um eine optimale Dashboardgeschwindigkeit zu erhalten, werden Filter und Aggregation nach dem Laden des anfänglichen Datasets in Ihrem Browser ausgeführt. Da diese Vorgänge lokal verarbeitet werden, vermeiden sie eine weitere Interaktion mit dem Data Warehouse und werden nicht im Abfrageverlauf angezeigt. |
| Groß (> 100K Zeilen oder > 100 MB) | Filterung und Aggregation werden auf dem Back-End-Server anstelle in Ihrem Browser behandelt. Die erste Datasetabfrage wird in eine SQL-Klausel WITH eingeschlossen, und die resultierende Abfrage wird im Abfrageverlauf angezeigt. |
| Kombinierte Abfragen (große Datasets) | Für Visualisierungsanfragen, die an das Backend gesendet werden, werden separate Abfragen gegen dasselbe Dataset, die dieselben GROUP BY-Klauseln und Filterprädikate verwenden, zu einer einzigen Abfrage zusammengefasst, um sie zu verarbeiten. In diesem Fall wird Benutzern möglicherweise eine kombinierte Abfrage im Abfrageverlauf angezeigt, die Ergebnisse für mehrere Visualisierungen oder Filter abruft. |
Hinweis
Parameter ersetzen Werte direkt zur Laufzeit in einer Abfrage, sodass diese Vorgänge immer im Abfrageverlauf angezeigt werden.
Zwischenspeicherung und Aktualität von Daten
Dashboards verwalten einen 24-Stunden-Ergebniscache, um die anfänglichen Ladezeiten zu optimieren. Dabei wird das Prinzip der bestmöglichen Leistung angewandt. Das System versucht daher zwar immer, historische Abfrageergebnisse in Verbindung mit Dashboardanmeldeinformationen zu verwenden, um die Leistung zu verbessern, es gibt jedoch einige Fälle, in denen zwischengespeicherte Ergebnisse nicht erstellt oder verwaltet werden können. Zwischengespeicherte Daten verfügen nicht über ein bestimmtes Speicherlimit oder eine feste Abfrageanzahl.
Um ladezeiten zu verbessern, überprüfen Dashboards zuerst den Dashboardcache. Wenn keine Cacheergebnisse verfügbar sind, überprüfen sie den generischen Abfrageergebniscache. Während der Dashboardcache veraltete Ergebnisse für bis zu 24 Stunden zurückgeben kann, gibt der Abfrageergebniscache niemals veraltete Daten zurück. Wenn sich die zugrunde liegenden Daten ändern, werden alle Abfrageergebniscacheeinträge ungültig.
Bei mehrseitigen Dashboards gilt Folgendes:
- Beim Bearbeiten eines Entwurfsdashboards werden alle Datasets geladen und zwischengespeichert.
- Wenn Viewer ein veröffentlichtes Dashboard öffnen, werden nur Datasets ausgeführt und zwischengespeichert, die die aktive Seite unterstützen.
- Wenn ein Zeitplan festgelegt ist, werden alle Datasets entsprechend dem Zeitplan aktualisiert, und diese Ergebnisse werden zwischengespeichert.
In der folgenden Tabelle wird erläutert, wie die Zwischenspeicherung je nach Dashboardstatus und Anmeldeinformationen variiert:
| Dashboard-Typ | Cachingtyp |
|---|---|
| Ein Dashboard, das mit freigegebenen Datenerlaubnissen veröffentlicht wurde. | Gemeinsamer Cache Alle Betrachter sehen dieselben Ergebnisse. |
| Entwurfs-Dashboard oder veröffentlichtes Dashboard mit individuellen Datenberechtigungen | Cache pro Benutzer. Betrachter sehen Ergebnisse basierend auf ihren Datenberechtigungen. |
Dashboards verwenden automatisch zwischengespeicherte Abfrageergebnisse, wenn die zugrunde liegenden Daten nach der letzten Abfrage unverändert bleiben oder die Ergebnisse vor weniger als 24 Stunden abgerufen wurden. Wenn veraltete Ergebnisse vorhanden sind und Parameter auf das Dashboard angewandt wurden, werden Abfragen erneut ausgeführt, sofern nicht dieselben Parameter in den letzten 24 Stunden verwendet wurden. Ebenso fordert das Anwenden von Filtern auf Datasets, die mehr als 100.000 Zeilen überschreiten, eine erneute Ausführung der Abfragen an, sofern nicht dieselben Filter in den letzten 24 Stunden zuvor angewandt wurden.
Aktuelle Zeitstempelfunktionen und Cache-Invalidierung
Die Verwendung von current_timestamp() oder ähnlichen Funktionen in Ihrer SQL-Abfrage hebt den Cache auf der Dashboard-Ebene nicht auf. Diese Funktionen können jedoch den Abfrageergebniscache ungültig machen, wodurch die SQL-Abfrage überprüft und eine Cacheaktualisierung ausgelöst wird.
Geplante Abfragen
Das Hinzufügen eines Zeitplans zu einem Dashboard, das mit freigegebenen Datenberechtigungen veröffentlicht wurde, kann den anfänglichen Ladevorgang für alle Dashboard-Viewer erheblich beschleunigen.
Für jedes geplante Dashboard-Update geschieht Folgendes:
- Alle SQL-Logik, die Datasets definiert, wird im festgelegten Zeitintervall ausgeführt.
- Ergebnisse füllen den Abfrageergebniscache und helfen, die anfängliche Ladezeit des Dashboards zu verbessern.