Google Next 2026 für die Datenverarbeitung: Looker, BigQuery und MCP-Server.

Google Cloud Next 2026 in Las Vegas fand in dem Umfang statt, den die Marke verspricht, mit Keynotes und Sessions in einem riesigen Veranstaltungsort. Für alle, die Looker- oder BigQuery-Projekte umsetzen, waren die Vorträge zu Analytik, Datenintegration und agiler Analytik besonders wichtig. Im Folgenden werden die Ankündigungen aufgelistet, die die Vorgehensweise bei solchen Projekten in den nächsten zwölf Monaten verändern werden, anschließend werden Erkenntnisse aus den Gesprächen mit Kunden dargestellt, die sich als nützlicher erwiesen als die meisten Produktneuigkeiten.

Der Ansatz: Vom Antworten zum Handeln

Googles allgemeine Botschaft für Analytik- und Datenplattformen ist ein Wandel von einem „System der Intelligenz“ zu einem „System des Handelns“. Das erste ist reaktive Business Intelligence, die auf Anfrage antwortet. Das zweite sind proaktive Agenten, die Metriken überwachen, ihre Erkenntnisse zusammenfassen und im Interesse des Unternehmens handeln.

Im Grunde ist nichts davon neu. ereignisgesteuerte Benachrichtigungen und automatisierte Reaktionen gibt es bereits seit zwanzig Jahren in den BI-Toolkits für Unternehmen. Dennoch leistet die erneute Betonung dieser Aspekte nützliche Arbeit, denn sie verändert, was zum Umfang eines im Jahr 2026 in Auftrag gegebenen Looker-Projekts gehört.

Daraus ergibt sich eine praktische Konsequenz für alle, die eine Auftragsbeschreibung verfassen. Früher bestanden die Liefergegenstände ausschließlich aus Berichten und Dashboards. Heute muss die Diskussion auch darüber geführt werden, wer oder was die Daten verarbeitet (Menschen oder Agenten), welche Fragen die Agenten eigenständig beantworten sollen und wer die Geschäftsregeln zertifiziert, auf denen diese Agenten angewiesen sind. Projekte, die diese Diskussion überspringen, entdecken sie in der Regel später, mitten in der Umsetzung, zu höheren Kosten.

Agentic Data Cloud und ihre drei Konzepte

Der Hauptvortrag konzentrierte sich auf den Agentic Data Cloud, Googles Lösung für ein Ungleichgewicht: Die für Menschen entwickelten Tools zur Datenverständnis waren nie für eine Welt gedacht, in der KI-Agenten selbstständig auf diese Daten reagieren. Drei Grundsätze stützen dieses Konzept.

Agenten benötigen neben Daten auch Bedeutungsinformationen. Es ist ein teures Wagnis, einen leistungsstarken Agenten auf Rohdaten anzuwenden in der Hoffnung, dass er die Geschäftsprozesse selbst entschlüsselt. Er muss lernen, dass „Nettoeinnahmen“ keine Renditen berücksichtigen, dass eine Kennzahl in zwei Geschäftseinheiten unterschiedlich berechnet wird oder dass eine Klausel in einem Vertrag die Routenplanung von Lieferungen verändert. Der Knowledge Catalog soll dieses institutionelle Wissen erfassen und kontinuierlich aufrechterhalten, damit jeder Agent, der mit den Daten arbeitet, von derselben standardisierten Verständnisbasis ausgeht.

Agenten müssen handeln, nicht nur Berichte erstellen. Ein Beispiel aus einer Konferenz: Anstatt eines Dashboards, das einen Anstieg bei Stornierungen anzeigt, bemerkt ein Agent diesen Anstieg, führt eine Ursachenanalyse anhand von Logistik- und Verkaufsdaten durch, identifiziert das zuständige Verteilzentrum, empfiehlt eine Umleitung und startet einen Überwachungsmechanismus, um zu beobachten, wann sich die Situation verbessert. Niemand musste darum bitten.

Die Daten bleiben dort, wo sie sind. Cloud-Plattformen verlangen seit Langem, dass alles an einen Ort verschoben wird, bevor ein Nutzen entsteht. Hier können Agenten die Daten dort abrufen, wo sie sich befinden – egal ob auf Google Cloud, AWS, Azure, Snowflake, Databricks oder lokalen Systemen – ohne vorherige kostspielige Migration.

