Multi-Source-Daten-JOIN im Browser: Spar dir die Python-Pipeline

Dein Analyst muss eine Frage beantworten: Welche Produkte aus unserem Katalog sind bei den Lieferanten, von denen wir letztes Quartal bestellt haben, aktuell ausverkauft, und wie viel Umsatz droht uns zu entgehen?

Diese Frage zu beantworten erfordert drei Datenquellen: deinen Produktkatalog (eine CSV), deine Lieferanten-Bestellungen (ein Datenbank-Export) und live Lieferanten-Inventar (eine API). In einem normalen Daten-Stack heißt diese zu joinen: Python-Skript schreiben, Virtual-Environment einrichten, drei Quellen in Pandas-DataFrames laden, Merge-Logik für jeden Join schreiben, dtype-Mismatches handhaben und ein Resultat ausspucken, das in deiner Terminal-Session lebt, bis du es in noch eine Datei exportierst.

Das ist eine Zwei-Stunden-Aufgabe für jemanden, der mit Python komfortabel ist. Für einen Business-Analysten, der primär in SQL und Spreadsheets arbeitet, kann es einen Tag dauern — oder er eskaliert ans Engineering.

In Harbinger Explorer ist es eine SQL-Query im Browser.

TL;DR

• Multi-Source-Joins kosten ohne SQL-Engine viel Zeit (Python: ~1–2h)
• Heterogene Quellen (Files + APIs + DBs) sind das Hauptproblem
• Harbinger Explorer: DuckDB-SQL-Engine, alle Quellen als Tabellen, voller JOIN-Support im Browser
• Speicherbare Queries → einmaliger Aufwand wird wiederkehrender Report

Selbst testen — Kostenlos loslegen. Keine Kreditkarte. 8 Demo-Datenquellen ready to query.

Warum Multi-Source-Daten-Joins heute so schmerzhaft sind

Das Heterogene-Daten-Problem

Moderne Business-Daten leben nicht an einem Ort. Tun sie nie und werden sie nie. Eine typische Analyse umfasst:

• Files: CSVs aus Exports, Excel-Sheets von Partnern, JSON-Dumps aus Legacy-Systemen
• APIs: REST-Endpoints von SaaS-Tools, CRM-Systemen, Finanzdaten-Providern, internen Microservices
• Datenbanken: PostgreSQL-Exports, BigQuery-Tabellen, SQLite-Dumps, Parquet-Files

Jede dieser Quellen hat eigenes Format, eigene Auth, eigene Schema-Konventionen. Sie zu joinen verlangt einen Layer, der all diese Sprachen gleichzeitig spricht.

Die "Ich mach das eben mit VLOOKUP"-Falle

Nicht-technische Analysten bei Multi-Source-Joins greifen oft zu Excel oder Google Sheets. Sie exportieren alles als CSV, öffnen in Sheets, bauen VLOOKUP-Ketten. Funktioniert für kleine Datensätze (paar tausend Zeilen), bricht schnell:

• VLOOKUP ist one-directional und gibt nur den ersten Match zurück
• Many-to-Many-Joins unmöglich ohne Helper-Spalten
• Sheets mit 100k+ Zeilen werden schmerzhaft langsam
• Resultierende Formeln sind unmöglich zu auditieren oder zu reproduzieren

Warum Python nötig ist — aber nicht sein sollte

Python mit Pandas ist das richtige Tool für komplexe Large-Scale Multi-Source-Joins. Aber es sollte nicht das einzige sein. Wenn ein Analyst eine einfache Business-Frage zu zwei Datenquellen beantworten muss, ist ein Python-Environment hochzuziehen und ein 50-Zeilen-Skript zu schreiben massive Friction.

Zeit-Budget:

• 5 Min: Virtual-Environment anlegen und aktivieren
• 10 Min: Dependencies installieren
• 15 Min: Datenquellen laden und inspizieren
• 20 Min: Merge-Logik schreiben und debuggen
• 10 Min: dtype- und Null-Issues handhaben
• 15 Min: Output validieren

