Google Cloud Data Lakehouse: Architektur für hybride Daten

Im heutigen Finanzumfeld, und insbesondere im Hypothekensektor, liegt der wahre Wert nicht nur in strukturierten Datenbanken, sondern in einer oft ungenutzten Goldgrube: unstrukturierten Dokumenten. Gehaltsabrechnungen, Immobiliengutachten, Notarverträge und Ausweisdokumente bilden das, was oft als Dark Data bezeichnet wird. Die Herausforderung für CTOs und Datenarchitekten im Jahr 2026 besteht nicht mehr nur darin, diese Dateien zu archivieren, sondern sie in Echtzeit zusammen mit Transaktionsdaten abfragbar zu machen.

In diesem technischen Artikel untersuchen wir, wie man eine Google Cloud Data Lakehouse-Architektur entwirft und implementiert, die in der Lage ist, die Silos zwischen dem Data Lake (wo die PDFs liegen) und dem Data Warehouse (wo die CRM-Daten liegen) aufzubrechen. Wir nutzen die Leistung von BigQuery, die Intelligenz von Document AI und die prädiktiven Fähigkeiten von Vertex AI, um einen manuellen Prüfungsprozess in eine automatisierte und sichere Pipeline zu verwandeln.

Das Data-Lakehouse-Paradigma im Fintech

Traditionell unterhielten Banken zwei getrennte Stacks: einen Data Lake (z. B. Google Cloud Storage) für Rohdateien und ein Data Warehouse (z. B. Legacy-SQL-Datenbanken oder frühe MPPs) für Business Intelligence. Dieser Ansatz führte zu Datenduplizierung, hoher Latenz und Informationsdiskrepanzen.

Das Data Lakehouse auf der Google Cloud Platform (GCP) löst dieses Problem, indem es ermöglicht, im Objektspeicher archivierte Dateien so zu behandeln, als wären sie Tabellen einer relationalen Datenbank, wobei jedoch die niedrigen Speicherkosten und die hohe Leistung des Warehouse erhalten bleiben.

Schlüsselkomponenten der Architektur

• Google Cloud Storage (GCS): Die physische Speicherebene für Dokumente (PDF, JPG, TIFF).
• BigQuery (BQ): Das Herzstück des Lakehouse. Verwaltet sowohl strukturierte Daten (CRM) als auch Metadaten unstrukturierter Dateien über Object Tables.
• Document AI: Der Dienst für intelligente Dokumentenverarbeitung (IDP) zum Extrahieren von Schlüsselentitäten.
• Vertex AI: Für das Training von Kredit-Scoring-Modellen auf Basis vereinheitlichter Daten.

Phase 1: Architekturdesign und Ingestion

Der erste Schritt zum Aufbau eines effektiven Google Cloud Data Lakehouse besteht darin, die Ingestion-Ebene korrekt zu strukturieren. Wir laden nicht einfach nur Dateien hoch; wir bereiten den Boden für die Analyse vor.

Konfiguration der Object Tables in BigQuery

Seit den jüngsten GCP-Updates ermöglicht BigQuery das Erstellen von Object Tables. Dies sind schreibgeschützte Tabellen, die Dateien in einem GCS-Bucket abbilden. So können wir PDF-Gehaltsabrechnungen direkt in BigQuery sehen, ohne sie zu verschieben.

CREATE OR REPLACE EXTERNAL TABLE `fintech_lakehouse.raw_documents`
WITH CONNECTION `us.my-connection`
OPTIONS (
  object_metadata = 'SIMPLE',
  uris = ['gs://mutui-docs-bucket/*.pdf']
);

Mit dieser einzigen SQL-Anweisung haben wir unser Dokumentenarchiv per SQL zugänglich gemacht. Wir können Metadaten (Erstellungsdatum, Größe, Dateiname) abfragen, als wären es strukturierte Spalten.

Phase 2: Intelligente Extraktion mit Document AI und Remote Functions

