Datentransfer – Was einfach klingt ist deutlich komplexer

Daten sind allgegenwärtig – und doch verursachen sie so viele Probleme: sie zu beschaffen, zu speichern, zu verschieben, zu bereinigen, sie also tatsächlich zu nutzen. Mit dem richtigen Tool kann die richtige Art von Daten, auf die richtige Weise eingesetzt, von unschätzbarem Wert sein. Das Problem ist jedoch die Übertragung von Daten.

Dies beginnt damit, dass Daten so weit verstreut sind, dass sie irgendwohin übertragen werden müssen, wenn ein Unternehmen etwas damit anfangen will. Unternehmen sammeln Daten, ihre verschiedenen Abteilungen oder sogar einzelne Mitarbeiter sammeln Daten, sie werden an verschiedenen Orten und in verschiedenen Formaten gespeichert. Um hier Ordnung zu schaffen, müssen die Daten also verschoben oder übertragen werden, doch die Herausforderung liegt im Detail.

Stefan Käser, Solution Architect bei DoubleCloud, erklärt die Grundlagen von Datentransfer und zeigt, dass hinter diesem recht simplen Begriff mehr steckt, als man zunächst glaubt. DoubleCloud aus Berlin ist ein junger Anbieter eines modernen Data-Stacks für End-to-End-Analytik:

Was sind eigentlich Daten?

Laut Wikipedia sind Daten „eine Sammlung von einzelnen Werten, die Informationen vermitteln, die Quantität, Qualität, Fakten, Statistiken, andere grundlegende Bedeutungseinheiten oder einfach Folgen von Symbolen beschreiben, die weiter interpretiert werden können“. Daten sind etwas, das Informationen speichert und eine gewisse Struktur hat, wie eine Tabellenkalkulation, in der jede Zeile und Spalte eine Information enthält. Um sie von einem Ort zum anderen zu verschieben, sind zwei völlig unterschiedliche Arten von Speicher erforderlich – einer, um sie zunächst zu speichern, und einer, um sie zu verschieben.

Welche Daten werden verschoben?

Es kann sich um Tabellen aus Datenbanken handeln, strukturierte oder halbstrukturierte Daten, die aus einer API, einer Rohdatei oder einer Streaming-Plattform (wie z. B. Apache Kafka) stammen, oder sogar um völlig unkategorisierte Daten, die nützlich aussehen und eine gewisse Struktur aufweisen. Unabhängig von der Art der Daten gilt es, zunächst die Struktur zu definieren, die Unternehmen nach dem Verschieben haben möchten, und die Datenmenge, die sie verschieben wollen. Dies beginnt damit, sie zu lesen, damit sie an anderer Stelle geschrieben werden können. Bei Tabellen ist dieser Prozess nicht schwierig, da fast jede Art von Tabelle mit einem Schema versehen ist. Das heißt, um eine Tabelle von einer Datenbank in eine andere zu übertragen, müssen Benutzer in der Lage sein, ihr Schema zu definieren, die Daten zu lesen und sie dann in die neue Zieldatenbank zu schreiben.

Bei unstrukturierten Daten, z. B. APIs, S3-Dateien oder sogar Streaming-Nachrichten, wird es etwas komplizierter, da Benutzer selbst ein Schema für diese Daten erstellen müssen. Wenn sie Glück haben, ist das nur einmal nötig. Bei Aufgaben wie APIs oder S3-Buckets ist immer bekannt, welche Art von Struktur erforderlich ist, so dass es relativ einfach zu bewerkstelligen ist. Bei anderen Aufgaben bleibt jedoch kaum eine andere Wahl, als jede Entscheidung von Fall zu Fall zu treffen. So entsteht ein so genannter Snapshot.

Ein Snapshot der Daten definiert Wikipedia wie folgt: „Ein Snapshot ist der Zustand eines Systems zu einem bestimmten Zeitpunkt. Der Begriff wurde als Analogie zur Fotografie geprägt. Er kann sich auf eine tatsächliche Kopie des Zustands eines Systems oder auf eine von bestimmten Systemen bereitgestellte Fähigkeit beziehen.“ Bei Tabellen ist es sogar noch einfacher, da jede Datenbank, die Benutzer erstellen, so konfiguriert werden kann, dass sie über eine API bedient werden kann, z.B. SQL, so dass Benutzer alle Daten auswählen können, die sie aus der zu schreibenden Tabelle benötigen.

Das Problem entsteht, wenn mehr Daten hinzukommen

