Kategorien
Einer für alle – Import unification
Mashups sind nichts Neues mehr. Die halbe digitale Welt besteht aus der Aggregation von Inhalten aus verschiedensten Quellen. Dieser Artikel beschreibt eine Herangehensweise aus technischer Sicht, um solche Importe aus performante und skalierbare Weise zu planen und zu entwickeln.
Die Ausgangssituation ist folgendermaßen definiert:
Gegeben ist eine Plattform in beliebiger Hochsprache mit der Möglichkeit XML Daten performant zu verarbeiten. Diese Plattform stellt Daten in aufbereiteter Form Nutzern zur Verfügung und bezieht diese Daten aus einer oder mehreren Quellen in diversen strukturierten Formaten (XML, JSON, CSV, etc.). Alle Datensätze werden in einer beliebigen, relationalen Datenbank persistiert. NoSQL Datenbanken werden hier bewusst ausgelassen, da die Möglichkeiten, die diese Art der Datenhaltung mitbringen, das Ziel dieses Artikels überschreiten würden und eher in einem weiteren Artikel Beachtung finden sollten.
Ein erster Gedankengang geht in die Richtung für jede der gegebenen Quellen einen eigenen Prozess zu planen, ein Mapping oder eine Transformation zu definieren und darauf hin einen Importer zu entwickeln, der diesem Prozess Folge leistet. Diese Herangehensweise hat Vor- und Nachteile. Der, in meinen Augen, größte Vorteil liegt in der Detailtreue des einzelnen Imports. Er kann auf die Eigenheiten und Feinheiten der jeweiligen Datenstrukturen eingehen. Doch hier beginnt schon der erste nachteilige Aspekt zu wirken, denn es schleicht sich meist zu viel Applikationslogik mit in den Import ein, der im Grunde nur Daten transportieren und transformieren soll. Skalieren wir das Szenario nun auf 100 verschiedene Importe, so wird eine Anpassung an der eigenen Datenhaltung zum teuren Unterfangen. Jeder Import muss daraufhin angepasst werden, getestet werden und vielleicht sogar neu optimiert werden. In meinen Augen ein erschreckendes Bild, dass es, nicht nur aus betriebswirtschaftlicher Sicht, zu vermeiden gilt. Ein weiterer Nachteil ist, dass solche Importe meist selbst schlecht skalieren. Wenn ein Import Prozess bei einer Eingangsdatenmenge von 100 MB 60 Sekunden zur Verarbeitung benötigt, dann werden 1000 MB im besten Fall 600 Sekunden brauchen. Schneller kann es nur unter zwei Bedingungen gehen – ich kaufe bessere Hardware oder ich optimiere den Import. Beides hat seine Grenzen, denn irgendwann habe ich den schnellsten Server und den schnellsten (und zumeist auch am wenigsten wartbaren) Quellcode – das Ende der Fahnenstange in diesem Fall.
Es ist hoffentlich deutlich geworden, dass eine Alternative gefunden werden muss, die neben der Wartbarkeit und Skalierbarkeit auch Geschwindigkeit hergeben muss.
Für diese Lösung ist ein wenig umdenken erforderlich. Wir teilen dafür die Aufgabe in zwei Teile. Der Erste ist adaptiv, also auf das Eingangsformat abgestimmt. Der Zweite ist stetig der Selbe, also ein einziges, fest definiertes und validierbares Format, in diesem Szenario XML, zu importieren. Es drängt sich die Frage auf, was sich damit an der Lösung der Problemstellung ändert? Einiges, wenn nicht sogar alles.
Wir rollen das Feld von hinten auf und beginnen mit dem zweiten Teil, der Import Phase. Wir gewinnen durch die Festlegung eines einzigen Formates die Möglichkeit den Import auf genau ein Format zu optimieren – sowohl den Speicherverbrauch, als auch die Ausführungsgeschwindigkeit. Änderungen an der Datenstruktur brauchen nur in einem Import reflektiert werden. Der Aufwand für eine Änderung wird damit berechenbar. Obendrein bekommen wir mit einem Bruchteil von Tests eine deutlich höhere Abdeckung zu Stande – was wiederum zu erhöhter Qualität führt. Diese Kausalkette darf jeder gern für sich selbst fortsetzen, die Richtung sollte jedoch klar geworden sein.
In der ersten Phase, der Unify Phase, geht es schlich darum, das Fremdformat in das Eigene zu überführen. Auch dieser Prozess kann für sich selbst pro Quelle optimiert werden. Der Vorteil, der hierbei jedoch heraus sticht, ist die gewonnene Verteilbarkeit dieses Prozesses. Unter Verwendung von z. B. Hadoop lässt sich die Verarbeitungsgeschwindigkeit nicht nur mit der Leistung der Hardware sonder viel mehr mit der Anzahl der Hardware skalieren.
Sicherlich lässt sich dieser Ansatz nicht auf jeden Import in jedes System übertragen, jedoch ist es gerade für beständige Systeme (z.B. Shops, News Sites oder Aggregatorsuchen) aus meiner Sicht ein Gewinn.
An dieser Stelle noch ein Hinweis aus eigener Erfahrung. Die Import Phase ist vom Grunde her ebenfalls verteilbar. Jedoch ist hier die Leistung der Datenbank-Server, bzw. -Hardware der „Deckel“. Man kann schon mit einem kleinen Hadoop Cluster einen gut dimensionierten Datenbank Server ausknocken. Es ist Vor- und Umsicht geboten ;).
