Dieser Beitrag beschreibt, wie wir bei einem Kunden die Cube-Umgebungen aufgesetzt haben. Dort verwenden wir – was seit einiger Zeit – möglich ist, Power BI Premium-Datasets als Cubes, wodurch wir uns Azure Analysis Services sparen können, der ja ein eher hochpreisiger Dienst ist.
Dieser Beitrag soll dabei nicht die Kriterien beschreiben, wann es sich in Bezug auf Kosten rechnet, sondern wie wir unter der Prämisse von Power BI Premium Datasets unsere Entwicklungs-, Test- und produktive Umgebungen aufgesetzt haben.
Im Backend haben wir dabei ein DWH und ETL-Routinen, die das DWH befüllen. Als Business Layer verwendeten wir immer Cubes, auf die dann mit Power BI zugegriffen wird. Zur Modellierung verwenden wir Visual Studio.
| Umgebung | Lösung | Besonderheit |
| Arbeitsbereichserver im Visual Studio | Azure Analysis Services | Den Dienst deaktivieren wir automatisch, um Kosten zu sparen (s. mein Blogeintrag) |
| Entwicklungsumgebung | Power BI Premium Datasets | User-bezogene Premium-Lizenzen |
| Testumgebung | Power BI Premium Datasets | User-bezogene Premium-Lizenzen |
| Produktivumgebung | Power BI Premium Datasets | Premium-Kapazität |
Wie man sieht, verwenden wir für die Entwicklungs- und Test-Umgebung user-bezogene Premium-Kapazitäten. Dies tun wir, da nur wenige Benutzer für die Entwicklungs- und Testumgebung zugreifen. Damit stellen wir sicher, dass diese Umgebungen nicht Ressourcen innerhalb der produkiven Kapazität nutzen, die dann der Produktion fehlen könnten.
Der Arbeitsbereichserver für die Entwicklungsumgebung ist ein Azure Analysis Services, weil man dort keine Power BI Premium Datasets verwenden kann (Dies lässt Visual Studio bzw. Power BI nicht zu). Da wir aber nicht ständig die Entwicklungsumgebung online benötigen, verwenden wir die Lösung aus meinem Blog-Beitrag, um die Umgebung täglich auszuschalten. Wenn wir entwickeln, müssen wir halt dann in der Früh den Azure Analysis-Services-Dienst manuell hochfahren. Mit diesem Vorgehen kostet der Azure Analysis Services – der auch sehr klein gesized ist – sehr wenig.
Theoretisch könnte man natürlich auch in der Entwicklungs- und Testumgebung genauso vorgehen. Dies widerspricht aber der grundsätzlichen Vorgehensweise, dass diese Systeme genauso aufgesetzt sein sollen wie das Produktivsystem.
Als Nebenbemerkung möchte ich noch erwähnen, dass wir als Power BI Premium Datasets alle Features verwenden konnten, die wir auch in Azure Analysis Services genutzt haben – bis auf Perspektiven: Verwendet man Azure Analysis Services-Cubes als Quelle eines Power BI Berichts, kann man dort eine Verbindung auf eine Perspektive einrichten, die dann als Dataset (mit Live-Verbindung zur AAS-Cube-Perspektive) existiert. Der Berichtersteller sieht dann nur die Attribute/Measures der Perspektive. Eine solche Option gibt es bei der Verwendung von Power BI Premium Datasets nicht.