Es gibt viele unterschiedliche Paradigmen, wie und warum man die Daten für eine BI Anwendung mit Tableau so oder so aufbereiten und speichern soll. Embedded oder Live Connection, Tableau PREP oder ein externes ETL Tool und so weiter. Natürlich entscheidet letztlich der konkrete Anwendungsfall über die finale Ausgestaltung der Lösung. Jedoch ist unser persönlicher Favorit in den meisten Fällen eine Kombination aus Tableau + MS SQL Server.
Warum Tableau + MS SQL Server?
Die Kombination aus Tableau und Datenbank-Server bietet aus unserer Sicht 3 wesentliche Vorteile, die in den Bereichen
liegen. Lassen Sie uns nun einen Blick auf die einzelnen Teilbereiche werfen.
Security mit Tableau + MS SQL Server
In den meisten BI-Anwendungen gehen wir mit sensiblen Daten um. Deshalb ist Data-Security immer ein wichtiges Thema. Wir müssen uns also überlegen, wo wir den Sercurity-Layer anlegen.
Security in Tableau
Eine Möglichkeit ist, diesen direkt in Tableau zu implementieren. Die Konfiguration erfolgt dabei über ACL’s (Access Configuration Lists), die in Windows angelegt und gepflegt werden. Genauer gesagt im sogenannten „Active Directory“.
Diese Lösung hat jedoch eine Reihe von Problemen. Zum Einen muss für jedes mögliche Teilpaket an Daten, für die ein Benutzer / eine Benutzerin Zugriff im Dashboard habe soll, eine eigene ACL angelegt werden. Das kann (und wird) sehr schnell unübersichtlich. Wir haben Projekte erlebt, bei denen mit mehreren Hundert!!!! ACL’s gearbeitet wurde. Dabei geht fast zwangsläufig der Überblick verloren und man legt bei Zugriffsanfragen einfach eine weitere Gruppe an, da es in diesem Wust schlicht unmöglich ist, heraus zu finden, ob es bereits eine passende gibt oder nicht.
Zum Anderen erfordert jede Neuzuordnung zu einer weiteren ACL die Beteiligung des Active Directory Admins. Das mag im ersten Augenblick nicht nach einem Problem klingen – aber wer schon mal in einem Groß-Unternehmen unterwegs war weiß, dass man die IT nur dann einbindet, wenn es gar keinen anderen Weg gibt, da damit immer enorm bürokratische und langwierige Prozesse verbunden sind.
Kritisch ist dieser Ansatz auch aus der generellen Security Sicht. Denn gelingt es einem Benutzer oder einer Benutzerin, den Daten-Tab im Workbook anzuzeigen, erhält er/sie Zugriff auf die gesamten Daten.
Security im Datenbank-Server
Eine andere Möglichkeit ist, diese Sicherheits-Ebene direkt in der Datenbank anzusiedeln und dort über Konfigurations-Tabellen zu steuern.
Der Benutzer / die Benutzerin wird dabei über den Windows Account im Active Directory identifiziert und über eine sog. „Trusted Connection“ an den SQL Server bei einer Datenanfrage übergeben. Damit weiß der Datenbank-Server, wer etwas von ihm möchte und kann die gewünschten Daten liefern. Dabei kann er zum Beispiel Konfigurationstabellen nutzen um festzustellen, auf welche Daten der Benutzer / die Benutzerin Zugriff hat. So wird ein individuelles Ergebnis vom Server geliefert.
Für die Pflege dieser Konfigurations-Tabellen ist eine Einbindung von IT nicht zwangsläufig erforderlich. Diese kann auch über eine kleine Anwendung durch berechtigte Personen in den Fachbereichen selbst durchgeführt werden.
Ein weiterer Vorteil ist, dass bei entsprechendem Aufbau der Konfigurations-Tabellen, ein beliebig kleinteiliger Aufbau der Berechtigungen erfolgen kann. Für den Personal-Bereich eines großen Konzerns haben wirr nach diesem Konzept eine Reporting-Lösung aufgebaut. Dabei konnte man bis auf die Personalnummern-Ebene hinab einzelne Mitarbeiterinnen und Mitarbeier ein- oder ausschließen. Ein Versinken im ACL-Sumpf konnte dadurch vermieden werden.
Etwas komplexer gestaltet sich der Aufbau übrigens bei Verwendung eines Tableau-Servers für die Anzeige. Diesen Themenkomplex werde ich jedoch in einem eigenständigen Artikel näher erläutern. Für den Moment soll es uns reichen, dass das skizzierte Szenario grundsätzlich so funktioniert. Es gibt uns maximale Flexibilität bei der benutzergesteuerten Sicherheit. Das gilt übrigens gleichermaßen für die Spalten- wie auch die Zeilen-Security. Zudem eliminiert es die Notwendigkeit, die IT Abteilung hierfür einzubinden.
Datenkonsistenz und Wiederverwendbarkeit mit Tableau + MS SQL Server
Ein weiter wichtiger Aspekt, der für die Verwendung eines zentralen Datenbank-Servers spricht, sind die Themen Datenkonsistenz und Wiederverwendbarkeit.
In aller Regel lassen sich die Quelldaten für das Reporting nicht 1:1 verwenden. Sie müssen für die Anzeige im Dashboard erst mehr oder weniger mühsam aufbereitet werden. Verlegt man diesen Schritt nun in den Anzeige-Layer – also nach Tableau, hat man das Problem, dass diese Schritte für jedes Workbook von Neuem durchlaufen werden müssen. Alleine deshalb ist es schon sinnvoll, für diese sog. ETL (Extract, Transform, Load) Prozesse eine eigene Ebene zu schaffen, damit die zum Teil sehr aufwendigen Schritte nur einmal durchlaufen werden müssen.
Dadurch ist auch sichergestellt, dass immer die gleichen Ergebnisse angezeigt werden und es nicht zu Inkonsistenzen auf Grund unterschiedlicher Aufbereitungen der Daten für Workbook A und B kommt. Ein zentraler Datenspeicher ist also essentiell für eine konsistente Datenhaltung. Durch die Vermeidung von mehrfachen Aufbereitungen der gleichen Quelldaten reduziert dieses Vorgehen auch die erforderlichen Aufwände und ist somit kosteneffizient.
Ein weiterer Vorteil dieser Architektur ist, dass der so geschaffene Daten-Pool von verschiedenen Workbooks und auch anderen Programmen benutzt werden kann. So ist es beispielsweise möglich, neben einem Tableau-Dashboard auch noch eine Excel Arbeitsmappe für das Line by Line Reporting aufzusetzen . Das ist etwas, das besser außerhalb von Tableau geschehen sollte. Durch die Entkopplung der Daten-Lade Prozesse von der Anzeige-Ebene, ist dies problemlos möglich.
Da man Trusted Connection auch in MS Excel nutzen kann, lässt sich auch hierfür der bereits besprochene Security Layer verwenden. So erhalten die Benutzerinnen und Benutzer nur Zugriff auf die Daten, die sie auch sehen sollen – egal, ob sie darauf von Tableau aus zugreifen oder die Daten in Excel importieren möchten. Es werden immer die gleichen Ergebnisse geliefert, da die Daten-Grundlage immer die selbe ist. So geht Datenkonsistenz und Wiederverwertbarkeit!
Performance
Ein altes Sprichwort sagt: „Schuster, bleib bei Deinen Leisten!“. Auf die IT übertragen könnte man sagen: „Ein Programm sollte nur das tun, was es am besten kann!“. Im Falle von Tableau ist das ganz bestimmt die Anzeige und Analyse von Daten während es die Aufgabe von Datenbanken ist, diese Informationen schnell und im gewünschten Aggregations-Level zu liefern.
Moderne Datenbank-Management-Systeme, wie der MS SQL Server, beinhalten hierfür sehr leistungsfähige Werkzeuge wie Execution Plans und Query Optimizer. Durch die Vergabe sog. Indizes in den Datentabellen kann zudem das Design der Datenbank optimal auf die Erfordernisse des Reportings ausgelegt werden. Zudem können verschiedene Daten-Sichten bereits vorberechnet werden (Stichwort OLAP Cubes), so dass die Notwendigkeit der (laufzeitintensiven) Berechnung im Anzeige-Layer entfällt.
Die Verwendung eines Datenbank-Servers ist zwar kein Allheilmittel gegen schlechte Performance eines Tableau-Dashboards. Abhängig vom Aufbau der Daten und des Dashboards – kann es sogar mal sein, dass dadurch gar kein Performance Gewinn erzielt wird – jedoch ist das die Ausnahme. Grundsätzlich gilt: je komplexer die Daten sind und je auswendiger sie aufbereitet werden müssen, desto lohnender ist der Einsatz eines Datenbank-Servers.
Abschließende Gedanken
Auf Grund der oben genannten Punkte raten wir Unternehmen in aller Regel dazu, zusätzlich zu Tableau auch einen Datenbank-Server für die Datenhaltung und -aufbereitung einzuplanen. Wir sind in diesem Artikel auf einige Vorteile dieser Kombination (insbesondere im Zusammenspiel mit dem MS SQL Server) eingegangen. Das gilt gleichwohl übrigens nicht für alle Datenbank-Management-Systeme. Es macht durchaus einen großen Unterschied, ob an Stelle des MS SQL Servers hierfür ein Oracle, SAP Hana, MongoDB System oder was auch immer eingesetzt wird. Dieser Vergleich lohnt aber einen eigenen Artikel. Es kommt also auf den Einzelfall an, wie die bestmögliche Architektur aussieht. Lassen Sie Sich bei der Entscheidung zu diesem Thema Zeit und treffen Sie keine voreilige Entscheidung. Wenn Sie sich unsicher sind, lassen Sie Sich beraten. Fehler, die Sie hier machen, lassen sich später oft nur sehr mühsam und kostspielig beseitigen.