Tag Archive for: Google

Artikelserie: BI Tools im Vergleich – Datengrundlage

Als Datengrundlage habe ich mir die Trainingsdaten – AdventureWorks 2017 – von Microsoft geschnappt und Ziel soll es sein, ein möglichst gleiches Dashboard in jedem dieser Tools zu erstellen.

Bei der Datenbasis handelt es sich bereits um ein relationales Datenbankmodel mit strukturierten Daten, welches als bak (Backup Datei) zur Verfügung steht. Die Daten sind bereits bereinigt und normalisiert, sowie bestehen auch bereits Beziehungen zwischen den Tabellen. Demnach fallen in meinem Fall aufwendige Datenbereinigungen und auch der Aufbau eines relationalen Datenmodells im Dashboard selbst weg. In den meisten Tools ist beides möglich, wenn auch nicht das optimale Programm, um Datenbereinigungen vorzunehmen. Alle Tools bieten einem die Möglichkeit strukturierte und unstrukturierte Daten aus verschiedensten Datenquellen zu importieren. Meine Datenquelle wird SQL Server von Microsoft sein, da die bak nicht direkt in die meisten Dashboards geladen werden kann und zudem auf Grund der Datenmenge ein kompletter Upload auch nicht ratsam ist. Aus Gründen der Performance sollten nur die für das Dashboard relevanten Daten importiert werden. In meinem Fall werde ich Daten aus lediglich 15 von insgesamt 71 Tabellen verwenden um Visualisierungen für wesentliche Geschäftskennzahlen aufzubauen. Die obere Grafik zeigt das Entity-Relationship-Modell (ERM) zu den relevanten Tabellen. Die Datengrundlage eignet sich sehr gut für tiefer gehende Analysen und bietet zugleich ein großes Potential für sehr ausgefallene Visualisierungen. Im Fokus dieser Artikelserie soll aber nicht die Komplexität der Grafiken, sondern die allgemeine Handhabbarkeit stehen. Meiner Erfahrung nach geht der Blick für das wesentliche verloren, sobald man zu ausgefallene Visualisierungen in einem Dashboard verwendet.

Eine mir selbst auferlegte Beschränkung soll sein, dass die Daten lediglich in dem Dashboard manipuliert werden, bedeutet das keine Tabellen in SQL Server geändert oder Views erstellt werden. Gehen wir einfach Mal davon aus, dass der Data Engineer Haare auf den Zähnen hat und mich weder an seine Datenbank ran lässt noch mir in irgendeiner Art und Weise zuarbeitet.

Also ganz nach dem Motto: Help yourself! 😉

Daten zum Üben gibt es etliche. Einfach Mal Github, Kaggle oder andere Open Data Quellen anzapfen. Falls ihr Lust habt, dann probiert euch doch selber einmal an den Dashboards. Ihr solltet ein wenig Zeit mitbringen, aber wenn man erstmal drin ist macht es viel Spaß und es gibt immer etwas neues zu entdecken!

Das erste Dashboard werde ich in Power BI erstellen. Falls ihr mir folgen möchtet: Hier ein paar Links um euch startklar zu machen.

Dataset: AdventureWorks 2017

MS SQL Server

MS SSMS

MS Power BI (Desktop)

Artikelserie: BI Tools im Vergleich – Einführung und Motivation

„Mit welchem BI-Tool arbeitest du am liebsten?“ Mit dieser Frage werde ich dieser Tage oft konfrontiert. Meine klassische Antwort und eine typische Beraterantwort: „Es kommt darauf an.“ Nach einem Jahr als Berater sitzt diese Antwort sicher, aber gerade in diesem Fall auch begründet. Auf den Analytics und Business Intelligence Markt drängen jedes Jahr etliche neue Dashboard-Anbieter und die etablierten erweitern Services und Technik in rasantem Tempo. Zudem sind die Anforderungen an ein BI-Tool höchst unterschiedlich und von vielen Faktoren abhängig. Meine Perspektive, also die Anwenderperspektive eines Entwicklers, ist ein Faktor und auch der Kern dieser Artikelserie. Um die Masse an Tools auf eine machbare Anzahl runter zu brechen werde ich die bekanntesten Tools im Vergleich ausprobieren und hier vorstellen. Die Aufgabe ist also schnell erklärt: Ein Dashboard mit den gleichen Funktionen und Aussagen in unterschiedlichen Tools erstellen. Im Folgenden werde ich auch ein paar Worte zur Bewertungsgrundlage und zur Datengrundlage verlieren.

