Teilen über

Festlegen der Größe des lokalen Datengateways

  • Artikel

Dieser Artikel richtet sich an Power BI-Administratoren, die das lokale Datengateway installieren und verwalten müssen.

Das Gateway ist immer dann erforderlich, wenn Power BI Zugriff auf Daten benötigt, die nicht direkt über das Internet zugänglich sind. Die Installation kann entweder auf einem lokalen Server oder in einem VM-gehosteten IaaS-Dienst (Infrastructure-as-a-Service) erfolgen.

Gatewayworkloads

Das lokale Datengateway unterstützt zwei Workloads. Es ist wichtig, dass Sie diese verstehen, bevor Sie sich mit der Gatewaygröße und den Empfehlungen beschäftigen.

Workload des Typs „Zwischengespeicherte Daten“

Die Arbeitsauslastung für zwischengespeicherte Daten ruft Quelldaten zum Laden in Power BI-Semantikmodelle ab und wandelt sie um. Dies erfolgt in drei Schritten:

  1. Verbindung: Das Gateway stellt eine Verbindung mit den Quelldaten her.
  2. Datenabruf und Transformation: Die Daten werden abgerufen und bei Bedarf transformiert. Wenn möglich überträgt die Power Query-Mashup-Engine Transformationsschritte mithilfe von Push zur Datenquelle. Dieser Vorgang wird als Query Folding bezeichnet. Wenn dies nicht möglich ist, müssen die Transformationen vom Gateway durchgeführt werden. In diesem Fall verbraucht das Gateway mehr CPU- und Arbeitsspeicherressourcen.
  3. Übertragung: Die Daten werden an den Power BI-Dienst übertragen. Dabei ist besonders für große Datenvolumen eine zuverlässige und schnelle Internetverbindung entscheidend.

Diagramm zu zwischengespeicherten Daten, in dem dargestellt wird, wie das lokale Datengateway mit lokalen Quellen verbunden ist

Workloads des Typs „Liveverbindung und DirectQuery“

Die Workload des Typs Liveverbindung und DirectQuery funktioniert größtenteils im Pass-Through-Modus. Der Power BI-Dienst sendet Abfragen, und das Gateway antwortet mit Abfrageergebnissen. Abfrageergebnisse sind allgemein eher klein.

Diese Workload benötigt CPU-Ressourcen für das Routing von Abfragen und Abfrageergebnissen. Normalerweise ist die CPU-Auslastung sehr viel geringer als für Workloads des Typs „Zwischengespeicherte Daten“. Dies gilt vor allem dann, wenn Daten für die Zwischenspeicherung transformiert werden müssen.

Eine zuverlässige, schnelle und gleichmäßige Verbindung ist wichtig, damit Benutzer von Berichten optimal damit arbeiten können.

Diagramm zu Liveverbindung und DirectQuery, in dem dargestellt wird, wie das lokale Datengateway mit lokalen Quellen verbunden ist

Überlegungen zur Größe

Das Festlegen der korrekten Größe für Ihren Gatewaycomputer kann von den folgenden Faktoren abhängen:

  • Bei Workloads des Typs „Cachedaten”:
    • Die Anzahl der gleichzeitigen Aktualisierungen des semantischen Modells
    • Typen von Datenquellen (relationale Datenbank, Analysedatenbank, Datenfeeds oder Dateien)
    • Datenvolumen, das aus Datenquellen abgerufen werden soll
    • alle Transformationen, die von der Power Query-Mashup-Engine ausgeführt werden müssen
    • Datenvolumen, das an den Power BI-Dienst übertragen werden soll
  • Bei Workloads des Typs „Liveverbindung” und „DirectQuery”:
    • Anzahl von Benutzern, die den Bericht gleichzeitig verwenden
    • Anzahl der Visuals auf den Berichtsseiten (jedes Visual sendet mindestens eine Abfrage)
    • Häufigkeit, mit der der Abfragecache des Power BI-Dashboards aktualisiert wird
    • Anzahl von Echtzeitberichten, die das Feature Automatische Seitenaktualisierung verwenden
    • Gibt an, ob semantische Modelle Sicherheit auf Zeilenebene (RLS) erzwingen

Im Allgemeinen erfordern Workloads des Typs „Liveverbindung und DirectQuery“ ausreichend CPU, während Workloads des Typs „Zwischengespeicherte Daten“ mehr CPU und Arbeitsspeicher benötigen. Beide Workloads benötigen sowohl zum Power BI-Dienst als auch zu den Datenquellen gute Konnektivität.

Hinweis

Die Kapazitäten von Power BI verursachen Limits für den Parallelismus der Modellaktualisierung, die Liveverbindung und den DirectQuery-Durchsatz. Es ist zwecklos, für Ihre Gateways eine Größe festzulegen, die die vom Power BI-Dienst unterstützte Größe übersteigt. Limits variieren je nach Premium-SKU (und gleichgroßen A-SKUs). Weitere Informationen finden Sie unter Microsoft Fabric-Kapazitätslizenzen und Was ist Power BI Premium? (Kapazitätsknoten).

Wichtig

