This blog post is also available in English

Dieser Artikel stellt eine Vertiefung zum Thema „Data Products“ für Teams dar. Im Artikel Warum dein Team Data Products braucht ging es allgemeiner um Data Products.

Was sind eigentliche BI-Tools?

BI steht für Business Intelligence.

Das Themengebiet ist groß. Anbieter wie Microsoft, Amazon, IBM und weitere haben viele Angebote rund um das Thema. Ich möchte mich aber auf eine bestimmte Art von BI-Tools konzentrieren.

Ich möchte den Blick auf Programme lenken, die folgende Eigenschaften erfüllen:

Kandidaten auf welche diese Eigenschaften zutreffen sind:

Tools für Daten Teams und Daten Analysten

Das sind doch Tools für Daten Teams und Daten Analysten. Mit denen haben wir als Entwicklungsteam nichts zu tun. Wir liefern dafür nur die Daten.

So oder so ähnlich könnte eine Reaktion ausfallen. Falls das bei dir zutrifft, bitte diesen Artikel noch nicht zur Seite legen.

Es gibt gute Gründe, sich auch als Entwicklungsteam damit auseinanderzusetzen.

Beispiele:

„One size fits all“, gilt auch hier nicht.

Natürlich lassen sich eigene Lösungen für die Analyse von Daten entwickeln. Oder vorhandene Tools und Frameworks lassen sich kombinieren. Es hängt vom Kontext ab, ob das eine angemessene Entscheidung ist. Und doch ist meine Hypothese, dass der Einsatz von BI Software häufig der schnellere Weg ist.

Vorüberlegungen

Ein paar Vorüberlegungen sind aber wichtig. Es gilt zu prüfen, ob eine BI Software nützlich sein kann.

Die Liste ist ein Startpunkt.

Beispiel mit Google Looker

Schauen wir uns nun einmal ein Beispiel mit Google Looker an. Es stammt aus einem realen Projekt. Dort wurde die Umsetzung von Berichten alle von einer Person durchgeführt, die nicht als Entwickler:in ausgebildet war. Ausgehend von diesen Erfahrungen ist meine Hypothese, dass Entwickler:innen vielleicht 2–3 Tage Einarbeitung benötigt. Anschließend stehen schon die ersten Berichte zur Verfügung.

Setup

In unserem konkreten Setup wird Google Big Query als „Warehouse“ eingesetzt. Das bedeutet alle Data Products werden dort gespeichert. Google Looker ist als Infrastruktur bereits vorhanden, und es gibt existierende Abläufe für die Einrichtung neuer Projekte.

Klar, so gute Voraussetzungen gibt es nicht immer. Aber doch vielleicht häufiger als man annimmt.

Ein paar Daten zu Looker

Looker ist vollständig webbasiert. Looker arbeitet mit verschiedenen Warehouses zusammen (u.a. Google Big Query). Es arbeitet mit relationalen Daten. Meiner Einschätzung nach bietet es sich in mittleren Unternehmen als „One-Shop-Lösung“ an. Damit meine ich, dass ggf. auch bestimmte Datentransformationen in Looker vorgenommen werden. In größeren Unternehmen bietet es sich zur Analyse und Visualisierung von Datenprodukten an.

Ein paar positive Dinge aus der Perspektive eines Entwicklungsteams:

Es gibt auch negative Aspekte. Diese Fallen je nach Kontext und Vorlieben mehr oder weniger ins Gewicht.

Aufbau eines Looker Modells

Dieser Artikel soll kein How-To oder ein Training werden. Aber um aufzuzeigen wie schnell (oder langsam) gearbeitet werden kann, sind ein paar Grundlagen wichtig.

Wir starten mit der Definition eines Modells. Jede Definition wird in einer Datei gemacht, diese können wieder in Ordner organisiert werden. Das Modell sagt im einfachsten Fall nur aus, welche Definitionen berücksichtigt werden müssen. Dies geschieht über die Anweisung include.

Im nächsten Schritt werden die views definiert. So etwas wie die Datentabellen mit denen wir arbeiten können. Eine View kann einfach 1:1 einer Tabelle im Warehouse entsprechen. Es ist aber auch möglich größere SQL Abfragen zu schreiben. Dadurch könnten zum Beispiel auch mehrere vorhandene Tabellen kombiniert werden. Hier muss man nun aufpassen und sich entscheiden. Ist das ein Anwendungsfall für Looker? Oder ist das ein Anwendungsfall für eine Ebene vor Looker?

Views können komplett manuell beschrieben werden. Looker kann aber auch vorhandene Tabellen einlesen. Das Ergebnis ist dann ein vorgeschlagenes Set aus Dimensionen und Measures. Dimensionen sind die Eigenschaften. Sie können angezeigt oder gefiltert werden. Measures sind in der Regel Berechnungen. Der Durchschnitt von X. Die Summe von Y.

Für alle Daten können auch label und description hinterlegt werden, um die Verständlichkeit zu erhöhen.

Die Einarbeitung um so weit zu kommen ist relativ gering.

include: "/views/**/*.view"

