Zurück zur Startseite

ETL für 15 Millionen GPS-Pings: Stack und Architektur

ETL-System verarbeitet täglich 15 Millionen GPS-Pings von Tashkent-Bussen. Verwendet PostgreSQL mit PostGIS, PySpark für räumliche Analysen und Data Vault 2.0 für Modellierung. Segmentiert Fahrten nach Geschwindigkeit, Lücke und Nähe zu Haltestellen und bildet analytische Marts.

15 Millionen GPS-Pings pro Tag: Wie baut man ETL für Busse?
Advertisement 728x90

Verarbeitung von 15 Millionen GPS-Pings täglich: ETL-Architektur für Transportanalysen

Das System verarbeitet 15 Millionen GPS-Koordinaten von 1.800 Bussen auf 170 Linien in Taschkent. Pings kommen alle 10 Sekunden über die 3TM-API. Die größte Herausforderung ist die Umwandlung isolierter Koordinaten in strukturierte Daten für Analysen: Haltestellen, Staus, Fahrten und Routenabweichungen müssen identifiziert werden.

Ein Loader mit asyncio + aiohttp ruft die API über systemd-Timer ab. Daten werden in PostgreSQL mit PostGIS geschrieben. Die ETL-Orchestrierung über Dagster stellt die Reihenfolge sicher: Routen → Busse → Haltestellen → GPS-Updates.

Technologieauswahl und Vermeidung von Over-Engineering

Zunächst wurden Kafka und ClickHouse getestet, erwiesen sich aber als ungeeignet:

Google AdInline article slot
  • Kafka ist für ein Pull-basiertes API-Abrufmodell nicht ideal – es bringt Overhead ohne Nutzen.
  • ClickHouse ist bei den aktuellen Abfragevolumen verfrüht.

Finaler Stack:

  • Erfassung: Asynchroner Python-Loader, ~360 Einfügungen/Sekunde auf 2 vCPU / 4 GB RAM.
  • Speicherung: PostgreSQL + PostGIS für Routen, Haltestellen, GPS-Zeitreihen.
  • Orchestrierung: Dagster für Abhängigkeiten und Nachverfolgbarkeit.
  • Raumanalysen: PySpark für aufwändige Aufgaben – Zuordnung von GPS zu Routen, Berechnung der Auslastung.

Die Staging-Schicht speichert rohe JSON-Daten für 1 Tag, dann strukturiert ODS Daten im Speicher ohne erneutes Lesen aus der Datenbank.

Mehrschichtiges Datenmodell

Daten sind in drei Schichten für Skalierbarkeit und Nachvollziehbarkeit organisiert:

Google AdInline article slot
  • ODS: Operative Daten – Routen, Haltestellen, aktuelle Buspositionen.
  • DDS (Data Vault 2.0): Hubs (Entitäten), Satelliten (Attribute), Links (Beziehungen). GPS wird nicht gespeichert; Fokus liegt auf Routen, Bussen, Haltestellen.
  • CDM: Analytische Data Marts. Die Tabelle fct_bus_trips – PostGIS LineString pro Fahrt mit Metadaten: Zeitstempel, Kilometerstand, Geschwindigkeit, Übereinstimmungs-% mit Route.

Data Vault ermöglicht das Hinzufügen von Attributen (Telemetrie) ohne Modellüberarbeitung.

Fahrtsegmentierungs-Algorithmen

Segmentierung bestimmt Fahrtstart/-ende basierend auf drei Signalen:

  • Geschwindigkeit: Stillstand an Start-/Endhaltestellen.
  • Zeitlücke >5 Min: Unterbrechung des Datenstroms.
  • Nähe zum Routenendpunkt.

— Editorial Team

Google AdInline article slot
Advertisement 728x90

Weiterlesen