WikiDBGraph: A Data Management Benchmark Suite for Collaborative Learning over Database Silos

Das Paper stellt WikiDBGraph vor, eine umfassende Benchmark-Suite aus 100.000 realen relationalen Datenbanken, die die Lücke zwischen theoretischen kollaborativen Lernansätzen und der praktischen Bewältigung unstrukturierter, fragmentierter Datensilos durch die Einbeziehung des gesamten Datenmanagement-Workflows aufzeigt.

Das Wesentliche

Hier ist eine einfache Erklärung der Forschungspaper "WikiDBGraph", erzählt wie eine Geschichte mit ein paar kreativen Vergleichen.

Das große Problem: Die isolierten Daten-Inseln

Stell dir vor, die Welt der Daten ist wie ein riesiger Archipel aus tausenden von kleinen Inseln. Jede Insel ist eine Datenbank, die von einer Organisation (z. B. einem Museum, einer Krankenkasse oder einer Stadtverwaltung) verwaltet wird.

Das Problem? Diese Inseln sind voneinander abgeschnitten. Sie sind wie "Daten-Silos".

• Die eine Insel hat tolle Informationen über alte Gebäude.
• Die andere hat Daten über historische Personen.
• Aber sie können nicht miteinander reden, weil sie ihre Sprache (das Datenformat) leicht unterschiedlich schreiben und niemand weiß genau, welche Inseln überhaupt in der Nähe liegen.

Wenn man versuchen will, eine künstliche Intelligenz (KI) zu bauen, die aus allen diesen Daten lernt, scheitert es oft daran, dass man die Daten nicht einfach zusammenwerfen kann, ohne die Privatsphäre der Inselbewohner zu verletzen.

Die Lösung: Ein neuer "Karten-Atlas" (WikiDBGraph)

Die Forscher haben sich gedacht: "Wir brauchen eine Landkarte, die uns zeigt, welche Inseln eigentlich Nachbarn sind, auch wenn sie sich nicht kennen."

Sie haben WikiDBGraph gebaut. Das ist im Grunde ein riesiger Atlas mit 100.000 Inseln (Datenbanken) und 17 Millionen Brücken (Verbindungen), die sie miteinander verknüpfen.

Wie haben sie das gemacht?
Stell dir vor, jede Insel hat einen "Fingerabdruck" (eine Art ID-Nummer). Früher dachten die Forscher nur an Inseln mit dem exakt gleichen Fingerabdruck. Aber das war zu wenig.
Also haben sie eine KI trainiert, die wie ein Detektiv arbeitet. Diese KI schaut sich die "Sprache" der Inseln an (welche Begriffe werden benutzt, welche Datenstrukturen gibt es?) und sagt: "Hey, obwohl diese beiden Inseln nicht den gleichen Namen tragen, sprechen sie fast dieselbe Sprache und gehören zum selben Thema!"

So haben sie Brücken gebaut, wo vorher keine waren.

Die drei großen Herausforderungen (Die "Dreiecks-Verwirrung")

Das Paper zeigt, dass das einfache "Zusammenwerfen" von Daten in der echten Welt viel schwieriger ist als in Lehrbüchern. Hier sind die drei Stolpersteine, die wie ein verrücktes Puzzle wirken:

1. Die "Nicht-Verbindbare" (Unjoinable):

   • Vergleich: Stell dir vor, du willst zwei riesige Bücher zusammenkleben, um ein dickeres zu machen. Aber eines der Bücher ist so groß, dass es den ganzen Raum füllt und du es gar nicht mehr bewegen kannst.
   • Realität: Viele Datenbanken sind so riesig, dass man sie technisch gar nicht zu einer einzigen Tabelle verschmelzen kann. Man muss sie getrennt lassen.

2. Die "Halb-Verbindbare" (Unaligned):

   • Vergleich: Stell dir vor, du hast zwei Kochbücher. In Buch A heißt das Kapitel "Zutaten für Pizza", in Buch B heißt es "Teig und Belag". Die Inhalte sind ähnlich, aber die Überschriften sind anders. Und in Buch A fehlen die Rezepte für die Soße, die in Buch B sind.
   • Realität: Die Datenbanken haben oft ähnliche Themen, aber die Spaltennamen sind unterschiedlich oder die Daten decken sich nur teilweise. Eine KI muss erst lernen, dass "Architekturstil" in Buch A dasselbe ist wie "Gebäudeart" in Buch B.

3. Die "Vernetzte" (Interconnected):

   • Vergleich: Früher dachte man, jede Insel ist ein einsamer Felsen. Jetzt sehen wir, dass sie ein komplexes Netz aus Brücken sind. Manche Inseln sind nur über eine kleine Hängebrücke verbunden, andere sind fest miteinander verschmolzen.
   • Realität: Datenbanken sind nicht isoliert. Sie hängen in einem riesigen Netzwerk zusammen. Um KI zu trainieren, muss man dieses Netzwerk verstehen, nicht nur die einzelnen Inseln.