view: root_products {
  sql_table_name: `datamarts.root_products`;;
  label: "Root Products"

# Define dimensions

  dimension: root_product_code {
    primary_key: yes
    type: string
    sql: ${TABLE}.root_product_code ;;
    label: "Code"
    description: "Unique key to identify a root product"

    # Link uses the code as value and offers direct access to
    # the product search prefilled with the code.
    link: {
      label: "Open in Product Search"
      url: "https://my-web-app-url/products?filter.label={{value}}"
      icon_url: "https://my-web-app-url/assets/favicon.png" #Optional
    } 
  }

  dimension: short_description {
    type: string
    sql: ${TABLE}.short_description ;;
    label: "Short description"
    description: "Short description for the product"
  }
}

Dieser kleine Auszug definiert eine view. Grundlage ist eine Tabelle die im Dataset datamarts liegt.

Es werden zwei Dimensionen definiert,

Nun geht es daran diese Daten für Analysen öffentlich verfügbar zu machen. Das geschieht über explores.

Ein einfaches Beispiel:

# Define explores

explore: product_data_explore {
  view_name: root_products
  label: "Product Data"
  group_label: "Evaluate" 
 }

Jetzt kann man über die Weboberfläche bereits auf die Daten zugreifen.

Damit sind bereits alle Voraussetzungen erfüllt, um folgende Aktivitäten durchführen zu können:

Ab jetzt können also bereits mehr Personengruppen mit den Daten arbeiten. Auch solche die nicht als Entwickler:in ausgebildet sind.

Natürlich ist es selten ausreichend nur auf eine view zu blicken. Deshalb gibt es die Möglichkeit per join das explore zu erweitern. In unserem Beispiel haben wir eine Hierarchie von Produkten. Ergänzen wir also unsere Sicht um die nächste Ebene.

Dazu ergänzen wir unsere Definition. Wir müssen uns nur kurz vorstellen, das bereits weitere views definiert wurden.

join: color_products {
    type: left_outer 
    sql_on: ${root_products.root_product_code} = ${color_product.root_product_code};;
    relationship: one_to_many
  }

Die View color_products wird eingebunden. Sie enthält den root_product_code als Fremdschlüssel. Ab jetzt stehen in unserem Explore product_data_explore beide Tabelle zur Verfügung.

Mehr geht immer

Ein richtiges Modell erfordert natürlich mehr Zeilen. Aber die Beispiele sollen zeigen, das die Syntax nicht sehr aufwändig ist. Zusätzlich lässt sich an vielen Stellen auch SQL einbinden. Wer also z.B. für eine Dimension eine Anpassung machen muss, kann dies einfach mit SQL machen. Zum Beispiel CAST nutzen, um einen Datentyp zu ändern.

Doch mit diesem relativ geringen Aufwand lassen sich die Daten komfortabel visualisieren.

Darüber hinaus gibt es natürlich noch weitere Möglichkeiten. Ein Blick in die Dokumentation lohnt sich. Oder halte Ausschau nach einem Online-Kurs. Das Angebot ist recht groß.

In unserem Beispiel war der Einsatz von Looker sinnvoll, weil

Alternativen

Einen ausführlicher Vergleich soll an dieser Stelle nicht erfolgen. Doch auf zwei Alternativen möchte ich noch kurz eingehen.

Die ersten Schritte haben wir mit Power BI unternommen, bis wir wussten, wer uns ein eigenes Looker Projekt einrichten konnte. Im Vergleich zu Looker wird die Basisarbeit in einer grafischen Umgebung gemacht. Es gibt leider keine richtige Versionsverwaltung. Dafür kann man aber schnell starten. Im Unterschiedlich zu Looker gibt es auch einen Windows-Client. Mit diesem lassen sich viele Dinge schon lokal machen. Auch der Zugriff auf Datenbanken ist natürlich möglich. Möchte man den Einsatz aber skalieren, reicht eine lokale Installation nicht. Aber kleine Auswertungen und Prototypen lassen sich so schnell entwickeln.

Wenn es darum geht Berichte zu veröffentlichen oder die Aktualisierung von Daten in der Cloud zu machen, muss man die entsprechenden Services von Microsoft buchen.

Ein anderes Werkzeug ist das (gute) alte Excel. Liegen die Daten bereits geeignet vor (z.B. in Big Query), dann lassen sich viele Analysen tatsächlich auch mit Excel machen. Nicht zuletzt durch die Einführung von Power Query in Microsoft Excel erhält man auch dort eine Menge Möglichkeiten zur Analyse. Und Visualisierungen unterstützt Excel ebenfalls.

Fazit

Am Ende hängt alles vom jeweiligen Kontext ab. Doch in vielen Fällen kann auch ein Entwicklungsteam Zeit durch den Einsatz von BI Software sparen. Und Stakeholder können bei früher eingebunden werden.

Welche positive oder negativen Erfahrungen habt ihr gemacht? Welche Gedanken habt ihr nach dem Lesen dieses Artikels? Ich freue mich auf Kommentare, Fragen und Diskussionen.

TAGS