Looker als semantische und benutzererfahrungsorientierte Schicht

Praktisch ausgedrückt vereint der Agentic Data Cloud BigQuery, den Knowledge Catalog, Gemini und Looker, wobei Looker als Benutzeroberflächenschicht fungiert und alle vier Komponenten als ein System statt als getrennte Produkte arbeiten. Konversationelle Analytik, Dashboard-Agenten, ausgelöste Workflows sowie weitere Funktionen von Looker sind die Mittel, über die diese Architektur die Nutzer erreicht – an diesem Punkt spüren die Menschen den Unterschied zwischen BI, das nur Berichte liefert, und BI, das auch handelt.

Das neue Explore geht noch einen Schritt weiter. Das alte Modell mit Feldauswahl und Filtern wird durch eine visuelle, drag-and-drop-basierte Benutzeroberfläche ersetzt, die dem Design von Google Search oder Google Docs ähnelt. Darin sind drei Gemini-Assistenten integriert: Einer dient zum Navigieren mittels natürlicher Sprache, ein anderer erstellt Looker-Expressionen aus gewöhnlichem Englisch und ein weiterer wählt den geeigneten Diagrammtyp für die gestellte Frage aus.

Für Lieferteams bedeutet dies weniger Zeit, die Menschen Schritt für Schritt durch die Visualisierungsschicht zu führen, und mehr Zeit für die Qualität sowie die semantische Korrektheit von LookML im Hintergrund, da die Assistenten auf der Grundlage dessen handeln, was das Modell definiert. Eine nachlässig gestaltete semantische Schicht führt zu nachlässigen Antworten – und das nun in konversationaler Skala.

Dashboard Agents sind im Allgemeinen verfügbar. Dashboards sind nicht mehr statische, nur zur Übertragung bestimmter Informationen dienende Artefakte: Nutzer können sie befragen, Zusammenfassungen von Inhalten und Änderungen anfordern sowie im Gespräch die Gründe hinter Zahlen erfragen. Das stärkste Unternehmensbeispiel stammt von YouTube, wo Partnermanager nach Portfolios von Kreativen in fünfzehn zusammengeführten Datenquellen fragen – und das alles über ein scheinbar gewöhnliches Looker-Dashboard.

Die ausgelösten Workflows verwandeln Agenten von passiven Reagierenden in proaktive Überwacher. Metriken werden rund um die Uhr überwacht, und Teams erhalten sofortige Benachrichtigungen, sobald ein Schwellenwert überschritten wird. Der kurzfristige Entwicklungsplan beinhaltet Agenten, die eigenständig E-Mails verfassen oder in Slack posten. Für die operative Analytik ist das wertvoller, als es klingt, und es handelt sich dabei um eine Anforderung, die Kunden vor zwei Jahren noch nicht hatten.

Weitere Ankündigungen von Looker verdienen Erwähnung:

• Looker-Agenten innerhalb von Gemini Enterprise. In Looker erstellte Agenten können in Gemini Enterprise veröffentlicht und zusammen mit anderen Unternehmensagenten verwaltet werden. Für Kunden, die dort investieren, wird Looker zu einem Teil einer umfassenderen KI-Strategie anstelle eines eigenständigen BI-Tools.
• Conversational Analytics API, jetzt GA. Es verfügt über eine native Integration mit dem Looker SDK, die Einbettung in Iframes sowie eine Open-Source-Referenzimplementierung. Teams, die konversationelle Analysen in ihren eigenen Anwendungen einbinden möchten, haben nun einen unterstützten Weg, und Gespräche, die aufgrund der Vorabversion der API gestoppt wurden, können wieder aufgenommen werden.
• LookML Agent für VS Code (Vorabversion). Eine Erweiterung, die den gesamten LookML-Lebenszyklus ab der natürlichen Sprache abdeckt.
• Looker MCP als offener Standard. Es gibt einen verwalteten MCP-Server neben Open-Source-Optionen über das MCP Toolbox. Die Verbindung von Looker mit Assistenten wie Claude ermöglicht eine umfassendere Analyse sowie agierendes Denken, das über die alleinige Funktionsfähigkeit von Looker hinausgeht.
• Integrationen in die native semantische Schicht. Looker liest die Graphendefinitionen von BigQuery sowie die semantischen Ansichten von Snowflake direkt, sodass die bereits in BigQuery vorhandene semantische Logik nicht mehr in LookML neu erstellt werden muss.
• Mehrfach-Explorations-Agenten. Ein Agent kann gleichzeitig bis zu fünf Explorationsvorgänge nutzen. Yahoos Konfiguration kombiniert HR-, Finanz-, Such- und Support-Daten in einzelnen Agenten über mehrere Looker-Instanzen hinweg.