Das ist über eine Stunde Setup und Boilerplate, bevor du die Business-Frage beantwortet hast.

Der SQL-Vorteil

SQL wurde für Joins designt. Das gesamte relationale Modell baut auf der Idee, Daten aus mehreren Tabellen über geteilte Keys zu kombinieren. Eine Datenbank mit ordentlicher Indizierung joint Millionen Zeilen in Millisekunden. Und SQL ist die Lingua Franca der Datenanalyse — viel mehr Analysten kennen SQL als Python.

Das Problem ist nicht SQL. Das Problem ist, deine heterogenen Daten in eine SQL-Engine zu kriegen, ohne erst ein ganzes Data-Warehouse zu bauen.

Welche Multi-Source-Join-Tools existieren aktuell

Apache Spark / Databricks

Für Enterprise-Scale Joins über mehrere große Quellen ist Spark das richtige Tool. Daten aus S3, Delta Lake, APIs und mehr laden und mit Spark-SQL joinen. Resultate sind production-grade.

Setup-Overhead signifikant: Spark-Cluster, Cluster-Config, Data-Engineering-Team zur Wartung, signifikante Infrastruktur-Kosten. Keine Lösung für Ad-hoc-Analyse durch Business-Analysten.

dbt (data build tool)

dbt ist exzellent für strukturierte, versions-kontrollierte Daten-Transformations-Pipelines. Modelle in SQL definieren, ketten, gegen Data-Warehouse laufen lassen. Richtiger Ansatz für wiederkehrende, governed Transformations.

Nicht der richtige Ansatz für Ad-hoc-Multi-Source-Joins: laufendes Warehouse, dbt installiert, Modelle schreiben können nötig.

Google Sheets + ImportJSON / ImportRange

Power-User in Sheets nutzen Custom-Functions, um API-Daten zu pullen und mit Sheet-Daten zu kombinieren. Funktioniert für simple Fälle aber hat schwere Limits: Rate-Limits, Row-Limits, Formel-Komplexität, keine ordentliche JOIN-Semantik.

Python + Pandas in Jupyter

Häufigster Ansatz für Analysten mit Python-Skills. Flexibel, mächtig. Aber braucht Python-Wissen, Environment-Management und produziert Resultate, die ohne Re-Run des Notebooks nicht teilbar sind.

Der bessere Ansatz: SQL-JOINs über jede Datenquelle im Browser

Harbinger Explorer bietet eine SQL-Query-Engine (auf Basis von DuckDB), die jede registrierte Datenquelle als querbare Tabelle behandelt. Files, APIs, gecrawlte Web-Daten — alle zugänglich in derselben SQL-Query, mit vollem JOIN-Support, in deinem Browser.

Kein Python. Keine ETL-Pipeline. Kein Datenbank-Cluster. Quellen registrieren, SQL schreiben, Antworten kriegen.

Wie Multi-Source-Joins in Harbinger Explorer funktionieren

Schritt 1: Alle Quellen registrieren

Jede Datenquelle zu Harbinger Explorer hinzufügen:

• CSV- und Excel-Dateien direkt hochladen
• API-Endpoint-URLs einfügen (mit Auth-Headern falls nötig)
• AI Crawler für strukturierte Web-Daten nutzen

Jede Quelle wird gecrawlt, Schema inferiert und als benannte Tabelle verfügbar gemacht.

Schritt 2: JOIN-Query schreiben

Im Harbinger-Explorer-Query-Editor Standard-SQL-JOINs über deine Quellen schreiben. Die Business-Frage von oben — Produkte mit Risiko durch Lieferanten-Stockouts — wird:

SELECT
  pc.product_id,
  pc.product_name,
  pc.category,
  pc.price,
  so.quantity_ordered,
  so.order_date,
  si.current_stock AS supplier_current_stock,
  pc.price * so.quantity_ordered AS revenue_at_risk
