Data-Sink

Kurz: Der Endpunkt, an dem ein Datenstrom ankommt und verarbeitet oder gespeichert wird — das Gegenstück zur Datenquelle.

Genauer: In Datenpipelines beschreibt “Source → Sink” den Weg der Daten vom Ursprung (z. B. Sensor, API, Log-Datei) bis zum Ziel (z. B. Datenbank, Analyse-Tool, Dashboard). Der Begriff macht deutlich, dass Daten nicht nur transportiert, sondern am Ende irgendwo konsumiert werden müssen.

Im Detail

Rolle statt Produkt

Der Begriff stammt aus der Datenverarbeitung (ETL-Pipelines, Streaming-Systeme wie Apache Kafka oder Flink) und beschreibt bewusst nur die Rolle in einem Datenfluss, nicht ein konkretes Produkt: Dieselbe Datenbank kann in einer Pipeline als Sink fungieren (Daten werden dort abgelegt) und in einer anderen Pipeline gleichzeitig als Source (Daten werden von dort weitergelesen und an ein anderes System weitergereicht). Eine typische Kette sieht so aus:

Source (Sensor/API/Logfile) → Verarbeitung/Transformation → Sink (Datenbank/Dashboard/Data Warehouse)

Push- vs. Pull-Sinks

Wichtig ist die Unterscheidung zwischen Push- und Pull-Sinks: Bei einem Push-Sink schickt die Quelle die Daten aktiv dorthin, ohne dass der Sink von sich aus nachfragen muss (z. B. ein IoT-Sensor, der Messwerte in regelmäßigen Abständen an eine API sendet, oder ein Webhook, der bei jedem Ereignis sofort eine Nachricht auslöst). Bei einem Pull-Sink holt sich der Sink die Daten dagegen selbst aktiv ab, meist in festgelegten Intervallen (z. B. ein Analyse-Tool oder Business-Intelligence-Dashboard, das jede Nacht eine Datenbank abfragt und die neuen Datensätze importiert). Push-Modelle liefern tendenziell aktuellere Daten mit geringerer Verzögerung, belasten die Quelle aber stärker; Pull-Modelle sind einfacher zu kontrollieren (der Sink bestimmt selbst, wann er Kapazität für neue Daten hat), führen aber zu Verzögerung zwischen Entstehung und tatsächlicher Verarbeitung der Daten.

Mehrstufige Pipelines

Data-Sinks können außerdem selbst wieder als Quelle für die nächste Verarbeitungsstufe dienen — in komplexeren Pipelines entstehen so mehrstufige Ketten, bei denen derselbe Knotenpunkt gleichzeitig Sink für die vorherige und Source für die nächste Stufe ist. Ein typisches Beispiel: Rohdaten landen zunächst in einem Data Lake (Sink Stufe 1), werden von dort periodisch gelesen, bereinigt und aggregiert (der Data Lake wird zur Source, ein Data Warehouse zum Sink Stufe 2), und aus dem Data Warehouse liest wiederum ein Dashboard-Tool für die tägliche Visualisierung (Data Warehouse wird zur Source, das Dashboard zum finalen Sink).

Fehlerbehandlung an der Sink-Grenze

Ein praktisch wichtiger Aspekt bei Sinks ist die Behandlung von Fehlern und Wiederholungen: Schlägt das Schreiben in einen Sink fehl (z. B. weil die Zieldatenbank kurzzeitig nicht erreichbar ist), muss die Pipeline entscheiden, ob sie die Daten verwirft, zwischenspeichert und später erneut versucht, oder die gesamte vorgelagerte Verarbeitung anhält. Robuste Streaming-Systeme nutzen dafür häufig ein Konzept namens “Dead Letter Queue” — ein separater Ablageort für Datensätze, die auch nach mehreren Versuchen nicht erfolgreich in den eigentlichen Sink geschrieben werden konnten, damit sie später manuell untersucht werden können, ohne den restlichen Datenfluss zu blockieren.

Siehe auch: Übertragung, API