Was Yahoo und Virgin Media O2 gelernt haben

Die Sitzungen zur konversationalen Analyse von Yahoo und Virgin Media O2 erwiesen sich als wertvollstes Hilfsmittel für diejenigen, die diese Arbeit durchführen. Die wichtigste Erkenntnis: Die Genauigkeit hängt hauptsächlich von zwei Faktoren ab – den sogenannten „Golden Queries“ sowie den in YAML geschriebenen Anweisungen für die Agenten. Yahoo stellte nach dem Umstieg der Agentenanweisungen von JSON auf YAML bessere Ergebnisse fest. Anschließend verlegten sie die „Golden Queries“ sowie das Geschäftslexikon in LookML, anstatt sie an anderer Stelle zu belassen, was die Komplexität der Anweisungen erheblich verringerte, da das Modell nun auf der semantischen Ebene statt auf manuell eingetragenen Kontexten arbeitet.

Yagos eigene Zusammenfassung war der zitierwertigste Satz der Veranstaltung: Die konversationalen Analysen beginnen mit der semantischen Ebene und nicht mit der KI. Sobald Daten und Modelle bereit sind, stellt die konversationalen Analyse fast den nächsten Schritt in der Entwicklung dar.

Die praktische Vorgehensweise für Teams bedeutet einen Wandel in der Arbeitsweise. Das Schreiben langer, sorgfältig abgestimmter Anweisungen an die Agenten weicht dem Aufwerten des Modells selbst, denn alles, was in LookML platziert wird, steht jedem Agenten und jedem Benutzer zur Verfügung, während Inhalt in Anweisungen nur einem Agenten dient und stillschweigend veraltet.

Dadurch hat sich ein gutes LookML-Modell für konversationelle Analysen verändert. Die Grundausstattung umfasst nun Labels, Beschreibungen, Synonyme und Kommentare zu jedem Feld, in LookML eingebettete „goldene Abfragen“ sowie ein YAML-basiertes Geschäftslexikon innerhalb des Modells. Die Anweisungen an die Agenten bleiben absichtlich einfach, da die semantische Schicht die Hauptarbeit übernimmt. Die Einrichtung von Dashboard-Agenten, ausgelösten Workflows sowie „goldenen Abfragen“ sollte nun zum Standardbestandteil jeder ernsthaften Looker-Anforderung gehören und nicht auf einer Liste optionaler Zusatzfunktionen stehen.

Data Studio kehrt zurück

Looker Studio wurde in Data Studio umbenannt und hat nun ein erweitertes Aufgabenspektrum. Es verarbeitet nun drei Arten von Artefakten. Der erste sind die bekannten Berichte oder Dashboards, die aus BigQuery, Google- sowie Partner-SaaS-Connectoren oder der Looker-Semantikschicht stammen. Der zweite ist ein konversationeller Analyseagent, der in BigQuery entwickelt und dort veröffentlicht wurde. Der dritte ist die neue Konzeption der „Data Apps“, bei der Colab-Notebooks als interaktive Anwendungen veröffentlicht werden.

Data Apps liegen zwischen einem Dashboard und einer vollständigen Anwendung. Sie eignen sich für Kunden, die auf Looker für operative Berichterstattung angewiesen sind, mehr Interaktivität wünschen und keine vollständige eingebettete Anwendung in Auftrag geben möchten.

Eine Folge der Markenüberarbeitung sowie der neuen Self-Service-Funktionen ist folgende: Das integrierte „Studio in Looker“, das einst als Zukunft der Benutzeroberfläche von Looker beworben wurde, steht Organisationen, die es nicht aktiviert hatten, nicht mehr zur Verfügung, und es soll am 15. Juni 2026 ausgemustert werden.

BigQuery: Datenengineering-Agenten und ein verwalteter MCP-Server

Ein großer Teil der Vorabversionen vom letzten Jahr ist nun in die allgemeine Verfügbarkeit übergegangen. Dazu gehören die Agenten für Datenengineering und Datenwissenschaft, die konversationelle Analytik innerhalb von BigQuery sowie dessen API, das BigQuery ADK, ein verwalteter Remote-MCP-Server für BigQuery, das Open-Source-MCP-Toolbox sowie ein Plugin, das Telemetriedaten über die Leistung der Agenten sammelt.