FROM product_catalog pc
JOIN supplier_orders so
  ON pc.product_id = so.product_id
  AND so.order_date >= CURRENT_DATE - INTERVAL '90 days'
JOIN supplier_inventory_api si
  ON so.supplier_id = si.supplier_id
  AND pc.product_id = si.product_id
WHERE si.current_stock = 0
ORDER BY revenue_at_risk DESC

Hier ist product_catalog eine hochgeladene CSV, supplier_orders ein Datenbank-Export-File und supplier_inventory_api eine Live-API-Quelle. Der JOIN funktioniert über alle drei nahtlos.

Schritt 3: Laufen lassen und analysieren

Query läuft in DuckDB, einer der schnellsten Analytical-SQL-Engines verfügbar, und gibt Resultate in Sekunden zurück. Du kannst sofort weitere SQL-Filter, Aggregationen oder Window-Functions anwenden:

WITH at_risk AS (
  -- die Query oben
),
by_category AS (
  SELECT
    category,
    COUNT(*) AS products_at_risk,
    SUM(revenue_at_risk) AS total_revenue_at_risk
  FROM at_risk
  GROUP BY category
)
SELECT
  category,
  products_at_risk,
  total_revenue_at_risk,
  ROUND(total_revenue_at_risk * 100.0 / SUM(total_revenue_at_risk) OVER (), 1) AS pct_of_total
FROM by_category
ORDER BY total_revenue_at_risk DESC

Schritt 4: Speichern und teilen

Query mit beschreibendem Namen speichern. Jeder im Team mit Harbinger-Explorer-Zugriff kann sie laufen lassen und dieselben Resultate kriegen. Kein "schick mir dein Python-Skript". Kein "welche Version vom Notebook?". Die Query ist die Single Source of Truth.

Pricing: Starter 8 €/Monat (25 Chats/Tag, 10 Crawls/Monat) oder Pro 24 €/Monat (200 Chats/Tag, 100 Crawls/Monat, Recrawling, Priority-Support). Preise →

Kostenloser 7-Tage-Trial. Kostenlos starten →

Advanced Multi-Source-Join-Patterns

FULL OUTER JOINs für Daten-Abgleich

Beim Abgleich zweier Quellen — was ist in einer, aber nicht der anderen — nutze FULL OUTER JOIN:

SELECT
  COALESCE(a.customer_id, b.customer_id) AS customer_id,
  a.customer_name AS name_in_crm,
  b.customer_name AS name_in_billing,
  CASE
    WHEN a.customer_id IS NULL THEN 'Nur in Billing'
    WHEN b.customer_id IS NULL THEN 'Nur in CRM'
    ELSE 'In Beiden'
  END AS reconciliation_status
FROM crm_customers a
FULL OUTER JOIN billing_customers b ON a.customer_id = b.customer_id
WHERE a.customer_id IS NULL OR b.customer_id IS NULL
ORDER BY reconciliation_status

Dieser Reconciliation — Diskrepanzen zwischen zwei Systemen finden — ist einer der häufigsten Multi-Source-Join-Use-Cases und braucht normalerweise Python oder dediziertes ETL.

Window-Functions über gejointen Quellen

Sobald deine Daten gejoint sind, lassen Window-Functions dich Kontext hinzufügen, ohne Zeilen zu kollabieren:

SELECT
  s.sale_id,
  s.amount,
  c.customer_tier,
  c.country,
  AVG(s.amount) OVER (PARTITION BY c.country) AS avg_sale_by_country,
  s.amount - AVG(s.amount) OVER (PARTITION BY c.customer_tier) AS vs_tier_average,
  RANK() OVER (PARTITION BY c.country ORDER BY s.amount DESC) AS rank_in_country
FROM sales s
JOIN customers c ON s.customer_id = c.customer_id