Erstmal kurz zu mir: Wie bereits erwähnt arbeite ich seit einem Jahr als Berater, genauer als Data Analyst in einem BI-Consulting Unternehmen namens DATANOMIQ. Bereits davor habe ich mich auf der anderen Seite der Macht, quasi als Kunde eines Beraters, viel mit Dashboards beschäftigt. Aber erst in dem vergangenen Jahr wurde mir die Fülle an BI Tools bewusst und der Lerneffekt war riesig. Die folgende Grafik zeigt alle Tools welche ich in der Artikelserie vorstellen möchte.

Gartner’s Magic Quadrant for Analytics and Business Intelligence Platform führt jedes Jahr eine Portfolioanalyse über die visionärsten und bedeutendsten BI-Tools durch, unter der genannten befindet sich nur eines, welches nicht in dieser Übersicht geführt wird, ich jedoch als potenziellen Newcomer für die kommenden Jahre erwarte. Trotz mittlerweile einigen Jahren Erfahrung gibt es noch reichlich Potential nach oben und viel Neues zu entdecken, gerade in einem so direkten Vergleich. Also seht mich ruhig als fortgeschrittenen BI-Analyst, der für sich herausfinden will, welche Tools aus Anwendersicht am besten geeignet sind und vielleicht kann ich dem ein oder anderen auch ein paar nützliche Tipps mit auf den Weg geben.

Was ist eigentlich eine „Analytical and Business Intelligence Platform“?

Für alle, die komplett neu im Thema sind, möchte ich erklären, was eine Analytical and Business Intelligence Platform in diesem Kontext ist und warum wir es nachfolgend auch einfach als BI-Tool bezeichnen können. Es sind Softwarelösungen zur Generierung von Erkenntnissen mittels Visualisierung und Informationsintegration von Daten. Sie sollten einfach handhabbar sein, weil der Nutzer für die Erstellung von Dashboards keine speziellen IT-Kenntnisse mitbringen muss und das Userinterface der jeweiligen Software einen mehr oder minder gut befähigt die meisten Features zu nutzen. Die meisten und zumindest die oben genannten lassen sich aber auch um komplexere Anwendungen und Programmiersprachen erweitern. Zudem bestimmt natürlich auch der Use Case den Schwierigkeitsgrad der Umsetzung.

Cloudbasierte BI Tools sind mittlerweile der Standard und folgen dem allgemeinen Trend. Die klassische Desktop-Version wird aber ebenfalls von den meisten angeboten. Von den oben genannten haben lediglich Data Studio und Looker keine Desktop- Version. Für den einfachen User macht das keinen großen Unterschied, welche Version man nutzt. Aber für das Unternehmen in Gesamtheit ist es ein wesentlicher Entscheidungsfaktor für die Wahl der Software und auch auf den Workflow des Developers bzw. BI-Analyst kann sich das auswirken.

Unternehmensperspektive: Strategie & Struktur

Die Unternehmensstrategie setzt einen wesentlichen Rahmen zur Entwicklung einer Datenstrategie worunter auch ein anständiges Konzept zur Data Governance gehört.

Ein wesentlicher Punkt der Datenstrategie ist die Verteilung der BI- und Datenkompetenz im Unternehmen. An der Entwicklung der Dashboards arbeiten in der Regel zwei Parteien, der Developer, der im Unternehmen meistens die Bezeichnung BI- oder Data Analyst hat, und der Stakeholder, also einzelner User oder die User ganzer Fachabteilungen.

Prognose: Laut Gartner wird die Anzahl der Daten- und Analyse-Experten in den Fachabteilungen, also die Entwickler und Benutzer von BI Tools, drei Mal so schnell wachsen verglichen mit dem bereits starken Wachstum an IT-Fachkräften.

Nicht selten gibt es für ein Dashboard mehrere Stakeholder verschiedener Abteilungen. Je nach Organisation und Softwarelösung mit unterschiedlich weitreichenden Verantwortlichkeiten, was die Entwicklung eines Dashboards an geht.