Einige der neueren Funktionen sind wichtiger, als es auf den ersten Blick scheint.

Flüssige Skalierung. BigQuery fügt Rechenleistung hinzu, wenn die Agenten aktiv sind, und entfernt sie, wenn sie inaktiv sind – ohne manuelle Anpassung der Größe. Der gängige Einwand bezüglich der Kosten für skalierbare konversationelle Analysen wird dadurch erheblich schwächer.

BigQuery Graphs. Ein natives Graphen-Engine ohne ETL-Schritt, das sich auf Milliarden von Knoten skalieren lässt und ISO GQL unterstützt. Die besonders interessante Erweiterung sind die Measures in BigQuery Graph, die regulierte Metriken mit Beziehungsabbildungen verknüpfen und es den Agenten ermöglichen, über mehrstufige Abhängigkeiten nachzudenken.

Maße als Erweiterungen des Schlussfolgerungsvermögens. Eine nützliche Methode, um die beiden Arten von Maßen voneinander zu unterscheiden: LookML-Maße steuern die Berechnung, indem sie definieren, was eine Metrik bedeutet, und eine konsistente SQL-Abfrage für jeden Analysten und Agenten, der Looker verwendet, gewährleisten. Graphen-Maße steuern das Schlussfolgern, indem sie dieselben Metrikdefinitionen innerhalb eines Graphen verbundener Entitäten wie Produkte, Lieferanten, Knotenpunkte und Routen platzieren, sodass ein Agent nachvollziehen kann, warum sich eine Metrik verändert hat, indem er die Beziehungen zwischen den Einflussfaktoren verfolgt.

Migrationsdienste

Der BigQuery Migration Service wurde in Data Analytics Migration Services umbenannt, und es handelt sich um eine umfassende Überarbeitung. Daher sollten alle, die 2026 einen Umstieg von Snowflake, Cloudera oder Databricks planen, ihre Entscheidung neu überdenken. Bei Cloudera und Databricks erfolgt die Bewertung automatisch und liefert einen Entwurf mit einer Auflistung der Arbeitslasten samt Schätzungen der Gesamtkosten. SQL aus Hive, Snowflake und anderen Dialekten wird auf Compilerebene in GoogleSQL übersetzt. Die Migration von Lakehouse-Strukturen umfasst Iceberg-, Parquet- und Hive-Tabellen, und ein Validierungsdienst prüft dabei jede Tabelle sowie jede Spalte auf Genauigkeit. Da die Migration-APIs über MCP erreichbar sind, könnte ein Tool wie Claude Code die gesamte Migration orchestrieren.

Frühere Versionen des Services zeigten bei der komplexen Übersetzung von SQL unterschiedliche Leistungen, während die neue Generation deutlich leistungsfähiger erscheint. Das Validierungs-Dashboard ist besonders hervorzuheben, da es viele manuelle Überprüfungen übernimmt, die seit Jahren die Migrationspläne verzögern. Teams, die zuvor Wochenplanungen für Analysten vorgenommen hatten, um Zeilenzahlen und Spaltenwerte manuell zu vergleichen, sollten diese Schätzungen überdenken.

Föderierung über Clouds hinweg

Was die Föderierung angeht, so kann der Databricks Unity Catalog auf AWS S3 nun in beide Richtungen gelesen werden, und Snowflake Polaris sowie AWS Glue können ebenfalls von BigQuery ausgelesen werden. Alles basiert auf dem Apache Iceberg REST-Katalogstandard, sodass BigQuery diese externen Kataloge direkt abfragen kann, ohne dass Daten verschoben werden müssen.

Für Kunden, die nicht oder nicht vollständig migrieren können oder wollen, ändert sich der Ansatz. Anstatt darauf zu bestehen, dass alle Daten in BigQuery übertragen werden, lautet das Angebot nun: Lassen Sie die Daten an ihrem ursprünglichen Ort, greifen Sie darauf über BigQuery zu und setzen Sie darüber Looker sowie Conversational Analytics ein. Snowflake-Kunden, die sonst von einem auf GCP ausgerichteten Analyseansatz ausgeschlossen würden, erhalten somit eine echte Alternative, die vermutlich als Sprungbrett für vollständigere Migrationen dient.