Es reicht nicht, die Dateien in BigQuery aufzulisten. Wir müssen ihren Inhalt lesen. Hier kommt die Integration zwischen BigQuery und Document AI über Remote Functions ins Spiel.

Anstatt komplexe ETL-Pipelines mit Dataflow oder externen Python-Skripten zu erstellen, können wir das Extraktionsmodell direkt aus einer SQL-Abfrage aufrufen. Stellen wir uns vor, wir müssten das "Nettoeinkommen" und den "Arbeitgeber" aus Gehaltsabrechnungen extrahieren.

1. Erstellung des Document AI Prozessors

In der GCP-Konsole konfigurieren wir einen Lending Document Splitter & Parser (spezifisch für den Hypothekensektor) oder einen Custom Extractor, der auf spezifische Gehaltsabrechnungen trainiert ist.

2. Implementierung der Remote Function

Wir erstellen eine Cloud Function (Gen 2), die als Brücke fungiert. Diese Funktion empfängt den Datei-URI von BigQuery, ruft die Document AI API auf und gibt ein JSON-Objekt mit den extrahierten Entitäten zurück.

3. Extraktion via SQL

Jetzt können wir unsere Rohdaten anreichern, indem wir sie in strukturierte Informationen umwandeln:

CREATE OR REPLACE TABLE `fintech_lakehouse.extracted_income_data` AS
SELECT
  uri,
  remote_functions.extract_entities(uri) AS json_data
FROM
  `fintech_lakehouse.raw_documents`
WHERE
  content_type = 'application/pdf';

Das Ergebnis ist eine Tabelle, die den Link zum Originaldokument und eine Spalte JSON mit den extrahierten Daten enthält. Das ist die wahre Stärke des Google Cloud Data Lakehouse: unstrukturierte Daten werden on-the-fly in strukturierte Daten umgewandelt.

Phase 3: Datenmodellierung und Schema-Optimierung

Wie sollen wir die Daten speichern, sobald sie extrahiert sind? Im Hypothekenkontext ist Flexibilität entscheidend, aber die Abfrageleistung hat Priorität.

Hybrider Ansatz: Strukturierte Spalten + JSON

Wir raten davon ab, jedes einzelne extrahierte Feld vollständig in eine eigene Spalte zu überführen, da sich Dokumentformate ändern. Der beste Ansatz ist:

• Core-Spalten (Strukturiert): Akten-ID, Steuernummer, Monatseinkommen, Einstellungsdatum. Diese Spalten müssen typisiert sein (INT64, STRING, DATE), um schnelle Joins mit CRM-Tabellen zu ermöglichen und Speicherkosten zu optimieren (BigQuery Capacitor-Format).
• Payload-Spalte (JSON): Der gesamte Rest der Extraktion (kleinere Details, Randnotizen) verbleibt in einer Spalte vom Typ JSON. BigQuery unterstützt nativ den Zugriff auf JSON-Felder mit einer effizienten Syntax.

Beispiel einer vereinheitlichten analytischen Abfrage:

SELECT
  crm.customer_id,
  crm.risk_score_preliminare,
  docs.reddito_mensile,
  SAFE_CAST(docs.json_payload.dettagli_extra.bonus_produzione AS FLOAT64) as bonus
FROM
  `fintech_lakehouse.crm_customers` crm
JOIN
  `fintech_lakehouse.extracted_income_data` docs
ON
  crm.tax_code = docs.codice_fiscale
WHERE
  docs.reddito_mensile > 2000;

Phase 4: Sicherheit und DSGVO-Compliance (Row-Level Security)

Da wir sensible Daten wie Einkommen und Gutachten verarbeiten, ist Sicherheit keine Option. Die DSGVO schreibt vor, dass der Zugriff auf personenbezogene Daten auf das unbedingt notwendige Personal beschränkt sein muss.

In einem Google Cloud Data Lakehouse ist es nicht notwendig, separate Views für jede Benutzergruppe zu erstellen. Wir nutzen die Row-Level Security (RLS) von BigQuery.

Implementierung der Zugriffsrichtlinien