Die obige Grafik zeigt die wesentlichen Prozessschritte von der Konzeption bis zum fertigen Dashboard und drei oft gelebte Konzepte zur Verteilung der Aufgaben zwischen dem User und dem Developer. Natürlich handelt es sich fast immer um einen iterativen Prozess und am Ende stellen sich auch positive Nebenerkenntnisse heraus. Verschiedene Tools unterstützen durch Ihre Konfiguration und Features verschiedene Ansätze zur Aufgabenverteilung, auch wenn mit jedem Tool fast jedes System gelebt werden kann, provozieren einige Tools mit ihrem logischen Aufbau und dem Lizenzmodell zu einer bestimmten Organisationsform. Looker zum Beispiel verkauft mit der Software das Konzept, dem User eine größere Möglichkeit zu geben, das Dashboard in Eigenregie zu bauen und gleichzeitig die Datenhoheit an den richtigen Stellen zu gewährleisten (mittlerer Balken in der Grafik). Somit wird dem User eine höhere Verantwortung übertragen und weit mehr Kompetenzen müssen vermittelt werden, da der Aufbau von Visualisierung ebenfalls Fehlerpotential in sich birgt. Ein Full‑Service hingegen unterstützt das Konzept fast aller Tools durch Zuweisen von Berechtigungen. Teilweise werden aber gewisse kostenintensive Features nicht genutzt oder auf Cloud-Lizenzen verzichtet, so dass jeder Mitarbeiter unabhängig auf einer eigenen Desktop-Version arbeitet, am Ende dann leider die Single Source of Truth nicht mehr gegeben ist. Denn das führt eigentlich gezwungenermaßen dazu, dass die User sich aus x beliebigen Datentöpfen bedienen, ungeschultes Personal falsche Berechnungen anstellt und am Ende die unterschiedlichen Abteilungen sich mit schlichtweg falschen KPIs überbieten. Das spricht meistens für ein Unternehmen ohne vollumfängliches Konzept für Data Governance bzw. einer fehlenden Datenstrategie.

Zu dem Thema könnte man einen Roman schreiben und um euch diesen zu ersparen, möchte ich kurz die wichtigsten Fragestellungen aus Unternehmensperspektive aufzählen, ohne Anspruch auf Vollständigkeit:

  • Wann wird ein Return on Invest (ROI) realisiert werden?
  • Wie hoch ist mein Budget für BI-Lösungen?
  • Sollen die Mitarbeiter mit BI-Kompetenz zentral oder dezentral organisiert sein?
  • Wie ist meine Infrastruktur aufgebaut? Cloudbasiert oder on Premise?
  • Soll der Stakeholder/User Zeit-Ressourcen für den Aufbau von Dashboards erhalten?
  • Über welche Skills verfügen die Mitarbeiter bereits?
  • Welche Autorisierung in Bezug auf die Datensichtbarkeit und -manipulation haben die jeweiligen Mitarbeiter der Fachabteilungen?
  • Bedarf an Dashboards: Wie häufig werden diese benötigt und wie oft werden bestehende Dashboards angepasst?
  • Kann die Data Exploration durch den Stakeholder/User einen signifikanten Mehrwert liefern?
  • Werden Dashboards in der Regel für mehrere Stakeholder gebaut?

Die Entscheidung für die Wahl eines Dashboards ist nicht nur davon abhängig, wie sich die Grafiken von links nach rechts schieben lassen, sondern es handelt sich auch um eine wichtige strategische Frage aus Unternehmersicht.

Ein Leitsatz hierbei sollte lauten:
Die Strategie des Unternehmens bestimmt die Anforderungen an das Tool und nicht andersrum!

Perspektive eines Entwicklers:      Bewertungsgrundlage der Tools

So jetzt Mal Butter bei die Fische und ab zum Kern des Artikels. Jeder der Artikel wird aus den folgenden Elementen bestehen:

  • Das Tool:
    • Daten laden
    • Daten transformieren
    • Daten visualisieren
    • Zukunftsfähigkeit am Beispiel von Pythonintegration
    • Handhabbarkeit
  • Umweltfaktoren:
    • Community
    • Dokumentation
    • Features anderer Entwickler(-firmen) zur Erweiterung
    • Lizenzmodell
      • Cloud (SaaS) ODER on premise Lizenzen?
      • Preis (pro Lizenz, Unternehmenslizenz etc.)
      • Freie Version

 