Manchmal bezieht sich dieser Artikel auf Power BI Premium oder seine Kapazitätsabonnements (P-SKUs). Beachten Sie, dass Microsoft derzeit Kaufoptionen konsolidiert und die SKUs von Power BI Premium pro Kapazität einstellt. Neue und vorhandene Kunden sollten stattdessen den Kauf von Fabric-Kapazitätsabonnements (F-SKUs) in Betracht ziehen.

Weitere Informationen finden Sie unter Wichtige Updates zur Power BI Premium-Lizenzierung und Häufig gestellte Fragen zu Power BI Premium.

Empfehlungen

Die Empfehlungen für Gatewaygrößen hängen von vielen Faktoren ab. In diesem Abschnitt erhalten Sie allgemeine Empfehlungen, die Ihnen bei der Entscheidung helfen können.

Anfängliche Größeneinstellung

Es kann sehr schwierig sein, die richtige Größe korrekt einzuschätzen. Es wird empfohlen, mit einem Computer mit mindestens 8 CPU-Kernen, 8 GB RAM und mehreren Gigabit an Netzwerkadaptern zu beginnen. Anschließend können Sie eine typische Gatewayworkload messen, indem Sie die Systemzähler für die CPU und den Arbeitsspeicher protokollieren. Weitere Informationen finden Sie unter Überwachen und Optimieren der Leistung des lokalen Datengateways.

Konnektivität

Schaffen Sie von vornherein die besten Voraussetzungen für die bestmögliche Konnektivität zwischen dem Power BI-Dienst und Ihrem Gateway sowie zwischen dem Gateway und den Datenquellen.

  • Bemühen Sie sich um Zuverlässigkeit, Schnelligkeit und eine niedrige, gleichmäßige Latenz.
  • Eliminieren (oder reduzieren) Sie Computerhops zwischen dem Gateway und Ihren Datenquellen.
  • Entfernen Sie alle Netzwerkeinschränkungen, die von Ihrer Firewallproxyschicht verursacht werden. Weitere Informationen zu Power BI-Endpunkten finden Sie unter Hinzufügen von Power BI-URLs zu Ihrer Zulassungsliste.
  • Konfigurieren Sie Azure ExpressRoute, um private, verwaltete Verbindungen zu Power BI herzustellen.
  • Stellen Sie für Datenquellen auf Azure-VMs sicher, dass sich die VMs in derselben Region wie der Power BI-Dienst befinden.
  • Stellen Sie sicher, dass bei Workloads des Typs „Liveverbindung” zu SQL Server Analysis Services (SSAS) mit dynamischer Sicherheit auf Zeilenebene (RLS) eine gute Verbindung zwischen dem Gatewaycomputer und dem lokalen Active Directory-Dienst besteht.

Clustering

Bei umfangreichen Bereitstellungen können Sie ein Gateway mit mehreren Clustermitgliedern erstellen. Mit Clustern lassen sich Single Points of Failure vermeiden. Außerdem können Sie einen gatewayübergreifenden Lastenausgleich für den Datenverkehr vornehmen. Sie können Folgendes ausführen:

  • Installieren von mindestens einem Gateway in einem Cluster
  • Auslagern von Workloads in eigenständige Gateways oder Cluster von Gatewayservern

Weitere Informationen finden Sie unter Verwalten von Clustern mit hoher Verfügbarkeit und Lastenausgleich für das lokale Datengateway.

Entwurf und Einstellungen für semantische Modelle

Der Entwurf und die Einstellungen eines semantischen Modells können Auswirkungen auf Gatewayworkloads haben. Sie können die folgende Maßnahmen ergreifen, um die Gatewayworkload zu reduzieren.

Für den Import von semantischen Modellen:

  • Richten Sie eine weniger häufige Datenaktualisierung ein.
  • Richten Sie eine inkrementelle Aktualisierung ein, um die zu übertragende Datenmenge zu minimieren.
  • Stellen Sie sicher, dass nach Möglichkeit Query Folding angewendet wird.
  • Vor allem bei großen Datenmengen oder einem Bedarf an geringer Latenz sollten Sie den Entwurf in ein DirectQuery-Modell oder ein zusammengesetztes Modell konvertieren.

Für DirectQuery-semantische Modelle:

  • Optimieren Sie die Datenquellen, Modelle und Berichtsentwürfe. Weitere Informationen finden Sie unter Leitfaden für das DirectQuery-Modell in Power BI Desktop.
  • Erstellen Sie Aggregationen, um allgemeine Ergebnisse zwischenzuspeichern und so die Anzahl von DirectQuery-Anforderungen zu reduzieren.
  • Schränken Sie die Intervalle für die automatische Seitenaktualisierung in Berichtsentwürfen und den Kapazitätseinstellungen ein.
  • Schränken Sie die Aktualisierungshäufigkeit des Dashboardcaches vor allem dann ein, wenn die dynamische Sicherheit auf Zeilenebene erzwungen wird.
  • Konvertieren Sie den Entwurf vor allem bei kleineren Datenmengen oder permanenten Daten in ein importiertes oder ein zusammengesetztes Modell.

Für Liveverbindung-semantische Modelle:

  • Schränken Sie die Aktualisierungshäufigkeit des Dashboardcaches vor allem dann ein, wenn die dynamische Sicherheit auf Zeilenebene erzwungen wird.

Zugehöriger Inhalt

Weitere Informationen zu diesem Artikel finden Sie in den folgenden Ressourcen: