Marcel Moré stellte die neue XML-Konvertierungs-Engine von FM-Lab vor. Der Import des FileMaker-Strukturexports (Save a Copy as XML) war bisher der Flaschenhals des gesamten Analyse-Workflows – mit der neuen “Katana Engine” schrumpft er in einer großen Produktiv-Lösung von knapp einer Stunde auf unter zwei Minuten.

Das Problem: XML als Bremsklotz

FM-Lab basiert auf DuckDB, das große Datenmengen sehr effizient und multithreaded verarbeitet. Ausgerechnet beim XML-Import ging diese Rechnung bisher nicht auf – und das lag nicht an DuckDB selbst, sondern am zwischengeschalteten Webbed-Plugin, das die XML-Parser-Funktionalität beisteuert:

  • Kein Multithreading: Das Plugin zwingt die Verarbeitung in einen einzigen Thread. Moderne Mehrkernprozessoren liegen brach.
  • Speicherhunger: Im DOM-Modus muss der komplette XML-Baum in den RAM passen. Bei großen Lösungen führt das zu Speicherengpässen – mehrere Beta-Tester waren bereits an genau diese Grenze gestoßen.

In der Praxis bedeutete das: Eine gewachsene Lösung mit 57 XML-Dateien und rund 1,2 GB Gesamtgröße vom Roh-XML brauchte etwa 50 Minuten für eine Komplettkonvertierung. Sie produziert bei der Konvertierung einen Memory-Footprint von ca. 16 GB.

Die Lösung: Katana Engine

Der Name ist Programm – das japanische Schwert zerlegt das XML in handhabbare Stücke. Der Ansatz kombiniert mehrere Verfahren:

  • Hybrides Parsing: Das Webbed-Plugin beherrscht zwei Betriebsmodi – den speicherhungrigen DOM-Modus und das speichereffiziente SAX-Streaming. Beide sind allerdings nicht auf Parität: Es gibt Sonderfälle beim Decoding bestimmter Entities und Konstrukte, die nur einer der beiden Modi sauber auflöst. Die Katana Engine schneidet das XML an genau den Stellen klein, an denen beide Verfahren zuverlässig arbeiten können.
  • Selbstkonfiguration: Vor dem Lauf prüft die Engine die Umgebung – verfügbarer Speicher, Anzahl der CPU-Kerne, VM oder Host-System – und wählt Partitionierung und Engine automatisch. Man kann das Verfahren auch manuell setzen, out of the box trifft das Tool aber eine gute Wahl. Auch bei knappem Speicher läuft der Vorgang sauber durch, dann eben etwas langsamer.
  • Delta-Verarbeitung per Hash: Beim ersten Durchlauf merkt sich die Engine für jeden Katalog (Skripte, Layouts, Felder und alle weiteren Unterkataloge) einen Hashwert und einen Zeitstempel. Beim nächsten Export entscheidet sie pro Katalog, ob überhaupt neu gelesen werden muss. Wer in einer 2-GB-Lösung drei Skripte und ein Layout ändert, bei dem werden anschließend auch nur diese vier Objekte eingelesen.
  • Parallele Verarbeitung über Parquet: Die Schnipsel – in großen Lösungen über 900 Einzeldateien – werden von parallelen Workern in das spaltenorientierte Parquet-Format überführt. Dieses native Datenformat kann DuckDB anschließend sehr schnell parallel importieren.
  • Vollständige Katalogauflösung: Nur der Einleseteil wird durch Parallel-Verabeitung beschleunigt. Am Ende läuft immer die komplette Referenzauflösung über alle Objekte, damit keine Verknüpfung verloren geht – auch dann nicht, wenn ein geändertes Skript eine neue Beziehung zu einem übersprungenen Schnipsel aufgebaut hat.

Ergebnis

Im Webfrontend wird die Verarbeitung anschaulich visualisiert – eine Übersicht zeigt alle Dateien, den Konvertierungs-Status, den Durchlauf der einzelnen Phasen und die Parallel-Verabeitung der Chunks. Zusätzlich wird ein Log-File erzeugt, dass sich live im Frontend verfolgen lässt.

In der Live-Demo lief eine Lösung mit 1,17 GB XML durch: rund 912 Chunks, über 600.000 Objekte, Gesamtdauer knapp zwei Minuten – und das in einem Docker-Container mit lediglich 16 GB RAM. Der zweite Durchlauf mit der Option “nur geänderte Dateien” war nach drei Sekunden fertig, weil die Engine zuverlässig feststellt, dass nichts zu verarbeiten war.

Damit öffnet sich eine neue Perspektive: Der FileMaker Server könnte alle 15 Minuten ein frisches XML exportieren und durch die Pipeline schicken. Das Ergebnis ist ein digitaler Zwilling der Lösung, der praktisch immer auf aktuellem Stand ist – und auf dem alle weiteren Analysewerkzeuge aufsetzen.

Fazit

Aus einem Batch-Prozess, den man über Nacht laufen ließ, wird interaktives Arbeiten. Die Konvertierung ist damit nicht länger der begrenzende Faktor.

Weitere Infos:

FM-Lab – Katana XML Engine
https://github.com/marcel-more/fm-lab/blob/main/docs/fm-lab/Wiki/katana-engine.md