Column Mapping für Cross-Source-Key-Alignment

Reale Datenquellen nutzen oft verschiedene Namen für dasselbe Konzept: customer_id, cust_id, CustomerID, id. Harbinger Explorers Column-Mapping definiert kanonische Namen und mappt Varianten dorthin.

API-Daten mit historischen Files joinen

Besonders mächtiges Pattern: Live-API-Daten gegen historische Archive joinen. Z. B. aktuelle Marktpreise aus einer API gegen ein historisches CSV deiner Portfolio-Positionen:

SELECT
  p.ticker,
  p.shares_held,
  p.average_cost,
  mp.current_price,
  p.shares_held * mp.current_price AS current_value,
  p.shares_held * (mp.current_price - p.average_cost) AS unrealized_pnl,
  ROUND((mp.current_price - p.average_cost) / p.average_cost * 100, 2) AS pct_return
FROM portfolio_csv p
JOIN market_prices_api mp ON p.ticker = mp.symbol
ORDER BY unrealized_pnl DESC

Dieser Join — historisches File plus Live-API — produziert eine Real-time-Portfolio-P&L-Sicht ohne Infrastruktur jenseits von Harbinger Explorer.

Häufige Fehler bei Multi-Source-Joins

Fehler 1: Spalten mit verschiedenen Datentypen joinen Wenn customer_id in einer Quelle als Integer und in einer anderen als String gespeichert ist, gibt der Join still null Zeilen zurück. Immer Typen vor Join prüfen:

SELECT TYPEOF(customer_id) AS type, COUNT(*) FROM source_a GROUP BY 1
UNION ALL
SELECT TYPEOF(customer_id) AS type, COUNT(*) FROM source_b GROUP BY 1

Explizit casten falls nötig: CAST(a.customer_id AS VARCHAR) = b.customer_id

Fehler 2: DISTINCT vergessen bei One-to-Many Wenn Source B mehrere Zeilen pro Customer hat, multipliziert ein INNER JOIN mit Source A Zeilen. Row-Count vor und nach Join prüfen:

SELECT COUNT(*) FROM source_a;  -- erwartet: N Zeilen
SELECT COUNT(*) FROM source_a JOIN source_b ON ...;  -- viel größer als N → Fan-Out-Join

Fehler 3: INNER JOIN statt LEFT JOIN INNER JOIN dropt Zeilen aus der linken Tabelle ohne Match. Wenn du alle Zeilen aus der linken Tabelle behalten willst (mit Nulls für fehlende Matches), nutze LEFT JOIN.

Fehler 4: Join-Key-Eindeutigkeit nicht validieren Vor dem Joinen prüfen, dass dein Join-Key tatsächlich eindeutig ist in der Tabelle, in der du ihn eindeutig erwartest:

SELECT customer_id, COUNT(*) AS occurrences
FROM customers
GROUP BY customer_id
HAVING COUNT(*) > 1

Feature-Vergleich

FAQ

Wie viele Quellen kann ich in einer Query joinen? DuckDB (die Engine in Harbinger Explorer) unterstützt JOINs über so viele Tabellen, wie deine Query verlangt. In der Praxis joinen die meisten Analysen 2–5 Quellen. Kein künstliches Limit.

Funktioniert es mit großen Files? Harbinger Explorer handhabt Files bis zu mehreren hundert MB effizient. DuckDB ist für Analytics-Workloads designt und performt gut auf großen Datensätzen.

Können nicht-technische User JOIN-Queries schreiben? Harbinger Explorer hat einen AI-Assistant, der SQL aus Natural Language generiert. Auf Deutsch beschreiben ("zeig mir Produkte aus dem Katalog, die null Stock im Lieferanten-Inventar haben") und die KI schreibt das SQL.

Welche File-Formate werden unterstützt? CSV, JSON, Excel (XLSX), Parquet und mehr. API-Quellen unterstützen Standard-REST-JSON-Responses.