Lektionen aus der Migration bei Target, Wells Fargo und Virgin Media O2

Ein Panel mit diesen drei Unternehmen zeigte Muster auf, die viele Menschen auf die harte Tour gelernt haben, aber dennoch erwähnt werden sollten.

Regel eins – und die wichtigste: Bringen Sie zunächst die semantische Schicht in Betrieb. Errichten Sie die Looker- oder BI-Schicht auf GCP, damit Geschäftsbenutzer auf die Daten zugreifen können, während die Datenverarbeitung noch im Gange ist, und überbrücken Sie die Lücke mit taktischen Replikationsaufgaben, die wichtige Datensätze in BigQuery kopieren. Virgin Media O2 hat dies durch sechs umfangreiche Plattformmigrationen geschafft, und Wells Fargo hat diesen Ansatz befürwortet.

Weitere Muster:

• Verringern Sie den Datenumfang vor der Migration. KI kann im Voraus ungenutzte und doppelte Daten erkennen; ein Unternehmen im Panel stellte fest, dass über 80 Prozent seiner Daten dupliziert waren.
• Migrieren Sie zunächst und modernisieren Sie anschließend. Refaktorisieren während der Migration verzögert den Zeitplan unvorhersehbar.
• Etablieren Sie von Anfang an eine Governance. Datenverträge, ein Geschäftslexikon sowie Regeln zur Datenqualität gehören zum Migrationsprogramm, da deren Einführung später oft fehlschlägt, sobald die politische Chance verstrichen ist.
• Beginnen Sie mit Datenverträgen schrittweise. Wählen Sie einen begrenzten Bereich aus, erstellen Sie für diesen Fall klare Verträge mit Lieferanten und Empfängern und nutzen Sie diese als Vorbild dafür, wie gute Verträge aussehen, bevor Sie skalieren.

Target hat außerdem einen nützlichen Begriff vorgeschlagen, den man übernehmen kann: „irrationale Ziele“. Wählen Sie Ziele, die nur erreicht werden können, wenn die Plattform um Methoden, die auf KI basieren, neu aufgebaut wird. Dadurch verschiebt sich die Diskussion von der Frage, wie man migriert, hin zur Frage, wie man transformiert.

Data Agent Kit

In der Vorschau verbindet das Data Agent Kit eine VS Code-Erweiterung mit Plugins für Gemini CLI, Cloud Code und Codex. Gemeinsam bieten sie Fähigkeiten sowie MCP-Tools für Datenworkflows in BigQuery: agentebasierte Fähigkeiten, MCP-Server, Tools zur Anbindung an BigQuery sowie Plugins für eine tiefgreifende Anpassung von VS Code. Die Fähigkeiten selbst sind open source und können angepasst werden.

Beratungsfirmen und Kundenteams, die bereits interne Tools für agentebasierte Arbeitsabläufe entwickeln, sollten dieses Produkt ernsthaft prüfen. Es umfasst laut ersten Einschätzungen die Entwicklung auf BigQuery-Ebene und ergänzt umfassendere Orchestrierungslösungen sowie LookML – und passt somit zu bereits verwendeten fähigkeitsbasierten Ansätzen.

Knowledge Catalog, früher Dataplex, als Agent-Kontext

Dataplex ist nun Knowledge Catalog und dient als Kontext-Backend für agierende Workflows in Google Cloud. Drei Säulen stützen dieses System. Die erste sammelt Metadaten aus Google-Diensten, einschließlich Looker, sowie aus Partnerkatalogen wie Atlan, Collibra und SAP. Die zweite bereichert diese Metadaten durch automatische Erstellung sowie ein in der Produktionsumgebung verfügbares Geschäftslexikon. Die dritte bietet semantische Suche mithilfe einer Context API, über die Agenten das benötigte Wissen abrufen können.

Der aufschlussreichste Fall stammt von Bloomberg Media. Der „Knowledge Gap Agent“ lernt aus Fehlern der Agenten, erkennt Stellen, an denen der Datenkontext falsch oder fehlt, und schlägt Aktualisierungen für den Knowledge Catalog vor, die von Menschen geprüft werden müssen. Das Hauptergebnis: 102 Nutzungshinweise wurden automatisch in zwanzig MVP-Tabellen erstellt, wodurch die Genauigkeit eines Datenzugriffs-Agenten um 63 % gesteigert werden konnte.