Der Test: Funktioniert das in der Praxis?

Die Forscher haben diesen Atlas genutzt, um verschiedene KI-Methoden zu testen. Das Ergebnis war eine Mischung aus "Gut!" und "Noch nicht ganz":

• Das Gute: Wenn man die richtigen Inseln findet (die echten Nachbarn), kann die KI durch Zusammenarbeit (Collaborative Learning) viel besser lernen als wenn jede Insel allein arbeitet. Es ist wie ein Team von Detektiven, das gemeinsam einen Fall löst, statt dass jeder nur seinen eigenen Teil kennt.
• Das Schlechte: Die aktuellen KI-Methoden sind oft noch zu stur. Sie erwarten, dass die Daten perfekt sortiert sind. In der echten Welt ist das aber chaotisch. Wenn die Daten nicht perfekt "zusammengeklebt" werden (was sehr schwer ist), macht die KI oft mehr Fehler als wenn sie allein gearbeitet hätte.

Das Fazit

WikiDBGraph ist wie ein riesiger Kompass für die Zukunft der KI. Er zeigt uns:

1. Es gibt unendlich viele Daten, die wir gemeinsam nutzen könnten.
2. Aber wir müssen erst lernen, wie man diese Daten in ihrer chaotischen, unperfekten Form zusammenbringt, ohne die Privatsphäre zu verletzen.

Es ist ein Werkzeug, um die Lücke zwischen der schönen Theorie ("Lass uns alle Daten teilen!") und der harten Realität ("Oh nein, die Datenformate passen gar nicht!") zu schließen. Die Forscher sagen im Grunde: "Wir haben die Landkarte. Jetzt müssen wir die Brücken bauen."

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „WikiDBGraph: A Data Management Benchmark Suite for Collaborative Learning over Database Silos" auf Deutsch:

1. Problemstellung

Kooperatives Lernen (Collaborative Learning, CL), einschließlich Federated Learning (FL) und Split Learning (SL), verspricht, Modelle über verteilte Datenquellen hinweg zu trainieren, ohne Rohdaten auszutauschen. Trotz Fortschritten in Algorithmen und Benchmarks (z. B. LEAF, FedML) bleiben reale Bereitstellungen selten. Der Hauptgrund liegt in einer Lücke zwischen der aktuellen Forschung und der Realität:

• Irrealistische Annahmen: Bestehende Benchmarks gehen oft von isolierten, perfekt ausgerichteten (horizontal oder vertikal) und vollständig verknüpfbaren Datenbanken aus.
• Reale Komplexität: In der Praxis sind Datenbanken oft unstrukturiert, nicht perfekt ausgerichtet (Schema-Mismatch, unterschiedliche Spaltennamen), nur teilweise überlappend (sowohl in Instanzen als auch in Features) und aufgrund ihrer Größe oft nicht vollständig verknüpfbar (Joins sind rechnerisch unmöglich).
• Fehlende Graph-Struktur: Es fehlt an großen Datensätzen, die die tatsächlichen Beziehungen zwischen Datenbanken als Graph abbilden, anstatt sie als isolierte Einheiten zu betrachten.

2. Methodik: Aufbau von WikiDBGraph

Die Autoren stellen WikiDBGraph vor, einen groß angelegten, offenen Graphen von relationalen Datenbanken, der auf dem WikiDBs-Korpus (aus Wikidata extrahiert) basiert.

• Datengrundlage: Der Datensatz umfasst 100.000 reale relationale Datenbanken mit insgesamt 17 Millionen gewichteten Kanten, die Beziehungen zwischen diesen Datenbanken darstellen.
• Erkennung von Korrelationen (Contrastive Learning):
  • Da explizite Verknüpfungen zwischen Datenbanken im WikiDBs-Korpus selten sind (nur ~8.800 Paare von 100.000), wurde ein Contrastive-Learning-Ansatz entwickelt.
  • Datenbanken werden serialisiert (Name, Tabellennamen, Spaltennamen, repräsentative Stichprobenwerte) und in Textform gebracht.
  • Ein Embedding-Modell (basierend auf BGE-M3) wird trainiert, um die semantische Ähnlichkeit zwischen Datenbanken vorherzusagen. Positive Paare teilen dieselbe wikidata_topic_item_id (TID), negative Paare nicht.
  • Das Modell lernt implizite Korrelationen, die über die expliziten TIDs hinausgehen.
• Graph-Konstruktion:
  • Basierend auf den Embeddings wird ein Graph erstellt, wobei Knoten Datenbanken und Kanten deren Ähnlichkeit (gewichtete Kanten) darstellen.
  • Ein Schwellenwert ($\tau$) steuert die Dichte des Graphen.