Nehmen wir an, wir haben zwei Benutzergruppen: Risikoanalysten (vollständiger Zugriff) und Handelsvertreter (Zugriff beschränkt auf eigene Akten).

CREATE ROW ACCESS POLICY commercial_filter
ON `fintech_lakehouse.extracted_income_data`
GRANT TO ('group:agenti-commerciali@banca.it')
FILTER USING (agente_id = SESSION_USER());

Mit dieser Richtlinie filtert BigQuery bei Ausführung eines SELECT * durch einen Vertreter automatisch die Ergebnisse und zeigt nur die Zeilen an, bei denen die agente_id dem eingeloggten Benutzer entspricht. Die sensiblen Daten anderer Kunden bleiben unsichtbar, was die Einhaltung der Vorschriften ohne Datenduplizierung gewährleistet.

Phase 5: Prädiktives Credit Scoring mit Vertex AI

Die letzte Meile unseres Lakehouse ist die Aktivierung der Daten. Jetzt, da wir Verhaltensdaten (Zahlungshistorie aus dem CRM) mit realen Einkommensdaten (aus Gehaltsabrechnungen extrahiert) verknüpft haben, können wir überlegene Machine-Learning-Modelle trainieren.

Durch die Nutzung von Vertex AI integriert mit BigQuery können wir ein logistisches Regressionsmodell oder ein neuronales Netz erstellen, um die Ausfallwahrscheinlichkeit (PD) vorherzusagen.

1. Feature Engineering: Wir erstellen einen View in BigQuery, der CRM- und Dokumententabellen verbindet.
2. Training: Wir nutzen CREATE MODEL direkt in SQL (BigQuery ML) oder exportieren das Dataset für AutoML nach Vertex AI.
3. Prediction: Das trainierte Modell kann jede Nacht im Batch-Verfahren aufgerufen werden, um den Risikoscore aller offenen Akten neu zu berechnen und Anomalien zwischen dem erklärten Einkommen und dem aus Dokumenten extrahierten Einkommen zu melden.

Fazit

Die Implementierung eines Google Cloud Data Lakehouse im Hypothekensektor verändert die Arbeitsweise radikal. Es geht nicht nur um Technologie, sondern um Geschäftsgeschwindigkeit: von Tagen zu Minuten für die Vorabgenehmigung einer Hypothek.

Die vorgestellte Architektur, basierend auf der engen Integration von BigQuery, GCS und Document AI, bietet drei unmittelbare Wettbewerbsvorteile:

1. Vereinheitlichung: Eine einzige Quelle der Wahrheit für strukturierte und unstrukturierte Daten.
2. Automatisierung: Reduzierung menschlicher Eingriffe bei der Datenextraktion (Data Entry).
3. Compliance: Granulare Zugriffskontrolle nativ in der Datenbank.

Für Finanzinstitute, die auf das Jahr 2026 und darüber hinaus blicken, stellt diese Konvergenz zwischen Dokumentenmanagement und Datenanalyse den De-facto-Standard dar, um in einem zunehmend von Algorithmen gesteuerten Markt wettbewerbsfähig zu bleiben.

Häufig gestellte Fragen

Quellen und Vertiefung

1. BaFin – Aufsichtliche Beurteilung von Cloud-Diensten im Finanzsektor
2. BSI – Anforderungskatalog C5 (Cloud Computing Compliance Criteria Catalogue)
3. Wikipedia – Definition und Architekturkonzept des Data Lakehouse (Englisch)
4. Wikipedia – Definition von Dark Data in der Informationsverarbeitung

Francesco Zinghinì

Elektronikingenieur mit der Mission, die digitale Welt zu vereinfachen. Dank seines technischen Hintergrunds in Systemtheorie analysiert er Software, Hardware und Netzwerkinfrastrukturen, um praktische Leitfäden zu IT und Telekommunikation anzubieten. Er verwandelt technische Komplexität in für alle zugängliche Lösungen.

LinkedInFacebookVollständige Biografie →