Der entscheidende Unterschied zu klassischem Machine Learning lässt sich in einem Satz fassen: Das Modell kommt zu den Daten, nicht die Daten zum Modell. Wer schon einmal ein ML-Projekt im Mittelstand begleitet hat, weiß, wie viel Reibung allein dadurch entsteht, dass Daten erst aus dem operativen System extrahiert, transformiert, in eine Notebook-Umgebung geladen und nach dem Training wieder integriert werden müssen. BigQuery ML streicht diesen gesamten Daten-Pendelverkehr.
Praktisch sieht das so aus: Wer in BigQuery bereits eine Tabelle mit historischen Verkaufszahlen hat, schreibt eine Abfrage, die mit dem Schlüsselwort CREATE MODEL beginnt – und BigQuery trainiert daraufhin im Hintergrund ein Modell, ganz ohne dass eine Zeile Python geschrieben werden muss. Anschließend ruft man Vorhersagen mit einer Funktion wie ML.PREDICT ab, wieder per SQL. Wer SELECT, JOIN und GROUP BY beherrscht, hat damit fast schon die Grundlagen, um ein erstes Vorhersagemodell zu bauen.
Drei Eigenschaften definieren BigQuery ML:
Die ehrliche Antwort lautet: für Unternehmen, die zwei Voraussetzungen erfüllen. Erstens, die Daten liegen bereits in BigQuery oder lassen sich mit vertretbarem Aufwand dorthin bringen. Zweitens, es gibt im Haus mindestens eine Person, die solides SQL beherrscht – typischerweise im Controlling, im Reporting, in der BI-Abteilung oder im Data Engineering. Sind diese beiden Bedingungen erfüllt, ist BigQuery ML oft der wirtschaftlich naheliegendste Weg, um die erste produktive Vorhersage zu bauen, ohne ein komplettes Data-Science-Team aufzustellen.
Weniger geeignet ist BigQuery ML, wenn die Daten verteilt in vielen Quellsystemen liegen und nie konsolidiert wurden, wenn es im Haus keinerlei SQL-Kompetenz gibt oder wenn von Anfang an hochspezialisierte Modelle mit Echtzeit-Anforderungen im Millisekundenbereich gefragt sind. In diesen Fällen lohnt zunächst die Arbeit am Datenfundament beziehungsweise der direkte Schritt zu spezialisierten Plattformen.
BigQuery ML steht nicht allein, sondern ist Teil eines abgestuften Angebots. BigQuery selbst ist das Data Warehouse – der Ort, an dem strukturierte Daten gespeichert und abgefragt werden. BigQuery ML setzt direkt darauf auf und bringt SQL-basiertes Modelltraining hinzu. Darüber liegt Vertex AI, Googles vollwertige ML-Plattform für anspruchsvolle, individuell entwickelte Modelle. Und quer dazu steht die Gemini-Modellfamilie, die generative KI bereitstellt und über definierte Schnittstellen auch aus BigQuery heraus nutzbar ist. Wer dieses Stufenmodell versteht, trifft die richtigen Werkzeug-Entscheidungen – darauf kommen wir in Kapitel 05 ausführlich zurück.
Im klassischen Machine Learning durchläuft ein Projekt einen typischen Zyklus: Daten werden aus dem Quellsystem extrahiert, in eine Data-Science-Umgebung geladen, dort bereinigt und aufbereitet, das Modell wird mit Python und einem ML-Framework trainiert, evaluiert und schließlich als Dienst bereitgestellt. Erst dann lassen sich Vorhersagen abrufen – oft müssen die Ergebnisse wieder zurück ins Warehouse oder ins operative System geschrieben werden. Jeder dieser Übergänge kostet Zeit, schafft Fehlerquellen und erzeugt zusätzliche Datenkopien.
BigQuery ML kollabiert diese Kette. Daten, Training, Evaluation und Vorhersage finden im selben System statt, gesteuert durch dieselbe SQL-Oberfläche. Der Effekt ist mehr als eine reine Bequemlichkeit – er hat handfeste Konsequenzen für Governance, Geschwindigkeit und Qualität.
Der Verzicht auf Datenbewegung klingt zunächst nach einer technischen Randnotiz, ist aber in der Praxis einer der stärksten Argumente für BigQuery ML. Jede Datenkopie ist ein Governance-Risiko: Sobald personenbezogene oder geschäftskritische Daten ein kontrolliertes System verlassen und auf Laptops, in Notebook-Umgebungen oder in temporäre Buckets wandern, wird die Nachverfolgbarkeit schwierig. Wo liegt die Kopie? Wer hat Zugriff? Wird sie nach dem Projekt gelöscht? Diese Fragen entfallen weitgehend, wenn die Daten das Warehouse nie verlassen.
Hinzu kommt die Konsistenz: Modelle werden auf exakt denselben Daten trainiert, die auch für das Reporting verwendet werden. Es gibt keine Diskrepanz zwischen der „Wahrheit im Warehouse“ und einer veralteten Kopie im Notebook. Auch die Zugriffssteuerung bleibt erhalten – die Berechtigungen, die in BigQuery für eine Tabelle gelten, gelten implizit auch für die ML-Funktionen, die auf diese Tabelle zugreifen.
Für die Werkzeugwahl ist eine einfache Frage entscheidend: Gibt es eine bekannte Zielgröße, die das Modell vorhersagen soll? Wenn ja – etwa der tatsächliche Umsatz oder die historische Information, welche Kunden gekündigt haben –, spricht man von überwachtem Lernen. Regression und Klassifikation gehören in diese Kategorie. Sie sind in der Regel der einfachste Einstieg, weil das Erfolgskriterium klar ist: Das Modell soll möglichst nah an der bekannten Wahrheit liegen.
Gibt es keine solche Zielgröße, sondern soll das Modell selbst Struktur in den Daten finden, handelt es sich um unüberwachtes Lernen. Clustering ist das Paradebeispiel: Man kennt die Segmente vorher nicht, sondern lässt das Modell ähnliche Datensätze gruppieren. Das ist konzeptionell anspruchsvoller, weil das Ergebnis interpretiert werden muss – ein Cluster ist erst dann wertvoll, wenn das Fachteam erkennt, was die Gruppe inhaltlich verbindet.
Für Teams ohne tiefes ML-Wissen bietet BigQuery ML automatisierte Modelltypen, bei denen das System selbst eine passende Modellarchitektur auswählt und optimiert. Das nimmt den Druck, sich von Anfang an für einen konkreten Algorithmus entscheiden zu müssen. Der Preis dafür ist eine geringere Kontrolle und – je nach Datenmenge – ein höherer Rechenaufwand. Unsere Empfehlung in der Praxis: für die allerersten Gehversuche und zum Verständnis des Datenpotenzials sind diese automatisierten Optionen hervorragend, für den produktiven Dauerbetrieb lohnt sich später meist der Umstieg auf einen bewusst gewählten, schlankeren Modelltyp.
Konkret funktioniert das über sogenannte „Remote-Modelle“: In BigQuery wird ein Verweis auf ein in Vertex AI bereitgestelltes Modell angelegt. Anschließend lässt sich dieses Modell wie eine Funktion in SQL aufrufen. Eine Abfrage kann damit beispielsweise über Tausende von Freitext-Kundenkommentaren laufen und für jeden Eintrag eine Zusammenfassung, eine Stimmungsbewertung oder eine Kategorie erzeugen – alles in einer einzigen, vertrauten Abfrage und ohne dass die Texte das Warehouse verlassen.
Der praktische Reiz liegt darin, generative KI auf strukturierte und unstrukturierte Daten in großem Maßstab anzuwenden, ohne eine separate Anwendung bauen zu müssen. Typische Muster aus der Praxis:
So elegant die Integration ist, sie ersetzt keine durchdachte KI-Anwendung. Wer Gemini massenhaft über Millionen Zeilen laufen lässt, erzeugt entsprechend hohe Kosten und Laufzeiten – generative Modelle sind deutlich rechenintensiver als ein einfaches Regressionsmodell. Außerdem gelten dieselben grundsätzlichen Vorbehalte wie bei jeder generativen KI: Die Ausgaben müssen auf Korrektheit geprüft werden, sie können Fehler enthalten, und für rechtlich oder sicherheitskritisch sensible Auswertungen braucht es einen menschlichen Kontrollschritt. BigQuery ML macht den Zugang einfach – die Verantwortung für sinnvolle Anwendung bleibt beim Unternehmen.
BigQuery ML spielt seine Stärken dort aus, wo die Daten bereits in BigQuery liegen, ein SQL-affines Team vorhanden ist und ein gängiger Anwendungsfall – Forecasting, Churn, Segmentierung – schnell zu einem ersten Ergebnis geführt werden soll. Es ist außerdem hervorragend für die Exploration: Bevor ein Unternehmen in ein aufwendiges ML-Projekt investiert, lässt sich mit überschaubarem Aufwand prüfen, ob in den Daten überhaupt vorhersagbares Signal steckt. Diese „Machbarkeitsprüfung mit Bordmitteln“ ist einer der unterschätztesten Nutzen von BQML.
Vertex AI – Googles vollwertige ML-Plattform – wird relevant, sobald die Anforderungen über das hinausgehen, was sich elegant in SQL abbilden lässt. Das ist typischerweise der Fall bei eigenen, hochspezialisierten Modellarchitekturen, bei sehr großen Deep-Learning-Modellen, bei strengen Echtzeit-Anforderungen mit niedriger Latenz und überall dort, wo ein professioneller Modell-Lebenszyklus mit Versionierung, Monitoring und automatisiertem Retraining gefragt ist. Der gute Übergang: Was in BigQuery ML beginnt, lässt sich oft in Vertex AI weiterführen, weil beide Teil desselben Google-Cloud-Ökosystems sind und auf denselben Daten arbeiten.
Klassisches ML mit Python und eigenen Frameworks behält seine Berechtigung dort, wo maximale Freiheit, Plattformunabhängigkeit oder sehr spezielle wissenschaftliche Modelle gefragt sind. Für den Mittelstand mit einem ersten produktiven Anwendungsfall ist es allerdings selten der pragmatischste Startpunkt.
Aus unserer Erfahrung scheitern ML-Projekte selten an der Technik und fast immer an einem zu großen ersten Schritt. Deshalb empfehlen wir, mit genau einem klar umrissenen Anwendungsfall zu beginnen, der drei Eigenschaften hat: Die nötigen Daten liegen bereits in BigQuery, das Ergebnis ist für eine konkrete Abteilung sofort nützlich, und der Erfolg ist messbar. Eine Absatzprognose für eine wichtige Produktgruppe oder eine Churn-Vorhersage für ein Abo-Geschäft erfüllen diese Kriterien typischerweise gut.
Der entscheidende Punkt ist nicht die Genauigkeit des allerersten Modells, sondern der organisatorische Lerneffekt: Das Team erlebt, wie aus Daten eine Vorhersage wird, wie sie ins Tagesgeschäft kommt und welche Datenlücken sichtbar werden. Dieser erste Durchlauf ist die Grundlage für alles Weitere – und mit BigQuery ML ist er in Wochen statt Monaten machbar.
Das klingt trivial, ist aber in der Praxis oft die größte Hürde. BigQuery ML arbeitet auf Daten, die im Warehouse liegen – verteilte Daten in ERP, CRM, Onlineshop und diversen Excel-Inseln helfen zunächst nicht weiter. Bevor ein Modell trainiert werden kann, müssen die relevanten Datenquellen zuverlässig und regelmäßig nach BigQuery überführt werden. Für Unternehmen, die ohnehin schon mit BigQuery als zentralem Analyse-Warehouse arbeiten, ist diese Voraussetzung erfüllt. Für andere ist der Aufbau dieser Datenbasis der eigentliche erste Schritt – und er lohnt sich, weil davon auch das gesamte Reporting profitiert.
BigQuery ML ist genau dann ein Geschenk, wenn es Menschen gibt, die SQL beherrschen – und genau dann nutzlos, wenn niemand im Haus mit Datenbanken umgehen kann. Die gute Nachricht: Diese Kompetenz ist in vielen Unternehmen bereits vorhanden, oft im Controlling, in der BI- oder Reporting-Abteilung. Wer komplexe Auswertungen mit JOINs und Aggregationen bauen kann, hat die wesentliche Grundlage. ML-spezifisches Wissen – welcher Modelltyp passt, wie interpretiere ich die Evaluation – lässt sich darauf aufbauend in überschaubarer Zeit ergänzen, oft im Rahmen eines begleiteten ersten Projekts.
Dies ist der am häufigsten unterschätzte Punkt. Ein Modell lernt aus den Daten, die es bekommt – Fehler, Lücken und Verzerrungen inklusive. Wenn historische Verkaufsdaten unvollständig sind, wenn Kundendatensätze doppelt vorliegen oder wenn wichtige Felder oft leer bleiben, wird auch das beste Modell unzuverlässige Vorhersagen liefern. Datenqualität ist kein nachträglicher Feinschliff, sondern Voraussetzung. In vielen unserer Projekte fließt ein erheblicher Teil des Aufwands in die Datenbereinigung und -aufbereitung – und das ist gut investierte Zeit, weil sie über Erfolg oder Misserfolg entscheidet.
Über die technischen Punkte hinaus braucht es eine klare Verantwortlichkeit: Wer pflegt das Modell, wer prüft die Ergebnisse, wer entscheidet, wann ein Modell neu trainiert werden muss? Modelle altern – verändert sich das Geschäft, das Kundenverhalten oder der Markt, verlieren sie an Genauigkeit. Eine erfolgreiche Einführung plant deshalb von Anfang an mit, wie ein Modell regelmäßig überprüft und aufgefrischt wird. Das muss nicht aufwendig sein, aber es muss jemand zuständig sein.
Im Kern zahlt man bei BigQuery für zwei Dinge: für das Speichern der Daten im Warehouse (Storage) und für das Rechnen – also für die Verarbeitungsleistung, die Abfragen und Modelltraining verbrauchen (Compute). Beim Machine Learning kommt die Rechenkomponente besonders zum Tragen, denn Modelltraining ist deutlich rechenintensiver als eine normale Abfrage.
Die gute Nachricht: Bei den klassischen ML-Anwendungsfällen – Forecasting, Churn, Segmentierung auf normalen Mittelstands-Datenmengen – bewegen sich die Kosten meist in einem überschaubaren Rahmen, gerade im Vergleich zum Aufwand eines eigenen Data-Science-Setups. Entscheidend ist eine bewusste Steuerung. In unseren Projekten setzen wir auf einige bewährte Prinzipien:
Unter dem Strich gilt: BigQuery ML ist kein Werkzeug mit unkalkulierbaren Kosten – aber eines, das eine bewusste Kostensteuerung verlangt. Wer von Anfang an mit Budgets und eingegrenzten Abfragen arbeitet, behält die Ausgaben gut im Griff.
Auch mit europäischer Datenresidenz bleibt Google Cloud ein US-Konzern und unterliegt damit grundsätzlich US-Recht, etwa dem US Cloud Act. Die Wahl einer EU-Region und ein sauberer Auftragsverarbeitungsvertrag reduzieren das Risiko erheblich, beseitigen es aber nicht vollständig. Für die meisten Mittelständler mit nicht-hochsensiblen Daten ist dieses Restrisiko bei sauberer Konfiguration in der Praxis vertretbar. Für besonders sensible Datenkategorien, Berufsgeheimnisträger oder kritische Infrastrukturen ist eine sorgfältige Einzelfallbewertung – idealerweise mit dem Datenschutzbeauftragten und juristischer Begleitung – unverzichtbar.
Eine erfolgreiche Einführung folgt einem klaren, abgestuften Vorgehen – mit Fokus auf Datenfundament, einem fokussierten Pilotfall und sauberer Governance.
