Datenkollektoren - Daten kontinuierlich erfassen

Ein Datenkollektor ist ein Prozess, der Daten zyklisch aus einer Quelle abruft, prüft und in Ihrer Datenbank speichert – ohne jeden Durchlauf manuell zu starten. Für Dashboards und Prognosen mit regelmäßigen Aktualisierungen ist er ein wichtiger Teil der Datenschicht; einmalige Analysen können einen kontrollierten Export nutzen.

Vor der Kalkulation müssen neben dem Abruf auch Validierung, Duplikate, Wiederholungen, verspätete Daten, Monitoring, Aufbewahrung und Wiederherstellung nach einem Ausfall berücksichtigt werden. Bei einer einfachen Quelle kann diese Hülle mehr Arbeit erfordern als der API-Aufruf selbst.

Woraus ein solider Kollektor besteht

Sechs Elemente, deren Umfang zur Quelle, Datenaktualität und den Kosten einer Lücke passen muss:

1. Abruf aus der Quelle – Programmierschnittstelle, Datenbank, Datei oder Website.
2. Validierung – ob die Daten die erwartete Struktur und plausible Werte haben. Ein Kollektor, der alles speichert, was er erhält, vergiftet die Datenbank still.
3. Zeit- und Herkunftskennzeichen – wann abgerufen und woher. Ohne diese können Sie keine Abweichung diagnostizieren.
4. Idempotentes Speichern – die Wiederholung desselben Abrufs darf keine Daten duplizieren. Das ist Voraussetzung, um fehlgeschlagene Läufe sicher wiederholen zu können.
5. Fehlerbehandlung mit Wiederholungen – mit wachsendem Abstand zwischen Versuchen, um eine gestörte Quelle nicht zusätzlich zu belasten.
6. Alert und Log – die Information, dass etwas nicht funktioniert, bevor es jemand beim Blick auf den Bericht bemerkt.

Ein Alert ist ein Systemelement, ersetzt aber keine Vollständigkeitskontrolle. Es braucht außerdem einen Verantwortlichen, eine erwartete Lieferzeit für die Daten und ein Verfahren zum Schließen einer Lücke. Unvollständige Daten ohne klare Kennzeichnung können zu einer falschen Entscheidung führen.

Vier Abrufarten und wann welche passt

Methode	Wie sie funktioniert	Wann verwenden
Periodisches Polling	Alle X Minuten fragen wir die Quelle nach neuen Daten	Wenn die API inkrementelles Lesen unterstützt und die akzeptable Verzögerung im Intervall liegt
Eingehende Ereignisse	Die Quelle sendet selbst eine Benachrichtigung über eine Änderung	Wenn eine Reaktion mit geringer Verzögerung nötig ist und der Anbieter Wiederholungen dokumentiert
Periodischer Batch	Einmal täglich der gesamte Satz oder sein Zuwachs	Große Volumina, historische Daten
Abruf von einer Website	Website-Inhalte lesen, wenn es keine Schnittstelle gibt	Eine gegen HTML-Änderungen anfällige Lösung; Nutzungsbedingungen und häufigere Kontrollen müssen geprüft werden

Garantien für Webhooks und Streams hängen vom Anbieter ab: Ereignisse können wiederholt, mehrfach, verspätet oder in anderer Reihenfolge geliefert werden. Entwerfen Sie den Empfänger idempotent und prüfen Sie die Dokumentation der jeweiligen Quelle. Ein periodischer Abgleich mit API oder Export kann eine zusätzliche Absicherung der Vollständigkeit sein.

Wo speichern?

Für Messdaten und zeitlich geordnete Ereignisse ist TimescaleDB eine Option, eine PostgreSQL-Erweiterung, die unsere Analyse- und Prognoseplattform nutzt. Sie ist nicht für jedes Projekt nötig: Ein kleines Volumen kann in gewöhnlichem PostgreSQL bleiben, während andere Lasten einen spaltenorientierten Speicher oder einen Streamingdienst rechtfertigen können.

Drei Fragen dieses Datenmodells klären wir zu Beginn:

• Rohdaten getrennt von verarbeiteten Daten – falls sie benötigt werden. Die Aufbewahrung beschränken wir gemäß Zweck, Kosten, Vertrag und Datenminimierung. Einen vollständigen Rohdatenbestand bewahrt man nicht unbegrenzt „für alle Fälle“ auf.
• Wie lange Details aufbewahrt werden. Stündliche oder tägliche Aggregate können bleiben, während ältere Details nach einer klaren Regel gelöscht werden. TimescaleDB unterstützt automatische Aufbewahrungsrichtlinien und eine getrennte Aufbewahrung von Aggregaten. Quelle: Dokumentation zur Datenaufbewahrung in TimescaleDB.
• Wie unsichere Daten gekennzeichnet werden. Ein verspätet abgerufener oder durch eine Schätzung ergänzter Wert muss erkennbar sein.

Warum Kollektoren still ausfallen

Fünf häufigste Ursachen, alle aus der Praxis:

• Der Anbieter hat Format oder Schnittstelle geändert. Termin und Umfang der Änderung wurden in der Integration nicht verarbeitet.
• Ein Token oder Passwort ist abgelaufen. Der Kollektor wird abgewiesen und ruft nichts mehr ab.
• Der Datenumfang hat sich geändert. Die Quelle liefert nun weniger Datensätze, technisch korrekt – daher entdeckt keine reine Formatprüfung das Problem.
• Ein Abfragelimit wurde überschritten. Die Quelle lehnt einen Teil der Aufrufe ab, und die Daten erhalten Lücken.
• Zeit- und Zeitzonenwechsel. Ortszeit, UTC sowie Sommer- und Winterzeit können Lücken oder Duplikate erzeugen, wenn das Zeitmodell nicht explizit ist.

Die praktische Schlussfolgerung: Eine Formatprüfung genügt nicht. Es braucht eine Plausibilitätsprüfung. Ein Alert kann auf fehlende Daten im erwarteten Fenster, eine geänderte Datensatzanzahl oder Werte außerhalb eines festgelegten Bereichs reagieren. Die Schwellen müssen getestet werden, damit sie das Team nicht mit Fehlalarmen überfluten.

So führen wir es ein

1. Quelleninventar – was, wo, auf welchem Weg, wie oft ändert es sich, welche Limits gibt es?
2. Datenmodell – was ist ein Datensatz, welchen Zeitstempel hat er, wie erkennen wir ein Duplikat?
3. Ein Kollektor von Ende zu Ende, einschließlich Alerts. Niemals fünf Kollektoren ohne Alerts.
4. Plausibilitätskontrollen, die zur jeweiligen Quelle passen.
5. Statuspanel – ob jede Quelle antwortet und wann sie zuletzt Daten geliefert hat. Das ist das Erste, worauf wir bei jeder Unsicherheit über Zahlen schauen.
6. Erst danach die Analyseschicht – Dashboard, Berichte, Prognosen.

Wann kein Kollektor nötig ist

• Wenn die Daten bereits an einem Ort und ordentlich strukturiert sind. Dann genügt ein an die Datenbank angeschlossenes Reporting-Werkzeug.
• Wenn die Frage selten gestellt wird und keinen Alert braucht. Ein kontrollierter Export auf Abruf kann günstiger sein als ein ständig betriebener Prozess.
• Wenn noch nicht klar ist, welche Kennzahlen gebraucht werden. „Alles auf Vorrat“ zu sammeln erzeugt Speicher- und Arbeitskosten ohne Entscheidung am Ende. Klären Sie zuerst, welche Entscheidungen Sie treffen – eine Methode dazu in Vanity Metrics.
• Wenn die Quelle keinen stabilen Abrufweg hat. Das Auslesen einer Website ist manchmal die einzige Option, muss dann aber bewusst als störungsanfällig akzeptiert werden.

Was kostet das?

Kollektoren sind meist Teil eines Analyseprojekts, keine separate Anschaffung. Unsere Preisrahmen vom August 2026: Dashboard mit Integration einiger Quellen 15.000–40.000 PLN netto, Plattform mit Kollektoren und automatischem Reporting 40.000–120.000 PLN netto, Betrieb 2.000–7.000 PLN netto/Monat.

Die Kalkulation wird durch Anzahl der Quellen, Qualität ihrer Schnittstellen, Volumen, erforderliche Aktualität, Aufbewahrung und Garantien zur Wiederherstellung beeinflusst. Legen Sie für jede Entscheidung die maximal akzeptable Verzögerung fest, statt automatisch Echtzeit zu wählen.

Häufige Fragen

Reicht nicht ein fertiges Werkzeug für die Datenintegration?

Bei einfachen Quellen und kleinen Volumina oft doch, und das sagen wir offen. Eigene Kollektoren sind sinnvoll, wenn Daten individuell verarbeitet werden müssen, das Volumen groß ist oder ein Ausfall Geld kostet. Die Grenzen dieser Wahl beschreiben wir in Systemintegration ohne Programmierer.

Was, wenn die Quelle keine Programmierschnittstelle hat?

Prüfen Sie Dateiexport, reinen Lesezugriff auf die Datenbank, eine Ereigniswarteschlange oder eine offizielle Partnerintegration. Das Auslesen einer Website ist die letzte Option: Es erfordert Zustimmung zu dieser Nutzungsweise, eine Analyse der Dienstbedingungen und die Akzeptanz einer größeren Anfälligkeit für HTML-Änderungen.

Wie lange sollten historische Daten aufbewahrt werden?

So lange, wie es der konkrete Zweck, Vertrag oder eine gesetzliche Pflicht verlangt – und ohne Begründung nicht länger. Für Prognosen wird die benötigte Historie nach Datenfrequenz, Saisonalität, Strukturänderungen und Validierungsmethode bestimmt; es gibt keine universelle Anforderung von zwei Zyklen. Aggregate können länger als Details gespeichert werden, wenn sie weiterhin dem Analysezweck entsprechen.

---

In unserem eigenen Produktivbetrieb halten wir überwachte Kollektoren vor, die für kontinuierliche Arbeit konzipiert sind. Unterbrechungen passieren; Erfahrung umfasst ihre Erkennung, Diagnose und das Ergänzen von Daten. Sehen Sie sich Daten und Analyse sowie unsere Plattform an.