Wenn die Daten von einer Plattform zur nächsten wandern, kommen mehr Daten in die erste Plattform, so dass der Snapshot nicht mehr genau ist. Dies stellt ein Problem für alle dar, die sich auf Echtzeitdaten oder echtzeitnahe Daten verlassen, was als Datenlatenz bezeichnet wird. Um wieder einen „Live“-Blick auf die Daten zu erhalten, gilt es, diese erneut hinüber zu kopieren, was solange gut geht, bis mehr Daten eintreffen. Dieser Prozess ist gängig, aber irgendwann müssen IT-Administratoren diese Fragen beantworten: Wie viele Daten kommen herein, wie schnell können wir sie weiter übertragen und wie wichtig ist uns „Echtzeit“. An dieser Stelle kommt die Optimierung des Prozesses ins Spiel.

Eine schnelle und einfache Lösung besteht darin, nur neue Daten zu übertragen, anstatt ständig den gesamten Datensatz zu kopieren. Dazu müssen Benutzer markieren, was sie bereits kopiert haben, um zu wissen, was sie beim nächsten Mal kopieren müssen – und was nicht. Dazu filtern sie die bereits kopierten Daten heraus und speichern einen Cursor – in den meisten Fällen wird dies der universelle Cursor sein – die Zeit. Wie in den meisten APIs gibt es eine Funktion namens start_data oder begin_time, mit der sich alle alten, bereits übertragenen Daten herausfiltern lassen. Das funktioniert auch in einer Datenbank. Die Benutzer müssen nur eine Spalte created_at oder modified_at anlegen und die Daten mit dem SQL-Prädikat where created_at > today() – 1 auswählen. In der Regel ist dies als inkrementeller Kopierprozess definiert. Dieser ist einfach zu implementieren, besonders gut skalierbar bei kleinen bis mittelgroßen Datensätzen und bietet cursorähnliche Spalten oder Datenpunkte.

Bei dieser Technik ist jedoch zu beachten, dass alle gelöschten Datensätze in den alten Daten gespeichert werden, was bedeutet, dass die Daten nicht mit der Quelle konsistent sind, wenn diese gelöscht wird. Angenommen, ein Benutzer kopiert die heutigen Daten, löscht dann aber ein paar Datensätze daraus – entweder aus Versehen oder weil er sie nicht braucht: Wenn er das nächste Mal Daten überträgt, sieht er nur die neuen Daten, nicht aber die gelöschten Datensätze. Um dieses Problem zu beheben, gilt es, in das Innere einer Datenbank einzutauchen, ein Konzept, das als Write Ahead Logging bekannt ist.

Wie Write Ahead Logging zum Einsatz kommt

Jede Datenbank ist nur ein Protokoll von Operationen, die durchgeführt werden müssen. Dieses Protokoll wird Write-Ahead-Log genannt, und darin befinden sich transaktionsgebundene Operationen, die Datenbankbenutzer auf ihre Zeilen anwenden können. Mit diesem Wissen können sie nun einen Prozess erstellen, der das Quell-Schreibprotokoll nimmt und es „in flight“ auf die Zieldatenbank anwendet. Auf diese Weise lässt sich das Problem der Datenlatenz lösen, da nur ein kleiner Prozentsatz der Daten übertragen werden muss, und die Konsistenzprobleme, da nun auch Anwendungs-, Lösch- und Aktualisierungsvorgänge möglich sind. Dieser Prozess nennt sich Change Data Capture (CDC).

Was ist eine Änderungsdatenerfassung?

Laut Wikipedia ist in Datenbanken „die Änderungsdatenerfassung (Change Data Capture, CDC) ein Satz von Softwareentwurfsmustern, die verwendet werden, um die geänderten Daten zu bestimmen und zu verfolgen, so dass Maßnahmen unter Verwendung der geänderten Daten ergriffen werden können. CDC ist ein Ansatz zur Datenintegration, der auf der Identifizierung, Erfassung und Bereitstellung von Änderungen an Unternehmensdatenquellen basiert.“

CDC ermöglicht es im Regelfall, Daten von der Quelle zum Ziel zu replizieren, was eine effiziente, wenn auch manchmal etwas komplizierte Methode zur Datenübertragung ist. Die Übertragung von Daten ist nicht immer so einfach, wie es aussieht. DoubleCloud hat deshalb eine Plattform entwickelt, die all diese Techniken bereits für Unternehmen implementiert, damit die Benutzer sich nicht darum kümmern müssen.