Im Rahmen dieser Artikelserie erscheinen im Laufe der kommenden Monate folgende Artikel zu den Reviews der BI-Tools:

  1. Power BI von Microsoft
  2. Tableau
  3. Qlik Sense
  4. MicroStrategy (erscheint demnächst)
  5. Looker (erscheint demnächst)

Über einen vorausgehend veröffentlichten Artikel wird die Datengrundlage erläutert, die für alle Reviews gemeinsam verwendet wird: Vorstellung der Datengrundlage

Big Data Essentials – Intro

1. Big Data Definition

Data umfasst Nummern, Text, Bilder, Audio, Video und jede Art von Informationen die in Ihrem Computer gespeichert werden können. Big Data umfasst Datenmengen, die eine oder mehrere der folgenden Eigenschaften aufweisen: Hohes Volumen (High Volume), hohe Vielfalt (High Variety) und / oder eine notwendige hohe Geschwindigkeit (High Velocity) zur Auswertung. Diese drei Eigenschaften werden oft auch als die 3V’s von Big Data bezeichnet.

1.1. Volumen: Menge der erzeugten Daten

Volumen bezieht sich auf die Menge der generierten Daten. Traditionelle Datenanalysemodelle erfordern typischerweise Server mit großen Speicherkapazitäten, bei massiver Rechenleistung sind diese Modelle nicht gut skalierbar. Um die Rechenleistung zu erhöhen, müssen Sie weiter investieren, möglicherweise auch in teurere proprietäre Hardware. Die NASA ist eines von vielen Unternehmen, die enorme Mengen an Daten sammeln. Ende 2014 sammelte die NASA alle paar Sekunden etwa 1,73 GB an Daten. Und auch dieser Betrag der Datenansammlung steigt an, so dass die Datenerfassung entsprechend exponentiell mitwachsen muss. Es resultieren sehr hohe Datenvolumen und es kann schwierig sein, diese zu speichern.

1.2. Vielfalt: Unterschiedliche Arten von Daten

Das  traditionelle  Datenmodell (ERM)  erfordert  die  Entwicklung  eines  Schemas,  das  die  Daten in ein Korsett zwingt. Um das Schema zu erstellen, muss man das Format der Daten kennen, die gesammelt werden. Daten  können  wie  XML-Dateien  strukturiert  sein,  halb  strukturiert  wie  E-Mails oder unstrukturiert wie Videodateien.

Wikipedia – als Beispiel – enthält mehr als nur Textdaten, es enthält Hyperlinks, Bilder, Sound-Dateien und viele andere Datentypen mit mehreren verschiedenen Arten von Daten. Insbesondere unstrukturierte   Daten haben   eine   große   Vielfalt.  Es   kann   sehr   schwierig   sein, diese Vielfalt in einem Datenmodell zu beschreiben.

1.3. Geschwindigkeit: Geschwindigkeit, mit der Daten genutzt werden

Traditionelle Datenanalysemodelle wurden für die Stapelverarbeitung (batch processing) entwickelt. Sie sammeln die gesamte Datenmenge und verarbeiten sie, um sie in die Datenbank zu speichern. Erst mit einer Echtzeitanalyse der Daten kann schnell auf Informationen reagiert werden. Beispielsweise können Netzwerksensoren, die mit dem Internet der Dinge (IoT) verbunden sind, tausende von Datenpunkten pro Sekunde erzeugen. Im Gegensatz zu Wikipedia, deren Daten später verarbeitet werden können, müssen Daten von Smartphones und anderen Netzwerkteilnehmern mit entsprechender Sensorik in  Echtzeit  verarbeitet  werden.

2. Geschichte von Big Data

2.1. Google Solution

  • Google File System speichert die Daten, Bigtable organisiert die Daten und MapReduce verarbeitet es.
  • Diese Komponenten arbeiten zusammen auf einer Sammlung von Computern, die als Cluster bezeichnet werden.
  • Jeder einzelne Computer in einem Cluster wird als Knoten bezeichnet.

2.2 Google File System

Das Google File System (GFS) teilt Daten in Stücke ‚Chunks’ auf. Diese ‚Chunks’ werden verteilt und auf verschiedene Knoten in einem Cluster nachgebildet. Der Vorteil ist nicht nur die mögliche parallele Verarbeitung bei der späteren Analysen, sondern auch die Datensicherheit. Denn die Verteilung und die Nachbildung schützen vor Datenverlust.