Bei kleineren Projekten bleibt das Knowledge Catalog im Hintergrund aktiv. Für Kunden, die in großem Umfang analytische Agenten für konversationelle Anwendungen entwickeln und dabei institutionelles Wissen noch nicht an einem Ort kodifiziert haben, auf den die Agenten zugreifen können, stellt es das fehlende Element dar. Bloomberg bezeichnete dieses zugrundeliegende Problem als „42-Dollar-Problem“, das sowohl menschliche Analysten als auch KI-Agenten betrifft: Wissen, das in der Datenplattform nirgends dokumentiert ist.

In ihrem Beispiel wählte ein Junior-Analyst die richtigen Tabellen, schrieb gültigen SQL-Code und wendete die Standardlogik zur Berechnung des Nettoeinkommens an, erhielt jedoch das falsche Ergebnis. Der Zahlungsdienstleister erhebt eine Gebühr von 42 Dollar pro Kundenstreitigkeitsfall, und diese Gebühr muss in die Einkommensberechnung einbezogen werden. Die entsprechende Regel befand sich weder in irgendeinem Schema noch in irgendeinem Datenfluss und auch nicht in irgendeinem zugänglichen Dokument. Sie existierte lediglich auf einer Confluence-Seite aus dem Jahr 2017, deren Autor das Unternehmen bereits verlassen hatte.

Fehlt das semantische Engine?

Eine Kritik, die danach die Runde machte, besagt, Google setze voll auf die Agentenschicht, während sein semantischer und geschäftlicher Kontext im Vergleich schwach bleibe. Nach dieser Sichtweise ähnelt das Knowledge Catalog einem Metadaten-Aggregator und weist nur wenig von den Eigenschaften eines echten Unternehmensbetriebssystems wie OpenAI’s Frontier oder Palantir’s Foundry auf. Ohne einen leistungsstarken semantischen Motor, der geschäftliche Bedeutungen mit den Agenten verbindet, besteht selbst bei fortschrittlichen Werkzeugen die Gefahr, dass die Ergebnisse abweichen, Halluzinationen auftreten oder eine richtige Antwort auf die falsche Frage gegeben wird.

Der größte Teil dieser Diagnose bleibt zutreffend, und die semantische Schicht ist in einer agierenden Welt wichtiger als je zuvor in einer Dashboard-Welt. Die optimistischere Sichtweise ist, dass die semantische Schicht von LookML bereits den größten Teil der Aufgaben im Geschäftskontext abdeckt, die von einem Unternehmensbetriebssystem erwartet werden. Sie beseitigt das Problem mehrerer Wahrheiten, stellt definierte Metrikdefinitionen bereit und dient als zuverlässiger Metrikspeicher für Assistenten wie Claude über das MCP Toolbox.

Dass im Knowledge Catalog auf der Konferenz nur wenig über die Integration von LookML gesagt wurde, bedeutet nicht, dass LookML untätig ist. Die Arbeit findet auf einer Ebene statt, die unterhalb der liegt, an der Kritiker nach ihr suchen.

Der konkrete Beweis liegt in Googles dokumentierten Best Practices für die Konfiguration von Conversational Analytics in Looker. Dabei werden zwei Hauptquellen herangezogen: die Struktur, Felder, Labels, Beschreibungen und Synonyme im LookML-Modell sowie spezifische Feldwerte, die aus den Daten entnommen werden, wobei die Kardinalität (die Anzahl der eindeutigen Werte) bestimmt, wie diese Werte verwendet werden.

Zur Abfrage der eindeutigen Werte ruft Conversational Analytics die seit Langem verwendete Looker-API-Methode model_fieldname_suggestions auf. Dies ist derselbe Mechanismus hinter den Filtervorschlägen im Feldauswahler und Dashboard-Filtern, der nun als Grundsignal für das Modell wiederverwendet wird. Drei vorhandene LookML-Parameter, suggestions, suggest_explore und suggest_dimension, dienen somit gleichzeitig als Mittel für Entwickler, zu steuern, welche Werte Conversational Analytics kennt.