Real-World Case Study: Procurement-Team joint drei Quellen für Einsparungen

Ein Procurement-Team in einem Fertigungs-Unternehmen musste Kosteneinsparungs-Chancen über ihre Lieferanten-Beziehungen identifizieren. Die Daten lebten an drei Orten:

1. Lieferanten-Stammdaten: CSV-Export aus dem ERP mit Lieferanten-Namen, -Tiers, Zahlungsbedingungen und Kategorie-Codes
2. Bestell-Historie: Datenbank-Export (CSV) mit allen POs der letzten zwei Jahre
3. Benchmark-Pricing-API: Third-Party Commodity-Pricing-API für aktuelle Marktraten

Die Frage: "Welche Komponenten kaufen wir über Marktrate, von welchen Lieferanten, und wie hoch ist der Gesamt-Mehrausgaben?"

In ihrem vorherigen Workflow:

1. ERP-Daten als CSV exportieren
2. Datenbank-Export ziehen
3. Python-Skript schreiben, das beide lädt und die Pricing-API für jede eindeutige Komponenten-SKU callt
4. Drei Datensätze in Pandas mergen
5. Mehrausgaben pro Position berechnen
6. Nach Excel für Category-Manager exportieren

Dauerte ca. drei Stunden inklusive Debugging.

In Harbinger Explorer lud der Analyst die zwei CSVs hoch, registrierte die Pricing-API und schrieb:

WITH po_with_market AS (
  SELECT
    po.po_id,
    po.supplier_id,
    po.component_sku,
    po.quantity,
    po.unit_price AS negotiated_price,
    mp.market_unit_price,
    po.quantity * po.unit_price AS total_paid,
    po.quantity * mp.market_unit_price AS market_value,
    po.quantity * (po.unit_price - mp.market_unit_price) AS overspend
  FROM purchase_orders po
  JOIN market_prices_api mp ON po.component_sku = mp.sku
  WHERE po.order_date >= CURRENT_DATE - INTERVAL '365 days'
    AND po.unit_price > mp.market_unit_price
),
supplier_summary AS (
  SELECT
    s.supplier_name,
    s.supplier_tier,
    s.category_code,
    COUNT(DISTINCT pwm.component_sku) AS overpriced_components,
    SUM(pwm.total_paid) AS total_paid,
    SUM(pwm.market_value) AS market_equivalent,
    SUM(pwm.overspend) AS total_overspend,
    ROUND(SUM(pwm.overspend) / SUM(pwm.total_paid) * 100, 1) AS overspend_pct
  FROM po_with_market pwm
  JOIN supplier_master s ON pwm.supplier_id = s.supplier_id
  GROUP BY s.supplier_name, s.supplier_tier, s.category_code
)
SELECT *
FROM supplier_summary
WHERE total_overspend > 10000
ORDER BY total_overspend DESC

Query lief in vier Sekunden. Gesamtzeit von "Files hochladen" zu "Resultat vor dem Category-Manager": 25 Min, inklusive Zeit zum SQL-Schreiben.

Die gespeicherte Query wurde zu einem wiederkehrenden Report: jeden Monat läuft der Analyst sie gegen aktualisierte Exports und die Live-API.

Das Procurement-Team identifizierte 340.000 € jährliche Mehrausgaben über drei Lieferanten-Beziehungen in der ersten Analyse — was Jahre von Harbinger-Explorer-Abos im ersten Monat amortisierte.

Fazit

Multi-Source-Daten-Joins sind eine der häufigsten analytischen Tasks und eine der friction-schwersten. Die Wahl zwischen "zwei Stunden Python schreiben" und "mit VLOOKUP approximieren" ist eine falsche Dichotomie. Harbinger Explorer gibt dir eine dritte Option: SQL im Browser schreiben, über jede Kombination von Files und APIs, und Antworten in Minuten kriegen.

Stand: 14. Mai 2026.