2.3. Bigtable

Bigtable ist ein Datenbanksystem, das GFS zum Speichern und Abrufen von Daten verwendet. Trotz seines Namens ist Bigtable nicht nur eine sehr große Tabelle. Bigtable ordnet die Datenspeicher mit einem Zeilenschlüssel, einem Spaltenschlüssel und einem Zeitstempel zu. Auf diese Weise können dieselben Informationen über einen längeren Zeitraum hinweg erfasst werden, ohne dass bereits vorhandene Einträge überschrieben werden. Die Zeilen sind dann in den Untertabellen partitioniert, die über einem Cluster verteilt sind. Bigtable wurde entwickelt, um riesige Datenmengen zu bewältigen, mit der Möglichkeit, neue Einträge zum Cluster hinzuzufügen, ohne dass eine der vorhandenen Dateien neu konfiguriert werden muss.

2.4. MapReduce

Als dritter Teil des Puzzles wurde ein Parallelverarbeitungsparadigma namens MapReduce genutzt, um die bei GFS gespeicherten Daten zu verarbeiten. Der Name MapReduce wird aus den Namen von zwei Schritten im Prozess übernommen. Obwohl der Mapreduce-Prozess durch Apache Hadoop berühmt geworden ist, ist das kaum eine neue Idee. In der Tat können viele gängige Aufgaben wie Sortieren und Falten von Wäsche als Beispiele für den MapReduce- Prozess betrachtet werden.

Quadratische Funktion:

  • wendet die gleiche Logik auf jeden Wert an, jeweils einen Wert
  • gibt das Ergebnis für jeden Wert aus
    (map square'(1 2 3 4)) = (1 4 9 16)

Additionsfunktion

  • wendet die gleiche Logik auf alle Werte an, die zusammen genommen werden.
    (reduce + ‘(1 4 9 16)) = 30

Die Namen Map und Reduce können bei der Programmierung mindestens bis in die 70er-Jahre zurückverfolgt werden. In diesem Beispiel sieht man, wie die Liste das MapReduce-Modell verwendet. Zuerst benutzt man Map der Quadratfunktion auf einer Eingangsliste für die Quadratfunktion, da sie abgebildet ist, alle angelegten Eingaben und erzeugt eine einzige Ausgabe pro Eingabe, in diesem Fall (1, 4, 9 und 16). Additionsfunktion reduziert die Liste und erzeugt eine einzelne Ausgabe von 30, der die Summe aller Eingänge ist.

Google nutzte die Leistung von MapReduce, um einen Suchmaschinen-Markt zu dominieren. Das Paradigma kam in der 19. Websearch-Engine zum Einsatz und etablierte sich innerhalb weniger Jahre und ist bis heute noch relevant. Google verwendete MapReduce auf verschiedene Weise, um die Websuche zu verbessern. Es wurde verwendet, um den Seiteninhalt zu indexieren und ein Ranking über die Relevant einer Webseite zu berechnen.

map(String key, String value): 
    //key: document name 
    //value: document contents 
    for each word w in value: 
        EmitIntermediate(w,"1"); 
     
reduce(String key, Iterator values): 
    //key: a word 
    //values: a list of counts 
    int result = 0; 
    for each v in values: 
        result += ParseInt(v); 
        Emit(AsString(result)); 

Dieses  Beispiel  zeigt  uns  den MapReduce-Algorithmus, mit dem Google Wordcount auf Webseiten ausführte. Die Map-Methode verwendet als Eingabe einen Schlüssel (key) und einen Wert, wobei der Schlüssel den Namen des Dokuments darstellt  und  der  Wert  der  Kontext  dieses Dokuments ist. Die Map-Methode durchläuft jedes Wort im Dokument und gibt es als Tuple zurück, die aus dem Wort und dem Zähler 1 besteht.

Die   Reduce-Methode   nimmt   als   Eingabe auch  einen  Schlüssel  und  eine  Liste  von  Werten an, in der der Schlüssel ein Wort darstellt. Die  Liste  von  Werten  ist  die  Liste  von  Zählungen dieses Worts. In diesem Beispiel ist der Wert 1. Die Methode “Reduce” durchläuft alle Zählungen. Wenn die Schleife beendet ist, um die Methode zu reduzieren, wird sie als Tuple zurückgegeben, die aus dem Wort und seiner Gesamtanzahl besteht.