Teams müssen nicht darauf warten, dass das Produkt dies übernimmt; dieselbe Lösung kann auch manuell in einem BigQuery-Lager erstellt werden. Neben einem standardmäßigen Datendictionary, das aus INFORMATION_SCHEMA abgeleitet wird, kann man ein Markdown-Leitfaden pflegen, der einem Assistenten als Fähigkeit zur Verfügung gestellt wird und regelmäßig durch einen Profilierungsschritt erneuert wird. Dieser beschreibt jede Tabelle mit Zeilenzahlen, Datumsbereichen sowie den Wertmengen und Kardinalitäten von kategorischen Feldern mit hohem Signalwert, sodass der Assistent beispielsweise weiß, dass eine Nachrichtentabelle sich in bekannten Proportionen auf iMessage, Slack, WhatsApp und andere aufteilt, anstatt zu raten.

Conversational Analytics erledigt nun das Äquivalente auf der LookML-Ebene und ist somit für alle Looker-Nutzer verfügbar. Nehmen wir eine city-Dimension, die aus Kundendaten oder Betriebsdaten stammt. Das System wählt dabei die eindeutigen Werte aus, wie zum Beispiel Brighton, Hove und London, und lässt die Kardinalität bestimmen, wie stark jeder Wert bei der Beantwortung von Fragen berücksichtigt werden soll.

Die wichtigsten Einstellmöglichkeiten für einen LookML-Entwickler sind diese drei Parameter, die wie folgt verwendet werden:

view: customer {
  dimension: city {
    label: "Customer City"
    description: "The city associated with the customer's primary address. Most operational activity occurs in Brighton and Hove (UK head office) and London (UK secondary office)."
    type: string
    sql: ${TABLE}.customer_city ;;
    # Hard-code a curated list of values rather than letting Looker
    # run SELECT DISTINCT against a large table.
    suggestions: ["Brighton", "Hove", "London", "Edinburgh", "Manchester"]
  }
  dimension: customer_segment {
    label: "Customer Segment"
    description: "Customer tier based on annual recurring revenue."
    type: string
    sql: ${TABLE}.segment ;;
    # Pull suggestions from another view rather than scanning
    # the much larger customer fact table.
    suggest_explore: segments
    suggest_dimension: segments.segment_name
  }
}

In Kombination mit Beschreibungen, Synonymen sowie einigen in das Modell eingebetteten „goldenen“ Abfragen bietet LookMLs semantische Schicht genau das, was Kritiker von einem Unternehmensbetriebssystem erwarten: einen fundierten, regulierten Geschäftskontext für die Agentenschicht sowie eine kartellitätsbewusste Stichprobenziehung realer Werte – alles aus derselben LookML-Struktur, die hinter Dashboards und Explorern verwendet wird.

Daher unterscheidet sich die Wahrnehmung von Knowledge Catalog und LookML voneinander. Derzeit erscheint LookML in der Architektur des Knowledge Catalog als nur eine von vielen Eingabemöglichkeiten, und es ist leicht nachvollziehbar, warum das als unzureichend gilt. In den nächsten zwölf bis achtzehn Monaten wird sich dies voraussichtlich erheblich ändern, da Google allen Grund hat, LookML zur wichtigsten Eingabemöglichkeit des Catalogs zu machen und nicht nur zu einer von mehreren.

Der semantische Engine, nach der die Kritiker rufen, fehlt eigentlich nicht, denn der größte Teil davon existiert bereits in LookML. Unklar bleibt, ob Knowledge Catalog zu einer Geschäftskontextschicht heranreift, die die Bedeutung von LookML durch den gesamten agilen Stack trägt, oder ob ein anderes Produkt diese Rolle übernimmt. In jedem Fall lohnt sich die Zeit, die man in die Optimierung von LookML investiert.

Verwandte Artikel

• Praktische Anmerkungen: RAG ist tot. Die LLM-Wiki sowie Andrej Karpathys Idee – das, was als Nächstes kommt: Detaillierte Anleitung zu „Praktische Anmerkungen: RAG ist tot. Die LLM-Wiki sowie Andrej Karpathys Idee – das, was als Nächstes kommt“, einschließlich Verträgen, Überprüfungen und Code-Blöcken für Teams, die RAG einsetzen.

Spring AI im Unternehmensumfeld: Ein Support-Agent mit Tools, RAG und Überprüfungsmöglichkeiten: Erstellen Sie einen Hilfsassistenten für die Priorisierung von Vorfällen mit Spring AI: Prompts als Verträge, strukturierte Ausgaben, Aufruf von Tools, MCP, Qdrant RAG, Überwachungsfunktionen sowie begrenzte Agentenschleifen.