• Anreicherung mit Metadaten: Jeder Knoten und jede Kante wird mit spezifischen Eigenschaften annotiert:
  • Knoten-Eigenschaften (13): Struktur (Anzahl Tabellen/Spalten, Fremdschlüssel-Dichte), Semantik (Topic-Cluster, Embeddings) und Statistik (Datenvolumen, Kardinalität, Sparsity).
  • Kanten-Eigenschaften (12): Strukturelle Ähnlichkeit (Jaccard-Indizes für Tabellen/Spalten), semantische Ähnlichkeit (Embedding-Similarity) und statistische Korrespondenz (KL-Divergenz, Overlap-Ratio).
• Automatisierte Evaluierungs-Pipeline: Um CL-Algorithmen zu testen, wurde eine Pipeline entwickelt, die:
  1. Ähnliche Datenbankpaare auswählt.
  2. Labels identifiziert und Tabellen per Foreign-Key-Links joinet (mit Memory-Limit).
  3. Spalten automatisch ausrichtet (Case-insensitive String-Matching).
  4. Daten standardisiert und für CL-Algorithmen (FedAvg, FedProx, SplitNN, etc.) aufbereitet.

3. Wichtige Beiträge

1. WikiDBGraph-Datensatz: Der erste groß angelegte Benchmark für kooperatives Lernen, der reale, vernetzte Datenbanken mit 100.000 Knoten und 17 Millionen Kanten abbildet. Er füllt die Lücke zwischen synthetischen Benchmarks und realen Daten-Silos.
2. Automatisierte CL-Pipeline: Ein End-to-End-Workflow, der die Herausforderungen der Datenvorbereitung (Schema-Matching, Joining, Alignment) in einem realistischen Szenario simuliert.
3. Umfassende Analyse und Fallstudien:
   • Identifikation von drei charakteristischen Merkmalen realer Daten: Interkonnektivität (Graph-Struktur), Hybrid-Ausrichtung (Mischung aus horizontaler und vertikaler Überlappung) und Nicht-Verknüpfbarkeit (wegen Datenvolumen).
   • Fallstudien zu reinem Feature-Overlap, reinem Instance-Overlap und komplexen Hybrid-Szenarien.

4. Ergebnisse

Die Experimente auf WikiDBGraph zeigen sowohl die Wirksamkeit als auch die Grenzen bestehender CL-Methoden:

• Leistungssteigerung vs. Solo: In automatisierten Tests verbesserten CL-Algorithmen die Leistung im Durchschnitt nur in weniger als 50 % der Fälle gegenüber dem Training auf isolierten Daten (Solo).
• Vergleich mit Zentrale: Es besteht eine signifikante Lücke zwischen den Ergebnissen von CL und einem zentralen Training (Combined), was auf die Schwierigkeit der Datenheterogenität (Non-IID) und vor allem auf Probleme in der Datenvorverarbeitung hinweist.
• Einfluss der Datenvorverarbeitung: Die automatische Spaltenausrichtung (String-Matching) führt oft zu Fehlern („Garbage in, Garbage out"). Ein Experiment mit semantisch bewusstem Alignment (DeepJoin) verbesserte die F1-Scores um 0,06–0,09, was zeigt, dass die Datenvorbereitung der kritische Engpass ist.
• Fallstudien-Erfolge:
  • Bei manuell kuratierten, gut ausgerichteten Paaren (Feature-Overlap) übertrafen FL-Methoden (FedAvg, FedProx) die Solo-Baselines deutlich, erreichten aber nicht das Niveau des zentralen Trainings.
  • Bei Instance-Overlap (Split Learning) zeigten sich signifikante Gewinne durch Feature-Erweiterung.
  • Graph-basiertes Lernen: Die Nutzung von Graph-Eigenschaften (Knoten- und Kantendaten) in personalisierten FL-Methoden (SFL) führte zu besseren Ergebnissen als Standard-FedAvg, wobei Kanten-Eigenschaften den größten Beitrag leisteten.
• Heterogenität: Die Analyse der Label-Verteilung zeigt eine „Long-Tail"-Heterogenität, wobei fast 25 % der Paare extrem nicht-IID verteilt sind ($\alpha < 1,0$).

5. Bedeutung und Ausblick

WikiDBGraph ist ein Meilenstein für die Forschung im Bereich des kooperativen Lernens, da es:

• Die Diskrepanz zwischen Algorithmus-Design und Datenmanagement aufdeckt. Es zeigt, dass reine Algorithmus-Optimierung ohne Berücksichtigung von Schema-Matching und Datenintegration nicht ausreicht.
• Ein realistisches Testfeld für die Entwicklung neuer CL-Systeme bietet, die mit unvollständigen, unalignierten und graphenbasierten Datenstrukturen umgehen können.
• Die Notwendigkeit für neue Algorithmen unterstreicht, die direkt mit relationalen Datenbanken arbeiten (statt auf vorverknüpfte Tabellen angewiesen zu sein) und semantisch robuste Schema-Matching-Verfahren integrieren.

Das Paper schließt damit, dass WikiDBGraph als entscheidende Benchmark dient, um die Lücke zwischen theoretischem Potenzial und praktischer Anwendbarkeit von Collaborative Learning in realen Daten-Silos zu messen und zukünftige Forschungsrichtungen zu lenken.