Der entscheidende Unterschied zu vielen anderen BI-Tools: Looker rechnet nicht selbst, es delegiert. Statt Daten zu importieren und in einem eigenen Format zu speichern, übersetzt Looker jede Nutzeranfrage in SQL und schickt diese direkt an Ihre Datenbank oder Ihr Data Warehouse – etwa BigQuery, Snowflake oder PostgreSQL. Das nennt man „in-database“ oder „live query“. Die Folge: Es gibt keine veralteten Datenkopien, keine separate Extraktions-Pipeline für jede Auswertung und – bei sauberer Modellierung – auch keine widersprüchlichen Zahlen zwischen Abteilungen.
Drei Eigenschaften definieren Looker:
In den meisten BI-Tools definiert jede Person ihre Kennzahlen selbst: Der eine Analyst zieht „Umsatz“ aus Spalte A, der andere zieht „Umsatz netto nach Storno“ aus einer Formel, ein Dritter vergisst die Retouren. Drei Berichte, drei Wahrheiten. LookML dreht dieses Prinzip um: Eine zentrale Definition legt fest, wie „Umsatz“ berechnet wird, welche Tabellen verknüpft werden und welche Filter gelten. Alle Auswertungen im Haus greifen anschließend auf genau diese Definition zu.
LookML beschreibt die Daten in wenigen, klar getrennten Bausteinen. Es ist kein Programmieren im klassischen Sinn, sondern ein Beschreiben von Beziehungen und Regeln – näher an Konfiguration als an Software-Entwicklung, auch wenn Versionierung über Git dazugehört.
Der praktische Nutzen zeigt sich, sobald Kennzahlen unternehmenskritisch werden. Wenn Geschäftsführung, Controlling und Vertrieb in jeder Sitzung über unterschiedliche „Umsatz“-Zahlen streiten, liegt das selten an Böswilligkeit – es liegt an unterschiedlichen Definitionen, die niemand zentral festgehalten hat. LookML zwingt das Unternehmen, diese Definitionen einmal sauber auszuhandeln und festzuschreiben.
Diese Disziplin ist Lookers Stärke und zugleich seine Hürde. Die Modellierung ist Vorarbeit, die ein Tool nicht abnimmt. Sie verlangt Menschen, die sowohl die Datenstruktur als auch das Geschäft verstehen – die sogenannte Analytics-Engineering-Rolle. Wo diese Rolle fehlt, bleibt Looker ein leeres Gerüst. Wo sie vorhanden ist, wird aus dem Modell ein dauerhafter Vermögenswert, der mit jedem neuen Bericht weiter trägt, statt erneut gebaut werden zu müssen.
Über die reine Anzeige hinaus ist Looker auf die Verteilung von Ergebnissen ausgelegt. Dashboards und einzelne Auswertungen lassen sich planen und automatisch als E-Mail, Datei oder über Schnittstellen ausliefern. So landet das Vertriebs-Reporting jeden Montagmorgen im Postfach der Regionalleitung, ohne dass jemand es manuell zieht. Datengesteuerte Warnungen können zusätzlich automatisch auslösen, wenn eine Kennzahl einen Schwellenwert über- oder unterschreitet – etwa wenn der Lagerbestand eines Artikels unter eine kritische Menge fällt.
Wie viele Google-Cloud-Dienste hat auch Looker generative KI integriert, um Auswertungen über natürliche Sprache zugänglicher zu machen. Nutzer können Fragen in Alltagssprache stellen, statt Felder manuell zu kombinieren, und erhalten Erklärungen oder Visualisierungs-Vorschläge. Diese Funktionen entwickeln sich schnell weiter und variieren je nach Plan und Konfiguration. Entscheidend bleibt: Auch die KI antwortet auf Basis des semantischen Modells – die Qualität der Antworten hängt direkt von der Qualität der LookML-Definitionen ab. Ein gutes Modell macht KI-Abfragen verlässlich, ein lückenhaftes Modell produziert auch mit KI fragwürdige Ergebnisse.
Looker Studio (früher „Google Data Studio“) ist ein kostenloses, leicht zugängliches Visualisierungswerkzeug. Man verbindet eine Datenquelle – Google Analytics, Google Ads, eine Tabelle, BigQuery – und baut per Klick Berichte. Es ist ideal für Marketing-Reportings, schnelle Dashboards und Einzelpersonen. Es gibt kein zentrales semantisches Modell: Jede Definition lebt im jeweiligen Bericht.
Looker dagegen ist eine kostenpflichtige Enterprise-Plattform mit dem LookML-Modell im Zentrum, Governance, Berechtigungssteuerung und Embedding-Funktionen für den unternehmensweiten Einsatz. Die folgende Tabelle stellt beide gegenüber.
Für viele kleinere Anforderungen ist Looker Studio die richtige – und kostenlose – Wahl. Wenn ein Marketingteam Kampagnenzahlen visualisieren, ein Geschäftsführer ein schnelles Umsatz-Dashboard sehen oder eine Einzelperson eine Tabelle aufbereiten will, ist der Aufwand einer LookML-Modellierung nicht gerechtfertigt. Looker Studio liefert hier in Minuten ein brauchbares Ergebnis.
Der Wechsel lohnt, sobald die Schwächen der Einzelbericht-Logik schmerzen: wenn dieselbe Kennzahl in fünf Berichten fünf Werte liefert, wenn Zugriffsrechte auf Zeilenebene gebraucht werden, wenn Auswertungen revisionssicher dokumentiert sein müssen oder wenn Analysen in ein eigenes Produkt eingebettet werden sollen. Häufig ist die pragmatische Lösung übrigens beides nebeneinander: Looker als governte Basis für unternehmenskritische Kennzahlen, Looker Studio für schnelle, unkritische Ad-hoc-Berichte am Rand.
Looker spielt seine Stärke aus, wenn drei Bedingungen zusammenkommen: Erstens existiert bereits ein zentrales Data Warehouse – idealerweise BigQuery, aber auch Snowflake, Redshift oder PostgreSQL funktionieren gut. Zweitens ist eine einheitliche, governte Kennzahlen-Definition unternehmensweit wichtig, weil mehrere Abteilungen mit denselben Zahlen arbeiten. Drittens sollen Analysen in eigene Anwendungen eingebettet oder als Datenprodukt bereitgestellt werden. Wo Google Cloud ohnehin die Datenplattform ist, ist Looker die naheliegende Ergänzung.
Power BI ist meist die wirtschaftlichste Wahl für Unternehmen, die tief in der Microsoft-Welt verankert sind: Wer Microsoft 365 und Azure nutzt, bekommt mit Power BI eine eng integrierte, vergleichsweise günstige Lösung mit niedriger Einstiegshürde und großer Verbreitung am Arbeitsmarkt. Tableau überzeugt dort, wo explorative, visuell anspruchsvolle Datenanalyse im Vordergrund steht und Analysten maximale gestalterische Freiheit brauchen. Beide Werkzeuge sind für klassisches Self-Service-Reporting oft schneller einsatzbereit als Looker, weil sie keine vorgelagerte LookML-Modellierung verlangen. Der Preis dafür: Ohne diszipliniertes Governance-Konzept entsteht hier leichter wieder das Definitions-Chaos, das Looker konstruktiv verhindert.
Klassische BI-Werkzeuge ziehen oft eine Kopie der Daten in einen eigenen, optimierten Speicher und werten diese aus. Looker geht den umgekehrten Weg: Es speichert kein eigenes Datenextrakt, sondern erzeugt aus dem LookML-Modell live SQL-Abfragen gegen Ihre Datenbank. Die Daten bleiben dort, wo sie ohnehin liegen. Das bedeutet aktuelle Zahlen ohne Synchronisations-Verzögerung, keine doppelte Datenhaltung und keine separate Extraktions-Pipeline je Bericht. Es bedeutet aber auch, dass die Leistung von Looker direkt von der Leistung Ihrer Datenbank abhängt – eine langsame oder schlecht modellierte Datenbasis macht auch Looker langsam.
Looker unterstützt eine breite Palette an Datenbanken und Data Warehouses. Besonders nahtlos ist die Verbindung zu Google BigQuery, da beide aus dem Google-Cloud-Ökosystem stammen.
Weil aller Datenzugang über das LookML-Modell läuft, lassen sich Berechtigungen zentral und feingranular steuern. Looker kann den Zugriff auf einzelne Zeilen (etwa nur die eigene Region), auf bestimmte Spalten (etwa keine Gehaltsfelder) und auf ganze Auswertungsbereiche regeln. Da diese Regeln im Modell verankert sind, gelten sie überall gleich – im Dashboard, im freien Explore, in der eingebetteten Ansicht. Das ist ein wesentlicher Unterschied zu Werkzeugen, bei denen Berechtigungen pro Bericht neu gepflegt werden müssen und leicht auseinanderlaufen.
Der Grundgedanke: Daten entfalten ihren Wert am Ort der Entscheidung. Ein Vertriebsmitarbeiter, der im CRM ohnehin den Kunden geöffnet hat, profitiert mehr von einer eingebetteten Umsatzhistorie als von einem Dashboard in einem anderen Tab. Ein Kunde, der im SaaS-Produkt seine Nutzungszahlen direkt sieht, braucht keinen Export. Looker macht aus Analytics ein Feature statt eines separaten Ziels.
Looker unterscheidet im Kern zwei Szenarien, die sich auch lizenzrechtlich unterscheiden:
Beim externen Embedding spielt die feingranulare Governance ihre volle Rolle aus: Ein einziges LookML-Modell versorgt viele Kunden, doch über die Zugriffsregeln sieht jeder ausschließlich seinen eigenen Datenausschnitt – die sogenannte Mandantentrennung. Für Software-Anbieter, die ihren Kunden Analysen bieten wollen, ohne diese von Grund auf selbst zu entwickeln, ist das ein erheblicher Beschleuniger.
Über klassisches Embedding hinaus lässt sich Looker als Datenschicht für eigene Anwendungen nutzen. Über programmierbare Schnittstellen können Entwickler die im Modell definierten Kennzahlen abrufen und in eigene Oberflächen, Workflows oder Automatisierungen einbauen – sogenannte „Data Apps“. Die Geschäftslogik bleibt dabei zentral im LookML-Modell, während die Oberfläche frei gestaltet wird. So entstehen datengetriebene Anwendungen, die auf derselben verlässlichen Kennzahlen-Definition fußen wie die internen Dashboards.
Vereinfacht setzt sich der Looker-Preis aus zwei Bestandteilen zusammen. Erstens einer Plattform-Komponente, die die Bereitstellung der Looker-Instanz selbst abdeckt – also die zentrale Infrastruktur, auf der das Modell läuft. Zweitens einer Nutzer-Komponente, die sich nach Anzahl und Art der Nutzer richtet.
Bei den Nutzern wird typischerweise unterschieden, wer was tun darf: Anwender, die nur Dashboards ansehen, werden anders eingestuft als Anwender, die frei explorieren, und wiederum anders als Entwickler, die das LookML-Modell pflegen. Diese Staffelung erlaubt, vielen Mitarbeitenden günstigen Lesezugriff zu geben, während die teureren Lizenzen den wenigen Modell-Entwicklern vorbehalten bleiben.
Die reine Lizenz ist selten der größte Posten. In der Praxis treten weitere Kostenblöcke hinzu, die in eine ehrliche Kalkulation gehören:
Auch Google bleibt ein US-Konzern und unterliegt grundsätzlich US-Recht. Die Wahl einer EU-Datenregion reduziert das Risiko deutlich, weil die Verarbeitung geografisch in Europa stattfindet. Trotzdem bleibt – wie bei allen großen US-Cloud-Anbietern – ein rechtliches Restrisiko bestehen, das im Rahmen einer Datenschutz-Folgenabschätzung bewertet werden sollte. Ein Vorteil der In-Database-Architektur ist dabei, dass die sensiblen Rohdaten oft im eigenen, kontrollierten Data Warehouse verbleiben können, während Looker primär das Modell und die Abfrage-Logik betreibt. Für hochsensible Daten oder Berufsgeheimnisträger empfehlen wir wie immer eine fallbezogene rechtliche Prüfung.
Eine erfolgreiche Looker-Einführung folgt einem bewährten Muster, das die Modellierung in den Mittelpunkt stellt – und nicht das Tool selbst.
