Datentransport auf neuen Wegen Deutsche Post DHL bewegt mit Apache Kafka (Daten-)Pakete

Anbieter zum Thema

Vogel IT-Medien GmbH

VMware Global Inc Zweigndl. Deutschland

Fujitsu Technology Solutions GmbH

DHL Vertriebs GmbH

DHL Freight GmbH

mehr weniger

Confluent Germany GmbH

weniger

Die Anzahl der Datenpakete wächst rasant, ein Umstand, der die Deutsche Post DHL dazu veranlasst, ihre Systemlandschaft zu modernisieren. Hierbei setzt das Unternehmen auf „Apache Kafka“ und „Confluent“, damit die großen Datenmengen in Echtzeit verarbeitet und korreliert werden können.

Die Deutsche Post DHL transportiert an einem Tag nicht nur Millionen physische Pakete: Auch innerhalb der IT-Landschaft des Postunternehmens wandern täglich rund ein Terabyte an Datenpaketen von einem System zum nächsten. Paketversand und diverse Zusatzleistungen hängen maßgeblich davon ab, dass diese Systeme uneingeschränkt miteinander kommunizieren und Daten in Echtzeit bereitgestellt werden.

Das passiert: Wir geben ein Paket bei der Deutschen Post ab, dieses wird gescannt und bis zum Weitertransport verstaut. Bei Bedarf erhalten wir noch einen Beleg für die Online-Sendungsverfolgung und schon ist der Versandprozess für uns an dieser Stelle beendet und wir vertrauen darauf, dass das Paket unbeschadet am Ziel ankommt.

Doch was braucht es abgesehen von Mitarbeitern, Fließbändern und Transportfahrzeugen, damit Pakete am vorgesehenen Abgabeort ankommen? Was passiert hinter den Kulissen im virtuellen Raum? Welche digitalen Prozesse spielen sich ab, damit diese kritische Infrastruktur funktioniert?

Der Status quo der Datenverarbeitung bei der Deutschen Post DHL

Der Schlüssel hierfür sind Daten, die sich ständig in Bewegung befinden, in Echtzeit verarbeitet und zwischen den verschiedenen Systemen transportiert und integriert werden. Dieses Konzept wird „Data in Motion“ genannt. Sobald ein Angestellter in einer der DHL-Filialen das Paket bei der Annahme einscannt, erzeugt das System Event-Daten.

Vom Transport zum Paketzentrum bis hin zur eigentlichen Zustellung beim Empfänger: Während der gesamten Verarbeitung entstehen unzählige Events, die verarbeitet und zu den Zielsystemen transportiert werden müssen. Mehr als 170 Millionen solcher Nachrichten stellen täglich den reibungslosen Paketversand sicher. Das entspricht einem täglichen Datendurchsatz von über einem Terabyte.

Diese Zahl soll künftig sogar weiter anwachsen: Die Deutsche Post rechnet in den kommenden Jahren mit mehr als 250 Millionen Events täglich und mit einem Peak-Durchsatz von über 7.500 Nachrichten pro Sekunde – eine Entwicklung, die die derzeitige Systemlandschaft der Deutschen Post nicht stemmen könnte.

Die Grenze ist erreicht

Das Verarbeitungssystem, das die Deutsche Post bis dato nutzte, besteht grundlegend aus zahlreichen Punkt-zu-Punkt-Verbindungen zwischen Datenproduzenten und -konsumenten und basiert auf der Messaging-orientierten Middleware „IBM MQ“. Diese sammelt die Daten, die die verschiedenen Systeme generieren und leitet sie an eine „Webmethods“-basierte Track-Event-Integration-Plattform weiter, die die Daten anreichert.

Über IBM MQ gelangen die Daten in das hauseigene Verteilsystem, das in einem „Weblogic Application Server“ implementiert ist. Hier entstehen wiederum neue Events, die die Konsumenten direkt mit den Daten zu beispielsweise logistischen und kaufmännischen Aktivitäten versorgen.

Eine Skalierung ist in einer solchen Umgebung schwer möglich; denn die steigende Event-Menge könnte nicht effizient und schnell genug verarbeitet werden. Es war also an der Zeit für eine Modernisierung.

Apache Kafka für eine effiziente Datenbereitstellung

Die Modernisierung sieht vor allem den Austausch der gesamten Transportlandschaft vor. Da die Datenproduzenten und -konsumenten vorerst weiterhin IBM MQ nutzen und sich auf die reibungslose Funktionalität der Middleware verlassen müssen, kann diese Umstellung nur sukzessiv verlaufen. Außerdem sollte die neue Transportplattform nicht nur den steigenden Event-Anforderungen der Deutschen Post gerecht werden, indem sie eine effiziente Verarbeitung und Integration großer Datenmengen in Echtzeit ermöglicht.

Sie muss zudem eine hohe Verfügbarkeit aufweisen und ausfallsicher sein. Daher entschied sich die Deutsche Post für den Einsatz der hochskalierbaren, hochverfügbaren und ausfallsicheren Daten-Streaming-Plattform Confluent, basierend auf Apache Kafka.

Zunächst setzte die Deutsche Post Kafka hauptsächlich für den Datenausgang ein, so dass Daten produzierende Systeme weiterhin mit IBM MQ arbeiten könnten und die erzeugten Events über die Middleware transportiert werden. Diese laufen wie gewohnt über die Track-Event-Integration-Plattform und IBM MQ in das Verteilsystem, das jedoch nun auf Basis einer „Spring-Boot“-Applikation umgesetzt wird, die sich einfacher horizontal skalieren lässt. Kafka nimmt diese Daten auf, woraufhin ein Distributor sie an die Konsumenten aufteilt.

Ein Blick in die Zukunft

Bislang hat sich die Deutsche Post vor allem auf den Datenausgang konzentriert. Jedoch besteht das System aus weit mehr als Datenkonsumenten. Dieses Jahr plant die Deutsche Post, Apache Kafka und Confluent auch im Rahmen der Datenproduktion sowohl in der Cloud als auch On-Prem anzubieten.

Dabei löst Kafka IBM MQ ab, bezieht die Daten direkt von den Produzenten und speist sie in die Track-Event-Integration-Plattform. Daraufhin beliefert Kafka das hauseigene, über eine Spring-Boot-Applikation umgesetzte Verteilsystem mit den angereicherten Daten.

Neben dem Dateneingang bleibt die weitere Modernisierung des Datenausgangs auch in den kommenden Jahren ein Thema: Hier erhalten einige Konsumenten derzeit die Daten weiterhin über Punkt-zu-Punkt-Verbindungen direkt von IBM MQ.

Diese ineffizient gewordene Form der Datenbereitstellung plant die Deutsche Post mittels des Publish-Subscribe-Prinzips zu umgehen. Unabhängig von den Releases des Verteilsystems sollen Datenkonsumenten künftig selbst bestimmen können, welche Daten relevant sind und die entsprechenden „Kafka Topics“ abonnieren. Auf diesem Weg können die sich bewegenden Daten effizienter und in Echtzeit über eine einzige technologische Schnittstelle bereitgestellt werden, unabhängig davon ob der Konsument eine Streaming-Anwendung, einen Web-Service, eine Datenbank oder eine Mobile App ist.

*Der Autor Kai Waehner ist Technologie-Evangelist sowie Field CTO und Global Technology Advisor bei Confluent.

(ID:47980737)