Herausforderungen in Phase 1
Beim Aufbau einer Streamingplattform standen wir vor vielen Herausforderungen.
Herausforderung 1: Hohe Skalierung mit begrenzten Ressourcen. Wir hatten sechs Monate Zeit, um Keystone so aufzubauen, dass 500 Milliarden Ereignisse pro Tag verarbeitet werden konnten - und das ganze mit nur sechs Teammitgliedern.
Herausforderung 2: Unreife Streamingumgebung. Die Entwicklung und der Betrieb einer Infrastruktur mit dem Ansatz "Streaming First" war 2015 noch sehr schwierig, da sowohl Transport- (Apache Kafka) als auch Verarbeitungstechnologien (Apache Samza, Apache Flink) gerade erst aufkamen. Nur wenige Technologieunternehmen verfügten über erwiesenermaßen erfolgreiche Deployments mit Streaming als oberster Priorität in dem von uns benötigten Maßstab.
Deshalb mussten wir alle technologischen Möglichkeiten auswerten und experimentieren. In Anbetracht unserer begrenzten Ressourcen konnten wir nicht einfach alles selbst aufbauen, sondern mussten entscheiden, was wir selbst entwickeln und auf welche aufkommenden Tools wir setzen würden.
Herausforderung 3: Analytische und operative Bedenken unterscheiden sich. Der Schwerpunkt bei der analytischen Streamverarbeitung liegt auf Richtigkeit und Vorhersehbarkeit. Beispielsweise sind für die Verschiebung aller Clickstreams der Benutzer in das Data Warehouse Datenkonsistenz (minimale Duplikate oder Verluste) und Vorhersehbarkeit bei der Latenz (die üblicherweise im Bereich von Minuten liegt) notwendig. (Hierbei ist Keystone wirklich gut.)
Bei der operativen Streamverarbeitung liegt der Schwerpunkt eher auf Wirtschaftlichkeit, Latenz und Verfügbarkeit. Wenn wir zum Beispiel den Zustand der gesamten Gerätelandschaft von Netflix kennen, können wir von Latenzen profitieren, die im Sekundenbereich oder sogar darunter liegen. Außerdem können Stichproben oder Profile der Daten aus der Quelle erstellt werden, um Kosten zu sparen. (Hierbei ist Mantis wirklich gut.)
Herausforderung 4: Cloudeigene Resilienz für eine zustandsbehaftete Datenplattform ist schwierig. Netflix arbeitete bereits seit einigen Jahren in der AWS-Cloud. Wir waren jedoch die Ersten, denen es gelang, eine zustandsbehaftete Datenplattform in die auf Containern basierende Cloudinfrastruktur zu bringen. Im Hintergrund laufen in allen Rechenzentren Hunderttausende physischer Maschinen, die die Cloud antreiben. Bei diesem Umfang sind Hardwareausfälle unvermeidlich.
Wenn diese Ausfälle unerwartet auftreten, kann es für die Systeme sehr schwierig werden, die Erwartungen hinsichtlich Verfügbarkeit und Konsistenz zu erfüllen. Die Herausforderung ist in einer ungebundenen Umgebung für die Streamverarbeitung mit niedriger Latenz, bei der jede Ausfallwiederherstellung dazu führen kann, dass sich Gegendruck aufbaut, sogar noch größer. Eine cloudeigene Resilienz für eine Streaming-First-Architektur würde uns vor enorme technische Herausforderungen stellen.
Zusammenfassung zu Streamverarbeitungsmustern in Phase 1
Ich stelle einige selbst beobachtete Anwendungsfälle mit den jeweiligen Streamverarbeitungsmustern für jede Innovationsphase vor. Das vermittelt ein Gefühl für die Entwicklung im Laufe der Zeit.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
- ohne Werbung
- mit ausgeschaltetem Javascript
- mit RSS-Volltext-Feed
Muster | Produkt | Anwendungsfälle |
---|---|---|
Datenrouting | Keystone | Protokollierung, Datenbewegung (MVP) |
Echtzeitwarnungen / Dashboard | Mantis | SPS-Warnung |
Phase 1: Rettung der Netflix-Protokolle | Strategiewetten in Phase 1 |
Ich hatte den Artikel in meinem RSS feed gespeichert, weil ich die Thematik sehr...
Ich finde den Artikel auch furchtbar "sperrig". Und ja, ist mir auch schon desöfteren...
kwt.
Kommentieren